user numbers in etc/passwd
 

Greetings.

I am thinking of trying the current version of bedrock. I have one question from when I tried the previous version. I had noticed that the numbers assigned to users in the bedrock /etc/passwd file did not all match those of /etc/passwd the first client (well, now called strata).

Do these numbers need to match?

I can obviously go and change them in /etc/passwd, but I would *think* that files in the file systems have the "raw" number rather than a string with the user name?

Come to think of it, this question applies to groups as well.

p.s. I have installed bedrock succesfully, once, in a VM. Some stuff was a bit funny, but it was able to get into xorg and go online. An attempt to set it up on a physical machine did not go as well, but hey, this is new technology. :)

The user name is for your convenience, system identifies users by "those numbers", which are called UID and GID.

Howdy :)

With the default/recommended configs, processes should all see the same file at /etc/passwd, irrelevant of which stratum provides them, as it is a global file. If that's not the case, either the system is misconfigured, or there's a bug.

If you're looking at the files through explicit access (that is, through /bedrock/strata/*stratum*/etc/passwd rather than directly at /etc/passwd), then they can differ. Or they can be the same. There's no rule about what global files look like when accessed through there; it's undefined. That access is only defined for local files.

Assuming direct access (that is, through /etc/passwd and not /bedrock/strata/*stratum*/etc/passwd), you most likely want them to match. There may be some fancy exceptions where you want them to differ, but I can't think of any at the moment.

The filesystem does use the underlying user id. However, this doesn't alleviate potential problems from /etc/passwd mismatches. Processes from different strata would look up the username-uid mappings and try to do things with the filesystem based on what they think the user id should be and then get very confused.

It does - same idea, just /etc/group instead of /etc/passwd. That should also be in sync.

If the funny things you ran into don't show up in the known issues page or in the github issues page, and you think it's an issue with Bedrock Linux rather than a mistake on your part or an issue with software from another distro, please do report it so I can look into it.

If you think it was a mistake on your part, feel free to request assistance, that's what this forum is for :)

Sigh, poor phrasing on my part. The "hey this is new technology" to me implied, high tech, as in, things beyond my knowledge. In other words, this *is* rocket science. ;) So I *expect* to make mistakes and to fail to understand some things. I did not intend to imply anything negative about bedrock. My attitude towards bedrock is one of enthusiasm and wonder.

Oh no worries, I didn't interpret it as any sort of slight! Always happy to hear about such enthusiasm :)

edit:
Oops! I'm comparing a list of users to a list of groups! Let me get back to you on that once I properly check users vs. users and groups vs groups.
end edit

Getting specific numbers now, I'm thinking of beginning a bedrock install (yes, I'm taking my time at this :p ) with a hijack of the November 2015 version of Slackware "current". The numbers Slackware has for the users are:
Note: that was extacted from the passwd file.

According to the quick install instructions for Nyla, the numbers should be
A quick look reveals some apparent conflicts. For example: bedrock's tty uses 5 but slackware uses that for sync. How flexible are these numbers? Would it be workable to simply go with the slackware numbers? Or, instead, are these numbers hard-coded deep within bedrock?

All right. Got my act together. Here are the groups specified by number in the Nyla quick-start documentation that have numbered different from groups in the to-be-hijacked linux:
In addition, there is a group in bedrock that is not in the linux that has the same number as an existing group in the linux. This group is staff, with a number of 50. In the linux, 50 is used by the ftp group.

Will this be a problem after the hijack?

I see no mention of users with specified numbers, so it looks like that might not be a concern after all. :)

I think that if you hijack a distro, you'd better just use that distro's passwd and group files as a starting base (with the correction for root's and users' shells, of course), then add whatever needed for other strata by checking each new strata's defaults and adding whatever is missing.

You should take care of any conflict with other strata IDs by scanning every other strata's filesystem and looking for files that DON'T belong to root:root[*], and chown'ing them to whatever UID:GID numbers you choose for that user:group to solve the conflict.

For example: Void's package manager has the executable /usr/bin/xbps-uchroot owned by root:xbuilder, which by Void's defaults corresponds to 0:101.

You need to create or copy the xbuilder group to your global /etc/group file; if the 101 GID is already taken you can use another number, but then you need to chgrp the /usr/bin/xbps-uchroot file to the GID number you're using, and probably do that every time you update the Void package manager.

[*]

The various uid/gid numbers are not "hard-coded deep within bedrock". That bit of the instructions is simply ensuring you have some values there. Whatever Slackware starts with is fine - just make sure if it's missing something that's listed in the quick start instructions, you get the missing thing. I should probably reword that section of the instructions to be more clear.

EmaRsk is also correct in that when you add a new stratum, it may be advisable to merge the uids and gids and ensure the on-disk values are correct. We had someone working on a utility to automate such merging, but they've moved on elsewhere before finishing it. We'll have to get back to it.

Thank you, everyone, for the information. :)

@EmaRsk: Neat! My experience with find has been minimal. This could be the basis of a script. :)

Just a correction, in case someone is copy-pasting the 'find' line above: 'ls' should have the '-d' option, or else it would list the content of the found directories, instead of the directories themselves.