1.2.6.2-beta — where we are and what comes next

[MacRimi]

Hey @Vaso73 and @f3rs3n,

The 1.2.6.2 beta is out, and a large part of it is yours. Thank you both.

I've closed #343, #360, #361 and #392 so that from here on we have one place to talk.

My idea is to let this beta settle for two weeks at most and then release 1.2.7, with Audit & Report and OCI manager Apps. Until then I don't want to start anything new, only improve and fix what is already there.

These are the things I'll be on:

• Whatever users report on this beta. It's the first time OCI manager is in other people's hands.
• The documentation of the website. I'm going through the English so it reads clearly, and I'd like it complete in the eight languages for 1.2.7. When the text stops moving I'll tell you here. @Vaso73, Slovak is where the automatic translation falls shortest, so I'd like to hear how you'd prefer to approach it.
• The OCI validations. Ten reports are waiting for my review on the Roadmap, I'll go through them these days. ESPHome and Jellyfin Official are in progress with nobody assigned, are they yours?

After 1.2.7 this is what I have in mind. I'm telling you now so we can start thinking about it together.

• A catalog in the Monitor. Installing applications from the browser, which is very close to what you proposed, Vaso. I picture the OCI manager applications and the Helper-Scripts together, sorted by category, with a main search like the one in the new menu that also finds ProxMenux options. Each application would be a card, and clicking it opens a window with its description, images and details. For that the descriptions will have to grow.
• Custom repositories. Further ahead, I'd like a user to be able to add a repository of applications compatible with ProxMenux, the way Home Assistant does, and see them in the same search. We would need to define a template for how such a repository is laid out.
• Addons. The same idea for addons: third-party applications that integrate with ProxMenux and add new functions to it.
• User profiles. Accounts that can run things and accounts that can only look, where the action buttons and the terminals don't appear at all, together with a better sign-in that supports OIDC.
• The multi-node view, which people have been asking for.

I don't know if all of this fits in 1.2.8. Splitting it across several versions will probably be the practical way.

@Vaso73, there is one more thing, the one you mentioned: creating plain LXC containers, which is what's still missing. My idea is to use the official Proxmox templates, with the operating systems Proxmox offers, through a guided flow like the one for creating VMs, and tied to the firewall as you suggested. If you'd like to take it, that would be great. Feel free to assign yourself the Create LXC card on the Roadmap.

@f3rs3n, the same goes for you: feel free to pick any task or idea you'd like to build and put your name on it.

And if you see any of this differently, tell me here.

[Vaso73]

Thanks, MacRimi — it feels really good to see the beta out, and I’m glad that the Slovak work, the OCI testing and the fixes that came from it are part of it.

Yes — ESPHome and Jellyfin Official are mine. The text on both Roadmap cards is still the older, pre-test version, so I left them In progress rather than rewrite or move them before you had a chance to review the results.

ESPHome has since completed an isolated single-container Modify/recovery scenario. Modify from 2 to 3 CPU, a verified VZDump, official Remove, restore and supported OCI recovery all passed. The backed /config marker, DHCP and firewall configuration, OCI registration and HTTP service were preserved, and I also completed the browser check. The final cleanup removed the disposable test CT and its OCI record. The NFS work-storage fallback and an internal reboot initiated by the ESPHome image are still explicitly unverified, so I am not counting those as passed.

Jellyfin Official is still blocked on purpose. Install, reboot, the /config marker and HTTP service passed, but Modify correctly stopped before changing anything because the current catalog gives managed /cache and /media volumes backup=false, while the recovery transaction can only honestly recover backed managed data. I kept that safeguard in place, captured the evidence safely and cleaned up the test scenario.

My first thought for Jellyfin after the 1.2.7 window would be to keep rootfs and /config recoverable, treat retained media as explicitly acknowledged external data, and make cache disposable only when there is a clear contract proving it can be recreated safely. That would need focused regression coverage and a new isolated retest first. It is only a proposal, though — I would really like your view on whether that feels like the right direction, or whether you would prefer a different shape before I take it any further.

For the Slovak website documentation, I would prefer to wait until the English text settles, then manually review only the changed source delta and send focused EN/SK contributions. That keeps the Slovak natural without creating a moving translation target.

I also like the direction for plain LXC containers: a guided flow using the official Proxmox templates and firewall integration sounds like the right shape. I would be happy to take it on once the 1.2.7 window opens; until then I will leave the Roadmap card unassigned so it does not look like new beta work.

For now, I’ll keep to real beta feedback and fixes only. If users uncover something in OCI manager Apps, I’m happy to reproduce it carefully and help turn it into a safe fix.

[f3rs3n]

Hi @MacRimi, I’m pleased to see the beta out too, and glad our contributions have helped bring it together. Like Vaso, I’ll focus on refining what is already there and addressing any concrete issues during this stabilization period; I’d also be happy to review the Italian website documentation once the English text has settled.

In the meantime, I’ll finish the Bitcoin Knots validation, then pick further OCI applications one at a time, keeping each scenario and its results clear rather than taking on several in parallel.

One idea for after 1.2.7: could we compare the current automatic translations with an LLM-based provider, using a small sample and giving it the relevant UI or documentation context, a technical glossary and examples of our reviewed wording?

I’m suggesting this because, during the Italian review, I was surprised by how little I needed to change in the model’s proposed wording. Of course, an unattended translation service is not directly comparable to an agent-assisted review with source context, iteration and checks, so I wouldn’t assume the same results from a simple API call. I also haven’t investigated the costs or which providers would be suitable yet.

If this proved feasible, I would consider it an important improvement, not just a way to reduce manual cleanup. During the Italian review, I found some of the automatic translations misleading and, in my view, potentially unsafe because they could give users the wrong understanding of an operation or its risks. Better initial translations could help reduce that risk, while still preserving curated wording, the existing placeholder and markup checks, and human review. A small comparison reviewed by native speakers would help us judge whether the improvement is real and worth integrating, without adding work to this beta.

[f3rs3n]

Log2RAM loses journal records during rotation

Hi @MacRimi, I found a journal persistence problem during tests of 1.2.6.2-beta.

The migration to Log2RAM optimization version 1.6 passed. It preserved the configuration, binary and mounts. I have no evidence that the beta introduced this problem. It is separate from the live-reinstall corruption in #327.

Environment: Proxmox VE 9.2.21, kernel 7.0.14-23-pve, systemd 257.13-1~deb13u1. Log2RAM uses a 512 MiB tmpfs at /var/log, with /var/hdd.log as disk storage and JOURNALD_AWARE=true.

First test: I preserved the journals and inserted a unique notice-level marker. I verified the marker in RAM, ran journalctl --sync, then ran /usr/local/bin/log2ram write once. That command already rotates the journal.

The RAM journal contained 99 archives and one active file. With the default SystemMaxFiles=100, journald deleted the new archive before rsync started the copy. The journal recorded Deleted archived journal for the exact archive that the header identified.

The marker disappeared from RAM and never reached disk. Log2RAM returned exit 0, and both journal stores passed integrity verification. A normal reboot also lost the records from the previous boot.

The active file contained lower sequence numbers than every archive with the same sequence-number ID. For matching IDs, systemd 257.13 orders archives by sequence number, not timestamp.

Second test: I added a runtime-only SystemMaxFiles=200 drop-in and restarted only journald. The size limits did not change. The restart preserved the active file and sequence-number ID. The sequence counter did not decrease.

The same marker/write test then passed. The marker reached disk, and the archive contained identical bytes in RAM and on disk.

The disk copy of system.journal still dates from August 31. The journal-aware sync excludes this active file, but startup copies disk contents into RAM. This suggests that startup restores old sequence state. I did not test that startup behavior.

I see three possible approaches:

1. A higher file limit as a temporary measure, plus verification that a marker reaches disk. This is not a permanent fix.
2. A fix for sequence restoration and journal rotation that keeps Log2RAM. This needs tests of scheduled sync and preservation across a reboot.
3. Native persistent journald with size limits, as an alternative for users who prioritize reboot diagnostics over fewer disk writes.

