I wonder how all this would work for things that require an initial configuration of a database and so forth. Once you then delete the jail and try to recreate it with your mount points, how will it know to not do the initial configuration?
I suppose most service have a config file that you can edit after the fact and point it to your already configured database/config files.
Guacamole has a guacamole.properties
Nextcloud has a config.php
Others, like Uptime-Kuma simply have a data folder that hold everything.
Humm…database config will be fun. I mean, using shell commands in the first-person I do not think it will be difficult but probably not the best idea to mount in a database directory.
On using BSDPot? Seems super stable; I plan to use it for now. Instead of working on the database config stuff, I got a bit diverted making my own mini-jail-making-script-thing. On my diversion, I got as far as creating a jail.conf file and copying in a script to run, and doing mountings and all that stuff (I got to the point of being a “functioning–but fragile–jail maker”).
As far as the database config stuff, I saw a post where Dan did a plugin script for Nextcloud; my plan was to steal as much of his stuff as I could because it seemed as though he must have worked through a lot of stuff with his script (his script seemed like he put a lot of work into it). When I initially glanced at his script, it looked as though he was issuing the commands to IOCAGE to execute on the jail; for my setup, I’ll just rewrite his IOCAGE EXEC steps and copy in the script to be run from with inside the jail.
For me there are essentially two paths you can go down with these jail managers (this is why I got diverted on my own mini-jail-manager-thing):
Copy in the script(s), start the jail, execute the script(s).
Copy in the script as an rc.d type script(s), enable the service(s), run the script(s) when the jail gets started.
Both have their goods-and-bad points and I’m leaning more towards the simpler #1. I want to start creating a series of jail configurations (plugins so-to-speak) which other BSD-ers can grab from. The BSDPot “templates” are geared heavily towards the whole image type of thing–docker-like–and I want simple jail setup scripts right now. I resurrected my GitHub so I’ll try to keep you updated if I get some templates going.
I also have another project in the works but that hasn’t really gotten past the concept stage (well, I found “the tool” I plan to use and started learning the “how’s and what’s” but thats about it).
I also starting making you a man page for your ZFS tool/script but I didn’t finish it (and I thought I saw that you had reworked the entire script).
The “zfs-replicate” script? Yes, with the help of the author, aaronhurt, we are now completely POSIX compliant and it’s an incredible tool. I did most of the testing, and he did most of the writing.
I’m looking into Bastille again, but I’m with you on the whole script thing, as jail managers come and go, it would be best to have a universal script that can simply be run inside the jail.
Mounting will ultimately have to be done with the “mount” command outside of the jail, probably before running the script on the inside.
As for reinstalling overtop existing data, we could figure that the same way the nextcloud script does it. By checking the corresponding paths for a database, data files, etc…
I’ve been wondering about how to do proper install/reinstall of applications, and I think you just gave me THE idea.
Create the jail with whatever manager you so choose.
Add your mount points using the jail manager, or simply the mount command (will need to document what and where for each app)
Set your jail properties using the jail manager (if needed, ie: mlock, allow_raw_sockets etc…)
Execute the script inside the jail. The script will be able to read the data from the mount points and determine if it will be a full install or reinstall
That mini-jail manager I was writing did steps 2-4. You could play with it, it’s in a pretty crude form but it worked. I’ll get a link to my GitHub when I get back home; I think I pushed a working copy.
Here is a link to that mini-jail manager thing I was writing. Looks like the version I published on github didn’t “handle mountings” all that well, but this is only a sideline project and only really exists to allow me to create the scripts (see the example in the link below) to use them in a few different jail managers easier and is also a chance for me to start getting my 10,000 lines of shell script code. I will push some changes soon, but this will give you something to play with if you’re interested.
This project does work so feel free to play around with some simple jail config scripts.
As far as ‘full install’ v ‘reinstall’, I would imagine if you had a good setup script then a reinstall would not be as fast as a fresh install. For example, for major version upgrades, you can just download a new userland, destroy your jail and make a new one with the updated userland and your setup script faster than trying to update. The fresh install method would also allow you to test/update your install script(s) and keep your outdated versions up and running as a backup. If you have at least one working version of your jail, you can roll out updated versions at your leisure.
Some applications require mounting the data after certain steps have been done inside the jail. One example is Uptime-Kuma. You need to clone the repo, then create a folder inside the cloned repo, mount it, and run the install if you want the data to be stored outside the jail. This won’t really be possible using just an install script.
I’ve now done 20 ~ ish apps, most of which I use and have tested all but 2 or so.
Photoprism can’t run on my box as I don’t have a CPU that supports AVX2.
But with time I suppose as people start using them, the issues that pop up can easily be solved.
I’m wondering if it’s better to have it all in one repo or split them out into separate ones. Right now I like the togetherness as it keeps things organized.
EDIT And they can easily be used together with any template system. Just create your template that will set your jail properties, mounts and such, then fetch and run the script.
