ZFS alone is enough reason to give BSD distros a try for your server. While Linux has support for ZFS, due to complex licensing issues it’s not included in the kernel. ZFS is open source under Common Development and Distribution License (CDDL) 1.0 whereas Linux kernel is licensed under the GNU General Public License (GPL) 2.0.

This means on Linux you have to rely on Dynamic Kernel Module Support (DKMS). This works fine, but means ZFS on root for Linux could potentially break after a kernel update if the ZFS DKMS package has some incompatibility issue, or if there is manual intervention required that you happen to miss. Leaving your system unbootable, requiring a safety rescue.

Key Benefits of FreeBSD

With that said, FreeBSD defaulting to its built-in ZFS filesystem is a much more straightforward approach, and FreeBSD’s ZFS support is more mature. The kernel and base system are developed and maintained as a unified codebase, unlike Linux, which has components from various distributed sources.

This design means that all components, such as the kernel, core utilities, and system libraries are all versioned and tested together, reducing compatibility issues that can arise from independently updated packages. Upgrades are more predictable and reliable, with fewer dependencies breaking or services failing after a system update.

The benefits of ZFS are hard to ignore:

Key Benefits of ZFS on FreeBSD

1. Data Integrity: End-to-end checksumming and self-healing protect against data corruption.
2. Flexible Storage Pools: Dynamic allocation with pooled storage rather than fixed partitions.
3. Snapshots and Clones: Fast, space-efficient snapshots and writable clones for testing and backup. Robust CLI for managing pools, datasets, and replication with zfs send/receive.
4. Performance Optimization: Features like ARC caching, ZIL, and intelligent I/O improve speed.
5. Integrated RAID: Native support for mirror and RAID-Z configurations without external tools.
6. FreeBSD Integration: Full support for booting from ZFS, jails, and system utilities.
7. Compression and Deduplication: Transparent data compression and optional deduplication.
8. Copy-on-Write: Ensures consistent data at all times, simplifying snapshots and rollback.

After installing FreeBSD on my server, the first task was to organize storage using ZFS, taking advantage of its powerful features like snapshots, self-healing, and flexible datasets.

To begin, I needed to identify the available disks on the system. FreeBSD provides the geom command for this purpose:

$~ geom disk list

