Unable to create 13.4 jail

TrueNAS General
,
21

yes, but when I looked at bastille it required the setup scripts to be written in a short-hand form. I wanted to utilize all the existing setup scripts out in the wild already. Like the iocage ones from iX, yours, etc… But, yes, I don’t expect mine to used mainstream (I doubt anyone besides me has even tried it) and I know my code doesn’t stack up to professionally written and/or sponsored jail managers like bastille but, for my first venture into shell scripting, I really tried to apply professional coding practices to the scripts (created single use functions with proper headers) and added a ton of comments in my code in the hopes someone smart will actually comment.

My feeling is that jails will become even more trivial to setup for the end user and there will be a bigger push towards packaged jails developed using automated configuration/packaging/deployment of “jails” with things like tarfs. I mean, I think in the future people can set up a jail and package up the userland for deployment so my concept of keeping a directory for each configuration should help in the automation and setup aspects. However, most of these jail managers store the jail.confg file in the jail’s container location instead of the system default of /usr/local/jail.conf.d. This will hinder the whole idea of sharing jail userlands.

So, for example: my script will ignore the “userland extraction” process if the userland already exists and just create the jail.conf file. This will hopefully allow an end user to download a tared-up jail, mount it–or extract it–and just create a jail.conf file. …sharing is caring.

But yes, you are right. My script will never get tried and people will stick to flashy, more known, tools like Bastille, IoCAGE, CBSD, etc.

EDIT:
I guess that post was a bit gibberishy. I think people are focusing on the wrong aspect of what a “containers” should be and I’m tired of redoing every six months (jails, docker, k8s, k3s). The fundamental aspect of a “jailed service (like: plex)” should contain all the things it needs to run (aka: a userland which is only dependent on the host’s kernel) and the configuration (IP address, name, mount points, etc) should be kept separate. I’d love to just tar up a jail, share that tarfile and you just create a jail.conf file containing the mount points specific to your system/needs. Let other people who are actually smart talk/work on setting up fancy container specifications, schemas, deployment methods, and whatnot I just want to download a “14.1 plex” tarfile, extract it, give it the name, mount points, and IP I want so I can do something else besides sit in front of a damn computer.

22

I use the Bastillefile with ask my scripts. Simply fetch and run.

The rest requires mount points, which have to be run from the host, and can be included in the Bastillefile.

23

Same as me. …But you’ve just made my point about people will always choose the “mainstream version” which will eventually just stagnate the whole jail/container thing. People will always choose the mainstream–and even possibly do more work than necessary every rendition–even if the workflow is the exact same and thus never advance the thought process.

24

True to a point.

I use it for these reasons.

POSIX compliance
No dependencies (unless for Linux jails)
Easy to script and improve
Simple, small lightweight
Among some others…

25

Please don’t get me wrong, my script’s existence isn’t dependent on your or anyone’s usage. I made it for my personal use (it would be nice if people shared “14.1.jail.plex.tar” files with each other but that’s not going to happen). My script I would argue is all of what you list and more (mine is even smaller, more easier to configure–because my configs are file based instead of command line switches–, zero dependencies, single purposed, etc.) but I’m just happy that you–or anyone–has something that works for them (use what you like and understand) because that’s just that many more experts. I prefer to have FreeBSD manage my jails, other people like–or want to rely on–the jail manager and that’s totally fine. I set up and configured Bastille and Rocinante (sp) on my server when I first started to make the switch from TrueNAS but I didn’t like spending time writing stuff that was useless without that specific tool (I cannot use any of what I wrote for those tools–it was a waste of my time).

I want the OS to manage my jail because: sysrc is a tool to edit the rc.conf file; this promotes the ideas of and concept of automation and intelligence (self-healing). Wouldn’t it be nice to use that sysrc mindset on jail.conf files? Currently sysrc doesn’t understand UCL but I’ve emulated UCL in my configuration files in the hopes UCL will be more adopted. Because of that I even had to build a little parser (a very, very dumb one) in shell script. However, while I hope this will happen, I’m not holding my breath, so I just wrote/rewrote five (5) libraries in C (all memory safe, commented, and streamlined) to build myself a little language independent config parser thing and a few other tools in this class just in case the actual smart people in charge don’t move fast enough for me.

