[Pkg-shadow-devel] Bug#498635: Bug#498635: passwd: useradd -r and groupadd -r don't play nicely with ldap

Fri Sep 12 16:46:51 UTC 2008

* Nicolas François <nicolas.francois at centraliens.net> [20080911 18:21]:
> Hello,
> 
> On Thu, Sep 11, 2008 at 09:44:36AM -0700, benp at reed.edu wrote:
> > 
> > "useradd -r" and "groupadd -r" hang "forever" when run on a system that 
> 
> Does "forever" means "a long time" ?

I haven't had a chance to try waiting forever (hard to find the time),
but I've never seen the command run to completion.  I've always had to
interrupt it.  I've let it run as long as 15 minutes.

> (I assume you made no changes to /etc/login.defs)

Correct.

> Do you have a group/user ID with an high value?

We've got a sizeable LDAP infrastructure (a couple thousand users, a few
hundred groups) with plenty of users and groups with high id values.  

> Do you have a group/user ID with an high value in the 0-1000 range?

We do have some legacy groups and users in the 0-1000 range.

> Do you have a lot of system groups/users?

Just the default set of system groups and users.

> Could "forever" mean doing a large number of LDAP requests?
>
> Does it also take "forever" when you force the user or group ID?
> Could you strace useradd/groupadd when it takes "forever"?

It *could* mean that the system is doing a large number of LDAP
requests, but an strace on the process doesn't indicate that.  When
running under strace the command stalls in a 'poll' against one of our
LDAP servers.  I can see it reading hundreds of groups from our LDAP
server, lots of lines like this:

    29888 read(7, "\"cn=admnstf,ou=Group,dc=reed,dc=e"..., 74) = 74
    29888 read(7, "#cn=alifeprj,ou=Group,dc=reed,dc="..., 106) = 106
    29888 read(7, "!cn=art201,ou=Group,dc=reed,dc=ed"..., 98) = 98
    29888 read(7, "!cn=art318,ou=Group,dc=reed,dc=ed"..., 73) = 73
    29888 read(7, "!cn=art345,ou=Group,dc=reed,dc=ed"..., 73) = 73
    29888 read(7, "!cn=art347,ou=Group,dc=reed,dc=ed"..., 73) = 73

Not sure what the initial "!", "#", and "\" characters in the strace
output indicate.

Looking on the LDAP server I see the query logged this way (IP addr
redacted):

    Sep 12 08:56:12 ldap slapd[24932]: conn=614205 fd=48 ACCEPT from IP=xxx.xxx.xxx.xxx:57265 (IP=0.0.0.0:389)
    Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=0 BIND dn="" method=128
    Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=0 RESULT tag=97 err=0 text=
    Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=1 SRCH base="dc=reed,dc=edu" scope=2 deref=0 filter="(&(objectClass=posixGroup))"
    Sep 12 08:56:12 ldap slapd[24932]: conn=614205 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
    Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=1 SEARCH RESULT tag=101 err=0 nentries=364 text=
    Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SRCH base="dc=reed,dc=edu" scope=2 deref=0 filter="(&(objectClass=posixGroup))"
    Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
    Sep 12 08:56:13 ldap slapd[24932]: conn=614205 op=2 SEARCH RESULT tag=101 err=4 nentries=136 text=
    Sep 12 09:07:48 ldap slapd[24932]: conn=614205 fd=48 closed (idletimeout)

i.e. the search found and returned 364 posixgroup entries within 1
second.

But in the end the command stalls at the last "poll" line in the strace
output below (IP addrs redacted):

    29888 read(8, "$cn=natsciweb,ou=Group,dc=reed,dc"..., 113) = 113
    29888 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
    29888 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
    29888 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=8, revents=POLLIN}])
    29888 read(8, "0\f\2\1\3e\7\n"..., 8)   = 8
    29888 read(8, "\1\4\4\0\4\0"..., 6)     = 6
    29888 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
    29888 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
    29888 stat("/etc/libnss-ldap.conf", {st_mode=S_IFREG|0644, st_size=8385, ...}) = 0
    29888 geteuid()                         = 0
    29888 getsockname(8, {sa_family=AF_INET, sin_port=htons(54239), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, [16]) = 0
    29888 getpeername(8, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, [68719476752]) = 0
    29888 stat("/etc/libnss-ldap.conf", {st_mode=S_IFREG|0644, st_size=8385, ...}) = 0
    29888 geteuid()                         = 0
    29888 getsockname(8, {sa_family=AF_INET, sin_port=htons(54239), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, [16]) = 0
    29888 getpeername(8, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, [68719476752]) = 0
    29888 poll([{fd=8, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = ?  ERESTART_RESTARTBLOCK (To be restarted)
    29888 --- SIGINT (Interrupt) @ 0 (0) ---
    29888 +++ killed by SIGINT +++

That's me sending the SIGINT at the end, after waiting 15 minutes.

> > is configured to use libnss-ldap (with ldap references for "passwd" and
> > "group" in /etc/nsswitch.conf).  I use the following ldap related
> > configs in nsswitch.conf:
> > 
> >     passwd_compat: ldap
> >     group:      files ldap
> >     netgroup:   files ldap
> > 
> > The impact of this problem can be very ugly. In the case of an etch
> > to lenny upgrade, packages like libuuid1 try to create a "system"
> > group necessitates killing the stalled "apt-get dist-upgrade" process.
> 
> Once it's killed, is the group created or are you able to create it
> manually?

Once killed the group has not been created

> What version of libuuid1 is it?

libuuid1 version is 1.41.0-3.

> Is it the same bug as in #487443? (http://bugs.debian.org/487443)

I don't think so, I have an unmodified /etc/adduser.conf (no spaces
in the key/value pairs).

> What groupadd command line is used?

groupadd -r foofoo

And in the case of libuuid (/var/lib/dpkg/info/libuuid1.postinst):

    groupadd -f -K GID_MIN=$FIRST_SYSTEM_GID \
        -K GID_MAX=$LAST_SYSTEM_GID libuuid

Also for what it's worth "addgroup" (from the "adduser" package)
successfully runs:

    # addgroup --system foofoo
    Adding group `foofoo' (GID 117) ...

I see that the -r/--system flags are new to the groupadd command in
lenny. 

> > It'd be really really nice to resolve this before lenny's released.
> 
> I currently have no way to debug it.
> I will try to see if I get some ideas based on the answers to the
> questions above.
>
> Thanks in advance,

Thank you!  Please let me know if I can answer any further questions.

Ben
-- 
________________________________________________________________________
PGP fingerprint:      A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20080912/fdc5ee43/attachment.pgp 