mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-02 19:02:31 +00:00
docs: review post-install documentation in all seven translations
This commit is contained in:
Jonatan
@@ -1,13 +1,13 @@
|
||||
{
|
||||
"meta": {
|
||||
"title": "Automated Post-Install Script | ProxMenux Documentation",
|
||||
"description": "The ProxMenux Automated post-install script applies a curated set of 14 safe, hardware-aware optimizations to a fresh Proxmox VE host with zero prompts. Reversible configuration changes are registered for later restoration.",
|
||||
"description": "The ProxMenux Automated post-install script runs a fixed set of 14 hardware-aware optimizations on a fresh Proxmox VE host. It has no feature-selection checklist, but banner removal, some Log2RAM installations and rebooting can ask for confirmation. Reversible configuration changes are registered for later restoration.",
|
||||
"ogTitle": "Automated Post-Install Script | ProxMenux Documentation",
|
||||
"ogDescription": "14 curated optimizations applied to a fresh Proxmox VE host with zero prompts. Hardware-aware, with reversible configuration changes tracked."
|
||||
"ogDescription": "14 fixed, hardware-aware optimizations for a fresh Proxmox VE host, with confirmations for some actions and reversible configuration changes tracked."
|
||||
},
|
||||
"header": {
|
||||
"title": "Automated Post-Install Script",
|
||||
"description": "One click, zero prompts — ProxMenux applies a curated set of 14 safe optimizations that almost every Proxmox host benefits from. Reversible configuration changes are registered for Uninstall Optimizations; package upgrades are not described as reversible.",
|
||||
"description": "ProxMenux runs a fixed set of 14 baseline optimizations without a feature-selection checklist. Some actions still ask for confirmation. Reversible configuration changes are registered for Uninstall Optimizations; package upgrades are not described as reversible.",
|
||||
"section": "Post-Install · Automated"
|
||||
},
|
||||
"intro": {
|
||||
@@ -43,7 +43,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "Skip language packages",
|
||||
"what": "Writes /etc/apt/apt.conf.d/99-disable-translations to stop downloading locale-specific packages. Faster, lighter apt updates.",
|
||||
"what": "Writes /etc/apt/apt.conf.d/99-disable-translations to stop downloading translated package-description indexes, reducing the data fetched by apt updates.",
|
||||
"category": "Basic Settings",
|
||||
"categorySlug": "basic-settings"
|
||||
},
|
||||
@@ -97,7 +97,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "Logrotate tuning",
|
||||
"what": "Daily rotation with size cap 10M, 7 rotations, compression and copytruncate — Log2RAM-friendly.",
|
||||
"what": "Sets daily and then size 10M globally, keeps 7 rotations, enables compression and copytruncate. The later size criterion takes precedence; per-log rules may override it. Suitable for Log2RAM, but rotation frequency depends on the rules and timer.",
|
||||
"category": "System",
|
||||
"categorySlug": "system"
|
||||
},
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
],
|
||||
"officialTitle": "The official Proxmox recommendation",
|
||||
"officialBody": "Proxmox's own upgrade guidance is to run, in this exact order:",
|
||||
"officialOutro": "That single line is all you need on any current Proxmox release. The challenge isn't the command itself — it's making sure the repositories on the host are sane <em>before</em> running it.",
|
||||
"officialOutro": "For routine updates within the installed Proxmox VE major version, this is the usual command. Check the host’s repositories and review the proposed package changes <em>before</em> proceeding. Upgrading to another major version requires the official migration procedure.",
|
||||
"doesTitle": "What the ProxMenux option does — verified against the script",
|
||||
"doesIntro": "The ProxMenux update wraps the exact apt commands above and adds a number of pre/post steps you would otherwise have to remember by hand. Every item below is what the dispatcher script actually does (see <link>Proxmox System Update</link> for the full breakdown):",
|
||||
"doesItems": [
|
||||
@@ -59,7 +59,7 @@
|
||||
},
|
||||
"languages": {
|
||||
"heading": "Skip downloading additional languages",
|
||||
"intro": "On every <code>apt update</code>, Debian by default pulls translation files for every locale it ships — a lot of traffic and disk space for something you'll rarely see. This option tells APT to only fetch the main metadata. Before disabling, ProxMenux <strong>makes sure the host's own locale is actually generated</strong> (reads <code>/etc/default/locale</code> or <code>/etc/environment</code>, appends to <code>/etc/locale.gen</code> if missing, and runs <code>locale-gen</code>). So you don't lose your shell locale as a side effect.",
|
||||
"intro": "During <code>apt update</code>, APT can download translated package descriptions as well as the main metadata. This option disables those translation downloads to save bandwidth and disk space. Before disabling them, ProxMenux <strong>makes sure the host’s own locale is actually generated</strong> (reads <code>/etc/default/locale</code> or <code>/etc/environment</code>, appends to <code>/etc/locale.gen</code> if missing, and runs <code>locale-gen</code>). So you do not lose your shell locale as a side effect.",
|
||||
"writtenTitle": "What gets written",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
"revertBody": "Deleting <code>/etc/apt/apt.conf.d/99-disable-translations</code> (either manually or from the Uninstall menu) restores the default behaviour and APT downloads language files again."
|
||||
|
||||
@@ -7,12 +7,12 @@
|
||||
},
|
||||
"header": {
|
||||
"title": "Customizable Post-Install Script",
|
||||
"description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~35 individual tools into 10 categories, each with its own checklist dialog. Same engine as Automated, but with full control over what gets applied.",
|
||||
"description": "Cherry-pick exactly which optimizations to apply to a Proxmox VE host. ProxMenux groups ~35 individual tools into 10 categories in one checklist dialog. Same engine as Automated, but with full control over what gets applied.",
|
||||
"section": "Post-Install · Customizable"
|
||||
},
|
||||
"intro": {
|
||||
"title": "When to pick Customizable",
|
||||
"body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist per category so you can pre-select, deselect or mix-and-match optimizations. Items can be applied again later, and reversible configuration changes are tracked for <link>Uninstall Optimizations</link>. Package upgrades are not presented as reversible."
|
||||
"body": "Choose this path when you already know which tweaks you want on the host — or which you definitely do not want. The script presents a checklist grouped by category so you can pre-select, deselect or mix-and-match optimizations. Items can be applied again later, and reversible configuration changes are tracked for <link>Uninstall Optimizations</link>. Package upgrades are not presented as reversible."
|
||||
},
|
||||
"compare": {
|
||||
"heading": "How it compares to Automated",
|
||||
@@ -20,7 +20,7 @@
|
||||
},
|
||||
"categoriesSection": {
|
||||
"heading": "The 10 categories",
|
||||
"body": "The Customizable script groups optimizations into 10 categories. Each category has its own checklist dialog and its own documentation page — open one of the cards below for the per-option rationale, defaults and verification steps."
|
||||
"body": "The Customizable script groups optimizations into 10 categories in one checklist dialog. Each category has its own documentation page — open one of the cards below for the per-option rationale, defaults and verification steps."
|
||||
},
|
||||
"categories": [
|
||||
{
|
||||
@@ -33,7 +33,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Virtualization",
|
||||
"description": "Prepare the host for advanced virtualization. Auto-installs the guest agent on templates and enables IOMMU/VFIO for PCI passthrough of GPUs, controllers and TPUs."
|
||||
"description": "Prepare the host for advanced virtualization. Installs a matching guest agent when Proxmox itself runs inside a supported VM, and enables IOMMU/VFIO for PCI passthrough of GPUs, controllers and TPUs."
|
||||
},
|
||||
{
|
||||
"name": "Network",
|
||||
@@ -53,7 +53,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Monitoring",
|
||||
"description": "Integrate the host with OVH Real-Time Monitoring. Only appears when ProxMenux detects an OVH server."
|
||||
"description": "Integrate the host with OVH Real-Time Monitoring. Installs RTM only when ProxMenux detects an OVH server; on other hosts the option makes no changes."
|
||||
},
|
||||
{
|
||||
"name": "Performance",
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
"breakTitle": "Can break after Proxmox updates",
|
||||
"breakBody": "Proxmox regularly ships UI updates that overwrite <code>proxmoxlib.js</code>. When that happens, the banner comes back. You can re-apply this option after every Proxmox update to re-patch the file, or just accept the nag until you reapply. ProxMenux also installs an APT hook that auto-re-patches on package upgrades — see <link>Uninstall Optimizations</link> for how that hook is reversed.",
|
||||
"legalTitle": "Legal note (always worth repeating)",
|
||||
"legalBody": "This option only hides the UI nag. It does <strong>not</strong> grant you enterprise support, access to the enterprise repository, or any rights to ship Proxmox commercially without a subscription. If you run Proxmox in a revenue-generating environment, buy a subscription — it supports the project and gets you the stable enterprise channel."
|
||||
"legalBody": "This option only hides the UI notice. It does <strong>not</strong> grant enterprise support or access to the enterprise repository, and it does not change the software license. Proxmox VE is released under the GNU AGPLv3. A subscription supports the project and provides access to the enterprise update channel; choose the appropriate support level for your environment."
|
||||
},
|
||||
"verify": {
|
||||
"heading": "Verification",
|
||||
|
||||
@@ -30,8 +30,8 @@
|
||||
"verifyTitle": "Verification",
|
||||
"verifyBody": "On a real OVH host, after a reboot you should see the <a>RTM dashboard</a> in your OVH Manager populated with live data for the host. On the Proxmox side, the RTM collector is a systemd service — check it directly:",
|
||||
"troubleTitle": "Troubleshooting",
|
||||
"revertTitle": "Not reversible from the Uninstall menu",
|
||||
"revertBody": "There is no dedicated uninstall entry for RTM. On a real OVH host, remove the packages manually with <code>apt purge ovh-*</code> and delete any puppet manifests under <code>/etc/puppet/</code> that RTM installed. On a non-OVH host, nothing was ever installed, so there's nothing to revert."
|
||||
"revertTitle": "Remove RTM from the Uninstall menu",
|
||||
"revertBody": "When RTM is registered as installed, Uninstall Optimizations offers an OVH Real-Time Monitoring entry. It runs <code>apt-get purge -y ''ovh-rtm*'' ''rtm'' ''rtm-*''</code>, removes /etc/rtm, and marks RTM as uninstalled. Puppet artefacts may still need manual cleanup; review any RTM-specific manifests under <code>/etc/puppet/</code>. On a non-OVH host, no RTM packages were installed, so there is nothing to remove."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -74,7 +74,7 @@
|
||||
"impactTitle": "Impact is workload-dependent",
|
||||
"impactBody": "BBR shines on high-latency or lossy links (cross-continent replication, VPN tunnels, mobile clients). On a LAN between two machines on the same switch, the difference is often within noise. TFO helps short, repeated HTTP connections the most.",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
"revertBody": "BBR/TFO are tracked. <link>Uninstall Optimizations</link> removes the two sysctl files (<code>/etc/sysctl.d/99-tcp-bbr.conf</code> and <code>99-tcp-fastopen.conf</code>) and reloads sysctl so the kernel returns to <code>cubic</code> and <code>tcp_fastopen=1</code>. Manual equivalent:"
|
||||
"revertBody": "BBR/TFO are tracked. <link>Uninstall Optimizations</link> removes the two sysctl files (<code>/etc/sysctl.d/99-kernel-bbr.conf</code> and <code>99-tcp-fastopen.conf</code>) and reloads the remaining sysctl configuration. Removing a file does not itself reset its live kernel values. Defaults such as <code>cubic</code> and <code>tcp_fastopen=1</code> return after a reboot unless another configuration overrides them. Manual equivalent:"
|
||||
},
|
||||
"names": {
|
||||
"heading": "Interface Names (persistent)",
|
||||
@@ -83,13 +83,13 @@
|
||||
"whyItems": [
|
||||
"Adding or removing PCIe devices can shift the bus numbering, turning <code>enp3s0</code> into <code>enp4s0</code>. If your <code>/etc/network/interfaces</code> references the old name, the bridge vanishes on reboot.",
|
||||
"BIOS / firmware updates sometimes change how devices enumerate, with the same effect.",
|
||||
"LXC containers with <code>hotplug</code> NICs and bonded links can race on boot and end up named inconsistently. Pinning fixes that."
|
||||
"The helper pins physical NIC names, including physical ports used by bonds. It skips virtual interfaces such as LXC veth devices and the bond devices themselves; it does not fix naming races for virtual <code>hotplug</code> NICs."
|
||||
],
|
||||
"writtenTitle": "What gets written",
|
||||
"writtenIntro": "One file per physical NIC, at <code>/etc/systemd/network/10-proxmenux-<iface>.link</code>. Each file starts with the header <code># Managed by ProxMenux — do not edit</code> so ProxMenux can distinguish its own files from user- or package-provided <code>.link</code> files.",
|
||||
"writtenOutro": "<code>.link</code> files from other packages or hand-written by the user are left in place — only files carrying the ProxMenux header are managed. On re-run, the function reconciles its own set: it re-reads <code>MACAddress=</code> from every <code>10-proxmenux-*.link</code> and drops any whose MAC no longer appears under <code>/sys/class/net/</code>. Files written by an earlier ProxMenux release in the old <code>10-<iface>.link</code> format are migrated automatically the first time.",
|
||||
"pveTitle": "PVE 9 vs PVE 8",
|
||||
"pveBody": "On Proxmox VE 9 (<code>systemd-networkd</code> native), the script reloads udev rules after writing the <code>.link</code> files so new hotplug NICs pick up the correct name without a reboot. On PVE 8 (<code>ifupdown2</code>), interface naming is resolved at boot anyway — a reboot is required for the changes to take effect. The script sets the reboot flag either way so Customizable prompts you.",
|
||||
"pveBody": "The script uses systemd <code>.link</code> files for persistent names. On Proxmox VE 9 it also reloads udev rules after writing them, so newly added NICs can use the rules without rebooting. Existing interfaces should be checked after a reboot on both PVE 8 and PVE 9. This does not switch the host away from <code>ifupdown2</code>. The script sets the reboot flag in either case so Customizable prompts you.",
|
||||
"reviewTitle": "Review existing /etc/network/interfaces first",
|
||||
"reviewBody": "If your host has legacy configuration in <code>/etc/network/interfaces</code> that references NIC names generated by the kernel's default scheme, pinning <em>today's</em> names is exactly what you want. But if you've already manually customised the config around specific names, double-check the pinning matches what the interfaces file expects before rebooting.",
|
||||
"revertTitle": "Reversible from the Uninstall menu",
|
||||
|
||||
@@ -133,7 +133,7 @@
|
||||
},
|
||||
"log2ram": {
|
||||
"title": "Install Log2RAM (SSD/NVMe wear reduction)",
|
||||
"intro": "Log2RAM mounts <code>/var/log</code> on a tmpfs ramdisk and periodically syncs the contents back to the underlying disk. On a hypervisor journald churn hits the root SSD every few seconds; moving the writes to RAM reduces wear and disk I/O without losing logs — the periodic sync flushes them to disk and a clean shutdown flushes them too.",
|
||||
"intro": "Log2RAM mounts <code>/var/log</code> on a tmpfs ramdisk and periodically syncs it to the underlying disk. Buffering frequent journald writes in RAM can reduce root SSD wear and disk I/O. Periodic sync and a clean shutdown save logs to disk, but an abrupt power loss can lose entries written since the last sync.",
|
||||
"upstreamLabel": "Upstream project:",
|
||||
"upstreamUrl": "https://github.com/azlux/log2ram",
|
||||
"upstreamLinkLabel": "azlux/log2ram on GitHub",
|
||||
@@ -149,7 +149,7 @@
|
||||
"Registers itself in <code>installed_tools.json</code> so it can be reverted from Uninstall Optimizations."
|
||||
],
|
||||
"howUseLabel": "How to use:",
|
||||
"howUseBody": "On the Automated flow Log2RAM applies unattended when an SSD/NVMe root is detected. On the Customizable flow the script prompts for size, sync interval and whether to enable the 90% auto-sync guard.",
|
||||
"howUseBody": "On the Automated flow Log2RAM installs unattended when an SSD/NVMe root is detected. The Customizable flow asks for size, sync interval and whether to enable the auto-sync guard. Its prompt currently says 90%, but the generated guard uses the 80% cleanup and 92% aggressive thresholds described above.",
|
||||
"verifyLabel": "Verify and manage from the shell:",
|
||||
"verifyCode": "# Service state and configured timers\nsystemctl status log2ram\nsystemctl list-timers log2ram*\n\n# Current ramdisk usage — /var/log IS the tmpfs itself\ndf -h /var/log\n\n# Force a sync now (tmpfs → disk); does NOT shrink the tmpfs\nlog2ram write\n\n# Trigger the auto-sync guard on demand (vacuum + sync when usage is high)\n/usr/local/bin/log2ram-check.sh\n\n# Current config: SIZE, mail settings, path\ncat /etc/log2ram.conf\n\n# ProxMenux-specific cron jobs\ncat /etc/cron.d/log2ram /etc/cron.d/log2ram-auto-sync\n\n# Recent Log2RAM activity\njournalctl -u log2ram -n 50 --no-pager"
|
||||
},
|
||||
@@ -172,6 +172,6 @@
|
||||
},
|
||||
"autoApplication": {
|
||||
"title": "Automatic Application",
|
||||
"body": "These optional features are applied only when specifically selected during the post-install process. Each feature can be individually chosen based on your specific needs and preferences."
|
||||
"body": "In the Customizable flow, select each optional feature according to your needs. Log2RAM is also part of the Automated flow with hardware detection; ZRAM remains Customizable-only. Review the individual sections for prompts and prerequisites."
|
||||
}
|
||||
}
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
"heading": "Use pigz for faster gzip compression",
|
||||
"intro": "Standard <code>gzip</code> compresses data using a <strong>single CPU core</strong>. On modern Proxmox hosts with 8, 16 or 32 cores, that is a huge bottleneck during <code>vzdump</code> VM/CT backups, log rotation, and anything else that pipes through <code>gzip</code>. <a>pigz</a> is a drop-in parallel replacement: same gzip-compatible output, but it spreads the work across every core.",
|
||||
"doesTitle": "What ProxMenux does",
|
||||
"doesIntro": "Four steps, all idempotent:",
|
||||
"doesIntro": "Five steps, all idempotent:",
|
||||
"doesItems": [
|
||||
"Sets <code>pigz: 1</code> in <code>/etc/vzdump.conf</code> so Proxmox's backup tool uses pigz natively.",
|
||||
"Installs the <code>pigz</code> apt package if not already present.",
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
"trackedBody": "Each of these options registers a tool in <code>installed_tools.json</code>, so they appear in <link>Uninstall Optimizations</link>. Reverting <code>zfs_arc</code> removes <code>/etc/modprobe.d/99-zfsarc.conf</code> and rebuilds initramfs; <code>zfs_auto_snapshot</code> reverses the cron schedule and offers to purge the package; <code>zfs_autotrim</code> sets <code>autotrim=off</code> on the pools it enabled; <code>vzdump_speed</code> restores <code>/etc/vzdump.conf</code> from the <code>.bak</code> the install created.",
|
||||
"arc": {
|
||||
"heading": "Optimize ZFS ARC size",
|
||||
"intro": "The <strong>Adaptive Replacement Cache (ARC)</strong> is ZFS's in-memory read cache. Without explicit tuning, ZFS happily grabs up to half the host RAM for itself, which is excessive on a Proxmox host that also needs memory for VMs and LXCs. This option caps ARC to a sane fraction of total RAM based on the size of the machine.",
|
||||
"intro": "The <strong>Adaptive Replacement Cache (ARC)</strong> is ZFS’s in-memory read cache. Proxmox VE installations since 8.1 set a limit of 10% of RAM, capped at 16 GiB; older or upgraded hosts may differ. This option writes its own RAM-based ARC limit. Check existing settings and workload needs before changing it; a smaller cache is not always faster.",
|
||||
"sizingTitle": "Sizing rules",
|
||||
"headerRam": "Host RAM",
|
||||
"headerMax": "ARC cap",
|
||||
@@ -41,7 +41,7 @@
|
||||
"max": "16 GiB (cap)"
|
||||
}
|
||||
],
|
||||
"after": "The file <code>/etc/modprobe.d/99-zfsarc.conf</code> contains a single directive — <code>options zfs zfs_arc_max=…</code>. Every other ZFS module parameter (<code>zfs_arc_min</code>, L2ARC prefetch/write throttle, TXG timeout) is left at its OpenZFS default. Before writing, a reconcile step scans any other <code>*.conf</code> in <code>/etc/modprobe.d/</code> that sets <code>zfs_arc_min</code> / <code>zfs_arc_max</code>, backs them up to <code>/usr/local/share/proxmenux/backups/zfs_arc/</code> with a manifest, and strips the conflicting lines so only ProxMenux's file is active. After writing the file, ProxMenux runs <code>update-initramfs -u -k all</code> and, when applicable, <code>proxmox-boot-tool refresh</code>, so the cap also lands in the initramfs used by ZFS-on-root setups.",
|
||||
"after": "The file <code>/etc/modprobe.d/99-zfsarc.conf</code> contains a single directive — <code>options zfs zfs_arc_max=…</code>. This option does not tune other ZFS module parameters (<code>zfs_arc_min</code>, L2ARC prefetch/write throttle, TXG timeout). Before writing, a reconcile step scans other <code>*.conf</code> in <code>/etc/modprobe.d/</code> that set <code>zfs_arc_min</code> / <code>zfs_arc_max</code>, backs them up to <code>/usr/local/share/proxmenux/backups/zfs_arc/</code> with a manifest, and strips conflicting lines so only ProxMenux’s ARC file is active. After writing, it runs <code>update-initramfs -u -k all</code> and, when applicable, <code>proxmox-boot-tool refresh</code>, so the limit also reaches the initramfs used by ZFS-on-root setups.",
|
||||
"rebootTitle": "Requires a reboot to take effect",
|
||||
"rebootBody": "ARC settings are read when the <code>zfs</code> kernel module loads. To make the cap take effect on ZFS-on-root hosts, ProxMenux regenerates the initramfs with <code>update-initramfs -u -k all</code> and, when applicable, refreshes the boot loader with <code>proxmox-boot-tool refresh</code>. A reboot is still required to pick up the new module parameter; the \"reboot required\" flag is set automatically.",
|
||||
"safeTitle": "Safe on non-ZFS hosts",
|
||||
@@ -90,22 +90,22 @@
|
||||
},
|
||||
"autotrim": {
|
||||
"heading": "Enable ZFS autotrim (SSD/NVMe pools)",
|
||||
"intro": "Enables the <code>autotrim</code> property on every ZFS pool that is backed exclusively by SSDs or NVMe drives with TRIM support. Pools that include a single HDD vdev are skipped automatically — TRIM on rotational drives is meaningless and ZFS will refuse it. Pools that were already set to <code>autotrim=on</code> are left as they are.",
|
||||
"intro": "Enables the <code>autotrim</code> property on ZFS pools backed exclusively by SSDs or NVMe drives with TRIM support. The script conservatively skips pools containing a rotational device. Pools already set to <code>autotrim=on</code> are left unchanged.",
|
||||
"trimTitle": "What TRIM does, and why it matters on ZFS",
|
||||
"trimBody1": "SSDs / NVMe drives manage internal storage in fixed-size erase blocks that are much larger than the logical sectors the filesystem talks to. When a filesystem deletes a file, the drive doesn't know — it still thinks those sectors are in use, so its internal garbage collector keeps shuffling stale data around to free new erase blocks. <strong>TRIM</strong> is the standard command the OS uses to tell the drive \"these sectors are now free, you can erase them ahead of time\".",
|
||||
"trimBody2": "Without TRIM, SSD performance degrades over time as the drive runs out of pre-erased blocks and has to do erase-on-write, and write amplification increases — both shortening the drive's useful life. With TRIM enabled, the drive can keep a healthy pool of empty blocks ready to write into.",
|
||||
"trimBody3": "On ZFS, <code>autotrim=on</code> is the modern equivalent of the periodic <code>zpool trim <pool></code> command — instead of having to remember to run a trim manually (or schedule one), the pool issues TRIM commands automatically and continuously as blocks become free. It's low-overhead and the recommended setting for SSD-backed pools.",
|
||||
"trimBody3": "With <code>autotrim=on</code>, ZFS trims recently freed space in the background, grouping ranges before issuing commands. A periodic <code>zpool trim <pool></code> is another option. Autotrim avoids a separate schedule, but its performance impact depends on the devices; periodic manual trim may suit some lower-end drives better.",
|
||||
"practicalTitle": "Why is this practical to enable?",
|
||||
"practicalItems": [
|
||||
"<strong>Sustained write performance.</strong> SSDs that never see TRIM commands slow down measurably over months. Autotrim keeps the controller's job easier.",
|
||||
"<strong>Drive longevity.</strong> Lower write amplification means fewer total NAND writes for the same amount of data — measurable in years of useful life for the disk.",
|
||||
"<strong>Sustained write performance.</strong> TRIM can help a drive reclaim unused blocks efficiently. The benefit and any latency impact depend on the device and workload.",
|
||||
"<strong>Drive longevity.</strong> Avoiding unnecessary internal copying can reduce write amplification and NAND wear. It does not guarantee a specific increase in drive lifespan.",
|
||||
"<strong>No scheduled cron job to remember.</strong> Unlike a periodic <code>zpool trim</code>, autotrim is fire-and-forget — the pool handles it on its own."
|
||||
],
|
||||
"whenTitle": "When is this necessary?",
|
||||
"whenIntro1": "<strong>You should enable it</strong> on any ZFS pool whose vdevs are all SSD or NVMe with TRIM support — the typical Proxmox install on consumer or enterprise SSDs.",
|
||||
"whenIntro1": "<strong>Consider enabling it</strong> on ZFS pools made entirely of TRIM-capable SSD or NVMe devices. Check device behaviour and workload latency; a scheduled manual trim can be preferable on some hardware.",
|
||||
"whenIntro2": "<strong>The script skips it automatically</strong> on:",
|
||||
"whenSkipItems": [
|
||||
"Pools containing any HDD (rotational) vdev — TRIM is meaningless there.",
|
||||
"Pools containing any HDD (rotational) vdev — a conservative hardware filter used by this script.",
|
||||
"Drives without <code>discard_granularity</code> exposed in sysfs — usually old SSDs without TRIM, or pass-through paths where the OS can't see the underlying device.",
|
||||
"Pools where ZFS itself reports the property unsupported (rare; very old pools).",
|
||||
"Pools already set to <code>autotrim=on</code> (no-op)."
|
||||
@@ -121,7 +121,7 @@
|
||||
},
|
||||
"vzdump": {
|
||||
"heading": "Increase vzdump backup speed",
|
||||
"intro": "By default, Proxmox vzdump throttles backups to protect running VMs/CTs from IO starvation. On many setups that throttle is more conservative than needed. This option removes the bandwidth cap and lowers the I/O priority so vzdump can saturate the storage path during backup windows.",
|
||||
"intro": "Writes bwlimit: 0 and ionice: 5 in the global vzdump configuration. Proxmox already defaults to no bandwidth limit, so this removes a cap only if one was configured. Compared with the default ionice: 7, the value 5 gives a higher best-effort I/O priority where the scheduler honours it. This can affect running guests and does not guarantee faster backups.",
|
||||
"changedTitle": "What gets changed in /etc/vzdump.conf",
|
||||
"backupTitle": "First run creates a .bak of vzdump.conf",
|
||||
"backupBody": "The first time this option runs, ProxMenux copies <code>/etc/vzdump.conf</code> to <code>/etc/vzdump.conf.bak</code> before touching it. Subsequent runs re-use that backup and won't overwrite it, so a hand-edited config from before the first apply stays recoverable. The changes to <code>bwlimit</code> and <code>ionice</code> are then made with <code>sed</code>, and any other options in the file (compress, pigz, tmpdir, exclude-path, etc.) are preserved.",
|
||||
@@ -145,7 +145,7 @@
|
||||
{
|
||||
"label": "Backup and Restore commands",
|
||||
"href": "/docs/help-info/backup-commands",
|
||||
"tail": " — vzdump CLI reference (now without the legacy bwlimit / ionice caps)."
|
||||
"tail": " — vzdump CLI reference for bandwidth and I/O-priority settings."
|
||||
},
|
||||
{
|
||||
"label": "Uninstall Optimizations",
|
||||
|
||||
@@ -28,9 +28,9 @@
|
||||
},
|
||||
"logrotate": {
|
||||
"heading": "Optimize logrotate",
|
||||
"intro": "Rewrites <code>/etc/logrotate.conf</code> with a tighter policy suitable for a host that's also part of an SSD-protecting Log2RAM setup: daily rotation, 7-day retention, 10 MB size trigger, compression, and <code>copytruncate</code> so active services keep writing without reopening their log files. Original <code>logrotate.conf</code> is backed up to <code>.bak</code> on first apply.",
|
||||
"intro": "Rewrites <code>/etc/logrotate.conf</code> with global daily and size settings, 7 retained rotations, compression and <code>copytruncate</code>, so active services can keep writing without reopening their log files. The size setting follows daily and takes precedence unless a per-log rule overrides it. Original <code>logrotate.conf</code> is backed up to <code>.bak</code> on first apply.",
|
||||
"tipTitle": "Log2RAM-friendly",
|
||||
"tipBody": "The <code>size 10M</code> trigger means logs rotate on size <em>or</em> daily, whichever comes first. Combined with Log2RAM's RAM-backed <code>/var/log</code>, this keeps the working set small so flushes to disk stay cheap."
|
||||
"tipBody": "The <code>size 10M</code> directive takes precedence over the earlier daily setting; it does <em>not</em> mean whichever comes first. Logrotate checks the threshold when it runs, and per-log rules may override the global settings. With Log2RAM’s RAM-backed <code>/var/log</code>, review both the rules and the timer frequency to control disk usage."
|
||||
},
|
||||
"limits": {
|
||||
"heading": "Increase various system limits",
|
||||
@@ -72,7 +72,7 @@
|
||||
}
|
||||
],
|
||||
"tipTitle": "Why inotify matters",
|
||||
"tipBody": "Applications like Docker, Syncthing, Node.js watchers, Plex's library scanner and many more hit <code>max_user_watches</code> quickly. Default on Debian is 8192 — a single running Plex can exhaust it. 1M is generous and costs ~1 KB of RAM per watch, which is negligible."
|
||||
"tipBody": "Docker, Syncthing, Node.js file watchers and Plex library scans can exhaust <code>max_user_watches</code>. The default depends on the kernel and host memory; it is not always 8192. Raising the limit to 1M allows more watches, but does not preallocate them. Active watches consume kernel memory, so monitor actual usage on memory-constrained hosts."
|
||||
},
|
||||
"memory": {
|
||||
"heading": "Optimize memory settings",
|
||||
@@ -102,8 +102,8 @@
|
||||
"verify": {
|
||||
"heading": "Verification",
|
||||
"intro": "After applying the System optimizations:",
|
||||
"tipTitle": "Fully reversible",
|
||||
"tipBody": "All six options are tracked in <code>installed_tools.json</code>, so they appear in <link>Uninstall Optimizations</link> if you want to back any of them out. Reverts restore the sysctl files' defaults, drop the systemd unit and alias for kexec, and reset journald/logrotate to stock Debian configs."
|
||||
"tipTitle": "Restoration and limitations",
|
||||
"tipBody": "All six options are tracked in <code>installed_tools.json</code> and offered in <link>Uninstall Optimizations</link>. Restoration removes configuration files, the kexec unit and alias, and restores journald/logrotate configuration. Some live limits need a new session or reboot. The system-limits cleanup removes the legacy ulimit -n 256000 line from /root/.profile; the current ulimit -n 1048576 line can remain and may need manual removal."
|
||||
},
|
||||
"related": {
|
||||
"heading": "Related",
|
||||
|
||||
@@ -58,7 +58,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "APT Language Skip",
|
||||
"restores": "Removes /etc/apt/apt.conf.d/99-disable-translations. APT will download language packages again."
|
||||
"restores": "Removes /etc/apt/apt.conf.d/99-disable-translations, allowing APT to download translated package-description indexes according to its remaining language settings."
|
||||
},
|
||||
{
|
||||
"tool": "APT IPv4 Force",
|
||||
@@ -83,7 +83,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "System Limits Increase",
|
||||
"restores": "Removes /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf and /etc/security/limits.d/99-limits.conf. Reverts PAM limits and systemd DefaultLimitNOFILE, and strips the ulimit -n 256000 line from /root/.profile."
|
||||
"restores": "Removes /etc/sysctl.d/99-maxwatches.conf, 99-maxkeys.conf, 99-swap.conf, 99-fs.conf and /etc/security/limits.d/99-limits.conf. Reverts PAM limits and systemd DefaultLimitNOFILE. Its /root/.profile cleanup targets the legacy ulimit -n 256000 line; a ulimit -n 1048576 line from the current installer can remain and may need manual removal."
|
||||
},
|
||||
{
|
||||
"tool": "ZRAM swap profile",
|
||||
@@ -104,7 +104,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "TCP BBR + TCP Fast Open",
|
||||
"restores": "Removes /etc/sysctl.d/99-tcp-bbr.conf and 99-tcp-fastopen.conf and reloads sysctl so the kernel returns to the cubic congestion control and to tcp_fastopen=1."
|
||||
"restores": "Removes /etc/sysctl.d/99-kernel-bbr.conf and 99-tcp-fastopen.conf and reloads remaining sysctl configuration. File removal does not itself reset live values; defaults such as cubic and tcp_fastopen=1 return after reboot unless another configuration overrides them."
|
||||
},
|
||||
{
|
||||
"tool": "Persistent Interface Names",
|
||||
@@ -166,8 +166,8 @@
|
||||
"restores": "Removes idle=nomwait from kernel cmdline (ZFS) or GRUB, and the ignore_msrs / report_ignored_msrs options from /etc/modprobe.d/kvm.conf."
|
||||
},
|
||||
{
|
||||
"tool": "QEMU Guest Agent (templates)",
|
||||
"restores": "Reads /usr/local/share/proxmenux/guest_agent.pkg (recorded at install time) and apt purges whichever package was installed (qemu-guest-agent for standard hosts, spice-vdagent when Spice mode is used)."
|
||||
"tool": "Guest agent for a virtualized Proxmox host",
|
||||
"restores": "Reads /usr/local/share/proxmenux/guest_agent.pkg and purges the recorded host package. The installer selects qemu-guest-agent, open-vm-tools or virtualbox-guest-utils according to the detected hypervisor. If the record is missing, the uninstaller tries those three packages. This acts on the nested Proxmox host, not guest templates."
|
||||
}
|
||||
]
|
||||
},
|
||||
@@ -221,7 +221,7 @@
|
||||
},
|
||||
{
|
||||
"tool": "OVH RTM (monitoring)",
|
||||
"restores": "apt purges any ovh-* packages the RTM installer added and deletes the puppet manifests it dropped under /etc/puppet/. On non-OVH hosts nothing was ever installed, so nothing is removed."
|
||||
"restores": "Purges packages matching ovh-rtm*, rtm and rtm-*, removes /etc/rtm and clears the RTM registry entry. Puppet artefacts under /etc/puppet/ may need manual inspection and cleanup; the uninstaller does not delete that directory. On non-OVH hosts the installer normally makes no changes."
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -230,7 +230,7 @@
|
||||
"edge": {
|
||||
"heading": "Edge cases and caveats",
|
||||
"packageTitle": "Package reinstall touches live Proxmox packages",
|
||||
"packageBody": "Reverting <strong>Subscription Banner Removal</strong> reinstalls <code>pve-manager</code>, <code>proxmox-widget-toolkit</code>, <code>libjs-extjs</code> and <code>libpve-http-server-perl</code> with <code>--force-confnew</code>. This is generally safe but does touch the running web UI — refresh your browser afterwards, and expect a few seconds of reconnection. Don't run this in the middle of a migration or clone operation.",
|
||||
"packageBody": "If ProxMenux’s own backups cannot restore <strong>Subscription Banner Removal</strong>, the fallback reinstalls <code>pve-manager</code>, <code>proxmox-widget-toolkit</code>, <code>libjs-extjs</code> and <code>libpve-http-server-perl</code> with <code>--force-confnew</code>. This touches the running web UI: refresh the browser afterwards and allow a few seconds to reconnect. Avoid doing it during a migration or clone operation.",
|
||||
"rebootTitle": "Persistent names and VFIO need a reboot",
|
||||
"rebootBody": "Removing ProxMenux's <code>10-proxmenux-*.link</code> files (<em>Persistent Interface Names</em>) and reverting <em>IOMMU/VFIO</em> do not affect the running system — they only matter after a reboot. ProxMenux sets the reboot flag automatically for these.",
|
||||
"perItemTitle": "You can revert one thing and keep the rest",
|
||||
|
||||
@@ -48,9 +48,9 @@
|
||||
},
|
||||
"pathB": {
|
||||
"heading": "Path B — From the Monitor dashboard",
|
||||
"intro": "The same updates appear in the Monitor under <link>Settings → ProxMenux Optimizations</link>. When pending updates are detected the card shows an \"Updates available\" banner with the count and an <strong>Apply</strong> action that opens the same per-optimization picker.",
|
||||
"imageAlt": "ProxMenux Optimizations card on the Monitor dashboard with an Updates available banner at the top showing the count of pending updates and an Apply button that opens the per-optimization picker",
|
||||
"imageCaption": "The Optimizations card in the Monitor — when at least one optimization has a newer version on disk, the banner surfaces it without requiring shell access."
|
||||
"intro": "The same updates appear in the Monitor under <link>Settings → ProxMenux Optimizations</link>. When pending updates are detected, the card shows an <strong>updates count badge</strong> that opens the per-optimization picker. Individual tools also provide their own update action.",
|
||||
"imageAlt": "ProxMenux Optimizations card in Monitor settings, with a pending-updates count badge that opens the per-optimization picker and update actions on individual tools",
|
||||
"imageCaption": "The Optimizations card in the Monitor — when at least one optimization has a newer version on disk, its count badge makes the updates accessible without shell access."
|
||||
},
|
||||
"applying": {
|
||||
"heading": "What happens when you apply",
|
||||
@@ -69,7 +69,7 @@
|
||||
},
|
||||
{
|
||||
"title": "Registry refresh sent to the Monitor",
|
||||
"body": "Once the batch finishes, the menu POSTs to <code>http://127.0.0.1:8008/api/updates/post-install/scan</code> to rebuild <code>/usr/local/share/proxmenux/updates_available.json</code>. That is what makes the Monitor's Optimizations card and the shell menu entry disappear immediately after the update, without waiting for the next scheduled scan."
|
||||
"body": "Once the batch finishes, the menu POSTs to <code>http://127.0.0.1:8008/api/updates/post-install/scan</code> to rebuild <code>/usr/local/share/proxmenux/updates_available.json</code>. After all pending updates are applied, the update badge in the Monitor’s Optimizations card and the conditional shell menu entry disappear without waiting for the next scheduled scan. The Optimizations card itself remains available."
|
||||
}
|
||||
],
|
||||
"jqTitle": "jq is required",
|
||||
|
||||
Reference in New Issue
Block a user