Allow empty default_cmd in brn.conf #11

yshui · 2016-03-24T22:40:54Z

If default_cmd is unset, then the init configured in strata.conf should be
used.

If default_cmd is unset, then the init configured in strata.conf will be used.

paradigm · 2016-03-25T00:36:31Z

This will fail if a user has multiple init options set, which is what brn.conf's default_cmd was intended to cover.

Some distros provide multiple init options with different paths such that they can all be installed at the same time. For example, on Debian, you can install runit which installs /sbin/runit-init so you can have that and systemd's /lib/systemd/systemd installed at the same time.

On my system, I have:

$ awk '$0 == "[jessie]", $0 == ""' /bedrock/etc/strata.conf
[jessie]
framework = default
init = /sbin/runit-init
init = /lib/systemd/systemd

$ bri -c jessie init
/sbin/runit-init
/lib/systemd/systemd

That's why default_cmd is needed. Your patch does not appear to work in this situation.

If default_cmd is unset but default_stratum is set, we could test for the possibility that default_stratum just has one init item and then use that. It wouldn't be a big change from your current patch. However, I'm not overly fond of that kind of implicit/auto-config. I dislike the idea of a user adding another init item to their strata.conf then changing their default init as a side-effect. That's confusing/surprising in a bad way. The advantage there doesn't seem worth the potential cost. However, I could be missing something - I'm definitely open to suggestion here.

yshui · 2016-03-25T23:57:17Z

How about only pick up the init in strata.conf as default_cmd only if there's one init configured? When there's multiple init configured then the selection menu can ask user which to use.

What I don't like is having to configure the same thing in two different places. User might forget to chang 'default_cmd' after changing the 'init' in strata.conf.

paradigm · 2016-03-27T10:33:22Z

How about only pick up the init in strata.conf as default_cmd only if there's one init configured? When there's multiple init configured then the selection menu can ask user which to use.

That's what I had proposed in the last paragraph of my previous entry here. My concerns there:

If the user doesn't know about it or forgets about it, it could lead to an unpleasant surprise should the user add another init to the default_stratum without intending to change the default.
It's implicit. This makes it harder to debug. A user cannot find the config file by greping for the default init command /bedrock/etc if it isn't actually listed in the relevant config file. With the future installation changes it'll be very easy for the user to avoid having to touch the config at install time.

In contrast to the issues with the current system:

If the user wishes to change the default init, and installs another init in the default stratum, and configures this other init in strata.conf, but forgets to or doesn't consider the need to change the config file which specifies the default.
If the user wishes to change the default init, the user does not have the option to do so by adding a new init to strata.conf and removing the previous init from strata.conf.

From my point of view, the problems with the proposed system are both more significant than those with the current one, as well as more likely to happen. I've never heard of anyone forgetting to change the config specifying the default init when they want to change the default init. Has that happened to you, or someone else you know? It could be I'm just in an echo chamber of more experienced users here and missing something. I've also never heard of anyone removing an undesired init from a desired stratum - usually either the stratum goes, or both inits are retained.

Are there any other routes we could take here that alleviate all above-mentioned concerns? It could be there's something neither of us have yet considered that would work well for both of us.

