Eu tive o mesmo problema esta manhã.
Essa resposta pessoal consertou isso para mim.
link
quando tento iniciar o bind9; simplesmente falhar por causa do chroot & amp; openssl
/etc/init.d/bind9 start
mensagens de log;
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
Se eu não perdi um ponto, Apparmor nega isso;
meu arquivo usr.sbin.named já contém estas linhas:
/var/named/run-root/** rw,
/var/named/run-root/usr/** rw,
também posso confirmar que este arquivo;
/var/named/run-root/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so
existe no sistema de arquivos.
Literalmente, estou preso, que outras opções eu tenho, para corrigir esse problema?
Talvez, remover o apparmor completamente seja uma solução, mas eu não queria fazer isso
Eu tive o mesmo problema esta manhã.
Essa resposta pessoal consertou isso para mim.
link
Este é o primeiro hit em "initializing DST: openssl failure", que foi o erro que tive quando meu DNS quebrou como resultado da atualização do ubuntu de lúcido para preciso, então gostaria de mencionar a solução aqui. / p>
No meu caso, foi devido a vincular dependendo de uma biblioteca ssl que não estava em sua cadeia chroot. A solução foi:
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/
Claro, agora preciso manter esses arquivos atualizados e não sei se há uma solução melhor.
Mais informações sobre como eu percebi isso aqui: link