You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR aimes to close#33 and currently expects #32 being merged first.
I implemented a --prefix option to the activate command. This prefix is currently saved in a zfs property of the pool, like the active pool flag.
Non-regression tests are passing (see checks on fork repo or directly on Cirrus CI).
The issue that remains is that jails, even if they are exposed a dataset they can use, cannot modify the zfs properties of the host pool. So I am not sure how to proceed from there.
I am thinking of implementing a configuration file / a configuration option in /etc/rc.conf - but that would break the current iocage philosophy of working only with zfs as its source of information. We could however limit the damage by leaving it optional and only using that way of working if the file / option exists.
What do you think?
Make sure to follow and check these boxes before submitting a PR! Thank you.
Instead of using pool/iocage, we can now use anything like
pool/some/prefix/iocage, which enables iocage use within jails. To do
so, use the -p / --prefix option with iocage activate. The prefix is
then stored as a ZFS property of the pool and used for all commands.
A fixture is also added to the tests to enable functional tests.
It's a big change, and a good idea IMHO.
Could you rebase this on master, to avoid mixing ALL feature with this one ?
I'll try to review and test this next week (hoping I'll find time to)
While thinking, why not including /iocage in iocroot variable, this may allow using arbitrary zfs to contain jails without mandatory /iocage/ parent zfs ?
Also, nowadays there are not many properties stored in zfs as it used to be in the old shell version, most data is in json files (defaults and jails configs).
I think the only config bit in zfs prop is iocage's main location.
Yes that's possible. I will try to make things work with the prefix approach work first and then we can improve. For the first step I preferred changing the least I could.
We could also try and do some refactoring and make sure we use either Dataset or Path objects in the different places. I feel like the current code mixes both a bit, with strings here and there, so it would make it clearer.
For configuration, I went with settings in /etc/rc.conf and getting by calling sysrc. It works fine outside a jail (see CI runs on my repo). Although we might want to check performance later and maybe cache the result.
I am still working on some issues with hierarchical jails:
iocage cannot manipulate devfs rulesets like it currently does on the host inside jails. I fixed this by catching the error on the call to devfs and falling back to devfs_ruleset=0 but that is not clean so I am looking at using sysctl instead like they did in bastille (see BastilleBSD/bastille@6ca8ea5).
iocage cannot mount the second-level jail's /var/run/log in /dev like it does in the first-level one. But I have no idea why it tries to do that anyway. Do you?
Apart from that, it works. I will do some cleaning up and try to push a new version you can play with in the week.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello,
This PR aimes to close #33 and currently expects #32 being merged first.
I implemented a
--prefixoption to theactivatecommand. This prefix is currently saved in a zfs property of the pool, like the active pool flag.Non-regression tests are passing (see checks on fork repo or directly on Cirrus CI).
The issue that remains is that jails, even if they are exposed a dataset they can use, cannot modify the zfs properties of the host pool. So I am not sure how to proceed from there.
I am thinking of implementing a configuration file / a configuration option in
/etc/rc.conf- but that would break the current iocage philosophy of working only with zfs as its source of information. We could however limit the damage by leaving it optional and only using that way of working if the file / option exists.What do you think?
Make sure to follow and check these boxes before submitting a PR! Thank you.