If you want to avoid all that just follow the DNS BIND on the wiki and compile BIND YOURSELF. That'd save you many trouble.
I did that. Sent from my iPhone On 2/06/2013, at 22:16, Gary Maurizi <garymaur...@gmail.com> wrote: > I think I might have figured out something about this Centos 6.4 thing and > BIND9_DLZ dynamic updates NOT working with the CentOS 6.4 bind package: > > [root@server private]# named -V > BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 built with > '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' > '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' > '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' > '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' > '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' > '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' > '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' > '--disable-openssl-version-check' '--with-dlz-ldap=yes' > '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' > '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' > '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' > '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' > 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' > 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= > -DDIG_SIGCHASE' > using OpenSSL version: OpenSSL 1.0.0 29 Mar 2010 > > > look at: '--with-gssapi=yes' ' (looks like the compile option is set to > 'yes' when its meant to be a directory path) wtf? > > shouldn't this be: --with-gssapi=/usr/include/gssapi/' > > [root@server private]# ls /usr/include/gssapi > gssapi_ext.h gssapi_generic.h gssapi.h gssapi_krb5.h mechglue.h > [root@server private]# > > > > On Sun, Jun 2, 2013 at 5:40 PM, Gary Maurizi <garymaur...@gmail.com> wrote: > >> I want to thank you both so very much for your help. >> >> It's another day and I'm back to it, refreshed, and determined to figure >> out what is causing so many issues for the CentOS 6.4 users. >> >> Going through the same exact steps on ubuntu 12.04 on a different machine >> does give me working dynamic DNS updates, so I have isolated the issue I'm >> having to CentOS only slightly. >> >> Though bind does not run chrooted by default/at all on CentOS 6.4, I am at >> the point of wondering if maybe some of the samba related features are >> either compiled in and broken/buggy, or not compiled in at all for the bind >> package in the base repositories. >> >> I would like to try compiling bind 9.9 from source with all of the options >> explicitly stated, but was just wondering if maybe some one could take a >> look at the build options for the CentOS-Base repo version of bind and see >> if anything sticks out as missing, I don't want to miss something samba >> needs in 9.9 using the same options presented below, when I do this. :) >> >> [root@server samba-master]# named -V >> BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 built with >> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' >> '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' >> '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' >> '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' >> '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' >> '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' >> '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' >> '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' >> '--disable-openssl-version-check' '--with-dlz-ldap=yes' >> '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' >> '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' >> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' >> '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' >> 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' >> 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= >> -DDIG_SIGCHASE' >> using OpenSSL version: OpenSSL 1.0.0 29 Mar 2010 >> using libxml2 version: 2.7.6 >> [root@server samba-master]# >> >> Thank You so much, >> GM. >> >> >> On Sun, Jun 2, 2013 at 4:36 PM, Andrew Bartlett <abart...@samba.org>wrote: >> >>> On Mon, 2013-06-03 at 01:11 +0200, steve wrote: >>>> On Mon, 2013-06-03 at 08:16 +1000, Andrew Bartlett wrote: >>>>> On Mon, 2013-06-03 at 00:05 +0200, steve wrote: >>>> >>>>>> Hi >>>>>> openSUSE 12.3 >>>>>> This is the first time in many years where the SUSE/openSUSE bind >>> has >>>>>> _almost_ worked out of the box. They will not entertain non chrooted >>>>>> installs. >>>>> >>>>> This is somehow totally disabled? >>>> >>>> No. You can enable it, but the chroot is the default. You cannot install >>>> bind without the bind-chroot environment package too. >>>>> >>>>>> I've tested it. It's OK without tkey-domain nor >>> tkey-gssapi-credential >>>>> >>>>> Good. >>>>> >>>>>> I am trying to present as minimal a setup for the OP. I think in >>>>>> situations such as these, it is important to get bind working choose >>>>>> what. For that we must cut it down to an absolute minimal install >>> with >>>>>> security settings wide open. once it's working, then we can. . . >>>>>> >>>>>> I think that DNS is still our weakest link and I'm really pleased >>> to see >>>>>> the devs looking through the end user list occasionally. Until the >>>>>> internal DNS is ready, we're stuck with bind. Let's try and make it >>> as >>>>>> painless as possible for ourselves. >>>>> >>>>> The only way we can really improve it (as far as I'm currently aware) >>> is >>>>> to take the bind binary, and launch it with a custom config file >>> inside >>>>> 'samba' like we do smbd, pointing only at our DNS zone, and with >>> chroot >>>>> etc disabled. >>>>> >>>>> That should, in theory, get us most of the control we get with the >>>>> internal server. Someone needs to write the patches however, and it >>>>> would mean we gain yet another DNS mode (which may be more trouble >>> than >>>>> it's worth - I don't know). >>>>> >>>>> Andrew Bartlett >>>> >>>> End users need something simple to install. We also need something that >>>> does dynamic dns reliably. The strong points of the internal dns are >>>> it's simplicity of installation. Would it be possible to get it to do >>>> dns updates from nsupdate? >>> >>> It does do dns updates from nsupdate. There is a client-side error >>> shown *after* the successful update, but the developer who developed the >>> patch for this hasn't been able to write the tests to allow his changes >>> to make it into master. >>> >>>> The only reason most of us have to go with >>>> bind is because we need reliable dynamic dns updates. Not just sometimes >>>> and then only with windows clients. Many of the questions and confusion >>>> on this list is to do with DNS. Get that sorted and you have a killer >>>> app. >>> >>> We are not aware that this is anything more than a cosmetic issue. We >>> know it looks really bad, but we need someone to pick up that patch, and >>> find a way to test. >>> >>>> As this is a very big stopper for many of us, would it be possible to >>>> consider a change of developer emphasis for 4.1? Something like a 'DNS >>>> or bust' approach? Many of the things you are doing are amazing but >>>> without the basic DNS, they're lost on us end users. If you wanted any >>>> DNS testers to get it to the rolling out stage, I'm sure many of us here >>>> would be only too pleased to help you test whatever you could throw at >>>> us. >>> >>> Sadly that just isn't how the Samba Team works, sorry. >>> >>>> Thanks for reading. Please don't lose sight of those of us do not code. >>>> We're still very much Samba and still very much here to help the devs >>>> and so the project. >>> >>> We do very much appreciate your interest. >>> >>> Andrew Bartlett >>> >>> -- >>> Andrew Bartlett >>> http://samba.org/~abartlet/ >>> Authentication Developer, Samba Team http://samba.org >>> >>> >>> -- >>> To unsubscribe from this list go to the following URL and read the >>> instructions: https://lists.samba.org/mailman/options/samba >>> >> >> > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba