You are not logged in.

#1 2017-12-13 08:10:20

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Problems with/etc/group & hosts files after pacstrap

Hi,

I've followed the wiki for the installation routine, but after the pacstrap I inspected the group and hosts files and have found some issues with them. The group file has very odd gids, e.g. 993 or so for users. The hosts file is completely empty apart from the header comment.

That does not look like a proper installation to me. The users group should be 100 according to [1]. In hosts there should be the localhost lines.

First I thought it's a bug ([2]), but apparently it isn't.

So, what am I missing here? Or is this a problem or bug?

I really need to install this system and I don't want to move to another distribution, since I'm fairly familiar with Arch after 10 years.... hmm

Cheers!

[1] https://wiki.archlinux.org/index.php/De … D_Database
[2] https://bugs.archlinux.org/task/56691

Offline

#2 2017-12-13 13:28:01

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,867

Re: Problems with/etc/group & hosts files after pacstrap

The "users" group is now dynamically managed by sysusers.d .

Not sure if the localhost lines are still needed, but this is the file from the previous filesystem-2017.03-2

#
# /etc/hosts: static lookup table for host names
#

#<ip-address>	<hostname.domain.org>	<hostname>
127.0.0.1	localhost.localdomain	localhost
::1		localhost.localdomain	localhost

# End of file

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#3 2017-12-13 13:31:32

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Problems with/etc/group & hosts files after pacstrap

The hosts file is indeed now delivered without anything other than the comment header.

So it sounds like everything's fine in your installation.  The installation guide may need some revision to clear up ambiguity (at least at the /etc/hosts part) due to the filesystem package changes.

For future reference you may want to reconsider how you present bug reports.  Your presentation in this thread is just right: seeking information and understanding; but your bug report really wasn't presented productively.  But I do have to say, I enjoy seeing people get nocked right off their high horse, so thanks! tongue

Being familiar with arch is great - but that means you should be familiar with things changing.  If those changes actually result in something not functioning properly, then raise the issue.  But if everything works, but just works a bit differently, then that should be par for the course in a rolling release distro.

To echo Eschwartz's comment on closing your bug report, if these changes are causing problems for you, please elaborate on the problems and we can help with those.

Last edited by Trilby (2017-12-13 13:39:50)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2017-12-13 15:53:44

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

And FWIW the shadow package did have a configuration default for useradd which assumed the gid for "users" was 100, which clashed with the move to a dynamic sysusers.d(5) gid.
This turned out to be causing problems with new installs, but since no one really bootstraps a new system using the testing repos, no one realized until too late...

See https://bugs.archlinux.org/task/56316

This has been fixed with the latest [core]/shadow package.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2017-12-13 16:41:44

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Trilby wrote:

The hosts file is indeed now delivered without anything other than the comment header.

So it sounds like everything's fine in your installation.  The installation guide may need some revision to clear up ambiguity (at least at the /etc/hosts part) due to the filesystem package changes.

Thanks for the confirmation, that's good to know, cause it caused a lot of confusion on my side.

So, does this mean, I have to live with random and unpredictable gids now?

I found it pretty nice to be always sure about `users` == `100`.

Trilby wrote:

For future reference you may want to reconsider how you present bug reports.  Your presentation in this thread is just right: seeking information and understanding; but your bug report really wasn't presented productively.  But I do have to say, I enjoy seeing people get nocked right off their high horse, so thanks! :p

Being familiar with arch is great - but that means you should be familiar with things changing.  If those changes actually result in something not functioning properly, then raise the issue.  But if everything works, but just works a bit differently, then that should be par for the course in a rolling release distro.

To echo Eschwartz's comment on closing your bug report, if these changes are causing problems for you, please elaborate on the problems and we can help with those.

You're definitely right, and this is not my style. Eventually I even had qualms about writing it like this, cause I know it's unproductive. But you know, frustration kicked in, cause all I want to do is edit my photos with darktable and not spend a couple of precious evenings playing part-time sys admin. In the past 10 years I went from student to someone with a full blown life, like work, etc. and my focus and interests shifted. Time is now very limited and as said before, fiddling with bugs or unexpected behavior is not high on my list anymore. I know the in and outs of a Linux distribution (not only Arch), because it's part of my professional occupation. But most of the time I'm just like everyone else, I just want things to work, preferably Free and OSS. :)

