name: nexuspanel
description: Administration tools for Nexus Panel, a self-hosted control panel that manages containerised workloads — applications, services, databases and game servers — across one or more Linux machines. The snap ships two programs: `nexusctl`, which installs, upgrades, repairs and operates the panel stack on the host, and `nexus-agent`, which runs on each managed machine and supervises the workloads on it.
snapcraft: NexusPanel-Installer/snap/snapcraft.yaml at main · Banibu/NexusPanel-Installer · GitHub
upstream: PRIVATE — the source is proprietary. Releases, distribution and issue tracking are public at GitHub - Banibu/NexusPanel-Installer · GitHub
upstream-relation: I am the author and sole maintainer of the upstream project, and the publisher of this snap.
supported-category: None of the listed categories fits, and I would rather say so than stretch one. The nearest is “HPC or orchestration agents/software for running workloads on systems without traditional users”, but that category requires the systems to be “otherwise managed outside of the agent” and the software to not “manage the systems themselves”. Nexus Panel does manage them — it installs the container runtime, creates the service user and writes systemd units — so claiming that category would describe a different product than the one in the `snapcraft.yaml` linked above. Following the process document, I am asking for the requirements to be gathered by a senior reviewer and discussed with an architect.
reasoning: Both programs administer the host they run on, so the sandbox is not a restriction to work around but a contradiction of what they do. Concretely, they:
-
install, enable and control systemd units in `/etc/systemd/system` — for the panel stack and for the node agent — and reload the daemon;
-
install and drive the Docker daemon over `/var/run/docker.sock`, creating and supervising the containers that hold every managed workload;
-
create the service user and group the panel and its workloads run as, and add that user to the `docker` group;
-
own directories outside any sandbox: `/opt/nexus` (configuration, secrets, PKI), `/srv/nexus` (per-workload data), `/usr/local/bin` (the installed binaries);
-
configure the host firewall — ufw, firewalld, or raw iptables on cloud images that ship neither — so the panel can reach the node agent;
-
apply XFS project quotas to workload directories and manage host **port bindings** for the workloads they expose.
I went through the supported interfaces and found no interface, or combination of them, that expresses “install and manage systemd units, a container runtime, system users and arbitrary host paths for software this tool installs”. Interfaces such as `docker-support` and `system-observe` cover parts of that surface for a program that uses those subsystems; they do not cover a program whose job is to install and configure them on a machine the operator has deliberately handed to it. Strict confinement does not degrade this snap, it removes its function: `nexusctl` exists to set up the host, and `nexus-agent` exists to run and supervise other people’s workloads on it.
Additional details that may help the review:
Publisher: Banibu
Architectures: amd64
Snap size: ~22 MB — two static Go binaries, no bundled runtime
Automated review: 16 passes, 0 warnings; the single failure is the classic-confinement flag itself
- Every release is built from an audited immutable commit and published with a SHA-256 manifest and a provenance file; the APT and RPM repositories are GPG signed.
I understand that strict confinement is generally preferred over classic.
I have tried the existing interfaces to make the snap work under strict confinement.
Note that snappy-debug can be used to identify possible required interfaces. See snapcraftio/docs/debug-snaps for more information.
