211 lines
3.3 KiB
Markdown
211 lines
3.3 KiB
Markdown
<p align="center">
|
||
<img src="images/architecture-diagram.png" width="50%" alt="Architecture Diagram">
|
||
</p>
|
||
|
||
# 🧠 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
|
||
|
||
```text
|
||
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:
|
||
|
||
```bash
|
||
/opt/update-manager/hosts.conf
|
||
```
|
||
|
||
Format:
|
||
|
||
```text
|
||
name ip user
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
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:
|
||
|
||
```bash
|
||
/opt/update-manager/log/update-manager.log
|
||
```
|
||
|
||
Log format:
|
||
|
||
```text
|
||
YYYY-MM-DD HH:MM:SS [LEVEL] host - message
|
||
```
|
||
|
||
Example:
|
||
|
||
```text
|
||
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:
|
||
|
||
```bash
|
||
apt list --upgradable
|
||
```
|
||
|
||
4. Parse output
|
||
5. Determine:
|
||
|
||
* Up-to-date
|
||
* Updates available
|
||
* Connection failure
|
||
6. Write result to:
|
||
|
||
* terminal output
|
||
* log file
|
||
|
||
---
|
||
|
||
## Configuration
|
||
|
||
Primary config:
|
||
|
||
```bash
|
||
/etc/update-manager.conf
|
||
```
|
||
|
||
Fallback:
|
||
|
||
```bash
|
||
./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.
|
||
|