We are using cvsd on LDAP enabled systems without any problems for years. But it seems as some kind of bug was introduced, probably when the implementation of the interaction between cvs and cvsd changed (a year ago?). Now with recent versions of cvsd&cvs, whenever we enable LDAP support in /etc/nsswitch.conf: passwd: files ldap shadow: files ldap group: files ldap All cvs operations via cvsd fail. For example: cuse@trinity:~/footest$ cvs -d:pserver:anonymous@cvs.linuxsampler.org:/var/cvs/linuxsampler co libgig cvs [checkout aborted]: received broken pipe signal cvs [checkout aborted]: end of file from server (consult above messages if any) cuse@trinity:~/footest$ With debug verbosity enabled, the log file of cvsd shows this: cvsd: version 1.0.7 starting cvsd: debug: binding :: 2401 family=10 socktype=1 protocol=6 cvsd: listening on :: 2401 cvsd: debug: binding 0.0.0.0 2401 family=2 socktype=1 protocol=6 cvsd: debug: bind() failed (ignored): Address already in use cvsd: debug: nice(1) done cvsd: debug: setgroups(0,NULL) done cvsd: debug: setgid(441) done cvsd: debug: setuid(101) done cvsd: debug: cvs command to execute: '/usr/bin/cvs -f --allow-root=/var/cvs/linuxsampler pserver' cvsd: accepting connections cvsd: connection from x.x.x.x 41819 cvsd: debug: limit coredumpsize to 0(soft) and 0(hard) cvsd: debug: fork() succeeded (child pid=8009) cvsd: debug: select() failed (ignored): Interrupted system call cvsd: cvs command exited with exit-status 1 However, as soon as I disable LDAP support in /etc/nsswitch.conf with: passwd: files shadow: files group: files all cvs operations via cvsd work smoothly again. Here are the use flags we are using for cvs and cvsd: dev-util/cvs-1.12.12-r4 USE="crypt nls pam server -doc -emacs -kerberos" dev-util/cvsd-1.0.7 USE="tcpd" I recompiled cvs without the use flags "crypt", "nls" and of course "pam", but it didn't help, I got the same error again. Btw, the CVS repository directories do not use user accounts mapped by LDAP, only regular, local system accounts. Using cvs locally on that box (that is without using pserver) works smoothly without problems. Our LDAP configuration hasn't changed in years and works flawlessly on our servers. This LDAP-cvsd problem occured on any of our servers we tried. So I'm pretty sure it's a bug in recent versions of either cvsd or probably cvs, or somewhere in between. ;) So far we sticked with old versions of cvsd & cvs to avoid this LDAP related problem, but due to security reasons we cannot do this anymore, so we were forced to upgrade cvsd and cvs. Any pointers or help very much appreciated! Reproducible: Always
I think I narrowed the main problem down a bit: our CVSROOT/passwd files look like this: joe:ENCRYPTEDPASS:cvsd bob:ENCRYPTEDPASS:cvsd ... so we force all cvs commands to be executed as "cvsd" user, not as the user as authenticated to cvsd. But again: cvsd is an ordinary local unix account, not a LDAP user account.
please retry with 1.0.17
