[karlitschek]

Part 1 of 5, stacked on master:

1. feat(os): collect the operating system status #1214 – collect the operating system status ← this PR
2. feat(os): add an optional root helper #1215 – optional root helper
3. feat(os): support dnf, zypper, pacman and apk #1216 – dnf, zypper, pacman and apk
4. feat(os): report operating system concerns where admins look #1217 – setup checks, notifications, monitoring API, dashboard widget
5. feat(os): add the Operating system page #1218 – the Operating system page

AI disclosure: this change was written with Claude Code (claude-opus-5-5) and reviewed by the author; every commit carries an Assisted-by trailer.

🤖 Generated with Claude Code

[AndyScherzinger]

I reviewed this for correctness, security and performance, and deployed the branch to a nextcloud-docker-dev instance (NC 36 dev, PHP 8.5, Debian 13 container) to exercise it. Inline comments carry the details; this is the summary.

Blocking

1. CI "NPM build" fails: the committed js/serverinfo-main.mjs.license and js/serverinfo-main.mjs.map.license list @vitejs/plugin-vue 6.0.10, while package-lock.json pins 6.0.7. They were generated from a node_modules out of sync with the lock file; npm ci && npm run build regenerates them correctly. The version bump itself is needed for the background job and command to register.
2. Missing or stale package lists turn into "no security updates" (reproduced): with the image's purged /var/lib/apt/lists, apt-get -s dist-upgrade reported 0 pending updates; after apt-get update the same container reported 71 pending, 35 of them security. The updates concern only becomes unknown when updates === null, so the headline answer is a false all-clear wherever the lists are missing or old (see OsVerdict.php).
3. occ serverinfo:os-status exit codes do not follow the monitoring-plugin convention it cites: "not checked yet" exits 1 (= WARNING), and an all-unknown verdict reports "level": "ok" and exits 0. In the Docker container 3 of 4 concerns were unknown and the command said OK. Monitoring plugins use 3 for UNKNOWN.

Correctness

• The first-seen key includes the candidate version, so a superseding security update resets the pending-days counter.
• CoreLibraryProbe treats an upgraded systemd binary as a reboot reason, though systemd re-executes itself on upgrade; on Debian, which has no /run/reboot-required by default, that is a recurring false positive.
• In LXC without lxcfs, /proc/uptime is the host's, so a container created after the host booted reports a core-library reboot straight away.
• Smaller: Thresholds::load() does not enforce warning ≤ error; nixos-unstable is not an os-release ID; Raspbian is mapped to Debian's support dates though it has its own archive; /dev/shm/ is shadowed by /dev/.
• Worth stating in the UI later: Debian ships many fixes through point releases (libc6 2.41-12+deb13u4 from Debian:13.7/stable in my run), so "0 security updates" does not mean fully patched.

Security

