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: