On 09/19/2013 12:01 PM, Martin Kosek wrote: > ----- Original Message ----- >> From: "Ana Krivokapic" <[email protected]> >> To: "Nathan Kinder" <[email protected]> >> Cc: "Martin Kosek" <[email protected]>, "freeipa-devel" >> <[email protected]>, "Mark Reynolds" >> <[email protected]> >> Sent: Thursday, September 19, 2013 11:00:05 AM >> Subject: Re: [Freeipa-devel] [RFE] Support for automember rebuild membership >> >> On 09/18/2013 06:51 PM, Nathan Kinder wrote: >>> On 09/18/2013 07:26 AM, Martin Kosek wrote: >>>> On 09/18/2013 01:37 PM, Ana Krivokapic wrote: >>>>> On 09/13/2013 10:48 AM, Martin Kosek wrote: >>>>>> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >>>> ... >>>>>> I would rather add an option --dry-run or --test for all new automember >>>>>> commands which would return how would the updated entry look like. BTW, >>>>>> did >>>>>> the >>>>>> automember export updates task work for you? I tried this LDIF and >>>>>> /tmp/automember.ldif was empty: >>>>>> >>>>>> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config >>>>>> changetype: add >>>>>> objectClass: top >>>>>> objectClass: extensibleObject >>>>>> cn: my export task 1 >>>>>> basedn: cn=accounts,dc=example,dc=com >>>>>> filter: (uid=*) >>>>>> scope: sub >>>>>> ldif: /tmp/automember.ldif >>>>>> >>>>>> Adding Mark to CC in case if he has any advise for utilizing the export >>>>>> task in >>>>>> FreeIPA. >>>>>> >>>>>> By the way, using this approach I think we would also hit issues with >>>>>> permissions on the resulting LDIF, given it is created by DS and would >>>>>> be read >>>>>> by Apache. SELinux would be complaining as well. To sum it up, I am not >>>>>> sure >>>>>> this will be that easy and straightforward. >>>>> You are right about this. I haven't been able to find a way to make this >>>>> work. >>>>> Namely, the resulting LDIF is created by dirsrv user and is not readable >>>>> by >>>>> apache user. Any ideas/pointers here would be very much appreciated. >>>> Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about >>>> that. >>>> If we do not find a better way to transfer the resulting LDIF to Apache, >>>> we >>>> will need to leave the --dry-run part until we do. >>> I don't see an easy way of solving this without changes to 389 DS that >>> offer >>> alternate methods for exporting the automember updates, such as making them >>> available via LDAP. I'm not even sure if this is a good idea since the >>> export >>> could be quite sizable. >>> >>> Another approach would be to allow the task to specify the mode to use when >>> creating the export file. This still isn't ideal, as you either have to >>> open >>> the file up to everyone, or you have to have the httpd and 389 DS users in >>> the >>> same group (which opens up other permission issues). >>> >>> Thanks, >>> -NGK >>>> Martin >> Thanks Nathan for your input. I opened this ticket to allow a better way of >> accessing results of the automember export updates task: >> https://fedorahosted.org/389/ticket/47518. After further conversation with >> Nathan on IRC, we both agreed that at this point, the --dry-run option seems >> to >> be more trouble than it's worth. So I will leave it out for now (until the >> above >> ticket is implemented in 389). > ACK! Please also create FreeIPA RFE ticket pointing to the 389 ticket so that > we do no forget about it. > > Martin
https://fedorahosted.org/freeipa/ticket/3936 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
