Manuale Gentoo Linux 2006.1 AMD64

Indice:

Installazione di Gentoo
In questa parte si tratta dell'installazione di Gentoo su un sistema.
1. A proposito dell'installazione di Gentoo
  Gli utenti meno familiari con Gentoo Linux non sanno ancora che la scelta è ciò che sta alla base di Gentoo.
2. Avviare l'installazione con il LiveCD di installazione
  Con il LiveCD di installazione si può avviare il sistema in un ambiente funzionante, che permette di installare Gentoo.
3. Procedura grafica di installazione
  E' ora possibile utilizzare un'interfaccia grafica per l'installazione di Gentoo. Tramite una semplice interfaccia è estremamente semplice impostare le proprie preferenze ed avviare il processo.
4. Procedura di installazione da console
  E' anche possibile condurre l'installazione da console e configurando le opzioni disponibili attraverso una serie di domande.
5. Cosa fare adesso?
  Il sistema Gentoo è pronto, e adesso?
Lavorare con Gentoo
Si comincia a lavorare con Gentoo: installare software, impostare parametri, cambiare il comportamento di portage ecc.
1. Una introduzione di Portage
  Questo capitolo spiega i semplici passi che un utente deve conoscere per mantenere il software sul proprio sistema.
2. Flag USE
  Le flag USE sono un aspetto molto importante di Gentoo. In questo capitolo, si spiega come lavorare con le flag USE e comprendere come queste interagiscono con il sistema.
3. Caratteristiche di Portage
  Si scoprono le caratteristiche di Portage, tra le quali il supporto per le compilazioni distribuite, ccache e altre.
4. Initscripts
  Gentoo usa un formato speciale di initscript che, tra le altre caratteristiche, permette risoluzioni guidate delle dipendenze e initscript virtuali. Questo capitolo spiega tutti questi aspetti e spiega come utilizzare questi script.
5. Variabili di ambiente
  Con Gentoo si possono controllare facilmente le variabili di ambiente per il sistema. Questo capitolo spiega come farlo e descrive anche le variabili utilizzate con maggior frequenza.
Lavorare con Portage
"Lavorare con Portage" offre una completa panoramica di Portage, il sistema di gestione dei pacchetti caratteristico di Gentoo.
1. File e directory
  Per conoscere bene le caratteristiche di Portage è necessario conoscere come e dove conserva i propri dati e i propri file.
2. Configurazione e variabili
  Portage è completamente personalizzabile tramite diversi tipi di variabili che possono essere impostate sia nel file di configurazione che nell'ambiente di esecuzione.
3. Combinare Software affidabile e non
  Gentoo offre il software separato in diverse categorie, a seconda del livello di stabilità per ciascuna architettura. Questo capitolo offre informazioni su come personalizzare questa ripartizione e combinare software proveniente da diverse categorie.
4. Ulteriori strumenti di Portage
  Portage comprende inoltre alcuni strumenti ulteriori in grado di agevolare notevolmente l'uso di Gentoo. Il capitolo illustra l'utilizzo di dispatch-conf e altri tool.
5. Separarsi dalla collezione di software originale
  Questo capitolo offre trucchi e suggerimenti su come utilizzare una collezione di software personalizzata, sincronizzando solo alcune categorie, inserendo pacchetti ed altro.
Configurazione di rete di Gentoo
Una guida esaustiva alla configurazione di rete in Gentoo.
1. Configurazione comune
  La guida più rapida per far funzionare la propria connessione di rete nella maggior parte dei casi.
2. Configurazione Avanzata
  La guida di riferimento per capire come funziona la configurazione, è un prerequisito per capire le impostazioni modulari.
3. Impostazioni modulari
  Gentoo fornisce impostazioni di rete flessibili, dando la possibilità di scegliere diversi client DHCP, impostare bonding, bridging, VLAN e altro.
4. Reti Wireless
  Le reti Wireless sono ancora per esperti, ma questa è una guida utile!
5. Ulteriori funzionalità
  Per gli esperti ecco le istruzioni per personalizzare l'infrastruttura di rete.
6. Gestione della rete
  Per i portatili o per chi cambia frequentemente rete.

A. Installazione di Gentoo

1. A proposito dell'installazione di Gentoo

1.a. Introduzione

Innanzitutto un caldo benvenuto a Gentoo. Si sta per entrare nel mondo delle possibilità e delle performance. Tutto Gentoo gira intorno alle possibilità. Durante l'installazione di Gentoo questo concetto viene chiarito più volte; è possibile scegliere quanto vogliate compilare autonomamente, come installare Gentoo, che logger di sistema utilizzare, e molto altro.

Gentoo è una veloce e moderna metadistribuzione con una architettura semplice e flessibile. Gentoo è stata costruita con software libero e non nasconde agli utenti i meccanismi che ne stanno alla base. Portage, il sistema di gestione dei pacchetti utilizzato da Gentoo, è scritto in Python: è semplice quindi esaminare e modificare il sorgente. Il sistema di pacchetti di Gentoo è basato sui sorgenti, sebbene sia anche compreso il supporto per precompilati, e la configurazione di Gentoo avviene tramite semplici file di testo. In altre parole è tutto alla luce del sole.

E' molto importante comprendere che le possibilità sono ciò che sta alla base di Gentoo. L'obiettivo è di non forzare mai l'utente a qualcosa che non desidera, al contrario offrire tutte le possibilità di cui si può avere bisogno. Nel caso si abbia un'impressione diversa è possibile segnalarlo.

Struttura dell'installazione

Gentoo Linux propone due versione di un semplice applicativo di installazione. Una, basata su GTK+, da utilizzare in ambiente grafico X e una basata su finestre testuali per la console. Il Capitolo 3 del manuale tratta la versione basata su GTK+, mentre il Capitolo 4 quella testuale.

All'interno del manuale a volte si presentano casi in cui è necessario effettuare una scelta: viene quindi fatto il possibile per illustrare quali siano i pro e i contro. La guida continua poi con una scelta di Default, indentificata come "Default: " nel titolo. Le restanti possibilità vengono indicate come "Alternative: ". La scelta di default in generale non è quella raccomandata, è semplicemente quello che si pensa che faccia la maggior parte degli utenti.

A volte può essere intrapreso un passo opzionale. In questo caso il passo viene segnato come "Opzionale: " e non è dunque indispensabile per l'installazione di Gentoo. In ogni caso alcuni passi opzionali dipendono strettamente da decisioni prese in precedenza. Viene quindi messa in luce la questione in tali occasioni, sia prima che venga intrapresa la scelta, sia prima della descrizione del passo opzionale.

A proposito delle opzioni

Si può installare Gentoo in molti modi differenti. Si può scaricare e installare da uno dei CD di installazione, si può farlo da un'altra distribuzione già esistente, da un CD bootabile (come Knoppix), da un ambiente avviato via rete, da un floppy ecc.

Questo documento tratta dell'installazione tramite il CD di Installazione, un CD bootabile, che contiene tutto ciò di cui si ha bisogno per installare ed eseguire Gentoo Linux. Esistono due tipi di CD di Installazione, l'InstallCD e il LiveCD di installazione. L'InstallCD è un ambiente essenziale che contiene solo gli strumenti necessari per eseguire un'installazione. Il LiveCD di installazione è un ambiente Gentoo Linux completo che può essere utilizzato per diversi scopi, uno dei quali l'installazione. Il LiveCD non è ancora disponibile per tutte le architetture. Se per la propria architettura non è ancora disponibile un LiveCD nel documento viene fatto riferimento all'InstallCD.

Con questo metodo non si utilizzano subito le ultime versioni dei pacchetti disponibili; se si desidera questo altro metodo, si vedano le istruzioni di installazione nel Manuale Gentoo Linux.

Per istruzioni riguardanti altri approcci consultare la Guida alternativa all'installazione. E' inoltre disponibile una raccolta di suggerimenti che potrebbero essere una lettura altrettanto utile. Nel caso queste istruzioni sembrassero troppo complesse è possibile usare una guida più rapida disponibile nella pagina della documentazione ufficiale, se la propria architettura ha questo tipo di documento.

In caso di problemi

Se durante l'installazione o nella documentazione si trovassero problemi è possibile controllare l'errata corrige o il sistema di gestione dei bug e, nel caso non fosse un problema già noto, segnalarlo per una rapida soluzione. Non c'è motivo di temere la reazione degli sviluppatori a cui vengono assegnati i bug: sono innocui.

Notare che, nonostante il presente documento sia specifico per ogni architettura, non mancano riferimenti ad altre architetture. Questo avviene a causa del fatto che diverse parti del manuale sono comuni a tutte le architetture per evitare duplicazioni e problemi vari. L'intento è comunque quello di limitare i riferimenti alle altre architetture per evitare confusioni.

Se, nonostante l'attenta lettura del manuale, non è ben chiaro se il problema riguardi un errore dell'utente, o un bug software, cosa effettivamente plausibile nonostante i numerosi test, è possibile entrare nel canale #gentoo su irc.freenode.net. Ovviamente si è sempre benvenuti!

Se ci fossero domande riguardanti Gentoo, è possibile consultare le Risposte frequenti, disponibili nella Documentazione Gentoo. E' possibile inoltre sfruttare le FAQ disponibili sui forum. Se ancora il dubbio rimanesse irrisolto si può entrare in #gentoo su irc.freenode.net dove parecchi esperti sono sempre disponibili.

1.b. Installazione rapida grazie alla Gentoo Reference Platform

Cos'è la Gentoo Reference Platform?

La Gentoo Reference Platform, d'ora in poi GRP, è un'insieme di pacchetti precompilati che gli utenti possono utilizzare durante l'installazione di Gentoo per velocizzare il processo. La GRP comprende praticamente tutti i pacchetti necessari per ottenere un'installazione di Gentoo completamente funzionante. E non solo sono disponibili i pacchetti necessari ad avere un'installazione di base in poco tempo, ma anche tutti i pacchetti più voluminosi (come xorg-x11, GNOME, OpenOffice e Mozilla).

Questi pacchetti però non vengono mantenuti nel corso dell'esistenza della distribuzione Gentoo. Vengono semplicemente resi disponibili ad ogni rilascio ufficiale di Gentoo e servono solo ad avere un'installazione funzionale in breve. E' possibile aggiornare il proprio sistema in seguito senza dover interrompere il proprio lavoro.

Come vengono gestiti i pacchetti GRP da Portage

Il proprio Portage Tree, cioè l'insieme delle proprie ebuild (che sono file che contengono tutte le informazioni utili su un pacchetto, come la descrizione, la homepage, gli URL dei sorgenti, le istruzioni di compilazione, le dipendenze, etc), deve essere sincronizzato con il set GRP che si desidera usare: le versioni delle ebuild e dei pacchetti GRP devono corrispondere.

Per questo motivo si può beneficiare dei pacchetti GRP forniti da Gentoo solo quando si effettua questo metodo di installazione. GRP non è disponibile per coloro che sono interessati ad installare con le ultime versioni dei pacchetti disponibili.

Disponibilità dei GRP

Non tutte le architetture dispongono di pacchetti GRP. Questo non significa che il sistema GRP non sia supportato in tali architetture ma solo che non ci sono ancora le risorse necessarie per compilare e testare i pacchetti.

Al momento sono disponibili i pacchetti GRP per le seguenti architetture:

L'architettura amd64 (amd64)
L'architettura ppc (ppc32, ppc64)
L'architettura sparc (sparc64)
L'architettura x86 (athlon, athlon-xp, athlon-mp, pentium-pro, pentium2, pentium3, pentium4 e pentium-m). Nota: i pacchetti sono per i686 e sono disponibili sul LiveCD di installazione.

Se la propria architettura (o sottoarchitettura) non è tra quelle elencate, non è possibile utilizzare i pacchetti GRP durante l'installazione.

L'introduzione termina qui, si può continuare con Avviare il LiveCD di Installazione/InstallCD.

2. Avviare l'installazione con il LiveCD di installazione

2.a. Richieste Hardware

Introduzione

Prima ancora di cominciare vengono elencate le richieste hardware necessarie per installare Gentoo sulla propria macchina con il LiveCD di intallazione.

Richieste hardware

CPU	Tutte le AMD64 CPU *
Memoria	128 MB
Spazio su disco	1.5 GB (escluso lo spazio per swap)
Spazio per swap	Almeno 256 MB

2.b. Il LiveCD di installazione Gentoo Linux

Introduzione

Un LiveCD è un CD bootabile che contiene un ambiente Gentoo autonomo. Consente di bootare Linux da CD. Durante il processo di boot viene rilevato l'hardware e vengono caricati i relativi driver. I CD vengono mantenuti dagli sviluppatori Gentoo.

Sono disponibili due CD di installazione:

Il LiveCD di installazione contiene tutto ciò di cui si ha bisogno per installare Gentoo. Fornisce uno stage3 per le architetture comuni, codici sorgenti per le applicazioni che si possono scegliere e le istruzioni di installazione per la propria architettura.
Il CD di installazione Minimale contiene solo un ambiente minimale che permette di avviare e configurare la rete per connettersi a Internet. Non contiene ulteriori file e non può essere usato durante questo metodo di installazione.

2.c. Scaricare, masterizzare e bootare il LiveCD di installazione Gentoo Linux

Scaricare e masterizzare il LiveCD di installazione

Si possono scaricare i LiveCD di installazione da uno dei nostri mirror. I LiveCD di installazione sono nella directory releases/amd64/2006.1/livecd/.

Dentro quella directory si trovano i file ISO. Si tratta di immagini complete di CD che possono essere scritte su un CD-R.

Dopo aver scaricato il file, si può controllare l'integrità:

Si può controllare il checksum MD5 e confrontarlo con quelli forniti (con il tool md5sum sotto Linux/Unix o con md5sum per Windows)
Si può verificare la firma crittografata che forniamo. Si deve ottenere la chiave pubblica che è usata da noi (17072058) prima di andare avanti.

Per scaricare la nostra chiave pubblica con l'applicazione GnuPG, eseguire il seguente comando:

Codice 3.1: Ottenere una chiave pubblica

$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058

Verificare ora la firma:

Codice 3.2: Verificare la firma crittografata

$ gpg --verify <signature file> <downloaded iso>

Per masterizzare l'immagine scelta è necessario scegliere la modalità RAW. Come impostarla dipende dal programma. Si tratteranno cdrecord e K3B: ulteriori informazioni si possono trovare sulle Gentoo FAQ.

Con cdrecord, scrivere semplicemente cdrecord dev=/dev/hdc <downloaded iso file> (dove /dev/hdc è la periferica del masterizzatore)
Con K3B, selezionare Tools > CD > Burn Image. Si può individuare il file ISO nell'area 'Image to Burn'. Poi cliccare su Start.

Bootare il LiveCD di installazione

Importante: E' importante leggere in anticipo tutta questa parte prima di continuare perchè probabilmente non ci sarà modo di farlo ad operazioni in corso.

Una volta masterizzato i LiveCD di installazione è tempo di bootare. Rimuovere tutti i CD dal CD drive, riavviare il sistema ed entrare nel BIOS, di solito premendo i tasti DEL, F1 o ESC a seconda della marca del BIOS. All'interno del BIOS cambiare l'ordine del boot in modo tale che il CD-ROM preceda l'hard disk. Spesso questa opzione si trova sotto "CMOS Setup". Nella maggior parte dei casi saltare questo passo porta a non poter bootare direttamente da CD.

Inserire il LiveCD di installazione nel lettore CD-ROM e riavviare il sistema. Dovrebbe comparire una schermata con il prompt del boot. A questo punto, premendo invio è possibile far partire il processo di boot con le opzioni di default oppure far bootare il CD di installazione con opzioni personalizzate specificando un kernel seguito dalle opzioni desiderate e premendo invio.

Vengono forniti diversi kernel sul LiveCD di installazione. Quello di default è gentoo. Altri kernel sono per necessità hardware specifiche e la variante -nofb che disabilita il framebuffer.

Di seguito è possibile consultare una breve descrizione per ognuno dei kernel disponibili:

Kernel	Descrizione
gentoo	Kernel di default con supporto per CPU K8 (tra cui NUMA) e CPU EM64T
memtest86	Analizza la RAM alla ricerca di errori

E' possibile anche selezionare opzioni per il kernel. Si tratta di direttive particolari che possono essere attivate o meno a piacere. La seguente lista descrive tutte le opzioni del kernel disponibili quando si preme da F2 a F7.

Codice 3.3: Opzioni disponibili per il kernel scelto

Hardware options:

acpi=on         Carica il supporto per ACPI e attiva l'avvio del demone
                acpid insieme al CD. L'opzione è necessaria solo se il sistema
                necessita di ACPI per funzionare correttamente. Non è necessario
                per il supporto Hyperthreading.
        
acpi=off        Disabilita completamente ACPI. E' utile su alcuni
                sistemi un po' datati ed è prerequisito per utilizzare APM.
                L'opzione disabilita il supporto Hyperthreading del processore.
        
console=X       Imposta una console seriale per il CD. La prima opzione è la
                periferica, di solito ttyS0 su x86, seguita da ulteriori opzioni
                di connessione, separate da virgola. Le opzioni di default sono
                9600,8,n,1.
        
dmraid=X        Consente il passaggio di opzioni al sistema device-mapper
                RAID. Le opzioni devono essere passate tra virgolette.
        
doapm           Carica il driver APM. E' prerequisito che sia impostato     
                acpi=off.
        
doslowusb       Aggiunge pause extra nel processo di boot per il lento CDROM
                USB dell'IBM BladeCenter.
        
dopcmcia        Carica il supporto per hardware PCMCIA e Cardbus e
                imposta l'avvio automatico sul CD del pcmcia cardmgr. E'
                richiesto solo quando si sta bootando da una periferica
                PCMCIA/Cardbus.
        
doscsi          Carica il supporto per la maggior parte di controller SCSI.
                E' prerequisito per bootare da molte periferiche USB, visto che
                utilizzano il supporto SCSI del kernel.
        
hda=stroke      Consente di partizionare l'intero disco fisso anche quando
                il BIOS non è in grado di vedere dischi grandi. Questa opzione
                viene usata solo su macchine con BIOS vecchio. Sostituire hda
                con la periferica che richiede l'opzione.
        
ide=nodma       Forza a disabilitare il DMA nel kernel ed è necessario per
                alcuni chipset IDE e alcuni lettori CDROM. Se il sistema ha
                problemi a leggere dal CDROM è possibile provare quest'opzione.
                Disabilita inoltre le impostazioni di default di hdparm.
        
noapic          Disabilita l'Advanced Programmable Interrupt
                Controller che è presente sulle schede madri più recenti. Sembra
                che abbia alcuni problemi con hardware più vecchio
        
nodetect        Disabilita tutta la fase di rilevazione da parte del CD, tra
                cui la rilevazione delle periferiche e il DHCP. E' utile per il
                debugging di un CD o un driver non funzionante
        
nodhcp          Disabilita la ricerca DHCP per le interfacce di rete
                rilevate. Utile per le reti con indirizzi IP statici.
        
nodmraid        Disabilita il supporto per il device-mapper             
                RAID, come quello usato per il controller IDE/SATA RAID onboard
        
nofirewire      Disabilita il caricamento dei moduli Firewire. Dovrebbe
                essere necessario solo se l'hardware Firewire è causa di
                problemi in fase di boot
    
nogpm           Disabilita il mouse in console via gpm

nohotplug       Disabilita l'esecuzione degli script hotplug e coldplug al
                boot. Utile per il debug di un driver o un CD difettoso.
        
nokeymap        Disabilita la selezione della keymap per configurazioni non US.
        
nolapic         Disabilita l'APIC locale su kernel monoprocessore.

nosata          Disabilita il caricamento dei moduli Serial ATA. Utile se il
                sistema ha problemi con il sistema SATA.
        
nosmp           Disabilita SMP, il Symmetric Multiprocessing, su kernel che lo
                supportano. E' utile per il debug di problemi SMP per
                specifiche schede madr i e driver.
        
nosound         Disabilita il supporto per il suono e il volume. Utile nei
                casi in cui il suono causa problemi.
        
nousb           Disabilita il caricamento automatico dei moduli USB, utile
                per il debug di problemi con USB

Gestione dei Volumi e delle periferiche:

dodevfs         Abilita il filesystem devfs, ormai sconsigliato su kernel
                2.6. E' inoltre necessario abilitare noudev per rendere
                effettiva l'opzione. Visto che devfs è obbligatoria nei kernel
                2.4 l'opzione non ha effetto su questi ultimi.
        
doevms2         Abilita il supporto per l'EVMS di IBM, conosciuto anche
                come Enterprise Volume Management System. Non è consigliato per
                l'utilizzo con lvm2.
        
dolvm2          Abilita il supporto per il Logical Volume Management di Linux.
                Da non abilitarsi con evms2.
        
noudev          Disabilita il supporto udev per i kernel 2.6. L'opzione
                richiede l'attivazione di dodevfs. Visto che udev non è
                disponibile su kernel 2.4, l'opzione non ha efficacia su questi
                ultimi.
        
unionfs         Abilita il supporto Unionfs sulle immagini CD supportate.
                Viene dunque creata una directory modificabile in una tmpfs in
                modo da consentire la modifica di tutti i file su CD.
        
unionfs=X       Abilita il supporto Unionfs sulle immagini CD supportate.
                Viene dunque creata una directory modificabile sulla
                periferica specificata. La periferica deve essere formattata con
                un filesystem riconosciuto e modificabile dal kernel.

Altre opzioni:

debug           Abilita la modalità di debug. L'opzione può confondere in
                quanto provoca la visualizzazione di grosse quantità di testo a
                video.
        
docache         Produce l'archiviazione in cache dell'intera parte runtime
                del CD in RAM, in modo da consentire di smontare /dev/cdrom e
                montarne un altro. L'opzione richiede di avere almeno il doppio
                della RAM rispetto alla dimensione del CD.
        
doload=X        Consente al ramdisk iniziale di caricare tutti i moduli
                elencati oltre alle dipendenze. Sostituire X con il nome del
                modulo. Possono essere spcificati diversi moduli separati da
                virgola.
        
noload=X        Impedisce al ramdisk iniziale il caricamento di un modulo
                spscifico che potrebbe causare problemi. La sintassi è la
                medesima di doload.
        
nox             Impedisce ai LiveCD con X di caricare l'interfaccia grafica
                e propone direttamente l'interfaccia testuale.
        
scandelay       Forza il CD a effettuare pause di 10 secondi durante alcune
                parti del processo di boot per consentire alle periferiche lente
                di caricarsi correttamente.
        
scandelay=X     Consente di specificare un adeguato ritardo in secondi da
                aggiungere in alcune parti del processo di boot per consentire
                alle periferiche lente di caricarsi correttamente. Sostituire X
                con il numero di secondi di pausa.

Adesso è possibile bootare il CD selezionando il kernel (se non volete utilizzare quello di default) e le opzioni di boot. Ad esempio ecco come bootare il kernel gentoo, con il parametro dopcmcia:

Codice 3.4: Bootare un CD di installazione

boot: gentoo dopcmcia

Si dovrebbe presentare ora un altra schermata con una barra che indica lo svolgersi delle operazioni. Se si sta installando Gentoo da un sistema con una tastiera non statunitense, premere Alt-F1 per passare alla modalità verbose e seguire il prompt. Se non è fatta nessuna selezione dopo 10 secondi, sarà accettata la tastiera di default (statunitense) e continuerà il processo di boot. Una volta completato il processo di boot si avvia l'ambiente Live di Gentoo Linux con una sessione Gnome dell'utente "gentoo". Si avranno inoltre a disposizione delle console testuali con i privilegi di "root, l'utente amministratore, riconoscibili dal simbolo "#" nel prompt. E' possibile passare dall'una all'altra premendo Alt-F2, Alt-F3, Alt-F4 Alt-F5, Alt-F6. Per tornare all'interfaccia grafica premere Alt-F7. Per passare alle console da X è necessario premere anche Ctrl. Da interfaccia grafica è possibile eseguire comandi con privilegi di root da qualsiasi terminale semplicemente utilizzando l'applicazione sudo. E' infine possibile diventare root all'interno di un terminale per eseguire comodamente diverse operazioni.

