Shell Simple jail making script : jcreate

J

JohnK

My goal was to create "jail setup up scripts" using shell script (took inspiration from BSDPot) and I wanted to an easy(ier) way to create jails and test my scripts (while still giving myself some sort of organization). I ended up creating a simple script that creates jails the way the handbook says to: jail.conf. My script works but now I'm wondering what I did wrong.

My script doesn't do anything extravagant besides extract the userland, load in my script but it cant be this simple.

I was wondering if someone could please test this (even a simple once-over-eyes-only will suffice). I'm still learning shell script--and I knew I wanted to ask for a quick test so, I took some time and tried to add a bit of "professionalism" to the script by using function defs, validating, checking and what not to make it easier to follow. I also put a bit more effort into the makefile (to install/uninstall from traditional locations) and documentation. I'm not proposing yet another jail manager (which is this is not) but I want to verify if this method works before I go off creating a bunch of "setup scripts". I know my coding is not great but someone with more experience can tell me if this script will launch rockets or something horrible at least.

github.com

GitHub - JohnKaul/jcreate: Script to create a FreeBSD jail.conf style jail with setup script, mounts, copy-in abilities

Script to create a FreeBSD jail.conf style jail with setup script, mounts, copy-in abilities - JohnKaul/jcreate
github.com github.com
 
I have made two updates to this jail setup tool:

  1. Added the optional ability to install packages from the host system with a 'jail.packages' variable. This allows the jail to be slimmed (extra unnecessary stuff removed from within) thus moving the jail maintenance steps to host system. This also should allow for easier copying of existing jail templates (like the plugins or scripts others have written, which may keep a separate package list). See the “emby example” in the example directory.
  2. Added a check for existing userland (container). This should allow for updates to be run -i.e. skipping the userland extraction step will allow for the setup script and etc. to be (re)copied in and run for extra/changed setups.

Again, this is not a jail manager. The tool's only purpose is to extract the userland and setup the jail.conf file. This allows me to keep/create jail setup scripts/configurations, in a directory, and stay organized.
 
I've probably written more documentation for this tool than actual code but what you need to know about this tool (if you haven't looked at it) to answer the following question is:
This tool extracts a userland .tar.gz and runs a setup script on it and creates a conf file in /etc/jail.conf.d/. I run the script by copy-in, launching the jail and executing the script (basically, this script does what the handbook says to do but adds the option to add a setup/configure script). Currently it works great, but I wonder what benefits (if any) there would be to setup a rc.d script to launch the setup script upon jail start instead of launching the script?

Are there any benefits or problems with using rc.d instead of out-right-execution (my thought was I could eliminate the "jail start", "launch", and "stop" phase)?
 
I have created and tested an instancing based rc.d script for the jail setup portion of this tool to use the rc.d system instead of the current "execution-based method". By using an rc.d script to launch the setup this should allow for more streamlined automation possibilit(y/ies); since the host system can copy-in an updated setup script and enable the script to be run on launch/reboot with either manual scripting or an updated `jcreate` configuration.

The rc.conf looks like:

Code: 
run_setup_enable (bool):        Set to YES to enable run on startup.
                                Default: NO
run_setup_path (string):        Path of script to run

because the rc.d script is instancing, it will allow a symlink to be created:

Code: 
ln -s /usr/local/etc/rc.d/run_setup /usr/local/etc/rc.d/run_setup_sshd
sysrc run_setup_sshd_enable=YES
sysrc run_setup_sshd_path=/location/of/sshd/setup/script.sh

The jail can then be restarted, or the service(s) can be manually started from within with a service start like:

Code: 
service run_setup_sshd start
 
Thinking about the rc.d step more last night, I think this may pan out to be more of an unnecessary feature than I think; in that, during creation if the packages are to be installed from the host, the jail is started anyways so the rc.d setup script wouldn't save a jail execution step (i.e., the rc.d setup script may stay in my back pocket for now).

However, I did find a bug in the last commit. Fixed and pushed.
 
Implemented a `host.config` variable to execute commands or launch scripts that do setup on the host.

-e.g. host.config = "host_setup_script.sh"
which can create directories or copy setup scripts for use in the `exec.poststart` / `exec/prestop` jail.conf variables or anything else you desire.

-e.g. host.config = jail -m ... meta="key=value" env="configuration"
or attach metadata to the created jail.
 
You must log in or register to reply here.
Back
Top