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. _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