26

That’s also news to me. So if I create my jails with Bastille they will be started by the OS without any specific bastille service enabled like with iocage?

That would be great. A nice CLI tool for interactive work but for production just deploy jail1234.conf with Ansible is what we are seeking.

Kind regards
Patrick

27

From the documentation, I believe you can use the rc.conf list method with Bastille as well (i.e., this looks like it emulates the jail_list method listed in rc.conf(5)) but, no, bastille is still doing the starting (you need to enable bastille and specify the list of jails or let bastille start all jails without a list).

Services in FreeBSD are managed centrally in the /etc/rc.conf and use a syntax of name_enable=(YES|NO). For example, to start containers automatically at boot you can set bastille_enable=YES using:

sysrc bastille_enable=YES
By default, Bastille will start all created containers at boot when enabled.

To specify a limited list of containers to start at boot, set the optional bastille_list value to the name(s) of containers to start.

sysrc bastille_list=“azkaban arkham alcatraz”
Once services have been enabled in the /etc/rc.conf, they can be managed using the service command.

service foo [start|stop|restart]
Bastille does not run as a service and does not need to be started as such. Enabling Bastille primarily manages containers at startup and shutdown.

EDIT:
An aspect you didnt mention out-right, but is related to what I think you’re also after is automatic restarting or “self-healing” jails.

Since I find myself using a “plex jail” as my theorical jail all the time, I’ll keep to that. In my /etc/jail.conf.d/plex.conf file I have these two lines.

  exec.poststart += "if [ -f /var/jail/jobs/plex.crontab ]; then cp /var/jail/jobs/plex.crontab /etc/cron.d/plex.crontab; fi";
  exec.prestop += "if [ -f /etc/cron.d/plex.crontab ]; then rm /etc/cron.d/plex.crontab; fi";

which just copies/deletes a cron file upon start/stop and just checks if a process is running. If not, restart the jail (e.g. service jail stop/start plex...).

   @hourly	root    /var/jail/jobs/processcheck.sh "Plex Media Server" plex

So then, in theory, I would also start/stop the bastille service as well as the jail start/stop to be extra cautious. CORRECTION: since bastille is *NOT* a service, I believe you can emulate the same without start/stop bastille itself. NOTE: I implemented the processcheck.sh and the cron file but I copy/enable/setup this gymnastics when my jail gets created.

28

Bastille still has a service that will start the jails on boot. But the bastille command simply executes the “jail” command and points to each jails conf file.

It also does things like add redirection rules, add the jail IP to pfctl etc…

29

So then in theory, you could get the system to do the starting with some manual additions to the master /etc/jail.conf file after you create the jail.

.include	"/a/location/where/bastiles/creates/jails/jail1/*.conf";
.include	"/a/location/where/bastiles/creates/jails/jail2/*.conf";

Which, in theory, would enable a service jail start jail1 but I’d be 100pct sure Bastille isn’t doing more gymnastics than just calling jail.

If at all possible, I highly recommend using a master jail.conf file with each jails.conf file in the jail.conf.d directory. The include directive added to jail in 14+ is a real game changer and makes life so much easier. I’m not sure if the include directive is recursive (I’d have to study the code) but if it were, the include statements would be easier to maintain and/or create.

30

That is true. Bastille only calls the jail command with the conf file.

But as I said, if you want to do rdr, you need the pfctl commands.

I’ve gone through every bit of code for bastille and am pretty familiar with how it works.

It just runs “jail….-f /path/to/jail.conf” for each jail to start it.

1 Like
31

So, I’m working on the readme for my project and right at the top I’m putting a disclaimer:
“This is NOT a jail manager, it only sets up a jail container based on a configuration.”