nimmo/nixos-config

Watch

Fork 0

Migrate SABnzbd on vega to the native NixOS service #26

New issue

Closed

opened 2026-07-01 16:17:32 +01:00 by nimmo · 3 comments

nimmo commented

2026-07-01 16:17:32 +01:00

Owner

Goal

Execute the first strong native-module migration after Newt/SillyTavern by moving SABnzbd off Docker on vega.

Acceptance Checklist

Confirm the intended target paths for config, incomplete downloads, and media access.
Check the real NixOS option names before implementation.
Stand up SABnzbd with the native module.
Bind it to the intended host/port for the existing access model.
Allow UI-managed config initially if that is still the desired trade-off.
Validate that the service works with the existing partial-download and media layout.

Current Docker Context From The Note

container: sabnzbd
image: lscr.io/linuxserver/sabnzbd:latest
web port: 8383 -> 8080
config: /srv/stacks/sabnzbd/config
incomplete downloads: /mnt/partial/sabnzbd-downloads
media: Docker NFS volume backed by 192.168.8.238:/volume1/media

Notes

This is intentionally ahead of Paperless because it is smaller and lower-risk.

## Goal Execute the first strong native-module migration after Newt/SillyTavern by moving SABnzbd off Docker on `vega`. ## Acceptance Checklist - Confirm the intended target paths for config, incomplete downloads, and media access. - Check the real NixOS option names before implementation. - Stand up SABnzbd with the native module. - Bind it to the intended host/port for the existing access model. - Allow UI-managed config initially if that is still the desired trade-off. - Validate that the service works with the existing partial-download and media layout. ## Current Docker Context From The Note - container: `sabnzbd` - image: `lscr.io/linuxserver/sabnzbd:latest` - web port: `8383 -> 8080` - config: `/srv/stacks/sabnzbd/config` - incomplete downloads: `/mnt/partial/sabnzbd-downloads` - media: Docker NFS volume backed by `192.168.8.238:/volume1/media` ## Notes This is intentionally ahead of Paperless because it is smaller and lower-risk.

nimmo added this to the Service Stack NixOS Migration milestone

2026-07-01 16:17:32 +01:00

nimmo added the

host:vega

project:service-stack-migration

labels

2026-07-01 16:17:32 +01:00

nimmo commented

2026-07-03 13:06:39 +01:00

Author

Owner

Starting implementation of the native SABnzbd migration on vega.

Chosen approach for this pass:

keep incomplete downloads on /mnt/partial/sabnzbd-downloads
replace the Docker-managed /media volume with a host-level mount of 192.168.8.238:/volume1/media
expose SABnzbd via the native Newt path and on Nebula only, not on the regular LAN
copy existing state from /srv/stacks/sabnzbd/config to a new service path for rollback safety instead of moving it
translate the current live SABnzbd config into declarative services.sabnzbd.settings/secretFiles now rather than leaving it UI-managed

I’m using the live Docker stack and SABnzbd config on Vega as the migration source of truth while keeping the old stack in place until validation passes.

Starting implementation of the native SABnzbd migration on `vega`. Chosen approach for this pass: - keep incomplete downloads on `/mnt/partial/sabnzbd-downloads` - replace the Docker-managed `/media` volume with a host-level mount of `192.168.8.238:/volume1/media` - expose SABnzbd via the native Newt path and on Nebula only, not on the regular LAN - copy existing state from `/srv/stacks/sabnzbd/config` to a new service path for rollback safety instead of moving it - translate the current live SABnzbd config into declarative `services.sabnzbd.settings`/`secretFiles` now rather than leaving it UI-managed I’m using the live Docker stack and SABnzbd config on Vega as the migration source of truth while keeping the old stack in place until validation passes.

nimmo commented

2026-07-03 13:31:55 +01:00

Author

Owner

Implemented the first native SABnzbd migration pass on vega.

What changed:

moved the Vega-specific SABnzbd setup into modules/services/sabnzbd.nix and imported it from the host
created a dedicated encrypted secrets/sabnzbd.yaml for the preserved API/NZB keys and Usenet credentials
mounted the media share on the host at /srv/media via NFS instead of a Docker NFS volume
kept incomplete downloads on /mnt/partial/sabnzbd-downloads
copied the old SABnzbd state into /srv/services/sabnzbd so admin DB/log/history state moved forward while the old stack directory remains available for rollback
restricted access to Nebula only (10.10.0.2:8383) rather than the regular LAN

Validation performed:

nix flake check passed locally after the module split and service-unit adjustments
nixos-rebuild test --flake .#vega completed successfully on Vega
native sabnzbd.service is active on Vega
Nebula path http://10.10.0.2:8383/sabnzbd/ returned HTTP 200 from another host
regular LAN path http://192.168.8.108:8383/sabnzbd/ timed out from another host, matching the firewall intent
the old Docker-era state files are present under /srv/services/sabnzbd after copy (admin/*.db, queue/history files, logs, old backup INIs)

Key migration learnings:

the Docker container on 8383 had to be stopped before the native service could come up cleanly
SABnzbd’s own -d daemon mode exited with status 2 in this setup, while running it under systemd as Type=simple with --console started cleanly, so the native service now uses that mode

Follow-up risk:

I have not submitted a test NZB yet, so end-to-end download/write verification against /mnt/partial and /srv/media/sabnzbd-complete is still outstanding.

Implemented the first native SABnzbd migration pass on `vega`. What changed: - moved the Vega-specific SABnzbd setup into `modules/services/sabnzbd.nix` and imported it from the host - created a dedicated encrypted `secrets/sabnzbd.yaml` for the preserved API/NZB keys and Usenet credentials - mounted the media share on the host at `/srv/media` via NFS instead of a Docker NFS volume - kept incomplete downloads on `/mnt/partial/sabnzbd-downloads` - copied the old SABnzbd state into `/srv/services/sabnzbd` so admin DB/log/history state moved forward while the old stack directory remains available for rollback - restricted access to Nebula only (`10.10.0.2:8383`) rather than the regular LAN Validation performed: - `nix flake check` passed locally after the module split and service-unit adjustments - `nixos-rebuild test --flake .#vega` completed successfully on Vega - native `sabnzbd.service` is active on Vega - Nebula path `http://10.10.0.2:8383/sabnzbd/` returned HTTP 200 from another host - regular LAN path `http://192.168.8.108:8383/sabnzbd/` timed out from another host, matching the firewall intent - the old Docker-era state files are present under `/srv/services/sabnzbd` after copy (`admin/*.db`, queue/history files, logs, old backup INIs) Key migration learnings: - the Docker container on `8383` had to be stopped before the native service could come up cleanly - SABnzbd’s own `-d` daemon mode exited with status 2 in this setup, while running it under systemd as `Type=simple` with `--console` started cleanly, so the native service now uses that mode Follow-up risk: - I have not submitted a test NZB yet, so end-to-end download/write verification against `/mnt/partial` and `/srv/media/sabnzbd-complete` is still outstanding.

nimmo commented

2026-07-03 20:03:28 +01:00

Author

Owner

Post-cutover SABnzbd follow-up on Vega:

Confirmed the migrated state directory /srv/services/sabnzbd contains the copied SABnzbd admin state, including admin/history1.db from the old Docker install.
The apparently missing history is inherited behavior from the previous config rather than migration loss: the old sabnzbd.ini already had history_limit = 10 and history_retention_option = days-archive with history_retention_number = 7.
Adjusted the declarative Nix config to set misc.config_lock = true while staying in declarative mode. After rebuild and live deployment, the recurring Cannot write to INI file /var/lib/sabnzbd/sabnzbd.ini error no longer appears; SABnzbd now logs Configuration locked, cannot save settings instead.
Validation: nix flake check passed locally, nixos-rebuild test --flake .#vega passed on Vega, nixos-rebuild switch --flake .#vega completed successfully, and systemctl status sabnzbd shows the native service running after the deployment.

Remaining note: declarative mode still means UI changes are blocked and non-persistent by design, so runtime config edits will continue to be rejected.

Post-cutover SABnzbd follow-up on Vega: - Confirmed the migrated state directory `/srv/services/sabnzbd` contains the copied SABnzbd admin state, including `admin/history1.db` from the old Docker install. - The apparently missing history is inherited behavior from the previous config rather than migration loss: the old `sabnzbd.ini` already had `history_limit = 10` and `history_retention_option = days-archive` with `history_retention_number = 7`. - Adjusted the declarative Nix config to set `misc.config_lock = true` while staying in declarative mode. After rebuild and live deployment, the recurring `Cannot write to INI file /var/lib/sabnzbd/sabnzbd.ini` error no longer appears; SABnzbd now logs `Configuration locked, cannot save settings` instead. - Validation: `nix flake check` passed locally, `nixos-rebuild test --flake .#vega` passed on Vega, `nixos-rebuild switch --flake .#vega` completed successfully, and `systemctl status sabnzbd` shows the native service running after the deployment. Remaining note: declarative mode still means UI changes are blocked and non-persistent by design, so runtime config edits will continue to be rejected.

nimmo closed this issue

2026-07-03 20:10:20 +01:00