Warning: there may be occasional oddness due to css and blog edits. **remodel of posts done. Overhaul of pages (distilled) in progress 3/9

Friday, July 10, 2026

jail porting with sylve

Once before, in the now distant past I had used a spiffy GUIfied tool to handle jails on my FreeBSD system.  This was Warden on PC-BSD.  It was super helpful and easy to use.  Since then I have tried numerous different tools including bastille.  Of those, only bastille worked for me and was easy enough to use.  Unfortunately I never got accustomed to using it, not having used it enough.  I recently played with sylve as a tool for handling Virtual Machines in bhyve, and since it also has a jail function I have decided to test this out too.

My recent perceived finished Mudlet port seems to have developed a pile of flaws after I erased everything installed on my system when not long ago I had graphics issues.  It is because of this that I am going back to using jails for my periodic port updates if possible, and definitely when I do the initial porting.  This will ensure the option of a clean system with nothing else installed, so that I can start from zero without suffering the lack of things installed on my host system.

sylve jail setup

The setup seems very simple, there is a basic guide on the sylve site that helps to inform the user what each setting is about.  I followed it to get the initial jail setup accomplished but if I can mount my ~/GitRepos/PortsTree and possibly even use that as an overlay of the main ports tree, that would be ideal.

Click image to enlarge

When we create a jail, first from the Basic tab we choose a jail name and host name, they can be the same, and it makes sense to set 200 for the first jail ID.  From the Storage tab, we choose the host ZFS pool, and the Base we downloaded.  I could have chosen a 15.x release image "base.txz" but since there are snapshots for 15.1-stable, I chose to use that as it would be closest to what I have on my host system.  Using something nearly identical to what is on Ichigo will help me duplicate all aspects I already know, and help me find other issues that I have not yet discovered.  From the Network tab I choose Inherit, so that the jail uses the host's connectivity.  Accessing the Hardware tab lets us choose various limits, so I untick Resource limits.  I am unsure precisely what Clean Environment means, but I leave it ticked.  We also choose between Linux and FreeBSD jail type which I leave as FreeBSD because that was what I need for my purposes.  The Allowed Options dropdown includes a number of things we should tick for the jail purpose I need: Set Hostname, Raw Sockets, Mount devfs, Socket Address Families, Reserved Ports, Mount nullfs.

One thing I need to do to make use of the ports tree on the host is to null mount it within the jail.  I could set it as read-only because there are no changes I will need to make, but adding it will eliminate the need to re-create it within the jail.  The small problem is that /usr/ports/distfiles needs to be read-write, so we make the whole /usr/ports read-write.  We need to enter the jail to create the mountpoint, /usr/ports before the fstab can be successful.

Click image to enlarge

On sylve, we need to edit the fstab for the jail.  The jail I created has its name and an ID number in parenthesis, I set mine as 200 so that the ID will be distinct between VMs and Jails.  We click the jailname we gave it, underneath our hostname in the tree on the left.  Underneath the summary tab, at the bottom is options.  We click the options tab which opens a window showing property and value.  Right now there is no value for the FSTab Entries property.  We click on that line, and a new button, Edit FSTab Entries appears.  When we click on the edit button, we get an empty window with the title FSTab Entries.  Into the FSTab Entries window we type the line to add the host ports tree into the jail.

/usr/ports   /zroot/sylve/jails/200/usr/ports   nullfs   rw   0   0

Getting the nullfs mounted ports tree took me a bit of trial and error, since things are slightly different with sylve than they are for other jail managers.  I couldn't look at examples or forum posts and do the exact same thing, I had to try a couple ways to see which was successful by discovering which attempt permitted the jail to start.  Once it started I could use the console button below the summary button to verify by doing an ls of /usr/ports.

The other thing I want to do, to make things easier for myself, is to use a ports tree overlay of my ~/GitRepos/PortsTree onto the official FreeBSD ports tree.  The only time I have done this successfully was using the instructions to build xlibre the first time.  Its already been a while since I did that, but referencing the instructions at b-aaz/xlibre-ports on github, it tells me to clone that repo and enter it, then echo the pwd into the make.conf, and so to translate this to my purposes I do a little differently.

cd ~/GitRepos/PortsTree
echo "OVERLAYS=$(pwd)/" >> /etc/make.conf

This I can also do on the host in order to setup the overlay there as well.  What I am unsure about but seems likely, is that I may need to edit or remove the various directory Makefiles and the MOVED file.  Doing this in the jail will inform me about whether that is necessary.  However, to even attempt the ports overlay that I want, I will need to add two more lines to the fstab and create its mountpoint /home.

/home/tigersharke   /zroot/sylve/jails/200/home/tigersharke   nullfs   rw   0   0

One more detail that missed my recognition, we need to initialize pkg by initiating a pkg update.  Once this is done, a fetch in any of my -dev ports will succeed to register.  When I did a make config I discovered a new improvement that tripped me up some years ago.  Attempting to make config will cause bsddialog and portconfig to be installed, which otherwise would have caused the make config to fail, this was a pleasant surprise.

