когда я пытаюсь запустить bind9; просто потерпеть неудачу из-за chroot & amp; openssl
/etc/init.d/bind9 start
протоколировать сообщения;
Feb 17 08:26:27 ISTVS2024 named[2440]: initializing DST: openssl failure
Feb 17 08:26:27 ISTVS2024 named[2440]: exiting (due to fatal error)
Feb 17 08:26:27 ISTVS2024 kernel: [ 92.091098] type=1400 audit(1361082387.173:14): apparmor="DENIED" operation="file_mmap" parent=2439 profile="/usr/sbin/named" name="/var/named/run-root/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so" pid=2440 comm="named" requested_mask="m" denied_mask="m" fsuid=108 ouid=0
Если я не пропустил точку, Apparmor это отрицает;
мой файл usr.sbin.named уже содержит следующие строки:
/var/named/run-root/** rw,
/var/named/run-root/usr/** rw,
также я могу подтвердить, что этот файл;
/var/named/run-root/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so
существует в файловой системе.
Буквально, я застрял, какие у меня есть другие варианты, чтобы решить эту проблему?
Может быть, полное удаление apparmor - это решение, но я не хотел этого делать
У меня была та же проблема этим утром.
Этот ответ ребята исправил это для меня.
http://www.failover.co/blog/plesk-11-bind9-and-ubuntu-12-04-apparmor-problems
Это первый удар по «инициализации DST: сбой openssl», который был ошибкой, которую я получил, когда мой DNS сломался в результате обновления ubuntu с lucid до точного, поэтому я хотел бы упомянуть решение здесь. [ 112]
В моем случае это было связано с привязкой в зависимости от библиотеки ssl, которая не была в его chroot-тюрьме. Решение было следующим:
mkdir -p /usr/lib/i386-linux-gnu/openssl-1.0.0/engines
cp -a /usr/lib/i386-linux-gnu/openssl-1.0.0/engines /var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/
Конечно, теперь мне нужно постоянно обновлять эти файлы, и я не знаю, есть ли лучшее решение.
Подробнее о том, как я это выяснил, можно узнать здесь: https://darxus.livejournal.com/329621.html
.