If we configured via a GUI, we could provide some indication of the side-effects when configuring, such as an animation which shows the default init changing. However, we're all flat files here so that's not a clean option.
We could have the default stratum/init pairing derive from some other config. For example, the first stratum with an init and it's first init in strata.conf could be the default init. I suspect this is along the lines of what you're hoping, as you only have to touch one file here. However, this doesn't work with the /bedrock/etc/strata.d/* files. It's also super implicit in a way that could cause unintended side-effects when users reorder items without recalling that order matters. We'll also still need a timeout value somewhere, and it wouldn't fit in strata.conf
Instead of having a blank value indicate the system should use the first init, we could have some explicit setting for that. I'm not sure it's actually any better, but maybe worthwhile food for thought. Maybe brn.conf could look like:

  ### Settings for the pre-iNit script, brn
  #
  # This indicates the amount of time, in seconds, the user is provided to make a
  # selection before the default is automatically chosen.  Set to 0 to indicate
  # no time should be provided - always boot directly into the configured
  # default.  Set to -1 to indicate no time limit - nothing will be chosen
  # automatically, the user has as much time as desired.
  #
  timeout = 60
  
  # This indicates the default stratum to use.  This is chosen if the timeout
  # expires or the user enters a blank selection.
  #
  default_stratum = void
  
  # This indicates the default command to use.  This is chosen if the timeout
  # expires or the user enters a blank selection.  A value of "use_first"
  # indicates the first corresponding init listed in
  # `strata.conf`/`strata.d` should be utilized.  This will be the value
  # provided by `bri -c <stratum> init | head -n1`
  #
  default_cmd = use_first

I'll bring this up at today's dev meeting in the IRC room, see what other people say. You're certainly welcome to attend, although I fear the time may be problematic for you. It's in our IRC room, #bedrock on freenode, at noon EST on the last Sunday of every month.

What I don't like is having to configure the same thing in two different places

I agree. This is a problem for other config values, like $PATH. Right now we configure it in /bedrock/etc/rc.conf and /etc/sudoers. I think I may need to add it to /etc/X11/Xsession.d/41bedrock_env as well. That's a problem - bad DRY, user may update one without touching others. I'd definitely like to resolve that eventually.

However, the default init items are two different values. In one instance we list available init options, and in another we pick a default. I don't see the latter as redundant.

yshui · 2016-03-28T01:15:51Z

If the user doesn't know about it or forgets about it, it could lead to an unpleasant surprise should the user add another init to the default_stratum without intending to change the default.

I didn't see why the solution I proposed will have this problem: When user add another init, the worst thing that can happen is that brn will go from booting directly to asking user to choose an init.

It's implicit. This makes it harder to debug. A user cannot find the config file by greping for the default init command /bedrock/etc if it isn't actually listed in the relevant config file.

But the user will see the init configured in strata.conf

Well the best the solution I can think of is like this:

In strata.conf:

[stratum0]
framework = default
init.systemd = /lib/systemd/systemd
init.runit = /sbin/init

Then in brn.conf

default_stratum = stratum0
default_cmd = systemd

Avoid quadratic time complexity by incrementally copy path components

Ground work for vfork()+chroot() brp_realpath() Also removes access() check in read_filter, because brp_realpath() should have already made sure the file exists by using lstat()

Also, brp_realpath is replaced by brp_openplus brp_realpath returns a path, which in most case is not what the caller wanted. Causing them to repeat brp_realpath's work (e.g. lstat()). The new function returns a file descriptor and stat instead.

Prepare for chroot()

Now instead of resolving symlink relative to stratum root manually, we first chroot() into the stratum root, then let the kernel do the path resolution.

Reduce the number of seteuid() calls, which is quite heavy

paradigm · 2016-07-04T18:11:49Z

If the user doesn't know about it or forgets about it, it could lead to an unpleasant surprise should the user add another init to the default_stratum without intending to change the default.

I didn't see why the solution I proposed will have this problem: When user add another init, the worst thing that can happen is that brn will go from booting directly to asking user to choose an init.

That "worst thing that can happen" is the unpleasant surprise that I'm talking about. All of a sudden the machine stops booting.

Consider the (very common) workflow where people do not typically have physical access to a machine, but instead remote into it via ssh. If the machine doesn't boot through to ssh reliably, it's a pain to fix. Adding a new stratum with its own init or another init to an existing stratum shouldn't trigger that scenario.

It's implicit. This makes it harder to debug. A user cannot find the config file by greping for the default init command /bedrock/etc if it isn't actually listed in the relevant config file.

But the user will see the init configured in strata.conf