Working on porting

I had forgotten that I had a duplicate of yajl in the devel directory of my own PortsTree which necessarily conflicted with the official one because I didn't name it to be unique.  This didn't matter until I used my pseudo ports tree with the overlay, but now it caused unusual errors.  Easily fixed, I renamed the directory with the -dev suffix.  At the same time I renamed any extra Makefiles and the touched MOVED file with a hid- prefix.  I may not need them but I'm keeping them around for now.

When I tried to build Mudlet outside of the jail, before I set all this up, I ran into some weird errors.  It took me a while to recognize that the issue was one Mudlet dependency.  The lua-luarocks dependency is an oddity itself.  If you tick the option to use luajit instead of ordinary lua, then lua-luarocks has no flavors.  If you do not tick that option, lua-luarocks does have flavors.  This is somewhat of a concern but I am not sure how to permit either to satisfy the dependency for Mudlet.  I am going to add a note in the Makefile and use the unticked option build of lua-luarocks.

make all-depends-list | sed -e 's#^\/usr\/ports##' > all-depends
yes|pkg install `cat all-depends`

Another oddity originates from how I populated the jail.  Without anything installed, I chose to make an all-depends-list and use that to have pkg install all of those dependencies in the jail.  This greatly speeds things up but since this is an empty jail, there are more than 1000 things to install.  After all of that was installed, the build declares that I need a different port to satisfy the zip requirement, so I revised that dependency line and later, outside of the jail, it wanted to use the other zip dependency.  I decided to have both listed and let the system install whatever.  I am not sure yet if I need to have an option for whether to use zip or minizip.

The build eventually succeeded inside the jail and outside the jail, and I continued to update Mudlet for the more recent upstream commits, my own Mudlet-dev repo advancing from June 26th all the way to July 6th.

Later I adjusted the patch files with conditional wrappers and then on a whim, checked to see how many of the four patches were actually required.  What I discovered was that only one file must be patched and it needs both of the two patches within the GeyserAdjustableContainer.lua file.  I have since submitted a pull request for this patch to upstream Mudlet so that either my corrections will be applied for FreeBSD or better understanding of the issue will lead to changes which may obsolete FreeBSD specific patches for it.

After I setup git with my email and user name, I had to fix the dubious directory permission/ownership setting in git to quiet that complaint.  I had to add my github token file to my root in the jail, so I can copy and paste it, or maybe copy from outside and paste it into the console.  I also may want to eventually add any number of aliases or scripts that would make porting easier within the jail.  One thing that will be very nice is that the options for any port can be different within the jail than outside.  This means that when I rebuild luanti or mudlet for the latest commit, when I build it to use, I can leave the options set to only those that I personally need or want.  I won't need to tick and then untick for the two builds, but also there will need to be two builds because one is in the jail.  I frequently did build twice normally, so this will be a small improvement.

Sylve jail thoughts

Using sylve via librewolf is with a console screen in the browser.  This is a bit different than an xterm, the cursor is a blinking bar on the left edge of the current occupied space or character which takes a little getting used to.  Another difference is that I like to use the mouse to select and paste which is common for Unix/X but can be challenging in the sylve console.  Instead of select with one mouse button and paste with another, its select and control-v to paste.  This is functional but a little strange.  Selecting within the console can be difficult to limit to the line you desire, primarily if the line is near the bottom edge.

I had moments when sylve (or librewolf) forgot that I was typing in the console, and it took a little bit to sort of wake it up, or maybe it simply did not scroll to match what was displayed.  There is also some weirdness with how the option screen for a port configuration appears to me, a bit washed out and a kind of broken almost graph-paper appearance though all a pale blue.  I don't know why it looks like this, except that it is some kind of interpretation by either sylve or librewolf.  Its not something I could determine as able to be changed.

We can change the font size and color or background color from a gear icon in the upper right, so I chose green text on black, and size 14 font.  Closing that dialog after the change sometimes leaves it accessible, so pressing return or clicking the console could brings it back, but it is easily hidden again and doesn't appear unintentionally another time.

I figured out how to get the text in the console to have a gap between it and the bounds of the window with a little CSS but I was unable to figure out how to get the lines in the textarea to have a bit more spacing, and I have not yet checked whether I can use CSS to adjust the cursor.

.terminal-wrapper
{
    padding-left:8px;
    padding-top: 4px;
    padding-bottom: 4px;
    user-select: auto!important;
}

Sylve is definitely functional for use to setup a jail and to stop or start it, and I will be continuing to use it for that function, as well as for the virtual machine I setup previously.  I believe I can access a jail with a simple chroot into it since its localhost, so if I wanted, I could do similarly as with the VM and reach it with an ordinary xterm but with chroot instead of ssh.  Perhaps I am misremembering or it might have been a thing with Warden, so I was wrong, but it seems as though using sh is also the way to access the jail if I do not use the sylve console.

No comments:

Frequently viewed this week