Differential D38826
Fix multiple rc.d/jail and jail.conf.d issues Authored by antranigv_freebsd.am on Feb 28 2023, 6:07 PM. Tags Referenced Files
Details This patch adds/fixes the following:
Sponsored by: illuria, Inc. we need to test the following scenarios.
Diff Detail
Event TimelineComment Actions To add a bit of context from a conversation on IRC, this review is intended to make it much easier to define jail(8) variables globally at the top of jail.conf(5), you only need to instanciate the name of a jail and optionally some per-jail values. The method of defining jails has been known and used for quite a while, but in order to make it work with jail.conf.d, this change is required. Comment Actions I like the overall idea, thank you for adding more conf.ds to FreeBSD! Something I do not understand: My "dormant", cron-initiated jails will always start upon boot (i.e., /etc/jail.anotherjail.conf, while anotherjail not in jail_list)? Regarding the code itself, wouldn't it be better to create a function, something like: all_jail_confs()
{
local jail_conf_locations
jail_conf_locations="$jail_conf $jail_conf_dir/*.conf /etc/jail.*.conf"
if [ -f "$1" ]; then
jail_conf_locations="$1 $jail_conf_locations"
fi
cat $jail_conf_locations 2>/dev/null
}And use it instead of repeating the same code in 5 places? Comment Actions Also, that would enable you to add extra command. Currently when all configuration files are concatenated, jail(8) will report errors on lines of that combined configuration. With something like service jail dump_config we could at least examine which line is the actual problem. Comment Actions
That will require an UPDATING notice. AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior. Comment Actions This change conflicts with https://reviews.freebsd.org/D39011 Comment Actions What is the motivation for changing the default behavior in the first place? I have a bunch of “utility” jails that I don’t want starting up on boot. If it does change to start all jails, there either needs to be a way to maintain old behavior with an inclusion list, or at least provide an exclusion list to prevent some jails from starting. I prefer the current behavior with inclusion lists. You have to enable most services - starting all jails by default conflicts with that general principle. Starting all jails - with no way to exclude them - would cause a big problem for me. Comment Actions Valid points. I suggest we start with a switch which enables the new solution. That means it does not break stuff for people who upgrade. Eventually the new behavior becomes the default, and you introduce a switch for the old behavior. Users will be in two camps:
Comment Actions
I'm skeptical that the new behavior should ever become the default, and am interested in hearing the motivation for it.
The .disabled already works if you want to disable a jail completely. But this is about what happens at boot time. I still want to be able to service jail start my-utility-jail after the machine has booted - I just don't want it to start automatically.
| ||||||||||||||||||||||||||||||||||||||