11:01 a.m.
Thank you for your time, Rob. I see what I was doing wrong, when I was
running `ipa group-find` I wasn't using the `--private` flag, which won't
show the primary user groups. I see that user still has a private group
with the corresponding uid-matched gid, so I will go ahead and make the
necessary changes.
To answer your second question: other than the IPA users' home directories
across the infrastructure we haven't found files/directories owned by this
group.
Again thank you for your help,
Devin
On Tue, Apr 16, 2019 at 9:53 AM Rob Crittenden <rcritten(a)redhat.com> wrote:
Devin Roark via FreeIPA-users wrote:
> Hello,
>
> I have inherited a freeipa cluster and during a cleanup of groups. We
> discovered one of the groups that was deleted was set as a couple user's
> primary gid in the past, which I'm assuming was a manual process because
> it looks like the default behavior is the standard groupname/gid
> matching the username/uid in FreeIPA. This causes errors when on
> enrolled hosts, bash runs the id command behind the scenes and
> subsequently breaks some automated pipelines for these users.
>
> Although doing an `ipa group-find --gid=${CORRESPONDING_UID}` doesn't
> return any groups but users still match uid's and gid's, my thinking is
> if we modify these two users to use their UID's as their primary group
> again the issues will be resolved.
>
> My question is will this have any known unintended consequences?
But the user will still point to a non-existent group so I don't know
that anything will change. Why not create a matching group for the user
with the same name and uid and set the user's gid to that?
I assume you've already checked for files owned by the now-deleted groups.
rob