186 lines
8.1 KiB
Markdown
186 lines
8.1 KiB
Markdown
# 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 the shared iDSSYS defaults and opens the
|
|
interactive menu. Update availability is checked in the background and cached;
|
|
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 required iDSSYS Defaults repository is handled separately: it is
|
|
automatically refreshed before launch when its last successful check is more
|
|
than four hours old. If the remote is unavailable, the installed copy is used.
|
|
Updates are fast-forward-only. Local file changes, local-only commits, and
|
|
diverged histories are preserved and reported instead of being overwritten.
|
|
|
|
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 Gitea 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
|
|
- `/opt/idssys/defaults/default.inc`
|
|
- `/opt/idssys/defaults/colors.inc`
|
|
|
|
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 detection previews cluster-wide QEMU VM and template
|
|
changes before applying the ProxCLMC recommendation 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.
|
|
|
|
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, and controls Gitea connectivity plus restoration
|
|
of the `voltron/iDS-Defaults.git` repository. Repository updates 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`. On each interactive launch, TA-ProxMenu makes best-effort HTTPS
|
|
calls to the configured broker to record installation/upgrade state, start and
|
|
completion status, duration, TA-ProxMenu and Git versions, PVE/OS/kernel
|
|
versions, architecture, and whether the host is clustered. No background
|
|
service is installed, and broker availability never prevents the menu from
|
|
running.
|
|
|
|
The registry does not send hostnames, machine IDs, MAC addresses, usernames,
|
|
customer names, VM/container inventory, deployment codes, authorization
|
|
tokens, or command output. The broker stores only a digest of the random host
|
|
credential. A successful deployment-code exchange links the already-random
|
|
installation ID to a verified registry entry.
|