Collegium:Imperium System: Difference between revisions

From OODA WIKI
Jump to navigation Jump to search
AdminIsidore (talk | contribs)
No edit summary
AdminIsidore (talk | contribs)
 
(2 intermediate revisions by the same user not shown)
Line 14: Line 14:
! Tools/Dependencies
! Tools/Dependencies
! Objectives
! Objectives
! Status
|-
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| '''NFS Setup on Roma, Horreum, and Torta'''
Line 19: Line 20:
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
| Completed
|-
|-
| '''NFS-Plus GPU Dispatching'''
| '''NFS-Plus GPU Dispatching'''
Line 24: Line 26:
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
| Pending
|-
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| '''Preparing Dockers and Directories on Latium and Torta'''
Line 29: Line 32:
| Docker, ''.bashrc'' modifications, directory scripts
| Docker, ''.bashrc'' modifications, directory scripts
| Functional containers and directories, tested by mock commands in each context
| Functional containers and directories, tested by mock commands in each context
| Pending
|-
|-
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
Line 34: Line 38:
| NFS, WireGuard, ''ufw''
| NFS, WireGuard, ''ufw''
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
| Pending
|-
|-
| '''Flamen Martialis and Salii Separation'''
| '''Flamen Martialis and Salii Separation'''
Line 39: Line 44:
| Python, NFS, SSH
| Python, NFS, SSH
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
| Pending
|-
|-
| '''Simple Data Diodes'''
| '''Simple Data Diodes'''
Line 44: Line 50:
| RSYNC, ''ufw'', WireGuard
| RSYNC, ''ufw'', WireGuard
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
| Pending
|-
|-
| '''RSYNC Optimization'''
| '''RSYNC Optimization'''
Line 49: Line 56:
| RSYNC, WireGuard, cron
| RSYNC, WireGuard, cron
| Transfer mock JSON files in <1s, tested by comparing transfer times
| Transfer mock JSON files in <1s, tested by comparing transfer times
| Pending
|-
|-
| '''Tar + Netcat (nc) Implementation'''
| '''Tar + Netcat (nc) Implementation'''
Line 54: Line 62:
| Tar, Netcat, WireGuard
| Tar, Netcat, WireGuard
| Functional burst transfer with a decision matrix, tested with mock data
| Functional burst transfer with a decision matrix, tested with mock data
| Pending
|-
|-
| '''Firejail/Bubblewrap Sandboxing'''
| '''Firejail/Bubblewrap Sandboxing'''
Line 59: Line 68:
| Firejail, Python
| Firejail, Python
| Sandboxed mock script with restricted access, tested via confinement checks
| Sandboxed mock script with restricted access, tested via confinement checks
| Pending
|-
|-
| '''Supabase Integration'''
| '''Supabase Integration'''
Line 64: Line 74:
| Supabase client libraries, REST API, WireGuard
| Supabase client libraries, REST API, WireGuard
| Validated data push/pull, tested with a mock schema
| Validated data push/pull, tested with a mock schema
| Pending
|-
|-
| '''JSONPlaceholder Data Pipeline Test'''
| '''JSONPlaceholder Data Pipeline Test'''
Line 69: Line 80:
| Python, RSYNC/nc, NFS, pywikibots
| Python, RSYNC/nc, NFS, pywikibots
| Complete data cycle, tested by verifying output on ''OodaWiki''
| Complete data cycle, tested by verifying output on ''OodaWiki''
| Pending
|-
|-
| '''NOTAM Data Pipeline Test'''
| '''NOTAM Data Pipeline Test'''
Line 74: Line 86:
| Python, Supabase (optional), RSYNC/nc, NFS
| Python, Supabase (optional), RSYNC/nc, NFS
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
| Pending
|-
|-
| '''RapidAPI via Supabase Test'''
| '''RapidAPI via Supabase Test'''
Line 79: Line 92:
| Supabase, Python, RSYNC/nc, pywikibots
| Supabase, Python, RSYNC/nc, pywikibots
| API-to-Wiki flow, tested by published data on ''OodaWiki''
| API-to-Wiki flow, tested by published data on ''OodaWiki''
| Pending
|-
|-
| '''Automation/Standardized Deployment Script'''
| '''Automation/Standardized Deployment Script'''
Line 84: Line 98:
| Bash/Python, Docker, NFS, Supabase
| Bash/Python, Docker, NFS, Supabase
| Script for project setup with one command, tested by deploying a mock project
| Script for project setup with one command, tested by deploying a mock project
| Pending
|}
|}


Line 97: Line 112:
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
* Mission 1 (NFS Setup) was completed with fixed port configurations for NFS services and verified through multi-node file creation, concurrent writes, and cleanup tests, establishing unified access in Pomerium.

Latest revision as of 16:08, 9 October 2025

Imperium System Mission Plan

Overview

The Imperium System Mission Plan outlines the phased construction and testing of the Imperium, a distributed data processing pipeline. Each mission is executed in a separate thread using OODA (Observe, Orient, Decide, Act) loops, with completion validated via independent tests. The plan adheres to the Lingua standard, using Latin nomenclature (e.g., aqua_datum, grana_datum, pomerium, flamen_martialis) to ensure script interoperability and support quarterly redundancy audits for AI training.

Mission Plan

The following table details the 14 missions, each with tools, dependencies, and objectives to build a unified, secure, and efficient system.

