• MCC drakconf problem

    From faeychild@2:250/1 to All on Sat May 22 06:07:09 2021


    I am unable to launch MCC as "user" Clicking on MCC icon and mgaaplet nothing happens

    running drakcong from CL

    [faeychild@unimatrix ~]$ drakconf
    Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
    The value for the SHELL variable was not found the /etc/shells file

    This incident has been reported.


    The content of /etc/shells is

    /bin/bash
    /bin/sh
    /usr/bin/bash
    /usr/bin/dash
    /usr/bin/sh

    It will launch fine from root and from "junk"

    Do I have a permissions problem?

    regards


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat May 22 07:22:12 2021
    On 22/5/21 3:07 pm, faeychild wrote:


    I am unable to launch MCC as "user" Clicking on MCC icon and mgaaplet nothing happens


    No I have a an environment problem

    ~]$ set | grep -i SHELL
    SECSHELL=1
    SHELL=/bin/bin SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor


    env | grep -i SHELL
    SHELL=/bin/bin
    SHELL_SESSION_ID=95fdac2d32b646b194b699e29c78edd7
    SECSHELL=1


    printenv | grep -i SHELL
    SHELL=/bin/bin
    SHELL_SESSION_ID=95fdac2d32b646b194b699e29c78edd7
    SECSHELL=1

    I tried defining in /etc/environment
    and tried to declare in the bash CL but it isn't permanent.
    Finally put it in ~/.bashrc where it works.

    I would be curious to know where $SHELL is initially defined and how it
    is corrupted


    Regards.


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat May 22 08:11:37 2021
    On 22/5/21 4:22 pm, faeychild wrote:


    I would be curious to know where $SHELL is initially defined and how it
    is corrupted


    It's disquietingly defined everywhere


    [root@unimatrix ~]# grep -r "SHELL=" /etc/*
    /etc/anacrontab:SHELL=/bin/sh
    /etc/crontab:SHELL=/bin/bash
    /etc/default/useradd:SHELL=/bin/bash
    /etc/environment:SHELL=/bin/bash
    grep: /etc/grub2-efi.cfg: No such file or directory
    /etc/profile.d/10tmpdir.sh: export SECSHELL=1
    /etc/profile.d/01msec.sh: export SECSHELL=1 /etc/shorewall/shorewall.conf:SHOREWALL_SHELL=/bin/sh /etc/shorewall6/shorewall6.conf:SHOREWALL_SHELL=/bin/sh


    SO... which was original and was changed to reflect `SHELL=/bin/bin` and
    then broke "drakconfig" and trashed my quiet afternoon.




    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sat May 22 11:49:16 2021
    On Sat, 22 May 2021 16:22:12 +1000, faeychild wrote:

    I tried defining in /etc/environment
    and tried to declare in the bash CL but it isn't permanent.
    Finally put it in ~/.bashrc where it works.

    I would be curious to know where $SHELL is initially defined

    A place to start looking
    grep -ir shell /etc/profile.d/*.sh


    Hnnnm, me too. man bash under INVOCATION does not say.

    Looking through my brain book I see
    $ uh login path order
    _path_login_order_ Typical Non-gui login order of execution is _path_login_order_ /etc/login.defs
    _path_login_order_ /etc/profile which sources /etc/profile.d/*.sh scripts _path_login_order_ ~/.bash_profile which sources ~/.bashrc _path_login_order_ ~/.bashrc sources /etc/bashrc
    _path_login_order_ /usr/share/config/kdm/kdmrc

    $ uh dm login
    _login_dm_de_system_loc_ /var/cache/lightdm/dmrc/(user).dmrc _login_dm_de_system_loc_ /var/lib/AccountsService/users/(user) _login_dm_de_system_loc_ /var/lib/lightdm-data/(user) _login_dm_de_system_loc_ $HOME/.dmrc
    _login_tool_ dm-tool switch-to-user browser
    _login_tool_ dm-tool switch-to-user $_sys_owner _Change_graphic_on_login_screen_ /etc/X11/gdm/Init/Default _path_login_order_ /usr/share/config/kdm/kdmrc

    and how it is corrupted

    That would require a bit of work on your part. I had to modify the
    INVOCATION files to dump desired info for debugging these kinds of
    problems.

    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?



    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From TJ@2:250/1 to All on Sat May 22 12:44:31 2021
    On 5/22/21 6:49 AM, Bit Twister wrote:
    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?

    He mentioned "junk" works OK in the original post.

    TJ

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sat May 22 13:21:20 2021
    On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
    On 5/22/21 6:49 AM, Bit Twister wrote:
    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?

    He mentioned "junk" works OK in the original post.

    Shuckey dern, you are correct. Back to speed reading 101 for me.

    As for an owner check the command would be
    find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;

    I have not done Plasma in years, so not sure of what is executed.
    Usual problems occur if save session is enabled.

    Other places to dink up thing is scripts running from the autostart
    directory.

    Usual kde/Plasma check is to just rename the kde sub-directory log
    out/in. Of course that still could save the current environment
    back into the kde directory.

    I found it preferable to do that work via root with the user
    not logged in.

    --- MBSE BBS v1.0.7.21 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat May 22 23:32:14 2021
    On 22/5/21 8:49 pm, Bit Twister wrote:
    On Sat, 22 May 2021 16:22:12 +1000, faeychild wrote:

    I tried defining in /etc/environment
    and tried to declare in the bash CL but it isn't permanent.
    Finally put it in ~/.bashrc where it works.

    I would be curious to know where $SHELL is initially defined

    A place to start looking
    grep -ir shell /etc/profile.d/*.sh


    grep -ir shell /etc/profile.d/*.sh
    /etc/profile.d/01msec.sh:# shell security options
    /etc/profile.d/01msec.sh:if [ -z "$SECSHELL" -a -r /etc/security/shell
    ]; then
    /etc/profile.d/01msec.sh: . /etc/security/shell
    /etc/profile.d/01msec.sh: export SECSHELL=1
    /etc/profile.d/10tmpdir.sh:if [ -z "$SECSHELL" -a -r /etc/security/shell
    ]; then
    /etc/profile.d/10tmpdir.sh: . /etc/security/shell /etc/profile.d/10tmpdir.sh: export SECSHELL=1
    /etc/profile.d/20mc.sh:# Don't define aliases in plain Bourne shell /etc/profile.d/40configure_keyboard.sh:# shell /etc/profile.d/40configure_keyboard.sh:# For other shells, I assume $-
    is not available
    /etc/profile.d/40configure_keyboard.sh:if [ "$SHELL" = "/bin/bash" ]; then /etc/profile.d/60alias.sh:# Don't define aliases in plain Bourne shell /etc/profile.d/95bash-extras.sh: # allow mixing history when several
    shells running in parallel
    /etc/profile.d/ladspa.sh:# Set LADSPA_PATH for Bash shell /etc/profile.d/vte.sh:# Not an interactive shell?



    That would require a bit of work on your part. I had to modify the
    INVOCATION files to dump desired info for debugging these kinds of
    problems.

    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?



    Root and junk were fine. Only user was affected.


    I have done only one "experiment" that could have some bearing. I did
    edit my line in /etc/passwd to be /bin/nologin. Just to see what would happen.

    Surprise surprise! I couldn't log in.

    But that is not going to corrupt the bash env variable.

    But I''l try it again later this afternoon



    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat May 22 23:34:53 2021
    On 22/5/21 10:21 pm, Bit Twister wrote:
    On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
    On 5/22/21 6:49 AM, Bit Twister wrote:
    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?

    He mentioned "junk" works OK in the original post.

    Shuckey dern, you are correct. Back to speed reading 101 for me.

    As for an owner check the command would be
    find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;


    The prompt returns - nothing found


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sat May 22 23:53:03 2021
    On 23/5/21 8:32 am, faeychild wrote:

    But that is not going to corrupt the bash env variable.

    But I''l try it again later this afternoon

    Also later I will remove my override entry in .bashrc and see if the
    SHELL env returns to /bib/bin.

    I should have done that yesterday. clearly not thinking well.


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Sun May 23 00:22:50 2021
    On Sat, 22 May 2021 03:11:37 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
    SO... which was original and was changed to reflect `SHELL=/bin/bin` and
    then broke "drakconfig" and trashed my quiet afternoon.

    What does "grep $USER /etc/passwd" show? The 7th (last) variable defines the shell to use, and does set the initial value used for $SHELL in the environment when the user logs in, though it may be altered by scripts later in the login procedure.

    See "man login".

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun May 23 01:56:37 2021
    On Sun, 23 May 2021 08:34:53 +1000, faeychild wrote:
    On 22/5/21 10:21 pm, Bit Twister wrote:
    On Sat, 22 May 2021 07:44:31 -0400, TJ wrote:
    On 5/22/21 6:49 AM, Bit Twister wrote:
    Have you tried a test account, say junk, to see if it is a system
    wide problem or user problem?

    He mentioned "junk" works OK in the original post.

    Shuckey dern, you are correct. Back to speed reading 101 for me.

    As for an owner check the command would be
    find $HOME \( -not -user $USER -or -not -group $USER \) -exec ls -ald '{}' \;


    The prompt returns - nothing found

    Which is a valid/normal result.

    The fact that junk works indicates the problem is in your account
    and no further research is required for system login files.


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sun May 23 03:18:32 2021
    On 23/5/21 9:22 am, David W. Hodgins wrote:
    On Sat, 22 May 2021 03:11:37 -0400, faeychild
    <faeychild@nomail.afraid.org> wrote:
    SO... which was original and was changed to reflect `SHELL=/bin/bin` and
    then broke "drakconfig" and trashed my quiet afternoon.

    What does "grep $USER /etc/passwd" show? The 7th (last) variable defines
    the
    shell to use, and does set the initial value used for $SHELL in the environment
    when the user logs in, though it may be altered by scripts later in the login

    That's the best clue so far for the origin
    But my passwd login shell was is /bin/bash. Surely no program would
    change that - I hope


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun May 23 03:24:45 2021
    On Sun, 23 May 2021 12:18:32 +1000, faeychild wrote:
    On 23/5/21 9:22 am, David W. Hodgins wrote:
    On Sat, 22 May 2021 03:11:37 -0400, faeychild
    <faeychild@nomail.afraid.org> wrote:
    SO... which was original and was changed to reflect `SHELL=/bin/bin` and >>> then broke "drakconfig" and trashed my quiet afternoon.

    What does "grep $USER /etc/passwd" show? The 7th (last) variable defines
    the
    shell to use, and does set the initial value used for $SHELL in the
    environment
    when the user logs in, though it may be altered by scripts later in the
    login

    That's the best clue so far for the origin
    But my passwd login shell was is /bin/bash. Surely no program would
    change that - I hope

    Problem has got to be in your account.

    Back out your .bashrc change, boot run level 3, log in and
    echo $SHELL

    if valid you know something in Desktop Environment is causing the
    problem.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sun May 23 04:23:15 2021
    On 23/5/21 12:24 pm, Bit Twister wrote:

    Problem has got to be in your account.

    Yes! and it has cleared up

    Back out your .bashrc change, boot run level 3, log in and
    echo $SHELL

    it was /bin/bash

    and it still is, on the Desktop with the .bashrc shell entry remmed out

    FWIW Since the shell mod and the user passwd editing yesterday I
    have a new user on the login screen called "system user for..."

    It's not in the passwd file



    if valid you know something in Desktop Environment is causing the
    problem.


    I have been going over the events of yesterday as much as I remember and
    I am staring to blame myself.
    When I edited the passwd file experimentally to show /bin/nologin, did I restore it properly afterward?.
    Could I have typed /bin/bin?
    Have I given myself the runaround?

    It seem more likely than an OS fault. PEBKAC

    I suppose the upside of dumb-ass errors is the education you get from them.


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Sun May 23 09:17:07 2021
    On Sun, 23 May 2021 13:23:15 +1000, faeychild wrote:
    On 23/5/21 12:24 pm, Bit Twister wrote:

    Problem has got to be in your account.

    Yes! and it has cleared up

    Back out your .bashrc change, boot run level 3, log in and
    echo $SHELL

    it was /bin/bash

    and it still is, on the Desktop with the .bashrc shell entry remmed out

    FWIW Since the shell mod and the user passwd editing yesterday I
    have a new user on the login screen called "system user for..."

    It's not in the passwd file

    Yep, the Greeter keeps a list of users so it knows which Display Environment
    is to be used for the user.

    And, is yet another reason not to edit /etc/passwd file with an editor.

    if valid you know something in Desktop Environment is causing the
    problem.


    I have been going over the events of yesterday as much as I remember and
    I am staring to blame myself.

    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.

    When I edited the passwd file experimentally to show /bin/nologin, did I restore it properly afterward?.
    Could I have typed /bin/bin?
    Have I given myself the runaround?

    It seem more likely than an OS fault. PEBKAC

    I suppose the upside of dumb-ass errors is the education you get from them.



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Sun May 23 23:22:53 2021
    On 23/5/21 6:17 pm, Bit Twister wrote:


    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.


    As root

    ~]# pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes



    [root@unimatrix ~]# grpck -r
    'faeychild' is a member of the 'lp' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdrom' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdwriter' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'systemd-journal' group in /etc/group but
    not in /etc/gshadow
    'faeychild' is a member of the 'scanner' group in /etc/group but not in /etc/gshadow
    [root@unimatrix ~]#

    Does faeychild need to be in gshadow?



    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Mon May 24 00:14:58 2021
    On Sun, 23 May 2021 18:22:53 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
    [root@unimatrix ~]# grpck -r
    'faeychild' is a member of the 'lp' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdrom' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdwriter' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'systemd-journal' group in /etc/group but
    not in /etc/gshadow
    'faeychild' is a member of the 'scanner' group in /etc/group but not in /etc/gshadow
    [root@unimatrix ~]#

    Does faeychild need to be in gshadow?

    Did you copy one or more of the files /etc/passwd, /etc/shadow, /etc/group,
    and /etc/gshadow from another install or manually edit them?

    The files are supposed to be kept in sync with each other and the standard utilities for working with them ensure that's done.

    I think it's saying that according to /etc/group your id is in the lp group, but isn't in the lp group according to /etc/gshadow. Same with the other
    groups it's showing.

    I have no idea what type of impact that may have.

    First check the permissions ...
    # ll /etc/passwd /etc/shadow /etc/group /etc/gshadow
    -rw-r--r-- 1 root root 2581 Jan 1 17:48 /etc/group
    -r--r----- 1 root shadow 2188 Jan 1 17:48 /etc/gshadow
    -rw-r--r-- 1 root root 5652 Feb 7 17:04 /etc/passwd
    -r--r----- 1 root shadow 2444 Feb 7 17:04 /etc/shadow

    Read "man pwconv". After fixing the permissions and ownership if needed, I think
    running the "grpconv" command will repair the gshadow file.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Mon May 24 00:36:40 2021
    On 2021-05-23, faeychild <faeychild@nomail.afraid.org> wrote:
    On 23/5/21 6:17 pm, Bit Twister wrote:


    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.


    As root

    ~]# pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist

    This one seems to have been a typo you probably introduced in your
    playing around with nologin.
    It should be /sbin/nologin, not s/bin/nologin

    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    The rest do nor really matter unless you want something to actually
    login to those users.
    (They also exist on my Mga8-- some problem in the installation rpm
    scripts I presume).




    [root@unimatrix ~]# grpck -r
    'faeychild' is a member of the 'lp' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdrom' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdwriter' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'systemd-journal' group in /etc/group but
    not in /etc/gshadow
    'faeychild' is a member of the 'scanner' group in /etc/group but not in /etc/gshadow

    Since you undoubtedly do not have any passwords anyway, it does not
    matter. However, if you did have group passwords, this would allow you
    to user your group identity without a password (man gshadow)

    [root@unimatrix ~]#

    Does faeychild need to be in gshadow?




    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 02:18:50 2021
    On 24/5/21 9:14 am, David W. Hodgins wrote:

    Did you copy one or more of the files /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow from another install or manually edit them?

    I don't remember but I doubt that I would transfer that type of file.



    The files are supposed to be kept in sync with each other and the standard utilities for working with them ensure that's done.

    I think it's saying that according to /etc/group your id is in the lp
    group,
    but isn't in the lp group according to /etc/gshadow. Same with the other groups it's showing.

    I have no idea what type of impact that may have.

    First check the permissions ...
    # ll /etc/passwd /etc/shadow /etc/group /etc/gshadow
    -rw-r--r-- 1 root root   2581 Jan  1 17:48 /etc/group
    -r--r----- 1 root shadow 2188 Jan  1 17:48 /etc/gshadow
    -rw-r--r-- 1 root root   5652 Feb  7 17:04 /etc/passwd
    -r--r----- 1 root shadow 2444 Feb  7 17:04 /etc/shadow

    Read "man pwconv". After fixing the permissions and ownership if needed,
    I think
    running the "grpconv" command will repair the gshadow file.

    Regards, Dave Hodgins


    Ok I've snipped this text. Believe it or not I was completely unaware
    of the group shadow file.

    regards
    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 02:33:00 2021
    On 24/5/21 9:36 am, William Unruh wrote:
    On 2021-05-23, faeychild <faeychild@nomail.afraid.org> wrote:
    On 23/5/21 6:17 pm, Bit Twister wrote:


    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.


    As root

    ~]# pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist

    This one seems to have been a typo you probably introduced in your
    playing around with nologin.
    It should be /sbin/nologin, not s/bin/nologin

    Agreed. Some massive scrambling seems to have occurred.
    mea culpa


    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    The rest do nor really matter unless you want something to actually
    login to those users.
    (They also exist on my Mga8-- some problem in the installation rpm
    scripts I presume).

    I sort of presumed that the entries may be created when the program runs


    Since you undoubtedly do not have any passwords anyway, it does not
    matter. However, if you did have group passwords, this would allow you
    to user your group identity without a password (man gshadow)

    So much to read - so little time


    regards


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 02:38:10 2021
    On 24/5/21 9:14 am, David W. Hodgins wrote:


    Read "man pwconv". After fixing the permissions and ownership if needed,
    I think
    running the "grpconv" command will repair the gshadow file.

    Regards, Dave Hodgins


    "grpconv" ran clean

    and now "grpck -r" returns nothing

    regards
    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon May 24 03:02:40 2021
    On Mon, 24 May 2021 08:22:53 +1000, faeychild wrote:
    On 23/5/21 6:17 pm, Bit Twister wrote:


    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.


    As root

    ~]# pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    As root, run mkdir on each directory that does not exist.

    No good idea why nscd is dinked up uless a problem in the biological
    unit between keyboard and chair.

    s/bin/nologin should be /sbin/nologin






    [root@unimatrix ~]# grpck -r
    'faeychild' is a member of the 'lp' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdrom' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'cdwriter' group in /etc/group but not in /etc/gshadow
    'faeychild' is a member of the 'systemd-journal' group in /etc/group but
    not in /etc/gshadow
    'faeychild' is a member of the 'scanner' group in /etc/group but not in /etc/gshadow
    [root@unimatrix ~]#

    Any shadow or gshadow messages indicate someone or something
    is modifying /etc/password or /etc/group without using the
    correct maintenance tool.

    Does faeychild need to be in gshadow?

    Well as far as I am concerned, any message from pwck or grpck
    is a problem. I run both in my nightly sys_audit cron job.

    I suggest you should/need to run
    usermod --append --groups \
    lp cdrom cdwriter usb systemd-journal wireshark scanner

    after all changes run
    pwck -r
    grpck -r
    again.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon May 24 03:10:32 2021
    On Mon, 24 May 2021 11:38:10 +1000, faeychild wrote:
    On 24/5/21 9:14 am, David W. Hodgins wrote:


    Read "man pwconv". After fixing the permissions and ownership if needed,
    I think
    running the "grpconv" command will repair the gshadow file.

    Regards, Dave Hodgins


    "grpconv" ran clean

    and now "grpck -r" returns nothing

    regards

    Looking in my faeychild file you might want to verify the groups
    you want to be in. My file has you with
    lp cdrom cdwriter usb systemd-journal wireshark scanner

    Check with id -nG



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon May 24 03:53:28 2021
    On Mon, 24 May 2021 08:22:53 +1000, faeychild wrote:
    On 23/5/21 6:17 pm, Bit Twister wrote:


    You might want to run
    pwck -r
    grpck -r
    and if nothing comes back, you know passwd and group are in sync.


    As root

    ~]# pwck -r
    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    Forgot to add after running mkdir, you need to run chmod
    to set uid/gid to same as user's uid/gid


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 04:25:18 2021
    On 24/5/21 12:10 pm, Bit Twister wrote:


    Looking in my faeychild file you might want to verify the groups
    you want to be in. My file has you with
    lp cdrom cdwriter usb systemd-journal wireshark scanner

    Check with id -nG



    id -nG
    faeychild lp cdrom cdwriter systemd-journal scanner
    [faeychild@unimatrix ~]$


    Clearly some minor slippage.
    I'm a tad impressed with you "Dossier"

    It may put the CIA to shame

    [root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
    usermod: group 'wireshark' does not exist
    usermod: group '' does not exist


    where does group '' come from?


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 04:49:32 2021
    On 24/5/21 12:02 pm, Bit Twister wrote:


    As root, run mkdir on each directory that does not exist.

    No good idea why nscd is dinked up uless a problem in the biological
    unit between keyboard and chair.

    Yes!! That idiot causes enormous grief





    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 04:51:29 2021
    On 24/5/21 12:53 pm, Bit Twister wrote:

    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    Forgot to add after running mkdir, you need to run chmod
    to set uid/gid to same as user's uid/gid


    "root uid/gid" surely


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Mon May 24 05:32:35 2021
    On Sun, 23 May 2021 23:51:29 -0400, faeychild <faeychild@nomail.afraid.org> wrote:

    On 24/5/21 12:53 pm, Bit Twister wrote:

    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    Forgot to add after running mkdir, you need to run chmod
    to set uid/gid to same as user's uid/gid


    "root uid/gid" surely

    In this case I disagree with Bit Twister. I wouldn't create the missing home directories, just fix the nscd entry.

    The users are among the standard ones included in all Mageia installs as
    the initial /etc/passwd file from the setup package. https://gitweb.mageia.org/software/setup/tree/passwd

    The directories only actually get created if the associated package(s) are installed. For example /var/spool/news is used by leafnode, and various other usenet related packages. They are specified in the setup package mostly for historical reasons, and also to ensure there are not multiple directories created
    by the various packages and they can work together. Those packages will ensure the directories they create have the correct owner, group, and permissions.

    While creating the directories shouldn't cause any harm, it also doesn't do anything useful. It is just a waste of resources and a potential cause for a future bug if the ownership/permissions are not set as they would be by those packages.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Mon May 24 05:40:16 2021
    On Sun, 23 May 2021 23:25:18 -0400, faeychild <faeychild@nomail.afraid.org> wrote:
    [root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
    usermod: group 'wireshark' does not exist
    usermod: group '' does not exist

    where does group '' come from?

    The usermod program doesn't like the space after the comma, so the command failed
    with no changes made.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 05:47:45 2021
    On 24/5/21 2:40 pm, David W. Hodgins wrote:
    On Sun, 23 May 2021 23:25:18 -0400, faeychild
    <faeychild@nomail.afraid.org> wrote:
    [root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
    usermod: group 'wireshark' does not exist
    usermod: group '' does not exist

    where does group '' come from?

    The usermod program doesn't like the space after the comma, so the
    command failed
    with no changes made.



    ten four

    regards
    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Mon May 24 05:53:13 2021
    On 24/5/21 2:32 pm, David W. Hodgins wrote:


    While creating the directories shouldn't cause any harm, it also doesn't do anything useful. It is just a waste of resources and a potential cause
    for a
    future bug if the ownership/permissions are not set as they would be by those
    packages.

    Regards, Dave Hodgins


    I will pull all this down eventually because the scanner doesn't work
    and a fresh install is in the wind.

    The scanner does work in my test install of Mageia 8 and my booting
    backward and forward to use it must come to an end.


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon May 24 09:50:02 2021
    On Mon, 24 May 2021 13:51:29 +1000, faeychild wrote:
    On 24/5/21 12:53 pm, Bit Twister wrote:

    user 'adm': directory '/var/adm' does not exist
    user 'news': directory '/var/spool/news' does not exist
    user 'uucp': directory '/var/spool/uucp' does not exist
    user 'nscd': program 's/bin/nologin' does not exist
    user 'avahi-autoipd': directory '/var/lib/avahi-autoipd' does not exist
    pwck: no changes

    Forgot to add after running mkdir, you need to run chown
    to set uid/gid to same as user's uid/gid


    "root uid/gid" surely

    Not hardly. If you were to grep /etc/passwd for each, you can
    get the uid:gid. For example

    # grep uucp /etc/passwd
    uucp:x:10:14:uucp:/var/spool/uucp:/bin/sh

    mkdir -p /var/spool/uucp
    chown 10:14 var/spool/uucp



    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Mon May 24 10:26:33 2021
    On Mon, 24 May 2021 13:25:18 +1000, faeychild wrote:

    [root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
    usermod: group 'wireshark' does not exist
    usermod: group '' does not exist


    where does group '' come from?

    I screwed up, there should not have been any spaces in the group list.
    Also forgot to add your user id. Updated the faeychild text file to have


    # usermod --append --groups faeychild \
    lp,cdrom,cdwriter,usb,systemd-journal,wireshark,scanner

    log out/in and check with
    $ id -nG

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Mon May 24 10:29:06 2021
    On Mon, 24 May 2021 04:50:02 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
    Not hardly. If you were to grep /etc/passwd for each, you can
    get the uid:gid. For example

    # grep uucp /etc/passwd
    uucp:x:10:14:uucp:/var/spool/uucp:/bin/sh

    mkdir -p /var/spool/uucp
    chown 10:14 var/spool/uucp

    But should it be root owned with the group set to uucp, vice-versa, or both
    set to uucp? Should it be only owner readable, etc.?

    Set the permissions wrong and then install a usenet feed sharing program (i.e. one
    of the uucp server packages), and it may or may not work properly with the settings
    chosen, if that program doesn't alter the choices for an existing directory and only sets them if it creates the directory on the package installation.

    Other then getting rid if the messages from the grpck/pwck programs which you normally should not be running manually, creating the directories is of no use and may cause problems later.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Tue May 25 00:09:42 2021
    On 24/5/21 7:26 pm, Bit Twister wrote:
    On Mon, 24 May 2021 13:25:18 +1000, faeychild wrote:

    [root@unimatrix ~]# usermod -a -G wireshark, usb, faeychild
    usermod: group 'wireshark' does not exist
    usermod: group '' does not exist


    where does group '' come from?

    I screwed up, there should not have been any spaces in the group list.
    Also forgot to add your user id. Updated the faeychild text file to have

    Maybe, but it was a discovery moment. I found that the trailing comma
    is also not allowed :-)


    # usermod --append --groups faeychild \
    lp,cdrom,cdwriter,usb,systemd-journal,wireshark,scanner

    OK you've thrown me a bit, Is faeychild a group in this case, what does
    the backslash do and should not the user name be tacked on the end?


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Tue May 25 00:15:27 2021
    On 24/5/21 6:50 pm, Bit Twister wrote:

    Forgot to add after running mkdir, you need to run chown
    to set uid/gid to same as user's uid/gid


    "root uid/gid" surely

    Not hardly. If you were to grep /etc/passwd for each, you can
    get the uid:gid. For example

    # grep uucp /etc/passwd
    uucp:x:10:14:uucp:/var/spool/uucp:/bin/sh

    mkdir -p /var/spool/uucp
    chown 10:14 var/spool/uucp


    I thought you meant he user users uid:gid eg: mine: faeychild

    cross purposes again :-)


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Tue May 25 02:58:10 2021
    On Tue, 25 May 2021 09:09:42 +1000, faeychild wrote:

    # usermod --append --groups faeychild \
    lp,cdrom,cdwriter,usb,systemd-journal,wireshark,scanner

    OK you've thrown me a bit, Is faeychild a group in this case, what does
    the backslash do

    A trailing ' \' on a bash command tells bash that there are more
    arguments on the next line. I use it all the time in scripts to keep
    line lengths less than 80 characters for printing.

    Also helps when posting to Usenet with a good Usenet client that
    will prompt you to fix long lines to meet Usenet guidelines.

    and should not the user name be tacked on the end?

    Ah, Frap. You are correct. I screwed up yet again.
    There goes all my gold stars for this month.

    Anytime a command returns an error/warning you should
    check the man page.


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Tue May 25 03:18:29 2021
    On Mon, 24 May 2021 05:29:06 -0400, David W. Hodgins wrote:
    On Mon, 24 May 2021 04:50:02 -0400, Bit Twister <BitTwister@mouse-potato.com> wrote:
    Not hardly. If you were to grep /etc/passwd for each, you can
    get the uid:gid. For example

    # grep uucp /etc/passwd
    uucp:x:10:14:uucp:/var/spool/uucp:/bin/sh

    mkdir -p /var/spool/uucp
    chown 10:14 var/spool/uucp

    But should it be root owned with the group set to uucp, vice-versa, or both set to uucp? Should it be only owner readable, etc.?

    Set the permissions wrong and then install a usenet feed sharing program (i.e. one
    of the uucp server packages), and it may or may not work properly with the settings
    chosen, if that program doesn't alter the choices for an existing directory and
    only sets them if it creates the directory on the package installation.

    Other then getting rid if the messages from the grpck/pwck programs which you normally should not be running manually, creating the directories is of no use
    and may cause problems later.


    I will conceded to all your possible problem arguments.
    As for running pwck/grpck manually I suggest it is a good practice
    as a basic check of your work like the s/bin instead of /sbin problem
    we saw.

    Since I use pwck in
    grep 'pwck -r' * | wc -l
    34
    scripts I'll stick with creating missing login directories and try to
    remember your comments when suggesting pwck usage.




    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Tue May 25 23:49:06 2021
    On 25/5/21 11:58 am, Bit Twister wrote:
    On Tue, 25 May 2021 09:09:42 +1000, faeychild wrote:

    # usermod --append --groups faeychild \
    lp,cdrom,cdwriter,usb,systemd-journal,wireshark,scanner

    OK you've thrown me a bit, Is faeychild a group in this case, what does
    the backslash do

    A trailing ' \' on a bash command tells bash that there are more
    arguments on the next line. I use it all the time in scripts to keep
    line lengths less than 80 characters for printing.


    I suspected as much. Sorry to be a pedant



    usermod --append --groups faeychild <snip>

    Purely academically What happens if I am not added to my group?

    regards

    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 26 01:20:37 2021
    On 2021-05-25, faeychild <faeychild@nomail.afraid.org> wrote:
    On 25/5/21 11:58 am, Bit Twister wrote:
    On Tue, 25 May 2021 09:09:42 +1000, faeychild wrote:

    # usermod --append --groups faeychild \
    lp,cdrom,cdwriter,usb,systemd-journal,wireshark,scanner

    OK you've thrown me a bit, Is faeychild a group in this case, what does
    the backslash do

    A trailing ' \' on a bash command tells bash that there are more
    arguments on the next line. I use it all the time in scripts to keep
    line lengths less than 80 characters for printing.


    I suspected as much. Sorry to be a pedant



    usermod --append --groups faeychild <snip>

    Purely academically What happens if I am not added to my group?

    You do not have to be, assuming that that group is what is listed in /etc/passwd/
    username:password:uid:gid:Name:homedirectory
    That gid is automatically associated with that userid. No need to make
    it explicit in /etc/group. And it could be any gid, it does not have to
    have the username as the groupname.
    Eg, youo could have all users have the same gid, making it easier for
    them to share files.

    regards


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Wed May 26 02:27:39 2021
    On Wed, 26 May 2021 08:49:06 +1000, faeychild wrote:


    usermod --append --groups faeychild <snip>

    Purely academically What happens if I am not added to my group?

    Then you might not have access to files/directories that you want.

    The question is somewhat vague, to me, based on your latest adventure.

    For instance you have decided to quit mucking around with with a file
    editor in passwd/group and chose to use mcc. It is pretty easy for you
    to just check box the desired groups, but it is just as easy to change
    your primary group which will prevent you from logging in and/or access
    to other files.

    I suggest that any future experiments be done to a test account. :)


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 26 03:51:21 2021
    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Wed, 26 May 2021 08:49:06 +1000, faeychild wrote:


    usermod --append --groups faeychild <snip>

    Purely academically What happens if I am not added to my group?

    Then you might not have access to files/directories that you want.

    ?? You are the user. You have access to your own files already.

    There is a main group, which is what is in /etc/passwd, the third entry
    on your line. By default that is a group with your name in /etc/group,
    but it could be any group. It is the group that will be the group owner
    of any file your create. Then there are the additional groups you are
    enrolled in. They are the ones where your user name is entered into the
    end the of the group entry in /etc/group.

    The question is somewhat vague, to me, based on your latest adventure.

    For instance you have decided to quit mucking around with with a file
    editor in passwd/group and chose to use mcc. It is pretty easy for you
    to just check box the desired groups, but it is just as easy to change
    your primary group which will prevent you from logging in and/or access
    to other files.
    No idea what you mean. Do you have an example?



    I suggest that any future experiments be done to a test account. :)


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Wed May 26 10:36:29 2021
    On Wed, 26 May 2021 02:51:21 -0000 (UTC), William Unruh wrote:
    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:

    For instance you have decided to quit mucking around with with a file
    editor in passwd/group and chose to use mcc. It is pretty easy for you
    to just check box the desired groups, but it is just as easy to change
    your primary group which will prevent you from logging in and/or access
    to other files.
    No idea what you mean. Do you have an example?

    If you mean an example of that screw up, no. If you mean where, then there is
    mcc->System->Manage users on system
    Right click a user and pick Edit, then click/select Groups in the pop
    up screen and note the
    Primary Group
    selection box bottom of screen.


    Note to users doing a su - root and run mcc.
    Ignore all the Glib, Oops and Override messages.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Aragorn@2:250/1 to All on Wed May 26 16:17:49 2021
    On 26.05.2021 at 00:20, William Unruh scribbled:

    On 2021-05-25, faeychild <faeychild@nomail.afraid.org> wrote:

    Purely academically What happens if I am not added to my group?

    You do not have to be, assuming that that group is what is listed in /etc/passwd/
    username:password:uid:gid:Name:homedirectory
    That gid is automatically associated with that userid. No need to make
    it explicit in /etc/group. And it could be any gid, it does not have
    to have the username as the groupname.
    Eg, youo could have all users have the same gid, making it easier for
    them to share files.

    That's how RedHat used to do it, and if I remember correctly, so did
    the first couple of versions of Mandrake.

    The group for every new user account would always default to "users",
    but this would require a different umask for users, for reasons of
    privacy. That's why it was decided to give each new user account a
    primary group matching their user name and maintain a system-wide umask
    of 022. (Personally, I use a umask of 077 for unprivileged user
    accounts above UID 1000.)


    --
    With respect,
    = Aragorn =


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 26 16:38:50 2021
    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Wed, 26 May 2021 02:51:21 -0000 (UTC), William Unruh wrote:
    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:

    For instance you have decided to quit mucking around with with a file
    editor in passwd/group and chose to use mcc. It is pretty easy for you
    to just check box the desired groups, but it is just as easy to change
    your primary group which will prevent you from logging in and/or access
    to other files.
    No idea what you mean. Do you have an example?

    If you mean an example of that screw up, no.
    Yes an example of how not putting the user as a member of their own
    primary group could screw things up. The user is automatically amember
    of their own primary group and has all of the priveledges thereof. No
    need to enter them into membership in /etc/group. So I am trying to
    imagine how not doing so could ever cause trouble.
    It certainly causes no harm as far as I can see, but neither does not
    doing so. I see it as simply being redundant, but you seemed to imply
    otherwise and I am wondering if I have overlooked something.




    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Bit Twister@2:250/1 to All on Wed May 26 19:20:22 2021
    On Wed, 26 May 2021 15:38:50 -0000 (UTC), William Unruh wrote:

    .. I see it as simply being redundant, but you seemed to imply
    otherwise and I am wondering if I have overlooked something.

    Conversation I was in was about changing primary group in mcc.
    Not about user wanting/needing to be in their group.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From William Unruh@2:250/1 to All on Wed May 26 20:10:33 2021
    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Wed, 26 May 2021 15:38:50 -0000 (UTC), William Unruh wrote:

    . I see it as simply being redundant, but you seemed to imply
    otherwise and I am wondering if I have overlooked something.

    Conversation I was in was about changing primary group in mcc.
    Not about user wanting/needing to be in their group.
    OK, I misunderstood. But again I ask whether I have misunderstood
    something. If a user changes their primary group ( which the
    installation script in Mageia makes their own group) I cannot imagine
    how that that could cause trouble in booting or in logging in. AFAIK,
    the files in the user's home have both the UID and the group be the
    user's UID and primary group. Or sometimes perhaps, the user's UID and the group
    of some other system service (although I have not seen any file like
    that . I just checked and all files in my home have group be my primary
    group).

    But even if I changed them all, I would not expect to have any problems booting. Again I may have overlooked something which is why I am asking.


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From Aragorn@2:250/1 to All on Wed May 26 20:55:32 2021
    On 26.05.2021 at 19:10, William Unruh scribbled:

    On 2021-05-26, Bit Twister <BitTwister@mouse-potato.com> wrote:
    On Wed, 26 May 2021 15:38:50 -0000 (UTC), William Unruh wrote:

    . I see it as simply being redundant, but you seemed to imply =20
    otherwise and I am wondering if I have overlooked something. =20

    Conversation I was in was about changing primary group in mcc.
    Not about user wanting/needing to be in their group. =20
    OK, I misunderstood. But again I ask whether I have misunderstood
    something. If a user changes their primary group ( which the
    installation script in Mageia makes their own group) I cannot imagine
    how that that could cause trouble in booting or in logging in. AFAIK,
    the files in the user's home have both the UID and the group be the
    user's UID and primary group. Or sometimes perhaps, the user's UID
    and the group of some other system service (although I have not seen
    any file like that . I just checked and all files in my home have
    group be my primary group).
    =20
    But even if I changed them all, I would not expect to have any
    problems booting. Again I may have overlooked something which is why
    I am asking.

    A user's primary group only matters with regard to the files and
    directories the user creates. =20

    Whether the user has read or read/write access to directories and files
    has nothing to do with what the user's primary group is, although it may
    depend on whether the user belongs to the group that owns the directory
    or the file =E2=80=94 emphasis on "may", because in most GNU/Linux distribu= tions
    intended for desktop use, just about every system-owned directory
    (except for /root [*]) has 755 permissions and every system-owned file
    either has 644 permissions if it's not executable, or 755 if it is
    executable.

    There is no way that changing a user's primary group would prevent the
    system from booting or the user from logging in.


    [*] /root =E2=80=94 i.e. the root user's home directory =E2=80=94 normally = has either
    750 or 700 permissions.

    --=20
    With respect,
    =3D Aragorn =3D


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (2:250/1@fidonet)
  • From Aragorn@2:250/1 to All on Wed May 26 20:58:18 2021
    On 26.05.2021 at 21:55, Aragorn scribbled:

    Whether the user has read or read/write access to directories and
    files has nothing to do with what the user's primary group is,
    although it may depend on whether the user belongs to the group that
    owns the directory or the file =E2=80=94 emphasis on "may", because in mo=
    st
    GNU/Linux distributions intended for desktop use, just about every system-owned directory (except for /root [*]) has 755 permissions and
    every system-owned file either has 644 permissions if it's not
    executable, or 755 if it is executable.

    Of course, /etc/shadow and /etc/gshadow have 600 permissions, but I
    didn't expect anyone to take my statement as literally applicable to
    EVERY file. ;)


    --=20
    With respect,
    =3D Aragorn =3D


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Strider (2:250/1@fidonet)
  • From David W. Hodgins@2:250/1 to All on Wed May 26 21:05:42 2021
    On Wed, 26 May 2021 15:10:33 -0400, William Unruh <unruh@invalid.ca> wrote:
    something. If a user changes their primary group ( which the
    installation script in Mageia makes their own group) I cannot imagine
    how that that could cause trouble in booting or in logging in. AFAIK,

    First, the user can not change their primary group, or add/remove their id to/from
    other groups. Only root can do that. The user can change the group of files and directories they own to any group they are a member of.

    Changing the user's primary group would have no impact on the user. It only has impact on others (if any), that root has chosen to also make members of your primary group.

    If you look at the way imap is implemented, in my /home/dave directory ...
    $ tree -ifaug mail
    mail
    [dave mail ] mail/.imap
    [dave mail ] mail/.imap/dovecot.list.index.log
    [dave mail ] mail/.imap/INBOX
    [dave mail ] mail/.imap/INBOX/dovecot.index
    [dave mail ] mail/.imap/INBOX/dovecot.index.cache
    [dave mail ] mail/.imap/INBOX/dovecot.index.log

    So the directory /home/dave/mail has it's group set to mail, with group permissions
    that allows the imap daemon (which runs with the id mail) to update the files within
    that directory tree. Note that my id is a member of the mail group.

    Another way that could have been implemented would be to add my group as an additional group for the mail user and give those directories and files group write access, but that would mean the mail user would have access to all of my files that have my group id.

    Remember, any changes root makes regarding which groups your id is a member of only
    take effect when you next login.

    Regards, Dave Hodgins

    --
    Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
    email replies.

    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)
  • From faeychild@2:250/1 to All on Fri May 28 03:42:59 2021
    On 26/5/21 10:20 am, William Unruh wrote:


    Eg, youo could have all users have the same gid, making it easier for
    them to share files.


    Ah yes . That's one of those things that are only immediately obvious
    AFTER being pointed out. :-]


    --
    faeychild
    Running plasmashell 5.20.4 on 5.10.33-desktop-1.mga8 kernel.
    Mageia release 8 (Official) for x86_64 installed via Mageia-8-x86_64-DVD.iso


    --- MBSE BBS v1.0.7.22 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (2:250/1@fidonet)