Which approach do you prefer? Log2RAM remains installed, and only the runtime measure is active. I preserved the evidence. I did not yet test scheduled sync or a reboot with this measure.

If you prefer a separate report, I can open a focused issue.

[MacRimi]

Thank you both for your comments, @Vaso73 and @f3rs3n.

A few new strings are coming to develop. I've opened a thread to collect applications for the OCI catalog, Suggest an application for the OCI catalog, and with it the menu has a new option: installing an application from an oci-compose written by hand. That option and the Log2RAM fix add 14 strings. The bot will fill them in and I'll tell you here when they land, so you only have to look at those.

@Vaso73, this is the way of working you described: review only what changed. I'd like to make that easier by having the bot list the strings it adds in each language. Slovak is where the automatic translation falls shortest, so your reviewed strings are the best reference we have, and any comparison of providers should include Slovak from the start.

@f3rs3n, this fits what you proposed. These strings could be a first small sample: new, few, and with a clear context. And the review PRs from both of you already give us pairs of what the bot wrote and what you left, a ready-made reference to measure any other provider against.

After 1.2.7 I'd also like to give the translator more context than it has today, starting with a comparison like the one Martino describes. Tell me how you see it.

[f3rs3n]

Thanks, @MacRimi. Log2RAM 1.7 passed the manual sync after a normal reboot, with all tested new-boot records persisted at the default 100-file limit. As expected, the transition removed some legacy records with the old sequence order.

[Vaso73]

Hey @MacRimi, I'd like to extend “Find applications” with a read-only discovery fallback for native apps outside the tracking catalog, keeping the current UI.

The scan would collect service, process, port and installation metadata, then present candidates with supporting evidence and prefilled details for user confirmation. A missing version would not hide a candidate.

Existing verified detectors, automatic OCI registration and Docker inventory would be preserved. Managed OCI containers would not receive generic guest probes or duplicate registrations.

Discovery would not infer update commands, add bulk-update targets, start stopped containers or install anything. Scans would have time/output limits and avoid sensitive data and unknown executable probes.

Would this scope fit your plans before I start implementing it?

[MacRimi]

Hey @Vaso73, I like this. Today Find applications only knows what is in the tracking catalog, and anything installed by hand has to be registered by the user, so a careful fallback with evidence and confirmation fits well.

The scope looks right to me as you describe it. Three things I'd keep in mind:

• Leave out the services of the system itself (ssh, cron, postfix, rsyslog and the like), so the candidates are applications and not noise.
• Alpine containers too, which have no systemd.
• Only on demand from the button, never in the periodic refreshes.

Go ahead and start whenever you like. I think there is room for it to make 1.2.7; if 1.2.7 is ready before it is, I'll let you know and it goes into the next beta.

[Vaso73]

Hi @MacRimi, thanks again for the helpful guidance here.

I’ve been exploring a small extension to Find applications for services installed outside the tracking catalog. The intended experience is simple: a user clicks Find, sees only well-supported candidates with the evidence behind them, and then still chooses whether to add one. It stays on-demand, avoids system services, and supports both systemd and Alpine-style containers.

Before I turn this into a PR, I’d really value your view on the overall direction. Alongside native applications, I have also explored two optional parts that improve the same flow: retrieving an icon directly from the selected local web app, and recognising an app that lives inside Docker when there is strong, specific evidence.

Would you prefer the first contribution to stay limited to native LXC apps, or does it make sense to keep those optional pieces together as one carefully bounded Find experience? If you see a simpler shape, a better boundary, or anything I may be overlooking, I’d be very happy to adjust it. No PR yet — I wanted to get the direction right first.

Thanks!

[MacRimi]

Thanks for checking the direction first, it helps a lot.

I'd keep the first PR to native LXC apps. That's the heart of it, it can be reviewed and tested well on its own, and it's the part that still has a chance of making 1.2.7; if not, it goes into the next beta.

The other two sound good, and I'd bring them later as separate PRs. Taking the icon from the app's own web page means the Monitor fetching content from a guest and showing it, so it deserves its own care around limits, image types and SVG sanitising. The Docker side overlaps the Docker inventory and the apps already registered with their image, so I'd rather look at how they meet without rushing it.

