OpenRC/Baselayout 1 to 2 migration/it

Questa guida fornisce istruzioni riguardo la migrazione da baselayout-1 a baselayout-2 per OpenRC.

Cos'è baselayout?
Baselayout fornisce un insieme base di file che sono necessari per far funzionare adeguatamente tutti i sistemi, come ad esempio. Fornisce anche il layout base del filesystem usato da Gentoo (ad es. le directory, , , ).

Cos'è OpenRC?
OpenRC è un sistema rc (run command) basato sulle dipendenze che funziona con qualsiasi init fornito dal sistema, normalmente. Comunque, OpenRC non è un sostituto per. L'init di default usato da Gentoo Linux è, mentre Gentoo/FreeBSD utilizza l'init di FreeBSD fornito da.

Perchè migrare?
Inizialmente il sistema rc di Gentoo è stato compilato dentro baselayout-1 e scritto interamente in bash. Questo porta a molte limitazioni. Per esempio, certe chiamate di sistema hanno bisogno di essere accedute durante il boot e ciò ha richiesto l'aggiunta di chiamate basate su C. Ognuna di queste chiamate era linkata staticamente, con la conseguenza che il sistema rc ci metteva più tempo ad eseguire le proprie operazioni.

Inoltre, siccome Gentoo si è espansa ad altre piattaforme come Gentoo/FreeBSD e Gentoo Embedded, è diventato impossibile richiedere a un sistema rc basato su bash. Questo ha portato allo sviluppo di baselayout 2, che è scritto in C e richiede unicamente una shell POSIX-compilant. Durante lo sviluppo di baselayout 2, si è determinato come più appropriato se baselayout avesse fornito semplicemente i file base ed il layout del filesystem per Gentoo, ed il sistema rc fu spostato in un suo pacchetto. Da questo nacque OpenRC.

OpenRC fu inizialmente sviluppato da Roy Marples fino al 2010 ed è mantenuto ora dal Gentoo OpenRC Project. OpenRC supporta tutte le correnti variazioni di Gentoo (es. Gentoo Linux, Gentoo/FreeBSD, Gentoo Embedded, e Gentoo Vserver) e altre piattaforme come FreeBSD e NetBSD.

Migrazione ad OpenRC
La migrazione a OpenRC è piuttosto lineare; sarà introdotta come parte del normale processo di aggiornamento dal gestore dei pacchetti. Il passo più importante attualmente avviene dopo l'installazione dei nuovi pacchetti  e. È importantissimo eseguire dispatch-conf ed assicurarsi che i file in siano aggiornati lanciando dispatch-conf (o un altro tool similare) prima di riavviare. ""Un fallimento nel farlo produrrà un sistema non più avviabile"" e richiederà l'uso di un LiveCD per effettuare i passaggi seguenti per riparare il proprio sistema.

Una volta finito di aggiornare i propri file di configurazione, ci sono alcune cose da verificare prima di riavviare.

Il file è stato deprecato. Tutte le impostazioni in esso contenute avranno bisogno di essere trasferite alle impostazioni appropriate in. Si prega di leggere interamente e  e migrare le impostazioni. Una volta finito, cancellare.

Moduli del kernel
Normalmente, quando si vuole che certi moduli del kernel siano caricati all'avvio, li si mette in insieme ad ogni parametro che gli si vuole passare. Nel baselayout-2, questo file non è più utilizzato. Invece, i moduli caricati automaticamente e i loro parametri sono situati in un file,, qualsiasi sia la versione del kernel.

Un esempio di configurazione vecchio stile sarebbe:

Convertire l'esempio precedente risulterà nel seguente:

Negli esempi precedenti, i moduli e i loro parametri saranno passati soltanto ai kernel della serie 2.6.x. La nuova configurazione permette un controllo più preciso sui moduli e sui parametri basato sulla versione del kernel.

Un esempio approfondito sarà:

Runlevel di Boot
Il runlevel di  esegue molti passi importanti per ogni macchina. Per esempio, assicurarsi che il proprio filesystem root sia montato in lettura/scrittura, che i propri filesystem siano controllati, che i propri mountpoint siano disponibili, e che lo pseudo-filesystem sia avviato al boot.

Con OpenRC, i servizi di gestione del volume per i propri dispositivi a blocchi non sono più avviati automaticamente al boot. Questo include LVM, RAID, swap, device-mapper (dm), dm-crypt e simili. Bisogna assicurarsi che lo script di init appropriato per questi servizi sia aggiunto al runlevel boot, altrimenti è possibile che il sistema non si possa più avviare.

Sebbene l'ebuild di OpenRC proverà a fare questa migrazione, l'amministratore di sistema dovrà verificare che tutti i servizi di gestione di volume siano propriamente migrati:

Se, , , e  sono mancanti nell'output precedente, lanciate il seguente comando per aggiungerli al runlevel  :

Se il sistema utilizza mdraid e/o LVM ed essi non sono menzionati nella lista precedente, i rispettivi script di init devono essere anch'essi aggiunti al runlevel :

Udev
OpenRC non avvia più udev in modo predefinito; questo deve essere presente nel runlevel  per essere avviato. L'ebuild di OpenRC dovrebbe rilevare se era stato precedentemente abilitato e aggiungerlo al runlevel. Comunque, per esserne sicuri, controllare se è presente:

