Проблема с BIND + DLZ-LDAP [REOPEN]
Примерно пару дней назад с какого-то перепуга перестал работать bind с dlz с ldap
Двое суток копал, так и не нашел в чем причина. Симптомы следующие.
В named.conf указана конфигурация для работы с ldap:
dlz "zone" {
database "ldap 2 v3 simple
{cn=dns,ou=access,dc=host}
{secret}
{127.0.0.1}
ldap:///dlzZoneName=%zone%,ou=dns,dc=host???objectclass=dlzZone
ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,dc=host?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?objectclass=dlzAbstractRecord
{}
ldap:///dlzZoneName=%zone%,ou=dns,dc=host?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?objectclass=dlzAbstractRecord
ldap:///dlzZoneName=%zone%,ou=dns,dc=host??sub?(&(objectclass=dlzXFR)(dlzIPAddr=%client%))";
};
естественно все строки, начинающиеся с ldap:///... без переносов и пробелов.
Если закомментировать это, то бинд стартует без проблем.
Все прекрасно работало, конфигурация не менялась, бинд не обновлялся, лдап тоже, остальные сервисы с лдапом работают замечательно, а вот бинд в какой-то момент перестал запускаться со словами:
starting BIND 9.3.2 -u named -n 1 -t /srv/chroot/dns
found 1 CPU, using 1 worker thread
loading configuration from '/etc/bind/named.conf'
listening on IPv4 interface eth0, 172.16.0.1#53
listening on IPv4 interface eth1, 10.2.0.1#53
listening on IPv4 interface lo, 127.0.0.1#53
Loading 'zone' using driver ldap
parsing allow zone transfer query failed
SDLZ driver failed to load.
DLZ driver failed to load.
loading configuration: failure
exiting (due to fatal error)
Причем, в логах лдапа нет даже попытки к нему подконнектится со стороны бинда.
Пересобрал мир - не помогло. Система под ~x86
Сейчас стоит bind-9.3.2-r1 с USE="berkdb dlz ldap ssl threads -doc -idn -ipv6 -mysql -odbc -postgres"
Пробовал откатываться на bind-9.2.6-r1, не помогло, таже песня в логах.
Пробовал собирать бинд без ccache и confcache, тоже не помогло.
В общем потерял покой и сон, уже двое суток толком не спавши.
Вот вывод emerge --info
Gentoo Base System version 1.12.0_pre19
Portage 2.1_rc1-r4 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.4-r3, 2.6.16-gentoo-r8 i686)
=================================================================
System uname: 2.6.16-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
ccache version 2.4 [enabled]
dev-lang/python: 2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache: 2.4-r1
dev-util/confcache: 0.4.2-r1
sys-apps/sandbox: 1.2.18.1
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils: 2.16.1-r2
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer -fforce-addr"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg ccache confcache distlocks fixpackages metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://ftp.citkit.ru/pub/Linux/gentoo http://mirror.aiya.ru/pub/gentoo/ ftp://ftp.citkit.ru/pub/Linux/gentoo ftp://mirror.aiya.ru/pub/gentoo/"
LANG="ru_RU.UTF-8"
LC_ALL="ru_RU.UTF-8"
LDFLAGS="-Wl,-z,now"
LINGUAS="ru"
MAKEOPTS="-j2"
PKGDIR="/srv/raid/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 / 7zip acpi apache2 apm avi bash-completion berkdb bitmap-fonts bzip2 cgi checkpath chroot cli crypt cups dba dlz dri dvd dvdr dvdread eds emboss encode foomaticdb force-cgi-redirect fortran gd gif gstreamer gtk2 icq imap imlib isdnlog jabber kde ldap ldapsam libg++ libwww logrotate mad maildir matroska mmx mode-paranoid motif mp3 mpeg mpm-worker mppe-mppc ncurses nls no-suexec nptl nptlonly ogg pam pcre pdflib perl pppd python quotas radius readline reflection samba sdl session slang spl sse sse2 ssl threads truetype-fonts type1-fonts udev unicode userlocales utf8 vchroot vhosts vorbis xml xorg zlib elibc_glibc kernel_linux linguas_ru userland_GNU"
Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_RSYNC_EXTRA_OPTS
- Для комментирования войдите или зарегистрируйтесь
Может дело в LDAP?
Может дело в LDAP? Проверял ли ветку, в которой хранится зона? Посмотри на конфиг LDAP может он заменён.
Нет, дело не в
Нет, дело не в лдапе, это точно, потому что к лдапу даже не коннектится, а зоны там уже месяца 2 не менялись. Впрочем как и конфиг лдапа тоже. Сначала тоже думал что дело в лдапе, пересобрал базу, а не помогло, а потом смотрю, даже попыток подключиться к лдапу нету.
Меня вот эта строка в логах смущает:
parsing allow zone transfer query failed
А все таки дело было в лдапе
А все таки дело было в лдапе, стоял последний openldap-2.3.21-r1
Хоть с ним бинд и собирался, но вот работать с libldap этой версии не мог.
Помог откат на openldap-2.2.28-r4, пересборка зависимостей через revdep-rebuild и соответственно пересборка базы из последнего .ldiff
У меня была
У меня была аналогичная проблемма, поставил бинд последний + лдап последний и пытался их увязать, бился 2 дня пока не наткнулся на Ваш пост, большое Вам спасибо.
Уважаемые, что
Уважаемые, что же делать. Проблема так и не решается, нашлись серьезные дыры в ldap и bind, надо обновляться, а не могу, bind так до сих пор и не хочет работать с ldap-2.3.xx, симптомы те же, а последний bind-9.3.3 вообще в корку валится при обращении к ldap. Видимо придеться от бинда отказываться в пользу djbdns. А щастье было так близко...
Насколько я понял, за ~4 года
Насколько я понял, за ~4 года ничего не поменялось? Столкнулся с той же проблемой :-)
http://bugs.gentoo.org/show_bug.cgi?id=167056 - тут есть патч, 3-х летней давности...
Кто-нибудь решал эту проблему последнее время?