LOGAR is an enterprise-grade log aggregation, normalization, and centralized provisioning system ("Log-Zusammenführung und Bereitstellung") built for heterogeneous server fleets (Windows & Linux). It pairs ultra-lightweight, zero-state edge forwarders with a secure centralized server hub that enforces mutual TLS 1.3 (mTLS) authentication, dynamic PKI fleet licensing with cryptographic seat leasing, 12-hour temporal persistence tracking, and direct anomaly pass-through—delivering clean, structured, verified log telemetry directly to Hermes AI for autonomous deep reasoning, contextual root-cause analysis, and operational decision-making.

Core Purpose & Philosophy (Log-Zusammenführung & Bereitstellung)
End-to-End System Architecture
System State Machines & Subsystem Lifecycles
Master License Authority & PKI Fleet Licensing
mTLS 1.3 Transport Security & Forwarder Auto-Enrollment
Cloud-Side Temporal Persistence & Direct Hermes Reasoning
Agentic Hermes & Client Management API
Dynamic Machine & Domain Identification
Automated Service Installers (Linux & Windows)
Repository & Shippables Structure
Getting Started & Deployment
Running Tests
Automated Releases via Gitea Actions

Core Purpose & Philosophy

1. Centralized Log Aggregation & Provisioning (Log-Zusammenführung & Bereitstellung)

The foundational objective of LOGAR is reliable, secure collection and structured delivery of system events:

Heterogeneous Fleet Aggregation: Ingests Windows Event Logs (System, Application, Security) and Linux systemd journalctl events into a unified, normalized JSON data format.
Centralized Provisioning: Serves as the authoritative clearinghouse and real-time streaming endpoint (/api/hermes/report), providing structured logs with temporal metadata to external consumers and automated AI agents.
Zero Local Edge Footprint: Forwarders maintain zero local databases, zero cache files, and zero disk overhead. If a network disruption occurs, agents automatically re-establish mTLS streaming without state corruption.

2. Direct Hermes Intelligence (No Heuristic Bottlenecks)

LOGAR strictly separates data aggregation/provisioning from semantic reasoning:

Removal of Arbitrary Heuristics: The legacy 4-run throttling rule was eliminated. All ingested candidate logs (INFO, WARNING, ERROR, CRITICAL) within the active 12-hour temporal evaluation window are immediately verified and provisioned.
Hermes Autonomous Thinking: Hermes AI performs all multi-factor reasoning, cross-server correlation, urgency prioritization, and automated remediation decisions directly on the provisioned log stream.

3. Hierarchical Dynamic PKI & Fleet Licensing

Authoritative Master PKI: Subordinate server hubs do not require manual certificate generation or static keys. The Master License Authority (logar.eibl.tech) issues cryptographically signed Sub-CA certificates with custom X.509 seat quotas (1.3.6.1.4.1.59999.1.1).
Dynamic Seat Leasing: Server hubs enforce local seat allocations in real-time, instantly revoking or admitting edge nodes while synchronizing with the central authority over bidirectional WebSockets.

End-to-End System Architecture