So, I apologize sincerely for my not-so-well formulated bug report. I'll try to keep my emotions in check next time. Also towards Eschartz, hope you don't feel offended. I appreciate the work of everyone who keeps Arch running! It's still my favorite distribution. But like every relation, there are ups and downs.

I'm not sure about high horse though... I don't think I'm arrogant, or at least I don't want to be! :)

Offline

#6 2017-12-13 17:06:08

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

Very well, you're forgiven. smile Just try to take a step back next time and proceed more calmly.

I'm not really sure what the benefit of users=100 would be, to be honest -- is there something in particular that relies on a hardcoded gid for that? In what manner do you need to rely on it?
Keep in mind that user accounts also have unpredictable uids. tongue So there is a certain amount of work involved in mapping system-specific data already... it's always better to use user names in preference over user ids, if possible, e.g. for backup systems.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2017-12-13 17:11:34

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Problems with/etc/group & hosts files after pacstrap

jrk wrote:

So, does this mean, I have to live with random and unpredictable gids now?

Perhaps there's a way to specify which gid would be used - I'm not sure about that.  But it's not really unpredictable.  Once it's set for that system then it stays the same.

I suppose people have previously taken advantage of the coincidence that the first user created on a system and the "users" groups generally had the same id's across most linux machines.  So when a drive was moved from one linux machine to another, the ownership could be "inherited" due to this coincidence.  That always seemed to be more of a bug than a feature to me.

Is having read/write access to files created on a *nix filesystem from another system your concern?  There are trivial ways to deal with that if it is.  Or in what other way would having the "users" group not be a universally-known number cause a problem?

Last edited by Trilby (2017-12-13 17:12:01)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#8 2017-12-13 20:34:41

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,407
Website

Re: Problems with/etc/group & hosts files after pacstrap

The installation guide may need some revision to clear up ambiguity (at least at the /etc/hosts part) due to the filesystem package changes.

I'm confused by all these changes in the filesystem package. How does the update alleviate the need to modify /etc/hosts (which was mostly done to avoid issues with certain popular applications like firefox)?


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

#9 2017-12-13 21:37:34

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Problems with/etc/group & hosts files after pacstrap

I don't know that it does change anything the user needs to do (or should do) during installation.  But the /etc/hosts part of the guide (as of this morning) gave an example of what /etc/hosts should look like and mentioned appending to the existing lines.  These instructructions are no longer quite right, if anything is to be added, complete lines need to be constructed.

EDIT: oops, it doesn't say to append to existing lines, but it does give an example suggesting some lines should already be there.  I could imagine someone totally new to arch would be troubled and think "wait, my file doesn't look anything like that".

Last edited by Trilby (2017-12-13 21:39:05)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2017-12-13 21:52:24

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,407
Website

Re: Problems with/etc/group & hosts files after pacstrap

In that case, please add a discussion to the talk page of the Installation guide.


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

#11 2017-12-14 07:17:32

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Trilby wrote:

I don't know that it does change anything the user needs to do (or should do) during installation.  But the /etc/hosts part of the guide (as of this morning) gave an example of what /etc/hosts should look like and mentioned appending to the existing lines.  These instructructions are no longer quite right, if anything is to be added, complete lines need to be constructed.

EDIT: oops, it doesn't say to append to existing lines, but it does give an example suggesting some lines should already be there.  I could imagine someone totally new to arch would be troubled and think "wait, my file doesn't look anything like that".

Well, not only completely new users are confused wink

The problem is, that there is no Changelog. Or at least none that I can find. Is it somewhere in the git for the PKGBUILD?


Regarding user and group ids:

I used to set my (main) uids and gids to the same value on all of my machines, Laptop, Desktop, VPS, VMs, etc. out of habit. Most of the time it makes no difference though. Where it makes a difference is when you start to use NFS, which I did a long time ago. Now I don't use it anymore and it's probably just a habitually relic of mine. Maybe I can get by without it. OTOH I have a portable usb disk and I'd appreciate it if I could use it easily between my computers without funky gids.

I realize that the solution to this would be centralized user management like LDAP, and I used to have that in the past (remember, I was a student once... smile ). But now, all that work for a single user account on maybe a hand full of machines? It's easier to just set the same {u,g}id once on installation.

I'll add a discussion about the filesystem package in the installation guide and refer to this thread!

