Looking for a focused functional contribution

[Vaso73]

Hi @MacRimi,

Thank you again for the kind feedback on #391. I would like to contribute more broadly to ProxMenux, including functional work as well as Slovak localization.

I noticed the request for real OCI Manager testing in discussion #360, and I also looked through the planned roadmap items. I would be happy either to validate an existing Docker workload as a native LXC, or to take on a small, clearly bounded development slice from a planned area.

Before starting anything, I would like to agree the priority, scope, and expected behaviour with you. My goal is to support the direction you already have in mind, avoid overlapping with work in progress, and keep any contribution easy to review and test.

Is there a testing scenario or a small functional area you would find most valuable for me to take next?

[MacRimi]

Hi @Vaso73, how are you?

I can't tell you how happy your message made me. Having you offer to go beyond the Slovak and take on real functional work means a great deal, and it comes at exactly the right moment.

Here's what I had in mind, if it sounds good to you.

The first would be real testing of OCI Manager. It's the thing I most need and can't do myself: you already run workloads under Docker, and comparing two or three of them against their native LXC install would tell us far more than any test I can write. Installing them from the catalog, checking that volumes, environment, ports and first run behave as they do under Docker, and then going through update, recreate and remove. What works the same, what doesn't, and how to reproduce it would be incredibly valuable. The Slovak interface would get a real-world pass along the way.

The second, entirely at your own pace, would be the plain-language guidance for Audit & Report. You reviewed the pattern on the backup checks, and 37 checks still follow it. If you'd like, I'd be glad to hand one area over to you completely, or more as you feel comfortable.

That would free me to start thinking properly about the two larger pieces still ahead, multi-user and multi-node support, and to put more time into the documentation. When I have a clear idea of the approach for those, I'd love to talk it through with you and hear what you think.

What do you think? Does this fit what you had in mind, or would you approach it differently? And for the testing, which workloads would you find most natural to start with?

[Vaso73]

Hi @MacRimi, thank you again for asking for a focused functional contribution in #392.

I used a separate Proxmox test environment to exercise real OCI Manager workloads end to end, rather than stopping at catalog or code review. The work followed the same loop for each finding: reproduce it, identify the runtime cause, make a general safe fix, add regression coverage, and repeat the live test.

The main findings were:

• PocketBase persistence was not safe on a fresh native-LXC installation: the persistent mount did not target the image’s real data directory, and a new empty volume could hide the image-provided initial data. This affected first-run state and could leave the application without its expected initial setup.
• The Glances web profile advertised TCP 61209, while glances -w actually serves its Web UI on TCP 61208.
• The optional host-monitor mode correctly shares the Proxmox host’s network namespace, but that also means its Web UI is subject to the host firewall. A manual narrow rule proved the cause; the missing product flow was a safe, explicit way to manage that access during installation.
• A mixed deployed OCI engine version initially returned the user to the main menu instead of exposing its import error. The menu wrapper now preserves unexpected engine failures instead of hiding them.

The resulting fixes are split into two reviewable PRs:

• fix(oci): preserve persistent data and caller-owned plans #394 preserves application data safely. It introduces a declarative, opt-in seed mechanism that copies image-provided initial data only into a new empty persistent target, while preserving existing managed-volume and host-bind data. It also keeps install inputs in private canonical copies so caller-owned files are never rewritten.
• fix(oci): scope Glances host-monitor firewall access #393 corrects the Glances Web UI contract and introduces a reusable, opt-in firewall flow for host-monitor profiles. The profile declares its web port; the installer derives the IPv4 subnet from the bridge selected on that Proxmox host, displays the bridge/subnet/TCP port, requires a separate confirmation, revalidates the plan on the host, and adds only a missing narrow inbound rule. Existing rules are preserved and exact duplicates are skipped.

Live validation covered PocketBase persistence across controlled recreation, host-bind storage, clean installation, and backup behaviour. For Glances, I ran the full interactive OCI Manager path and confirmed that host-monitor mode shows actual host CPU, memory, processes, and bridge metrics through the Web UI.

The existing matching firewall rule was deliberately left in place during the final live run, so the installer’s safe idempotent path was verified without changing an already working host firewall. The missing-rule creation path is covered by the regression tests.

