Gentoo Linux Installer
1.
Introduzione
Al momento, Gentoo non dispone di un installer guidato (dove, per installer, si
intende un sistema che accompagna l'utente passo dopo passo nell'installazione).
Un buon numero di utenti ha espresso interesse verso un qualche tipo di
applicazione che alleggerisca l'attuale processo di installazione. Molti utenti
nuovi di Gentoo o Linux in generale, vengono intimoriti dal processo di
installazione e perfino con una forte certezza di avere supporto ed una
eccellente documentazione, sono riluttanti al provare. Alcuni utenti hanno
dichiarato che questa è la sola ragione per cui non sono mai passati o non hanno
mai ancora provato Gentoo. Il processo attuale sarà ancora disponibile per
coloro che sceglieranno di usarlo.
Il progetto Gentoo Linux Installer mira a realizzare una piattaforma di
installazione a norma per sistemi sia desktop che server. In genere, l'obiettivo
di un installer è la consistenza fra diverse architetture, usabilità per tutti
gli utenti, e flessibilità. La sezione sulle caratteristiche fornirà uno sguardo
d'insieme più approfondito sulle specifiche, ma è sufficiente dire che sarà per
tutti gli utenti, aventi ogni livello di esperienza, per tutti gli ambienti.
2.
Caratteristiche
Di seguito è fornita una lista di caratteristiche che saranno presenti
nell'installer. Anche se non è una lista esaustiva, dovrebbe dare un'idea
migliore di cosa sarà possibile. Non tutte queste caratteristiche sono ad uso e
consumo di tutti gli utenti, ma l'idea è quella di fornire qualcosa di
consistente per tutti gli utenti così da tenere la logica di "se non è per me,
per qualcun'altro" ben salda in testa.
Interfacce d'accesso multiple
L'installer avrà interfacce utente intercambiabili di cui alcune saranno perfino
grafiche e destinate ad X. Dato che alcune piattaforme sono più comunemente
installate con mezzi che non supportano X windows (impianti Sun serial console,
ecc.) verrà sviluppata anche un'interfaccia testuale. Gli utenti saranno liberi
di sviluppare interfacce utente (di ogni tipo) come loro ritengono adatte, ma
per scopi di manutenzione, solo una basata su testo e una grafica verranno
ufficialmente supportate inizialmente.
Framework di base riutilizzabile
L'attuale cavallo di battaglia dell'installer sarà un insieme di API che
verranno invocate da coloro che ne hanno bisogno. Per mantenere una separazione
netta e chiara fra funzionalità e interfaccia utente, per ogni strumento sarà
definita una piattaforma generica che mira al controllo dell'installazione di un
sistema Gentoo. Questo promuove anche una consistenza forte tra tutte le
piattaforme e gli ambienti.
Deployment automatizzato
L'installer supporterà il deployment automatico (il deployment consiste
nell'aggiunta / inserimento corretto di un elemento in un dato sistema,
letteralmente "schieramento", ma si userà di seguito il termine inglese) tramite
l'uso di profili di installazione pre-configurati. Ciò permetterà una facile
installazione in grandi ambienti con hardware simile o in situazioni dove si
vuole mettere da parte un backup dei parametri di una prima installazione su una
propria macchina per un eventuale recupero. Il profilo d'installazione conterrà
tutti i dati richiesti per "replicare" un'installazione (per esempio cflag, use
flag, schema di partizionamento, pacchetti installati conseguentemente, etc.).
Prove generali per la generazione del profilo
Gli utenti potranno creare profili di'installazione passando attraverso
l'installer senza seguire i passi esposti al momento. Tutti i dati generati
dalle azioni degli utenti saranno serializzati in un profilo di installazione
(rappresentato come documento XML) che potrà essere usato in seguito per il
deployment automatico.
Supporto completo per tutte le architetture di Gentoo
Come requisito, tutte le architetture supportate da Gentoo saranno supportate
anche dal progetto per l'installer di tale sistema. Sono incluse, ma non sono le
uniche, x86, ppc, sparc, alpha, amd64, mips, hppa, e itanium. (L'unica notevole
eccezione sono i sistemi embedded. Ciò è dovuto alla presenza di ambienti
altamente specializzati che l'installer potrebbe non essere in grado di
soddisfare.)
Profili specializzati
Profili specializzati come SELinux saranno supportati allo stesso modo delle
architetture tradizionali (basate su processore). Questi profili specializzati
supporteranno le caratteristiche aggiuntive e i requisiti dei loro rispettivi
processi di installazione.
Politiche aperte e uso di standard
Quando possibile, l'installer userà formati aperti e standard così da interagire
meglio con altri strumenti sviluppati dagli utenti. Sono inclusi formati dei
file (XML), protocolli di rete, e altre cose di questo tipo. Particolare
attenzione sarà riposta per non escludere l'uso di strumenti alternativi e
utilità varie.
Integrazione con progetti di configurazione futuri
Dove possibile, l'installer si integrerà con mezzi di configurazione specifici
del sistema Gentoo e utilità per facilitare l'organizzazione post-installazione
e la configurazione di macchine. Potrebbe essere incluso anche il supporto per
strumenti non specifici di Gentoo come cfengine.
3.
Progetto e Struttura
La struttura dell'installer deve essere abbastanza generica da supportare le
caratteristiche di cui sopra ma anche non astrarre troppo dal sistema così da
rendere difficili compiti semplici o necessitare di alta manutenzione.
Pochi requisiti di progetto sono stati indicati:
-
Devono essere supportate interfacce utente multiple (gestione e supporto
di viste astratte)
-
Deve essere mantenuta una separazione completa fra modello, vista e
controllore della logica
-
Tutte le caratteristiche devono essere supportate indipendentemente
dall'interfaccia esposta e/o dall'architettura
- Il deployment automatico deve essere sempre possibile
Per ottenere ciò, la piattaforma dell'installer (con la quale si fa riferimento
all'intero sistema) è suddivisa in tre parti principali.
Interfaccia d'accesso o front-end (Client)
Il client rappresenta l'interfaccia utente del sistema. Contiene la logica e il
supporto per tutte le interfacce utente. Inoltre, informazioni di stato meno
rilevanti riguardo configurazioni temporanee del client stesso, incluso
argomenti da riga di comando, impostazioni d'ambiente, metodo di invocazione
(interattivo / non-interattivo), posizione dei log, indirizzi (URI) dei server
contenenti i pacchetti binari, e altro ancora. Alcune di queste impostazioni
saranno "interne" all'installazione, ma molte altre no.
L'utente sarà in grado di usare la propria interfaccia preferita per generare i
profili di installazione da usare per il seguente deployment, e nel rispetto di
quanto detto questo lo si può pensare come un sistema di generazione del
profilo.
Il client può anche integrarsi con le configurazioni degli strumenti di sistema
in un secondo momento.
In genere, il client è "stupido" e non ha idea dell'implementazione logica
dell'attuale processo di installazione, anche se saranno presenti alcune logiche
per architetture specifiche.
Dietro le quinte o back-end (API o framework)
La parte più gustosa dell'installer è un insieme di API orientate agli oggetti
che permettono di astrarre dai comandi che ad oggi vengono eseguiti per
installare il sistema. Il framework è un po' più astratto nel senso che il suo
comportamento è dipendente dal modello architetturale utilizzato al momento. Il
numero di prudenti passi impiegati dipende molto dai requisiti e
dall'implementazione del modello architetturale (un file XML che ha una natura
simile alle informazioni contenute in /etc/make.profile di Portage).
Dato che il framework è nascosto dal client, può essere usato per
l'installazione personalizzata di prodotti sviluppati dall'utente. Le categorie
principali sono le seguenti:
-
Una classe controllore che stabilisce, basandosi sul modello
dell'architettura (un file XML), quali passi compiere e in quale ordine.
Questo è il cuore di tutta la logica.
-
Ua classe per il profilo di installazione che mantiene tutte le informazioni
del processo di installazione come schema di partizionamento, cflag, use
flag, e altri dati di questo tipo. Questa classe può serializzarsi in un
file XML (cioè trascriversi di fatto su un file) che può venire poi messo
su un server per il deployment automatico per usi futuri.
Altre classi minori possono essere usate per il supporto intermedio, ma queste
due stabiliscono cosa deve essere considerato pubblico nello sviluppo di client.
Server di deployment
Il terzo componente è probabilmente di solo interesse per coloro che usano la
caratteristica di deployment automatico dell'installer. Il server di deployment
è attualmente solo una combinazione di servizi e file.
I profili di installazione possono essere immagazzinati su una macchina e
forniti usando un server rsync. Il client (o, più precisamente, chi sta dietro
ad esso, ovvero il back-end) recupererà tutti i profili disponibili una volta
data la URI del server rsync. Questa è la parte principale del componente.
Il server di deployment può anche eseguire servizi come tftp e dhcp così da
facilitare l'avvio da rete per installazioni in larga scala. Normalmente ciò
richiede il supporto per l'avvio da rete nella macchina client, ma cd-live
personalizzati con tale supporto potrebbero essere resi disponibili da Gentoo.
In poche parole, il server di deployment non è un demone specifico o un
servizio, ma una combinazione di servizi standard e liberamente accessibili.
L'idea è di trovare un vantaggio nell'uso di servizi che potrebbero già essere
in esecuzione sulla rete dell'utente.
4.
Processo
Il processo attuale riguardante quali passi intraprendere e in quale ordine e
come operare è determinato principalmente dal modello architetturale. Per gran
parte, lo schema dell'architettura replicherà i passi discussi nel manuale di
installazione di Gentoo.
Gli schemi per architetture speciali come il già citato SELinux possono usare
questo stesso meccanismo per modificare il processo di base. Il modello
architetturale sovrascriverà il comportamento predefinito con uno generico. Così
facendo, ogni architettura non dovrà specificare cose come la sincronizzazione
con l'albero di portage, l'emerge del sistema di base, o altri passi che tutte
le architetture devono comunque intraprendere.
5.
Contatti
Gli sviluppatori che lavorano al progetto Gentoo Linux Installer si ritrovano
prevalentemente in due posti. Il canale IRC #gentoo-installer (su Freenode) è il
forum di discussione principale dove molte questioni sono esposte e discusse in
tempo reale. Questo è di solito il posto preferito per discussioni che vanno più
a fondo. Per discussioni più generiche esiste un'apposita mailing list dedicata
all'installer. È possibile iscriversi inviando una email all'indirizzo
gentoo-installer+subscribe@lists.gentoo.org.
6.
Autori e Partecipanti
Tutte le informazioni in questo documento sono state estratte da diverse
conversazioni in svariati posti.
In #gentoo-installer, blackace, dams, esammer, iggy, karltk, klieber, Method,
pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum, e tseng. Anche altri
sono passati per un attimo e hanno dato una mano, ma queste persone sono
attualmente inattive al momento della stesura del documento.
La mailing list desktop-research era il luogo in cui questo progetto ha visto la
luce per la prima volta come progetto ufficiale di Gentoo con il team attuale.
Grazie anche a tutte queste persone.
Il canale #gentoo-server è stato utile per fare saltare fuori molti problemi del
deployment automatico e diverse raccomandazioni. Grazie a tutti loro.
Questo documento è un riferimento cumulativo ed è il frutto del lavoro di ognuno
nella comunità di Gentoo.
I contenuti di questo documento sono rilasciati sotto la licenza Creative
Commons - Attribution / Share Alike.
|