1 n8n Automated Server Audit — “Intelligent Server Update Monitor with AI Recommendations”#

When local SMTP is unavailable or when you want a richer, centrally-consolidated overview of the entire fleet’s update posture, an n8n workflow (imported from Intelligent Server Update Monitor with AI Recommendations.json) runs on a repeating schedule to SSH into every node, inspect pending packages via apt list --upgradable, send those results through a local Ollama instance for intelligent categorisation, and deliver the verdict in your inbox.

1.1 What it does (in brief)#

The workflow executes five distinct schedule-triggered groups. Each group:

1. SSHes into its assigned servers (private-key auth) running apt list --upgradable, capturing hostname & IP using marker-delimited output (HOSTNAME / IPADDRESS).
2. Aggregates all server results and branches depending on whether any updates are available.
3. If updates exist, bundles every package string into a single prompt sent to the local Ollama API (http://10.1.2.231:11435/api/generate, model llama3.2:latest, temperature 0.2).
4. The AI response classifies each package by category (SECURITY / BUG_FIX / FEATURE / OTHER), urgency (CRITICAL / HIGH / MEDIUM / LOW), whether a reboot is needed, and provides an overall summary object.
5. A Format Consolidated Report node turns the structured JSON into HTML and sends an email via proxmox.app@gmail.com (SMTP credential: XF5FJ0lpvaUmmzs5).
6. If every server in a group reports zero updates, a simpler All-clear Email is sent instead.
7. Each trigger also fires a Pushover notification when the job starts ("[GROUP] [TIME] n8n Script Started").

1.2 Server Inventory — who gets checked and when#

Footnotes:

• HP1Couds — likely a typo/historical name for an HP-series cloud/VPS node.
• Datacenter / Pi-Hole 2 / HP1VPSBackup / MMProxmox / Pi-Hole / RN-VPS — external or off-prem nodes monitored via SSH.
• MMProxmox appears to be a separate hardware node (“Micro Server” series).
• There are two distinct Pi-hole instances: one named Pi-Hole 2 in groups 1 & 3, another named Pi-Hole in group 2.

Total: 6 unique schedules firing across the fleet, touching ~28 server connections (some overlap between groups).

1.3 Group-by-group workflow topology#

Every group follows the same internal structure:

[ScheduleTrigger]
    → [SSH nodes × N servers] → [Process Code node per server]
                                ↓
                         [Aggregate All Results]
                                ├── Branch: has_updates ──▶ [Prepare For AI Analysis]
                                                                      └─▶ [Ollama AI Analysis (HTTP)]
                                                                            └─▶ [Consolidate Analysis]
                                                                                  └─▶ [Format Consolidated Report]
                                                                                        └─▶ [Send Consolidated Update Email]
                                ├── Branch: no_updates ──▶ [Format No Updates Report]
                                                                      └─▶ [Send All Clear Email]
                                └── Branch: ssh_error ──▶ [Format SSH Errors]
                                                                              └─▶ [Send Consolidated SSH Error Email]

Group 1 — HP1-Proxmox 8:10 (daily, first batch)#

• SSH nodes: HP1TrueNAS, HP1Proxmox, HP1Docker, HP1BackupServer, HP1GPU, HP1Couds, Datacenter, Pi-Hole 2, HP1VPSBackup
• Prompt template sent to Ollama (verbatim key points):

  “You are a Linux system administrator expert. Analyze these server update packages and provide detailed recommendations… For each package: package name, category (SECURITY/BUG_FIX/FEATURE/OTHER), urgency (CRITICAL/HIGH/MEDIUM/LOW), reboot_required (bool), reason, recommendation. Also an overall summary object with: overall_urgency, total_reboot_required, recommended_action (IMMEDIATE/SCHEDULED_24H/SCHEDULED_WEEK/NEXT_MAINTENANCE), maintenance_window_suggestion, executive_summary (2-3 sentences), technical_notes. Return ONLY valid JSON…”

Group 2 — MMProxmox 8:15 (daily, +5 min stagger)#

• SSH nodes: MMProxmox, Pi-Hole, MMDocker
• Same Ollama prompt template & model as Group 1.
• Staggered by 5 minutes from Group 1 to avoid simultaneous SSH blast.

Group 3 — HP4 Daily 13:30 (daily midday)#

• SSH nodes: HP4Proxmox, HP4BackupServer
• Sends a dedicated Pushover notification with text "HP4 13:30 n8n Script Started".

Group 4 — HP3 Sun 9:20 (weekly, Sunday)#

• SSH nodes: HP3Proxmox, HP3TrueNAS, HP3GPU
• Weekly cadence reflects that these are likely lower-traffic or less critical systems.

Group 5 — HP7-HP8-VPS 9:10 (daily morning)#

• SSH nodes: HP7TrueNAS, HP8Proxmox, HP8BackupServer, HP8TrueNAS, RN-VPS, HP8GPU
• Monitors both on-prem HP-series and an off-site VPS.

Group 6 — HP2 18:10 (daily evening)#

• SSH nodes: HP2Proxmox, HP2Docker, HP2TrueNAS, HP2BackupServer, HP2GPU
• Same Ollama prompt template & model as Groups 1–5.
• The 7-hour gap between the last morning batch (Groups 1/2 at 8:10) and this evening group means it picks up any midday package rollouts or weekend maintenance that slipped earlier. Used to confirm you receive those daily emails.

1.4 AI prompt & expected response format#

The workflow sends each server’s raw apt list --upgradable lines to Ollama with a system prompt asking for JSON structured like:

{ "packages": [
  {
    "package": "linux-libc-dev",
    "category": "SECURITY",
    "urgency": "HIGH",
    "reboot_required": false,
    "reason": "CVE fix for memory management",
    "recommendation": "Patch within 24-48 hours. No reboot expected."
  }
],
 "summary": {
   "overall_urgency": "HIGH",
   "total_reboot_required": false,
   "recommended_action": "SCHEDULED_24H",
   "maintenance_window_suggestion": "Tuesday or Wednesday night (01:00-05:00)",
   "executive_summary": "Two security patches available across HP4Proxmox and HP4BackupServer. No reboot required.",
   "technical_notes": "glibc update on HP4BackupServer may require service restarts for Docker containers."
 }
}

1.5 Key observations & considerations#

1. No kernel updates are requested — the workflow only calls apt list --upgradable; kernel blacklisting is handled at the OS level (§3.1 above).
2. SSH error handling is silent — if a server fails to respond, it produces an SSH Error Email but no AI analysis follows (correctly, since there’s nothing to analyse).
3. HTTP timeout on Ollama: 300 seconds (5 min) — generous enough for a deep analysis prompt but will still fail if the node is under-heavy load.
4. Staggered triggers minimise SSH blast: groups fire at 8:10, 8:15, 9:10, 13:30, 18:10 (HP2), and Sunday 9:20 — a spread of ~6h+ across weekdays.