[Freeipa-devel] [RFE] Support for automember rebuild membership

Ana Krivokapic akrivoka at redhat.com
Fri Sep 13 12:53:25 UTC 2013


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

My plan was to use the interactive_prompt_callback for the CLI, but the approach
with --dry-run sounds better. So effectively, the --dry-run option would invoke
the automember export updates task, while the command without --dry-run would
invoke the automember rebuild membership task. In the web UI, a click on the
"rebuild membership" button/link would present the user with the list of
candidate entries (command with --dry-run is called), and then after
confirmation, the command without --dry-run would be called. Does it make sense?

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

I came across this issue while doing initial investigation, and reported it
here: https://fedorahosted.org/389/ticket/47507. As a workaround, Mark suggested
to use a different value for the basedn parameter in the above ldif:
cn=computers,cn=accounts,dc=example,dc=com - for hosts
cn=users,cn=accounts,dc=example,dc=com - for users

This worked for me, but seemed to cause a hang of the DS server when the ldif is
executed. The issue seems to be in the schema compat plugin. Bugzillas have been
open to address this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1007451
https://bugzilla.redhat.com/show_bug.cgi?id=1007453

To work around _this_ problem, disabling the schema compat plugin seems to do
the trick:
$ ipa-compat-manage disable

To sum it up, in order to test the automember tasks, you need to:
1. Change the 'basedn' parameter in the above ldif (as described above)
2. Disable the schema compat plugin

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


-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.




More information about the Freeipa-devel mailing list