This project has an ambitious goal of creating a framework for writing NixOS router configurations - in other words, being the simple-nixos-mailserver of the networking world, but without the "simple" part, because networking is hard. This may include complex features like running multiple DHCP servers, using network namespaces, having interfaces turn on and off while the rest of the system keeps working, etc.
Welcome to the NixOS Router documentation. This guide will help you install, configure, and maintain your NixOS-based router.
Quick Links
- Installation Guide - Get started with installing the router
- Upgrading Guide - Learn how to upgrade your router
- Verification - Verify your router is working correctly
- WebUI Documentation - Learn about the web interface features
- Configuration - Configure all aspects of your router
My home internet connection comes with proper dual-stack support. I get a public IPv4 address via DHCP, a /128 (IA_NA) and a /48 IPv6 prefix (IA_PD) via DHCPv6.
Traditionally you would configure your networking via iproute2 and then fork-off a DHCP client to configure the external addresses.
Usually all of that is being hidden from you through wrappers (like Debian’s ifupdown). The configuration would be set, the daemons fired off and hopefully everything would go well.
The limitations of the system become visible once you have a more dynamic set of interfaces that have to be initialized in some order, some VPN device that depend on the uplink connection etc. While systems like ifupdown have employed hooks of all sorts that you still end up writing a bunch of (inlined) shell scripts that deal with some little details of your setup. Adding sleep statements at worst. Things get tricky when one interface going up changes things on another interface or even system wide (think sysctl, iptables, starting a VPN daemon, …).
I decided to switch to NixOS on my router as part of my crusade to switch most of my devices to it. So, here is how I did it! This post is more or less a raw thought stream from during the setup process. It also resembles a tutorial - that is purely because it makes it easier for me to write, this isn't really intended as a tutorial, more as an explanation of what I did - you're free to use this as reference though!
This is the second part of my journey of having NixOS based router on BananaPI R3 board (bpir3) in which I will focus more on the software side of things. The first part is here, however reading it is not essential for understanding of this part.
Before we begin I want to briefly mention that there are two different ways to have a reproducible router. The obvious one that I took is to just install NixOS there and configure it to serve as a router. The other one is to use OpenWRT, write your configuration in a declarative way and render set of uci commands to apply on an OpenWRT instance. You can read more about the second approach here: https://github.com/Mic92/dotfiles/tree/main/openwrt
WireGuard is a fast and modern VPN protocol.
It is a point-to-point VPN, which means it does not have a client-server architecture, but peers, and does not rely on a PKI, unlike OpenVPN. It is super simple to setup to connect multiple machines together.
WireGuard supports roaming, which means you can switch between network connections and not have to reconnect to your peers. On servers, it’s rarely useful, but when one of the peer is a mobile client like a laptop or a smartphone, it’s a life saver, because the usage of WireGuard is completely transparent.
I’m used to OpenVPN, I even maintain a quite popular script, but WireGuard is better in pretty much all aspects.
Für dieses Tutorial habe ich eine Installation mit Debian 11.1 (Bullseye) verwendet. Auf dem Host existieren die beiden User Alice und Bob, welche für die Nutzung von rootless-Podman vorbereitet werden.
Die Einrichtung von rootless-Podman unter Debian Bullseye
Rootless-Container haben die Eigenschaft, dass sie in User Namespaces (siehe user_namespaces(7) und namespaces(7)) ausgeführt werden. UIDs und GIDs, welche innerhalb des Containers existieren, werden dabei auf UIDs/GIDs des Hosts abgebildet. So besitzt ein Prozess, welcher innerhalb eines Containers mit der UID 0 (root) läuft, außerhalb des Containers bspw. die UID 165537 und damit die Rechte eines normalen Benutzers.
NOTE: This solution should only be used in non-production environments as a method to get familiar with Ansible. For production use, I recommend installing Ansible on a dedicated Linux server.
An automated deployment tool is a must have for any IT environment. In my lab, that’s Ansible. I’ve used Ansible in my lab to automate VM deployment/destruction, adding SSH keys for remote access to my servers, joining/leaving AD domain, and monitoring the newly deployed VMs. This is very useful as I frequently deploy/destroy VMs for testing a specific use case.
For a Windows admin, Ansible can seem daunting… For one, it runs on linux. Second, it’s based off of Python. I’m here to tell you, it’s not that difficult. In fact, did you know that Ansible is one of the few configuration management tools out there that can easily/natively use PowerShell code?
In this post, I’m going to review the steps involved in getting Ansible installed & running on Windows Server 2019. While install times may vary due to lab resources and internet speed, I’m able to complete the steps outlined below for installing Ansible in a little over 20 minutes.
I have been using the awesome window manager for 10 years. It is a tiling window manager, configurable and extendable with the Lua language. Using a general-purpose programming language to configure every aspect is a double-edged sword. Due to laziness and the apparent difficulty of adapting my configuration—about 3000 lines—to newer releases, I was stuck with the 3.4 version, whose last release is from 2013.
It was time for a rewrite. Instead, I have switched to the i3 window manager, lured by the possibility to migrate to Wayland and Sway later with minimal pain. Using an embedded interpreter for configuration is not as important to me as it was in the past: it brings both complexity and brittleness.
This Ansible playbook is meant to help you run your own Matrix homeserver, along with the various services related to that.
That is, it lets you join the Matrix network using your own @<username>:<your-domain> identifier, all hosted on your own server (see prerequisites).
We run all services in Docker containers (see the container images we use), which lets us have a predictable and up-to-date setup, across multiple supported distros (see prerequisites) and architectures (x86/amd64 being recommended).
Installation (upgrades) and some maintenance tasks are automated using Ansible (see our Ansible guide).
ifupdown-ng is a network device manager that is largely compatible with Debian ifupdown, BusyBox ifupdown and Cumulus Networks' ifupdown2.
For more information read the admin guide.
Thunderbird is the free and open source email client by Mozilla Foundation. I have been using it for some years now. Till now the Thunderbird users had to use an extension Enigmail to use GnuPG. Thunderbird 78 now uses a different implementation of OpenPGP called RNP.
Since RNP library still does not support the use of secret key on smartcards, to use Yubikey or any other GnuPG enabled smartcards, we need manually configure Thunderbird with GnuPG. The steps as said are the following :
Setting up and bootstrapping the zone catalog feature. The requierments are:
- a running knot dns server verion >= 3.0
- configured remote, acl and key sections for a primary/secondary zone transfer setup
Assumptions:
- nsp.domain.tld is the primary nameserver.
- ns1.domain.tld is the secondary nameserver
- There exist valid remote, acl and key configurations for this hosts on the other side
- special catalog zone is name "zone.catalog"
-
Create a zone template for the zones, which will be created on this zone catalog feature
- For the primary nameserver:
- id: "catalog-zone-template"
...
notify: ns1
acl: ns1
...- For the secondary nameserver:
- id: "catalog-zone-template"
...
notify: nsp
acl: nsp
... -
Create the special catalog zone for this feature
- For the primary nameserver:
zone:
- domain: "zone.catalog."
...
notify: ns1
acl: ns1
catalog-role: "interpret"
catalog-template: "catalog-zone-template"- For the secondary nameserver:
zone:
- domain: "zone.catalog."
...
notify: nsp
acl: nsp
catalog-role: "interpret"
catalog-template: "catalog-zone-template" -
Create the content for the special catalog zone. We need to have at least a SOA, NS and TXT resource record:
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog @ 60 NS nsp.REDACTED.DOM.
zone-set zone.catalog @ 60 SOA nsp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set zone.catalog version 0 TXT "2"
zone-commit zone.catalog
EOT -
Create on the primary nameserver member zone in the special catalog zone.
- Create an unique id for the first member zone:
ZUID="id-$RANDOM-$RANDOM" # generate a random id string
# ZUID="id-$(pwgen -AB 8 1)" # or other method of generating a random id string- And create this zone with the knotc command as user knot:
NEWDOMAIN="my-first-domain.invalid"
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog id-${ZUID}.zones 0 IN PTR ${NEWDOMAIN%.}.
zone-commit zone.catalog
EOT- The easy thing to oversee is ".zones" part in the in the PTR resource record.
-
Last step: Setup the new domain content.
NEWDOMAIN="my-first-domain.invalid"
cat<<EOZ | su -c /usr/bin/knotc knot
zone-begin ${NEWDOMAIN%.}
zone-set ${NEWDOMAIN%.} @ 60 SOA nshp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set ${NEWDOMAIN%.} @ 60 NS nshp.REDACTED.DOM.
zone-commit ${NEWDOMAIN%.}
EOZ -
Check this new domain content on your secondary nameserver:
NEWDOMAIN="my-first-domain.invalid"
su -c "/usr/bin/knotc zone-read ${NEWDOMAIN%.}." knot
Heute läuft der Server mit Ubuntu 20.04. Darauf laufen keine LXC/LXD Container mehr. Stattdessen läuft jetzt Kubernetes darauf. Zu Beginn nutzte ich für die Installation von Kubernetes Kubespray ein, das Standard-Kubernetes war allerdings deutlich zu fett. Größtes Manko war, dass das etcd verdammt viel auf die SSD geschrieben hat und ich regelmäßig bei jedem Upgrade das Setup kaputt gespielt habe. Für den Privatgebrauch ergab das so daher keinen Sinn.
Mittlerweile setze ich auf das vergleichsweise schlanke k3s.io. Das braucht im Heimbetrieb deutlich weniger Leistung und erledigt trotzdem das, was ich brauche. Statt etcd setzt es auf sqlite und statt Docker auf containerd.
This guide shows how to provision and manage remote Docker Hosts with Docker Machine on your OpenNebula cloud.
Mit ein paar kleinen Eingriffen in die Jitsi-Meet-Konfiguration könnt ihr die Leistung optimieren. Insbesondere Video-Konferenzen mit mehreren Teilnehmern profitieren von den Einstellungen.
Öffnet dazu die config.js-Datei von Jitsi Meet:
This article provides you a simple solution of how to setup a Kubernetes on multiple nodes using a tool called Ansible.
Documentation to set up a simple macOS VM in QEMU, accelerated by KVM.
By @FoxletFox, and the help of many others. Find this useful? You can donate on Coinbase or Paypal!.
New to macOS and KVM? Check the FAQs.
Repository with copies of my XMPP server configuration for public interest / investigation.
Notes on this setup
- Database backend: PostgreSQL
- Admin web interface and API are disabled
- In-Band registration and web registration are enabled
- Captchas enabled
- Nginx is used as HTTP / Websocket Proxy
- Port 5223 used as TLS port for "XMPP over TLS" feature (Port 443 is forwarded to 5223)