mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-09-14 18:56:52 +00:00
docs(monitor): new App + Updates sub-pages for VMs & LXCs with i18n
This commit is contained in:
MacRimi
@@ -0,0 +1,272 @@
|
||||
{
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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>."
|
||||
},
|
||||
"whatYouGet": {
|
||||
"heading": "What you get by registering an app",
|
||||
"lead": "Depending on the data configured, ProxMenux can surface:",
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"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",
|
||||
"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>."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"state": {
|
||||
"heading": "Reading an app's state",
|
||||
"lead": "A registered app can display any of the following states:",
|
||||
"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."
|
||||
},
|
||||
"manage": {
|
||||
"heading": "Managing existing records",
|
||||
"lead": "Enter management mode to:",
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,231 @@
|
||||
{
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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"
|
||||
}
|
||||
},
|
||||
"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:",
|
||||
"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."
|
||||
],
|
||||
"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>."
|
||||
},
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
],
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
},
|
||||
"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."
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user