Enable or disable a jail

[yerrysherry]

When rebooting the server, all the jails start up. Sometimes this is not what you want. Now, it is possible to enable or disable a jail.

root@bastille:~ # bastille enable test test: Enabled. root@bastille:~ # bastille disable test test: Disabled.

When the jail is "disabled' it won't start up when the server is rebooted.

I have not changed the command "bastille list" because I have no idea what the best option is.

[cedwards]

sysrc bastille_enable=YES sysrc bastille_list="jail1 jail2 jail3"

This functionality is already supported with the above configuration.

Having said that I do like the dynamic nature of an enable/disable. Will think about this a bit.

[yerrysherry]

Yes, indeed, but it's a long list when you have more than 50 jails. Also when you constantly create and delete jails, it takes some efforts to update bastille_list.

[tobiastom]

I think I prefer this way for the same reason @yerrysherry argued: having a lot of jails makes it quite hard to manage bastille_list manually.

[JRGTH]

Be aware that if the jail is already running and renaming the jail.conf to jail.conf.disable will make the jail to fail to stop with the error "jail.conf does not exist for jail: jail1", and potentially to be unsafely terminated upon a system restart/shutdown.

However, another possible way to implement this enable/disable feature may be by simply using sysrc | sed to manipulate either rc.conf/rc.conf.local by dynamically editing ${bastille_list} on the fly regardless of the jail status.

Regards

[yerrysherry]

Indeed JRGTH, I have not thought of this. I can not change the name of the file jail.conf. The file must always exist. The problem is also that the jails in "bastille_list" are execute in this order. Some users want to start up their jails in a specific order. This makes manipulating with sed hard. An other problem is when this list contains lot of jails. Sometimes I spin up more than 100 jails for testing. Putting so many jails into bastille_list is also not a good idea.

An other solution when the file "bastille_list" is not defined, is to put the file .disable in the same folder as "jail.conf" This could be used when booting up the server.

In the same way, we could put a filename like something xx..enable where xx is the startup priority number: 01 = high startup priority = startup first 99 = low startup priority = startup last

Or create a jail.config file or may by into "bastille.conf", something like: (same as iocage, prefer this way) But that is also harder to program. Ex.

jail["boot"]=true jail["priority"]=1

Then for changing a parameter:

bastille config set priority=50

Regards,

[JRGTH]

@yerrysherry you are right, working with $bastille_list is not so convenient in regards to manipulate jail startup order with hundred+ jails, and there are several ways to accomplish this feature as well.

Was initially thinking on a possible and compact solution by using a global bastille startup file to handle jail startup based on a priority number, while at the same time no priority number = disabled, think of when creating a jail they will be set on that global startup file with an incremental number, then you later want to move that jail number to a higher priority, then make the jail owning that priority to inherit the other jail priority number and alike, however there are caveats too, then create|delete|clone|etc|etc commands have to update said file accordingly and unfortunately may break $bastille_list, i.e. not backward compatible.

And of course your solution by creating a file in the corresponding jail directory is another way to do, but most important is to make this seamlessly integrated and not to break current functionality to maintain startup backward compatibility.

So to use both worlds and keep compatibility is to use the currently working $bastille_list to handle jail enable/disable with simple sysrc/sed and using a bastille/jails/jailname/priority_file? to handle startup priority, while jails not having priority file to be started by the standard $bastille_list.

This is an interesting feature and would like to hear for more suggestions as well.

Regards

[JRGTH]

Hi yerrysherry, I've implemented the enable|disable commands by manipulating the bastille rc vars bastille_enable|bastille_list safely with sysrc, also does not touch jails configuration files, here below are some examples.

Bastille enable and disable example:

root@nas-mserver: ~# bastille enable emby 
Enabling emby...
bastille_list:  -> emby
emby enabled.
root@nas-mserver: ~# bastille enable nginx
Enabling nginx...
bastille_list: emby -> emby nginx
nginx enabled.
root@nas-mserver: ~# bastille enable devel
Enabling devel...
bastille_list: emby nginx -> emby nginx devel
devel enabled.
root@nas-mserver: ~# bastille disable nginx
Disabling nginx...
bastille_list: emby nginx devel -> emby devel
nginx disabled.
root@nas-mserver: ~# bastille enable nginx
Enabling nginx...
bastille_list: emby devel -> emby devel nginx
nginx enabled.

As we can see above the bastille enable command follows the current queue by always placing the enabled jail to last position by default.

If bastille_list is not empty, enabling ALL will clear and set the default startup list:

root@nas-mserver: ~# bastille enable ALL
Clearing current startup list...
bastille_list: nginx devel emby -> 
Enabling all jails...
bastille_list:  -> devel emby nginx
All jails enabled.

Disabling ALL jails example:

