The jail.conf system seems to be rather useful in and of itself, but given the approach of docker, xorg, openldap, and such, shouldn't this be easier to drop and replace config like in the conf.d format rather than appending the one conf file? I believe even rc has this approach available using rc.conf.d system. This would make much more sense given that jails are individual objects in the system. Individual conf files allow quicker deployment, copy and modify, and updates to the individual jail rather than the whole conf file - especially by automation tools, where it is likely you'd want better protection to individual jails rather than bork the lot if something goes sideways if the one conf file is modified.
(In reply to rocky from comment #0) It seems that in FreeBSD 12.0, it is possible to have per-jail rc.conf files. Perhaps, this might help you because the approach seems similar to conf.d. Good examples can be found at /usr/share/examples/jails or at: https://svnweb.freebsd.org/base/release/12.0.0/share/examples/jails/ I haven't tested this myself, but while reading through the example, the "conf.d" style may be already possible in 12.0.
I don't think it really is the same thing, as it seems that one is required to use rc.conf. While that might be a workaround allowing something like include /etc/jail.d/*.conf or even: include /usr/local/etc/jail.d/*.conf would allow one to simply use a file system overlay or installing a jail for example via a package without having to modify rc scripts. In that regard it could behave similar to newsyslog.conf.d which recently got a similar features allowing the same thing. This might even benefit the ports system. So while using rc.conf is a workaround /etc/rc.d/jail defaults to just loading /etc/jail.conf and it would be nice for software that is able to handle jail.conf(5) syntax to create (or parse) such jail configuration files and not having to understand how /etc/rc.d precisely parses options in the rc.conf. It would be really helpful for third party software and automation to have a setup similar to newsyslog.conf.d, where includes are supported (the syntax above is just an example, maybe ) and per default - if enabled - looks in both /etc/ and /usr/local/etc.
/signed I think this would really improve jails . Moving jails around from one host to another is a pain.
/signed to Further support for this. Would significantly aid portability and transport of individual jails between systems.
Take.
^Triage: Assignee timeout, reset.
I would look to an official tool/process to appear in base. In the mean time I created a tool for myself that (so far) has worked well for my use cases. It's very crude, but does the job. https://github.com/tuaris/freebsd-admintools#build-config-lets-you-manage-a-conf-file-using-a-modular-approach
^Triage: Antranig has a PoC/WIP in review, add references: https://twitter.com/DLangille/status/1385047281104269313
The function your talking about adding is all ready there in jail. There is no restriction in having more that a single jail.conf formatted file as in one for each jail on the host. All that is needed is a jail start command line to target each individual jail on the host. The jail command allows you to point to any file no matter its name as long as its formatted with jail statements. The qjail utility uses this concept as the standard way of defining and running all it's non-vnet and vnet jails. Would like to see qjail become part of the base system. Comment 3 and comment 4 are also already handled in qjail. And one thing no one has brought up before is that the jail parameters defined in the rc.conf file are depreciated and were scheduled to be removed in release 11 but are still being carried along forgotten.
(In reply to Daniel Morante from comment #7) > I would look to an official tool/process to appear in base. The purpose of this PR is to create such a tool for base.
(In reply to joeb1 from comment #9) > The function your talking about adding is all ready there in jail. We disagree. Having a jail.d directory is quite different from what you described, from what I understand of it. Can you give an example of what you mean by "All that is needed is a jail start command line to target each individual jail on the host." please? > And one thing no one has brought up before is that the jail parameters defined in the rc.conf file are depreciated and were scheduled to be removed in release 11 but are still being carried along forgotten. Sounds like a separate PR entirely.
there's a proposed change: https://reviews.freebsd.org/D24570 it's stuck somewhat
This was landed as commit 7955efd574b9 [1] back in September, 2021 - so I think it's safe to close this bug report now. :) 1: https://cgit.freebsd.org/src/commit/?id=7955efd574b9