BIND9 позволяет вам связывать динамически загружаемые модули зоны (DLZ) во время выполнения с помощью драйвера dlopen
. Модульный тест для этой функциональности проходит для моей среды, но когда я пытаюсь запустить его named
со связанным скомпилированным файлом общего объекта, я получаю эту ошибку:
dlz_dlopen failed to open library '/usr/lib/dlz_example.so' - /usr/lib/dlz_example.so: failed to map segment from shared object
Я уже открыл тикет в BIND9 GitLabздесь, который включает в себя подробную информацию о моей конкретной проблеме.
В целом, мне интересно, есть ли у людей понимание распространенных проблем при попытке загрузки общих объектов или опыт использования модулей DLZ. Я подозреваю, что я чего-то не понимаю в том, как они работают, и есть какая-то глупая неправильная конфигурация, которая вызывает проблему. Конечно, советы по отладке также приветствуются.
Страница базы знаний ISC «Использование DLZ в BIND»:https://kb.isc.org/docs/aa-00995
решение1
Итак, вы используете Debian или Ubuntu, которые по умолчанию включают AppArmor и ограничивают, named
из каких мест демон может читать, писать, или mmap, или выполнять. Любые попытки загрузить модули из "неправильных" мест будут отклонены ядром и зарегистрированы dmesg
.
Политика по умолчанию допускает /etc/apparmor.d/usr.sbin.named
только два местоположения:
/usr/lib/bind/*.so rm
– для большинства упакованных модулей/{usr/,}lib/@{multiarch}/samba/bind9/*.so rm
– для зон Samba AD DC
Пользовательские дополнения могут быть сделаны /etc/apparmor.d/local/usr.sbin.named
(как показывает оператор #include в конце файла). Этот файл не имеет никаких начальных/конечных разделителей, только сами дополнительные правила, такие как:
/usr/local/lib/*.so rm,
Чтобы перезагрузить профиль после редактирования, используйте:
apparmor_parser --replace /etc/apparmor.d/usr.sbin.named