graph TB
    subgraph Authority [Master License Authority - logar.eibl.tech]
        M_CA[Master Root CA<br/>RSA-4096 / SHA-256]
        AUTH_WS[WebSocket Licensing Hub<br/>/ws/license]
        AUTH_DB[(Authority DB<br/>Tenants, Users, 2FA, Seats)]
        AUTH_UI[Authority WebUI<br/>User Mgmt & Fleet Quotas]
        AUTH_WS --- AUTH_DB
        AUTH_UI --- AUTH_DB
    end

    subgraph ServerHub [LOGAR Server Hub - Central Aggregation & Provisioning]
        SUB_CA[Subordinate CA<br/>Signed with Seat OID 1.3.6.1.4.1.59999.1.1]
        SEAT_MGR[Dynamic Seat Manager<br/>Enforces Seat Quota in SQLite]
        MTLS_SRV[mTLS 1.3 Ingestion Server<br/>Port 9443 - ssl.CERT_REQUIRED]
        TEMP_ENG[12h Temporal Persistence Engine<br/>Correlates First/Last Seen & Run Counts]
        HUB_DB[(logar_state.db<br/>active_issues, clients, config)]
        PROV_API[Log Provisioning & Hermes API<br/>Port 8443 - GET /api/hermes/report]
        
        SUB_CA --> SEAT_MGR
        SEAT_MGR --> MTLS_SRV
        MTLS_SRV --> TEMP_ENG
        TEMP_ENG --> HUB_DB
        HUB_DB --> PROV_API
    end

    subgraph EdgeNodes [Heterogeneous Edge Forwarders]
        WIN[Win_Client.exe / Win_Client.py<br/>Windows Event Log Ingestion]
        LIN[Linux_Client.bin / Linux_Client.py<br/>systemd journalctl -p warning]
    end

    subgraph Downstream [Hermes AI Reasoning Layer]
        HERMES[Hermes AI Engine<br/>Autonomous Analysis & Remediation]
    end

    %% PKI & Licensing Relationships
    M_CA -->|Signs Sub-CA Cert via /ws/license| SUB_CA
    AUTH_WS <==>|Bidirectional Sync & Live Seat Expansion| SUB_CA
    
    %% Forwarder Enrollment & mTLS Transport
    WIN -->|1. Auto-Enrollment POST /api/client/enroll| SUB_CA
    LIN -->|1. Auto-Enrollment POST /api/client/enroll| SUB_CA
    SUB_CA -->|2. Issues Client Cert & Root Trust| WIN
    SUB_CA -->|2. Issues Client Cert & Root Trust| LIN
    
    WIN ==>|3. Continuous mTLS 1.3 Stream :9443| MTLS_SRV
    LIN ==>|3. Continuous mTLS 1.3 Stream :9443| MTLS_SRV

    %% Log Provisioning & Hermes Consumption
    PROV_API ==>|Centralized Log Delivery| HERMES

System State Machines & Subsystem Lifecycles

3.1 High-Level System State Machine

A simplified macroscopic view of the end-to-end LOGAR lifecycle:

stateDiagram-v2
    [*] --> 1_PKI_Licensing: Master Authority generates Bootstrap .lic Package
    1_PKI_Licensing --> 2_Hub_Ready: Server Hub imports .lic & signs Sub-CA over WebSocket
    2_Hub_Ready --> 3_Edge_Enrollment: Edge Forwarders auto-enroll & lease licensed seats
    3_Edge_Enrollment --> 4_mTLS_Streaming: Forwarders stream framed logs over mTLS 1.3 (:9443)
    4_mTLS_Streaming --> 5_Temporal_Aggregation: Server Hub normalizes & correlates logs in 12h window
    5_Temporal_Aggregation --> 6_AI_Provisioning: Logs provisioned to Hermes AI via GET /api/hermes/report
    6_AI_Provisioning --> 4_mTLS_Streaming: Continuous operational loop

3.2 Master License Authority & WebSocket Enrollment State Machine

Details the bidirectional cryptographic enrollment, seat leasing, and hot-reload lifecycle between logar.eibl.tech and the LOGAR Server Hub:

stateDiagram-v2
    [*] --> Idle_Unlicensed: Server Hub initial launch (no active license)
    
    state "Master Authority (logar.eibl.tech)" as MasterAuth {
        BootstrapGenerated: Generates Bootstrap .lic with Comm Cert & CSR Template
        WS_Listening: WebSocket Hub listening on /ws/license
        ValidateCSR: Validates Server CSR & Hardware Fingerprint
        SignSubCA: Signs Sub-CA with OID_LOGAR_SEATS (1.3.6.1.4.1.59999.1.1)
    }

    state "LOGAR Server Hub PKI Engine" as ServerPKI {
        ImportLic: Admin imports .lic file via CLI or WebUI
        GenerateLocalCSR: Server generates local Sub-CA Keypair & CSR
        WS_Connecting: Opens WebSocket to wss://logar.eibl.tech/ws/license
        InstallSubCA: Installs signed Sub-CA Cert & Master Root Trust
        ActivateSeatQuota: Parses Seat OID & initializes SQLite seat quota
        mTLS_Listening: Starts mTLS 1.3 Listener on Port 9443
        
        HeartbeatSync: Sends periodic check_updates heartbeat over WebSocket
        InFlightReload: Hot-reloads ssl.SSLContext without restarting service
        
        RevokedState: License revoked by Master Authority
        DropConnections: Drops all incoming mTLS connections immediately
    }

    BootstrapGenerated --> ImportLic: Operator deploys .lic
    ImportLic --> GenerateLocalCSR
    GenerateLocalCSR --> WS_Connecting
    WS_Connecting --> WS_Listening: action="enroll_or_sync"
    WS_Listening --> ValidateCSR
    ValidateCSR --> SignSubCA
    SignSubCA --> InstallSubCA: status="success", ca_cert, master_root_ca
    InstallSubCA --> ActivateSeatQuota
    ActivateSeatQuota --> mTLS_Listening
    
    mTLS_Listening --> HeartbeatSync: Scheduled or manual sync
    HeartbeatSync --> WS_Listening: action="check_updates"
    WS_Listening --> InFlightReload: Updated seat quota / renewed cert
    InFlightReload --> mTLS_Listening
    
    WS_Listening --> RevokedState: Authority revokes license_id
    RevokedState --> DropConnections