[DrOwl]

I have just done my first test of an OCI install, I have a bug / feature request, not sure how best to report it but when choosing a network interface there was no option for adding a vlan. This is an issue for me as my setup is a vlan aware linux bridge and tags on each "virtuals" interface.

[MacRimi]

Hello and thank you for reporting it.
I will check it.

[MacRimi]

I'd like to add an optional VLAN tag to the network step, kept with the installation so updates, modifications and restores apply it again. Version 1.2.7 is about to be released, so I'm thinking of it for the next beta. Thanks again for the report, it's exactly the kind of setup I want OCI manager to handle.

[DrOwl]

Thanks for the update, I am happy to help with some testing for vlan tagging options

[MacRimi]

Hi @Vaso73, @f3rs3n and @jcastro,

Before the stable release, I wanted to stop for a moment and say thank you.

@Vaso73 and @f3rs3n, this beta simply wouldn't have been possible without you. The testing, the fixes, the reviews and the countless details you caught have shaped every part of it. On top of that, you've taken care of the Slovak and Italian translations and reviews, which brings ProxMenux to many more people and makes it feel at home in their own language. I'm truly grateful for all of it.

I'd also like to introduce @jcastro to this thread. Jonatan has contributed a great deal to OCI manager: features, debugging and reviews that have made it much more solid. Since he published his video, OCI manager has been a real revolution, and I'm sure it will be even more so once it's available to everyone with the stable release. Thank you, Jonatan, for everything you've brought to it.

My plan is to publish 1.2.7 tomorrow. There are still a few texts left to review so that everything is ready and available.

Thank you all, it's a pleasure to build this with you.

[Vaso73]

Hi @jcastro, nice to see you here! I've been watching your YouTube videos and recently joined your Telegram channel. I'm following from Slovakia, so I watch with English subtitles — keeping up with them is still a bit of a workout for me 😄. Thanks for sharing your knowledge and for your work on ProxMenux!

[f3rs3n]

Hi @jcastro, I just watched your recent video about OCI (with English subtitles). Nice work, clear and informative! I'm glad to see your support for @MacRimi.

And thank you, @MacRimi, for your kind words. It's been a pleasure to contribute. I find it especially satisfying to track down and fix those hidden bugs!

[MacRimi]

Hi @Vaso73 and @f3rs3n,

I'm about to open the PR from develop to main for 1.2.7. Some strings in your languages changed after your last commit, and I'd like to give you the chance to adjust them before the merge, if you want to.

Slovak (@Vaso73): 123 strings since 44ab9d5. Most are in lang/sk.json (OCI catalog texts, registry and tmpfs messages), plus one release note in the Monitor and three lines in the AI assistant docs page.
Italian (@f3rs3n): 317 strings since 12f4249. Most are in lang/it.json, plus seven in the Monitor (background LXC update messages and the release notes) and three lines in the AI assistant docs page.
No pressure at all. I'll wait before merging.

[Vaso73]

Hi @MacRimi, thank you for waiting, and for your kind words on #527!

I've reviewed the requested Slovak delta and sent a focused correction PR with 32 wording improvements. The rest already reads well or consists of product names and technical identifiers that should stay as they are.

The automated checks and SK/EN desktop/mobile browser tests passed. I also checked the translations on an isolated test host; the PR describes the existing website issues found during the broader checks.

Thanks again for giving us time to review this before 1.2.7!

[MacRimi]

Hi @Vaso73, @f3rs3n and @jcastro,

1.2.7 is out, and everything we talked about here made it in or has been solved since: the validations, Find applications with native apps, icons and Docker, the Slovak and Italian reviews, and Log2RAM, which is getting a full redesign in 1.2.8.

I'm closing this thread and we carry on in #560, for 1.2.8 and the beta after it. Two things move over with us: the VLAN tag in the OCI network step (@DrOwl, thanks for offering to test it, I'll call on you there), and the comparison of the automatic translations with an LLM that Martino suggested.

My idea is to keep 1.2.8 short and corrective, and to start the bigger plans in the beta that follows, beginning with the multi-node view.