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). -- 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
