Jails have functionality beyond Apps. For example, it’s pretty likely that iXsystems will increasingly lock down OS / TrueNAS. In turn, that will likely start to break things you can currently do at the OS level.
Hence, you’re likely better off creating jails that are fully segregated from the OS for many tasks like scripts, etc. Jails will continue to exist on your datasets vs. being at greater risk of critical settings / packages / etc. being overwritten inside the boot pool.
For example, I found that my iocage folders were pretty devoid of anything useful when I transitioned the NAS from core to scale so I’m glad in now have jails that I can back up separately.
Then there is the issue of cruft. For example, my CORE boot pool included @dan’s excellent deploy freenas script to allow a wider scope of DNS providers than route 53 for SSL deployment to TrueNAS.
SSL deployment goes beyond just acme.sh, it also includes the need for socat snd other packages. Some
of those items may be incompatible with the OS or require the use of a different version of the enabling software than iXsystems includes in its version of Linux.
In a jail, you can have whatever you need, making similar changes inside the boot pool you are potentially risking the stability of the NAS.
These days, I save scripts that require additional software installs into a dedicated jail and once those scripts are no longer needed, delete the jail rather than try to return the underlying boot pool back to a “pre-deployment” status. It keeps everything cleaner.
Actually the simple way with SCALE is now to have Docker containers for each app directly in TrueNAS and no sandbox.
Sandboxes (next month with LXC and Incus over nspawn and jailmaker) are for more complex applications where a container does not fit, or if you want full control of what goes in.
There’s no need to install docker in a sandbox, unless you want full segregation or some non-standard installation (e.g. rootless Docker).
Thanks. I’ve been reading about Incus, and I think that’s probably the way I will want to go rather than Docker. At least, that seems to be the most straightforward way to reproduce my current jails (including having separate IP addresses and preserving settings). It looks like Fangtooth is now stable, so just need some free time to redo everything.
I have been running several Ubuntu LXCs with some special sauce to detect intruders and monitor all the networks for new devices (opencanary + arpscan), since Jailmaker was released.
It just works, so I will simply wait until they get Containers working under libvirt.
IX virtualization back and forth did make me pause in my VM and Container plans/testing, so I only hope that the next release is finally “complete”.
Hello, I can’t seem to find a way to edit the name of a jail that is created with jlmkr
I tried jlmkr edit jailname and there doesn’t seem to be a name in the config to alter
EDIT Scratch that, I just copied the folder of the jail to a new name and then it creates a new jail of that name and I start it and remove the old one