[EDIT]
I've also added a discussion item here:
https://wiki.archlinux.org/index.php/Ta … id_anymore
[EDIT]

Last edited by jrk (2017-12-14 07:26:03)

Offline

#12 2017-12-14 07:33:02

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

If you really want to, sysusers.d allows you to specify the uid or gid in use. See how our own /usr/lib/sysusers.d/arch.conf specifies them.

The difference is that users is created by basic.conf which is part of systemd, not arch.conf which is our own distro configurations. If you read the manpage for sysusers.d you will learn how to configure this automatically, e.g. by creating a configuration in /etc before installing with pacstrap -- it will automatically be picked up!
(Since systemd-sysusers is run by the systemd post_install script, it will be picked up without having to rely on the sysusers.d pacman hook that only runs the files which have been updated through pacman.)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#13 2017-12-14 08:24:24

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,867

Re: Problems with/etc/group & hosts files after pacstrap

ESchwartz wrote:

(Since systemd-sysusers is run by the systemd post_install script, it will be picked up without having to rely on the sysusers.d pacman hook that only runs the files which have been updated through pacman.)

It's also runs at every boot :

$ ls -l /usr/lib/systemd/system/sysinit.target.wants/
total 0
lrwxrwxrwx 1 root root 20 13 dec 09:00 cryptsetup.target -> ../cryptsetup.target
lrwxrwxrwx 1 root root 22 13 dec 09:00 dev-hugepages.mount -> ../dev-hugepages.mount
lrwxrwxrwx 1 root root 19 13 dec 09:00 dev-mqueue.mount -> ../dev-mqueue.mount
lrwxrwxrwx 1 root root 28 13 dec 09:00 kmod-static-nodes.service -> ../kmod-static-nodes.service
lrwxrwxrwx 1 root root 19 13 dec 09:00 ldconfig.service -> ../ldconfig.service
lrwxrwxrwx 1 root root 22  3 nov 08:20 lvm2-lvmetad.socket -> ../lvm2-lvmetad.socket
lrwxrwxrwx 1 root root 36 13 dec 09:00 proc-sys-fs-binfmt_misc.automount -> ../proc-sys-fs-binfmt_misc.automount
lrwxrwxrwx 1 root root 32 13 dec 09:00 sys-fs-fuse-connections.mount -> ../sys-fs-fuse-connections.mount
lrwxrwxrwx 1 root root 26 13 dec 09:00 sys-kernel-config.mount -> ../sys-kernel-config.mount
lrwxrwxrwx 1 root root 25 13 dec 09:00 sys-kernel-debug.mount -> ../sys-kernel-debug.mount
lrwxrwxrwx 1 root root 36 13 dec 09:00 systemd-ask-password-console.path -> ../systemd-ask-password-console.path
lrwxrwxrwx 1 root root 25 13 dec 09:00 systemd-binfmt.service -> ../systemd-binfmt.service
lrwxrwxrwx 1 root root 28 13 dec 09:00 systemd-firstboot.service -> ../systemd-firstboot.service
lrwxrwxrwx 1 root root 30 13 dec 09:00 systemd-hwdb-update.service -> ../systemd-hwdb-update.service
lrwxrwxrwx 1 root root 41 13 dec 09:00 systemd-journal-catalog-update.service -> ../systemd-journal-catalog-update.service
lrwxrwxrwx 1 root root 27 13 dec 09:00 systemd-journald.service -> ../systemd-journald.service
lrwxrwxrwx 1 root root 32 13 dec 09:00 systemd-journal-flush.service -> ../systemd-journal-flush.service
lrwxrwxrwx 1 root root 36 13 dec 09:00 systemd-machine-id-commit.service -> ../systemd-machine-id-commit.service
lrwxrwxrwx 1 root root 31 13 dec 09:00 systemd-modules-load.service -> ../systemd-modules-load.service
lrwxrwxrwx 1 root root 30 13 dec 09:00 systemd-random-seed.service -> ../systemd-random-seed.service
lrwxrwxrwx 1 root root 25 13 dec 09:00 systemd-sysctl.service -> ../systemd-sysctl.service
lrwxrwxrwx 1 root root 27 13 dec 09:00 systemd-sysusers.service -> ../systemd-sysusers.service
lrwxrwxrwx 1 root root 37 13 dec 09:00 systemd-tmpfiles-setup-dev.service -> ../systemd-tmpfiles-setup-dev.service
lrwxrwxrwx 1 root root 33 13 dec 09:00 systemd-tmpfiles-setup.service -> ../systemd-tmpfiles-setup.service
lrwxrwxrwx 1 root root 24 13 dec 09:00 systemd-udevd.service -> ../systemd-udevd.service
lrwxrwxrwx 1 root root 31 13 dec 09:00 systemd-udev-trigger.service -> ../systemd-udev-trigger.service
lrwxrwxrwx 1 root root 30 13 dec 09:00 systemd-update-done.service -> ../systemd-update-done.service
lrwxrwxrwx 1 root root 30 13 dec 09:00 systemd-update-utmp.service -> ../systemd-update-utmp.service
$ 

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#14 2017-12-14 11:55:31

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Eschwartz wrote:

