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.

Ticket #1131


Freeipa-devel mailing list

Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to