at the same time on different IPA clients, group name could become unavailable on one but not the other:
===== available on fisher ===== fisher:$ groups chuck chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc =====
===== unavailable on robin ===== [root@robin ~]# groups chuck chuck : groups: cannot find name for group ID 422 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp =====
Note in this case 422 is mri, but it could happen to another GID.
Just did a "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb" and "service sssd restart", the group name still did not come back. A reboot would fix the problem, but it could creep back some time later.
Any idea why this is happening?
Best Regards, Qing
On Fri, Apr 19, 2013 at 01:02:00PM -0400, Qing Chang wrote:
at the same time on different IPA clients, group name could become unavailable on one but not the other:
===== available on fisher ===== fisher:$ groups chuck chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc =====
===== unavailable on robin ===== [root@robin ~]# groups chuck chuck : groups: cannot find name for group ID 422 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp =====
Note in this case 422 is mri, but it could happen to another GID.
Just did a "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb" and "service sssd restart", the group name still did not come back.
Which version is this? If that's 1.9 you also need to remove the memory cache to be completely sure (/var/lib/sss/mc/*)
A reboot would fix the problem, but it could creep back some time later.
Any idea why this is happening?
There's not enough information, sorry. Debug logs (nss and domain) would tell us more. Also what version on what OS?
it is 1.9.2-82.4.el6_4. Host is RHEL 6.4 (2.6.32-358.2.1.el6.x86_64)
/var/log/sssd/sssd_nss.log has multiple entries: [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
It seems to be complaining about duplicate gid entries. How can I have a recursive look of all GIDs? "getent group" (with enumerate turned on) returns single entries for the GIDs that are involved so far (42, 421 etc,.)
Thanks, Qing
On 19/04/2013 1:07 PM, Jakub Hrozek wrote:
On Fri, Apr 19, 2013 at 01:02:00PM -0400, Qing Chang wrote:
at the same time on different IPA clients, group name could become unavailable on one but not the other:
===== available on fisher ===== fisher:$ groups chuck chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc =====
===== unavailable on robin ===== [root@robin ~]# groups chuck chuck : groups: cannot find name for group ID 422 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp =====
Note in this case 422 is mri, but it could happen to another GID.
Just did a "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb" and "service sssd restart", the group name still did not come back.
Which version is this? If that's 1.9 you also need to remove the memory cache to be completely sure (/var/lib/sss/mc/*)
A reboot would fix the problem, but it could creep back some time later.
Any idea why this is happening?
There's not enough information, sorry. Debug logs (nss and domain) would tell us more. Also what version on what OS? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
It seems that "member" and "memberUid" attributes are not in sync. Is this a normal behavior? Another curious situation is that sssd seems to be able to get the name on some IPA clients not others, as mentioned in my first post...
Thanks, Qing
On 19/04/2013 1:33 PM, Qing Chang wrote:
it is 1.9.2-82.4.el6_4. Host is RHEL 6.4 (2.6.32-358.2.1.el6.x86_64)
/var/log/sssd/sssd_nss.log has multiple entries: [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
It seems to be complaining about duplicate gid entries. How can I have a recursive look of all GIDs? "getent group" (with enumerate turned on) returns single entries for the GIDs that are involved so far (42, 421 etc,.)
Thanks, Qing
On 19/04/2013 1:07 PM, Jakub Hrozek wrote:
On Fri, Apr 19, 2013 at 01:02:00PM -0400, Qing Chang wrote:
at the same time on different IPA clients, group name could become unavailable on one but not the other:
===== available on fisher ===== fisher:$ groups chuck chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc =====
===== unavailable on robin ===== [root@robin ~]# groups chuck chuck : groups: cannot find name for group ID 422 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp =====
Note in this case 422 is mri, but it could happen to another GID.
Just did a "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb" and "service sssd restart", the group name still did not come back.
Which version is this? If that's 1.9 you also need to remove the memory cache to be completely sure (/var/lib/sss/mc/*)
A reboot would fix the problem, but it could creep back some time later.
Any idea why this is happening?
There's not enough information, sorry. Debug logs (nss and domain) would tell us more. Also what version on what OS? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On 04/22/2013 09:59 AM, Qing Chang wrote:
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
It seems that "member" and "memberUid" attributes are not in sync. Is this a normal behavior? Another curious situation is that sssd seems to be able to get the name on some IPA clients not others, as mentioned in my first post...
There are two schema RFC 2307bis and RFC 2307. One uses member (DN) another memberUid (login name), this is one of the major differences. Mixing entries with different schema in one deployment is not a good idea and can lead to unexpected results like you have seen.
However if you change the group membership and the compat tree is not adequately updated this is probably a bug but before filing it I would suggests you make sure that the entry you are experimenting with does not have bad member and memberUid attributes.
Thanks, Qing
On 19/04/2013 1:33 PM, Qing Chang wrote:
it is 1.9.2-82.4.el6_4. Host is RHEL 6.4 (2.6.32-358.2.1.el6.x86_64)
/var/log/sssd/sssd_nss.log has multiple entries: [sssd[nss]] [nss_cmd_getgrgid_search] (0x0010): getgrgid call returned more than one result !?!
It seems to be complaining about duplicate gid entries. How can I have a recursive look of all GIDs? "getent group" (with enumerate turned on) returns single entries for the GIDs that are involved so far (42, 421 etc,.)
Thanks, Qing
On 19/04/2013 1:07 PM, Jakub Hrozek wrote:
On Fri, Apr 19, 2013 at 01:02:00PM -0400, Qing Chang wrote:
at the same time on different IPA clients, group name could become unavailable on one but not the other:
===== available on fisher ===== fisher:$ groups chuck chuck : mri hcgrp ccgrp prgrp chuksh crdsh2 ipausers slcc =====
===== unavailable on robin ===== [root@robin ~]# groups chuck chuck : groups: cannot find name for group ID 422 422 ipausers prgrp crdsh2 slcc chuksh hcgrp ccgrp =====
Note in this case 422 is mri, but it could happen to another GID.
Just did a "\rm /var/lib/sss/db/cache_sri.utoronto.ca.ldb" and "service sssd restart", the group name still did not come back.
Which version is this? If that's 1.9 you also need to remove the memory cache to be completely sure (/var/lib/sss/mc/*)
A reboot would fix the problem, but it could creep back some time later.
Any idea why this is happening?
There's not enough information, sorry. Debug logs (nss and domain) would tell us more. Also what version on what OS? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Apr 22, 2013 at 09:59:53AM -0400, Qing Chang wrote:
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
I would guess that the rfc2307 memberuid attributes would be removed/not migrated and rfc2307bis member attributes would be used instead. But frankly, you might get a more qualified answer on the freeipa-users list: https://www.redhat.com/mailman/listinfo/freeipa-users
It seems that "member" and "memberUid" attributes are not in sync. Is this a normal behavior? Another curious situation is that sssd seems to be able to get the name on some IPA clients not others, as mentioned in my first post...
As mentioned in my reply to the post, it shouldn't be that way and we need the debug logs to analyze the situation.
On 23/04/2013 4:42 AM, Jakub Hrozek wrote:
On Mon, Apr 22, 2013 at 09:59:53AM -0400, Qing Chang wrote:
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
I would guess that the rfc2307 memberuid attributes would be removed/not migrated and rfc2307bis member attributes would be used instead. But frankly, you might get a more qualified answer on the freeipa-users list: https://www.redhat.com/mailman/listinfo/freeipa-users
Our OpenLDAP server was using rfc2307, I guess when migrated, both rfc2307 and rfc2307bis were used for "cn=groups,cn=accounts", as both memberUid and member were created. For "cn=groups,cn=compat", only memberUid exist.
When a test account is created and assigned to a group on IPA, for "cn=groups,cn=accounts", only rfc2307bis is used because only member is added for the assigned group. Consistently for "cn=groups,cn=compat", only memberUid is added.
Removing the test account DOES remove the member and memberUid entries for that account.
I think this is not a bug in IPA or SSSD, it is caused by migrating nonexistent members of a group that should not happen in the first place. Apologies...
I think I can also assume that it is safe to remove ALL memberUid entries for "cn=groups,cn=accounts".
Regards, Qing
It seems that "member" and "memberUid" attributes are not in sync. Is this a normal behavior? Another curious situation is that sssd seems to be able to get the name on some IPA clients not others, as mentioned in my first post...
As mentioned in my reply to the post, it shouldn't be that way and we need the debug logs to analyze the situation. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On 04/24/2013 10:50 AM, Qing Chang wrote:
On 23/04/2013 4:42 AM, Jakub Hrozek wrote:
On Mon, Apr 22, 2013 at 09:59:53AM -0400, Qing Chang wrote:
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
I would guess that the rfc2307 memberuid attributes would be removed/not migrated and rfc2307bis member attributes would be used instead. But frankly, you might get a more qualified answer on the freeipa-users list: https://www.redhat.com/mailman/listinfo/freeipa-users
Our OpenLDAP server was using rfc2307, I guess when migrated, both rfc2307 and rfc2307bis were used for "cn=groups,cn=accounts", as both memberUid and member were created. For "cn=groups,cn=compat", only memberUid exist.
When a test account is created and assigned to a group on IPA, for "cn=groups,cn=accounts", only rfc2307bis is used because only member is added for the assigned group. Consistently for "cn=groups,cn=compat", only memberUid is added.
Removing the test account DOES remove the member and memberUid entries for that account.
I think this is not a bug in IPA or SSSD, it is caused by migrating nonexistent members of a group that should not happen in the first place. Apologies...
I think I can also assume that it is safe to remove ALL memberUid entries for "cn=groups,cn=accounts".
Yes.
Regards, Qing
It seems that "member" and "memberUid" attributes are not in sync. Is this a normal behavior? Another curious situation is that sssd seems to be able to get the name on some IPA clients not others, as mentioned in my first post...
As mentioned in my reply to the post, it shouldn't be that way and we need the debug logs to analyze the situation. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Apr 24, 2013 at 10:50:34AM -0400, Qing Chang wrote:
On 23/04/2013 4:42 AM, Jakub Hrozek wrote:
On Mon, Apr 22, 2013 at 09:59:53AM -0400, Qing Chang wrote:
just for the record. This is considered solved.
When migrated from OpenLDAP to IPA, inactive user accounts were left out, but some of the accounts were still in place as secondary group members of a certain group (mri as example). Nonexistent "member" in "cn=groups,cn=accounts" causes the lookup of group name to fail. After the removal of that account, the lookup succeeds.
In looking at all group membership attributes of the group, it seems that the removal of a "member" of "cn=groups,cn=accounts" (which is done in the Web GUI) does not translate into the removal of "memberUid" of "cn=groups,cn=accounts", as well "memberUid" of "cn=groups,cn=compat".
I would guess that the rfc2307 memberuid attributes would be removed/not migrated and rfc2307bis member attributes would be used instead. But frankly, you might get a more qualified answer on the freeipa-users list: https://www.redhat.com/mailman/listinfo/freeipa-users
Our OpenLDAP server was using rfc2307, I guess when migrated, both rfc2307 and rfc2307bis were used for "cn=groups,cn=accounts", as both memberUid and member were created. For "cn=groups,cn=compat", only memberUid exist.
When a test account is created and assigned to a group on IPA, for "cn=groups,cn=accounts", only rfc2307bis is used because only member is added for the assigned group. Consistently for "cn=groups,cn=compat", only memberUid is added.
Removing the test account DOES remove the member and memberUid entries for that account.
I think this is not a bug in IPA or SSSD, it is caused by migrating nonexistent members of a group that should not happen in the first place. Apologies...
No problem, we're glad you got your setup working!
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Qing Chang