On 09/18/2013 07:26 AM, Martin Kosek wrote:
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.
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
cn: my export task 1
Adding Mark to CC in case if he has any advise for utilizing the export task in
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.
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).
Freeipa-devel mailing list