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

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

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

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

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

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

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

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

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

-----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

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

Carlos E. R. wrote:

The entire 127 network is your localhost

Along with ::1 in IPv6. -- 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

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

-----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

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

* Anton Aylward [04-02-12 07:51]:

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

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

-----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

-----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

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

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

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

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/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 on alt.goth -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org