Etckeeper on Kicksecure

Sun, 08 Mar 2026 00:00:00 +0000

This article is part of my Self-Hosting with Kicksecure series.

1. Introduction

Before making any system changes, I want to decide on a way to record every change I make so that:

I can easily reproduce my work if I ever have to reinstall or migrate to another machine
I can easily identify problematic configs and revert them
I don’t forget the reasoning behind a particular security decision or config change in 6 months
I can identify what changes I made as opposed to changes made by software or other people
I can compare the current state of my configs against a ‘known-good’ config

The /etc directory will contain most of my configs. Outside of /etc I will need to pay attention to my dotfiles which I like to manage with GNU Stow.

Etckeeper is a neat piece of software that turns /etc into a git repository. It automatically commits changes before and after package installations, and I can manually commit my own changes too.

2. Installation

Kicksecure protects itself by isolating system maintainence tasks from daily activity. This means administrative tasks like installing new software cannot be performed from the standard user account, even with sudo. You have to reboot and select an option to boot into a session with the sysmaint account, make your changes, and then reboot back into the standard user session to continue with daily usage.

Having booted with sysmaint, I install Etckeeper from the Debian repositories:

apt install etckeeper

3. Etckeeper Basics

Do the standard git stuff:

git config --global user.email "person@email.com"
git config --global user.name "I'm a person with a name!"


I start by initializing the repository:

```bash
cd /etc
etckeeper init

And making my initial commit:

etckeeper commit "Initial configuration snapshot"

Etckeeper hooks into apt. When I install or remove packages, it automatically commits them to the git repo. So I don’t need to worry about doing a commit myself! I only need to commit after I make manual changes in /etc.

For configuration changes I make outside of apt:

# within /etc
git add .
etckeeper commit "Descriptive message about what changed"

4. Viewing History

Standard git commands work:

cd /etc
git log --oneline

View a specific change:

git show COMMIT_HASH

Compare two states:

git diff COMMIT_HASH1 COMMIT_HASH2

5. The .gitignore File

Some files in /etc shouldn’t be tracked: temporary files, secrets, or auto-generated content.

On my server I ended up configuring a ZFS RAID. Here’s an example of excluding tracking of my ZFS cache with a few other things in /etc/.gitignore:

# Ignore auto-generated ZFS cache
/zfs/zfs-list.cache/

# Example: ignore temporary files
*.tmp
*.swp

After editing:

git add .gitignore
etckeeper commit "Updated gitignore to exclude my auto-generated ZFS cache"

6. Backups

Always back up your changes so you have access to these records if your system breaks! In my case, I back up to a local ‘bare repository’ on my BTRFS backup drive. I explain how I set up this drive on Kicksecure in a later post.

Additionally, because I’d like to be able to identify known-good states of my configs even if an attacker compromises my server or network, I sanatize + compress + back up my data (or just the hashes for big files) to an air-gapped system regularly using something similar to a data diode. The air gap setup is beyond the scope of this post, but I thought the suggestion might interest readers!

Here’s how I back up my /etc repo:

6.1. Create a Bare Repository

On my already mounted BTRFS storage:

mkdir -p /mnt/storage_name/host_vault/kicksecure-etckeeper.git
git init --bare /mnt/storage_name/host_vault/kicksecure-etckeeper.git

6.2. Add as Remote

cd /etc
git remote add localvault /mnt/storage_name/host_vault/kicksecure-etckeeper.git

6.3. Push Changes

git push -u localvault main

Future pushes:

git push localvault

6.4. Push After Every Commit

This became a habit:

etckeeper commit "Made a change" && git push localvault

7. What to Track

Here’s what I have tracked so far in /etc:

/etc/fstab - Mount point config
/etc/crypttab - Encrypted drive config
/etc/ufw/ - Firewall rules
/etc/ssh/ - SSH configuration
/etc/permission-hardener.d/ - Kicksecure permission whitelists
/etc/systemd/system/ - Custom systemd units
/etc/modprobe.d/ - Kernel module configuration

8. What’s Next

Encrypted BTRFS Storage on Kicksecure

Self-Hosting with Kicksecure

Fri, 06 Mar 2026 00:00:00 +0000

1. Intro

I formerly self-hosted my services on a Kubernetes cluster with FluxCD inside openSUSE MicroOS VMs hosted by Proxmox. While that was really flexible, it became a burden maintaining it in my freetime and demanded too much RAM and storage on my resource-constrained servers. I still want to keep my K8s cluster around for tinkering in my homelab, but for a personal setup that I need to “just work” for NAS, git hosting, and backups, the complexity didn’t justify the benefits.

Yet, I loved my former workflows: GitOps, infrastructure as code, and declarative container management. I wanted to manage my self-hosting from a git repository. That’s how I landed on etckeeper for managing my base system and Podman quadlets for managing my container services declaratively with systemd.

There was one more criteria I wanted to meet…

2. Why Kicksecure?

I also don’t have enough time in my day to exhaustively follow hardening guides. I’d prefer an opinionated, secure by default system. I evaluated several options before choosing Kicksecure.

Secureblue looks promising! But I’m more comfortable with Debian-based systems, and I wasn’t familiar with its development background and whether the project is reputable.

NixOS and Gentoo were considered. Gentoo could be a really secure option but would have been another maintenance burden. NixOS might have worked since I daily drive it on my gaming PC and I’ve already gone through some hardening guides so I could copy my existing configs. Unfortunately I ran into a known bug preventing NixOS/GuixSD from booting with Heads on my server. Heads is a security focused distribution based on the coreboot open source BIOS based with features to prevent boot tampering, and rather than toiling against this bug I opted to go with the next option:

Kicksecure is connected to the same team behind Whonix which I already use! Whonix is a well-established project and it currently fits my constraints.

Kicksecure does need extra configuration to work with podman, but it turned out to be much more manageable than my old stack.

3. Retrospective

By the end of this project, I had assembled:

An etckeeper managed Kicksecure server
An encrypted BTRFS storage with subvolumes for backing up extremely critical stuff
Rootless Podman containers managed with git tracked systemd quadlets
A running Gitea instance with SSH access on port 4022
Firewall rules restricting access to only necessary ports

3.1 Posts in this series

I’m documenting my journey through the setup process in these posts:

Step	Article	Description
1	Etckeeper GitOps on Kicksecure	Keep track of all my Kicksecure configuration changes from the start
2	Encrypted BTRFS Storage on Kicksecure	Configuring server storage on BTRFS subvolumes with LUKS encryption
3	Podman Permissions on Kicksecure	Allowing rootless Podman to use newuidmap/newgidmap via Kicksecure’s Permission Hardener
4	Podman Quadlets on Kicksecure	Deploying containers with Git-tracked Podman quadlets and UFW firewall

Additionally, I flashed and locked down Heads/coreboot, installed an open source zero trust mesh VPN for remote access, deployed host-based IDS, moved server management to Ansible roles, and set up a Nextcloud instance utilizing storage on a ZFS RAID 10 array with 4x 8TB HDD’s. In the future I hope to expand this series with posts detailing those efforts, as well as posts further exploring Kicksecure’s nifty security features.

Gitops on Matty Spangler