ed/update-manager
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
update-manager/docs/architecture.md

3.2 KiB
Raw Blame History

🧠 Update Manager Architecture

This document describes how Update Manager is structured internally and how data flows through the system.

Overview

Update Manager is a lightweight, SSH-based system for managing updates across multiple Linux hosts.

It consists of two main layers:

  • UI layer – interactive menu (update-manager-ui.sh)
  • Core engine – update logic (update-manager.sh)

The system is designed to be simple, transparent, and dependency-light.

High-Level Flow

User
  ↓
UI (update-manager-ui.sh)
  ↓
Core (update-manager.sh)
  ↓
SSH → Remote Hosts
  ↓
Results
  ↓
Logging (/opt/update-manager/log)
  ↓
UI / User

Components

UI Layer (update-manager-ui.sh)

Responsible for:

  • Displaying menu (via dialog)
  • Handling user input
  • Managing hosts (add/remove/edit)
  • Providing access to logs
  • Delegating actions to core engine

The UI does not perform updates directly.

Core Engine (update-manager.sh)

Responsible for:

  • Reading configuration
  • Parsing hosts file
  • Executing SSH commands
  • Checking for updates (apt list --upgradable)
  • Handling connection errors
  • Writing structured logs

This is the execution layer of the system.

Hosts Configuration

File:

/opt/update-manager/hosts.conf

Format:

name    ip    user

Example:

server1       192.168.1.10    user
server2       192.168.1.20    user
server3       192.168.1.30    user

Each line represents a target system accessed via SSH.

Logging System

Log file:

/opt/update-manager/log/update-manager.log

Log format:

YYYY-MM-DD HH:MM:SS [LEVEL] host - message

Example:

2026-03-18 20:45:01 [INFO] lanx-www - Checking updates
2026-03-18 20:45:03 [OK] lanx-www - 3 updates available
2026-03-18 20:45:05 [ERR] lanx-db - Connection failed

Log Levels

  • INFO – informational messages
  • OK – successful operations
  • ERR – errors or failures

Logging is centralized and written locally.

Execution Flow

For each host:

  1. Read host entry from hosts.conf
  2. Establish SSH connection
  3. Execute:
apt list --upgradable

  1. Parse output

  2. Determine:

    • Up-to-date
    • Updates available
    • Connection failure

  3. Write result to:

    • terminal output
    • log file

Configuration

Primary config:

/etc/update-manager.conf

Fallback:

./update-manager.conf

Supported options:

  • HOSTS_FILE
  • SSH_OPTIONS

Design Principles

  • No agents – uses standard SSH only
  • Simple over complex – minimal dependencies
  • Transparent behavior – everything is visible/logged
  • CLI-first – designed for terminal environments
  • Modular growth – prepared for future extensions

Future Architecture Direction

Planned extensions:

  • Plugin system (modular features)
  • Web interface (optional UI layer)
  • Notification system (alerts)
  • Metrics / monitoring
  • Integration with Lanx AI

Summary

Update Manager follows a clean separation:

  • UI = interaction
  • Core = execution
  • Config = data
  • Log = output

This keeps the system predictable, debuggable, and easy to extend.