Guida alla Migrazione di Baselayout e OpenRC
1.
Contesto
Cos'è baselayout?
Baselayout fornisce un insieme base di file che sono necessari per far
funzionare adeguatamente tutti i sistemi, come ad esempio
/etc/hosts. Fornisce anche il layout base del filesystem usato da
Gentoo (ad es. le directory /etc, /var,
/usr, /home).
Cos'è OpenRC?
OpenRC è un sistema rc basato sulle dipendenze che funziona con qualsiasi init
fornito dal sistema, normalmente /sbin/init . Comunque, non
è un sostituto per /sbin/init. L'init di default usato da Gentoo
Linux è sys-apps/sysvinit, mentre Gentoo/FreeBSD utilizza l'init di
FreeBSD fornito da sys-freebsd/freebsd-sbin.
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, è stato determinato che era più appropriato se baselayout avesse fornito
meramente i file base e il layout del filesystem per Gentoo e il sistema rc fu
spostato in un suo pacchetto. Sicché abbiamo OpenRC.
OpenRC è sviluppato inizialmente da Roy Marples ed ora mantenuto 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.
2.
Migrazione a OpenRC
La migrazione a OpenRC è piuttosto diretta; sarà introdotta come parte del
proprio processo di aggiornamento dal tuo gestore dei pacchetti. Il passo più
importante attualmente avviene dopo l'installazione dei nuovi pacchetti
>=sys-apps/baselayout-2 e sys-apps/openrc. È
importantissimo eseguire dispatch-conf ed assicurarsi che il
proprio /etc sia aggiornato prima di riavviare. Un
fallimento nel farlo produrrà un sistema non più avviabile e richiederà
l'uso del Gentoo 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.
/etc/conf.d/rc
Il file /etc/conf.d/rc è stato deprecato e tutte le impostazioni in
esso contenute avranno bisogno di essere trasferite alle impostazioni
appropriate in /etc/rc.conf. Si prega di leggere interamente
/etc/rc.conf e /etc/conf.d/rc e migrare le
impostazioni. Una volta finito, cancellare /etc/conf.d/rc.
Moduli del Kernel
Normalmente, quando si vuole che certi moduli del kernel siano caricati
all'avvio, li si mette in /etc/modules.autoload.d/kernel-2.6insieme
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, /etc/conf.d/modules, qualsiasi sia la
versione del kernel.
Un esempio di configurazione vecchio stile sarebbe:
Codice 2.1: /etc/modules.autoload.d/kernel-2.6 |
ivtv
cx88_dvb video_br=2
|
Convertire l'esempio precedente risulterà nel seguente:
Codice 2.2: /etc/conf.d/modules |
modules_2_6="ivtv cx88_dvb"
module_cx88_dvb_args_2_6="video_br=2"
|
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.
Importante:
Le variabili module* non sono cumulative. Le variabili con versioni più
specifiche sovrascriveranno le variabili con versione più generica.
|
Nota:
Notare la differenza tra module_ and modules_.
|
Un esempio approfondito sarà:
Codice 2.3: esempio dettagliato di /etc/conf.d/modules |
modules_2_6_23_gentoo_r5="ivtv"
modules_2_6_23="cx88_dvb"
modules_2_6="tun usbserial"
modules="ohci1394 ieee1394"
module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2"
module_usbserial_args_2_6="vendor=0x1410 product=0x2110"
module_ieee1394_args="debug"
|
Runlevel di Boot
Il runlevel di boot 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 /proc 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, evms, e il like. Bisogna assicurarsi che
l'initscript appropriato per questi servizi nel runlevel di boot,
altrimenti sarà possibile che il proprio sistema non si avvii!
Sebbene l'ebuild di OpenRC proverà a fare questa migrazione, si dovrà verificare
che migri tutti i servizi di gestione di volume propriamente:
Codice 2.4: Mostrare tutti i servizi nel runlevel boot |
# ls -l /etc/runlevels/boot/
|
Se non si vede root, procfs, mtab, swap e fsck con il precedente comando,
effettuare le seguenti istruzioni per aggiungerli al runlevel boot:
Codice 2.5: Aggiungere servizi critici al runlevel boot |
# rc-update add root boot
# rc-update add procfs boot
# rc-update add mtab boot
# rc-update add fsck boot
# rc-update add swap boot
|
Se si è a conoscenza di utilizzare mdraid e lvm ma non li si vede sopra, si
dovranno eseguire le seguenti istruzioni per aggiungere gli initscript al
runlevel boot:
Codice 2.6: Aggiungere mdraid e lvm al runlevel boot |
# rc-update add mdraid boot
# rc-update add lvm boot
|
Udev
OpenRC non avvia più udev in modo predefinito, ma deve essere presente
nel runlevel sysinit per essere avviato. L'ebuild di OpenRC dovrebbe
rilevare se udev era stato precedentemente abilitato e aggiungerlo al
runlevel sysinit. Comunque, per esserne sicuri, controllare se
udev è presente:
Codice 2.7: Verificare udev |
# ls -l /etc/runlevels/sysinit
lrwxrwxrwx 1 root root 14 2009-01-29 08:00 /etc/runlevels/sysinit/udev -> /etc/init.d/udev
|
Se udev non è elencato, aggiungerlo al corretto runlevel:
Codice 2.8: Aggiungere udev al runlevel sysinit |
# rc-update add udev sysinit
|
Rete
Siccome baselayout e OpenRC sono stati divisi in due pacchetti differenti, il
proprio initscript net.eth0 può scomparire durante il processo di aggiornamento.
Per sostituire questo initscript e aggiungerlo nuovamente al runlevel di
default, eseguire i seguenti comandi:
Codice 2.9: Riaggiungere lo script net.eth0 mancante |
# cd /etc/init.d
# ln -s net.lo net.eth0
# rc-update add net.eth0 default
|
Se manca qualsiasi altro initscript di rete, seguire le istruzioni menzionate
sopra per aggiungerlo nuovamente. Basta sostituire eth0 con il nome del
proprio dispositivo di rete.
Inoltre, /etc/conf.d/net (oldnet) non utilizza più gli array stile
bash per la configurazione. Si prega di consultare
/usr/share/doc/openrc-<version>/net.example 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:
Codice 2.10: Vecchio stile di /etc/conf.d/net |
config_eth0=( "192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255" )
routes_eth0=( "default via 192.168.1.100" "10.0.0.0/8 via 192.168.1.2")
|
Codice 2.11: Nuovo stile di /etc/conf.d/net |
config_eth0="192.168.1.37 netmask 255.255.255.0 brd 192.168.1.255"
routes_eth0="default via 192.168.1.100
10.0.0.0/8 via 192.168.1.2"
|
Orologio
Le impostazioni dell'orologio sono state rinominate da
/etc/conf.d/clock al proprio strumento di impostazione di orologio
nativo di sistema. Questo significa che in Linux sarà
/etc/conf.d/hwclock e in FreeBSD sarà
/etc/conf.d/adjkerntz. I sistemi senza un chip con orologio interno
("real time clock", o "RTC", ndt) funzionante dovrebbero usare
/etc/init.d/swclock, 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 /etc/init.d/ è anch'esso stato rinominato
conseguentemente, quindi assicurarsi che sia nel runlevel boot.
Inoltre, la variabile TIMEZONE non è più in questo file. I suoi contenuti
sono invece nel file /etc/timezone. Se non esiste, bisognerà
ovviamente 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 /usr/share/zoneinfo. Per esempio, per quelli
che vivono nella costa orientale degli Stati Uniti, l'esempio seguente sarà una
corretta impostazione:
Codice 2.12: /etc/timezone |
America/New_York
|
XSESSION
La variabile XSESSION non si trova più in /etc/rc.conf. Invece, si
può impostare la variabile XSESSION per quanto riguarda il singolo utente in
~/.bashrc (o equivalente), oppure impostarlo globalmente per il
sistema in /etc/env.d/
Ecco un esempio di come impostare XSESSION per l'intero sistema:
Codice 2.13: Impostare XSESSION per tutto il sistema |
# echo 'XSESSION="Xfce4"' > /etc/env.d/90xsession
|
Importante:
Bisogna eseguire env-update dopo aver creato un file in
/etc/env.d, e successivamente effettuare il logout e poi il login
perché abbia effetto. Se si imposta la variabile in ~/.bashrc, si
può rifare il source del file con source ~/.bashrc.
|
EDITOR e PAGER
La variabile EDITOR non si trova più in /etc/rc.conf. Sia EDITOR
che PAGER sono impostati in modo predefinito in /etc/profile. Si
dovrebbe cambiare ciò se se ne ha bisogno nel proprio file
~/.bashrc (o equivalente) o creare /etc/env.d/99editor
ed assegnare l'impostazione predefinita di sistema lì.
Importante:
Bisogna eseguire env-update dopo aver creato un file in
/etc/env.d, e successivamente effettuare il logout e poi il login
perché abbia effetto. Se si è impostato la variabile in ~/.bashrc,
si può rifare il source del file con source ~/.bashrc.
|
Log di Boot
Precedentemente, si poteva loggare il processo di boot utilizzando
app-admin/showconsole. 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 /etc/rc.conf. I log
appariranno in /var/log/rc.log.
Codice 2.14: Abilitare il logging del boot in /etc/rc.conf |
rc_logger="YES"
|
local.start e local.stop
Con OpenRC, /etc/conf.d/local.start e
/etc/conf.d/local.stop non sono più validi. Durante la migrazione a
OpenRC, i file vengono spostati in /etc/local.d e guadagnano il
suffisso .start oppure .stop. 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 keyword nelle funzioni depend.
Tuttavia, con il rilascio 0.7.0., è necessario configurare esplicitamente il
sotto-tipo usando la variabile rc_sys in /etc/rc.conf. Il
sotto-tip dovrebbe essere impostato per combaciare con l'ambiente di
virtualizzazione nella quale risiede root. Generalmente, un rc_sys non
vuota dovrebbe esserci dentro ai contenitori virtuali; il nodo host dovrebbe
avere rc_sys="".
Importante:
Se non si vuole specificare nessun sotto-tipo, si preca di usare il valore
predefinito, ovvero una stringa vuota "". Se la variabile non è
specificata, verrà restituito un avviso e il sistema cercherà di usare il
vecchio algoritmo di rilevamento.
|
Nota:
Se non si sa che valore sta usando il proprio sistema con il rilevamento
automatico, è possibile commentare temporaneamente la variabile rc_sys ed
eseguire il comando di rilevamento, rc -S.
|
Codice 2.15: Impostare il sotto-tipo di sistema ad un valore nullo in /etc/rc.conf |
rc_sys=""
|
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.
| Sottotipo |
Descrizionw |
Note |
|
Predefinito, nessun sotto-tipo |
Non lo stesso se non impostato; FreeBSD, Linux & NetBSD |
| jail |
FreeBSD jail |
|
| lxc |
Contenitori Linux |
Non rilevato automaticamente |
| openvz |
Linux OpenVZ |
|
| prefix |
Prefix |
Non rilevato automaticamente; FreeBSD, Linux & NetBSD |
| vserver |
Linux vserver |
|
| xen0 |
Xen0 Domain |
Linux & NetBSD |
| xenU |
XenU Domain |
Linux & NetBSD |
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 è /etc/conf.d/net.example, ora sostituito
da /usr/share/doc/openrc-*/net.example.bz2.
Finalizzare
Una volta terminato e aggiornato i propri file di configurazione e gli
initscript, l'ultima cosa da fare è reboot. Questo è necessario perché
le informazioni di stato del sistema non sono preservate durante
l'aggiornamento, quindi bisognerà fornirle con un boot pulito.
3.
Funzionalità modificate
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. In OpenRC, l'azione pause è stata
rimossa; questa funzionalità è supportata dal comando /etc/init.d/service
--nodeps stop, che funziona anche nel vecchio baselayout.
voce rootfs in /etc/mtab
In precedenza, la voce iniziale rootfs era stata rimossa da
/etc/mtab, 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.
I contenuti di questo documento sono rilasciati sotto la licenza Creative
Commons - Attribution / Share Alike.
|