Re: ldap problem
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
Reply to: