# TA-ProxMenu Interactive installation and configuration helpers used when deploying Proxmox VE environments. ## Install Run as `root` on a Proxmox VE host: ```bash bash <(curl -fsSL https://go.scity.us/install-tapm) ``` The installed launcher loads TA-ProxMenu's bundled defaults and colors, then opens the interactive menu. Updates are installed only when explicitly selected or requested with `tapm update`. On a clustered Proxmox host, both `tapm update` and the management-menu update update every online cluster node over Proxmox's root SSH trust, then update the initiating node. Each node independently performs the same clean-worktree, branch, and fast-forward safety checks. Offline, unreachable, dirty, ahead, or diverged nodes are never overwritten and are reported as failures. Standalone hosts retain the local-only update behavior. When testing this branch, use `tapm main` to switch the installed copy back to the published main branch. The command refuses to switch when local changes, local-only commits, or diverged branch history would be at risk. The TA-ProxMenu Management menu can safely switch TA-ProxMenu between branches published on its Git origin. Branch switching is refused when the installed repository has local changes or when the destination branch has commits that would be discarded. ## Direct actions The menu script also supports these direct actions: ```text pulse Install Pulse monitoring rmm Install the ConnectWise RMM agent omsa Install legacy Dell OMSA on supported PowerEdge x30/x40 hosts glances Install Glances acronis Install the Acronis agent post-install Open the native TAPM host configuration menu proxmenux Open TAPM host configuration for migration compatibility virtio Download current VirtIO drivers sentinelone Install the SentinelOne agent screenconnect Install the ScreenConnect agent restart Restart core local Proxmox management services cpu Detect and optionally apply a migration-safe CPU model maintenance Toggle local HA maintenance mode keepalived Deploy Keepalived across the cluster iso-nfs Create an LXC NFS server and cluster-wide shared ISO storage ``` ## Companion files Large installer artifacts used by this project are stored in the private `TAI/files` package registry. SentinelOne, RMM, Acronis, and ScreenConnect installation require a temporary deployment code from TAPM Deployment Access. The private Git credentials are never stored on or returned to a Proxmox host. SentinelOne package versions can be updated through the deployment portal without changing ProxMenu. ## Runtime requirements - Proxmox VE and root privileges - Bash, Git, curl, wget, Python 3, and standard Debian package tools - The bundled `defaults.inc` and `colors.inc` files The Keepalived deployment additionally requires a healthy, quorate Proxmox cluster and passwordless root SSH between cluster nodes. The shared ISO storage wizard creates a privileged Debian LXC with a dedicated secondary volume, restricts its NFS export to a supplied client CIDR, and adds the export to Proxmox's cluster-wide storage configuration. The container host and network path to the container must remain available for nodes to use the ISO repository. The legacy Dell OMSA installer is limited to supported PowerEdge x30/x40 systems running Proxmox VE 9 on Debian 13 (Trixie), amd64. CPU compatibility analysis compares every cluster host's physical processor, processor generation/family, and supported generic VM CPU baseline. It then previews QEMU VM and template changes before applying the highest baseline shared by all nodes through the Proxmox CLI. Running VMs are not restarted automatically. The native TAPM host configuration workflow replaces the former ProxMenux post-install dependency. It can audit a host, apply the recommended PVE 9 profile, customize individual items, migrate recognized ProxMenux configurations, repair ProxMenux's system gzip replacement, and remove ProxMenux after validation. Every mutating run first creates a timestamped backup under `/var/backups/ta-proxmenu/post-install`. The recommended profile installs only missing diagnostic utilities, preserves the configured timezone and NTP servers, enables conservative kernel and network safeguards, retains up to 1 GiB or 30 days of persistent journal history, verifies logrotate, and uses Proxmox's native pigz support without replacing `/bin/gzip`. APT remains dual-stack by default; its conditional IPv4 compatibility check is optional. Global vzdump bandwidth and I/O-priority changes are available through a separate explicit menu. Pulse can also be deployed without installing TA-ProxMenu. Run the standalone bootstrap as root on a Proxmox VE host: ```bash bash <(curl -fsSL https://tagit.technologyarch.com/taiadmin/TA-ProxMenu/raw/branch/V2/install-pulse.sh) ``` The bootstrap downloads the Pulse deployment module and its LXC storage helper from the same branch into a protected temporary directory, validates their Bash syntax and expected entry points, runs the normal interactive Pulse workflow, and removes the temporary files afterward. It does not clone or install TA-ProxMenu. Set `TAPM_PULSE_SOURCE_BRANCH` before running it to use another branch. VirtIO downloads are managed from a dedicated submenu. The stable release is checked only when that submenu is opened, and curated compatibility ISOs are available for Windows Server 2008, 2008 R2, 2012/R2, and 2016. Downloads are validated before atomically replacing a file with the same name. Maintenance evacuation leaves HA-managed guests under Proxmox HA control. Remaining shared-storage guests are routed to online, non-maintenance nodes with the required storage, while local-storage guests are gracefully shut down. HA node-affinity preferences are honored when an eligible node exists. ## Development checks Run the local validation suite with Bash 4.3 or newer: ```bash ./tests/run.sh ``` The suite checks Bash syntax and Git whitespace, runs ShellCheck when it is installed, and exercises Git update states, LXC input/storage selection, maintenance evacuation routing, HA affinity parsing, host-profile migration signatures and backups, and VirtIO filename validation. Tests use temporary files and mocked Proxmox output; they do not download installers or change a Proxmox host. ## Deployment broker URL TA-ProxMenu exchanges deployment codes with the configured TAPM broker. The URL is selected in this order: 1. Existing `TAPM_BROKER_URL` environment variable 2. `TAPM_BROKER_URL` in `/etc/ta-proxmenu/config.env` For a persistent per-system setting: ```sh install -d -m 0755 /etc/ta-proxmenu install -m 0644 config.env.example /etc/ta-proxmenu/config.env ``` The tracked example contains only: ```dotenv TAPM_BROKER_URL=https://tapm.example.com GITEA_DOMAIN=git.example.com ``` Replace it with the deployed HTTPS origin, without an API path. There is no hard-coded operational broker URL; authorization fails with a configuration message when the variable is missing or invalid. `GITEA_DOMAIN` is a hostname, without `https://` or a path. Repository updates use the installed TA-ProxMenu checkout's configured Git `origin` and do not overwrite the system configuration file. On the first V2 launch after installation or upgrade, TA-ProxMenu detects a missing or incomplete `/etc/ta-proxmenu/config.env` and interactively requests both values. Inputs are validated and written atomically with mode `0600` before update checks or menu actions continue. A non-interactive launch without valid configuration stops with an explicit setup message instead of selecting a default company URL. ## Installation registry V2 creates a random installation UUID and 256-bit credential in `/var/lib/ta-proxmenu/identity.env`. The directory is mode `0700` and the file is mode `0600`. The first successful launch enrolls the host with the broker. Later launches make one best-effort HTTPS call on completion or failure to record the hostname, duration, result, TA-ProxMenu and Git versions, PVE/OS/kernel versions, architecture, and whether the host is clustered. A failed event schedules re-enrollment on the next invocation instead of adding another retry to the current run. No background service is installed, and broker availability never prevents the menu from running. Automatic Git update checks and the stable VirtIO release lookup are cached for 24 hours. Their explicit **Check again** and **Refresh** actions bypass the cache. Installer, package-repository, and vendor download traffic occurs only after a technician selects the corresponding action. The hostname is treated as a limited operational identifier. The registry does not send machine IDs, MAC addresses, usernames, VM/container inventory, deployment codes, authorization tokens, credentials, or command output. The broker stores only a digest of the random host credential. A successful deployment-code exchange carrying the same random installation ID marks that registry entry as verified.