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

Ana Krivokapic akrivoka at redhat.com
Thu Sep 19 10:19:28 UTC 2013


On 09/19/2013 12:01 PM, Martin Kosek wrote:
> ----- Original Message -----
>> From: "Ana Krivokapic" <akrivoka at redhat.com>
>> To: "Nathan Kinder" <nkinder at redhat.com>
>> Cc: "Martin Kosek" <mkosek at redhat.com>, "freeipa-devel" <freeipa-devel at redhat.com>, "Mark Reynolds"
>> <mareynol at redhat.com>
>> Sent: Thursday, September 19, 2013 11:00:05 AM
>> Subject: Re: [Freeipa-devel] [RFE] Support for automember rebuild membership
>>
>> 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).
> ACK! Please also create FreeIPA RFE ticket pointing to the 389 ticket so that we do no forget about it.
>
> Martin

https://fedorahosted.org/freeipa/ticket/3936

-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.




More information about the Freeipa-devel mailing list