Differences in jail config properties to python-iocage

[gronke]

When interacting with jails created with python-iocage libiocage reports a couple of unknown properties.

The config property 'CONFIG_VERSION' of jail 'iptest' is unknown.
The config property 'hostid_strict_check' of jail 'test-bad' is unknown.
The config property 'host_time' of jail 'test-bad' is unknown.
The config property 'dhcp' of jail 'test-bad' is unknown.
The config property 'depends' of jail 'test-bad' is unknown.
The config property 'comment' of jail 'test-bad' is unknown.
The config property 'bpf' of jail 'test-bad' is unknown.

@skarekrow could you explain what they are used for?

[skarekrow]

Sure, some are in the man page however :P I'll copy the more verbose answers here

CONFIG_VERSION - The config revision of iocage they are on :)

hostid_strict_check - If used, the jail will refuse to start if the host's hostid is not identical.

host_time - Puts the hosts tz into the jail to reduce post configuration

dhcp - Enables...DHCP :P

     dhcp=[on | off]
                   This controls starting the jail with the Dynamic Host
                   Configuration Protocol enabled.  To enable dhcp, vnet and
                   bpf must also be enabled.

                   Default: off

                   Source: local

depends - Will start the specified jails before the current jail, great for a FEMP stack.

     depends=“none | foo bar”
                   Require another jail to start before starting this jail.
                   Space delimited.  The option nests, resulting in dependent
                   jails waiting in turn for their dependents, if specified,
                   to start.

                   Default: "none"

                   Source: local

comment - A comment about the jail, not parsed

bpf - Passes the bpf device into the jail and unhides it with devfs rules, required for DHCP in a jail cleanly. But has security implications.