If you really want to, sysusers.d allows you to specify the uid or gid in use. See how our own /usr/lib/sysusers.d/arch.conf specifies them.

The difference is that users is created by basic.conf which is part of systemd, not arch.conf which is our own distro configurations. If you read the manpage for sysusers.d you will learn how to configure this automatically, e.g. by creating a configuration in /etc before installing with pacstrap -- it will automatically be picked up!
(Since systemd-sysusers is run by the systemd post_install script, it will be picked up without having to rely on the sysusers.d pacman hook that only runs the files which have been updated through pacman.)

Soooooo... may I suggest to ship an `arch.conf` which implements DeveloperWiki:UID / GID Database?

#Type  Name   ID              GECOS                 Home directory
u root 	0 - /root
u bin 	1 - -
u daemon 	2 - -
u mail 	8 - -
# ... etc ...
g root 	0 - -
g bin 	1 - -
g daemon 	2 - -
g sys 	3 - -
g adm 	4 - -
# ... etc ...

Offline

#15 2017-12-14 12:24:40

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

Lone_Wolf wrote:
ESchwartz wrote:

(Since systemd-sysusers is run by the systemd post_install script, it will be picked up without having to rely on the sysusers.d pacman hook that only runs the files which have been updated through pacman.)

It's also runs at every boot :

This is true, and maybe I should have mentioned that I actually had a rather subtle point there.

It doesn't matter if sysusers are parsed on subsequent boots, because the pacman hook would parse basic.conf without parsing an unpackaged conf, and create those users/groups with a random uid/gid. Waiting for the unpackaged conf to be parsed at the next boot would be too late... however, since during an initial pacstrap transaction, you are also installing a package (systemd) which runs systemd-sysusers on *all* files the way the service would, but this time during a post_install script running before the hooks do, the whole thing still works as expected with a custom file (assuming the custom file is named in accordance with the sysusers.d filename priority ordering in mind).

jrk wrote:

Soooooo... may I suggest to ship an `arch.conf` which implements DeveloperWiki:UID / GID Database?

You can certainly suggest it, but I doubt you will get any traction given that we explicitly chose not to in the first place.

If it was something that had be "overlooked", then we might automatically accept such a suggestion because "thanks for reminding us". But since there were actual reasons involved in *not* doing so, you'd have to provide actual reasons why we *should* do so.

Any non-implemented part of the UID/GID Database was not-implemented, because it was regarded as unnecessary to hardcode them on a modern system. So you'd have to explain why they are necessary.

https://bugs.archlinux.org/task/56662

Last edited by eschwartz (2017-12-14 12:31:33)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#16 2017-12-14 13:32:28

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

ESchwartz wrote:
jrk wrote:

Soooooo... may I suggest to ship an `arch.conf` which implements DeveloperWiki:UID / GID Database?

You can certainly suggest it, but I doubt you will get any traction given that we explicitly chose not to in the first place.

If it was something that had be "overlooked", then we might automatically accept such a suggestion because "thanks for reminding us". But since there were actual reasons involved in *not* doing so, you'd have to provide actual reasons why we *should* do so.

Any non-implemented part of the UID/GID Database was not-implemented, because it was regarded as unnecessary to hardcode them on a modern system. So you'd have to explain why they are necessary.

https://bugs.archlinux.org/task/56662

Ok, understood. So I'm probably better of with just adding `users=100` to my personal config. In the end it doesn't matter that much to me, as long as I have a reliable option to configure the behavior. I also never really thought about hardcoded gids, because it's been like that forever. Which brings me to the question of what's the benefit of dynamic gids, despite of bloated static gids. I'm not a systemd opponent, never been, but replacing static ids with dynamic allocation sounds also bloaty to me, at least when I think in software terms. smile

