Mailinglist Archive: opensuse (1477 mails)

< Previous Next >
Re: [opensuse] what does 127.0.1.1 mean?
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups