[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ldap problem



Have you tried looking at the auth.log?  Maybe that will give you some hint.
I've found that pam is very good about outputting stuff to the auth.log.  I was
able to debug one problem from looking at the auth.log and seeing that pam
couldn't contact the ldap server because the permissions on my libnss-ldap.conf
file accidentally had the wrong mode.

jamie.


On Mon, Jun 27, 2005 at 10:36:34AM -0700, Matt Dunford wrote:
> On Sun, Jun 26, 2005 at 09:42:55AM -0400, jrollins@phys.columbia.edu wrote:
> > Hello.  I just yesterday finished setting up a lab with ldap and nfs for a group
> > of amd64 machines.  It seems to be working smoothly at the moment.
> 
> Cool, I'm glad to see that I'm the only one with problems.  This way
> at least we know the problem is me and not the debian port.
> 
> > > There's definately some duplicates (tty, nobody, etc).  But I'm not
> > > sure what will happen if I take those out, the ldap server being in
> > > production and all..
> > 
> > Is this wise?  I ask, because I honestly don't know.  I would assume that this
> > is a bad idea.  I would think there should be no possible dupblicate user
> > mappings.  Something is bound to get confused.  In general I also think that
> > there is probably no reason whatsoever to share system user account information
> > anyway.  Each machine should handle system accounts locally.  System group
> > information seems a bit trickier, though, since system group membership
> > information would not be shared.
> 
> I don't believe it's a bad idea.  Take this entry in
> /etc/nsswitch.conf as an example:
> 
> hosts: files dns nis
> 
> When looking up a hostname, the system should consult /etc/hosts
> first.  If it doesn't exist there, then it consults dns.  If it's in
> dns, it returns the ip of the hostname.  Even if the same entry is in
> nis, it doesn't matter, since it doesn't query nis.  It's already got
> it's info from dns.
> 
> At least that's how I thought the nsswitch.conf files worked: on a
> first come, first serve basis.
> 
> So in a similar way when looking for system accounts (like root), it
> will query files first.  And if it doesn't find an entry, then it
> queries ldap.
> 
> Also browsing through the ldap logs, I don't see any queries for
> system accounts go by.
> 
> > I have been using getent to see what name service is reporting as all available
> > users and groups.
> 
> Things like `getent passwd username` and `id username` work correctly.
> automounting too.  They all draw their info from the ldap server.  I
> have the ldap log open as I test this and can see their queries go by.
> 
> Ssh (and the other login mechanisms) also communicate correctly, but
> then just hang like I described before.
>
> > I use the configuration recommended in the libpam-ldap README.Debian that looks
> > like this:
> > 
> >   auth [success=1 default=ignore] pam_unix.so
> >   auth required pam_ldap.so use_first_pass
> >   auth required pam_permit.so
> > 
> > for essentially all of my common-* pam config files (the above is my
> > common-auth).  This configuration seems to work for me.
> 
> I've given that one a try too.  I'm at my wit's end.  It must be
> something small as ldap works on everything but the amd64s.
> 
> > I wish I could be of more help.  How do you know where it is that sshd hangs
> > during the connection attempt?
> 
> I googled around and found a few examples of how ssh developers debug
> their code in gdb.  So I applied the same method and that's how I got
> the backtrace.
> 
> -- 
> Sincerely,
> Matt Dunford
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-amd64-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: