Initial commit

This commit is contained in:
Shawn Borton 2026-06-21 01:36:08 -05:00
commit a4db9c8516
36 changed files with 15659 additions and 0 deletions

View file

@ -0,0 +1,79 @@
#+title: Nebula Sync
* Nebula Sync Configuration
#+begin_src nix :noweb yes :tangle ~/Development/falcon_nest/virtualization/nebula-sync-oci.nix
{ config, lib, pkgs, ... }:
{
<<nebula-user>>
<<sops>>
<<oci-container>>
}
#+end_src
** Version number
I'm putting the version number at the start of this file just below the configuration file skeleton. The goal is to receive an update that a new version is ready, then update this version number to the new version and tangle the code block. Then, commit both this Org file and the generated file to Git for the pipeline to run.
You may ask, why not just use the "latest" tag? It makes sense. If I'm updating the container image manually, I wouldn't need to change anything, just run `nixos-rebuild-switch` when I get word of a new release. The virtue of Nix and NixOS, however, is that I can make my setup reproducible with respects to not only the NixOS version, but the Docker image version. Plus, it provides a historical record of the container on Crow's Nest and Git, not to mention, if I shut down and wipe clean the container, then decide I need it again, I can go right back to the last known working version.
#+NAME: version-number
#+begin_src nix :noweb-ref version-number
0.11.2
#+end_src
** Set up the nebula user
Each container on this system gets its own user.
#+NAME: nebula-user
#+begin_src nix :noweb-ref nebula-user
users.users.nebula = {
isSystemUser = true;
group = "podman";
home = "/var/lib/nebula";
linger = false;
createHome = true;
autoSubUidGidRange = true;
};
#+end_src
** Set up secrets
The setup for nebula-sync requires the user to put in two environment variables,
one for the primary Pi-Hole instance and one for what it calls replicas or the
secondary instances. Each of these variables is a string consisting of the IP
address followed by a pipe symbol then the admin or app password for
the instance.
Obviously, having passwords in the configuration file wouldn't do so I decided to use sops-nix to manage secrets. After a bit of finessing, it works well, you just have to use environmentFiles for any oci-containers since the end result of the secrets management is a single file with the necessary information inside and you'll need to reference that file.
#+NAME: sops
#+begin_src nix :noweb-ref sops
sops = {
secrets = {
nebula-sync-env = {
sopsFile = ../secrets/nebula-sync.env;
format = "dotenv";
owner = config.users.users.nebula.name;
};
};
};
#+end_src
** Configure the container
Then we bring it all together. I'm skipping TLS verification for now, though I plan on going back and setting up the Pi-Holes with a proper domain name and SSL certificate. Plan on being the keyphrase here.
Cron is set to run at 23 minutes past the hour. We won't do a full sync, but we'll ensure gravity is updated after each run.
#+NAME: oci-container
#+begin_src nix :noweb yes :noweb-ref oci-container
virtualisation.oci-containers.containers.nebula-sync = {
autoRemoveOnStop = false;
autoStart = false;
image = "ghcr.io/lovelaze/nebula-sync:<<version-number>>";
environment = {
FULL_SYNC = "false";
RUN_GRAVITY = "true";
CRON = "23 * * * *";
CLIENT_SKIP_TLS_VERIFICATION = "true";
};
environmentFiles = [ config.sops.secrets.nebula-sync-env.path ];
podman = { user = "nebula"; };
log-driver = "journald";
};
#+end_src