Disclaimer : Questo manuale è stato sostituito da una nuova versione e non è più mantenuto. |
Indice:
Innanzitutto un caldo benvenuto a Gentoo. Si sta per entrare nel mondo delle possibilità e delle performance. Tutto Gentoo gira intorno alle possibilità. Durante l'installazione di Gentoo questo concetto viene chiarito più volte; è possibile scegliere quanto vogliate compilare autonomamente, come installare Gentoo, che logger di sistema utilizzare, e molto altro.
Gentoo è una veloce e moderna metadistribuzione con una architettura semplice e flessibile. Gentoo è stata costruita con software libero e non nasconde agli utenti i meccanismi che ne stanno alla base. Portage, il sistema di gestione dei pacchetti utilizzato da Gentoo, è scritto in Python: è semplice quindi esaminare e modificare il sorgente. Il sistema di pacchetti di Gentoo è basato sui sorgenti, sebbene sia anche compreso il supporto per precompilati, e la configurazione di Gentoo avviene tramite semplici file di testo. In altre parole è tutto alla luce del sole.
E' molto importante comprendere che le possibilità sono ciò che sta alla base di Gentoo. L'obiettivo è di non forzare mai l'utente a qualcosa che non desidera, al contrario offrire tutte le possibilità di cui si può avere bisogno. Nel caso si abbia un'impressione diversa è possibile segnalarlo.
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 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.
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, un CD bootabile, che contiene tutto ciò di cui si ha bisogno per installare ed eseguire Gentoo Linux. Esistono due tipi di CD di Installazione, l'InstallCD e il LiveCD di installazione. L'InstallCD è un ambiente essenziale che contiene solo gli strumenti necessari per eseguire un'installazione. Il LiveCD di installazione è un ambiente Gentoo Linux completo che può essere utilizzato per diversi scopi, uno dei quali l'installazione. Il LiveCD non è ancora disponibile per tutte le architetture. Se per la propria architettura non è ancora disponibile un LiveCD nel documento viene fatto riferimento all'InstallCD.
Con questo metodo non si 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.
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 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.
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:
Se la propria architettura (o sottoarchitettura) non è tra quelle elencate, non è possibile utilizzare i pacchetti GRP durante l'installazione.
L'introduzione termina qui, si può continuare con Avviare il LiveCD di Installazione/InstallCD.
Prima ancora di cominciare vengono elencate le richieste hardware necessarie per installare Gentoo sulla propria macchina.
| CPU | Tutte le PowerPC64 CPU |
| Sistemi | IBM RS/6000s, Power Macintosh G5, iMac G5, IBP pSeries e IBM OpenPower |
| Memoria | 64 MB |
| Spazio su disco | 1.5 GB (escluso quello swap) |
| Spazio swap | Almeno 256 MB |
Per una lista completa dei sistemi supportati, vedere http://www.linuxppc64.org/hardware.shtml.
2.b. Il CD di installazione Gentoo Universale
Gentoo Linux può essere installato tramite un archivio stage3, che è un archivio compresso tar che contiene un ambiente minimale.
Le installazioni condotte utilizzando archivi stage1 o stage2 non vengono trattate in questo manuale. Per reperire informazioni in proposito è possibile consultare le Domande frequenti (FAQ) su Gentoo.
CD di installazione Gentoo Universale
Un CD di installazione Gentoo è un CD avviabile che contiene un ambiente Gentoo autonomo. Consente di avviare 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:
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 dopo una installazione di Gentoo e prima di aggiornare il Portage tree.
L'uso del CD di pacchetti è trattato più avanti.
Scelta dell'ambiente (userland)
Su PPC64 il kernel è a 64 bit, ma l'ambiente può essere a 32 bit o a 64 bit. L'ambiente è costituito dalle applicazioni che si utilizzano, quali bash o mozilla-firefox. Possono essere compilate per essere eseguite sia in modalità 32 bit che 64 bit. Gentoo offre ambienti sia a 32 che a 64 bit, è necessario scegliere quale utilizzare.
Gira voce che le applicazioni a 64 bit siano migliori, ma in realtà quella a 32 bit richiedono un po' meno memoria per essere eseguite e spesso sono un po' più rapide delle controparti a 64 bit.
Se ha effettivamente bisogno delle applicazioni a 64 bit quando si necessita di più memoria di quella consentita dall'ambiente a 32 bit o nel caso si effettuino diverse operazioni su numeri a 64 bit. Se si utilizzano applicazioni che richiedono più di 4GB di memoria o applicazioni scientifiche è consigliabile scegliere un ambiente a 64 bit. In caso contrario scegliere ambienti a 32 bit come consigliato dagli sviluppatori Gentoo/PPC64.
Inoltre l'ambiente a 32 bit è disponibile in Portage da più tempo di quello a 64 bit. Questo significa che esistono più applicazioni che sono state testate nell'ambiente a 32 bit che funzioneranno immediatamente. Diverse applicazioni compilate per 64 bit potrebbero essere stabili come nella loro versione a 32 bit, ma non sono ancora state testate accuratamente. Sebbene il testing non sia complicato può essere lungo e fastidioso se si utilizzano svariate applicazioni a 64 bit non testate. Infine alcuni programmi non possono essere eseguiti a 64 bit finchè non verrà modificato il codice, ad esempio OpenOffice.
Gentoo mette a disposizione stage a CD di pacchetti sia per ambienti a 32 bit che 64 bit, quindi a seconda della scelta si ha comunque la possibilità di installare il sistema con successo senza fastidi.
2.c. Scaricare, masterizzare ed avviare un CD di installazione Gentoo
Scaricare e masterizzare i CD di installazione
Si possono scaricare i CD di installazione Universali (e se lo si desidera, anche il CD di pacchetti), da uno dei mirror di Gentoo. I CD di installazione sono nella directory sreleases/ppc/2007.0/ppc64/installcd; i CD di pacchetti sono nella directory releases/ppc/2007.0/ppc64/packagecd.
Dentro quella directory si troveranno i file ISO. Questi sono immagini complete di CD che possono essere scritte su un CD-R.
Dopo aver scaricato il file, si può controllarne l'integrità:
Per scaricare la chiave pubblica usata dagli sviluppatori Gentoo con l'applicazione GnuPG, eseguire il seguente comando:
Codice 3.1: Ottenere una chiave pubblica |
$ gpg --keyserver subkeys.pgp.net --recv-keys 0x17072058
|
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 nelle Domande frequenti su Gentoo.
Avviare il CD di installazione su Apple
Controllare README.kernel sul CD di installazione per le ultime informazioni sul boot dei vari kernel ed ottenere supporto hardware.
Inserire il CD di installazione nel lettore di CD-ROM e riavviare il sistema. Al bootup tenere premuto il tasto 'C'. Sullo schermo appare un messaggio di benvenuto e il prompt boot: in basso.
In questo prompt è anche possibile impostare alcune opzioni del Kernel tra quelle elencate di seguito:
| Opzioni di avvio | Descrizione |
| video | Questa opzione è seguita da uno dei seguenti tag: radeonfb, rivafb, atyfb, aty128, nvidiafb o ofonly. Si può anche specificare la risoluzione e il refreshrate da utilizzare. Ad esempio video=radeonfb:1280x1024@75. Se si è indecisi su cosa scegliere, ofonly è sicuramente funzionante. |
| nol3 | Disabilita la cache di terzo livello su alcuni PowerBook (richiesta almeno per i 17") |
| debug | Abilita i messaggi di avvio e genera una shell initrd che può essere utilizzata per il debug del CD di installazione |
| sleep=X | Attende X secondi prima di continuare; questo può servire per qualche vecchio CD-ROM SCSI che non accelera il CD abbastanza rapidamente |
| bootfrom=X | Avvia da un dispositivo differente |
In questo prompt premere Invio per caricare dal CD un ambiente completo di Gentoo Linux. Continuare con Una volta avviato il sistema....
Avviare il CD di installazione su IBM pSeries, OpenPower e server Power5 iSeries
Controllare README.kernel sul CD di installazione per le ultime informazioni sul boot dei vari kernel e ottenere supporto hardware.
I moderni server pSeries possono avviarsi dal CDROM con SMS ('1' quando i messaggi “IBM IBM IBM” compaiono sulla console). Per alcuni vecchi sistemi pSeries, alcune volte può succedere che i cd non vengano avviati automaticamente. Si dovrebbe impostare il cdrom come dispositivo avviabile nel menu multi boot. (F1 allo startup) L'altra opzione è quella di spostarsi in OF e farlo da lì:
Una volta avviato il sistema...
Viene visualizzato un prompt di root ("#") nella console corrente. È possibile anche passare alle altre console premendo Alt-fn-F2, Alt-fn-F3 e Alt-fn-F4. Ritornare a quella di partenza premendo Alt-fn-F1.
Se si sta installando Gentoo su un sistema con una tastiera non-US, si può utilizzare loadkeys per caricare la keymap della propria tastiera. Per elencare le keymap disponibili eseguire ls /usr/share/keymaps/i386.
Codice 3.3: Elencare le keymap disponibili |
(I PPC usano le keymap x86 nella maggior parte dei sistemi. Le keymap mac/ppc fornite con il CD di installazione sono keymap ADB e sono inutilizzabili con i kernel dei CD di installazione) # ls /usr/share/keymaps/i386 |
Caricare la keymap scelta:
Codice 3.4: Caricare la keymap |
# loadkeys be-latin1
|
Continuare ora con la Configurazione dell'Hardware aggiuntivo.
Configurazione dell'hardware aggiuntivo
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 automatica 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
|
Opzionale: Ottimizzazione delle prestazioni dell'hard disk
Alcuni utenti esperti potrebbero voler ottimizzare le prestazioni del proprio hard disk tramite hdparm. Con le opzioni -tT è possibile testare le prestazioni del proprio disco (eseguire il test alcune volte per avere risultati più precisi):
Codice 3.6: Test delle prestazioni 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.7: Ottimizzazione delle prestazioni 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 |
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'utilità passwd:
Codice 3.8: 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. È possibile utilizzare useradd e passwd per farlo, come mostra il prossimo esempio in cui si crea l'utente "john".
Codice 3.9: 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) |
È possibile dunque cambiare utente da root al nuovo utente tramite su:
Codice 3.10: Cambiare utente |
# su - john
|
Opzionale: Vedere la documentazione mentre si installa
Se si desidera vedere il Manuale Gentoo 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 links per leggerla:
Codice 3.11: Vedere la documentazione sul CD |
# links /mnt/cdrom/docs/handbook/html/index.html
|
Tuttavia, è preferibile usare il Manuale Gentoo online poichè probabilmente sarà più recente di quello sul CD.
Codice 3.12: Vedere la documentazione online |
# links http://www.gentoo.org/doc/it/handbook/2007.0/handbook-ppc64.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.13: 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.a. Si ha bisogno della rete?
Generalmente, non è necessario avere una connesione di rete per installare Gentoo con l'InstallCD Universale o il LiveCD di installazione. Ma ci sono alcune circostanze in cui si può desiderare di avere una connessione a Internet:
Per scoprire se lo stage3 è disponibile per la propria architettura e si sta utilizzando un InstallCD Universale, 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.
Lo stage3 costruito dal LiveCD di installazione x86 è ottimizzato per i686 o superiori ed utilizza NPTL. Lo stage3 costruito dal LiveCD di installazione amd64 è ottimizzato per amd64 generici ed utilizza NPTL.
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
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 |
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.gentoo.org
|
La rete è funzionante? Se è così, si può saltare il resto di questa sezione e continuare con la Preparazione dei Dischi. Se non è così, purtroppo, è necessario procedere 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 pppoe-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.
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.
Se c'è bisogno di PPPoE per connettersi a internet, il CD di Installazione (qualsiasi versione) rende le cose facili perchè include ppp. Usare lo script fornito pppoe-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 ppp |
# pppoe-setup # pppoe-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.
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 pppoe-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 pppoe-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:
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.
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.
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 |
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.a. Introduzione ai dispositivi a blocchi
Si da 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 dischi serial ATA hanno /dev/sda anche se sono dischi IDE.
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.
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. Sulla maggior parte dei sistemi, queste sono chiamate partizioni. Altre architetture, usano una tecnica simile, chiamandole slices.
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/sda1 | Partition map | 31.5k | Partition map |
| /dev/sda2 | (bootstrap) | 800k | Apple_Bootstrap |
| /dev/sda3 | (swap) | 512M | Partizione swap |
| /dev/sda4 | ext3 | Resto dello spazio su disco | Partizione root |
Nota: Ci sono partizioni come: Apple_Driver43, Apple_Driver_ATA, Apple_FWDriver, Apple_Driver_IOKit, Apple_Patches, che si possono cancellare se non si desidera utilizzare MacOS 9, perchè MacOS e Linux non ne hanno bisogno. Si deve usare parted per eliminarle, poichè mac-fdisk ancora non può farlo. |
Se si è interessati ad avere informazioni su quanto dovrebbe essere grande una partizione, o anche su quante partizioni si ha bisogno, seguono alcuni suggerimenti. Altrimenti continuare con Apple G5: Usare mac-fdisk per partizionare il disco o IBM pSeries: 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:
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.
4.c. Default: Usare mac-fdisk (Apple G5) per partizionare il disco
Si creano le partizioni con mac-fdisk:
Codice 3.1: Eseguire mac-fdisk |
# mac-fdisk /dev/sda
|
Per prima cosa si cancellino le partizioni precedentemente eliminate per poter inserire le partizioni Linux. Usare d in mac-fdisk per eliminare queste partizioni. Verrà chiesto il numero della partizione da eliminare.
Si crei una partizione Apple_Bootstrap con b. Verrà chiesto da quale blocco si vuole partire. Dare il numero della prima partizione libera, seguito da p. Per esempio 2p.
Nota: Questa partizione non è quella "boot". Non è usata da Linux, non si deve mettere nessun filesystem su essa e non si dovrebbe neanche montare. Gli utenti PPC non hanno bisogno di una partizione /boot. |
Si crei una partizione swap digitando c. Verrà chiesto da quale blocco si vuole far partire questa partizione, e si digiti 3p. Quando verrà chiesta la grandezza, si digiti 512M (o qualsiasi altra grandezza si desidera), e quando verrà chiesto il nome scrivere swap (obbligatorio).
Per creare la partizione root, premere c seguito da 4p, 4 è il blocco di inizio della partizione. Quando verrà chiesta la grandezza premere di nuovo 4p, mac-fdisk lo interpreterà come "Usare tutto lo spazio disponibile". Quando verrà chiesto il nome digitare root (obbligatorio).
Per finire si devono memorizzare le partizioni sul disco con w e uscire da mac-fdisk premendo q.
Nota: Per assicurarsi che tutto è andato bene, si dovrebbe rieseguire mac-fdisk e controllare se ci sono le partizioni. Se non ci sono o se non si vedono i cambiamenti, si dovrebbe reinizializzare le partizioni premendo i in mac-fdisk. Questo ricreerà la mappa delle partizioni e rimuoverà quelle precedenti. |
Ora che le partizioni sono create, si può continuare con la sezione riguardante come Creare i filesystem.
4.d. IBM pSeries, iSeries e OpenPower: Usare fdisk per partizionare il disco
Nota: Se si vuole usare un disk array RAID per la installazione di Gentoo e si sta usando un hardware POWER5, si dovrebbe eseguire iprconfig per disporre i dischi al formato Advanced Function e creare disk array. Si dovrebbe emergere iprutils dopo che la installazione è completata. |
Se si ha un adattatore SCSI ipr, si dovrebbe avviare le utility ipr ora.
Codice 4.1: Avviare le utility ipr |
# /etc/init.d/iprinit start
|
La parte seguente spiega come creare lo schema di partizione di esempio descritto precedentemente:
| Partizione | Descrizione |
| /dev/sda1 | Partizione PPC PReP Boot |
| /dev/sda2 | Partizione swap |
| /dev/sda3 | 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/sda):
Codice 4.2: Eseguire fdisk |
# fdisk /dev/sda
|
Si visualizzerà un prompt come questo:
Codice 4.3: Prompt di fdisk |
Command (m for help): |
Se si ha ancora un layout di partizione AIX sul sistema, si ottiene il seguente messaggio di errore:
Codice 4.4: Messaggio di errore di fdisk |
There is a valid AIX label on this disk.
Unfortunately Linux cannot handle these
disks at the moment. Nevertheless some
advice:
1. fdisk will destroy its contents on write.
2. Be sure that this disk is NOT a still vital
part of a volume group. (Otherwise you may
erase the other disks as well, if unmirrored.)
3. Before deleting this physical volume be sure
to remove the disk logically from your AIX
machine. (Otherwise you become an AIXpert).
Command (m for help):
|
Non ci si deve preoccupare! Si può creare una nuova tabella di partizione dos vuota digitando o.
Avvertenza: Questo distrugge ogni versione AIX installata |
Digitare p per visualizzare le attuali partizioni presenti sul disco:
Codice 4.5: Un esempio di partizionamento |
Command (m for help): p Disk /dev/sda: 30.7 GB, 30750031872 bytes 141 heads, 63 sectors/track, 6761 cylinders Units = cylinders of 8883 * 512 = 4548096 bytes Device Boot Start End Blocks Id System /dev/sda1 1 12 53266+ 83 Linux /dev/sda2 13 233 981571+ 82 Linux swap /dev/sda3 234 674 1958701+ 83 Linux /dev/sda4 675 6761 27035410+ 5 Extended /dev/sda5 675 2874 9771268+ 83 Linux /dev/sda6 2875 2919 199836 83 Linux /dev/sda7 2920 3008 395262 83 Linux /dev/sda8 3009 6761 16668918 83 Linux Command (m for help): |
Questo disco è configurato per avere sei filesystem Linux (chiamati "Linux" nelle corrispondenti partizioni) e una partizione swap (chiamata "Linux swap").
Si procede ora alla rimozione dal disco di tutte le partizioni esistenti. Digitare d per eliminare una partizione. Per esempio, per eliminare /dev/sda1:
Nota: Se non si desidera eliminare tutte le partizioni, eliminare solo alcune di esse. E' raccomandato fare un backup dei dati per evitare la loro perdita. |
Codice 4.6: 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 4.7: Tabella con nessuna partizione |
Disk /dev/sda: 30.7 GB, 30750031872 bytes 141 heads, 63 sectors/track, 6761 cylinders Units = cylinders of 8883 * 512 = 4548096 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 boot PPC PReP
Si crea una piccola partizione boot PReP. 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 +7M per creare una partizione di 7 Mbyte. Digitare t per impostare il tipo di partizione, 1 per selezionare la partizione creata e 41 per impostare la partizione a "PPC PReP Boot". Si dovrà mettere la partizione PReP come bootable.
Nota: La partizione PReP deve essere più piccola di 8 MByte. |
Codice 4.8: Creare la partizione boot PReP |
Command (m for help): p Disk /dev/sda: 30.7 GB, 30750031872 bytes 141 heads, 63 sectors/track, 6761 cylinders Units = cylinders of 8883 * 512 = 4548096 bytes Device Boot Start End Blocks Id System Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-6761, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-6761, default 6761): +8M Command (m for help): t Selected partition 1 Hex code (type L to list codes): 41 Changed system type of partition 1 to 41 (PPC PReP Boot) Command (m for help): a Partition number (1-4): 1 Command (m for help): |
Quando si digita p, si dovrebbe vedere la seguente partizione:
Codice 4.9: Partizione di boot creata |
Command (m for help): p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 3 13293 41 PPC PReP Boot
Command (m for help):
|
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/sda2. 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 4.10: Elenco delle partizioni dopo aver creato la partizione swap |
Command (m for help): p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 3 13293 41 PPC PReP Boot
/dev/sda2 4 117 506331 82 Linux swap
Command (m for help):
|
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/sda3. 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 4.11: Elenco delle partizioni dopo aver creato la partizione root |
Command (m for help): p Disk /dev/sda: 30.7 GB, 30750031872 bytes 141 heads, 63 sectors/track, 6761 cylinders Units = cylinders of 8883 * 512 = 4548096 bytes Device Boot Start End Blocks Id System /dev/sda1 1 3 13293 41 PPC PReP Boot /dev/sda2 4 117 506331 82 Linux swap /dev/sda3 118 6761 29509326 83 Linux Command (m for help): |
Salvare lo schema delle partizioni
Per salvare lo schema delle partizioni e uscire da fdisk, digitare w.
Codice 4.12: 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.
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.
Nota: Sono disponibili molti filesystem. Il supporto per ext2, ext3 e ReiserFS è compilato nei kernel del CD di installazione. Il supporto per JFS e XFS è disponibile tra i moduli del kernel. |
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. Utilizza un indice HTree che abilita alte prestazioni in quasi tutte le situazioni. In breve, ext3 è un filesystem davvero molto valido e affidabile.
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. 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, file molto grandi e directory contenenti decine di migliaia di piccoli 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 la produzione.
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 root (/dev/sda4) ext3 si usa:
Codice 5.1: Applicare un filesystem su una partizione |
# mke2fs -j /dev/sda4
|
Ora si procede alla creazione dei filesystem sulle partizioni (o volumi logici) create precedentemente.
Importante: Se si è scelto di usare ReiserFS per /, non cambiare la sua dimensione predefinita dei blocchi nel caso in cui si andasse ad utilizzare yaboot come bootloader, come spiegato in Configurazione del Bootloader. |
mkswap è il comando usato per inizializzare le partizioni swap:
Codice 5.2: Creare una signature swap |
# mkswap /dev/sda3
|
Per attivare la partizione swap, usare swapon:
Codice 5.3: Attivare la partizione swap |
# swapon /dev/sda3
|
Creare e attivare swap con il comando menzionato sopra.
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 crea un mount point e si monta la partizione root:
Codice 6.1: Montare le partizioni |
# mkdir /mnt/gentoo # mount /dev/sda4 /mnt/gentoo |
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. |
Continuare con Copia dei file di installazione di Gentoo.
5.a. Installazione di uno stage
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 UTC 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). A questo punto è consigliabile impostare l'ora UTC, è possib ile poi regolare la timezone in seguito. Ad esempio per impostare la data al 29 marzo 2005 e l'ora alle 16:21:
Codice 1.2: Impostare data e ora in UTC |
# date 032916212005
|
5.b. Default: Usare uno stage3 dal CD di Installazione
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 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-ppc64-32ul-2007.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-ppc64-32ul-2007.0.tar.bz2
|
Ora si è pronti per procedere con la prossima sezione riguardante come Installare Portage.
Decomprimere ora lo stage nel sistema. Utilizzare l'utility tar per procedere poichè è il metodo più facile:
Codice 2.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.
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 3.1: Posizionarsi sul punto di mount |
# cd /mnt/gentoo
|
Codice 3.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 3.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 3.4: Copiare il codice sorgente |
# mkdir /mnt/gentoo/usr/portage/distfiles # cp /mnt/cdrom/distfiles/* /mnt/gentoo/usr/portage/distfiles/ |
5.d. Configurare le opzioni di compilazione
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 4.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. |
La variabile CHOST imposta il tipo di compilazione da effettuare. Dovrebbe già essere impostata al valore corretto. Non modificarla perchè potrebbe causare seri malfunzionamenti. Se la variabile CHOST non sembra essere quella corretta è probabile che sia stato scelto lo stage sbagliato.
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). Per le più comuni impostazioni di ottimizzazione, lo stesso file make.conf.example contiene molti esempi e informazioni da consultare.
Una delle impostazioni sono le flag -march= o -mcpu= che specificano il nome dell'architettura per cui compilare. Le opzioni disponibile sono descritte nel file make.conf.example come commenti.
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). -O2 è il default che si raccomanda.
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). Non ha impatto sul codice generato.
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. I valori di default contenuti nello stage3 sono già sufficienti. L'esempio che segue è puramente esplicativo:
Codice 4.2: Definizione delle variabili CFLAGS e CXXFLAGS |
CFLAGS="-O2 -pipe"
# Usare le stesse impostazioni per entrambe le variabili
CXXFLAGS="${CFLAGS}"
|
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 4.3: MAKEOPTS per un normale sistema con 1-CPU |
MAKEOPTS="-j2" |
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.
Montare i filesystem /proc e /dev
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; montare poi tramite bind il filesystem /dev.
Codice 1.1: Montare /proc e /dev |
# mount -t proc none /mnt/gentoo/proc # mount -o bind /dev /mnt/gentoo/dev |
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.2: Chroot nel nuovo ambiente |
# chroot /mnt/gentoo /bin/bash # env-update >>> Regenerating /etc/ld.so.cache... # source /etc/profile # export PS1="(chroot) $PS1" |
Congratulazioni! Da adesso si è dentro Gentoo Linux. Naturalmente la fine dell'installazione è lontana, poichè mancano ancora alcune sezioni.
Creazione della cache di Portage
Una volta installato l'archivio di Portage è necessario impostare la cache in modo tale che le future installazioni vengano ottimizzate. emerge --metadata è il comando che esegue questo compito.
Codice 1.3: Creazione della cache di Portage |
# emerge --metadata
|
6.b. Configurare 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 -qt3 -qt4 abilita i programmi al supporto gnome (e gtk), ma non a quello kde (e qt), rendendo il sistema ottimizzato per GNOME.
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 qt3 qt4 kde dvd alsa cdr" |
Innanzitutto è necessario selezionare il proprio fuso orario (timezone), in modo che il sistema riconosca in che parte del globo è collocato. Individuare il proprio fuso orario in /usr/share/zoneinfo, dopodichè copiarlo in /etc/localtime. Si sconsiglia di utilizzare i fusi orari del tipo /usr/share/zoneinfo/Etc/GMT* poichè i loro nomi non indicano le zone che ci si aspetterebbe. Per esempio GMT-8 indica GMT+8.
Codice 1.1: Abilitare le informazioni sul fuso orario (timezone) |
# ls /usr/share/zoneinfo (Per esempio GMT:) # cp /usr/share/zoneinfo/GMT /etc/localtime |
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 PPC64 si consiglia di usare gentoo-sources.
Codice 2.1: Installare un sorgente del kernel |
# emerge gentoo-sources
|
Se si dà un'occhiata a /usr/src, si dovrebbe vedere un link simbolico chiamato linux, che punta al sorgente del kernel. In questo caso il sorgente del kernel installato punta a gentoo-sources-2.6.19-r7. La versione potrebbe essere differente.
Codice 2.2: Il link simbolico al sorgente del kernel |
# ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Aug 10 11:04 /usr/src/linux ->
linux-2.6.19-r7
|
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 ma al momento non è completamente funzionante per PPC64.
Continuare con Configurazione manuale.
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).
Codice 3.1: Aprire menuconfig |
# cd /usr/src/linux Importante: Per 32bit userland, si deve editare il top level Makefile in /usr/src/linux e cambiare la opzione CROSS_COMPILE con CROSS_COMPILE ?= powerpc64-unknown-linux-gnu-. Si deve farlo prima di eseguire make menuconfig o si potrebbero avere problemi con la compilazione del kernel. # 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 ---> [*] Prompt for development and/or incomplete code/drivers |
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 e /dev/pts file system for Unix98 PTYs:
Codice 3.3: Selezionare il filesystem |
File systems --->
[*] Virtual memory file system support (former shm fs)
[*] /proc file system support
[*] /dev/pts file system for Unix98 PTYs
(Selezionare una o più delle seguenti opzioni in base al sistema)
<*> Reiserfs support
<*> Ext3 journalling file system support
<*> JFS filesystem support
<*> Second extended fs support
<*> XFS filesystem support
|
Nota: Si troverano alcune opzioni, in Pseudo filesystems una sezione di File systems. |
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 (si troveranno in Networking support una sezione di Device Drivers):
Codice 3.4: Selezionare i driver necessari per PPPoE |
Network device 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 ppp se configurato per PPPoE in modalità kernel.
Chi ne ha bisogno, non deve dimenticare di includere il supporto, per la scheda ethernet, nel kernel.
Disabilitare ADB raw keycodes:
Codice 3.5: Disabilitare ADB raw keycodes |
Macintosh Device Drivers ---> [ ] Support for ADB raw keycodes |
Una volta terminata la configurazione del kernel continuare con 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.6: Compilare il kernel |
# make && make modules_install
|
Quando la compilazione è finita, è necessario copiare l'immagine del kernel in /boot. Ricordarsi di sostituire <kernel-version> con la versione del kernel che si è scelta.
Codice 3.7: Installare il kernel |
# cp vmlinux /boot/<kernel-version>
|
Adesso continuare con Configurare i moduli.
Si dovrebbero inserire i moduli che si vogliono caricare in /etc/modules.autoload.d/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 "<versione kernel>" con la versione del kernel appena compilato:
Codice 4.1: Vedere tutti i moduli disponibili |
# find /lib/modules/<versione kernel>/ -type f -iname '*.o' -or -iname '*.ko'
|
Per esempio, per caricare automaticamente il modulo 3c59x.ko, modificare il file kernel-2.6 e inserire il nome.
Codice 4.2: Modificare /etc/modules.autoload.d/kernel-2.6 |
# nano -w /etc/modules.autoload.d/kernel-2.6
|
Codice 4.3: /etc/modules.autoload.d/kernel-2.6 |
3c59x |
Continuare l'installazione con la Configurazione del sistema.
8.a. Informazioni sul filesystem
In Linux, tutte le partizioni usate dal sistema devono essere elencate in /etc/fstab. Questo è un file che contiene i punti di montaggio 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.).
/etc/fstab usa una sintassi speciale. Ogni riga contiene sei parti, separate da spazio (spazio, tabs o entrambi). Ogni parte ha un significato:
Il file /etc/fstab fornito da Gentoo è solo di esempio, quindi è indispensabile creare il proprio /etc/fstab personalizzato:
Codice 1.1: Aprire /etc/fstab |
# nano -w /etc/fstab
|
Aggiungere le regole corrispondenti al proprio schema di partizionamento e completare con le regole per le periferiche CD-ROM drive e ovviamente per le altre partizioni o dispositivi che si dovessero possedere.
Usare ora l'esempio che segue per creare il proprio /etc/fstab:
Codice 1.2: Un esempio di /etc/fstab |
/dev/sda4 / ext3 noatime 0 1 /dev/sda3 none swap sw 0 0 /dev/cdrom /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.
Per migliorare le prestazioni la maggior parte degli utenti è interessata ad utilizzare in fase di mount l'opzione noatime: questo porta ad un sistema più rapido in quanto non vengono registrate le date di accesso che comunque nella maggior parte dei casi sono superflue.
Rileggere con attenzione /etc/fstab, salvarlo e uscire per continuare.
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, è importante sapere 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 impostare l'hostname:
Codice 2.1: Impostare l'hostname |
# nano -w /etc/conf.d/hostname (Impostazione della variabile HOSTNAME al proprio hostname) HOSTNAME="tux" |
Poi, se si necessita di un nome di dominio, impostarlo in /etc/conf.d/net. E' necessario un nome di domincio solo se il proprio provider o il proprio amministratore lo richiedono o se si ha un DNS ma non un DHCP. Non è necessario preoccuparsi del dominio se i propri parametri di rete vengono impostati via DHCP.
Codice 2.2: Impostare il domainname |
# nano -w /etc/conf.d/net (Impostazione della variabile dns_domain al proprio dominio) dns_domain_lo="homenetwork" |
Nota: Se si sceglie di non impostare il nome di dominio è possibile rimuovere il messaggio "This is hostname.(none)" alla schermata di logine modificando il file /etc/issue. Eliminare la stringa .\O dal file. |
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 |
# nano -w /etc/conf.d/net (Impostazione della variabile nis_domain al proprio dominio NIS) nis_domain_lo="my-nisdomain" |
Nota: Per ulteriori informazioni sulla configurazione dei DNS e i NIS, consultare gli esempi forniti nel file /etc/conf.d/net.example. E' possibile anche installare resolvconf-gentoo per gestire la configurazione DNS/NIS. |
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.
Nota: Ulteriori e più dettagliate informazioni riguardanti la rete come bonding, bridging, 802.1Q VLANs o wireless networking sono trattate nella sezione riguardante la Configurazione di rete in Gentoo. |
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. Non ci si deve preoccupare, in quanti verrà spiegato tutto. Un esempio completo e commentato che comprende diversi tipi di configurazione è disponibile in /etc/conf.d/net.example.
Il DHCP viene utilizzato in modo predefinito e non richiede alcuna configurazione.
Se si necessita di configurare la propria connessione di rete, o perchè si desiderano opzioni particolari di DHCP o perchè non si usa affatto DHCP è possibile modificare /etc/conf.d/net con il proprio editor preferito (in questo esempio viene usato nano):
Codice 2.4: Aprire /etc/conf.d/net |
# nano -w /etc/conf.d/net
|
Ecco come si presenta il file:
Codice 2.5: /etc/conf.d/net di default |
# Questa configurazione imposta l'utilizzo del DHCP per qualsiasi script net.* # in /etc/init.d. Per creare una configurazione più completa è possibile # consultare l'esempio in /etc/conf.d/net.example e salvare le proprie modifiche # in /etc/conf.d/net (questo file!). |
Per impostare il proprio indirizzo IP, netmask e gateway è necessario impostare sia config_eth0 che routes_eth0:
Codice 2.6: Impostare manualmente le caratteristiche di eth0 |
config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" ) routes_eth0=( "default via 192.168.0.1" ) |
Per utilizzare DHCP ed aggiungere opzioni particolari definire config_eth0 e dhcp_eth0:
Codice 2.7: Ottenere automaticamente un indirizzo IP per eth0 |
config_eth0=( "dhcp" ) dhcp_eth0="nodns nontp nonis" |
Consultare /etc/conf.d/net.example per una lista delle opzioni disponibili.
Nel caso si posseggano più interfacce di rete ripetere i passi per config_eth1, config_eth2, ecc.
Salvare la configurazione ed 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.
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 initscript 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.lo 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 hostname e gli indirizzi IP, per gli host che non sono risolti dal nameserver. E' necessario impostare una riga per il proprio sistema. Si potrebbe anche volerne impostare ulteriori per sistemi delle propria rete che non si desidera risolvere tramite il DNS.
Codice 2.10: Aprire /etc/hosts |
# nano -w /etc/hosts
|
Codice 2.11: Inserire le informazioni di rete |
(Definizione per il proprio sistema) 127.0.0.1 tux.homenetwork tux localhost (Definire ulteriori host della propria rete. E' necessario che dispongano di un indirizzo IP statico per utilizzare questa definizione.) 192.168.0.5 jenny.homenetwork jenny 192.168.0.6 benny.homenetwork benny |
Salvare ed 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
Gli utenti PCMCIA innanzitutto installano il pacchetto pcmciautils:
Codice 2.12: Installazione di pcmciautils |
# emerge pcmciautils
|
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
|
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
|
Terminata la configurazione di /etc/rc.conf, salvare ed uscire.
Come si può vedere, questo file contiene tutte le spiegazioni necessarie per impostare le variabili di configurazione. E' possibile impostare il proprio sistema per utilizzare unicode e definire il proprio editor di default e display manager (come gdm o kdm).
Gentoo utilizza /etc/conf.d/keymaps per gestire la configurazione della tastiera. E' possibile modificarlo per configurare la propria tastiera.
Codice 3.4: Modificare /etc/conf.d/keymaps |
# nano -w /etc/conf.d/keymaps
|
Prestare particolare attenzione alla variabile KEYMAP. Se si seleziona una keymap errata si otterranno risultati inattesi mentre si scrive con la testiera.
Nota: PPC usa le keymap x86 nella maggior parte dei casi. Gli utenti che desiderino utilizzare keymaps ADB al boot devono abilitare i keycode ADB nel kernel ed impostare una keymap mac/ppc in /etc/conf.d/keymaps. |
Una volta terminate le modifiche a /etc/conf.d/keymaps, salvare e chiudere.
Gentoo utilizza /etc/conf.d/clock per impostare le opzioni dell'orologio. E' possibile modificarlo per personalizzare il comportamento in base alle proprie esigenze.
Codice 3.5: Modificare /etc/conf.d/clock |
# nano -w /etc/conf.d/clock
|
Se il proprio orologio hardware non è UTC, è necessario aggiungere CLOCK="local" al file, in caso contrario si noteranno negli errori nell'ora.
E' necessario definire il fuso orario che si è precedentemente copiato in /etc/localtime in modo tale che gli aggiornamenti al pacchetto sys-libs/timezone-data possano automaticamente aggiornare /etc/localtime. Ad esempio se si dovesse usare l'impostazione GMT si dovrebbe aggiungere TIMEZONE="GMT".
Una volta terminate le modifiche a /etc/conf.d/clock, salvare e chiudere.
Se si sta utilizzando una console virtuale è necessario decommentare la linea corrispondente nel file /etc/inittab perchè la console apra realmente un prompt di comandi.
Codice 3.6: Abilitare il supporto hvc o hvsi in /etc/inittab |
hvc0:12345:respawn:/sbin/agetty -L 9600 hvc0 hvsi:12345:respawn:/sbin/agetty -L 19200 hvsi0 |
E' impostante anche controllare che venga elencata in /etc/securetty la console corretta.
E' possibile ora continuare con l'Installazione degli strumenti di sistema.
Alcuni strumenti non sono inclusi nello stage3 perchè ci sono diversi pacchetti che offrono le medesime funzionalità ed è discrezione dell'utente scegliere quali installare.
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 |
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 si desidera usare EVMS, è necessario installare emvs:
Codice 4.1: Installazione degli strumenti EVMS |
# USE="-gtk" emerge evms
|
L'uso di USE="-gtk" evita che vengano installate alcune dipendenze. Se si desidera abilitare i tool grafici di evms è possibile ricompilare il pacchetto più tardi.
Opzionale: strumenti RAID per hardwrae IBM
Se si sta utilizzando il RAID su SCSI con un sistema POWER5, si dovrebbe valutare l'installazione di iprutils che consente di lavorare con la batteria di dischi SCSI, visualizzare lo stato dei dischi e aggiornare il microcode, tra le altre funzioni.
Codice 4.2: Installazione di iprutils |
# emerge iprutils
|
Se non si necessita di ulteriori strumenti per la rete (quali ppp o un client dhcp) continuare con la Configurazione del bootloader.
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 6.1: Installazione di dhcpcd |
# emerge dhcpcd
|
Opzionale: Installare un client PPPoE
Se si ha bisogno di ppp per connettersi alla rete, si deve installarlo:
Codice 6.2: Installare ppp |
# emerge ppp
|
Continuare ora con la Configurazione del Bootloader.
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.
Su Linux/PPC64 si ha solo yaBoot come bootloader, fino a quando non è terminato grub2.
Importante: Per un 64bit si deve usare yaboot-static invece di yaboot, perchè yaboot non si compila su 64bit. Per un 32bit usare yaboot. |
Ci sono due modi di configurare yaBoot. Si può usare il nuovo e migliore yabootconfig, incluso in yaboot-1.3.8-r1 e successivi, per installare automaticamente yaboot. Se per qualche motivo non si desidera eseguire yabootconfig per installare /etc/yaboot.conf o si sta installando Gentoo su un G5 (sul quale yabootconfig non sembra funzionare sempre), si può modificare il file di esempio già installato sul sistema.
Codice 2.1: Installazione di strumenti per il filesystem |
# emerge hfsutils hfsplusutils
|
Codice 2.2: Installare il bootloader |
(64bit userland) # emerge --update yaboot-static (32bit userland) # emerge --update yaboot |
Importante: yabootconfig/ybin non funziona su IBM. Si deve installare yaboot in un altro modo: Usare yaboot su IBM hardware |
Nota: Se root ha il filesystem JFS, assicurarsi di aggiungere ro come opzione del kernel. JFS deve ripetere il log in sola lettura prima che si monti in lettura e scrittura. |
yabootconfig rileva automaticamente le partizioni sulla macchina, e installa doppie e triple combinazioni di boot con Linux, Mac OS, e Mac OS X.
Per usare yabootconfig, il disco deve avere una partizione bootstrap, e /etc/fstab deve essere configurato con le partizioni Linux. Entrambe queste condizioni dovrebbero essere state soddisfatte precedentemente. Prima di iniziare, assicurarsi di avere installata l'ultima versione di yaboot eseguendo emerge --update yaboot-static. Questo è necessario poichè l'ultima versione è disponibile tramite Portage, ma non nei file dello stage.
Ora eseguire yabootconfig. L'esecuzione del programma chiede conferma sulla posizione della partizione di bootstrap. Digitare Y se è corretta. Altrimenti, ricontrollare /etc/fstab. Poi yabootconfig controlla il setup del sistema, crea /etc/yaboot.conf ed esegue mkofboot. mkofboot viene usato per formattare la partizione di bootstrap e installare in essa il file di configurazione di yaboot.
Si potrebbe voler verificare il contenuto di /etc/yaboot.conf. Se si effettuano cambiamenti a /etc/yaboot.conf (come, impostare l'OS di default/boot), assicurarsi di rieseguire ybin -v, per applicare i cambiamenti alla partizione di bootstrap.
Ora continuare con Riavviare il sistema.
Alternativa: Configurazione manuale di yaBoot
Segue un file completo di yaboot.conf di esempio. Modificarlo in base alle necessità.
Codice 2.3: /etc/yaboot.conf |
## /etc/yaboot.conf ## ## eseguire: "man yaboot.conf" per ulteriori informazioni. Non portare cambiamenti prima di aver letto. ## consultare anche: /usr/share/doc/yaboot/examples per configurazioni d'esempio. ## ## Per un sistema dual-boot aggiungere una o più delle seguenti: ## bsd=/dev/hdaX, macos=/dev/hdaY, macosx=/dev/hdaZ ## partizione di bootstrap: boot=/dev/hda2 ## ofboot il modo open firmware di specificare la partizione bootstrap. ## Se questa non è definita, yaboot non funziona sui G5 e su alcuni G4 (a meno che ## non si passino gli argomenti necessari al programma mkofboot/ybin). ## hd:X vuol dire /dev/sdaX (o /dev/hdaX). ofboot=hd:2 ## hd: il modo open firmware di riferirsi ad hda device=hd: delay=5 defaultos=macosx timeout=30 install=/usr/lib/yaboot/yaboot magicboot=/usr/lib/yaboot/ofboot ################# ## Questa sezione può essere duplicata se si hanno più di un kernel ## o più di un set di opzioni di boot - sostituire la propria ## versione al posto di kernel-2.6.19-gentoo-r7 ################# image=/boot/kernel-2.6.19-gentoo-r7 label=Linux root=/dev/hda3 partition=3 read-only macos=hd:13 macosx=hd:12 enablecdboot enableofboot |
Una volta che yaboot.conf è stato configurato secondo le proprie necessità, eseguire mkofboot -v per installare le impostazioni nella partizione di bootstrap. Non dimenticare di farlo! Dare conferma quando mkofboot chiede di creare un nuovo filesystem.
Se tutto va bene e si utilizzano le stesse opzioni dell'esempio precedente, il prossimo reboot dovrebbe dare un semplice menu di boot con cinque voci. Se si desidera in futuro modificare il file di configurazione di yaboot, è sufficiente eseguire ybin -v per aggiornare la partizione di bootstrap; mkofboot è solo per l'installazione iniziale.
Per ulteriori informazioni su yaboot, consultare il yaboot project. Ora continuare l'installazione con Riavviare il sistema.
10.c. Usare yaboot su IBM hardware
Su hardware IBM non si può eseguire yabootconfig o ybin. Si deve procedere con i seguenti passi:
Codice 3.1: yaboot.conf per IBM hardware |
device=disk:
partition=2
root=/dev/sda2
default=linux
timeout=50
image=/boot/kernel-2.6.19-gentoo-r7
label=linux
append="console=ttyS0,9600"
read-only
|
Per hardware POWER4, POWER5, e blade-based dove la partizione PReP e la partizione che contiene il kernel sono sullo stesso disco fisico, si può usare un yaboot.conf semplificato. Il seguente dovrebbe essere sufficiente:
Codice 3.2: yaboot.conf per PReP hardware |
default = linux
timeout = 100
image=/boot/kernel-2.6.19-gentoo-r7
label=linux
read-only
root = /dev/sda2
append="root=/dev/sda2"
|
Per verificare che yaboot è stato copiato nella partizione PReP:
Codice 3.3: Verificare che yaboot è installato su PReP |
# dd if=/dev/sda1 count=10 | grep ELF
Binary file (standard input) matches
10+0 records in
10+0 records out
|
Un match significa che yaboot è stato installato correttamente.
Uscire dall'ambiente in cui si è fatto il chroot e smontare tutte le partizioni montate. Poi digitare il comando reboot.
Codice 4.1: Uscire dal chroot, smontare tutte le partizioni e riavviare |
# exit ~# cd ~# umount /mnt/gentoo/boot /mnt/gentoo/dev /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.
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 |
| portage | abilita l'utilizzo di emerge --pretend da utente normale |
| usb | abilita l'accesso ai dispositivi USB |
| plugdev | concede la possibilità di monstare ed utilizzre unità rimovibili quali memorie USB o macchine fotografiche. |
| 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 e GNOME.
Codice 2.4: Installare GNOME |
# emerge --usepkg gnome
|
Per avere un elenco dei pacchetti precompilati è possibile visualizzare i file in /mnt/cdrom/All. Ad esempio per vedere se è possibile installare KDE:
Codice 2.5: Verificare se è possibile installare KDE |
# ls /mnt/cdrom/All/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.
Congratulazioni! Adesso si ha un sistema funzionante con Gentoo. Ma cosa fare adesso? Quali sono le opzioni? Che cosa vedere per prima cosa? Gentoo fornisce ai suoi utenti molte possibilità e caratteristiche più o meno documentate.
Si dovrebbe dare un'occhiata alla prossima parte del Manuale Gentoo, Lavorare con Gentoo, che spiega come mantenere aggiornato il software, come installare altro software, che cosa sono le flag USE, come funziona il Gentoo Init system, etc.
Se si è interessati all'ottimizzazione del proprio sistema per il desktop, o si vuole imparare a configurare il sistema affinchè diventi un desktop completamente funzionante, consultare le Guide alla configurazione del desktop. Inoltre, è possibile fare riferimento alla nostra Guida alla localizzazione per adattare il sistema alla nazionalità.
E' ionoltre disponibile un ampio documento riguardante la Manuale sulla sicurezza per Gentoo di certo interesse.
Per un elenco completo di tutta la documentazione disponibile, consultare le risorse della Documentazione Gentoo.
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 2007.0
Non ci sono cambiamenti significativi al momento.
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
|
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
|
1.c. Manutenzione 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
|
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) |
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.
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 vuole aggiornare ogni singolo pacchetto del sistema, occorre aggiungere l'argomento --deep:
Codice 3.11: Aggiornare l'intero sistema |
# emerge --update --deep 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.12: Eseguire un aggiornamento completo |
# emerge --update --deep --newuse world
|
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 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.13: 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.14: Installazione del pacchetto gentoolkit |
# emerge gentoolkit
|
1.d. 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 sistema di gestione degli eventi provvede un virtual/syslog in modo tale che le applicazioni possano dipendere da tale virtual/syslog.
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.
Codice 4.1: Portage avverte riguardo ai pacchetti bloccati (con --pretend) |
[blocks B ] mail-mta/ssmtp (from pkg mail-mta/postfix-2.2.2-r1) |
Codice 4.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.
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 'atomico', come <media-video/mplayer-bin-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.
Codice 4.3: Portage avverte riguardo ai pacchetti mascherati |
!!! all ebuilds that could satisfy "bootsplash" have been masked. |
Codice 4.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) |
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:
Codice 4.5: 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.
Codice 4.6: Portage avverte circa l'ambiguità di nomi di ebuild |
!!! The short ebuild name "aterm" is ambiguous. Please specify
!!! one of the following fully-qualified ebuild names instead:
dev-libs/aterm
x11-terms/aterm
|
L'applicazione che si vuole installare ha un nome che corrisponde con un altro pacchetto. Occorre specificare la categoria. Portage informa sulle scelte possibili.
Codice 4.7: 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.
Codice 4.8: 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 4.9: 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 4.10: 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. |
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.
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 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.
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/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 2004.3:
Codice 2.1: Somma delle variabili USE make.defaults per il profilo 2004.3 |
(Questo esempio è la somma delle impostazioni in base, default-linux, default-linux/x86 e default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad
mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt
quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"
|
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/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/make.conf:
Codice 2.2: Un esempio di dichiarazione USE in /etc/make.conf |
USE="-kde -qt3 -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/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
|
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):
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.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/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
|
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.
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/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
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. Nelle compilazioni comuni, il tempo di compilazione risulta di 5-10 volte più veloce.
Per maggiori informazioni su ccache, è possibile consultare la homepage di ccache.
Per installare ccache, eseguire emerge ccache:
Codice 3.1: Installare ccache |
# emerge ccache
|
Attivare il supporto di Portage
Aprire /etc/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/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/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
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/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
|
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.
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.
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.
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.
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 |
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
|
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.
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.
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/make.conf), e rendono davvero facile configurare un servizio. Permettono inoltre di aggiungere molte informazioni sulle variabili (come commenti).
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!
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)
}
restart() {
(Comando necessario per riavviare un servizio)
}
|
Ogni init script richiede che la funzione start() sia definita. Tutte le altre sezioni sono opzionali.
Ci sono due tipi di dipendenze che possono essere definite: use e need. Come menzionato sopra, la dipendenza need è più restrittiva della dipendenza use. Secondo questo tipo di dipendenza si definisce il concetto di dipendenza virtuale.
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:
In alcuni casi si potrebbe non aver bisogno di un servizio, ma si può voler avviare un servizio prima (o dopo) un'altro se disponibile sul sistema (notare il condizionale:questa non è un'altra dipendenza) e eseguirle nello stesso runlevel. Si possono fornire queste informazioni usando before o after.
Come esempio vengono esaminate le impostazioni del servizio Portmap:
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
}
|
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() {
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.
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.
Altre funzioni che si possono definire sono: stop() e restart(). Non si è obbligati a definire queste funzioni! Il sistema di init è abbastanza intelligente da inserire da solo queste funzioni se si usa start-stop-daemon.
Sebbene non occorra creare una funzione stop(), viene fornito un esempio:
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 Bourne Again Shell (bash) così si possono usare costrutti compatibili bash nei propri init script.
Aggiungere opzioni personalizzate
Se si ha bisogno di maggiori opzioni negli init script, si può aggiungere l'opzione alla variabile opts, 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 |
opts="${opts} restartdelay"
restartdelay() {
stop
sleep 3 # Attendere 3 secondi prima di avviarsi nuovamente
start
}
|
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):
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.
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 verrà poi rimosso dal runlevel offline, udev proverà ancora ad avviare ogni elemento che riesce a rilevare e invocherà i servizi appropriati. Pertanto, sarà necessario aggiungere ogni servizio di rete che non si vuole venga avviato (così come tutti gli altri servizi per ogni altro componente che potrebbero essere avviati da udev) a /etc/conf.d/rc come mostrato di seguito.
Codice 5.3: Disabilitare i servizi inizializzati per i diversi componenti in /etc/conf.d/rc |
RC_COLDPLUG="yes"
(Di seguito, specificare i servizi che non si vuole vengano inizializzati automaticamente")
RC_PLUG_SERVICES="!net.eth0"
|
Nota: Per maggiori informazioni sui servizi inizializzati per i diversi componenti, si invita a porre attenzione nei commenti del file /etc/conf.d/rc. |
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 è completamente analogo a softlevel. L'unica differenza è che si sta definendo un secondo runlevel di "boot" invece di un secondo runlevel "default".
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.
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
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.
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, solo con le seguenti variabili la si può ottenere: KDEDIRS, PATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH e PRELINK_PATH_MASK. Per tutte le altre variabili è usato l'ultimo valore definito (in ordine alfabetico dei file in /etc/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
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.
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"
|
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/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/make.profile.
Se si sta pianificando la modifica di una variabile di configurazione non alterare /etc/make.globals o make.defaults. Usare invece /etc/make.conf che ha la precedenza sui file precedenti. C'è anche un file chiamato /etc/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/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:
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/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 |
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/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.
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.
Il codice sorgente delle applicazioni è memorizzato in modo predefinito all'interno di /usr/portage/distfiles. Questa ubicazione è definita dalla variabile DISTDIR.
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.
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.
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.
Portage crea specifiche directory di compilazione per ogni pacchetto emerso all'interno di /var/tmp/portage. Questa ubicazione è definita dalla variabile BUILD_PREFIX.
Portage installa in modo predefinito tutti i file sul filesystem corrente (/), ma si può modificare questa definizione usando la variabile d'ambiente ROOT.
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:
Importante: Se si usa enotice con Portage-2.0.*, si deve completamente rimuovere enotice, in quanto incompatibile con elog. |
2.a. Configurazione del Portage
Si è potuto notare come il Portage sia configurabile attraverso numerose variabili che si possono definire in /etc/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:
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
|
Per 'sproteggere' certe sottodirectory da locazioni protette si può usare la variabile CONFIG_PROTECT_MASK.
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:
Una terza definizione coinvolge l'ubicazione del server rsync usato quando si aggiorna l'albero del Portage:
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.
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.
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:
Per maggiori informazioni su queste ed altre opzioni, leggere la pagina di manuale di rsync.
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.
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
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
|
La variabile NOCOLOR, il cui valore predefinito è "false", definisce se Portage deve disabilitare l'uso di output colorato.
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.
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/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
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.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.keywords per gnumeric, linea completa |
app-office/gnumeric ~x86 |
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.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 ~x86 |
3.c. Usare pacchetti mascherati
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 stessa identica linea 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 |
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 |
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:
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
|
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.
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, arts e procps:
Codice 3.1: Esempio dell'uso di quickpkg |
# quickpkg curl arts procps
|
I pacchetti precompilati vengono memorizzati in $PKGDIR/All (/usr/portage/packages/All di default). Link simbolici che puntano a questi pacchetti sono posti in $PKGDIR/<category>.
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 --exclude-from in /etc/make.conf.
Codice 1.1: Definizione del file di esclusione in /etc/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/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.
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/gentoolkit-dev fornisce gensync, uno strumento che aiuta a mantenere aggiornati gli overlay repository.
Con gensync si possono aggiornate tutti i repository in una volta sola o selezionare solo alcuni di essi. Ogni repository dovrebbe avere un file .syncsource nella directory di configurazione /etc/gensync/ che contiene l'ubicazione del repository, il nome, l'ID, ecc.
Si supponga di avere due repository aggiuntivi 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 gensync per aggiornare alcuni repository |
# gensync java entapps
|
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 |
Nota: Questo documento assume che il kernel e i suoi moduli per l'hardware siano stati configurati correttamente e che si conosca il nome della propria interfaccia hardware. Si assume inoltre di voler configurare eth0, ma potrebbe essere anche eth1, wlan0, ecc. |
Nota: Questo documento richiede l'esecuzione di baselayout-1.11.11 o versioni successive. |
Per iniziare la configurazione della scheda di rete, si deve far conoscere quest'ultima al sistema Gentoo RC, tramite la creazione di un collegamento simbolico da net.lo a net.eth0 in /etc/init.d.
Codice 1.1: Collegamento simbolico di net.eth0 a net.lo |
# cd /etc/init.d # ln -s net.lo net.eth0 |
Ora il sistema Gentoo RC conosce questa interfaccia, ma deve anche sapere come configurarla. Tutte le interfacce di rete sono configurate in /etc/conf.d/net. Segue un esempio di configurazione per DHCP e indirizzi statici.
Codice 1.2: Esempi per /etc/conf.d/net |
# Per DHCP config_eth0=( "dhcp" ) # Per IP statico usando la notazione CIDR config_eth0=( "192.168.0.7/24" ) routes_eth0=( "default via 192.168.0.1" ) # Per IP statico usando la notazione netmask config_eth0=( "192.168.0.7 netmask 255.255.255.0" ) routes_eth0=( "default via 192.168.0.1" ) |
Nota: Se non si specifica una configurazione per l'interfaccia, viene automaticamente utilizzato DHCP. |
Nota: CIDR significa Classless InterDomain Routing. In origine, gli indirizzi IPv4 erano classificati come A, B, o C. Questo sistema di classificazione non prevedeva la grande popolarità di Internet, e rischia di rimanere a corto di nuovi indirizzi univoci. CIDR è uno schema di indirizzamento che permette ad un indirizzo IP di designare molti indirizzi IP. Un indirizzo CIDR IP assomiglia ad un indirizzo IP normale tranne per il fatto che finisce con uno slash seguito da un numero; per esempio, 192.168.0.0/16. CIDR è descritto in RFC 1519. |
Ora che l'interfaccia è stata configurata, si può avviarla e fermarla con i comandi seguenti.
Codice 1.3: Avviare e fermare gli script di rete |
# /etc/init.d/net.eth0 start # /etc/init.d/net.eth0 stop |
Importante: Quando si hanno problemi con la rete, è raccomandato impostare RC_VERBOSE="yes" in /etc/conf.d/rc in modo da ottenere maggiori informazioni su quello che succede. |
Ora che l'interfaccia di rete è stata avviata e fermata con successo, è consigliabile farla partire durante l'avvio di Gentoo, utilizzando i comandi seguenti. L'ultimo comando "rc" dice a Gentoo di avviare qualsiasi script nel runlevel attuale che non è ancora stato avviato.
Codice 1.4: Configurare una interfaccia di rete che si carica al boot |
# rc-update add net.eth0 default # rc |
La variabile config_eth0 è il cuore della configurazione di un'interfaccia, ed è composta da un elenco di istruzioni di alto livello per la sua configurazione (in questo caso l'interfaccia è eth0). Ogni comando di questo elenco è effettuato sequenzialmente, e l'interfaccia viene considerata funzionante se almeno un comando viene eseguito con successo.
Ecco un elenco delle istruzioni integrate.
| Comando | Descrizione |
| null | Non fa niente |
| noop | Se l'interfaccia è attiva e c'è un indirizzo, chiude la configurazione con successo |
| un indirizzo IPv4 o IPv6 | Aggiunge l'indirizzo dell'interfaccia |
| dhcp, adsl o apipa (o un comando personalizzato da un modulo di terze parti) | Esegue il modulo fornito dal comando. Per esempio dhcp esegue un modulo che fornisce dhcp, il quale può essere uno tra dhcpcd, dhclient o pump. |
Se un comando non funziona, si può specificare un comando di riserva. Questo deve corrispondere con esattezza alla struttura di configurazione.
Si possono unire insieme questi comandi. Ecco alcuni esempi reali:
Codice 1.1: Esempi di configurazione |
# Aggiungere tre indirizzi IPv4 config_eth0=( "192.168.0.2/24" "192.168.0.3/24" "192.168.0.4/24" ) # Aggiungere un indirizzo IPv4 e due indirizzi IPv6 config_eth0=( "192.168.0.2/24" "4321:0:1:2:3:4:567:89ab" "4321:0:1:2:3:4:567:89ac" ) # Mantenere l'indirizzo assegnato dal kernel, a meno che l'interfaccia # non venga disattivata e allora assegnarne un altro tramite DHCP. Se DHCP # fallisce aggiungere un indirizzo statico determinato tramite APIPA config_eth0=( "noop" "dhcp" ) fallback_eth0=( "null" "apipa" ) |
Nota: Quando si usa il modulo ifconfig e si aggiunge più di un indirizzo, per ogni ulteriore indirizzo vengono creati degli alias di interfaccia. Con gli esempi precedenti, si ottengono le interfacce eth0, eth0:1 e eth0:2. Non si può fare niente di speciale con queste interfacce poichè il kernel e gli altri programmi trattano eth0:1 e eth0:2 come eth0. |
Importante: L'ordine dei comandi di riserva è importante! Se non si specifica l'opzione null allora il comando apipa si esegue solo se fallisce il comando noop. |
Gli script di inizializzazione in /etc/init.d possono dipendere da una specifica interfaccia di rete o da net. net può essere definita in /etc/conf.d/rc e può voler significare diverse cose grazie alla variabile RC_NET_STRICT_CHECKING.
| Valore | Descrizione |
| none | Il servizio net è sempre considerato attivo |
| no | Significa che almeno un servizio net.* oltre a net.lo deve essere attivo. Può essere usato dagli utenti con notebook che usano la rete WIFI e una schede di rete statica e ne vogliono solamente una attiva in qualsiasi momento per considerare come attivo il servizio net. |
| lo | È lo stesso di no, ma viene preso in considerazione anche net.lo. Dovrebbe essere utile alle persone che non danno peso a quale specifica interfaccia venga attivata durante l'avvio. |
| yes | TUTTE le interfacce di rete DEVONO essere attive affinchè il servizio net sia considerato attivo. |
Ma che succede se net.br0 dipende da net.eth0 e net.eth1? net.eth1 potrebbe essere un dispositivo wireless o ppp che deve essere configurato prima che sia aggiunto al bridge. Non può essere fatto in /etc/init.d/net.br0 poichè questo è un collegamento simbolico a net.lo
La risposta corretta è quella di usare la funzione depend() in /etc/conf.d/net
Codice 2.1: Dipendenza net.br0 in /etc/conf.d/net |
# Si può usare qualsiasi dipendenza (use, after, before) come si # trova negli script attuali
depend_br0() {
need net.eth0 net.eth1
}
|
Per una discussione più dettagliata sulla dipendenza, consultare la sezione Scrivere Init Script nel Manuale Gentoo.
2.c. Nomi di variabili e valori
I nomi delle variabili sono dinamici. Di solito seguono la struttura variable_${interface|mac|essid|apmac}. Per esempio, la variabile dhcpcd_eth0 contiene il valore per le opzioni dhcpcd per eth0 e dhcpcd_essid contiene il valore per le opzioni dhcpcd quando una interfaccia si connette a essid "essid".
Non c'è nessuna regola che dice che i nomi delle interfacce debbano essere ethx. Molte interfacce wireless hanno nomi come wlanx, rax e anche ethx. Alcune interfacce definite dagli utenti, come i bridge, possono avere qualsiasi nome, per esempio foo. Per rendere il tutto più interessante, gli Access Point Wireless possono avere nomi che contengono caratteri alfa numerici - questo è importante perchè si possono configurare i parametri di rete per ESSID.
Gentoo usa variabili bash per la rete - e bash non può usare altro che caratteri alfanumerici inglesi. Per ovviare a questa limitazione si cambia ogni carattere non alfanumerico inglese nel carattere _
Altro problema con bash, è il contenuto delle variabili - alcuni caratteri hanno bisogno di essere specificati in modo particolare. Si risolve mettendo un \ all'inizio di questi. I seguenti caratteri devono essere specificati in modo particolare: ", ' e \.
In questo esempio si usa wireless ESSID poichè contiene un vasto numero di caratteri. Si usa il ESSID My "\ NET:
Codice 3.1: Esempio di nomi di variabili |
(Funziona, ma il domain è invalido) dns_domain_My____NET="My \"\\ NET" (Il comando precedente imposta il domain dns a My "\ NET quando una scheda wireless si connette a un AP che ha ESSID come My "\ NET) |
Attualmente vengono supportati gli script di rete modulari, il che significa che si può aggiungere il supporto per nuovi tipi di interfaccia e moduli di configurazione mantenendo allo stesso tempo la compatibilità con quelli esistenti.
I moduli vengono caricati in modo predefinito se il pacchetto che essi necessitano è installato. Se si specifica un modulo che non ha installato il suo pacchetto, si ottiene un errore che avvisa quale pacchetto necessita di essere installato. Idealmente, le impostazioni per i moduli sono da usare solamente quando si hanno due o più pacchetti installati che forniscono lo stesso servizio e si deve preferire uno rispetto ad un altro.
Nota: Tutte le impostazioni discusse, sono in /etc/conf.d/net, dove non diversamente specificato. |
Codice 1.1: Preferenza dei moduli |
# Si preferisce iproute2 su ifconfig modules=( "iproute2" ) # Si possono anche specificare altri moduli per una interfaccia # In questo caso si preferisce pump su dhcpcd modules_eth0=( "pump" ) # Si possono anche specificare quali moduli non usare - per esempio # si potrebbe usare un supplicant o un linux-wlan-ng per controllare # la configurazione wireless ma volere ancora configurare le impostazioni di # rete per ESSID che sono associate. modules=( "!iwconfig" ) |
3.b. Utilità di configurazione delle interfacce
Sono fornite due utilità di configurazione delle interfacce: ifconfig e iproute2. C'è bisogno di una di esse per fare qualsiasi tipo di configurazione di rete.
ifconfig è la scelta predefinita di Gentoo ed è incluso nel profilo di sistema. iproute2 è un pacchetto più potente e flessibile, ma non è incluso in modo predefinito.
Codice 2.1: Installare iproute2 |
# emerge sys-apps/iproute2 # Preferire iproute2 su ifconfig se entrambi sono installati modules=( "iproute2" ) |
Poichè ifconfig e iproute2 fanno un lavoro molto simile, viene permesso che le loro configurazioni di base funzionino l'una con l'altra. Per esempio entrambi i codici funzionano a prescindere dal modulo che si sta usando.
Codice 2.2: Esempi di ifconfig e iproute2 |
config_eth0=( "192.168.0.2/24" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0" )
# Si può anche specificare il broadcast
config_eth0=( "192.168.0.2/24 brd 192.168.0.255" )
config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )
|
DHCP è la possibilità di ottenere informazioni di rete (indirizzo IP, server DNS, Gateway, ecc.) da un server DHCP. Ciò significa che se c'è un server DHCP funzionante sulla rete, basta dire ad ogni client di usare DHCP in modo da fargli impostare la rete da sè. Bisogna configurare altre cose come wireless, ppp o altre se sono richieste, prima di usare DHCP.
DHCP può essere fornito da dhclient, dhcpcd, o pump. Ogni modulo DHCP ha i suoi pro e i suoi contro, eccone un breve riassunto.
| Modulo DHCP | Pacchetto | Pro | Contro |
| dhclient | net-misc/dhcp | Fatto da ISC, gli stessi che fanno il software BIND DNS. Altamente configurabile | La configurazione è complessa, il software è enorme, non si possono ottenere server NTP da DHCP, non invia l'hostname in modo predefinito |
| dhcpcd | net-misc/dhcpcd | Da tanto tempo scelta predefinita di Gentoo, nessuna dipendenza da strumenti esterni, attivamente sviluppato da Gentoo | Può essere lento, non può essere ancora eseguito come demone quando il lease è infinito |
| pump | net-misc/pump | Leggero, nessuna dipendenza da altri strumenti | Non è più mantenuto dagli sviluppatori originali, non sicuro, specialmente su alcuni modem, non si possono ottenere server NIS da DHCP |
Se si ha installato più di un client DHCP, bisogna specificare quale usare, altrimenti la scelta predefinita sarà dhcpcd, se disponibile.
Per passare opzioni specifiche al modulo dhcp, usare module_eth0="..." (cambiare module con il module DHCP che si sta usando, es. dhcpcd_eth0)
L'obiettivo è quello di rendere DHCP più semplice, perciò vengono supportati i seguenti comandi usando la variabile dhcp_eth0. L'impostazione predefinita è non impostare nessuna di queste.
Codice 3.1: Esempio di configurazione DHCP in /etc/conf.d/net |
# Necessario solamente se sono stati installati più moduli DHCP modules=( "dhcpcd" ) config_eth0=( "dhcp" ) dhcpcd_eth0="-t 10" # Timeout dopo 10 secondi dhcp_eth0="release nodns nontp nonis" # Ottiene solo un indirizzo |
Nota: dhcpcd e pump inviano l'attuale hostname al server DHCP predefinito, in questo modo non occorre più specificarlo. |
Prima bisogna installare il software ADSL.
Codice 4.1: Installare il pacchetto ppp |
# emerge net-dialup/ppp
|
Nota: Se c'è la necessità di utilizzare PPPoA, assicurarsi di usare >=baselayout-1.12.x. |
Poi, creare lo script net per PPP e quello per l'interfaccia di rete usata da PPP.
Codice 4.2: Creare gli script PPP e ethernet |
# ln -s /etc/init.d/net.lo /etc/init.d/net.ppp0 # ln -s /etc/init.d/net.lo /etc/init.d/net.eth0 |
Assicurarsi di impostare RC_NET_STRICT_CHECKING="yes" in /etc/conf.d/rc.
Ora bisogna configurare /etc/conf.d/net.
Codice 4.3: Una configurazione base per PPPoe |
config_eth0=( null ) (Specificare la propria interfaccia ethernet) config_ppp0=( "ppp" ) link_ppp0="eth0" (Specificare la propria interfaccia ethernet) plugins_ppp0=( "pppoe" ) username_ppp0='user' password_ppp0='password' pppd_ppp0=( "noauth" "defaultroute" "usepeerdns" "holdoff 3" "child-timeout 60" "lcp-echo-interval 15" "lcp-echo-failure 3" noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp ) depend_ppp0() { need net.eth0 } |
La password può essere anche impostata in /etc/ppp/pap-secrets.
Codice 4.4: Esempio /etc/ppp/pap-secrets |
# L'asterisco * è importante
"username" * "password"
|
Se si utilizza PPPoE con un modem USB bisogna installare br2684ctl. Si prega di leggere /usr/portage/net-dialup/speedtouch-usb/files/README per ottenere informazioni su come configurarlo adeguatamente.
Importante: Leggere attentamente le sezioni su ADSL e PPP in /etc/conf.d/net.example. Questo file contiene un gran numero di spiegazioni dettagliate riguardo a tutte le impostazioni per la propria configurazione particolare di PPP. |
3.e. APIPA (Automatic Private IP Addressing)
APIPA cerca di trovare un indirizzo libero tra 169.254.0.0-169.254.255.255 con un arping di un indirizzo casuale, incluso nella gamma di indirizzi summenzionati, sull'interfaccia. Se non c'è nessuna risposta allora si assegna questo indirizzo all'interfaccia.
L'uso di APIPA è utile per le LAN in cui non c'è nessun server DHCP e non ci si connette direttamente a Internet e tutti gli altri computer utilizzano APIPA.
Per il supporto ad APIPA installare net-misc/iputils o net-analyzer/arping.
Codice 5.1: Configurazione di APIPA in /etc/conf.d/net |
# Cercare DHCP - se fallisce passare ad APIPA config_eth0=( "dhcp" ) fallback_eth0=( "apipa" ) # Usare APIPA config_eth0=( "apipa" ) |
Per poter effettuare il bonding/trunking (ndT: unione/aggregazione) di collegamenti installare net-misc/ifenslave.
Il bonding è usato per aumentare la larghezza di banda della rete. Se si hanno due schede di rete sulla stessa rete, si possono collegare insieme in modo che le applicazioni vedano una sola interfaccia ma in realtà utilizzino entrambe le due schede di rete.
Codice 6.1: Configurazione per il bonding in /etc/conf.d/net |
# Per collegare le interfacce slaves_bond0="eth0 eth1 eth2" # Si può non assegnare un IP all'interfaccia collegata config_bond0=( "null" ) # Dipende da eth0, eth1 e eth2 poichè essi possono richiedere una configurazione extra depend_bond0() { need net.eth0 net.eth1 net.eth2 } |
3.g. Bridging (supporto 802.1d)
Per il supporto al "bridging" installare net-misc/bridge-utils
Il bridging è usato per collegare insieme delle reti. Per esempio, si ha un server che si connette a Internet con un modem ADSL e una scheda wireless access che permette a altri computer di connettersi a Internet con il modem ADSL. Si può creare un "bridge" (ponte) per unire le due interfacce.
Codice 7.1: Configurazione per il bridge in /etc/conf.d/net |
# Configurare il bridge - "man brctl" per ulteriori dettagli brctl_br0=( "setfd 0" "sethello 0" "stp off" ) # Per aggiungere delle porte al bridge br0 bridge_br0="eth0 eth1" # Si devono configurare le porte con valori null in modo da non avviare dhcp config_eth0=( "null" ) config_eth1=( "null" ) # Dare un indirizzo al bridge - si può usare DHCP config_br0=( "192.168.0.1/24" ) # Dipende da eth0 e eth1 poichè essi possono richiedere una configurazione aggiuntiva depend_br0() { need net.eth0 net.eth1 } |
Importante: Per usare alcune impostazioni per il bridge di rete, è consigliabile consultare la documentazione riguardante i nomi di variabili |
3.h. Indirizzo MAC (MAC Address)
Non occorre installare niente per cambiare l'indirizzo MAC di una interfaccia se si utilizza sys-apps/baselayout-1.11.14 o superiore e si desidera cambiarlo in un indirizzo MAC specifico. Tuttavia, se lo si vuole cambiare con un indirizzo MAC a caso o si ha una versione di baselayout più vecchia rispetto a quella appena nominata, allora per potere fare uso di questa caratteristica bisogna installare net-analyzer/macchanger.
Codice 8.1: Esempio di cambio di un Indirizzo MAC |
# Impostare l'indirizzo MAC all'interfaccia mac_eth0="00:11:22:33:44:55" # Per rendere casuali solo gli ultimi 3 byte mac_eth0="random-ending" # Per rendere casuale tra lo stesso tipo fisico di connessione (esempio # fibra, copper, wireless), tutti i fornitori mac_eth0="random-samekind" # Per rendere casuale tra qualsiasi tipo fisico di connessione (esempio # fibra, copper, wireless), tutti i fornitori mac_eth0="random-anykind" # Casualità completa - ATTENZIONE: alcuni indirizzi MAC generati # da questo esempio potrebberoNON funzionare come previso mac_eth0="random-full" |
Non occorre installare niente per il tunnelling in quanto il gestore dell'interfaccia lo fa già da sè.
Codice 9.1: Configurazione per il tunnelling in /etc/conf.d/net |
# Per tunnel GRE iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255" # Per tunnel IPIP iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255" # Per configurare l'interfaccia config_vpn0=( "192.168.0.2 peer 192.168.1.1" ) |
Per il supporto alle VLAN installare net-misc/vconfig.
Virtual LAN è un gruppo di dispositivi di rete che si comportano come se fossero connessi ad un singolo segmento di rete, anche se realmente non lo sono. I membri della VLAN possono solo vedere i membri della stessa VLAN anche se potrebbero condividere la stessa rete.
Codice 10.1: Configurazione per la VLAN in /etc/conf.d/net |
# Specificare i numeri VLAN per le interfacce in questo modo # Assicurarsi che gli ID di VLAN NON abbiano degli zeri riempitivi vlans_eth0="1 2" # Si può anche configurare la VLAN # vedere la pagina man di vconfig per ulteriori dettagli vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" ) # Configurare l'interfaccia come al solito config_vlan1=( "172.16.3.1 netmask 255.255.254.0" ) config_vlan2=( "172.16.2.1 netmask 255.255.254.0" ) |
Importante: Per usare alcune impostazioni di VLAN, è consigliabile consultare la documentazione relativa ai nomi di variabili. |
Attualmente si supporta l'installazione wireless sia con wireless-tools sia con wpa_supplicant. La cosa importante è ricordare che si configura per reti wireless su basi globali e non su basi di interfaccia.
wpa_supplicant è la scelta migliore, ma non supporta tutti i driver. Per un elenco di tutti i driver supportati, leggere il sito di wpa_supplicant. Inoltre, wpa_supplicant attualmente può essere connesso solamente al SSID che si è configurato.
wireless-tools supporta quasi tutte le schede e i driver, ma non può connettersi ad Access Point configurati solamente con WPA.
Avvertenza: Il driver linux-wlan-ng non è supportato ancora da baselayout. Questo perchè linux-wlan-ng ha la propria installazione e configurazione che è differente da quella di tutti gli altri. Gli sviluppatori di linux-wlan-ng sembra vogliano cambiare le impostazioni a wireless-tools - quando accadrà si potrà usare linux-wlan-ng con baselayout. |
WPA Supplicant è un pacchetto che permette di connettersi ad access point WPA abilitati. La sua installazione non è fluida poichè è ancora in beta - ma comunque funziona bene.
Codice 2.1: Installare wpa_supplicant |
# emerge net-wireless/wpa_supplicant
|
Importante: Bisogna avere abilitato CONFIG_PACKET nel kernel per fare funzionare wpa_supplicant. |
Configurare /etc/conf.d/net, per specificare l'utilizzo preferito di wpa_supplicant rispetto a wireless-tools (se entrambi sono installati, wireless-tools è quello predefinito).
Codice 2.2: Configurazione di /etc/conf.d/net per wpa_supplicant |
# Si preferisce wpa_supplicant a wireless-tools modules=( "wpa_supplicant" ) # E' importante dire a wpa_supplicant quale driver dovrebbe # essere usato in quanto non riesce ancora ad indovinarlo correttamente wpa_supplicant_eth0="-Dmadwifi" |
Nota: Se si sta usando il driver host-ap si deve mettere la scheda in Managed mode prima di usarla con wpa_supplicant. Per ottenere ciò, si può usare iwconfig_eth0="mode managed" in /etc/conf.d/net. |
Semplice vero? Tuttavia c'è ancora da configurare wpa_supplicant che risulta essere un po' più difficile in base alla tipo di configurazione di sicurezza degli Access Point a cui si sta cercando di connettere. L'esempio seguente è preso e semplificato da /usr/share/doc/wpa_supplicant-<versione>/wpa_supplicant.conf.gz il quale viene fornito insieme a wpa_supplicant.
Codice 2.3: Un esempio di /etc/wpa_supplicant/wpa_supplicant.conf |
# La riga sottostante non deve essere cambiata altrimenti non funziona ctrl_interface=/var/run/wpa_supplicant # Assicurarsi che solo root possa leggere la configurazione WPA ctrl_interface_group=0 # Lasciare che wpa_supplicant si occupi della scansione e della selezione AP ap_scan=1 # Caso semplice: WPA-PSK, PSK come un ASCII passphrase, permette tutte cifre valide network={ ssid="simple" psk="very secret passphrase" # Più alta è la priorità, prima c'è riconoscimento priority=5 } # Lo stesso del precedente, ma è richiesto la scansione specifica per # SSID (per AP che rifiutano il broadcast del SSID) network={ ssid="second ssid" scan_ssid=1 psk="very secret passphrase" priority=2 } # E' usato solo WPA-PSK. Qualsiasi combinazione di cifre valida è accettata network={ ssid="example" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb priority=2 } # Connessione plaintext (no WPA, no IEEE 802.1X) network={ ssid="plaintext-test" key_mgmt=NONE } # Connessione condivisa WEP key (no WPA, no IEEE 802.1X) network={ ssid="static-wep-test" key_mgmt=NONE # Le chiavi tra doppi apici sono in formato ASCII wep_key0="abcde" # Le chiavi specificate senza doppi apici sono in formato esadecimales wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 } # Connessione condivisa WEP key (no WPA, no IEEE 802.1X) usando # autenticazione Shared Key IEEE 802.11 network={ ssid="static-wep-test2" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 auth_alg=SHARED } # Rete IBSS/ad-hoc con WPA-None/TKIP network={ ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="secret passphrase" } |
Impostazione iniziale e Managed Mode
Wireless Tools forniscono un modo generico di configurare le interfacce wireless di base fino al livello di sicurezza WEP. Sebbene WEP sia un metodo di sicurezza debole, è anche quello prevalente.
La configurazione di Wireless Tools è controllata da poche variabili principali. L'esempio di configurazione seguente dovrebbe descrivere tutto il necessario. Una cosa da tenere in mente è che nessuna configurazione significa "connesso al più forte non criptato Access Point" - si cerca e ci si connette sempre a qualcosa.
Codice 3.1: Installare wireless-tools |
# emerge net-wireless/wireless-tools
|
Nota: Si possono mettere le impostazioni wireless in /etc/conf.d/wireless, ma questa guida raccomanda di metterle in /etc/conf.d/net. |
Importante: Si deve consultare la guida nomi di variabili. |
Codice 3.2: Esempio di impostazione iwconfig in /etc/conf.d/net |
# Si preferisce iwconfig a wpa_supplicant modules=( "iwconfig" ) # Configurare le chiavi WEP per gli Access Point denominati ESSID1 e ESSID2 # Si potrebbero configurare fino a 4 chiavi WEP, ma si utilizzarne solamente 1 alla volta # per cui si fornisce un indice predeinito di [1] per impostare la chiave [1] e in # seguito cambiare la chiave attiva a [1] # Viene fatto questo in caso si definiscano altri ESSID per usare chiavi WEP diverse da 1 # # Prefissare la chiave con s: significa che è una chiave ASCII, altrimenti è una chiave esadecimale (HEX) # # enc open specificata sicurezza aperta (più sicura) # enc restricted specificata sicurezza ristretta (meno sicura) key_ESSID1="[1] s:tuachiavequi key [1] enc open" key_ESSID2="[1] aaaa-bbbb-cccc-dd key [1] enc restricted" # Il seguente funziona solo quando si cercano Access Point disponibili # Qualche volta è visibile più di un Access Point per cui si deve # definire un ordine preferito per connettersi preferred_aps=( "ESSID1" "ESSID2" ) |
Regole personalizzate per la selezione degli Access Point
Si possono aggiungere alcune opzioni extra per raffinare la selezione degli Access Point, ma normalmente non sono richieste.
Si può decidere se ci si connette solo a Access Point preferiti o no. Come regola predefinita se ogni configurazione fallisce e ci si può connettere a un Access Point non criptato allora va bene. Questo può essere controllato dalla variabile associate_order. Ecco una tabella di valori e come essi controllano questo aspetto.
| Valore | Descrizione |
| any | Comportamento predefinito |
| preferredonly | Ci si connette solo ad AP visibili nell'elenco preferito |
| forcepreferred | Ci si connette ad AP nell'ordine preferito se non sono stati trovati in una scansione |
| forcepreferredonly | Non fa la scansione per gli AP, invece cerca di connettere a ognuno di essi in ordine |
| forceany | Uguale a forcepreferred, in più si connette ad ogni altro AP disponibile |
Infine sono disponibili alcune selezioni blacklist_aps e unique_ap. blacklist_aps funziona in modo simile a preferred_aps. unique_ap è un valore yes o no che dice se una seconda interfaccia wireless può connettersi allo stesso Access Point come la prima interfaccia.
Codice 3.3: Esempio di blacklist_aps e unique_ap |
# Qualche volta non ci si vuole connettere a alcuni access point blacklist_aps=( "ESSID3" "ESSID4" ) # Se si possiede più di una scheda wireless, è possibile dare il # permesso a ogni scheda di associarsi (o no) allo stesso Access Point # Valori sono "yes" e "no" # Predefinito è "yes" unique_ap="yes" |
Si può volere una impostazione Ad-Hoc se non si riesce a connettere a un Access Point con la modalità "managed".
Codice 3.4: Tornare al modo ad-hoc |
adhoc_essid_eth0="This Adhoc Node" |
C'è una configurazione apposita per connettersi a reti Ad-Hoc o funzionare in modo Master per trasformarsi in un Access Point, ricordarsi comunque di specificare le chiavi WEP come mostrato in precedenza.
Codice 3.5: Esempio di configurazione ad-hoc/master |
# Impostare il modo - può essere managed (predefinito), ad-hoc o master # Non tutti i driver supportano tutti i modi mode_eth0="ad-hoc" # Impostare il ESSID dell'interfaccia # Nel modo managed, questo forza l'interfaccia ad effettuare un tentativo di connessione # solamente al ESSID specificato essid_eth0="This Adhoc Node" # Viene usato il canale 3 se non ne viene specificato uno channel_eth0="9" |
Importante: L'esempio precedente è preso dalla documentazione BSD che si trova nella documentazione NetBSD. Sono possibili 14 canali; i canali 1-11 sono legali per il Nord America, canali 1-13 per la maggior parte dell'Europa, canali 10-13 per la Francia, e solo il canale 14 per il Giappone. Per ulteriori chiarimenti si rimanda alla documentazione della propria scheda o dell'access point. Assicurarsi che il canale selezionato sia lo stesso canale dell'access point (o dell'altra scheda in una rete ad-hoc). L'impostazione predefinita per le schede vendute in Nord America e nella maggior parte dell'Europa è 3, quella predefinita per le schede vendute in Francia è 11, e quella predefinita per le schede vendute in Giappone è 14. |
Risoluzione di problemi con Wireless Tools
Ci sono alcune variabili che possono aiutare a far funzionare la propria rete wireless, conseguentemente a problemi di driver o di ambiente. Ecco una tabella contenente altre opzioni che si possono provare.
| Variabile | Valore predefinito | Descrizione |
| iwconfig_eth0 | Vedere la pagina man di iwconfig per dettagli su cosa è possibile indicare a iwconfig | |
| iwpriv_eth0 | Vedere la pagina man di iwpriv per dettagli su cosa è possibile indicare a iwpriv | |
| sleep_scan_eth0 | 0 | Il numero di secondi che aspetta prima di fare la scansione. E' necessario quando il driver/firmware ha bisogno di più tempo per attivarsi prima che possa essere usato. |
| sleep_associate_eth0 | 5 | Il numero di secondi che aspetta l'interfaccia per associarsi con l'Access Point prima di spostarsi al prossimo |
| associate_test_eth0 | MAC | Alcuni driver non resettano l'indirizzo MAC associato con uno invalido quando perdono o cercano di effettuare un'associazione. Alcuni driver non resettano il livello di qualità quando perdono o cercano di effettuare un'associazione. Impostazioni valide sono MAC, quality e all. |
| scan_mode_eth0 | Alcuni driver devono fare la scansione nel modo ad-hoc, così se questa fallisce cercano di impostare ad-hoc qui | |
| iwpriv_scan_pre_eth0 | Manda alcuni comandi iwpriv all'interfaccia prima della scansione. Vedere la pagina man di iwpriv per altre informazioni | |
| iwpriv_scan_post_eth0 | Manda alcuni comandi iwpriv alla interfaccia dopo la scansione. Vedere la pagina man di iwpriv per altre informazioni |
4.d. Definire la configurazione di rete per ESSID
Qualche volta quando ci si connette a ESSID1 si deve avere un IP statico e quando ci si connette a ESSID2 si deve avere DHCP. La maggior parte delle variabili dei moduli possono essere definite per ESSID. Ecco come farlo.
Nota: Funzionano se si usa WPA Supplicant o Wireless Tools. |
Importante: Si deve consultare la guida nomi di variabili. |
Codice 4.1: Sovrapporre le impostazioni di rete per ESSID |
config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" ) routes_ESSID1=( "default via 192.168.0.1" ) config_ESSID2=( "dhcp" ) fallback_ESSID2=( "192.168.3.4/24" ) fallback_route_ESSID2=( "default via 192.168.3.1" ) # Si possono definire nameserver e altre cose # NOTARE: DHCP sovrappone queste impostazioni a meno che # gli venga detto di non farlo dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" ) dns_domain_ESSID1="some.domain" dns_search_domains_ESSID1="search.this.domain search.that.domain" # Si sovrappone dall'indirizzo MAC dell'Access Point # E' pratico se si va a posizioni differenti che hanno lo stesso ESSID config_001122334455=( "dhcp" ) dhcpcd_001122334455="-t 10" dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" ) |
5.a. Funzioni di hook (intercettazioni) standard
Possono essere definite quattro funzioni, che sono chiamate in prossimità delle operazioni di avvio/chiusura. Le funzioni sono chiamate con il nome dell'interfaccia in modo che una funzione possa controllare adattatori multipli.
I valori di ritorno per le funzioni preup e predown dovrebbero essere 0 (successo) per indicare che la configurazione o la deconfigurazione dell'interfaccia può continuare. Se preup ritorna con un valore diverso da zero, allora la configurazione dell'interfaccia viene chiusa. Se predown ritorna con un valore diverso da zero, allora all'interfaccia non viene permesso di continuare la deconfigurazione.
I valori di ritorno per le funzioni postup e postdown sono ignorati poichè non c'è niente da fare se indicano un fallimento.
${IFACE} è impostata sull'interfaccia che viene portata sù/giù (up/down). ${IFVAR} è ${IFACE} convertita al nome della variabile che bash permette.
Codice 1.1: Esempi di funzione pre/post up/down |
preup() {
# Test per link sull'interfaccia prima di avviarla. Questo
# funziona solo su alcuni adattatori di rete e richiede che il pacchetto
# ethtool sia installato.
if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "No link on ${IFACE}, aborting configuration"
return 1
fi
# Ricordarsi di restituire 0 in caso di successo
return 0
}
predown() {
# L'azione predefinita nello script è eseguire un test per NFS root e non permettere
# che in quel caso le interfacce vengano disattivate. Notare che se si specifica una funzione
# predown() si sovrappone questa logica, mostrata in dettaglio qui di seguito, in caso
# la si voglia usare...
if is_net_fs /; then
eerror "root filesystem is network mounted -- can't stop ${IFACE}"
return 1
fi
# Ricordarsi di restituire 0 in caso di successo
return 0
}
postup() {
# Questa funzione potrebbe essere usata, per esempio, per
# registrarsi ad un servizio dinamico DNS. Un'altra possibilità potrebbe essere
# mandare/ricevere mail quando l'interfaccia è avviata.
return 0
}
postdown() {
# Questa funzione viene utilizzata perlopiù per completezza. Attualmente
# non c'è mai stato bisogno di utilizzarla.
return 0
}
|
5.b. Funzioni di hook (intercettazioni) per "Wireless Tools"
Nota: Non funziona con WPA Supplicant - ma le variabili ${ESSID} e ${ESSIDVAR} sono disponibili nella funzione postup() |
Possono essere definite due funzioni, che sono chiamate in prossimità della funzione associata. Le funzioni sono chiamate con il nome dell'interfaccia in modo che una funzione possa controllare adattatori multipli.
I valori di ritorno per la funzione preassociate dovrebbero essere 0 (successo) per indicare che la configurazione o la deconfigurazione dell'interfaccia può continuare. Se la preassociate ritorna un valore diverso da zero, allora la configurazione dell'interfaccia viene chiusa.
Il valore di ritorno per la funzione postassociate è ignorato poichè non c'è niente da fare se indica un fallimento.
${ESSID} è impostata all'esatto ESSID dell'AP con cui si è connessi. ${ESSIDVAR} è ${ESSID} convertita al nome della variabile che bash permette.
Codice 2.1: Funzioni di associazione pre/post |
preassociate() {
# Il codice seguente aggiunge due variabili di configurazione
# leap_user_ESSID e leap_pass_ESSID. Quando sono entrambe configurate per
# essere connesse a ESSID, viene eseguito lo script CISCO LEAP
local user pass
eval user=\"\$\{leap_user_${ESSIDVAR}\}\"
eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"
if [[ -n ${user} && -n ${pass} ]]; then
if [[ ! -x /opt/cisco/bin/leapscript ]]; then
eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils"
return 1
fi
einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\""
if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login Failed for ${user}"
return 1
fi
fi
return 0
}
postassociate() {
# Questa funzione viene utilizzata perlopiù per completezza. Attualmente
# non c'è mai stato bisogno di utilizzarla.
return 0
}
|
Nota: ${ESSID} e ${ESSIDVAR} non sono disponibili nelle funzioni predown() e postdown() |
Se si è sempre in movimento con il proprio computer, non sempre è disponibile un cavo ethernet o un access point. Inoltre, se un cavo di rete viene inserito o viene trovato un access point, si potrebbe desiderare che i propri servizi di rete funzionino automaticamente.
Di seguito vengono elencati alcuni strumenti utili alla gestione della rete.
Nota: Questo documento parla solo di ifplugd, ma ci sono alternative come netplug. netplug è un'alternativa a ifplugd molto leggera, ma dipende dal corretto funzionamento dei driver di rete del kernel, e molti driver purtroppo non lo fanno. |
ifplugd è un demone che avvia e chiude le interfacce quando si inserisce o rimuove un cavo ethernet. Può anche gestire la rilevazione associazioni agli Access Point o quando dei nuovi Access Point entrano nel raggio di copertura.
Codice 2.1: Installare ifplugd |
# emerge sys-apps/ifplugd
|
La configurazione di ifplugd è molto semplice. Il file di configurazione è /etc/conf.d/ifplugd. Eseguire man ifplugd per dettagli sulle variabili disponibili. Inoltre vedere /etc/conf.d/net.example per ulteriori esempi.
Codice 2.2: Configurazione d'esempio per ifplug |
(Sostituire eth0 con l'interfaccia da monitorare) ifplugd_eth0="..." (Per monitorare un'interfaccia wireless) ifplugd_eth0="--api-mode=wlan" |
In aggiunta alla gestione di connessioni di rete multiple, è possibile aggiungere uno strumento che facilita il funzionamento con molteplici server DNS e configurazioni; ciò è molto pratico se si riceve l'indirizzo IP tramite DHCP. Per installarlo, effettuare l'emerge di openresolv.
Codice 2.3: Installare openresolv |
# emerge openresolv
|
Vedere man resolvconf per saperne di più riguardo alle sue caratteristiche.
I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.