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

Martin Kosek mkosek at redhat.com
Thu Sep 19 10:01:12 UTC 2013


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




More information about the Freeipa-devel mailing list