Codice 3.5: Usare sudo per eseguire applicazioni

(Esempio)
(Modificare il file group)
# sudo vi /etc/group
(diventare root per l'intera sessione)
# sudo su -

Configurazione dell'hardware extra

Al momento del boot il LiveCD prova a rilevare tutte le periferiche hardware e caricare i corrispondenti moduli del kernel di supporto. Nella grande maggior parte dei casi l'operazione va a buon fine. A volte potrebbero non essere caricati tutti i moduli necessari. Se la rilevazione PCI ha saltato qualche periferica, è necessario caricare manualmente il modulo corrispondente.

Nel seguente esempio si prova a caricare il modulo 8139too (che supporta un certo tipo di interfacce di rete):

Codice 3.6: Caricamento dei moduli del kernel

# modprobe 8139too

Se si ha bisogno del supporto PCMCIA, si dovrebbe avviare init script pcmcia:

Codice 3.7: Avviare init script PCMCIA

# /etc/init.d/pcmcia start

Opzionale: Ottimizzazione delle performance dell'hard disk

Alcuni utenti esperti potrebbero voler ottimizzare le performance del proprio hard disk tramite hdparm. Sono necessari i privilegi di root per l'esecuzione di hdparm. Con le opzioni -tT è possibile testare le performance del proprio disco (eseguire il test alcune volte per avere risultati più precisi):

Codice 3.8: Test delle performance del disco

# hdparm -tT /dev/hda

Per l'ottimizzazione è possibile utilizzare uno dei seguenti esempi (o una configurazione personalizzata) che usano /dev/hda come disco (sostituirlo con il proprio):

Codice 3.9: Ottimizzazione delle performance del disco

Attivare il DMA:
# hdparm -d 1 /dev/hda

Attivare le opzioni sicure di ottimizzazione:
# hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda

Opzionale: Account utente

Se si pensa di dare accesso ad altri al proprio ambiente di installazione o si desidera chattare usando irssi senza i privilegi root (per ragioni di sicurezza), è necessario creare gli opportuni account utente e cambiare la password di root. Sono necessari i privilegi di root per cambiare la password di rotto o aggiungere nuovi utenti.

Per cambiare la password di root utilizzare l'utility passwd:

Codice 3.10: Cambiare la password di root

$ sudo su -
# passwd
New password: (Inserire la nuova password)
Re-enter password: (Inserire nuovamente la password)

Per creare un account utente è necessario inserire i suoi dati seguiti dalla sua password. E' possibile utilizzare useradd e passwd per farlo, come mostra il prossimo esempio in cui si crea l'utente "john".

Codice 3.11: Creare un account utente

# useradd -m -G users john
# passwd john
New password: (Inserire la password di john)
Re-enter password: (Inserire nuovamente la password di john)

E' possibile dunque cambiare utente da root al nuovo utente tramite su:

Codice 3.12: Cambiare utente

# su - john

E' anche possibile cambiare la password dell'utente "gentoo" in modalità grafica. L'account è già pronto per l'utilizzo di applicazioni Internet.

Codice 3.13: Cambiare la password dell'utente gentoo

$ passwd
New password: (Inserire la nuova password)
Re-enter password: (Inserire nuovamente la password)

Opzionale: Vedere la documentazione mentre si installa

Se si desidera vedere il Manuale Gentoo (da un CD o online) durante l'installazione, è possibile farlo con Mozilla Firefox, in modalità grafica, o con links da terminale.

Codice 3.14: Consultare la documentazione su CD con Firefox

# firefox /mnt/cdrom/docs/handbook/html/index.html

Se invece si preferisce usare links e visualizzare una versione solo testuale del manuale, assicurarsi di aver creato un account utente (vedere Opzionale: Account utente). Premere poi Alt-F2 per visualizzare il terminale ed accedere.

Codice 3.15: Consultare la documentazione su CD con links

# links /mnt/cdrom/docs/handbook/html/index.html

E' possibile poi tornare all'interfaccia grafica con Alt-F7.

Tuttavia, si preferisce usare il Manuale Gentoo online poichè è più recente di quello sul CD. E' possibile consultarlo con Firefox o links, ma solo dopo avere completato il capitolo Configurazione della rete (altrimenti non si potrà andare su Internet per vedere i documenti):

Codice 3.16: Vedere la documentazione online con Firefox

# firefox http://www.gentoo.org/doc/en/handbook/2006.1/handbook-amd64.xml

Codice 3.17: Vedere la documentazione online con links

# links http://www.gentoo.org/doc/en/handbook/2006.1/handbook-amd64.xml

Procedere ora all'utilizzo della procedura grafica di installazione (che si basa su X) o della procedura a menu che può anche essere esegui ta da terminale.

3. Procedura grafica di installazione

2.a. Benvenuto

Introduzione

Una volta terminato il caricamento dell'applicativo Gentoo dedicato all'installazione si presenta una schermata di benvenuto. E' una semplice introduzione al processo di installazione di Gentoo sul proprio computer. E' importante ricordare di leggere attentamente ciascuna delle opzioni. E' disponibile documentazione dettagliata per ogni passo dell'installazione, basta cliccare su Help, in basso a sinistra nella finestra di installazione. E' importante leggere le pagine di documentazione prima di effettuare le scelte. In ogni momento durante l'installazione è possibile salvare le impostazioni per riprendere l'installazione in un secondo tempo.

Esistono due modalità di installazione: scegliere Networkless per avviare l'installazione di Gentoo Linux.

Nota: Selezionare Networkless renderà in seguito non disponibili alcune opzioni di configurazione. Procedere alla schermata successiva.

3.b. Configurazione preinstallazione

Opzionale: Configurazione di rete manuale

Nella prossima parte si affronta la configurazione di rete. L'applicativo di installazione dovrebbe rilevare e configurare automaticamente la rete, ma se così non fosse è possibile impostare i parametri manualmente. Dal tab Misc. si può infine impostare la directory dove l'applicativo conserva il log oppure accontentarsi del default /var/log/installer.log.

Opzionelae: Installazione remota

Se si desidera abilitare l'accesso SSH per la macchina è sufficiente avviare sshd e specificare la password di root.

Opzionale: Caricare moduli aggiuntivi del kernel

Se si ha la necessità di caricare ulteriori moduli per il kernel per supportare il proprio hardware, inserire i nomi all'interno della riga apposita, separandoli con spazi.

Avvertenza: Non cambiare l'opzione Install mode in qualcosa che non sia Normal. Questa feature è ancora sperimentale e in corso di cambiamento. Potrebbe causare seri problemi in fase di boot!

3.c. Partizionamento

Preparazione dei dischi

Per consentire l'installazione di Gentoo sul sistema è necessario preparare i dischi. La schermata Partitioning mostra la lista dei dischi rilevati e consente di specificare il tipo di filesystem che si desidera sulla propria partizione. Cliccando su Clear partitions è possibile eliminare tutte le partizioni già esistenti, prestare attenzione all'utilizzo di questo strumento! E' infine possibile ridimensionare alcuni tipi di partizoione.

Se si sceglie l'impostazione consigliata, Recommended layout, l'installazione crea tre partizioni: 100MB per /boot, una partizione di /swap grande fino a 512MB ed il resto dello spazio libero viene assegnato a /, la partizione di root. Se si dispone di più di 4GB di spazio non partizionato, utilizzando l'opzione "Recommended" si può configurare le partizioni senza dover rimuovere alcun dato nelle partizioni restanti.

Avvertenza: Come durante l'utilizzo di qualsiasi applicazione per la gestione delle partizioni, è consigliabile effettuare un backup del sistema prima di apportare cambiamenti alla tabella delle partizioni. In alcuni casi, la presenza di bug può portare a perdite di dati.

3.d. Unità di rete

Opzionale: Definizione di unità di rete

La schermata consente di impostare ed utilizzare unità di rete esistenti durante e dopo l'installazione. Selezionare New per cominciare la confi gurazione. Al momento sono supportate solo unità NFS.

3.e. make.conf

Flag USE

Visto che si sta effettuando una installazione GRP senza supporto di rete, non è possibile selezionare le flag USE prima dell'installazione. In ogni caso si è liberi di impostare le proprie preferenze con le flag USE, modificando il file /etc/make.conf una volta riavviato il sistema installato.

CFLAGS

Si dovrebbe comunque selezionare il tipo di processore in uso nella sezione CFLAGS includendo anche tutte le ottimizzazioni personalizzate che si desidera, quali -O2 o -pipe.

Altro

Qualsiasi altra opzione che si desideri impostare per il sistema può essere selezionata ora. Build binary packages crea pacchetti binari pronti per l'installazione di tutti i pacchetti che si compilano per il sistema. DistCC offre la possibilità di suddividere il peso della compilazione du diverse macchine tramite una connessione di rete. ccache salva il codice compilato per uso futuro e può essere di grande utilità nel caso capiti di reinstallare o aggiornare lo stesso pacchetto.

Non è possibile cambiare CHOST perchè l'operazione può compromettere gravemente l'installazione. In MAKEOPTS è possibile definire quante compilazioni parallele consentire durante l'installazione di un pacchetto. La scelta consigliata equivale al numero di CPU del sistema più uno, ma non è detto che questa sia sempre l'impostazione migliore. Su un sistema uniprocesore si consiglia di impostare -j2.

3.f. Sorgenti del kernel

Utilizzo del kernel del LiveCD

E' necessario utilizzare il kernel presente sul LiveCD per le installazioni GRP senza internet. Si tratta semplicemente di un kernel gentoo-sources compilato con genkernel, lo strumento di compilazione automatica di Gentoo; rileva automaticamente e configura il proprio hardware in fase di boot.

Se si desidera avere una bella immagine di sfondo durante il boot, selezionale l'opzione Enable bootsplash.

3.g. Bootloader

Possibilità di scelta

La schermata consente di scegliere il bootloader da installare e, se lo si desidera, specificare ulteriori parametri da passare al kernel il fase di boot.

E' possibile scegliere da quale disco fare il boot scegliendo l'opzione corrispondente in Boot Drive. In Linux, il primo disco IDE del sistema viene chiamato hda, il secondo disco IDE hdb e csì via. Se si è in possesso di dischi SATA o SCSI vengono chiamati sda, sdb, eccetera. Selezionare l'opzione corretta per il proprio sistema.

Se si necessita di passare ulteriori opzioni al kernel, ad esempio le impostazioni video o vga, è possibile aggiungerli nella sezione "Extra kernel parameters".

Se si è impostato il proprio disco con il jumper perchè il BIOS non è in grado di gestire dischi grandi è necessario aggiungere hdx=stroke. Se si è in possesso di perferiche SCSI è importante aggiungere doscsi come opzione per il kernel.

3.h. Fuso orario

Scegliere la propria zona

Esaminare la mappa e scegliere la regione più vicina al proprio luogo di residenza. Successivamente viene chiesto se impostare il proprio orologio di sistema a UTC o all'ora locale.

3.i. Rete

Aggiungere una periferica di rete

Da questa schermata è possibile configurare le varie interfacce di rete rilevate sul proprio computer. Esaminare attentamente le opzioni disponibili.

Sul tab Hostname/Proxy Information/Other è necessario scegliere il nome della propria macchina. E' possibile inoltre specificare il server proxy ed le impostazioni DNS, se necessarie.

3.j. Servizi

Servizio cron

I servizi Cron sono strumenti utili che eseguono operazioni particolari ad intervalli pianificati. Non è necessario installarne uno ma possono ess ere molto utili.

Logger di sistema

Un logger di sistema è indispensabile per ogni sistema operativo Linux, sceglierne uno tra le possibilità elencate.

3.k. Pacchetti Extra

Opzionale: installazione di altri pacchetti

Il LiveCD mette a disposizione una serie di pacchetti precompilati. Se si desidera installarne alcuni selezionare la spunta relativa.

3.l. Servizi di avvio

La schermata offre la possibilità di scegliere i servizi da attivare in fase di avvio. Esaminare attentamente le opzioni disponibili e le loro descrizioni e selezionare i servizi desiderati. Ad esempio se si è scelto di installare xorg-x11 e si vuole avviare immediatamente dopo il boot l'interfaccia grafica è possibile selezionare dalla lista "xdm".

3.m. Altre impostazioni

Opzioni varie

A questo punto è possibile modificare diverse impostazioni, tra cui la configurazione della tastiera, il display manager, l'editor di testo preferito e l'impostazione dell'orologio di sistema a UTC o locale.

3.n. Users

Aggiunta di utenti e gruppi

Innanzitutto impostare la password di root, l'utente amministratore.

Si raccomanda fortemente di creare un utente non privilegiato per il lavoro quotidiano. Agire sul sistema con i privilegi di root è pericoloso e deve essere evitato. Creare dunque i propri utenti, impostare le rispettive password ed aggiungerli ai gruppi appropriati. E' inoltre possibile modificare le directory personali, le shell e impostare utili commenti.

3.o. Riepilogo

Conclusione

E' opportuno ora controllare attentamente ogni passo del processo di installazione e verificare che il proprio sistema sia configurato correttamente. Una volta terminata la revisione è possibile salvare le impostazione ed uscire oppure selezionare Install per incominciare subito il processo automatico di installazione di Gentoo.

Durante il processo di installazione si può girare per i vari contenuti del LiveCD. La finstra di installazione avvisa al termine dell'installazione. A quel punto si può procedere a chiudere la finestra cliccando sulla x in alto a destra. Infine disconnettersi e riavviare il sistema ricordandosi di rimuovere il LiveCD durante il reboot.

Congratulazioni, il sistema è completamente installato. Continuare ora con i passi successivi per saperne di più su Gentoo.

4. Procedura di installazione da console

4.a. Benvenuto

Prima di iniziare

Una volta effettuato il boot dal LiveCD di installazione Gentoo, si dovrebbe avviare l'interfaccia grafica. Se così non fosse, viene visualizzato un propompt dei comandi testuale. Per lanciare la procedura di installazione eseguire:

Codice 1.1: Avviare l'installazione

# installer

Terminato il caricamento dell'applicativo, viene visualizzata la schermata di benvenuto che offre una semplice introduzione al processo di installazione di Gentoo sul computer. E' importante leggere attentamente ciascuna delle opzioni. Nella parte superiore è sempre disponibile una descrizione che può essere utile consultare ad ogni passo. E' raccomandabile leggere bene queste istruzioni prima di procedere alla scelta delle azioni da intraprendere. Notare che in ogni momento è possibile salvare le impostazioni selezionare e continuare il processo di installazione più tardi. Utilizzare il tasto Tab della tastiera per muoversi attraverso i menu e il tasto Invio per confermare le scelte.

Esistono due modalità di installazione: scegliere Networkless per avviare l'installazione di Gentoo Linux.

Nota: Selezionare Networkless renderà in seguito non disponibili alcune opzioni di configurazione. Procedere alla schermata successiva.

4.b. Configurazione preinstallazione

Opzionale: Configurazione manuale della rete

Sebbene l'installazione non utilizzi una connessione ad internet è possibile impostare manualmente la connessione alla propria rete locale, nel caso si desideri installare Gentoo da una macchina remota della propria rete.

Se si desidera abilitare l'accesso SSH per consentire una installazione remota, è possibile avviare sshd e specificare una password di root.

Opzionale: Aggiungere nuovi moduli del kernel

Se si ha la necessità di caricare ulterioi moduli del kernel per supportare il proprio hardware, inserire ciascun nome separato da uno spazio.

4.c. Partizioni

Preparazione dei dischi

Per installare Gentoo sulla proprioa macchina è necessario preparare i dischi. la schermata denominata Partitioning visualizza la lista dei dischi rilevati e consente di specificare i filesystem che si desidera applicare alle proprie partizioni. Selezionando Clear partitions vengono cancellate tutte le partizioni esistenti sul disco, prestare attenzione a questa opzione! E' inoltre possibile ridimensionare alcuni tipi di partizione.

4.d. Unità di rete

Opzionale: Definizione di unità di rete

La schermata consente di impostare ed utilizzare unità di rete esistenti durante e dopo l'installazione. Al momento sono supportate solo unità NFS.

4.e. make.conf

flag USE

CFLAGS

Selezionare il tipo del proprio processore nella sezione CFLAGS, oltre a qualsiasi opzione di ottimizzazione che si desideri, quali -O2 o -pipe.

Ulteriori opazioni

Qualsiasi altra opzione che si desideri impostare per uso futuro deve essere selezionata ora. Consultare le FEATURES disponibili e scegliere le proprie.

4.f. Sorgenti del kernel

Utilizzo del kernel del LiveCD

4.g. Bootloader

Che cosa scegliere

Questa schermata consente di scegliere il bootloader. In seguito selezionare il dispositivo su cui eseguire il boot e se lo si desidera gli ulteriori parametri del boot.

4.h. Fuso orario

Scegliere la propria zona

Esaminare la lista e scegliere la regione più vicina al proprio luogo di residenza.

4.i. Rete

Aggiungere una periferica di rete

Da questa schermata è possibile configurare le varie interfacce di rete rilevate sul proprio computer. Esaminare attentamente le opzioni disponibili.

La prossima schermata offre la possibilità di scegliere tra DHCP e configurazione con IP statico. Una volta che l'interfaccia è configurata correttamente, è necessario impostare il nome del proprio sistema. E' possibile inoltre specificare un eventuale nome di dominio e le informazioni relative al DNS.

4.j. Pacchetti Extra

Opzionale: installazione di altri pacchetti

Il LiveCD mette a disposizione una serie di pacchetti precompilati. Se si desidera installarne alcuni selezionare la spunta relativa.

4.k. Servizi di avvio

Questa schermata consente di scegliere i servizi da avviare al boot di sistema. Studiare con attenzione le opzioni disponibili e le loro descrizioni e selezionare poi i servizi desiderati. Ad esempio se si è scelto di installare xorg-x11 e si desidera avere immediatamente disponibile l'interfaccia grafica, si può selezionare "xdm" dalla lista.

4.l. Ulteriori impostazioni

Varie

Ora è possibile cambiare ulteriori impostazioni, quali la configurazione della tastiera, il tipo di interfaccia grafica, l'editor di testo preferito e se si desidera avere un orologio UTC o impostato sull'ora locale.

4.m. Utenti

Aggiunta di utenti e gruppi

Innanzitutto impostare la password di root, l'utente amministratore.

4.n. Riepilogo

Conclusione

L'applicativo di installazione avvisa al termine delle operazioni. A quel punto, tornati al prompt dei comandi è sufficiente riavviare:

Codice 14.1: Riavvio

# shutdown -r now

Congratulazioni, il sistema è completamente installato. Continuare ora con i passi successivi per saperne di più su Gentoo.

5. Cosa fare adesso?

5.a. Documentazione

Congratulazioni! Adesso si ha un sistema funzionante con Gentoo. Ma cosa fare adesso? Quali sono le opzioni? Che cosa vedere per prima cosa? Gentoo fornisce ai suoi utenti molte possibilità e caratteristiche più o meno documentate.

Si dovrebbe dare un'occhiata alla prossima parte del Manuale Gentoo, Lavorare con Gentoo, che spiega come mantenere aggiornato il software, come installare altro software, che cosa sono le flag USE, come funziona il Gentoo Init system, etc.

Se si è interessati all'ottimizzazione del proprio sistema per il desktop, o si vuole imparare a configurare il sistema affinchè diventi un desktop completamente funzionante, consultare le Guide alla configurazione del desktop. Inoltre, è possibile fare riferimento alla nostra localization guide per adattare il sistema alla nazionalità.

E' ionoltre disponibile un ampio documento riguardante la Sicurezza in Gentoo di certo interesse.

Per un elenco completo di tutta la documentazione disponibile, consultare le risorse della Documentazione Gentoo.

5.b. Gentoo Online

Naturalmente si è i benvenuti sui Forum Gentoo, o su uno dei tanti Canali IRC Gentoo.

Ci sono anche molte mailing list aperte a tutti gli utenti. Informazioni su come unirsi sono contenute sulla pagina.

Per ora si termina qui, buon divertimento con Gentoo.

5.c. Cambiamenti di Gentoo dalla 2006.1

Cambiamenti

Non ci sono cambiamenti significativi al momento.

B. Lavorare con Gentoo

1. Una introduzione di Portage

1.a. Benvenuti in Portage

Portage è probabilmente l'innovazione di Gentoo più rilevante nella gestione software. La grande flessibilità e l'enorme quantità di caratteristiche ne fanno uno dei migliori programmi per la gestione del software disponibili per Linux.

Portage è completamente scritto in Python e Bash e perciò completamente visibile agli utenti essendo entrambi linguaggi di scripting.

Molti utenti useranno Portage attraverso il tool emerge. Questo capitolo non è un duplicato delle informazioni disponibili attraverso le pagine man di emerge. Per avere la lista completa delle opzioni di emerge, consultare la pagina man:

Codice 1.1: Leggere la pagina man di emerge

# man emerge

1.b. L'albero del Portage

Gli ebuild

Quando si parla di pacchetti si intendono spesso titoli software che sono disponibili agli utenti Gentoo attraverso l'albero del Portage. L'albero del Portage è una collezione di file ebuild che contengono tutte le informazioni necessarie al Portage per manutenere il software (installare, ricercare,....). Questi ebuild risiedono di default in /usr/portage.

Ogni qualvolta si chiede al Portage di eseguire alcune azioni riguardanti i titoli software, vengono usati gli ebuild del sistema come base. Diviene, così, importante aggiornare regolarmente gli ebuild del sistema in modo tale che Portage sia a conoscenza del nuovo software, degli aggiornamenti, ecc.

Aggiornamento dell'albero del Portage

L'albero del Portage viene di solito aggiornato con rsync, una utility per il trasferimento incrementale di file. L'aggiornameto è realmente semplice dato che il comando emerge fornisce un'interfaccia per rsync:

Codice 2.1: Aggiornamento dell'albero del Portage

# emerge --sync

Se non si riesce ad usare rsync a causa di un firewall si può aggiornare l'albero del Portage usando lo snapshot che viene generato giornalmente. Il tool emerge-webrsync scarica ed installa automaticamente l'ultimo snapshot dai sistemi Gentoo.

Codice 2.2: Eseguire emerge-webrsync

# emerge-webrsync

Un vantaggio ulteriore nell'uso di emerge-webrsync è che consente all'amministratore di prelevare nel portage solo gli snapshot dell'albero che sono contrassegnati dalla chiave GPG dela Gentoo release engineering. Ulteriori informazioni su questo argomento possono essere trovate nella sezione Prelevare snapshot del portage convalidati, di Caratteristiche di Portage.

1.c. Manutenzione del software

Ricerca del software

La ricerca dei titoli software attraverso l'albero del Portage si esegue utilizzando la funzione di ricerca di emerge. Di default emerge --search restituisce i nomi dei pacchetti i cui titoli corrispondono (per intero o parzialmente) a quelli forniti per la ricerca.

Per esempio, dovendo cercare tutti i pacchetti che hanno "pdf" nel loro nome:

Codice 3.1: Cercare i pacchetti che contengono pdf nel nome

$ emerge --search pdf

Se si vuole cercare attraverso la descrizione si può usare l'opzione --searchdesc ( o -S):

Codice 3.2: Cercare i pacchetti che contengono pdf nella descrizione

$ emerge --searchdesc pdf

Da uno sguardo all'output si nota che vengono fornite diverse informazioni. I campi sono chiaramente identificativi per cui non si addentrerà ulteriormente nel loro significato:

Codice 3.3: Esempio dell'output di 'emerge --search'

*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2

Installazione del software

Una volta trovato il titolo del software che interessa, lo si può facilmente installare con emerge facendolo seguire dal nome del pacchetto. Per esempio, per installare gnumeric:

Codice 3.4: Installare gnumeric

# emerge gnumeric

Dato che molte applicazioni dipendono da altre ogni tentativo di installare certi pacchetti software potrebbe portare all'installazione di alcuni pacchetti aggiuntivi. Se si vuol sapere cosa verrà installato dal Portage quando viene richiesta un'installazione, si deve aggiungere l'opzione --pretend. Per esempio:

Codice 3.5: Fingere di installare gnumeric

# emerge --pretend gnumeric

Quando si chiede al Portage di installare un pacchetto, verrà scaricato il codice sorgente necessario da internet e memorizzato di default in /usr/portage/distfiles. Il pacchetti verrà quindi estratto, compilato ed installato. Se si vuole che Portage scarichi solo i sorgenti senza installarli, aggiungere al comando emerge l'opzione --fetchonly:

Codice 3.6: Scaricare il codice sorgente di gnumeric

# emerge --fetchonly gnumeric

Trovare la documentazione di pacchetti installati

Molti pacchetti forniscono la propria documentazione. Alcune volte il flag USE doc determina se la documentazione del pacchetto verrà installata o no. Si può controllare l'esistenza di un flag USE doc con il comando emerge -vp <nome pacchetto>.

Codice 3.7: Controllo dell'esistenza di un flag USE doc

(Naturalmente, alsa-lib è solamente un esempio.)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

La modalità di abilitazione migliore per la flag USE doc è quella per singolo pacchetto tramite /etc/portage/package.use, in modo da avere la documentazione solo per i pacchetti desiderati. Abilitare globalmente questa flag può introdurre dei problemi di dipendenze circolari. Per maggiori informazioni, si prega di consultare il capitolo Flag USE.

Una volta che il pacchetto è stato installato, la sua documentazione viene generalmente trovata in una sottodirectory col nome del pacchetto nella directory /usr/share/doc. Si può avere la lista dei file installati con lo strumento equery che fa parte del pacchetto app-portage/gentoolkit .

Codice 3.8: Trovare la documentazione di un pacchetto

# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 28
-rw-r--r--  1 root root  669 May 17 21:54 ChangeLog.gz
-rw-r--r--  1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x  2 root root 8560 May 17 21:54 html
-rw-r--r--  1 root root  196 May 17 21:54 TODO.gz

(Alternativamente, usare equery per localizzare file che interessano:)
# equery files alsa-lib | less
media-libs/alsa-lib-1.0.14_rc1
* Contents of media-libs/alsa-lib-1.0.14_rc1:
/usr
/usr/bin
/usr/bin/alsalisp
(output troncato)

Rimozione del software

Se si vuole rimuovere un pacchetto dal sistema, usare emerge --unmerge. Questo comando rimuoverà tutti i file installati dal pacchetto eccetto i file di configurazione che sono stati alterati dopo l'installazione. In questo modo si permette di continuare a lavorare con il pacchetto nel caso si decidesse di installarlo nuovamente.

Attenzione: Portage non controllerà se il pacchetto che si vuole rimuovere sia richiesto da un altro pacchetto. Verrà solo emesso un avviso del fatto che la rimozione di pacchetti importanti potrebbe danneggiare il sistema.

Codice 3.9: Rimozione di gnumeric

# emerge --unmerge gnumeric

Quando si rimuove un pacchetto dal sistema, le sue dipendenze saranno lasciate. Per far trovare al Portage tutte le dipendenze che potrebbero essere rimosse, usare la funzionalità --depclean di emerge. Se ne parlerà in seguito.

Aggiornare il software

Per mantenere il sistema in perfetta forma (e non solo con gli ultimi aggiornamenti sulla sicurezza) si dovrà mantenere aggiornato il sistema regolarmente. Dato che Portage controlla gli ebuild dell'albero del Portage si dovrà prima aggiornare l'albero. Quindi, si potrà aggiornare il sistema con emerge --update world. Nell'esempio che segue, verrà utilizzato il parametro --ask che istruisce il Portage a visualizzare la lista dei pacchetti da aggiornare e la richiesta se si vuole continuare:

Codice 3.10: Aggiornare il sistema

# emerge --update --ask world

Portage cercherà quindi le nuove versioni delle applicazioni installate. Verranno comunque verificate solo le versioni per le applicazioni che si sono esplicitamente installate (cioè le applicazioni elencate in /var/lib/portage/world) e non le dipendenze. Se si vogliono aggiornare anche le dipendenze di questi ultimi pacchetti, occorre aggiungere l'argomento --deep:

Codice 3.11: Aggiornare il sistema con le dipendenze

# emerge --update --deep world

Questo ancora non vuol dire tutti i pacchetti: alcuni pacchetti nel proprio sistema sono necessari durante le fasi di compilazione e assemblaggio di altri pacchetti, ma una volta che questi sono installati, questi pacchetti non sono più necessari. Portage chiama queste dipendenze di assemblaggio. Per includerle in un ciclo di aggiornamento, occorre aggiungere --with-bdeps=y:

Codice 3.12: Aggiornare l'intero sistema

# emerge --update --deep --with-bdeps=y world

Dato che aggiornamenti che riguardano la sicurezza possono essere correlati a pacchetti che non si sono esplicitamente installati nel sistema (ma che sono stati installati quali dipendenze di altri programmi), si raccomanda di eseguire questo comando una volta ogni tanto.

Se è stato alterato qualche USE flag si può aggiungere l'opzione --newuse. Portage verificherà se la modifica richiede l'installazione di nuovi pacchetti o la ricompilazione di quelli esistenti:

Codice 3.13: Eseguire un aggiornamento completo

# emerge --update --deep --with-bdeps=y --newuse world

Metapacchetti

Alcuni pacchetti presenti nell'albero del Portage non hanno un contenuto reale ma sono usati per installare una collezione di pacchetti. Per esempio, il pacchetto kde-meta installa un ambiente KDE sul sistema ricercando tra i vari pacchetti legati al KDE come dipendenze.

La rimozione di un tale pacchetto dal sistema usando emerge --unmerge, non avrà successo dato che le numerose dipendenze rimarranno sul sistema.

Portage ha anche la funzionalità di rimozione delle dipendenze orfane, ma dato che la disponibilità del software è dinamicamente dipendente, occorre prima aggiornare completamente l'intero sistema, includendo, se ci sono state, le modifiche alle flag USE. Quindi sarà possibile eseguire emerge --depclean per rimuovere le dipendenze orfane. Fatto ciò, ci sarà bisogno di ricompilare le applicazioni che erano dinamicamente linkate al software rimosso ma non più richiesto.

Tutto ciò può essere fatto con un seguenti tre comandi:

Codice 3.14: Rimozione delle dipendenze orfane

# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

revdep-rebuild viene fornito col pacchetto gentoolkit, che deve essere quindi preventivamente installato:

Codice 3.15: Installazione del pacchetto gentoolkit

# emerge gentoolkit

1.d. Licenze

A partire dalla versione 2.1.7 di Portage, è possibile accettare o rifiutare l'installazione di un software in base alla sua licenza. Tutti i pacchetti nell'albero di Portage contengono una voce LICENSE nelle rispettive ebuild. Eseguendo emerge --search nomepacchetto è possibile visualizzare la licenza del pacchetto.

Come impostazione predefinita, Portage permette tutte le licenze, eccetto le "End User License Agreements" (EULA) che richiedono la lettura e la sottoscrizione dell'accettazione di un accordo.

La variabile che controlla le licenze permesse è ACCEPT_LICENSE, che può essere impostata in /etc/portage/make.conf:

Codice 4.1: Valorizzazione predefinita di ACCEPT_LICENSE in /etc/portage/make.conf

ACCEPT_LICENSE="* -@EULA"

Con questa configurazione, i pacchetti che richiedono un'interazione durante l'installazione a causa dell'approvazione della loro licenza EULA non verranno installati. I pacchetti senza un licenza di tipo EULA verranno installati.

È possibile specificare globalmente ACCEPT_LICENSE all'interno di /etc/portage/make.conf, o specificarla in base ad ogni pacchetti in /etc/portage/package.license.

Per esempio, se si vuol permettere la licenza truecrypt-2.7 per app-crypt/truecrypt, aggiungere la voce seguente al file /etc/portage/package.license:

Codice 4.2: Specificare una licenza truecrypt in package.license

app-crypt/truecrypt truecrypt-2.7

Questo permette l'installazione delle versioni di truecrypt che hanno una licenza truecrypt-2.7, ma non delle versioni che hanno una licenza truecrypt-2.8

Importante: Le licenze sono memorizzate all'interno della directory /usr/portage/licenses, e i gruppi di licenze dentro a /usr/portage/profiles/license_groups. La prima voce di ogni linea avente lettere MAIUSCOLE è il nome del gruppo delle licenze, e ogni voce successiva è una licenza individuale.

I gruppi di licenze definiti in ACCEPT_LICENSE hanno il prefisso @ nel loro nome. Ecco un esempio di un sistema che permette globalmente il gruppo di licenze compatibile con GPL, oltre ad alcuni altri gruppi e singole licenze :

Codice 4.3: ACCEPT_LICENSE in /etc/portage/make.conf

ACCEPT_LICENSE="@GPL-COMPATIBLE @OSI-APPROVED @EULA atheros-hal BitstreamVera"

Se nel proprio sistema si vogliono solamente documentazione e software libero, è consigliabile usare la seguente impostazione:

Codice 4.4: Usare solo licenze libere

ACCEPT_LICENSE="-* @FREE"

In questo caso, "free" ("libero", ndt) viene solitamente definito da FSF e OSI. Qualsiasi pacchetto la cui licenza non soddisfi tali requisiti non potrà essere installata nel proprio sistema.

1.e. Errori durante l'uso del Portage

Slot, virtuals, branche, architetture e profili

Portage è estremamente potente e supporta molte caratteristiche che altri gestori di software omettono. Si vedranno ora altri aspetti del Portage senza andare troppo nei dettagli.

Portage permette la coesistenza di differenti versioni dello stesso pacchetto. A differenza di altre distribuzioni che tendono a chiamare i propri pacchetti con le versioni (come freetype e freetype2), Portage usa una tecnica chiamata SLOT. Un ebuild dichiara un certo SLOT per le proprie versioni. Ebuild con SLOT differenti possono coesistere sullo stesso sistema. Per esempio, il pacchetto freetype ha un ebuild con SLOT="1" e SLOT="2".

Ci sono anche pacchetti che provvedono la stessa funzionalità ma con un'implementazione diversa. Per esempio, metalogd, sysklogd e syslog-ng, tutti gestori di eventi di sistema. Applicazioni che fanno assegnamento sulla disponibilità di un gestore di eventi di sistema, non possono dipendere da uno in particolare. Per esempio, metalogd, come altri sistemi di gestione di eventi, sono tutti un'ottima scelta. Portage permette l'uso di virtuals: ogni logger di sistema è elencato come dipendenza "esclusiva" del servizio di loggind nel pacchetto virtuale logger della categoria virtual, quindi queste applicazioni dipendono dal pacchetto virtual/logger. Una volta installato, il pacchetto tirerà il primo pacchetto menzionato nello stesso, a meno che non sia già installato.(In questo caso il virtual è soddisfatto).

Il software all'interno dell'albero del Portage, può risiedere in differenti branche. Di default il sistema accetta solo pacchetti che Gentoo giudica stabili. Molti nuovi software una volta raccomandati, vengono aggiunti ad una branca di test, il che significa che sarà necessario procedere ad ulteriori verifiche prima di marcarli come stabili. Anche se gli ebuild per tali software sono presenti nell'albero del Portage, non vengono aggiornati prima di raggiungere la branca stabile.

Alcuni software sono disponibili solo per alcune architetture. Oppure il software non gira su altre architetture o ha necessità di essere ulteriormente testato o gli sviluppatori che raccomandano il software non sono in grado di verificare se il pacchetto gira su differenti architetture.

Ogni installazione di Gentoo aderisce ad un certo profilo che contiene tra le altre informazioni, la lista dei pacchetti che sono richiesti affinché un sistema funzioni normalmente.

Pacchetti bloccati

Codice 5.1: Portage avverte riguardo ai pacchetti bloccati (con --pretend)

[blocks B     ] mail-mta/ssmtp (from pkg mail-mta/postfix-2.2.2-r1)

Codice 5.2: Portage avverte riguardo ai pacchetti bloccati (senza --pretend)

!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.

Gli ebuild contengono specifici campi che informano il Portage sulle dipendenze. Ci sono due possibili dipendenze: dipendenze in fase di compilazione dichiarate in DEPEND e dipendenze per l'esecuzione dichiarate in RDEPEND. Quando una di queste dipendenze marca un pacchetto o un virtuale come non compatibile, questo viene bloccato.

Sebbene le versioni recenti di Portage siano sufficentemente avanzate nel risolvere dei semplici blocchi senza l'intervento dell'utente, occasionalmente bisognerà correggerli manualmente, come spiegato qui di seguito.

Per correggere il blocco, si può scegliere tra il non installare il pacchetto o rimuovere prima il pacchetto che causa il conflitto. Nel precedente esempio si può scegliere tra il non installare postfix o rimuovere prima ssmtp.

Si possono anche avere blocchi a livello di versione del pacchetto, come <media-video/mplayer-1.0_rc1-r2. In questo caso, l'aggiornamento ad una versione più recente potrebbe essere sufficiente a rimuovere il blocco.

E' anche possibile che due pacchetti che devono essere ancora installati siano in conflitto tra loro. In questo raro caso, si dovrebbe capire perché si vogliono installare entrambi dato che in molti casi può bastare l'installazione di un solo pacchetto. Se non è questo il caso, aprire un bug sul Gentoo bugtracking system.

Pacchetti mascherati

Codice 5.3: Portage avverte riguardo ai pacchetti mascherati

!!! all ebuilds that could satisfy "bootsplash" have been masked.

Codice 5.4: Portage avverte riguardo ai pacchetti mascherati - la ragione

!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

Quando si desidera installare un pacchetto che non è disponibile per il nostro sistema, si riceverà un errore di pacchetto mascherato. Si dovrà quindi installare un'applicazione differente disponibile per il nostro sistema oppure aspettare finché il pacchetto divenga disponibile. C'è sempre una ragione perché un pacchetto viene mascherato:

~arch keyword significa che l'applicazione non è stata sufficientemente testata per essere inserita nella branca stabile. Aspettare alcuni giorni o alcune settimane e provare nuovamente.
-arch keyword o -* keyword significa che l'applicazione non funziona sulla nostra architettura. Se si crede che il pacchetto funzioni, aprire un bug sul bugzilla di Gentoo.
missing keyword significa che l'applicazione non è ancora stata testata sulla nostra architettura. Chiedere al gruppo che si occupa del porting per l'architettura di testare il pacchetto o testarlo per loro e riportare i risultati sul bugzilla di Gentoo.
package.mask significa che il pacchetto è corrotto, instabile o difettoso ed è stato deliberatamente marcato come non-usare.
profile significa che il pacchetto non è stato trovato appropriatamente nel vostro profilo. Le applicazioni potrebbero danneggiare il sistema se installate o sono solo non compatibili col profilo in uso.
license significa che la licenza del pacchetto non è compatibile con la propria impostazione di ACCEPT_LICENSE. bisogna esplicitamente permettere la licenza o il gruppo nel quale essa è contenuta inserendola in /etc/portage/make.conf o in /etc/portage/package.license. Fare riferimento alla sezione Licenze per ricevere ulteriori informazioni sul loro funzionamento.

Modifiche necessarie alle flag USE

Codice 5.5: Avvisi del Portage sulla richiesta di modifica di flag USE

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

Se --autounmask non è impostato, il messaggio di errore può essere anche mostrato come segue:

Codice 5.6: Errore del Portage sulla richiesta di modifica di flag USE

emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

Questi messaggi appaiono quando si vuole installare un pacchetto che non solo dipende da un altro pacchetto, ma richiede anche che quel pacchetto sia compilato con una particolare flag USE (o insieme di flag USE). Nell'esempio proposto, il pacchetto app-text/feelings ha bisogno di essere compilato con USE="test", ma questa flag USE non impostata nel sistema.

Per risolvere, si può o aggiungere la flag USE alle flag USE globali in /etc/portage/make.conf o impostarla per il pacchetto specifico in /etc/portage/package.use.

Dipendenze omesse

Codice 5.7: Portage avverte riguardo le dipendenze omesse

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r4
!!! Possibly a DEPEND/*DEPEND problem.

L'applicazione che si sta provando ad installare dipende da un altro pacchetto che non è disponibile per il sistema. Controllare su Bugzilla se la cosa è segnalata altrimenti la si può riportare. A meno che non si stia mescolando le branche, questo non dovrebbe accadere ed è perciò un bug.

Nomi di ebuild ambigui

Codice 5.8: Portage avverte circa l'ambiguità di nomi di ebuild

[ Results for search key : listen ]
[ Applications found : 2 ]

*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD

*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of files: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2

!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

L'applicazione che si vuole installare ha un nome che corrisponde con un altro pacchetto. Occorre specificare la categoria. Portage informa sulle scelte possibili.

Dipendenze circolari

Codice 5.9: Portage avverte circa le dipendenze circolari

!!! Error: circular dependencies:

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Due (o più) pacchetti che si vuole installare dipendono l'uno dall'altro e non possono perciò essere installati. Questo è probabilmente un bug del Portage. Provare ad eseguire un rsync e provare nuovamente. Si può anche controllare su bugzilla se è un caso conosciuto oppure no, nel qual caso lo si può riportare.

Scaricamento non riuscito

Codice 5.10: Portage avverte circa un download non riuscito

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

Portage non è riuscito a scaricare i sorgenti per una data applicazione e proverà a proseguire con l'installazione delle altre applicazioni se ci sono. Questo problema può essere causato da un mirror che non è stato sincronizzato appropriatamente o perché l'ebuild punta ad una locazione incorretta. Il server dove risiedono i sorgenti potrebbe anche non essere disponibile per qualche ragione.

Riprovare dopo un'ora e vedere se la situazione persiste.

Protezione dei profili di sistema

Codice 5.11: Portage avverte circa la protezione dei profili

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

Si è richiesto la rimozione di un pacchetto che fa parte del core del sistema. Tale pacchetto è listato nel vostro profile come richiesto e dovrebbe perciò non essere rimosso dal sistema.

Insuccessi nella verifica del digest

A volte durante il tentativo di emergere un pacchetto, si ottiene un errore col seguente messaggio:

Codice 5.12: Insuccesso di verifica del digest

>>> checking ebuild checksums
!!! Digest verification failed:

Questo è un segno che c'è qualche cosa di errato nell'albero del Portage. Spesso è causato da uno sviluppatore che può aver sbagliato l'inserimento del pacchetto nell'albero del Portage.

Quando la verifica del digest fallisce, non provare a ricreare il digest. Eseguire ebuild foo manifest non risolve il problema, ma molto probabilmente lo peggiorerà!

Il suggerimento è di aspettare un'ora o due perché venga sistemato l'albero del Portage. E' probabile che l'errore sia già stato notato, ma occorre un po' di tempo affinché la correzione sia diramata. Durante l'attesa, controllare su Bugzilla per vedere se qualcuno ha riportato il problema. In caso contrario segnalare il bug per il pacchetto oggetto del problema.

Una volta controllato che il bug sia stato corretto, provare ad eseguire nuovamente il sync per ottenere il digest corretto.

Importante: Questo non significa che si possa fare un sync tre volte di seguito! Come specificato nella politica di rsync (visibile quando si esegue emerge --sync), gli utenti che eseguono sync troppo spesso verranno interdetti. Infatti è meglio aspettare il prossimo sync che si è schedulato per evitare il sovraccarico dei server rsync.

2. Flag USE

2.a. Cosa sono le flag USE

L'idea dietro le flag USE

Durante l'installazione di Gentoo (o di altre distribuzioni o comunque di altri sistemi operativi), sono possibili diverse scelte a seconda dell'ambiente di lavoro. Le impostazioni per un server differiscono da quelle per una workstation, così come una stazione per giocare differisce da una per il rendering 3D.

Questo non è vero soltanto per la scelta dei pacchetti da installare, ma anche per le caratteristiche che un certo pacchetto dovrebbe supportare. Ad esempio, se l'uso delle OpenGL non è richiesto, perchè installarle ed abilitarne il supporto nei pacchetti che ne farebbero uso? Per lo stesso motivo, se non si vuole usare KDE, perchè preoccuparsi di compilare i pacchetti col supporto per KDE se questi pacchetti funzionano tranquillamente senza?

Per aiutare gli utenti a decidere cosa installare/attivare e cosa no, è necessario che l'utente specifichi il proprio ambiente nel modo più semplice. Questo forza l'utente a decidere cosa desidera realmente e facilita Portage, il sistema per la gestione dei pacchetti, a prendere le decisioni appropriate.

Definizione delle flag USE

Concettualmente un flag USE è una parola chiave che racchiude l'idea di supporto e di informazione sulla dipendenza. Se si definisce una certa flag USE, si indica a Portage la volontà di avere il supporto per la parola chiave scelta. Questo, naturalmente, altera anche le informazioni sulle dipendenze per un dato pacchetto.

Prendendo come esempio la parola chiave kde, si ottiene questo comportamento: se questa parola chiave non è presente nella variabile USE, tutti i pacchetti che hanno il supporto opzionale per KDE vengono compilati senza tale supporto; conseguentemente tutti i pacchetti cha hanno una dipendenza opzionale con KDE vengono installati senza le relative librerie KDE. Se invece la parola chiave kde è stata definita, questi pacchetti vengono compilati col supporto di KDE e di conseguenza anche le sue librerie vengono installate come dipendenze.

Definendo in maniera corretta le parole chiave si avrà a disposizione un sistema perfettamente ritagliato sulle proprie esigenze.

Quali sono le flag USE utilizzabili

Ci sono due tipi di flag USE: globali e locali.

Una flag USE globale è usata da alcuni pacchetti a livello di sistema. Questo è ciò che molti utenti vedono come flag USE.
Una flag USE locale è usata da un singolo pacchetto per prendere decisioni specifiche sul pacchetto stesso.

Una lista di flag USE globali disponibili può essere trovata online o localmente in /usr/portage/profiles/use.desc.

Un elenco delle flag USE locali disponibili può essere trovata in /usr/portage/profiles/use.local.desc.

2.b. Usare le flag USE

Dichiarare flag USE permanenti

Seguono le informazioni su come dichiarare le flag USE in modo permanente.

Come precedentemente menzionato, tutte le flag USE sono dichiarate attraverso la variabile USE. Per facilitare la ricerca e la scelta delle flag USE, viene fornita una configurazione USE predefinita. Questa configurazione è una collezione di flag USE che dovrebbe essere comunemente usata dagli utenti Gentoo ed è dichiarata nei file make.defaults che fanno parte del proprio profilo.

Il collegamento simbolico /etc/portage/make.profile punta al profilo di sistema utilizzato. Ogni profilo lavora insieme con un altro profilo superiore, ed il risultato è la somma di tutti i profili. Quello superiore è quello base, (/usr/portage/profiles/base).

Dare una occhiata alle impostazioni predefinite per il profilo 10-0:

Codice 2.1: Somma delle variabili USE make.defaults per il profilo 10.0

(Questo esempio è la somma delle impostazioni in base, default/linux, default/linux/x86 e default/linux/x86/10.0)
USE="a52 aac acpi alsa branding cairo cdr dbus dts dvd dvdr emboss encode exif
     fam firefox flac gif gpm gtk hal jpeg lcms ldap libnotify mad mikmod mng
     mp3 mp4 mpeg ogg opengl pango pdf png ppds qt3support qt4 sdl spell
     startup-notification svg tiff truetype vorbis unicode usb X xcb x264 xml
     xv xvid"

Come è evidente, questa variabile contiene già una serie di parole chiave. Non alterare nessun file make.defaults per adattare la variabile USE alle proprie esigenze in quanto le modifiche a questi file vengono sovrascritte ad ogni aggiornamento del Portage.

Per cambiare la configurazione predefinita, è necessario aggiungere o rimuovere parole chiave dalla variabile USE e questo può essere fatto globalmente definendo la variabile USE nel file /etc/portage/make.conf. In questa variabile è possibile aggiungere le flag USE aggiuntive richieste o rimuoverne di non richieste nel qual caso occorre anteporre alla parola chiave il segno meno ("-").

Per esempio, per rimuovere il supporto per KDE e QT ed aggiungere il supporto per ldap, può essere definita la seguente dichiarazione della variabile USE in /etc/portage/make.conf:

Codice 2.2: Un esempio di dichiarazione USE in /etc/portage/make.conf

USE="-kde -qt4 ldap"

Dichiarare flag USE per pacchetti individuali

Qualche volta si desidera dichiarare una determinata flag USE per una (o per più) applicazioni ma non per tutto il sistema. Per fare questo, si deve creare la directory /etc/portage (se ancora non esiste) e modificare /etc/portage/package.use. Solitamente è un file singolo, ma può essere anche una directory: vedere man portage per ulteriori informazioni. Il seguente esempio presuppone che package.use sia un file singolo.

Per esempio, se non si vuole che berkdb sia supportato globalmente, ma lo si desidera per mysql, si dovrebbe aggiungere:

Codice 2.3: Esempio di /etc/portage/package.use

dev-db/mysql berkdb

Si possono naturalmente anche disabilitare le flag USE per una certa applicazione. Per esempio, se non si desidera il supporto java in PHP:

Codice 2.4: Secondo esempio di /etc/portage/package.use

dev-php/php -java

Dichiarare flag USE temporanee

In certi casi è utile dichiarare flag USE una sola volta. Invece di modificare /etc/portage/make.conf due volte (una per la modifica e l'altra per riportare il tutto all'origine) è possibile dichiarare la variabile USE come fosse una variabile ambiente. Ricordarsi che, quando si ri-emerge o si aggiorna questa applicazione (in modo esplicito o parte di un aggiornamento del sistema), i cambiamenti saranno persi!

Segue un esempio di come rimuovere temporaneamente il supporto java durante l'installazione di mozilla.

Codice 2.5: Usare USE come una variabile ambiente

# USE="-java" emerge seamonkey

Precedenza

Naturalmente esiste un ordine definito riguardante la priorità delle dichiarazioni nelle configurazioni USE. Non è necessario dichiarare USE="-java" solo per vedere se "java" è ancora usato per una impostazione con un'alta priorità. L'ordine di precedenza per le impostazioni di USE è il seguente (i primi hanno la priorità più bassa):

USE predefinita dichiarata nei file make.defaults parte del proprio profilo
Configurazione USE definita dall'utente in /etc/portage/make.conf
Configurazione USE definita dall'utente in /etc/portage/package.use
Dichiarazione USE definita dall'utente come variabile ambiente

Per vedere la configurazione finale di USE che viene usata da Portage, eseguire emerge --info che visualizzerà una lista di tutte le variabili rilevanti (incluso la variabile USE) col valore usato da Portage.

Codice 2.6: Eseguire emerge --info

# emerge --info

Adattare il proprio sistema alle nuove flag USE

Se si sono cambiate le proprie flag USE e si desidera aggiornare l'intero sistema, affinchè utilizzi le nuove flag USE, si può usare l'opzione --newuse di emerge:

Codice 2.7: Ricompilare il sistema

# emerge --update --deep --newuse world

Dopo, eseguire il depclean di Portage per rimuovere le dipendenze condizionali che erano state emerse nel vecchio sistema, ma che sono diventate obsolete con l'uso delle nuove flag USE.

Avvertenza: Eseguire emerge --depclean è una operazione pericolosa e dovrebbe essere fatta con cura. Ricontrollare la lista fornita di pacchetti "obsoleti" per assicurarsi che non si rimuovano pacchetti di cui si ha bisogno. Nell'esempio seguente si è aggiunto -p per avere solo la lista dei pacchetti senza rimuoverli.

Codice 2.8: Rimuovere pacchetti obsoleti

# emerge -p --depclean

Al termine del processo di depclean, eseguire revdep-rebuild per ricompilare le applicazioni che sono collegate in modo dinamico agli oggetti condivisi forniti dai pacchetti rimossi. revdep-rebuild è parte del pacchetto gentoolkit; non dimenticarsi di emergerlo prima.

Codice 2.9: Eseguire revdep-rebuild

# revdep-rebuild

Quando tutto è finito, il sistema userà le nuove flag USE.

2.c. Flag USE specifiche per pacchetto

Visualizzare le flag USE disponibili

Ecco l'esempio di seamonkey per vedere quali flag sono disponibili. Per questo usare emerge con le opzioni --pretend e --verbose:

Codice 3.1: Vedere le flag USE utilizzate

# emerge --pretend --verbose seamonkey
These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild   R   ] www-client/seamonkey-1.0.7  USE="crypt gnome java -debug -ipv6
-ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznopango
-moznoroaming -postgres -xinerama -xprint" 0 kB

emerge non è il solo strumento che fa questo, infatti ci sono strumenti dedicati alla gestione delle informazioni sui pacchetti come equery che fa parte del pacchetto gentoolkit. Occorre prima installare gentoolkit:

Codice 3.2: Installare gentoolkit

# emerge gentoolkit

Ora è possibile usare equery con l'argomento uses per avere la lista dei flag USE usati da un dato pacchetto. Ad esempio per il pacchetto gnumeric:

Codice 3.3: Usare equery per vedere le flag USE utilizzate

# equery --nocolor uses =gnumeric-1.6.3 -a
[ Searching for packages matching =gnumeric-1.6.3... ]
[ Colour Code : set unset ]
[ Legend : Left column  (U) - USE flags from make.conf              ]
[        : Right column (I) - USE flags packages was installed with ]
[ Found these USE variables for app-office/gnumeric-1.6.3 ]
 U I
 - - debug  : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml .
 + + gnome  : Adds GNOME support
 + + python : Adds support/bindings for the Python language
 - - static : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically

3. Caratteristiche di Portage

3.a. Caratteristiche di Portage

Portage ha molte altre caratteristiche che rendono Gentoo ancora migliore. Molte di queste comprendono strumenti software che migliorano le prestazioni, l'affidabilità, la sicurezza, ...

Per abilitare o disabilitare alcune caratteristiche di Portage, bisogna modificare la variabile FEATURES di /etc/portage/make.conf, che contiene varie keyword separate da spazi bianchi. In molti casi si devono installare ulteriori strumenti sui quali sono basate le caratteristiche.

Non sono elencate qui tutte le caratteristiche che Portage supporta. Per una descrizione completa si veda la manpage make.conf:

Codice 1.1: Vedere la manpage make.conf

$ man make.conf

Per scoprire quali sono le caratteristiche di default, eseguire emerge --info e cercare la variabile FEATURES o eseguire un grep:

Codice 1.2: Scoprire quali caratteristiche sono già impostate

$ emerge --info | grep FEATURES

3.b. Compilazione Distribuita

Usare distcc

distcc è un programma per distribuire la compilazione su diverse macchine, non necessariamente identiche, su una rete. Il client distcc trasmette tutte le informazioni necessarie ai server distcc che vengono resi disponibili tramite l'esecuzione di distccd, in modo che possano compilare parte del codice sorgente per il client. Il risultato è un tempo di compilazione inferiore.

E' possibile trovare più informazioni su distcc (e informazioni su come deve funzionare con Gentoo) nella nostra Documentazione Gentoo su distcc.

Installare distcc

Distcc include un strumento grafico per tenere sotto controllo i task che il computer sta inviando per la compilazione. Se si usa Gnome si inserisca 'gnome' nella variabile USE. Se non si usa Gnome e si desidera comunque utilizzare il monitor, si inserisca 'gtk' nella variabile USE.

Codice 2.1: Installare distcc

# emerge distcc

Attivare il supporto di Portage

Aggiungere distcc alla variabile FEATURES in /etc/portage/make.conf. Modificare la variabile MAKEOPTS a proprio piacimento. In "-jX" la X è il numero di CPU che eseguono distccd (incluso l'host attuale) più uno, ma si potrebbero avere migliori risultati con altri numeri.

Eseguire distcc-config e impostare la lista di server distcc disponibili. Per esempio si assume che i server distcc disponibili sono 192.168.1.102 (l'host attuale), 192.168.1.103 e 192.168.1.104 (due host remoti):

Codice 2.2: Configurare distcc per usare tre server disponibili DistCC

# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Non dimenticarsi di eseguire anche il demone distccd:

Codice 2.3: Avviare il demone distccd

# rc-update add distccd default
# /etc/init.d/distccd start

3.c. Cache per la compilazione

Cosa è ccache

ccache è un veloce gestore cache per il compilatore. Dopo aver compilato un programma, esso immagazzina i risultati intermedi, in modo che se si dovesse ricompilare lo stesso programma, il tempo di compilazione sia notevolmente ridotto. La prima volta che si esegue ccache, la sua esecuzione sarà molto più lenta ad una normale compilazione. Ricompilazioni sequenziali dovrebbero invece essere più veloci. ccache è utile solamente se si sta ricompilando più volte la stessa applicazione; ciò è praticamente utile solo agli sviluppatori software.

Per maggiori informazioni su ccache, è possibile consultare la homepage di ccache.

Avvertenza: È risaputo che ccache causa numerosi fallimenti nella compilazione. Talvolta ccache preserva oggetti di codice inutili o file corrotti, che portano alla mancata compilazione del pacchetto. Se ciò accade (se si ricevono errori come "File not recognized: File truncated"), provare a ricompilare l'applicazione disabilitando ccache ((FEATURES="-ccache" in /etc/portage/make.conf) prima di aprire un bug report. A meno che non si debbano eseguire lavori come sviluppatore, non abilitare ccache.

Installare ccache

Per installare ccache, eseguire emerge ccache:

Codice 3.1: Installare ccache

# emerge ccache

Attivare il supporto di Portage

Aprire /etc/portage/make.conf e aggiungere ccache alla variabile FEATURES. Poi, aggiungere una nuova variabile chiamata CCACHE_SIZE e impostarla a "2G":

Codice 3.2: Editare CCACHE_SIZE in /etc/portage/make.conf

CCACHE_SIZE="2G"

Per controllare se ccache funziona, si possono vedere le statistiche. Portage usa una diversa directory home ccache e si deve impostare la variabile CCACHE_DIR:

Codice 3.3: Esaminare le statistiche di ccache

# CCACHE_DIR="/var/tmp/ccache" ccache -s

Il /var/tmp/ccache è la directory home di default di Portage; se si desidera cambiare questa impostazione modificare la variabile CCACHE_DIR in /etc/portage/make.conf.

Se si esegue ccache, si usa la posizione di default di ${HOME}/.ccache, ed è per questo che si deve impostare la variabile CCACHE_DIR quando si cercano le statistiche (Portage) ccache.

Usare ccache per la compilazione di C non-Portage

Se si desidera usare ccache per compilazioni non-Portage, si aggiunga /usr/lib/ccache/bin all'inizio della variabile PATH (prima di /usr/bin). Può essere fatto modificando .bash_profile nella directory home del proprio utente. Usare .bash_profile è un modo per definire la variabile PATH.

Codice 3.4: Modificare .bash_profile

PATH="/usr/lib/ccache/bin:/opt/bin:${PATH}"

3.d. Supporto per pacchetti binari

Creare pacchetti precompilati

Portage supporta l'installazione di pacchetti precompilati. Anche se Gentoo non fornisce pacchetti precompilati (tranne GRP), Portage può essere informato dei pacchetti precompilati.

Per creare un pacchetto precompilato si può usare quickpkg se il pacchetto è già installato sul sistema, o emerge con le opzioni --buildpkg o --buildpkgonly.

Se si desidera che Portage crei pacchetti precompilati di ogni singolo pacchetto che si installa, aggiungere buildpkg alla variabile FEATURES.

Supporto più esteso per le impostazioni sui pacchetti precompilati può essere ottenuto con il catalyst. Per ulteriori informazioni sul catalyst leggere le Domande frequenti su Catalyst.

Installare pacchetti precompilati

Anche se Gentoo non li fornisce, si può creare un repository centrale dove mettere i pacchetti precompilati. Se si desidera usare questo repository, si deve far puntare la variabile PORTAGE_BINHOST ad esso. Per esempio, se i pacchetti precompilati sono su ftp://buildhost/gentoo:

Codice 4.1: Impostare PORTAGE_BINHOST in /etc/portage/make.conf

PORTAGE_BINHOST="ftp://buildhost/gentoo"

Quando si desidera installare un pacchetto precompilato, si deve aggiungere l'opzione --getbinpkg al comando emerge accanto all'opzione --usepkg. Il primo (--getbinpkg) dice a emerge di scaricare il pacchetto precompilato dal server precedentemente definito mentre il secondo (--usepkg) chiede a emerge di cercare di installare il pacchetto precompilato prima di scaricare i sorgenti e compilarlo.

Per esempio, per installare gnumeric con i pacchetti precompilati:

Codice 4.2: Installare il pacchetto precompilato gnumeric

# emerge --usepkg --getbinpkg gnumeric

Più informazioni sulle opzioni di emerge con i pacchetti precompilati possono essere trovate nella manpage emerge:

Codice 4.3: Vedere manpage emerge

$ man emerge

3.e. Scaricare file

Scaricamenti paralleli

Quando si stanno emergendo una serie di pacchetti, Portage può scaricare i file sorgenti del prossimo pacchetto nella lista, anche se sta compilando un altro pacchetto. Per usare questa opzione, aggiungere "parallel-fetch" alla propria FEATURES. Da notare che questa feature è già attiva, quindi non si deve specificatamente abilitarla.

Userfetch

Quando Portage è eseguito da root, FEATURES="userfetch" permette a Portage di levarsi dai privilegi di root mentre scarica i sorgenti di un pacchetto. Questo è un piccolo miglioramento di sicurezza.

3.f. Prelevare snapshot del Portage convalidati

Come amministratori del sistema, si può decidere di aggiornare il proprio albero del Portage solo attraverso uno snapshot del Portage convalidato crittograficamente rilasciato dall'infrastruttura Gentoo. Questo assicura che che nessun mirror rsync malevolo aggiunga codice o pacchetti indesiderati all'albero che si sta scaricando.

Per configurare Portage, si deve prima creare un deposito sicuro dove scaricare e accettare le chiavi fornite dall'Infrastruttura Gentoo responsabile per la firma degli snapshot dell'albero di Portage. Naturalmente, se si vuole farlo, è possibile convalidare questa chiave GPG come indicato nelle appropriate indicazioni (ad esempio verificando l'impronta. Puoi trovare la lista delle chiavi GPG usate dal team di release engineering sulla loro pagina.

Codice 6.1: Creare un deposito sicuro per Portage

# mkdir -p /etc/portage/gpg
# chmod 0700 /etc/portage/gpg
(... Sostituire le chiavi con quelle menzionate nella pagina release 
engineering ...)
# gpg --homedir /etc/portage/gpg --keyserver subkeys.pgp.net --recv-keys 0x239C75C4 0x96D8BF6D
# gpg --homedir /etc/portage/gpg --edit-key 0x239C75C4 trust
# gpg --homedir /etc/portage/gpg --edit-key 0x96D8BF6D trust

Successivamente, modificare /etc/portage/make.conf abilitando il supporto per la convalida degli snapshot di Portage firmati (usando FEATURES="webrsync-gpg") e disabilitando l'aggiornamento di Portage attraverso il metodo ordinario emerge --sync.

Codice 6.2: Aggiornare Portage per la convalida degli snapshot firmati

FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/etc/portage/gpg"
SYNC=""

Fatto. La prossima volta che verrà eseguito emerge-webrsync, solo gli snapshot con una firma valida verranno incorporati nel proprio sistema.

4. Initscripts

4.a. Runlevel

Avviare il sistema

All'avvio del sistema, ci sono molte scritte che scorrono e il testo è il medesimo ad ogni avvio. La sequenza di tutte queste azioni viene chiamata sequenza di boot ed è (più o meno) definita staticamente.

Per prima cosa, il boot loader carica l'imagine del kernel, definita nella configurazione in memoria, dopo di che dice alla CPU di eseguire il kernel. Quando il kernel è caricato e in esecuzione, inizializza tutte le strutture e i lavori specifici del kernel ed avvia il processo init.

Questo processo si assicura che tutti i filesystem (definiti in /etc/fstab) siano montati e pronti per l'uso. Poi esegue alcuni script situati in /etc/init.d, che avviano i servizi necessari per un corretto avvio del sistema.

Alla fine, quando tutti gli script sono eseguiti, init attiva i terminali (nella maggior parte dei casi solo le console virtuali che sono nascoste in Alt-F1, Alt-F2, ecc.) attaccandogli un processo chiamato agetty. Questo processo per prima cosa si assicura che sia possibile eseguire il login su questi terminali eseguendo login.

Init Script

Ora init non esegue gli script in /etc/init.d casualmente. Inoltre, non lancia tutti gli script in /etc/init.d, ma solo quelli che gli è stato detto di eseguire. Decide che script eseguire guardando in /etc/runlevels.

Prima, init esegue tutti gli script da /etc/init.d che hanno un link simbolico in /etc/runlevels/boot. Solitamente, esegue gli script in ordine alfabetico, ma alcuni di essi hanno delle informazioni di dipendenze all'interno, che dicono al sistema che un altro script deve essere avviato prima che possa essere avviati loro stessi.

Quando tutti gli script refenziati in /etc/runlevels/boot sono stati eseguiti, init continua eseguendo gli script che hanno un collegamento simbolico in /etc/runlevels/default. Ancora, usa l'ordine alfabetico per decidere che script avviare prima, a meno che lo script non abbia dipendenze, nel qual caso l'ordine viene cambiato per fornire una valida sequenza di boot.

Come lavora init

Certamente init non decide tutto da solo. Ha bisogno di un file di configurazione che specifica quali azioni debba eseguire. Questo file di configurazione è /etc/inittab.

La prima azione di init è di montare tutti i filesystem. Questo è definito nella seguente linea di /etc/inittab:

Codice 1.1: La linea di inizializzazione del sistema in /etc/inittab

si::sysinit:/sbin/rc sysinit

Questa linea dice a initche deve eseguire /sbin/rc sysinit per inizializzare il sistema. Lo script /sbin/rc si occupa dell'inizializzazione, init infatti non fa molto: esso delega altri compiti, come l'inizializzazione del sistema, ad un'altro processo.

In secondo luogo init esegue gli script che hanno un collegamento in /etc/runlevels/boot. Questo è definito dalla seguente linea:

Codice 1.2: Inizializzazione del sistema, continua

rc::bootwait:/sbin/rc boot

Ancora lo script rc provvede ai compiti necessari. Notare che l'opzione passata a rc (boot) è la stessa della sottodirectory /etc/runlevels.

Ora init controlla il suo file di configurazione per vedere quale runlevel deve eseguire. Per deciderlo, legge la seguente linea da /etc/inittab:

Codice 1.3: La linea initdefault

id:3:initdefault:

In questo caso (che la maggioranza di utenti Gentoo usa), l'id del runlevel è 3. Usando questa informazione, init vede che deve avviare il runlevel 3:

Codice 1.4: La definizione del runlevel

l0:0:wait:/sbin/rc shutdown
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

La linea che definisce il livello 3, ancora, usa lo script rc per avviare il servizio (ora con argomento default). L'argomento di rc è ancora lo stesso della sottodirectory in /etc/runlevels.

Quando rc ha finito, init decide quale console virtuale attivare e quali comandi devono essere eseguiti su ciascuna console:

Codice 1.5: Definizione delle console virtuali

c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Cos'è un runlevel?

Init usa uno schema numerico per decidere quale runlevel attivare. Un runlevel è uno stato nel quale il sistema viene avviato e contiene una collezione di script (runlevel script o initscript) che devono essere eseguiti quando si entra o si lascia un runlevel.

In Gentoo, ci sono sette runlevel definiti: tre runlevel interni, e quattro runlevel definiti dall'utente. I runlevel interni si chiamano sysinit, shutdown e reboot e fanno esattamente quello che i nomi implicano: inizializzano il sistema, spengono il sistema e riavviano il sistema.

I runlevel definiti dall'utente sono delle sottodirectory di /etc/runlevels: boot, default, nonetwork e single. Il runlevel boot avvia tutti i servizi necessari al sistema che tutti gli altri runlevel usano. I rimanenti tre differiscono per i servizi avviati: default viene usato per le operazioni di tutti i giorni, nonetwork è usato in caso non sia necessaria alcuna connettività, e single viene usato per riparare il sistema.

Lavorare con gli script di Init

Gli script che il processo rc avvia sono chiamati init script. Ogni script in /etc/init.d può essere eseguito con gli argomenti start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme o broken.

Per avviare, fermare o riavviare un servizio (e tutti i servizi dipendenti), vengono usati start, stop e restart:

Codice 1.6: Avviare Postfix

# /etc/init.d/postfix start

Nota: Solo i servizio necessari al servizio dato saranno fermati o riavviati. Gli altri servizi dipendenti (quelli che usa ma non gli sono necessari) non vengono toccati.

Per fermare un servizio, ma non i servizi che dipendono da lui si può usare l'argomento pause:

Codice 1.7: Fermare Postfix ma mantenere in esecuzione i servizi dipendenti

# /etc/init.d/postfix pause

Per vedere un servizio in che stato si trova (started, stopped, paused, ...) si può usare l'argomento status:

Codice 1.8: Informazioni di stato per postfix

# /etc/init.d/postfix status

Se le informazioni di stato dicono che un servizio è in esecuzione, ma non è così, si può fare il reset delle informazioni di stato a "stopped" con l'argomento zap:

Codice 1.9: reset delle informazioni di stato per postfix

# /etc/init.d/postfix zap

Per sapere quali dipendenze ha un servizio si può usare iuse o ineed. Con ineed vengono mostrati i servizi veramente necessari per il corretto funzionamento del servizio. iuse invece mostra i servizi che vengono usati ma non sono necessari al servizio per il corretto funzionamento.

Codice 1.10: Richiedere la lista di tutti i servizi da cui Postfix dipende

# /etc/init.d/postfix ineed

In modo simile si può chiedere la lista dei servizi che dipendono da lui (needsme) o possono usarlo

Codice 1.11: Richiedere la lista dei servizi che richiedono Postfix

# /etc/init.d/postfix needsme

Infine, si possono chiedere quali dipendenze, richieste da un servizio, sono mancanti:

Codice 1.12: Richiedere la lista delle dipendenze mancanti per Postfix

# /etc/init.d/postfix broken

4.b. Lavorare con rc-update

Cos'è rc-update?

Il sistema di init in Gentoo usa un albero di dipendenze per decidere quali dipendenze vanno avviate prima. Essendo un compito tedioso da eseguire manualmente c'è uno strumento che rende semplice l'amministrazione dei runlevel e init script.

Con rc-update si possono aggiungere e rimuovere init script da un runlevel. Lo strumento rc-update automaticamente interroga depscan.sh per ricostruire l'albero delle dipendenze.

Aggiungere e rimuovere servizi

Lo script rc-update richiede un secondo argomento che definisce l'azione: add, del o show.

Per aggiungere o rimuovere un'init script, bisogna passare a rc-update l'argomento add o del, seguito dallo script di init e dal runlevel. Per esempio:

Codice 2.1: Rimuovere Postfix dal runlevel default

# rc-update del postfix default

Il comando rc-update -v show mostra tutti gli script di init disponibili e in quale runlevel vengono eseguiti:

Codice 2.2: Ricevere informazioni sugli init script

# rc-update -v show

È possibile anche usare rc-update show (senza -v) per vedere solamente gli script di init abilitati e il loro runlevel.

4.c. Configurare i servizi

Perchè una configurazione aggiuntiva?

Gli Init script possono essere complessi. Qui non si è interessati a far modificare direttamente gli init script, dato che sono piuttosto proni a errori. È comunque importante saper configurare bene un servizio, ad esempio per per dare più opzioni al servizio stesso.

Un secondo motivo è di avere la configurazione al di fuori dell'init script per aggiornare gli init script senza preoccuparsi di perdere i cambiamenti alla configurazione.

La directory /etc/conf.d

Gentoo fornisce un modo semplice per configurare i servizi: ogni init script che può esser configurato ha un file in /etc/conf.d. Per esempio, l'init script di apache2 (chiamato /etc/init.d/apache2) ha un file di configurazione chiamato /etc/conf.d/apache2, che contiene le opzioni che si vogliono passare al server Apache 2 quando esso viene avviato:

Codice 3.1: Variabili definite in /etc/conf.d/apache2

APACHE2_OPTS="-D PHP5"

I file di configurazione contengono variabili e solo quello (tipo /etc/portage/make.conf), e rendono davvero facile configurare un servizio. Permettono inoltre di aggiungere molte informazioni sulle variabili (come commenti).

4.d. Scrivere Init Scripts

È necessario?

No. Scrivere init script non è solitamente necessario dato che Gentoo fornisce init script pronti all'uso per ogni servizio. Comunque, si potrebbe installare un servizio senza usare Portage, nel qual caso probabilmente è necessario creare un init script.

È consigliabile non usare init script forniti dal servizio se non sono scritti esplicitamente per Gentoo: gli init script di Gentoo non sono compatibili con quelli usati dalle altre distribuzioni!

Layout

Il layout di base di un init script è mostrato sotto.

Codice 4.1: Layout di base di un init script

#!/sbin/runscript

depend() {
  (Informazioni di dipendenza)
}

start() {
  (Comando necessario per avviare un servizio)
}

stop() {
  (Comando necessario per fermare un servizio)
}

Ogni init script richiede che la funzione start() sia definita. Tutte le altre sezioni sono opzionali.

Dipendenze

Ci sono due tipi di impostazioni simili alle dipendenze che possono influenzare l'avvio o la sequenza degli script: use e need. Oltre a queste due, ci sono altri due metodi che influenzano l'ordine di esecuzione, chiamati before e after. Gli ultimi due non sono delle vere dipendenze - non provocano il fallimento dell'init script originale se quello indicato non è programmato per avviarsi (o fallisce l'avvio).

L'impostazione use informa il sistema init che lo script usa le funzionalità offerte dallo script indicato, ma non dipende direttamente da quello. Un buon esempio potrebbe essere use logger o use dns. Se questi servizi sono disponibili, verranno adeguatamente utilizzati, ma se non si ha un logger o un server DNS i servizi funzioneranno ugualmente. Se i servizi esistono, allora verranno avviati prima dello script che ne fa uso.
L'impostazione need è una vera dipendenza. Significa che lo script che ha bisogno di un altro script non partirà prima che l'altro si sia avviato correttamente. Inoltre, se l'altro script verrà riavviato, allora anche lo script che ne ha bisogno verrà riavviato.
Quando si usa before, lo script verrà avviato prima di quello indicato se quello indicato fa parte del livello di init. Quindi, im init script xdm che dichiara before alsasound partirà prima dello script alsasound, ma solo se alsasound è programmato per avviarsi nello stesso livello di init. Se alsasound non è programmato per avviarsi, allora questa impostazione non ha effetto e xdm verrà avviato quando il sistema init lo riterrà appropriato.
In modo analogo, after informa il sistema init che lo script dovrà essere avviato dopo quello indicato, se quello indicato fa parte del livello di init. Altrimenti l'impostazione non ha effetto e lo script verrà avviato quando il sistema init lo riterrà appropriato.

Dovrebbe essere chiaro da quanto scritto sopra che need è l'unica "vera" dipendenza, in quanto determina se lo script verrà avviato o meno. Tutte le altre sono semplici indicazioni al sistema init per chiarire in quale ordine gli script devono (o dovrebbero) essere eseguiti.

Ora, se si osservano i molti init script disponibili in Gentoo, si noterà che alcuni hanno dipendenze rispetto a cose che non sono init script. Chiamiamo queste "cose" dipendenze virtuali.

Una dipendenza virtuale è una dipendenza che fornisce un servizio, ma non è fornita solo da quel servizio. L'init script può dipendere da logger di sistema, ma possono essercene molti altri disponibili (metalogd, syslog-ng, sysklogd, ...). Dato che non è possibile mettere need per ognuno di loro (nessun sistema ha tutti questi logger di sistema installati e in esecuzione) ci si assicura che tutti questi servizi forniscano una dipendenza virtuale.

Ora verranno esaminate le informazioni relative alle dipendenze del servizio postfix.

Codice 4.2: Informazioni di dipendenze per Postfix

depend() {
  need net
  use logger dns
  provide mta
}

Com'è possibile vedere, il servizio postfix:

richiede la dipendenza (virtuale) net(che è fornita, per esempio, da /etc/init.d/net.eth0)
usa la dipendenza (virtuale) logger (che è fornita per esempio, da /etc/init.d/syslog-ng)
usa la dipendenza (virtuale) dns (che è fornita, per esempio da /etc/init.d/named)
fornisce la dipendenza (virtuale) mta (che è comune a tutti i mail server)

Controllare l'ordine

Come descritto nella sezione precedente, si può istruire il sistema init sull'ordine da seguire per avviare (o fermare) gli init script. L'ordine è governato da entrambe le use e need, ma anche dalle impostazioni di ordinamento before e after. Poich* queste impostazioni sono state già descritte in precedenza, prendiamo il servizio Portmap come esempio di init script.

Codice 4.3: La funzione depend() nel servizio Portmap

depend() {
  need net
  before inetd
  before xinetd
}

Si può anche usare "*" per selezionare tutti i servizi nello stesso runlevel, ma non è consigliabile.

Codice 4.4: Eseguire un init script come primo script nel runlevel

depend() {
  before *
}

Se il servizio deve scrivere su dischi locali, dovrebbe aver bisogno di localmount. Se non mette niente in /var/run, come un pidfile, allora dovrebbe partire dopo bootmisc:

Codice 4.5: Esempio di funzione depend()

depend() {
  need localmount
  after bootmisc
}

Funzioni Standard

Dopo la funzione depend(), è necessario definire la funzione start(). Questa contiene tutti i comandi necessari ad inizializzare il servizio. È consigliabile usare le funzioni ebegin e eend per informare l'utente su cosa sta accadendo:

Codice 4.6: Esempio di funzione start()

start() {
  if [ "${RC_CMD}" = "restart" ];
  then
    # Aggiungere qualcosa nel caso che un restart richieda più che stop, start
  fi
  ebegin "Starting my_service"
  start-stop-daemon --start --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Sia --exec che --pidfile dovrebbero essere usati nelle funzioni start e stop. Se il servizio non crea un pidfile, usare se possibile --make-pidfile. Altrimenti non usare pidfile. Si può anche aggiungere --quiet alle opzioni start-stop-daemon, ma non è raccomandato. L'uso di --quiet potrebbe ostacolare il debugging se il servizio non si avvia correttamente.

Un'altra impostazione di rilievo utilizzata nell'esempio precedente è il controllo dela varaibile RC_CMD. A differenza del sistema init precedente, il nuovo sistema openrc non supporta una funzione specifica per il restart. Di conseguenza, lo script ha bisogno di controllare il contenuto di RC_CMD per vedere se una funzione (che sia start() o stop()) deve essere invocata come parti di un restart o meno.

Nota: Assicurarsi che --exec chiami un servizio e non uno script shell che lancia servizi e esce: è a questo che serve l'init script.

Se si ha bisogno di più esempi della funzione start(), leggere il codice sorgente degli init script disponibili nella propria directory /etc/init.d.

Un'altra funzione che può essere definita è stop(). Non si è obbligati a definire questa funzione! Il sistema di init è abbastanza intelligente da inserire da solo questa funzione se si usa start-stop-daemon.

Ecco une esempio di una funzione stop():

Codice 4.7: Esempio funzione stop()

stop() {
  ebegin "Stopping my_service"
  start-stop-daemon --stop --exec /path/to/my_service \
    --pidfile /path/to/my_pidfile
  eend $?
}

Se il servizio esegue qualche altro script (per esempio bash, python o perl), e questo script più avanti cambia i nomi (per esempio da foo.py a foo), si deve aggiungere --name a start-stop-daemon. Si deve specificare il nome che sarà cambiato dallo script. In questo esempio, un servizio fa partire foo.py, che cambia nome in foo:

Codice 4.8: Un servizio che fa partire lo script foo

start() {
  ebegin "Starting my_script"
  start-stop-daemon --start --exec /path/to/my_script \
    --pidfile /path/to/my_pidfile --name foo
  eend $?
}

start-stop-daemon ha una eccellente pagina man per vedere maggiori opzioni:

Codice 4.9: Pagina Man di start-stop-daemon

$ man start-stop-daemon

La sintassi di init script di Gentoo è basata su POSIX così si possono usare costrutti compatibili sh nei propri init script. Tenere altri costrutti come bash specifici, al di fuori dallo script di init per essere sicuri che lo script funzioni indipendentemente dai cambi che Gentoo potrebbe fare sul proprio sistema di init.

Aggiungere opzioni personalizzate

Se si ha bisogno di maggiori opzioni negli init script, si può aggiungere l'opzione alla variabile extra_commands, e creare una funzione con lo stesso nome dell'opzione. Per esempio, per il supporto di un'opzione chiamata restartdelay:

Codice 4.10: Aggiungere l'opzione restartdelay

extra_commands="restartdelay"

restartdelay() {
  stop
  sleep 3    # Attendere 3 secondi prima di avviarsi nuovamente
  start
}

Importante: La funzione restart() non può essere sovrascritta in openrc!

Variabili di configurazione dei servizi

Non occorre fare nulla per supportare un file di configurazione in /etc/conf.d: se l'init script viene eseguito, vengono automaticamente processati i seguenti file (e per esempio le variabili sono pronte per essere usate):

/etc/conf.d/<vostro init script>
/etc/conf.d/basic
/etc/rc.conf

Inoltre, se l'init script fornisce una dipendenza virtuale (come net), viene processato anche il file associato a questa dipendenza (come /etc/conf.d/net).

4.e. Cambiare il comportamento del Runlevel

Può effettivamente essere utile?

Molti utenti di portatili conoscono la situazione: a casa si ha bisogno di avviare net.eth0 ma non si vuole avviare net.eth0 quando si è in giro (se non c'è nessuna rete disponibile). Con Gentoo si può alterare il comportamento del runlevel per venire incontro alle proprie esigenze.

Per esempio si può creare un secondo runlevel "default" con cui effettuare il boot contenente altri init script assegnati ad esso. Si può selezionare al momento del boot quale runlevel predefinito usare.

Usare softlevel

Per prima cosa, creare la directory di runlevel per il secondo "default" runlevel. Per esempio per creare il runlevel offline:

Codice 5.1: Creare la directory di runlevel

# mkdir /etc/runlevels/offline

Aggiungere i necessari init script al nuovo runlevel creato. Per esempio, per avere una copia del corrente runlevel default ma senza net.eth0:

Codice 5.2: Aggiungere gli init script necessari

(Copia tutti i servizi dal runlevel default al runlevel offline)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(Rimuove servizi non desiderati da runlevel offline)
# rc-update del net.eth0 offline
(Visualizza i servizi attivi per runlevel offline)
# rc-update show offline
(Parte di un output esempio)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Anche se net.eth0 è stato rimosso dal runlevel offline, udev potrebbe tentare ancora di avviare ogni dispositivo che rileva e avviare i servizi relativi, una funzionalità chiamata hotplugging. Come impostazione predefinita, Gentoo non abilita l'hotplugging.

Se si vuole abilitare l'hotplugging, ma solo per un certo insime di script, si può usare la variabile rc_hotplug in /etc/rc.conf:

Codice 5.3: Disabilitare i servizi iniziati dai dispositivi in /etc/rc.conf

# Abilitare net.wlan così come ogni altro servizio, eccetto quelli net.*
# per essere avviati al rilevamento
rc_hotplug="net.wlan !net.*"

Nota: Per maggiori informazioni sui servizi inizializzati per i diversi componenti, si invita a porre attenzione nei commenti del file /etc/rc.conf.

Ora bisogna configurare il bootloader e aggiungere una nuova voce per il runlevel offline. Per esempio in /boot/grub/grub.conf:

Codice 5.4: Aggiungere una voce per offline runlevel

title Gentoo Linux Offline Usage
  root (hd0,0)
  kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Se per il boot del sistema si seleziona la nuova voce il runlevel offline viene usato al posto del default.

Usare bootlevel

Usare bootlevel è completamente analogo a softlevel. L'unica differenza è che si sta definendo un secondo runlevel di "boot" invece di un secondo runlevel "default".

5. Variabili di ambiente

5.a. Variabile d'ambiente

Cosa sono

Una variabile ambiente è un oggetto nominale che contiene informazioni usate da una o più applicazioni. Questo risulta essere un po' misterioso o di difficile gestione da parte di molti utenti, specialmente coloro che si avvicinano per la prima volta a Linux. L'uso di variabili ambiente, invece, può facilitare la modifica della configurazione per una o più applicazioni.

Esempi importanti

Segue una tabella con la lista delle variabili usate su un sistema Linux e la loro descrizione. I valori di esempio sono presentati di seguito.

Variabile	Descrizione
PATH	Variabile che contiene una lista di directory, separate dai due punti (:), nelle quali il sistema cerca file eseguibili. Se si digita un comando (come ls, rc-update o emerge) che non è presente nella lista, il sistema non può essere in grado di eseguirlo, a meno che non si digiti il comando preceduto da tutto il percorso, come /bin/ls.
ROOTPATH	Variabile che ha la stessa funzione di PATH, con la sola differenza che le directory specificano il percorso di ricerca per comandi digitati dall'utente root.
LDPATH	Variabile che contiene la lista di directory, separate dai due punti (:), per la ricerca delle librerie da parte del linker dinamico.
MANPATH	Variabile che contiene la lista di directory, separate dai due punti (:), per la ricerca delle pagine man da parte del comando man.
INFODIR	Variabile che contiene la lista di directory, separate dai due punti (:), per la ricerca delle pagine info da parte del comando info.
PAGER	Variabile che contiene il percorso del programma usato per visualizzare il contenuto di file di testo (come less o more).
EDITOR	Variabile che contiene il percorso del programma usato per modificare il contenuto di file di testo (come nano o vi).
KDEDIRS	Variabile che contiene la lista di directory, separate dai due punti (:), nelle quali si trova materiale specifico per KDE.
CONFIG_PROTECT	Variabile che contiene la lista di directory, separate da spazi, che vengono protette durante il processo di aggiornamento del sistema da parte del Portage.
CONFIG_PROTECT_MASK	Variabile che contiene la lista di directory, separate da spazi, che non dovranno essere protette durante il processo di aggiornamento del sistema da parte del Portage.

Segue un esempio di definizione di tutte queste variabili:

Codice 1.1: Esempio di definizioni

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin"
ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin"
LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"
MANPATH="/usr/share/man:/usr/local/share/man"
INFODIR="/usr/share/info:/usr/local/share/info"
PAGER="/usr/bin/less"
EDITOR="/usr/bin/vim"
KDEDIRS="/usr"
CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
                /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \
                /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf"

5.b. Definire variabili globali

La directory /etc/env.d

Per centralizzare la definizione di queste variabili, è stata introdotta in Gentoo la directory /etc/env.d. All'interno di questa directory si trovano un certo numero di file, come 00basic, 05gcc, ecc. che contengono le variabili necessarie alle applicazioni menzionate nel nome del file.

Per maggiore chiarezza; quando si installa il gcc, viene anche creato dall'ebuild un file chiamato 05gcc, che contiene la definizione delle seguenti variabili:

Codice 2.1: /etc/env.d/05gcc

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info"
CC="gcc"
CXX="g++"
LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

In altre distribuzioni la definizione di variabili ambiente viene fatta con modifiche o aggiunte al file /etc/profile o ad altre locazioni. D'altra parte l'uso di Gentoo facilita la manutenzione e la gestione delle variabili ambiente, dato che non occorre fare attenzione ai numerosi file che possono contenere variabili ambiente.

Per esempio, durante l'aggiornamento del gcc viene anche aggiornato il file /etc/env.d/05gcc senza nessuna richiesta di interazione da parte dell'utente.

Di questo sono beneficiari il Portage e anche l'utente. Occasionalmente potrebbe nascere l'esigenza di configurare una variabile ambiente a livello globale. Prendiamo per esempio la variabile http_proxy. Invece di modificare l'/etc/profile, basta creare un file /etc/env.d/99local, e inserire la seguente definizione:

Codice 2.2: /etc/env.d/99local

http_proxy="proxy.server.com:8080"

L'uso dello stesso file per tutte le variabili utente, aiuta ad avere una panoramica delle variabili definite in seguito dall'utente stesso.

Lo script env-update

Alcuni file in /etc/env.d definiscono la variabile PATH. L'esecuzione di env-update appende le diverse definizioni prima di aggiornare le variabili ambiente, rendendo semplice l'aggiunta di variabili ambiente ai pacchetti (o agli utenti) senza interferire con i valori già presenti.

Lo script env-update appende i valori dei file in /etc/env.d in ordine alfabetico. I nomi dei file devono iniziare con due cifre decimali.

Codice 2.3: Ordine di aggiornamento di env-update

         00basic        99kde-env       99local
     +-------------+----------------+-------------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

La concatenazione di variabili non è sempre possibile, la si può ottenere con le seguentI: ADA_INCLUDE_PATH, ADA_OBJECTS_PATH, CLASSPATH, KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH, PRELINK_PATH_MASK, PKG_CONFIG_PATH e PYTHONPATH. Per tutte le altre variabili è usato l'ultimo valore definito (in ordine alfabetico dei file in /etc/env.d).

Puoi aggiungere più variabili in questa list di variabili concatenate aggiungendo il nome della variabile a una tra: COLON_SEPARATED o SPACE_SEPARATED (anche dentro un file env.d).

Durante l'esecuzione di env-update vengono create tutte le variabili ambiente e verranno poste in /etc/profile.env (usato a sua volta da /etc/profile). Vengono inoltre estratte le informazioni dalla variabile LDPATH per creare il file /etc/ld.so.conf. Dopo di che, viene eseguito il comando ldconfig per ricreare il file /etc/ld.so.cache usato dal linker dinamico.

Per vedere l'effetto immediato di env-update dopo il suo uso, eseguire il seguente comando per aggiornare l'ambiente. Utenti che hanno installato Gentoo, si ricordano probabilmente questo dalle istruzioni di installazione:

Codice 2.4: Aggiornare l'ambiente

# env-update && source /etc/profile

Nota: Il comando precedente aggiorna solo le variabili nel terminale corrente e nelle nuove console. Se si sta lavorando in X11 si dovrà digitare source /etc/profile in ogni altro terminale che si aprirà o se si riavvierà X così che tutti i nuovi terminali abbiano le nuove variabili. Se si usa un login manager passare a root e digitare /etc/init.d/xdm restart. Saltando questo ultimo comando si dovrà fare il logout e di nuovo il login per X per ottenere i nuovi valori delle variabili.

Importante: Non è possibile sfruttare le variabili della shell quando vengono definite altre variabili. Questo significa che cose come FOO="$BAR" (dove $BAR è un'altra variabile) non sono permesse.

5.c. Definire variabili locali

Specifiche dell'utente

Non sempre è conveniente definire variabili ambiente a livello globale. Per esempio, l'aggiunta di /home/mioutente/bin e la attuale directory (quella in cui ci si trova) alla variabile PATH non dovrebbe riflettersi su tutti gli altri utenti. E' necessario definire una variabile ambiente locale e per questo occorre usare i file ~/.bashrc o ~/.bash_profile:

Codice 3.1: Estendere PATH per uso locale in ~/.bashrc

(Due punti seguiti da nessuna directory è inteso come la attuale directory)
PATH="${PATH}:/home/mioutente/bin"

Dopo un nuovo login, la variabile PATH viene aggiornata.

Specifiche alla sessione

A volte sono necessarie anche definizioni più ristrette. Potrebbe essere il caso in cui è necessario usare file binari di una directory temporanea senza usare il percorso dei binari di sistema o senza modificare ~/.bashrc per la temporaneità dell'uso.

In questo caso si può definire la variabile PATH nella sessione corrente usando il comando export. Finché non si esegue un'operazione di logout, la variabile PATH manterrà la configurazione temporanea.

Codice 3.2: Definire una variabile ambiente specifica per una sessione

# export PATH="${PATH}:/home/my_user/tmp/usr/bin"

C. Lavorare con Portage

1. File e directory

2.a. I file del Portage

Direttive per la configurazione

Portage usa le configurazioni predefinite memorizzate in /etc/make.globals. Scorrendo questo file, si noterà che tutta la configurazione del Portage è gestita da variabili. Quali sono queste variabili ed il loro significato è descritto in seguito.

Dato che molte direttive di configurazione differiscono da architettura ad architettura, Portage ha dei file di configurazione predefiniti che fanno parte del proprio profilo. Il proprio profilo è indicato dal link simbolico /etc/portage/make.profile; le configurazioni del Portage sono definite dai file in make.defaults del proprio profilo e dei profili parenti. Verranno presi in considerazione i profili e la directory /etc/portage/make.profile.

Se si sta pianificando la modifica di una variabile di configurazione non alterare /etc/make.globals o make.defaults. Usare invece /etc/portage/make.conf che ha la precedenza sui file precedenti. C'è anche un file chiamato /usr/share/portage/config/make.conf.example, che, come implica il nome stesso, non è nient'altro che un esempio di configurazione, il quale viene ignorato completamente da Portage.

Si può anche definire una variabile di configurazione di Portale come una variabile ambiente, ma non è raccomandato.

Informazioni specifiche sul profilo

Si è già avuto a che fare con la directory /etc/portage/make.profile. Questa non è esattamente una directory ma un link simbolico ad un profilo, come impostazione predefinita è uno di quelli all'interno di /usr/portage/profiles anche se potete crearne uno vostro e farlo puntare a questo. Il profilo a cui punta il link è il profilo al quale aderisce il sistema.

Un profilo contiene informazioni specifiche dell'architettura così come una lista di pacchetti che appartengono al sistema che corrisponde a questo profilo, una lista di pacchetti che non girano su questo profilo (o sono mascherati), ecc.

Informazioni specifiche dell'utente

Quando si vuole sovrascrivere il comportamento di Portage riguardo l'installazione del software, si dovranno modificare i file all'interno di /etc/portage. Si è incoraggiati ad usare i file all'interno di /etc/portage e scoraggiati ad usare variabili ambiente.

All'interno di /etc/portage si possono creare i seguenti file:

package.mask una lista di pacchetti che si vuole che Portage non installi
package.unmask una lista di pacchetti che si vuole installare anche se gli sviluppatori di Gentoo scoraggiano dal farlo
package.accept_keywords una lista di pacchetti che si vuole installare anche se il pacchetto non è (ancora) considerato adatto per la propria architettura di sistema
package.use una lista di flag USE che si vuole usare per certi pacchetti senza che l'intero sistema ne sia coinvolto

Tuttavia non devono per forza essere dei file; possono essere anche delle directory contenenti un file per pacchetto. Maggiori informazioni sulla directory /etc/portage e la lista completa dei file che vi si possono creare, può essere trovata nella pagina di manuale di Portage:

Codice 1.1: Leggere la pagina di manuale di Portage

$ man portage

Modificare l'ubicazione dei file e delle directory di Portage

Come menzionato precedentemente i file di configurazione non possono essere memorizzati in directory diverse da quelle predefinite. Comunque, Portage usa molte altre ubicazioni per vari scopi: memorizzazione del codice sorgente, directory di compilazione, albero di Portage, ...

Tutti questi scopi hanno ubicazioni predefinite ma che possono essere alterate attraverso /etc/portage/make.conf. Il resto di questo capitolo spiega quali sono le ubicazioni per scopi speciali usate da Portage e come alterare la loro collocazione nel filesystem.

Questo documento non deve essere usato come un riferimento. Se si desidera avere una panoramica, fare riferimento alle pagine man del Portage e di make.conf:

Codice 1.2: Leggere le pagine man del Portage e del make.conf

$ man portage
$ man make.conf

1.b. Ubicazione dei file

L'albero del Portage

L'ubicazione predefinita per l'albero del Portage è /usr/portage. Questo è definito dalla variabile PORTDIR. Se si vuole mettere l'albero di Portage da qualche altra parte (alterando questa variabile), non ci si deve dimenticare di modificare il link simbolico /etc/portage/make.profile in accordo con la nuova ubicazione.

Se si altera la variabile PORTDIR, si possono voler modificare anche le seguenti variabili in quanto non noteranno il cambio di PORTDIR (a causa del modo di gestire le variabili del Portage): PKGDIR, DISTDIR, RPMDIR.

Binari precompilati

Anche se Portage non usa pacchetti precompilati in modo predefinito, ha comunque un supporto esteso anche per questi. Quando si chiede al Portage di usare pacchetti precompilati, questi verranno cercati nella directory /usr/portage/packages. Questa ubicazione è definita dalla variabile PKGDIR.

Codice Sorgente

Il codice sorgente delle applicazioni è memorizzato in modo predefinito all'interno di /usr/portage/distfiles. Questa ubicazione è definita dalla variabile DISTDIR.

Portage Database

Portage memorizza il proprio stato (quali pacchetti sono installati, che file appartengono ad un dato pacchetto, ...) in /var/db/pkg.Non alterare questi file manualmente! Si potrebbe alterare la conoscenza che il Portage ha del proprio sistema.

Portage Cache

La cache di Portage (con la data di modifica, i pacchetti virtuali, l'informazione sull'albero delle dipendenze,...) viene memorizzata in /var/cache/edb. Questa locazione è realmente una cache: la si può rimuovere se non si sta eseguendo nessuna applicazione collegata a portage.

1.c. Compilare il software

File temporanei

I file temporanei del Portage sono memorizzati in modo predefinito all'interno di /var/tmp. Questo è definito dalla variabile PORTAGE_TMPDIR.

Se si altera la variabile PORTAGE_TMPDIR, si potrebbe voler modificare anche le seguenti variabili dato che non noteranno la modifica di PORTAGE_TMPDIR (a causa di come Portage gestisce le variabili): BUILD_PREFIX.

Directory di compilazione

Portage crea specifiche directory di compilazione per ogni pacchetto emerso all'interno di /var/tmp/portage. Questa ubicazione è definita dalla variabile BUILD_PREFIX.

Ubicazione nel filesystem

Portage installa in modo predefinito tutti i file sul filesystem corrente (/), ma si può modificare questa definizione usando la variabile d'ambiente ROOT.

1.d. Caratteristiche di log

Ebuild Logging

Portage può creare file di log per ebuild, ma solo quando la variabile PORT_LOGDIR è definita con una locazione che sia scrivibile dall'utente portage. Il valore predefinito per questa variabile è nullo. Se non viene impostata PORT_LOGDIR, non si riceveranno i log delle compilazioni con il log system corrente benché si possano ricevere alcuni log dal nuovo elog. Se la variabile PORT_LOGDIR è definita e si usa elog, si riceveranno i log di compilazione e qualsiasi log salvato da elog, come spiegato di seguito.

In Portage è possibile avere un controllo fine su ciò che viene registrato nei log con l'uso di elog:

PORTAGE_ELOG_CLASSES: attraverso questa variabile si impostano i tipi di messaggio che devono essere registrati. Si può usare qualsiasi combinazione di info, warn, error, log e qa separata da spazi.
- info: Registra i messaggi "einfo" stampati da un ebuild
- warn: Registra i messaggi "ewarn" stampati da un ebuild
- error: Registra i messaggi "eerror" stampati da un ebuild
- log: Registra i messaggi "elog" che si trovano in alcuni ebuild
- qa: Registra i messaggi "QA notice" stampati da un ebuild
PORTAGE_ELOG_SYSTEM: attraverso questa variabili si seleziona il modulo(i) per processare i messaggi di log. Se lasciata vuota, la registrazione dei log viene disabilitata. Si può usare una qualsiasi combinazione di save, custom, syslog, mail, save_summary e mail_summary separata da spazi. Si deve selezionare almeno un modulo per poter utilizzare elog.
- save: Salva un log per pacchetto in $PORT_LOGDIR/elog, o /var/log/portage/elog se $PORT_LOGDIR non è definita.
- custom: Passa tutti i messaggi ad un comando definito dall'utente in $PORTAGE_ELOG_COMMAND; discusso di seguito.
- syslog: Invia tutti i messaggi al sistema di log installato.
- mail: Passa tutti i messaggi al mailserver definito dall'utente in $PORTAGE_ELOG_MAILURI; discusso di seguito. Questa caratteristica di elog richiede >=portage-2.1.1.
- save_summary: Simile a save, ma unisce tutti i messaggi in $PORT_LOGDIR/elog/summary.log, o /var/log/portage/elog/summary.log se $PORT_LOGDIR non è definita.
- mail_summary: Simile a mail, ma manda tutti i messaggi in una singola mail quando emerge termina l'operazione.
PORTAGE_ELOG_COMMAND: usata solo quando il modulo custom è abilitato. Attraverso questa variabile si può specificare un comando per processare i messaggi di log. Si possono usare due variabili: ${PACKAGE} per il nome e la versione del pacchetto e ${LOGFILE} per il path assoluto del file di log. Eccone un possibile uso:
- PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
PORTAGE_ELOG_MAILURI: contiene i parametri per il modulo mail come indirizzo, utente, password, mailserver e numero di porta. Il valore predefinito è "root@localhost localhost".
Ecco un esempio per un server smtp che richiede username e password per l'autenticazione su una particolare porta (la porta di default è la 25):
- PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
PORTAGE_ELOG_MAILFROM: permette di impostare l'indirizzo "from" della mail di log; se non viene impostata, il valore predefinito è "portage".
PORTAGE_ELOG_MAILSUBJECT: permette di creare il soggetto per le mail di log. Si possono usare due variabili: ${PACKAGE} per mostrare il nome e la versione del pacchetto e ${HOST} per il nome completo dell'host dove è in esecuzione Portage.
Eccone un possibile uso:
- PORTAGE_ELOG_MAILSUBJECT="pacchetto \${PACKAGE} è stato installato su \${HOST} con alcuni messaggi"

Importante: Se si usa enotice con Portage-2.0.*, si deve completamente rimuovere enotice, in quanto incompatibile con elog.

2. Configurazione e variabili

2.a. Configurazione del Portage

Si è potuto notare come il Portage sia configurabile attraverso numerose variabili che si possono definire in /etc/portage/make.conf. Si faccia riferimento alle pagine man di make.conf per maggiori e più complete informazioni:

Codice 1.1: Leggere le pagine man di make.conf

$ man make.conf

2.b. Opzioni specifiche per la compilazione

Opzioni per la configurazione e la compilazione

Quando Portage compila un'applicazione, passa il contenuto delle seguenti variabili al compilatore e allo script configure:

CFLAGS & CXXFLAGS definiscono le flag per i compilatori C e C++.
CHOST definisce l'informazione dell'host per lo script configure dell' applicazione.
MAKEOPTS è passata al comando make e di solito definisce l'ammontare del parallelismo usato durante la compilazione. Maggiori informazioni sulle opzioni di make possono essere trovate nella pagina man di make.

Anche la variabile USE viene usata durante la configurazione e la compilazione ma è già stata spiegata minuziosamente nei precedenti capitoli.

Opzioni di installazione tramite emerge

Quando Portage deve effettuare l'emerge una nuova versione di un certo software, rimuoverà i file obsoleti delle vecchie versioni dal sistema. Portage aspetta cinque secondi prima di rimuovere le vecchie versioni. Questi cinque secondi sono definiti dalla variabile CLEAN_DELAY.

Si può usare emerge in modo che utilizzi certe opzioni ogni volta che viene eseguito, impostando la variabile EMERGE_DEFAULT_OPTS. Alcune utili opzioni potrebbero essere --ask, --verbose, --tree, etc.

2.c. Protezione dei file di configurazione

Protezione delle locazioni del Portage

Portage sovrascrive i file provvisti dalle nuove versioni di un software se i file non sono memorizzati in una locazione protetta. Queste locazioni protette sono definite dalla variabile CONFIG_PROTECT e sono generalmente locazioni di file di configurazione. La lista delle directory è separata da spazi.

Un file che avrebbe dovuto essere scritto in tale locazione protetta viene rinominato e l'utente viene avvertito della presenza di una nuova versione del (presumibilmente) file di configurazione.

Si può avere la definizione corrente di CONFIG_PROTECT attraverso l'output di emerge --info:

Codice 3.1: Avere la definizione di CONFIG_PROTECT

$ emerge --info | grep 'CONFIG_PROTECT='

Sono disponibili maggiori informazioni sulla protezione dei file di configurazione del Portage nella sezione CONFIGURATION FILES della pagina di manuale di emerge:

Codice 3.2: Maggiori informazioni sulla protezione dei file di configurazione

$ man emerge

Escludere directory

Per 'sproteggere' certe sottodirectory da locazioni protette si può usare la variabile CONFIG_PROTECT_MASK.

2.d. Opzioni per il download

Ubicazione dei server

Quando le informazioni o i dati richiesti non sono disponibili sul sistema, Portage cerca di recuperarli da Internet. L'ubicazione dei server per le varie informazioni e i canali dati sono definite attraverso le seguenti variabili:

GENTOO_MIRRORS definisce la lista dei server che contengono codice sorgente (distfiles)
PORTAGE_BINHOST definisce un particolare server che contiene pacchetti precompilati per il sistema

Una terza definizione coinvolge l'ubicazione del server rsync usato quando si aggiorna l'albero del Portage:

SYNC definisce un particolare server che Portage usa per aggiornare il proprio albero

Le variabili GENTOO_MIRRORS e SYNC possono essere definite attraverso il comando mirrorselect. Sarà necessario emergere l'applicazione prima dell'uso con emerge mirrorselect. Per maggiori informazioni vedere l'aiuto in linea di mirrorselect:

Codice 4.1: Maggiori informazioni su mirrorselect

# mirrorselect --help

Se il nostro ambiente richiede di usare un proxy server, si possono usare le variabili http_proxy, ftp_proxy e RSYNC_PROXY per dichiarare il proxy server.

Comandi per il download

Quando Portage necessita di scaricare codice sorgente, usa il comando wget di default. E' possibile modificarlo attraverso la variabile FETCHCOMMAND.

Portage riesce e riprendere download parziali di codice sorgente. Per questo usa wget, ma si può alterare con la variabili RESUMECOMMAND.

Occorre assicurarsi che sia FETCHCOMMAND che RESUMECOMMAND memorizzino il codice sorgente nella collocazione corretta. Per questo si possono usare le variabile \${URI} e \${DISTDIR} per puntare all'ubicazione del codice sorgente e dei distfiles rispettivamente.

Si possono anche definire dei gestori di protocollo specifici con FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, ecc.

Configurazione di rsync

Non si può alterare il comando rsync usato dal Portage per aggiornare il proprio albero, ma si possono definire delle variabili relative al comando rsync:

PORTAGE_RSYNC_OPTS imposta il numero predefinito di variabili da utilizzare durante il sync separate da spazi. Queste non dovrebbero essere modificate a meno che non si conosca esattamente cosa si sta facendo. Da notare che certe opzioni richieste verranno sempre usate anche se PORTAGE_RSYNC_OPTS è vuota.
PORTAGE_RSYNC_EXTRA_OPTS può essere utilizzata per impostare opzioni aggiuntive durante il sync. Ogni opzione dovrebbe essere separata da spazi.
- --timeout=<number>: imposta il numero di secondi che definiscono il time-out della connessione. Il valore predefinito è 180 ma utenti che utilizzano connessioni via modem o con computer lenti potrebbero voler impostare questo valore a 300 o maggiore.
- --exclude-from=/etc/portage/rsync_excludes: il valore della variabile è un file contenente una lista di pacchetti e/o categorie che rsync dovrebbe ignorare dirante il processo di aggiornamento. In questo caso il file è /etc/portage/rsync_excludes. Leggere Usare un Portage Tree Subset per la sintassi di questo file.
- --quiet: riduce l'output a schermo
- --verbose: stampa una lista completa dei file
- --progress: mostra il progressivo per ogni file
PORTAGE_RSYNC_RETRIES definisce quante volte rsync dovrebbe provare a connettersi al mirror definito dalla variabile SYNC prima di rinunciarvi. Il valore predefinito per questa variabile è 3.

Per maggiori informazioni su queste ed altre opzioni, leggere la pagina di manuale di rsync.

2.e. Configurazione di Gentoo

Selezione di una branca

Si può cambiare la branca predefinita con la variabile ACCEPT_KEYWORDS il cui valore predefinito è l'architettura stabile del sistema. Maggiori informazioni sulle branche di Gentoo possono essere trovate nel prossimo capitolo.

Caratteristiche del Portage

Si possono attivare certe caratteristiche del Portage con la variabile FEATURES. Le caratteristiche del Portage sono state discusse nei capitoli precedenti, come in Caratteristiche del Portage.

2.f. Comportamento del Portage

Gestione delle risorse

Con la variabile PORTAGE_NICENESS si può aumentare o ridurre il valore nice con cui viene eseguito il Portage. Il valore di PORTAGE_NICENESS viene aggiunto al valore corrente di nice.

Per maggiori informazioni sui valori di nice fare riferimento alle pagine man del nice:

Codice 6.1: Maggiori informazioni sul nice

$ man nice

Comportamento dell'output

La variabile NOCOLOR, il cui valore predefinito è "false", definisce se Portage deve disabilitare l'uso di output colorato.

3. Combinare Software affidabile e non

3.a. Usare una branca

La branca stabile

La variabile ACCEPT_KEYWORDS definisce la branca usata dal sistema. Il suo valore predefinito è la branca stabile per l'architettura del sistema in uso, per esempio x86

La raccomandazione è di usare solo la branca stabile, comunque, se non si è preoccupati eccessivamente per la stabilità e si vuole aiutare Gentoo sottomettendo rapporti di problemi su http://bugs.gentoo.org, si può proseguire con la lettura.

La branca di test

Se si vogliono usare i software più recenti si può considerare l'uso della branca test. Per far usare al Portage la branca di test occorre aggiungere il simbolo ~ prima dell'architettura del sistema in uso.

La branca di test è esattamente ciò che significa: In fase di test. Se un pacchetto è in fase di test, significa che gli sviluppatori pensano che sia funzionante ma non ancora testato in maniera esauriente. Ci si potrebbe trovare ad essere i primi a scoprire un bug nel pacchetto, nel qual caso si dovrebbe aprire un bug su bugreport per farlo conoscere agli sviluppatori.

Si potrebbero comunque notare problemi di stabilità, gestione imperfetta dei pacchetti (per esempio dipendenze errate od omesse), aggiornamenti troppo frequenti (risultante in compilazioni multiple) o pacchetti corrotti. Se non si conosce come lavora Gentoo e come risolvere i problemi, si raccomanda di usare le branche stabili e testate.

Per esempio, per selezionare la branca di test per architetture x86, editare /etc/portage/make.conf e definire:

Codice 1.1: Definire la variabile ACCEPT_KEYWORDS

ACCEPT_KEYWORDS="~x86"

Se si aggiorna il sistema dopo questa modifica, si avranno molti pacchetti da aggiornare. Una cosa da tenere bene in mente è che se si aggiorna il sistema in uso alla branca di test non c'è un modo semplice per tornare alla branca stabile (eccetto l'uso di backup, naturalmente).

3.b. Miscelare branche stabili e test

package.accept_keywords

Si può chiedere al Portage di permettere la branca di test per particolari pacchetti ma usare la branca stabile per il resto del sistema. Per questo, si deve aggiungere la categoria ed il nome del pacchetto che si vuole usare dalla branca di test al file /etc/portage/package.accept_keywords. E' anche possibile creare una directory (con lo stesso nome) ed elencare il pacchetto nei file in questa directory. Per esempio, per usare la branca di test di gnumeric:

Codice 2.1: Definizione di /etc/portage/package.accept_keywords per gnumeric

app-office/gnumeric

Sperimentare versioni particolari

Se si vuole usare una versione specifica di software dalla branca di test ma non si vuole che Portage usi la branca di test per le versioni successive, si può aggiungere la versione nel file package.accept_keywords. In questo caso si deve usare l'operatore =. Si può anche inserire un intervallo di versioni usando gli operatori <=, <, > o >=.

In ogni caso, volendo aggiungere una versione si deve usare un operatore. Se non si specifica alcuna versione non si possono usare operatori.

Il seguente esempio mostra come accettare gnumeric-1.2.13:

Codice 2.2: Usare una particolare versione di gnumeric

=app-office/gnumeric-1.2.13

3.c. Usare pacchetti mascherati

package.unmask

Importante: Gli sviluppatori di Gentoo non supportano l'uso di questa locazione. Si prega di usare cautela nel loro uso. Le richieste di supporto in relazione a package.unmask e/o package.mask non avranno risposta. Si è avvertiti.

Quando un pacchetto è stato mascherato dagli sviluppatori di Gentoo e si vuole comunque installare il file a dispetto della ragione menzionata nel file package.mask (ubicato di default in /usr/portage/profiles), aggiungere la versione desiderata (in genere è esattamente la stessa linea di profiles) in /etc/portage/package.unmask (o in un file in questa directory se questa è una directory).

Per esempio, se =net-mail/hotwayd-0.8 è mascherato, si può comunque installarlo aggiungendo la stessa identica linea nella locazione package.unmask:

Codice 3.1: /etc/portage/package.unmask

=net-mail/hotwayd-0.8

Nota: Se un elemento di /usr/portage/profiles/package.mask contiene un range di versioni per un pacchetto, è necessario smascherare solo la versione che davvero si vuole. Leggere la sezione precedente per capire come indicare le versioni in package.unmask.

package.mask

Se non si vuole che Portage installi un certo pacchetto o una specifica versione di un pacchetto, lo si può mascherare autonomamente aggiungendo una riga appropriata in /etc/portage/package.mask (sia in questo file o in un file in questa directory).

Per esempio, se non si vuole che Portage installi nuove versioni del kernel dopo gentoo-sources-2.6.8.1, si aggiunga la seguente linea in package.mask:

Codice 3.2: /etc/portage/package.mask esempio

>sys-kernel/gentoo-sources-2.6.8.1

4. Ulteriori strumenti di Portage

4.a. dispatch-conf

dispatch-conf è uno strumento il cui scopo è di installare i file ._cfg0000_<name> generati da Portage quando quest'ultimo vuole sovrascrivere un file in una directory protetta dalla variabile CONFIG_PROTECT.

Con dispatch-conf è possibile applicare gli aggiornamenti ai propri file di configurazione tenendo traccia contemporaneamente di tutti i cambiamenti. dispatch-conf memorizza le differenze tra i file di configurazione sottoforma di patch o usando il sistema di revisione RCS. Ciò significa che se si commette un errore nell'aggiornare un file di configurazione, è possibile tornare indietro alla versione precedente del file in qualsiasi momento.

Con dispatch-conf, viene richiesto di mantenere il file di configurazione invariato, usare il nuovo file, modificare il file corrente o fondere le modifiche interattivamente. Inoltre, dispatch-conf possiede anche alcune caratteristiche aggiuntive:

Vengono aggiornati automaticamente i file di configurazione le cui modifiche coinvolgono solo commenti.
Vengono automaticamente aggiornati i file di configurazione che differiscono solo per la quantità di spazi.

Accertarsi di modificare /etc/dispatch-conf.conf e di creare la directory referenziata dalla variabile archive-dir.

Codice 1.1: Eseguire dispatch-conf

# dispatch-conf

Durante l'esecuzione di dispatch-conf, verrà analizzato ciascun file di configurazione, uno alla volta. Premete u per aggiornare (sostituire) il file di configurazione corrente con quello nuovo e continuare con il file successivo. Premere z per ignorare (cancellare) il nuovo file di configurazione e continuare con il file successivo. Una volta che tutti i file di configurazione sono stati processati, dispatch-conf uscirà. È anche possibile premere q in qualsiasi momento.

Per maggiori informazioni, consultare le pagine di manuale di dispatch-conf. Essa spiega come fondere in modo interattivo i nuovi file di configurazione in quelli correnti, modificare i nuovi file di configurazione, esaminare le differenze tra i file, e altro ancora.

Codice 1.2: Leggere le pagine di manuale di dispatch-conf

$ man dispatch-conf

4.b. etc-update

In alternativa si può usare etc-update per fondere i file di configurazione. La sua modalità d'utilizzo non è semplice come quella di dispatch-conf, non è così ricco di funzionalità, ma fornisce comunque uno strumento interattivo di aggiornamento della configurazione e può anche auto-aggiornare i cambiamenti minori.

Tuttavia, diversamente da dispatch-conf, etc-update non preserva le vecchie versioni dei propri file di configurazione. Una volta aggiornato il file, la vecchia versione è persa per sempre! Pertanto bisogna essere molto cauti, in quanto usare etc-update è significativamente meno sicuro che usare dispatch-conf.

Codice 2.1: Eseguire etc-update

# etc-update

Dopo l'installazione dei file di configurazione non importanti, viene visualizzata una lista di file protetti che dovrebbero essere aggiornati. In fondo alla lista viene richiesto il da farsi tra le seguenti possibili opzioni:

Codice 2.2: Opzioni di etc-update

Please select a file to edit by entering the corresponding number.
              (-1 to exit) (-3 to auto merge all remaining files)
                           (-5 to auto-merge AND not use 'mv -i'):

Se si sceglie -1, si provoca l'uscita immediata di etc-update senza aver eseguito alcun cambiamento. Con le scelte -3 o -5, tutti i file di configurazione listati verrano sovrascritti con le nuove versioni. E' perciò molto importante selezionare prima i file di configurazione che non si vorrebbero aggiornare automaticamente. Questo si può fare semplicemente digitando il numero listato alla sinistra del file di configurazione.

Come esempio selezioniamo il file di configurazione /etc/pear.conf:

Codice 2.3: Aggiornare un file di configurazione specifico

Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
[...]
End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf
1) Replace original with update
2) Delete update, keeping original as is
3) Interactively merge original with update
4) Show differences again

Si possono ora vedere le differenze tra i due file. Se si pensa che il file possa venire aggiornato senza problemi, digitare 1. Se si pensa che l'aggiornamento non sia necessario o non provveda nuove o utili informazioni, digitare 2. Se si vuole aggiornare il file di configurazione corrente in modo interattivo, digitare 3.

Non ci sono punti a favore della fusione interattiva. Per completezza, segue la lista di comandi che possono essere usati mentre si sta interattivamente fondendo i due file. Vengono visualizzate due linee (quella originale e quella proposta nell'aggiornamento) e la richiesta sul da farsi tra uno dei seguenti comandi:

Codice 2.4: Comandi disponibili per la fusione interattiva

ed:     Edit then use both versions, each decorated with a header.
eb:     Edit then use both versions.
el:     Edit then use the left version.
er:     Edit then use the right version.
e:      Edit a new version.
l:      Use the left version.
r:      Use the right version.
s:      Silently include common lines.
v:      Verbosely include common lines.
q:      Quit.

Una volta terminato l'aggiornamento dei file di configurazione importanti, si può procedere all'aggiornamento automatico dei restanti file, etc-update terminerà la sua esecuzione quando non ci saranno più file di configurazione da aggiornare.

4.c. quickpkg

Con quickpkg si possono creare archivi di pacchetti che sono già installati sul sistema. Questi archivi possono essere usati come pacchetti precompilati. L'uso di quickpkg è estremamente semplice, basta aggiungere i nomi dei pacchetti che si vuole archiviare.

Per esempio, se si vogliono archiviare curl, orage e procps:

Codice 3.1: Esempio dell'uso di quickpkg

# quickpkg curl orage procps

I pacchetti precompilati vengono memorizzati in $PKGDIR (/usr/portage/packages/ come impostazione predefinita). Questi pacchetti sono posti in $PKGDIR/<category>.

5. Separarsi dalla collezione di software originale

5.a. Usare un Portage Tree Subset

Escludere pacchetti e/o categorie

Si possono selettivamente aggiornare certe categorie/pacchetti ed ignorarne altre/i facendo in modo che rsync escluda categorie/pacchetti durante la fase di emerge --sync.

Occorre definire il nome del file che contiene i pacchetti o le categorie da escludere nella variabile PORTAGE_RSYNC_EXTRA_OPTS in /etc/portage/make.conf.

Codice 1.1: Definizione del file di esclusione in /etc/portage/make.conf

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

Codice 1.2: Escludere tutti i giochi in /etc/portage/rsync_excludes

games-*/*

Si noti comunque che questo può portare ad avere problemi di dipendenze nuove, aggiornando pacchetti che potrebbero dipendere da pacchetti nuovi ma esclusi.

5.b. Aggiungere ebuild non ufficiali

Definizione di una propria directory Portage

Il Portage può usare ebuild che non sono disponibili attraverso l'albero ufficiale. Per far questo, si può creare una nuova directory (per esempio /usr/local/portage) entro la quale memorizzare gli ebuild di terze parti usando la stessa struttura delle directory dell'albero del Portage.

Si definisce quindi la variabile PORTDIR_OVERLAY in /etc/portage/make.conf affinché punti alla directory creata precedentemente. Usando Portage dopo queste modifiche, si potranno usare questi nuovi ebuild senza che vengano rimossi o sovrascritti da un nuovo emerge --sync.

Lavorare con diversi overlay

Per gli utenti che sviluppano su diversi strati, testano pacchetti prima di porli nell'albero di Portage o vogliono semplicemente usare ebuild non ufficiali di varie sorgenti, il pacchetto app-portage/layman fornisce layman, uno strumento che aiuta a mantenere aggiornati gli overlay repository.

Per prima cosa installare e configurare layman seguendo le istruzioni contenute nel documento Overlay Gentoo: Guida per gli Utenti, e aggiungere i propri repository desiderati tramite il comando layman -a <nome-overlay>.

Si supponga di avere due repository chiamati java (per lo sviluppo di ebuild java) e entapps (per le applicazioni sviluppate per la propria azienda), si potranno aggiornare nel seguente modo:

Codice 2.1: Usare layman per aggiornare tutti i repository

# layman -S

Per ulteriori informazioni su l'utilizzo degli overlay, si prega di consultare man layman e la guida utente per layman/overlay.

5.c. Software non mantenuto dal Portage

Usare il Portage con software proprietario

In alcuni casi si può voler configurare, installare e manutenere software proprietario senza dover automatizzare il processo del Portage anche se Portage può provvedere il titolo software. Casi conosciuti sono sorgenti del kernel e driver nvidia. Si può configurare Portage in modo tale che sappia che certi pacchetti sono stati installati manualmente nel sistema. Questo processo è chiamato injecting ed è supportato dal Portage attraverso il file /etc/portage/profile/package.provided.

Per esempio, per informare il Portage che gentoo-sources-2.6.11.6 è stato installato manualmente, aggiungere la seguente linea a /etc/portage/profile/package.provided:

Codice 3.1: Esempio di linea per package.provided

 sys-kernel/gentoo-sources-2.6.11.6

D. Configurazione di rete di Gentoo

1. Configurazione comune

1.a. Iniziare

Nota: Questo documento assume che il kernel e i suoi moduli per l'hardware siano stati configurati correttamente e che si conosca il nome della propria interfaccia hardware. Si assume inoltre di voler configurare eth0, ma potrebbe essere anche eth1, wlan0, ecc.

Nota: Questo documento richiede l'esecuzione di baselayout-1.11.11 o versioni successive.

Per iniziare la configurazione della scheda di rete, si deve far conoscere quest'ultima al sistema Gentoo RC, tramite la creazione di un collegamento simbolico da net.lo a net.eth0 in /etc/init.d.

Codice 1.1: Collegamento simbolico di net.eth0 a net.lo

# cd /etc/init.d
# ln -s net.lo net.eth0

Ora il sistema Gentoo RC conosce questa interfaccia, ma deve anche sapere come configurarla. Tutte le interfacce di rete sono configurate in /etc/conf.d/net. Segue un esempio di configurazione per DHCP e indirizzi statici.

Codice 1.2: Esempi per /etc/conf.d/net

# Per DHCP
config_eth0="dhcp"

# Per IP statico usando la notazione CIDR
config_eth0="192.168.0.7/24"
routes_eth0="default via 192.168.0.1"
dns_servers_eth0="192.168.0.1 8.8.8.8"

# Per IP statico usando la notazione netmask
config_eth0="192.168.0.7 netmask 255.255.255.0"
routes_eth0="default via 192.168.0.1"
dns_servers_eth0="192.168.0.1 8.8.8.8"

Nota: Se non si specifica una configurazione per l'interfaccia, viene automaticamente utilizzato DHCP.

Nota: CIDR significa Classless InterDomain Routing. In origine, gli indirizzi IPv4 erano classificati come A, B, o C. Questo sistema di classificazione non prevedeva la grande popolarità di Internet, e rischia di rimanere a corto di nuovi indirizzi univoci. CIDR è uno schema di indirizzamento che permette ad un indirizzo IP di designare molti indirizzi IP. Un indirizzo CIDR IP assomiglia ad un indirizzo IP normale tranne per il fatto che finisce con uno slash seguito da un numero; per esempio, 192.168.0.0/16. CIDR è descritto in RFC 1519.

Ora che l'interfaccia è stata configurata, si può avviarla e fermarla con i comandi seguenti.

Codice 1.3: Avviare e fermare gli script di rete

# /etc/init.d/net.eth0 start
# /etc/init.d/net.eth0 stop

Importante: Quando si hanno problemi con la rete, è utile dare uno sgaurdo a /var/log/rc.log. A meno di non aver scelto di impostare rc_logger="NO" in /etc/rc.conf, in quel file si troveranno informazioni sulle attività di avvio del sistema.

Ora che l'interfaccia di rete è stata avviata e fermata con successo, è consigliabile farla partire durante l'avvio di Gentoo, utilizzando i comandi seguenti. L'ultimo comando "rc" dice a Gentoo di avviare qualsiasi script nel runlevel attuale che non è ancora stato avviato.

Codice 1.4: Configurare una interfaccia di rete che si carica al boot

# rc-update add net.eth0 default
# rc

2. Configurazione Avanzata

2.a. Configurazione avanzata

La variabile config_eth0 è il cuore della configurazione di un'interfaccia, ed è composta da un elenco di istruzioni di alto livello per la sua configurazione (in questo caso l'interfaccia è eth0). Ogni comando di questo elenco è effettuato sequenzialmente, e l'interfaccia viene considerata funzionante se almeno un comando viene eseguito con successo.

