I vastly under appreciated that folks rely upon the ng_eiface not moving with the struct ifnet. Probably because I've been using them in jails for over a decade and only recently noticed myself.

In D49158#1121374, @zec wrote:

Your obsession with getting rid of the "flawed" if_vmove() is noted, but for the sake of other people who may have a different view, and who have applications relying on this very concept for 20+ years, please do not take that route.

In D49158#1121338, @glebius wrote:

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4).

I think I'll just accept my understanding is flawed now to save time and withdraw this. Thank you.

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4). You may create a new netgraph node for your purpose - a node that is present in two vnets, that would be a second legal exclusion to the virtualization rule.

By design, moving an eiface ifnet from one vnet to another impled that its netgraph node will remain attached in the parent vnet. This is not an omission or a mistake, but a well established mode of operation on which certain applications heavily depend on, and which this patch proposes to change, for reasons not clearly stated.

Not really part of this specific problem, but jail(8) should auto-recognize list parameters because their SYSCTL_JAIL specification has a type with ",a" appended. Ideally, it would build a list of such parameters it sees like that. For non-kernel parameters like vnet.interface and zfs.dataset, putting them in the array is probably as good as its going to get.

Looks good to me.

The tests looks good. I need some time to read the code carefully ...

Manpage LGTM

It would make sense for the exec.clean parameter to apply to the config execution. Bit of a chicken and egg problem there, but there's still the "-l" flag.

Address style feedback.

Using this /etc/jail.conf:

.include "/usr/local/etc/jail[.]conf";
.include "/etc/jail.d/*.conf";
.include "/usr/local/etc/jail.d/*.conf";

I'm a little torn on the idea itself, but here's some review

In D45647#1041512, @zlei wrote:

I guess the change for sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c go to upstream first. Will it ?

I guess the change for sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c go to upstream first. Will it ?

I would subtly change the title :-)
Otherwise, looks good to me.

OK for the man page change. Make sure to bump the .Dd when you commit it for this content change.
Thanks for working on this, it's appreciated!

• make some scripts compatible with svcj (convert parts of the precmd into another way of settings variables), precmd is not run inside the same shell/jail = make it work with svcj
• add some support for nfs in svcj, not yet finished (precmd is not comaptible)
• exclude some scripts from svcj due to an incompatible precmd (not run in same shell/jail)

Make jls quiet.

Only rc.d/opensm is missing.

Add support for nfs. Sort the options.

Add config for some more services.

Change what was noticed in comments. Add a feature to enable the execution of extra commands inside the service jail.

In D40188#920799, @jamie wrote:

Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/

Oh and we also have to close it, because it did land! ugh Phabricator is very Project-Management-y :)

In D40188#920799, @jamie wrote:

Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/

In D38826#920142, @ihor_antonovs.family wrote:

IMHO this is superseded by https://reviews.freebsd.org/D40188

Two fixes for the man page.

The overall idea seems ok to me for what it's worth, my comments are about cosmetic issues.

My comments have been addressed and I think it makes sense to go ahead with the proposed patches.

In D40377#922101, @nyan_myuji.xyz wrote:

In D40377#922083, @crest_freebsd_rlwinm.de wrote:

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

Static storage are always initialized to 0/NULL by C standard.

In D40377#922083, @crest_freebsd_rlwinm.de wrote:

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

The jail_name variable must be initialised to NULL. This should be done through an explicit char * jail_name = NULL; in line 101 of route.c.

Commited in eb5bfdd06565. I forgot to add the review to the commit message :-/

I've committed the "jails can include jails" and "use the recursive parser" bits separately. This new diff is just the part that handles the includes.

IMHO this is superseded by https://reviews.freebsd.org/D40188

In D40188#919081, @crest_freebsd_rlwinm.de wrote:

Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32

Just a small nitpick: I would prefer a macro #define MAX_INCLUDE_DEPTH 32 or constant static const unsigned int max_include_depth = 32; somewhere above the include_config() in config.c instead of the literal to improve readability.

Simple include-loop prevention with via a maximum depth counter.

True, they're not handled. I took my include inspiration from newsyslog (which has includes that also support globbing), and there it's also just a simple matter or running whatever it's told to include. It's kind of a footgun situation, where it's generally good enough to trust the administrator not to make such a loop. I did it for depend loops, but only because that's kind of elemental in building an acyclic directed graph.

It doesn't look like the patch in it's current state handles this circular includes.

In D40188#915660, @dvl wrote:

In D40188#915159, @otis wrote:

Haven't looked closely yet, but: are circular includes handled correctly?

This is what I came here to ask.

In D40188#915159, @otis wrote:

Haven't looked closely yet, but: are circular includes handled correctly?

Haven't looked closely yet, but: are circular includes handled correctly?

I you use git format-patch -1 -U9999 and apply it with git am <patch>, you get the whole commit with the message. Not strictly needed, but makes life easier.

I like this approach.
It blurs the line between UCL and jail format (IMHO making future transition to UCL smoother), and makes include more explicit (and less magical comparing to D40188)

New and improved diff :-)

@jamie please re-generate the diff with -U9999 and re-upload it. This is necessary to have context available. (Annoying Phab limitation when diffs are uploaded manually)

I suggest we start with a switch which enables the new solution. That means it does not break stuff for people who upgrade.

In D38826#894218, @guest-patmaddox wrote:

In D38826#887279, @dvl wrote:

All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf

That will require an UPDATING notice.

AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior.

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.

In D38826#887279, @dvl wrote:

All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf

That will require an UPDATING notice.

AND: perhap a switch[es] to preserve the old behavior and if set, enable the new behavior.

This change conflicts with https://reviews.freebsd.org/D39011
@antranigv_freebsd.am and @meka_tilda.center need to hash this out

All jails.conf jail (in /etc/jail.conf, /etc/jail.*.conf and /etc/jail.conf.d/*.conf) start automatically, without the need to define them in jail_list in rc.conf

In D38826#884016, @jlduran_gmail.com wrote:

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?

I like the overall idea, thank you for adding more conf.ds to FreeBSD!

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.

• Remove the memo and add jail_conf_dir