No production system was contacted. I’m happy to adjust the contracts or extend the same runtime-validation pattern to another host-monitor profile based on your review.

[Vaso73]

Hi @MacRimi — a quick follow-up to the OCI lifecycle testing.

I completed a direct Docker baseline as well, using the same PocketBase and Glances images in a separate disposable Docker test environment, then compared install, update check, recreate, and removal with the native OCI LXC flow.

The PocketBase result was especially useful: the original imported Docker contract mounts its volume at /pb_data, but the image actually keeps its database and initial data under /pocketbase/pb_data. The mounted volume stayed empty, and a small test marker in the real data directory disappeared after recreating the original Docker container.

I then repeated the test with a new volume seeded once from the image and mounted at /pocketbase/pb_data. The marker survived both recreate and removal of the Docker application container. This directly confirms the behavior addressed by PR #394: the native LXC flow is intentionally using the image’s real data path, seeding only a new empty volume, and preserving existing data afterwards.

For Glances, the Docker image worked normally on TCP 61208 before and after recreate. The original Compose definition also publishes 61209, but the application did not answer on that port. That gives a direct Docker runtime confirmation for PR #393 keeping the native LXC contract limited to the actual Web UI port, 61208.

The native LXC lifecycle itself was exercised through the OCI Manager UI, while the Docker baseline ran inside a separate disposable Docker LXC. So this is a functional comparison of the images, ports, data paths, and lifecycle behavior — not a performance comparison with a separate bare-metal Docker host. No production system was contacted.

One small follow-up question: would you like the original imported Docker contract corrected as a separate, narrowly scoped change as well, or would you prefer to keep it as source provenance and retain the corrected behavior only in the native LXC layer? I do not want to change generated or externally sourced catalog data without aligning with your preferred ownership and update path first.

I’m happy to take the next step either way.

[MacRimi]

Hi @Vaso73,

Thank you so much for this. Reading your report made my day. This is exactly the kind of real-world testing I was hoping for, and going as far as a Docker baseline to confirm each finding is more than I would have dared to ask. I've reviewed #393 and #394, and both are good to merge.

On your question about the imported Docker contract, I'd keep it exactly as the source published it. That file is regenerated from upstream, so any correction made there would be lost on the next import, and keeping it intact also documents what upstream actually ships. The overlay is the right place for ProxMenux's corrections, which is exactly where you put them.

A few small things I noticed, none of them blocking, just ideas for a follow-up if you think they're worth it:

oci/tests/test_glances_ports.py imports proxmenux_oci without adding src to sys.path as the other tests do, so it only passes when another test has loaded the engine first. None of the workflows run oci/tests, which is probably why it didn't show up.
The host firewall rule stays in place after the application is removed. Since it carries the CT in its comment, it might be natural to remove it together with the application.
If adding the rule fails as the very last step, the cleanup destroys an otherwise complete installation. A warning that leaves the container installed might be kinder there.
What do you think? Would you approach any of these differently, or is there something else you'd rather look at next?

[Vaso73]

Hi MacRimi,

I’m really glad to be able to contribute to ProxMenux in this way.

I still remember my own first steps with Proxmox: I often knew what I wanted to achieve, but not where to click or how the individual pieces fit together. ProxMenux and the wider community scripts gave me a much friendlier way into it and helped me become comfortable with Proxmox over time.

That is why this project feels meaningful to me. I see ProxMenux as a great opportunity to help more people become familiar with Proxmox, understand what is happening, and manage it confidently without needing to be an expert first.

I completed the three follow-ups you suggested. The Glances test can now run independently, OCI-created firewall rules are safely cleaned up when their matching application is removed, and a late firewall-rule failure no longer destroys an otherwise successful installation.

I also repeated the whole lifecycle through OCI Manager on the test environment: install, open the host-monitor UI, confirm the narrow firewall access, and remove the application again. The complete OCI test suite passes as well.

I kept the imported Docker source untouched and left the ProxMenux-specific correction in the overlay, as you recommended.

I’m happy to keep helping wherever careful real-world testing or a beginner’s perspective can make ProxMenux more approachable for people.

Warm regards,
Vaso