ESchwartz wrote:

Hardcoding things without due cause is bloated and silly.

Most often, the cause are performance reasons. No runtime lookups, no dynamic allocation, etc. In this context however, the reasoning might be different.

Offline

#17 2017-12-14 15:14:18

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

jrk wrote:

Ok, understood. So I'm probably better of with just adding `users=100` to my personal config. In the end it doesn't matter that much to me, as long as I have a reliable option to configure the behavior. I also never really thought about hardcoded gids, because it's been like that forever. Which brings me to the question of what's the benefit of dynamic gids, despite of bloated static gids. I'm not a systemd opponent, never been, but replacing static ids with dynamic allocation sounds also bloaty to me, at least when I think in software terms. smile

The benefit would be simplification of the UID/GID database, and less of a need to coordinate those UIDs/GIDs for, say, AUR packages where there is no such database. Maintaining that database is not a zero-cost option. smile Neither is ensuring that packaged files are properly chown'ed to the right static UID, but sometimes you need to...

And it really isn't a systemd thing at all. Consider, that `useradd` will by default also assign a random UID, and both useradd and systemd offer an option to specify a UID. Also consider that we *cannot* use sysusers.d for the git package, as systemd simplified things by not allowing you to specify anything other than the default /sbin/nologin when creating a system user. (And the git package uses useradd in the post_install script since it needs to create a "git" user with the /usr/bin/git-shell wrapper as its login shell.)

jrk wrote:
ESchwartz wrote:

Hardcoding things without due cause is bloated and silly.

Most often, the cause are performance reasons. No runtime lookups, no dynamic allocation, etc. In this context however, the reasoning might be different.

Well, that can qualify as due cause. tongue


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#18 2017-12-15 06:42:35

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Eschwartz wrote:
jrk wrote:

Ok, understood. So I'm probably better of with just adding `users=100` to my personal config. In the end it doesn't matter that much to me, as long as I have a reliable option to configure the behavior. I also never really thought about hardcoded gids, because it's been like that forever. Which brings me to the question of what's the benefit of dynamic gids, despite of bloated static gids. I'm not a systemd opponent, never been, but replacing static ids with dynamic allocation sounds also bloaty to me, at least when I think in software terms. smile

The benefit would be simplification of the UID/GID database, and less of a need to coordinate those UIDs/GIDs for, say, AUR packages where there is no such database. Maintaining that database is not a zero-cost option. smile Neither is ensuring that packaged files are properly chown'ed to the right static UID, but sometimes you need to...

I see. It's obviously way less work to care about all the packages and a static database. You're reducing maintenance work and get more reliability. I get it. smile

But know I'm thinking, why are there such static lookup tables after all? Most likely because you need numbers for the filesystem and the kernel (easier to process). In the end you should have a dynamic mapping service, just like DNS, which reduces the importance of the actual number, but rather rely on the name. A service or program which relies on the numbers is then tightly coupled to the implementation and therefore badly designed.

Eschwartz wrote:

And it really isn't a systemd thing at all. Consider, that `useradd` will by default also assign a random UID, and both useradd and systemd offer an option to specify a UID. Also consider that we *cannot* use sysusers.d for the git package, as systemd simplified things by not allowing you to specify anything other than the default /sbin/nologin when creating a system user. (And the git package uses useradd in the post_install script since it needs to create a "git" user with the /usr/bin/git-shell wrapper as its login shell.)

With "simplified" you mean "put unnecessary and arbitrary restrictions on my choices, making everything unflexible"? wink

Eschwartz wrote:
jrk wrote:
ESchwartz wrote:

Hardcoding things without due cause is bloated and silly.

Most often, the cause are performance reasons. No runtime lookups, no dynamic allocation, etc. In this context however, the reasoning might be different.

Well, that can qualify as due cause. tongue

But, as written above, the benefits of the dynamic solution probably outweigh the drawbacks of the static solution. The performance impact of generating `shadow` and `group` on the fly is probably negliable on modern desktop / server machines. It might make a difference for embedded system, but you wouldn't install a regular Linux distribution on those anyway. wink

Offline

#19 2017-12-15 13:40:22

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

jrk wrote:
Eschwartz wrote:
jrk wrote:

