You can install and run pkgs in an embedded install via unionfs_mount. I have done this for over 12 years (as of mid-2025) without any problems whatsoever. No jails or VM, and it's quick and easy to set up.

INSTRUCTIONS:

1. Choose one of your data discs (NOT system disc). Mine is /mnt/HDD.

2. Enter the following commands (change the name "extensions" to whatever you choose):

cd /mnt/HDD
mkdir extensions
mkdir extensions/usr
mkdir extensions/usr/local
mkdir extensions/var
mkdir extensions/var/db
mkdir extensions/var/db/pkg
mkdir extensions/var/cache
mkdir extensions/var/cache/pkg

1. Then go to "Command Scripts" and add the following commands in this order (all PostInit and usually the first commands). They're all important!

rsync -a /usr/local/ /mnt/HDD/extensions/usr/local/ 
mount_unionfs -o rw /mnt/HDD/extensions/usr/local/ /usr/local/
mount_unionfs -o rw /mnt/HDD/extensions/var/db/pkg /var/db/pkg
mkdir /var/cache && mkdir /var/cache/pkg
mount_unionfs -o rw /mnt/HDD/extensions/var/cache/pkg /var/cache/pkg

1. Of course, you should modify the above commands to reflect the name of your selected data disc and the name you choose for your primary directory (in my case /extensions)

2. Reboot XNAS

You should now be able to add (and later upgrade) all desired pkgs, and they will remain and operate the same as if you did a full install.

You might hear of the so-called "dangers" of unionfs_mount - THEY DON'T APPLY TO AN EMBEDDED INSTALL, which by its very nature makes it impossible to screw up your system. Should there ever be any problem installing a package(and I've never experienced any), all one has to do is disable the command script items and reboot for a "clean" install.

Each release is supported by the Security Officer for a limited time only.

The designation and expected lifetime of all currently supported branches and their respective releases are given below. The Expected EoL (end-of-life) column indicates the earliest date on which support for that branch or release will end. Please note that these dates may be pushed back if circumstances warrant it.

AB 1856 excludes open-source operating systems from the upcoming Digital Age Assurance Act.//

These amendments redefine the term “operating system provider” to exclude any person or entity that distributes an OS or application “under license terms that permit a recipient to copy, redistribute, and modify the software.” Any software distributed under the GPL, MIT, BSD, and Apache licenses satisfies that test, which removes the likes of Debian, Fedora, Ubuntu, Arch, and the BSD family from AB 1856’s scope.

Linux dominates the VPS world, and for good reason. Debian, Ubuntu, Alma, and Rocky are everywhere, well-supported, and familiar. (And yes, you can run RedHat Enterprise for free under a dev license if you want to).

Linux has a number of big advantages, but it’s not the only OS on the planet. Besides Windows, there are also the BSDs: Free, Open, and Net. I won’t get into the last two, because honestly if you want to run either of those two, you’re already thoroughly immersed in the BSDverse.

But let’s talk FreeBSD for a moment. Should you run it? There are some pros and cons.

This is the third part in our seven-part series on the BSD series of operating systems.FreeBSD is the most widely-used BSD operating system. It runs on amd64, 64-bit ARM (aarch64), i386, 32-bit ARM (armv6, armv7), RISC-V, and PowerPC. In earlier times, I thought of the three BSDs (DragonFly wasn’t around yet) as “NetBSD = runs on anything, OpenBSD = high security, FreeBSD = awesome on amd64”.

I’ve never been a big NetBSD guy. I played with it a long time ago (like 30 years ago) when I had a 68K Mac and wanted to run a Unix-like OS on it, and NetBSD was the only option. Since then I’ve fooled around with it once or twice, but I just never had a need that OpenBSD or Linux didn’t meet better.

But recently I saw that NetBSD 11 was released, and it included this brag:

New MICROVM kernel for x86, supporting both i386 and amd64, NetBSD 11.0 introduces a dedicated MICROVM kernel designed for extremely fast virtual machine boot, leveraging PVH boot, VirtIO MMIO, and multiple kernel optimizations, it can boot in about 10 ms on 2020-era x86 CPUs.

That certainly sounds cool! My home Proxmox runs on an i5-8250U which is a little earlier than that. It was released in 2017 Q3. So maybe it won’t be quite 10ms, but it should still be pretty fast. //

