Hello everyone. Can you clarify the situation about nested groups? When I use rfc2307bis I'm not able to get membership from nested groups. Example: GRP-SVC-SSH-NODE |- user1 |- user2
GRP-SVC-SSH-NODE1 |- GRP-SVC-SSH-NODE
Users from GRP-SVC-SSH-NODE are not members of GRP-SVC-SSH-NODE1.
In previous version 1.3.1 it works, but from 1.4 version it is not working. As I may see in "src/providers/ldap/sdap_async_accounts.c":
/* FIXME: we ignore nested rfc2307bis groups for now */ filter = talloc_asprintf(grp_state, "(objectclass=%s)", opts->user_map[SDAP_OC_USER].name);
Also the same situation with LDAP memberOf attribute. It just create "originalMemberOf" entry, but do nothing with it.
Maybe the problem is because of groups are stored in different OU:
OU=COMPUTE |-OU=GROUP-ACCESS |- cn=GRP-SVC-SSH-NODE |- ou=SSH-GROUPS |-cn=GRP-SVC-SSH-NODE01
which means: GRP-SVC-SSH-NODE = cn=GRP-SVC-SSH-NODE,ou=GROUP-ACCESS,ou=COMPUTE, dc...... GRP-SVC-SSH-NODE1 = cn=GRP-SVC-SSH-NODE1,ou=SSH-GROUPS,ou=GROUP-ACCESS,ou=COMPUTE, dc.....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 08:13 AM, Sergei V. Kovylov wrote:
Hello everyone. Can you clarify the situation about nested groups? When I use rfc2307bis I'm not able to get membership from nested groups.
Example: GRP-SVC-SSH-NODE |- user1 |- user2
GRP-SVC-SSH-NODE1 |- GRP-SVC-SSH-NODE
Users from GRP-SVC-SSH-NODE are not members of GRP-SVC-SSH-NODE1.
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
In previous version 1.3.1 it works, but from 1.4 version it is not working. As I may see in "src/providers/ldap/sdap_async_accounts.c":
/* FIXME: we ignore nested rfc2307bis groups for now */ filter = talloc_asprintf(grp_state, "(objectclass=%s)", opts->user_map[SDAP_OC_USER].name);
Also the same situation with LDAP memberOf attribute. It just create "originalMemberOf" entry, but do nothing with it.
Maybe the problem is because of groups are stored in different OU:
OU=COMPUTE |-OU=GROUP-ACCESS |- cn=GRP-SVC-SSH-NODE |- ou=SSH-GROUPS |-cn=GRP-SVC-SSH-NODE01
which means: GRP-SVC-SSH-NODE = cn=GRP-SVC-SSH-NODE,ou=GROUP-ACCESS,ou=COMPUTE, dc...... GRP-SVC-SSH-NODE1 = cn=GRP-SVC-SSH-NODE1,ou=SSH-GROUPS,ou=GROUP-ACCESS,ou=COMPUTE, dc.....
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
I'm using getnet passwd and getent group to define if groups and users come to sssd from LDAP. # getent group GRP-SVC-SSH-NODE01 GRP-SVC-SSH-NODE01:*:31002:
# getent group GRP-SVC-SSH-NODE GRP-SVC-SSH-NODE:*:30001:skovylov,azvarich
#ldbsearch -H /var/lib/sss/db/cache_MD.METEORF.RU.ldb # record 36 dn: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb createTimestamp: 1289569193 gidNumber: 31002 name: GRP-SVC-SSH-INODE01 objectClass: group originalDN: cn=GRP-SVC-SSH-INODE01,ou=SVC-SSH,ou=GROUP-ACCESS,ou=COMPUTE,dc=<skipped> originalModifyTimestamp: 20101012084647Z lastUpdate: 1289569193 dataExpireTimestamp: 1289574593 distinguishedName: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (7): Adding original DN [cn=GRP-SVC-SSH-NODE,ou=GROUP-ACC ESS,ou=COMPUTE,dc=<skipped>] to attributes of [GRP-SVC-SSH-NODE]. (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (6): Storing info for group GRP-SVC-SSH-NODE (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x5e5e60
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x5e5f10
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Destroying timer event 0x5e5f10 "ltdb_timeout"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Ending timer event 0x5e5e60 "ltdb_callback"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sysdb_search_group_by_name] (6): Error: 2 (No such file or directory) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): start ldb transaction (nesting: 1) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x634930
Also I have noticed, that if remove member GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE1, wait some time and then return membership back - then users become a member of GRP-SVC-SSH-NODE1 untill reinstalling sssd package. It seems like sssd ignore entries that are not created yet.
Also sorry for mistake, latest working version is sssd-1.3.0 instead of sssd-1.3.1. 1.3.1 contains the same issue.
2010/11/12 Sergei V. Kovylov serejka@gmail.com:
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
I'm using getnet passwd and getent group to define if groups and users come to sssd from LDAP. # getent group GRP-SVC-SSH-NODE01 GRP-SVC-SSH-NODE01:*:31002:
# getent group GRP-SVC-SSH-NODE GRP-SVC-SSH-NODE:*:30001:skovylov,azvarich
#ldbsearch -H /var/lib/sss/db/cache_MD.METEORF.RU.ldb # record 36 dn: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb createTimestamp: 1289569193 gidNumber: 31002 name: GRP-SVC-SSH-INODE01 objectClass: group originalDN: cn=GRP-SVC-SSH-INODE01,ou=SVC-SSH,ou=GROUP-ACCESS,ou=COMPUTE,dc=<skipped> originalModifyTimestamp: 20101012084647Z lastUpdate: 1289569193 dataExpireTimestamp: 1289574593 distinguishedName: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (7): Adding original DN [cn=GRP-SVC-SSH-NODE,ou=GROUP-ACC ESS,ou=COMPUTE,dc=<skipped>] to attributes of [GRP-SVC-SSH-NODE]. (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (6): Storing info for group GRP-SVC-SSH-NODE (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x5e5e60
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x5e5f10
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Destroying timer event 0x5e5f10 "ltdb_timeout"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Ending timer event 0x5e5e60 "ltdb_callback"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sysdb_search_group_by_name] (6): Error: 2 (No such file or directory) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): start ldb transaction (nesting: 1) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x634930
Also I have noticed, that if remove member GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE1, wait some time and then return membership back - then users become a member of GRP-SVC-SSH-NODE1 untill reinstalling sssd package. It seems like sssd ignore entries that are not created yet.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 09:39 AM, Sergei V. Kovylov wrote:
Also sorry for mistake, latest working version is sssd-1.3.0 instead of sssd-1.3.1. 1.3.1 contains the same issue.
That's not possible. SSSD 1.3.0 and 1.3.1 are identical, except for a completely unrelated single change in authentication code.
If you're seeing a difference in behavior between 1.3.0 and 1.3.1, something else is going on.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 09:37 AM, Sergei V. Kovylov wrote:
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
I'm using getnet passwd and getent group to define if groups and users come to sssd from LDAP. # getent group GRP-SVC-SSH-NODE01 GRP-SVC-SSH-NODE01:*:31002:
# getent group GRP-SVC-SSH-NODE GRP-SVC-SSH-NODE:*:30001:skovylov,azvarich
please also include the output of id skovylov and/or id azvarich
I want to see if initgroups is also misbehaving, or if it's only getgrnam
#ldbsearch -H /var/lib/sss/db/cache_MD.METEORF.RU.ldb # record 36 dn: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb createTimestamp: 1289569193 gidNumber: 31002 name: GRP-SVC-SSH-INODE01 objectClass: group originalDN: cn=GRP-SVC-SSH-INODE01,ou=SVC-SSH,ou=GROUP-ACCESS,ou=COMPUTE,dc=<skipped> originalModifyTimestamp: 20101012084647Z lastUpdate: 1289569193 dataExpireTimestamp: 1289574593 distinguishedName: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (7): Adding original DN [cn=GRP-SVC-SSH-NODE,ou=GROUP-ACC ESS,ou=COMPUTE,dc=<skipped>] to attributes of [GRP-SVC-SSH-NODE]. (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (6): Storing info for group GRP-SVC-SSH-NODE (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x5e5e60
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x5e5f10
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Destroying timer event 0x5e5f10 "ltdb_timeout"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Ending timer event 0x5e5e60 "ltdb_callback"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sysdb_search_group_by_name] (6): Error: 2 (No such file or directory) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): start ldb transaction (nesting: 1) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x634930
Also I have noticed, that if remove member GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE1, wait some time and then return membership back - then users become a member of GRP-SVC-SSH-NODE1 untill reinstalling sssd package. It seems like sssd ignore entries that are not created yet. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
# id skovylov uid=15001(skovylov) gid=15000(mcc-rhm) группы=15000(mcc-rhm),31000(GRP-SVC-SSH-IFRONT1),30000(GRP-SVC-SSH-IFRONT),30004(GRP-SVC-SSH-XFRONT),30006(GRP-SVC-SUDO-NODE),30001(GRP-SVC-SSH-NODE),31021(GRP-SVC-SSH-XPBS2),30005(GRP-SVC-SSH-XTECH),30007(GRP-SVC-SUDO-XPBS),30003(GRP-SVC-FTP-IMDS),30002(GRP-SVC-SSH-IMDS)
2010/11/12 Stephen Gallagher sgallagh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 09:37 AM, Sergei V. Kovylov wrote:
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
I'm using getnet passwd and getent group to define if groups and users come to sssd from LDAP. # getent group GRP-SVC-SSH-NODE01 GRP-SVC-SSH-NODE01:*:31002:
# getent group GRP-SVC-SSH-NODE GRP-SVC-SSH-NODE:*:30001:skovylov,azvarich
please also include the output of id skovylov and/or id azvarich
I want to see if initgroups is also misbehaving, or if it's only getgrnam
#ldbsearch -H /var/lib/sss/db/cache_MD.METEORF.RU.ldb # record 36 dn: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb createTimestamp: 1289569193 gidNumber: 31002 name: GRP-SVC-SSH-INODE01 objectClass: group originalDN: cn=GRP-SVC-SSH-INODE01,ou=SVC-SSH,ou=GROUP-ACCESS,ou=COMPUTE,dc=<skipped> originalModifyTimestamp: 20101012084647Z lastUpdate: 1289569193 dataExpireTimestamp: 1289574593 distinguishedName: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (7): Adding original DN [cn=GRP-SVC-SSH-NODE,ou=GROUP-ACC ESS,ou=COMPUTE,dc=<skipped>] to attributes of [GRP-SVC-SSH-NODE]. (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (6): Storing info for group GRP-SVC-SSH-NODE (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x5e5e60
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x5e5f10
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Destroying timer event 0x5e5f10 "ltdb_timeout"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Ending timer event 0x5e5e60 "ltdb_callback"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sysdb_search_group_by_name] (6): Error: 2 (No such file or directory) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): start ldb transaction (nesting: 1) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x634930
Also I have noticed, that if remove member GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE1, wait some time and then return membership back - then users become a member of GRP-SVC-SSH-NODE1 untill reinstalling sssd package. It seems like sssd ignore entries that are not created yet. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzdVUQACgkQeiVVYja6o6ORhACfVHwVwpDjrxWRQD620dqVnYpP VzEAnjfzrktPuxeZRNJUAxj29e8aUHNk =aPCa -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Stephen, you are right 1.3.1 is working version too. I have made some experiment and found out that: 1. The behaviour of sssd (1.3.1) depends on how to create OU on LDAP server. If OU with groups is created after all users' OUs then sssd gets everything correctly. Example: correct sequence: ou=MCC (users) ou=HMC (users) ou=GROUP-ACCESS (groups)
incorrect sequence: ou=GROUP-ACCESS (groups) ou=MCC (users) ou=HMC (users)
2. sssd 1.4.x doesn't work even with correct sequence of OU creation (see above). 3. if I remove GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE and recreate membership back then sssd will see members of GRP-SVC-SSH-NODE in GRP-SVC-SSH-NODE group but untill new installation or reinstallation of sssd.
2010/11/12 Sergei V. Kovylov serejka@gmail.com:
# id skovylov uid=15001(skovylov) gid=15000(mcc-rhm) группы=15000(mcc-rhm),31000(GRP-SVC-SSH-IFRONT1),30000(GRP-SVC-SSH-IFRONT),30004(GRP-SVC-SSH-XFRONT),30006(GRP-SVC-SUDO-NODE),30001(GRP-SVC-SSH-NODE),31021(GRP-SVC-SSH-XPBS2),30005(GRP-SVC-SSH-XTECH),30007(GRP-SVC-SUDO-XPBS),30003(GRP-SVC-FTP-IMDS),30002(GRP-SVC-SSH-IMDS)
2010/11/12 Stephen Gallagher sgallagh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 09:37 AM, Sergei V. Kovylov wrote:
What command are you using to check this? Can you tell me if getent group GRP-SVC-SSH-NODE1 shows the users from GRP-SVC-SSH-NODE?
What about: id <user from GRP-SVC-SSH-NODE> Does that show the user as a member of both groups?
I'm using getnet passwd and getent group to define if groups and users come to sssd from LDAP. # getent group GRP-SVC-SSH-NODE01 GRP-SVC-SSH-NODE01:*:31002:
# getent group GRP-SVC-SSH-NODE GRP-SVC-SSH-NODE:*:30001:skovylov,azvarich
please also include the output of id skovylov and/or id azvarich
I want to see if initgroups is also misbehaving, or if it's only getgrnam
#ldbsearch -H /var/lib/sss/db/cache_MD.METEORF.RU.ldb # record 36 dn: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb createTimestamp: 1289569193 gidNumber: 31002 name: GRP-SVC-SSH-INODE01 objectClass: group originalDN: cn=GRP-SVC-SSH-INODE01,ou=SVC-SSH,ou=GROUP-ACCESS,ou=COMPUTE,dc=<skipped> originalModifyTimestamp: 20101012084647Z lastUpdate: 1289569193 dataExpireTimestamp: 1289574593 distinguishedName: name=GRP-SVC-SSH-INODE01,cn=groups,cn=DOMAIN,cn=sysdb
If possible, please also turn debug_level up to 6 and include the debug log in /var/log/sssd/sssd_<domain>.log for those two commands.
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (7): Adding original DN [cn=GRP-SVC-SSH-NODE,ou=GROUP-ACC ESS,ou=COMPUTE,dc=<skipped>] to attributes of [GRP-SVC-SSH-NODE]. (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sdap_save_group] (6): Storing info for group GRP-SVC-SSH-NODE (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x5e5e60
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x5e5f10
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Destroying timer event 0x5e5f10 "ltdb_timeout"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Ending timer event 0x5e5e60 "ltdb_callback"
(Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [sysdb_search_group_by_name] (6): Error: 2 (No such file or directory) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): start ldb transaction (nesting: 1) (Fri Nov 12 14:25:42 2010) [sssd[be[MD.METEORF.RU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x634930
Also I have noticed, that if remove member GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE1, wait some time and then return membership back - then users become a member of GRP-SVC-SSH-NODE1 untill reinstalling sssd package. It seems like sssd ignore entries that are not created yet. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzdVUQACgkQeiVVYja6o6ORhACfVHwVwpDjrxWRQD620dqVnYpP VzEAnjfzrktPuxeZRNJUAxj29e8aUHNk =aPCa -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 11:01 AM, Sergei V. Kovylov wrote:
Stephen, you are right 1.3.1 is working version too. I have made some experiment and found out that:
- The behaviour of sssd (1.3.1) depends on how to create OU on LDAP
server. If OU with groups is created after all users' OUs then sssd gets everything correctly. Example: correct sequence: ou=MCC (users) ou=HMC (users) ou=GROUP-ACCESS (groups)
incorrect sequence: ou=GROUP-ACCESS (groups) ou=MCC (users) ou=HMC (users)
- sssd 1.4.x doesn't work even with correct sequence of OU creation
(see above). 3. if I remove GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE and recreate membership back then sssd will see members of GRP-SVC-SSH-NODE in GRP-SVC-SSH-NODE group but untill new installation or reinstallation of sssd.
Sorry it's taken me so long to reply. I've been able to reproduce the problem and I'm working on fixing it right now.
I have opened https://fedorahosted.org/sssd/ticket/683 to track the problem.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/16/2010 12:03 PM, Stephen Gallagher wrote:
On 11/12/2010 11:01 AM, Sergei V. Kovylov wrote:
Stephen, you are right 1.3.1 is working version too. I have made some experiment and found out that:
- The behaviour of sssd (1.3.1) depends on how to create OU on LDAP
server. If OU with groups is created after all users' OUs then sssd gets everything correctly. Example: correct sequence: ou=MCC (users) ou=HMC (users) ou=GROUP-ACCESS (groups)
incorrect sequence: ou=GROUP-ACCESS (groups) ou=MCC (users) ou=HMC (users)
- sssd 1.4.x doesn't work even with correct sequence of OU creation
(see above). 3. if I remove GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE and recreate membership back then sssd will see members of GRP-SVC-SSH-NODE in GRP-SVC-SSH-NODE group but untill new installation or reinstallation of sssd.
Sorry it's taken me so long to reply. I've been able to reproduce the problem and I'm working on fixing it right now.
I have opened https://fedorahosted.org/sssd/ticket/683 to track the problem.
I take that back. I had a misconfiguration in my environment that was falsely giving me the wrong information.
I'm now actually pretty certain that you're hitting bug https://fedorahosted.org/sssd/ticket/663
What's happening is that our cleanup task (that makes sure the cache doesn't grow excessively large containing unused entries) is incorrectly cleaning out groups that only contain other groups (and no direct users).
This will be fixed in 1.5.0. (I will probably also backport the patch to 1.4.x in Fedora)
As an interim solution, please update to sssd-1.4.1-2.fc14 in updates-testing - https://admin.fedoraproject.org/updates/sssd-1.4.1-2.fc14 - and add:
ldap_purge_cache_timeout = 0
To your [domain/MD.METEORF.RU] section of sssd.conf.
If you're not using the Fedora binaries and are instead building your own copies, please cherry-pick the following patch:
commit 4f5824cf9b80dede79a6eddbcbb48f4ac75e5de4 Author: Stephen Gallagher sgallagh@redhat.com Date: Tue Nov 2 07:46:13 2010 -0400
Properly document ldap_purge_cache_timeout
Also allow it to be disabled entirely
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen, thanks. I had planned to spend my week-ends for hardly debuggin sssd behaviour. You save my time :-). I will rebuild sssd (I'm using custom build for SLES10) and check it.
2010/11/16 Stephen Gallagher sgallagh@redhat.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/16/2010 12:03 PM, Stephen Gallagher wrote:
On 11/12/2010 11:01 AM, Sergei V. Kovylov wrote:
Stephen, you are right 1.3.1 is working version too. I have made some experiment and found out that:
- The behaviour of sssd (1.3.1) depends on how to create OU on LDAP
server. If OU with groups is created after all users' OUs then sssd gets everything correctly. Example: correct sequence: ou=MCC (users) ou=HMC (users) ou=GROUP-ACCESS (groups)
incorrect sequence: ou=GROUP-ACCESS (groups) ou=MCC (users) ou=HMC (users)
- sssd 1.4.x doesn't work even with correct sequence of OU creation
(see above). 3. if I remove GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE and recreate membership back then sssd will see members of GRP-SVC-SSH-NODE in GRP-SVC-SSH-NODE group but untill new installation or reinstallation of sssd.
Sorry it's taken me so long to reply. I've been able to reproduce the problem and I'm working on fixing it right now.
I have opened https://fedorahosted.org/sssd/ticket/683 to track the problem.
I take that back. I had a misconfiguration in my environment that was falsely giving me the wrong information.
I'm now actually pretty certain that you're hitting bug https://fedorahosted.org/sssd/ticket/663
What's happening is that our cleanup task (that makes sure the cache doesn't grow excessively large containing unused entries) is incorrectly cleaning out groups that only contain other groups (and no direct users).
This will be fixed in 1.5.0. (I will probably also backport the patch to 1.4.x in Fedora)
As an interim solution, please update to sssd-1.4.1-2.fc14 in updates-testing - https://admin.fedoraproject.org/updates/sssd-1.4.1-2.fc14 - and add:
ldap_purge_cache_timeout = 0
To your [domain/MD.METEORF.RU] section of sssd.conf.
If you're not using the Fedora binaries and are instead building your own copies, please cherry-pick the following patch:
commit 4f5824cf9b80dede79a6eddbcbb48f4ac75e5de4 Author: Stephen Gallagher sgallagh@redhat.com Date: Tue Nov 2 07:46:13 2010 -0400
Properly document ldap_purge_cache_timeout
Also allow it to be disabled entirely
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzixcsACgkQeiVVYja6o6PK0QCfcx42Wea3jpJPwT4ywoPD7+87 pCcAoJ7sbOaXqNrJ/UyGZIuXdR//kRvJ =Vnlx -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
I will be putting the setup of the continuous integration automated acceptance testing into the next sprint http://tigger.idm.lab.bos.redhat.com/sssd/ticket/256 This may have been caught by existing tests, if not, will add task to regression test this scenario. Jenny
Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2010 11:01 AM, Sergei V. Kovylov wrote:
Stephen, you are right 1.3.1 is working version too. I have made some experiment and found out that:
- The behaviour of sssd (1.3.1) depends on how to create OU on LDAP
server. If OU with groups is created after all users' OUs then sssd gets everything correctly. Example: correct sequence: ou=MCC (users) ou=HMC (users) ou=GROUP-ACCESS (groups)
incorrect sequence: ou=GROUP-ACCESS (groups) ou=MCC (users) ou=HMC (users)
- sssd 1.4.x doesn't work even with correct sequence of OU creation
(see above). 3. if I remove GRP-SVC-SSH-NODE from GRP-SVC-SSH-NODE and recreate membership back then sssd will see members of GRP-SVC-SSH-NODE in GRP-SVC-SSH-NODE group but untill new installation or reinstallation of sssd.
Sorry it's taken me so long to reply. I've been able to reproduce the problem and I'm working on fixing it right now.
I have opened https://fedorahosted.org/sssd/ticket/683 to track the problem.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkziuWAACgkQeiVVYja6o6PL5QCff+mydw0B1iuiA/9gUEVxPerY oyUAnAyAXHzCJRWtlsS1JxJBojk0PZK4 =6c2m -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Jenny Galipeau -
Sergei V. Kovylov -
Stephen Gallagher