Миграция InfluxDB 0.9 до InfluxDB 1.1

Между 0.9 и 1.1 нет прямой совместимости, поэтому прежде всего понадобится какая-нибудь промежуточная версия на короткий промежуток времени:
# wget https://dl.influxdata.com/influxdb/releases/influxdb-0.11.1-1_linux_amd64.tar.gz

Сначала рекомендуется сбросить WAL (write-ahead log), для этого рекомендуется изолировать сервер InfluxDB от записи и выполнить его restart.
Далее, останавливаем InfluxDB 0.9 и с помощью утилиты influx_tsm из пакета InfluxDB версии 1.1 конвертируем директорию data.
Предполагается, что резервную копию данных мы уже сделали внешним образом.
# influx_tsm -parallel -nobackup /var/lib/influxdb/data

Утилита выводит список всех найденных файлов устаревшего формата b1 или bz1 и спрашивает Proceed? y/N:
После подтверждения данные преобразуются в новый формат tsm.

Далее осталось преобразовать в новый формат /var/lib/influxdb/meta. Для этого на некоторое время придется запустить InfluxDB версии 0.11
# ./influxdb-0.11.1-1/usr/bin/influxd -config /etc/influxdb/config.toml

И попросить его сделать резервную копию:
# influxd backup /tmp/backup/
2016/11/27 17:41:37 backing up metastore to /tmp/backup/meta.00
2016/11/27 17:41:37 backup complete

После этого сервер 0.11 можно выключить и загрузить резервную копию назад, но уже используя InfluxDB версии 1.1:
# influxd restore -metadir=/var/lib/influxdb/meta/ /tmp/backup/
Using metastore snapshot: /tmp/backup/meta.00

После этого восстановим права доступа
# chown -R influxdb:influxdb /var/lib/influxdb/

И можно запускать сервер InfluxDB 1.1
# systemctl start influxd

Открываем консоль influx и проверяем что все наши данные доступны.

Настройка звука в конфигурации с несколькими одинаковыми звуковыми картами

Имеется следующая конфигурация. Два звуковых устройства, оба управляются одним и тем же модулем snd-hda-intel. Первое устройство отвечает за звуковой канал в HDMI, встроенной в процессор графической системы. Второй устройство — обычный интегрированный на материнскую плату аудио-контроллер.
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
00:1b.0 Audio device [0403]: Intel Corporation 9 Series Chipset Family HD Audio Controller [8086:8ca0]
Пользователи жалуются, что звук не работает. Проблема состоит в том, что YaST создаёт следующую конфигурацию в 50-sound.conf:
options snd slots=snd-hda-intel,snd-hda-intel
alias snd-card-0 snd-hda-intel
alias snd-card-1 snd-hda-intel
Здесь snd-card-0 — звуковое устройство "по умолчанию". Очевидно, что в таком подходе ситуация, когда один и тот же модуль отвечает за два устройства, обрабатывается не корректно. Кто из устройств первый попал в функцию azx_probe модуля, тот и станет snd-card-0. В нашем случае, это не то устройство, которое нам хотелось бы. Это можно проверить, сделав
ls -l /sys/class/sound/card0/device
lrwxrwxrwx 1 root root 0 окт  9 21:36 /sys/class/sound/card0/device -> ../../../0000:00:03.0

Для восстановления правильного порядка предлагается делать следующее.
Во-первых, внимательно изучив исходники модуля, добавляем в 50-sound.conf:
options snd-hda-intel index=1,0
Во-вторых, надеемся, что при следующих загрузках порядок инициализации не будет меняться случайным образом, потому-что кто первый попадет в функцию azx_probe, тот теперь и будет card1. И это всё происходит в 2015 году, когда повсюду systemd и прочий udev, а звуковую карту за её DeviceId привязать нельзя.

Настройка вложенной виртуализации в ESXi 6.0

Иногда в гостевой системе требуется в свою очередь запускать виртуальные машины. В нашем случае, гипервизор VMWare ESXi 6.0 (он же известен под названием vSphere Hypervisor) используется для запуска различных операционных систем, сервисы в одной из которых, в свою очередь, динамически запускают qemu-kvm. Для того, чтобы kvm в гостевой системе работал, необходимо включить вложенную (nested) виртуализацию. Делается это следующим замысловатым образом.

Во-первых, в vmx-файл настроенной гостевой системы дописывается директива vhv.enable = "TRUE". Включить эту настройку из клиентского приложения, видимо, нельзя. Для редактирования файла можно сначала загрузить его на локальную машину, а затем отредактированную версию загрузить назад, используя браузер датастора гипервизора.
Во-вторых, нужно попросить гипервизор перечитать vmx-файл, как описано в тикете 1026043 базы знаний VMWare. А именно, используя ssh для доступа к командной строке гипервизора выполнить команды:
# vim-cmd vmsvc/getallvms
# vim-cmd vmsvc/reload Vmid
Первая команда просто отображает список всех виртуальных машин гипервизора, она нужна чтобы определить Vmid интересующей нас машины, это число используется во второй команде.

После этого стартуем виртуальную машину и проверяем, что аппаратная виртуализация стала доступна нам в гостевой системе:
# cat /proc/cpuinfo | grep vmx
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat epb dtherm tpr_shadow vnmi ept vpid
# lsmod | grep kvm
kvm_intel             151704  3 
kvm                   493230  1 kvm_intel

Удаленная сетевая консоль ядра Linux

Иногда, когда ядро Linux испытывает проблемы, одними из способов сбора отладочной информации являются консоль последовательного порта или сетевая консоль. Сразу обратим внимание, что второй вариант имеет как недостатки, например, предполагает, что сетевая подсистема ядра остается функциональной во время возникновения проблем, так и преимущества, например, можно сконфигурировать удаленно.

Полное описание сетевой консоли находится в документации ядра. Для настройки достаточно добавить в modprobe.d/99-local.conf:
options netconsole netconsole=@/,514@192.168.10.7/00:0C:29:F3:92:97
Здесь, 514 - номер UDP порта, 192.168.10.7 - IP удаленного хоста куда будет отсылаться информация, 00:0C:29:F3:92:97 - его MAC адрес, если его не указать явно то будет использоваться широковещательный адрес FF:FF:FF:FF:FF:FF, что может затруднить передачу информации в зависимости от настроек сетевого оборудования.
И загрузить модуль netconsole или, по желанию, поставить его на автозагрузку при старте системы.

После загрузки модуля netconsole, сетевая консоль начинает немедленно функционировать, а в системном журнале можно увидеть примерно следующее:
May  1 18:57:51 192.168.10.4 kernel: [162255.522603] netconsole: local port 6665
May  1 18:57:51 192.168.10.4 kernel: [162255.522673] netconsole: local IP 0.0.0.0
May  1 18:57:51 192.168.10.4 kernel: [162255.522710] netconsole: interface eth0
May  1 18:57:51 192.168.10.4 kernel: [162255.522746] netconsole: remote port 514
May  1 18:57:51 192.168.10.4 kernel: [162255.522784] netconsole: remote IP 192.168.10.7
May  1 18:57:51 192.168.10.4 kernel: [162255.522826] netconsole: remote ethernet address 00:0c:29:f3:92:97
May  1 18:57:51 192.168.10.4 kernel: [162255.522881] netconsole: local IP 192.168.10.4
May  1 18:57:51 192.168.10.4 kernel: [162255.523032] console [netcon0] enabled
May  1 18:57:51 192.168.10.4 kernel: [162255.523349] netconsole: network logging started

Данные приходят в самом простом текстовом виде и их можно читать самым простым способом:
netcat -u -l 514
Если у нас в наличии есть syslog-ng — можно использовать его следующим образом:
source s_remote_udp {
        network(transport("udp") ip(0.0.0.0) port(514));
};
filter f_remote_remhost {
        netmask(192.168.10.4);
};
destination d_remote_remhost {
        file("/var/log/remote/remhost.log");
};
log {
        source(s_remote_udp);
        filter(f_remote_remhost);
        destination(d_remote_remhost);
};

Проверить, что всё работает можно следующим образом:
echo '<7>Hello world!' > /dev/kmsg
dmesg -n 8
Сообщение должно появиться в журнале и быть передано по сети на удаленный хост.

Удаленная отладка ядра Linux

Ядро Linux периодически ломается, иногда это происходит на стадии загрузки. Одним из методов исследования проблемы является удаленная отладка с использованием последовательного порта.

Опции конфигурации ядра должны быть такими:
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
Кроме того, драйвер последовательного порта должен быть включен в состояние Y.

Далее нам понадобятся отладочные символы и исходные коды ядра, которые находятся в пакетах -debuginfo и -debugsource. Скорее всего, архитектуры удаленной и локальной системы не будут совпадать, так как особенно часто ядро Linux не работает на архитектуре armv7l, поэтому просто распакуем данные следующим образом:
> rpm2cpio kernel-default-base-debuginfo-4.2.rc4-1.1.gaf243bc.armv7hl.rpm | cpio -id
> rpm2cpio kernel-default-debuginfo-4.2.rc4-1.1.gaf243bc.armv7hl.rpm | cpio -id
> rpm2cpio kernel-default-debugsource-4.2.rc4-1.1.gaf243bc.armv7hl.rpm | cpio -id
В текущей директории будет создана поддиректория /usr содержащая отладочные символы и исходные коды в стандартной иерархии. Кроме того, нам понадобятся сами бинарные файлы ядра:
> rpm2cpio kernel-default-base-4.2.rc4-1.1.gaf243bc.armv7hl.rpm | cpio -id
> rpm2cpio kernel-default-4.2.rc4-1.1.gaf243bc.armv7hl.rpm | cpio -id

Далее, следует подключить последовательный порт, и открыть удаленную консоль следующим, например, образом:
> screen /dev/ttyUSB0 115200
и начать загрузку целевого устройства. Для активации механизма kgdb потребуется добавить параметры командной строки ядра в загрузчике:
U-Boot# setenv append "kgdboc=ttyO0,115200 kgdbwait"
U-Boot# boot

Если все пойдет правильно, то загрузка ядра остановится после примерно следующих строк:
[    3.753423] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 154, base_baud = 3000000) is a OMAP UART0
[    4.497783] console [ttyO0] enabled
[    4.502387] STMicroelectronics ASC driver initialized
[    4.507960] KGDB: Registered I/O driver kgdboc
[    4.512673] KGDB: Waiting for connection from remote gdb...

Entering kdb (current=0xdb0b3480, pid 1) on processor 0 due to Keyboard Entry
[0]kdb> 
kdb ождает ввода команд, среди прочего доступна команда help, выводящая список базовых команд. На этом консоль можно закрыть: Ctrl-A :quit и открыть отладчик gdb.

Для начала установим пути к отладочным символам и исходным кодам и загрузим объектный файл ядра целевой системы (внимание, сначала этот файл нужно будет распаковать командой gz).
(gdb) set debug-file-directory /tmp/dbg/usr/lib/debug
(gdb) directory /tmp/dbg/usr/src/debug/kernel-default-4.2.rc4/linux-4.2-rc4/linux-obj
(gdb) file /tmp/dbg/boot/vmlinux-4.2.0-rc4-1.gaf243bc-default
Reading symbols from /tmp/dbg/boot/vmlinux-4.2.0-rc4-1.gaf243bc-default...Reading symbols from /tmp/dbg/usr/lib/debug/boot/vmlinux-4.2.0-rc4-1.gaf243bc-default.debug...done.
done.
После этого нужно подключиться к целевой системе:
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0xc031dc08 in arch_kgdb_breakpoint () at ../arch/arm/include/asm/outercache.h:142

Далее можно использовать отладчик как обычно. Через команду monitor доступны все команды из консоли kdb, среди них есть достаточно полезные, например dmesg или lsmod:
(gdb) monitor lsmod
Module                  Size  modstruct     Used by
musb_am335x             1431  0xbf000278    1  (Loading) 0xbf000000 [ ]
Обратите внимание, что команда lsmod любезно нам показывает адрес 0xbf000000, куда в памяти загружен модуль musb_am335x. Этот адрес нужен чтобы отлаживать код из модуля:
(gdb) add-symbol-file /tmp/dbg/lib/modules/4.2.0-rc4-1.gaf243bc-default/kernel/drivers/usb/musb/musb_am335x.ko 0xbf000000

Устойчивые имена сетевых интерфейсов

Разработчики systemd продолжают вести нас в светлое будущее. В udev уже давно реализован механизм Predictable Network Interface Names, который представляет из себя кусочек кода на C, заполняющий переменные ID_NET_NAME_* исходя из свойств расположения физического сетевого устройства.

Считается, что подобный подход дает больше информации, чем прибитие гвоздями имен интерфейсов eth? к MAC-адресам в 70-persistent-net.rules. Однако, не обходится без недостатков. Например, при запуске системы под гипервизором VMWare ESXi, единственный сетевой интерфейс у меня называется eno16777728. Устройства, определяемые в DTB для одноплатных компьютеров на базе ARM, не поддерживаются схемой именования и имеют обычные имена eth?. А при подключении USB устройств, типа мобильных телефонов или модемов, схема именования генерирует скорее неустойчивые имена, потому-что в имя входит расположение устройства на шине USB, которое изменится при следующем подключении, таким образом придется настраивать интерфейс заново, потому-что предыдущие сохраненные настройки будут относиться к интерфейсу с другим именем.

