[RPZ] 9.9.3-rpz2+rl.150.20 fails to launch "due to assertion failure"

darx+dnsrpz at sent.com darx+dnsrpz at sent.com
Fri May 31 16:44:05 UTC 2013


I'm fairly sure I'd done all that cleaning, just hadn't regaled you with
the clean-up details, but for the sake of completeness, following
instructions:

> wget/fetch/curl/ftp/browser/whatever to fetch
>  ftp://ftp.isc.org/isc/bind9/9.9.3/bind-9.9.3.tar.gz and
>  http://ss.vix.su/~vjs/rpz2+rl-9.9.3.patch
> expand the 9.9.3 tarball, perhaps into /tmp/foo/bind-9.9.3
>  with `mkdir /tmp/foo; cd /tmp/foo; pax -rzf`
>  or `cd /tmp/foo; gzcat bind-9.9.3.tar.gz | tar -xf -`
> cd /tmp/foo/bind-9.9.3
> patch -si .../rpz2+rl-9.9.3.patch
> ./configure ...
> make
> mv /usr/local/sbin/named /usr/local/sbin/named.save
> cp /tmp/foo/bind-9.9.3/bin/named/named /usr/local/sbin

rpm -e `rpm -qa | grep -i bind-9`

rm -rf   /usr/local/src/BIND-TESTING
mkdir -p /usr/local/src/BIND-TESTING
cd       /usr/local/src/BIND-TESTING

wget ftp://ftp.isc.org/isc/bind9/9.9.3/bind-9.9.3.tar.gz
wget http://ss.vix.su/~vjs/rpz2+rl-9.9.3.patch

pax -rzf bind-9.9.3.tar.gz
cd bind-9.9.3

echo $LD_PRELOAD

echo $STD_CDEFINES

echo $CFLAGS
	-O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector
	-funwind-tables -fasynchronous-unwind-tables -march=atom
	-mtune=atom -fPIC -DPIC -D_GNU_SOURCE -fno-strict-aliasing -Wall
echo $CXXFLAGS
	-O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector
	-funwind-tables -fasynchronous-unwind-tables -march=atom
	-mtune=atom -fPIC -DPIC -D_GNU_SOURCE -fno-strict-aliasing -Wall
echo $CPPFLAGS
	-I/usr/local/include -I/usr/local/ssl/include -I/usr/include
echo $LDFLAGS
	-L/usr/local/ssl/lib64 -Wl,-rpath,/usr/local/ssl/lib64 -lssl
	-lcrypto

./configure \
--prefix=/usr/local \
 --bindir=/usr/local/bin \
 --sbindir=/usr/local/sbin \
 --sysconfdir=/usr/local/etc/named \
 --localstatedir=/var \
 --libdir=/usr/local/lib64 \
 --includedir=/usr/local/include/bind \
 --mandir=/usr/local/share/man \
 --infodir=/usr/local/share/info \
 --enable-shared --disable-static \
--enable-chroot \
--enable-ipv6 \
--with-libxml2=yes \
--with-libtool \
--with-gnu-ld \
--without-idn \
--enable-threads \
--enable-largefile \
--with-randomdev=/dev/urandom \
  --enable-openssl-version-check \
  --disable-openssl-hash \
  --with-openssl=/usr/local/ssl \
  --without-pkcs11 \
 --with-dlz-postgres=no \
 --with-dlz-mysql=no \
 --with-dlz-bdb=/usr/local/dlz-bdb \
 --with-dlz-filesystem=yes \
 --with-dlz-ldap=no \
 --with-dlz-odbc=no \
 --with-dlz-stub=yes \
 --with-dlopen=yes \
--enable-rpz-nsip \
--enable-rpz-nsdname \
--with-make-clean

make depend
make

mv /usr/local/sbin/named /usr/local/sbin/named.save
	mv: cannot stat ‘/usr/local/sbin/named’: No such file or
	directory
cp bin/named/named       /usr/local/sbin/

rehash
ldconfig
which named
	/usr/local/sbin/named

