On Mon, 28 Mar 2011 15:27:46 -0700
Nathan Kinder <nkin...@redhat.com> wrote:

> On 03/28/2011 03:20 PM, Dmitri Pal wrote:
> > On 03/28/2011 04:38 PM, Pavel Zůna wrote:
> >> This patch handles the issue in a kind of stupid way, but I
> >> couldn't think of anything better.
> >>
> >> It adds a new flag parameter to user-add (--noprivate). With this 
> >> flag, the command marks the private group about to be created for 
> >> deletion and is deleted after the user is created. The only
> >> exception is when there is a group, that is named the same way as
> >> the user, but isn't a private group - then the group is left there.
> >>
> >> Private groups are created automatically by the managed entry DS 
> >> plugin and I didn't find a way to disable its creation for a
> >> specific user.
> >
> > The idea that comes to mind is to define some magical attribute
> > that the DS plugin would recognize and skip the creation of the
> > managed entry as well as strip the entry of this magic
> > attribute/value. I remember that other plugins might take advantage
> > of the similar approach.
> >
> > Is something like this possible?
> You are probably thinking of the DNA plug-in and it's use of a magic 
> value used to tell the plug-in to allocate a value from a range.  I 
> would not like to use this approach here, as it requires additional 
> coding and complexity that I don't think is needed.
> I would prefer that we use the originFilter to deal with this.  We
> could have an auxiliary objectclass that IPA usually adds when
> creating an IPA user.  The originFilter can key off of this
> objectclass to create managed groups.  When a user is added with the
> --noprivate option, this objectclass is not included in the user
> entry that is added.  Rob and I discussed this approach on IRC
> earlier today.

Ack, this sounds like a better approach, although it doesn't
necessarily need to be an objectclass it can also be an attribute with
a specific value that is checked in the filter as (!(attrib=value))


Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to