Ok, understood. So I'm probably better of with just adding `users=100` to my personal config. In the end it doesn't matter that much to me, as long as I have a reliable option to configure the behavior. I also never really thought about hardcoded gids, because it's been like that forever. Which brings me to the question of what's the benefit of dynamic gids, despite of bloated static gids. I'm not a systemd opponent, never been, but replacing static ids with dynamic allocation sounds also bloaty to me, at least when I think in software terms. smile

The benefit would be simplification of the UID/GID database, and less of a need to coordinate those UIDs/GIDs for, say, AUR packages where there is no such database. Maintaining that database is not a zero-cost option. smile Neither is ensuring that packaged files are properly chown'ed to the right static UID, but sometimes you need to...

I see. It's obviously way less work to care about all the packages and a static database. You're reducing maintenance work and get more reliability. I get it. smile

But know I'm thinking, why are there such static lookup tables after all? Most likely because you need numbers for the filesystem and the kernel (easier to process). In the end you should have a dynamic mapping service, just like DNS, which reduces the importance of the actual number, but rather rely on the name. A service or program which relies on the numbers is then tightly coupled to the implementation and therefore badly designed.

Well... lots of programs *do* look up the user name rather than the user id. But perhaps you should talk to the people who develop filesystems. wink

jrk wrote:

I'm not a systemd opponent, never been, but replacing static ids with dynamic allocation sounds also bloaty to me, [...]

Eschwartz wrote:

And it really isn't a systemd thing at all. Consider, that `useradd` will by default also assign a random UID, and both useradd and systemd offer an option to specify a UID. Also consider that we *cannot* use sysusers.d for the git package, as systemd simplified things by not allowing you to specify anything other than the default /sbin/nologin when creating a system user. (And the git package uses useradd in the post_install script since it needs to create a "git" user with the /usr/bin/git-shell wrapper as its login shell.)

With "simplified" you mean "put unnecessary and arbitrary restrictions on my choices, making everything unflexible"? wink

Either simplicity is a good thing that systemd lacks, or it's a bad thing that systemd has?

Eschwartz wrote:
jrk wrote:

Most often, the cause are performance reasons. No runtime lookups, no dynamic allocation, etc. In this context however, the reasoning might be different.

Well, that can qualify as due cause. tongue

But, as written above, the benefits of the dynamic solution probably outweigh the drawbacks of the static solution. The performance impact of generating `shadow` and `group` on the fly is probably negliable on modern desktop / server machines. It might make a difference for embedded system, but you wouldn't install a regular Linux distribution on those anyway. wink

Well, my Kindle Touch runs an Amazon-derived version of Ubuntu... systemd was supposedly designed *for* the sake of embedded systems, in the sense that a single process that can handle the entire init probably takes a lot less load than forking off a billion processes in some involved shellscript.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#20 2017-12-15 14:47:02

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,411

Re: Problems with/etc/group & hosts files after pacstrap

Since this has shifted from an Installation issue to a fundamentality discussion, I'll move this to Arch Discussion.

Online

#21 2017-12-22 06:39:38

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Eschwartz wrote:

Well... lots of programs *do* look up the user name rather than the user id. But perhaps you should talk to the people who develop filesystems. wink

Ah no, I think it's fine that way. To me it sounded more as if someone needs to talk to the people who hardcode static uids. smile

Eschwartz wrote:
jrk wrote:

With "simplified" you mean "put unnecessary and arbitrary restrictions on my choices, making everything unflexible"? wink

Either simplicity is a good thing that systemd lacks, or it's a bad thing that systemd has?

Depends on whom you ask and what your use case is.

Eschwartz wrote:

Well, my Kindle Touch runs an Amazon-derived version of Ubuntu... systemd was supposedly designed *for* the sake of embedded systems, in the sense that a single process that can handle the entire init probably takes a lot less load than forking off a billion processes in some involved shellscript.

Now we can debate about whether a an Amazon-derived version of Ubuntu qualifies as embedded system.

The systems my colleagues develop for industrial applications don't run systemd and probably won't do so for a long time.

Who said that systemd was designed for embedded systems? Or is written down somewhere (formal design documents)? I'm genuinely curious, also because it might be food for thought for my colleagues smile