3.3 Edge Forwarder Auto-Enrollment & mTLS Lifecycle State Machine

Details how edge nodes discover their identity, bootstrap mTLS trust, and stream logs without local state:

stateDiagram-v2
    [*] --> HostDiscovery: Edge Client (Win_Client / Linux_Client) launches
    
    state "Machine & Domain Identification" as Disc {
        HostDiscovery --> QueryFQDN: socket.getfqdn()
        QueryFQDN --> OS_DomainDiscovery: Windows AD env / Linux resolv.conf
        OS_DomainDiscovery --> BuildClientID: Computes FQDN client_id & Site Attribution
    }

    state "Zero-Touch Enrollment" as Enroll {
        CheckLocalCert: Inspects certs/client.crt & certs/ca.crt
        EnrollRequest: POST /api/client/enroll with enrollment_secret
        VerifyQuota: Server verifies secret & active_seats < max_seats
        StoreCerts: Saves client.crt, client.key, ca.crt
    }

    state "Secure Streaming & Self-Healing" as Stream {
        mTLS_Handshake: Mutual TLS 1.3 Handshake (Port 9443)
        ValidateClientCN: Server checks client_id status in clients table
        ActiveStreaming: Streams candidate log frames (INFO..CRITICAL)
        CertExpiryCheck: Checks client cert validity before each run
        ProactiveRenew: Renews cert when expiring in < 30 days
        ReactiveSelfHeal: Re-enrolls automatically on CA rotation / handshake error
    }

    BuildClientID --> CheckLocalCert
    CheckLocalCert --> mTLS_Handshake: Valid local certificates exist
    CheckLocalCert --> EnrollRequest: Certificates missing or expired
    EnrollRequest --> VerifyQuota
    VerifyQuota --> StoreCerts: 200 OK (Certificate Issued)
    VerifyQuota --> [*]: 403 Forbidden (Seat Quota Full / Bad Secret)
    StoreCerts --> mTLS_Handshake
    
    mTLS_Handshake --> ValidateClientCN
    ValidateClientCN --> ActiveStreaming: Client active in DB
    ValidateClientCN --> [*]: Client seat revoked
    
    ActiveStreaming --> CertExpiryCheck
    CertExpiryCheck --> ProactiveRenew: Expiry < 30 days
    ProactiveRenew --> EnrollRequest
    ActiveStreaming --> ReactiveSelfHeal: Handshake failure / CA changed
    ReactiveSelfHeal --> EnrollRequest

3.4 Fleet Log Aggregation, 12h Temporal Window & AI Provisioning State Machine

Details how log events are extracted, deduplicated, temporally tracked, and provisioned directly to Hermes AI:

