Guida alla Migrazione di Baselayout e OpenRC

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

Background

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 (run command) basato sulle dipendenze che funziona con qualsiasi init fornito dal sistema, normalmente /sbin/init. Comunque, OpenRC 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, 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 >=sys-apps/baselayout-2 e sys-apps/openrc. È importantissimo eseguire dispatch-conf ed assicurarsi che i file in /etc 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.

/etc/conf.d/rc

Il file /etc/conf.d/rc è stato deprecato. 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.6 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, /etc/conf.d/modules, qualsiasi sia la versione del kernel.

Un esempio di configurazione vecchio stile sarebbe:

FILE /etc/modules.autoload.d/kernel-2.6

ivtv
cx88_dvb video_br=2

Convertire l'esempio precedente risulterà nel seguente:

FILE /etc/conf.d/modules

# Moduli caricati automaticamente all'avvio
modules_2_6="ivtv cx88_dvb"
# Parametri dei Moduli
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.

Important
Le variabili module* non sono cumulative. Le variabili più specifiche sovrascriveranno le variabili con versione più generica.

Note
Attenzione alla differenza tra module_ e modules_.

Un esempio approfondito sarà:

FILE /etc/conf.d/modules

# Caricare ivtv solo per il kernel 2.6.23-gentoo-r5
modules_2_6_23_gentoo_r5="ivtv"
# Caricare solamente cx88_dvb per i kernel 2.6.23 (all'infuori di -gentoo-r5)
modules_2_6_23="cx88_dvb"
# Caricare solamente tun e usbserial per i kernel della serie 2.6.x dove x != 23
modules_2_6="tun usbserial"
# Altrimenti caricare ochi1394 e ieee1394
modules="ohci1394 ieee1394"
# Solo per il kernel 2.6.23-gentoo-r5, passare come argomento video_br=2 # a cx88_dvb
module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2"
# Per i kernel della serie 2.6.x passare sempre vendor e product
module_usbserial_args_2_6="vendor=0x1410 product=0x2110"
# Passare sempre debug a ieee1394
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 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:

root #ls -l /etc/runlevels/boot/

Se root, procfs, mtab, swap e fsck sono mancanti nell'output precedente, lanciate il seguente comando per aggiungerli al runlevel boot:

root #rc-update add root boot

root #rc-update add procfs boot

root #rc-update add mtab boot

root #rc-update add fsck boot

root #rc-update add swap boot

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 boot:

root #rc-update add mdraid boot

root #rc-update add lvm boot

Udev

OpenRC non avvia più udev in modo predefinito; questo 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:

root #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 è presente, aggiungerlo al runlevel corretto:

root #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:

root #cd /etc/init.d

root #ln -s net.lo net.eth0

root #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 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:

FILE /etc/conf.d/netVecchio Stile

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" )

FILE /etc/conf.d/netNuovo stile

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à 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:

FILE /etc/timezone

America/New_York

XSESSION

La variabile XSESSION non si trova più in /etc/rc.conf. Invece, è possibile impostare una variabile XSESSION per singolo utente nel file ~/.bashrc (o equivalente), o system-wide in /etc/env.d/.

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

root #echo 'XSESSION="Xfce4"' > /etc/env.d/90xsession

Important
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ì.

Important
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.

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 (rc_logger) in /etc/rc.conf. I log appariranno in /var/log/rc.log.

FILE /etc/rc.confAbilitazione logging

rc_logger="YES"

local.start e local.stop

Con OpenRC, /etc/conf.d/local.start e local.stop sono deprecati. 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="".

Important
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.

Note
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.

FILE /etc/rc.confImpostare il sotto-tipo di sistema ad un valore nullo

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	Descrizione	Note
	Default, nessun sottotipo	Non lo stesso come se non impostato; FreeBSD, Linux and NetBSD
jail	FreeBSD jails
lxc	Linux Containers	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.

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.

Entry 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.

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: cardoe, nightmorph, robbat2, uberlord
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.