lynn said the following on 03/31/2012 03:17 AM:
Hi Yes. I can explain the conflict now. My Samba4 dynamic dns configuration was creating the forward zone for me so by adding my own it was conflicting with the zone that was already loaded. DUH! I only needed to add the _forward_ zone myself as the A record was already there.
Ah. I'm glad you found that. I'm glad because I have no experience or insight into Samba*4*. I use a simplified samba3; the on;ly time I bring a early W/Xp out of the closet it to run MS-Money/97 and I fire up samba on a server so I can print out stuff for my accountant. Its a once a year event and my samba needs are not great.
Anton, could you be an absolute darling and have a look through this for me? I think it's working now but I need expert opinion before I take it to the production lan.
The server has fqdn hh3.hh3.site at 192.168.1.3
Now *that* I would put in /etc/host! Actually it should be supplied by DHCP but my experience is that many/some machines don't always honour all of option log-servers option lpr-servers option time-servers option smtp-server option netbios-name-servers I'd recommend reading http://www.cymru.com/Documents/secure-bind-template.html which is what I've based my home network on. Its simple and clear and well explained.
Here is the log showing samba creating the forward zone and then loading my reverse zone:
Mar 31 08:47:46 hh3 named[9900]: Loading 'AD DNS Zone' using driver dlopen
Ouch! Samba stuff. I'm out of my depth with this :-(
Mar 31 08:47:46 hh3 named[9900]: samba_dlz: started for DN DC=hh3,DC=site Mar 31 08:47:46 hh3 named[9900]: samba_dlz: starting configure Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone 'hh3.site' Mar 31 08:47:46 hh3 named[9900]: samba_dlz: configured writeable zone '_msdcs.hh 3.site' Mar 31 08:47:46 hh3 named[9900]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2012033101
Here is my reverse zone (created by Yast):
cat /var/lib/named/master/1.168.192.in-addr.arpa $TTL 2d @ IN SOA hh3.hh3.site. root.hh3.hh3.site. ( 2012033101 ; serial 3h ; refresh 1h ; retry 1w ; expiry 1d ) ; minimum 1.168.192.in-addr.arpa. IN NS hh3.hh3.site. 3 IN PTR hh3.hh3.site.
Now you *may* have a problem here. [Sidebar: I'm assuming that yast created such a minimalist zone file because that was all it could see, just the local machine. If you google, you'll find there are many tools (often written in perl or shell) for generating zone files. ] I'm assuming that your other machines - workstations ? - are also on the 192.168.1/24 subnet and have addresses assigned by DHCP. There are two ways to can get their reverse addresses to work. The first is to use 'dynamic dns' where the DHCP server tells the DNS server that it has assigned an address and supplies the details which the DNS server can now had out in response to queries. Its another thing to have to get exactly right. http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_02.htm http://www.sghaida.com/dhcp-bind-dynamic-updates/ and this mentions a few important 'secrets' http://hackerific.net/2007/12/24/dynamic-dns-with-dhcp-and-bind-9/ When you report
Still can't lose this error: Mar 31 08:47:46 hh3 named[9900]: couldn't add command channel ::1#953: address not available
Well that's what its talking about, but it looks like that involves IPv6. To be honest, once IPv6 comes into play with ddns things get a bit complicated, especially of you're not using IPv6 in the first place :-) The other way to deal with workstation addresses is a bit of a cheat, but its easy and it works and in a constrained small system as opposed to a multi-segment, multi-server campus, I'm not going to argue. I use it for my home system, a few machines around the house, a couple of laptops, toys ... wifi on the patio ... Basically you pre-load the reverse domain to match the addresses DHCP can supply. So if your DHCP says subnet 192.168.1.0 netmask 255.255.255.127 { authoritative; range dynamic-bootp 192.168.1.32 192.168.1.64 ; Then you can load up you reverse zone with 32 IN PTR ws32.hh3.site. 33 IN PTR ws33.hh3.site. ... 64 IN PTR ws64.hh3.site. Actually if you're really good and have the upper levels set correctly, you can use a lot of shorthand and only need lines like 32 IN PTR ws32 :-) But heck, belt and braces approach never hurt!
Here is /etc/named.conf grep -v "#" /etc/named.conf
Filtering out comments .... after reading mine, go back and read what you didn't show!
options { directory "/var/lib/named"; managed-keys-directory "/var/lib/named/dyn/"; dump-file "/var/log/named_dump.db"; statistics-file "/var/log/named.stats";
All those should be writeable by named.
listen-on-v6 { any; };
WHOA! listen-on-v6 turns on BIND to listen for IPv6 queries. If you're not running IPv6 then you want "none" rather than "any". This may account for one error :-) See http://www.zytrax.com/books/dns/ch7/hkpng.html
notify no; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab"; include "/etc/named.d/forwarders.conf";
That may or may not produce more ....
}; zone "." in { type hint; file "root.hint"; }; zone "localhost" in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.0.0.zone"; }; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa"
If you're not using IPv6 then you might consider removing all such references.
in { type master; file "127.0.0.zone"; allow-transfer { any; };
Why?
}; include "/etc/named.conf.include";
Again, an 'include' may alter things dramatically!
logging { category default { log_syslog; }; channel log_syslog { syslog; }; }; zone "1.168.192.in-addr.arpa" in { allow-transfer { any; };
Why?
file "master/1.168.192.in-addr.arpa"; type master; }; include "/usr/local/samba/private/named.conf";
Again, an 'include' may alter things dramatically!
Notes: Changes made to the 12.1 bind to get rid of the startup errors: chown named:named /var/lib/named (working directory not writable)
:-)
touch /var/lib/dyn/managed-keys.bind (file does not exist)
No, that needs to contain the crypto key used by ddns.
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail)
I can see that; I'm not going to harp on abut "basic security". I chroot so I know I can, but if you can justify not needing to then its "no harm, no foul".
The Yast DNS module is not easy to use. Do you think it would be helpful if I wrote a howto for it? There is one here: http://www.pcc-services.com/sles/dns3.html but it's not correct.
There are so many tools out there that do all this a help page might read "use these instead"! Check out named-checkconf and named-checkzone and have a look at named-compilezone -- Hardware has grown following Moore's Law; software seems to be stuck with Gresham's Law. - Jim Horning, Inside Risks 133 CACM 44, 7, July 2001 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org