dadv (dadv) wrote,
dadv
dadv

Category:

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/ и пересобрать порт).

Tags: freebsd, networking, stunnel
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 9 comments