Speaking of Ubuntu. Out of frustration and curiousity I gave 17.10 a try on my new computer. And what should I say. I like the streamlined experience, I like Gnome 3 (and I'm coming from a heavily modified XMonad, then Openbox, most recently Mate, and hacked on my own WMs in the past...). All I have to figure out now is how to install it on Btrfs, so I can get snapshots with snapper. After almost 10 years I'm leaving Arch with sadness in my heart, but I guess I need a tool, but not a hacker's tool anymore. I'm losing control over my system, but in the I just care about whether it works or not, just like Android. A very Apple-like attitude, but I still care a lot about FOSS and dislike proprietary solutions. In the end I think I've just grown into a less technical personality and I'm fine with it (that was a process on it's own, not always easy, but what's easy anyway... smile )

Nevertheless, Arch will always have a warm spot in my heart and I'll keep fond memories of it. I'd recommend it warmly to anyone who wants to learn more about the technical details of a Linux distribution. Arch served me very well and the community is friendly and welcoming!

Offline

#22 2017-12-23 23:48:47

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Problems with/etc/group & hosts files after pacstrap

http://0pointer.de/blog/projects/why.html <-- Lennart

http://bec-systems.com/site/1098/why-sy … ux-systems <-- random google result

https://events.static.linuxfound.org/si … ystems.pdf <-- random people who received Lennart's love for offering professional systemd embedded consulting, and here they discuss slimming it down for embedded purposes.

I don't claim systemd is good for embedded systems, and I may have been going too far by implying that embedded systems are its reason for being.
Truth be told, I am not claiming much of anything, because I am no expert in the matter.

All I know is that Lennart thinks systemd is a good idea for embedded systems to use. wink That much (that he says it) is a fact, which I can tell you. I'll leave the merit-based judgments to people who know what they are talking about. big_smile


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#23 2017-12-24 00:30:27

Xyem
Member
Registered: 2010-08-14
Posts: 20

Re: Problems with/etc/group & hosts files after pacstrap

Trilby wrote:

If those changes actually result in something not functioning properly, then raise the issue.  But if everything works, but just works a bit differently, then that should be par for the course in a rolling release distro.

I did a fresh installation to check this new behaviour and it causes 'localhost' to be queried via DNS. This is a breaking change and a security risk as the DNS server can respond affirmatively with another address and the machine will connect to that rather than itself.

Interestingly, building perl (e.g. perlbrew) fails due to this as there is an explicit check for the returned IP address being 127.0.0.1.

This really needs to be reversed..

Offline

#24 2017-12-24 12:57:23

jrk
Member
From: Nämberch
Registered: 2012-10-16
Posts: 37

Re: Problems with/etc/group & hosts files after pacstrap

Eschwartz wrote:

http://0pointer.de/blog/projects/why.html <-- Lennart

http://bec-systems.com/site/1098/why-sy … ux-systems <-- random google result

https://events.static.linuxfound.org/si … ystems.pdf <-- random people who received Lennart's love for offering professional systemd embedded consulting, and here they discuss slimming it down for embedded purposes.

I don't claim systemd is good for embedded systems, and I may have been going too far by implying that embedded systems are its reason for being.
Truth be told, I am not claiming much of anything, because I am no expert in the matter.

All I know is that Lennart thinks systemd is a good idea for embedded systems to use. wink That much (that he says it) is a fact, which I can tell you. I'll leave the merit-based judgments to people who know what they are talking about. big_smile

Lennart seems to have strong opinions, especially when it benefits his own projects. Not judging, just my impression. I even like systemd and pulseaudio. wink

Anyhow, thanks for the links! I'll talk to my colleagues after the holidays about this. There's also a yocto layer, so integration should be fairly easy. But I need to compile some answers to the obvious "why should we use systemd instead of our working solution" question first. smile

Anyhow, I'm looking forward to the discussion with my colleagues because it's an interesting mix of more traditionalist and conservative graybeards who have experience on their side and some younger folks with less experience but who are open to adopt new and uncommon solutions.

Offline

#25 2018-03-11 00:54:26

rtfreedman
Member
Registered: 2011-08-27
Posts: 80

Re: Problems with/etc/group & hosts files after pacstrap

Trilby wrote:

Is having read/write access to files created on a *nix filesystem from another system your concern?  There are trivial ways to deal with that if it is.

I just run into this - sharing data partitions with up to four distributions.
What is your advise - best practice to overcome this annoyance?

Offline

Board footer

Powered by FluxBB