Ecco un elenco delle istruzioni integrate.

Comando	Descrizione
null	Non fa niente
noop	Se l'interfaccia è attiva e c'è un indirizzo, chiude la configurazione con successo
un indirizzo IPv4 o IPv6	Aggiunge l'indirizzo dell'interfaccia
dhcp, adsl o apipa (o un comando personalizzato da un modulo di terze parti)	Esegue il modulo fornito dal comando. Per esempio dhcp esegue un modulo che fornisce dhcp, il quale può essere uno tra dhcpcd, dhclient o pump.

Se un comando non funziona, si può specificare un comando di riserva. Questo deve corrispondere con esattezza alla struttura di configurazione.

Si possono unire insieme questi comandi. Ecco alcuni esempi reali:

Codice 1.1: Esempi di configurazione

# Aggiungere tre indirizzi IPv4
config_eth0="192.168.0.2/24"
192.168.0.3/24
192.168.0.4/24"

# Aggiungere un indirizzo IPv4 e due indirizzi IPv6
config_eth0="192.168.0.2/24
4321:0:1:2:3:4:567:89ab
4321:0:1:2:3:4:567:89ac"

# Mantenere l'indirizzo assegnato dal kernel, a meno che l'interfaccia
# non venga disattivata e allora assegnarne un altro tramite DHCP. Se DHCP
# fallisce aggiungere un indirizzo statico determinato tramite APIPA
config_eth0="noop
dhcp"
fallback_eth0="null
apipa"