named -v
	/usr/local/sbin/named: error: `/usr/local/sbin/.libs/named' does
	not exist
	This script is just a wrapper for named.
	See the libtool documentation for more information.

mkdir -p /usr/local/sbin/.libs/
cp bin/named/.libs/named /usr/local/sbin/.libs/
named -v
	BIND 9.9.3-rpz2+rl.150.20 (Extended Support Version)

/usr/local/sbin/named -t /var/chroot/named -n 4 -S 1024 -u named -c
/etc/named.conf -fd 10

	2013-05-31T09:11:48.259786-07:00 core named[18009]: starting
	BIND 9.9.3-rpz2+rl.150.20 -t /var/chroot/named -n 4 -S 1024 -u
	named -c /etc/named.conf -fd 10
	...
	2013-05-31T09:11:48.607684-07:00 core named[18009]: command
	channel listening on 127.0.0.1#953

works.

!!! ???

hmm.  trying the package machinery,

checkinstall -R --fstrans=no --nodoc --pkgname=bind --pkgversion=993
make install
	...
	Building RPM package...
	...

ls -al /usr/src/packages/RPMS/x86_64/bind-993-1.x86_64.rpm
	-rw-r--r-- 1 root root 1.7M May 31 09:18
	/usr/src/packages/RPMS/x86_64/bind-993-1.x86_64.rpm
rpm -qlp /usr/src/packages/RPMS/x86_64/bind-993-1.x86_64.rpm | grep -i
sbin | grep -i named
	/usr/local/sbin/named
	/usr/local/sbin/named-checkconf
	/usr/local/sbin/named-checkzone
	/usr/local/sbin/named-compilezone
	/usr/local/sbin/named-journalprint

rm -f \
 /usr/local/sbin/named \
 /usr/local/sbin/.libs/named

rpm -ivh /usr/src/packages/RPMS/x86_64/bind-993-1.x86_64.rpm
	Preparing...                         
	################################# [100%]
	Updating / installing...
	   1:bind-993-1                #################################
	   [100%]

rehash
ldconfig
which named
	/usr/local/sbin/named

named -v
	BIND 9.9.3-rpz2+rl.150.20 (Extended Support Version)

then

	/usr/local/sbin/named -t /var/chroot/named -n 4 -S 1024 -u named
	-c /etc/named.conf -fd 10

fails, AGAIN, with the 'parser.c' error


so, iiuc,

	(1) 9.9.2-P2+patch build, 'manual' install --> WORKS
	(2) 9.9.2-P2+patch build, 'rpm'    install --> WORKS
	(3) 9.9.3+patch    build, 'manual' install --> WORKS
	(4) 9.9.3+patch    build, 'rpm'    install --> FAILS

argh.

> It would be easier to believe that the line number machinery in BIND
> is broken and/or the compiler is being too smart and that
> /usr/local/sbin/named was built with bind-9.9.3/lib/isccfg/parser.c 
> if line 2432 of the 9.9.2-P2 parser.c did not fit so well.  That
> makes a build problem likely.

I understand your suspicion.

Other than telling you, I can't prove to you that there's no remnants of
9.9.2 around when I build/install 9.9.3

> Please don't be offended, but I see a common thread.  BIND 9.9.3
> had pre-releases and reasonably extensive real world testing.  It's
> possible that something in your named.conf and zone files is triggering
> bugs during launch while things are simple and easy to debug.
> It's possible that when I added "drop" and "client-ip" to the
> response-policy{} grammar I broke something and only you see the
> resulting crash.  However, the smart money would bet on build
> problems.

No worries; no offense at all.

What I'm seeing is real & reproducible.  Whether it's build &/or code,
really matters not at all to me.  Just trying to find it and fix it (or
at least help along the way ...).

Sure looks like build is, at least, PART of the puzzle. Why it's ONLY
occurring in the 9.9.3 case, dunno -- yet.

If bind had a 'make uninstall', so I could do a full install (docs,
bins, etc) where I need/want it to be, and cleanly remove/recover, I
wouldn't be bothering at all with the checkinstall-generated rpms.

darx



More information about the DNSfirewalls mailing list