Bug 124549 - getent fails when takes data from ldap
getent fails when takes data from ldap
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-27 09:39 EDT by Alexander Kolesnik
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-07 11:55:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexander Kolesnik 2004-05-27 09:39:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Opera 
7.23  [en]

Description of problem:
I had working ldap configuration under FC1 that took user's 
information from W2K active directory until I've installed Fedora 
Core 2. After the upgrade (via yum), an error appears when I run 
`getent group' command:
[root@alexkol-vm etc]# getent group                 
root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:
disk:x:6:root
lp:x:7:daemon,lp
mem:x:8:
kmem:x:9:
wheel:x:10:root
mail:x:12:mail
news:x:13:news
uucp:x:14:uucp
man:x:15:
games:x:20:
gopher:x:30:
dip:x:40:
ftp:x:50:
lock:x:54:
nobody:x:99:
users:x:100:
rpm:x:37:
floppy:x:19:
vcsa:x:69:
utmp:x:22:
slocate:x:21:
nscd:x:28:
sshd:x:74:
rpc:x:32:
rpcuser:x:29:
nfsnobody:x:65534:
mailnull:x:47:
smmsp:x:51:
pcap:x:77:
apache:x:48:
squid:x:23:
webalizer:x:67:
dbus:x:81:
named:x:25:
ntp:x:38:
desktop:x:80:
gdm:x:42:
dovecot:x:97:
postgres:x:26:
xfs:x:43:
getent: ../../../libraries/liblber/sockbuf.c:82: ber_sockbuf_ctrl: 
Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )' failed.
Aborted

"xfs:x:43:" - is the last line of /etc/group file. The next - should 
be an entry from the active directory, but the program fails.

Probably, there is no need to have an active directory - plain 
ldap-server would satisfy.

Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
1. Install FC1
2. Configure ldap.conf and nsswitch.conf
3. rpm -Uhv yum-2.0.7-1.1.noarch.rpm
4. rpm -Uhv fedora-release-2-4.i386.rpm
5. Run `yum upgrade'
6. Run `getent group'
   

Additional info:

[root@alexkol-vm etc]# cat /etc/ldap.conf | grep -v "^#" | grep -v 
"^$"
host ad.domain.com
base dc=domain,dc=com
ldap_version 3
binddn cn=user,cn=Users,dc=domain,dc=com
bindpw pass
port 389
scope sub
pam_filter objectclass=User
pam_login_attribute sAMAccountName
pam_password ad
nss_base_passwd cn=Users,dc=domain,dc=com?one
nss_base_shadow cn=Users,dc=domain,dc=com?one
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute cn sAMAccountName
nss_map_attribute uniqueMember member
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_objectclass posixGroup Group
ssl no


[root@alexkol-vm etc]# cat /etc/nsswitch.conf | grep -v "^#" | grep 
-v "^$"         
passwd:     files ldap
shadow:     files ldap
group:      files ldap
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files ldap
rpc:        files
services:   files ldap
netgroup:   files ldap
publickey:  nisplus
automount:  files ldap
aliases:    files nisplus
Comment 1 Alexander Kolesnik 2004-05-27 09:49:26 EDT
Due to this bug, no other tools that use getgrent() call work..
Comment 2 Alexander Kolesnik 2004-05-27 09:58:13 EDT
installing openldap package from the FC1 doesn't help :-(
Comment 3 Alexander Kolesnik 2004-05-27 10:14:43 EDT
Using the kernel from FC1 (2.4.22-1.2188.nptl) solves the problem. 
So, it looks like the 2.6 kernel problem.
Comment 4 Alexander Kolesnik 2004-07-07 11:55:14 EDT
Problem looks like disappeared after upgrading to the new kernel
version (2.6.6-1.435.2.3)

Note You need to log in before you can comment on or make changes to this bug.