mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-09-28 09:36:47 +00:00
fix: improve host diagnostics, storage handling, and maintenance workflows
- add zero-downtime Proxmox TLS certificate refresh from the Security panel (#307) - classify storage availability independently from missing capacity information (#309) - update ZFS ARC sizing and safely reconcile conflicting module configurations - preserve and restore migrated ZFS settings without overwriting later administrator changes - stop memory optimization from forcing the kernel overcommit policy - correlate multi-line OOM events and identify the affected LXC, cgroup limits, swap and killed process - add selectable Bash prompt path styles and clearer shell activation guidance - protect technical names during automatic translation and correct localized terminology - update the Coral and VM/LXC Apps and Updates documentation, translations and screenshots
This commit is contained in:
MacRimi
@@ -1,281 +1,183 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "App — register and monitor LXC applications | ProxMenux",
|
||||
"description": "Declare the apps running inside an LXC container from the ProxMenux Monitor and optionally track their versions."
|
||||
"title": "LXC App tab: discovery, links and version tracking | ProxMenux",
|
||||
"description": "Discover and register LXC applications, create web links and optionally track installed and available versions."
|
||||
},
|
||||
"header": {
|
||||
"title": "App — register and monitor LXC applications",
|
||||
"description": "Declare the apps running inside a container, wire quick web links, and optionally track installed vs. upstream versions."
|
||||
"title": "LXC App tab: discovery, links and version tracking",
|
||||
"description": "Give each LXC application a persistent identity, web access and optional version evidence without coupling registration to updates."
|
||||
},
|
||||
"intro": {
|
||||
"p1": "The <strong>App</strong> tab records which applications run inside an LXC container. Each registered app can expose a display name, an icon, one or several web links and — optionally — its version status.",
|
||||
"p2": "A single LXC can host several registered applications. A main service can share the container with an administration interface, an API or any other application reachable on a different port.",
|
||||
"p3": "Registering an application does not modify it or update it. This tab is about identification and display. The mechanisms that <em>execute</em> an update are configured and used from the <link>Updates tab</link>."
|
||||
"p1": "The <strong>App</strong> tab records which applications belong to an LXC. A registration can contain only a name and web link, or also include an installed-version detector and an upstream source.",
|
||||
"p2": "The procedure that changes software is configured separately on the <link>Updates tab</link>. Saving an app never runs an installer or updater.",
|
||||
"callout": "Registration, version tracking and updating are three independent capabilities. Any one can be used without requiring the other two."
|
||||
},
|
||||
"whatYouGet": {
|
||||
"heading": "What you get by registering an app",
|
||||
"lead": "Depending on the data configured, ProxMenux can surface:",
|
||||
"overview": {
|
||||
"heading": "What an application record can provide",
|
||||
"lead": "A single saved record can include:",
|
||||
"items": [
|
||||
"A one-click shortcut to the application's web UI.",
|
||||
"Multiple links when the LXC exposes more than one service or port.",
|
||||
"The version currently installed.",
|
||||
"The latest version published by the project.",
|
||||
"A notice when a newer version is available.",
|
||||
"Notifications on new releases if enabled in Monitor settings."
|
||||
"A display name and a theme-aware logo.",
|
||||
"One or more clickable web links built from the LXC address, scheme and saved port.",
|
||||
"An optional detector for the version currently installed inside the LXC.",
|
||||
"An optional GitHub, HTTP JSON or Docker Hub source for the latest available version.",
|
||||
"Per-application release notifications and update-counter inclusion preferences.",
|
||||
"A corresponding section on the Updates tab, even when version tracking is disabled."
|
||||
]
|
||||
},
|
||||
"discovery": {
|
||||
"heading": "Cached discovery and Find applications",
|
||||
"lead": "Application suggestions are part of the per-LXC modal cache. The startup scan prepares them in the background so opening the App tab can show cached results immediately.",
|
||||
"items": [
|
||||
"Opening the App tab does <strong>not</strong> start a new catalog scan and does not repeatedly query the LXC.",
|
||||
"<strong>Find applications</strong> explicitly runs a fresh discovery pass for that LXC. Use it after installing new software while ProxMenux is already running.",
|
||||
"The previous list remains visible while the explicit scan runs. New matches are added when it finishes.",
|
||||
"If no new match is found, the result is stated beside the actions and <strong>Register application</strong> remains available for manual entry.",
|
||||
"Saving, removing or restoring an app updates the same cache immediately. Starting or restoring an LXC refreshes only that guest through its existing lifecycle event."
|
||||
],
|
||||
"trailing": "Version tracking is optional. An app can be registered purely to keep its name, icon and web links handy.",
|
||||
"callout": "The <strong>Update available</strong> label means ProxMenux found a difference between the installed and the published version. It does not automatically mean it also knows how to upgrade the app — that is a separate setup, done on the Updates tab."
|
||||
"callout": "A suggestion is not a registration. It stays read-only until <strong>Register</strong> is pressed and the form is saved."
|
||||
},
|
||||
"firstOpening": {
|
||||
"heading": "First time opening the App tab",
|
||||
"p1": "On first open, ProxMenux tries to recognise apps in the container using the information it has: the installer used when the LXC was created, detected services, and ports that are listening.",
|
||||
"p2": "When matches are found, they show up as suggestions. Always review the proposal before saving — auto-detection speeds up registration, but it cannot guarantee that every detected service corresponds exactly to the app you intended."
|
||||
},
|
||||
"figures": {
|
||||
"f01": {
|
||||
"alt": "Empty App tab showing detected app suggestions",
|
||||
"caption": "Empty state with one or more detected suggestions"
|
||||
},
|
||||
"f02": {
|
||||
"alt": "Catalog search showing matches for the typed name",
|
||||
"caption": "Catalog search and match selection"
|
||||
},
|
||||
"f03": {
|
||||
"alt": "App registration form with name, icon and two web links",
|
||||
"caption": "Basic form with name, icon and two web links"
|
||||
},
|
||||
"f04": {
|
||||
"alt": "LXC with Docmost and Redis both registered as separate apps, each with its own version state",
|
||||
"caption": "Two apps in the same LXC — a file-tracked app and a dpkg-tracked one, each with its own version state"
|
||||
},
|
||||
"f05": {
|
||||
"alt": "Advanced tracking options showing the installed-version method and the upstream source",
|
||||
"caption": "Advanced options with the installed-version method and the upstream source"
|
||||
},
|
||||
"f06": {
|
||||
"alt": "Registered app card with the installed version, the latest upstream version and an Update available indicator",
|
||||
"caption": "A wired card shows Installed, Latest upstream, an Update-available arrow when they differ, and the web link"
|
||||
},
|
||||
"f07": {
|
||||
"alt": "Minimal registered app showing just its name and a single web link, no version tracking",
|
||||
"caption": "Link-only record — just a name and a web link, without version tracking"
|
||||
}
|
||||
},
|
||||
"registerSuggested": {
|
||||
"heading": "Registering a suggested app",
|
||||
"registration": {
|
||||
"heading": "Registering an application",
|
||||
"lead": "A detected suggestion and a manual record use the same editor:",
|
||||
"steps": [
|
||||
"Open the LXC from the <strong>VMs & LXCs</strong> card.",
|
||||
"Select the <strong>App</strong> tab.",
|
||||
"Locate the suggested app.",
|
||||
"Press <strong>Register</strong>.",
|
||||
"Check the name, links and auto-filled data.",
|
||||
"Save the app."
|
||||
],
|
||||
"trailing": "If a suggestion doesn't match anything you actually want to register, you can hide it. Hidden suggestions can be brought back from <strong>Register a different app</strong>."
|
||||
"Press <strong>Register</strong> on a suggestion or <strong>Register application</strong> to choose from the catalog or enter a custom name.",
|
||||
"Review the name and logo proposed by the catalog.",
|
||||
"Add the required web links. Detected listening ports are offered as shortcuts, but none is saved automatically.",
|
||||
"Leave <strong>Track upstream version</strong> disabled for a link-only record, or enable it and review the installed-version detector and upstream source.",
|
||||
"Use <strong>Test detector</strong> when tracking is enabled, then save the record.",
|
||||
"Press <strong>Done</strong> after editing. The App and Updates tabs reuse the updated cached record."
|
||||
]
|
||||
},
|
||||
"catalog": {
|
||||
"heading": "Using the catalog",
|
||||
"p1": "The catalog helps you find known applications and pre-fill some of their data. Typing into the name field shows the closest matches — picking one can autofill the name, icon, typical ports and, when a verified profile exists, the version-tracking options too.",
|
||||
"p2": "The catalog is a helper, not a complete list of every piece of software an LXC might host. Some entries only carry basic information; others also include a ready-made way to read the installed version.",
|
||||
"p3": "If the application isn't in the catalog, register it manually."
|
||||
"heading": "Catalog-assisted registration",
|
||||
"lead": "The catalog supplies defaults, but the saved record remains editable.",
|
||||
"items": [
|
||||
"Search results can prefill the canonical name, logo and common web ports.",
|
||||
"Known version detectors are based on real package names, binaries, files, Python distributions, OCI labels or commands rather than a universal <code>/root/.app</code> assumption.",
|
||||
"Verified runtime overrides take precedence when an installation uses a path that differs from its installer metadata.",
|
||||
"Proxmox VE Helper-Scripts markers such as <code>/root/.slug</code> remain one compatibility signal for newer helper installations, not the only detector.",
|
||||
"Every proposed value can be edited before saving to cover official installers and manual installations."
|
||||
]
|
||||
},
|
||||
"manual": {
|
||||
"heading": "Register an application manually",
|
||||
"p1": "Use <strong>Register a different app</strong> when the LXC has no apps yet. If it already has at least one, use <strong>Add another application</strong>.",
|
||||
"p2": "The basic configuration only needs a name. Everything else is added according to what you want to display.",
|
||||
"nameHeading": "Name and icon",
|
||||
"nameBody": "Give the app a name that makes it easy to recognise. The icon is optional and can be supplied as a URL.",
|
||||
"linksHeading": "Web links and ports",
|
||||
"linksLead": "Each link can carry:",
|
||||
"linksItems": [
|
||||
"Protocol <code>http</code> or <code>https</code>.",
|
||||
"Port.",
|
||||
"Description, such as <em>Web UI</em>, <em>Administration</em> or <em>API</em>.",
|
||||
"An optional per-link icon."
|
||||
"docker": {
|
||||
"heading": "How Docker LXCs are represented",
|
||||
"lead": "For an LXC whose primary platform is Docker, <strong>Docker</strong> is the application registered at LXC level.",
|
||||
"items": [
|
||||
"A containerized workload such as Portainer, Frigate or Vaultwarden is not suggested as an independent native LXC application.",
|
||||
"Running Docker services with published TCP ports are offered inside the Docker editor as optional web links.",
|
||||
"Each suggested link shows the service, host port and container port. Only links that provide a web interface should be saved.",
|
||||
"The global Docker logo is used when a link has no specific logo. A per-link logo overrides it when one is configured.",
|
||||
"After Docker is registered, Docker Engine and image updates are shown together in its section on the Updates tab."
|
||||
],
|
||||
"linksTrailing": "ProxMenux combines protocol and port with the LXC's IP address to build the URL. Add as many links as the app needs when a single container exposes several related services.",
|
||||
"linksConfirm": "Before saving, confirm the port really corresponds to the service and that you can reach it from the browser."
|
||||
"callout": "This structure prevents a Docker workload from looking like software installed directly in the LXC while preserving quick links to its interfaces."
|
||||
},
|
||||
"multiple": {
|
||||
"heading": "Registering several apps in the same LXC",
|
||||
"intro": "After saving the first app, press <strong>Add another application</strong> and repeat. Each record keeps its own links, detection method and version state independently.",
|
||||
"usefulLead": "This is useful when:",
|
||||
"usefulItems": [
|
||||
"An LXC hosts several independent services.",
|
||||
"An installation includes a main app plus companion tooling.",
|
||||
"Each service has its own web interface or its own release cycle."
|
||||
],
|
||||
"dontGroup": "Don't group under a single record programs that publish and update independently. Registering them separately makes it clear which one has a new release and lets each one carry its own update method on the Updates tab."
|
||||
"webLinks": {
|
||||
"heading": "Web links and logos",
|
||||
"lead": "Web links work with or without version tracking.",
|
||||
"items": [
|
||||
"Each link stores a scheme, port, optional description and optional logo URL.",
|
||||
"The displayed URL uses the current address already detected for the LXC; the address is not duplicated in every app record.",
|
||||
"A link without its own logo falls back to the app-level logo.",
|
||||
"Several links can represent an admin interface, API, secondary UI or another endpoint of the same app.",
|
||||
"A saved link-only app also appears on Updates, where a custom updater can be configured later."
|
||||
]
|
||||
},
|
||||
"tracking": {
|
||||
"heading": "Version tracking",
|
||||
"intro": "Open the advanced options in the form to configure version tracking. Two different pieces of information are needed:",
|
||||
"ingredients": [
|
||||
"<strong>Installed version</strong> — how to read the version currently running inside the LXC.",
|
||||
"<strong>Latest available version</strong> — where to read the version published by the project."
|
||||
"heading": "Optional version tracking",
|
||||
"lead": "Tracking combines an installed-version detector with an optional upstream source. The two sides are checked independently.",
|
||||
"colMethod": "Installed-version method",
|
||||
"colUse": "Use",
|
||||
"detectorRows": [
|
||||
{ "method": "dpkg / apk", "use": "Reads the installed package version from Debian, Ubuntu or Alpine package metadata." },
|
||||
{ "method": "binary", "use": "Runs an absolute binary path or a command name with version arguments." },
|
||||
{ "method": "file + regex", "use": "Reads a real file and extracts the version with one capture group." },
|
||||
{ "method": "docker label / docker exec", "use": "Reads an OCI version label or runs a version command inside a Docker container." },
|
||||
{ "method": "python distribution", "use": "Uses importlib.metadata through the selected Python interpreter." },
|
||||
{ "method": "command", "use": "Runs an advanced argv-style command without a shell and extracts the version from its output." },
|
||||
{ "method": "manual", "use": "Stores a version entered manually; it must be changed after upgrading the app." }
|
||||
],
|
||||
"trailing": "If only the installed version is configured, ProxMenux can show it, but cannot tell whether an update exists. For an <strong>Update available</strong> label to appear, both values have to be readable and comparable.",
|
||||
"methodsHeading": "Methods to read the installed version",
|
||||
"methodsLead": "Pick the method that matches how the app was installed:",
|
||||
"methodsTable": {
|
||||
"colMethod": "Method",
|
||||
"colWhen": "When to use it",
|
||||
"rows": [
|
||||
{ "method": "None (link only)", "when": "You only need the name and web links." },
|
||||
{ "method": "dpkg package", "when": "The application is installed as a Debian or Ubuntu package." },
|
||||
{ "method": "apk package", "when": "The application is installed as an Alpine package." },
|
||||
{ "method": "Binary", "when": "An executable returns its version through an argument like --version." },
|
||||
{ "method": "File + regex", "when": "The version string is written inside a file." },
|
||||
{ "method": "Python distribution", "when": "The application is installed as a Python package." },
|
||||
{ "method": "Command", "when": "A specific command must be executed to obtain the version." },
|
||||
{ "method": "Manual", "when": "The user enters the installed version by hand." }
|
||||
]
|
||||
},
|
||||
"methodsTrailing": "Use the most direct and stable method. If the application comes from a system package, prefer querying that package over parsing the output of a generic command.",
|
||||
"commandHeading": "The Command method does not update the app",
|
||||
"commandP1": "In this form, <strong>Command</strong> serves exclusively to read the installed version. Its arguments are entered comma-separated and ProxMenux runs them directly, without a shell interpreter.",
|
||||
"commandP2": "If your usual query is:",
|
||||
"commandExample1": "myapp version --short",
|
||||
"commandP3": "Form arguments would be:",
|
||||
"commandExample2": "myapp, version, --short",
|
||||
"commandP4": "Don't use operators like <code>&&</code>, redirections or pipes here. If you need a full procedure to upgrade the application, that is configured later on the Updates tab.",
|
||||
"sourceHeading": "Source for the latest available version",
|
||||
"sourceLead": "ProxMenux can query a public source of the project, for example:",
|
||||
"sourceItems": [
|
||||
"The releases or tags of a GitHub repository.",
|
||||
"An HTTP endpoint that returns the version inside a JSON response."
|
||||
"sourcesHeading": "Available-version sources",
|
||||
"sources": [
|
||||
"<strong>GitHub repository</strong>: latest release or tag from a public <code>owner/name</code> repository.",
|
||||
"<strong>HTTP JSON</strong>: a public endpoint plus a dotted path such as <code>data.version</code> or <code>releases[0].tag_name</code>.",
|
||||
"<strong>Docker Hub</strong>: versioned tags filtered by a regular expression. A live preview shows real matching tags before the record is saved.",
|
||||
"Moving tags such as <code>latest</code>, <code>stable</code> or <code>lts</code> do not contain a version. Track those images by digest from Docker image updates instead."
|
||||
],
|
||||
"sourceTrailing": "Always use the app's official source. A fork or a third-party endpoint may announce versions that don't match the installation in the LXC.",
|
||||
"regexHeading": "Version regular expressions",
|
||||
"regexIntro": "A regular expression, or <strong>regex</strong>, isolates the version number inside a longer text. Most projects don't publish a ready-made regex — the user builds one from real output or a real release name.",
|
||||
"regexOptional": "It is not always needed. Leave it empty first if the source already returns a clean value like <code>2.14.3</code>. Add one only when ProxMenux needs to separate the version from other words, symbols or numbers.",
|
||||
"regexTwoHeading": "There are two different regex fields",
|
||||
"regexTwoItems": [
|
||||
"<strong>Installed version regex</strong> is applied to the output read inside the LXC.",
|
||||
"<strong>Version regex</strong> or <strong>Tag regex</strong> is applied to the release / tag name published by the external source."
|
||||
"regexHeading": "Writing the capture expression",
|
||||
"regexLead": "A detector regular expression must return the version in its <strong>first capture group</strong>.",
|
||||
"regexRules": [
|
||||
"Match the text emitted by the selected binary, file, command or tag source; do not guess a generic path.",
|
||||
"Escape literal dots as <code>\\.</code> so they cannot match arbitrary characters.",
|
||||
"Allow a leading <code>v</code> only when the source can include it.",
|
||||
"Include suffixes such as prerelease or distro revisions only when they are meaningful for the comparison.",
|
||||
"Use <strong>Test detector</strong> before saving and verify that the displayed installed version matches the LXC."
|
||||
],
|
||||
"regexTwoTrailing": "Both must produce comparable values. For instance, if the local app returns <code>MyApp v2.14.3</code> and GitHub publishes <code>release-2.14.3</code>, both expressions should extract <code>2.14.3</code>.",
|
||||
"step1Heading": "1. Capture a real sample",
|
||||
"step1P1": "Before writing the pattern, capture exactly the text ProxMenux will have to interpret.",
|
||||
"step1P2": "For the installed version, run the same binary and arguments configured in the form from the LXC console. Depending on the method, you may also query the corresponding package or file.",
|
||||
"step1P3": "For example:",
|
||||
"step1Cmd": "myapp --version",
|
||||
"step1P4": "Suppose the real output is:",
|
||||
"step1Output": "MyApp version v2.14.3 (stable)",
|
||||
"step1P5": "For the published version, check the exact release or tag name in the official repository. If you use a JSON endpoint, inspect the value the configured path returns.",
|
||||
"step1P6": "Do not build the pattern against an invented example — a single space, prefix or extra number can change the result.",
|
||||
"step2Heading": "2. Identify the part to keep",
|
||||
"step2Lead": "In the example above we want to keep <code>2.14.3</code> and drop:",
|
||||
"step2Items": [
|
||||
"The text <code>MyApp version</code>.",
|
||||
"The letter <code>v</code>.",
|
||||
"The text <code>(stable)</code>."
|
||||
],
|
||||
"step2Recommended": "The recommended expression:",
|
||||
"step2Regex": "version[ :=]+v?([0-9]+\\.[0-9]+\\.[0-9]+)",
|
||||
"step2ReadLead": "Read piece by piece:",
|
||||
"step2Breakdown": {
|
||||
"colPart": "Fragment",
|
||||
"colMeaning": "Meaning",
|
||||
"rows": [
|
||||
{ "part": "version", "meaning": "Anchors the search on that word to avoid matching an unrelated number." },
|
||||
{ "part": "[ :=]+", "meaning": "Accepts one or more spaces, colons or equal signs." },
|
||||
{ "part": "v?", "meaning": "The letter v may appear once or not at all." },
|
||||
{ "part": "( and )", "meaning": "Mark the portion ProxMenux should keep." },
|
||||
{ "part": "[0-9]+", "meaning": "Matches one or more digits." },
|
||||
{ "part": "\\.", "meaning": "Matches a literal dot between the numbers." }
|
||||
]
|
||||
},
|
||||
"step2DotNote": "The dot is written as <code>\\.</code> because, in a regex, a bare dot means \"any character\".",
|
||||
"step3Heading": "3. Pick a pattern that fits the format",
|
||||
"step3Lead": "These patterns cover the most common cases:",
|
||||
"step3Examples": {
|
||||
"colText": "Sample text",
|
||||
"colRegex": "Recommended regex",
|
||||
"colResult": "Result",
|
||||
"rows": [
|
||||
{ "text": "v2.14.3", "regex": "v?([0-9]+\\.[0-9]+\\.[0-9]+)", "result": "2.14.3" },
|
||||
{ "text": "Version: 2.14", "regex": "Version[ :=]+v?([0-9]+(?:\\.[0-9]+){1,3})", "result": "2.14" },
|
||||
{ "text": "release-2.14.3.1", "regex": "release-v?([0-9]+(?:\\.[0-9]+){1,3})", "result": "2.14.3.1" },
|
||||
{ "text": "build 2026.08.10", "regex": "build[ :=]+([0-9]{4}\\.[0-9]{1,2}\\.[0-9]{1,2})", "result": "2026.08.10" },
|
||||
{ "text": "{\"version\":\"2.14.3\"}", "regex": "\"version\"\\s*:\\s*\"v?([0-9]+(?:\\.[0-9]+){1,3})\"", "result": "2.14.3" }
|
||||
]
|
||||
},
|
||||
"step3Note1": "<code>(?: ... )</code> groups a fragment of the pattern without producing an extra output value. This form is convenient to accept versions with two, three or four blocks without complicating the result.",
|
||||
"step3Note2": "Enter the regex exactly as shown in the table: without surrounding quotes and without the <code>/.../</code> delimiters some online tools use.",
|
||||
"step4Heading": "4. Prefer a single capture",
|
||||
"step4Intro": "ProxMenux uses capture groups to decide which value to return:",
|
||||
"step4Items": [
|
||||
"With no capture groups it keeps the whole match.",
|
||||
"With one capture, it keeps that capture's content.",
|
||||
"With several captures, it joins them with dots."
|
||||
],
|
||||
"step4Trailing": "For predictable results, wrap the whole version in a single capture and use <code>(?: ... )</code> for helper groups.",
|
||||
"step4RecLabel": "Recommended:",
|
||||
"step4RecRegex": "v?([0-9]+(?:\\.[0-9]+){1,3})",
|
||||
"step4LessLabel": "Less clear for beginners:",
|
||||
"step4LessRegex": "v?([0-9]+)\\.([0-9]+)\\.([0-9]+)",
|
||||
"step4Note": "Both can produce <code>2.14.3</code>, but the first is easier to maintain if the format changes.",
|
||||
"step5Heading": "5. Avoid overly broad matches",
|
||||
"step5Lead": "A pattern like this one is usually too open:",
|
||||
"step5Regex": "([0-9.]+)",
|
||||
"step5P1": "It can capture a year, a port, a dependency version or the first number that appears in the output. Anchor it with a nearby word such as <code>version</code>, <code>release</code> or <code>build</code> when the text carries several numbers.",
|
||||
"step5P2": "Also confirm the upstream source isn't mixing stable releases with beta, nightly or development builds. The regex must select the same channel that is installed in the LXC.",
|
||||
"step6Heading": "6. Save and verify the result",
|
||||
"step6Lead": "After saving the app, press <strong>Check</strong> and read the two values ProxMenux reports:",
|
||||
"step6Output": "Installed: 2.14.3\nLatest: 2.15.0",
|
||||
"step6CorrectLead": "The regex is correct when:",
|
||||
"step6CorrectItems": [
|
||||
"Both fields contain only the expected version.",
|
||||
"The application name and extra text are not captured.",
|
||||
"The version is not confused with any other number.",
|
||||
"Local and published values use the same format."
|
||||
],
|
||||
"step6ErrorNote": "If the match errors out, capture the real output again and compare it character by character. Pay particular attention to uppercase, spaces, hyphens, the letter <code>v</code> and the number of version blocks.",
|
||||
"step6Callout": "If you can't build a reliable pattern, prefer to disable upstream tracking temporarily and keep the app as a link-only record. A wrong regex can raise false alerts or hide a real update."
|
||||
"regexExampleLead": "Common semantic-version capture:",
|
||||
"regexExample": "v?(\\d+\\.\\d+\\.\\d+)",
|
||||
"regexCallout": "A successful regex match is not proof that the detector path is correct. The path or package must also exist in the real installation being registered."
|
||||
},
|
||||
"state": {
|
||||
"heading": "Reading an app's state",
|
||||
"lead": "A registered app can display any of the following states:",
|
||||
"updater": {
|
||||
"heading": "Version tracking and updating are independent",
|
||||
"lead": "The <link>Updates tab</link> creates an app section as soon as any application record is saved.",
|
||||
"items": [
|
||||
"<strong>Up to date</strong> — versions match.",
|
||||
"<strong>Update available</strong> — the source publishes a newer version.",
|
||||
"<strong>Checking</strong> — the check is in progress.",
|
||||
"<strong>Version tracking pending</strong> — no check has completed yet.",
|
||||
"<strong>Error</strong> — one of the versions could not be read or parsed."
|
||||
],
|
||||
"trailing": "Use <strong>Check</strong> to repeat the query manually after tweaking the configuration. If an error appears, review the installed-version method, the upstream source and the regex patterns first."
|
||||
"A link-only record shows that version tracking is not configured, but can still receive a custom update command.",
|
||||
"An app with tracking but without an executable method shows a neutral message asking for a custom command.",
|
||||
"An app with a verified Proxmox VE Helper-Scripts wrapper can use that integrated updater even when the registration began from a web link.",
|
||||
"Adding or editing an updater does not change the detector or upstream source stored on the App tab."
|
||||
]
|
||||
},
|
||||
"manage": {
|
||||
"heading": "Managing existing records",
|
||||
"lead": "Enter management mode to:",
|
||||
"states": {
|
||||
"heading": "Version states on the App card",
|
||||
"colState": "State",
|
||||
"colDisplay": "Display",
|
||||
"colMeaning": "Meaning",
|
||||
"rows": [
|
||||
{ "state": "Update available", "display": "Available version in purple with an upward-arrow icon", "meaning": "The installed and upstream versions differ." },
|
||||
{ "state": "Current", "display": "Installed and latest versions without the purple alert", "meaning": "The last check found no newer upstream version." },
|
||||
{ "state": "Tracking pending", "display": "Checking or pending state", "meaning": "The record is configured but has not completed both checks yet." },
|
||||
{ "state": "Tracking disabled", "display": "Web links only; no version comparison block", "meaning": "The record remains valid and can still have an updater." },
|
||||
{ "state": "Check error", "display": "Amber explanation inside the card", "meaning": "The previous saved state remains visible while the detector or upstream error is reported." }
|
||||
]
|
||||
},
|
||||
"management": {
|
||||
"heading": "Managing saved and suggested apps",
|
||||
"lead": "The actions at the bottom of the tab have distinct roles:",
|
||||
"items": [
|
||||
"Re-check an app.",
|
||||
"Edit its name, links or version tracking.",
|
||||
"Delete a record that is no longer needed.",
|
||||
"Add another app to the same LXC."
|
||||
],
|
||||
"trailing": "Deleting a record does not uninstall or stop the app. It only removes the information ProxMenux uses to display it and monitor its version."
|
||||
"<strong>Find applications</strong> refreshes discovery for this LXC only.",
|
||||
"<strong>Register another application</strong> opens the catalog and manual editor without rescanning the LXC.",
|
||||
"<strong>Edit</strong> reveals per-card Remove, Check, notification and Edit fields actions.",
|
||||
"<strong>Hide</strong> removes an unwanted suggestion. Hidden detections can be restored from the registration browser.",
|
||||
"<strong>Check</strong> refreshes the selected saved app's version evidence; it does not search for new apps."
|
||||
]
|
||||
},
|
||||
"options": {
|
||||
"heading": "Optional toggles",
|
||||
"lead": "Two independent switches sit under the version tracking options:",
|
||||
"items": [
|
||||
"<strong>Notify me when a new upstream version is available</strong> — sends the <code>app_update_available</code> event to the channels enabled in <strong>Settings → Notifications</strong>.",
|
||||
"<strong>Exclude from the LXC updates counter</strong> — leaves this app out of the aggregate updates badge shown on the LXC list card."
|
||||
],
|
||||
"trailing": "Both toggles can be set independently. The App tab still shows the real state of each registered app regardless of these choices."
|
||||
"troubleshooting": {
|
||||
"heading": "Common situations",
|
||||
"colProblem": "Situation",
|
||||
"colResolution": "Resolution",
|
||||
"rows": [
|
||||
{ "problem": "Software was installed after ProxMenux started", "resolution": "Press Find applications. The explicit scan updates cached suggestions for that LXC." },
|
||||
{ "problem": "No application was detected", "resolution": "Register it manually. A name and one web link are sufficient; tracking can be added later." },
|
||||
{ "problem": "The suggested detector returns the wrong version", "resolution": "Open Edit fields, select the real package, binary or file path and test the detector before saving." },
|
||||
{ "problem": "A Docker workload is not offered as an LXC app", "resolution": "Register Docker and add the workload's published interface as a Docker web link. Image updates remain in the Docker section." },
|
||||
{ "problem": "A saved app has no update button", "resolution": "Open the Updates tab and configure its update method. Version tracking alone does not define how an update is installed." }
|
||||
]
|
||||
},
|
||||
"notDetected": {
|
||||
"heading": "If the app is not detected",
|
||||
"intro": "Automatic detection is not required to use this feature. If no suggestion appears:",
|
||||
"steps": [
|
||||
"Register the app manually.",
|
||||
"Add its known links and ports.",
|
||||
"Leave it as <strong>None (link only)</strong> if you only need a shortcut.",
|
||||
"Configure version tracking only when a reliable source has been identified for both values.",
|
||||
"Configure the update method later from <link>Updates</link>, if you want ProxMenux to run it."
|
||||
],
|
||||
"trailing": "Don't invent a package name, path or regex just to fill the form. A simple, correct record beats an automatic tracking based on unverified data."
|
||||
"figures": {
|
||||
"catalog": {
|
||||
"alt": "Application registration catalog with search results, logos, ports and detector fields",
|
||||
"caption": "Catalog metadata accelerates registration while every proposed value remains editable."
|
||||
},
|
||||
"webLinks": {
|
||||
"alt": "Saved LXC application card containing a clickable web link",
|
||||
"caption": "A link-only record is valid: version tracking can stay disabled and an updater can be added independently."
|
||||
},
|
||||
"tracking": {
|
||||
"alt": "Optional installed-version detector and upstream source fields",
|
||||
"caption": "Installed-version detection and the upstream source are configured and tested separately."
|
||||
},
|
||||
"card": {
|
||||
"alt": "Saved application card with installed and available versions plus a web link",
|
||||
"caption": "The card combines identity, version evidence and web access without running update actions from this tab."
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,231 +1,194 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Updates — updating an LXC's system and apps | ProxMenux",
|
||||
"description": "Which mechanisms ProxMenux can use to update the operating system and the applications registered in an LXC container."
|
||||
"title": "LXC updates: OS, apps and Docker | ProxMenux",
|
||||
"description": "Configure and run operating-system, application, Docker Engine and Docker image updates from an LXC container."
|
||||
},
|
||||
"header": {
|
||||
"title": "Updates — updating an LXC's system and apps",
|
||||
"description": "Where ProxMenux decides how to upgrade a container: OS packages, Community Scripts helper, or a custom command."
|
||||
"title": "LXC updates: OS, apps and Docker",
|
||||
"description": "Review every update target in one place, run it independently, or combine selected targets in a controlled bulk action."
|
||||
},
|
||||
"intro": {
|
||||
"p1": "The <strong>Updates</strong> tab gathers the mechanisms ProxMenux can run to upgrade the operating system and the applications registered inside an LXC container.",
|
||||
"p2": "The <link>App tab</link> declares which applications exist and, optionally, compares their versions. <strong>Updates</strong> is about the action: it decides which mechanism is available, presents the matching button and runs the upgrade inside the container.",
|
||||
"callout": "<strong>Core idea:</strong> detecting a new version and knowing how to install it are two different jobs. An app can show <strong>Update available</strong> on the App tab and still not have a working update button until a valid method is defined."
|
||||
"p1": "The <strong>Updates</strong> tab separates version detection from the action that installs an update. Registration and optional version tracking live on the <link>App tab</link>; executable update methods live here.",
|
||||
"p2": "A saved application appears in Updates even when it contains only a web link. Version tracking is optional, and an updater can be configured independently.",
|
||||
"callout": "No action is inferred from an application name alone. ProxMenux runs an integrated method only after verifying it, or a custom command that has been explicitly saved."
|
||||
},
|
||||
"overview": {
|
||||
"heading": "What the tab contains",
|
||||
"lead": "Each available target has its own section and action:",
|
||||
"items": [
|
||||
"<strong>OS packages</strong> for Debian, Ubuntu and Alpine containers.",
|
||||
"One section for every <strong>registered application</strong>, including link-only records.",
|
||||
"A <strong>Docker</strong> section when Docker is registered, with Docker Engine and tagged images grouped together.",
|
||||
"A configurable <strong>Bulk update</strong> section, followed by backup, restart and scheduling options."
|
||||
]
|
||||
},
|
||||
"mechanisms": {
|
||||
"heading": "Available update mechanisms",
|
||||
"intro": "Depending on how the app was installed and where its updates come from, ProxMenux picks from three mechanisms.",
|
||||
"osHeading": "Operating system packages",
|
||||
"osP1": "On Debian or Ubuntu containers, ProxMenux queries and updates packages through APT. On Alpine, it uses APK.",
|
||||
"osP2": "Registered apps whose install method is <code>dpkg</code> or <code>apk</code> are part of this pass. They don't need a second command in the app section — they update as part of <strong>Apply OS update</strong>.",
|
||||
"osP3": "The section shows the number of pending packages, how many are security updates, the OS family and the time of the last check.",
|
||||
"helperHeading": "Proxmox VE Helper-Scripts updater",
|
||||
"helperP1": "When the LXC was created with a helper from the <linkHelperHome>Proxmox VE Helper-Scripts</linkHelperHome> project, ProxMenux recognises its updater. The matching app must be registered on the App tab so the Monitor can associate the helper with the service shown to the user.",
|
||||
"helperP2": "<strong>The update logic itself is maintained by the Proxmox VE Helper-Scripts project</strong>, not by ProxMenux. Each helper ships its own <code>update_script</code> function; ProxMenux fetches it and runs it inside the container in silent mode (<code>PHS_SILENT=1</code>), without prompts. There is no need to copy the helper or write a custom command on the ProxMenux side.",
|
||||
"helperP3": "Full documentation for the update mechanism lives on the project site — <linkHelperDocs>community-scripts.org / update-apps</linkHelperDocs>. Each helper also has its own entry on the <linkHelperHome>project site</linkHelperHome> with a description of what the script does, its default configuration and the source of the update logic — use that page as the reference for what the updater will change inside the LXC.",
|
||||
"helperP4": "Not every helper supports in-place updates. If the catalog marks an application as non-upgradable, the tab will surface that state and won't present this method as available.",
|
||||
"customHeading": "Custom command",
|
||||
"customP1": "A registered app can store its own update command. ProxMenux runs it inside the LXC when the user presses <strong>Apply update</strong> or when a scheduled task includes that app.",
|
||||
"customP2": "This method is designed for apps whose installer provides no recognised helper and that don't update as part of APT or APK."
|
||||
"heading": "How an update method is selected",
|
||||
"lead": "The integrated Proxmox VE Helper-Scripts path follows the official <helper>update-apps mechanism</helper>. Other install types use the matching package, Docker or custom path.",
|
||||
"colSource": "Source",
|
||||
"colAction": "Displayed action",
|
||||
"colNotes": "What runs",
|
||||
"rows": [
|
||||
{
|
||||
"source": "APT or APK packages",
|
||||
"action": "Apply OS updates",
|
||||
"notes": "Updates the container packages. Registered apps installed as dpkg or apk packages are covered by this same pass."
|
||||
},
|
||||
{
|
||||
"source": "Proxmox VE Helper-Scripts",
|
||||
"action": "Apply update",
|
||||
"notes": "Uses the verified /usr/bin/update wrapper. A legacy marker without a valid wrapper is identified, but never executed automatically."
|
||||
},
|
||||
{
|
||||
"source": "Custom command",
|
||||
"action": "Run updater",
|
||||
"notes": "Runs the saved command inside the LXC and replaces any integrated app updater for that record."
|
||||
},
|
||||
{
|
||||
"source": "Docker Engine",
|
||||
"action": "Update Docker Engine",
|
||||
"notes": "Updates only installed Docker packages and their required dependencies. Other OS packages and containers are not changed."
|
||||
},
|
||||
{
|
||||
"source": "Docker image",
|
||||
"action": "Update image",
|
||||
"notes": "Pulls the selected image and recreates its Compose service group or protected standalone container."
|
||||
}
|
||||
],
|
||||
"callout": "A custom command always <strong>replaces</strong> the integrated Proxmox VE Helper-Scripts updater for that application. The two methods are not run one after the other."
|
||||
},
|
||||
"decision": {
|
||||
"heading": "How ProxMenux picks the action to show",
|
||||
"table": {
|
||||
"colSituation": "Situation",
|
||||
"colAction": "Action",
|
||||
"rows": [
|
||||
{ "situation": "APT or APK packages pending", "action": "Apply OS update" },
|
||||
{ "situation": "The app uses a dpkg or apk package", "action": "Apply OS update — no separate app command needed" },
|
||||
{ "situation": "A compatible helper exists and the app is registered", "action": "Apply update via Community Scripts" },
|
||||
{ "situation": "The registered app has a custom command", "action": "Apply update using that command" },
|
||||
{ "situation": "A new version exists but no helper or command is configured", "action": "Shows No updater configured; offers to add a command" },
|
||||
{ "situation": "System and app updates are both available", "action": "Combined Apply OS + Apps updates action may appear" }
|
||||
]
|
||||
},
|
||||
"trailing": "An app registered only as a link is never shown as upgradable — ProxMenux doesn't have enough information to wire an update method to it."
|
||||
"docker": {
|
||||
"heading": "Docker Engine and Docker images",
|
||||
"lead": "After Docker is registered on the App tab, its engine and image inventory appear inside the same <strong>Docker</strong> section.",
|
||||
"items": [
|
||||
"Docker Engine version tracking is separate from the OS package counter and has its own update button.",
|
||||
"Tagged local images are compared with their registry by immutable digest. <strong>Check now</strong> refreshes this inventory without pulling images or restarting containers.",
|
||||
"Compose services are updated from their declared project. Images that belong to the same service group are handled together so the project is not recreated repeatedly.",
|
||||
"A standalone container is recreated from its current configuration. The protected flow keeps rollback data and restores the previous container if recreation fails.",
|
||||
"Every image can be selected separately in manual, bulk and scheduled updates, except declared Compose dependencies that must follow their parent service."
|
||||
],
|
||||
"callout": "Containers running inside Docker are not shown as independent LXC applications. Their published web ports can be saved as links under the Docker registration, while image updates remain in the Docker section."
|
||||
},
|
||||
"figures": {
|
||||
"f01": {
|
||||
"alt": "OS packages card showing pending updates count, security-updates count and the Apply OS update button",
|
||||
"caption": "Pending OS packages: total count, security-updates count, and the Apply OS update button"
|
||||
},
|
||||
"f02": {
|
||||
"alt": "Same OS packages card after applying updates — no packages pending, OS up to date badge",
|
||||
"caption": "After applying: 'No OS updates pending' and the OS up to date badge"
|
||||
},
|
||||
"f03": {
|
||||
"alt": "Registered app card showing 'No update method available' and an Add custom update command button",
|
||||
"caption": "'No update method available' — ProxMenux tracks the app but has nothing wired to upgrade it yet"
|
||||
},
|
||||
"f04": {
|
||||
"alt": "Custom update command editor with the example placeholder visible inside the textarea",
|
||||
"caption": "The custom command editor with its placeholder example, Cancel and Save buttons"
|
||||
},
|
||||
"f05": {
|
||||
"alt": "Terminal panel labelled 'Apply updates — CT 103' showing live apt output as packages are unpacked",
|
||||
"caption": "Terminal panel streaming the update output live while apt unpacks packages inside the CT"
|
||||
},
|
||||
"f06": {
|
||||
"alt": "Options card with snapshot before applying enabled, backup storage set to pbs, and restart after applying enabled",
|
||||
"caption": "Options card with vzdump snapshot, backup storage and restart-after-applying enabled together"
|
||||
},
|
||||
"f07": {
|
||||
"alt": "Scheduled updates section enabled — Frequency set to Daily at 3:00, cron expression 0 3 * * *, and What to update set to OS + application",
|
||||
"caption": "Scheduled updates enabled — frequency preset, matching cron expression and target scope selected"
|
||||
}
|
||||
"actions": {
|
||||
"heading": "Individual actions and status colours",
|
||||
"lead": "Every section remains independently actionable, whether or not a bulk update is configured.",
|
||||
"items": [
|
||||
"The <strong>Edit</strong> button is always available. Integrated methods open with their current command, which can be reviewed, replaced or cleared.",
|
||||
"When version tracking is disabled but an updater exists, the neutral <strong>Run updater</strong> action is shown. ProxMenux does not claim that an update is pending.",
|
||||
"When no method is available, <strong>Configure</strong> opens the custom-command editor.",
|
||||
"The <strong>Update image</strong> action applies only to the selected Docker unit; it does not update Docker Engine or unrelated images."
|
||||
],
|
||||
"statusColState": "Known state",
|
||||
"statusColAppearance": "Appearance",
|
||||
"statusColMeaning": "Meaning",
|
||||
"statusRows": [
|
||||
{
|
||||
"state": "Verified update available",
|
||||
"appearance": "Purple text, upward-arrow icon and purple action",
|
||||
"meaning": "Installed and available versions or image digests differ."
|
||||
},
|
||||
{
|
||||
"state": "Verified current",
|
||||
"appearance": "Green check and green Updated action",
|
||||
"meaning": "The latest completed check confirms that the target is current."
|
||||
},
|
||||
{
|
||||
"state": "Version unknown",
|
||||
"appearance": "Neutral text and neutral action",
|
||||
"meaning": "An updater can run, but no version evidence exists to label it pending or current."
|
||||
}
|
||||
]
|
||||
},
|
||||
"custom": {
|
||||
"heading": "Adding a custom update command",
|
||||
"p1": "When an app has version tracking but no update method, the tab shows <strong>No updater configured</strong>. Press <strong>Add custom update command</strong> to open the editor.",
|
||||
"p2": "The command must represent the real, complete procedure that upgrades that app. Don't just paste the command that reads its version."
|
||||
},
|
||||
"figureOut": {
|
||||
"heading": "How to figure out the correct command",
|
||||
"intro": "There is no universal update command. Before saving one, identify how the software was installed and what the project's recommended upgrade path is.",
|
||||
"step1Heading": "1. Check whether the system already handles it",
|
||||
"step1P1": "If the app was installed from Debian, Ubuntu or Alpine repositories it usually upgrades with system packages. In that case don't add a custom command — use <strong>Apply OS update</strong>.",
|
||||
"step1P2": "You can check the package origin from the LXC console with the distro's tooling. For example:",
|
||||
"step1Cmd1": "dpkg -l | grep -i name",
|
||||
"step1P3": "or:",
|
||||
"step1Cmd2": "apk info | grep -i name",
|
||||
"step1P4": "Replace <code>name</code> with the package you are investigating. A match doesn't automatically confirm it's the main package — cross-check the name against the app's documentation.",
|
||||
"step2Heading": "2. Consult the official documentation",
|
||||
"step2P1": "Look in the official docs or repository for sections like <strong>Upgrade</strong>, <strong>Update</strong>, <strong>Maintenance</strong> or <strong>Manual installation</strong>. The procedure must match the method used to install the app in that LXC.",
|
||||
"step2P2": "Don't use instructions targeting a different distribution, a different install type or a different version.",
|
||||
"step3Heading": "3. Inspect the existing installation",
|
||||
"step3Lead": "If you don't remember how the app was installed, look at:",
|
||||
"step3Items": [
|
||||
"The history or notes of the original installer.",
|
||||
"The path where its files live.",
|
||||
"The service definition that starts it.",
|
||||
"Any maintenance scripts shipped by the app.",
|
||||
"The documentation stored inside its install directory."
|
||||
],
|
||||
"step3P1": "For a systemd service, this can help locate the binary and its working directory:",
|
||||
"step3Cmd": "systemctl show service-name -p ExecStart -p WorkingDirectory",
|
||||
"step3P2": "This helps identify the installation, but it does not automatically translate the <code>ExecStart</code> line into an update command.",
|
||||
"step4Heading": "4. Test the procedure in the LXC console",
|
||||
"step4Lead": "Open a console into the container and run the procedure manually before saving it in ProxMenux. Verify that it:",
|
||||
"step4Items": [
|
||||
"Finishes without prompts or interactive menus.",
|
||||
"Returns a correct exit code.",
|
||||
"Restarts or reloads only the services that need it.",
|
||||
"Leaves the app reachable afterwards.",
|
||||
"Changes the installed version as expected."
|
||||
],
|
||||
"step4Note": "When feasible, take a container backup before testing.",
|
||||
"step5Heading": "5. Save only the in-container command",
|
||||
"step5P1": "Enter only what would be executed inside the LXC. Don't include:",
|
||||
"step5Cmd1": "pct exec <vmid> --",
|
||||
"step5P2": "ProxMenux already handles entering the container. The command runs as <code>root</code> via <code>sh -c</code>, so it accepts chained operations and directory changes.",
|
||||
"step5P3": "If the updater must run from a specific path, include it explicitly:",
|
||||
"step5Cmd2": "cd /opt/my-app && ./update.sh",
|
||||
"step5P4": "If the project ships an updater at a different path, use the path and arguments named by the official documentation."
|
||||
},
|
||||
"requirements": {
|
||||
"heading": "Requirements for a reliable command",
|
||||
"lead": "Before running it from the Monitor, confirm the command:",
|
||||
"heading": "Custom update commands",
|
||||
"lead": "Use a custom command when the installation has no verified integrated updater, or when its normal procedure must be replaced.",
|
||||
"items": [
|
||||
"Runs without user interaction.",
|
||||
"Uses absolute paths or changes into the correct directory first.",
|
||||
"Stops, migrates and restarts services as required by the official instructions.",
|
||||
"Exits with an error when the update fails.",
|
||||
"Does not contain visible passwords, tokens or other secrets.",
|
||||
"Does not download or execute scripts from untrusted sources."
|
||||
"Open <strong>Configure</strong> when the field is empty, or <strong>Edit</strong> when a method already exists.",
|
||||
"For an integrated app or Docker Engine, the editor shows the command currently used. Saving different content turns it into the explicit override for that record.",
|
||||
"Test the complete procedure in the LXC terminal first. It must be non-interactive, use the correct working directory and return a non-zero exit status on failure.",
|
||||
"Do not include <code>pct exec</code>; ProxMenux already enters the container and runs the command as root."
|
||||
],
|
||||
"trailing": "The content is stored in the LXC's configuration and executed with administrator privileges. Treat it with the same care as any command run as <code>root</code>."
|
||||
"exampleLead": "Example of a complete in-container procedure:",
|
||||
"example": "cd /opt/my-app && ./update.sh",
|
||||
"callout": "A version command such as <code>myapp --version</code> only reads a version; it is not an updater. Commands run with administrative privileges, so stored content must be reviewed with the same care as a root shell command."
|
||||
},
|
||||
"difference": {
|
||||
"heading": "Difference between the detection command and the update command",
|
||||
"lead": "Both fields have different goals:",
|
||||
"table": {
|
||||
"colField": "Field",
|
||||
"colLocation": "Location",
|
||||
"colRole": "Role",
|
||||
"rows": [
|
||||
{
|
||||
"field": "Command for the installed version",
|
||||
"location": "App → advanced tracking",
|
||||
"role": "Reads and returns the current version; executed as an argument list without a shell."
|
||||
},
|
||||
{
|
||||
"field": "Custom update command",
|
||||
"location": "Updates",
|
||||
"role": "Runs the upgrade procedure; interpreted via sh -c."
|
||||
}
|
||||
]
|
||||
},
|
||||
"trailing": "Don't blindly copy the value of one into the other. A command like <code>myapp --version</code> may correctly detect the version but won't install a new one."
|
||||
},
|
||||
"apply": {
|
||||
"heading": "Applying an update",
|
||||
"lead": "Before pressing an apply button:",
|
||||
"steps": [
|
||||
"Confirm what will be updated: system, one app or both.",
|
||||
"Check the backup and restart options.",
|
||||
"Press the matching button.",
|
||||
"Follow the process output in the terminal panel.",
|
||||
"Verify the final result and that the service responds again."
|
||||
"bulk": {
|
||||
"heading": "Bulk update",
|
||||
"lead": "Bulk update creates one reusable action for an exact set of targets in the LXC. It is placed after the individual app and Docker sections and before <strong>Options</strong>.",
|
||||
"items": [
|
||||
"OS packages are mandatory. At least one additional app, Docker Engine or Docker image unit must be selected.",
|
||||
"Applications and Docker units are selected individually. A Compose parent shows the dependencies that will be updated with it.",
|
||||
"Unavailable or removed targets are marked as stale and must be removed before the configuration can be saved.",
|
||||
"The <strong>Apply updates</strong> button is purple when any selected target has a verified update, green when all selected targets are verified current, and neutral when the result is unknown.",
|
||||
"Removing the bulk configuration does not remove individual update methods or scheduled-update settings."
|
||||
],
|
||||
"trailing1": "If the LXC is stopped, ProxMenux starts it to run the process. If the update finishes correctly and the restart option is enabled, the container is restarted at the end.",
|
||||
"systemLead": "On a system update:",
|
||||
"systemItems": [
|
||||
"Debian and Ubuntu run the upgrade via APT.",
|
||||
"Alpine runs it via APK."
|
||||
],
|
||||
"appLead": "On an app update:",
|
||||
"appItems": [
|
||||
"The compatible helper is used, when it exists.",
|
||||
"The custom command stored for the app is executed, when configured.",
|
||||
"If several apps are selected, their methods run in sequence."
|
||||
],
|
||||
"trailing2": "The terminal panel shows progress and ends with a successful result or the process's error code."
|
||||
"callout": "Bulk update does not replace the individual buttons. It is an optional shortcut for a selection that should run together."
|
||||
},
|
||||
"backup": {
|
||||
"heading": "Backup before updating",
|
||||
"p1": "Enable <strong>Snapshot the container before applying</strong> to create a <code>vzdump</code> backup before touching the LXC. You can also choose the target storage.",
|
||||
"p2": "If the backup is requested and it fails, ProxMenux won't continue with the update. This prevents changes from starting without the requested recovery point.",
|
||||
"p3": "This option applies to both manual runs and scheduled runs."
|
||||
},
|
||||
"restart": {
|
||||
"heading": "Restart after updating",
|
||||
"p1": "<strong>Restart the container after applying</strong> is a preference, not a signal that the restart is mandatory. Enable it when the app's procedure or the installed packages require it.",
|
||||
"p2": "The restart only happens after a successful run. If the update fails, the container stays up so the error can be inspected.",
|
||||
"p3": "The backup and restart options are saved for that LXC and also apply to its scheduled tasks."
|
||||
"options": {
|
||||
"heading": "Backup and restart options",
|
||||
"lead": "The same options apply to manual, bulk and scheduled runs:",
|
||||
"items": [
|
||||
"<strong>Snapshot before applying</strong> creates a vzdump backup on the selected storage. If the required backup fails, the update does not start.",
|
||||
"<strong>Restart after applying</strong> restarts the LXC only after a successful run.",
|
||||
"The selections are stored per LXC and remain independent from the target list."
|
||||
]
|
||||
},
|
||||
"scheduled": {
|
||||
"heading": "Scheduled updates",
|
||||
"p1": "The <strong>Scheduled updates</strong> section runs automatically the same flow the manual buttons use.",
|
||||
"createLead": "To create a schedule:",
|
||||
"createSteps": [
|
||||
"Open <strong>Options</strong> and press <strong>Edit</strong>.",
|
||||
"Enable <strong>Scheduled updates</strong>.",
|
||||
"Choose a preset frequency or enter a cron expression.",
|
||||
"Select what will be updated: system packages only, applications only, or system and applications.",
|
||||
"Review the backup and restart options.",
|
||||
"Save the configuration."
|
||||
"lead": "Scheduled updates use the same executable targets and safety options as manual actions.",
|
||||
"items": [
|
||||
"Choose a preset or cron expression, then select exact targets: OS packages, individual apps, Docker Engine, standalone Docker units or Compose service groups.",
|
||||
"A release hold applies only to selected applications with version tracking. Apps without tracking run their updater whenever their schedule is due.",
|
||||
"The last-run state distinguishes success, partial completion, failure, safety hold and a run with nothing pending.",
|
||||
"External host schedules detected from Proxmox VE Helper-Scripts are shown separately so overlapping automation is visible."
|
||||
],
|
||||
"p2": "The card shows whether the schedule is active, what it covers and the outcome of the last run. A disabled schedule can be kept for later re-activation, or removed entirely.",
|
||||
"p3": "If ProxMenux detects an external schedule created by Community Scripts on the host, it surfaces it so the user knows another automation is already in place.",
|
||||
"callout": "Before scheduling app updates, test every helper or command manually. A scheduled task can't answer prompts or fix an incomplete procedure."
|
||||
"callout": "Run every selected method manually before enabling a schedule. Scheduled commands cannot answer prompts."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Checking the result",
|
||||
"p1": "After applying system packages, ProxMenux forces a fresh check to update the pending-package counter without waiting for the next periodic cycle.",
|
||||
"p2": "For an app, go back to the <link>App tab</link> and press <strong>Check</strong> if the version number doesn't refresh immediately. This runs the configured installed-version method again and queries the upstream source.",
|
||||
"p3": "Confirm additionally that the app's web links respond correctly. A command finishing without errors is not a substitute for functional verification of the service."
|
||||
"completion": {
|
||||
"heading": "What happens after an update",
|
||||
"lead": "The update is not considered finished when the terminal command merely exits.",
|
||||
"items": [
|
||||
"The same run records its final result and refreshes OS package state, registered app versions and Docker inventory as applicable.",
|
||||
"The LXC cache is replaced with the verified post-update state, so badges and buttons do not retain the previous result.",
|
||||
"If a stopped or restored LXC starts, the existing lifecycle event refreshes that LXC again. Docker inventory waits for the daemon to become ready instead of caching an empty startup result as final.",
|
||||
"Enabled notifications are emitted from the finalized run, including partial failures and grouped Docker image results."
|
||||
]
|
||||
},
|
||||
"troubleshoot": {
|
||||
"heading": "Common problems",
|
||||
"noButtonHeading": "Update available appears, but there's no Apply update button",
|
||||
"noButtonBody": "Version detection works, but no method to install the update was found. Check whether the app updates via system packages, a compatible helper or a custom command.",
|
||||
"aptHeading": "The app updates through APT or APK",
|
||||
"aptBody": "Use <strong>Apply OS update</strong>. Don't add a second command for the same operation — the app is already part of the system update.",
|
||||
"noUpdaterHeading": "No updater configured is shown",
|
||||
"noUpdaterBody": "ProxMenux tracks the app but doesn't know how to update it. Check its official documentation, test the procedure in the console and, if appropriate, save it via <strong>Add custom update command</strong>.",
|
||||
"helperDetectedHeading": "The helper is detected but can't be used",
|
||||
"helperDetectedBody": "The helper may be marked as non-upgradable or fall outside the recognised methods. Follow the app's official instructions and don't assume every LXC built with Community Scripts supports automatic updates.",
|
||||
"customFailsHeading": "The custom command fails",
|
||||
"customFailsBody": "Re-run it in the LXC console. Check the working path, permissions, dependencies, non-interactive arguments and exit code. Don't swap the command for a different variant until you've verified the recommended procedure with the project."
|
||||
"troubleshooting": {
|
||||
"heading": "Common situations",
|
||||
"colProblem": "Situation",
|
||||
"colResolution": "Resolution",
|
||||
"rows": [
|
||||
{
|
||||
"problem": "No update method has been identified",
|
||||
"resolution": "Open Configure, add the official non-interactive procedure and test it manually before scheduling it."
|
||||
},
|
||||
{
|
||||
"problem": "A Proxmox VE Helper-Scripts identity is shown but no action exists",
|
||||
"resolution": "The LXC has legacy identification data but no verified /usr/bin/update wrapper. Add a custom method only after confirming the correct procedure."
|
||||
},
|
||||
{
|
||||
"problem": "Docker images are temporarily empty after startup or restore",
|
||||
"resolution": "Wait for Docker to become ready or press Check now. The inventory retries startup and does not treat a transient empty result as final."
|
||||
},
|
||||
{
|
||||
"problem": "A saved bulk target is no longer available",
|
||||
"resolution": "Edit the bulk configuration, remove the stale target and select its current replacement if one exists."
|
||||
},
|
||||
{
|
||||
"problem": "A custom command fails",
|
||||
"resolution": "Run it in the LXC terminal and review its path, dependencies, non-interactive flags and exit code."
|
||||
}
|
||||
]
|
||||
},
|
||||
"figures": {
|
||||
"osPending": {
|
||||
"alt": "Operating-system packages section with pending and security update counts",
|
||||
"caption": "The operating-system section keeps package updates independent from application and Docker actions."
|
||||
},
|
||||
"options": {
|
||||
"alt": "LXC update options with pre-update backup and post-update restart",
|
||||
"caption": "Backup and restart preferences apply to manual, bulk and scheduled executions."
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -52,7 +52,7 @@
|
||||
},
|
||||
"drillIn": {
|
||||
"heading": "Per-guest drill-in modal",
|
||||
"intro": "The modal opens with a header showing the guest name, VMID, type badge (LXC / VM), state badge (RUNNING / STOPPED / …) and current uptime. Below the header are <strong>two tabs</strong> — <em>Status</em> and <em>Backups</em> — and a fixed action bar at the bottom of the modal with the four lifecycle controls (Start / Shutdown / Reboot / Force Stop) and, on running LXC containers, a Console button.",
|
||||
"intro": "The modal opens with the guest name, VMID, type, state and uptime. Its navigation adapts to the guest: <strong>Status</strong>, <strong>App</strong> and <strong>Updates</strong> for LXC application management, <strong>Mounts</strong> when an LXC has mount points, plus <strong>Backups</strong> and <strong>Firewall</strong>. The fixed action bar keeps the lifecycle controls and the LXC terminal available from every tab.",
|
||||
"statusTitle": "Tab 1 — Status",
|
||||
"statusImageAlt": "Per-guest drill-in modal — Status tab with CPU / Memory / Disk live cards, Disk and Network I/O totals, the OS distro logo, and the Resources / IP Addresses block",
|
||||
"statusImageCaption": "Status tab — live CPU / Memory / Disk with progress bars at the top, accumulated I/O totals (disk read/write, network down/up) below, then the static Resources block with Notes and + Info expansions and the IP Addresses pill list.",
|
||||
@@ -77,7 +77,17 @@
|
||||
],
|
||||
"ipsTitle": "4. IP Addresses",
|
||||
"ipsBody": "Pill list of every IPv4 / IPv6 address the guest currently exposes — green pill per address. Empty when the guest is stopped or when the QEMU agent isn't installed in a VM (LXCs always report addresses directly).",
|
||||
"mountsTitle": "Tab 2 — Mounts (LXC only)",
|
||||
"appTitle": "Tab 2 — App (LXC only)",
|
||||
"appIntro": "Registers applications that belong to the LXC, saves web links and optionally compares installed and available versions. Suggestions come from the startup cache; <strong>Find applications</strong> explicitly refreshes discovery for this LXC after new software is installed.",
|
||||
"appLinkLead": "See the",
|
||||
"appLinkLabel": "dedicated App page",
|
||||
"appLinkTail": "for cached discovery, catalog-assisted registration, Docker web links and version detectors.",
|
||||
"updatesTitle": "Tab 3 — Updates (LXC only)",
|
||||
"updatesIntro": "Keeps <strong>OS packages</strong>, registered applications, <strong>Docker Engine</strong> and Docker images as separate targets. Each target can run independently; an optional bulk action and a schedule can select the exact methods that should run together.",
|
||||
"updatesLinkLead": "See the",
|
||||
"updatesLinkLabel": "dedicated Updates page",
|
||||
"updatesLinkTail": "for integrated and custom updaters, Docker recreation, bulk selection, safety options and scheduling.",
|
||||
"mountsTitle": "Tab 4 — Mounts (LXC only, when present)",
|
||||
"mountsImageAlt": "LXC drill-in modal — Mounts tab listing every mount point the container is using: PVE volumes, host binds, binds from PVE storage and ad-hoc NFS/CIFS mounts the operator mounted from inside the CT. Each card carries a type badge, capacity bar, used/total bytes, mount options, and a colour-coded state dot (green healthy, amber readonly/divergent, red stale)",
|
||||
"mountsImageCaption": "Mounts tab — only renders for LXC containers, and only when at least one mount point or ad-hoc remote mount is present. A CT without mounts gets no tab.",
|
||||
"mountsIntro": "Proxmox's own UI shows the mount-point entries defined in the container config (<code>mpX</code>) but stops there — anything you mount from inside the CT later (<code>mount.cifs</code>, NFS via <code>autofs</code>, …) is invisible. This tab merges <strong>both views</strong>: the configured mounts <strong>and</strong> the runtime mounts ProxMenux probes from inside the container, with a per-mount health status and a capacity bar wherever the backend can resolve one.",
|
||||
@@ -96,7 +106,7 @@
|
||||
],
|
||||
"mountsCalloutTitle": "What this gives you over the native UI",
|
||||
"mountsCalloutBody": "A truthful, capacity-aware view of every place the container reads or writes. NFS or CIFS shares mounted from inside the CT — invisible to the Proxmox web UI — appear here with the same look and the same health probe as any configured mount point. Stale remote mounts and zombie binds are flagged before they bite during a backup.",
|
||||
"backupsTitle": "Tab 3 — Backups",
|
||||
"backupsTitle": "Tab 5 — Backups",
|
||||
"backupsImageAlt": "Per-guest drill-in modal — Backups tab with the available backups list, destination tag, sizes and the Create Backup button",
|
||||
"backupsImageCaption": "Backups tab — every backup stored on configured Proxmox storages for this guest, sorted newest first. The tab header carries the count badge.",
|
||||
"backupsIntro": "Lists every backup stored across configured Proxmox storages for this guest, sorted newest first. The tab title carries a count badge so you see at a glance whether the guest is backed up. Per row:",
|
||||
@@ -106,23 +116,7 @@
|
||||
"<strong>Size</strong> — final on-disk size of the backup."
|
||||
],
|
||||
"backupsOutro": "The <strong>+ Create Backup</strong> button at the top right kicks off a new run on the storage marked as \"Backup target\" in the Proxmox storage config. Restore lives in the Proxmox web UI — the Monitor exposes the \"is this guest backed up recently?\" view, not the recovery flow.",
|
||||
"updatesTitle": "Updates badge (LXC only)",
|
||||
"updatesImageAlt": "LXC drill-in modal — clickable violet 'updates available' badge in the header of a container that has pending apt or apk updates. Clicking it expands a panel listing every upgradable package with its current and target versions, plus a security-only counter when the underlying repo flags any of them as security",
|
||||
"updatesImageCaption": "The badge only appears on running LXC containers that have at least one upgradable package. Click it to open the package list inside the modal — no separate tab in the nav strip.",
|
||||
"updatesIntro": "ProxMenux probes every running container on the host once a day and counts the upgradable packages. Currently supported in this phase: <strong>Debian / Ubuntu</strong> via <code>apt list --upgradable</code> and <strong>Alpine</strong> via <code>apk list -u</code>. Containers running other distributions (CentOS, Arch, …) are skipped for now — they show no badge instead of a misleading zero.",
|
||||
"updatesPanelTitle": "What the panel shows",
|
||||
"updatesPanelItems": [
|
||||
"<strong>Total upgradable count</strong> at the top, plus a separate <strong>security</strong> counter when the underlying repository flags any of the packages as security (Debian/Ubuntu \"-security\" suite). Alpine doesn't expose a separate security suite via apk metadata, so security is always 0 on Alpine containers.",
|
||||
"<strong>Per-package list</strong> with name, current version and target version. Use this to decide whether to run the upgrade now or wait for a maintenance window."
|
||||
],
|
||||
"updatesScopeTitle": "What the system tracks vs what the script counts",
|
||||
"updatesScopeBody": "This update detector follows whatever is already installed inside the container — it does <strong>not</strong> install anything new and does <strong>not</strong> know about applications that were deployed outside apt / apk (a Docker container running inside the LXC, a Vaultwarden installed from source, a binary dropped into <code>/usr/local/bin</code>). It is a <em>package-manager</em> view, not an <em>application</em> view. Future phases of this work will integrate community-script application metadata so per-app upstream tracking (Vaultwarden, Jellyfin, …) becomes possible.",
|
||||
"updatesToggleTitle": "Detection vs notification — toggle semantics",
|
||||
"updatesToggleCalloutTitle": "Detection is always on; the toggle only controls the notification",
|
||||
"updatesToggleCalloutBody": "The package-update detection on running containers runs unconditionally — the badge appears in this modal whenever there are updates pending, regardless of any other setting. The <code>lxc_updates_available</code> notification toggle in <strong>Settings → Notifications</strong> only controls whether a grouped \"N CT(s) have pending updates\" message is delivered to your channels. This keeps the toggle semantics consistent with every other update stream (NVIDIA driver, Coral driver, ProxMenux optimizations): turning notifications off never hides the information in the dashboard.",
|
||||
"updatesApplyTitle": "Applying the updates",
|
||||
"updatesApplyBody": "Open the container shell from the bottom action bar, or use <code>pct exec <vmid> -- apt full-upgrade -y</code> / <code>pct exec <vmid> -- apk upgrade -y</code> from the host. The dashboard re-scans on its 24h cycle (or after the next manual refresh) and the badge updates.",
|
||||
"firewallTitle": "Tab 5 — Firewall",
|
||||
"firewallTitle": "Tab 6 — Firewall",
|
||||
"firewallIntro": "Reads the per-guest Proxmox firewall log straight from the host (no extra service, no polling). The tab is always present in the navigation strip; the panel decides what to render depending on whether the firewall is enabled for that guest and whether any rule is actually logging:",
|
||||
"firewallItems": [
|
||||
"<strong>Firewall disabled</strong> — an amber notice explains exactly where to enable it in the Proxmox UI (<em><Container|VM> → Firewall → Options</em>) and reminds you that at least one rule needs <code>log: info</code> (or higher) before packets show up.",
|
||||
|
||||
Reference in New Issue
Block a user