[Freeipa-devel] [PATCH] Add a new user-add flag param to disable the creation of UPG.

[Pavel Zuna]

On 04/04/2011 03:47 PM, Simo Sorce wrote:
> On Mon, 28 Mar 2011 15:27:46 -0700
> Nathan Kinder<nkinder at 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.
>

New patch with new approach attached.

It sets the checked filter to:
(&(objectclass=posixAccount)(!(description=__no_upg__)))

If a user entry is created with the description attribute equal to the string 
"__no_upg__", the DS plugin will not trigger and no UPG is going to be created.

After this patch, the user-add plugin adds this description attribute 
(NO_UPG_MAGIC = "__no_upg__") in the pre_callback and deletes it in the 
post_callback if necessary.

I think the description attribute is the best choice, because it's part of the 
posixAccount objectClass and we don't use it for anything on user entries.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pzuna-88-2-noprivate.patch
Type: text/x-patch
Size: 5168 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20110408/5fb31697/attachment.bin>