stateDiagram-v2
    [*] --> EventCaptured: Windows Event Log / Linux journalctl event
    
    state "Edge Filtering (Zero State)" as EdgeFilter {
        EventCaptured --> NoiseStripping: Discards DEBUG, trace logs & events > 24h old
        NoiseStripping --> FrameEncoding: Normalizes to JSON frame (severity, site, server, signature)
    }

    state "Server Ingestion & 12h Temporal Window" as ServerIngest {
        FrameIngested: mTLS Socket reads length-prefixed frame
        ComputeFingerprint: Fingerprint = {site}:{server}:{signature}
        EvaluateTemporalWindow: Compares (now - last_seen) against 12h window
        
        state EvaluateTemporalWindow <<choice>>
        WithinWindow: (now - last_seen) <= 12 hours
        WindowExpired: (now - last_seen) > 12 hours (First run in new window)
        
        UpdatePersistence: Increment consecutive_runs, update last_seen
        ResetWindow: Set consecutive_runs = 1, update first_seen & last_seen
        
        UpsertSQLite: Upserts active_issues with status="VERIFIED"
    }

    state "Centralized Provisioning & Hermes AI" as AIProvision {
        API_Report: GET /api/hermes/report (Port 8443)
        JSON_Payload: Delivers structured verified anomalies with temporal metadata
        HermesThinking: Hermes AI executes multi-factor reasoning & autonomous decisions
    }

    FrameEncoding --> FrameIngested: Streamed over mTLS 1.3
    FrameIngested --> ComputeFingerprint
    ComputeFingerprint --> EvaluateTemporalWindow
    EvaluateTemporalWindow --> WithinWindow: Existing issue seen recently
    EvaluateTemporalWindow --> WindowExpired: New issue or inactive > 12h
    WithinWindow --> UpdatePersistence
    WindowExpired --> ResetWindow
    UpdatePersistence --> UpsertSQLite
    ResetWindow --> UpsertSQLite
    
    UpsertSQLite --> API_Report
    API_Report --> JSON_Payload
    JSON_Payload --> HermesThinking

Master License Authority & PKI Fleet Licensing

1. TLS 1.3 Mutual Authentication (mTLS)

Port 9443: Ingestion occurs exclusively over TLS 1.3 sockets with ssl.CERT_REQUIRED.
Both the hub and edge clients verify each other's certificates:
- Client verifies server certificate against ca.crt.
- Server verifies client certificate against the Subordinate/Root CA.
Client CN Identification & Revocation: In the TLS handshake, the server extracts the commonName attribute (client_id), validates that the client is marked active in the clients table, updates the last_seen timestamp, and drops unregistered or revoked certificates immediately.

2. Master License Authority (`logar.eibl.tech`), Multi-Tenancy & Subordinate CA

