(without the n :-)
Ooops :)
sssd cares only about what exists in ldap to date.
Ooops again
If you look at the ldap tree on its own you see an "unknown" user name as member of a group.
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
Anyway, thank you so much for your responses Simo and Stephen : I'll adapt my view to what is possible then :-)
Kindest,
--- Olivier
2012/3/14 Simo Sorce simo@redhat.com:
On Wed, 2012-03-14 at 19:51 +0100, Olivier wrote:
Simon,
(without the n :-)
that's where I don't catch ( sorry) :
You are asking it to know about "unknown" users
If you say in nsswitch.conf :
passwd: local sss group: sss local
Then sss should know about users that are in local /etc/passwd and may retrieve their groups in ldap ?
No, sssd is blissfully unaware of what you have in /etc/passwd or /etc/group, sssd cares only about what exists in ldap to date.
Why would that be inconsistent not to insert users entries in ldap in that situation ?
Because in the ldap server there is no corresponding user. If you look at the ldap tree on its own you see an "unknown" user name as member of a group.
BTW, I don' think that ldap requires that an entry exists for a posixgroup memberuid ?
No the rfc2307 schema does not mandate consistency (the rfc2307bis schema does mandate it due to use of DNs instead of simple names).
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
memberuid cannot be resolved through a referral as it cannot contain a DN :-) however if you use the "member" attribute and rfc2307bis you could end up chasing a referral that is temporarily broken. In that case you'd have a resolution issue, not an "unknown" member.
I am not sure how sssd would handle a referral problem in this case, hopefully it would recognize the problem and just use a previously cached value. If it is the first lookup it would have no choice but to pretend the member did not exist until the next lookup.
Simo.
On Wed, 2012-03-14 at 16:36 -0400, Simo Sorce wrote:
On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
memberuid cannot be resolved through a referral as it cannot contain a DN :-) however if you use the "member" attribute and rfc2307bis you could end up chasing a referral that is temporarily broken. In that case you'd have a resolution issue, not an "unknown" member.
I am not sure how sssd would handle a referral problem in this case, hopefully it would recognize the problem and just use a previously cached value. If it is the first lookup it would have no choice but to pretend the member did not exist until the next lookup.
Right now we can't handle this safely. It's a limitation of using the internal openldap referral chasing. As far as we see as a consumer, the entry doesn't exist, and we have to treat it on the client as LDAP definitively asserting that the user does not exist, and therefore must delete it from the local cache.
I'm trying to work out ways to resolve this when we rewrite the referral processing with our own implementation.
On Wed, 2012-03-14 at 18:00 -0400, Stephen Gallagher wrote:
On Wed, 2012-03-14 at 16:36 -0400, Simo Sorce wrote:
On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
memberuid cannot be resolved through a referral as it cannot contain a DN :-) however if you use the "member" attribute and rfc2307bis you could end up chasing a referral that is temporarily broken. In that case you'd have a resolution issue, not an "unknown" member.
I am not sure how sssd would handle a referral problem in this case, hopefully it would recognize the problem and just use a previously cached value. If it is the first lookup it would have no choice but to pretend the member did not exist until the next lookup.
Right now we can't handle this safely. It's a limitation of using the internal openldap referral chasing. As far as we see as a consumer, the entry doesn't exist, and we have to treat it on the client as LDAP definitively asserting that the user does not exist, and therefore must delete it from the local cache.
I'm trying to work out ways to resolve this when we rewrite the referral processing with our own implementation.
Thanks, should we open a ticket specifically about this issue so we A) do not forget and B) can add a test case ?
Simo.
On 03/14/2012 06:27 PM, Simo Sorce wrote:
On Wed, 2012-03-14 at 18:00 -0400, Stephen Gallagher wrote:
On Wed, 2012-03-14 at 16:36 -0400, Simo Sorce wrote:
On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
memberuid cannot be resolved through a referral as it cannot contain a DN :-) however if you use the "member" attribute and rfc2307bis you could end up chasing a referral that is temporarily broken. In that case you'd have a resolution issue, not an "unknown" member.
I am not sure how sssd would handle a referral problem in this case, hopefully it would recognize the problem and just use a previously cached value. If it is the first lookup it would have no choice but to pretend the member did not exist until the next lookup.
Right now we can't handle this safely. It's a limitation of using the internal openldap referral chasing. As far as we see as a consumer, the entry doesn't exist, and we have to treat it on the client as LDAP definitively asserting that the user does not exist, and therefore must delete it from the local cache.
I'm trying to work out ways to resolve this when we rewrite the referral processing with our own implementation.
Thanks, should we open a ticket specifically about this issue so we A) do not forget and B) can add a test case ?
Simo.
https://fedorahosted.org/sssd/ticket/860#comment:8
Thanks !
To summary, I know now that I will definitlly need to maintain a DIT branch in my ldap server as an additional source of reference for sysaccounts if I want to be able to include them in centralized posixgroups ...
... I have tried (-:
Thanks for your time !
--- Olivier
2012/3/14 Simo Sorce simo@redhat.com:
On Wed, 2012-03-14 at 21:17 +0100, Olivier wrote:
Ok, I see the logic now ( although I'm not completely convinced from a practical point of view to be honnest : a user name could be defined somewhere else, in a referal ldap for example. In that case, should it be an overall group consistency problem if a memberuid was uknown because a referal server is not accessible ? ).
memberuid cannot be resolved through a referral as it cannot contain a DN :-) however if you use the "member" attribute and rfc2307bis you could end up chasing a referral that is temporarily broken. In that case you'd have a resolution issue, not an "unknown" member.
I am not sure how sssd would handle a referral problem in this case, hopefully it would recognize the problem and just use a previously cached value. If it is the first lookup it would have no choice but to pretend the member did not exist until the next lookup.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Olivier -
Simo Sorce -
Stephen Gallagher