Nota: Quando si usa il modulo ifconfig e si aggiunge più di un indirizzo, per ogni ulteriore indirizzo vengono creati degli alias di interfaccia. Con gli esempi precedenti, si ottengono le interfacce eth0, eth0:1 e eth0:2. Non si può fare niente di speciale con queste interfacce poichè il kernel e gli altri programmi trattano eth0:1 e eth0:2 come eth0.

Importante: L'ordine dei comandi di riserva è importante! Se non si specifica l'opzione null allora il comando apipa si esegue solo se fallisce il comando noop.

Nota: APIPA e DHCP sono discussi più avanti.

2.b. Dipendenze di rete

Gli script di inizializzazione in /etc/init.d possono dipendere da una specifica interfaccia di rete o da net. Tutte le interfacce nel sistema init di Gentoo forniscono quella che viene chiamata net.

Se in /etc/rc.conf si imposta rc_depend_strict="YES", allora tutte le interfacce di rete che forniscono net devono essere attive prima che la dipendenza "net" sia considerarta soddisfatta. In altre parole, se si ha net.eth0 e net.eth1 e un init script dipende da "net", allora entrambe devono essere attivate.

D'altro canto, se si imposta rc_depend_strict="NO", allora la dipendenza "net" è considerata soddisfatta nel momento cin cui almeno una interfaccia di rete viene attivata.

