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

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

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.

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.

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

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

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

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

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.

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

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

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.

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.

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

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
>

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. :)

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. :)
>

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.

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 =

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.

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.

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.

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
> >> 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.

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

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 — emphasis on "may", because in most 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.

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

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

--
With respect,
= Aragorn

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 — emphasis on "may", because in most
> 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. ;)

--
With respect,
= Aragorn

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.