Re: Strange LDAP problem
This one time, at band camp, Michael Loftis said: > augh disregard my last...sound slike you got that done. long day over here > already. > > can you turn up debugging on your slapd? loglevel 256 or loglevel 512 are > VERY helpful, they log what searches are run--one or both does i can't > remember...this way you can find out whats up. With loglevel 512: Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=nabraham,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=wcwa,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=sharon,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=bigstape,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=jseidel,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=nancymk,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=waldron,ou=People,dc=ccil,dc=org" [...] about 1500 more time, which I don't think anyone really needs to see :) It is doing the lookups, but it is apparently not getting translated back by the system calls? finger -m does, work, as does finger without a user argument, so at some level all of this works, jyust not for large queries. Similarly, I just noticed that getent passwd $user works, but getent passwd only returns the users in /etc/passwd. Odd, but I'm on to something now, I guess - all large queries fail, and the small ones succeed. Not sure what to do with it, but I have a starting point now. Maybe this is a problem in the system calls, or the size of the nscd cache, or something screwy like that? Not sure where else to go with this now. Thanks again, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpjPek1cQNTb.pgp Description: PGP signature
Re: Strange LDAP problem
This one time, at band camp, Michael Loftis said: > augh disregard my last...sound slike you got that done. long day over here > already. I know that feeling :) > can you turn up debugging on your slapd? loglevel 256 or loglevel 512 are > VERY helpful, they log what searches are run--one or both does i can't > remember...this way you can find out whats up. I will do so when I get some time - I think I did some of this in the past, and it helped me past some stupid errors in our ldif's before. Will try again. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpSTXP802zim.pgp Description: PGP signature
Re: Strange LDAP problem
This one time, at band camp, Theodore Knab said: > If finger is not working, does chfn or the password change stuff work ? > > I think this is a PAM issue. However, I could be wrong. > > My '/etc/pam.d/login' file looks like this and fingers work with LDAP. > > What does your look like ? > > [EMAIL PROTECTED]:/etc/pam.d$ cat login | grep -v ^# > > auth requisite pam_securetty.so > auth requisite pam_nologin.so > auth required pam_env.so > auth sufficient pam_ldap.so > auth required pam_unix.so nullok > accountsufficient pam_ldap.so > accountrequired pam_unix.so > sessionsufficient pam_ldap.so > sessionrequired pam_unix.so > sessionoptional pam_lastlog.so > sessionoptional pam_motd.so > sessionoptional pam_mail.so standard noenv > password sufficient pam_ldap.so obscure min=4 max=50 > password required pam_unix.so nullok obscure min=4 max=50 auth required pam_securetty.so auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix_auth.so try_first_pass accountsufficient pam_ldap.so accountrequired pam_unix_acct.so password sufficient pam_ldap.so password required pam_unix.so use_first_pass session sufficientpam_ldap.so sessionrequired pam_unix_session.so #sessionoptional pam_console.so Not so strikingly different that I see the problem. Remeber too, that users can log in and that `id` works as expected. > My LDAP entry looks like: [...] > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > objectClass: account > objectClass: qmailuser > objectClass: couriermailaccount > objectClass: Person > objectClass: OrganizationalPerson > objectClass: inetOrgPerson This is where I see some differences. We don't use inetOrgPerson, but we use a locally extended one in our schema. I don't see how this could make a difference, though. Thanks for the help, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0SXQ9UFLdq.pgp Description: PGP signature
Re: Strange LDAP problem
This one time, at band camp, Michael Loftis said: > augh disregard my last...sound slike you got that done. long day over here > already. > > can you turn up debugging on your slapd? loglevel 256 or loglevel 512 are > VERY helpful, they log what searches are run--one or both does i can't > remember...this way you can find out whats up. With loglevel 512: Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=nabraham,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=wcwa,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=sharon,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=bigstape,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=jseidel,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=nancymk,ou=People,dc=ccil,dc=org" Mar 24 21:15:51 mercury slapd[19886]: conn=46 op=1 ENTRY dn="uid=waldron,ou=People,dc=ccil,dc=org" [...] about 1500 more time, which I don't think anyone really needs to see :) It is doing the lookups, but it is apparently not getting translated back by the system calls? finger -m does, work, as does finger without a user argument, so at some level all of this works, jyust not for large queries. Similarly, I just noticed that getent passwd $user works, but getent passwd only returns the users in /etc/passwd. Odd, but I'm on to something now, I guess - all large queries fail, and the small ones succeed. Not sure what to do with it, but I have a starting point now. Maybe this is a problem in the system calls, or the size of the nscd cache, or something screwy like that? Not sure where else to go with this now. Thanks again, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Strange LDAP problem
This one time, at band camp, Michael Loftis said: > augh disregard my last...sound slike you got that done. long day over here > already. I know that feeling :) > can you turn up debugging on your slapd? loglevel 256 or loglevel 512 are > VERY helpful, they log what searches are run--one or both does i can't > remember...this way you can find out whats up. I will do so when I get some time - I think I did some of this in the past, and it helped me past some stupid errors in our ldif's before. Will try again. Thanks, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
Re: Strange LDAP problem
This one time, at band camp, Theodore Knab said: > If finger is not working, does chfn or the password change stuff work ? > > I think this is a PAM issue. However, I could be wrong. > > My '/etc/pam.d/login' file looks like this and fingers work with LDAP. > > What does your look like ? > > [EMAIL PROTECTED]:/etc/pam.d$ cat login | grep -v ^# > > auth requisite pam_securetty.so > auth requisite pam_nologin.so > auth required pam_env.so > auth sufficient pam_ldap.so > auth required pam_unix.so nullok > accountsufficient pam_ldap.so > accountrequired pam_unix.so > sessionsufficient pam_ldap.so > sessionrequired pam_unix.so > sessionoptional pam_lastlog.so > sessionoptional pam_motd.so > sessionoptional pam_mail.so standard noenv > password sufficient pam_ldap.so obscure min=4 max=50 > password required pam_unix.so nullok obscure min=4 max=50 auth required pam_securetty.so auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix_auth.so try_first_pass accountsufficient pam_ldap.so accountrequired pam_unix_acct.so password sufficient pam_ldap.so password required pam_unix.so use_first_pass session sufficientpam_ldap.so sessionrequired pam_unix_session.so #sessionoptional pam_console.so Not so strikingly different that I see the problem. Remeber too, that users can log in and that `id` works as expected. > My LDAP entry looks like: [...] > objectClass: posixAccount > objectClass: top > objectClass: shadowAccount > objectClass: account > objectClass: qmailuser > objectClass: couriermailaccount > objectClass: Person > objectClass: OrganizationalPerson > objectClass: inetOrgPerson This is where I see some differences. We don't use inetOrgPerson, but we use a locally extended one in our schema. I don't see how this could make a difference, though. Thanks for the help, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgp0.pgp Description: PGP signature
