Виктор Судаков

Можно ли вообще сравнивать docker и jails? Обсуждение

there's a conceit in the FreeBSD community that there's an element of "we had Docker containers years ago but we call them jails." I don't think the comparison is 100% accurate. I like jails, but I believe the tooling and ecosystem around them falls short of that around Docker

И о перспективах

They're not quite the same as Docker images, but the iocage jail manager supports "plugins", https://iocage.readthedocs.io/en/latest/plugins.html. They're canned instructions for building an image for a particular application, not ready-made images, but they work similarly.

FreeNAS/ixSystem supports a set of about 30 and there's a repository for community plugins: https://github.com/ix-plugin-hub/iocage-plugin-index

There's a nice, recent tutorial that covers creating plugins over on the FreeNAS blog site: https://www.ixsystems.com/blog/plugins-development/

Источник: https://lists.freebsd.org/pipermail/freebsd-questions/2020-February/287879.html

Может пригодиться, например, для тестирования графических desktop environments. В качестве оболочки к bhyve использован sysutils/vm-bhyve, в качестве VNC клиента - net/tightvnc.

Поскольку framebuffer console доступна только при загрузке гостевой ОС в режиме UEFI (а в режиме bhyveload недоступна), то нужно установить гостевую FreeBSD в режиме UEFI.

I. В конфиге новой VM должны присутствовать параметры

loader="uefi"
graphics="yes"
graphics_wait="auto"
graphics_res="1280x720"
xhci_mouse="no"

II. Запускаем установку как обычно для UEFI гостей:

vm install test1 FreeBSD-12.1-RELEASE-amd64-disc1.iso
vncviewer 192.168.1.1:5900

В EFI консоли дожидаемся FreeBSD boot menu, нажимаем 3 (Escape to loader prompt). В консоли лоадера

set boot_serial=NO
boot

При установке Auto (ZFS) нужно выбрать "Partition Scheme GPT(UEFI)", bsdinstall создаст EFI раздел и положит туда загрузчик. При установке на UFS придется вручную создать EFI раздел и наполнить его содержимым из /boot/boot1.efifat.

III. На последнем шаге установки (Manual Configuration):

echo 'boot_serial="NO"' >> /boot/loader.conf

IV. Устанавливаем иксы и нужный desktop environment:

pkg install xorg gnome3

V. В /usr/local/etc/X11/xorg.conf.d/driver-scfb.conf добавляем секцию:

Section "Device"
        Identifier    "Card0"
        Driver        "scfb"
EndSection

Это важно! Если не добавить, X-server не найдет framebuffer-ную консоль.

VI. Запускаем нужную графическую среду

sysrc dbus_enable=YES
sysrc hald_enable=YES
sysrc gdm_enable=YES
apply "service %1 start" dbus hald gdm

Источники:
https://wiki.freebsd.org/bhyve/UEFI
Тред в https://lists.freebsd.org/pipermail/freebsd-virtualization/2019-December/007944.html

Алгоритм взаимодействия apcupsd с системой при её выключении не менялся уже 17 лет. По умолчанию apcupsd запускается с ключом --kill-on-powerfail, что означает: при исчерпании заряда аккумулятора в ИБП, послать ИБП команду "уснуть" и одновременно запустить процедуру doshutdown из /usr/local/etc/apcupsd/apccontrol. В ИБП обычно предусмотрена задержка (так называемый grace delay) 10-40 секунд исполнения команд "выключиться" и "уснуть". В этом месте начинается race: что случится раньше, shutdown успеет корректно завершиться или ИБП выключится?

В прежние времена, наверное, это всех устраивало, потому что выключение системы проходило быстро и shutdown успевал всё завершить до выключения питания. Хотя напомню, что значение по умолчанию rcshutdown_timeout="90" заведомо больше grace delay любого ИБП. Так что race condition никуда не девался на самом деле.

В нынешнее время с распространением виртуальных машин во время выключения хоста включено время выключения виртуалок, которое может быть весьма значительным. Я например устаналиваю rcshutdown_timeout="240" и kern.init_shutdown_timeout="300" и то виндовые VM выключиться не успевают. Понятно, что в UPS grace delay не укладываемся точно.

Поэтому предлагаю новый алгоритм выключения системы посредством apcupsd, и открыл на эту тему ПР https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237600 Суть нового (не очень нового, на самом деле, в Linux используется подобный) алгоритма:

Запускаем apcupsd с ключом --term-on-powerfail

apcupsd_enable="YES"
apcupsd_flags="--term-on-powerfail"

это значит после запуска процедуры shutdown и создания флага /var/run/powerfail apcupsd должен выйти и не путаться пока под ногами.

А в конце /etc/rc.shutdown вписываем строчку

test -f /var/run/powerfail && /usr/local/sbin/apcupsd --hibernate

или

test -f /var/run/powerfail && /usr/local/sbin/apcupsd --power-off

(кому как удобнее, в зависимости от требуемого поведения ИБП после восстановления питания).

Это означает, что только после отработки всех rc.d скриптов с параметром stop в ИБП будет послана команда "уснуть" или "выключиться" соответственно.

UPD A brief summary in English.

My final conclusion. The default way apcupsd is started by the port (with --kill-on-powerfail) is wrong. You cannot rely on the UPS grace shutdown delay even with the default setting of rcshutdown_timeout="90", while using virtual machines necessitates making rcshutdown_timeout even longer. A race between the UPS grace delay and the FreeBSD shutdown procedure must be eradicated.

The only feasible way of doing it is:

1. Starting apcupsd with apcupsd_flags="--term-on-powerfail" so that the daemon exits once it has started the doshutdown procedure and does not send any commands to the UPS at this stage.

2. Putting the line

"test -f /var/run/powerfail && /usr/local/sbin/apcupsd --hibernate"

or

"test -f /var/run/powerfail && /usr/local/sbin/apcupsd --power-off"

(depending on the desired behaviour of the UPS after the mains is restored) at the very end of the /etc/rc.shutdown script, after the "Insert other shutdown procedures here" line.

Thus the shutdown procedure started by "apcupsd --term-on-powerfail" can proceed at its own tempo, with "apcupsd --hibernate" being called when all the daemons and VMs have been safely shut down.

UPD 2. Ещё предлагают такой способ: http://www.wfido.ru/m/RU.UNIX.BSD/grosbein.net+c3b53b4f который призван исключить достаточно маловероятную, но неприятную ситуацию, если питание успело восстановиться после завершения apcupsd, но до killpower.

bhyve и некоторые другие гипервизоры (похоже что VirtualBox тоже) в режиме EFI не поддерживают эмуляцию NVRAM для сохранения efi variables между перезагрузками. Это может привести к проблеме: гостевая ОС установится штатно, а после перезагрузки получаем сообщение от EFI наподобие

Boot Failed. EFI DVD/CDROM
Failed to set MokListRT: Invalid Parameter
Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found
Boot Failed. EFI Misc Device
.

Это происходит оттого, что инсталлятор при установке ОС сохранил в efi variables путь к загрузчику (например "\EFI\centos\grubx64.efi"), а после перезагрузки гостевой системы настройка забылась и гипервизор начинает пытаться грузить нечто другое, что заложено в него по умолчанию или по эвристике.

Решений может быть несколько.

Первое тупое. Подмонтировать как-нибудь efi-раздел установленной гостевой ОС (например из другой виртуалки, или из LiveCD в той же виртуалке) и положить нужный загрузчик в то место, где его ищет и не может найти гипервизор: например подложить его в качестве "\EFI\BOOT\BOOTX64.EFI", или как в примере выше, скопировать из \EFI\centos\grubx64.efi в \EFI\BOOT\grubx64.efi.

Второе более интересное. После неудачной загрузки дождаться EFI interactive shell и создать файл startup.nsh, это типа такой autoexec.bat:

fs0:
edit startup.nsh

А в нем уже прописать тот загрузчик, который нужен гостевой ОС, например строчку "\EFI\centos\grubx64.efi".

Третье фантастическое. Запинать авторов UEFI-EDK2 firmware реализовать поддержку сохранения efi variables между перезагрузками.

UPDATE. Вот на ту же тему https://www.centos.org/forums/viewtopic.php?p=278745#p278745

UPDATE 2. А инсталлятор FreeBSD уже сразу создает в EFI-разделе startup.nsh c нужным загрузчиком. Молодцы!

Где взять и как собрать http://justinholcomb.me/blog/2016/05/28/bhyve-uefi-gop-support.html

svn co svn://svn.freebsd.org/base/projects/bhyve_graphics
cd bhyve_graphics
make BHYVE_SYSDIR=/usr/src -m /usr/src/share/mk
make BHYVE_SYSDIR=/usr/src -m /usr/src/share/mk install
pkg install uefi-edk2-bhyve-20160704_1
ln -s /usr/local/share/uefi-firmware/BHYVE_UEFI.fd $vm_dir/.config/

Чтобы права на создаваемые и удаляемые "на лету" устройства были такие как надо:

В /etc/rc.conf.local
devfs_system_ruleset="localrules"

В /etc/devfs.rules
[localrules=10]
add path 'nmdm*' mode 0660 group dialer

/etc/rc.d/devfs restart

/dev/nmdmN[AB] удобно использовать для доступа к консолям виртуальных машин в bhyve.

Документация на syslinux-6.01 предлагает такой пример для выбора WDS из PXE меню:

label WDS
 menu LABEL Windows Deployment Service
 com32 pxechn.c32
 append 10.1.1.4::boot\x86\wdsnbp.com -W

Так вот такой способ не работает из-за баги в pxelinux, в результате которой pxechn.c32 не понимает, что 10.1.1.4 является IP адресом, пытается его резолвить как имя в DNS, потом искать локальный файл с именем "10.1.1.4::boot\x86\wdsnbp.com", а потом возвращает ошибку "pxechn.c32: Attempting to load '10.1.1.4::boot\x86\wdsnbp.com': 2:No such file or directory"

Workaround. Если указать не адрес, а DNS имя WDS сервера, то всё работает:

label WDS
 menu LABEL Windows Deployment Service
 com32 pxechn.c32
 append wds01.your.domain.ru::boot\x86\wdsnbp.com  -W

UPD а если PXE клиент в DHCP запросе не запрашивает option 6 (например так делает реализация PXE в Oracle VirtualBox), то он ее и не получит в DHCP ACK, поэтому информация о DNS серверах не будет доступна pxelinux-у, и всё вышеописанное работать не будет.

Вторая часть: http://nuclight.livejournal.com/128712.html

Тут же помещаю свой комментарий для памяти, вдруг не пройдет модерацию у nuclight 

IMHO вся проблема с монолитной базовой системой надумана. Мне не мешают ни sendmail, ни bind в базовой системе, при нынешних-то объёмах дисков. Поэтому я изложу те проблемы, которые на мой взгляд более серьёзны.

1. Обновление на следующий релиз.

В пределах одного major release утилиты freebsd-update, portsnap и portmaster обеспечивают беспроблемное, технологичное поддержание системы и софта в актуальном состоянии (в том числе и jail нормально бинарно обновляются снаружи через "freebsd-update -b"). Но поддержка security ветки имеет неприятное свойство кончаться, и вот тут начинается кошмар. "freebsd-update upgrade" разве уже пригоден к применению? Единственный рабочий способ обновления - через make world. После чего применимость freebsd-update к получившейся системе уже под вопросом, а "freebsd-update IDS" ломается полностью. Отдельный вопрос - mergemaster, IMHO он слишком сложен, скажем я не представляю, как по нему тех. карту расписать. Но это всё цветочки. Самое страшное - это то, что обновление мира влечёт пересборку всех портов и никаких гарантий, что после пересборки всё будет работать как работало. У меня на домашней системе был случай, когда после работы portmaster появились дубликаты в /var/db/pkg, пришлось сносить весь /usr/local и строить заново по заранее сохраненному `portmaster --list-origins`.

Можно конечно не делать "make delete-old" после пересборки мира, но тогда не стоило и систему обновлять вообще.

2. Виртуализация

Не хватает развитых средств виртуализации. В jail нет лимитов на CPU, память и прочее, нет и нормальной инфраструктуры создания/удаления джейлов (в качестве примера хорошей инфраструктуры см. Solaris zones)

Меня также напрягает, что из VMWare ESX нельзя послать на FreeBSD guest сигнал выключиться. Не знаю почему, и можем ли мы что-то с этим сделать.

3. cvsup поломали

Наверное в связи с переходом на SVN теперь все исходники cvsup-ятся только целиком, в результате вывод "csup -L0" оказался замусорен.

src/etc/Makefile,v: Checksum mismatch -- will transfer entire file
src/sys/kern/vfs_mount.c,v: Checksum mismatch -- will transfer entire file
src/usr.bin/catman/catman.c,v: Checksum mismatch -- will transfer entire file