Re: [RFC PATCH 00/22] Replace community.general.zypper

[Anthony Iliopoulos <ailiop@suse.com>]

On Wed, Apr 17, 2024 at 06:48:01PM +0000, Chuck Lever III wrote:
> 
> 
> > On Apr 17, 2024, at 2:39 PM, Anthony Iliopoulos <ailiop@suse.com> wrote:
> > 
> > On Wed, Apr 17, 2024 at 04:57:23PM +0000, Chuck Lever III wrote:
> >> 
> >> 
> >>> On Apr 15, 2024, at 6:38 PM, Anthony Iliopoulos <ailiop@suse.com> wrote:
> >>> 
> >>> On Mon, Apr 15, 2024 at 09:41:38PM +0000, Chuck Lever III wrote:
> >>>> 
> >>>> 
> >>>>> On Apr 15, 2024, at 5:35 PM, Goldwyn Rodrigues <rgoldwyn@suse.com> wrote:
> >>>>> 
> >>>>> On Mon, Apr 15, 2024 at 4:11 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> >>>>>> 
> >>>>>> On Mon, Apr 15, 2024 at 03:32:59PM -0500, Goldwyn Rodrigues wrote:
> >>>>>>> On Mon, Apr 15, 2024 at 9:39 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
> >>>>>>>> 
> >>>>>>>> I've been able to test some of this series with OpenSuSE 15.3.
> >>>>>>>> Found and fixed one bug. I've pushed the result to:
> >>>>>>>> 
> >>>>>>>> https://github.com/chucklever/kdevops/tree/replace-zypper-module
> >>>>>>>> 
> >>>>>>>> However it looks like the fstests workflow hasn't been tested
> >>>>>>>> on SuSE for quite some time.
> >>>>>>>> 
> >>>>>>>> OpenSuSE doesn't like the group name "123456-fsgqa" (and probably
> >>>>>>>> the user name is rejected too, but kdevops tries the group first,
> >>>>>>>> and that's where the workflow fails).
> >>>>>>> 
> >>>>>>> I am able to add users without any issue here.
> >>>>>> 
> >>>>>> Is "here" on an OpenSuSE 15.3 system? I did log into the test system
> >>>>>> and try "groupadd" directly, and it failed in the same way.
> >>>>> 
> >>>>> openSUSE Tumbleweed, but I am sure nothing has changed since openSUSE 15.3
> >>>>> I am able to add the group 123456-fsgqa. However, if you have added a
> >>>>> 123456-fsgqa *user* before it may fail. What is the error message you
> >>>>> get?
> >>>> 
> >>>> TASK [fstests : Add missing groups for fstests] ************************************************************************************************
> >>>> changed: [cel-tmpfs-default] => (item=Ensuring the group sys exists)
> >>>> failed: [cel-tmpfs-default] (item=Ensuring the group 123456-fsgqa exists) => {
> >>>>   "ansible_loop_var": "item",
> >>>>   "changed": false,
> >>>>   "item": "123456-fsgqa",
> >>>>   "name": "123456-fsgqa"
> >>>> }
> >>>> 
> >>>> MSG:
> >>>> 
> >>>> groupadd: '123456-fsgqa' is not a valid group name
> >>>> 
> >>>> I logged in at the time, and tried by hand:
> >>>> 
> >>>> cel-tmpfs-default:~ # groupadd 123456-fsgqa
> >>>> groupadd: '123456-fsgqa' is not a valid group name
> >>>> cel-tmpfs-default:~ #
> >>> 
> >>> The issue is that SLE is using shadow v4.8, and it doesn't allow
> >>> user/group names starting with digits. This was later on relaxed via
> >>> shadow upstream commit cfc981df2afc ("shadow: use relaxed usernames")
> >>> which was released in v4.13. This is why this works in TW.
> >>> 
> >>> I had a local old kdevops patch that did "useradd --badnames -U" to
> >>> bypass the check for SLE.
> >> 
> >> Thanks for the suggestion!
> >> 
> >> The current playbooks/roles/fstests/tasks/main.yml uses
> >> the ansible.builtin.group and ansible.builtin.user
> >> modules, neither of which have a "badname" parameter.
> > 
> > Yes I don't think this was ever implemented in ansible, or at least I
> > don't see anything from a quick look at [1].
> > 
> > The way I had fixed this for SLE was along the lines of:
> > 
> > diff --git a/playbooks/roles/fstests/tasks/main.yml b/playbooks/roles/fstests/tasks/main.yml
> > index 63531f618b4b..e4cc1fa9bfb6 100644
> > --- a/playbooks/roles/fstests/tasks/main.yml
> > +++ b/playbooks/roles/fstests/tasks/main.yml
> > @@ -872,6 +872,7 @@
> >   group:
> >     name: "{{ item }}"
> >     state: present
> > +  command: "useradd --badnames -U {{ item }}"
> 
> This task is supposed to add only the group. A subsequent
> task adds the corresponding user. To make this work I think
> we will need to combine these two tasks and then use the
> command module you have here to run "useradd", which should
> add both the user and group at the same time. No reason I
> can think of to add them separately.

Yes the above diff was just illustrative, in the original local fix I
had this was indeed combined in one task (thus useradd -U), also because
the --badname option was never available for groupadd.

> >   with_items:
> >     - sys
> >     - 123456-fsgqa
> > 
> >> I also looked at Fedora's useradd, and it does not have
> >> "--badname" either.
> > 
> > Which fedora release is that? I can see it in f39 at least, and I think
> > it has been available since f32 which ships shadow-utils v4.8.1 [2] (the
> > --badname(s) option was introduced in shadow v4.8, commit a2cd3e9ef03a).
> 
> I looked on Fedora 38 and now again on 39. groupadd does
> not have a --badname, but I see that useradd does.
> 
> I'll post a patch... if all OS-families do something
> sensible, then this should be easy to do without any
> family-specific processing.

Sure, as long as useradd comes from the shadow-utils package (which is
indeed the case for most of the distros), then this will be fine.

Regards,
Anthony