Master Root Authority: Standalone PKI repository & submodule (LOGAR-LICENSING/, upstream at https://gitea.eibl.tech/me0nline/LOGAR-LICENSING.git) deployed at logar.eibl.tech.
Multi-Tenant Fleet Isolation & User Management:
- Supports multiple isolated Tenants (e.g. DEFAULT, CORP_A, PRODUCTION_FLEET) with live tenant filtering.
- Built-in user management with PBKDF2 password hashing, RBAC (Administrators & Operators), and self-service password updates.
Custom Enterprise X.509 OIDs:
- OID_LOGAR_SEATS (1.3.6.1.4.1.59999.1.1): Embeds the exact licensed seat quota directly inside the signed Subordinate CA certificate.
- OID_LOGAR_LICENSE_ID (1.3.6.1.4.1.59999.1.2): Uniquely tracks enterprise license entitlement.
- OID_LOGAR_ISSUER_URL (1.3.6.1.4.1.59999.1.3): Embedded endpoint coordinate (https://logar.eibl.tech).
Bootstrap .lic Packages & Instant WebSocket Auto-Enrollment:
- The License Authority (logar.eibl.tech) generates initial Bootstrap .lic Packages containing Master Root CA, dedicated communication credentials (communication_cert + communication_key), CSR templates, assigned tenant, and WebSocket coordinates bound directly to the authority server host.
- 1-Click Import & Live Signing: Importing the .lic file on the client server (python src/Server.py --import-lic <file.lic> or via WebUI) connects directly via WebSocket, submits the server Sub-CA CSR, and immediately installs the officially signed Sub-CA license certificate.
Self-Updating Client Servers & Live WebSocket Sync:
- Client servers update themselves against the master authority (wss://logar.eibl.tech/ws/license) over WebSocket (python src/Server.py --sync-license or via WebUI / automated watchdog).
- Seat quotas can be increased with each renewal or updated on-demand in the License Authority WebUI.
- The client server automatically receives the updated seat quota in its signed certificate, updates its SQLite database and runtime configuration, and reloads its in-flight ssl.SSLContext without dropping client connections or restarting services.
Automated Container Pipeline & Ephemeral NPM Pass-Through:
- The license authority repository includes a dedicated CI/CD workflow (.gitea/workflows/build-container.yml) publishing to gitea.eibl.tech/me0nline/logar-licensing:latest (authenticated via giteatoken secret).
- Works seamlessly with ephemeral Nginx Proxy Manager (NPM) by enabling the standard Websockets Support toggle for logar.eibl.tech.
- Admin WebUI is protected by authenticated login with user and tenant administration.

3. Integrated Fleet Licensing & WebUI Dashboard

WebUI URL: Accessible at http://<server_host>:8443/webui (or /).
Visual Seat Quota Meter: Real-time progress bar displaying active forwarders vs. allocated seat limit.
Licensing Actions:
- 1-click Export .lic Request file download.
- Interactive View & Copy CA CSR modal.
- Drag-and-drop or paste Import License (.lic / ca.crt) modal.
- Sync & Renew via mTLS button for immediate upstream synchronization and seat expansion.
Seat Management & Revocation Table:
- Lists all connected Windows and Linux edge forwarders.
- Revoke Seat: Instantly drops and blocks the client at the TLS socket handshake layer.
- Reactivate Seat: Restores the client to active status if within seat quota limits.

4. Cloud-Side In-Flight Certificate Watchdog

Continuous Hub PKI Watchdog:
- The server hub runs a continuous background watchdog coroutine (cert_validity_watchdog, running every 12 hours).
- Automatically renews Subordinate CA certificates over mTLS with logar.eibl.tech and Server TLS certificates in-flight, dynamically reloading the active ssl.SSLContext.
Client Proactive Check & Reactive Self-Healing:
- Proactive Renewal: Edge clients inspect client.crt before every run cycle. If expiring within 30 days, they contact /api/client/enroll to renew.
- Reactive Self-Healing: If the server CA rotates or a handshake error occurs, edge clients catch the exception, re-bootstrap enrollment against the hub, and re-establish streaming cleanly.

Cloud-Side Temporal Persistence & Direct Hermes Reasoning

Incoming candidate logs are tracked in SQLite table active_issues:

Issue Fingerprint: Formatted as {site_name}:{server}:{signature}.
12-Hour Evaluation Window:
- The hub compares (now - last_seen).
- If more than 12 hours have elapsed since the issue was last recorded, the previous window expires and the cycle resets to run_count = 1.
Direct Verification & Temporal Telemetry:
- Ingested anomalies are immediately promoted to VERIFIED and made available to Hermes with complete temporal metadata (first seen, last seen, consecutive run counts).
- Hermes performs all contextual analysis, pattern recognition, and alerting logic.

Agentic Hermes & Client Management API

The server hub exposes a management and reporting REST API (default port 8443):

`POST /api/client/enroll`

Client enrollment endpoint:

Request:

{
  "client_id": "web-worker-01.corp.internal",
  "hostname": "web-worker-01",
  "os": "linux",
  "enrollment_secret": "<SECRET>"
}

Response:

{
  "ca_cert": "-----BEGIN CERTIFICATE-----\n...",
  "client_cert": "-----BEGIN CERTIFICATE-----\n...",
  "client_key": "-----BEGIN RSA PRIVATE KEY-----\n..."
}

`GET /api/clients`

Returns seat quota status and registered client telemetry:

{
  "active_seats": 2,
  "max_seats": 10,
  "clients": [
    {
      "client_id": "web-worker-01.corp.internal",
      "hostname": "web-worker-01",
      "os_type": "linux",
      "cert_fingerprint": "7D5B660B...",
      "status": "active",
      "first_seen": "2026-09-04 18:00:00",
      "last_seen": "2026-09-04 19:15:00"
    }
  ]
}

`GET /api/hermes/report`

Returns all verified anomalies within the active 12-hour evaluation window with full temporal metadata for direct Hermes reasoning:

[
  {
    "fingerprint": "corp.internal:web-worker-01.corp.internal:PostgresPoolExhausted",
    "site": "corp.internal",
    "server": "web-worker-01.corp.internal",
    "signature": "PostgresPoolExhausted",
    "severity": "WARNING",
    "message": "Connection pool saturated (>95%)",
    "os_type": "linux",
    "first_seen": "2026-09-04T07:00:00+00:00",
    "last_seen": "2026-09-04T19:00:00+00:00",
    "consecutive_runs": 4,
    "evaluation_window": "12h",
    "verified": true,
    "status": "VERIFIED"
  }
]

`GET /api/hermes/all`

Diagnostic endpoint listing all tracked anomalies in SQLite.

`GET /health`

Returns hub health, encryption fingerprint, listener ports, and mTLS status.

Dynamic Machine & Domain Identification

Client configurations intentionally contain no hardcoded machine name or site name. Both forwarders dynamically identify their host and domain at runtime via get_machine_identifier():

Fully Qualified Domain Name (FQDN): Checked via socket.getfqdn().
OS-Specific Domain Discovery:
- Windows: Checks Active Directory environment variables (USERDNSDOMAIN, USERDOMAIN).
- Linux: Parses /etc/resolv.conf domain and search directives.
Reverse DNS Lookup: Resolves canonical hostname via socket.gethostbyaddr.
Fallback: Local hostname socket.gethostname().

The server automatically infers site attribution from domain qualifiers (e.g. node01.corp.internal \rightarrow site corp.internal).

Automated Service Installers (Linux & Windows)

LOGAR provides production-grade installation scripts and installer builders for automated service deployment:

1. Linux Service Installers

Client Installer (compilation/install_linux_client.sh):
- Non-interactive script deploying to /opt/logar-client.
- Automatically queries /etc/machine-id and enrolls with the hub via curl.
- Installs and enables logar-client.service systemd unit.
```
sudo ./compilation/install_linux_client.sh "http://hub.example.com:8443" "<ENROLLMENT_SECRET>"
```
Server Installer (compilation/install_linux_server.sh):
- Deploys server to /opt/logar-server.
- Configures logging and installs logar-server.service with LimitNOFILE=65536.
```
sudo ./compilation/install_linux_server.sh
```

2. Windows Inno Setup Installers

Built using Inno Setup 6 and bundled with NSSM (compilation/nssm.exe):
- Client Setup (compilation/installer_client.iss): Compiles LOGAR-Client-Setup.exe. Installs Win_Client.exe into {autopf}\LOGAR, sets up LOGAR_Client service via NSSM with stdout/stderr redirection to {commonappdata}\LOGAR\client.log, and starts the service. Clean uninstallation stops and removes the service.
- Server Setup (compilation/installer_server.iss): Compiles LOGAR-Server-Setup.exe. Installs Server.exe and sets up LOGAR_Server Windows service via NSSM.

Repository & Shippables Structure

LOGAR/
├── .gitea/
│   └── workflows/
│       ├── ci.yml                     # CI pipeline: syntax, 25 unit tests & mTLS pipeline test
│       └── release.yml                # Consolidated release workflow (Linux binaries & Windows installers)
├── compilation/                       # Packaging, installers, and release automation
│   ├── install_linux_client.sh        # Automated Linux client systemd installation script
│   ├── install_linux_server.sh        # Automated Linux server systemd installation script
│   ├── installer_client.iss           # Inno Setup Windows Client installer script
│   ├── installer_server.iss           # Inno Setup Windows Server installer script
│   ├── nssm.exe                       # Official 64-bit NSSM service manager binary
│   ├── package_dist.py                # Standalone binary compiler & packager
│   ├── requirements.txt               # Unified project dependencies
│   └── upload_release.py              # Gitea REST API release asset publisher
├── src/                               # Core application source modules
│   ├── __init__.py
│   ├── Server.py                      # Central mTLS server, temporal engine, and Hermes REST API
│   ├── server_enrollment.py           # Dynamic PKI, Root CA, and client certificate generator
│   ├── Win_Client.py                  # Windows edge forwarder with auto-enrollment
│   └── Linux_Client.py                # Linux edge forwarder with auto-enrollment
├── tests/                             # Automated test suites
│   ├── test_linux_client.py           # Linux client unit tests & mTLS certificate validation
│   ├── test_pipeline.py               # End-to-end mTLS integration & direct anomaly verification test
│   ├── test_server.py                 # Server unit tests, PKI generation, and seat quota tests
│   └── test_win_client.py             # Windows client unit tests & mTLS certificate validation
├── .gitignore                         # Ignores venv, caches, DBs, and private keys
├── README.md                          # Architecture and usage documentation
├── RELEASE_NOTES.md                   # Release history and changelog
├── server_config.sample.json          # Reference server configuration
└── out/                               # Component guides and sample configs
    ├── linux_server/
    │   ├── README.md
    │   └── server_config.sample.json
    ├── win_server/
    │   ├── README.md
    │   └── server_config.sample.json
    ├── linux_client/
    │   ├── README.md
    │   └── client_config.sample.json
    └── win_client/
        ├── README.md
        └── client_config.sample.json

Getting Started & Deployment

1. Central Server Hub

Install dependencies:

pip install -r compilation/requirements.txt

Start the server (generates server_config.json, Root CA, and server certs on first run):
```
python src/Server.py
```

Export a client configuration:

python src/Server.py --create-client-config --server-host <SERVER_IP> --server-port 9443 --client-out client_config.json

2. Windows Client Deployment

Download LOGAR-Client-Setup.exe from releases and run it, or place Win_Client.exe and client_config.json in C:\Program Files\LOGAR.
On first run with client_config.json, Win_Client.exe automatically enrolls with the hub, receives its mTLS certificates, and establishes secure streaming.

3. Linux Client Deployment

Run the automated installer:

sudo ./compilation/install_linux_client.sh "http://<HUB_HOST>:8443" "<ENROLLMENT_SECRET>"

The installer enrolls the client, configures /etc/logar/certs, and activates logar-client.service.

Running Tests

1. Component Unit Tests

python -m unittest discover -s tests -v

Runs all 25 unit tests, covering:

Dynamic Root CA generation and server TLS certificate issuance.
Dynamic client certificate issuance with CN and authority key extensions.
Enrollment secret authentication, seat limits, and certificate revocation.
Proactive certificate validity checks, Root CA auto-renewal, and in-flight server SSLContext reload.
Windows & Linux event log collection, deduplication, and mTLS certificate verification.
12-hour evaluation window and direct Hermes anomaly verification.

2. End-to-End Pipeline Integration Test

# 1. Initialize test configuration
python src/Server.py --create-client-config --server-host 127.0.0.1 --server-port 9443 --client-out client_config.json

# 2. Launch server in background
python src/Server.py &

# 3. Run integration test
python tests/test_pipeline.py

Tests client enrollment, secret rejection, mTLS TLS 1.3 socket handshake, direct warning promotion, immediate error promotion, and Hermes report output.

Releases & Binary Distribution

Releases can be built and published through three complementary channels:

1. Tag Push Automation (Gitea Actions)

Pushing a release tag automatically triggers the build workflows:

git tag v2.0.1
git push origin v2.0.1

The consolidated workflow release.yml defines two parallel jobs:

release-linux (ubuntu-latest): Compiles standalone native ELF binaries (Linux_Client.bin, Server.bin) and checksums.
release-windows (windows-latest): Compiles Windows executables (Win_Client.exe, Server.exe), builds Inno Setup installers, and publishes checksums (requires self-hosted Windows Act Runner).

2. Manual Workflow Dispatch (Gitea UI)

Workflows can be manually triggered on demand from the Gitea web interface:

Navigate to Actions \rightarrow Release Binaries & Installers (release.yml).
Click Run workflow, set the release tag (defaults to v2.0.1), and run.

3. Native Local Windows Build & Direct Release Upload

For environments without a registered Windows CI runner, Windows executables can be built and published directly to Gitea releases:

# 1. Build Windows binaries locally
python compilation/package_dist.py --target windows

# 2. Upload assets and release notes directly to the Gitea release
python compilation/upload_release.py --tag v2.0.1 --token <GITEA_TOKEN> --skip-build

LOGAR Release v0.3.5.1

Latest

2026-09-30 16:37:56 +00:00

Python 94.4%

Inno Setup 2.5%

NSIS 2%

Shell 0.9%

Dockerfile 0.2%

README.md

LOGAR: Fleet Log Aggregation & Centralized Provisioning System

Sichere Log-Zusammenführung, PKI-Flottenlizenzierung & Bereitstellung für autonome KI-Analyse

Table of Contents