Bedrock LinuxThis forum is for the discussion of Bedrock Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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).
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.
Quote:
Originally Posted by jr_bob_dobbs
Do these numbers need to match?
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.
Quote:
Originally Posted by jr_bob_dobbs
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?
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.
Quote:
Originally Posted by jr_bob_dobbs
Come to think of it, this question applies to groups as well.
It does - same idea, just /etc/group instead of /etc/passwd. That should also be in sync.
Quote:
Originally Posted by jr_bob_dobbs
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.
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.
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 ) with a hijack of the November 2015 version of Slackware "current". The numbers Slackware has for the users are:
Code:
root 0
bin 1
daemon 2
adm 3
lp 4
sync 5
shutdown 6
halt 7
mail 8
news 9
uucp 10
operator 11
games 12
ftp 14
smmsp 25
mysql 27
rpc 32
sshd 33
gdm 42
oprofile 51
usbmux 52
sddm 64
apache 80
messagebus 81
haldaemon 82
pop 90
nobody 99
bob 1000
Note: that was extacted from the passwd file.
According to the quick install instructions for Nyla, the numbers should be
Code:
0 root
5 tty
6 disk
7 lp
15 kmem
20 dialout
24 cdrom
25 floppy
26 tape
29 audio
44 video
50 staff
65534 nogroup or 60000 nogroup
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?
Last edited by jr_bob_dobbs; 06-26-2016 at 05:25 PM.
Reason: woops
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.