However, that live image doesn’t use MBR but rather GPT. So you’ll get this if you use the recipe on NetBSD’s MICROVM page.

...

At that point, I entered a ? and it gave a list of potential disk candidates. I don’t know why I remembered that trick of yore…must be some 30-year-old brain cell that didn’t expire when it was supposed to. Well you know what they say, cache expiry is the hardest problem in computer science.

Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files.
With Ventoy, you don't need to format the disk over and over, just drag-and-drop files to the USB drive and boot them directly.
You can copy many files to different folders and Ventoy will give you a boot menu to select them (screenshot).
You can also browse ISO/WIM/IMG/VHD(x)/EFI files in local disks and directly boot them.
x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, ARM64 UEFI and MIPS64EL UEFI are supported in the same way.
Most types of OS supported

The IPFIREWALL (IPFW) is a FreeBSD-sponsored firewall application. It is a stateful firewall written for the FreeBSD system and supports both IPv4 and IPv6. The IPFW is included in the basic FreeBSD installation; you just need to load the module through the '/etc/rc.conf' file to enable it.

This tutorial will show you how to set up the Basic IPFW Firewall on FreeBSD 12.0. We will first set up the firewall with the default rules provided by FreeBSD and then with a custom rule.

A celebration of the tweaks and customizations that make life easier at the CLI.

it appears that ${name}_umask will do the job. i.e. in my case syncthing_umask="0002" set in /etc/rc.conf (or /usr/local/etc/rc.conf).

FreeBSD can play not only one but three firewalls. Networking is complicated by itself and firewalls can be complex too. So when they mix together your brain may collapse. Pick up one and then learn how the networks function and later how to manipulate the firewall.  One of those three firewalls in FreeBSD is IPFW. The minimal configuration for IPFW is the one written on this article. Don’t think of this firewall as a dumb, too simple firewall solution. Mac OS X, for example, uses it and puts a nice interface in the System Settings so any noob can use it. Although nowadays it’s using another firewall PFCTL I guess it’s from the OpenBSD, it has had IPFW for many years as the default firewall. And quite frankly it has served many users pretty well.

We will edit the main os configuration file with nano.

As always under FreeBSD the /etc/rc.conf file is the one in charge to activate OS level features as well as some other important software. Type this command to set the firewall configuration into the right file:

sudo nano /etc/rc.conf

Now edit the rules so they look as follows.

firewall_enable="YES"
firewall_quiet="YES"
firewall_type="workstation"
firewall_myservices="22 80 443 10000"
firewall_allowservices="any"
firewall_logdeny="YES"

Now you must start up the service in order for the firewall to start working. Type the following order at the terminal prompt.

sudo service ipfw onestart

The numbers appearing in the line firewall_myservices=”22 80…” are the ports the firewall leaves open. The rest of the ports to your server or workstation will remain closed.

The opened ones are the basic to run a web server. Port number 22 is used for remote connections through SSH (secure shell). The number 80 is used by the HTTP protocol and since we are setting up a web server this is mandatory. Something similar happens with the port number 443 but this is the one for the https, which is the http protocol surrounded by an TLS encryption so no one can read the content in it.

Fail2ban is a complementary tool to your firewall. It works by scanning log files and bans IPs which present suspicious activity such as failed logins. It is compatible with many UNIX-like systems and is a security tool to have in your arsenal. It can filter not only ssh logins, but other services too, for example CMS web sites as WordPress or Drupal, repositories such as your own GitLab, and even your Postfix (or other) mail server.

For existing users, use the chsh command (“change shell”):

chsh -s SHELL USER
chsh -s /usr/local/bin/bash root

For future users:

Edit "/etc/pw.conf" defaultshell keywords
When use adduser(), choose necessary shell

This entry is intended to replace the default FreeBSD MTA agent with one that is easier to manage. Because of its simplicity we are going to use SSMTP as it takes very few configuration lines.

To list all installed packages in FreeBSD, you can use pkg info command.

To list all installed packages in FreeBSD that are outdated, you can use pkg version -vL=

To clean package cache in FreeBSD, you can use pkg clean command. This will remove all old and unused packages from cache.

