Questa pagina è dedicata a chi ha il compito di mantenere in salute, giorno per giorno, un'installazione Eldric — installazione, utenti, tenant, monitoraggio, backup, aggiornamenti. Percorre in ordine la superficie operativa standard; per i riferimenti più approfonditi (ogni endpoint, ogni flag) segui i link al riferimento API e alle pagine specifiche per ogni funzionalità.
Un cluster Eldric ha un controller, uno o più router, uno o più worker di inferenza, uno o più data worker e un anello opzionale di worker specializzati (agent / media / comm / science / training / xLSTM / IoT). Il gateway edge è il punto di ingresso pubblico. Tutti i daemon girano come unità systemd su ciascun host.
Per un cluster di valutazione ridotto, un singolo host esegue tutto tramite il metapacchetto eldric-aios. In produzione, distribuisci sugli host — tipicamente le macchine equipaggiate con GPU eseguono inferenza + xLSTM, quelle con molto storage eseguono i data worker e un piccolo host di gestione esegue controller + edge. La guida all'installazione copre il percorso single-node; il percorso multi-nodo è qui sotto.
Un host, un meta-package. Il percorso consigliato a comando singolo:
curl -fsSL https://repo.eldric.ai/install-eldric.sh | sudo bash
Il bootstrap concatena il setup del repository, dnf install eldric-aios, systemctl enable --now eldric-aios e il probe di salute + riepilogo post-installazione di eldric setup. Passa -s -- --license-file PATH --admin-email EMAIL per attivare un file di licenza nello stesso colpo.
Preferisci i passaggi separati:
curl -fsSL https://repo.eldric.ai/install.sh | sudo bash sudo dnf install eldric-aios sudo systemctl enable --now eldric-aios sudo eldric setup
Nel giro di 30 secondi la chat shell è disponibile su http://<host>:8880/chat — in modalità single-node l'ascolto è sulla porta 8880 per impostazione predefinita. (Quando metti davanti un gateway edge dedicato, l'URL perde la porta e diventa https://<host>/chat.) La prima registrazione diventa l'amministratore. Vedi primo avvio per i passaggi successivi.
Eldric 5.0 è un meta-package per host (eldric-aios); gli host con GPU aggiungono l'RPM CUDA (eldric-aios-cuda). Lo stesso comando di installazione gira su ogni nodo — ciò che cambia è l'assegnazione di ruolo, impostata tramite il file di environment in /etc/eldric/eldric-aios.env.
# Su ogni host — stesso one-liner
curl -fsSL https://repo.eldric.ai/install-eldric.sh | sudo bash
# Gli host con GPU aggiungono il pacchetto CUDA
sudo dnf install eldric-aios-cuda
# Su ogni host non-controller, punta al controller e fissa il ruolo
echo "ELDRIC_AIOS_CONTROLLER_URL=https://mgmt-host:8880" | \
sudo tee -a /etc/eldric/eldric-aios.env
echo "ELDRIC_AIOS_ROLE=worker" | sudo tee -a /etc/eldric/eldric-aios.env # oppure controller / data / edge / agent / media / comm / science / training / iot
sudo systemctl restart eldric-aios
Ogni daemon si registra al controller al primo avvio. systemctl status eldric-aios su ciascun host conferma il ciclo di vita; la meta-unità unificata ospita tutti i moduli di quel nodo. La pagina della topologia del cluster nella chat shell (Console di amministrazione → Cluster) mostra in tempo reale i nodi registrati. Fissare il ruolo conta — lasciare un nodo bare sul valore predefinito role=all può innescare crash-loop del watchdog di salute su hardware che non regge l'intero stack.
Console di amministrazione → Utenti per aggiungere, sospendere o rimuovere utenti. I ruoli sono Viewer / Developer / Admin / SuperAdmin (quest'ultimo solo per operazioni fra tenant). Console di amministrazione → Tenant per aggiungere nuovi tenant — uno per reparto / studio / progetto / cliente. L'ambito per tenant è imposto al gateway; l'accesso fra tenant viene negato in modo incondizionato.
Esempio guidato — onboarding di un nuovo reparto: (1) crea il tenant (Tenant → Nuovo) con uno slug breve; (2) assegna una quota di storage per quel tenant; (3) aggiungi il responsabile del reparto come Admin di quel tenant; (4) l'Admin invita i suoi utenti dalla Console di amministrazione del proprio tenant. Il SuperAdmin a livello di piattaforma si fa da parte a questo punto — l'amministrazione quotidiana vive all'interno del tenant.
Console di amministrazione → KB per allestire basi di conoscenza per ciascun tenant. Ogni KB ha il proprio modello di embedding + archivio vettoriale + (facoltativo) livello di memoria a matrice. L'anteprima della memoria compressa vive qui — vedi retrieval avanzato (EN) per il percorso opt-in.
Esempio guidato — aggiungere documenti: (1) KB → Nuova KB → scegli il modello di embedding e il livello opzionale di memoria a matrice; (2) KB → Carica → trascina PDF / DOCX / Markdown / HTML / testo semplice (oppure preleva da un mount del Data Worker); (3) la pipeline di embedding gira in background — segui in KB → Stato; (4) dialoga con la KB selezionandola dal selettore di fonti della chat shell, oppure interrogala direttamente via API. Il ri-embedding dopo un cambio modello ricostruisce l'intera KB in loco; nessun rollover manuale necessario.
Console di amministrazione → Modelli per gestire quali modelli sono visibili per ciascun tenant — mostrali tutti, limitali a un elenco curato, nascondi del tutto le API esterne. I badge di backend (Ollama, OpenAI, Inferenced, vLLM, llama.cpp e così via — vedi provider di modelli (EN)) sono derivati automaticamente dalla fonte di ciascun modello. Fissare un modello come predefinito per il tenant lo rende il punto di ingresso per le nuove conversazioni.
Console di amministrazione → Licenza per inserire il file di licenza firmato. Il controller verifica la firma Ed25519 sul file e alza i limiti di conseguenza. Gli aggiornamenti di licenza a caldo sono supportati — nessun riavvio. E-mail licenze: license@core.at.
journalctl -u eldric-aios traccia la meta-unità unificata (il daemon 5.0 ospita tutti i moduli abilitati dal ruolo di quel nodo). Il registro di audit in /var/lib/eldric/audit/ incatena con hash ogni azione amministrativa e ogni decisione assistita dall'IA — documentazione difendibile per le revisioni di conformità. Il registro è append-only e a prova di manomissione; un amministratore che lo legge non può modificare le voci precedenti, neppure accedendo direttamente al file. Console di amministrazione → Audit esporta una porzione del registro come JSON firmato per la consegna in ambito compliance.
/health sulla porta primaria. Una semplice probe di liveness dal tuo stack di monitoraggio interroga questi endpoint./metrics in formato Prometheus. Contatori standard (rate di richieste, rate di errori, percentili di latenza) più suddivisioni per tenant e per modello.Allarmi consigliati da collegare al tuo stack esistente:
/v1/chat/completions superiore al tuo obiettivo di servizio — tipicamente 2× la mediana su una finestra mobile. Scatta quando un worker di inferenza, un modello backend o un provider cloud è degradato.La pagina Console di amministrazione → Telemetria suggerisce valori sensati per ciascuno. Adattali al profilo del tuo traffico; gli allarmi che non scattano mai sono solo rumore per chi è di turno.
Due percorsi di backup coprono lo stato del cluster:
Per copie offsite / disaster recovery, monta lo storage offsite sul data worker e punta il sistema di snapshot su quello — il percorso 5.0. Una prossima patch 5.0.x aggiunge l'automazione per la destinazione offsite.
Il controller esegue un orchestratore di rolling update che percorre ogni nodo a turno: drain → installazione → riavvio → verifica, poi passa al successivo. Dalla Console di amministrazione → Aggiornamenti, scegli la versione di destinazione e avvia; l'orchestratore gestisce la sequenza e riporta lo stato per nodo.
Per installazioni single-node il classico sudo dnf update eldric-aios funziona direttamente. Per cluster air-gap, replica repo.eldric.ai/5.0/ in locale e fai puntare dnf al mirror.
L'automazione del rollback arriva con una prossima patch 5.0.x (§70). In 5.0 il rollback è manuale: blocca la versione precedente e ri-esegui l'orchestratore.
La piattaforma include un harness di stress test — utenti paralleli × numero di richieste contro un host del cluster con soglie di pass/fail su latenza p99 e budget di errore. Eseguilo prima della finestra di soak quando metti in esercizio un cluster, e rieseguilo dopo un cambiamento significativo di capacità. I risultati si confrontano con la baseline del cluster demo pubblicato.
journalctl -u eldric-aios --since today --no-pager — primo posto dove guardare per qualunque problema di daemon.Per la vista lato sviluppatore: per gli sviluppatori (EN) + riferimento API (EN). Per la vista più profonda della piattaforma: come funziona (EN). Domande: office@eldric.ai.