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

Ana Krivokapic akrivoka at redhat.com
Thu Sep 19 09:00:05 UTC 2013


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.




More information about the Freeipa-devel mailing list