Se non è presente, aggiungerlo al runlevel corretto:

Rete
Siccome baselayout e OpenRC sono stati divisi in due pacchetti differenti, il proprio initscript può scomparire durante il processo di aggiornamento. Per sostituire questo initscript e aggiungerlo nuovamente al runlevel di default, eseguire i seguenti comandi:

Se manca qualsiasi altro initscript di rete, seguire le istruzioni menzionate sopra per aggiungerlo nuovamente. Basta sostituire  con il nome del proprio dispositivo di rete.

Inoltre, (oldnet) non utilizza più gli array stile bash per la configurazione. Si prega di consultare bash per le istruzioni di configurazione. La conversione dovrebbe essere relativamente diretta, impostando separatamente le voci ognuna su una nuova linea, per esempio un assegnamento statico di IP cambierà in questo modo:

Orologio
Le impostazioni dell'orologio sono state rinominate da al proprio strumento di impostazione di orologio nativo di sistema. Questo significa che in Linux sarà e in FreeBSD sarà. I sistemi senza un chip con orologio interno ("real time clock", o "RTC", ndt) funzionante dovrebbero usare, che imposta l'orario di sistema basandosi sull'orario di modifica di un file che viene creato durante lo spegnimento del sistema. L'initscript in è anch'esso stato rinominato conseguentemente, quindi assicurarsi che sia nel runlevel boot.

Inoltre, la variabile  non è più in questo file. I suoi contenuti sono invece nel file. Se non esiste, bisognerà crearlo con il proprio fuso orario. Si prega di controllare entrambi questi file per assicurarsi della loro correttezza.

Il valore appropriato per questo file è il percorso relativo al proprio fuso orario a partire da. Per esempio, per quelli che vivono nella costa orientale degli Stati Uniti, l'esempio seguente sarà una corretta impostazione:

XSESSION
La variabile  non si trova più in. Invece, è possibile impostare una variabile  per singolo utente nel file  (o equivalente), o system-wide in.

Ecco un esempio di come impostare  per l'intero sistema:

EDITOR e PAGER
La variabile  non si trova più in /etc/rc.conf. Sia  che   sono impostati in modo predefinito in /etc/profile. Si dovrebbe cambiare ciò se se ne ha bisogno nel proprio file (o equivalente) o creare  ed assegnare l'impostazione predefinita di sistema lì.

Log di Boot
Precedentemente, si poteva loggare il processo di boot utilizzando. Tuttavia, OpenRC ora gestisce tutto il processo di logging internamente, quindi non c'è bisogno dei trucchetti che showconsole ha adottato. Si può fare l'unmerge di showconsole senza problemi. Per continuare a loggare i messaggi di boot, impostare semplicemente la variabile appropriata in. I log appariranno in.

e
Con OpenRC, e  sono deprecati. Durante la migrazione a OpenRC, i file vengono spostati in e guadagnano il suffisso  oppure. OpenRC li eseguirà in ordine alfabetico.

Sotto-tipi di sistemi: casi speciali di virtualizzazione
Nelle prime versioni di OpenRC, venivano esplicitamente rilevate diverse tipologie di virtualizzazione, e si usava quel rilevamento per segnalare quando determinati script di inizializzazione dovevano essere saltati, usando la chiamata  nelle funzioni.

Tuttavia, con il rilascio 0.7.0., è necessario configurare esplicitamente il sotto-tipo usando la variabile rc_sys in. Il sotto-tip dovrebbe essere impostato per combaciare con l'ambiente di virtualizzazione nella quale risiede root. Generalmente, un  non vuota dovrebbe esserci dentro ai contenitori virtuali; il nodo host dovrebbe avere.

L'algoritmo di rilevamento ha dovuto essere sostituito con la configurazione manuale a causa dell'introduzione di nuovi sotto-tipi e cambiamenti al kernel che rendevano il rilevamento precedente inaffidabile.

Pulizia dei file di configurazione inutilizzati
Dopo la migrazione, alcuni file non rimossi da Portage resteranno sul filesystem. Si tratta di file di configurazione protetti dal sistema di protezione dei file di configurazione di Portage.

L'esempio più rilevante è, ora sostituito da.

Finalizzare
Una volta terminato e aggiornato i propri file di configurazione e gli initscript, l'ultima cosa da fare è reboot</tt>. Questo è necessario perché le informazioni di stato del sistema non sono preservate durante l'aggiornamento, quindi bisognerà fornirle con un boot pulito.

L'azione pausa
In precedenza era possibile interrompere temporaneamente un servizio senza terminare tutti i servizi dipendenti da esso usando il comando /etc/init.d/servizio pause</tt>. In OpenRC, l'azione pause è stata rimossa; questa funzionalità è supportata dal comando /etc/init.d/service --nodeps stop</tt>, che funziona anche nel vecchio baselayout.

Entry rootfs in
In precedenza, la voce iniziale  era stata rimossa da, ed era presente solamente la voce  della root reale. L'oggetto duplicato rootfs è stato effettivamente riaggiunto durante lo spegnimento. In OpenRC, entrambe le voci devono essere presenti per il pieno supporto a initramfs e root su tmpfs. Ciò significa anche meno scritture necessarie durante lo spegnimento.