Gentoo Logo

Gentoo Linux Installer

Indice:

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.



Stampa

Aggiornato il 29 gennaio 2004

Oggetto: Una introduzione al progetto Gentoo Linux Installer in cui si discute il suo scopo, la struttura del progetto e si espongono i partecipanti.

Eric Sammer
Autore

Blackace
Redazione

Michele Caini
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.