Mac OS - Aliases Management

Mac OS - Aliases Management#

Keep Mac Studio and MacBook Air in Sync

The Mac Studio is the source of truth for the shared aliases. Edit and publish changes there, then pull them onto the MacBook Air.

On the Mac Studio — edit and publish:

nano ~/Scripts/MacOS/Aliases/MacOS-Aliases.zsh
source ~/.zshrc
pushscripts

pushscripts commits and pushes pending changes in the ~/Scripts repository.

On the MacBook Air — download and apply:

pullscripts
source ~/.zshrc

If an open terminal still shows old aliases, open a new terminal window. The shared aliases are in ~/Scripts/MacOS/Aliases/MacOS-Aliases.zsh; ~/.zshrc is local to each Mac and must source that file.

Mac OS - Brewfile

Mac OS - Brewfile#

Daily Sync Shortcuts (Keep Computers Mirrored):

  • Run pushbrew on the machine where you just installed/removed software to scan your system, update the Brewfile, and push it to GitHub.
  • Run pullbrew on your other workstations to pull the update and automatically install/clean up your packages to match.

Quick Restore & Sync (Workstation Rebuild):

  • To Restore (New Computer):
    1. Install Homebrew (if missing): /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    2. Clone scripts: git clone git@github.com:marcoue/Scripts.git ~/Scripts
    3. Reinstall all software: brew bundle --file=~/Scripts/MacOS/Brew/Brewfile
  • To Sync Updates (Ongoing):
    • Pull latest and clean up local packages: pullbrew

Related Recovery Guides: Master Checklist: Mac OS - Recovery | Shortcut Configuration: Mac OS - Aliases Management | Repository Standard: Scripts Mangement.

Mac OS - Recovery

Mac OS - Recovery#


Intel iMac profile: The 2014 iMac is a managed macOS workstation for Scripts, Obsidian, and MCP administration. Its Homebrew prefix is /usr/local, and Intel Homebrew may compile large packages from source. Use the standalone uv installer plus uv-managed Python 3.12 for MCP Python environments when Homebrew builds are impractical. Xcode is optional for this workstation; the shared xcode-tools definition may remain configured but can stay offline.

Scripts Management Migration Plan

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:

Proxmox - PBS Backups via NAS with to GDrive

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

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.

Immich & Photo Management Guide

Immich & Photo Management Guide#


1. Synology Photo Workflow#

Album Creation#

  1. In Synology Photo:
    • Move images from Personal space to Shared Space.
    • Create an album with the moved images.

2. Immich Management#

Update Attempt — 2026-10-02#

  • Host: HP1GPU (10.1.2.231), compose directory /home/marc/docker-compose/immich.
  • Attempted stable upgrade from v3.1.0 to v3.2.4, including CUDA machine learning; PostgreSQL and Valkey images were unchanged.
  • Pre-upgrade database dump: /mnt/Immich/Immich-Uploads/upgrade-backups/2026-10-02-v3.2.4/database.sql.gz. Gzip integrity check passed and the SQL dump completion marker was verified.
  • Original compose file preserved as docker-compose.yaml.pre-v3.2.4; stable image override saved as docker-compose.stable-v3.2.4.yaml.
  • Server failed to start with PostgreSQL password authentication failure. Restored the original compose file and recreated both application containers with local v3.1.0 images using docker-compose.recovery-v3.1.0.yaml.
  • The same database authentication error persisted after rollback to v3.1.0, indicating an authentication/configuration issue upon container recreation. Following the user’s restart through their 1Password workflow, the API responded successfully with v3.1.0 and pong, with zero application container restarts. The stable upgrade remains pending. Credential inspection requires explicit authorization under the vault agent instructions.
  • Root filesystem has approximately 3.2 GB free (95% used); old and new images retained. No database restore or credential changes performed.

External Libraries & Albums#

  1. Scan Libraries: Settings > Administration > External Library > Scan All Libraries.
  2. Monitor Progress: Jobs > Check when the job is finished.
  3. Create Album: Main page > Albums > Create Album > Select Photos.
  4. Sharing: Share with Nadine.

