[SOLVED] filesystem-2017.10 introduces extensives modifcations

hoschi · 2017-12-10 21:29:02

Hello!

Winter has come and filesystem relies now on systemd-sysusers. This should make maintenance of users and groups easier and builds up on an automatic usage of configurations files, provided by packages responsible for the users and groups. It will not care about the specific users and groups, maintained by the superuser.

The result during upgrade:

( 1/72) upgrading filesystem                                                                               [###############################################################] 100%
warning: /etc/fstab installed as /etc/fstab.pacnew
warning: /etc/group installed as /etc/group.pacnew
warning: /etc/hosts installed as /etc/hosts.pacnew
warning: /etc/nsswitch.conf installed as /etc/nsswitch.conf.pacnew
warning: /etc/passwd installed as /etc/passwd.pacnew
warning: /etc/resolv.conf installed as /etc/resolv.conf.pacnew
warning: /etc/shells installed as /etc/shells.pacnew
warning: /etc/gshadow installed as /etc/gshadow.pacnew
warning: /etc/shadow installed as /etc/shadow.pacnew

That is a much bigger migration than ususal. I want suggest to announce this with a posting in the news, including best practices and instructions. The pacnew-files are of course empty. I assume that I have to migrate all the users, groups and so on manually? Just copy the contents and handling some syntax-modifications?

Thanks
PS: Winter has really come. Today we got a lot of snow here!

// Update
As described here by Eschwartz users don't have to merge the pacnew-files during a regular upgrade of filesystem. Ignore it and you are save! If you want do align syntax and comments for aesthetical reasons you can merge the files - which is your own job and risk.

The only actual modifiction is in nsswitch.conf compatbility "compat" is turned off in favour of "files".

Last edited by hoschi (2017-12-12 21:29:44)

hoschi · 2017-12-10 21:48:39

Here a good example:

/etc/shells

#
# /etc/shells
#

/bin/sh
/bin/bash

# End of file
/usr/bin/git-shell

/etc/shells.pacnew

# Pathnames of valid login shells.
# See shells(5) for details.

/bin/sh
/bin/bash

/usr/bin/git-shell?
And why is that declared after "# End of file"?

https://git.archlinux.org/svntogit/pack … es/git#n11
I would say, the old file is already not "correct".

Last edited by hoschi (2017-12-10 21:51:45)

jasonwryan · 2017-12-10 21:52:44

Shells you install, or in the case of git applications that include a shell, are appended to the file.

hoschi · 2017-12-10 22:12:35

Yep. Thanks! I have already done it so. I was just confused, because I didn't was aware of the "git ssh shell".

# Pathnames of valid login shells.
# See shells(5) for details.

/bin/sh
/bin/bash
/usr/bin/git-shell

Using common sense and copying the configuration values seem to have worked flawlessly. The only weird change I have noticed during migration:

--- passwd	2017-12-10 22:40:29.398990608 +0100
+++ /etc/passwd	2017-12-10 22:49:44.548992568 +0100
@@ -1,4 +1,4 @@
-root:x:0:0:root:/root:/bin/bash
+root:x:0:0::/root:/bin/bash

The new passwd doesn't the "user name or comment field". Poor tiny superuser, lost his comment/name

Last edited by hoschi (2017-12-10 22:13:55)

Omar007 · 2017-12-10 22:13:10

Old file looks fine to me, assuming you have git installed.

For the other files, you probably have to do no merging whatsoever. If you check the files you'll find that all the *.pacnew files specify a subset of information already contained in the ones already on your system.
And that makes sense; over time you've added onto the bare minimum provided by the filesystem package.

The part I'm honestly more curious about is why the git user isn't managed using sysusers.d?

Comment by userwithuid (userwithuid) - Sunday, 02 April 2017, 15:54 GMT
@all:
Should sysusers.d be used to replace useradd/groupadd in .install files for all Arch packages not just filesystem? New TODO list?
-------------------------
Comment by Bruno Pagani (ArchangeGabriel) - Monday, 03 April 2017, 18:04 GMT
@userwithuid: I think it should. It’s already done for numerous packages, and we now have the hook to handle this without even having an .install file.

EDIT: Was posting at the same time as the above message. Leaving it here anyway for the record but it no longer really adds anything xD

Last edited by Omar007 (2017-12-10 22:15:13)

hoschi · 2017-12-10 22:27:57

Some packages do so already (filesystem, systemd, dbus, mysql, gdm and so on). But I think the maintainer would be glad about a feature request.

Am I right, that systemd-sysusers cannot remove users and groups?

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in /etc/sysusers.d/ bearing the same filename.

https://www.freedesktop.org/software/sy … rs.d.html#

This is just the suppression of creation.

Last edited by hoschi (2017-12-10 22:35:33)

kerny · 2017-12-10 22:53:28

hoschi wrote:

Hello!
That is a much bigger migration than ususal. I want suggest to announce this with a posting in the news, including best practices and instructions. The pacnew-files are of course empty. I assume that I have to migrate all the users, groups and so on manually? Just copy the contents and handling some syntax-modifications?

I was surprised by this as well. I've been checking Archlinux news website to see any information about the manual intervention needed. So far nothing. This is a big change and should have been announced accordingly.

Condor · 2017-12-11 17:39:02

Several of the renewed config files are merged into their old counterparts easily enough (e. g. fstab).

Where I stumble are the user and group related files (passwd, group and so forth). How can I establish which additional users, beside my own user account of course, will need to be carried over?

Or, in other words:

hoschi wrote:

Some packages do so already (filesystem, systemd, dbus, mysql, gdm and so on).

How do I establish which packages already utilize systemd-sysusers already, and which don't?

loqs · 2017-12-11 18:14:58

/etc/passwd and similar are handled automatically and should never require manual merging.

eschwartz · 2017-12-11 21:37:56

Omar007 wrote:

Old file looks fine to me, assuming you have git installed.
For the other files, you probably have to do no merging whatsoever. If you check the files you'll find that all the *.pacnew files specify a subset of information already contained in the ones already on your system.
And that makes sense; over time you've added onto the bare minimum provided by the filesystem package.

The part I'm honestly more curious about is why the git user isn't managed using sysusers.d?

sysusers does not allow one to specify the login shell, and always uses the nologin binary. This is problematic for something like git, which wants to use the git-shell wrapper as a login shell...

kerny wrote:

hoschi wrote:
Hello!
That is a much bigger migration than ususal. I want suggest to announce this with a posting in the news, including best practices and instructions. The pacnew-files are of course empty. I assume that I have to migrate all the users, groups and so on manually? Just copy the contents and handling some syntax-modifications?
I was surprised by this as well. I've been checking Archlinux news website to see any information about the manual intervention needed. So far nothing. This is a big change and should have been announced accordingly.

That is specifically because there is *no* manual intervention needed. The best thing you can do is, do nothing.

Never, ever, ever, ever, ever merge the pacnew file for /etc/{passwd,shadow,gshadow,group} unless you want to make the new comments match aesthetically with your in-use user accounts database. The only practical difference that merging can ever cause is to accidentally delete users or mangle the whole file's syntax and render your computer maybe unbootable.

Changes for other pacnew files are mostly irrelevant comment modifications. But there too, the concept of merging a pacnew is hardly new to Arch users. What is special about these ones?

Also the whole "do not merge /etc/passwd.pacnew" thing has always been documented in our Wiki...
https://wiki.archlinux.org/index.php/Us … r_database

Omar007 · 2017-12-11 22:02:27

Eschwartz wrote:

sysusers does not allow one to specify the login shell, and always uses the nologin binary. This is problematic for something like git, which wants to use the git-shell wrapper as a login shell...

And so you learn something new every day. I guess in a way that limitation actually makes sense; why would a system user need a login shell?

koyote · 2017-12-12 13:20:22

I see mkinitcpio.conf has changed " " for ( ). Is safe leave with the " " or must change for ( )?

Sorry for my english.

WorMzy · 2017-12-12 13:41:03

That is an unrelated change and has been discussed in other topics. Please search.

drcouzelis · 2017-12-12 18:34:32

Just a heads up...

I tried deleting all of the entries in my "/etc/passwd" and "/etc/group" files in order to start doing things the fancy new "systemd" way (which I'm sure works great on a fresh installation of Arch Linux).

It was a bad decision. Don't do it. My computer wouldn't boot. Thank goodness for backups.

ugjka · 2017-12-12 19:04:47

drcouzelis wrote:

Just a heads up...
I tried deleting all of the entries in my "/etc/passwd" and "/etc/group" files in order to start doing things the fancy new "systemd" way (which I'm sure works great on a fresh installation of Arch Linux).
It was a bad decision. Don't do it. My computer wouldn't boot. Thank goodness for backups.

If it is not broken, don't fix it atleast until the wiki is updated with new information on how to do things in the fancy "systemd" way

hoschi · 2017-12-12 20:30:28

Eschwartz wrote:

That is specifically because there is *no* manual intervention needed. The best thing you can do is, do nothing.

Thanks

Eschwartz wrote:

Never, ever, ever, ever, ever merge the pacnew file for /etc/{passwd,shadow,gshadow,group}.

This is what I would have expected in the news or pacman output.

Eschwartz wrote:

...unless you want to make the new comments match aesthetically with your in-use user accounts database.

Ooops. You have describe me - literally. But this is my personal problem

What is special about these ones?

It are many files and also a change in how package based users/groups are managed (through systemd). Probably that is also relevant for packagers?

// edit
Marked as solved!

Last edited by hoschi (2017-12-12 20:36:59)

eschwartz · 2017-12-12 22:25:40

drcouzelis wrote:

Just a heads up...
I tried deleting all of the entries in my "/etc/passwd" and "/etc/group" files in order to start doing things the fancy new "systemd" way (which I'm sure works great on a fresh installation of Arch Linux).
It was a bad decision. Don't do it. My computer wouldn't boot. Thank goodness for backups.

Yeah...

About that. Running /usr/bin/system-sysusers will reload the missing system users and groups from the sysusers.d(5) directory drop-ins. This command is not automatically run, until the next time you boot. It is also run via a pacman hook upon package installation or upgrade (the hook only parses the specific drop-ins that have been installed/updated though).

None of this will recreate the user accounts that were created for the purpose of logging in and doing things as a user. It only applies to system accounts.

So you should in theory be perfectly okay the next time you rebooted, except that you'd need to login as root and create a new user or possibly create a user matching the name+uid that corresponds to the orphaned files in /home/*

hoschi · 2017-12-12 23:46:35

Eschwartz wrote:

None of this will recreate the user accounts that were created for the purpose of logging in and doing things as a user. It only applies to system accounts.

Lennart Potter - And the chamber of secrets

kerny · 2017-12-14 01:02:31

Changes for other pacnew files are mostly irrelevant comment modifications. But there too, the concept of merging a pacnew is hardly new to Arch users. What is special about these ones?
Also the whole "do not merge /etc/passwd.pacnew" thing has always been documented in our Wiki...
https://wiki.archlinux.org/index.php/Us … r_database

Thanks!

I've been an Arch user for 7 years now and this is news to me.
All those years I've been painfully merging passwd.pacnew files on every filesystem upgrade.

Last edited by kerny (2017-12-14 01:03:00)

Arch Linux

#1 2017-12-10 21:29:02

[SOLVED] filesystem-2017.10 introduces extensives modifcations

#2 2017-12-10 21:48:39

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#3 2017-12-10 21:52:44

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#4 2017-12-10 22:12:35

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#5 2017-12-10 22:13:10

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#6 2017-12-10 22:27:57

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#7 2017-12-10 22:53:28

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#8 2017-12-11 17:39:02

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#9 2017-12-11 18:14:58

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#10 2017-12-11 21:37:56

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#11 2017-12-11 22:02:27

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#12 2017-12-12 13:20:22

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#13 2017-12-12 13:41:03

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#14 2017-12-12 18:34:32

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#15 2017-12-12 19:04:47

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#16 2017-12-12 20:30:28

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#17 2017-12-12 22:25:40

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#18 2017-12-12 23:46:35

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

#19 2017-12-14 01:02:31

Re: [SOLVED] filesystem-2017.10 introduces extensives modifcations

Board footer