Mission Description Tools/Dependencies Objectives Status
NFS Setup on Roma, Horreum, and Torta Configure NFS mounts to unify Roma, Horreum, and Torta (smaller HDD, ~698 GB) as a single logical system within Pomerium, enabling seamless file sharing for scripts and grana_datum. Ensures no race conditions and supports the "single machine" goal. NFS (nfs-kernel-server, nfs-common); configure /etc/exports on Torta, mount on Roma/Horreum Read/write access across nodes with static IPs, tested via file creation/listing on pomerium_via paths Completed
NFS-Plus GPU Dispatching Extend NFS setup to enable Roma or Torta scripts to dispatch GPU-intensive tasks (e.g., AI processing) to Horreum’s NVIDIA RTX 5060 Ti, preserving energy efficiency. Builds on NFS for unified data access. NFS mounts, CUDA toolkit on Horreum, SSH-based job dispatching (e.g., ssh or SLURM) Run a sample GPU task (e.g., Python/CUDA script) from Roma using Horreum’s GPU Pending
Preparing Dockers and Directories on Latium and Torta Set up Docker containers (Pomerium, Campus Martius, Flamen Martialis) on Latium and minimal directory structure on Torta (e.g., /mnt/lacus, /mnt/aquaeductus) for pipeline operations. Simplifies Torta by keeping it Docker-free. Docker, .bashrc modifications, directory scripts Functional containers and directories, tested by mock commands in each context Pending
NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium Configure Torta’s external HDDs (larger ~1.8 TB for lacus, smaller ~698 GB for aquaeductus) with NFS, integrating Latium’s Pomerium Docker into the internal NFS network. Ensures secure data flow from external to internal zones. NFS, WireGuard, ufw Read-only NFS access from Latium to Torta’s smaller HDD, tested via mount and file read Pending
Flamen Martialis and Salii Separation Implement Flamen Martialis in Latium’s Campus Martius Docker for external data collection/sanitation, with Salii on Roma for internal processing, reducing Latium’s role and vulnerabilities. Ensures Salii is air-gapped, using Horreum’s GPU. Python, NFS, SSH Flamen Martialis collecting aqua_datum and Salii processing to grana_datum, tested with a mock dataset Pending
Simple Data Diodes Establish a one-way data flow from Latium to Torta (Campus Martius to Pomerium) to prevent reverse communication, mitigating security risks. Focuses on lightweight, secure transfer protocols. RSYNC, ufw, WireGuard One-way aqua_datum push to /mnt/lacus, tested by verifying no reverse access Pending
RSYNC Optimization Optimize RSYNC for fast, secure one-way data transfers over WireGuard, replacing SCP to avoid bottlenecks in pipelines like NOTAM. Tunes MTU and compression for performance. RSYNC, WireGuard, cron Transfer mock JSON files in <1s, tested by comparing transfer times Pending
Tar + Netcat (nc) Implementation Implement tar + nc for burst/large dataset transfers, comparing with RSYNC to determine the best tool per task (e.g., NOTAM vs. musica). Establishes a decision process for tool selection. Tar, Netcat, WireGuard Functional burst transfer with a decision matrix, tested with mock data Pending
Firejail/Bubblewrap Sandboxing Deploy Firejail (or Bubblewrap) on Latium to sandbox Flamen Martialis scripts, ensuring secure processing of external aqua_datum. Avoids heavy Firecracker setup. Firejail, Python Sandboxed mock script with restricted access, tested via confinement checks Pending
Supabase Integration Integrate Supabase as a filtering buffer for aqua_datum, using RLS and edge functions to validate data before transfer to Torta or Roma. Enhances security and supports prototypes. Supabase client libraries, REST API, WireGuard Validated data push/pull, tested with a mock schema Pending
JSONPlaceholder Data Pipeline Test Test the full pipeline using JSONPlaceholder’s mock API, simulating data flow from Latium to Torta to Roma/OodaWiki. Validates end-to-end setup. Python, RSYNC/nc, NFS, pywikibots Complete data cycle, tested by verifying output on OodaWiki Pending
NOTAM Data Pipeline Test Test the pipeline with NOTAM API data, focusing on scheduled pulls and performance. Ensures reliable handling of time-sensitive data. Python, Supabase (optional), RSYNC/nc, NFS NOTAM ingestion to Roma SQL or OodaWiki, tested by data accuracy Pending
RapidAPI via Supabase Test Test a basic RapidAPI endpoint via Supabase for filtering, integrating with the pipeline to store/publish results. Validates external API handling. Supabase, Python, RSYNC/nc, pywikibots API-to-Wiki flow, tested by published data on OodaWiki Pending
Automation/Standardized Deployment Script Develop a CLI script to automate directory and tool setup for new projects (e.g., musica, NOTAM) across Imperium, using test lessons. Ensures consistent, customizable deployments. Bash/Python, Docker, NFS, Supabase Script for project setup with one command, tested by deploying a mock project Pending

Execution Plan

Each mission will be executed in a dedicated thread using OODA loops:

  • Observe: Assess current system state (e.g., installed packages, configurations).
  • Orient: Plan configurations and identify dependencies.
  • Decide: Select specific tools and parameters.
  • Act: Implement and test the setup.

Upon thread completion, results are reported to the main strategic thread, where an independent test (e.g., file access, data transfer, script execution) confirms success. Successful missions are closed, and the next thread is initiated. The main thread tracks progress, ensuring coherence with the Imperium’s Lingua conventions and strategic goals.

Notes

  • Missions adhere to the Lingua standard, using Latin terms (e.g., pomerium_via for NFS paths, frumentarii_transfer for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
  • The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
  • Mission 1 (NFS Setup) was completed with fixed port configurations for NFS services and verified through multi-node file creation, concurrent writes, and cleanup tests, establishing unified access in Pomerium.