Yes, there will be a line which mentions it there. However, the fact that that line is also interpreted to mean it should be the default is implicit / non-obvious.

Well the best the solution I can think of is like this:

In strata.conf:

[stratum0]
framework = default
init.systemd = /lib/systemd/systemd
init.runit = /sbin/init

Then in brn.conf

default_stratum = stratum0
default_cmd = systemd

I don't see how this helps your goal here - you still have to touch two files
when updating. It also adds an additional layer of redirection/complexity.

paradigm · 2016-07-04T21:04:19Z

I've got an idea that I believe will resolve your original issue with what may be acceptable downsides.

Consider: The init = field in the strata.conf/strata.d is only used by brn, as far as I recall. Since brn has its own config - brn.conf - there's no reason to have init = in strata.conf/strata.d. We could move all of the brn-related configuration to brn.conf.

We could have a brn.conf which contains four broad pieces of information:

Default stratum/init.
Timeout before selecting default stratum/init pairing.
Something to indicate if brn should try and automatically find init options. I expect this will be relatively easy to implement and help minimize unnecessary editing of config files, which seems to be your goal here.
A list of stratum/init pairs to provide as selectable options

Something like this:

[general]
# timeout in seconds before automatically selecting default init.  0 indicates
# no timeout; go straight to default.  -1 indicates to wait indefinitely.
timeout = 60
# Default init to use at boot should timeout expire. Use <stratum>:</path>
# pairing.
#
# Example:
#     default = arch:/lib/systemd/systemd
# or
#     default = slack:/sbin/init
#
default = fallback:/sbin/init
# Attempt to automatically find init options by looking in common
# locations in the boot-time-enabled strata.  Looks for:
# - /sbin/init
# - /sbin/runit-init
# - /lib/systemd/systemd
auto_detect_inits = true
[options]
# list init options here, one per line.  Use <stratum>:<path> formatting.  Example:
#     fallback:/sbin/init
#     arch:/lib/systemd/systemd
#     jessie:/lib/systemd/systemd
#     jessie:/sbin/runit-init
#     slack:/sbin/init
fallback:/sbin/init
arch:/lib/systemd/systemd
jessie:/lib/systemd/systemd
jessie:/sbin/runit-init
slack:/sbin/init

