Nice little one-liner to restart all failed services on OpenBSD:

rcctl start $(rcctl ls failed | awk 'BEGIN{ORS=" "}{print}')

So I decided to give the unifi controller a shot on running on OpenBSD and most importantly the plan was to run it alongside all the other daemons on the system, so I don’t need to have a seperate VM / machine running just for the unifi controller. Spoiler: while I was able to get the unifi controller to run on my OpenBSD server I stopped the daemon right away after having all up and running. But why would I go through all the hassles just to not use it, you might ask. Well, if you are not interested about the intricacies of getting the controller up and running, just skip to the conclusion.

All commands are run as root unless otherwise specified.

Acknowledgements

The whole thing was greatly inspired by Renaud Allard’s piece

It is also possible to use the net/unifi port. But as I didn’t want to pull in the whole ports(7) tree just for one port I decided to go down my own route.

Getting all the bits and pieces

Not only do you need to Download the latest release of the UniFi Network Application (formerly known as Controller) but you also need to install MongoDB and you also need a Java Runtime not newer than 17 for the Controller to run. For the controller we create a new user (make sure to use a UID and GID > 1000 to avoid clashes with system and ports users).

At first we create a user for the UniFi Controller to use.

useradd -g =uid -m -d /var/unifi -L daemon -c 'Unifi daemon' -s /sbin/nologin _unifi

Now you need to install and setup all the dependencies for running the Controller. As you want authentication for basically everything in a mixed environment, you are also setting up MongoDB to use authentication. This also means that you need to setup MongoDB users and databases before running the Unifi controller. Java itself doesn’t need any special configuration.

You will start by installing the packages needed:

pkg_add mongodb-4.4.29 jdk-17.0.10.7.1v0 unzip
rcctl enable mongodb
rcctl start mongod
mongo --port 27017

and then …

After running into more or less the same problem every damn keycloak upgrade it’s time to put some notes into place so I won’t struggle in the future anymore. At least not with the same problem.

• Change into the root directory for keycloak

  cd /var/www
  

• Download the latest release tarball

  curl -LO https://github.com/keycloak/keycloak/releases/download/24.0.3/keycloak-24.0.3.tar.gz
  

• Change ownership

  chown _keycloak keycloak-24.0.3
  

• Read the upgrade instructions! Most of the time it boils down to

  cp -Rpv keycloak-22.0.5/{conf,providers,themes} keycloak-24.0.3/
  

  for me

• Change into the new release directory

  cd keycloak-24.0.3/
  

• Stop old keycloak

  rcctl stop keycloak
  

• This step is crucial and well hidden within the documentation of keycloak.

  JAVA_HOME=/usr/local/jdk-21 bin/kc.sh build
  

  Failing to do the build first before starting keycloak with the --optimized flag via my rc file results in an exception due to problems with the jdbc URL:

  2024-04-19 13:38:08,815 ERROR [org.keycloak.quarkus.runtime.cli.ExecutionExceptionHandler] (main) ERROR: URL format error; must be "jdbc:h2:{ {.|mem:}[name] | [file:]fileName | {tcp|ssl}:[//]server[:port][,server2[:port]]/name }[;key=value...]" but is "jdbc:postgresql://localhost:5432/keycloak" [90046-224]
  

• adjust daemon_execdir to reflect the new version in /etc/rc.d/keycloak

• Start the new keycloak

  rcctl start keycloak
  

• Clean up behind you

  rm -rd /var/www/keycloak-22.0.5
  

This is more a personal reminder than anything else. Also this expects an installation following this guide.

• stop netbox: rcctl stop netbox
• upgrade source: cd /var/www/netbox && git pull
• checkout 3.0.10: git checkout v3.0.10
• adjust upgrade.sh:

  diff --git a/upgrade.sh b/upgrade.sh
  index 67b8aaa89..0d694daf3 100755
  --- a/upgrade.sh
  +++ b/upgrade.sh
  @@ -7,7 +7,7 @@
   # Python 3.7 or later.
   #  
   #   cd "$(dirname "$0")"
   #   -VIRTUALENV="$(pwd -P)/venv"
   #   +VIRTUALENV="$(pwd -P)/env"
   #    PYTHON="${PYTHON:-python3}"
   #     
   #      # Remove the existing virtual environment (if any)
   #      @@ -20,7 +20,7 @@ else
   #       fi
   #        
   #         # Create a new virtual environment
   #         -COMMAND="${PYTHON} -m venv ${VIRTUALENV}"
   #         +COMMAND="virtualenv --system-site-packages ${VIRTUALENV}"
   #          echo "Creating a new virtual environment at ${VIRTUALENV}..."
   #           eval $COMMAND || {
   #              echo "--------------------------------------------------------------------"
  

• run upgrade script: bash upgrade.sh
• start the service: rcctl start netbox

Ever since dywis0r made me aware of netbox I was planning on getting my hands dirty with it. But only after looking loads of videos on the topic and after being `forced’ to use it at work has I been able to finally get enough momentum going to start the journey for myself.

At the beginning of it lay another topic I was successfully procrastinating since a very long time: a suffiently detailed network diagram which was both useful and pleasing to the eye. Being interested especially in isometric network diagrams I started working on that very foundation for better documentation of my home network. A journey which led me down a rabbit hole at which’s bottom I found inkscape to be the best tool available for my different needs. It’s not the most effective tool for drawing a network diagram but I had a nice produce after a steep learning curve. But this is another story.

Back to the topic at hand. After drawing the diagram and cleaning up my network from countless redesigns leaving artifacts of me learning and labbing at home I started on working on netbox. After some further research I found what I think to be a good starting point over at Jasper’s blog. I used it as a skeletton but wanted to

1. use relayd(8) instead of nginx for redirecting static content elsewhere
2. use httpd(8) instead of nginx to serve static content
3. use rc(8) instead of supervisord

in large parts due to the software already laying around and the target system already had httpd running. The architecture will more or less look like this:

Other than that you get same as with Jasper’s setup:

The following documents the steps needed to setup NetBox on OpenBSD. I am running NetBox on a PC Engines APU which holds up fairly well and I have since migrated my own setup from RackTables to NetBox, primarily because of the API functionality NetBox offers which allows for integration with SaltStack. But more on that some other …