lynn said the following on 03/31/2012 01:54 PM:
On 03/31/2012 06:59 PM, Anton Aylward wrote:
lynn said the following on 03/31/2012 11:36 AM:
Do I need a PTR for each computer on the lan? I can imagine circumstance where the answer to that is 'no' but I suspect those circumstances don't apply to you.
If you had ddns working then it would be done 'auto-magically'.
OK. Well, we have ddns with a (re) writeable forward zone handled by Samba4. You can see the IP it has been assigned by DHCP on the server as it issues Kerberos tickets for the fileserver and such. I suppose the test would be to remove the 127.0.1.1 hostname.fqdn hostname entry in /etc/hosts on the client and see if we can still authenticate.
I'm not sure that would actually be a test. See later ....
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. Yes. That's what we have. that's what the samba4 guys added to bind9 to Was it the Samba guys? I thought DDNS (RFC2136 et al [3007, 4033, 4034, 4035]) dates back to 1997 and was out of ISC edited by the proverbial Mr Vixie :-)
Yes, Microsoft and Ad integrated DDNS and brought in the modified version of kerberos, but that still doesn't make it a SAMBA initiative.
You can experiment manually adding records from the CLI with 'nsupdate'. They were the ones who put he dlz code into bind to make it work against AD.
Are you running AD? You have a Microsoft domain master running AD or are you all Linux at the core and just Windows clients?
get it to do the dynamic updates. We have our win7 and linux clients using the dhcp server. That's the server running under Linux? 12.1 server running the Samba4 AD implementation to serve both win7 and Linux clients.
Just Windows clients then ...
The server needs the fqdn of the Linux client (to do e.g. Kerberized nfs mounts). Under windows this happens automagically whether the win7 box has a dhcp address or not. Under Linux I have to either have a fixed IP or, if I want DHCP have to use the 127.0.1.1 workaround. I'm hoping your reverse lookups will solve this.
THis is where thigns are tricky, a bit beyond my experince, so I'm speculating. I do know the code I've seen has kerberos calling "krb_mk_req()" to get a ticket and that needs the FQDN as a parameter. Now the question I'm left with is this. Is the machine up and running, has it got its IP address from the DHCP server? If it has and there is a reverse lookup that gives its FQDN that will satisfy the kerberos ticket server, then fine. I'm sorry but I'm not enough of a code-monkey to be able to hunt down what I should be looking at in the low level code; is it the kerb5 libraries; is it those bits of SAMBA4? Its one of those things that its quicker to experuiment. My suggestion is to use the 'cheat' I suggested. If this is a sort-of static setup so that the MAC address of that workstation tells DHCP what IP address to hand out, then you are safe to hard code the reverse stuff in; it seems the YAST interface will allow that. Oh, and get rid of all the IPV6 stuff while you're about it.
No that's fine. The only error now is here: Mar 31 17:25:44 hh3 named[2483]: starting BIND 9.8.1-P1 -u named Info not err
Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file '/etc/bind.keys' Yes but I recall there isn't actual a key, there , is there?
Building the key and including it in DNS/DHCP was an option on those screens at the blog which you didn't take. Perhaps you should have ..
The only reason I created an empty file at /var/lib/named/dyn/managed-keys.bind was to get rid of the managed-keys file not found error when starting bind.
Yes, I got that. But that's where it expect to see they keys when its doing the DDNS stuff.
Yes, but unless it contains the crypto key shared by DHCP and DNS then DDNS won't work. This should have been generated by YAST. Its one of the options, like deleting IPv6, that you should have set. In my case, the ddns is handled elsewhere so no problem.
Yes, but it seems only for the Windows clients. With the linux clients up you should be able to do a reverse lookup for each of them. You really want to use the tools (dig, host, nslookup) to dump the whole of the in-memory forward and reverse tables - a 'zone transfer'. According to http://docstore.mik.ua/orelly/networking_2ndEd/tcp/appc_01.htm <quote> SIGINT: Causes named to dump its cache to named_dump.db. The dump file contains all of the domain information that the local name server knows. The file begins with the root servers and marks off every domain under the root that the local server knows anything about. </quote> Try that - after all the machines are 'up and runnning' and see if the forward and reverse entries are being injected. -- "How well we communicate is determined not by how well we say things but by how well we are understood." -- Andrew S. Grove. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org