We could also have a brn.d directory whose files are effectively cat'd to
the end of this when it is read (like strata.conf/strata.d. This would be
useful for brg to use to add options when new strata are added.

yshui · 2016-07-08T20:41:10Z

OK.

paradigm · 2018-06-06T02:37:48Z

With the upcoming release, the configuration system has been completely reworked with the aim of resolving a number of independent issues the previous system had. I did remember there was a push to remove redundant configuration (although I forgot where it came from and failed to comment about it here) and I did incorporate it into the design.

It's somewhat close to what I had described above: the meta-init system automatically detects likely inits so the user does not have to explicitly configure them per stratum. We'll likely be able to collect a list of common init system file locations and effectively remove the need for users to do any manual configuration there. The only thing the user will need to configure is their preference for the default and the timeout.

Here is the relevant bit of a proposed config for the upcoming release.

Provided you're in agreement that resolves the concerns, we can close this. Otherwise, let me know and we can adjust. The code to consume this configuration is still very much in flux and now is a good time to make such changes.

Mouvedia · 2018-06-06T03:22:52Z

We'll likely be able to collect a list of common init system file locations and effectively remove the need for users to do any manual configuration there.

Here's a non-exhaustive list of standalone ones:

SysV init
busybox init
myinit
ninit
sinit
sninit
ueld
uinit
simpleinit-msb (discontinued)

For the ones with integrated management check this list; out of these OpenRC and systemd are common.

paradigm · 2018-06-06T11:43:25Z

@Mouvedia Apologies for not being clear; I assumed prior experience with what Nyla does in this domain. What I need is the file path to the init's initially launched executable. With most inits as packaged by most distros, this is /sbin/init. However, we can't assume /sbin/init for quite everything. Some distros which package multiple inits (e.g. Debian, Gentoo) will place each init's files in different locations to keep them from conflicting so you can have multiple installed at once. For example, Debian places runit's initial executable at /sbin/runit-init while Debian places openrc's initial executable at /sbin/openrc-init.

From Bedrock's point of view, it doesn't really matter which init system has its initial executable at a given path, it just needs to know which paths to look at which might provide an init option it should offer to the user. Bedrock doesn't care if /sbin/init launches sysv init or busybox init or is symlinked to systemd, it just needs to know that /sbin/init is a possibility to consider in this domain.

Here's a list of what I know of so far:

/sbin/init (catch-all for most inits including sysv and busybox)
/sbin/openrc-init (openrc alternative option to leveraging sysv's /sbin/init)
/sbin/runit-init (runit)
/sbin/fallback-init (bedrock specific; may be removed before poki is released)
/lib/systemd/systemd (systemd)
/usr/lib/systemd/systemd (another common systemd path)

You're welcome to dig into rarer inits and figure out what Bedrock should expect for them if you'd like. However, it's not a big priority. I expect the above list will hit the vast, vast majority of user use cases, and the exceptions will likely be able to configure Bedrock accordingly (and will hopefully report it so we can support that going forward). We don't need an all encompassing solution here for Poki, just one good enough for the immediate future.

Mouvedia · 2018-06-06T14:52:31Z

sbin/init:
- ueld
- uinit
- sinit
- sninit
ninit: by default it's /sbin/ninit
myinit: the README recommends /sbin/myinit
simpleinit: /sbin/simpleinit

paradigm · 2018-06-06T15:13:06Z

Added them - thanks!

Allow empty default_cmd in brn.conf

40f17e3

If default_cmd is unset, then the init configured in strata.conf will be used.

yshui added 6 commits May 24, 2016 17:21

Speed improvements for brp_realpath

b333eaf

Avoid quadratic time complexity by incrementally copy path components

Make corresponding() returns a file descriptor instead

e7bbf0d

Ground work for vfork()+chroot() brp_realpath() Also removes access() check in read_filter, because brp_realpath() should have already made sure the file exists by using lstat()

Rewrite the config parser

ae0559c

Also, brp_realpath is replaced by brp_openplus brp_realpath returns a path, which in most case is not what the caller wanted. Causing them to repeat brp_realpath's work (e.g. lstat()). The new function returns a file descriptor and stat instead.

Make iteration through stratum the outmost loop

547eed2

Prepare for chroot()

Switch from hand written readlink() implementation to chroot()

bb8bea1

Now instead of resolving symlink relative to stratum root manually, we first chroot() into the stratum root, then let the kernel do the path resolution.

Verify file is at least accessible by root before SET_CALLER_UID

4372f72

Reduce the number of seteuid() calls, which is quite heavy

Allow empty default_cmd in brn.conf #11

Are you sure you want to change the base?

Allow empty default_cmd in brn.conf #11

Uh oh!

Conversation

yshui commented Mar 24, 2016

Uh oh!

paradigm commented Mar 25, 2016

Uh oh!

yshui commented Mar 25, 2016

Uh oh!

paradigm commented Mar 27, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yshui commented Mar 28, 2016

Uh oh!

paradigm commented Jul 4, 2016

Uh oh!

paradigm commented Jul 4, 2016

Uh oh!

yshui commented Jul 8, 2016

Uh oh!

paradigm commented Jun 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mouvedia commented Jun 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paradigm commented Jun 6, 2018

Uh oh!

Mouvedia commented Jun 6, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paradigm commented Jun 6, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

paradigm commented Mar 27, 2016 •

edited

Loading

paradigm commented Jun 6, 2018 •

edited

Loading

Mouvedia commented Jun 6, 2018 •

edited

Loading

Mouvedia commented Jun 6, 2018 •

edited

Loading