Re: SRV records can't point to CNAMEs
On Sat, Feb 19, 2011 at 08:14:03AM +0100, Petter Reinholdtsen wrote:
> [Andreas B. Mundt]
> > Hmm, I don't know how to fix this. To me it looks a bit like
> > sacrificing a clear and common DNS setup in favor of a very special
> > setup (for which I don't know how to get Kerberos working). This
> > tuned setup works out of the box at the University of Oslo in a
> > special environment, but causes hassle and confusion probably
> > everywhere else.
> Note that as far as I can tell, the university of Oslo is not a
> special environment, and the script is written to handle the common
> way to set up Kerberos and LDAP on unix in a mixed AD/Unix network.
> It allow Windows and AD clients to get their separate setup without
> one leaking into the other unless it is the indended behaviour. The
> script also generate what seem to be a working setup for mit.edu, and
> I would very much welcome info on other environments (DNS-domains)
> where I can test it. :)
> There were many considerations to take when writing the code to
> dynamically set up all clients during installation based on DNS, and I
> believe I ended up with the most sensible way to do it.
Well I don't know. But I wonder when asking for the domain's ldap
server in the basic setup right now (and not the mixed Windows AD
root@localhost:~# nslookup -type=srv _ldap._tcp.intern
_ldap._tcp.intern service = 100 0 389 tjener.intern.
I get the correct answer: LDAP is currently provided by
tjener.intern. This is what I expect.
But if I use the script debian-edu-ldapserver which I would think has
exactly the same job, to tell me the ldap server, it fails. Hopefully
this is fixed now with the latest commit. It fixes a bug that
prevented the fallback to 'ldap' in debian-edu-ldapserver to work.
Let's see how far we get with that now. But if a function called
'find_ldap_server' does not find the ldapserver which is clearly
announced by its service record in the domain, I'm not sure if that
function works as intended.