![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
stunnel, chroot, FreeBSD и SIGHUP
Не все знают, что при переходе из single user mode в multiuser mode ядро FreeBSD посылает всем процессам сигнал HUP (номер 1). Дефлотный обработчик этого сигнала завершает выполнение процесса - таким образом, при переходе в multiuser умирают все фоновые процессы, за исключением запущенных процедурой начальной загрузки сервисов, корректно отвязавшихся от управляющего терминала и/или обрабатывающих сигнал самостоятельно.
С разработанным под Linux софтом, где такого нет, из-за этого иногда возникают проблемы. Ещё под FreeBSD 4.11 в своё время разворачивал линуксовую версию IPSoft Billing, имевшую в своём составе СУБД SyBase Anywhere, которая успешно стартовала, но в момент перехода в multiuser, получив SIGHUP, корректно завершалась. Тогда мне помогла утилита daemon(8), вставленная в стартовый скрипт, которая запускала СУБД, предварительно демонизировавшись и включив игнорирование SIGHUP. После чего та система проработала долго и счастливо много лет.
Но это всё присказка была.
Несколько версий назад stunnel научился перечитывать файл конфигурации по сигналу HUP, до этого перечитывать конфигурацию он не умел и после изменения его приходилось рестартовать. Что происходит с stunnel, если в его конфигурации одновременно включены chroot и использование клиентских сертификатов?
Во время первоначального запуска stunnel демонизируется, читает конфигурационный файл, [s]pwd.db для трансляции имени stunnel в uid, читает сертификаты с ключами, открывает прослушивание указанных портов, открывает нужные ему файлы в /dev, подключается к syslog, если сказано, устанавливает обработчики сигналов - в общем, выполняет множество действий. Потом делает chroot и ждет подключений. Во время загрузки FreeBSD всё это происходит в single user mode. В момент окончания загрузки системы stunnel получает SIGHUP от ядра и пытается заново прочитать конфигурацию, сертификаты, [s]pwd.db и прочее. В конфигурации по умолчанию ничего этого изнутри chroot ему сделать уже нельзя и в итоге он перестаёт слушать порты и обслуживать пользователей, так и не начав. Так простое обновление старой версии порта может дать изумительный эффект (ещё один пример этой же проблемы).
Если конфигурацию и сертификаты путем тщательной обработки системы напильником ему можно предоставить в chroot (создав структуры в /var/stunnel и симлинки туда по образу и подобию /var/named), то генерировать там полное системное окружение, включая актуальные [s]pwd.db я посчитал излишним. Вместо этого запатчил stunnel, вернув игнорирование SIGHUP, если в конфигурации включено использование chroot (файл по ссылке положить в /usr/ports/security/stunnel/files/ и пересобрать порт).
no subject
no subject
no subject
no subject
no subject
no subject
дуракаумника, умеющего killall -1 stunnel.no subject
no subject
no subject
no subject
no subject