Proxmox VM and LXC Inventory#

HP1Proxmox#

HP2Proxmox#

HP3Proxmox#

HP4Proxmox#

HP5Proxmox#

HP7Proxmox#

MMProxmox#

Proxmox - Wake-on-LAN (WOL) Monitoring & Sniffer#

This guide outlines a persistent, lightweight background service for monitoring and logging Wake-on-LAN (WOL) Magic Packets on the Proxmox network. The payload is retained so the target MAC can be identified even when a server has multiple NICs or alternate MAC addresses.

2026-08-03 Antigravity chat: agy –conversation=3b2d07f7-d649-4fed-9976-8f0deadf60f9

1. Overview & Purpose#

• Primary Target: HP3 (10.1.1.13), documented MAC ec:b1:d7:7c:a9:48
• Additional Targets: Any WOL target visible on the monitored segment, including HP2 (94:57:a5:65:7e:88)
• Capture Host: MMProxmox / MacMini (10.1.1.10)
• Capture Interface: bond0 (active-backup bond; nic1 currently active)
• Objective: Capture the source IP, source Ethernet MAC, timestamp, VLAN, and WOL payload target MAC.
• Resource Overhead: Near zero (~1 MB RAM, 0% CPU overhead).

2. Systemd Service Specification#

The sniffer uses tcpdump running as a background systemd daemon. It listens on the physical uplink (bond0) for UDP port 9/7 and raw Ethernet WOL traffic, retaining the complete packet payload in /var/log/wol_sniffer.log.

📜 Scripts Management#

Workstation Sync Shortcut: To automatically backup all your scripts and custom terminal aliases configuration (staging and pushing your entire ~/Scripts/ repository):

pushscripts

This will stage all modified files in ~/Scripts/, commit, and push updates directly to GitHub and your NAS (without running Homebrew operations).

MCP Configuration Sync: MCP configuration is maintained in a separate repository, ~/.mcp-config, linked to git@github.com:marcoue/MCP-Config-MacOS.git. Use:

pushmcp   # Commit selected MCP master files, compile through the post-commit hook, and push to GitHub
pullmcp   # Pull MCP changes; the post-merge hook recompiles client configurations

These commands do not operate on ~/Scripts and do not replace pushscripts or pullscripts.

Scripts Management Migration Plan#

This document is the master architectural migration plan for establishing /Users/marc/Scripts as your primary local master Git repository, linked to git@github.com:marcoue/Scripts.git, with automated mirroring to the UNAS-Pro NAS (/Volumes/Software/Software/Scripts/) and automated pull execution by remote TrueNAS/Linux/Proxmox nodes.

1. Executive Summary & Architecture Goal#

🎯 Primary Master Architecture#

1. Master Repository: /Users/marc/Scripts on your Mac SSD is your primary master repository for editing, testing, running, and managing all homelab scripts.
2. GitHub Remote: Linked to git@github.com:marcoue/Scripts.git on branch main.
3. Automated NAS Mirroring: A Git post-commit hook automatically syncs committed scripts from ~/Scripts/ to /Volumes/Software/Software/Scripts/ on UNAS-Pro.
4. Remote Server Pull Execution: Remote servers (HP1, HP2, HP3, HP7, HP8, Proxmox, Linux) pull their scripts from UNAS-Pro (Software/Scripts/) on their scheduled runs.

🔄 Data & Deployment Flow#

  [Mac Workstation] (Primary Master Workspace)
   └── ~/Scripts/ (git@github.com:marcoue/Scripts.git)
        ├── MacOS/
        ├── Linux/
        ├── Proxmox/
        └── TrueNAS/
             │
             ├── (git commit)
             ▼
        [Git post-commit Hook]
             │
             ├── (rsync auto-mirror)
             ▼
  [UNAS-Pro Master NAS] (Distribution Mirror)
   └── /Volumes/Software/Software/Scripts/
        ├── MacOS/
        ├── Linux/
        ├── Proxmox/
        └── TrueNAS/ (Exposed as Rsync Module: root@10.1.2.2::Software/Scripts/TrueNAS/)
             │
             ├── (Rsync pull on schedule)
             ▼
  [Remote Nodes: HP1, HP2, HP3, HP7, HP8, Proxmox, Linux]
   └── Local Execution of Version-Controlled Scripts

📂 1.1 Filesystem Standard & Disaster Recovery Protocol#

1. Standard POSIX Filesystem Path:
   • The destination path /Volumes/Software/Software/Scripts/ (and subfolders MacOS/, Linux/, Proxmox/, TrueNAS/) is a standard, plain-text directory tree residing on the mounted Software SMB share (smb://10.1.2.2/Software). There are zero proprietary databases, hidden hooks, or custom file structures on the NAS.
2. Mac Auto-Mount Convenience (Login Items):
   • To ensure the SMB share is always available for Git post-commit auto-mirroring, add /Volumes/Software to macOS System Settings > General > Login Items.
3. macOS Reinstall / Disaster Recovery:
   • Reinstalling or replacing macOS on your Mac Studio has zero effect on UNAS-Pro or TrueNAS servers. The NAS files remain intact, and TrueNAS backup cron jobs continue executing without interruption.
   • To restore your Mac workstation repo after a fresh macOS install:

     # Step 1: Clone master repository from GitHub
     git clone git@github.com:marcoue/Scripts.git ~/Scripts
     
     # Step 2: Re-install 1-line Git post-commit auto-mirror hook
     cat << 'EOF' > ~/Scripts/.git/hooks/post-commit
     #!/usr/bin/env bash
     if [ -d "/Volumes/Software/Software/Scripts" ]; then
         rsync -av --delete --exclude='.git' --exclude='*.log' /Users/marc/Scripts/ /Volumes/Software/Software/Scripts/
     fi
     EOF
     chmod +x ~/Scripts/.git/hooks/post-commit

2. Complete Script Inventory & Mapping#

The following table lists all existing scripts found across your NAS repository (git@github.com:marcoue/Scripts.git) and local Mac folder (~/Scripts/), mapped to their final category subfolders:

Lab-Servers Infrastructure & Virtualization Security Analysis#

VERDICT: [VERIFIED] SECURE AND HARDENED SECURITY SCORE: 97 / 100 (Grade: A+) An empirical security audit of the Lab-Servers network (10.1.1.0/24, interface br11) confirms that all Proxmox VE hypervisor nodes, Proxmox Datacenter Manager (PDM), Proxmox Backup Servers (PBS), TrueNAS storage arrays, and virtual server infrastructure operate on a dedicated 10G SFP+ aggregated network protected by Linux kernel firewall rules (iptables), gateway management isolation, active honeypot monitoring (10.1.1.254), and strict inter-VLAN boundary drops.

Proxmox Backup Server (PBS) - Backups via NAS to GDrive (Decoupled, Monitored & Encrypted)#

This guide is intended for off-site disaster recovery (DR) copies, not as a primary backup destination.

This documentation covers a decoupled, stage-based architecture: The PBS Method (Deduplicated Datastore on NAS): The Proxmox Backup Server (PBS) host HP1BackupServer (10.1.1.211) mounts a local NAS share under proper system ownership (uid=34) to run a fully deduplicated backup datastore. A dedicated sync container MMDocker (10.1.2.230) mounts the same share to asynchronously push the deduplicated chunk structure to Google Drive via an optimized rclone sync script.

Proxmox Backup Server - Mounting an SMB NAS Share as a PBS Datastore#

This note outlines the step-by-step process used to mount a remote SMB/Samba share from a NAS onto a Proxmox Backup Server (PBS) host at the OS level, assign proper permissions for the PBS daemon, and initialize it as a new backup datastore.

Prerequisites#

• A target share on the NAS (e.g., //10.1.2.2/ProxmoxBackups).
• An existing SMB credentials file on the PBS host (e.g., /root/.smb_credentials).

Step-by-Step Implementation#

Step 1: Create the Local Mount Directory#

Create a dedicated folder at the root of the PBS host filesystem where the network share will be attached.

Unattended-Upgrades Configuration (VM & LXC)#

Not Used, as a reference only

The objective of this guide is to safely automate software updates across a high-density environment of virtual machines and LXC containers, significantly reducing daily manual maintenance without compromising infrastructure stability. By shifting from a manual execution model to a structured deployment using the native unattended-upgrades utility, the system handles the download, installation, and post-update cleanup of all packages automatically in the background. Rather than allowing unpredictable automated reboots that could disrupt active services or interfere with critical backup windows, this configuration enforces a strict “notify-only” baseline. It leverage a lightweight mail client to alert the administrator immediately when a reboot is pending, combining hands-free patching with complete operational control.

Proxmox Initial Install & Provisioning#

This guide contains the steps performed immediately after installing Proxmox VE. These steps are designed to be integrated into the ultimate_master_restore.sh script.

1 System Maintenance#

1.1 Update System (Included in Restore script)#

apt update && apt full-upgrade -y
apt autoremove && apt autoclean

2 SSH Configuration#

2.1 Configure SSH Public Key (Included in Restore script)#

Edit authorized keys:

nano ~/.ssh/authorized_keys

Paste SSH keys for [1Password Private note](https://start.1password.com/open/i?a=G7ECSBBRRFHWPDIM7F7J6TWP7I&v=4bxn4d3worhhq7rc6m3usjciia&i=6hoe6ndejfr5evqpatwk2xsatq&h=my.1password.com)

Restart SSH:

Proxmox MCP Installation (Sillicon Mac) Intel below#

This guide details the process for installing the Proxmox Model Context Protocol (MCP) server and integrating it with Gemini-CLI to manage virtual machines and containers directly from the terminal.

1 Prerequisites#

• Proxmox VE: Access to a Proxmox cluster or node.
• Gemini-CLI: Installed via Homebrew or npm.
• Python 3.10+: Required for the MCP server environment.
• API Token: Created in Proxmox (Datacenter > Permissions > API Tokens). Ensure the token has sufficient permissions (e.g., PVEAuditor or PVEVMAdmin) and ‘Privilege Separation’ is unchecked.

2 Server Installation#

Run the following commands to clone the repository and set up the Python environment in a dedicated directory.