Hi Rich,
On 11/01/2013 02:22 PM, Rich Megginson wrote:
> All ldapsearch scripts are executed in background = in parallel
way.
> But server process them in serial way. I can tell that by increasing
> time needed to process ldapsearches. Increment around 2sec is caused
> by pam_unix delay because of wrong password.
>
> Is 389 bind process really serialized? Or have I just overlooked some
> limit?
PAM is not thread safe, in our experience, so we have to serialize calls
into PAM.
thank you for confirmation of my observation.
In fact I'm able to put my 389 server into deadlock.
I've written simple auth script for libpam-script [1] It's purpose is to
check pasword of user in other than main entry, attached.
Content of /etc/pam.d/ldapserver:
auth required /lib/security/pam_script.so onerr=fail
dir=/usr/share/libpam-script
account required /lib/security/pam_script.so onerr=fail
dir=/usr/share/libpam-script
[root@pdap 8445]# ls -l /usr/share/libpam-script
total 8
lrwxrwxrwx 1 root root 11 Oct 31 17:52 pam_script_acct -> perlauth.pl
lrwxrwxrwx 1 root root 11 Oct 31 17:52 pam_script_auth -> perlauth.pl
-rwxr-xr-x 1 root root 2450 Oct 31 19:45 perlauth.pl
It works fine in it's serialized way - until there is maximum 29
parallel connections.
If there is 30 or more parallel connections 389 hangs for ever. Very
often killing process ldapsearch process does not help. Server is very
often unable to restart so I have to kill it with -9.
My question is if there is any limit related to number of parallel bind
operations. I guess there is something to related to 30 or more likely
to 60 - my plugin itself open next connection to the same LDAP server.
Thanks
[1]
http://sourceforge.net/projects/pam-script/--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/