четверг, 19 сентября 2019 г.

Как в конфиге dhcpd вывести значение переменной в лог

Экспериментировал с ISC DHCP. Хотел сделать конфиг для PXE чтобы могли грузиться как машины с BIOS, так и UEFI. Итак, редактируем /etc/dhcpd.conf
Никак не мог понять почему не срабатывает конструкция
; This one line must be outside any bracketed scope
option architecture-type code 93 = unsigned integer 16;

     if option architecture-type = 0 {
         filename "path/to/BIOS/pxelinux.0";
     } elsif option architecture-type = 9 {
         filename "path/to/EFIx64/syslinux.efi";
     } elsif option architecture-type = 7 {
         filename "path/to/EFIx64/syslinux.efi";
     } elsif option architecture-type = 6 {
         filename "path/to/EFIia32/syslinux.efi";
     }

Нашёл её здесь: https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#UEFI

Оказалось, что проблема в том, что надо указывать не option architecture-type = 0, а option architecture-type = 00:00

Перед тем как это понять, мне пришлось узнать как вообще можно вываести значение переменной (или опции) в лог dhcpd.

Например, так:
set test_var = ff:00;

log (error,
  concat ("--->",
    binary-to-ascii(16,16,".",test_var)
  )
);

Потом используя для мониторинга происходящего команду
journalctl -u dhcpd4.service -f
Мы можем увидеть там нашу строку: "--->ff0"

вторник, 10 сентября 2019 г.

Как выставлять hostname на основе mac адреса при загрузке Linux по PXE

У меня есть pxe сервер, который раздаёт Arch Linux по сети. Я его гружу на разных машинах и дальше захожу в них по ssh. Чтобы проще было различать хосты, мне захотелось, чтобы их хостнеймы задавались автоматически из их mac адреса.
Для этого я пересобрал archiso (инструкция), добавив следующие изменения:

Создаём файл archlive/airootfs/etc/systemd/scripts/bootif-hostname:
#!/bin/bash
# example of kernel parameter: BOOTIF=00-01-02-03-04-05-06
eval $(cat /proc/cmdline | grep -o '\bBOOTIF=[^ ]*')
new_hostname="arch-`echo "${BOOTIF: -8}" | tr -d '-'`"
hostnamectl set-hostname "$new_hostname"
и делаем его исполняемым: chmod +x archlive/airootfs/etc/systemd/scripts/bootif-hostname
Создаём файл archlive/airootfs/etc/systemd/system/bootif-hostname.service:
[Unit]
Description=Start with a hostname based on last three octets of mac address of nic, which was used for pxe booting
Wants=network-pre.target
Before=network-pre.target

[Service]
ExecStart=/etc/systemd/scripts/bootif-hostname
Type=oneshot

[Install]
WantedBy=multi-user.target

В archlive/airootfs/root/customize_airootfs.sh вносим:
...
systemctl enable ... sshd.service bootif-hostname.service

На pxe сервере используется pxelinux. Он автоматически добавляет параметрам ядра BOOTIF=00-01-02-03-04-05-06. Я правда не пойму, откуда берётся самый первый октет.

P.S. чтобы зайти на хосты по ssh, надо либо создать пароль для рута и разрешить руту логиниться по ssh, либо создать отдельного пользователя. Я не стал загромождать статью этими изменениями.

Вот и всё. Теперь, когда мы загружаем ArchLinux по сети, в качестве имени хоста мы видим вот такую строку: arch-040506, которая формируется из трёх последних октетов mac адреса сетевой карты, которая была использована при загрузке машины.

суббота, 7 сентября 2019 г.

sendEmail - отправка копии письма нескольким адресатам - workaround

Расскажу о небольшой проблеме при использовании sendemail (в Arch Linux - sendEmail).
Мне нужно было отправить письмо, кроме основного, ещё и нескольким другим адресатам. Для этого я использовал опцию -cc.
Почему-то man страницы sendemail в системе нет. Но зато есть обычный help. Он показывается если вызвать sendEmail без параметров. Так вот, там есть такое описание:
    -cc ADDRESS [ADDR ...]
Т.е. вроде бы как можно указывать адресатов через пробел. Но у меня так не получилось. Письмо уходило только первому из перечисленных адресов.
Я пробовал и заключать адреса в треугольные скобки, и прописывать их через запятую, и в кавычках - никак не работало: программа жаловалась что адреса некорректные.

В конце концов нашёл рабочее решение - можно использовать опцию -cc несколько раз. То есть например так:

$ sendEmail \
    -f "$NAME_SURNAME <username@domain.com>" \
    -u "$SUBJECT" \
    -t "$MAIN_RECIEVERS" -cc "$CC_RECIEVER1" -cc "$CC_RECIEVER2" \
    -s "$SERVER_AND_PORT" \
    -o tls=yes \
    -o message-charset=utf-8 \
    -xu "username@domain.com" \
    -xp "******" \
    -o message-content-type=html \

    -m "$MAILBODY"

Я нигде не нашёл инструкции что так можно делать. Просто случайно добился рабочего результата. Поэтому решил зафиксировать это в данной заметке - вдруг кому-то ещё пригодится.
Версия sendEmail - sendEmail-1.56 (тоже со страницы help).

среда, 13 февраля 2019 г.

Особенности установки Ubuntu 18.04.1 server



Canonical предоставляет несколько вариантов iso образов LTS дистрибутивов для x86_64 (на февраль 2019):
ubuntu-18.04.1-live-server-amd64.iso - с новым установщиком (Subiquity)
ubuntu-18.04.1-server-amd64.iso - с альтернативным установщиком (Ubiquity)

Новый установщик имеет шероховатости, есть отрепорченные баги, ждём фиксов. Создатели дистрибутива говорят: "If you require advanced networking and storage features such as; LVM, RAID, multipath, vlans, bonds, or re-using existing partitions, you will want to continue to use the alternate installer."

Новый установщик

Если используем Subiquity, то имеем в виду (опять же, на февраль 2019):
стиль разметки будет всегда gpt, вне зависимости от режима загрузки
нужно будет создать раздел на накопителе для /boot. Это должен быть именно раздел на накопителе, sw raid пока не поддерживается. Наблюдаем здесь: https://bugs.launchpad.net/subiquity/+bug/1785332
установщик умеет работать в обоих режимах загрузки.
в режиме bios будет автоматом создан bios_grub
в режиме uefi будет автоматом создан esp

Чтобы загрузиться в режиме uefi на платформах supermicro, жмём F11 при старте платформы, выбираем наш загрузочный носитель, перед которым есть надпись "UEFI:". Лучшего решения пока нет.

Старый установщик

Если используем Ubiquity: этот установщик при партиционировании будет использовать gpt только на накопителях емкостью более 2tb. Как его заставить использовать gpt при напопителях меньшего размера не разбирался, может есть какой-то параметр. Если кто-то знает, подскажите.

В VirtualBox cоздать из gui такие накопители невозможно. Для создания используем команду:
vboxmanage createhd --filename 3TB_storage.vdi --size 3000000 --format VDI --variant Standard
Ubiquity автоматом bios_grub раздел не создаёт (в отличие от sibuiquity), поэтому нужно создать его вручную (выставляем Use as как Reserved BIOS boot area). Если этого не сделать, то получим ошибку на этапе установки загрузчика (Unable to install grub).

Раздел этот должен быть в пределах первых двух терабайт. (Это по логике. Я вот в virtualbox сделал его дальше 2.7Тб, и система грузилась нормально. Это очень странно, надо дальнейшие эксперименты провести и выяснить почему так. На реальном железе не проверял).

bios_grub разделы нужно сделать на всех накопителях, потому что так хочет инсталлер. Иначе он вывалится с критической ошибкой при попытке установить grub на раздел без bios_boot. Размер этого раздела делать более 1Mb не следует, т.к. ёмкость более 1MB всё равно не будет использоваться (туда пишется grub stage 1.5).

За логами можно смотреть на tty4, сам установщик работает на tty1.