Backup Strategy#

  • Photo ingress: The HP1Photos share on the Synology VM is the source of truth and is pushed one-way to the UNAS-Pro Photos share by the Linux sync hosts.
  • Immich: Immich reads the photo library from the UNAS-Pro Photos share.
  • UNAS-Pro protection: TrueNAS nodes pull the Photos and Immich data from UNAS-Pro according to the schedules documented in Unifi UNAS-Pro Backup Strategy.
  • Manual sync: Run pushphotos on HP1GPU (10.1.2.231) or HP1Docker (10.1.2.202) when a sync is required.

See Unifi UNAS-Pro Backup Strategy#3.2 Synology Photos to UNAS-Pro Push for the mounts, script, exclusions, and deletion policy.

Pangolin Backup Strategy

1 VPS BACKUP SYSTEM: Pangolin Docker#

Manual Backup Verification — 2026-10-02#

  • Triggered the existing backup script as vps-backup on VPSBackups LXC 102 (10.1.2.102) for RN-VPS (72.11.147.220); it completed successfully.
  • The current script stops the Pangolin stack, creates the archive on the VPS, restarts the stack, transfers the archive to LXC 102, and applies retention on both hosts.
  • Verified archive: /home/vps-backup/Backups/2026-10-02_08h27_PangolinBackup.tar.gz (313,781,104 bytes). The timestamp is the backup host’s local time.
  • The archive passed gzip -t; its file listing contains docker-compose.yml, config/db/db.sqlite, and config/traefik/traefik.yaml. A restore test was not performed.
  • All six Pangolin stack containers were running afterward; Pangolin and CrowdSec reported healthy. No component versions were changed.
  • Documentation discrepancy: /mnt/VPSBackups does not currently exist on LXC 102. The older storage and live-mirror references below have not been revalidated; the verified archive destination is /home/vps-backup/Backups/.

Target VPS: 72.11.147.220
VPS Provider: RackNerd (RN-VPS)
Backup LXC: Proxmox 102
Retention: 28 Files (14 Days)

Pangolin Tunnel - VPS Setup

Pangolin Tunnel Setup Guide#


Current VPS and SSH Access (Verified 2026-08-12)#

The current Pangolin VPS is hosted by RackNerd:

  • VPS hostname: RN-VPS
  • VPS public IP: 72.11.147.220
  • Operating system: Ubuntu
  • SSH port: TCP 22
  • Current home public IP: 208.96.219.86 (may change when the ISP address changes)

SSH access is restricted by multiple layers:

  1. UFW: incoming traffic is denied by default; TCP port 22 is allowed only from the current home public IP.
  2. Fail2ban: the sshd jail has the current home public IP in ignoreip, so it is not accidentally banned. The value must also be present persistently in /etc/fail2ban/jail.local.
  3. CrowdSec: the Pangolin container can enforce decisions through the Ubuntu host firewall via the INPUT and DOCKER-USER iptables chains.

The backup LXC connects outbound to the VPS. It does not require an inbound connection from the VPS to the home network. If the ISP IP changes, update both UFW and Fail2ban before the next backup.

Proxmox - Configuration

Proxmox - Configuration#

For fresh installations and initial server builds, please refer to the Proxmox - Initial Setup guide for automated provisioning steps.


1. Storage Management#

1.1 Storage: ZFS Pool Creation#

Create a simple mirrored or striped ZFS pool via CLI.

# Create a pool named 'Storage' using two disks
zpool create Storage sdb sdc

# The pool will now appear in Node > Storage > ZFS

1.2 Storage Specific Tests#

# Test SMB Share Throughput
dd if=/dev/zero of=/mnt/pve/HP1Storage/test.file bs=1M count=4000

# Test local-lvm Performance
dd if=/dev/zero of=/var/lib/vz/test.file bs=1M count=4000

2. Networking#

2.1 Add Second Network Bridge (Isolated VM Traffic)#

Use this for dedicated VM traffic on a specific physical port (e.g., eno6).