At Tue, 20 Oct 2009 20:29:20 +0000,
Evan Hunt <ea...@isc.org> wrote:
> BIND 9.7.0b1 is now available.
[snip]
> - On some platforms, named and other binaries can now print out
> a stack backtrace an assertion failure, to aid in debugging.
I'd like to know platforms for which this feature does NOT work, so
that we can fix the problem (preferably) or disable this feature at
./configure time for such platforms.
To see if it works for your platform, please perform the following
steps:
1. build 9.7.0b1
2. go to the "bind-9.7.0b1/bin/tests" directory
3. % make backtrace_test
4. % ./backtrace_test
On success, "backtrace_test" simply exits without any output (I know
it's not a good UI); if something goes wrong it will dump some warning
messages to stderr and exit with a non-0 exit code. If the test fails
on your platform, please report it to bind9...@isc.org, including
the OS, its version, and hardware architecture (x86, amd64, sparc,
etc).
There are several known defects:
- this feature doesn't work if it's built with libtool
- this doesn't work for Windows (probably obvious)
these cases don't have to be tested.
Thanks,
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code. If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).
I've seen a couple of prompt reports (thanks!), and these reports
reminded me that I forgot to ask for one more element of the platform:
compiler. Please include which compiler you use with your reports.
Thanks again,
> Dear beta testers,
>
> At Tue, 20 Oct 2009 20:29:20 +0000,
> Evan Hunt <ea...@isc.org> wrote:
>
>> BIND 9.7.0b1 is now available.
>
> [snip]
>
>> - On some platforms, named and other binaries can now print out
>> a stack backtrace an assertion failure, to aid in debugging.
>
> I'd like to know platforms for which this feature does NOT work, so
> that we can fix the problem (preferably) or disable this feature at
> ./configure time for such platforms.
>
> To see if it works for your platform, please perform the following
> steps:
>
> 1. build 9.7.0b1
> 2. go to the "bind-9.7.0b1/bin/tests" directory
> 3. % make backtrace_test
> 4. % ./backtrace_test
>
> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code.
> If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).
Possibly also useful to report success here so that many people aren't
needlessly repeating the same test.
It passed for me on:
x86_64 / Mac OS X 10.6.1 / Darwin dhcp4.sanxion.org 10.0.0 Darwin
Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;
root:xnu-1456.1.25~1/RELEASE_I386 i386
x86 / Ubuntu 9.04 / Linux sb 2.6.28-11-server #42-Ubuntu SMP Fri Apr
17 02:48:10 UTC 2009 i686 GNU/Linux
> There are several known defects:
> - this feature doesn't work if it's built with libtool
> - this doesn't work for Windows (probably obvious)
> these cases don't have to be tested.
>
> Thanks,
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> x86_64 / Mac OS X 10.6.1 / Darwin dhcp4.sanxion.org 10.0.0 Darwin
> Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;
> root:xnu-1456.1.25~1/RELEASE_I386 i386
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
> x86 / Ubuntu 9.04 / Linux sb 2.6.28-11-server #42-Ubuntu SMP Fri Apr
> 17 02:48:10 UTC 2009 i686 GNU/Linux
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
> Possibly also useful to report success here so that many people aren't
> needlessly repeating the same test.
Yes, that's indeed helpful as we actually plan to take an "opt-in"
approach, that is, enabling it only for those known to work.
This is a list of platforms I've confirmed to work correctly:
- FreeBSD 6.1-RELEASE i386, gcc (GCC) 3.4.4 [FreeBSD] 20050518
- FreeBSD 7.0-RC1 amd64, gcc (GCC) 4.2.1 20070719 [FreeBSD]
- FreeBSD 8.0-RC1 ia64, gcc (GCC) 4.2.1 20070719 [FreeBSD]
- Linux 2.6.25 i686, gcc (Debian 4.3.2-1.1) 4.3.2
- Linux 2.6.18-6-amd64, gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
- SunOS 5.10 i86pc(amd64), Sun C 5.7 2005/01/07
- SunOS 5.10 i86pc(amd64), gcc (GCC) 3.4.2 (producing 32-bit code)
In general, I expect it should work on
- most x86/amd64/IA64 + gcc platforms (regardless of OS)
- most Linux variants (assuming the compiler is gcc, regardless of
machine arch)
So, if it does NOT work on a platform that matches the above
condition, it's good to know. Likewise, if it DOES works on a
platform that doesn't match the condition, it's also a good input.
Other results, which are actually expected but not yet confirmed, are
also appreciated.
Thanks once again,
we're not using sparc for our bind installations, but this is a feedback
on your 'call for testers' (bind compilation went successfully on both
compilers):
solaris 10 sparc, sun studio 12u1 compiler:
$ uname -a
SunOS chuck 5.10 Generic_141414-10 sun4u sparc SUNW,Sun-Fire-V440
$ cc -V
cc: Sun C 5.10 SunOS_sparc 2009/06/03
[tests]$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented
[tests]$ echo $?
1
solaris 10 sparc, sun gcc compiler:
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
[tests]$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented
$ uname -a
SunOS hosting1 5.10 Generic_137111-04 sun4v sparc SUNW,SPARC-Enterprise-T5120
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented
$ echo $?
1
Debian 5 sparc running on Sun E250
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
$ uname -a
Linux squat 2.6.26-2-sparc64-smp #1 SMP Sun Jun 21 05:58:06 UTC 2009 sparc64 GNU/Linux
$ ./backtrace_test
isc_backtrace_gettrace failed: not found
$ echo $?
1
- NetBSD 4.99.62 amd64, gcc 4.1.3 20080202 prerelease (NetBSD nb1 20080202)
- NetBSD 5.0.0_PATCH i386, pcc 0.9.9 (HEAD) for i386-unknown-netbsdelf5.0.0.
# uname -a
SunOS nemesis 5.11 snv_125 sun4u sparc SUNW, 5-slot Sun Enterprise E3500
# gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6
Regards,
-----Original Message-----
From: bind-user...@lists.isc.org
[mailto:bind-user...@lists.isc.org] On Behalf Of JINMEI Tatuya / ????
Sent: Wednesday, October 21, 2009 8:18 PM
To: bind-...@isc.org
Subject: Re: call for testers (Re: ISC BIND 9.7.0b1 is now available)
At Wed, 21 Oct 2009 15:50:00 -0700,
JINMEI Tatuya <jin...@isc.org> wrote:
> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code. If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).
I've seen a couple of prompt reports (thanks!), and these reports
reminded me that I forgot to ask for one more element of the platform:
compiler. Please include which compiler you use with your reports.
Thanks again,
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
> Backtrace executes successfully on the latest build of OpenSolaris for SPARC
> (snv_125) with gcc version 3.4.6
>
> # uname -a
> SunOS nemesis 5.11 snv_125 sun4u sparc SUNW, 5-slot Sun Enterprise E3500
>
> # gcc -v
> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
> Configured with: ../configure --with-as=/usr/ccs/bin/as
> --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
> Thread model: posix
> gcc version 3.4.6
Thanks for testing. This is an interesting result...I didn't expect
it works for SunOS + sparc. Can you identify if your system has a
"backtrace()" library function in libc? Does your system have
/usr/include/execinfo.h?
metis% uname -a
SunOS metis 5.9 Generic_122300-31 sun4u sparc SUNW,Ultra-1
metis% make backtrace_test
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing -o backtrace_test_nosymtbl \
backtrace_test.c ../../lib/isc/libisc.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
#first step: create a first symbol table
rm -f symtbl.c
if test X/usr/bin/perl != X; then \
/usr/bin/perl ../../util/mksymtbl.pl \
backtrace_test_nosymtbl; else \
cp ../../lib/isc/backtrace-emptytbl.c symtbl.c; fi
#second step: build a binary with the first symbol table
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing \
-o backtrace_test0 backtrace_test.c symtbl.c \
../../lib/isc/libisc-nosymtbl.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
rm -f symtbl.c
#third step: create a second symbol table
if test X/usr/bin/perl != X; then \
/usr/bin/perl ../../util/mksymtbl.pl backtrace_test0; else \
cp ../../lib/isc/backtrace-emptytbl.c symtbl.c; fi
#fourth step: build the final binary
rm -f backtrace_test0
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing \
-o backtrace_test backtrace_test.c symtbl.c
../../lib/isc/libisc-nosymtbl.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
rm -f symtbl.c
metis% ./backtrace_test
isc_backtrace_gettrace failed: not implemented
metis%
>
> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code. If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).
>
> There are several known defects:
> - this feature doesn't work if it's built with libtool
> - this doesn't work for Windows (probably obvious)
> these cases don't have to be tested.
>
> Thanks,
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
---------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
| Direct: 408.569.7928
People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell
The price of freedom is eternal vigilance. -- Thomas Jefferson
"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton
OpenSolaris build 125 includes execinfo.h within the /usr/include directory.
Also, backtrace() functionality has been included within the OS since build
63.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6536146
Regards,
Gerry Scott
President and Principal Engineer
WAN Systems
Email: gsc...@wansyseng.com
"Empowering businesses with efficient, effective and secure local, wide area
and Internet infrastructure. Customer satisfaction is key to the
bottom-line; the network is key to providing the customer experience".
-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:jin...@isc.org]
Sent: Monday, October 26, 2009 4:33 AM
To: gsco...@gmail.com
Cc: bind-...@isc.org
Subject: Re: call for testers (Re: ISC BIND 9.7.0b1 is now available)
---
> OpenSolaris build 125 includes execinfo.h within the /usr/include directory.
> Also, backtrace() functionality has been included within the OS since build
> 63.
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6536146
Okay, that's good know. Thanks,
> BIND 9.7.0b1 is now available.
Apparently, support for the new algorithms RSASHA256 and RSASHA512 is
not included? Is it planned for 9.7 or shall I wait 9.8?
% bind/bin/dnssec/dnssec-keygen -a RSASHA256 -b 2048 -r /dev/urandom example.net
dnssec-keygen: fatal: unknown algorithm RSASHA256
That will be in 9.7.0b2.
--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.
>> Apparently, support for the new algorithms RSASHA256 and RSASHA512 is
>> not included? Is it planned for 9.7 or shall I wait 9.8?
>
>That will be in 9.7.0b2.
You aren't going to wait for the RFC? - it doesn't seem to be out yet.
Or maybe you are predicting that it will be out before 9.7.0b2 is...
--
Chris Thompson
Email: ce...@cam.ac.uk
> You aren't going to wait for the RFC?
It is in AUTH48 (the last step before publication, theoretically
meaning that the people involved have 48 h to make remarks).
After all, ldns already has it :-)
% ldns-keygen -a RSASHA256 vachement-secure.example
Kvachement-secure.example.+008+23094
% cat Kvachement-secure.example.+008+23094.key
vachement-secure.example. 3600 IN DNSKEY 256 3 8 \
AwEAAc87fkhQ3RehZ9AWUtataphm6Ku+DLKgtUPp/Zi0mwhtDN36oWBhzUt5a82Zeat4zsbC6W
jIDWWqOx33cWh3ISMKDK0cOu1kMRCZTXS98WoSA0TgfMBdGdaK/Z+yLX+COq8HL72gBDG/RuDqIOwdtC
BhbDluIwafzPAw3l2rIEiR \
;{id = 23094 (zsk), size = 1024b}
It's out now (RFC 5702), so this is a moot point--but we were mainly
waiting for IANA to pick the final codepoints, not so much for the
RFC to be finalized.
>> You aren't going to wait for the RFC? - it doesn't seem to be out yet.
>> Or maybe you are predicting that it will be out before 9.7.0b2 is...
>
>It's out now (RFC 5702), so this is a moot point--but we were mainly
>waiting for IANA to pick the final codepoints, not so much for the
>RFC to be finalized.
Will you be adding RSASHA256 support in the 9.5.x and 9.6.x series? It
might be a bit optimistic to expect everyone to move to 9.7.x by 2010-07-01,
if that's when the root zone is going to be *really* signed (with RSASHA256,
according to current reports).
Not 9.5.x, as it lacks NSEC3 support.
Adding SHA-2 to 9.6.x would violate our policy of making major
functional changes only in major releases, so I don't expect we'll
do that. Given the odd circumstances you mentioned, I won't say for
certain that we won't--but I doubt it.
9.7.0 is going to be final in a little over a month, which is fortunate
timing.
> - Support for RFC 5011 automated trust anchor maintenance (see
> README.rfc5011 for additional details).
Seems to work fine, thanks.
With:
managed-keys {
"se." initial-key 257 3 5
"AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ
...
// key id = 8779
};
I indeed get the new key, 49678
29-Oct-2009 09:23:07.275 zone managed-keys.bind/IN/_meta: loaded serial 5
> > - Support for RFC 5011 automated trust anchor maintenance (see
> > README.rfc5011 for additional details).
Hmmm, it suddenly had a problem:
02-Nov-2009 10:59:14.945 zone managed-keys.bind/IN/_meta: loaded serial 156
...
02-Nov-2009 11:26:35.154 malformed transaction: managed-keys.bind.jnl last serial 157 != transaction first serial 156
02-Nov-2009 11:26:35.154 zone managed-keys.bind/IN/_meta: keyfetch_done:dns_journal_write_transaction -> unexpected error
...
02-Nov-2009 11:27:04.198 malformed transaction: managed-keys.bind.jnl last serial 158 != transaction first serial 157
02-Nov-2009 11:27:04.198 zone managed-keys.bind/IN/_meta: keyfetch_done:dns_journal_write_transaction -> unexpected error
Is it serious? The file managed-keys.bind looks normal.
It's concerning. How many 5011-maintained zones are you running? Can I
see your managed-keys.bind file?
I would expect the result of this to be that keys are not properly updated
in managed-keys.bind until the problem with committing to the journal has
gone away. If it persists for more than one or two events, restart named.
If that doesn't fix it, delete managed-keys.bind.jnl and restart named
again.
I don't know how the journal's serial number would have gotten out of sync
like that. I'll have to look closer.