Hi! We have a problem when loading pam_ldap.so unit. In auth.log the following error gets: Mar 19 17:58:15 host sshd[36442]: in openpam_load_module(): no /usr/local/lib/pam_ldap.so found Mar 19 17:58:15 host sshd[36442]: fatal: PAM: initialisation failed The path to the unit is specified correctly, the rights are sets correctly, the unit file type is right: # pwd /usr/local/lib ls -l | grep pam -r--r--r-- 1 root wheel 42584 Mar 18 11:44 pam_ldap.so lrwxr-xr-x 1 root wheel 18 Mar 17 18:17 pam_mkhomedir.so -> pam_mkhomedir.so.2 -r--r--r-- 1 root wheel 9056 Mar 17 18:17 pam_mkhomedir.so.2 # file pam_ldap.so pam_ldap.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), stripped However, pam_mkhomedir.so from the same directory boots normally. A fragment of /etc/pam.d/sshd: # auth auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient pam_unix.so no_warn try_first_pass auth required /usr/local/lib/pam_ldap.so Change of parametres of call of the unit, condition type, does not influence result. The unit move to /usr/lib and instructions in pam.d/sshd without path also does not help . Units are installed from newest ports. On other machine with same hardware configuration, but 32bit FreeBSD (i386 kernel), pam_ldap works correctly. I will be very glad to hear your advices on problem elimination! Fast introduction of this service very important for us. Use of 32bit system not allowed, because it not detect over 4GB RAM. How-To-Repeat: Try to use pam_ldap from PAM on FreeBSD 7.1-RELEASE amd64 with similar hardware configuration (Intel Xeon).
Responsible Changed From-To: freebsd-ports-bugs->marcus Over to maintainer (via the GNATS Auto Assign Tool)
Good evening! I give the additional information on a problem: Failure is observed only with service sshd (config /etc/pam.d/sshd, and also at inclusion from pam.d/sshd other profiles pam, containing this unit) Other services (checked su and passwd) loads the unit normally, and work with it. Kernel customisations do not influence a situation. I loaded old (GENERIC) kernel for check. Settings of sshd (/etc/ssh/sshd_config) did not be customised. With the best regards, Alexandr.
State Changed From-To: open->feedback Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so.
Good evening! The decision to pass on i386 for increase of reliability of system was accepted. However, on i386 the problem has repeated. New system version (7.1 updated to STABLE): FreeBSD host.ripn.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Mon Mar 23 18:32:22 MSK 2009 ales@host.ripn.net:/usr/obj/usr/src/sys/CUSTOM i386 ktrace, kdump: 670 sshd RET select 1 670 sshd CALL accept(0x4,0xbfbfe720,0xbfbfee7c) 670 sshd STRU struct sockaddr { AF_INET, 195.19.26.183:2012 } 670 sshd RET accept 5 670 sshd CALL fcntl(0x5,F_GETFL,0) 670 sshd RET fcntl 6 670 sshd CALL fcntl(0x5,F_SETFL,O_RDWR) 670 sshd RET fcntl 0 670 sshd CALL pipe 670 sshd RET pipe 6 670 sshd CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xbfbfee70) 670 sshd RET socketpair 0 670 sshd CALL fork 670 sshd RET fork 23570/0x5c12 670 sshd CALL close(0x7) 670 sshd RET close 0 670 sshd CALL write(0x8,0xbfbfe657,0x5) 670 sshd GIO fd 8 wrote 5 bytes 0x0000 0000 00b7 00 |.....| 670 sshd RET write 5 670 sshd CALL write(0x8,0x28530000,0xb6) 670 sshd GIO fd 8 wrote 182 bytes 0x0000 0000 00ae 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a50 726f 746f 636f |...............................Protoco| 0x0026 6c20 320a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a |l 2...................................| 0x004c 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a |......................................| 0x0072 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 5375 6273 7973 7465 6d09 7366 7470 092f 7573 722f |..................Subsystem.sftp./usr/| 0x0098 6c69 6265 7865 632f 7366 7470 2d73 6572 7665 720a 0a0a 0a0a 0a0a 0000 0000 |libexec/sftp-server...........| 670 sshd RET write 182/0xb6 670 sshd CALL close(0x8) 670 sshd RET close 0 670 sshd CALL close(0x9) 670 sshd RET close 0 670 sshd CALL close(0x5) 670 sshd RET close 0 670 sshd CALL gettimeofday(0xbfbfe5fc,0) 670 sshd RET gettimeofday 0 670 sshd CALL getpid 670 sshd RET getpid 670/0x29e 670 sshd CALL open(0x2839d21f,O_RDONLY,<unused>0) 670 sshd NAMI "/dev/urandom" 670 sshd RET open 5 670 sshd CALL read(0x5,0xbfbfe608,0x74) 670 sshd GIO fd 5 read 116 bytes 0x0000 5d12 b05c 237b 7352 8767 0ff0 5ede 09c5 7711 e4d9 6082 ce84 50b5 9a42 a47f c7cb 6dfb dfaa cae4 |]..\#{sR.g..^...w...`...P..B....m.....| 0x0026 e767 5411 5366 b7f7 b6a7 4fa4 e8f2 a3bd 1a3e f133 20ef 767c 2cb3 63f4 f315 7e57 4ef2 ee2a f7cb |.gT.Sf....O......>.3 .v|,.c...~WN..*..| 0x004c 5dc2 0001 09d3 bd7d f2fc 63a4 3764 8dfa e181 946f e6b3 1bfd 164c 800c f62c 49db fa16 5d03 b73a |]......}..c.7d.....o.....L...,I...]..:| 0x0072 12b7 |..| 670 sshd RET read 116/0x74 670 sshd CALL close(0x5) 670 sshd RET close 0 670 sshd CALL select(0x7,0x285090ac,0,0,0) 670 sshd RET select 1 670 sshd CALL close(0x6) 670 sshd RET close 0 670 sshd CALL select(0x7,0x285090ac,0,0,0) 670 sshd RET select -1 errno 4 Interrupted system call 670 sshd PSIG SIGCHLD caught handler=0x8050550 mask=0x0 code=0x0 670 sshd CALL wait4(0xffffffff,0xbfbfe36c,WNOHANG,0) 670 sshd RET wait4 23570/0x5c12 670 sshd CALL wait4(0xffffffff,0xbfbfe36c,WNOHANG,0) 670 sshd RET wait4 0 670 sshd CALL sigaction(SIGCHLD,0,0xbfbfe30c) 670 sshd RET sigaction 0 670 sshd CALL sigreturn(0xbfbfe3a0) 670 sshd RET sigreturn JUSTRETURN 670 sshd CALL select(0x7,0x285090ac,0,0,0) On Sun, Mar 22, 2009 at 06:00:31PM +0000, marcus@FreeBSD.org wrote: > Synopsis: Failed loading pam_ldap.so from PAM (installed from security/pam_ldap, on FreeBSD 7.1-RELEASE amd64) > > State-Changed-From-To: open->feedback > State-Changed-By: marcus > State-Changed-When: Sun Mar 22 17:59:59 UTC 2009 > State-Changed-Why: > Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=132819 -- ______________________________________________________________________ Alexandr D.Sergeev MSK-IX & Russian Institute for Public Networks E-mail: ales@ripn.net Network Operational Center
Alexandr D. Sergeev wrote: > Good evening! > > The decision to pass on i386 for increase of reliability of system was accepted. > However, on i386 the problem has repeated. > > New system version (7.1 updated to STABLE): > FreeBSD host.ripn.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Mon Mar 23 18:32:22 MSK 2009 ales@host.ripn.net:/usr/obj/usr/src/sys/CUSTOM i386 > > ktrace, kdump: > > > 670 sshd RET select 1 > 670 sshd CALL accept(0x4,0xbfbfe720,0xbfbfee7c) > 670 sshd STRU struct sockaddr { AF_INET, 195.19.26.183:2012 } > 670 sshd RET accept 5 > 670 sshd CALL fcntl(0x5,F_GETFL,0) > 670 sshd RET fcntl 6 > 670 sshd CALL fcntl(0x5,F_SETFL,O_RDWR) > 670 sshd RET fcntl 0 > 670 sshd CALL pipe > 670 sshd RET pipe 6 > 670 sshd CALL socketpair(PF_LOCAL,SOCK_STREAM,0,0xbfbfee70) > 670 sshd RET socketpair 0 > 670 sshd CALL fork > 670 sshd RET fork 23570/0x5c12 > 670 sshd CALL close(0x7) > 670 sshd RET close 0 > 670 sshd CALL write(0x8,0xbfbfe657,0x5) > 670 sshd GIO fd 8 wrote 5 bytes > 0x0000 0000 00b7 00 |.....| > > 670 sshd RET write 5 > 670 sshd CALL write(0x8,0x28530000,0xb6) > 670 sshd GIO fd 8 wrote 182 bytes > 0x0000 0000 00ae 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a50 726f 746f 636f |...............................Protoco| > 0x0026 6c20 320a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a |l 2...................................| > 0x004c 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a |......................................| > 0x0072 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 0a0a 5375 6273 7973 7465 6d09 7366 7470 092f 7573 722f |..................Subsystem.sftp./usr/| > 0x0098 6c69 6265 7865 632f 7366 7470 2d73 6572 7665 720a 0a0a 0a0a 0a0a 0000 0000 |libexec/sftp-server...........| > > 670 sshd RET write 182/0xb6 > 670 sshd CALL close(0x8) > 670 sshd RET close 0 > 670 sshd CALL close(0x9) > 670 sshd RET close 0 > 670 sshd CALL close(0x5) > 670 sshd RET close 0 > 670 sshd CALL gettimeofday(0xbfbfe5fc,0) > 670 sshd RET gettimeofday 0 > 670 sshd CALL getpid > 670 sshd RET getpid 670/0x29e > 670 sshd CALL open(0x2839d21f,O_RDONLY,<unused>0) > 670 sshd NAMI "/dev/urandom" > 670 sshd RET open 5 > 670 sshd CALL read(0x5,0xbfbfe608,0x74) > 670 sshd GIO fd 5 read 116 bytes > 0x0000 5d12 b05c 237b 7352 8767 0ff0 5ede 09c5 7711 e4d9 6082 ce84 50b5 9a42 a47f c7cb 6dfb dfaa cae4 |]..\#{sR.g..^...w...`...P..B....m.....| > 0x0026 e767 5411 5366 b7f7 b6a7 4fa4 e8f2 a3bd 1a3e f133 20ef 767c 2cb3 63f4 f315 7e57 4ef2 ee2a f7cb |.gT.Sf....O......>.3 .v|,.c...~WN..*..| > 0x004c 5dc2 0001 09d3 bd7d f2fc 63a4 3764 8dfa e181 946f e6b3 1bfd 164c 800c f62c 49db fa16 5d03 b73a |]......}..c.7d.....o.....L...,I...]..:| > 0x0072 12b7 |..| > > 670 sshd RET read 116/0x74 > 670 sshd CALL close(0x5) > 670 sshd RET close 0 > 670 sshd CALL select(0x7,0x285090ac,0,0,0) > 670 sshd RET select 1 > 670 sshd CALL close(0x6) > 670 sshd RET close 0 > 670 sshd CALL select(0x7,0x285090ac,0,0,0) > 670 sshd RET select -1 errno 4 Interrupted system call > 670 sshd PSIG SIGCHLD caught handler=0x8050550 mask=0x0 code=0x0 > 670 sshd CALL wait4(0xffffffff,0xbfbfe36c,WNOHANG,0) > 670 sshd RET wait4 23570/0x5c12 > 670 sshd CALL wait4(0xffffffff,0xbfbfe36c,WNOHANG,0) > 670 sshd RET wait4 0 > 670 sshd CALL sigaction(SIGCHLD,0,0xbfbfe30c) > 670 sshd RET sigaction 0 > 670 sshd CALL sigreturn(0xbfbfe3a0) > 670 sshd RET sigreturn JUSTRETURN > 670 sshd CALL select(0x7,0x285090ac,0,0,0) I don't see any indication that sshd is even trying to load pam_ldap.so. Make sure you run ktrace with -d -i to capture forks. Joe > > > On Sun, Mar 22, 2009 at 06:00:31PM +0000, marcus@FreeBSD.org wrote: >> Synopsis: Failed loading pam_ldap.so from PAM (installed from security/pam_ldap, on FreeBSD 7.1-RELEASE amd64) >> >> State-Changed-From-To: open->feedback >> State-Changed-By: marcus >> State-Changed-When: Sun Mar 22 17:59:59 UTC 2009 >> State-Changed-Why: >> Please capture a ktrace/kdump of sshd when trying to load pam_ldap.so. >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=132819 > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome
State Changed From-To: feedback->open From misfiled email caught in spamtrap: Date: Wed, 25 Mar 2009 11:44:11 +0300
----- Forwarded message from Mark Linimon <linimon@lonesome.com> ----- On Thu, Mar 26, 2009 at 10:59:42AM +0000, linimon@FreeBSD.org wrote: > Diagnostics in http://people.freebsd.org/~linimon/kdump.out . [bugmeister > note: the dump was far too large to be suitable for the database] oops: http://people.freebsd.org/~linimon/tmp/kdump.out . mcl ----- End forwarded message -----
We have decided to refuse use pam_ldap in the introduced project, therefore promptness of the decision of a problem is noncritical. The demand priority can be lowered. Thanks for support! ______________________________________________________________________ Alexandr D.Sergeev MSK-IX & Russian Institute for Public Networks E-mail: ales@ripn.net Network Operational Center
State Changed From-To: open->feedback Requested a rebuild of libpam with -DOPENPAM_DEBUG to get more details as to why the module load fails.
State Changed From-To: feedback->closed This was caused by linking OpenLDAP to the ports version of OpenSSL. The pam_ldap module is only supported with OpenLDAP linked to the base OpenSSL. Switching to base OpenSSL has been known to fix this for one user.