[opensuse] what does 127.0.1.1 mean?
12.1 Hi We have a bind nameserver for our 192 domain. For a non static IP client I have to set the line: 127.0.1.1 hostname.domain hostname in /etc/hosts otherwise hostname -f and lots of other stuff doesn't work. 1. Why? 2. What should the file /etc/HOSTNAME contain? a. fqdn b. hostname Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 03/29/2012 01:34 PM:
12.1
Well it will depend on whether you are running systemd or sysvinit ... sort of
Hi We have a bind nameserver for our 192 domain.
And you have reverse lookup as well so that the FQDN of the machine based on its 192.whatever IP address can be determined?
For a non static IP client I have to set the line: 127.0.1.1 hostname.domain hostname in /etc/hosts
It really should be 127.0.0.1 localhost.localdomain localhost which makes me think you have an error in you DNS config. Do you have an entry in named.conf something like zone "0.0.127.in-addr.arpa" IN { type master; file "reverse/named.localdomain"; allow-update { none; }; }; :::::::::::: reverse/named.localdomain :::::::::::: $TTL 86400 @ IN SOA localhost. root.localhost. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS localhost. 1 IN PTR localhost. and a corresponding forward? zone "localdomain" IN { type master; file "master/localdomain.zone"; allow-update { none; }; }; :::::::::::::: master/localdomain.zone :::::::::::::: $TTL 86400 @ IN SOA localhost root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum IN NS localhost localhost IN A 127.0.0.1
otherwise hostname -f and lots of other stuff doesn't work.
1. Why? 2. What should the file /etc/HOSTNAME contain?
I don't use that, but perhaps you're thinking of "hostname -F ..." as in
-F, --file filename Read the host name from the specified file. Comments (lines starting with a ‘#') are ignored.
The manual says of "-f"
-f, --fqdn, --long Display the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS domain name. Unless you are using bind or NIS for host lookups you can change the FQDN and the DNS domain name (which is part of the FQDN) in the /etc/hosts file.
I'm sure that if you do a strace you'll find that the hostname command tries using DNS first. The issue is does it try "0.0.0.0" or does it try the ip address on Eth0 ? So take a look at boot scripts and see which it uses. Maybe it syslogs ....? Maybe it does a reverse lookup on /etc hosts and plonks whatever it finds into /etc/HOSTNAME. Maybe your problem is that its doing this before DHCP has assigned the 192. address and its using 127.0.0.1 instead ... perhaps because you're doing a boot in parallel and this should be a sync point. I haven't looked at how this works in systemd. I'll admit that I have a central control view of things. I've set up my DHCP/DNS so that it does it as "Oh, that's you MAC address, well on *that* subnet, this is your IP address and this is your name". None of this nonsense about the host telling the DHCP server what name it wants and what subnet it wants to be on ... Only static hosts (aka servers) have that right ... well not really, they don't use DHCP :-) If you're a visitor with an unrecognised address you get sandboxed. If you try spoofing a MAC address .... lets not talk about that, I don't want to give people ideas ... Yes, there are other ways to do it all, but this one works. -- "Conviction is worthless unless it is converted into conduct." -- Thomas Carlyle. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 29/03/12 20:43, Anton Aylward escribió:
lynn said the following on 03/29/2012 01:34 PM:
12.1
Well it will depend on whether you are running systemd or sysvinit ... sort of
systemd
And you have reverse lookup as well so that the FQDN of the machine based on its 192.whatever IP address can be determined?
No. It's straight from the box, as fas as it can be straight out of the box on openSUSE, cache only but we have added the dlz for dynamic updates.
It really should be 127.0.0.1 localhost.localdomain localhost
Setting only that does not work for, e.g. Kerberos realm lookups. In particular, krb5 nfs mounts fail if the 127.0.1.1 address is not specified.
which makes me think you have an error in you DNS config.
Everything else works fine. The dynamic updates included.
Do you have an entry in named.conf something like
We have this: 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"; listen-on-v6 { any; }; 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"; include "/etc/named.d/forwarders.conf"; tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab"; }; 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" in { type master; file "127.0.0.zone"; }; include "/usr/local/samba/private/named.conf"; Nearly the weekend:-) Cheers, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 03/30/2012 07:12 AM:
And you have reverse lookup as well so that the FQDN of the machine based on its 192.whatever IP address can be determined?
No. It's straight from the box, as fas as it can be straight out of the box on openSUSE, cache only but we have added the dlz for dynamic updates.
Sorry: please clarify. Are you saying your DNS server is 'straight out of the box'? Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner) # dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) That should give you the FQDN of your host.
It really should be 127.0.0.1 localhost.localdomain localhost
Setting only that does not work for, e.g. Kerberos realm lookups. In particular, krb5 nfs mounts fail if the 127.0.1.1 address is not specified.
Having that setting is 'out of the box'. The fact that Kerberos lookups don't work unless that is altered from the default makes me think you have an incorrect setup. As you can see below, properly set up, 127.0.0.1 *IS* there ... via DNS. And the lookup of the Kerberos server should be done by DNS, and the lookup of the NFS server(s) should be done by DNS. That's the point of having it 'centrally managed' and the distributed/replicated database that is DNS (and LDAP for that matter!) If you read the man page HOSTS(5) you;ll see it says <quote> The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. It augments or replaces the /etc/hosts file or hostname lookup, and frees a host from relying on /etc/hosts being up to date and complete. </quote> Yes there is the proviso for bootstrapping and yes you can buqqer this up by a mistake in /etc/nsswitch. Yes there is the provision for standalone. But if your machine is using /etc/hosts to do reverse lookup or to find the address of servers then either a) your DNS has failed, or b) your DNS is misconfigured. The latter could be because a) /etc/nsswitch is wrong b) information handed back by the DHCP server is wrong or inadequate c) your DNS is not set up correctly I'm skipping your named.conf. You can use nslookup, host or dig to test your DNS from this box. Before any network mount, any other stuff to do with networking, the machines needs an IP address. Its getting that either from DHCP or its hard wired. The ifconfig tool will tell you what the address is. You should be able to use the DNS lookup tools (see above) to do a reverse lookup of that IP address. It should make use of the DNS server if you have /etc/resolve set properly (either via DHCP or manually). Using the debug option will tell you how the DNS server is being interrogated. You should get something like this. It is from my redhat w/s which uses DHCP and my dns server is at .18 # dig -x 127.0.0.1 ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc15 <<>> -x 127.0.0.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5784 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 86400 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 86400 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 86400 IN A 127.0.0.1 ;; Query time: 30 msec ;; SERVER: 192.168.2.18#53(192.168.2.18) ;; WHEN: Fri Mar 30 07:49:50 2012 ;; MSG SIZE rcvd: 93 Note that this is querying the DNS server, not /etc/hosts.
which makes me think you have an error in you DNS config.
Everything else works fine. The dynamic updates included.
In some ways networking is very tolerant of minor errors and has fallbacks (that's the point of /etc/nsswitch) That your routing and DNS lets you access google and youtube and msn and facebook doesn't mean that you have *any* reverse lookup set up correctly. The fact that your /etc/hosts settings are used for reverse lookup tells me that the DNS reverse lookup isn't working or isn't being used. The latter emerges from how /etc/nsswitch is set. But a running system (aka 'after a successful boot and network start-up) with properly set up DNS etc shouldn't need /etc/hosts. OK so there are a pile of 'yes-buts' people are going to argue with on this. One I've seen is to set /etc/nsswitch to use 'files dns' for host lookup on the basis that file lookup is faster than DNS lookup. OK, but that's if and but; it says nothing about caching, it says nothing about correctness and maintenance. The point is that you *should* be able run without /etc/hosts. See the man page, as I quoted. The fact that you can't, the fact that you have to jimmy stuff in there to make it work, tells me something is wrong, and I suspect the DNS side of things. -- Think then act - There is nothing so useless as doing efficiently that which should not be done at all - Peter Drucker. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-30 14:35, Anton Aylward wrote:
Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host.
cer@Telcontar:~> dig -s $( ip addr show to 0.0.0.0/0 scope global | \
awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
Invalid option: -s Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt} {global-d-opt} host [@local-server] {local-d-opt} [ host [@local-server] {local-d-opt} [...]] Use "dig -h" (or "dig -h | more") for complete list of options - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEUEARECAAYFAk91zhMACgkQIvFNjefEBxqrUQCfQspPPHICXoSzpZDY63VsjVES tRMAkwT+vA0pkkEokAhmrOY4XG03Tug= =MRK4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 03/30/2012 11:15 AM:
On 2012-03-30 14:35, Anton Aylward wrote:
Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host. cer@Telcontar:~> dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) Invalid option: -s
Sorry, my finger slipped. s is next to x ... As the man page makes clear, reverse lookup is "-x". I'm sure everyone is smart enough ... -- We are born naked, wet and hungry. Then things get worse. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-30 19:16, Anton Aylward wrote:
Carlos E. R. said the following on 03/30/2012 11:15 AM:
Invalid option: -s
Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
When you know the idea, yes, perhaps. I didn't. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk919aEACgkQIvFNjefEBxqAagCdHudj1WpJv69fPX3QcYEKTA1D VuQAoJds4nm8v0AUnXNNKYP3/KMxItYB =bQQi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/03/12 19:16, Anton Aylward wrote:
Carlos E. R. said the following on 03/30/2012 11:15 AM:
On 2012-03-30 14:35, Anton Aylward wrote:
Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host. cer@Telcontar:~> dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) Invalid option: -s Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working. I just added the reverse zone in Yast but there seems to be a conflict between it and the samba4 dlz stuff we're running. dig -x $( ip addr show to 0.0.0.0/0 scope global | awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) berized nfs ; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56925 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;3.1.168.192.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 168.192.in-addr.arpa. 86400 IN SOA 168.192.in-addr.arpa. . 0 28800 7200 604800 86400 ;; Query time: 24 msec ;; SERVER: 192.168.1.3#53(192.168.1.3) ;; WHEN: Fri Mar 30 21:19:19 2012 ;; MSG SIZE rcvd: 77 My workaround is to add the 127.0.1.1 as. I only need it for really fussy dns stuff like Kerberos with nfs where if you so much as breathe, bind just turns away. I'm glad to see the Samba4 guys working on a modern replacement for bind. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 03/30/2012 03:28 PM:
On 30/03/12 19:16, Anton Aylward wrote:
Carlos E. R. said the following on 03/30/2012 11:15 AM:
On 2012-03-30 14:35, Anton Aylward wrote:
Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host. cer@Telcontar:~> dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) Invalid option: -s Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working.
Right
I just added the reverse zone in Yast but there seems to be a conflict between it and the samba4 dlz stuff we're running.
Could you explain what the 'conflict' is, how it manifests and a little of what's going on behind the scenes? The point I'm making here is that you need a complete and working 'spanning set'. Just parts of it working aren't going to be enough.
dig -x $( ip addr show to 0.0.0.0/0 scope global | awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) berized nfs ; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56925 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;3.1.168.192.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 168.192.in-addr.arpa. 86400 IN SOA 168.192.in-addr.arpa. . 0 28800 7200 604800 86400
;; Query time: 24 msec ;; SERVER: 192.168.1.3#53(192.168.1.3) ;; WHEN: Fri Mar 30 21:19:19 2012 ;; MSG SIZE rcvd: 77
Right. This shows the reverse for 192.168.1.3 isn't working and I'd assume from that for the whole of your 192.168.1/24 subnet. This has nothing to do with the reverse lookup of 127.0.0.1, which you might like to try as well: :-) # dig -x 127.0.0.1 I suspect that this has more to do with your problems than anything else.
My workaround is to add the 127.0.1.1 as. I only need it for really fussy dns stuff like Kerberos with nfs where if you so much as breathe, bind just turns away.
I've known many applications where there is a security check - given an IP address, do a backward lookup to get the name, then do a forward lookup to get the IP address for that name. Is the address you started out with the same as the one you ended up with? If not, something is wrong. If this is the case with the "fussy dns stuff like kerberos" then the failed reverse lookup you reported is a source of your problems.
I'm glad to see the Samba4 guys working on a modern replacement for bind.
There are number of 'replacements' - that is there are a number of other pieces of code that implement the protocol of the DNS server. BIND may have problems but these are not it. I suspect that if you used one of the alternatives to BIND you might find the configuration easier. I'm biased; I've been using BIND since 1990 so I'm used to it, but as I say, there's interaction with nsswitch and DHCP to consider. You are updating your DNS from DHCP, aren't you? If not then there's a possible source of your problems! http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/ See http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software#Feature_matri... for how crippled some of the alternatives are! The best (?) of the bunch is probably http://cr.yp.to/djbdns.html I've not used it; I find Daniels code and commentary to be confusing. On the whole I recommend the Cricket Lui book from O'Reilly. -- How come wrong numbers are never busy? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/03/12 00:21, Anton Aylward wrote:
lynn said the following on 03/30/2012 03:28 PM:
On 30/03/12 19:16, Anton Aylward wrote:
Carlos E. R. said the following on 03/30/2012 11:15 AM:
On 2012-03-30 14:35, Anton Aylward wrote:
Have you tried the reverse lookup? (Sorry this is complicated but its finding the IP address in a site independent manner)
# dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' )
That should give you the FQDN of your host. cer@Telcontar:~> dig -s $( ip addr show to 0.0.0.0/0 scope global | \ awk '/[[:space:]]inet / { print gensub("/.*","","g",$2) }' ) Invalid option: -s Sorry, my finger slipped. s is next to x ...
As the man page makes clear, reverse lookup is "-x".
I'm sure everyone is smart enough ...
Nope. Not working. Right
I just added the reverse zone in Yast but there seems to be a conflict between it and the samba4 dlz stuff we're running. Could you explain what the 'conflict' is, how it manifests and a little of what's going on behind the scenes?
The point I'm making here is that you need a complete and working 'spanning set'. Just parts of it working aren't going to be enough.
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. 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 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 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. Here is /etc/named.conf grep -v "#" /etc/named.conf 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"; listen-on-v6 { any; }; 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"; }; 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" in { type master; file "127.0.0.zone"; allow-transfer { any; }; }; include "/etc/named.conf.include"; logging { category default { log_syslog; }; channel log_syslog { syslog; }; }; zone "1.168.192.in-addr.arpa" in { allow-transfer { any; }; file "master/1.168.192.in-addr.arpa"; type master; }; include "/usr/local/samba/private/named.conf"; And here is the dig: dig -x 192.168.1.3 ; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53998 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;3.1.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 3.1.168.192.in-addr.arpa. 172800 IN PTR hh3.hh3.site. ;; AUTHORITY SECTION: 1.168.192.in-addr.arpa. 172800 IN NS hh3.hh3.site. ;; ADDITIONAL SECTION: hh3.hh3.site. 900 IN A 192.168.1.3 ;; Query time: 10 msec ;; SERVER: 192.168.1.3#53(192.168.1.3) ;; WHEN: Sat Mar 31 09:01:51 2012 ;; MSG SIZE rcvd: 98 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) /etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail) Still can't lose this error: Mar 31 08:47:46 hh3 named[9900]: couldn't add command channel ::1#953: address n ot available 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. Cheers, TIA and have a great weekend, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-03-31 09:17, lynn wrote:
Here is my reverse zone (created by Yast):
You got me curious as to how you did that. I did a DNS with YaST, created my zone, and only saw the forward files, no reverse. I created them manually with an editor. If you did it with YaST, how? :-? By the way, my method to know if the DNS entries are right is testing each address, one by one... like this: host 192.168.1.1 host 192.168.1.3
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)
You are right, I had to do that too. That's bugzilla matter, by the way ;-)
touch /var/lib/dyn/managed-keys.bind (file does not exist)
Dunno, I was not using dynamic.
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail)
I also did that, I did not know what was going wrong, so I removed the jail to have a class of issues less. Then I did not try to reinstate it back.
The Yast DNS module is not easy to use.
An understatement :-) - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk923LgACgkQIvFNjefEBxrVGACdH2pf+b7wtF8I4BoQUJeE132k 3HcAoMd3WHRXomzTLRxNRvtonbN8BJ2h =Kd8D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/03/12 12:30, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-31 09:17, lynn wrote:
Here is my reverse zone (created by Yast): You got me curious as to how you did that. I did a DNS with YaST, created my zone, and only saw the forward files, no reverse. I created them manually with an editor. If you did it with YaST, how? :-? The main problem with manually writing the zone files is that ridiculous syntax. Yast doesn't let miss a single punto: http://linuxcostablanca.blogspot.com.es/2012/03/opensuse-using-yast-to-setup...
By the way, my method to know if the DNS entries are right is testing each address, one by one... like this:
host 192.168.1.1 host 192.168.1.3
host 192.168.1.3 3.1.168.192.in-addr.arpa domain name pointer hh3.hh3.site. or dig;-)
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) You are right, I had to do that too. That's bugzilla matter, by the way ;-) bugzilla 738156 and 738258 The maintainer will not accept that this is a bug.
touch /var/lib/dyn/managed-keys.bind (file does not exist) Dunno, I was not using dynamic. Again. The bugzilla says it's fixed but it isn't.
/etc/sysconfig/named NAMED_RUN_CHROOTED="no" (It's too much hassle transferring the samba dlz stuff to the jail) I also did that, I did not know what was going wrong, so I removed the jail to have a class of issues less. Then I did not try to reinstate it back. I don't think we gain much by having it apart from more hassle. The Yast DNS module is not easy to use. An understatement :-) If you know how to write a zone file this makes it easier to get the syntax right first time. HTH L x
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 31/03/12 14:36, Anton Aylward wrote:
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. Correction: I meant _reverse_ zone of course. It is the forward zone tyat is already there. Ah. I'm glad you found that. I'm glad because I have no experience or insight into Samba*4*. It's not out of alpha yet but it's an amazing piece of kit. It helps enormously with sso on heterogeneous lans.
The server has fqdn hh3.hh3.site at 192.168.1.3
Now *that* I would put in /etc/host! OK. copy: 192.168.1.3 hh3.hh3.site hh3
Actually it should be supplied by DHCP but my experience is that many/some machines don't always honour all of
ofHere 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. Do I need a PTR for each computer on the lan? 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 get it to do the dynamic updates. We have our win7 and linux clients using the dhcp server. It works ok but coming back to the original point, we have to put 127.0.1.1 in /etc/hosts on the client to get a name over to the server. 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 IPv6 stuff come straight out of a default openSUSE bind install. I don't want it. It just gets put here.
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. Yes. Infact if the whole of /var/lib/named is not writeable by named, named will not start. the maintainers will not change this however. Pls see the other post for details of the bugzillas.
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 :-) Yes it does. Again, it is default openSUSE.
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 ....
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 Mar 31 17:25:44 hh3 named[2483]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--includedir=/usr/include/bind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-openssl' '--enable-threads' '--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql' '--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing' 'LDFLAGS=-L/usr/lib' Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096 to 1048576 Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets Mar 31 17:25:44 hh3 named[2483]: loading configuration from '/etc/named.conf' Mar 31 17:25:44 hh3 named[2483]: reading built-in trusted keys from file '/etc/bind.keys' Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv4 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv6 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1, 192.168.1.3#53 Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone 'hh3.site' Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone '_msdcs.hh3.site' Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty 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.0.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953 Mar 31 17:25:47 hh3 named[2483]: couldn't add command channel ::1#953: address not available Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2012033101 Mar 31 17:25:47 hh3 named[2483]: 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/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0 Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done Mar 31 17:25:47 hh3 named[2483]: running This is after changing ownership of /var/lib/named and after creating he managed-keys.bind file. Without those changes, bind will not start.
}; 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.
the ip6.arpa one no?
in { type master; file "127.0.0.zone"; allow-transfer { any; }; Why?
This is what the default install did.
}; include "/etc/named.conf.include";
Again, an 'include' may alter things dramatically!
Default again. named.conf.include is empty.
logging { category default { log_syslog; }; channel log_syslog { syslog; };
Default openSUSE.
}; zone "1.168.192.in-addr.arpa" in { allow-transfer { any; }; Why? This is for reverse lookup. This is what I added. Without it, reverse lookup does not work. file "master/1.168.192.in-addr.arpa"; type master; }; Reverse lookup added by myself. the samba 4 dlz stuff. include "/usr/local/samba/private/named.conf"; Again, an 'include' may alter things dramatically! This is working OK. It's he samba4 dlz stuff
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. Unless that file exists, it throws an error. /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". Yes. The samba include file must be readable. In the chroot it can't be read. I can't find a way of making it work in the chroot without including most of the samba stuff in there too.
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
Will do. Meanwhile, one important one. I need to add a PTR for each machine on the lan? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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'.
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'.
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?
It works ok but coming back to the original point, we have to put 127.0.1.1 in /etc/hosts on the client to get a name over to the server.
What is the server in need of? The FQDN? The FQDN should come from the unique IP address of the client. That's why I keep talking about the reverse DNS. I assume we're still talking about something that DHCP-driven? Either the name is hard-coded or its supplied by the DHCP server and the DHCP server tells the DNS server (via the DDNS protocol) to create the forward and reverse records. I _suspect_ that because there is no reverse record it falls back to 127.0.0.1 and that's what your faced with. I've not used kerberos in this context; my last venture using it was with AIX/SPSS ....
The IPv6 stuff come straight out of a default openSUSE bind install. I don't want it. It just gets put here.
NASTY! In the screens you show at the bloc ... opensuse-using-yast-to-setup-dns.html there is the option to delete the IPV6 entry and the option to enable DDNS
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 :-)
Yes it does. Again, it is default openSUSE.
I think its up to you to delete what isn't wanted and to enable what is wanted.
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]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--includedir=/usr/include/bind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-openssl' '--enable-threads' '--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql' '--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing' 'LDFLAGS=-L/usr/lib'
Info not err
Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096 to 1048576 Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets Mar 31 17:25:44 hh3 named[2483]: loading configuration from '/etc/named.conf'
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 ..
Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv4 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv6 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1, 192.168.1.3#53
Info not err
Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone 'hh3.site' Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone '_msdcs.hh3.site' Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA
That doesn't matter, its all info not err
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty 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.0.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
You really should disable IPv6 if you're not using it.
Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953
Info, but its the local IP address that counts :-
Mar 31 17:25:47 hh3 named[2483]: couldn't add command channel ::1#953: address not available
More IPv6 stuff you can do without.
Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2012033101 Mar 31 17:25:47 hh3 named[2483]: 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/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0 Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done Mar 31 17:25:47 hh3 named[2483]: running
This is after changing ownership of /var/lib/named and after creating he managed-keys.bind file. Without those changes, bind will not start.
The managed keys file isn't something you create by using 'touch'; it should contain the crypto keys you are using.
Again, an 'include' may alter things dramatically!
Default again. named.conf.include is empty.
OK .....
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.
Unless that file exists, it throws an error.
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.
/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".
Yes. The samba include file must be readable. In the chroot it can't be read. I can't find a way of making it work in the chroot without including most of the samba stuff in there too.
Yes, that's the point of chroot...
Meanwhile, one important one. I need to add a PTR for each machine on the lan?
Yes. As I said in a previous post; you can either use DDNS to let DHCP add and remove or you can 'cheat' and have them in there to match the same range as DHCP is going to hand out. The latter lets you micromanage the names. -- Insanity is hereditary. You get it from your kids. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
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.
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.
It works ok but coming back to the original point, we have to put 127.0.1.1 in /etc/hosts on the client to get a name over to the server. What is the server in need of? The FQDN? The FQDN should come from the unique IP address of the client. That's why I keep talking about the reverse DNS.
I assume we're still talking about something that DHCP-driven?
Either the name is hard-coded or its supplied by the DHCP server and the DHCP server tells the DNS server (via the DDNS protocol) to create the forward and reverse records.
I _suspect_ that because there is no reverse record it falls back to 127.0.0.1 and that's what your faced with. I've not used kerberos in this context; my last venture using it was with AIX/SPSS .... 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.
The IPv6 stuff come straight out of a default openSUSE bind install. I don't want it. It just gets put here. NASTY!
In the screens you show at the bloc ... opensuse-using-yast-to-setup-dns.html there is the option to delete the IPV6 entry and the option to enable DDNS Yes. I'll do the delete. That sould get rid of it. As I say, we already have ddns handled outside the Yast configuration with an externally generated tsig key so I would only use that option if I had created the forward zone myself. As it is, the forward zone is created for me by the Samba4 server.
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 :-) Yes it does. Again, it is default openSUSE. I think its up to you to delete what isn't wanted and to enable what is wanted. Point taken. I should not blame the tools, rather he bad workman. My fault.
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]: built with '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--localstatedir=/var' '--libdir=/usr/lib' '--includedir=/usr/include/bind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-openssl' '--enable-threads' '--with-libtool' '--enable-runidn' '--with-libxml2' '--with-dlz-mysql' '--with-dlz-ldap' 'CFLAGS=-fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNO_VERSION_DATE -fno-strict-aliasing' 'LDFLAGS=-L/usr/lib' Info not err
Mar 31 17:25:44 hh3 named[2483]: adjusted limit on open files from 4096 to 1048576 Mar 31 17:25:44 hh3 named[2483]: found 1 CPU, using 1 worker thread Mar 31 17:25:44 hh3 named[2483]: using up to 4096 sockets Mar 31 17:25:44 hh3 named[2483]: loading configuration from '/etc/named.conf' 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.
Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv4 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: using default UDP/IPv6 port range: [1024, 65535] Mar 31 17:25:44 hh3 named[2483]: listening on IPv6 interfaces, port 53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 31 17:25:44 hh3 named[2483]: listening on IPv4 interface eth1, 192.168.1.3#53 Info not err
Mar 31 17:25:44 hh3 named[2483]: generating session key for dynamic DNS Mar 31 17:25:44 hh3 named[2483]: sizing zone task pool based on 5 zones Mar 31 17:25:44 hh3 named[2483]: Loading 'AD DNS Zone' using driver dlopen Mar 31 17:25:47 hh3 named[2483]: samba_dlz: started for DN DC=hh3,DC=site Mar 31 17:25:47 hh3 named[2483]: samba_dlz: starting configure Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone 'hh3.site' Mar 31 17:25:47 hh3 named[2483]: samba_dlz: configured writeable zone '_msdcs.hh3.site' Mar 31 17:25:47 hh3 named[2483]: set up managed keys zone for view _default, file '/var/lib/named/dyn//managed-keys.bind' Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 10.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 16.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 17.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 18.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 19.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 20.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 21.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 22.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 23.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 24.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 25.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 26.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 27.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 28.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 29.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 30.172.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 31.172.IN-ADDR.ARPA That doesn't matter, its all info not err
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 168.192.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 0.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 127.IN-ADDR.ARPA
Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 254.169.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty 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.0.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: D.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 9.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: A.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: B.E.F.IP6.ARPA Mar 31 17:25:47 hh3 named[2483]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA You really should disable IPv6 if you're not using it.
Will do.
Mar 31 17:25:47 hh3 named[2483]: command channel listening on 127.0.0.1#953 Info, but its the local IP address that counts :-
Mar 31 17:25:47 hh3 named[2483]: couldn't add command channel ::1#953: address not available More IPv6 stuff you can do without.
Mar 31 17:25:47 hh3 named[2483]: zone 0.0.127.in-addr.arpa/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone 1.168.192.in-addr.arpa/IN: loaded serial 2012033101 Mar 31 17:25:47 hh3 named[2483]: 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/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: zone localhost/IN: loaded serial 42 Mar 31 17:25:47 hh3 named[2483]: managed-keys-zone ./IN: loaded serial 0 Mar 31 17:25:47 hh3 named[2450]: Starting name server BIND ..done Mar 31 17:25:47 hh3 named[2483]: running
This is after changing ownership of /var/lib/named and after creating he managed-keys.bind file. Without those changes, bind will not start. The managed keys file isn't something you create by using 'touch'; it should contain the crypto keys you are using.
Again, an 'include' may alter things dramatically! Default again. named.conf.include is empty. OK .....
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.
Unless that file exists, it throws an error. 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.
/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". Yes. The samba include file must be readable. In the chroot it can't be read. I can't find a way of making it work in the chroot without including most of the samba stuff in there too. Yes, that's the point of chroot...
Meanwhile, one important one. I need to add a PTR for each machine on the lan? Yes.
As I said in a previous post; you can either use DDNS to let DHCP add and remove or you can 'cheat' and have them in there to match the same range as DHCP is going to hand out. The latter lets you micromanage the names.
Big thanks again from all here at lcb. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
El 31/03/12 20:57, Anton Aylward escribió:
lynn said the following on 03/31/2012 01:54 PM:
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 ....
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?
Yes. Using Samba4 to which we have added the rfc2307 attributes by including the posixGroup and posixAccount objects which are defined in the AD LDAP schema. The very schema that m$ were forced to make public after the European Court found in favour of The Samba Team last year. Good ol' Tridge:-) 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 ...
No. Linux and Windows clients. It is a heterogeneous lan. <snip> Will get back to the rest 2moro. Thanks for your time. I'm learning a lot. BFN L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/03/12 20:57, Anton Aylward escribió:
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? If you had ddns working then it would be done 'auto-magically'.
Yes. I have ddns working. The forward zone is updated by Samba4 when new machines are allocated IP's, join the domain etc. I just didn't have a reverse lookup zone. 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.
I think that is what is happening because you can see the KDC receive requests from IP's which have been allocated via DHCP _and_ correctly lookup their Kerberos machine$/fqdn key correctly for authentication.
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?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
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 ...
No. Our lan consists of Linux and windows with a 12.1 server. Mainly 12.1 and win7 with some Ubuntu and xp clients to keep the punters happy.
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.
Kerberos needs not only to authenticate the user but also the machines on the lan. When I logon, both I and my computer have to authenticate. If I request a file then both I and the fileserver have to authenticate. This is why the dns is crucial with Kerberos.
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?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it? If it has and there is
a reverse lookup that gives its FQDN that will satisfy the kerberos ticket server, then fine.
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.
Will do.
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?
No. Just an empty file to get rid of he error message about the file not found.
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 ..
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.
How come the windows clients work OK. What do they have that we don't?
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.
Nearer to undestanding. Thanks again. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-01 09:06, lynn wrote:
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
Interesting...
Kerberos needs not only to authenticate the user but also the machines on the lan. When I logon, both I and my computer have to authenticate. If I request a file then both I and the fileserver have to authenticate. This is why the dns is crucial with Kerberos.
I see... I underwent a period of training, mostly with W2K8 R2. These servers had their corresponding DNS, but not DHCP because you can imagine the havoc 14 DHCP servers can make in the same LAN :-) But clients did authenticate to the domains. What I did not make sure is if the DNS could always track the clients. I think that when someone logged in, the machine was counted in the DNS. This can not be replicated with bind, AFAIK, and is perhaps the reason that the samba folks think of another dns daemon.
Nearer to undestanding. Thanks again. L x
Try to trim your messages, removing the old stuff from previous messages. Yours are very long and more difficult to read because you don't. It also needs learning, but please do :-) - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk94K7MACgkQIvFNjefEBxrXRgCg2h4V6c0+wmRUA+OJVid57yt7 3vIAn3POL3p4yeqmHGUECp6nWBfHjuIc =qMSW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/12 12:19, Carlos E. R. wrote:
On 2012-04-01 09:06, lynn wrote:
Interesting...
The Samba team needs greater recognition for the services they make to open source. Linux is on the verge of being able to replace m$ servers by running AD DNS itself.
But clients did authenticate to the domains.
What I did not make sure is if the DNS could always track the clients. I think that when someone logged in, the machine was counted in the DNS. This can not be replicated with bind, AFAIK, and is perhaps the reason that the samba folks think of another dns daemon.
Yes it can and is replicated in bind. The Samba team sent patches to bind which enabled it to do so. They are included as of bind9.8. We have the dlz patches working fine. win 7 clients use bind as their DNS and Samba4 as their AD, all under openSUSE. One of the points of this thread is to enable our Linux clients which are on the same lan, work as the windows clients do and get rid of that awful 127.0.1.1
Nearer to undestanding. Thanks again. L x
Try to trim your messages,
I read the messages in tb, not in an archive so I forget to trim but will do. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2012-04-01 at 14:53 +0200, lynn wrote:
their AD, all under openSUSE. One of the points of this thread is to enable our Linux clients which are on the same lan, work as the windows clients do and get rid of that awful 127.0.1.1
But "127.0.1.1" is your own localhost. The entire 127 network is your localhost, always, not another machine. Tri pinging, it works. - -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAk94vBQACgkQtTMYHG2NR9WYCQCgjvrmbTyv0slz62U1hgfii6G3 oL4AnizrivAX3v2pGS4NRmpwFsanjxV5 =ccly -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 01/04/12 22:35, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
But "127.0.1.1" is your own localhost. The entire 127 network is your localhost, always, not another machine. Tri pinging, it works.
I have three entries in /etc/hosts on each Linux client: 127.0.0.1 localhost 127.0.1.1 host.domain host 192.168.1.3 server.domain server with /etc/HOSTNAME containing host only Without the 127.0.1.1, hostname -f does not work and not much else does either. Without the 127.0.1.1, domain logons work but this is useless because Kerberized nfs doesn't and the user ends up without her files and nfs mounted windows shares. The automounter and rpc.gssd throw a fit if that value is not present. An alternative is to give the clients a fixed IP and use that instead of the 127.0.1.1. But if the windows clients can use dhcp, why can't our openSUSE clients use it from the same server? Windows clients have something that we do not. What is it? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/01/2012 04:53 PM:
Windows clients have something that we do not. What is it?
What are the names of the Windows hosts? How does DNS respond when queried on their addresses? How are those names assigned? Ditto for the Linux hosts. How are names assigned? As far as DHCP goes, either machines "know" their names and use that when asking for an IP address from the DHCP server, or they are given there names by the server, along with router, gateway, and all the other information that they should if you have DHCP set up properly. If you read the man page for the DHCP client (dhcpcd(8) you will find <quote> If the hostname is currenly blank, (null) or localhost then dhcpcd will set the hostname to the one supplied by the DHCP server, or look it up in DNS if none supplied. </quote> and <quote> -h, --hostname hostname By default, dhcpcd will send the current hostname to the DHCP server so it can register in DNS. You can use this option to specify the hostname sent, or an empty string to stop any hostname from being sent. </quote> So: unless you are forcing a name from the client, it is supplied buy the DHCP server ... EITHER The DHCP server hands out names along with ip addresses OR The DHCP server can query the DNS server for a name to go along with the IP address. This requires a pre-defined RR for the reverse lookup. You may care to look at the settings in /etc/sysconfig/network/dhcp and read the comments there. -- An NSA-employed acquaintance, when asked whether the government can crack DES traffic, quipped that real systems are so insecure that they never need to bother. Unfortunately, there are no easy recipes for making a system secure, no substitute for careful design and critical, ongoing scrutiny. -- Matt Blaze in AC2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/04/12 23:53, Anton Aylward wrote:
lynn said the following on 04/01/2012 04:53 PM:
Windows clients have something that we do not. What is it?
What are the names of the Windows hosts?
How does DNS respond when queried on their addresses? How are those names assigned?
Here is a win 7 client called LYNN-PC12@hh3.site. It has its address to be obtained automatically and has 192.168.1.2 hh1.hh3.site set as the only nameserver. Here is the request for the machine ticket. There must have been some communication betwen the DHCP server at 192.16.1.1, LYNN-PC12 and the KDC. LYNN-PC12 was allocated IP 192.168.1.27 but next boot, it will be different. Kerberos: AS-REQ LYNN-PC12$@HH3.SITE from ipv4:192.168.1.27:59048 for krbtgt/HH3.SITE@HH3.SITE Kerberos: Client sent patypes: encrypted-timestamp, 128 Kerberos: Looking for PKINIT pa-data -- LYNN-PC12$@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- LYNN-PC12$@HH3.SITE Kerberos: ENC-TS Pre-authentication succeeded -- LYNN-PC12$@HH3.SITE using arcfour-hmac-md5 Kerberos: AS-REQ authtime: 2012-04-02T09:31:37 starttime: unset endtime: 2012-04-02T19:31:37 renew till: 2012-04-09T09:31:37 And here is the domain admin logging into the domain. here she requests a cifs ticket: Kerberos: TGS-REQ Administrator@HH3.SITE from ipv4:192.168.1.27:59064 for cifs/hh1.hh3.site@HH3.SITE [canonicalize, renewable, forwardable] Kerberos: TGS-REQ authtime: 2012-04-02T09:41:49 starttime: 2012-04-02T09:41:59 endtime: 2012-04-02T19:41:49 renew till: 2012-04-09T09:41:49 host LYNN-PC12 LYNN-PC12.hh3.site has address 192.168.1.27 host 192.168.1.27 Host 27.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN) ping 192.168.1.27 PING 192.168.1.27 (192.168.1.27) 56(84) bytes of data. 64 bytes from 192.168.1.27: icmp_seq=1 ttl=128 time=7.30 ms
Ditto for the Linux hosts. How are names assigned?
Here is an openSUSE 12.1 client called LXDE2.hh3.site. Here, the same DHCP server has allocated 192.168.1.22 The machine ticket request: Kerberos: AS-REQ LXDE2$@HH3.SITE from ipv4:192.168.1.22:41947 for krbtgt/HH3.SITE@HH3.SITE Kerberos: Client sent patypes: encrypted-timestamp, 149 Kerberos: Looking for PKINIT pa-data -- LXDE2$@HH3.SITE Kerberos: Looking for ENC-TS pa-data -- LXDE2$@HH3.SITE Kerberos: ENC-TS Pre-authentication succeeded -- LXDE2$@HH3.SITE using arcfour-hmac-md5 Kerberos: AS-REQ authtime: 2012-04-02T09:53:14 starttime: unset endtime: 2012-04-02T19:53:14 renew till: 2012-04-03T09:53:12 A user request for her /home folder nfs upon login: Kerberos: TGS-REQ LXDE2$@HH3.SITE from ipv4:192.168.1.22:57654 for nfs/hh1.hh3.site@HH3.SITE [canonicalize, renewable] Kerberos: TGS-REQ authtime: 2012-04-02T09:53:14 starttime: 2012-04-02T09:53:14 endtime: 2012-04-02T19:53:14 renew till: 2012-04-03T09:53:12 Kerberos: TGS-REQ steve2@HH3.SITE from ipv4:192.168.1.22:48518 for nfs/hh1.hh3.site@HH3.SITE [canonicalize, renewable, forwardable] All OK so far. Now here is where the windows and linux clients differ: host LXDE2 Host LXDE2 not found: 3(NXDOMAIN) host lxde2.hh3.site Host lxde2.hh3.site not found: 3(NXDOMAIN) host lxde2 Host lxde2 not found: 3(NXDOMAIN) host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN) ping 192.168.1.22 PING 192.168.1.22 (192.168.1.22) 56(84) bytes of data. 64 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=0.724 ms
As far as DHCP goes, either machines "know" their names and use that when asking for an IP address from the DHCP server, or they are given there names by the server, along with router, gateway, and all the other information that they should if you have DHCP set up properly.
In this setup, the machine names are fixed. The DHCP is set to allocate addreses only.
If you read the man page for the DHCP client (dhcpcd(8) you will find
<quote> If the hostname is currenly blank, (null) or localhost then dhcpcd will set the hostname to the one supplied by the DHCP server, or look it up in DNS if none supplied. </quote> and <quote> -h, --hostname hostname By default, dhcpcd will send the current hostname to the DHCP server so it can register in DNS. You can use this option to specify the hostname sent, or an empty string to stop any hostname from being sent. </quote>
So: unless you are forcing a name from the client, it is supplied buy the DHCP server ... We are forcing the client name. The DHCP server does not allocate a name. EITHER The DHCP server hands out names along with ip addresses OR The DHCP server can query the DNS server for a name to go along with the IP address. This requires a pre-defined RR for the reverse lookup.
You may care to look at the settings in /etc/sysconfig/network/dhcp and read the comments there.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-02 10:13, lynn wrote:
All OK so far. Now here is where the windows and linux clients differ:
host LXDE2 Host LXDE2 not found: 3(NXDOMAIN)
host lxde2.hh3.site Host lxde2.hh3.site not found: 3(NXDOMAIN)
host lxde2 Host lxde2 not found: 3(NXDOMAIN)
You don't have an appropriate search domain. /etc/resolv.conf: search hh3.site nameserver 192.so.me.thing Every linux machine should have that. I don't know if the dhcp server can assign it.
host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
If reverse assignation from the dhcp server does not happen, you can set fixed arbitrary names, like 168.1.22.hh3.site - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk95buIACgkQIvFNjefEBxpCPwCeLD2PTOzjyP4tEQTMcRzxWaN6 zzgAn2sLn8eN4hahqbFHxum3q/WLOv5z =L1vz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
All OK so far. Now here is where the windows and linux clients differ:
host LXDE2 Host LXDE2 not found: 3(NXDOMAIN)
host lxde2.hh3.site Host lxde2.hh3.site not found: 3(NXDOMAIN)
host lxde2 Host lxde2 not found: 3(NXDOMAIN)
You don't have an appropriate search domain.
/etc/resolv.conf: search hh3.site nameserver 192.so.me.thing
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
If reverse assignation from the dhcp server does not happen, you can set fixed arbitrary names, like 168.1.22.hh3.site
I've suggested that (and other) "Cheats". -- The greatest obstacle to discovery is not ignorance - it is the illusion of knowledge -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
I don't want just any name. I want the name that I give to the computer. Not one which the dhcp server suggests. Oterwise the computer changes name each time it is booted. That's useless to me. Surely that's why there is an option to have the dhcp server dish out addresses only.
host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
If reverse assignation from the dhcp server does not happen, you can set fixed arbitrary names, like 168.1.22.hh3.site
I've suggested that (and other) "Cheats".
OK. So why does it happen for windoes clients and not for us? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/02/2012 12:26 PM:
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
I don't want just any name. I want the name that I give to the computer.
Yes I can understand that. By my assertions still hold. The DHCP server should be handing out more than just IP addresses. Have you read /etc/sysconfig/network/dhcp? I asked for the result of running "ps -ef | grep dhcpcd" on the client after its up and running. *IF* and *ONLY IF* you have things set up properly then the naming of the computers will be consistent. That has nothing to do with the other stuff DHCP *should* be handing out and *does not* require the additional line in /etc/hosts you keep mentioning.
Not one which the dhcp server suggests. Oterwise the computer changes name each time it is booted. That's useless to me. Surely that's why there is an option to have the dhcp server dish out addresses only.
If you read the man page, if you read /etc/sysconfig/network/dhcp you'd understand what I'm talking about. Its an EITHER/OR Either the machine tells the DHCP server its name 0- which is the way I have things set up on my system and use host MainBox { fixed-address 192.168.2.14 ; option domain-name-servers 192.168.2.18, 192.168.2.1, 8.8.8.8 ; } host BigBoy { ... } host SmallServer { .... } host laptopacer { ... } host laptophp { ... } host trixbox0 { ... } And then there's a catch-all for other 'unnamed' hosts. As you can see, I can control the IP that goes with a specific name if I want to, I can control the routing and nameserver that a specific host is given. You *should* have defaults in your server:/etc/dhcp.conf to ensure that the values you want are supplied, *along with the IP address*. The IP address should *not* be the *only* thing supplied.
host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
If reverse assignation from the dhcp server does not happen, you can set fixed arbitrary names, like 168.1.22.hh3.site
I've suggested that (and other) "Cheats".
OK. So why does it happen for windoes clients and not for us?
To answer that I'd have to probe a lot more and look at stuff I've asked for but you haven't forwarded. -- HTML has followed nature's example... bright, sometimes flashing, colors are a sign of indigestiblility. -- Rob Hartill -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/04/12 20:21, Anton Aylward wrote:
lynn said the following on 04/02/2012 12:26 PM:
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
I don't want just any name. I want the name that I give to the computer.
Yes I can understand that. By my assertions still hold. The DHCP server should be handing out more than just IP addresses.
Have you read /etc/sysconfig/network/dhcp? DHCLIENT_BIN=""
DHCLIENT6_BIN=""
DHCPCD_USER_OPTIONS=""
DHCLIENT_USER_OPTIONS=""
DHCP6C_USER_OPTIONS=""
DHCLIENT_DEBUG="no"
DHCLIENT_PRIMARY_DEVICE=""
DHCLIENT_SET_HOSTNAME="no"
DHCLIENT_SET_DEFAULT_ROUTE="no"
DHCLIENT_LEASE_TIME=""
DHCLIENT_USE_LAST_LEASE="yes"
DHCLIENT_TIMEOUT="0"
DHCLIENT_HOSTNAME_OPTION=""
DHCLIENT_CLIENT_ID=""
DHCLIENT_VENDOR_CLASS_ID=""
DHCLIENT_RELEASE_BEFORE_QUIT="no"
DHCLIENT6_RELEASE_BEFORE_QUIT="no"
DHCLIENT_SLEEP="0"
DHCLIENT_WAIT_AT_BOOT="15"
WRITE_HOSTNAME_TO_HOSTS="no" DHCLIENT_MODIFY_SMB_CONF="yes"
Maybe WRITE_HOSTNAME_TO_HOSTS="yes" ?
I asked for the result of running "ps -ef | grep dhcpcd" on the client after its up and running.
ps -ef | grep dhcpcd root 2108 1 0 08:21 ? 00:00:00 /sbin/dhcpcd --netconfig -L -E -G -c /etc/sysconfig/network/scripts/dhcpcd-hook -t 0 eth0
Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/03/2012 02:29 AM:
On 02/04/12 20:21, Anton Aylward wrote:
lynn said the following on 04/02/2012 12:26 PM:
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
I don't want just any name. I want the name that I give to the computer.
Yes I can understand that. By my assertions still hold. The DHCP server should be handing out more than just IP addresses.
Have you read /etc/sysconfig/network/dhcp? DHCLIENT_BIN=""
DHCLIENT6_BIN=""
DHCPCD_USER_OPTIONS=""
DHCLIENT_USER_OPTIONS=""
DHCP6C_USER_OPTIONS=""
DHCLIENT_DEBUG="no"
DHCLIENT_PRIMARY_DEVICE=""
DHCLIENT_SET_HOSTNAME="no"
DHCLIENT_SET_DEFAULT_ROUTE="no"
DHCLIENT_LEASE_TIME=""
DHCLIENT_USE_LAST_LEASE="yes"
DHCLIENT_TIMEOUT="0"
DHCLIENT_HOSTNAME_OPTION=""
DHCLIENT_CLIENT_ID=""
DHCLIENT_VENDOR_CLASS_ID=""
DHCLIENT_RELEASE_BEFORE_QUIT="no"
DHCLIENT6_RELEASE_BEFORE_QUIT="no"
DHCLIENT_SLEEP="0"
DHCLIENT_WAIT_AT_BOOT="15"
WRITE_HOSTNAME_TO_HOSTS="no" DHCLIENT_MODIFY_SMB_CONF="yes"
Maybe WRITE_HOSTNAME_TO_HOSTS="yes" ?
I asked for the result of running "ps -ef | grep dhcpcd" on the client after its up and running.
ps -ef | grep dhcpcd root 2108 1 0 08:21 ? 00:00:00 /sbin/dhcpcd --netconfig -L -E -G -c /etc/sysconfig/network/scripts/dhcpcd-hook -t 0 eth0
Well, there's one problem. You DHCP isn't doing what you thought it was doing. Check you MAN page for DHCPCD. There is the "-f" parameter in which the client tells the server what name it wants to use. You have said you want the clients determining their won names, not having one forced on them by the DHCP server. However that is *NOT* how you have it set up. The WRITE_HOSTNAME_TO_HOSTS="yes" means that host name supplied by the DHCP server gets written to the clients /etc/host file. Based on what you told us in previous emails that is *NOT what you want. The So what does that DHCPCD parameter set mean? Dis this what you really want? -t 0 <quote> -t, --timeout seconds Timeout after seconds, instead of the default 20. A setting of 0 seconds causes dhcpcd to wait forever to get a lease. </quote> That is your
DHCLIENT_TIMEOUT="0" setting. Do you want to 'wait forever"?
-G <quote> -G, --nogateway Don't set any default routes. </quote> That is your
DHCLIENT_SET_DEFAULT_ROUTE="no" setting. That must mean your network has no connectivity to any other network.
-L <quote> -L, --noipv4ll Don't use IPv4LL at all. </quote> See http://en.wikipedia.org/wiki/Link-local_address This suppresses the use of the Link-local route - (165.254.0.0/16) and repeated retries if the server isn't responding. See "-t 0" Is this what you want? Do you understand why you should or should not want this fall-back mode? My best guess is that your problems arise because of naming and identification issues doe to an incomplete configuration. The default of dhcpcd is to send the host name to the DHCP server but you have
DHCLIENT_SET_HOSTNAME="no" and there is no "-h hostname". In my /etc/dhcp.conf I have hostnames, as I mentioned in a previous post, and the stanzas determine specific characteristics for those hosts; this I can set specific routers, name severs, lease times and whatever.
You have said that you want the hosts to always have the same names. There are basically two ways to do that. 1) they know their names and they tell the DHCP server In this case the DHCP server should also be able to use the DDNS protocol -- if you have that set up, and the evidence is that you don't - to tell the DNS server to dynamically insert forward and reverse RRs into its in-memory DNS map. *NOT* the on-disk file. 2) the dhcp server is configured in terms of names and maps MAC addresses to names because the stanzas are written that way. Those same stanzas can arrange that a particular MAC address is always assigned the same IP address (BTDT)and so you can set up static (aka on disk files) DNS tables. This is what I refer to as a "cheat". DHCP makes sense when you have a large number of possible clients but only a few connected at a particular time and so need to re-assign IP addresses. It worked great when I was running a dial-up ISP :-) But on a lot of LANs its not used like that. The number of clients is fixed and does not exceed what's available on the RFC1918 subnet (192.168.1/24 in your case). In this situation the fixed binding of MAC address to IP address and the stanza having the name of the host is fine. It simplifies debugging and set up of DNS. Example: host trixbox0 { hardware ethernet 00:60:B0:F7:1B:3C ; fixed-address 192.159.2.10 ; } If you are not willing to adopt that approach, then I would at least set
DHCLIENT_SET_HOSTNAME="yes" so the client *does* tell the DHCP server its name and there is no ambiguity about that.
As for
DHCLIENT_MODIFY_SMB_CONF="yes" I'm sorry, I have no idea what that is doing.
This is back to network sniffing .... -- "Television is a medium because it is neither rare nor well done." -- Fred Friendly -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 03/04/12 14:42, Anton Aylward escribió:
lynn said the following on 04/03/2012 02:29 AM:
On 02/04/12 20:21, Anton Aylward wrote:
lynn said the following on 04/02/2012 12:26 PM:
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM:
On 2012-04-02 10:13, lynn wrote:
Every linux machine should have that. I don't know if the dhcp server can assign it.
Yes it can; yes it should. But lynn says that here DHCP server is only handing out IP addresses, therefore she has not configured it correctly.
I don't want just any name. I want the name that I give to the computer.
Yes I can understand that. By my assertions still hold. The DHCP server should be handing out more than just IP addresses.
Have you read /etc/sysconfig/network/dhcp? DHCLIENT_BIN=""
Hi Anton, you are wonderful. Let's not forget that I only need the 127.0.1.1 for nfs3 or 4 via Kerberos. This is specific to the stringent DNS requirements of rpc.gssd. Conventional nfs mounts fine without knowing the fqdn of the client. There is light emerging at the other side of the tunnel: https://lists.samba.org/archive/samba/2012-April/166821.html Our English may not be as good there as it is here;-) Meanwhile longing to add [solved] to this one. Thanks so much for your dedicated help. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 03/04/12 18:03, lynn escribió:
El 03/04/12 14:42, Anton Aylward escribió:
lynn said the following on 04/03/2012 02:29 AM:
On 02/04/12 20:21, Anton Aylward wrote:
lynn said the following on 04/02/2012 12:26 PM:
El 02/04/12 14:29, Anton Aylward escribió:
Carlos E. R. said the following on 04/02/2012 05:18 AM: > On 2012-04-02 10:13, lynn wrote:
From: https://lists.samba.org/archive/samba/2012-April/166830.html <quote> if your DHCP client is able to do GSS-TSIG updates against windows, </quote> Is our DHCP client able to do that? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn said the following on 04/03/2012 12:10 PM:
From: https://lists.samba.org/archive/samba/2012-April/166830.html
<quote> if your DHCP client is able to do GSS-TSIG updates against windows, </quote>
Is our DHCP client able to do that? L x
Let have the full quote: <quote> If your DHCP client is able to do GSS-TSIG updates against windows, it should be able to do the same against Samba4. If the DHCP client can't update, you'll have to figure out how to fix the client side of things. <quote> Lynn, this is all well documented in the various references I have provided and can be tested with nsupdate. Start from the inside out. 1. Can you dynamically update DNS with forward and reverse (manually, cli using nsupdate) ? If not, then you have a problem with DDNS against BIND. Find out what that is and fix it 2. Is the crypto key shared between DHCP and BIND? This should be the same key used in (1) 3. Is DHCP set up to use DDNS against BIND for the relevant subnet? Again, consult the URLs for parameters to DHCP that I included in earlier mails -- I wonder why. I wonder why. I wonder why I wonder. I wonder why I wonder why I wonder why I wonder! -- Richard Feynman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 03/04/12 19:18, Anton Aylward escribió:
Lynn said the following on 04/03/2012 12:10 PM:
From: https://lists.samba.org/archive/samba/2012-April/166830.html
<quote> if your DHCP client is able to do GSS-TSIG updates against windows, </quote>
Is our DHCP client able to do that? L x
Let have the full quote:
<quote> If your DHCP client is able to do GSS-TSIG updates against windows, it should be able to do the same against Samba4. If the DHCP client can't update, you'll have to figure out how to fix the client side of things. <quote>
Lynn, this is all well documented in the various references I have provided and can be tested with nsupdate.
Start from the inside out.
1. Can you dynamically update DNS with forward and reverse (manually, cli using nsupdate) ?
My DNS entries are stored in Active directory. nsupdate knows nothing about them. samba_dnsupdate does and can be used at the cli to update them if you want but is normally unnecessary. The updates occur as and when needed by the software.
If not, then you have a problem with DDNS against BIND. Find out what that is and fix it
2. Is the crypto key shared between DHCP and BIND? This should be the same key used in (1)
The key is only known to AD. As far as I know, bind cannot see the entries stored in AD.
3., Is DHCP set up to use DDNS against BIND for the relevant subnet? Again, consult the URLs for parameters to DHCP that I included in earlier mails
The only way I know to create the reverse entry in AD without a 2008 server is as follows (samba thread again): To create a reverse zone for 192.168.1.0/24 subnet, $ samba-tool dns zonecreate <server> 1.168.192.in-addr.arpa And then you can add record (e.g. test1.my.domain -> 192.168.1.1) $ samba-tool dns add <server> 1.168.192.in-addr.arpa 1 PTR test1.my.domain This method gives me reverse lookups fr static IP's. Now I need to be able to translate this into dynamic IP's Not very good answers but I think it points to conventional methods being of no use when dealing with dynamically loaded zones in AD. But don't let's give up! L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn said the following on 04/03/2012 03:20 PM:
My DNS entries are stored in Active directory.
Well *that* answers your question about 'why does it work for Windows and not Linux, doesn't it! ! !
updates occur as and when needed by the software.
Obvioulsy not, otherwise we wouldn't be having this conversation. Ph, *that* software updating AD. But the remote Linux clients that are given addresses by DHCP are using BIND for DN, not AD. is that what we've been talking about. I suppose there is a way to to have "option nameserver" entries in the /etc/dhcpd.conf on the server that tell the Linux clients granted IP address leases to use SAMBA as the name server rather than bind, and somehow get the DHCP to tell SAMBA when its handed out addresses or when they have expierd. But you seem pretty hung up on SAMBA so why not just figure out how to make that do the work of DHCP and BIND - and I can't help you with that. I can help you with getting Linux clients to use DHCP and BIND and I know that can work. If you want it to work and run in parallel and have Kerberos be able to do the forward-backward-forward address verificaton with an authoritative NAMED then what I've posted will do all that. BTDT. And as I've mentioned, done it in a hetrogeneous environment and with variations.
2. Is the crypto key shared between DHCP and BIND? This should be the same key used in (1)
The key is only known to AD. As far as I know, bind cannot see the entries stored in AD.
See above. And what I'm talking about is a key that's shred between DHCP and NAMED. There will be a stanza in each that reads key key_id { algorithm algorithm_id; # choose algorithm secret secret_string; # generate string }; and a reference to "key_id" for the subnet concerned. For example http://www.oceanwave.com/technical-resources/unix-admin/nsupdate.html#create... And yes you will have to have the entry in the named zone file to allow update as it describes. Keeping a copy of the key in a file allows you to use nsupdate.
3., Is DHCP set up to use DDNS against BIND for the relevant subnet? Again, consult the URLs for parameters to DHCP that I included in earlier mails
The only way I know to create the reverse entry in AD without a 2008 server is as follows (samba thread again):
[snip]
And since the Linux machines are using DHCP/NAMED then what's in AD doesn't matter as its invisible to them.
This method gives me reverse lookups fr static IP's. Now I need to be able to translate this into dynamic IP's
Which is what I've been describing and trying to get you to do.
Not very good answers but I think it points to conventional methods being of no use when dealing with dynamically loaded zones in AD. But don't let's give up!
At this point I'm dropping out of this thread.
I'm repeating myself and obviously not getting my message across, and I
don't think it has anything to with "English".
--
Do you want the truth, or a well-designed machination brought
into existence solely for the stroking of your ego?
-- Empty
El 03/04/12 22:18, Anton Aylward escribió:
Lynn said the following on 04/03/2012 03:20 PM:
At this point I'm dropping out of this thread. I'm repeating myself and obviously not getting my message across, and I don't think it has anything to with "English".
Thank you so much for the time and effort you have given. It's my English understanding which is at fault. Integration of Linux into AD is still early days. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn said the following on 04/03/2012 12:10 PM:
Is our DHCP client able to do that?
Question for the list: Should the client be able to update the DNS entries or is that a security hole? Surely its the DHCP client (or equivalent if we're using SAMBA) that manages the IP addresses that should be doing this? That's certainly the way I've done it and its the way I see it documented. -- "What ever you're doing, it's a bad idea." http://www.dailywav.com/0110/itsaBadIdea.wav -- Ray Romano (Manny) from Ice Age 3: Dawn Of The Dinosaurs -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/03/12 13:27, Anton Aylward pecked at the keyboard and wrote:
Lynn said the following on 04/03/2012 12:10 PM:
Is our DHCP client able to do that?
Question for the list:
Should the client be able to update the DNS entries or is that a security hole?
Not the client but the *server* should do the updates.
Surely its the DHCP client (or equivalent if we're using SAMBA) that manages the IP addresses that should be doing this?
That is the purpose and job of the DNS *server* _not_ the client.
That's certainly the way I've done it and its the way I see it documented.
-- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/02/2012 04:13 AM:
On 01/04/12 23:53, Anton Aylward wrote:
lynn said the following on 04/01/2012 04:53 PM:
Windows clients have something that we do not. What is it?
What are the names of the Windows hosts?
How does DNS respond when queried on their addresses? How are those names assigned?
Here is a win 7 client called LYNN-PC12@hh3.site. It has its address to be obtained automatically
"automatically" meaning WHAT? Can we see the DHCP logs and the DNS logs around that activity please.
and has 192.168.1.2 hh1.hh3.site set as the only nameserver.
Which is reasonable. If this were Linux I could do that via the DHCP server. Do you? If not, why not? And if not then how do the Linux machines get told their server? If you read the documentation on DHCP you'll see that the client daemon that runs on the clients can botan it from the DHCP server and write it to /etc/resolve.conf Are you doing that? If not, then why not?
Here is the request for the machine ticket. There must have been some communication betwen the DHCP server at 192.16.1.1, LYNN-PC12 and the KDC. LYNN-PC12 was allocated IP 192.168.1.27 but next boot, it will be different.
You can gaurentee it will be different? Would life be easier if you could get it assigned the same IP - if it was available?
Kerberos: AS-REQ LYNN-PC12$@HH3.SITE from ipv4:192.168.1.27:59048 for krbtgt/HH3.SITE@HH3.SITE
Now how is Kerboros associating name with IP address?
[...]
host LYNN-PC12 LYNN-PC12.hh3.site has address 192.168.1.27
I presumem that means you ran the 'host' command ...
host 192.168.1.27 Host 27.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
The most likely reason for that is that you don't have the reverse domain set up. If its not set up then even the most advanced DHCP or SAMBA4 can't inject reverse RRs.
Ditto for the Linux hosts. How are names assigned? Here is an openSUSE 12.1 client called LXDE2.hh3.site. Here, the same DHCP server has allocated 192.168.1.22
"The same DHCP server" ?? So the same DHCP server hands out addresses for (BOTH* the Windows machines and the Linux machines?
All OK so far. Now here is where the windows and linux clients differ:
host LXDE2 Host LXDE2 not found: 3(NXDOMAIN)
host lxde2.hh3.site Host lxde2.hh3.site not found: 3(NXDOMAIN)
host lxde2 Host lxde2 not found: 3(NXDOMAIN)
host 192.168.1.22 Host 22.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
All of which tells me that you don't have DHCP and DNS working togehter properly. I've suggested the "cheat" of pre-populating the zone files. You may also want to use constructs in DHCP like host lxde2 { hardware ethernet 00:00:00:00:00:00 ; # or whatever fixed-address 192.168.1.22 ; } and coresponding entries in the forward and backward DNS records. Yes, its a cheat, yes its "like" having static addresses, but it will work and it will prove or disprove other things, like the *need* for proper DNS instead of hacnking your hosts file. Then, perhaps, you can get DDNS to work so there is no need for the static addresses and pre-loaded zone files. Lynn: the issue here is DHCP and DNS. Its those log files I'd be interested in seeing. Make sure you have logging turned on for both (or debug to syslog)
As far as DHCP goes, either machines "know" their names and use that when asking for an IP address from the DHCP server, or they are given there names by the server, along with router, gateway, and all the other information that they should if you have DHCP set up properly.
In this setup, the machine names are fixed.
How are they "fixed"?
The DHCP is set to allocate addreses only.
WRONG! It should allocate other things like name server and routing information and should tell them how long their leases are to last. Please see the man page. option netbios-name-servers option netbios-dd-server option netbios-node-type option broadcast-address option routers Do you have those? If not, why not? Unless you have the dhcpcd on the Linux clients telling the DHCP server their individual names (and distinct names, which is why you shouldn't be buqqering around with the hosts file) then the DHCP server shold also be telling them their name. My ISP uses DHCP and tells my router its name is "CPE-" followed by the MAC address followed by another string, followed by the domain. You can do this with entries like ddns-hostname = concat(binary-to-ascii(10, 8, "-", leased-address), ".hh3"); ddns-domainname = ".site"; All this is in the DHCP/DNS documentation and the on-line articles have referred to in past email. -- Error of opinion may be tolerated where reason is left free to combat it. --Thomas Jefferson, First Inaugural Speech (1801) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-02 14:26, Anton Aylward wrote:
lynn said the following on 04/02/2012 04:13 AM:
Here is a win 7 client called LYNN-PC12@hh3.site. It has its address to be obtained automatically
"automatically" meaning WHAT? Can we see the DHCP logs and the DNS logs around that activity please.
In windows parlance "automatic" network means "dhcp". Ah, and if that fails, it gets another IP with another protocol and range that I don't remember.
In this setup, the machine names are fixed.
How are they "fixed"?
fixed == fijas in Spanish. Not "mended", but immutable. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk95pGYACgkQIvFNjefEBxrxWQCfTSwl6mly4Z84HFkVjkcdi3u5 JvoAn1XO3wTTkMJlSg5KTosFw6drkB9W =7Anb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 04/02/2012 09:06 AM:
On 2012-04-02 14:26, Anton Aylward wrote:
lynn said the following on 04/02/2012 04:13 AM:
Here is a win 7 client called LYNN-PC12@hh3.site. It has its address to be obtained automatically
"automatically" meaning WHAT? Can we see the DHCP logs and the DNS logs around that activity please.
In windows parlance "automatic" network means "dhcp". Ah, and if that fails, it gets another IP with another protocol and range that I don't remember.
IIR its 169.something. And this is the same DHCP server that, on Lynn's network, hands out addresses to the Linux machines. She's asking why there are forward DNS entries for the Windows majhines and not for the Linux majhines. For that I'd have to see the DHCP and DNS logs not the kerberos logs.
In this setup, the machine names are fixed.
How are they "fixed"?
fixed == fijas in Spanish. Not "mended", but immutable.
So let me ask it this way: how are they determined? How are they assigned. What are they - English pun - fixed to? I can see that in the case where each mahjine "knows" its own name, in which case its dhcpcd should be using the "-f" parameter to tell the DHCP server. If not, then there is an error in the setup. Lynn, can you run "ps -ef | grep dhcpcd" on one of the running Linux majhines to see how it thinks its talking to the DHCP server. The DHCP log files should show the requests. If not then turn up the logging/debug level! -- You can only protect your liberties in this world by protecting the other man's freedom. You can only be free if I am free. -- Clarence S. Darrow -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 02/04/12 15:06, Carlos E. R. escribió:
In this setup, the machine names are fixed.
How are they "fixed"?
fixed == fijas in Spanish. Not "mended", but immutable.
Maybe this is part of the problem. The openSUSE Spanish translation is incomplete to say the least. This in itself a big problem when you are working in a Spanish environment. You shouldn't need to be fluent in English to use Linux. But my gad, you're knackered if you aren't. The few bits that are translated into something meaningful (as opposed to sticking it in Google translate) tend to be for desktop users. As the Spanish observe, English speakers tend to speak English. Only. Given /var/log/messages in Spanish, many would give up. Now, all we need is someone to jump from behind a bush and mention the existence of a Spanish mailing list! Salu2, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-02 18:20, lynn wrote:
El 02/04/12 15:06, Carlos E. R. escribió:
In this setup, the machine names are fixed.
How are they "fixed"?
fixed == fijas in Spanish. Not "mended", but immutable.
Maybe this is part of the problem. The openSUSE Spanish translation is incomplete to say the least. This in itself a big problem when you are working in a Spanish environment. You shouldn't need to be fluent in English to use Linux. But my gad, you're knackered if you aren't. The few bits that are translated into something meaningful (as opposed to sticking it in Google translate) tend to be for desktop users.
Yast and the programs made by openSUSE are translated manually, I am one of the translators, and it is good quality. We don't use google translator. The rest of the applications depend on upstream. That is, we only translate things for which we are the "upstream". KDE has its own team of translators, and good ones. Gnome I'm not sure. Mozilla, LibreOffice... GNU has the gnu translation project. Many apps are not translated, other incomplete. However, I prefer the desktop in English, I'm more familiar with it. In general, you need to be able to at least read English if you are a programmer or computer admin. Even if things are translated, English books are more recent, and English forums/lists are more populated. Man pages / Info pages are seldom translated, and if they are, they are obsolete.
As the Spanish observe, English speakers tend to speak English. Only. Given /var/log/messages in Spanish, many would give up.
Usually I can not follow logs in English,
Now, all we need is someone to jump from behind a bush and mention the existence of a Spanish mailing list!
There is one ;-) - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk96F6YACgkQIvFNjefEBxp5ygCgnK8fHQ7QCT6lAanifUy6yv1C BscAmwUmFesBFs45JQhbKwHjYNz05ISu =Reii -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. said the following on 04/02/2012 05:18 PM:
Usually I can not follow logs in English,
You are not alone. And it has little to do with "English" and a lot to do with what the programmers have decided to use syslog to record. -- Any sufficiently advanced technology is undistinguishable from magic. - Arthur Clarke -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-03 00:44, Anton Aylward wrote:
Carlos E. R. said the following on 04/02/2012 05:18 PM:
Usually I can not follow logs in English,
You are not alone. And it has little to do with "English" and a lot to do with what the programmers have decided to use syslog to record.
Oops! Did I say English? I meant Spanish. If you are used to see the logs in English, you can not follow them in another language. And yes, it needs getting used to, in any language you choose. If you think understanding them in English is difficult, in another language it depends on what the translator thought the programmer meant, and the interpretation could be wrong... so the reader has to mentally translate back to English and then double guess the right translation :-P - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk96duQACgkQIvFNjefEBxr3KACeOfyx0tSZ1Pe0BQk/7Srpcavi n38AoMZljLYr1f0eCNFT8Y116QYO5rBA =z4ha -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 02/04/12 23:18, Carlos E. R. escribió:
Usually I can not follow logs in English,
That's exactly my point. Carlos, even _you_ find that hard even when your English is perfect. Imagine then what it's like for Pepe Rodriguez who's just been given a freebie 12.1 DVD from his visit to SIMO. Linux = being pretty fluent in English. And then some.
Now, all we need is someone to jump from behind a bush and mention the existence of a Spanish mailing list!
There is one ;-)
Thank you for your excellent translation work. It certainly helps introduce openSUSE to many non English speakers. L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Samba4 AD does not use zone files for DNS. It uses dlz. dlz sets up the forward zone simply by starting the DC (please see the bind logs posted earlier). How do I get dlz to produce a reverse zone? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Lynn said the following on 04/02/2012 12:46 PM:
Samba4 AD does not use zone files for DNS. It uses dlz. dlz sets up the forward zone simply by starting the DC (please see the bind logs posted earlier).
How do I get dlz to produce a reverse zone?
DHCP doesn't use zone files either. It used DDNS. We've established that your forward zone has one and only one entry in the file, that of the server. But when you're up and running with the Windows machines there are the forward records for them. This can only as a result of something - SAMBA ... whatever - injecting the appropriate RRs into the zone of the live DNS server with the DDNS protocol. I'm sure if you ran a network sniffer you'd see that happening. But nsupdate (or whatever) can't itnroduce RRs to a zone that isn't there. You have to have the basic zone set up and the DNS server aware of it in order to be able to inject RRs into it. Try running nsupdate by hand ... We're not talking "files" here for other than initialization. -- A hollow voice says, "A hollow voice says, 'Plugh'." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-01 22:53, lynn wrote:
El 01/04/12 22:35, Carlos E. R. escribió:
But "127.0.1.1" is your own localhost. The entire 127 network is your localhost, always, not another machine. Tri pinging, it works.
I have three entries in /etc/hosts on each Linux client: 127.0.0.1 localhost 127.0.1.1 host.domain host 192.168.1.3 server.domain server
with /etc/HOSTNAME containing host only
Without the 127.0.1.1, hostname -f does not work and not much else does either.
But I don't have any entry for 127.0.1.1 and hostname -f works fine. If you need an entry for that IP in the DNS, you can write it, it is fixed because it is always localhost, by definition. 127.*.*.* == localhost
An alternative is to give the clients a fixed IP and use that instead of the 127.0.1.1. But if the windows clients can use dhcp, why can't our openSUSE clients use it from the same server?
You can not assign 127.0.1.1 to any client, that will not work. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk947nkACgkQIvFNjefEBxoQ9ACfa4aie32KBgKoSFoei6fX5Q5U WqEAoJZGRExBW2tFQibMoGpcudTkSbcZ =k3iN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 02/04/12 02:10, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-01 22:53, lynn wrote:
El 01/04/12 22:35, Carlos E. R. escribió:
You can not assign 127.0.1.1 to any client, that will not work.
I have assigned 127.0.1.1 to every client: 127.0.1.1 host.domain host It is the only way I know to get the gss daemon to get the fqdn of the client using DHCP. I took the lead frm Ubuntu who assign that address after a default install which produces this: 127.0.0.1 localhost 127.0.1.1 the-computer-name-you-gave-it-in-setup L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/02/2012 02:59 AM:
El 02/04/12 02:10, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-01 22:53, lynn wrote:
El 01/04/12 22:35, Carlos E. R. escribió:
You can not assign 127.0.1.1 to any client, that will not work.
+1
I have assigned 127.0.1.1 to every client: 127.0.1.1 host.domain host
It is the only way I know to get the gss daemon to get the fqdn of the client using DHCP.
Which gets back to the issue of "you don't have DNS set up properly". So its not the *ONLY* way.
I took the lead frm Ubuntu who assign that address after a default install which produces this:
127.0.0.1 localhost 127.0.1.1 the-computer-name-you-gave-it-in-setup
That's different from naming every computer "host.domain host" Just because ubuntu does it doesn't make it right for Uses and doesn't make it right in general. If you want to do things the Ubuntu way, then fine, use ubuntu and when it doesn't work for ubuntu raise it on a ubuntu list; this is for openSuse and the way openSuse does things. -- One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's all right not to know anything. That to me is far more dangerous than a little pornography on the Internet. - Carl Sagan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward
lynn said the following on 04/02/2012 02:59 AM:
I took the lead frm Ubuntu who assign that address after a default install which produces this:
127.0.0.1 localhost 127.0.1.1 the-computer-name-you-gave-it-in-setup
and openSUSE assigns: 127.0.0.1 localhost 127.0.0.2 <name-you-assigned>
That's different from naming every computer "host.domain host"
Just because ubuntu does it doesn't make it right for Uses and doesn't make it right in general. If you want to do things the Ubuntu way, then fine, use ubuntu and when it doesn't work for ubuntu raise it on a ubuntu list; this is for openSuse and the way openSuse does things.
??? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/01/2012 03:06 AM:
El 31/03/12 20:57, Anton Aylward escribió:
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? If you had ddns working then it would be done 'auto-magically'.
Yes. I have ddns working. The forward zone is updated by Samba4 when new machines are allocated IP's, join the domain etc. I just didn't have a reverse lookup zone.
Then you don't have ddns working _completely_. Sorry if I seem picky, but we are definitely in a realm where accuracy and completeness matters.
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.
I think that is what is happening because you can see the KDC receive requests from IP's which have been allocated via DHCP _and_ correctly lookup their Kerberos machine$/fqdn key correctly for authentication.
KDC = Kerberos Domain Controller ? To correctly look up FQDN from only a IP requires treat DNS properly implements reverse lookup. We've established you don't have complete and accurate reverse tables. Could you please elucidate.
Are you running AD? You have a Microsoft domain master running AD or are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
I think we are talking at cross [purposes or I need an update. I thought SAMBA was acting as a Domain Controller and that the AD was the database, possibly (but not always) implemented by LDAP. AD = Active Directory, a dynamically maintained database, a directory service that runs on the Domain Controller and needs DNS, Kerberos and LDAP to support it. I thought SAMBA was more than just AD.
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.
... and it needs other parameters but I forget, ....
Kerberos needs not only to authenticate the user but also the machines on the lan. When I logon, both I and my computer have to authenticate. If I request a file then both I and the fileserver have to authenticate. This is why the dns is crucial with Kerberos.
That is why *properly implemented* DNS is crucial with Kerberos. If the code can't do a full backward-for-ward-backward verification of the IP/FQDN from the *authoritative* (and presumably secured) DNS service then the fallback to the /etc/hosts is a security hole. The user in control of the client machine can put whatever he (or she) likes into /etc/hosts and so spoof the identification.
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?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the DHCP server telling the DNS server. Since its supplying both IP address and name, the DNS server should be able to slot RRs in for both forward and backward zones. The address is handed out after the Linux machine is booted, long before the SAMBA client comes up, so the SAMBA side of things should have nothing to do with it. All this DDNS should work regardless of the presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it running in that kind of setting.
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.
How come the windows clients work OK. What do they have that we don't?
I don't know. I'm not very Windows-savvy. Actually we are *assuming* things here. Did you do the dump of the DNS tables? If we see in that dump that the Windows clients have both forward and reverse entries we know they are doing something the Linux clients are not. Then and only then can we say they are working OK in this sense of OK. -- Plunderers of the world, after they, laying everything waste, run out of land, they probe even the sea: if their enemy has wealth, they have greed; if the enemy be poor, they are ambitious; neither East nor West has sated them; alone of mankind they covet poverty with the same passion as wealth. Robbery, butchery, rape they misname Empire: they make a wasteland and call it peace. - Tacitus, Agricola 80 The speech of Calgacus the Caledonian at the battle of Mons Graupius -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 01/04/12 15:21, Anton Aylward escribió:
lynn said the following on 04/01/2012 03:06 AM:
El 31/03/12 20:57, Anton Aylward escribió:
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:
Then you don't have ddns working _completely_. Sorry if I seem picky, but we are definitely in a realm where accuracy and completeness matters.
No, be as picky as necessary. I need it.
KDC = Kerberos Domain Controller ?
Yes.
To correctly look up FQDN from only a IP requires treat DNS properly implements reverse lookup. We've established you don't have complete and accurate reverse tables.
Could you please elucidate.
I do not have reverse lookup. The forward zone is created when I start bind. It get updated when a new client (Linux or windows) boots or joins the domain. For ddns it has a tsig which is a Kerberos keytab. The keytab was produced when the AD was first provisioned. I posted he named.conf a few posts ago. I also have a static reverse zone. The only thing that prevents it too from being included in the ddns is that I don't know how to generate a keytab for it. This is where the Samba guys have changed the bind innards.
Are you running AD? You have a Microsoft domain master running AD or are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
I think we are talking at cross [purposes or I need an update. I thought SAMBA was acting as a Domain Controller and that the AD was the database, possibly (but not always) implemented by LDAP.
AD = Active Directory, a dynamically maintained database, a directory service that runs on the Domain Controller and needs DNS, Kerberos and LDAP to support it.
I thought SAMBA was more than just AD.
Samba4 is a windows domain controller. It consists of a totally Linux-ified AD. It has its own built in KDC and LDAP server. Soon, it will have its own DNS server too. It already has its own working DNS server but ironically it only works for forward ddns at the moment.
Kerberos needs not only to authenticate the user but also the machines on the lan. That is why *properly implemented* DNS is crucial with Kerberos.
If the code can't do a full backward-for-ward-backward verification of the IP/FQDN from the *authoritative* (and presumably secured) DNS service then the fallback to the /etc/hosts is a security hole. The user in control of the client machine can put whatever he (or she) likes into /etc/hosts and so spoof the identification.
Only root has access to /etc/hosts on our lan.
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?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the DHCP server telling the DNS server.
The address is handed out after the Linux machine is booted, long before the SAMBA client comes up, so the SAMBA side of things should have nothing to do with it. All this DDNS should work regardless of the presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it running in that kind of setting.
Kerberos has to authenticate the dns server before it can do anything on the lan. The KDC is supplied by Samba so Samba must be up before any ddns takes place. We can however show that the clients have an IP before doing a domain logon as they can ping the server on bot IP and fqdn (because the server is in their etc/hosts file. The missing link seems to be what the windows clients have instead of /etc/hosts.
How come the windows clients work OK. What do they have that we don't?
I don't know. I'm not very Windows-savvy.
Actually we are *assuming* things here. Did you do the dump of the DNS tables? How do I do a dump?
If we see in that dump that the Windows clients have both forward and reverse entries we know they are doing something the Linux clients are not. Then and only then can we say they are working OK in this sense of OK.
Will post it as soon as I know how. Meanwhile am running with the mysterious 127.0.1.1:-( Thanks again for your time, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
lynn said the following on 04/01/2012 04:41 PM:
To correctly look up FQDN from only a IP requires treat DNS properly implements reverse lookup. We've established you don't have complete and accurate reverse tables.
Could you please elucidate.
I do not have reverse lookup.
Then I can't see how you can expect this to work properly. And no, spoofing Kerberos by fiddling with /etc/hosts 127.0.0.1 entry is not "working properly". Carlos is quite right, that is localhost.localdomain and cannot be anything else without breaking other fundamentals. Changing it to the fqdn to get around the absence of reverse lookup is subverting Kerberos.
The forward zone is created when I start bind.
Picky: No, when you start bind it reads the config file and builds its internal map so that it can respond to queries about the forward zone. You need to have that zone defined and all the static devices in it (servers, firewalls, routers) as defined resource records (RRs) DHCP will add and remove more RRs - if you have the thing set up properly and DHCP knows about the shared cypto key needed for secure communications.
It get updated when a new client (Linux or windows) boots or joins the domain. For ddns it has a tsig which is a Kerberos keytab. The keytab was produced when the AD was first provisioned. I posted he named.conf a few posts ago. I also have a static reverse zone. The only thing that prevents it too from being included in the ddns is that I don't know how to generate a keytab for it. This is where the Samba guys have changed the bind innards.
Try reading http://www.oceanwave.com/technical-resources/unix-admin/nsupdate.html You recall that bind complained about a file and you created it (empty) with 'touch'? Well guess what....
Are you running AD? You have a Microsoft domain master running AD or are you all Linux at the core and just Windows clients?
Yes we are running AD. Samba4 _is_ AD. The schema includes rfc2703. Our users have the posixAccount and posixGroup objects which are defined in the m$ AD schema. (made public via the Samba vs m$ European Court ruling last year)
I think we are talking at cross [purposes or I need an update. I thought SAMBA was acting as a Domain Controller and that the AD was the database, possibly (but not always) implemented by LDAP.
AD = Active Directory, a dynamically maintained database, a directory service that runs on the Domain Controller and needs DNS, Kerberos and LDAP to support it.
I thought SAMBA was more than just AD.
Samba4 is a windows domain controller. It consists of a totally Linux-ified AD. It has its own built in KDC and LDAP server.
Soon, it will have its own DNS server too. It already has its own working DNS server but ironically it only works for forward ddns at the moment.
You keep asserting that, but can you give reference please.
Kerberos needs not only to authenticate the user but also the machines on the lan. That is why *properly implemented* DNS is crucial with Kerberos.
If the code can't do a full backward-for-ward-backward verification of the IP/FQDN from the *authoritative* (and presumably secured) DNS service then the fallback to the /etc/hosts is a security hole. The user in control of the client machine can put whatever he (or she) likes into /etc/hosts and so spoof the identification.
Only root has access to /etc/hosts on our lan.
Picky: Its not meant to be accessed from the LAN, its meant to be accessed from local programs, including ones that are not running as root. It should be 0644/root:root. Carlos, others, would you care to verify that and explain to Lynn why /etc/hosts needs to be readable by everyone. Check /etc/permissions
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?
Yes. At this point the dlz part of DNS grabs it. Now, only my forward is updated so my reverse zone is going to know nothing about the update is it?
I don't know. In all the systems I've worked with it boils down to the DHCP server telling the DNS server.
The address is handed out after the Linux machine is booted, long before the SAMBA client comes up, so the SAMBA side of things should have nothing to do with it. All this DDNS should work regardless of the presence of SAMBA, Kerberos, YP/NIS, or NFS. SAMBA is not a requirement for UNIX/Linux/AIX/HP-UX/DG-UX/Solaris-only networks and I've had it running in that kind of setting.
Kerberos has to authenticate the dns server before it can do anything on the lan.
Please explain. Are you saying that before the DNS server program listening on port 53 on the server machine can respond to DNS requests from the machine some Kerberos authentication has to take lace? Of what and by what? What about the DHCP server program running on the server ... ?
The KDC is supplied by Samba so Samba must be up before any ddns takes place.
No, that doesn't make sense. Take all the Windows stuff off your LAN, disable SAMBA and run it just as a Linux server and Linux clients. (or Linux server and Solaris clients, or AIX clients or HP-UX or DG-UX). You're running DHCP and BIND, so it must still be able to work. And I know, BTDT, that DDNS works without SAMBA in that kind of setup. I'm sure there are many people on this list who are or who have clients that are running DHCP<->DDNS<->BIND. Yes, I'm sure that one-day/some-day SAMBA will have built in replacements for all this (and probably its own internal database so you can forget about LDAP, forget about everything about Linus except the kernel...) but this is now. I'm sure that SAMBA *does* deal with the Windows side of things quite well, but what we are discussion is getting Linux machines working with Kerberos. That means getting forward and reverse DNS entries working. And if these machines have addresses handed out by DHCP that means either "cheating" (as I've described) or getting DDNS working.
We can however show that the clients have an IP before doing a domain logon as they can ping the server on bot IP and fqdn (because the server is in their etc/hosts file. The missing link seems to be what the windows clients have instead of /etc/hosts.
Googling I see mention of c:\windows\system32\drivers\etc\hosts Please note: Unlike the DNS, the hosts file is under the direct control of the local computer's administrator. That's why it should be *writeable* only by root and end users should not have root access. In addition, your nsswitch should prefer DNS and only use the host file when DNS isn't available. See also http://support.microsoft.com/kb/172218
Actually we are *assuming* things here. Did you do the dump of the DNS tables?
How do I do a dump?
Send a signal to the server, as I described in the except from the man page in an earlier mail. -- If computers get too powerful, we can organize them into a committee - that will do them in. -- Bradley's Bromide -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday 29 Mar 2012 19:34:29 lynn wrote:
12.1 Hi We have a bind nameserver for our 192 domain.
For a non static IP client I have to set the line: 127.0.1.1 hostname.domain hostname in /etc/hosts otherwise hostname -f and lots of other stuff doesn't work.
1. Why? 2. What should the file /etc/HOSTNAME contain? a. fqdn b. hostname
Thanks, L x
It might be a "bug", these may help http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099 http://www.debian.org/doc/manuals/debian- reference/ch05.en.html#_the_hostname_resolution (see 5.1.2) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Anton Aylward -
Carlos E. R. -
ianseeks -
James Knott -
Ken Schneider - openSUSE -
lynn -
Patrick Shanahan