Geom name: ada0
Providers:
1. Name: ada0
   Mediasize: 1000204886016 (931G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   descr: ST1000DM010-2EP102
   ident: Z4A123CD
   rotationrate: 7200
   fwsectors: 63
   fwheads: 16

Geom name: ada1
Providers:
1. Name: ada1
   Mediasize: 1000204886016 (931G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e1
   descr: ST1000DM010-2EP102
   ident: Z4A456EF
   rotationrate: 7200
   fwsectors: 63
   fwheads: 16
   
...etc

With the disk layout confirmed, I proceeded to create separate ZFS pools optimized for different workloads.

Setting Up a ZFS Pool for Plex

For Plex media storage, I created a ZFS pool named zplex using two mirrored vdevs. This provides redundancy in case of disk failure, essential for protecting a large media library.

zpool create zplex mirror ada0 ada1 mirror ada2 ada3

creates a new ZFS storage pool named zplex using four disks arranged as two mirrored vdevs.

Breaking it down

• zpool create zplex Creates a new pool named zplex.

• mirror ada0 ada1 The first vdev is a mirror made from the disks ada0 and ada1. This means the data is duplicated across both drives for redundancy.

• mirror ada2 ada3 The second vdev is another mirror, using the disks ada2 and ada3.

What you end up with

You’re effectively building a pool made of four disks, grouped like this:

• Mirror 1: ada0 + ada1
• Mirror 2: ada2 + ada3

ZFS then stripes data across the two mirrors, giving you:

• Redundancy: You can lose one disk per mirror (up to two total) as long as they’re not in the same mirror.
• Performance: Read and write performance benefits from striping across both mirror vdevs.

This arrangement is commonly called a “RAID10-style” ZFS layout: mirrors for redundancy, striped for performance.

Setting Up a ZFS Datasets for Plex

Next, I created ZFS datasets for Plex and assigned them custom mount points to logically separate media content:

These ZFS commands create a set of datasets inside your zplex pool, each with its own mountpoint so they appear as separate directories on your filesystem.

Command breakdown

1. Parent Dataset

zfs create -o mountpoint=/plex zplex/plex

This creates a ZFS dataset named zplex/plex and sets its mountpoint to /plex. Once created, the directory /plex becomes backed by this dataset.

2. First Child Dataset

zfs create -o mountpoint=/plex/movies zplex/plex/movies

This creates a child dataset named zplex/plex/movies, mounted at /plex/movies. Using a separate dataset gives you independent control of snapshots, quotas, compression, and permissions for your movies library.

3. Second Child Dataset

zfs create -o mountpoint=/plex/tv zplex/plex/tv

This creates another child dataset, zplex/plex/tv, mounted at /plex/tv.

Why make separate datasets?

By splitting movies and tv into their own datasets:

• Each can have its own snapshot schedule
• You can apply different quotas or compression settings
• Permissions can be delegated more cleanly
• Plex libraries stay neatly organized at the filesystem level
• ZFS manages each dataset independently

This structure not only helps with organization but also allows for dataset-specific settings like compression or quotas in the future.

Preparing Encrypted Storage for Jails

To host applications in FreeBSD jails, such as Git and Nextcloud, I created a separate ZFS pool named zstor using a mirrored configuration for redundancy:

zpool create zstor mirror ada4 ada5

For sensitive data, encryption is a must. ZFS’s native encryption makes this straightforward. I created encrypted and compressed datasets for Git and Nextcloud:

These commands create encrypted ZFS datasets for storing application data, each with its own mountpoint and compression enabled.

Command breakdown

Both commands follow the same pattern:

• zfs create – creates a new dataset.
• -o encryption=on – enables native ZFS encryption for the dataset.
• -o keyformat=passphrase – specifies that the encryption key will be a human-entered passphrase rather than a raw key file.
• -o keylocation=prompt – ZFS should ask you for the passphrase whenever the dataset is unlocked.
• -o compress=lz4 – turns on lz4 compression, giving good performance with automatic space savings.
• -o mountpoint=… – sets the directory where the dataset will be mounted.

1. Git dataset

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt \
           -o compress=lz4 -o mountpoint=/git zstor/git

This creates an encrypted dataset named zstor/git, mounted at /git. It’s ideal for storing private Git repositories or anything that requires an encrypted filesystem.

2. Nextcloud dataset

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt \
           -o compress=lz4 -o mountpoint=/nextcloud zstor/nextcloud

This creates a second encrypted dataset, zstor/nextcloud, mounted at /nextcloud, suitable for storing synced files, user data, and application content for a Nextcloud instance.

Why encrypted datasets?

Using encrypted datasets for Git and Nextcloud gives you:

• At-rest encryption handled natively by ZFS
• Clean separation between datasets
• Independent passphrases or unlock procedures
• Automatic compression to save space
• Flexibility to snapshot, clone, and replicate each dataset separately

With this layout, each jail has its own secure dataset, giving me fine-grained control, flexibility, and peace of mind—all integrated into FreeBSD’s native toolset.

Drive replacement

What good is a RAID setup if you can’t easily replace and recover from failed disks?

Not long after setting up my ZFS pool, I encountered a disk failure in the zplex pool. Fortunately, ZFS makes identifying and replacing failed drives straightforward. The first indication of a problem came from checking the pool’s health:

zpool status zplex

This command reports the status of each vdev and displays any errors or degraded conditions. In my case, one of the disks showed a status like:

NAME                        STATE     READ WRITE CKSUM
zplex                       DEGRADED     0     0     0
  mirror-0                  ONLINE       0     0     0
    ada0                    ONLINE       0     0     0
    ada1                    ONLINE       0     0     0
  mirror-1                  DEGRADED     0     0     0
    ada2                    ONLINE       0     0     0
    13095480495471608692    FAULTED      0     0     0

The long numeric value (13095480495471608692) identifies the failed disk. To find its physical device name prior to replacement, I used the following command:

geom disk list

Once the replacement disk was installed and recognized by the system (in this case as /dev/ada3), I instructed ZFS to begin the replacement:

zpool replace zplex 13095480495471608692 /dev/ada3

ZFS immediately began resilvering—rebuilding data on the new disk based on the surviving mirror. You can monitor the progress:

zpool status zplex

Example:

  pool: zplex
 state: ONLINE
  scan: resilver in progress since Tue Nov 19 10:42:03 2025
        150G scanned at 1.25G/s, 82G issued at 680M/s, 500G total
        82G resilvered, 16.4% done, 0h58m to go
config:

        NAME                       STATE     READ WRITE CKSUM
        zplex                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            ada0                   ONLINE       0     0     0
            ada1                   ONLINE       0     0     0
          mirror-1                 ONLINE       0     0     0
            ada2                   ONLINE       0     0     0
            replacing-2            ONLINE       0     0     0
              13095480495471608692 ONLINE       0     0     0  (old)
              ada3                 ONLINE       0     0     0  (resilvering)

errors: No known data errors

With minimal intervention and no downtime for media playback, the pool was back to a healthy state. This experience reinforced one of the strengths of ZFS: robust handling of hardware failures with clear diagnostics and built-in resiliency.

Conclusion

Building a solid storage foundation is the most critical step in creating a reliable homelab server, and this article demonstrates why FreeBSD with ZFS is an exceptional choice for the task. We’ve walked through the practical steps of creating distinct ZFS pools for different needs: a resilient, RAID10-style pool for our large Plex media library, and a separate, encrypted pool to securely house sensitive application data.

By leveraging ZFS datasets, we’ve not only organized our file systems logically for movies and TV shows but also enabled fine-grained control for future management. The real-world scenario of a disk failure underscored the power of ZFS, showcasing how easily a faulty drive can be identified, replaced, and resilvered without any data loss or significant downtime.

With a robust, self-healing, and secure storage backend now in place, our FreeBSD server is fully prepared for the next stage: deploying Plex and other services within isolated Jails. The initial setup proves that with ZFS, you get more than just storage, you get a professional-grade data management system that provides performance, flexibility, and peace of mind.

What is it?

Kubernetes Convention is the premier expo for everything k8s, that is put on several times per year by the Cloud native Computing Foundation

My time there

I went to Kubecon Europe in London this year and had a blast absorbing all of the content. It’s easy to live in a bubble within your day job and miss out on some of the cool developments in technology.

I would definitely recommend Kubecon to anyone that works with Kubernetes. Not only do you get awesome talks and panels, but you can browse the showroom floor for k8s related projects and services.

Below I’ll link to some cool talks and their slideshows, but before that I’ll hit a few key points that I thought were most interesting.

Cool Notes

• The paradigm for k8s clusters is to favor multiple smaller clusters versus fewer larger clusters. Tools like Cluster API make it easy to manage numerous clusters. Small clusters are easier to upgrade as there is less chances for upgrades to have detrimental effects on running applications.
• Companies are utilizing components of k8s to do cool stuff
  • Metal3 and kubenet to provision physical hardware and devices
    • Use the reconciliation and scheduling components of k8s to configure and deploy hardware
  • Edge devices with kops to test algae in the ocean
• Kubernetes API Aggregation Layer can be used as an alternative/supplement to CRDs when you need to bypass the limitations of ETCD and utilize another database.
  • Kueue bypassed k8s object size limitation in ETCD and instead stores objects in Redis
• eBPF is the future, made easy by bpftime
• LLM/AI workflows work well in a k8s native environment
  • Kubeflow
  • Ray

Takeaways

Below is a some quick points I gathered from most of the talks.

• General

  • COTS vs Build

  • Commercial-off-the-shelf (COTS) comes up a lot in talks when it comes to DevOps and SRE teams.
    • Small organizations can get away with COTS since their limited footprint makes it easier to migrate to a home grown solution

  • COTS

    • In some cases, allows you to quickly get started. Provides mostly complete turnkey solution
    • Avoid COTS where possible, some solutions lack OSS solutions (Finance, HR, etc)
    • COTS creates vendor and data lock, perpetual costs
    • Still requires development

  • Build

    • Requires investment in hiring talent
    • Allows the most flexibility and control

• AI Agents

  • Incorporating AI for Operations is harder than regular operations

  • Potential use cases

    • Code review
      • On Git pushes can check for common mistakes
    • Run unit tests
    • IaC integration
      • Can determine which use 3rd party tools to test deploy infra and verify changes
    • Create PR’s, write documentation on changes

  • Challenges

    • LLMs are notoriosly unpredictable
    • While deploying, difficult to monitor
      • Monitoring which prompts provided bad output, determining which workflow

  • Solutions

  • LLM Guardrails
    • Slideshow
    • YouTube Talk

Background

Setting up FreeIPA can be tedious and a chore. There are official FreeIPA Ansible Roles that you can leverage, and I decided to base a project around them to get you up and running with a baseline configuration that only requires editing a few configuration variables.

FreeIPA (Identity, Policy, and Audit) is an open-source identity management solution designed for Linux and Unix systems. It provides centralized authentication, access control, and auditing capabilities, making it easier to manage user identities, roles, and permissions across a network of systems. FreeIPA combines several technologies, such as LDAP (Lightweight Directory Access Protocol), Kerberos, DNS, and a certificate authority, to create an integrated identity and security management platform.

FreeIPA is an open-source alternative to Microsoft’s Active Directory that’s tailored specifically for Linux and Unix environments. It simplifies the management of users, groups, hosts, and access policies through a unified web interface, command-line tools, and robust APIs.

Usecase

Currently, my main use case is providing centralized ssh access to a slew of servers I may deploy and destroy for development, or some that I may have up in production.

• Avoid creating local admin users on every server
• Create service accounts for automation to use across servers with RBAC or HBAC
• Manager user groups
• Passwordless ssh authentication
• Support SSO sign-in for applications that support it
• Create Certificate authority to self-sign TLS certificates and distribute them
• Run your own DNS server to add private local domains

If you’re on-prem, you can run FreeIPA in a VM, same as if you’re in the cloud or hybrid environment.

Notes

FreeIPA has a robust web UI and API. Ideally, you’d want to restrict management access of FreeIPA to a private network. For example, on-prem FreeIPA can run in a VM with only a local private IP address. Clients on the same network can join the domain with no special configuration. For hybrid environments, you can use a VPN so that clients in the cloud can still join the domain.

DNS is important when dealing with FreeIPA, the basis of a FreeIPA cluster is the Realm (IPA1.EXAMPLE.NET) and primary DNS domain name (ipa1.example.net). You can join clients from separate domains to a single Realm.

Luckily, you do not need to purchase a domain name. You can instead use a valid local network domain. Technically, any TLD can be used locally if you run your own DNS, but the better question is should you?

You want to avoid conflicts, and for most of modern history, enterprises and home networks have used domains that ended in .local, .lan, .home, etc. However, according to ICANN such a free-for-all can lead to unintended side-effects and conflicts, such as what has been documented regarding using .local

Because of this, ICANN has proposed using .internal for use in private networks. For that reason, I would suggest using .internal if you’re not going to purchase a dedicated commercial TLD.

You will be running our own DNS server that comes with FreeIPA, and can set private domains there.

The GitLab project ReadMe with thorough documentation on the Ansible playbooks used, but a few minor points I wanted to elaborate on.

You will also be adding the FreeIPA Server (and any Replicas) domain to the /etc/hosts of all clients. This is for two reasons:

1. The clients need to connect to the FreeIPA server before it can have its DNS resolver settings updated
2. You still want to be able to use FreeIPA in case of total DNS server failure.

As I have mentioned in the ReadMe, when running your own DNS FreeIPA uses BIND9, and the recommended security configuration is to only allow recursion from IP addresses explicitly set in a trusted_network ACL configuration. For this, you will want to plan out IP addresses of clients so that you can whitelist CIDR ranges.

The playbooks are based around the official FreeIPA Ansible Role. I use JSON files to define Groups and Users that will be added to said Groups. Refer to the official documentation on Users and Groups to flesh out configuration depending upon your needs.

Conclusion

The project should be a good starting point for setting up FreeIPA. You will want to tune and customize it to your needs, but it should be a good starting point.

I recently built a 3 week long trip to Spain and Portugal around DevOps Barcelona and thought I would share my experiences traveling with tech related gear. It can be a bit daunting traveling internationally, especially given all the work involved with moving around between multiple locations.

In this article, I’ll go over some of the important electronics I think you should consider. Since everyone will likely have a cell phone, I want to start with getting a cheap and fast data plan.

eSIM

I think the most common question people generally have is how will their mobile phone coverage work in a foreign country. For most US cellular providers, it will fall into two main categories with the key distinction being data.

1. Your provider will give you “unlimited” data, but throttle it to a slow speed (~256Kbps)
2. You provider will give you “unlimited” data, but charge roaming data fees

In both cases, you will likely get free SMS, and have calls at ~$0.20/min. Having your speed throttled may not seem like a big deal, but it is noticeably slower when even grabbing an Uber.

The standard solution is to purchase an electronic SIM (eSIM) from a 3rd party that has coverage in your destination area. It will generally be much cheaper than paying roaming fees, and more cost effective than purchasing a temporary international package through your provider.

There are several reputable eSIM providers, you can search reddit for recommendations. I personally used MobiMatters with great success.

Steps eSIM

Purchasing the eSIM is simple. You pick your destination, length of time eSIM will be used, and the data transfer limit.

Since I was traveling between two EU countries, I picked a “Europe” eSIM. 30 days validity, and 15GB of data. Note, these particular SIMs do not come with a phone number, more on that later.

You will receive a QR code, along with the hardcoded IMEI and other network information included in the QR Code.

Setting up the eSIM

• Samsung Galaxy Z Flip6

Fun fact, the Sparks eSIM works in the USA, so you can ensure it works before even traveling to Europe.

Mobimatters does not require any special application. As with all eSIMs, your phone just needs to support eSIMs, which should be the case for all modern cell phones. The steps for activating and using the eSIM depends on your specific phone make and model.

The steps outlined here will refer to Android phones version 14+, more specifically the Samsung Flip6.

No app required, go to Settings » SIM Manager. You should see a plus (+) sign to add an eSIM. You can simply scan the QR Code you received from your purchase.

The eSIM should be added in an inactive state.

Activating eSIM

This step varies by your specific Android device. For my Samsung Flip6, you have a primary SIM, and alternate SIMs. Each time you make a call, or send a SMS/MMS in the Phone app it defaults to primary SIM, but you can select an alternative SIM. This option appears for every message and call, and can be changed back and forth.

The key here is that data will go through the Primary SIM. So for us, you want to set your eSIM as the primary SIM. This way, the eSIM will always be used for cellular data.

So how will you receive phone calls and SMS/MMS if our primary SIM is set to an eSIM which does not have a phone number?

The neat feature in Android phones is you can have dual Active/Active SIMs. So even though our eSIM does not have a phone number, your regular SIM (set as non-primary) will still receive calls and SMS/MMS as normal. You will actually see two cell signals at the top right of the screen, since the SIMs may be on different networks at the same time.

Important note, you will want to enable roaming on the eSIM to connect to the best network. No worries, there are no roaming charges with the eSIM.

Also note, I set roaming on my regular physical SIM for the same reason, even though it’s not used for data.

Motorola Razr

My wife has a Motorola Razr 2024, and the eSIM instructions are a bit different. You scan as normal, but you actually do not configure a primary or alternate SIM.

In the SIM manager, you explicitly set which SIM you want to use for Data, calls, and SMS/MMS for the entire phone. In my opinion this is a much more straightforward configuration setup.

Travel Router

• GL.iNet GL-A1300 Pocket VPN Travel Router. link

We had several phones, laptops, and tablets we wanted to use on Hotel wifi. So I thought it would be a good idea to purchase a router to help centralize management of wifi (and hardwired) internet connections in hotels.

Added benefit is this router is packed with features, such as the ability to configure OpenVPN and Wireguard VPN, along with built-in support for several 3rd party VPN providers.

The traditional wisdom is to always use a VPN when using hotel wifi, even if you did not require access to a private network. This was true years ago, but these days every serious website uses TLS encryption (HTTPS everywhere), so the risk of MITM and other snooping attacks is extremely low.

If you don’t intend on using a VPN (I didn’t for this trip) and want added security, you can avoid using hotel’s DNS by using the built-in AdGuard DNS

This little router has AdGuard and AdGuard DNS built-in. If you’re familiar with Pi-Hole, it has similar functionality. You get to block harmful and annoying tracking and ad serving endpoints while also avoiding going through unknown DNS servers.

Setting up

I didn’t do any configuring of the router until I got to my first hotel. The setup instructions are pretty typical of any other router. For my model I connected my laptop via ethernet to one of the LAN ports and hit https://192.168.8.1/ to do the initial configuration to set an admin password.

Note: this runs a self-signed TLS certificate, so your browser is not going to trust it by default and complain about it not being “secure”. But it is, in fact a secure TLS certificate

What’s different is configuring it to use the hotel’s WIFI so that it can act as a Repeater for your other devices. It’s still simple, in the admin console go to “Internet” and select the WIFI network to connect to.

When you connect, it will likely require a prompt to login via a browser. If so you will shortly see a web browser popup and/or link requiring you to login just as you normally would if connecting your phone or laptop directly to the wifi.

This login authentication will suffice so that all of your devices can connect to the router and use the internet.

If your hotel room has a hardwired ethernet port, you can simply connect it to the WAN port on the router and no authentication or configuration is required.

Some considerations

Most of the hotels worked fine, but a couple of them had strange wifi setups.

One hotel which has unencrypted/open WIFI, would immediately kick the router from the network. I did not have time to investigate the reason or fix for this, so I was not able to use the router in this hotel.

Another hotel would require a new signup/authentication every morning. Not too much of a hassle and I was able to still use the router fine. Just something to note.

Other accessories

Portable disk drive

• SanDisk Portable SSD. link

I always bring an encrypted Sandisk portable drive with me where I store Keepass vaults, ssh keys and other files.

Since I use Linux exclusively I use LUKS to encrypt the drive with an ext4 filesystem.

Instructions for LUKS

• Encrypting an External Drive

European Power adapters

US uses 120V for most electrical devices While the EU uses 220V for most electrical devices.

You will need to use some sort of adapter to plug your electronics into hotels, trains, cafes etc.

What I use:

• TESSAN European Travel Adapter(US To EU) With USB Ports, to Most of Europe, Iceland Spain Italy France Germany. link

• OREI American USA To European Plug Adapter – Type E/F Schuko Plug Adapter. link

Conclusion

I’ve covered the most important tech devices and configuration I use when I travel. In part two of this series, I will go over some of the apps I used to travel between different cities along with other tips I think are important.

ZFS

FreeBSD’s default filesystem is ZFS. This means ZFS on FreeBSD is baked right in and well documented. ZFS has been the best thing to happen for system administrators since containers. ZFS isn’t just a filesystem, it’s also a volume manager and elimiates the need for things like LVM (and as you’ll soon see, the need for seperate software RAID).

Jails

Thick Jails in BSD predate Docker containers, and jail management built right into the kernel. Even though you can manage jails without any extra software, we’re going to use a dedicated jail manager tool to make life simiplier. Jails can give you the flexibility of docker/podman containers with less overhead.

Jails can also run versions older than the hosts. For example, your host can be FreeBSD 14.0, while you can leave some jails on older, FreeBSD 13.

Ports and Pkg

In FreeBSD land, the “base” packages are managed seperately from user-installed packages. freebsd-update fetch install && pkg update && pkg upgrade respectively. I think this makes for an easier to manage server system where you have more control over software updates.

You can also downgrade, so if you upgrade to a new FreeBSD major or minor release, and find something doesn’t work correctly, you can revert back to the previous version.

Goals

Software

Plex

The reason I started building this server in the first place was to have a semi-dedicated place to store and stream my digital media. So most of the design choices revovled around utilizing Plex. Some people have had a fallen out with Plex as they are moving to become more of a Netflix-style platform integrating with self-hosted media.

Plex is the only self-hosted media solution that officially supports FreeBSD. Jellyfin exists, but there is no official Jellyfin support, and at the time of me building this server Jellyfin had mixed reviews on reliability.

Nextcloud

Nextcloud had been around for ages and is very mature as a self-hosted content platform. Was an obvious choice.

Gogs

I wanted to have my local Git repo be my main repo for private projects and Yadm dotfiles storage. Gogs offers a nice and simple web UI that’s easy to install and maintain.

Hardware

CPU

This is actually a debated issue for the simple fact that ECC RAM is specifically useful for ZFS pools. But the consumer Intel chips do not have any motherboards that support ECC RAM. You’d have to go with either a server or workstation chasis and motherboards, which will increase the cost several hundred dollars. While AMD has consumer-grade motherboards that support ECC.

When designing my system, Plex supported FreeBSD Intel Hardware Transcoding. However, as of May 2023, Plex has removed Intel hardware transcoding. This means you will have to setup a Docker Container running Linux, or wait for the two Pull requests to be merged to bring back native FreeBSD support. With that said, had I known about this before designing my system, I may have went with AMD to run ECC RAM.

There’s nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. Since ECC-RAM is not a hard requirement, I went with:

• Intel Core i7-12700K

RAM

• Crucial Pro 32GB (2 x 16GB) DDR4 3200

Room to upgrade to 64GB in the future

MOBO

• ASRock Z690 Pro RS LGA 1700

I wanted something with enough M.2 slots to run two in a mirrored vdev without taking away lanes with a SATA port. This one has 3x M.2 slots, but the 2nd middle slot if used will disable one of the onboard SATA ports. This is fine for me as I do not intend on using all three.

6x SATA ports is fine to start, you can upgrade with an PCI-E 3.0 HBA to add more drives later.

Every other feature is standard and not something you have to go out of your way to look for.

Storage

The bulk of my money was spent on HDDs and SDDs.

Boot/OS

• 2x 1TB NVMe SSD PCIE link

Running in a mirrored vdev so the total usable space will be ~1TB. Enough to run the OS and user-installed packages without worrying about disk space.

Jail Storage

I wanted all of the Jails running on seperate pools and seperate physical disks than the OS.

• 2x 1TB SATA SSDlink

Mirroed vdev pool so total space will be 1TB. Though I don’t expect much actual storage needed by jails, in hindsight I probably should have opted for double the space just to be on the safe side.

NAS Storage

Most of the storage is packed into large HDDs to hold the actual video media files. I wanted to maximize physical bay space by picking relatively large drivers (14TB+) and cheap price per TB. I researched a popular HDD seller that sold factory recertified disk drives. I felt confident given the track record, and the fact that the majority of the video files can be recovered from remote sources and the setup with ZFS will add redundancy and error checking.

• 4x 16TB Seagate EXOS X16 HDDs

2 seperate mirrored vdevs equals 32TB of total usable space.

FreeBSD Install

The FreeBSD Handbook has details on installing in Chapter 2. Complete with screenshots and important notes. However, if you’ve installed Linux before, it’s not much different.

Creating Install Media

I use a simple USB drive to install operating systems these days. So I downloaded the FreeBSD-14.0-RELEASE-amd64-memstick.img.xz which can be found in the ISO Images download site.

Using Etcher I flashed it to the USB drive. But of course you can just use any other method.

UEFI setup

Before I install, I like to disable SecureBoot since this system will not have windows installed, and FreeBSD does not support SecureBoot.

Components

The key being that it defaults to selecting debugging packages, which you likely won’t need for such a system. These are the Components I installed, but remember, these can always be installed or removed later, so it’s not that big a deal.

• lib32
• ports

Partitioning

Using guided root-on-ZFS is the simplest route. For Install, select the two boot drives, in my case the two NVMe devices.

• Pool Type: mirrored
• Pool Name: zroot (can be any arbitrary)
• Force 4k Sectors: Yes
• Encrypt Disks: No (I will be encrypting drives I use for Jails that store actual data, and won’t be using geli)
• Partition Scheme: GPT (UEFI)
• Swap Size: 16g, this setting is always debated. Old wisdom, even mentioned in the FreeBSD handbook says to use double the amount of RAM. However, this rule of thumb existed before systems came with as much RAM as they do now.
• Mirror Swap: No
• Encrypt Swap: No

Network Installation

The NIC on my Motherboard is a Dragon RTL8125BG, which is just Realtek RTL8125BG chipset. The install did not recongnize my network card, so I had to skip the network setup portion of my install. This means out of the box the machine won’t have LAN/WAN connectivity. I will show you how to install the drivers and configure networking at the end of this article. But for now just skip the network setup, and make sure you to keep your keyboard and monitor handy.

System Config

I selected:

• sshd
• ntpd
• ntpd_sync_on_start
• dumpdev

System Hardening

I skipped this section as I will configure this manually later, after the install.

Add Users

By default there is just a root account. I like to use sudo with a regular account. So you can create that account here now, or later.

Remaining Install

The rest of the install should be self-explanatory.

Network Interface Card (NIC) driver install

Since the installer did not reconginze my NIC, I had to manually install the drivers. This takes a bit of work, as you have to get the driver on the system in the first place.

Spare USB drive

You can use any USB drive formatted in FAT32.

Packages Required

You will need the following two packages

1. Realtek-re-kmod Kernel driver for Realtek PCIe Ethernet Controllers (found here)
2. pkg - Package manager (found here)

Pkg is the package management tool FreeBSD uses to install binary packages. It wasn’t installed in my case during the OS installation, and we’re going to use it to get the Realtek kernel driver installed.

Prepare USB

Copy over the pkg files to a USB drive formatted in FAT32 and plug it into our FreeBSD machine.

Mount Drive

When you insert the USB drive it won’t mount automatically. But you should see it in /dev folder.

ls /dev/da* should show /dev/da0s1 listed after you insert the USB drive, which you can then mount.

[~/]$ mkdir /media/usb
[~/]$ mount_msdosfs /dev/da0s1 /media/usb

Move the two .pkg files you place on the drive to any folder on the host. cp /media/usb/* /tmp/

Install Packages

The files are really XZ compressed TAR file (.txz) files. You’ll need to decompress the pkg package in order to bootstrap the package management in order to install the drivers.

The pkg-VERSION.pkg file has a full path to a binary called pkg-static, which you will use to install itself. Then install the realtek drivers.

[/tmp]$ tar xf pkg-VERSION.pkg
[/tmp]$ usr/local/sbin/pkg-static add pkg-VERSION.pkg
[/tmp]$ pkg add realtek-re-kmod-VERSION.pkg

Configure Networking

After the driver is installed. We simply have to add a line to the /etc/rc.conf file

ifconfig_re0="DHCP"

After that you can restart networking, manually bring up the interface or restart the server.

Manually bring up interface

[/tmp]$ ifconfig re0 up

Configuring a simple dynamic IP address to get it started, which can be setup with static later.

Next Steps

With the system setup, we can start adding ZFS pools for both Jail and Media storage. I’ll go over this in Part 2 of this series.

Background

If you want a mobile and more secure way to manage your SSH and GPG keys, one route you can take is leveraging hardware keys. The Nitrokey 3C acts as an MFA device, but it also has the ability to store keys commonly used for SSH authentication. One of the main benefits of storing your private keys on a secure hardware device is they’re never loaded into your computer’s RAM. The cryptographic operations are performed on the device’s firmware itself, meaning you’re protected from any malware attacks that could attempt to steal your private keys.

All of Nitrokey’s products are open-source and the Nitrokey 3C has firmware written in Rust. I have FIDO2 which I use for MFA for website logins and the 3C which is their newer product line that I received not too long ago. This is what I will be using for this blog post, though this guide should work for most other OpenPGP compatible hardware devices since we’re just using OpenGP.

The latest firmware at the time of this writing is v1.5.0 and it supports everything you need to use the keys stored on the device to SSH into Linux servers.

Prerequestites

• Nitrokey 3c
• Firmware v.1.5.0 or higher
• GPG v2.2.6 or higher

Creating Keys

If you already have keys, you can skip this section.

Run gpg2 --card-status to make sure your NitroKey shows up. If it doesn’t you may need to add the udev rules found in the Troubleshooting section of this post.

Run gpg2 --card-edit which will put you to the gpg prompt

Enter admin, then enter generate

It will ask you for the Admin PIN (default: 12345678), then ask for the PIN (default: 123456).

When it asks you to make an off-card backup of the encryption key, note it will only backup the encryption key, and not the whole key set. So the best option is to select No. If you want to make a full backup, follow these instructions.

Afterward, it will take some time, but it will generate the whole key set (Signature Key, Encryption Key, Authentication Key)

Note the “Authentication key”, as this is the key that will be used for the Linux server.

Copy Authentication Public key

Export the public key in ssh format. I like to place it in the .ssh folder so I can copy it to servers later.

gpg2 --export-ssh-key AUTH_KEY_ID > ~/.ssh/nitrossh.pub

You can use ssh-copy-id to send it to the server under the user you want to access.

ssh-copy-id -f -i ~/.ssh/nitrossh.pub -o 'IdentityFile test123.pem' youruser@example.net

Alternative

If you need to use a server key not in a keyring, such as the case with AWS EC2 nodes by default, use the -o flag and set the “IdentityFile” to the key you currently use to login

ssh-copy-id -f -i ~/.ssh/nitrossh.pub -o 'IdentityFile test123.pem' ec2-user@ec2-34-333-22-11.compute-1.amazonaws.com

Load Agent

Next you need to setup the GPG agent to interact with your SSH agent. There are a few configuration files that need to be in play, so I’ve created a GitHub repository with them.

Make sure you have an instance of ssh-agent running in your current terminal/shell.

eval $(ssh-agent)

You can source the bash file that sets the gpgagent environment variables and configuration required.

source nitrokey.sh

Logging in

Afterward, you should see the Authentication key stored on the Nitrokey loaded into the SSH agent.

ssh-add -L

You should see something like the following:

ssh-rsa LONGKEYHERE cardno:000F D51E28ED

You should be able to login to the server

Troubleshooting

GPG Agent cannot see card

If executing gpg2 --card-edit or gpg2 --card-status as a non-privileged user gives an error that the card cannot be found or opened. It is likely that the daemon responsible for handling smart cards is not running.

If you are using PC Smart Card Daemon, make sure it’s running.

systemctl status pcscd.service

The Arch documentation has good information on this issue

Getting Started

The following sections will briefly go over code and is meant to be read while viewing the code on the GitHub.

• GitHub: ecs-dynamodb-cdk-sampleapp

app.py

Just like the code from the previous, we start with the main point of entry, the app.py file.

The Props Dictionary holds some of the common values we’ll make use in the code that does the heavy lifting. Something new here is the introduction of runtime contexts to pass two account-specific values, noted by the -c VAR flag.. You could use dotenvs, but I wanted to show more CDK concepts this time.

DynamoDBStack

The DynamoDB is setup first, but the two stacks are not dependent upon each other and can swap places in order.

The prepare_import_data function highlights one of the main benefits of using CDK over CloudFormation, or even Terraform. This is a custom function I’ve created to handle importing data from CSV files (located in ./data) and bringing it into the DynamoDB tables that will be created later. You can obviously create functions or classes to handle anything you can imagine.

Digging deeper into this function, we’re formatting the data for PutRequest, a DynamoDB data type that will be used in an API call in this stack.

There are three tables being created: “Resource”, “Category”, and “Bookmark”. The Resource table has an added Global Secondary Index.

A cool feature of CDK is the ability to create custom resources which are AWS Lambda-backed functions. This function will load our BatchWriteItem API call to a short-lived Lambda function that will be responsible for actually making the API request to the DynamoDB table. We don’t have to worry about creating and managing a Lambda function.

The props.copy() is going to copy the props Dictionary we passed to it from app.py and copy it, combining any additions you might add to it so it can be passed to another stack. In this case, looking at app.py we pass this to the ECSStack.

ECSStack

While this stack is the bulk of our infrastructure, ironically it has fewer lines of code than the DynamoDB stack.

The VPC is created, and that’s all we really need to do in terms of our VPC configuration. The Fargate construct will create nearly everything else for us.

The construct for creating the ECS Cluster object is straightforward.

We have to create a Task Execution Role, so using the Role construct and giving it the correct service principal. This is so the AmazonEC2ContainerRegistryReadOnly managed role can get attached to it. Allows the task to pull from an ECR registry on launch if needed.

The ecs_patterns is a high-level construct library, and it will require less code to accomplish what we need. This particular code creates the service which will be underneath the cluster that will be created. This service will have an Application Load Balancer created with the target group being the service and its tasks. The image in this example is an image from Docker Hub, but it can be from any Docker registry, including ECR. There are also example environmental variables set, and Docker labels for the sake of example.

Since the Fargate construct created the security group, we use the object holding it to modify the ingress rule for the Security Group associated with the ECS Service. The SG for the ECS Service will allow port 8080 from the ELB and the CIDR 10.0.0.0/16. The ELB will use a default rule on port 80 from 0.0.0.0/0.

The db_stack object was passed from the DynamoDB stack through the main app.py to this ECSStack so that we can modify the Fargate task role to allow access to the DynamoDB Tables created in the previous stack.

Putting it all together

The last part simply prints the load balancer DNS to the terminal.

cdk deploy --all -c account_id="111111111111" -c preferred_region="us-east-2"

Why Contexts

The CDK Documentation recommends for production stacks to explicitly specify the environment (Account no. & Region) for each stack in your app using the env property.

Instead of hardcoding the values, I opted to use runtime contexts as mentioned earlier.

Found in app.py:

preferred_region = app.node.try_get_context("preferred_region")
account_id = app.node.try_get_context("account_id")
env = core.Environment(region=preferred_region, account=account_id)

Defined just below:

db_stack = DynamoDBStack(app, f"{props['namespace']}-Dynamo",props,env=env)
ecs_stack = ECSStack(app, f"{props['namespace']}-ECS",db_stack.output_props, db_stack=db_stack, env=env)

Conclusion

After this, you will have an ECS Fargate service setup behind an Application Load Balancer. The ALB will be setup as you expected, forwarding traffic on the ports you specified, and performing health checks on the traffic port (8080).

The ECR repository can easily be replaced by a DockerHub registry, or any supported image repository. There’s obviously a lot more you can do here, but I think this is a good start.

Background

When developing an application that you want to get deployed to the cloud quickly, one option would be to use Elastic Beanstalk. The Beanstalk platform handles your deployment’s provisioning, load balancing, scaling, and application health monitoring.

There may be other services you’re interested in stacking, such as RDS or an Elastic Load Balancer. Since you’re developing this stack on AWS, and will likely transition away from Beanstalk in the future for production, it would be good practice to get started with the Cloud Development Kit (CDK). This way you will have a good foundation for developing and deploying a wide range of services on AWS.

Cloud Development Kit (CDK)

CDK is an open-source software development framework to define your cloud application resources using popular programming languages, such as Python, Go, and Java. You define your architecture in your favorite programming languages, and the CDK engine outputs, or synthesizes your code to Cloudformation templates. You get the best of both worlds.

You get to benefit from the programming language’s expressive nature and functionality, such as objects, loops, and conditions. If your application were written in Python, it would make sense to write your CDK constructs in Python. This way you could integrate Python classes created for your application into your CDK application code to help bootstrap the application for deployment.

You also have the benefit of being able to version control your CDK code, just as you would if writing Cloudformation templates directly.

Getting Started

There are a few command-line tools and libraries you will need to install on your local system to get up and running. Obviously, you could install these in a Docker container, but that’s out of scope for this article.

Prerequisites

• AWS CLI
• AWS Account configured with appropriate permissions to deploy your services and create CloudFormation stacks
• AWS CDK toolkit
• Python (since this article focuses on CDK w/ Python)

Initialization

Normally, you will initialize a working directory by: cdk init sample-app --language python in the directory. As this will generate some scaffolding to help develop your CDK code.

But if you’re using my Github app as a starting point, you can just git pull my repo.

Python Setup

CDK in Python is similar to writing an application in Python, meaning it’s best practice to use something like virtrualenv to manage Python libraries with Pip. Most Python CDK projects should make installing the required CDK libraries and constructs easy with Pip.

Code Overview

For my sample CDK project that deploys Elastic Beanstalk, MySQL RDS, and an Application Load Balancer, we have three main files. In order of execution:

1. App.py
2. NetworkStack.py
3. RDSDBStack.py

App.py

This is the main file that gets executed when you run any of the CDK commands. Therefore, it should import and include all of the CDK constructs, Python libraries, and Stacks to run your code. It’s the file that connects everything together. I’ve also added some variables that will be shared between stacks.

NetworkStack.py

This stack takes the tedious, but important task of configuring your VPC, including subnets, route tables, and security groups, and expresses it into easy-to-read code that you can replicate and reuse. Since some of this information will be used in the next stack that’s in a separate file, I made sure to pass references to objects when needed.

For example, for a few subnets, and the VPC itself I pass the reference to a variable to be used with certain Beanstalk construct options that expect them. Until CDK creates the VPC, you won’t know what the VPC ID is, but by passing the reference to the object you won’t need to.

BeanstalkRDSStack.py

Starts off with some basic settings for launching the RDS service, along with generating a secure password and storing it in Secrets Manager.

Behind the scenes, when you bootstrap the CDK app into your region it creates and manages an S3 bucket used for storing files it uses. We can leverage this when uploading our application in a zip file to load into Beanstalk. The code I have expects a properly structured zip file to be one level up from the main app.py.

Most of this code uses Level 1 (low-level) CDK constructs, this is because it allows for more flexibility where needed.

As you’ll soon find out, Elastic Beanstalk makes a lot of assumptions about your application environment, which is fine because its job is to quickly deploy your application. But if you’re sitting down to write CDK code for your deployment, you might as well add a few lines to fine-tune it to fit your needs. There is a long list of options you can customize with Beanstalk.

The last few lines are important and depend on the application you want to deploy. So be sure to set the appropriate Beanstalk platform

Considerations

This should set you off to a nice start with your first CDK app. The one thing the code doesn’t handle is making use of the database password stored in Secrets Manager. Beanstalk doesn’t directly support pulling from Secrets Manager at the time of this writing, however, there are a handful of ways to go about it.

One way, though one I wouldn’t recommend for production, is to use environmental variables. However, the cleartext password will appear in console logs. A better way would be to use ebextensions, and use AWS CLI (get-secret-value). Depending on the actual application you’re deploying, you can use the AWS SDK and pull the secret that way.

Continued Learning

• AWS CDK Examples

What’s Next

Elastic Beanstalk is a good way to get your application deployed, but for a more scalable and flexible solution you may want to consider Elastic Container Service. So in my next article I’m going to discuss deploying an ECS/Fargate, DynamoDB stack for your application.

When dealing with AWS Command Line Interface you’ll quickly find out you will have to deal with multiple AWS Named Profiles. After all, they make sense to use when you have multiple user credentials you have to frequently use, especially when separating permissions between different users. As outlined in the AWS documentation you would specify the profile you want to run the command as by adding --profile myprof option on a command. If you don’t set this flag the command looks for the environmental variable AWS_PROFILE=myprof. If neither of these is set, then the default profile is used.

However, neither of these options really leverage the benefits you gain from using the command line. These options require you to remember to add the --profile option to each command, or remember which environmental variable you set when executing commands.

Z Shell (ZSH)

A while ago I discussed why you should switch to ZSH, and in this article, I’m going to give some tangible use-cases to support that statement. Working at the shell can and should be a more streamlined experience than dealing with GUI’s or web consoles. Using AWS web console may be an easier experience to get up and running, but once you start having to complete redundant tasks it becomes obvious that having to browse the web interface can be slow when configuring services.

The CLI allows a much faster workflow and the ability to reuse code to cut down on redundant tasks. You also get access to certain configuration and troubleshooting options and not available in the Web Console

ZSH AWS plugin

There’s a much better way and it involves ZSH and the AWS plugin. You simply set your local $HOME/.aws/ profiles as you normally would. But instead of messing with environmental variables directly or adding the --profile option to each command, you use the functions added with the plugin.

Plugin Installation

The ZSH AWS plugin includes the AWS Switch Profile (asp) function that we will use later. If you use Oh My ZSH, you can add the following to your .zshrc or .zshrc.local:

plugins = ( ... aws ... )

Usage

This function asp ran as a command switch to the specified AWS profile (as it exists in your $HOME/.aws/config file. Depending on your ZSH theme, the active profile will either be displayed at all times in your prompt or as in my case, it will be displayed in the corner when you type aws on the command line.

This plugin provides two important features that will make your workflow at the command line much easier.

1. Quick and easy profile switching
2. Clear & concise visual feedback on the active profile

Customizations

My setup uses Powerlevel10k, the default Manjaro Linux ZSH theme. Out of the box, it only shows the active AWS profile when you finish typing aws on the command line. Of course, if you want to always display the active profile you can do so.

There’s a line of code in the p10k.zsh configuration file that you can comment out to always show the active profile, non-default profile.

Another popular ZSH theme is Agnoster where the default behavior is to always show the aws profile if it’s non-default.

Notes

The AWS CLI command-line completion gives you the ability to view CLI options when typing commands. Depending on your system and how you installed the AWS CLI, it may or may not be configured.

ZSH and this plugin should certainly work on OS X, though I have not looked into it much since I haven’t owned a Mac in years.

You can spice up your AWS CLI use with a command-line fuzz finder.

One of the major benefits of Unix-like desktop systems is the ability to configure and fine-tune your desktop environment. The majority of these files are dotfiles, because traditionally they either reside in a folder that starts with a dot, e.g .ssh, or the file itself .zshrc. Obviously, this isn’t always the case, what’s important is that these are files and directories that contain configuration variables, functions, and settings.

Some of the dotfiles on my system include:

• .zshrc
• .ssh/ directory is encrypted, more on that later
• .aws/
• .gitconfig
• .spacemacs
• .aliases

This is considered a small list, but it handles the core of my desktop environment’s configuration. What becomes a hassle is when you run multiple desktops and include laptops in your arsenal.

1. Does anyone really want to manage separate dotfiles for each desktop environment when most, if not all of the files are exactly the same?
2. What if we need to revert previous changes?

The answer to these questions is why we’re here.

Enter yadm

Yadm (Yet Another Dotfiles Manager), solves the problems that we mentioned above. It’s a wrapper for Git, includes encryption support, and it’s extremely portable and lightweight since it’s just a Bash script. Git revision control allows you to create a centralized repository for you to push and pull configuration files where you get all the benefits of a typical git repository.

Installing Yadm

Installing Yadm is easy, most Linux distributions have yadm in their official repositories. There is also a homebrew package for OS X. At the time of this writing Fedora 35 is the latest stable release but does not have yadm in its official repo, however you can grab the latest Fedora Rawhide RPM package from OpenSuse Build System.

Check the full installation list here.

Getting Started

Outside of installing yadm and git on your local systems, you will probably want to set up your own private Git server. You could obviously use a private git repo from GitHub, Bitbucket, GitLab, or any one of the other Git services instead of managing your own server. If you elect not to manage sensitive configuration files, you could also just use a public Git repo.

I wouldn’t recommend using any Git service to store your configuration files. In my opinion, when dealing with a set of files that at one point in the future may contain sensitive files or credentials you won’t want to risk pushing them to a public Git repository. In my opinion, when taking control and adding more privacy to your digital life you should try to avoid services, and instead choose to store your dotfiles on your own private remote server. Luckily, there really isn’t much to install or manage to host your Yadm repo.

Setup Git Bare Repo

There really is no server to install, you simply install Git (if not installed already) and initialize your repo. Git isn’t a daemon so once you have the CLI tool installed, you either execute it on the server where it manages the git repo directories or run the CLI on your local computer to manage the Git working directories.

On your remote node that will act as the centralized host you want to add a dedicated Git user.

adduser git -m

You want to make sure this user has a home directory, as this will be where the Git repositories reside. You can store the repositories in any directory, but since this user will already own the home directory, we won’t need to set any permissions.

Next, you switch to the newly created git user, and initialize the bare repo in your home directory.

[git@mygithost ~]$ git init --bare dotfiles.git

You should see a directory named dotfiles.git. Conventionally, repositories initialized with the –bare flag ends in .git.

Why Bare Repo?

So why do we create a “bare” repo instead of a regular repo? If you’re familiar with using a Git service like GitHub you can create a Git repo through github.com before or after you git init your local project so you can push it to the remote git repo.

When you run git init, it creates a WORKING directory. It’s intended to be used as a directory where your file changes will take place. So this makes sense to run on your local dev machine. However, for the remote server that exists to store your repo and no person or service will be making changes to the files there is no need to take up file-space storing a working directory.

Setup connection

You’d want to use ssh keys to log in to the remote git server as the git user. The way to do this varies depending on the VPS or cloud service provider you use. Some general-purpose guides:

• How to generate SSH key pairs
• How to add SSH public key to server

The goal is to be able to git remote add origin mygithost:dotfiles.git and push/pull without being bothered with passwords. Again, you have multiple options, one such is to use ssh_config

Host mygithost 
	HostName 2.34.33.4 
	User admin 
	Port 22 
	IdentityFile ~/.ssh/mygitkey.pem
  

Setup Yadm

As mentioned Yadm is largely a wrapper for Git. So most of the commands are the same, just prepended with yadm. So to initialize the working directory of yadm, you would execute:

[localuser@dev-computer ~]$ yadm init

Notice that we want to initialize our home directory because this is the root of all our config files. After that, you add the files and directories you want to version control.

For example:

yadm add .spacemacs
yadm add .aws
yadm add myReadMe.org # I like to keep a file of config specific notes

After you’ve added the files you want to manage, you commit and push similarly to using pure Git.

yadm commit -m "added files"
yadm push -u origin master

Encrypted Files

Some configuration files are sensitive, they either contain credentials or are themselves private keys. Yadm is nice enough to offer a simple way to manage encrypted files without much manual work. You simply need to have either OpenSSL or GPG installed, and edit the yadm text file located in your local .config/ directory.

Edit a file at $HOME/.config/yadm/encrypt (create if it doesn’t exist) to include the files and/or directories you want to encrypt. My file consists of:

.ssh/*
.aws/credentials

I have every file inside my .ssh/ directory encrypted, and the one .aws/credentials file with sensitive credentials added. After the file is saved you tell Yadm you files to encrypt, then you add the file you just created along with the generated encrypted archive to versioning.

yadm encrypt
<ENTER PASSWORD>
yadm add .config/yadm/encrypt
yadm add .local/share/yadm/archive

Now we can commit and push this to our remote repo. And on another system that we want to sync our config files with you run yadm pull & yadm decrypt.

Wrapping Up

We now have a system that accomplishes our two main goals. Our important configuration files now have versioning, and we only need to maintain a central repository of configuration files. We only need to maintain one set of configuration files, but what if we have different systems? Say my desktop runs Linux, but I have a MacBook running OS X which requires slight configuration differences. One way is to make use of Alternate Files - yadm. This way we can specify different files depending on specific conditions.

Yadm also supports bootstrapping, the ability to create and run scripts to do any extra configuring in addition to the files you’re syncing. As an ideal use case for my setup you can imagine the extra libraries and software I have installed to work with Spacemacs. Such as the yaml-language-server which I installed using NPM, and certain Python libraries like flycheck. All of which I would rather not have to install manually on each new system. You can create an executable script that gets ran when you execute yadm bootstrap to install and configure any extra software.