Ma che succede se net.br0 dipende da net.eth0 e net.eth1? net.eth1 potrebbe essere un dispositivo wireless o ppp che deve essere configurato prima che sia aggiunto al bridge. Non può essere fatto in /etc/init.d/net.br0 poichè questo è un collegamento simbolico a net.lo

La risposta corretta è definire un'impostazione rc_need_ in /etc/conf.d/net

Codice 2.1: Dipendenza net.br0 in /etc/conf.d/net

rc_need_br0="net.eth0 net.eth1"

Ma questo da solo non basta. Gli init script Gentoo usano una dipendenza virtuale chiamata net per informare il sistema di quando la rete è disponibile. Ovviamente, nel caso precedente, la rete va considerata disponibile quando net.br0 è stata avviata, non quando lo sono le altre. Quindi dobbiamo dichiarare quanto vogliamo anche in /etc/conf.d/net:

Codice 2.2: Aggiornare le dipendenze virtuali per al rete

rc_net_lo_provide="!net"
rc_net_eth0_provide="!net"
rc_net_eth1_provide="!net"

Per una discussione più dettagliata sulla dipendenza, consultare la sezione Scrivere Init Script nel Manuale Gentoo. All'interno di quel file sono disponibili ulteriori informazioni su /etc/rc.conf.