root@nas-mserver: ~# bastille disable ALL
Disabling all jails...
bastille_list: devel emby nginx -> 
All jails disabled.
bastille_enable: YES -> NO

Enable command handling the bastille_enable status if non existent:

root@nas-mserver: ~# bastille enable emby
Enabling emby...
bastille_enable:  -> YES
bastille_list:  -> emby
emby enabled.

Enable command handling the bastille_enable status if non set to YES:

root@nas-mserver: ~# bastille enable nginx
Enabling nginx...
bastille_enable: NO -> YES
bastille_list:  -> nginx
nginx enabled.

Error output examples:

root@nas-mserver: ~# bastille enable nonexistent
[nonexistent]: Not found.
root@nas-mserver: ~# bastille disable ALL
All jails already disabled.
root@nas-mserver: ~# bastille enable emby
Enabling emby...
bastille_list:  -> emby
emby enabled.
root@nas-mserver: ~# bastille enable emby
emby already enabled
root@nas-mserver: ~# bastille disable emby
Disabling emby...
bastille_list: emby -> 
emby disabled.
root@nas-mserver: ~# bastille disable emby
emby already disabled
root@nas-mserver: ~# bastille enable emby nginx
Usage: bastille enable TARGET
root@nas-mserver: ~# bastille disable ALL
All jails already disabled.

Pretty much all common checks/errors are handled above.

I can happily commit the PR but I would like some feedback and/or suggestions. Regards

[yerrysherry]

I was thinking about the enable- disable - priority problem. Currently 2 solutions in my mind.

1. with the bastille_list

in /etc/rc.conf bastille_list="10#test 05#tiger 07#clock 10#cup"

When booting the server: bastille_list=$(echo $bastille_list | xargs -n 1 | sort | xargs | sed -e 's/..#//g') echo $bastille_list tiger clock cup test

Each time we add/change a new jail, we put the priority number before the hostname. If no priority is given then it's 99.

What is the best way to set those parameters?

bastille config set Jail priority 20 bastille disable Jail bastille enable Jail

2. with files

We leave the bastille_list as it is. The user must update this file. If there is no bastille_list in /etc/rc.conf, only then we use this option. If no jail priority is set then we use 99 as default. We write empty files into the folder where "jail.conf" lives.

ex. /usr/local/bastille/jails/flower

• Setting a priotity bastille config set Jail priority 20 Create: "20.enabled"

• disable a jail bastille config set Jail start_at_boot false Create the file "disabled"

• enable a jail bastille config set Jail start_at_boot true Delete the file "disabled"

When booting the server: When the file "disabled" does not exist then we add the file name and priority to the variable "bastille_list". Same as we dit in option 1. If there is no "enabled" file. Then we take "99.enable' as default.

bastille_list="10#test 05#tiger 07#clock 10#cup 99#football"

Advantages:

• We don't break anything.
• No need to change the code or bastille_list when deleting, renaming, cloning a jail.
• No need for the commands bastille enable/disable', everything is done with bastille config.
• Is this easier to implement this in a template?

I think option 2 is a nicer way to implement.

[JRGTH]

Hi yerrysherry, great solutions up there, I'm also inclined to the solution # 2 like you but with some suggestions, also I think that the priority stuff and the bastille_list should co-exist as well.

Basically instead of creating/removing multiple files in the jail/dir, we can also directly set parameters to a single jail metadata file like Chris Wells mentioned in Telegram yesterday, something like globals, metadata, manifest etc just for example, then sending/editing/reading/removing per-jail parameters there for the extra functionality. So basically sysrc -f /path/to/jail/manifest PRIORITY=005 ENABLED=YES and a like for example.

However if the current bastille_list has to be used instead since is the currently working defacto, then solution # 1 may be also doable, here is another command example, same as yours but modified it a bit, I used | as delimiter and allows 4 digits number to break the 999 jails barrier:

# bastille_list="jail8 0007|tv 0678|queue 0010|test 0005|tiger 0876|long 0007|clock 0010|cup 0999|lamp 0007|radio 0001|beer jail9 9999|lol"
# 
# echo $bastille_list | xargs -n1 | sort | xargs | sed -e 's/[0-9]\{0,4\}|//g'
beer tiger clock radio tv cup test queue long lamp lol jail8 jail9
# 

As expected jails with no priority delimiter always gets to the queue despite they position on the bastille_list, also attention is needed to the bastille sub commands that will read or manipulate this bastille list.

Regards

[yerrysherry]

Working with sysrc -f /path/to/jail/manifest PRIORITY=005 ENABLED=YES like Chris Wells mentioned is a very good start. I think it's important to specify which parameters are specific for a jail and other parameters, ex. date when the jail was started, comment who has created the jail, info what this jail is doing, ...

[bmac2]

Per Christer's comment above, functionality already supported. Also, this is an old PR on the older code base. If this is still a valid request, please update and submit from the current codebase.