When migrating users, provide an option to migrate groups as UPG. Below is the conversation from IRC which started thie RFE.
09:08 < herlo> attempting to fix an issue I had with UPG brought me to the realization that I needed to create a group for every user I have in IPA. When we migrated, this didn't happen. However, now that I've migrated the private group for my users, I find that it lists that group. When I create a user in the ui (or cli), I get the private group, but it doesn't show up in the UI at all. Is there a reason this is different?
09:10 < herlo> I have a lot of migrated users and would prefer NOT to have them show up in the UI. I usually use the search filter most of the time, but this introduces hundreds of unnecessary records in the ui.
09:11 < rcrit> no, we don't allow that
09:12 < rcrit> herlo, private groups are suppressed from listings by default. IIRC in the UI there is a private checkbox and on the CLI there is a switch to show them
09:13 < herlo> rcrit: so when I did the migrate, it didn't indicate it was a private group, I guess?
09:13 < herlo> rcrit: is there a way to make them migrate properly? I'm clearly just testing this and can do another migrate test if something could change.
09:13 < rcrit> herlo, private groups aren't created in migration
09:14 < herlo> rcrit: oh, so we just need to go through and modify the record once it's migrated?
09:14 < herlo> and that is the only way, right?
09:14 < rcrit> there is no real "make me private" option for a group
09:16 < herlo> rcrit: well, I meant the 'private checkbox' in the UI.
09:16 < simo> herlo: UPGs are created at user-creation time, what rob means is that we have no defined procedure to add them later ..
09:16 < rcrit> herlo, you can't switch a non-private to private
09:16 < herlo> simo: oh.
09:17 < simo> rcrit: well with some manual ldap operations something can be arranged ...
09:17 < herlo> simo: I could live with an ldapmodify of sorts.
09:17 < simo> actually not sure
09:17 < rcrit> that's probably true, we just don't provide a way to do it
09:17 < herlo> any ideas where i could look?
09:17 < rcrit> I've never tried
09:17 < simo> I am not sure we can remove the groupofnames objectclass
09:17 < simo> it could be a semi-private group ...
09:18 < simo> or perhaps simply remove the group and manually recreate it
09:18 < simo> it maybe relative easy to script
09:18 < simo> herlo: you can look at an existing private group to understand how it differs from a normal group
09:18 < rcrit> you need to make a change to the user simultaneously IIRC
09:18 < simo> herlo: every single attribute is important and any missing one is intentionally missing
09:18 < herlo> simo: yeah, was just thinking about scripting it...
09:19 < simo> rcrit: right to anchor the user to the private group
09:19 < rcrit> add mepOriginEntry
09:19 < rcrit> as an objectclass
09:19 < rcrit> and mepManagedEntry pointing to the group
09:20 < herlo> okay, so an ldapmodify with mepOriginEntry for the user, and mepManagedEntry pointing to the dn of the group?
09:20 < herlo> assuming I migrate the groups.
09:21 < herlo> simo: If I just create new groups in IPA, I can mark them private as I create them. I assume I still need to create the mepOriginEntry objectClass and the mepManagedEntry value?
09:23 < rcrit> herlo, you can't create private groups using the ipa tools, only adding a user will create a private group
09:24 < herlo> oh, I see. darn.
09:24 < simo> herlo: it would be best if you could, somehow filter the groups before migration so that private groups are created instead
09:24 < rcrit> you're stuck with ldapmodify I think
09:24 < rcrit> it is hardcoded now to not create private groups IIRC
09:24 < herlo> rcrit: that's okay.
09:24 < simo> rcrit: maybe we should have an option to ignore existing user-groups and instead create private ones in the migratrion mode
09:24 < herlo> simo: I'd like that.
09:24 < simo> it's tricky though
09:25 < herlo> simo: but it doesn't help my situation now. I suspect I'll be doing another migration down the road.
09:25 < rcrit> yes, and it would depend on what stance we decided to take
09:25 < simo> herlo: would you mind opening a RFE ticket in trac ?
09:25 < herlo> simo: I can do that...
09:25 < rcrit> would all private groups be rejected if one was non-conforming
09:25 < rcrit> or would we make private those that we could?
09:26 < simo> rcrit: I would ignore any group that is named as a user (just filter them out completely) and let ipa create the UPG instead
09:26 < rcrit> simo, but what if that group has add'l members in the other system?
09:26 < simo> it's tricky cause we'll need to cross check user names
09:26 < simo> rcrit: too bad, you asked for pvt groups and that's what you got :)
09:26 < rcrit> lol
09:26 < herlo> hehe
09:27 < rcrit> ok, best to capture all this in a ticket I guess
09:27 < herlo> my thought is it's a flag you send to migrate-ds. You either get UPG or you don't.
09:27 < rcrit> that seems to be simo's point of view as well
09:27 < rcrit> and simo always wins ;-)
09:27 < herlo> :)
09:27 < simo> rcrit: more seriously, I guess we can easily filter only groups that have no members, or the only member is the user itself
09:27 < rcrit> yes, that's what I was thinking as well
09:27 < simo> rcrit: it is just a matter of filtering them I think
09:27 < rcrit> but what do we do with those that don't conform? Leave them non-private or force them to private?
09:28 * herlo waits for the conversation to finish so he can bring the conversation into the RFE.
09:28 < rcrit> one idea would be to have an analyze option
09:28 < rcrit> that would run through all the users/groups to figure out if it'd work or not in advance
09:28 < simo> rcrit: I am sure someone will ask for a --force-upg flag :)
09:28 < rcrit> yup
09:28 < rcrit> and as long as we log all the failures it's probably fine anyway
09:29 < rcrit> they can just create a new group, assign the users, fix the perms and things will still work
09:29 < rcrit> where it gets stuck is if, for example, someone adds a user "mock" to their LDAP environment
09:32 < simo> rcrit: they are doing it wrong if they do
09:33 < rcrit> I don't disagree but it may happen
when fixed, provide steps to verify
dpal had an interesting idea:
I would suggest adding a command to add a UPG for a user. ipa user-mod --upg-create dpal. Or something like. Then for users that do not have UPGs due to migration or manual removal there will be a way to create UPG. The command would check the use of the user UID against GID space and if UID is not used would create a UPG otherwise would spit an error allowing caller to decide what to do in this case. The procedure can be scripted and part of the migration and run after migrate DS.
Related freeipa-users discussion: https://www.redhat.com/archives/freeipa-users/2016-January/msg00176.html
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1377241 (Red Hat Enterprise Linux 7)
Metadata Update from @herlo:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @pvoborni:
- Issue close_status updated to: None
to comment on this ticket.