2.c. Nomi di variabili e valori

I nomi delle variabili sono dinamici. Di solito seguono la struttura variable_${interface|mac|essid|apmac}. Per esempio, la variabile dhcpcd_eth0 contiene il valore per le opzioni dhcpcd per eth0 e dhcpcd_essid contiene il valore per le opzioni dhcpcd quando una interfaccia si connette a essid "essid".

Non c'è nessuna regola che dice che i nomi delle interfacce debbano essere ethx. Molte interfacce wireless hanno nomi come wlanx, rax e anche ethx. Alcune interfacce definite dagli utenti, come i bridge, possono avere qualsiasi nome, per esempio foo. Per rendere il tutto più interessante, gli Access Point Wireless possono avere nomi che contengono caratteri alfa numerici - questo è importante perchè si possono configurare i parametri di rete per ESSID.

Gentoo usa variabili bash per la rete - e bash non può usare altro che caratteri alfanumerici inglesi. Per ovviare a questa limitazione si cambia ogni carattere non alfanumerico inglese nel carattere _

Altro problema con bash, è il contenuto delle variabili - alcuni caratteri hanno bisogno di essere specificati in modo particolare. Si risolve mettendo un \ all'inizio di questi. I seguenti caratteri devono essere specificati in modo particolare: ", ' e \.

