Bugzilla Bug 97618

Please see the URL that demonstrates the problem I am seeing. I have determined
this to be nss_ldap from another user's post. Using nss_ldap-207-r1 adding users
to groups that don't have 'domain' in them works fine.

Other versions such as nss_ldap-238 and nss_ldap-226 do not work correctly
(these are the only ones I have tested).

For example, when a group is "full" (thats the way it seems) or screwed up
(can't add anymore user's to the group with smbldap-tools), issue the command
'id lhart1' (lhart1 is a user that was already added in LDAP), it gives the
follow error:

acad1 ~ # id lhart1
id: io.c:171: ber_free_buf: Assertion `((ber)->ber_opts.lbo_valid==0x2)'
failed.
uid=10214(lhart1) gid=505Aborted

Other tools that use nss_ldap also act strange/don't work. 'net groupmap list'
produces a segmentation fault in this condition; smbldap-useradd also gives a
segmentation fault.

I have verified things do work right with nss_ldap-207-r1.ebuild.
Please see the URL that demonstrates the problem for more details.

Reproducible: Always
Steps to Reproduce:
1. Install Gentoo 2005.0; emerge samba, nss_ldap, pam_ldap, and all related
packages for a Samba PDC w/ LDAP support. Setup a LDAP server. Configure Samba
for PDC w/ LDAP, configure smbldap-tools. Use smbldap-populate to initially
populate the LDAP tree.
2. Add a group w/ Samba mappings that doesn't have the word 'domain' in it, such
as 'users'.
3. Create a script that adds a whole bunch of users: i.e,
"smbldap_tools/smbldap-useradd -a -g users -c \"$Ofirst,$Olast,$studentnum\" -C
'\\\\HOST\\homes\\$username' -d $homedir/$username -m $username" for a whole
bunch of users -- ~20,000
4. Run your script, wait till you get about ~120 users (the other girl that had
the same problem said she could only add 116 users before things started
crapping out).
5. If you stop your script and remove the users just added; then change the
primary group to something such as 'domain users', it will add all of the users
without hesitation.

Actual Results:  
nss_ldap crapped out... basically nothing LDAP related (anything that uses
nss_ldap) works.

Expected Results:  
Add all of the users.

I am running a VMware virtual machine on ESX 2.5; the virtual machine has 256MB
RAM, 4GB hard drive, BusLogic SCSI, PCnet/PCI II NIC.

Please see the following posts for more information:
http://lists.samba.org/archive/samba/2005-June/107603.html
http://lists.samba.org/archive/samba/2005-June/107589.html
http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-linux/2004-04/0034.html

The only version that I have tried so far that works is nss_ldap-207-r1. I have
updated the 238 version ebuild of nss_ldap to 239, but it has the same problem.
Version 238 and 226 also do not work correctly.

I can't reproduce your problem in my setup, and I've never run into anything of 
the sort, and I used nss_ldap-238 (on production network).

I've got 500+ users in active production on a LDAP server, incl Samba with PDC-
LDAP.

My 'users' group contains all 500+ users.

The only difference is that I don't use smbldap-tools at all.

If you wish to continue this bug, please attach your exact configuration files 
for everything you mentioned in #1. Additionally, if you can reproduce the 
error with a single command from a dump-snapshot of your LDAP tree, include the 
command and the LDAP tree dump-snapshot.

When doing heavy adding work, I've found it can help greatly to DISABLE nscd, 
and NOT create the directories at all initially - just populate the LDAP 
database first, then re-enable NSCD, and create the home directories.

openldap is patched now.
2.1.30-r5 and 2.2.27-r1 have the patch.
2.1.30-r5 is the ebuild that should go stable. 
2.2.27-r1 (and the 2.2 series in general) will be considered for stable in 30 
days).

oops wrong bug.

please reopen with the required configuration files.

Created an attachment (id=62809) [edit]
dump of ldap tree

Created an attachment (id=62810) [edit]
slapd conf

Created an attachment (id=62811) [edit]
samba conf

Bug has not been resolved... Older versions of nss_ldap work fine, yet the 
newer version do not (please see first bug description).

Also attached is my smb.conf and slapd.conf. NOTE: ldbm is shown as the 
backend in slapd.conf, yet I have also used bdb, and they both give them same 
results.

Also, I have tested nss_ldap version 215 and it works fine.

OK, I've also tried to replicate your problem.  Now, I know that a few hundred
users in groups works OK on my setup, but like Robin I don't use smbldap-tools.
 So I setup a test server, and added a few hundred with smbldap-tools, just like
in your step-by-step, and had zero problems.

Next, I used your slapd.conf (with a couple modifications, like dropping the
local schema additions, and no loglevel), and imported your slapcat dump file. 
Now, nscd didn't like it, but once I shut down nscd it worked A-OK.

BTW, what you described in your mail to the Samba list was NOT shutting down
nscd.    Samba has nothing to do with nscd; it's independent software. 
Commenting everything out in nscd.conf only makes it fall back to default values
when restarted.  You would disable nscd with "/etc/init.d/nscd stop" and prevent
it from starting up on the next boot with "rc-update del nscd default".

Oh, I forgot to mention software versions.
    net-nds/openldap-2.2.26-r2
    sys-auth/nss_ldap-226
    smbldap-tools 0.9.0
    sys-libs/glibc-2.3.4.20040808-r1 (qpkg reports that /usr/sbin/nscd comes
from glibc)

I have discovered "--enable-rfc2307bis" configure option breaks nss_ldap. But
something else must have changed throughout the nss_ldap history (that causes
this problem) because version 215 of nss_ldap works for me, but it also has
"--enable-rfc2307bis" in the ebuild.

Also, the groups that screw up seem to be only ones that have a group name of 6,
7 or 8 characters.

I have confirmed the same thing happens with nss_ldap-238 from PADL's site.

Is there anyway I can compile nss_ldap with debugging support that spits all the
info out to a file? I know its kind of a wierd bug, but I have reproduced it on
2 systems.

sorry about the lack of response.
It does turn out to be an upstream nss_ldap bug, an obscure one.
Please retest with the latest nss_ldap-249 that I just put in the tree, it
should be fixed up.

please test the nss_ldap-250 that I just commited to ~arch. Upstream has
changed some of the group stuff.

Marc: 
I'd appreciate responses on the bug rather than direct email.
Could you try to add a lot of test users to see if it still occurs?

Hi Robin,


I setup a new test VM and used nss_ldap-250. After adding about 1,200 users,
this started happening:

Error: h

Hi Robin,


I setup a new test VM and used nss_ldap-250. After adding about 1,200 users,
this started happening:

Error: hµ at /usr/sbin//smbldap_tools.pm line 1005.
Error: `hø³ at /usr/sbin//smbldap_tools.pm line 1005.

This continues for every user its tries to add. I tried simply adding a user
after the I killed my script:

esdev2 log # /usr/sbin/smbldap-useradd -a -g 'students' -c
"Ofirst,Olast,studentnum" -C '\\ESFREMONT\blah' -d /home/fac_staff/blah -m -N
"Ofirst Olast" blah
Error: hï¶ at /usr/sbin//smbldap_tools.pm line 1005.
esdev2 log # 

So maybe it is now a problem with smbldap-tools?

It did get a lot farther! =)
Thank you very much for your time.


--Marc

ok, upstream make some more fixes to the group stuff finally.
please test nss_ldap-253.
for what I can see, there were some lurking problems before, but anything
further now will probably belong to samba.

This must be a problem with Samba and/or smbldap-tools now:

esdev2 ~ # smbldap-useradd -a -g students blah
Error: 

This must be a problem with Samba and/or smbldap-tools now:

esdev2 ~ # smbldap-useradd -a -g students blah
Error: ¨hµ at /usr/sbin//smbldap_tools.pm line 1056.

Thanks for your time and help!

marc: since this bug is quite long already, could you please open a new bug and
assign it to the samba folk, or pursue it yourself upstream?