It would be good to mention this in some man pages as well.

The new directory should also likely get added/tagged in mtree (^/etc/mtree/BSD.root.dist), so that we create it empty and add it to the 'utiltiies' package.

Hmm, I think it looks better this way?

Regarding the issue with _ALL actions, maybe it's better if I address that with another patch?

I would love for there to be some way to include global config in jail.conf and per-jail config in jail.d/${jail}.conf. This is a good start in that direction.
Getting libucl to work properly with the current jail.conf format would be a nice way to handle that. I have opened an issue here for one of the limitations I see preventing this: https://github.com/vstakhov/libucl/issues/227

Apart from the little man page nit I'm satisfied with this for now, but let's get it approved/committed by someone with more sway in the area.

Don't forget to update .Dd for manual pages. :-)

Also I think it would be nice to add some words in jail(8).

Can you check the manpage with textproc/igor and "mandoc -Tlint" to see if they find anything?
Thank you!

In D24570#568561, @antranigv_freebsd.am wrote:

however, still not able to understand mandoc's STYLE message :(

mandoc: share/man/man5/rc.conf.5:3848:14: STYLE: no blank before trailing delimiter: Pa /etc/jail.

It means that there must be a space after "jail":

.Pa /etc/jail .

Sorry for if this sounds link nitpicking. While checking /etc recently, I found that we have two naming of .d directory and its related .conf file in /etc:

pam.d - pam.conf
syslog.d - syslog.conf

and

newsyslog.conf.d - newsyslog.conf
rc.conf.d - rc.conf

And there are also ones not in these two cases:

cron.d - crontab
rc.d - which is where we put scripts but not config files.

This makes me think that what we should name this directory, jail.d or jail.conf.d? And for the above, it would be nice to get them aligned.

+1 for jail.conf.d

shorter is better, +1 for jail.d

In D24570#607987, @pi wrote:

shorter is better, +1 for jail.d

The problem with shorter in this case is that it's too vague, raising the possibility of confusion if some extended jail manager were to land in base. jail.conf.d is still relatively short, but more importantly cannot conflict with anything else because other applications already could not use jail.conf.

While I understand @pi 's point, I think jail.conf.d is better. I'm also planning to submit my base-based written in shell jail orchestration tool, using jail.d would be better for integrations (e.g. hooks, scripts, etc).

When decided, I will change the patch as needed.

In D24570#554569, @freqlabs wrote:

I would love for there to be some way to include global config in jail.conf and per-jail config in jail.d/${jail}.conf. This is a good start in that direction.
Getting libucl to work properly with the current jail.conf format would be a nice way to handle that. I have opened an issue here for one of the limitations I see preventing this: https://github.com/vstakhov/libucl/issues/227

i'd rather we have a pre-processor that issues warnings and urges people to upgrade their configs to pure UCL than to add explicit anything to the library

Hi,

ezjail has jail-config files in /usr/local/etc/ezjail/. Would it make sense to be able to override the path (BTW: /etc/jail.conf.d would be my preference), in the sense of having it as a variable in /etc/defaults/rc.conf (would this help in the netboot case)?
Would it make sense to make this a list,, so that I could do e.g. jail_conf_dir="/etc/jail.conf.d /usr/local/etc/jail.conf.d"?

Bye,
Alexander.

In D24570#616031, @netchild wrote:

Would it make sense to be able to override the path (BTW: /etc/jail.conf.d would be my preference), in the sense of having it as a variable in /etc/defaults/rc.conf (would this help in the netboot case)?
Would it make sense to make this a list,, so that I could do e.g. jail_conf_dir="/etc/jail.conf.d /usr/local/etc/jail.conf.d"?

+1 on both of these.

But I would also like the idea of these directories enumerating the jails when there aren't any jail names in rc.conf. One of the main advantages of a config directory is just being able to drop something into it without needing to update a global configuration file.

Hi @antranigv_freebsd.am,

Sorry for the delays on this; I dropped some inline comments based on the last bit of discussion that took place. I think we're in a good place to start driving this forward again. There are other things we can do to improve this, but IMO we can get the basics in place to match existing facilities then further enhance it once it's in-tree, e.g., @jamie's latest comment about an empty jail_list also indicating anything we can find in these directories.

Hey @jamie thanks for the feedback.

@kevans There are bugs in this current code, one line of return is missing, I think after one of the ifs :) . We run the new patch on prod at $WORK, I will update it accordingly (with our changes) and your feedback today.

Thank you all!

In D24570#551276, @antranigv_freebsd.am wrote:

Correct the documentation

As mentioned by kevans, jail.8 should not be changed, while in rc.conf it should be mentioned that the non /etc/jail.conf Jails will start only when listed in jail_list.

I prefer the approach taken by other tools where any *.conf file is an active file.

At present, any jail listed in /etc/jail.conf starts at run time if jail_list is empty.

I think it makes more sense all /etc/jail.d/conf/*.conf to be loaded and started at boot time.

In D24570#660901, @antranigv_freebsd.am wrote:

Hey @jamie thanks for the feedback.

@kevans There are bugs in this current code, one line of return is missing, I think after one of the ifs :) . We run the new patch on prod at $WORK, I will update it accordingly (with our changes) and your feedback today.

Thank you all!

Hey Antranig,

Friendly poke. :-)

Is this at the stage where I could start using it on a test system to provide feedback?

In D24570#721083, @dvl wrote:

Is this at the stage where I could start using it on a test system to provide feedback?

Yes! At the current stage you can put your jail configuration into /etc/jail.conf.d/www0.conf and then do sysrc jail_enable=YES; sysrc jail_list+=www0 and it should all work fine via service jail start www0.

Currently I'm working on auto-discovery i.e. if jail_list is empty, then it would automatically start /etc/jail.conf, /etc/jail.{name}.conf and /etc/jail.conf.d/{name}.conf, which I thank you for suggesting it :)

In D24570#721104, @antranigv_freebsd.am wrote:

Currently I'm working on auto-discovery i.e. if jail_list is empty, then it would automatically start /etc/jail.conf, /etc/jail.{name}.conf and /etc/jail.conf.d/{name}.conf, which I thank you for suggesting it :)

OK, good. Here is what I wanted to do. Do I understand correctly?

/etc/jail.conf:

exec.start = "/bin/sh /etc/rc";
exec.stop  = "/bin/sh /etc/rc.shutdown";
exec.clean;
exec.consolelog="/var/tmp/jail.$name";
mount.devfs;
path = /jails/$name;
allow.sysvipc     = 1;
allow.raw_sockets = 1;
securelevel = 2;
host.hostname = "x8dtu-$name.vpn.unixathome.org";
persist;

Then in /etc/jail.conf.d/pg01.conf:

pg01 {
    ip4.addr  = "lo3|127.163.54.32/32";
    ip4.addr += "igb0|10.100.0.200/32";

    persist;
}

If I don't want pg01 to start, I can do: mv pg01.conf pg01.disabled, for example; anything other than ending in .conf will disable that jail.