Run NiFi 2.10 workload as non-root user _daemon_ (uid/gid 584792)

[deusebio]

Why

The nifi:2.10 rock ran the workload as ubuntu (uid/gid 1000). To comply with the non-root charm requirements, the workload must run as the shared non-root user _daemon_ (uid/gid 584792) and retain read/write/exec access to every path the charm operates on:

• /opt/nifi/conf — charm pushes nifi.properties and state-management.xml
• /opt/nifi/bin/nifi.sh — charm execs it for sensitive-key rotation
• /var/lib/nifi/{data,content_repository,provenance_repository} — Juju storage mounts
• /var/log/nifi — NiFi log directory

Changes to 2.10/rockcraft.yaml

• Added run_user: _daemon_.
• Switched the nifi service user/group from ubuntu to _daemon_.
• Updated the user-setup override to chown /opt/nifi and the /var/lib/nifi repositories to 584792:584792 (via NIFI_UID/NIFI_GID).

Tests

Updated 2.10/goss.yaml to assert the workload runs as _daemon_ (uid/gid 584792), that the _daemon_ user exists, that all required paths are owned by _daemon_, and that they are writable/executable by the runtime user.

Verified on the rebuilt rock:

/opt/nifi                              _daemon_:_daemon_ 584792:584792 drwxr-xr-x
/opt/nifi/conf                         _daemon_:_daemon_ 584792:584792 drwxr-xr-x
/opt/nifi/bin/nifi.sh                   _daemon_:_daemon_ 584792:584792 -rwxr-x---
/var/lib/nifi/data                     _daemon_:_daemon_ 584792:584792 drwxrwx---
/var/lib/nifi/content_repository       _daemon_:_daemon_ 584792:584792 drwxrwx---
/var/lib/nifi/provenance_repository    _daemon_:_daemon_ 584792:584792 drwxrwx---
/var/log/nifi                          _daemon_:_daemon_ 584792:584792 drwxrwx---
_daemon_:x:584792:584792::/var/lib/pebble/default:/usr/bin/false

Related

• Charm PR: Run NiFi workload as non-root user _daemon_ (uid/gid 584792) nifi-k8s-operator#20

[deusebio]

CI troubleshooting: Tests failure is an upstream goss/observability issue, not this change

The failing PR / Tests check is not caused by the non-root changes in this PR. It is an upstream breakage in the shared reusable workflow canonical/observability/.github/workflows/rock-pull-request.yaml@v1.

Root cause

The reusable workflow installs goss with:

goss_base_url="https://github.com/goss-org/goss/releases/latest/download"
curl -L ${goss_base_url}/goss-linux-$(dpkg --print-architecture) -o /usr/local/bin/goss

goss's latest release is now v0.4.10, which removed the raw goss-linux-<arch> assets and ships tarballs instead (e.g. goss_0.4.10_linux_x86_64.tar.gz). As a result releases/latest/download/goss-linux-amd64 now returns 404, curl -L writes GitHub's "Not Found" page into /usr/local/bin/goss, kgoss copies that text file into the test pod, and executing it fails with exactly:

/tmp/goss/goss: 1: Not: not found
command terminated with exit code 127
[ERROR]: goss_wait.yaml never passed

This affects every rock repo using @v1, not just this PR. The baseline NiFi rock PR passed earlier only because latest still exposed the old asset name at that time.

Local verification (this rock is correct)

I rebuilt the rock from this branch and validated it locally:

• Container runs as _daemon_ (uid/gid 584792); the pebble nifi service is active and the NiFi API is healthy.
• I ran the full goss suite (goss_wait.yaml + goss.yaml) with a working goss v0.4.10 binary against the rebuilt image:

Total Duration: 0.197s
Count: 102, Failed: 0, Skipped: 0

This includes all of the new non-root assertions: runtime-uid-is-daemon / runtime-gid-is-daemon (584792), conf-dir-writable, nifi-sh-executable, data-dir-writable, content-repo-writable, provenance-repo-writable, log-dir-writable, _daemon_ ownership of /opt/nifi and the /var/lib/nifi repositories, and nifi-runs-as-daemon.

Fix

The fix belongs in canonical/observability (this repo only calls the reusable workflow). I've opened a PR there to update the goss install step to the new tarball layout: canonical/observability#497

Once that lands (and @v1 is updated), re-running CI here should go green.

[nikita-jare]

LGTM! One non-blocking nit below

[nikita-jare]

Thank you @deusebio !