On 09/13/2013 10:48 AM, Martin Kosek wrote:
> On 09/12/2013 07:59 PM, Ana Krivokapic wrote:
>> Hello,
>> The design document for $SUBJECT can be found at:
>> http://www.freeipa.org/page/V3/Automember_rebuild_membership
>> Related tickets:
>> https://fedorahosted.org/freeipa/ticket/3752
>> https://fedorahosted.org/freeipa/ticket/3928
>> Thoughts, comments, questions welcome.
> Besides membership reset discussion happening in second thread I other 
> comments.
> 1) I think we should also design permission&ACIs for the automember rebuild
> task creation (cn=automember rebuild membership,cn=tasks,cn=config container).
> You can talk to Petr3 about that as he is current working on redesigning ACIs.
> Just so that you are in sync.

I discussed this with Petr. We agreed that since the new redesign of ACIs will
not be implemented for some time, I should use the old way to add the ACIs for
automember tasks. I added a section to the design document to address ACIs,
permissions and privileges:


> 2) About the "Implementation" part and "automember rebuild membership"
> I do not think this is good approach. I do not know how do you plan doing the
> confirmation
> I do not think this workflow would work with our framework. We do not have
> support for confirming except if you would implement it in
> interactive_prompt_callback. But then the functionality would not be available
> for Web UI.
> 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.

> Martin


Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

Freeipa-devel mailing list

Reply via email to