Created from: https://bugzilla.redhat.com/show_bug.cgi?id=697890
Description of problem:
When adding a new user a private group with the same name as the user and its
UID as GID is created. Since we do not have a need for it but rather want new
users to be in a "staff" group (for instance) we want to be able to turn off
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create new user
2. ipa group-find --private
Shows a private group with name and GID as user's name and UID.
No private group.
Discussed with JrAquino on IRC.
Per IRC conversation with Rob, changing the scope of this bug to reflect a means to disable Managed Entries in general rather than creating separate tools for each one.
It should be noted that the tools will need comments explaining that the eventual proper method for disabling managed entries should be via deleting them from ldap, that method however is blocked by: https://bugzilla.redhat.com/show_bug.cgi?id=660399
Is it really blocked? The bug says that there is a workaround of using an origin filter that will never match. Thus the bug is marked as low priority for the DS team. Should it be escalated?
Sorry, the language perhaps wasn't completely clear. The bug/ticket is NOT blocked, the proper methodology for disabling an entry is what is blocked by the bz.
The reason for documenting this, is that the ldap2.py and user.py code expect the Managed Entry plugin to be completely deleted from the directory before performing certain tasks.
The ldap2.py code will need to be slightly modified to reflect this interactive method of disabling the plugin. Otherwise there is no means to delete the plugin and trigger the rest of the framework.
It seems that it is easier to fix the plugin than the DS so we should follow this path.
Ticket intention changed: Create Tool for Enabling/Disabling Managed Entry Plugins
The DS team is not planning to fix the issue in DS so shouldn't we move on with reviewing this patch?
I was just told that they are working on this now.
The problem with this patch is that in a replicated environment it could generate inconsistent results. cn=config is not replicated so an admin would really need to take down all replicas, modify dse.ldif to change the config, then restart them all to ensure that no inconsistencies occur. Running this even simultaneously on all replicas would not guarantee good results.
Pavel's approach in ticket 1131 may be better overall. See his current patch titled "Add a new user-add flag param to disable the creation of UPG." on ipa-devel.
Apply this patch before patch 25. This addresses the issue of the replicating the configurations.
389-ds 1.2.9 alpha just got pushed out today, pushing to Sprint 2.
(Authoritative) Patch 28 Was previously taken by a 1liner in a separate effort.
AUTHORITATIVE PATCH: Please ignore the previous one due to problem scope change
Metadata Update from @jraquino:
- Issue assigned to jraquino
- Issue set to the milestone: FreeIPA 2.1.2 (bug fixing)
to comment on this ticket.