[Date Prev][Date Next]
Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
- From: email@example.com
- Date: Wed, 20 May 2015 07:04:25 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
On 05/19/2015 11:55 PM, Howard Chu wrote:
> firstname.lastname@example.org wrote:
>> Full_Name: John Alex.
>> Version: 2.4.40
>> OS: FreeBSD 9.3
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (22.214.171.124)
>> 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