Hide Forgot
Description of problem: When migrating users, provide an option to migrate groups as UPG This is a clone of upstream ticket: https://fedorahosted.org/freeipa/ticket/4738
For reference, putting this to bz, so other people can see it: UPG are managed entries created by "managed entries plug-in". AFAIK they are created only on ADD of users (here I'm not sure, but docs suggest that [1]) migrate-ds doesn't handle UPGs well. More specifically it unconditionally stops creation of UPGs during migration of users by adding the NO_UPG_MAGIC constant into user's description attribute. It doesn't reflect UPG settings(enablement of UPG definition). But from the code it seems that there was some intention to do it which didn't happen. Workaround: It might be possible to work around the issue by removing following lines from migrate-ds plugin code (/usr/lib/python2.7/side-packages/ipalib/plugins/migration.py): # We don't want to create a UPG so set the magic value in description # to let the DS plugin know. entry_attrs.setdefault('description', []) entry_attrs['description'].append(NO_UPG_MAGIC) but it needs to be tested first, see comment in the commit below. Also it assumes that uidnumber==gidnumber and both are migrated. This was added in https://fedorahosted.org/freeipa/ticket/2562 commit https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=b55c98f1c5b0d46aba3f1792ebd8ecc059173b6a [1] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/managed-entries-attributes.html [2] https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA
Petr, removing those lines is only part of it. You also need to be sure that no other users are members of the group before creating it as a private group (which can have no members). This needs to checked both via group membership and via the user primary group. IIRC you are right, if the gid is different then I don't think it'll work using the managed entry plugin. That isn't to say it can't be faked by manually creating the group using pure ldap calls you're just getting close to no-man's land.
Actually the cloned upstream bug is not probably the right one for use case I was creating the workaround - IPA-IPA migration. In migration from one IPA to another we are not changing POSIX groups into UPGs but rather we should not migrate UPGs and create new UPGs for users which had them(I assume that if GID==UID then there was an UPG) I have a preliminary patch which does something like: if upg_support_enambled and gid != uid prevent UPG create else let managed entry plugin create UPG This works only if UIDs are migrated. It also doesn't cover other use cases like forced creation of UPGs for all users or creation of UPG after migration.
There was also a question when ipa migrate-ds created a group which looked like: ipa group-show lbar --all --raw dn: cn=lbar,cn=groups,cn=accounts,dc=example,dc=test cn: lbar description: User private group for lbar gidnumber: 903000004 ipaUniqueID: 5ced9f72-7f5f-11e6-a667-001a4a2314d1 mepManagedBy: uid=lbar,cn=users,cn=accounts,dc=example,dc=test objectClass: ipaobject objectClass: top objectClass: mepmanagedentry objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup This can happen when UPGs are not created by managed entry plugin and migration is done with options --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup The reason is that UPG is a POSIX group(has posixgroup object class) and therefore is migrated but is normalized in a way that it gets also all the other object classes. It then presents itself incorrectly in Web UI, CLI... To avoid it it is better to migrate with --group-container=cn=groups,cn=accounts --group-objectclass=ipausergroup Using ipausergroup will migrate also external groups but won't add additional object classed to UPGs.
Created attachment 1203005 [details] freeipa-pvoborni-0966-migrate-ds-user-private-group-support-if-UIDs-are-mi.patch Attaching a patch which does what I meant in comment 4 and comment 6 It will be later sent as upstream pull request.
I think there should probably be a separate option when doing IPA to IPA migration.
As for the patch, I don't think it's a safe assumption that the group is private just because the UID/GID match.
True, but if there is an overlap with other POSIX group then the other won't be migrated(will be reported) unless you pass --group-overwrite-gid which then changes it's GID (might not be wanted). The reason why it happens is that users are migrated first, UPGS are create at user creation and then migration of the other group will fail on "existing GID check". Possible alternative solution might be to make it configurable via some option e.g.: --upg-mode={matching-ids,force-upgs,ńo-ups} but I'd not like to over-engineer it. As for comment 9 - special option for IPA-IPA migration - best to be solved in https://fedorahosted.org/freeipa/ticket/3656
Upstream ticket: https://fedorahosted.org/freeipa/ticket/4738
The bugzilla doesn't have high enough priority in comparison to other IdM bugs/RFEs for 7.4. Moving to next release. Without sufficient justification it can be moved again later.
*** Bug 1476943 has been marked as a duplicate of this bug. ***