Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
For lack of response here, the heimdal guys are putting in a work-around for this bind bug. Sam On 25/08/10 17:41, Sam Liddicott wrote: I've also reported this as a bind bug, but I'm posting it here as I think it answers the case for the BSD user in the thread entitled: Can't get BIND to use GSSAPI from /usr/local on FreeBSD (Patch attached which fixes it for me) I've traced my problem to what looks like a mismatch of expectations between heimdal 1.3.3 and bind 9 (BIND 9.7.1-P2) in lib/dns/openssl_link.c, entropy_get returns the number of bytes if successful - always equal to argument num (if successful). entropy_get is registered as a delegate for openSSL's RAND_bytes in dst__openssl_init. My man page for RAND_bytes states: RETURN VALUES RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method. and entropy_get varies from that behaviour. This causes problems with heimdal 1.3.3, in heimdal's lib/krb5/crypto.c: 3995 if (RAND_bytes(buf, len) != 1) 3996 krb5_abortx(NULL, "Failed to generate random block"); So "nsupdate -g" fails when linked with heimdal 1.3.3 It looks like bind 9 is at fault even though heimdal could be more accepting. I don't know if there are other similar errors in other openssl_link.c ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
I've also reported this as a bind bug, but I'm posting it here as I think it answers the case for the BSD user in the thread entitled: Can't get BIND to use GSSAPI from /usr/local on FreeBSD (Patch attached which fixes it for me) I've traced my problem to what looks like a mismatch of expectations between heimdal 1.3.3 and bind 9 (BIND 9.7.1-P2) in lib/dns/openssl_link.c, entropy_get returns the number of bytes if successful - always equal to argument num (if successful). entropy_get is registered as a delegate for openSSL's RAND_bytes in dst__openssl_init. My man page for RAND_bytes states: RETURN VALUES RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method. and entropy_get varies from that behaviour. This causes problems with heimdal 1.3.3, in heimdal's lib/krb5/crypto.c: 3995if (RAND_bytes(buf, len) != 1) 3996krb5_abortx(NULL, Failed to generate random block); So nsupdate -g fails when linked with heimdal 1.3.3 It looks like bind 9 is at fault even though heimdal could be more accepting. I don't know if there are other similar errors in other openssl_link.c -- [FSF Associate Member #2325] http://www.fsf.org/register_form?referrer=2325 --- src/lib/dns/openssl_link.c.o 2010-08-25 02:38:23.0 -0700 +++ src/lib/dns/openssl_link.c 2010-08-25 02:39:05.0 -0700 @@ -79,7 +79,7 @@ if (num 0) return (-1); result = dst__entropy_getdata(buf, (unsigned int) num, ISC_FALSE); - return (result == ISC_R_SUCCESS ? num : -1); + return (result == ISC_R_SUCCESS ? 1 : -1); } static int @@ -93,7 +93,7 @@ if (num 0) return (-1); result = dst__entropy_getdata(buf, (unsigned int) num, ISC_TRUE); - return (result == ISC_R_SUCCESS ? num : -1); + return (result == ISC_R_SUCCESS ? 1 : -1); } static void ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On Sun, 13 Jun 2010, 12:53 -0700, Doug Barton wrote: On 06/11/10 02:51, John Marshall wrote: Is there something else I need to do to nudge BIND in the direction of libgssapi_krb5 in /usr/local ? Until now I've never built BIND with gssapi, so I'm prepared to be told I've missed something basic. Don't worry, you haven't. There is a thread on freebsd-secur...@freebsd.org atm about the wacky state of our base system kerberos, and unfortunately my understanding is that simply installing kerberos from ports doesn't help much. Thanks Doug, I might even buy into that thread. FYI, there is also http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/139426 which suggests that installing cyrus-sasl2 rather than kerberos from ports may be the right way to go. I haven't even started evaluating that patch yet, but perhaps someone on this list who has implemented GSS-TSIG could comment? BIND uses GSSAPI directly, SASL is not relevant here at all. (I've looked at the PR: adding the knob for gssapi makes sense to me but requiring SASL doesn't.) - I can build BIND with --with-openssl=/usr/local and it will link against the OpenSSL port. With this configuration nsupdate -g is not available (no gssapi). - I can build BIND with --with-openssl=/usr --with-gssapi=/usr and it links against the base system gssapi and base system OpenSSL. With this configuration nsupdate -g dies. - I can build BIND with --with-openssl=/usr/local --with-gssapi=/usr/local and it links against the OpenSSL port, the BASE gssapi AND the BASE OpenSSL (via the base gssapi). With this configuration nsupdate -g dies. I want to build BIND against a Kerberos port so that I can see whether or not the nsupdate -g crash is a problem in the base system's gssapi or in BIND. This is the backtrace and it makes the base system gssapi look suspicious to me: FreeBSD 8.1-RC1 BIND 9.7.1rc1 rwsrv05 gdb /usr/bin/nsupdate nsupdate.core --- snip (gdb) bt #0 0x28677c3f in kill () from /lib/libc.so.7 #1 0x28677b9e in raise () from /lib/libc.so.7 #2 0x286769dc in abort () from /lib/libc.so.7 #3 0x286df8ab in krb5_abortx () from /usr/lib/libkrb5.so.10 #4 0x286f3909 in krb5_generate_random_block () from /usr/lib/libkrb5.so.10 #5 0x286d957b in krb5_get_creds_opt_set_ticket () from /usr/lib/libkrb5.so.10 #6 0x286da3ab in krb5_get_creds_opt_set_ticket () from /usr/lib/libkrb5.so.10 #7 0x286da5cf in krb5_get_creds_opt_set_ticket () from /usr/lib/libkrb5.so.10 #8 0x286da950 in krb5_get_creds_opt_set_ticket () from /usr/lib/libkrb5.so.10 #9 0x286db26a in krb5_get_credentials_with_flags () from /usr/lib/libkrb5.so.10 #10 0x286db350 in krb5_get_credentials () from /usr/lib/libkrb5.so.10 #11 0x281fa9cb in _gsskrb5_init_sec_context () from /usr/lib/libgssapi_krb5.so.10 #12 0x286a8d8b in gss_init_sec_context () from /usr/lib/libgssapi.so.10 #13 0x080d79a5 in dst_gssapi_initctx () #14 0x080a4683 in dns_tkey_buildgssquery () #15 0x080509dd in start_gssrequest () #16 0x08051236 in recvsoa () #17 0x0816f17b in isc__taskmgr_dispatch () #18 0x0817207a in evloop () #19 0x08172238 in isc__app_ctxrun () #20 0x08172252 in isc__app_run () #21 0x0804d7df in main () (gdb) krb5_generate_random_block() fails and, from what I can tell, arguments from dst_gssapi_initctx() don't make it that far down. The above was built with... ./configure --prefix=/usr \ --localstatedir=/var \ --sysconfdir=/data/named \ --disable-ipv6 \ --disable-linux-caps \ --with-randomdev=/dev/random \ --with-openssl=/usr/local \ --with-gssapi=/usr/local \ --disable-isc-spnego \ CFLAGS='-O -pipe -march=prescott' Note how we end up linking against the base system gssapi, the libcrypto (OpenSSL) from ports AND the base libcrypto (via the base gssapi): /usr/bin/nsupdate: libgssapi_krb5.so.10 = /usr/lib/libgssapi_krb5.so.10 (0x281ef000) libcrypto.so.7 = /usr/local/lib/libcrypto.so.7 (0x28206000) libxml2.so.5 = /usr/local/lib/libxml2.so.5 (0x28358000) libz.so.5 = /lib/libz.so.5 (0x28477000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x28489000) libm.so.5 = /lib/libm.so.5 (0x2857e000) libc.so.7 = /lib/libc.so.7 (0x28597000) libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x286a6000) libkrb5.so.10 = /usr/lib/libkrb5.so.10 (0x286af000) libhx509.so.10 = /usr/lib/libhx509.so.10 (0x2870a000) libcrypto.so.6 = /lib/libcrypto.so.6 (0x2873e000) libroken.so.10 = /usr/lib/libroken.so.10 (0x2889) libasn1.so.10 = /usr/lib/libasn1.so.10 (0x2889f000) libcom_err.so.5 = /usr/lib/libcom_err.so.5 (0x2891) libcrypt.so.5 = /lib/libcrypt.so.5 (0x28912000) Configure seems convinced about using gssapi from /usr/local. Entire config.log available at:
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
In message slrni1ea5q.10j.j...@rwpc12.mby.riverwillow.net.au, John Marshall w rites: On Tue, 15 Jun 2010 16:52:05 +1000, Mark Andrews wrote: So what was in config.log? With libgssapi_krb5 you are trying to link against MIT kerberos. Sorry, s/_krb5// (Heimdal) The config.log is here, and seems convinced about using /usr/local. http://www.riverwillow.net.au/~john/bind971rc1/config.log Well you have two three versions of gssapi installed. Two in /usr (MIT + Heimdal) and one in /usr/local and configure is just not written to cope with that. MIT and Heimdal require different sets of libraries and the code that attempts to work that all out matched the MIT code in /usr before it tests the Heimdal code in /usr/local. I think this requires hand tweeking post configure. -- John Marshall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On Wed, 16 Jun 2010, 09:12 +1000, Mark Andrews wrote: In message slrni1ea5q.10j.j...@rwpc12.mby.riverwillow.net.au, John Marshall w rites: On Tue, 15 Jun 2010 16:52:05 +1000, Mark Andrews wrote: So what was in config.log? With libgssapi_krb5 you are trying to link against MIT kerberos. Sorry, s/_krb5// (Heimdal) The config.log is here, and seems convinced about using /usr/local. http://www.riverwillow.net.au/~john/bind971rc1/config.log Well you have two three versions of gssapi installed. Two in /usr (MIT + Heimdal) and one in /usr/local and configure is just not written to cope with that. MIT and Heimdal require different sets of libraries and the code that attempts to work that all out matched the MIT code in /usr before it tests the Heimdal code in /usr/local. I think this requires hand tweeking post configure. I guess what we're seeing is a feature of the way FreeBSD integrates Heimdal into its base system: it unbundles libgssapi into its component parts (libgssapi_krb5, _ntlm, _spnego). There is no MIT Kerberos on the system, just FreeBSD's port of Heimdal into its base system. Kerberos in FreeBSD 8.n is Heimdal 1.1.0 (split into component libraries in /usr/lib as described above). I also installed Heimdal 1.3.3 (un-hacked - all one libgssapi.so) into /usr/local/lib so that I could try linking BIND against it. Now that I think I understand what is happening, is it worth asking somebody who understands the workings of configure to teach it that (irrespective of library names) the FreeBSD base system uses Heimdal? Maybe not. In any case, pointers as to which file(s) to hack post-configure would be appreciated. Thank you for your help. -- John Marshall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
In message 20100615233907.gd1...@rwpc12.mby.riverwillow.net.au, John Marshall writes: On Wed, 16 Jun 2010, 09:12 +1000, Mark Andrews wrote: In message slrni1ea5q.10j.j...@rwpc12.mby.riverwillow.net.au, John Marsha ll w rites: On Tue, 15 Jun 2010 16:52:05 +1000, Mark Andrews wrote: So what was in config.log? With libgssapi_krb5 you are trying to link against MIT kerberos. Sorry, s/_krb5// (Heimdal) The config.log is here, and seems convinced about using /usr/local. http://www.riverwillow.net.au/~john/bind971rc1/config.log Well you have two three versions of gssapi installed. Two in /usr (MIT + Heimdal) and one in /usr/local and configure is just not written to cope with that. MIT and Heimdal require different sets of libraries and the code that attempts to work that all out matched the MIT code in /usr before it tests the Heimdal code in /usr/local. I think this requires hand tweeking post configure. I guess what we're seeing is a feature of the way FreeBSD integrates Heimdal into its base system: it unbundles libgssapi into its component parts (libgssapi_krb5, _ntlm, _spnego). There is no MIT Kerberos on the system, just FreeBSD's port of Heimdal into its base system. Kerberos in FreeBSD 8.n is Heimdal 1.1.0 (split into component libraries in /usr/lib as described above). I also installed Heimdal 1.3.3 (un-hacked - all one libgssapi.so) into /usr/local/lib so that I could try linking BIND against it. libgssapi_krb5 is from MIT Kerberos. % grep gssapi /usr/ports/security/heimdal/pkg-plist include/gssapi.h include/gssapi/gkrb5_err.h include/gssapi/gssapi.h include/gssapi/gssapi_krb5.h include/gssapi/gssapi_spnego.h lib/libgssapi.a lib/libgssapi.la lib/libgssapi.so lib/libgssapi.so.2 @dirrm include/gssapi % grep gssapi /usr/ports/security/krb5/pkg-plist include/gssapi.h include/gssapi/gssapi.h include/gssapi/gssapi_ext.h include/gssapi/gssapi_generic.h include/gssapi/gssapi_krb5.h include/gssapi/mechglue.h include/gssrpc/auth_gssapi.h lib/libgssapi_krb5.so lib/libgssapi_krb5.so.2 @dirrm include/gssapi % grep gssapi /usr/ports/security/krb5-16/pkg-plist include/gssapi.h include/gssapi/gssapi.h include/gssapi/gssapi_generic.h include/gssapi/gssapi_krb5.h include/gssapi/mechglue.h include/gssrpc/auth_gssapi.h lib/libgssapi_krb5.so lib/libgssapi_krb5.so.2 @dirrm include/gssapi % Now that I think I understand what is happening, is it worth asking somebody who understands the workings of configure to teach it that (irrespective of library names) the FreeBSD base system uses Heimdal? Maybe not. In any case, pointers as to which file(s) to hack post-configure would be appreciated. Thank you for your help. -- John Marshall -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
In message 20100615233907.gd1...@rwpc12.mby.riverwillow.net.au, John Marshall writes: On Wed, 16 Jun 2010, 09:12 +1000, Mark Andrews wrote: In message slrni1ea5q.10j.j...@rwpc12.mby.riverwillow.net.au, John Marsha ll w rites: On Tue, 15 Jun 2010 16:52:05 +1000, Mark Andrews wrote: So what was in config.log? With libgssapi_krb5 you are trying to link against MIT kerberos. Sorry, s/_krb5// (Heimdal) The config.log is here, and seems convinced about using /usr/local. http://www.riverwillow.net.au/~john/bind971rc1/config.log Well you have two three versions of gssapi installed. Two in /usr (MIT + Heimdal) and one in /usr/local and configure is just not written to cope with that. MIT and Heimdal require different sets of libraries and the code that attempts to work that all out matched the MIT code in /usr before it tests the Heimdal code in /usr/local. I think this requires hand tweeking post configure. I guess what we're seeing is a feature of the way FreeBSD integrates Heimdal into its base system: it unbundles libgssapi into its component parts (libgssapi_krb5, _ntlm, _spnego). There is no MIT Kerberos on the system, just FreeBSD's port of Heimdal into its base system. Kerberos in FreeBSD 8.n is Heimdal 1.1.0 (split into component libraries in /usr/lib as described above). I also installed Heimdal 1.3.3 (un-hacked - all one libgssapi.so) into /usr/local/lib so that I could try linking BIND against it. Now that I think I understand what is happening, is it worth asking somebody who understands the workings of configure to teach it that (irrespective of library names) the FreeBSD base system uses Heimdal? Maybe not. In any case, pointers as to which file(s) to hack post-configure would be appreciated. configure sets these. lib/isc/include/isc/platform.h: AC_SUBST(ISC_PLATFORM_HAVEGSSAPI) AC_SUBST(ISC_PLATFORM_GSSAPIHEADER) AC_SUBST(ISC_PLATFORM_KRB5HEADER) lib/dns/Makefile: bin/*/Makefile: AC_SUBST(USE_GSSAPI) AC_SUBST(DST_GSSAPI_INC) AC_SUBST(DNS_GSSAPI_LIBS) Thank you for your help. -- John Marshall -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On Wed, 16 Jun 2010, 10:06 +1000, Mark Andrews wrote: libgssapi_krb5 is from MIT Kerberos. ...and from FreeBSD's implementation of Heimdal rwsrv05 cat /usr/src/kerberos5/include/version.h /* $FreeBSD: src/kerberos5/include/version.h,v 1.15.2.1.4.1 2010/06/14 02:09:06 kensmith Exp $ */ const char *heimdal_long_version = @(#)$Version: Heimdal 1.1.0 (FreeBSD) $; const char *heimdal_version = Heimdal 1.1.0; rwsrv05 find /usr/src/kerberos5 -name libgssapi\* /usr/src/kerberos5/lib/libgssapi_krb5 /usr/src/kerberos5/lib/libgssapi_ntlm /usr/src/kerberos5/lib/libgssapi_spnego -- John Marshall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
In message 20100616004753.ge1...@rwpc12.mby.riverwillow.net.au, John Marshall writes: On Wed, 16 Jun 2010, 10:06 +1000, Mark Andrews wrote: libgssapi_krb5 is from MIT Kerberos. ...and from FreeBSD's implementation of Heimdal rwsrv05 cat /usr/src/kerberos5/include/version.h /* $FreeBSD: src/kerberos5/include/version.h,v 1.15.2.1.4.1 2010/06/14 02:09: 06 kensmith Exp $ */ const char *heimdal_long_version = @(#)$Version: Heimdal 1.1.0 (FreeBSD) $; const char *heimdal_version = Heimdal 1.1.0; rwsrv05 find /usr/src/kerberos5 -name libgssapi\* /usr/src/kerberos5/lib/libgssapi_krb5 /usr/src/kerberos5/lib/libgssapi_ntlm /usr/src/kerberos5/lib/libgssapi_spnego -- John Marshall Which means ports doesn't mask the system files. Who permitted this idiocy. The alternative is to edit configure.in to only have the libraries in the port version where configure checks for which set of libraries needed and run autoheader + autoconf followed by configure. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On Wed, 16 Jun 2010, 11:04 +1000, Mark Andrews wrote: The alternative is to edit configure.in to only have the libraries in the port version where configure checks for which set of libraries needed and run autoheader + autoconf followed by configure. Thanks. configure.in looks like the place to spend my time. It includes helpful comments about /usr vs /usr/local and KTH vs MIT. -- John Marshall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
In message 4c15371c.7070...@dougbarton.us, Doug Barton writes:
On 06/11/10 02:51, John Marshall wrote:
BIND 9.7.1rc1
FreeBSD 8.1-PRERELEASE
I've just stepped into the world of nsupdate (instead of doing the
freeze/edit/thaw dance). I have had success using TSIG (nsupdate -k)
but I would like to use TKEY-GSS (nsupdate -g). When I try to do that,
nsupdate dumps core.
$ /usr/bin/nsupdate -g -d
prereq nxdomain rwpc12.mby.riverwillow.net.au.
Reply from SOA query:
snip
Found zone name: mby.riverwillow.net.au
The master is: ns1.mby.riverwillow.net.au
start_gssrequest
nsupdate: Failed to generate random block
Abort trap (core dumped)
I suspect the operating system at this point but want to build BIND
against separate gssapi_krb5 and OpenSSL libraries in order to isolate
the problem.
Telling configure --with-openssl=/usr/local does the trick for OpenSSL.
Telling configure --with-gssapi=/usr/local makes all the right kind of
impressions on config.log, but the linker still ends up using the
operating system's gssapi libraries under /usr/lib. Is there something
else I need to do to nudge BIND in the direction of libgssapi_krb5 in
/usr/local ?
Until now I've never built BIND with gssapi, so I'm prepared to be told
I've missed something basic.
John,
Don't worry, you haven't. There is a thread on
freebsd-secur...@freebsd.org atm about the wacky state of our base
system kerberos, and unfortunately my understanding is that simply
installing kerberos from ports doesn't help much.
I don't want to get too deep in the weeds on FreeBSD-specific stuff
here, so you may want to follow up on -security for that stuff. I do
want to leave the door open however for anyone to comment on
BIND-specific issues with the configure script.
FYI, there is also
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/139426 which suggests
that installing cyrus-sasl2 rather than kerberos from ports may be the
right way to go. I haven't even started evaluating that patch yet, but
perhaps someone on this list who has implemented GSS-TSIG could comment?
Personally I loathe kerberos almost as much as windows, so I haven't
exactly been eager to dive into this, but because there is user demand
for it I would like to get up to speed so this seems as good a time as any.
Doug
Anything in the base system that is also in ports should be in its
own seperate tree(s).
/usr/local/foo/{bin,lib,include}
or
/usr/local/{bin,lib,include}/foo
This allows one to select the ports or system components on a per
component basis. I prefer the former.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On Tue, 15 Jun 2010, 10:31 +1000, Mark Andrews wrote: On 06/11/10 02:51, John Marshall wrote: Telling configure --with-openssl=/usr/local does the trick for OpenSSL. Telling configure --with-gssapi=/usr/local makes all the right kind of impressions on config.log, but the linker still ends up using the operating system's gssapi libraries under /usr/lib. Is there something else I need to do to nudge BIND in the direction of libgssapi_krb5 in /usr/local ? Anything in the base system that is also in ports should be in its own seperate tree(s). It is: base = /usr port = /usr/local This allows one to select the ports or system components on a per component basis. I prefer the former. and my point is that I can't get BIND to use the port. Sorry for the extra noise that obscured that fact. -- John Marshall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On 06/11/10 02:51, John Marshall wrote:
BIND 9.7.1rc1
FreeBSD 8.1-PRERELEASE
I've just stepped into the world of nsupdate (instead of doing the
freeze/edit/thaw dance). I have had success using TSIG (nsupdate -k)
but I would like to use TKEY-GSS (nsupdate -g). When I try to do that,
nsupdate dumps core.
$ /usr/bin/nsupdate -g -d
prereq nxdomain rwpc12.mby.riverwillow.net.au.
Reply from SOA query:
snip
Found zone name: mby.riverwillow.net.au
The master is: ns1.mby.riverwillow.net.au
start_gssrequest
nsupdate: Failed to generate random block
Abort trap (core dumped)
I suspect the operating system at this point but want to build BIND
against separate gssapi_krb5 and OpenSSL libraries in order to isolate
the problem.
Telling configure --with-openssl=/usr/local does the trick for OpenSSL.
Telling configure --with-gssapi=/usr/local makes all the right kind of
impressions on config.log, but the linker still ends up using the
operating system's gssapi libraries under /usr/lib. Is there something
else I need to do to nudge BIND in the direction of libgssapi_krb5 in
/usr/local ?
Until now I've never built BIND with gssapi, so I'm prepared to be told
I've missed something basic.
John,
Don't worry, you haven't. There is a thread on
freebsd-secur...@freebsd.org atm about the wacky state of our base
system kerberos, and unfortunately my understanding is that simply
installing kerberos from ports doesn't help much.
I don't want to get too deep in the weeds on FreeBSD-specific stuff
here, so you may want to follow up on -security for that stuff. I do
want to leave the door open however for anyone to comment on
BIND-specific issues with the configure script.
FYI, there is also
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/139426 which suggests
that installing cyrus-sasl2 rather than kerberos from ports may be the
right way to go. I haven't even started evaluating that patch yet, but
perhaps someone on this list who has implemented GSS-TSIG could comment?
Personally I loathe kerberos almost as much as windows, so I haven't
exactly been eager to dive into this, but because there is user demand
for it I would like to get up to speed so this seems as good a time as any.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