• CommandRunner is well done: an argument vector to proc_open() with no shell, validated binary names, a fixed PATH, LC_ALL=C, stdin from /dev/null, an output cap and a kill on timeout. All arguments are constants, so I found no injection surface, and restricted_mode is honoured.
• The risk is exposure rather than execution. In this PR the data is only visible to admins through occ, but a list of unpatched packages with exact versions is an attacker's roadmap. Once #1217 exposes this through the token-authenticated monitoring API, consider returning counts there and keeping the package list admin-only.
• Package names and origins are stored as parsed from tool output (\S+). Nothing here renders them, but #1218 should not pass them through v-html.
• The collector reads /proc/1/cgroup, /sys/class/dmi/id/* and queries systemd over D-Bus. Everything degrades to unknown when denied, which is right; the README could list what is read so hardened setups know what to expect.

Performance

• From system cron this is cheap. A full refresh took 0.75 s in the container; with 71 pending updates, apt-get -s dist-upgrade took 2.3 s and the remaining apt probes 0.4 s.
• Under AJAX or webcron background-job modes the job runs inside a web request. The timeouts add up to roughly four minutes in the worst case (120 s for apt-get, 3 × 30 s, plus the 10 s and 5 s probes), all holding one PHP-FPM worker. Consider skipping the job unless backgroundjobs_mode is cron, or shortening the timeouts there.
• The status is stored as a lazy app-config array capped at 500 updates, which fits the long-text column on every supported database.

[karlitschek]

@AndyScherzinger Thanks for the review. All should be fixed now

[AndyScherzinger]

Re-review of 60f59603. I deployed the whole stack (up to #1218) to the same nextcloud-docker-dev instance as before (NC 36 dev, PHP 8.5, Debian 13 container, background jobs from system cron) and re-ran the checks.

Verified fixed

• Missing package lists now make the pending updates unknown instead of an all-clear.
• occ serverinfo:os-status exits 3 when nothing has been collected yet (live: exit=3), and an unknown verdict also maps to 3.
• First-seen times are tracked per package, so a superseding update keeps counting.
• systemd is no longer a core-library reboot reason. A changed file now also needs a package change since boot, and system containers skip the probe.
• Error thresholds are clamped to their warning thresholds.
• Collection runs only from system cron, and a new freshness concern warns when the status gets old or cron is not system cron.
• The status moved to app data. Live: status.json is about 1.2 KB, and the legacy cached_os_status app config key is gone.
• The license files match the lock file again, and CI is green.

Remaining

One finding is left, inline: in an application container the command still reports ok and exits 0, although the container's own packages have pending security updates.

[AndyScherzinger]

This only turns the level unknown when an UPDATES concern exists and is unknown. In an application container OsVerdict never creates that concern (managesPackages() is false), so the result is ok and exit 0.

Live in the Docker container: occ serverinfo:os-status --refresh gives "level": "ok", "updates": "unknown" and exit 0. Earlier, apt-get -s dist-upgrade in that same container listed 71 pending updates, 35 of them from Debian-Security.

It is a fair design choice that the image's packages are not the admin's to patch in place. But ok/0 is still a claim about them, and monitoring will read it as healthy. I suggest one of:

• Emit the UPDATES concern as unknown (or a dedicated not-assessed state) in application containers, so that level() and the exit code say unknown.
• State explicitly in the output and the README that ok covers host-side concerns only.

The same root cause makes the #1217 dashboard widget say "The system is up to date" in this container.

[kesselb]

Turning off the update part

• A switch for the OS-update part only. Where patching is handled elsewhere (Ansible, Landscape, Ubuntu Pro) or does not apply (application containers, images rebuilt by CI/CD), the rest of serverinfo could stay available with this part off. One bool key in ConfigLexicon would do; when it is off, the verdict could say "disabled" rather than "unknown", so occ serverinfo:os-status does not exit 3.
• It might default to off when Docker or Kubernetes is detected, which would also cover @AndyScherzinger's remaining finding about application containers reporting ok.

Multiple application servers

Setups with two or more application servers are common. The status, the cache key and the first-seen times are currently shared, so the status shows whichever node last ran the job, and the thresholds reset when nodes disagree.

• Keying the data per node with IServerInfo::getServerId(). It already falls back to a hash of the hostname; admins can set serverid per node to rule out collisions in the 0–511 range.

• An option to turn off only the background job, so admins can run occ serverinfo:os-status --refresh from each node's own cron. The TimedJob runs on one node per interval only.

• A table rather than a cache keyed by node: id | serverid | collected_at | last_seen | status | first_seen | php_sample | php_outdated_since

  • collected_at: when this node's status was last collected
  • last_seen: when this node last wrote anything, to spot nodes that stopped reporting and clean up removed ones
  • status: today os-status/status.json plus the cache key status
  • first_seen, php_sample, php_outdated_since: today the cached_os_* app config keys

  A cache can be evicted (and first_seen must survive that), cannot list its nodes, and with only memcache.local configured the cron write never reaches web requests. One row per node also removes the race on first_seen, and one indexed read makes the cache in front of app data unnecessary.

• Nodes that only serve web requests would get a row with just php_sample and last_seen, shown as "not collected".

It would be good to settle this before #1217 and #1218 land, since it changes the storage format.

Nitpicks

• 21 of the 22 commits fix the first one, and some undo earlier changes (storage, license files, README), so their messages describe fixes to code that is not on master yet. Could they be squashed into one commit that describes the final design?
• The PHP-process sampler has no caller here yet. Could it move to feat(os): add the Operating system page #1218, where it is used?