7:52 a.m.
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?
Thanks,
Devin
8:53 a.m.
New subject: User's primary group set to recently deleted user group
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
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
1835
days inactive
1835
days old
freeipa-users@lists.fedorahosted.org
2 comments
2 participants
participants (2)
-
Devin Roark -
Rob Crittenden