To remove orphaned packages in FreeBSD, you can use pkg autoremove command. This will remove all packages that are no longer required by any other package.

Unix system administration commonly consists of repeating common and similar operations on different sets of targets. The notion of using, and stringing together, building block primitives such as cat, sort, strings, wc, sed and awk is a core tenet of Unix philosophy. //

By incorporating the data into the script itself, one can create powerful system administration tools, in the form of simple shell scripts, that consist merely of a single file.

The basic organization of such a script is a set of one or more data items which are commented out, as they are not actual commands, but commented in such a way that they can be distinguished from normal comments:

01: #!/bin/sh
02: #
03: # Here is the data set, and perhaps we will add some other comments here
04: #
05: ##DATA var1 var2 var3
06: ##DATA var1 var2 var3
07: ##DATA var1 var2 var3

As you can see, normal comments are commented out with one # character, but data items are commented with ##. Not only does this allow us the ability to parse through the script and easily identify which lines are data lines (as opposed to normal comments), but it also allows us to quickly disable a data line that we temporarily do not wish to use. Simply remove one of the # characters from the data line that is not to be used - it will not be parsed because it has no leading ##, but it still starts with #, and thus does not affect the script as it is still commented out.

The body of the script consists of a variable defining the path of the script itself (obviously the script needs to know the path to itself if it is to parse itself), and then a while loop that reads in every line of the script, but filters out (using grep) only those lines that are data lines, which begin with ##DATA :

08: myself=/usr/local/bin/script.sh
09:
10: while read line
11: do
12:
13:    if echo $line | grep "^##DATA"
14:    then
15:
16:      var1=`echo $line | awk '{print $2}'`
17:      var2=`echo $line | awk '{print $3}'`
18:      var3=`echo $line | awk '{print $4}'`
19:
20:      diff $var1 $var2 >> $var3
21:
22:    fi
23:
24: done < $myself

What is happening here is that the script, in line 08, defines the path to itself, and uses a "while read line" construct, the end of which in line 24 takes as input the name of the script itself. ...

The Depenguinator, version 2.0

In December 2003, I wrote a script for remotely upgrading a linux system to FreeBSD. I gave it a catchy name ("depenguinator", inspired by the "Antichickenator" in Baldur's Gate), announced it on a FreeBSD mailing list and on slashdot, and before long it was famous. Unfortunately, it didn't take long for changes in the layout of FreeBSD releases to make the depenguination script stop working; so for the past three years I have been receiving emails asking me to update it to work with newer FreeBSD releases.

A few weeks ago, Richard Bejtlich came forward with an offer to pay me to make the necessary improvements (money doesn't solve everything, but offering money certainly helps break the "I'll do it when I have some free time" / "I never have any free time" deadlock). In the end I asked him to arrange for a donation to the FreeBSD Foundation instead of paying me, but his offer was enough of a prompt for me to spend ten hours revising and testing the depenguinator.

Many computer systems around the world have been possessed by penguins; some have even been possessed by dead rats. In light of this, it is desireable to exorcize these evil spirits, and replace them with a nice, friendly daemon.
(More to the point, there are a number of dedicated server hosting companies which only offer Linux (or, in some cases, Linux and Windows); being able to remotely replace Linux with FreeBSD makes the (typically very low cost) offerings from these companies available to those who want to run FreeBSD.

I've put together some code for building a FreeBSD disk image which will boot into memory, configure the network, set a root password, and enable SSH. This can be used to "depenguinate" a Linux box, without requiring any access beyond a network connection.

The remainder of this page relates to the original (December 2003) version of my depenguinator. For a more recent version (which works with FreeBSD 7.0) see my blog post about my depenguinator version 2.0.

Welcome to the Mirror Services infrastruction site by BOINC Team Belgium. On here, you will find software mirrors of various Linux® and UNIX®-like operating systems distributions. The mirrors sync once an hour (or once per 2 hours for ISO mirros) using rsync with a Tier 0 or Tier 1 mirror

You can check the installation date of a FreeBSD server by looking at the /var/log/bsdinstall_log file, which typically contains a line indicating when the installation began.

Alternatively, you can use the command stat -f '%SB %N' / to see when the root filesystem was created, but this may not reflect the actual installation date if the system was modified later.