Full_Name: John Alex. Version: 2.4.40 OS: FreeBSD 9.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.58.252.240) I have a consumer configured with slapo-memberof and exattrs=memberof in order to keep track of group memberships locally as suggested in the manpages. This works ok when adding/deleting users to groups, but when a user entry containing "memberOf" values is modified, those values are deleted in the consumer. According to ITS#7400, exattrs=memberOf is necessary to avoid getting this attribute from the provider. However, it was suggested to me to remove "memberOf" from exattrs, which I did and now everything seems to work fine. In any case, even if exattrs=memberof is not needed anymore, it should not have any effect to the local slapo-memberof operations. See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html
alexoz66@gmail.com wrote: > Full_Name: John Alex. > Version: 2.4.40 > OS: FreeBSD 9.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (176.58.252.240) > > > I have a consumer configured with slapo-memberof and exattrs=memberof in order > to keep track of group memberships locally as suggested in the manpages. This > works ok when adding/deleting users to groups, but when a user entry containing > "memberOf" values is modified, those values are deleted in the consumer. > According to ITS#7400, exattrs=memberOf is necessary to avoid getting this > attribute from the provider. I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list and needs new design work. > However, it was suggested to me to remove > "memberOf" from exattrs, which I did and now everything seems to work fine. > > In any case, even if exattrs=memberof is not needed anymore, it should not have > any effect to the local slapo-memberof operations. Sorry, that doesn't follow. Adding settings will invariably change some server behavior. Adding a setting that you didn't need generally turns a working config into a broken config. > See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 05/19/2015 11:55 PM, Howard Chu wrote: > alexoz66@gmail.com wrote: >> Full_Name: John Alex. >> Version: 2.4.40 >> OS: FreeBSD 9.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (176.58.252.240) >> >> >> I have a consumer configured with slapo-memberof and exattrs=memberof in order >> to keep track of group memberships locally as suggested in the manpages. This >> works ok when adding/deleting users to groups, but when a user entry containing >> "memberOf" values is modified, those values are deleted in the consumer. >> According to ITS#7400, exattrs=memberOf is necessary to avoid getting this >> attribute from the provider. > > I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive > in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list > and needs new design work. By reading ITS#7400, I got the impression that the provider (wrongly) sends "memberOf" when the consumer requests "+", so I figured I had to either block this attribute by acl at the provider or by using exattrs on the consumer. Has this been fixed? >> However, it was suggested to me to remove >> "memberOf" from exattrs, which I did and now everything seems to work fine. >> >> In any case, even if exattrs=memberof is not needed anymore, it should not have >> any effect to the local slapo-memberof operations. > > Sorry, that doesn't follow. Adding settings will invariably change some server behavior. > Adding a setting that you didn't need generally turns a working config into a broken config. Redundant yes, but broken? Although I don't have the slightest clue about the inner workings of syncrepl and slapo-memberof, I don't see why one should affect the other. >> See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html > >
See ITS#7400, ITS#8444
changed notes moved from Incoming to Software Bugs