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