Gentoo Logo

Disclaimer : Questo manuale è stato sostituito da una nuova versione e non è più mantenuto.

Manuale Gentoo Linux 2005.0 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 CD di installazione Universale
      Con il CD di installazione Universale si può avviare il sistema in un ambiente funzionante, che permette di installare Gentoo.
    3. Configurazione della rete
      Se si ha bisogno delle impostazioni di rete, in questo capitolo si configura la rete e una connessione a Internet.
    4. Preparazione dei dischi
      Per poter installare Gentoo è necessario creare delle partizioni. Questo capitolo descrive come partizionare un disco.
    5. Copia dei file di installazione di Gentoo
      In questo capitolo si descrive come estrarre uno stage3 e come configurare Portage.
    6. Effettuare il chroot in un sistema base Gentoo
      Dopo l'estrazione dello stage3, si effettua il chroot in un nuovo sistema e si modifica la variabile USE.
    7. Configurazione del Kernel
      Il kernel di Linux è il cuore di ogni distribuzione. Il capitolo tratta della configurazione del Kernel.
    8. Configurazione del sistema
      E' necessario modificare alcuni importanti file di configurazione. In questo capitolo si dà una panoramica di questi file e dei cambiamenti da eseguire.
    9. Installazione degli strumenti di sistema
      Come già accennato, la forza di Gentoo è la varietà di scelta. Questo capitolo riguarda la scelta della versione e l'installazione degli strumenti di sistema.
    10. Configurazione del Bootloader
      In questo capitolo sarà descritto il Bootloader GRUB, e si vedrà la sua configurazione in base alle proprie necessità.
    11. Termine dell'installazione Gentoo
      E' quasi finita. Si creano uno o più utenti nel nuovo sistema e opzionalmente si installano i pacchetti precompilati.
    12. 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.
    6. L'applicativo Ebuild
      E' la documentazione ufficiale riguardante l'applicazione ebuild che Portage utilizza durante il processo di installazione del software e che può anche essere utilizzata separatamente dall'utente finale.
  • 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

Benvenuto

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 scelte sono ciò che sta alla base di Gentoo. L'obiettivo è di non forzare mai l'utente a qualcosa che non desidera. Nel caso si abbia un'impressione diversa è possibile segnalarlo.

Struttura dell'installazione

L'installazione di Gentoo può essere divisa in una procedura di dieci passi elementari, corrispondenti ai capitoli 2-11. Ogni passo ha come risultato uno stato intermedio:

  • Al termine del passo 1, è pronto l'ambiente di lavoro per l'installazione di Gentoo
  • Al termine del passo 2, è stata configurata la connessione ad internet per l'installazione; questo passo è opzionale
  • Al termine del passo 3, gli hard disk sono stati inizializzati ad accogliere l'installazione Gentoo
  • Al termine del passo 4, l'ambiente di installazione è pronto e ci si chroota nel nuovo ambiente
  • Al termine del passo 5, i pacchetti di sistema, identici per ogni genere di installazione, sono stati installati
  • Al termine del passo 6, è stato configurato il kernel
  • Al termine del passo 7, sono stati scritti la maggior parte dei file di configurazione Gentoo
  • Al termine del passo 8, sono stati installati una serie di strumenti di sistema, da scegliere da una lista
  • Al termine del passo 9, il proprio bootloader preferito è stato installato e configurato e si ha a disposizione il proprio ambiente Gentoo
  • Al termine del passo 10, si è pronti ad utilizzare Gentoo

Al momento in cui si presenta una scelta viene fatto il possibile per illustrare quali siano i pro e i contro. La guida continua 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.

Quali sono le opzioni?

