Yes, I'm sure.
Here is the output of `diff -u /usr/src/etc/nsswitch.conf /etc/nsswitch.conf'.
--- /usr/src/etc/nsswitch.conf 2010-03-08 09:04:25.000000000 +0800
+++ /etc/nsswitch.conf 2010-03-08 18:01:08.000000000 +0800
@@ -1,13 +1,13 @@
#
# nsswitch.conf(5) - name service switch configuration file
-# $FreeBSD: src/etc/nsswitch.conf,v 1.1.10.1 2009/08/03 08:13:06 kensmith Exp $
+# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $
#
group: compat
-group_compat: nis
+group_compat: ldap nis
hosts: files dns
networks: files
passwd: compat
-passwd_compat: nis
+passwd_compat: ldap nis
shells: files
services: compat
services_compat: nis
The line `+:*::::::::' has already put into /etc/master.passwd,
and the line `+:*::' has already put into /etc/group.
In fact, my 2 machines were upgraded on different days.
The 1st one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar 8 10:21:45 CST
2010
The 2nd one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 03:46:38 CST
2010
Both of them cannot work properly.
It can prove that this problem can be reproduced since 2/24 or earlier.
Besides, I precisely followed the 11-step instructions that described in
/usr/src/Makefile for upgrading my systems.
To do mergemaster is never a big problem for me because I've used it since this
script was born.
/usr/local/etc/ldap.conf & /usr/local/etc/nss_ldap.conf are also consistent on
my 4 machines.
These settings works properly for my RELENG_7 machines, but RELENG_8 ones.
By the way, I don't use nscd because it always caches users' login shell so
that users cannot update it immediately.
I also installed pam_ldap, and I have read this old topic:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041393.html
It says to set `bind_policy' to `hard' can resolve this issue, but it cannot
work for me.
--------------------------------------------------
From: "Peter C. Lai" <pe...@simons-rock.edu>
Sent: Tuesday, March 09, 2010 8:08 AM
To: "Ling-hua Tseng" <ura...@tinlans.org>
Cc: <freebsd-stable@freebsd.org>
Subject: Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap
Unable to reproduce, at least on a brand new 8-R install.
Did you make sure you correctly merged /etc/nsswitch.conf during mergemaster?
On 2010-03-08 09:07:12PM +0800, Ling-hua Tseng wrote:
Today I upgraded 2 of my 4 machines from RELENG_7 to RELENG_8.
Both of the 2 machines are just LDAP clients.
My LDAP server is still running on RELENG_7,
and the remained one is also a LDAP client.
All of them were installed OpenLDAP-2.4.21 and nss_ldap-1.265_3.
Before I upgrades my system, everything works properly.
I added a group named `group1' on LDAP server,
and then add a user named `user1' to this group.
I can type `id user1' to see the following line:
uid=3000(user1) gid=3000(user1) groups=3000(user1),10000(gorup1)
Of course, now the following record is already my LDAP server:
--
dn: cn=group,ou=group,dc=mydomain,dc=org
objectClass: posixGroup
cn: group1
gidNumber: 10000
memberUid: user1
--
After I upgraded these 2 machines from RELENG_7 to RELENG_8,
to type `id user1' could only show the following information:
uid=3000(user1) gid=3000(user1) groups=3000(user1)
This user's supplementary group was gone,
and he couldn't write any group-writable files which had gid 10000 one the 2
machines.
But in my other 2 machines that running on RELENG_7,
this problem is still not occured.
I have logged the behaviors of RELENG_7 & RELENG_8.
Here is the behavior when I type `id user1' on RELENG_7:
--
conn=1007 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1007 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
shadowLastChange shadowMax shadowExpire loginClass
conn=1007 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup))"
conn=1007 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup)(gidNumber=10000))"
conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
--
In step 2, it tries to fetch out the full group list from my LDAP server.
According to this information, it can know what user1's supplementary groups
are.
RELENG_8:
--
conn=1008 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixAccount)(uid=user1))"
conn=1008 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
shadowLastChange shadowMax shadowExpire loginClass
conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0
filter="(&(objectClass=posixGroup)(gidNumber=3000))"
conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
--
It never tried to get the group list from LDAP server,
hence it's impossible to know user1's supplementary groups.
The client settings on RELENG_7 & RELENG_8 are fully consistent,
so I don't think it's the problem of my config files.
Since my 4 machines use the same version of nss_ldap,
to downgrade nss_ldap's version for testing is meaningless.
Should this problem is a base system's bug?
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--
===========================================================
Peter C. Lai | Bard College at Simon's Rock
Systems Administrator | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu | (413) 528-7428
===========================================================
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