## IOCAGE -- Add DHCP to ruleset 4
[devfsrules_jail_dhcp=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path zfs unhide
add path 'bpf*' unhide

[gronke]

Thank you for starting to mention feature differences. We should still put those differences in our Version Matrix, but I'm glad to comment here as well:

DHCP

In libiocage you may enable DHCP on an interface level. The setting ip4_addr="vnet0|dhcp" starts a DHCP client for that interface. You can even combine it with static IP addresses. Using this option in a jail implies that it needs an according devfs rule.

Devfs rules are created semi-automatic. When you have enabled DHCP or other features that require specific rules, libiocage is going to check whether your currently selected (defaults to 4) rule meets those requirements. If that is not the case the rule is forked and a new one (with the next available rule number) is added and selected. This has the advantage that you still may create devfs rulesets manually while only temporary enabling DHCP. When it is no longer used, libiocage of course will only use the specified rule (number).

hostid_strict_check

Could you please explain what this is used for. You are right that this feature is currently not implemented because I personally never had the need for that. If you find this to be an important feature, could you please file a new Issue for that and label it Missing Feature?

CONFIG_VERSION

Personally I prefer feature detection over version detection. So far I did not spot any occasion of incompatible configuration formats that would not have been auto-detectable. Libiocage makes sure though that only new features would be stored in a conflicting format. (Such a feature for example is the nested structure in provisioning.ix)

host_time

The host time and locale should both be inherited on jail creation. If a user decides to change them later on that's fine, but it makes more sense to me to come with a matching configuration by default. @foo2342 might have an opinion here as well.

depends

Jails depending on other jails are a common situation. So far users may alter the boot order by setting numeric priorities in form of the priority jail config property, but I find it more reliable to depend on other jails. The issue with this feature is that it increases the complexity quite a bit depending on the implementation. I suggest we create a dedicated GitHub Issue for that because the devil is in the details.

comment

A similar feature in form of a user jail property namespace is already on its way in #470. With it being implemented you can store such information in user.comment or any other user. prefixed config property. @skarekrow do you have any particular use for this property comment?

[foo2342]

DHCP In libiocage you may enable DHCP on an interface level. The setting ip4_addr="vnet0|dhcp" starts a DHCP client for that interface. You can even combine it with static IP addresses. Using this option in a jail implies that it needs an according devfs rule. Devfs rules are created semi-automatic. When you have enabled DHCP or other features that require specific rules, libiocage is going to check whether your currently selected (defaults to 4) rule meets those requirements. If that is not the case the rule is forked and a new one (with the next available rule number) is added and selected. This has the advantage that you still may create devfs rulesets manually while only temporary enabling DHCP. When it is no longer used, libiocage of course will only use the specified rule (number).

I agree that we can deprecate the dhcp option.

hostid_strict_check Could you please explain what this is used for. You are right that this feature is currently not implemented because I personally never had the need for that. If you find this to be an important feature, could you please file a new Issue for that and label it Missing Feature?

This feature exists so you don’t end up running a jail with the same IP on two hosts after a zfs send. Very useful, should be implemented.

CONFIG_VERSION Personally I prefer feature detection over version detection. So far I did not spot any occasion of incompatible configuration formats that would not have been auto-detectable. Libiocage makes sure though that only new features would be stored in a conflicting format. (Such a feature for example is the nested structure in provisioning.ix

Your call, however proper versioning is a good idea in any storage format Imho.“

host_time The host time and locale should both be inherited on jail creation. If a user decides to change them later on that's fine, but it makes more sense to me to come with a matching configuration by default. @foo2342 might have an opinion here as well.

I’m a bit undecided here. Normally I like to keep the jails as separated from the host as possible, however the time is such a basic setting it’s okay to automate it. Locale on the hand needs commands executed in the jail, so I would advice against it.

depends Jails depending on other jails are a common situation. So far users may alter the boot order by setting numeric priorities in form of the priority jail config property, but I find it more reliable to depend on other jails. The issue with this feature is that it increases the complexity quite a bit depending on the implementation. I suggest we create a dedicated GitHub Issue for that because the devil is in the details.

Useful feature.

comment A similar feature in form of a user jail property namespace is already on its way in #470. With it being implemented you can store such information in user.comment or any other user. prefixed config property. @skarekrow do you have any particular use for this property comment?

Why would we deprecate it without reason? People might store information in the property, let’s not throw it away. How is this even up for discussion?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[skarekrow]

I’m a bit undecided here. Normally I like to keep the jails as separated from the host as possible, however the time is such a basic setting it’s okay to automate it. Locale on the hand needs commands executed in the jail, so I would advice against it.

Right, it's on by default in iocage, as I find it fairly harmless. But users need a way to disable defaults, hence the property.

depends
Jails depending on other jails are a common situation. So far users may alter the boot order by setting numeric priorities in form of the priority jail config property, but I find it more reliable to depend on other jails. The issue with this feature is that it increases the complexity quite a bit depending on the implementation. I suggest we create a dedicated GitHub Issue for that because the devil is in the details.

You're conflating priority and depends. Depends is granular, so a jail can be sure the others are started first. It's not terribly complicated, it just starts those jails and if they didn't fail, starts that jail. It could be extended to be even more useful

Devfs rules are created semi-automatic. When you have enabled DHCP or other features that require specific rules, libiocage is going to check whether your currently selected (defaults to 4) rule meets those requirements. If that is not the case the rule is forked and a new one (with the next available rule number) is added and selected. This has the advantage that you still may create devfs rulesets manually while only temporary enabling DHCP. When it is no longer used, libiocage of course will only use the specified rule (number).

Yes that's how iocage does it, the only difference between the implementations are in specifying dhcp in the interface constructor instead of a separate property. That property was inherited from legacy, to be less disruptive. That's fine to drop.

Personally I prefer feature detection over version detection. So far I did not spot any occasion of incompatible configuration formats that would not have been auto-detectable. Libiocage makes sure though that only new features would be stored in a conflicting format. (Such a feature for example is the nested structure in provisioning.ix

I strongly suggest you revisit that idea and use versioned configuration.

comment
A similar feature in form of a user jail property namespace is already on its way in #470. With it being implemented you can store such information in user.comment or any other user. prefixed config property. @skarekrow do you have any particular use for this property comment?

Just user comments, many things in iocage are by request, not personal use case ;) But it's a small property that others are currently using and will expect to continue to do so. It's not the same thing as user properties. While I think they can serve many of the same use cases, comments have the advantage of being normal language the user can decide. Or JSON, or whatever the user wants to put in it frankly. Let's not remove things, everything is there because of some issue or requirement, iocage has a had a long history ;)

TLDR; I agree with @foo2342 :)