К счастью, udev заполняет переменную ID_NET_NAME_MAC, представляющую имя интерфейса, основанное исключительно на его MAC-адресе. По-умолчанию, эта переменная не используется, но можно поменять стандартное поведение для USB-устройств. Один способ - через настройку udev, второй - используя systemd.link, файл, используемый systemd, для конфигурации сетевых интерфейсов.

Создадим файл /etc/systemd/network/90-usb.link следуя инструкции:
[Match]
Path=*-usb-*
[Link]
NamePolicy=mac
Юнит-файл состоит из двух секций: [Match] для описания устройств к которым он относится и [Link] для описания того, что с ними делать. В примере выше мы просим systemd использовать политику именования основанную на MAC-адресах для всех устройств подключенных через USB. После выполнения systemctl daemon-reload можно подключить устройство и увидеть его интерфейс с именем enx112233445566. Достаточно длинное, но уникальное (в известных пределах) и не изменится при следующем подключении устройства.

Кроме изменения имени через systemd.link можно настроить WOL, MTU, ограничить скорость на интерфейсе, назначить устройству другой MAC-адрес.

Изменение размера раздела

Имеется диск с тремя разделами sda1 (/boot), sda2 (swap), sda3 (/). Необходимо увеличить размер раздела /boot за счет swap.

Сначала отмонтируем все разделы и проверим файловую систему.
# swapoff  /dev/sda2 
# umount /dev/sda1 
# e2fsck /dev/sda1 
e2fsck 1.42.6 (21-Sep-2012)
/dev/sda1: clean, 49/14056 files, 47157/56196 blocks

Используем parted для того, чтобы сначала уменьшить и передвинуть второй раздел, а затем расширить первый на освободившееся место. Так как второй раздел - swap, то его мы просто передвинем, не заботясь о содержимом. Иначе говоря, сначала мы совсем сломаем, а потом заново её разметим.

# parted /dev/sda
GNU Parted 2.4
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s                                                           
(parted) print                                                            
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 120103200s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End         Size        Type     File system     Flags
 1      63s       112454s     112392s     primary  ext2            boot, type=83
 2      112455s   1686824s    1574370s    primary  linux-swap(v1)  type=82
 3      1686825s  120101939s  118415115s  primary  reiserfs        type=83

Для изменения раздела используется команда resize номер_раздела начало конец

(parted) resize 2 224973 1686824
WARNING: you are attempting to use parted to operate on (resize) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
(parted) print
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 120103200s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End         Size        Type     File system     Flags
 1      63s       112454s     112392s     primary  ext2            boot, type=83
 2      224973s   1686824s    1461852s    primary  linux-swap(v1)  type=82
 3      1686825s  120101939s  118415115s  primary  reiserfs        type=83

К сожалению в этот момент оно само подмонтировало всё назад, поэтому нужно снова отмонтировать первый раздел. Раздел swap в данный момент уже должен быть работоспособен, потому-что mkswap на нем выполнился сам автоматически. К сожалению, я не нашел способа отключить всю эту самодеятельность.

# umount /dev/sda1
# e2fsck -p /dev/sda1

Снова идем в parted:

# parted
GNU Parted 2.4
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s                                                           
(parted) print                                                            
Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 120103200s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End         Size        Type     File system     Flags
 1      63s       112454s     112392s     primary  ext2            boot, type=83
 2      224973s   1686824s    1461852s    primary  linux-swap(v1)  type=82
 3      1686825s  120101939s  118415115s  primary  reiserfs        type=83

(parted) resize 1 63 224972
WARNING: you are attempting to use parted to operate on (resize) a file system.
parted's file system manipulation code is not as robust as what you'll find in
dedicated, file-system-specific packages like e2fsprogs.  We recommend
you use parted only to manipulate partition tables, whenever possible.
Support for performing most operations on most types of file systems
will be removed in an upcoming release.
(parted) quit                                                             
Warning: You should reinstall your boot loader before rebooting.  Read section 4 of the Parted User documentation for more
information.
Information: You may need to update /etc/fstab.   

Готово, parted не только изменил размер раздела, но еще и молча расширил для нас файловую систему, а теперь предупреждает о необходимости обновить загрузчик.