In questo esempio si usa wireless ESSID poichè contiene un vasto numero di caratteri. Si usa il ESSID My "\ NET:

Codice 3.1: Esempio di nomi di variabili

(Funziona, ma il domain è invalido)
dns_domain_My____NET="My \"\\ NET"

(Il comando precedente imposta il domain dns a My "\ NET quando una
scheda wireless si connette a un AP che ha ESSID come My "\ NET)

3. Impostazioni modulari

3.a. Moduli di rete

Attualmente vengono supportati gli script di rete modulari, il che significa che si può aggiungere il supporto per nuovi tipi di interfaccia e moduli di configurazione mantenendo allo stesso tempo la compatibilità con quelli esistenti.

I moduli vengono caricati in modo predefinito se il pacchetto che essi necessitano è installato. Se si specifica un modulo che non ha installato il suo pacchetto, si ottiene un errore che avvisa quale pacchetto necessita di essere installato. Idealmente, le impostazioni per i moduli sono da usare solamente quando si hanno due o più pacchetti installati che forniscono lo stesso servizio e si deve preferire uno rispetto ad un altro.

Nota: Tutte le impostazioni discusse, sono in /etc/conf.d/net, dove non diversamente specificato.

Codice 1.1: Preferenza dei moduli

# Si preferisce ifconfig piuttosto che iproute2
modules="ifconfig"

# Si possono anche specificare altri moduli per una interfaccia
# In questo caso si preferisce pump su dhcpcd
modules_eth0="pump"

# Si possono anche specificare quali moduli non usare - per esempio
# si potrebbe usare un supplicant o un linux-wlan-ng per controllare
# la configurazione wireless ma volere ancora configurare le impostazioni di
# rete per ESSID che sono associate.
modules="!iwconfig"

3.b. Utilità di configurazione delle interfacce

Sono fornite due utilità di configurazione delle interfacce: ifconfig e iproute2. C'è bisogno di una di esse per fare qualsiasi tipo di configurazione di rete.

ifconfig è installato per default (il pacchetto net-tools è parte del set di sistema). iproute2 è un pacchetto più potente e flessibile, ma non è incluso in modo predefinito.

Codice 2.1: Installare iproute2

# emerge sys-apps/iproute2

# Preferire ifconfig invece di iproute2 se entrambi sono installati
# visto che openrc preferisce iproute2
modules="ifconfig"

Poichè ifconfig e iproute2 fanno un lavoro molto simile, viene permesso che le loro configurazioni di base funzionino l'una con l'altra. Per esempio entrambi i codici funzionano a prescindere dal modulo che si sta usando.

Codice 2.2: Esempi di ifconfig e iproute2

config_eth0="192.168.0.2/24"
config_eth0="192.168.0.2 netmask 255.255.255.0"

# Si può anche specificare il broadcast
config_eth0="192.168.0.2/24 brd 192.168.0.255"
config_eth0="192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"

3.c. DHCP

DHCP è la possibilità di ottenere informazioni di rete (indirizzo IP, server DNS, Gateway, ecc.) da un server DHCP. Ciò significa che se c'è un server DHCP funzionante sulla rete, basta dire ad ogni client di usare DHCP in modo da fargli impostare la rete da sè. Bisogna configurare altre cose come wireless, ppp o altre se sono richieste, prima di usare DHCP.

DHCP può essere fornito da dhclient, dhcpcd, o pump. Ogni modulo DHCP ha i suoi pro e i suoi contro, eccone un breve riassunto.

Modulo DHCP	Pacchetto	Pro	Contro
dhclient	net-misc/dhcp	Fatto da ISC, gli stessi che fanno il software BIND DNS. Altamente configurabile	La configurazione è complessa, il software è enorme, non si possono ottenere server NTP da DHCP, non invia l'hostname in modo predefinito
dhcpcd	net-misc/dhcpcd	Da tanto tempo scelta predefinita di Gentoo, nessuna dipendenza da strumenti esterni, attivamente sviluppato da Gentoo	Può essere lento, non può essere ancora eseguito come demone quando il lease è infinito
pump	net-misc/pump	Leggero, nessuna dipendenza da altri strumenti	Non è più mantenuto dagli sviluppatori originali, non sicuro, specialmente su alcuni modem, non si possono ottenere server NIS da DHCP

Se si ha installato più di un client DHCP, bisogna specificare quale usare, altrimenti la scelta predefinita sarà dhcpcd, se disponibile.

Per passare opzioni specifiche al modulo dhcp, usare module_eth0="..." (cambiare module con il module DHCP che si sta usando, es. dhcpcd_eth0)

L'obiettivo è quello di rendere DHCP più semplice, perciò vengono supportati i seguenti comandi usando la variabile dhcp_eth0. L'impostazione predefinita è non impostare nessuna di queste.

release - rilascia l'indirizzo IP per ri-usarlo
nodns - non sovrascrivere /etc/resolv.conf
nontp - non sovrascrivere /etc/ntp.conf
nonis - non sovrascrivere /etc/yp.conf

Codice 3.1: Esempio di configurazione DHCP in /etc/conf.d/net

# Necessario solamente se sono stati installati più moduli DHCP
modules="dhcpcd"

config_eth0="dhcp"
dhcpcd_eth0="-t 10" # Timeout dopo 10 secondi
dhcp_eth0="release nodns nontp nonis" # Ottiene solo un indirizzo

Nota: dhcpcd e pump inviano l'attuale hostname al server DHCP predefinito, in questo modo non occorre più specificarlo.

3.d. ADSL con PPPoe/PPPoA

Prima bisogna installare il software ADSL.

Codice 4.1: Installare il pacchetto ppp

# emerge net-dialup/ppp

Nota: Se c'è la necessità di utilizzare PPPoA, assicurarsi di usare >=baselayout-1.12.x.

Poi, creare lo script net per PPP e quello per l'interfaccia di rete usata da PPP.

Codice 4.2: Creare gli script PPP e ethernet

# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0
# ln -s /etc/init.d/net.lo /etc/init.d/net.eth0

Assicurarsi di impostare rc_depend_strict a "YES" in /etc/rc.conf.

Ora bisogna configurare /etc/conf.d/net.

Codice 4.3: Una configurazione base per PPPoe

config_eth0=( null ) (Specificare la propria interfaccia ethernet)
config_ppp0=( "ppp" )
link_ppp0="eth0" (Specificare la propria interfaccia ethernet)
plugins_ppp0=( "pppoe" )
username_ppp0='user'
password_ppp0='password'
pppd_ppp0=
noauth
defaultroute
usepeerdns
holdoff 3
child-timeout 60
lcp-echo-interval 15
lcp-echo-failure 3
noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp"

rc_need_ppp0="net.eth0"

La password può essere anche impostata in /etc/ppp/pap-secrets.

Codice 4.4: Esempio /etc/ppp/pap-secrets

# L'asterisco * è importante
"username"  *  "password"

Se si utilizza PPPoE con un modem USB bisogna installare br2684ctl. Si prega di leggere /usr/portage/net-dialup/speedtouch-usb/files/README per ottenere informazioni su come configurarlo adeguatamente.

Importante: Leggere attentamente le sezioni su ADSL e PPP in /usr/share/doc/openrc-0.8.3-r1/net.example.bz2. Questo file contiene un gran numero di spiegazioni dettagliate riguardo a tutte le impostazioni per la propria configurazione particolare di PPP. Ovviamente, cambiare 0.8.3-r1 con la versione di OpenRC installata nel proprio sistema.

3.e. APIPA (Automatic Private IP Addressing)

APIPA cerca di trovare un indirizzo libero tra 169.254.0.0-169.254.255.255 con un arping di un indirizzo casuale, incluso nella gamma di indirizzi summenzionati, sull'interfaccia. Se non c'è nessuna risposta allora si assegna questo indirizzo all'interfaccia.

L'uso di APIPA è utile per le LAN in cui non c'è nessun server DHCP e non ci si connette direttamente a Internet e tutti gli altri computer utilizzano APIPA.

Per il supporto ad APIPA installare net-misc/iputils o net-analyzer/arping.

Codice 5.1: Configurazione di APIPA in /etc/conf.d/net

# Cercare DHCP - se fallisce passare ad APIPA
config_eth0="dhcp"
fallback_eth0="apipa"

# Usare APIPA
config_eth0="apipa"

3.f. Bonding

Per poter effettuare il bonding/trunking (ndT: unione/aggregazione) di collegamenti installare net-misc/ifenslave.

Il bonding è usato per aumentare la larghezza di banda della rete. Se si hanno due schede di rete sulla stessa rete, si possono collegare insieme in modo che le applicazioni vedano una sola interfaccia ma in realtà utilizzino entrambe le due schede di rete.

Codice 6.1: Configurazione per il bonding in /etc/conf.d/net

# Per collegare le interfacce
slaves_bond0="eth0 eth1 eth2"

# Si può non assegnare un IP all'interfaccia collegata
config_bond0="null"

# Dipende da eth0, eth1 e eth2 poichè essi possono richiedere una configurazione extra
rc_need_bond0="net.eth0 net.eth1 net.eth2"

3.g. Bridging (supporto 802.1d)

Per il supporto al "bridging" installare net-misc/bridge-utils

Il bridging è usato per collegare insieme delle reti. Per esempio, si ha un server che si connette a Internet con un modem ADSL e una scheda wireless access che permette a altri computer di connettersi a Internet con il modem ADSL. Si può creare un "bridge" (ponte) per unire le due interfacce.

Codice 7.1: Configurazione per il bridge in /etc/conf.d/net

# Configurare il bridge - "man brctl" per ulteriori dettagli
brctl_br0="setfd 0" "sethello 0" "stp off"

# Per aggiungere delle porte al bridge br0
bridge_br0="eth0 eth1"

# Si devono configurare le porte con valori null in modo da non avviare dhcp
config_eth0="null"
config_eth1="null"

# Dare un indirizzo al bridge - si può usare DHCP
config_br0="192.168.0.1/24"

# Dipende da eth0 e eth1 poichè essi possono richiedere una configurazione aggiuntiva
rc_need_br0="net.eth0 net.eth1"

Importante: Per usare alcune impostazioni per il bridge di rete, è consigliabile consultare la documentazione riguardante i nomi di variabili

3.h. Indirizzo MAC (MAC Address)

Se se ne ha la necessità, è possibile cambiare anche l'indirizzo MAC di una interfaccia attraverso il file di configurazione della rete.

Codice 8.1: Esempio di cambio di un Indirizzo MAC

# Impostare l'indirizzo MAC all'interfaccia
mac_eth0="00:11:22:33:44:55"

# Per rendere casuali solo gli ultimi 3 byte
mac_eth0="random-ending"

# Per rendere casuale tra lo stesso tipo fisico di connessione (esempio
# fibra, copper, wireless), tutti i fornitori
mac_eth0="random-samekind"

# Per rendere casuale tra qualsiasi tipo fisico di connessione (esempio
# fibra, copper, wireless), tutti i fornitori
mac_eth0="random-anykind"

# Casualità completa - ATTENZIONE: alcuni indirizzi MAC generati
# da questo esempio potrebberoNON funzionare come previso
mac_eth0="random-full"

3.i. Tunnelling

Non occorre installare niente per il tunnelling in quanto il gestore dell'interfaccia lo fa già da sè.

Codice 9.1: Configurazione per il tunnelling in /etc/conf.d/net

# Per tunnel GRE
iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"

# Per tunnel IPIP
iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"

# Per configurare l'interfaccia
config_vpn0="192.168.0.2 peer 192.168.1.1"

3.j. VLAN (supporto 802.1q)

Per il supporto alle VLAN installare net-misc/vconfig.

Virtual LAN è un gruppo di dispositivi di rete che si comportano come se fossero connessi ad un singolo segmento di rete, anche se realmente non lo sono. I membri della VLAN possono solo vedere i membri della stessa VLAN anche se potrebbero condividere la stessa rete.

Codice 10.1: Configurazione per la VLAN in /etc/conf.d/net

# Specificare i numeri VLAN per le interfacce in questo modo
# Assicurarsi che gli ID di VLAN NON abbiano degli zeri riempitivi
vlans_eth0="1 2"

# Si può anche configurare la VLAN
# vedere la pagina man di vconfig per ulteriori dettagli
vconfig_eth0="set_name_type VLAN_PLUS_VID_NO_PAD"
vconfig_vlan1="set_flag 1" "set_egress_map 2 6"

# Configurare l'interfaccia come al solito
config_vlan1=( "172.16.3.1 netmask 255.255.254.0"
config_vlan2=( "172.16.2.1 netmask 255.255.254.0"

Importante: Per usare alcune impostazioni di VLAN, è consigliabile consultare la documentazione relativa ai nomi di variabili.

4. Reti Wireless

4.a. Introduzione

Il networking Wireless su Linux è solitamente abbastanza semplice. Ci sono due modi per configurare il wifi: tramite client grafici o tramite linea di comando.

Il modo più facile è usare un client grafico, una volta installato un ambiente desktop. La maggior parte dei client grafici, come wicd e NetworkManager, sono abbastanza auto-esplicativi. Offrono una comoda interfaccia punta-e-clicca che permette di collegarsi alla rete in pochi secondi.

Nota: wicd offre uno strumento a linea di comando in aggiunta all'interfaccia grafica principale. Lo si può ottenere effettuando l'emerge di wicd con la flag USE ncurses abilitata. L'utilità wicd-curses è particolarmente indicata agli utenti che non usano un ambiente desktop basato sulle librerie gtk, ma che vogliono comunque uno strumento a linea di comando facile che non richiede la modifica manuale dei file di configurazione.

Tuttavia, se non si desidera utilizzare un client grafico,è possibile configurare wifi tramite la linea di comando modificando pochissimi file di configurazione. Ciò comporta un po' più di tempo per impostare il collegamento, ma richiede meno pacchetti da scaricare ed installare. Siccome i client grafici sono praticamente autoesplicativi (con schermate utilii nelle relative homepage), l'attenzione verrà concentrate sulle alternative a linea di comando.

È possibile impostare il collegamento alla rete wireless tramite linea di comando installando wireless-tools o wpa_supplicant. La cosa importante da ricordare è che è possibile configurare le reti wireless a livello globale e non in base all'interfaccia.

wpa_supplicant è la scelta migliore. Per un elenco di tutti i driver supportati, leggere il sito di wpa_supplicant.

wireless-tools supporta quasi tutte le schede e i driver, ma non può connettersi ad Access Point configurati solamente con WPA. Se la propria rete offre solamente la criptazione WEP o è completamente aperta, si potrebbe preferire la semplicità di wireless-tools.

Avvertenza: Il driver linux-wlan-ng non è supportato ancora da baselayout. Questo perchè linux-wlan-ng ha la propria installazione e configurazione che è differente da quella di tutti gli altri. Gli sviluppatori di linux-wlan-ng sembra vogliano cambiare le impostazioni a wireless-tools - quando accadrà si potrà usare linux-wlan-ng con baselayout.

4.b. WPA Supplicant

WPA Supplicant è un pacchetto che permette di connettersi ad access point WPA abilitati.

Codice 2.1: Installare wpa_supplicant

# emerge net-wireless/wpa_supplicant

Importante: Bisogna avere abilitato CONFIG_PACKET nel kernel per fare funzionare wpa_supplicant. Eseguire grep CONFIG_PACKET /usr/src/linux/.config per verificare se questa opzione è abilitata nel proprio kernel.

Nota: In base alle proprie flag USE, wpa_supplicant può installare un'interfaccia grafica scritta in Qt4, che si integrerà perfettamente con KDE. Per ottenerla, eseguire echo "net-wireless/wpa_supplicant qt4" >> /etc/portage/package.use come utente root prima di effettuare l'emerge di wpa_supplicant.

Configurare /etc/conf.d/net, per specificare l'utilizzo preferito di wpa_supplicant rispetto a wireless-tools (se entrambi sono installati, wireless-tools è quello predefinito).

Codice 2.2: Configurazione di /etc/conf.d/net per wpa_supplicant

# Si preferisce wpa_supplicant a wireless-tools
modules="wpa_supplicant"

# E' importante dire a wpa_supplicant quale driver dovrebbe
# essere usato in quanto non riesce ancora ad indovinarlo correttamente
wpa_supplicant_eth0="-Dmadwifi"

Nota: Se si sta usando il driver host-ap si deve mettere la scheda in Managed mode prima di usarla con wpa_supplicant. Per ottenere ciò, si può usare iwconfig_eth0="mode managed" in /etc/conf.d/net.

Semplice vero? Tuttavia c'è ancora da configurare wpa_supplicant che risulta essere un po' più difficile in base alla tipo di configurazione di sicurezza degli Access Point a cui si sta cercando di connettere. L'esempio seguente è preso e semplificato da /usr/share/doc/wpa_supplicant-<versione>/wpa_supplicant.conf.gz il quale viene fornito insieme a wpa_supplicant.

Codice 2.3: Un esempio di /etc/wpa_supplicant/wpa_supplicant.conf

# La riga sottostante non deve essere cambiata altrimenti non funziona
ctrl_interface=/var/run/wpa_supplicant

# Assicurarsi che solo root possa leggere la configurazione WPA
ctrl_interface_group=0

# Lasciare che wpa_supplicant si occupi della scansione e della selezione AP
ap_scan=1

# Caso semplice: WPA-PSK, PSK come un ASCII passphrase, permette tutte cifre valide
network={
  ssid="simple"
  psk="very secret passphrase"
  # Più alta è la priorità, prima c'è riconoscimento
  priority=5
}

# Lo stesso del precedente, ma è richiesto la scansione specifica per
# SSID (per AP che rifiutano il broadcast del SSID)
network={
  ssid="second ssid"
  scan_ssid=1
  psk="very secret passphrase"
  priority=2
}

# E' usato solo WPA-PSK. Qualsiasi combinazione di cifre valida è accettata
network={
  ssid="example"
  proto=WPA
  key_mgmt=WPA-PSK
  pairwise=CCMP TKIP
  group=CCMP TKIP WEP104 WEP40
  psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb
  priority=2
}

# Connessione plaintext (no WPA, no IEEE 802.1X)
network={
  ssid="plaintext-test"
  key_mgmt=NONE
}

# Connessione condivisa WEP key (no WPA, no IEEE 802.1X)
network={
  ssid="static-wep-test"
  key_mgmt=NONE
  # Le chiavi tra doppi apici sono in formato ASCII
  wep_key0="abcde"
  # Le chiavi specificate senza doppi apici sono in formato esadecimales
  wep_key1=0102030405
  wep_key2="1234567890123"
  wep_tx_keyidx=0
  priority=5
}

# Connessione condivisa WEP key (no WPA, no IEEE 802.1X) usando
# autenticazione Shared Key IEEE 802.11
network={
  ssid="static-wep-test2"
  key_mgmt=NONE
  wep_key0="abcde"
  wep_key1=0102030405
  wep_key2="1234567890123"
  wep_tx_keyidx=0
  priority=5
  auth_alg=SHARED
}

# Rete IBSS/ad-hoc con WPA-None/TKIP
network={
  ssid="test adhoc"
  mode=1
  proto=WPA
  key_mgmt=WPA-NONE
  pairwise=NONE
  group=TKIP
  psk="secret passphrase"
}

4.c. Wireless Tools

Impostazione iniziale e Managed Mode

Wireless Tools forniscono un modo generico di configurare le interfacce wireless di base fino al livello di sicurezza WEP. Sebbene WEP sia un metodo di sicurezza debole, è anche quello prevalente.

La configurazione di Wireless Tools è controllata da poche variabili principali. L'esempio di configurazione seguente dovrebbe descrivere tutto il necessario. Una cosa da tenere in mente è che nessuna configurazione significa "connesso al più forte non criptato Access Point" - si cerca e ci si connette sempre a qualcosa.

Codice 3.1: Installare wireless-tools

# emerge net-wireless/wireless-tools

Nota: Si possono mettere le impostazioni wireless in /etc/conf.d/wireless, ma questa guida raccomanda di metterle in /etc/conf.d/net.

Importante: Si deve consultare la guida nomi di variabili.

Codice 3.2: Esempio di impostazione iwconfig in /etc/conf.d/net

# Si preferisce iwconfig a wpa_supplicant
modules="iwconfig"

# Configurare le chiavi WEP per gli Access Point denominati ESSID1 e ESSID2
# Si potrebbero configurare fino a 4 chiavi WEP, ma si utilizzarne solamente 1 alla volta
# per cui si fornisce un indice predeinito di [1] per impostare la chiave [1] e in
# seguito cambiare la chiave attiva a [1]
# Viene fatto questo in caso si definiscano altri ESSID per usare chiavi WEP diverse da 1
#
# Prefissare la chiave con s: significa che è una chiave ASCII, altrimenti è una chiave esadecimale (HEX)
#
# enc open specificata sicurezza aperta (più sicura)
# enc restricted specificata sicurezza ristretta (meno sicura)
key_ESSID1="[1] s:tuachiavequi key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"

# Il seguente funziona solo quando si cercano Access Point disponibili

# Qualche volta è visibile più di un Access Point per cui si deve
# definire un ordine preferito per connettersi
preferred_aps="'ESSID1' 'ESSID2'"

Regole personalizzate per la selezione degli Access Point

Si possono aggiungere alcune opzioni extra per raffinare la selezione degli Access Point, ma normalmente non sono richieste.

Si può decidere se ci si connette solo a Access Point preferiti o no. Come regola predefinita se ogni configurazione fallisce e ci si può connettere a un Access Point non criptato allora va bene. Questo può essere controllato dalla variabile associate_order. Ecco una tabella di valori e come essi controllano questo aspetto.

Valore	Descrizione
any	Comportamento predefinito
preferredonly	Ci si connette solo ad AP visibili nell'elenco preferito
forcepreferred	Ci si connette ad AP nell'ordine preferito se non sono stati trovati in una scansione
forcepreferredonly	Non fa la scansione per gli AP, invece cerca di connettere a ognuno di essi in ordine
forceany	Uguale a forcepreferred, in più si connette ad ogni altro AP disponibile

Infine sono disponibili alcune selezioni blacklist_aps e unique_ap. blacklist_aps funziona in modo simile a preferred_aps. unique_ap è un valore yes o no che dice se una seconda interfaccia wireless può connettersi allo stesso Access Point come la prima interfaccia.

Codice 3.3: Esempio di blacklist_aps e unique_ap

# Qualche volta non ci si vuole connettere a alcuni access point
blacklist_aps="'ESSID3' 'ESSID4'"

# Se si possiede più di una scheda wireless, è possibile dare il
# permesso a ogni scheda di associarsi (o no) allo stesso Access Point
# Valori sono "yes" e "no"
# Predefinito è "yes"
unique_ap="yes"

Modi Ad-Hoc e Master

Si può volere una impostazione Ad-Hoc se non si riesce a connettere a un Access Point con la modalità "managed".

Codice 3.4: Tornare al modo ad-hoc

adhoc_essid_eth0="This Adhoc Node"

C'è una configurazione apposita per connettersi a reti Ad-Hoc o funzionare in modo Master per trasformarsi in un Access Point, ricordarsi comunque di specificare le chiavi WEP come mostrato in precedenza.

Codice 3.5: Esempio di configurazione ad-hoc/master

# Impostare il modo - può essere managed (predefinito), ad-hoc o master
# Non tutti i driver supportano tutti i modi
mode_eth0="ad-hoc"

# Impostare il ESSID dell'interfaccia
# Nel modo managed, questo forza l'interfaccia ad effettuare un tentativo di connessione
# solamente al ESSID specificato
essid_eth0="This Adhoc Node"

# Viene usato il canale 3 se non ne viene specificato uno
channel_eth0="9"

Importante: L'esempio precedente è preso dalla documentazione BSD che si trova nella documentazione NetBSD. Sono possibili 14 canali; i canali 1-11 sono legali per il Nord America, canali 1-13 per la maggior parte dell'Europa, canali 10-13 per la Francia, e solo il canale 14 per il Giappone. Per ulteriori chiarimenti si rimanda alla documentazione della propria scheda o dell'access point. Assicurarsi che il canale selezionato sia lo stesso canale dell'access point (o dell'altra scheda in una rete ad-hoc). L'impostazione predefinita per le schede vendute in Nord America e nella maggior parte dell'Europa è 3, quella predefinita per le schede vendute in Francia è 11, e quella predefinita per le schede vendute in Giappone è 14.

Risoluzione di problemi con Wireless Tools

Ci sono alcune variabili che possono aiutare a far funzionare la propria rete wireless, conseguentemente a problemi di driver o di ambiente. Ecco una tabella contenente altre opzioni che si possono provare.

Variabile	Valore predefinito	Descrizione
iwconfig_eth0		Vedere la pagina man di iwconfig per dettagli su cosa è possibile indicare a iwconfig
iwpriv_eth0		Vedere la pagina man di iwpriv per dettagli su cosa è possibile indicare a iwpriv
sleep_scan_eth0	0	Il numero di secondi che aspetta prima di fare la scansione. E' necessario quando il driver/firmware ha bisogno di più tempo per attivarsi prima che possa essere usato.
sleep_associate_eth0	5	Il numero di secondi che aspetta l'interfaccia per associarsi con l'Access Point prima di spostarsi al prossimo
associate_test_eth0	MAC	Alcuni driver non resettano l'indirizzo MAC associato con uno invalido quando perdono o cercano di effettuare un'associazione. Alcuni driver non resettano il livello di qualità quando perdono o cercano di effettuare un'associazione. Impostazioni valide sono MAC, quality e all.
scan_mode_eth0		Alcuni driver devono fare la scansione nel modo ad-hoc, così se questa fallisce cercano di impostare ad-hoc qui
iwpriv_scan_pre_eth0		Manda alcuni comandi iwpriv all'interfaccia prima della scansione. Vedere la pagina man di iwpriv per altre informazioni
iwpriv_scan_post_eth0		Manda alcuni comandi iwpriv alla interfaccia dopo la scansione. Vedere la pagina man di iwpriv per altre informazioni

4.d. Definire la configurazione di rete per ESSID

Qualche volta quando ci si connette a ESSID1 si deve avere un IP statico e quando ci si connette a ESSID2 si deve avere DHCP. La maggior parte delle variabili dei moduli possono essere definite per ESSID. Ecco come farlo.

Nota: Funzionano se si usa WPA Supplicant o Wireless Tools.

Importante: Si deve consultare la guida nomi di variabili.

Codice 4.1: Sovrapporre le impostazioni di rete per ESSID

config_ESSID1="192.168.0.3/24 brd 192.168.0.255"
routes_ESSID1="default via 192.168.0.1"

config_ESSID2="dhcp"
fallback_ESSID2="192.168.3.4/24"
fallback_route_ESSID2="default via 192.168.3.1"

# Si possono definire nameserver e altre cose
# NOTARE: DHCP sovrappone queste impostazioni a meno che
# gli venga detto di non farlo
dns_servers_ESSID1="192.168.0.1 192.168.0.2"
dns_domain_ESSID1="some.domain"
dns_search_domains_ESSID1="search.this.domain search.that.domain"

# Si sovrappone dall'indirizzo MAC dell'Access Point
# E' pratico se si va a posizioni differenti che hanno lo stesso ESSID
config_001122334455="dhcp"
dhcpcd_001122334455="-t 10"
dns_servers_001122334455="192.168.0.1 192.168.0.2"

5. Ulteriori funzionalità

5.a. Funzioni di hook (intercettazioni) standard

Possono essere definite quattro funzioni in /etc/conf.d/net, che sono chiamate in prossimità delle operazioni di avvio/chiusura. Le funzioni sono chiamate con il nome dell'interfaccia in modo che una funzione possa controllare adattatori multipli.

I valori di ritorno per le funzioni preup e predown dovrebbero essere 0 (successo) per indicare che la configurazione o la deconfigurazione dell'interfaccia può continuare. Se preup ritorna con un valore diverso da zero, allora la configurazione dell'interfaccia viene chiusa. Se predown ritorna con un valore diverso da zero, allora all'interfaccia non viene permesso di continuare la deconfigurazione.

I valori di ritorno per le funzioni postup e postdown sono ignorati poichè non c'è niente da fare se indicano un fallimento.

${IFACE} è impostata sull'interfaccia che viene portata sù/giù (up/down). ${IFVAR} è ${IFACE} convertita al nome della variabile che bash permette.

Codice 1.1: Esempi di funzione pre/post up/down in /etc/conf.d/net

preup() {
  # Test per link sull'interfaccia prima di avviarla. Questo
  # funziona solo su alcuni adattatori di rete e richiede che il pacchetto
  # ethtool sia installato.
  if ethtool ${IFACE} | grep -q 'Link detected: no'; then
    ewarn "No link on ${IFACE}, aborting configuration"
    return 1
  fi

  # Ricordarsi di restituire 0 in caso di successo
  return 0
}

predown() {
  # L'azione predefinita nello script è eseguire un test per NFS root e non permettere
  # che in quel caso le interfacce vengano disattivate. Notare che se si specifica una funzione
  # predown() si sovrappone questa logica, mostrata in dettaglio qui di seguito, in caso
  # la si voglia usare...
  if is_net_fs /; then
    eerror "root filesystem is network mounted -- can't stop ${IFACE}"
    return 1
  fi

  # Ricordarsi di restituire 0 in caso di successo
  return 0
}

postup() {
  # Questa funzione potrebbe essere usata, per esempio, per
  # registrarsi ad un servizio dinamico DNS. Un'altra possibilità potrebbe essere
  # mandare/ricevere mail quando l'interfaccia è avviata.
       return 0
}

postdown() {
  # Questa funzione viene utilizzata perlopiù per completezza. Attualmente
  # non c'è mai stato bisogno di utilizzarla.
  return 0
}

Nota: Per maggiori informazioni su come scrivere le proprie funzioni, si prega di leggere /usr/share/doc/openrc-*/net.example.bz2.

5.b. Funzioni di hook (intercettazioni) per "Wireless Tools"

Nota: Non funziona con WPA Supplicant - ma le variabili ${ESSID} e ${ESSIDVAR} sono disponibili nella funzione postup()

Possono essere definite due funzioni /etc/conf.d/net, che sono chiamate in prossimità della funzione associata. Le funzioni sono chiamate con il nome dell'interfaccia in modo che una funzione possa controllare adattatori multipli.

I valori di ritorno per la funzione preassociate dovrebbero essere 0 (successo) per indicare che la configurazione o la deconfigurazione dell'interfaccia può continuare. Se la preassociate ritorna un valore diverso da zero, allora la configurazione dell'interfaccia viene chiusa.

Il valore di ritorno per la funzione postassociate è ignorato poichè non c'è niente da fare se indica un fallimento.

${ESSID} è impostata all'esatto ESSID dell'AP con cui si è connessi. ${ESSIDVAR} è ${ESSID} convertita al nome della variabile che bash permette.

Codice 2.1: Funzioni di associazione pre/post in /etc/conf.d/net

preassociate() {
  # Il codice seguente aggiunge due variabili di configurazione
  # leap_user_ESSID e leap_pass_ESSID. Quando sono entrambe configurate per
  # essere connesse a ESSID, viene eseguito lo script CISCO LEAP

  local user pass
  eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
  eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"

  if [[ -n ${user} && -n ${pass} ]]; then
    if [[ ! -x /opt/cisco/bin/leapscript ]]; then
      eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
      return 1
    fi
    einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
    if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
      ewarn "Login Failed for ${user}"
      return 1
    fi
  fi

  return 0
}

postassociate() {
  # Questa funzione viene utilizzata perlopiù per completezza. Attualmente
  # non c'è mai stato bisogno di utilizzarla.

  return 0
}

Nota: ${ESSID} e ${ESSIDVAR} non sono disponibili nelle funzioni predown() e postdown()

Nota: Per maggiori informazioni su come scrivere le proprie funzioni, si prega di leggere /usr/share/doc/openrc-*/net.example.bz2.

6. Gestione della rete

6.a. Gestione di rete

Se si è sempre in movimento con il proprio computer, non sempre è disponibile un cavo ethernet o un access point. Inoltre, se un cavo di rete viene inserito o viene trovato un access point, si potrebbe desiderare che i propri servizi di rete funzionino automaticamente.

Di seguito vengono elencati alcuni strumenti utili alla gestione della rete.

Nota: Questo documento parla solo di ifplugd, ma ci sono alternative come netplug. netplug è un'alternativa a ifplugd molto leggera, ma dipende dal corretto funzionamento dei driver di rete del kernel, e molti driver purtroppo non lo fanno.

6.b. ifplugd

ifplugd è un demone che avvia e chiude le interfacce quando si inserisce o rimuove un cavo ethernet. Può anche gestire la rilevazione associazioni agli Access Point o quando dei nuovi Access Point entrano nel raggio di copertura.

Codice 2.1: Installare ifplugd

# emerge sys-apps/ifplugd

La configurazione di ifplugd è molto semplice. Il file di configurazione è /etc/conf.d/ifplugd. Eseguire man ifplugd per dettagli sulle variabili disponibili. Inoltre vedere /usr/share/doc/openrc-*/net.example.bz2 per ulteriori esempi.

Codice 2.2: Configurazione d'esempio per ifplug

(Sostituire eth0 con l'interfaccia da monitorare)
ifplugd_eth0="..."

(Per monitorare un'interfaccia wireless)
ifplugd_eth0="--api-mode=wlan"

In aggiunta alla gestione di connessioni di rete multiple, è possibile aggiungere uno strumento che facilita il funzionamento con molteplici server DNS e configurazioni; ciò è molto pratico se si riceve l'indirizzo IP tramite DHCP. Per installarlo, effettuare l'emerge di openresolv.

Codice 2.3: Installare openresolv

# emerge openresolv

Vedere man resolvconf per saperne di più riguardo alle sue caratteristiche.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.

Stampa

Aggiornato il 12 novembre 2012

Questa traduzione non è più mantenuta

Oggetto: Questo è il Manuale Gentoo che ha l'obiettivo di centralizzare la documentazione di Gentoo Linux. Questo manuale contiene le istruzioni per una installazione senza rete su sistemi AMD64 & EM64T e le parti su lavorare con Gentoo e Portage.

Sven Vermeulen
Autore

Grant Goodyear
Autore

Roy Marples
Autore

Daniel Robbins
Autore

Chris Houser
Autore

Jerry Alexandratos
Autore

Joshua Saddler
Autore

Seemant Kulleen
Sviluppo x86

Tavis Ormandy
Sviluppo Alpha

Jason Huebel
Sviluppo AMD64

Guy Martin
Sviluppo HPPA

Pieter Van den Abeele
Sviluppo PPC

Joe Kallar
Sviluppo SPARC

John P. Davis
Redazione

Pierre-Henri Jondot
Redazione

Eric Stockbridge
Redazione

Rajiv Manglani
Redazione

Jungmin Seo
Redazione

Stoyan Zhekov
Redazione

Jared Hudson
Redazione

Colin Morey
Redazione

Jorge Paulo
Redazione

Carl Anderson
Redazione

Jon Portnoy
Redazione

Zack Gilburd
Redazione

Jack Morgan
Redazione

Benny Chuang
Redazione

Erwin
Redazione

Joshua Kinard
Redazione

Tobias Scherbaum
Redazione

Xavier Neys
Redazione

Shyam Mani
Redazione

Gerald J. Normandin Jr.
Revisione

Donnie Berkholz
Revisione

Ken Nowack
Revisione

Lars Weiler
Contributi

Marco Mascherpa
Traduzione

Stefano Pacella
Traduzione

Enrico Morelli
Traduzione

Donate to support our development efforts.