Si può installare Gentoo in molti modi differenti. Si può scaricare e installare da uno degli InstallationCD (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 Universale, un CD bootable, che contiene tutto ciò di cui si ha bisogno per installare ed eseguire Gentoo Linux. Si può anche usare uno dei CD di pacchetti per installare un sistema completo in pochi minuti, dopo aver installato il sistema base Gentoo.

Con questo metodo non si utilizzeranno 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.

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. Rapida installazione con la 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 KDE, 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ò solo beneficiare dei pacchetti GRP forniti da Gentoo, 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 x86 (x86, athlon-xp, pentium3, pentium4) Notare che i pacchetti x86 (packages-x86-2005.0.iso) sono disponibili sui nostri mirror, mentre quelli per pentium3, pentium4 e athlon-xp sono disponibili solo via bittorrent.
  • L'architettura amd64 (amd64)
  • L'architettura sparc (sparc64)
  • L'architettura ppc (G3, G4, G5)
  • L'architettura alpha

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 CD di Installazione Universale.

2. Avviare l'installazione con il CD di installazione Universale

2.a. Richieste Hardware

Introduzione

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

Richieste hardware

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

Nota: * Processori Intel con estensioni EM64T potrebbero funzionare, ma non sono testati.

Si dovrebbe controllare la Gentoo AMD64 Project Page prima di continuare.

2.b. Il CD di installazione Gentoo Universale

Introduzione

Gentoo Linux può essere installato tramite uno dei tre stage, che sono archivi compressi tar che contengono un ambiente minimale.

  • Lo stage1 non contiene niente altro che un compilatore, Portage (il sistema di gestione dei pacchetti di Gentoo) e alcuni pacchetti sui quali dipende il compilatore o Portage.
  • Lo stage2 contiene un sistema in cui si è già fatto il bootstrap, un ambiente minimale dal quale si può iniziare a compilare tutte le altre applicazioni necessarie per ottenere un ambiente completo Gentoo.
  • Lo stage3 contiene un sistema minimale già compilato, pronto da utilizzare. Mancano le applicazioni che l'utente di Gentoo deve scegliere quali sono da installare o meno.

In questo documento si opta per una installazione con lo stage3. Se si desidera effettuare una installazione Gentoo con lo stage1 o lo stage2, si devono usare le istruzioni di installazione del Manuale Gentoo. E' richiesta una connessione a Internet per questa.

CD di installazione Gentoo Universale

Un CD di installazione è 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 CD di installazione Universale 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.

Gentoo fornisce anche un CD di pacchetti. Non è un CD di installazione, ma una risorsa ulteriore che può essere sfruttata durante una installazione di Gentoo. Contiene pacchetti precompilati (GRP) che permettono di installare facilmente e rapidamente applicazioni (come OpenOffice.org, KDE, GNOME, ...), dopo una installazione di Gentoo e prima di aggiornare il Portage tree.

L'uso del CD di pacchetti è trattato più avanti.

2.c. Scaricare, masterizzare e bootare il CD di installazione Gentoo Universale

Scaricare e masterizzare il CD di installazione

Si possono scaricare i CD di installazione Universali (e se lo si desidera, anche il CD di pacchetti), su uno dei nostri mirror. I CD di installazione sono nella directory releases/amd64/2005.0/installcd; i CD di pacchetti sono nella directory releases/amd64/2005.0/packagecd.

Dentro quella directory si troveranno file ISO. Questi sono 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 pgp.mit.edu --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 CD di installazione Universale

Una volta masterizzato i CD 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 CD 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 sui CD 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 con NUMA
gentoo-em64t Uguale a gentoo, ma compilato per gen. x86-64 con supporto SMP

E' possibile anche selezionare opzioni per il kernel. Si tratta di direttive particolari che possono essere attivate o meno a piacere. La seguente tabella descrive tutte le opzioni del kernel disponibili.

Codice 3.3: Opzioni del boot disponibili

- agpgart       loads agpgart (use if you have graphic problems,lockups)
- acpi=on       loads support for ACPI firmware
- ide=nodma     force disabling of DMA for malfunctioning IDE devices
- doscsi        scan for scsi devices (breaks some ethernet cards)
- dopcmcia      starts pcmcia service for PCMCIA cdroms
- nofirewire    disables firewire modules in initrd (for firewire cdroms,etc)
- nokeymap      disables keymap selection for non-us keyboard layouts
- docache       cache the entire runtime portion of cd in RAM, allows you
                to umount /mnt/cdrom to mount another cdrom.
- nodetect      causes hwsetup/kudzu and hotplug not to run
- nousb         disables usb module load from initrd, disables hotplug
- nodhcp        dhcp does not automatically start if nic detected
- nohotplug     disables loading hotplug service
- noapic        disable apic (try if having hardware problems nics,scsi,etc)
- noevms2       disable loading of EVMS2 modules
- nolvm2        disable loading of LVM2 modules
- hdx=stroke    allows you to partition the whole harddrive even when your BIOS
                can't handle large harddrives
- noload=module1[,module2[,...]]
                disable loading of specific kernel modules

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 F2 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 è automaticamente nell'ambiente "Live" Gentoo Linux come "root", l'utente amministratore. Ci dovrebbe essere un prompt di root a schermo ("#") e dovrebbe essere possibile passare ad altre console premendo Alt-F2, Alt-F3 e Alt-F4 e tornare alla precedente premendo Alt-F1.

Continuare ora con la Configurazione dell'Hardware Extra.

Configurazione dell'hardware extra

Al momento del boot il CD 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.5: Caricamento dei moduli del kernel

# modprobe 8139too

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

Codice 3.6: 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. Con le opzioni -tT è possibile testare le performance del proprio disco (eseguire il test alcune volte per avere risultati più precisi):

Codice 3.7: 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.8: Ottimizzazione delle performance del disco

Attivare il DMA:                                          # hdparm -d 1 /dev/hda
Attivare il DMA e altre 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.

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

Codice 3.9: Cambiare la password di root

# passwd
New password: (Inserire la nuova password)
Re-enter password: (Inserire nuovamente la nuova 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.10: 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.11: Cambiare utente

# su - john

Opzionale: Vedere la documentazione mentre si installa

Se si desidera vedere il Manuale Gentoo (da un CD o online) durante l'installazione, assicurarsi di aver creato un account di un utente (vedere Opzionale: Account utente). Poi premere Alt-F2 per andare in un nuovo terminale, e quindi fare il log in.

Se si desidera vedere la documentazione sul CD si può immediatamente eseguire links2 per leggerla:

Codice 3.12: Vedere la documentazione sul CD

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

Tuttavia, è preferito usare il Manuale Gentoo online poichè è più recente di quello sul CD. Si può vederlo con links2, ma solo dopo avere completato il capitolo Configurazione della rete (altrimenti non si potrà andare su Internet per vedere il documento):

Codice 3.13: Vedere la documentazione online

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

Si può tornare al terminale originale premendo Alt-F1.

Opzionale: Avviare un demone SSH

Se si desidera consentire ad altri utenti l'accesso al pc durante l'installazione di Gentoo (magari perchè qualcuno di essi potrebbe essere di aiuto o addirittura condurre personalmente l'installazione), è necessario creare un account per ciascuno di essi o condividere con loro la password di root (solo se si confida pienamente in tale utente).

Per avviare il demone SSH, eseguire il seguente comando:

Codice 3.14: Avviare il demone SSH

# /etc/init.d/sshd start

Per potere usare sshd, si deve prima impostare la rete. Continuare con il capitolo Configurazione della rete.

3. Configurazione della rete

3.a. Si ha bisogno della rete?

Chi può farne a meno?

Generalmente, non è necessario avere una connesione di rete per installare Gentoo con il CD di Installazione Universale. Ma ci sono alcune circostanze in cui si può desiderare di avere una connessione a Internet:

  • Gli stage3 che sono nel CD di Installazione Universale non corrispondono alla propria architettura e si deve scaricare il corretto stage
  • Si deve installare una applicazione specifica per la rete, che permetterà la connessione a Internet, la quale non è disponibile sul CD di Installazione Universale ma è supportata (per esempio, si può connettersi a Internet con il CD di Installazione ma i sorgenti necessari non sono disponibili sul CD)
  • Si desidera assistenza remota durante una installazione (con SSH o con le conversazioni dirette con IRC)

Chi ha bisogno della rete?

Per scoprire se lo stage3 è disponibile per la propria architettura, si deve vedere nel /mnt/cdrom/stages e controllare se uno degli stage disponibili corrispondono alla propria architettura. Se non è così, si può ancora optare per uno stage3 di una architettura compatibile con la propria.

Se si desidera usare uno stage3 ottimizzato per la propria architettura ma lo stage3 non è disponibile, allora si avrà bisogno della rete per scaricare lo stage3 appropriato.

Se non si ha bisogno della rete, si può saltare il resto di questo capitolo e continuare con Preparazione dei dischi. Se invece si ha bisogno di configurare la rete, continuare con la sezione sotto.

3.b. Rilevamento automatico della rete

Potrebbe già funzionare

Se il sistema è collegato ad una rete Ethernet attraverso un server DHCP, è molto probabile che la configurazione di rete sia già stata completata automaticamente. In questo caso è già possibile usufruire dei vari comandi di rete inclusi nel CD di Installazione quali ssh, scp, ping, irssi, wget, links e molti altri.

Se la rete è già stata configurata il comando /sbin/ifconfig dovrebbe elencare alcune interfacce di rete oltre a lo, come ad esempio eth0:

Codice 2.1: Output di /sbin/ifconfig per una configurazione corretta

# /sbin/ifconfig
(...)
eth0      Link encap:Ethernet  HWaddr 00:50:BA:8F:61:7A
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1984 txqueuelen:100
          RX bytes:485691215 (463.1 Mb)  TX bytes:123951388 (118.2 Mb)
          Interrupt:11 Base address:0xe800 

Opzionale: Configurare i Proxy

Se l'accesso a Internet avviene attraverso un proxy, si potrebbe aver bisogno di configurare i parametri del proxy durante l'installazione. E' molto facile definire un proxy: basta definire una variabile che contiene le informazioni del server proxy.

Nella maggior parte dei casi, si definisce la variabile usando l'hostname del server. Ad esempio, si assuma che il proxy sia chiamato proxy.gentoo.org e che la porta sia la 8080.

Codice 2.2: Definire i server proxy

(Se il proxy filtra il traffico HTTP)
# export http_proxy="http://proxy.gentoo.org:8080"
(Se il proxy filtra il traffico FTP)
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
(Se il proxy filtra il traffico RSYNC)
# export RSYNC_PROXY="rsync://proxy.gentoo.org:8080"

Se il proxy richiede una username e una password, si dovrebbe usare la seguente sintassi per la variabile:

Codice 2.3: Aggiungere username/password alla variabile del proxy

http://username:password@proxy.gentoo.org:8080

Testare la Rete

Potrebbe essere utile fare il ping sul server DNS dell'ISP (si può trovare in /etc/resolv.conf) e su un sito Web a scelta, per assicurarsi che i pacchetti stiano raggiungendo la rete, che la risoluzione dei domi di dominio stia funzionando correttamente, eccetera.

Codice 2.4: Ulteriore test della rete

# ping -c 3 www.yahoo.com

La rete è funzionante? Se è così, si può saltare il resto di questa sezione e continuare con la Preparazione dei Dischi. Se non è così, sfortunatamente, si deve proseguire in altro modo.

3.c. Configurazione Automatica della Rete

Se la rete non funziona immediatamente, alcune modalità di installazione permettono di usare net-setup (per le reti normali o wireless) o adsl-setup (per gli utenti ADSL) o pptp (per gli utenti PPTP, disponibile solo per sistemi x86).

Se la modalità di installazione non prevede nessuno di questi tool o la rete non funziona ancora, continuare con la Configurazione Manuale della Rete.

Default: Usare net-setup

Il modo più semplice di installare la rete se non è configurata automaticamente è eseguire lo script net-setup:

Codice 3.1: Eseguire lo script net-setup

# net-setup eth0

net-setup pone alcune domande sull'ambiente di rete. Al termine si dovrebbe avere una connessione di rete attiva. Si verifichi il collegamento. Se i test sono positivi, congratulazioni! Si è pronti per installare Gentoo. Saltare il resto di questa sezione e continuare con la Preparazione dei Dischi.

Se la rete ancora non funziona, continuare con la Configurazione Manuale della Rete.

Alternativa: Usare RP-PPPoE

Se c'è bisogno di PPPoE per connettersi a internet, il CD di Installazione (qualsiasi versione) rende le cose facili perchè include rp-pppoe. Usare lo script fornito adsl-setup per configurare la connessione. Viene richiesto di inserire il dispositivo Ethernet che è collegato al modem adsl, lo username e la password, gli IP dei server DNS e se si ha bisogno un firewall di base o meno.

Codice 3.2: Usare rp-pppoe

# adsl-setup
# adsl-start

Se qualcosa andasse storto, ricontrollare di avere digitato correttamente lo username e la password controllando /etc/ppp/pap-secrets o /etc/ppp/chap-secrets e assicurarsi di stare usando il giusto dispositivo ethernet. Se il dispositivo ethernet non esiste, si deve caricare il modulo appropriato di rete. In questo caso si dovrebbe continuare con la Configurazione Manuale della Rete dove si spiega come caricare l'appropriato modulo di rete.

Se funziona tutto, continuare con la Preparazione dei Dischi.

Alternativa: Usare PPTP

Nota: PPTP è disponibile solo per architettura x86.

Se si ha bisogno del supporto PPTP, si può usare pptpclient che è fornito dai CD di Installazione. Ma prima bisogna assicurarsi che la configurazione sia corretta. Modificare /etc/ppp/pap-secrets o /etc/ppp/chap-secrets in modo che contenga la corretta combinazione username/password:

Codice 3.3: Modificare /etc/ppp/chap-secrets

# nano -w /etc/ppp/chap-secrets

Modificare se necessario /etc/ppp/options.pptp:

Codice 3.4: Modificare /etc/ppp/options.pptp

# nano -w /etc/ppp/options.pptp

Quando si è finito, eseguire pptp (con le opzioni che non si possono impostare in options.pptp) per connettere il server:

Codice 3.5: Connessione a un server dial-in

# pptp <server ip>

Ora continuare con la Preparazione dei Dischi.

3.d. Configurazione Manuale della Rete

Caricare gli Appropriati Moduli di Rete

Quando si effettua il boot con il CD di Installazione, quest'ultimo prova a rilevare tutti i dispositivi hardware e carica i moduli (driver) appropriati del kernel per supportare l'hardware. Nella grande maggioranza dei casi, l'operazione ha successo. Tuttavia, in alcuni casi, potrebbe non caricare automaticamente i moduli del kernel di cui si ha bisogno.

Se net-setup o adsl-setup non dessero buoni risultati, si può di sicuro supporre che la scheda di rete non è stata trovata immediatamente. Ciò significa che è necessario caricare gli appropriati moduli del kernel manualmente.

Avvertenza: Alcuni CD di Installazione sono privi di supporto per i moduli. Ciò significa che tutti i driver forniti sono già stati caricati. Se la scheda non è stata rilevata è possibile segnalare un bug agli sviluppatori che aggiornaranno il CD di Installazione.

Per scoprire quali moduli del kernel sono disponibili per la rete, usare ls:

Codice 4.1: Cercare i moduli disponibili

# ls /lib/modules/`uname -r`/kernel/drivers/net

Se si trova un driver per la scheda di rete, utilizzare modprobe per caricare il modulo del kernel:

Codice 4.2: Utilizzare modprobe per caricare un modulo del kernel

(Come esempio, si carica il modulo pcnet32)
# modprobe pcnet32

Per controllare se la scheda di rete è stata rilevata, eseguire ifconfig. Una scheda di rete rilevata dovrebbe produrre un risultato simile a questo:

Codice 4.3: Test della disponibilità della scheda di rete andato a buon fine

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          BROADCAST NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Se invece si riceve il seguente errore, la sheda di rete non è rilevata:

Codice 4.4: Test della disponibilità della scheda di rete non andato a buon fine

# ifconfig eth0
eth0: error fetching interface information: Device not found

Se si possiedono più schede di rete nel sistema, esse vengono etichettate rispettivamente eth0, eth1, ecc. Assicurarsi che la scheda che si desidera utilizzare sia funzionante e ricordarsi di utilizzare il nome corretto nelle operazioni successive. Nel resto del documento si fa riferimento alla scheda eth0.

Una volta rilevata una scheda di rete, si può eseguire di nuovo net-setup o adsl-setup (che adesso dovrebbero funzionare), ma per i puristi ecco come configurare la rete a mano.

Scegliere una delle seguenti sezioni a seconda della propria configurazione:

Usare un DHCP

Il DHCP (Dynamic Host Configuration Protocol) rende possibile ricevere automaticamente le informazioni sulla rete (indirizzo IP, netmask, indirizzo broadcast, gateway, nameserver ecc.). Funziona soltanto se si ha un server DHCP nella rete (o se il provider fornisce un servizio DHCP). Per avere una interfaccia di rete che riceva queste informazioni automaticamente, utilizzare dhcpcd:

Codice 4.5: Utilizzo di dhcpcd

# dhcpcd eth0
Alcuni amministratori di rete richiedono di utilizzare gli
hostname e nomi di dominio forniti dal server DHCP.
Nel caso utilizzare
# dhcpcd -HD eth0

Se funziona (provare a pingare alcuni server internet, come Google), allora è stato tutto configurato e si è pronti per continuare. Saltare il resto di questa sezione e continuare con la Preparazione dei Dischi.

Preparing for Wireless Access

Nota: Il supporto per il comando iwconfig è disponibile solo sui CD di Installazione x86, amd64 e ppc. E' possibile comunque mettere in funzione la periferica seguendo le istruzioni del linux-wlan-ng project.

Se si sta utilizzando una scheda wireless (802.11), potrebbe essere necessario configurare i parametri wireless prima di continuare. Per visualizzare gli attuali parametri wireless della propria scheda è possibile utilizzare iwconfig. una esecuzione di iwconfig dovrebbe produrre un risultato simile al seguente:

Codice 4.6: Visualizzazione dei parametri wireless

# iwconfig eth0
eth0      IEEE 802.11-DS  ESSID:"GentooNode"                                   
          Mode:Managed  Frequency:2.442GHz  Access Point: 00:09:5B:11:CC:F2    
          Bit Rate:11Mb/s   Tx-Power=20 dBm   Sensitivity=0/65535               
          Retry limit:16   RTS thr:off   Fragment thr:off                       
          Power Management:off                                                  
          Link Quality:25/10  Signal level:-51 dBm  Noise level:-102 dBm        
          Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx          
          excessive retries:237 Invalid misc:350282 Missed beacon:84            

Nota: Alcune schede possono avere un nome come wlan0 o ra0 invece che eth0. Eseguire iwconfig senza nessun altro parametro per determinare il nome corretto.

Per la maggior parte degli utenti sono solo due i parametri importanti da impostare, l'ESSID (il nome della rete wireless) e la chiave WEP. Se l'ESSID e l'indirizzo dell'access point visualizzati sono corretti e non si utilizza WEP, la configurazione è completa e funzionante. Se invece è necessario cambiare ESSID o aggiungere una chiave WEP è necessario eseguire i seguenti comandi:

Codice 4.7: Cambiare ESSID o aggiungere una chiave WEP

(Il comando imposta l'ESSID a "GentooNode")
# iwconfig eth0 essid GentooNode

(Imposta una chiave WEP esadecimale)
# iwconfig eth0 key 1234123412341234abcd

(Imposta una chiave ASCII preceduta da "s:")
# iwconfig eth0 key s:some-password

E' possibile ora confermare le proprie impostazioni utilizzando iwconfig. Una volta che la rete wireless è funzionante è possibile continuare a configurare le impostazioni del livello IP descritte nella sezione successiva (Terminologia di rete) o utilizzare net-setup come descritto in precedenza.

Terminologia di Rete

Nota: Se si conosce l'indirizzo IP, l'indirizzo broadcast, netmask e nameserver, allora si può saltare questa sottosezione e continuare con la sezione su come Usare ifconfig e route.

Se i tentativi precedenti falliscono, è necessario configurare la rete manualmente. Non si deve aver paura, non è difficile. Ma è necessario spiegare un po' di concetti riguardanti la rete per potere essere capaci di configurarla correttamente. Questo paragrafo illustra brevemente cosa sia un gateway, a cosa serva la netmask, come sia formato un indirizzo broadcast e perchè ci sia bisogno dei nameserver.

In una rete, gli host sono identificati dai loro indirizzi IP (indirizzi Internet Protocol). Un indirizzo è una combinazione di 4 numeri tra 0 e 255. Almeno così lo percepiamo. In realtà, un indirizzo IP consiste di 32 bits (1 e 0). Ecco un esempio:

Codice 4.8: Esempio di un indirizzo IP

IP Address (numbers):   192.168.0.2
IP Address (bits):      11000000 10101000 00000000 00000010
                        -------- -------- -------- --------
                           192      168       0        2

Un indirizzo IP deve essere unico per ogni host perchè le reti siano accessibili (in pratica tutti gli host che si possono raggiungere devono avere un indirizzo IP unico). Per potere fare una distinzione tra host dentro una rete, e host fuori una rete, l'indirizzo IP è diviso in due parti: la parte di network e la parte di host.

La separazione è demarcata tramite la netmask, un insieme di 1 seguito da un insieme di 0. La parte di IP corrispondente agli 1 è la parte di network, l'altra è la parte di host. Di solito, la netmask può essere scritta come un indirizzo IP.

Codice 4.9: Esempio della separazione network/host

IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Netmask:    11111111 11111111 11111111 00000000
               255      255     255        0
           +--------------------------+--------+
                    Network              Host

In altre parole, 192.168.0.14 fa ancora parte della rete dell'esempio, ma 192.168.1.2 no.

L'indirizzo broadcast è un indirizzo IP con la stessa parte di network, ma con solo una parte di host. Ogni host sulla rete ascolta questo indirizzo IP. Serve per i pacchetti di broadcast.

Codice 4.10: Indirizzo broadcast

IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Broadcast:  11000000 10101000 00000000 11111111
               192      168      0        255
           +--------------------------+--------+
                     Network             Host

Per potere navigare su internet, è necessario sapere quale host condivida la connessione a Internet. Questo host è chiamato gateway. E' un normale host ed ha un normale indirizzo IP (per esempio 192.168.0.1).

In precedenza si è detto che ogni host ha il suo indirizzo IP. Per potere raggiungere questo host tramite un nome (anzichè un indirizzo IP) è necessario un servizio che traduce un nome (come dev.gentoo.org) in un indirizzo IP (come 64.5.62.82). Questo servizio è chiamato name service. Per utilizzarlo si deve definire il nameserver in /etc/resolv.conf.

In alcuni casi, il gateway serve come nameserver. Altrimenti si dovrà inserire il nameserver fornito dall'ISP.

Per riassumere, si ha bisogno delle seguenti informazioni prima di continuare:

Elemento di rete Esempio
Indirizzo IP 192.168.0.2
Netmask 255.255.255.0
Broadcast 192.168.0.255
Gateway 192.168.0.1
Nameserver(s) 195.130.130.5, 195.130.130.133

Usare ifconfig e route

Installare la rete consiste di tre passi. Nel primo si assegna l'indirizzo IP con ifconfig. Nel secondo si configura il routing verso gateway con route. Nel terzo infine si inserisce l'IP dei nameserver in /etc/resolv.conf.

Per assegnare un indirizzo IP, si avrà bisogno dell'indirizzo IP da assegnare, dell'indirizzo broadcast e della netmask. Eseguire il seguente comando, sostituendo ${IP_ADDR} con l'indirizzo IP, ${BROADCAST} con l'indirizzo broadcast e ${NETMASK} con la netmask:

Codice 4.11: Usare ifconfig

# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up

Ora installare il routing con route. Sostituire ${GATEWAY} con l'indirizzo IP del gateway:

Codice 4.12: Usare route

# route add default gw ${GATEWAY}

Aprire /etc/resolv.conf con un editor qualsiasi (per esempio nano):

Codice 4.13: Creare /etc/resolv.conf

# nano -w /etc/resolv.conf

Inserire i nameserver secondo il seguente esempio. Assicurarsi di sostituire ${NAMESERVER1} e ${NAMESERVER2} con gli appropriati indirizzi dei nameserver:

Codice 4.14: Esempio di /etc/resolv.conf

nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}

Testare la rete con il ping di alcuni server Internet (come Google). Se funziona, congratulazioni, si è pronti per installare Gentoo. Continuare con la Preparazione dei Dischi.

4. Preparazione dei dischi

4.a. Introduzione ai dispositivi a blocchi

Dispositivi a blocchi

Si dà ora un'occhiata approfondita agli aspetti relativi ai dischi in Gentoo Linux e in Linux in generale, tra cui i filesystem Linux, le partizioni e i dispositivi a blocchi. Quindi, una volta acquisita familiarità con i dischi e i filesystem, si viene guidati attraverso il processo di configurazione delle partizioni e dei filesystem per l'installazione di Gentoo Linux.

Per cominciare, si introducono i dispositivi a blocchi. Il dispositivo a blocchi più famoso è molto probabilmente quello che rappresenta la prima unità IDE in un sistema Linux, /dev/hda. Se il sistema usa dischi SCSI, allora il primo disco fisso dovrebbe essere /dev/sda.

I dispositivi a blocchi rappresentano un'interfaccia astratta ai dischi. I programmi utente possono usare questi dispositivi a blocchi per interagire con i dischi, senza doversi chiedere se si tratta di unità IDE, SCSI o di qualsiasi altro tipo. Il programma può semplicemente indirizzare la memorizzazione su disco attraverso dei blocchi contigui, accessibili in modalità random, e di dimensione pari a 512 byte ciascuno.

Partizioni e slices

Nonostante sia possibile usare un intero disco per il sistema Linux, ciò non è quasi mai messo in pratica. Invece, i dispositivi a blocchi del disco sono divisi in parti più piccole e più maneggevoli. Sui sistemi amd64 queste parti sono chiamate partizioni.

Partizioni

Le partizioni sono divise in tre tipi: primarie, estese e logiche.

Una partizione primaria è una partizione che ha le sue informazioni memorizzate nel MBR (master boot record). Poichè MBR è molto piccolo (512 byte), possono essere definite solo quattro partizioni primarie (per esempio, da /dev/hda1 a /dev/hda4).

Una partizione estesa è una speciale partizione primaria (cioè deve essere una delle quattro), che contiene altre partizioni. In origine non esisteva una tale partizione, ma poichè quattro partizioni erano troppo poche, è stata data la possibilità di estendere lo schema di formattazione senza perdere la compatibilità.

Una partizione logica è una partizione compresa dentro la partizione estesa. Le informazioni di una partizione logica non sono disposte nel MBR, ma sono dichiarate nella partizione estesa.

4.b. Impostare uno schema di partizionamento

Schema di partizionamento di default

Se non si è interessati a elaborare uno schema di partizionamento per il sistema, si può usare quello di questo Manuale:

Partizione Filesystem Grandezza Descrizione
/dev/hda1 ext2 32M Partizione di boot
/dev/hda2 (swap) 512M Partizione swap
/dev/hda3 ext3 Resto dello spazio su disco Partizione root

Se si è interessati ad avere informazioni su quanto dovrebbe essere grande una partizione (o volume logico), o anche su quante partizioni (o volumi) si ha bisogno, seguono alcuni suggerimenti. Altrimenti continuare con il Usare fdisk per partizionare il disco.

Numero e dimensione delle partizioni

Il numero delle partizioni è altamente dipendente sull'ambiente. Per esempio, se si hanno molti utenti su una stessa macchina, molto probabilmente si desidera tenere separate le directory /home, aumentando così la sicurezza e rendendo più facile il backup. Se si sta installando Gentoo per utilizzarlo da mailserver, /var dovrebbe essere separata poichè tutta la posta viene memorizzata in essa. Una buona scelta del filesystem è quella che massimizza le prestazioni. I gameserver è bene che abbiano una partizione separata per /opt, visto che la maggior parte dei server di gioco sono installati li. La stessa cosa vale per /home: sicurezza e backup. Si dovrebbe tenere una grande /usr: questa contiene non solo la maggior parte delle applicazioni, il solo Portage tree occupa 500 MB di spazio, esclusi i sorgenti che sono in esso.

Come si è visto, molto dipende da cosa si desidera realizzare. Partizioni o volumi separati hanno i seguenti vantaggi:

  • Si può scegliere il filesystem con maggiori prestazioni per ogni partizione o volume
  • L'intero sistema non può esaurire lo spazio libero se un tool malfunzionante scrive all'infinito su una partizione od un volume
  • Nel caso si rendano necessari, i controlli sul filesystem sono ridotti, poichè possono essere condotti in parallelo diverse analisi (questo vantaggio è più per i dischi multipli che per le partizioni multiple)
  • La sicurezza può essere aumentata montando alcune partizioni o volumi in sola lettura, nosuid (i bit setuid vengono ignorati), noexec (i bit executable sono ignorati) etc.

Le partizioni multiple hanno però un grosso svantaggio: se non sono configurate correttamente, si potrebbe avere un sistema con molto spazio libero su una partizione e poco su un'altra. C'è anche un limite di 15 partizioni per SCSI e SATA.

Come esempio di partizionamento, ecco quello di un disco da 20GB, usato come un laptop di dimostrazione (contenente webserver, mailserver, gnome, ...):

Codice 2.1: Esempio di uso del filesystem

Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/hda5     ext3    509M  132M  351M  28% /
/dev/hda2     ext3    5.0G  3.0G  1.8G  63% /home
/dev/hda7     ext3    7.9G  6.2G  1.3G  83% /usr
/dev/hda8     ext3   1011M  483M  477M  51% /opt
/dev/hda9     ext3    2.0G  607M  1.3G  32% /var
/dev/hda1     ext2     51M   17M   31M  36% /boot
/dev/hda6     swap    516M   12M  504M   2% <not mounted>
(Spazio non partizionato per uso futuro: 2 GB)

/usr è quasi pieno (83% dello spazio già in uso), ma una volta installato tutto il software, non cresce molto. Per /var si può pensare che lo spazio assegnato sia troppo. Ma Gentoo compila tutti i programmi in /var/tmp/portage, quindi si dovrebbe avere /var con almeno 1GB libero se non si vogliono compilare grandi programmi e oltre 3GB liberi per compilare KDE e OpenOffice.org.

4.c. Usare fdisk per partizionare il disco

La parte seguente spiega come creare lo schema di partizione di esempio descritto precedentemente:

Partizione Descrizione
/dev/hda1 Partizione di boot
/dev/hda2 Partizione swap
/dev/hda3 Partizione root

Cambiare le partizioni in base alle proprie impostazioni.

Vedere la disposizione delle partizioni

fdisk è un tool popolare e potente per dividere il disco in partizioni. Eseguire fdisk per il disco (nell'esempio si usa /dev/hda):

Codice 3.1: Eseguire fdisk

# fdisk /dev/hda

Si visualizzerà un prompt come questo:

Codice 3.2: Prompt di fdisk

Command (m for help): 

Digitare p per visualizzare le attuali partizioni presenti sul disco:

Codice 3.3: Un esempio di partizionamento

Command (m for help): p

Disk /dev/hda: 240 heads, 63 sectors, 2184 cylinders
Units = cylinders of 15120 * 512 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1             1        14    105808+  83  Linux
/dev/hda2            15        49    264600   82  Linux swap
/dev/hda3            50        70    158760   83  Linux
/dev/hda4            71      2184  15981840    5  Extended
/dev/hda5            71       209   1050808+  83  Linux
/dev/hda6           210       348   1050808+  83  Linux
/dev/hda7           349       626   2101648+  83  Linux
/dev/hda8           627       904   2101648+  83  Linux
/dev/hda9           905      2184   9676768+  83  Linux

Command (m for help): 

Questo disco è configurato per avere sette filesystem Linux (chiamati "Linux" nelle corrispondenti partizioni) e una partizione swap (chiamata "Linux swap").

Rimuovere tutte le partizioni

Si procede ora alla rimozione dal disco di tutte le partizioni esistenti. Digitare d per eliminare una partizione. Per esempio, per eliminare /dev/hda1:

Codice 3.4: Eliminare una partizione

Command (m for help): d
Partition number (1-4): 1

E' stata memorizzata l'eliminazione della partizione. Non si rivedrà più se si digiterà p, ma non sarà eliminata fino a quando non si salveranno i cambiamenti. Se si è commesso un errore e si vuole uscire senza salvare, digitare q e invio e la partizione non sarà tolta.

Ora, se si desidera effettivamente eliminare tutte le partizioni sul sistema, digitare p per visualizzare l'elenco delle partizioni, e poi digitare d seguito dal numero della partizione, per eliminarle. Il risultato è una tabella con nessuna partizione:

Codice 3.5: Tabella con nessuna partizione

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System

Command (m for help):

Ora che la tabella è vuota, si è pronti a creare le partizioni. Come esempio, si fa riferimento allo schema di partizionamento visto precedentemente: non si deve seguire queste istruzioni alla lettera se non si desidera implementare lo stesso schema.

Creare la partizione di boot

Per prima cosa, si crei una piccola partizione di boot. Digitare n per creare una nuova partizione, poi p per selezionare una partizione primaria, seguito da 1 per selezionare la prima partizione primaria. Quando si visualizza il prompt per il primo cilindro, premere enter. Quando si visualizza il prompt per l'ultimo cilindro, digitare +32M per creare una partizione di 32 Mbyte:

Codice 3.6: Creare la partizione di boot

Command (m for help): n
Command action
  e   extended
  p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-3876, default 1): (Premere Enter)
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-3876, default 3876): +32M

Quando si digita p, si dovrebbe vedere la seguente partizione:

Codice 3.7: Partizione di boot creata

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1          1        14    105808+  83  Linux

E' necessario rendere questa partizione avviabile. Digitare a per rendere avviabile questa partizione e selezionare 1. Se si preme di nuovo p, si noterà che un * è posto nella colonna "Boot".

Creare la partizione swap

Si procede ora alla creazione della partizione swap. Per farlo, digitare n per creare una nuova partizione, poi p per dire a fdisk che si desidera creare una partizione primaria. Digitare 2 per creare la seconda partizione primaria, /dev/hda2. Quando si visualizza il prompt per il primo cilindro, premere invio. Quando si visualizza il prompt per l'ultimo cilindro, digitare +512M per creare una partizione di 512MB. Dopo aver fatto questo, digitare t per impostare il tipo di partizione, 2 per selezionare la partizione che si è creata e infine 82 per impostare il tipo di partizione a "Linux Swap". Finiti questi passaggi, digitando p si dovrebbe avere una tabella partizionata simile a questa:

Codice 3.8: Elenco delle partizioni dopo aver creato la partizione swap

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1 *        1        14    105808+  83  Linux
/dev/hda2         15        81    506520   82  Linux swap

Creare la partizione root

Si procede ora alla creazione della partizione root. Digitare n per creare una nuova partizione, poi p per dire a fdisk che si vuole una partizione primaria. Digitare 3 per creare la terza partizione primaria, /dev/hda3. Quando si visualizza il prompt per il primo cilindro, premere invio. Quando si visualizza il prompt per l'ultimo cilindro, premere invio per creare una partizione che occupi il resto dello spazio su disco. Infine, digitando p si dovrebbe avere una tabella partizionata simile a questa:

Codice 3.9: Elenco delle partizioni dopo aver creato la partizione root

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot    Start       End    Blocks   Id  System
/dev/hda1 *        1        14    105808+  83  Linux
/dev/hda2         15        81    506520   82  Linux swap
/dev/hda3         82      3876  28690200   83  Linux

Salvare lo schema delle partizioni

Per salvare lo schema delle partizioni e uscire da fdisk, digitare w.

Codice 3.10: Salvare e uscire da fdisk

Command (m for help): w

Ora che le partizioni sono create, si può continuare con la sezione riguardante come Creare i filesystem.

4.d. Creare i filesystem

Introduzione

Ora che le partizioni sono state create, è il momento di inserire il filesystem. Se non si è interessati alla scelta del filesystem e vanno bene quelli che si usano di default in questo Manuale, continuare con la sezione su come Applicare un filesystem a una partizione. Altrimenti ecco una descrizione dei filesystem disponibili.

Filesystem

Sono disponibili molti filesystem. Alcuni sono stabili sull'architettura amd64, altri no. I seguenti filesystem sono stabili: ext2 e ext3. jfs e reiserfs potrebbero funzionare ma hanno bisogno di più test. E' consigliato solo agli avventurosi provare i filesystem non supportati.

ext2 è il vero e proprio filesystem di Linux ma non possiede il supporto per il metadata journaling, il che significa che le routine che effettuano all'avvio i controlli sul filesystem ext2 possono impiegare diverso tempo. Al momento esiste una scelta abbastanza ampia di filesystem journaled di nuova generazione che sono in grado di effettuare controlli sulla consistenza molto velocemente e sono generalmente preferiti alle controparti non-journaled. I filesystem journaled prevengono i lunghi tempi di attesa che solitamente si riscontrano quando viene riavviato il sistema e il filesystem si trova in uno stato inconsistente.

ext3 è la versione journaled del filesystem ext2, fornisce il metadata journaling per un veloce recupero dei dati in aggiunta ad altre caratteristiche di journaling avanzate come full data e ordered data journaling. ext3 è un filesystem davvero molto valido e affidabile. Ha una ulteriore opzione di indice hashed b-tree che abilita alte prestazioni in quasi tutte le situazioni. Si può abilitare questo indice aggiungendo -O dir_index al comando mke2fs. In poche parole, ext3 è un filesystem eccellente.

ReiserFS è un filesystem basato su B*-tree che offre ottime performance generali e si dimostra notevolmente superiore a ext2 e ext3 con file di piccole dimensioni (file minori di 4k), spesso di un fattore 10-15. ReiserFS scala inoltre molto bene e supporta il metadata journaling. Dal kernel 2.4.18 in poi, ReiserFS ha raggiunto la solidità che lo porta a essere caldamente raccomandato sia per un uso generico che per casi estremi come la creazione di grandi filesystem, l'uso su molti file piccoli, file molto grandi e directory contenenti decine di migliaia di file.

XFS è un filesystem con metadata journaling che si presenta con un robusto insieme di caratteristiche ed è ottimizzato per la scalabilità. Se ne raccomanda l'uso su sistemi Linux dotati di unità di memorizzazione con canali in fibra o high-en SCSI e alimentazione continua. Data l'aggressività con la quale XFS si serve della cache in RAM per i dati in transito, programmi progettati in modo non adeguato (quelli che non prendono precauzioni quando scrivono file su disco, e ce ne sono diversi) possono perdere una discreta quantità di dati se il sistema si arresta in modo inaspettato.

JFS è il filesystem con journaling ad alte prestazioni di IBM. E' stato recentemente giudicato pronto per il mercato, ma ad oggi non è stato sufficientemente testato per fare commenti positivi o negativi sulla sua stabilità generale.

Applicare un filesystem a una partizione

Per creare un filesystem su una partizione o volume, sono disponibili tool per ogni filesystem possibile:

Filesystem Comando per la creazione
ext2 mke2fs
ext3 mke2fs -j
reiserfs mkreiserfs
xfs mkfs.xfs
jfs mkfs.jfs

Per esempio, per avere la partizione di boot (/dev/hda1) ext2 e la partizione root (/dev/hda3) ext3, si usa:

Codice 4.1: Applicare un filesystem su una partizione

# mke2fs /dev/hda1
# mke2fs -j /dev/hda3

Ora si procede alla creazione dei filesystem sulle partizioni create precedentemente.

Attivare la partizione swap

mkswap è il comando usato per inizializzare le partizioni swap:

Codice 4.2: Creare una signature swap

# mkswap /dev/hda2

Per attivare la partizione swap, usare swapon:

Codice 4.3: Attivare la partizione swap

# swapon /dev/hda2

Creare e attivare swap subito.

4.e. Montare

Ora che le partizioni sono inizializzate e hanno un filesystem, è il momento di montarle. Usare il comando mount. Non dimenticarsi di creare le necessarie directory di mount per ogni partizione creata. Come esempio si monta la partizione root e boot:

Avvertenza: Per un bug nel pacchetto e2fsprogs, è necessario specificare l'opzione mount -t ext3 se si sta usando un filesystem ext3.

Codice 5.1: Montare le partizioni

# mount /dev/hda3 /mnt/gentoo
(Per partizioni ext3:)
# mount -t ext3 /dev/hda3 /mnt/gentoo
# mkdir /mnt/gentoo/boot
# mount /dev/hda1 /mnt/gentoo/boot

Nota: Se si vuole che /tmp risieda in una partizione separata, assicurarsi di cambiare i permessi dopo il mount: chmod 1777 /mnt/gentoo/tmp. Questo vale anche per /var/tmp.

E' necessario inoltre montare il filesystem proc (una interfaccia virtuale con il kernel) su /proc. Ma prima si devono mettere i file sulle partizioni.

Continuare con Copia dei file di installazione di Gentoo.

5. Copia dei file di installazione di Gentoo

5.a. Installazione di uno stage

Impostare la data e l'ora

Prima di continuare è necessario controllare la data e l'ora ed aggiornarle. Un orologio impostato male può portare problemi in futuro.

Per visualizzare l'ora e la data attuali eseguire date:

Codice 1.1: Verificare la data e l'ora

# date
 Fri Mar 29 16:21:18 CEST 2005

Se la data o l'ora fossero errate, è possibile aggiornarle utilizzando il comando date MMDDhhmmCCYY ( dove M è il mese, D è il giorno, h l'ora, m il monuto, C il secolo e Y l'anno). Ad esempio per impostare la data al 29 marzo 2005 e l'ora alle 16:21:

Codice 1.2: Impostare data e ora

# date 032916212005

Individuare lo stage3

Se si è configurata la rete perchè si deve scaricare uno stage3 per la propria architettura, continuare con Alternativa: Scaricare uno stage3 da Internet. Se non si ha bisogno di scaricarlo, leggere Default: Usare uno stage3 dal CD di Installazione.

5.b. Default: Usare uno stage3 dal CD di Installazione

Estrazione delo stage

Gli stage sul CD risiedono nella directory /mnt/cdrom/stages. Per vedere un elenco degli stage disponibili, usare ls:

Codice 2.1: Elenco di tutti gli stage disponibili

# ls /mnt/cdrom/stages

Se il sistema risponde con un errore, si dovrebbe montare il CD-ROM prima:

Codice 2.2: Montare il CD-ROM

# ls /mnt/cdrom/stages
ls: /mnt/cdrom/stages: No such file or directory
# mount /dev/cdroms/cdrom0 /mnt/cdrom
# ls /mnt/cdrom/stages

Andare ora sul punto di mount di Gentoo (di solito /mnt/gentoo):

Codice 2.3: Cambiamento della directory a /mnt/gentoo

# cd /mnt/gentoo

Estrarre ora lo stage scelto. E' possibile farlo con il tool GNU tar. Assicurarsi di usare le stesse opzioni (-xvjpf)! La x significa di Estrarre, v di Visualizzare le operazioni ed è opzionale, j di Decomprimere con bzip2, p di Preservare i permessi dei file, f di Estrarre da file e non da input. Nel prossimo esempio, si estrae lo stage stage3-<subarch>-2005.0.tar.bz2. Assicurarsi ancora di sostituire il nome del file del tarball con quello scelto.

Codice 2.4: Estrarre lo stage

# tar -xvjpf /mnt/cdrom/stages/stage3-<subarch>-2005.0.tar.bz2

Ora si è pronti per procedere con la prossima sezione riguardante come Installare Portage.

5.c. Alternativa: Scaricare uno stage3 da Internet

Scaricare lo stage

Andare al punto sul quale si è montato il filesystem (molto probabilmente /mnt/gentoo):

Codice 3.1: Andare al mountpoint di Gentoo

# cd /mnt/gentoo

Secondo la modalità di installazione, sono disponibili un paio di tool per scaricare lo stage. Se si ha links2, allora si può visitare immediatamente la lista dei mirror di Gentoo e scegliere un mirror vicino.

Se non si dispone di links2, si dovrebbe poter almeno contare su lynx. Se è necessario un proxy, esportare le variabili http_proxy e ftp_proxy:

Codice 3.2: Impostare i proxy per lynx

# export http_proxy="http://proxy.server.com:port"
# export ftp_proxy="http://proxy.server.com:port"

D'ora in poi si suppone che l'utente utilizzi links2.

Selezionare la directory releases/, seguita dall'architettura (per esempio x86/), dalla versione di Gentoo (2005.0/), e infine la directory stages/. Si dovrebbero vedere tutti gli stage disponibili per l'architettura, eventualmente suddivisi in sottodirectory a seconda della sottoarchitettura. Selezionarne uno e premere D per scaricarlo. Quando si è finito, premere Q per chiudere il browser.

Codice 3.3: Cercare i mirror con links2

# links2 http://www.gentoo.org/main/en/mirrors.xml

(Se si necessita di proxy in links2:)
# links2 -http-proxy proxy.server.com:8080 http://www.gentoo.org/main/en/mirrors.xml

Se si desidera controllare l'integrità dello stage scaricato, usare md5sum e confrontare l'output con il checksum MD5 fornito sul mirror. Ad esempio per controllare la validit di un pacchetto x86:

Codice 3.4: Controllare l'integrità di un tarball dello stage

# md5sum -c stage3-x86-2005.0.tar.bz2.md5
stage3-x86-2005.0.tar.bz2: OK

Estrazione dello stage

Decomprimere ora lo stage nel sistema. Utilizzare l'utility tar di GNU per procedere poichè è il metodo più facile:

Codice 3.5: Estrazione dello stage

# tar -xvjpf stage3-*.tar.bz2

Assicurarsi di usare le stesse opzioni (-xvjpf). La x significa di Estrarre, v di Visualizzare le operazioni ed è opzionale, j di Decomprimere con bzip2, p di Preservare i permessi dei file, f di Estrarre da file e non da input.

Ora si è pronti per procedere con la prossima sezione riguardante come Installare Portage.

5.d. Installazione di Portage

Estrarre lo snapshot di Portage

Ora è necessario procedere all'installazione dello snapshot di Portage: si tratta di un archivio che contiene tutti i software che è possibile installare con le relative informazioni.

Estrarre lo snapshot dal CD di Installazione

Per installare lo snapshot, guardare in /mnt/cdrom/snapshots/ per vedere quale snapshot è disponibile:

Codice 4.1: Posizionarsi sul punto di mount

# cd /mnt/gentoo

Codice 4.2: Controllare /mnt/cdrom/snapshot

# ls /mnt/cdrom/snapshots

Estrarre lo snapshot con il seguente comando. Assicurarsi di usare le stesse opzioni con tar. La -C è maiuscola. Nel prossimo esempio si usa portage-<data>.tar.bz2 come filename dello snapshot. Sostituire lo snapshot con quello che è sul proprio CD di Installazione.

Codice 4.3: Estrazione dello snapshot di Portage

# tar -xvjf /mnt/cdrom/snapshots/portage-<data>.tar.bz2 -C /mnt/gentoo/usr

Copiare gli archivi di codice sorgente

Si deve copiare tutto il codice sorgente dal CD di Installazione Universale.

Codice 4.4: Copiare il codice sorgente

# mkdir /mnt/gentoo/usr/portage/distfiles
# cp /mnt/cdrom/distfiles/* /mnt/gentoo/usr/portage/distfiles/

5.e. Configurare le opzioni di compilazione

Introduzione

Per ottimizzare Gentoo, si possono impostare alcune variabili che hanno effetto sul comportamento di Portage. Tutte queste variabili possono essere impostate come variabili di ambiente (usando export), ma non in modo permanente. Per mantenere le impostazioni, Portage fornisce il file di configurazione /etc/make.conf. E' il file da modificare adesso.

Nota: Un elenco commentato di tutte le variabili possibili si trova in /mnt/gentoo/etc/make.conf.example. Ma per una installazione di Gentoo è soltanto necessario impostare le variabili che sono menzionate sotto.

Si prenda il proprio editor preferito (in questa guida si usa nano) per poter cambiare le variabili di ottimizzazione che di cui si sta trattando.

Codice 5.1: Aprire /etc/make.conf

# nano -w /mnt/gentoo/etc/make.conf

Come è evidente, il file make.conf.example è strutturato in modo molto semplice: le righe commentate iniziano con "#", le altre righe definiscono le variabili, usando la sintassi VARIABILE="valore". Molte di queste variabili vengono trattate in seguito.

Avvertenza: Non fare nessuna modifica alla variabile USE se si sta facendo una installazione con stage3 con GRP. Si può cambiare la variabile USE dopo aver installato il pacchetto che si desidera.

CHOST

Avvertenza: Anche se potrebbe essere interessante, gli utenti che non hanno scelto lo stage1, non devono cambiare le impostazioni CHOST in make.conf. Facendolo si può rendere il sistema inutilizzabile. Di nuovo: cambiare questa variabile esclusivamente se si sta utilizzando l'installazione con lo stage1.

L'installazione senza supporto di rete utilizza esclusivamente stage3. Non modificare la variabile CHOST!

CFLAGS e CXXFLAGS

Le variabili CFLAGS e CXXFLAGS definiscono le opzioni di ottimizzazione per i compilatori C e C++ rispettivamente di gcc. Anche se qui vengono definite in generale, le massime performance si ottengono quando si impostano le variabili per ogni programma separatamente perchè ogni programma è differente.

In make.conf si dovrebbero definire le impostazioni di ottimizzazione che si ritiene possano rendere il sistema più reattivo in generale. Non mettere impostazioni sperimentali in questa variabile; troppa ottimizzazione può far funzionare male i programmi (crash, o peggio ancora, malfunzionamento).

Non vengono spiegate tutte le possibili opzioni di ottimizzazione. Chi volesse conoscerle, legga il Manuale Online GNU o la pagina di informazioni gcc (info gcc -- funziona solo su un sistema Linux). Lo stesso file make.conf.example contiene molti esempi e informazioni da consultare.

Una prima impostazione è la flag -march=, che specifica il nome dell'architettura. Le possibili opzioni sono descritte nel file make.conf.example (come commenti). Per esempio, per l'architettura x86 Athlon XP:

Codice 5.2: Impostazione della flag march di GCC

# Gli utenti AMD64 che desiderino avere un sistema 64 bit nativo dovrebbero utilizzare -march=k8
-march=athlon-xp

Una seconda impostazione è la flag -O (o maiuscola, non zero), che specifica la classe di ottimizzazione di gcc. Possibili classi sono s (per ottimizzazioni di formato), O (per nessuna ottimizzazione), 1, 2 o 3 per più ottimizzazioni di velocità (ogni classe ha le stesse flag di quella precedente, più alcuni extra). Per esempio, per una ottimizzazione di classe 2:

Codice 5.3: L'impostazione O di GCC

-O2

Altre flag di ottimizzazione molto usate sono -pipe (si usa pipe piuttosto che i file temporanei, per la comunicazione tra i vari stage di compilazione).

L'utilizzo di -fomit-frame-pointer (che non tiene il puntatore al frame per funzioni che non ne hanno bisogno) potrebbe avere serie ripercussioni nel caso sia necessario effettuare il debug dell'applicazione.

Quando si definiscono CFLAGS e CXXFLAGS, si dovrebbero mettere insieme molte flag di ottimizzazione, come nel seguente esempio:

Codice 5.4: Definizione delle variabili CFLAGS e CXXFLAGS

CFLAGS="-march=athlon-xp -pipe -O2" # Gli utenti AMD64 utilizzano -march=k8
CXXFLAGS="${CFLAGS}" # Usare le stesse impostazioni per entrambe le variabili

MAKEOPTS

Con MAKEOPTS si definisce quante compilazioni parallele sono possibili quando si installa un pacchetto. Il numero suggerito è il numero di CPU più uno, ma non è detto che sia l'impostazione migliore.

Codice 5.5: MAKEOPTS per un normale sistema con 1-CPU

MAKEOPTS="-j2"

Pronti

Aggiornare /mnt/gentoo/etc/make.conf in base alle proprie preferenze, e salvarlo. Si è ora pronti per continuare con l'Effettuare il chroot in un sistema base Gentoo.

6. Effettuare il chroot in un sistema base Gentoo

6.a. Effettuare il chroot

Montare il filesystem proc

Montare il filesystem /proc su /mnt/gentoo/proc per permettere all'installazione di usare informazioni fornite dal kernel anche dentro l'ambiente in cui si è effettuato il chroot.

Codice 1.1: Montare /proc

# mount -t proc none /mnt/gentoo/proc

Opzionale: Copiare le informazioni del DNS

Se si è configurata la rete per scaricare lo stage appropriato da Internet, si devono copiare le informazioni del DNS da /etc/resolv.conf a /mnt/gentoo/etc/resolv.conf. Questo file contiene i nameserver che il proprio sistema userà per risolvere i nomi agli indirizzi IP.

Codice 1.2: Copiare le informazioni del DNS

# cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf 

Entrare nel nuovo ambiente

Adesso che tutte le partizioni sono pronte e che l'ambiente di base è installato, è arrivato il momento di entrare nel nuovo ambiente di installazione effettuando il chroot. Significa che ci si sposta dall'attuale ambiente di installazione al sistema di installazione nel proprio sistema (nelle partizioni create).

Il chroot è costituito di tre parti. Nella prima si cambia root, da / (sul supporto di installazione) a /mnt/gentoo (nelle partizioni create), usando chroot. Nella seconda si crea un nuovo ambiente usando env-update, il quale inizializza le variabili di ambiente. Nella terza si caricano queste variabili in memoria, con source.

Codice 1.3: Chroot nel nuovo ambiente

# chroot /mnt/gentoo /bin/bash
# env-update
 * Caching service dependencies...
# source /etc/profile

Congratulazioni! Da adesso si è dentro Gentoo Linux. Naturalmente la fine dell'installazione è lontana, poichè mancano ancora alcune sezioni.

6.b. Configurare la variabile USE

Cosa è la variabile USE?

USE è una delle variabili più potenti che Gentoo fornisce agli utenti. Molti programmi possono essere compilati con o senza il supporto opzionale per certi elementi. Per esempio, alcuni programmi possono essere compilati con il supporto per gtk, o con il supporto per qt. Altri con o senza il supporto per SSL. Alcuni programmi possono essere compilati con il suporto per framebuffer (svgalib), anzichè con quello per X11 (server X).

La maggior parte delle distribuzioni compila i propri pacchetti con il più alto supporto possibile, aumentando le dimensioni dei programmi e il tempo di avvio, per non parlare dell'enorme quantità di dipendenze. Con Gentoo si può definire con quali opzioni un pacchetto deve essere compilato. Questa è la funzione di USE.

Nella variabile USE si definiscono keywords che vengono poi tradotte in opzioni di compilazione. Per esempio, ssl abilita il supporto ssl nei programmi che lo supportano. -X (notare il trattino davanti) rimuove il supporto per il server X. gnome gtk -kde -qt abilita i programmi al supporto gnome (e gtk), ma non a quello kde (e qt), rendendo il sistema ottimizzato per GNOME.

Modificare la variabile USE

Avvertenza: Non fare nessuna modifica alla variabile USE se si vogliono usare i pacchetti precompilati (GRP). Si può cambiare la variabile USE dopo aver installato i pacchetti che si desiderano.

Le impostazioni di default di USE sono conservate nel file /etc/make.profile/make.defaults. Quello che si mette in /etc/make.conf è calcolato da queste impostazioni di default. Se si aggiunge qualcosa alle impostazioni di USE, si aggiunge anche all'elenco di default. Se si rimuove qualcosa dalle impostazioni di USE (mettendo un trattino davanti), si rimuove dall'elenco di default (se era nell'elenco). Non si deve cambiare mai nessuna opzione nella directory /etc/make.profile; in quanto essa viene sovrascritta quando si aggiorna Portage.

Una descrizione completa di USE si trova nella seconda parte del Manuale Gentoo, USE flag. Una descrizione completa sulle flag USE disponibili si trova in /usr/portage/profiles/use.desc.

Codice 2.1: Vedere le flag USE disponibili

# less /usr/portage/profiles/use.desc
(E' possibile muoversi con le frecce ed uscire con 'q')

Come esempio ecco le impostazioni di USE per un sistema basato su KDE, e con il supporto per DVD, ALSA e masterizzazione CD:

Codice 2.2: Si apre /etc/make.conf

# nano -w /etc/make.conf

Codice 2.3: Impostazioni USE

USE="-gtk -gnome qt kde dvd alsa cdr"

7. Configurazione del Kernel

7.a. Timezone

Innanzitutto è necessario selezionare la propria timezone, in modo che il sistema riconosca in che parte del globo è collocato. Per la propria timezone, consultare /usr/share/zoneinfo. Creare dunque un link simbolico a /etc/localtime usando ln:

Codice 1.1: Abilitare le informazioni sulla timezone

# ls /usr/share/zoneinfo
(Per esempio GMT)
# ln -sf /usr/share/zoneinfo/GMT /etc/localtime

7.b. Installare i sorgenti

Scegliere un Kernel

Il cuore, intorno al quale sono sviluppate tutte le distribuzioni, è il Kernel di Linux. E' la parte di software compresa tra i programmi e l'hardware. Gentoo dà la possibilità ai suoi utenti di scegliere tra diversi sorgenti del kernel. Una lista completa delle descrizioni dei kernel disponibili, è consultabile nella Guida ai Kernel Gentoo.

Per i sistemi basati su AMD64 si hanno gentoo-sources (sorgenti del kernel 2.6 con patch specifiche per amd64 che migliorano la stabilità, la performance e il supporto hardware).

Dopo la scelta del kernel, è necessario installarlo con emerge.

Nota: Eseguire emerge gentoo-sources non funziona perchè c'è un bug con il CD di installazione Universale. Eseguire quindi emerge =gentoo-sources-2.6.11-r1. Non ci saranno particolari cambiamenti sull'ambiente poichè Portage scaricherà automaticamente un sorgente del kernel più recente quando si aggiornerà il sistema (dopo la installazione).

Codice 2.1: Installare un sorgente del kernel

# echo "=sys-kernel/gentoo-sources-2.6.11-r1 ~amd64" >> /etc/portage/package.keywords
# emerge =gentoo-sources-2.6.11-r1

Se si dà un'occhiata a /usr/src, si dovrebbe vedere un link simbolico chiamato linux, che punta al sorgente del kernel:

Codice 2.2: Il link simbolico al sorgente del kernel

# ls -l /usr/src/linux
lrwxrwxrwx    1 root     root           12 Oct 13 11:04 /usr/src/linux -> linux-2.6.11-gentoo-r1

Se così non fosse (cioè il link simbolico punta a un sorgente del kernel differente), prima di continuare è necessario cambiare il link simbolico:

Codice 2.3: Cambiare il link simbolico al sorgente del kernel

# rm /usr/src/linux
# cd /usr/src
# ln -s linux-2.6.11-gentoo-r1 linux

Ora si procede a configurare e compilare il sorgente del kernel. Allo scopo è possibile utilizzare genkernel, che compila un kernel generico come quello usato dal CD di installazione. Si tratta però prima la configurazione "manuale", poichè è il miglior modo di ottimizzare l'ambiente.

Se si desidera configurare il kernel manualmente, continuare con Default: Configurazione manuale. Per chi preferisce usare genkernel, leggere Alternativa: Usare genkernel.

7.c. Default: Configurazione manuale

Introduzione

La configurazione manuale del kernel è spesso considerata la parte più difficile che ogni utente Linux incontra. Non è assolutamente vero -- dopo aver configurato un po' di kernel, l'operazione risulta semplice.

Una cosa è però vera: si deve conoscere il proprio sistema quando si comincia una configurazione manuale del kernel. La maggior parte delle informazioni può essere raccolta con emergere pciutils (emerge pciutils) che contiene lspci. Si potrà usare lspci con l'ambiente in cui si è effettuato il chroot. Si può ignorare i warning pcilib (come pcilib: cannot open /sys/bus/pci/devices). E' possibile anche eseguire lspci da un ambiente in cui non si è effettuato il chroot. I risultati sono gli stessi. Si può anche eseguire lsmod per vedere che moduli del kernel usa il CD di installazione (potrebbe fornire un buon suggerimento su cosa abilitare).

Andare nella directory del sorgente del kernel, e digitare make menuconfig per visualizzare un menu di configurazione basato su ncurses.

Codice 3.1: Aprire menuconfig

# cd /usr/src/linux
# make menuconfig

Vengono visualizzate molte sezioni di configurazione. Ecco ora alcune opzioni che devono essere attivate (altrimenti Gentoo non può funzionare, o non funziona correttamente senza modifiche aggiuntive).

Attivare le opzioni indispensabili

Prima di tutto, si deve attivare l'uso di codice/driver di sviluppo e sperimentale. Se non lo si fa, non si ha la possibilità di utilizzare qualche codice/driver molto importante:

Codice 3.2: Selezionare codice/driver sperimentale, General setup

Code maturity level options --->
  [*] Prompt for development and/or incomplete code/drivers
General setup --->
  [*] Support for hot-pluggable devices

Andare su File Systems e selezionare il supporto per il filesystem che si usa. Non compilarlo come modulo, altrimenti Gentoo non può montare le partizioni. Selezionare anche Virtual memory, /proc file system. Non selezionare /dev file system 2005.0/AMD64 usa udev di default.

Codice 3.3: Selezionare il filesystem

File systems --->
  Pseudo Filesystems --->
    [*] /proc file system support
    [ ] /dev file system support (OBSOLETE)
    [*] Virtual memory file system support (former shm fs)

(Selezionare una o più delle seguenti opzioni necessarie per il proprio sistema)
  <*> Reiserfs support
  <*> Ext3 journalling file system support
  <*> JFS filesystem support
  <*> Second extended fs support
  <*> XFS filesystem support

Se si sta usando PPPoE per connettersi a Internet o si sta usando un modem dial-up, si ha bisogno delle seguenti opzioni nel kernel:

Codice 3.4: Selezionare i driver necessari per PPPoE

Device Drivers --->
  Networking Support --->
    <*> PPP (point-to-point protocol) support
    <*>   PPP support for async serial ports
    <*>   PPP support for sync tty ports

Le due opzioni di compressione non sono dannose, ma neppure necessarie; lo stesso vale per PPP over Ethernet, che potrebbe essere usata soltanto da rp-pppoe se configurato in modalità kernel.

Chi ne ha bisogno, non deve dimenticare di includere il supporto per la scheda ethernet nel kernel.

Se si è in possesso di più CPU Opteron, è possibile attivare il "Symmetric multi-processing support":

Codice 3.5: Attivare il supporto multiprocessore

Processor type and features --->
  [*] Symmetric multi-processing support

Se si usa USB Input Devices (come tastiera o mouse), non dimenticarsi di abilitarli:

Codice 3.6: Attivare il supporto USB per Input Devices

Device Drivers --->
  USB Support --->
  <*>   USB Human Interface Device (full HID) support
  [*]   HID input layer support

Una volta terminata la configurazione del kernel continuare con Compilazione e Installazione.

Compilazione e Installazione

Ora che il kernel è configurato, il prossimo passo sarà la sua compilazione e la sua installazione. Uscire dal menu di configurazione e avviare il processo di compilazione:

Codice 3.7: Compilare il kernel

# make && make modules_install

Quando la compilazione è finita, è necessario copiare l'immagine del kernel in /boot:

Codice 3.8: Installare il kernel

# cp arch/x86_64/boot/bzImage /boot/kernel-2.6.11-gentoo-r1

E' inoltre consigliato copiare il file di configurazione del kernel in /boot.

Codice 3.9: Back up della configurazione del kernel

# cp .config /boot/config-2.6.11-gentoo-r1

Adesso continuare con Installare i moduli del Kernel.

7.d. Alternativa: Usare genkernel

Se si sta leggendo questa sezione, vuol dire che si è scelto di usare lo script genkernel, che configura il kernel.

Adesso che sono stati installati i sorgenti del kernel si può utilizzare lo script genkernel per configurarlo e compilarlo automaticamente. genkernel configura il kernel in modo quasi identico a come è configurato quello del CD di installazione. Infatti quando si usa genkernel per compilare il kernel, il sistema rileva tutto l'hardware al boot, proprio come il CD di installazione. Poichè genkernel non richiede nessuna configurazione manuale del kernel, questa è una soluzione ideale per quegli utenti che hanno qualche difficoltà nel compilarsi il kernel da soli.

Ecco come usare genkernel. Per prima cosa si deve emergere l'ebuild di genkernel:

Codice 4.1: Emergere genkernel

# emerge genkernel

Compilare ora il proprio kernel eseguendo genkernel all. Visto che genkernel compila un kernel che supporta quasi tutto l'hardware disponibile questa compilazione può essere un processo piuttosto lungo.

E' importante sapere anche che se non si usano ext2 o ext3 come filesystem è necessario configurare manualmente il kernel usando genkernel --menuconfig all e aggiungere il supporto per il filesystem scelto nel kernel (cioè non come modulo).

Codice 4.2: Esecuzione di genkernel

# genkernel all

Una volta completato genkernel, viene creato un kernel completo di moduli e root disk iniziale (initrd). Il kernel e initrd intervengono quando si configura un boot loader. E' consigliabile dunque annotare il nome del kernel e del initrd, poichè servono quando si scrive il file di configurazione del bootloader. Initrd si avvia subito dopo il boot per effettuare un rilevamento automatico dell'hardware (come nel CD di installazione), prima che si avvii il sistema "reale".

Codice 4.3: Controllo dell'immagine del kernel e dell'initrd

# ls /boot/kernel* /boot/initrd*

Ancora un altro passo per ottenere il sistema più simile al CD di installazione: emergere coldplug. Mentre initrd rileva automaticamente l'hardware necessario per avviare il sistema, coldplug autorileva tutto il resto. Per emergere e abilitare coldplug, digitare:

Codice 4.4: Emergere ed abilitare coldplug

# emerge coldplug
# rc-update add coldplug boot

7.e. Configuring Kernel Modules

Configurare i moduli

Si dovrebbero inserire i moduli che si vogliono caricare in /etc/modules.autoload.d/kernel-2.4 (o kernel-2.6). Se si vuole, si possono anche aggiungere altre opzioni ai moduli.

Per vedere tutti i moduli disponibili, eseguire il comando find. Non dimenticarsi di sostituire "<kernel version>" con la versione del kernel che si è compilata:

Codice 5.1: Vedere tutti i moduli disponibili

# find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko'

Per esempio, per caricare automaticamente il modulo 3c59x.o, modificare il file kernel-2.6 e inserire il nome.

Codice 5.2: Modificare /etc/modules.autoload.d/kernel-2.6

# nano -w /etc/modules.autoload.d/kernel-2.6

Codice 5.3: /etc/modules.autoload.d/kernel-2.6

3c59x

Continuare l'installazione con la Configurazione del sistema.

8. Configurazione del sistema

8.a. Informazioni sul filesystem

Cos'è fstab?

In Linux, tutte le partizioni usate dal sistema devono essere elencate in /etc/fstab. Questo è un file che contiene i mountpoint delle partizioni (cioè dove le partizioni compaiono nella struttura del filesystem), come devono essere montate (opzioni speciali), e quando (automaticamente o meno, se gli utenti possono montarle o meno, etc.).

Creare /etc/fstab

/etc/fstab usa una sintassi speciale. Ogni riga contiene sei parti, separate da spazio (spazio, tabs o entrambi). Ogni parte ha un significato:

  • La prima parte indica la partizione (il percorso al file dev)
  • La seconda parte indica il mountpoint, al quale deve essere montata la partizione
  • La terza parte indica il tipo di filesystem usato dalla partizione
  • La quarta parte indica le opzioni di mount, usate da mount quando monta la partizione. Poichè ogni filesystem ha le proprie opzioni di mount, è consigliato leggere la pagina di manuale di mount per avere una lista completa (man mount). Se si specificano varie opzioni di mount, si separano da una virgola.
  • La quinta parte è usata da dump per determinare se la partizione necessita dell'operazione di dump o no. Si può lasciarla a 0.
  • La sesta parte è usata da fsck per determinare l'ordine in cui dovrebbero essere controllati i filesystem, se il sistema non è stato spento correttamente. Il filesystem di root dovrebbe avere 1, mentre gli altri filesystem dovrebbero avere 2 (o 0 se non è necessario un controllo del filesystem).

Il file /etc/fstab fornito da Gentoo è solo di esempio, quindi aprire nano (o l'editor preferito) per modificare /etc/fstab:

Codice 1.1: Aprire /etc/fstab

# nano -w /etc/fstab

Si osservino le opzioni specificate per la partizione di /boot. Qusto è solo un esempio, se la propria architettura non richiede una partizione di /boot (come PPC), non copiarla pari pari.

Nel nostro esempio di partizionamento x86 /boot corrisponde a /dev/hda1, con ext2 come filesystem. Non ha bisogno di essere controllata, si può dunque scrivere:

Codice 1.2: Esempio di /boot per /etc/fstab

/dev/hda1   /boot     ext2    defaults        1 2

Alcuni utenti preferiscono non montare /boot all'avvio per ragioni di sicurezza. In questo caso è possibile sostituire defaults con noauto. Questo significa che è necessario montare manualmente la partizione ogni volta si desideri accedervi.

Per migliorare la performance, la maggior parte degli utenti potrebbe volere aggiungere l'opzione noatime come opzione di mount, con cui si ottiene un sistema più veloce, poichè i tempi di accesso non sono registrati (di solito comunque non c'è bisogno di averli):

Codice 1.3: Esempio migliorato di /boot per /etc/fstab

/dev/hda1   /boot     ext2    defaults,noatime    1 2

Continuando, si inseriscono le seguenti tre righe (per /boot, / e per la partizione swap):

Codice 1.4: Tre righe per /etc/fstab

/dev/hda1   /boot     ext2    defaults,noatime  1 2
/dev/hda2   none      swap    sw                0 0
/dev/hda3   /         ext3    noatime           0 1

Per finire, si dovrebbe aggiungere una regola per /proc, tmpfs (necessario) e per il lettore CD-ROM (e, se si hanno, anche per altre partizioni o periferiche):

Codice 1.5: Esempio completo di /etc/fstab

/dev/hda1   /boot     ext2    defaults,noatime     1 2
/dev/hda2   none      swap    sw                   0 0
/dev/hda3   /         ext3    noatime              0 1

none        /proc     proc    defaults             0 0
none        /dev/shm  tmpfs   nodev,nosuid,noexec  0 0

/dev/cdroms/cdrom0    /mnt/cdrom    auto      noauto,user    0 0

L'impostazione auto fa in modo che mount rilevi automaticamente il filesystem (raccomandato per i media rimovibili poichè possono essere creati con molti filesystem); l'impostazione user rende possibile montare il CD per gli utenti che non hanno il privilegio di root.

Usare l'esempio sopra per creare il proprio /etc/fstab. Se si è utenti SPARC, si dovrebbe aggiungere anche la seguente riga:

Codice 1.6: Aggiungere il filesystem openprom a /etc/fstab

none        /proc/openprom  openpromfs    defaults      0 0

Rileggere con attenzione /etc/fstab, salvarlo e uscire per continuare.

8.b. Informazioni di rete

Nome dell'host, nome di dominio, eccetera

Una delle scelte che l'utente deve fare, è quella di dare un nome al proprio PC. Sembra facile, ma molti utenti hanno delle difficoltà nel trovare il nome appropriato per il loro pc Linux. Per velocizzare le cose, si sappia che qualsiasi nome si scelga, si può in seguito cambiarlo. Per quello che importa si può chiamare il sistema tux e il dominio homenetwork.

Nel prossimo esempio, si usano questi due nomi. Per prima cosa impostiamo l'hostname:

Codice 2.1: Impostare l'hostname

# echo tux > /etc/hostname

Poi Impostiamo il nome di dominio:

Codice 2.2: Impostare il domainname

# echo homenetwork > /etc/dnsdomainname

Se si dispone di un dominio NIS (se non si sa cos'è, allora non lo si ha), si deve definire anche quello:

Codice 2.3: Settare NIS domainname

# echo nis.homenetwork > /etc/nisdomainname

Ora aggiungere lo script domainname al runlevel di default:

Codice 2.4: Aggiungere domainname al runlevel di default

# rc-update add domainname default

Configurare la rete

Si dovrebbe ricordare che la configurazione della rete fatta inizialmente era solo per l'installazione di Gentoo. Adesso è necessario configurare la rete per il sistema Gentoo in funzione.

Tutte le informazioni di rete sono raccolte in /etc/conf.d/net. Questo file usa una sintassi semplice ma non molto intuitiva per chi non sa installare la rete manualmente. Ma qui si spiega tutto.

Per prima cosa aprire /etc/conf.d/net con l'editor preferito (in questo esempio si usa nano):

Codice 2.5: Aprire /etc/conf.d/net

# nano -w /etc/conf.d/net

La prima variabile che si incontra è iface_eth0. Essa usa la seguente sintassi:

Codice 2.6: Sintassi di iface_eth0

iface_eth0="<indirizzo ip> broadcast <indirizzo di broadcast> netmask <netmask>"

Se si usa DHCP (che server per ottenere automaticamente un IP), si dovrebbe impostare iface_eth0 a dhcp. Se si usa rp-pppoe (per esempio, per ADSL), impostarlo a up. Se si deve installare la rete manualmente e questi termini non sono familiari, è consigliata, se non è stata gia fatta, la lettura di Comprendere la Terminologia della Rete.

Seguono tre esempi: nel primo si usa DHCP; nel secondo un IP statico 192.168.0.2, netmask 255.255.255.0, broadcast 192.168.0.255 e gateway 192.168.0.1, mentre il terzo attiva una interfaccia per rp-pppoe:

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

(Per DHCP:)
iface_eth0="dhcp"
# Alcuni amministratori di sistema richiedono che si utilizzi
# l'hostname e il domainname forniti dal server DHCP.
# In quiesto caso aggiungere l'istruzione seguente.
# Questo reimposterà le l'hostname e domainname definiti.
dhcpcd_eth0="-HD"
# Se si desidera utilizzare NTP per mantenere l'orologio aggiornato
# utilizzare l'opzione -N per evitare la sovrascrittura di /etc/ntp.conf
dhcpcd_eth0="-N"

(Per IP statico:)
iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0"
gateway="eth0/192.168.0.1"

(Per rp-pppoe:)
iface_eth0="up"

Se si hanno molte interfacce di rete, si devono creare variabili extra di iface_eth, come iface_eth1, iface_eth2 eccetera. La variabile gateway non deve essere riscritta, poichè si può settare un solo gateway per computer.

Salvare la configurazione e uscire per continuare.

Far partire automaticamente la rete al boot

Per attivare le interfacce di rete al boot, si deve aggiungerle al runlevel di default. Se si hanno interfacce PCMCIA, si può saltare questa azione, poichè vengono avviate dallo script init PCMCIA.

Codice 2.8: Aggiungere net.eth0 al runlevel di default

# rc-update add net.eth0 default

Se si hanno molte interfacce di rete, si devono creare gli initscripts per net.eth1, net.eth2 etc. Si può usare ln per farlo:

Codice 2.9: Creare gli initscripts extra

# cd /etc/init.d
# ln -s net.eth0 net.eth1
# rc-update add net.eth1 default

Scrivere le informazioni di rete

E' necessario fornire a Linux informazioni sulla propria rete. Queste si trovano in /etc/hosts, e aiutano a mettere in corrispondenza gli hostnames e gli indirizzi IP, per gli host che non sono risolti dal nameserver. Per esempio, se la rete interna consiste di tre PC, chiamati jenny (192.168.0.5), benny (192.168.0.6) e tux (192.168.0.7), si dovrebbe aprire /etc/hosts e inserire questi valori:

Codice 2.10: Aprire /etc/hosts

# nano -w /etc/hosts

Codice 2.11: Inserire le informazioni di rete

127.0.0.1     localhost
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny
192.168.0.7   tux.homenetwork tux

Se il proprio sistema è l'unico nella rete (o i nameserver gestiscono tutte le le risoluzioni), è sufficiente una sola riga. Ad esempio per chiamare tux il proprio sistema:

Codice 2.12: /etc/hosts per un solo PC o per un PC totalmente integrato

127.0.0.1     localhost tux

Salvare e uscire per continuare.

Se non si ha PCMCIA, si può continuare con le Informazioni sul sistema. Coloro che hanno PCMCIA possono invece leggere la parte seguente.

Opzionale: Far funzionare PCMCIA

Nota: pcmcia-cs al momento è disponibile solo per le piattaforme x86, amd64 e ppc.

Gli utenti PCMCIA devono innanzitutto installare il pacchetto pcmcia-cs. Questo passo è necessario anche per gli utenti del kernel 2.6 (anche se non utilizzano i driver forniti con il pacchetto).

Codice 2.13: Installare pcmcia-cs

# emerge pcmcia-cs

Dopo aver installato pcmcia-cs, aggiungere pcmcia al runlevel di default:

Codice 2.14: Aggiungere pcmcia al runlevel di default

# rc-update add pcmcia default

8.c. Informazioni sul sistema

Password di Root

Inanzitutto si imposta la password di root scrivendo:

Codice 3.1: Impostazione della password di root

# passwd

Se si pensa di aver bisogno di accedere al sistema tramite console seriale aggiungere tts/0 a /etc/securetty:

Codice 3.2: Aggiungere tts/0 a /etc/securetty

# echo "tts/0" >> /etc/securetty

Informazioni sul sistema

Gentoo usa /etc/rc.conf per la configurazione generale del sistema. Aprire /etc/rc.conf per vederne i contenuti e leggerne le spiegazioni.

Codice 3.3: Aprire /etc/rc.conf

# nano -w /etc/rc.conf

Come si può vedere, questo file contiene tutte le spiegazioni necessarie per impostare le variabili di configurazione. Si presti particolare attenzione a KEYMAP: impostare questo valore in maniera sbagliata significa avere problemi con l'uso della tastiera.

Nota: Gli utenti di sistemi SPARC basati su USB e cloni SPARC, dovrebbero selezionare una tastiera i386 (come "us"), invece di "sunkeymap".

PPC usa le keymap x86 sulla maggior parte dei sistemi. Gli utenti che desiderano utilizzare le keymap ADB al boot devono abilitare i keycode ADB nel kernel ed impostare una keymap mac/ppc in rc.conf.

Se non si sta utilizzando un orologio impostato su UTC, è necessario aggiungere CLOCK="local" al file. In caso contrario l'orologio può avere alcune dissincronie.

Dopo aver finito di configurare /etc/rc.conf, salvare e uscire, e continuare con l'Installazione degli strumenti.

9. Installazione degli strumenti di sistema

9.a. Logger di sistema

Il primo strumento che si deve scegliere serve a fornire un facile logging per il sistema. Unix e Linux hanno una eccellente storia sulle possibilità di logging; se si desidera, nei file di log si può osservare tutto quello che succede sul sistema. Ciò avviene attraverso il logger di sistema.

Gentoo offre molti system logger. Ci sono sysklogd, che è l'insieme tradizionale di demoni per i log di sistema, syslog-ng, un system logger avanzato, e metalog che è un system logger altamente configurabile. Potrebbero già esserne disponibili altri, visto che il numero di pacchetti cresce di giorno in giorno.

Se si sceglie di utilizzare sysklogd o syslog-ng può essere consigliabile l'installazione di logrotate visto che non viene fornito alcun sistema di archiviazione automatica dei log vecchi.

Per installare il logger di sistema scelto, si deve emergerlo e aggiungerlo al runlevel di default con rc-update. L'esempio seguente installa syslog-ng. Ovviamente si deve sostituirlo con il system logger scelto:

Codice 1.1: Installare un system logger

# emerge syslog-ng
# rc-update add syslog-ng default

9.b. Opzionale: Demone cron

Il prossimo strumento è il demone cron. Anche se è opzionale e non richiesto per il sistema, è consigliato installarlo. Di che cosa si tratta? Il demone cron esegue comandi programmati. E' molto utile se si deve eseguire qualche comando regolarmente (per esempio, giornalmente, settimanalmente o mensilmente).

Se si sta installando Gentoo senza supporto di rete, è possibile scegliere solo vixie-cron. Se si desidera installarne un altro è possibile attendere e farlo in seguito.

Codice 2.1: Installare un demone cron

# emerge vixie-cron
# rc-update add vixie-cron default

9.c. Opzionale: indicizzazione dei file

Se si desidera indicizzare i file del proprio sistema in modo da poterli localizzare rapidamente usando locate, è necessario installare sys-apps/slocate.

Codice 3.1: Installazione di slocate

# emerge slocate

9.d. Strumenti per il file system

In base al file system che si sta usando, si devono installare le necessarie utilities (per controllare l'integrità del file system, per creare un file system supplementare etc.).

La seguente tabella elenca gli strumenti necessari da installare se si usa un determinato file system. Non tutti i filesystem sono disponibili per ogni architettura.

File System Strumento Comando di installazione
XFS xfsprogs emerge xfsprogs
ReiserFS reiserfsprogs emerge reiserfsprogs
JFS jfsutils emerge jfsutils

Se non si necessita di ulteriori strumenti per la rete (quali rp-pppoe o un client dhcp) continuare con la Configurazione del bootloader.

9.e. Strumenti di rete

Opzionale: Installare un client DHCP

Se è necessario che Gentoo ottenga automaticamente un indirizzo IP per una o più interfacce di rete è necessario installare dhcpcd (o qualsiasi altro client DHCP). In caso contrario potrebbe non essere possibile utilizzare la rete al termine dell'installazione.

Codice 5.1: Installazione di dhcpcd

# emerge dhcpcd

Opzionale: Installare un client PPPoE

Se si ha bisogno di rp-pppoe per connettersi alla rete, si deve installarlo:

Codice 5.2: Installare rp-pppoe

# USE="-X" emerge rp-pppoe

USE="-X" proibisce a xorg-x11 di essere installato come una dipendenza (rp-pppoe ha strumenti grafici; se si vuole abilitarli, si può ricompilare rp-pppoe più avanti, o installare xorg-x11 adesso, il che però richiede molto tempo per la compilazione).

Continuare ora con la Configurazione del Bootloader.

10. Configurazione del Bootloader

10.a. La scelta

Introduzione

Dopo aver configurato e compilato il kernel e inserito i necessari file di configurazione, è venuto il momento di installare il programma che esegue il kernel nel momento in cui si avvia il sistema. Tale programma è chiamato bootloader.

Opzionale: Framebuffer

Se si è configurato il kernel con il supporto framebuffer (o si è usata la configurazione di default di genkernel) si può attivarlo aggiungendo una istruzione vga e/o video al file di configurazione del kernel.

I sistemi 64-bit devono usare il driver vesafb, e così dovranno impostare l'istruzione vga. L'istruzione vga controlla la risoluzione e la profondità del colore del schermo framebuffer per vesafb. Come previsto nel /usr/src/linux/Documentation/fb/vesafb.txt (installato insieme al kernel) si deve fornire il corrispondente numero VESA alla risoluzione e profondità di colore richieste.

La seguente tabella elenca le risoluzioni e le profondità di colore disponibili, e è necessario far combinare il valore che si deve fornire alla istruzione vga.

640x480 800x600 1024x768 1280x1024
256 0x301 0x303 0x305 0x307
32k 0x310 0x313 0x316 0x319
64k 0x311 0x314 0x317 0x31A
16M 0x312 0x315 0x318 0x31B

L'istruzione video controlla le opzione del display framebuffer. E' necessario che siano dati i driver framebuffer (vesafb per kernel 2.6, o vesa per kernel 2.4) seguiti dalle istruzioni di controllo che si vogliono abilitare. Tutte le variabili sono elencate in /usr/src/linux/Documentation/fb/vesafb.txt, ma qui saranno trattate le tre ozioni più usate:

Controllo Descrizione
ywrap Si assume che la scheda grafica può riavvolgere la sua memoria (per esempio continuare dall'inizio quando si è vicini alla fine)
mtrr Impostare i registri MTRR

Il risultato di queste due istruzioni potrebbe essere simile a vga=0x318 video=vesafb:mtrr,ywrap o video=vesafb:mtrr,ywrap,1024x768-32@85. Ricordarsi (o annotarsi) queste impostazioni, torneranno utili tra poco.

Continuare con l'istallazione di GRUB.

10.b. Usare GRUB

Comprendere la terminologia di GRUB

La parte più critica da capire di GRUB, è quella nella quale si deve prendere confidenza con il modo in cui GRUB si riferisce ai dischi e alle partizioni. La partizione di Linux /dev/hda1 è chiamata da GRUB (hd0,0). Prestare attenzione alle parentesi tra hd0,0, sono necessarie.

I dischi vengono contati da zero invece che da "a", e le partizioni partono da zero invece che da uno. Prestare ancora attenzione al fatto che tra le periferiche hd vengono inclusi solo gli hard disk e non le periferiche atapi-ide come i lettori cdrom e i masterizzatori. Lo stesso vale per i dischi scsi. (Normalmente questi prendono numeri più alti rispetto a quelli ide, eccetto quando il bios è configurato per fare il boot dai dischi scsi.) Quando si imposta il BIOS per avviare da un hard disk differente, questo hard disk è visto come hd0.

Avendo quindi un hard disk in /dev/hda, un lettore cdrom in /dev/hdb, un masterizzatore in /dev/hdc, un secondo hard disk in /dev/hdd e nessun disco SCSI, /dev/hdd7 viene trasformato in (hd1,6). Potrebbe suonare complicato e lo è in effetti, ma come si vedrà, GRUB offre un meccanismo di completamento con il tasto TAB che si dimostra comodo per coloro che hanno un numero elevato di hard disk e partizioni, e per coloro che sono a disagio con lo schema numerico di GRUB.

Dopo essere entrati nello spirito è il momento di installare GRUB.

Installare GRUB

Per installare GRUB, si deve prima emergerlo:

Codice 2.1: Installare GRUB

# emerge grub

Nonostante GRUB sia installato, si deve ancora modificare un file di configurazione per GRUB, ed installare GRUB nel MBR così che GRUB avvii automaticamente il kernel. Creare /boot/grub/grub.conf con nano (o con un altro editor):

Codice 2.2: Creare /boot/grub/grub.conf

# nano -w /boot/grub/grub.conf

Ora è necessario modificare grub.conf. Seguono due possibili grub.conf per l'esempio di partizione usato in questa guida che utilizza l'immagine del kernel kernel-2.6.11-gentoo-r1. Viene però analizzato a fondo solo il primo grub.conf.

  • Il primo grub.conf è per chi non ha usato genkernel per compilare il kernel
  • Il secondo grub.conf è per chi ha usato genkernel per compilare il kernel

Nota: Se la partizione root usa il filesystem JFS, si deve mettere "ro" alla riga del kernel così può ripetere il log prima che venga montata in lettura e scrittura.

Codice 2.3: grub.conf per utenti che non hanno usato genkernel

# Quale opzione viene avviata di default. 0 è la prima, 1 la seconda etc.
default 0
# Quanti secondi attendere prima di avviare l'opzione di default.
timeout 30
# Un'immagine gradevole
# Da commentare se non si dispone di scheda grafica
splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux 2.6.11 Gentoo r1
# La partizione dove si trova l'immagine del kernel (o il sistema operativo)
root (hd0,0)
kernel /kernel-2.6.11-gentoo-r1 root=/dev/hda3

# Le prossime quattro righe vanno messe solo se si ha un dualboot con Windows.
# In questo caso, Windows è in /dev/hda6.
title=Windows XP
rootnoverify (hd0,5)
makeactive
chainloader +1

Codice 2.4: grub.conf per utenti che hanno usato il genkernel

default 0
timeout 30
splashimage=(hd0,0)/grub/splash.xpm.gz

title=Gentoo Linux 2.6.11-gentoo-r1
root (hd0,0)
kernel /kernel-2.6.11-gentoo-r1 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev
initrd /initrd-2.6.11-gentoo-r1

# Solo nel caso si desideri il dual-boot
title=Windows XP
root (hd0,5)
makeactive
chainloader +1

Nota: Se si usa uno schema di partizioni e/o un'immagine del kernel differenti da quelli dell'esempio, cambiare le impostazioni di conseguenza. Assicurarsi che qualsiasi cosa che segue un GRUB-device (come (hd0,0)), sia relativa al mountpoint, e non a root. In altre parole, (hd0,0)/grub/splash.xpm.gz è /boot/grub/splash.xpm.gz poichè (hd0,0) è /boot.

Se si ha bisogno di inserire opzioni ulteriori al kernel, si deve aggiungerle alla fine dei comandi del kernel. Si è già inserita una opzione (root=/dev/hda3 o real_root=/dev/hda3), ma se ne possono inserire altre, ad esempio l'istruzione video per il framebuffer, di cui si è parlato precedentemente:

Coloro che usano genkernel devono sapere che i loro kernel hanno le stesse opzioni di boot del CD di installazione. Per esempio, se si dispone di un disco SCSI, si dovrebbe aggiungere doscsi come opzione del kernel.

Salvare il file grub.conf e uscire. Si deve installare GRUB nel MBR (Master Boot Record).

Gli sviluppatori di GRUB raccomandano l'uso di grub-install. Se per qualche ragione grub-install non funziona correttamente, si può installare GRUB manualmente.

Continuare con Default: Installare GRUB con grub-install o Alternativa: Installare GRUB con le istruzioni manuali.

Default: Installare GRUB con grub-install

Per installare GRUB ci sarà bisogno del comando grub-install. Però, grub-install non funziona subito dato che si è dentro un ambiente in cui si è effettuato il chroot. Si deve prima aggiornare /etc/mtab (il file con le informazioni su tutti i filesystem montati): fortunatamente c'è un modo facile per farlo, basta copiare /proc/mounts in /etc/mtab:

Codice 2.5: Aggiornare /etc/mtab

# cp /proc/mounts /etc/mtab

Ora si può installare GRUB con grub-install:

Codice 2.6: Eseguire grub-install

# grub-install /dev/hda

Se si hanno altre domande su GRUB, consultare le GRUB FAQ o il GRUB Manual.

Continuare con Riavviare il sistema.

Alternativa: Installare GRUB con le istruzioni manuali

Per iniziare la configurazione di GRUB, digitare grub. Viene visualizzato il prompt della linea di comando di grub, grub>. Ora si può procedere a digitare i comandi corretti per installare il boot record di GRUB sull'hard disk.

Codice 2.7: Avviare la shell di GRUB

# grub

Nota: Se il sistema non dispone di un lettore floppy, aggiungere l'opzione --no-floppy al comando precedente per evitare che grub lo cerchi.

Nella configurazione di esempio, si desidera installare GRUB in modo che legga le proprie informazioni dalla partizione di boot /dev/hda1 e installare il boot record di GRUB nel MBR (master boot record) dell'hard disk, in modo che la prima cosa che si veda, quando si accende il computer, è il prompt di GRUB. Se non si è seguita la configurazione di esempio durante l'installazione, è necessario cambiare i comandi di conseguenza.

Il meccanismo di completamento con il tasto TAB, può essere usato da dentro GRUB. Per esempio, se si digita "root (" seguito da TAB, viene elencata una lista degli hard disk disponibili (come hd0). Se si digita "root (hd0," seguito da TAB, viene invece elencata una lista delle partizioni disponibili nel disco (come hd0,0).

Con il tasto TAB non dovrebbe essere difficile impostare GRUB . Ecco ora la vera e propria configurazione di GRUB.

Codice 2.8: Installare GRUB nel MBR

grub> root (hd0,0)          (Specifica dove è la partizione /boot)
grub> setup (hd0)           (Installa GRUB nel MBR)
grub> quit                  (Esce dalla shell di GRUB)

Nota: Se si desidera installare GRUB in un'altra partizione, invece che nel MBR, è necessario cambiare il comando setup, in modo che esso punti alla partizione corretta. Per esempio, se si vuole installare GRUB in /dev/hda3, allora il comando diventa setup (hd0,2). Ma questo non è un caso molto comune.

Se si hanno altre domande su GRUB, consultare le GRUB FAQ o il GRUB Manual.

Ora continuare con Riavviare il sistema

10.c. Riavviare il sistema

Uscire dall'ambiente in cui si è fatto il chroot e smontare tutte le partizioni montate. Poi digitare il comando reboot.

Codice 3.1: Smontare tutte le partizioni e riavviare

# exit
# cd
# umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo
# reboot

Naturalmente non dimenticarsi di rimuovere il CD avviabile, altrimenti il CD ripartirà di nuovo invece del nuovo sistema Gentoo.

Dopo aver riavviato, finire con Termine dell'installazione Gentoo.

11. Termine dell'installazione Gentoo

11.a. Gestione utente

Aggiungere un utente per l'uso quotidiano

Lavorare come root su un sistema Unix/Linux è pericoloso e andrebbe evitato per quanto possibile. Per questo è fortemente raccomandato aggiungere un utente per l'uso quotidiano.

I gruppi a cui l'utente appartiene definiscono le attività che l'utente è autorizzato a effettuare. La seguente tabella elenca una serie dei più comuni gruppi:

Gruppo Descrizione
audio abilita l'accesso ai dispositivi audio
cdrom abilita l'accesso diretto ai dispositivi ottici
floppy abilita l'accesso diretto ai floppy
games abilita il gioco
usb abilita l'accesso ai dispositivi USB
video abilita l'accesso all'hardware e all'accelerazione
wheel abilita l'utilizzo di su

Per esempio, per creare un utente chiamato john, che è membro dei gruppi wheel, users e audio accedere come root ed eseguire useradd:

Codice 1.1: Aggiungere un utente per l'uso quotidiano

Login: root
Password: (inserire la password di root)

# useradd john -m -G users,wheel,audio -s /bin/bash
# passwd john
Password: (Digitare la password per john)
Re-enter password: (Ridigitare la password per verificare)

Se questo utente dovesse effettuare qualche operazione come root, può usare su - per ricevere temporaneamente i privilegi di root. Un altro modo è quello di usare il pacchetto sudo, che è molto sicuro, se configurato correttamente.

11.b. Opzionale: Installare i pacchetti GRP

Importante: Questa parte è per gli utenti che desiderano installare GRP. Chi non lo usa, può saltarla e continuare con Cosa fare adesso?.

Dopo che il sistema si è avviato, fare il login con l'utente che si è creato (per esempio, john) e usare su - per ottenere i privilegi di root:

Codice 2.1: Ottenere i privilegi di root

$ su -
Password: (Digitare la password di root)

Ora bisogna cambiare la configurazione di Portage, per cercare i binari precompilati nel secondo CD (CD di pacchetti Gentoo). Per prima cosa si monti il CD:

Codice 2.2: Montare il CD di pacchetti

(Inserire il CD di pacchetti)
# mount /mnt/cdrom

Si configuri Portage a usare /mnt/cdrom per i suoi pacchetti precompilati:

Codice 2.3: Configurare Portage a usare /mnt/cdrom

# ls /mnt/cdrom

(Se c'è una directory /mnt/cdrom/packages:)
# export PKGDIR="/mnt/cdrom/packages"

(Altrimenti:)
# export PKGDIR="/mnt/cdrom"

Si possono installare i pacchetti che si desiderano. Il CD di pacchetti contiene molti binari precompilati, per esempio KDE:

Codice 2.4: Installare KDE

# emerge --usepkg kde

Assicurarsi di installare ora i binari. Quando si fa un emerge --sync per aggiornare Portage (come si vedrà più avanti), i binari precompilati potrebbero non corrispondere con gli ebuild del Portage aggiornato. Si può cercare di aggirare questa situazione, digitando emerge --usepkgonly e non emerge --usepkg.

Congratulazioni, si ha un sistema totalmente funzionante. Continuare con Cosa fare adesso? per conoscere altre cose su Gentoo.

12. Cosa fare adesso?

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

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.

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

12.c. Cambiamenti di Gentoo dalla 2005.0

Cambiamenti

Gentoo è sempre in rapido cambiamento. Le sezioni seguenti descrivono cambiamenti importanti che interessano una installazione Gentoo. Saranno elencati solo quelli che importano ad una installazione, non i cambiamenti di pacchetti che non occorrono durante una installazione.

I seguenti cambiamenti devono riferirsi a dopo aver aggiornato il sistema (e prima di fare il reboot).

  • Il pacchetto baselayout è stato aggiornato in diverse parti, tra cui la Configurazione della rete. I cambiamenti coinvolgono soprattutto la nuova sintassi per il file /etc/conf.d/net, sebbene il vecchio formato sia ancora supportato. E' consigliato procedere all'aggiornamento appena possibile.

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

  1. USE predefinita dichiarata nei file make.defaults parte del proprio profilo
  2. Configurazione USE definita dall'utente in /etc/portage/make.conf
  3. Configurazione USE definita dall'utente in /etc/portage/package.use
  4. 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

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

6. L'applicativo Ebuild

D. Configurazione di rete di Gentoo

1. Configurazione comune

1.a. Getting started

Nota: This document assumes that you have correctly configured your kernel, its modules for your hardware and you know the interface name of your hardware. We also assume that you are configuring eth0, but it could also be eno0, ens1, wlan0, enp1s0 etc.

To get started configuring your network card, you need to tell the Gentoo RC system about it. This is done by creating a symbolic link from net.lo to net.eth0 (or whatever the network interface name is on your system) in /etc/init.d.

Codice 1.1: Symlinking net.eth0 to net.lo

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

Gentoo's RC system now knows about that interface. It also needs to know how to configure the new interface. All the network interfaces are configured in /etc/conf.d/net. Below is a sample configuration for DHCP and static addresses.

Codice 1.2: Examples for /etc/conf.d/net

# For DHCP
config_eth0="dhcp"

# For static IP using CIDR notation
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"

# For static IP using netmask notation
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: If you do not specify a configuration for your interface then DHCP is assumed.

Nota: CIDR stands for Classless InterDomain Routing. Originally, IPv4 addresses were classified as A, B, or C. The early classification system did not envision the massive popularity of the Internet, and is in danger of running out of new unique addresses. CIDR is an addressing scheme that allows one IP address to designate many IP addresses. A CIDR IP address looks like a normal IP address except that it ends with a slash followed by a number; for example, 192.168.0.0/16. CIDR is described in RFC 1519.

Now that we have configured our interface, we can start and stop it using the following commands:

Codice 1.3: Starting and stopping network scripts

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

Importante: When troubleshooting networking, take a look at /var/log/rc.log. Unless you have rc_logger="NO" set in /etc/rc.conf, you will find information on the boot activity stored in that log file.

Now that you have successfully started and stopped your network interface, you may wish to get it to start when Gentoo boots. Here's how to do this. The last "rc" command instructs Gentoo to start any scripts in the current runlevel that have not yet been started.

Codice 1.4: Configuring a network interface to load at boot time

# rc-update add net.eth0 default
# rc

2. Configurazione Avanzata

2.a. Advanced Configuration

The config_eth0 variable is the heart of an interface configuration. It's a high level instruction list for configuring the interface (eth0 in this case). Each command in the instruction list is performed sequentially. The interface is deemed OK if at least one command works.

Here's a list of built-in instructions.

Command Description
null Do nothing
noop If the interface is up and there is an address then abort configuration successfully
an IPv4 or IPv6 address Add the address to the interface
dhcp, adsl or apipa (or a custom command from a 3rd party module) Run the module which provides the command. For example dhcp will run a module that provides DHCP which can be one of either dhcpcd, dhclient or pump.

If a command fails, you can specify a fallback command. The fallback has to match the config structure exactly.

You can chain these commands together. Here are some real world examples.

Codice 1.1: Configuration examples

# Adding three IPv4 addresses
config_eth0="192.168.0.2/24
192.168.0.3/24
192.168.0.4/24"

# Adding an IPv4 address and two IPv6 addresses
config_eth0="192.168.0.2/24
4321:0:1:2:3:4:567:89ab
4321:0:1:2:3:4:567:89ac"

# Keep our kernel assigned address, unless the interface goes
# down so assign another via DHCP. If DHCP fails then add a
# static address determined by APIPA
config_eth0="noop
dhcp"
fallback_eth0="null
apipa"

Nota: When using the ifconfig module and adding more than one address, interface aliases are created for each extra address. So with the above two examples you will get interfaces eth0, eth0:1 and eth0:2. You cannot do anything special with these interfaces as the kernel and other programs will just treat eth0:1 and eth0:2 as eth0.

Importante: The fallback order is important! If we did not specify the null option then the apipa command would only be run if the noop command failed.

Nota: APIPA and DHCP are discussed later.

2.b. Network Dependencies

Init scripts in /etc/init.d can depend on a specific network interface or just net. All network interfaces in Gentoo's init system provide what is called net.

If, in /etc/rc.conf, rc_depend_strict="YES" is set, then all network interfaces that provide net must be active before a dependency on "net" is assumed to be met. In other words, if you have a net.eth0 and net.eth1 and an init script depends on "net", then both must be enabled.

On the other hand, if rc_depend_strict="NO" is set, then the "net" dependency is marked as resolved the moment at least one network interface is brought up.

But what about net.br0 depending on net.eth0 and net.eth1? net.eth1 may be a wireless or PPP device that needs configuration before it can be added to the bridge. This cannot be done in /etc/init.d/net.br0 as that's a symbolic link to net.lo.

The answer is defining an rc_need_ setting in /etc/conf.d/net.

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

rc_need_br0="net.eth0 net.eth1"

That alone, however, is not sufficient. Gentoo's networking init scripts use a virtual dependency called net to inform the system when networking is available. Clearly, in the above case, networking should only be marked as available when net.br0 is up, not when the others are. So we need to tell that in /etc/conf.d/net as well:

Codice 2.2: Updating virtual dependencies and provisions for networking

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

For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo Handbook. More information about /etc/rc.conf is available as comments within that file.

2.c. Variable names and values

Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid".

However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name, such as foo. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because you can configure networking parameters per ESSID.

The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into a _ character.

Another downside of bash is the content of variables - some characters need to be escaped. This can be achived by placing the \ character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \.

In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:

Codice 3.1: variable name example

(This does work, but the domain is invalid)
dns_domain_My____NET="My \"\\ NET"

(The above sets the dns domain to My "\ NET when a wireless card
connects to an AP whose ESSID is My "\ NET)

2.d. Network Interface Naming

How It Works

Network interface names are not chosen arbitrarily: the Linux kernel and the device manager (most systems have udev as their device manager although others are available as well) choose the interface name through a fixed set of rules.

When an interface card is detected on a system, the Linux kernel gathers the necessary data about this card. This includes:

  1. the onboard (on the interface itself) registered name of the network card, which is later seen through the ID_NET_NAME_ONBOARD parameter;
  2. the slot in which the network card is plugged in, which is later seen through the ID_NET_NAME_SLOT parameter;
  3. the path through which the network card device can be accessed, which is later seen through the ID_NET_NAME_PATH parameter;
  4. the (vendor-provided) MAC address of the card, which is later seen through the ID_NET_NAME_MAC parameter;

Based on this information, the device manager decides how to name the interface on the system. By default, it uses the first hit of the first three parameters above (ID_NET_NAME_ONBOARD, _SLOT or _PATH). For instance, if ID_NET_NAME_ONBOARD is found and set to eno1, then the interface will be called eno1.

If you know your interface name, you can see the values of the provided parameters using udevadm:

Codice 4.1: Reading the network interface card information

# udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null
ID_NET_NAME_MAC=enxc80aa9429d76
ID_OUI_FROM_DATABASE=Quanta Computer Inc.
ID_NET_NAME_PATH=enp3s0

As the first (and actually only) hit of the top three parameters is the ID_NET_NAME_PATH one, its value is used as the interface name. If none of the parameters is found, then the system reverts back to the kernel-provided naming (eth0, eth1, etc.)

Using the Old-style Kernel Naming

Before this change, network interface cards were named by the Linux kernel itself, depending on the order that drivers are loaded (amongst other, possibly more obscure reasons). This behavior can still be enabled by setting the net.ifnames=0 boot option in the boot loader.

Using your Own Names

The entire idea behind the change in naming is not to confuse people, but to make changing the names easier. Suppose you have two interfaces that are otherwise called eth0 and eth1. One is meant to access the network through a wire, the other one is for wireless access. With the support for interface naming, you can have these called lan0 (wired) and wifi0 (wireless - it is best to avoid using the previously well-known names like eth* and wlan* as those can still collide with your suggested names).

All you need to do is to find out what the parameters are for the cards and then use this information to set up your own naming rule:

Codice 4.2: Setting the lan0 name for the current eth0 interface

# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
ID_NET_NAME_MAC=enxc80aa9429d76
ID_OUI_FROM_DATABASE=Quanta Computer Inc.

# vim /etc/udev/rules.d/70-net-name-use-custom.rules
# First one uses MAC information, and 70- number to be before other net rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:0a:a9:42:9d:76", NAME="lan0"

# vim /etc/udev/rules.d/76-net-name-use-custom.rules
# Second one uses ID_NET_NAME_PATH information, and 76- number to be between
# 75-net-*.rules and 80-net-*.rules
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"

Because the rules are triggered before the default one (rules are triggered in alphanumerical order, so 70 comes before 80) the names provided in the rule file will be used instead of the default ones. The number granted to the file should be between 76 and 79 (the environment variables are defined by a rule start starts with 75 and the fallback naming is done in a rule numbered 80).

3. Impostazioni modulari

3.a. Network Modules

We now support modular networking scripts, which means we can easily add support for new interface types and configuration modules while keeping compatibility with existing ones.

Modules load by default if the package they need is installed. If you specify a module here that doesn't have its package installed then you get an error stating which package you need to install. Ideally, you only use the modules setting when you have two or more packages installed that supply the same service and you need to prefer one over the other.

Nota: All settings discussed here are stored in /etc/conf.d/net unless otherwise specified.

Codice 1.1: Module preference

# Prefer ifconfig over iproute2
modules="ifconfig"

# You can also specify other modules for an interface
# In this case we prefer pump over dhcpcd
modules_eth0="pump"

# You can also specify which modules not to use - for example you may be
# using a supplicant or linux-wlan-ng to control wireless configuration but
# you still want to configure network settings per ESSID associated with.
modules="!iwconfig"

3.b. Interface Handlers

We provide two interface handlers presently: ifconfig and iproute2. You need one of these to do any kind of network configuration.

ifconfig is installed by default (the net-tools package is part of the system profile). iproute2 is a more powerful and flexible package, but it's not included by default.

Codice 2.1: To install iproute2

# emerge sys-apps/iproute2

# To prefer ifconfig over iproute2 if both are installed as openrc prefers
# to use iproute2 then
modules="ifconfig"

As both ifconfig and iproute2 do very similar things we allow their basic configuration to work with each other. For example both the below code snippet work regardless of which module you are using.

Codice 2.2: ifconfig and iproute2 examples

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

# We can also specify 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 is a means of obtaining network information (IP address, DNS servers, Gateway, etc) from a DHCP server. This means that if there is a DHCP server running on the network, you just have to tell each client to use DHCP and it sets up the network all by itself. Of course, you will have to configure for other things like wireless, PPP or other things if required before you can use DHCP.

DHCP can be provided by dhclient, dhcpcd, or pump. Each DHCP module has its pros and cons - here's a quick run down.

DHCP Module Package Pros Cons
dhclient net-misc/dhcp Made by ISC, the same people who make the BIND DNS software. Very configurable Configuration is overly complex, software is quite bloated, cannot get NTP servers from DHCP, does not send hostname by default
dhcpcd net-misc/dhcpcd Long time Gentoo default, no reliance on outside tools, actively developed by Gentoo Can be slow at times, does not yet daemonize when lease is infinite
pump net-misc/pump Lightweight, no reliance on outside tools No longer maintained upstream, unreliable, especially over modems, cannot get NIS servers from DHCP

If you have more than one DHCP client installed, you need to specify which one to use - otherwise we default to dhcpcd if available.

To send specific options to the DHCP module, use module_eth0="..." (change module to the DHCP module you're using - i.e. dhcpcd_eth0).

We try and make DHCP relatively agnostic - as such we support the following commands using the dhcp_eth0 variable. The default is not to set any of them:

  • release - releases the IP address for re-use
  • nodns - don't overwrite /etc/resolv.conf
  • nontp - don't overwrite /etc/ntp.conf
  • nonis - don't overwrite /etc/yp.conf

Codice 3.1: Sample DHCP configuration in /etc/conf.d/net

# Only needed if you have more than one DHCP module installed
modules="dhcpcd"

config_eth0="dhcp"
dhcpcd_eth0="-t 10" # Timeout after 10 seconds
dhcp_eth0="release nodns nontp nonis" # Only get an address

Nota: dhcpcd and pump send the current hostname to the DHCP server by default so you don't need to specify this anymore.

3.d. ADSL with PPPoE/PPPoA

First we need to install the ADSL software.

Codice 4.1: Install the ppp package

# emerge net-dialup/ppp

Second, create the PPP net script and the net script for the ethernet interface to be used by PPP:

Codice 4.2: Creating the PPP and ethernet scripts

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

Be sure to set rc_depend_strict to "YES" in /etc/rc.conf.

Now we need to configure /etc/conf.d/net.

Codice 4.3: A basic PPPoE setup

config_eth0=null (Specify your ethernet interface)
config_ppp0="ppp"
link_ppp0="eth0" (Specify your ethernet interface)
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"

You can also set your password in /etc/ppp/pap-secrets.

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

# The * is important
"username"  *  "password"

If you use PPPoE with a USB modem you'll need to emerge br2684ctl. Please read /usr/portage/net-dialup/speedtouch-usb/files/README for information on how to properly configure it.

Importante: Please carefully read the section on ADSL and PPP in /usr/share/doc/netifrc-*/net.example.bz2. It contains many more detailed explanations of all the settings your particular PPP setup will likely need.

3.e. APIPA (Automatic Private IP Addressing)

APIPA tries to find a free address in the range 169.254.0.0-169.254.255.255 by arping a random address in that range on the interface. If no reply is found then we assign that address to the interface.

This is only useful for LANs where there is no DHCP server and you don't connect directly to the internet and all other computers use APIPA.

For APIPA support, emerge net-misc/iputils or net-analyzer/arping.

Codice 5.1: APIPA configuration in /etc/conf.d/net

# Try DHCP first - if that fails then fallback to APIPA
config_eth0="dhcp"
fallback_eth0="apipa"

# Just use APIPA
config_eth0="apipa"

3.f. Bonding

For link bonding/trunking emerge net-misc/ifenslave.

Bonding is used to increase network bandwidth. If you have two network cards going to the same network, you can bond them together so your applications see just one interface but they really use both network cards.

First, clear the configuration of the participating interfaces:

Codice 6.1: Clearing interface configuration in /etc/conf.d/net

config_eth0="null"
config_eth1="null"
config_eth2="null"

Next, define the bonding between the interfaces:

Codice 6.2: Define the bonding

slaves_bond0="eth0 eth1 eth2"
config_bond0="192.168.100.4/24"

Remove the net.eth* services from the runlevels, create a net.bond0 one and add that one to the correct runlevel.

3.g. Bridging (802.1d support)

For bridging support emerge net-misc/bridge-utils.

Bridging is used to join networks together. For example, you may have a server that connects to the internet via an ADSL modem and a wireless access card to enable other computers to connect to the internet via the ADSL modem. You could create a bridge to join the two interfaces together.

Codice 7.1: Bridge configuration in /etc/conf.d/net

# Configure the bridge - "man brctl" for more details
brctl_br0="setfd 0
sethello 2
stp on"

# To add ports to bridge br0
bridge_br0="eth0 eth1"

# You need to configure the ports to null values so dhcp does not get started
config_eth0="null"
config_eth1="null"

# Finally give the bridge an address - you could use DHCP as well
config_br0="192.168.0.1/24"

# Depend on eth0 and eth1 as they may require extra configuration
rc_need_br0="net.eth0 net.eth1"

Importante: For using some bridge setups, you may need to consult the variable name documentation.

3.h. MAC Address

If you need to, you can change the MAC address of your interfaces through the network configuration file too.

Codice 8.1: MAC Address change example

# To set the MAC address of the interface
mac_eth0="00:11:22:33:44:55"

# To randomize the last 3 bytes only
mac_eth0="random-ending"

# To randomize between the same physical type of connection (e.g. fibre,
# copper, wireless) , all vendors
mac_eth0="random-samekind"

# To randomize between any physical type of connection (e.g. fibre, copper,
# wireless) , all vendors
mac_eth0="random-anykind"

# Full randomization - WARNING: some MAC addresses generated by this may
# NOT act as expected
mac_eth0="random-full"

3.i. Tunnelling

You don't need to emerge anything for tunnelling as the interface handler can do it for you.

Codice 9.1: Tunnelling configuration in /etc/conf.d/net

# For GRE tunnels
iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"

# For IPIP tunnels
iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"

# To configure the interface
config_vpn0="192.168.0.2 peer 192.168.1.1"

3.j. VLAN (802.1q support)

For VLAN support, make sure that sys-apps/iproute2 is installed and ensure that iproute2 is used as configuration module rather than ifconfig.

Virtual LAN is a group of network devices that behave as if they were connected to a single network segment - even though they may not be. VLAN members can only see members of the same VLAN even though they may share the same physical network.

To configure VLANs, first specify the VLAN numbers in /etc/conf.d/net like so:

Codice 10.1: Specifying VLAN numbers

vlans_eth0="1 2"

Next, configure the interface for each VLAN:

Codice 10.2: Interface configuration for each VLAN

config_eth0_1="172.16.3.1 netmask 255.255.254.0"
routes_eth0_1="default via 172.16.3.254"

config_eth0_2="172.16.2.1 netmask 255.255.254.0"
routes_eth0_2="default via 172.16.2.254"

VLAN-specific configurations are handled by vconfig like so:

Codice 10.3: Configuring the VLANs

vlan1_name="vlan1"
vlan1_ingress="2:6 3:5"
eth0_vlan1_egress="1:2"

Importante: For using some VLAN setups, you may need to consult the variable name documentation.

4. Reti Wireless

4.a. Introduction

Wireless networking on Linux is usually pretty straightforward. There are two ways of configuring wifi: graphical clients, or the command line.

The easiest way is to use a graphical client once you've installed a desktop environment. Most graphical clients, such as wicd and NetworkManager, are pretty self-explanatory. They offer a handy point-and-click interface that gets you on a network in just a few seconds.

Nota: wicd offers a command line utility in addition to the main graphical interface. You can get it by emerging wicd with the ncurses USE flag set. This wicd-curses utility is particularly useful for folks who don't use a gtk-based desktop environment, but still want an easy command line tool that doesn't require hand-editing configuration files.

However, if you don't want to use a graphical client, then you can configure wifi on the command line by editing a few configuration files. This takes a bit more time to setup, but it also requires the fewest packages to download and install. Since the graphical clients are mostly self-explanatory (with helpful screenshots at their homepages), we'll focus on the command line alternatives.

You can setup wireless networking on the command line by installing wireless-tools or wpa_supplicant. The important thing to remember is that you configure wireless networks on a global basis and not an interface basis.

wpa_supplicant is the best choice. For a list of supported drivers, read the wpa_supplicant site.

wireless-tools supports nearly all cards and drivers, but it cannot connect to WPA-only Access Points. If your networks only offer WEP encryption or are completely open, you may prefer the simplicity of wireless-tools.

Avvertenza: The linux-wlan-ng driver is not supported by baselayout at this time. This is because linux-wlan-ng have its own setup and configuration which is completely different to everyone else's. The linux-wlan-ng developers are rumoured to be changing their setup over to wireless-tools, so when this happens you may use linux-wlan-ng with baselayout.

Some wireless cards are deactivated by default. To activate them, please consult your hardware documentation. Some of these cards can be unblocked using the rfkill application. If that is the case, use "rfkill list" to see the available cards and "rfkill unblock <index>" to activate the wireless functionality. If not, you might need to unblock the wireless card through a button, switch or special key combination on your laptop.

4.b. WPA Supplicant

WPA Supplicant is a package that allows you to connect to WPA enabled access points.

Codice 2.1: Install wpa_supplicant

# emerge net-wireless/wpa_supplicant

Importante: You have to have CONFIG_PACKET enabled in your kernel for wpa_supplicant to work. Try running grep CONFIG_PACKET /usr/src/linux/.config to see if you have it enabled in your kernel.

Nota: Depending on your USE flags, wpa_supplicant can install a graphical interface written in Qt4, which will integrate nicely with KDE. To get it, run echo "net-wireless/wpa_supplicant qt4" >> /etc/portage/package.use as root before emerging wpa_supplicant.

Now we have to configure /etc/conf.d/net to so that we prefer wpa_supplicant over wireless-tools (if both are installed, wireless-tools is the default).

Codice 2.2: configure /etc/conf.d/net for wpa_supplicant

# Prefer wpa_supplicant over wireless-tools
modules="wpa_supplicant"

# It's important that we tell wpa_supplicant which driver we should
# be using as it's not very good at guessing yet
wpa_supplicant_eth0="-Dmadwifi"

Nota: If you're using the host-ap driver you will need to put the card in Managed mode before it can be used with wpa_supplicant correctly. You can use iwconfig_eth0="mode managed" to achieve this in /etc/conf.d/net.

That was simple, wasn't it? However, we still have to configure wpa_supplicant itself which is a bit more tricky depending on how secure the Access Points are that you are trying to connect to. The below example is taken and simplified from /usr/share/doc/wpa_supplicant-<version>/wpa_supplicant.conf.gz which ships with wpa_supplicant.

Codice 2.3: An example /etc/wpa_supplicant/wpa_supplicant.conf

# The below line not be changed otherwise we refuse to work
ctrl_interface=/var/run/wpa_supplicant

# Ensure that only root can read the WPA configuration
ctrl_interface_group=0

# Let wpa_supplicant take care of scanning and AP selection
ap_scan=1

# Simple case: WPA-PSK, PSK as an ASCII passphrase, allow all valid ciphers
network={
  ssid="simple"
  psk="very secret passphrase"
  # The higher the priority the sooner we are matched
  priority=5
}

# Same as previous, but request SSID-specific scanning (for APs that reject
# broadcast SSID)
network={
  ssid="second ssid"
  scan_ssid=1
  psk="very secret passphrase"
  priority=2
}

# Only WPA-PSK is used. Any valid cipher combination is accepted
network={
  ssid="example"
  proto=WPA
  key_mgmt=WPA-PSK
  pairwise=CCMP TKIP
  group=CCMP TKIP WEP104 WEP40
  psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb
  priority=2
}

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

# Shared WEP key connection (no WPA, no IEEE 802.1X)
network={
  ssid="static-wep-test"
  key_mgmt=NONE
  # Keys in quotes are ASCII keys
  wep_key0="abcde"
  # Keys specified without quotes are hex keys
  wep_key1=0102030405
  wep_key2="1234567890123"
  wep_tx_keyidx=0
  priority=5
}

# Shared WEP key connection (no WPA, no IEEE 802.1X) using Shared Key
# IEEE 802.11 authentication
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
}

# IBSS/ad-hoc network with 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

Initial setup and Managed Mode

Wireless Tools provide a generic way to configure basic wireless interfaces up to the WEP security level. While WEP is a weak security method it's also the most prevalent.

Wireless Tools configuration is controlled by a few main variables. The sample configuration file below should describe all you need. One thing to bear in mind is that no configuration means "connect to the strongest unencrypted Access Point" - we will always try and connect you to something.

Codice 3.1: Install wireless-tools

# emerge net-wireless/wireless-tools

Nota: Although you can store your wireless settings in /etc/conf.d/wireless this guide recommends you store them in /etc/conf.d/net.

Importante: You will need to consult the variable name documentation.

Codice 3.2: sample iwconfig setup in /etc/conf.d/net

# Prefer iwconfig over wpa_supplicant
modules="iwconfig"

# Configure WEP keys for Access Points called ESSID1 and ESSID2
# You may configure up to 4 WEP keys, but only 1 can be active at
# any time so we supply a default index of [1] to set key [1] and then
# again afterwards to change the active key to [1]
# We do this incase you define other ESSID's to use WEP keys other than 1
#
# Prefixing the key with s: means it's an ASCII key, otherwise a HEX key
#
# enc open specified open security (most secure)
# enc restricted specified restricted security (least secure)
key_ESSID1="[1] s:yourkeyhere key [1] enc open"
key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted"

# The below only work when we scan for available Access Points

# Sometimes more than one Access Point is visible so we need to
# define a preferred order to connect in
preferred_aps="'ESSID1' 'ESSID2'"

Fine tune Access Point Selection

You can add some extra options to fine-tune your Access Point selection, but these are not normally required.

You can decide whether we only connect to preferred Access Points or not. By default if everything configured has failed and we can connect to an unencrypted Access Point then we will. This can be controlled by the associate_order variable. Here's a table of values and how they control this.

Value Description
any Default behaviour
preferredonly We will only connect to visible APs in the preferred list
forcepreferred We will forceably connect to APs in the preferred order if they are not found in a scan
forcepreferredonly Do not scan for APs - instead just try to connect to each one in order
forceany Same as forcepreferred + connect to any other available AP

Finally we have some blacklist_aps and unique_ap selection. blacklist_aps works in a similar way to preferred_aps. unique_ap is a yes or no value that says if a second wireless interface can connect to the same Access Point as the first interface.

Codice 3.3: blacklist_aps and unique_ap example

# Sometimes you never want to connect to certain access points
blacklist_aps="'ESSID3' 'ESSID4'"

# If you have more than one wireless card, you can say if you want
# to allow each card to associate with the same Access Point or not
# Values are "yes" and "no"
# Default is "yes"
unique_ap="yes"

Ad-Hoc and Master Modes

If you want to set yourself up as an Ad-Hoc node if you fail to connect to any Access Point in managed mode, you can do that too.

Codice 3.4: fallback to ad-hoc mode

adhoc_essid_eth0="This Adhoc Node"

What about connecting to Ad-Hoc networks or running in Master mode to become an Access Point? Here's a configuration just for that! You may need to specify WEP keys as shown above.

Codice 3.5: sample ad-hoc/master configuration

# Set the mode - can be managed (default), ad-hoc or master
# Not all drivers support all modes
mode_eth0="ad-hoc"

# Set the ESSID of the interface
# In managed mode, this forces the interface to try and connect to the
# specified ESSID and nothing else
essid_eth0="This Adhoc Node"

# We use channel 3 if you don't specify one
channel_eth0="9"

Importante: The below is taken verbatim from the BSD wavelan documentation found at the NetBSD documentation. There are 14 channels possible; We are told that channels 1-11 are legal for North America, channels 1-13 for most of Europe, channels 10-13 for France, and only channel 14 for Japan. If in doubt, please refer to the documentation that came with your card or access point. Make sure that the channel you select is the same channel your access point (or the other card in an ad-hoc network) is on. The default for cards sold in North America and most of Europe is 3; the default for cards sold in France is 11, and the default for cards sold in Japan is 14.

Troubleshooting Wireless Tools

There are some more variables you can use to help get your wireless up and running due to driver or environment problems. Here's a table of other things you can try.

Variable Default Value Description
iwconfig_eth0 See the iwconfig man page for details on what to send iwconfig
iwpriv_eth0 See the iwpriv man page for details on what to send iwpriv
sleep_scan_eth0 0 The number of seconds to sleep before attempting to scan. This is needed when the driver/firmware needs more time to active before it can be used.
sleep_associate_eth0 5 The number of seconds to wait for the interface to associate with the Access Point before moving onto the next one
associate_test_eth0 MAC Some drivers do not reset the MAC address associated with an invalid one when they lose or attempt association. Some drivers do not reset the quality level when they lose or attempt association. Valid settings are MAC, quality and all.
scan_mode_eth0 Some drivers have to scan in ad-hoc mode, so if scanning fails try setting ad-hoc here
iwpriv_scan_pre_eth0 Sends some iwpriv commands to the interface before scanning. See the iwpriv man page for more details.
iwpriv_scan_post_eth0 Sends some iwpriv commands to the interface after scanning. See the iwpriv man page for more details.

4.d. Defining network configuration per ESSID

Sometimes, you need a static IP when you connect to ESSID1 and you need DHCP when you connect to ESSID2. In fact, most module variables can be defined per ESSID. Here's how we do this.

Nota: These work if you're using WPA Supplicant or Wireless Tools.

Importante: You will need to consult the variable name documentation.

Codice 4.1: override network settings 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"

# We can define nameservers and other things too
# NOTE: DHCP will override these unless it's told not to
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"

# You override by the MAC address of the Access Point
# This handy if you goto different locations that have the same ESSID
config_001122334455="dhcp"
dhcpcd_001122334455="-t 10"
dns_servers_001122334455="192.168.0.1 192.168.0.2"

5. Ulteriori funzionalità

5.a. Standard function hooks

Four functions can be defined in /etc/conf.d/net which will be called surrounding the start/stop operations. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preup() and predown() functions should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preup() returns a non-zero value, then interface configuration will be aborted. If predown() returns a non-zero value, then the interface will not be allowed to continue deconfiguration.

The return values for the postup() and postdown() functions are ignored since there's nothing to do if they indicate failure.

${IFACE} is set to the interface being brought up/down. ${IFVAR} is ${IFACE} converted to variable name bash allows.

Codice 1.1: pre/post up/down function examples in /etc/conf.d/net

preup() {
  # Test for link on the interface prior to bringing it up.  This
  # only works on some network adapters and requires the ethtool
  # package to be installed.
  if ethtool ${IFACE} | grep -q 'Link detected: no'; then
    ewarn "No link on ${IFACE}, aborting configuration"
    return 1
  fi

  # Remember to return 0 on success
  return 0
}

predown() {
  # The default in the script is to test for NFS root and disallow
  # downing interfaces in that case.  Note that if you specify a
  # predown() function you will override that logic.  Here it is, in
  # case you still want it...
  if is_net_fs /; then
    eerror "root filesystem is network mounted -- can't stop ${IFACE}"
    return 1
  fi

  # Remember to return 0 on success
  return 0
}

postup() {
  # This function could be used, for example, to register with a
  # dynamic DNS service.  Another possibility would be to
  # send/receive mail once the interface is brought up.
       return 0
}

postdown() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)
  return 0
}

Nota: For more information on writing your own functions, please read /usr/share/doc/netifrc-*/net.example.bz2.

5.b. Wireless Tools function hooks

Nota: This will not work with WPA Supplicant - but the ${ESSID} and ${ESSIDVAR} variables are available in the postup() function.

Two functions can be defined in /etc/conf.d/net which will be called surrounding the associate function. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preassociate() function should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preassociate() returns a non-zero value, then interface configuration will be aborted.

The return value for the postassociate() function is ignored since there's nothing to do if it indicates failure.

${ESSID} is set to the exact ESSID of the AP you're connecting to. ${ESSIDVAR} is ${ESSID} converted to a variable name bash allows.

Codice 2.1: pre/post association functions in /etc/conf.d/net

preassociate() {
  # The below adds two configuration variables leap_user_ESSID
  # and leap_pass_ESSID. When they are both configured for the ESSID
  # being connected to then we run the CISCO LEAP script

  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() {
  # This function is mostly here for completeness... I haven't
  # thought of anything nifty to do with it yet ;-)

  return 0
}

Nota: ${ESSID} and ${ESSIDVAR} are unavailable in predown() and postdown() functions.

Nota: For more information on writing your own functions, please read /usr/share/doc/netifrc-*/net.example.bz2.

6. Gestione della rete

6.a. Network Management

If you and your computer are always on the move, you may not always have an ethernet cable or plugged in or an access point available. Also, you may want networking to automatically work when an ethernet cable is plugged in or an access point is found.

Here you can find some tools that help you manage this.

Nota: This document only talks about ifplugd, but there are alternatives such as netplug. netplug is a lightweight alternative to ifplugd, but it relies on your kernel network drivers working correctly, and many drivers do not.

6.b. ifplugd

ifplugd is a daemon that starts and stops interfaces when an ethernet cable is inserted or removed. It can also manage detecting association to Access Points or when new ones come in range.

Codice 2.1: Installing ifplugd

# emerge sys-apps/ifplugd

Configuration for ifplugd is fairly straightforward too. The configuration file is held in /etc/conf.d/net. Run man ifplugd for details on the available variables. Also, see /usr/share/doc/netifrc-*/net.example.bz2 for more examples.

Codice 2.2: Sample ifplug configuration

(Replace eth0 with the interface to be monitored)
ifplugd_eth0="..."

(To monitor a wireless interface)
ifplugd_eth0="--api-mode=wlan"

In addition to managing multiple network connections, you may want to add a tool that makes it easy to work with multiple DNS servers and configurations. This is very handy when you receive your IP address via DHCP. Simply emerge openresolv.

Codice 2.3: Installing openresolv

# emerge openresolv

See man resolvconf to learn more about its features.

Stampa

Aggiornato il 17 agosto 2014

Questa traduzione non è più mantenuta

Oggetto: Questo è il Manuale Gentoo che ha l'obiettivo di centralizzare la documentazione di Gentoo Linux.

Sven Vermeulen
Autore

Roy Marples
Autore

Daniel Robbins
Autore

Chris Houser
Autore

Jerry Alexandratos
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

Grant Goodyear
Revisione

Gerald J. Normandin Jr.
Revisione

Donnie Berkholz
Revisione

Ken Nowack
Revisione

Lars Weiler
Contributi

Marco Mascherpa
Traduzione

Stefano Rossi
Traduzione

Enrico Morelli
Traduzione

Donate to support our development efforts.

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