[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ successivo ]

La guida Debian
Capitolo 2 - Nozioni fondamentali della Debian

Questo capitolo fornisce le informazioni fondamentali sul sistema debian per i non-sviluppatori. Per avere informazioni più autorevoli, vedere:

reperibili sotto Riferimenti, Sezione 15.1.

Se state cercando una qualsiasi risposta che li riguarda senza, però, tutti i loro dettagli,andate direttamente a Gestione dei pacchetti in Debian, Capitolo 6 o ad altri capitoli.

Questo capitolo è formato da documenti presi dalla "Debian FAQ", e profondamente riorganizzati, per permettere ad un qualsiasi amministratore di un sistema Debian di avere un solido punto di partenza.

2.1 Gli archivi Debian

2.1.1 Struttura della directory

Il software impacchettato per la debian, è disponibile in una delle numerose directory su ciascun Mirror Debian raggiungibili tramite FTP o HTTP.

Queste sono le directory presenti su ciascun mirror, sotto la directory /debian/:

/dists/:

Contiene le "distribuzioni" ed era il luogo canonico di accesso dei pacchetti disponibili nelle versioni rilasciate e pre-rilascio. Alcuni vecchi pacchetti, i files Contents-*.gz, ed i files Packages.gz sono ancora qui.

pool/:

Nuova locazione, che contiene fisicamente tutti i pacchetti, sia quelli della versione rilasciata, che quelli pre-rilascio.

tools/:

Utilità DOS per creare dischetti boot, partizionare il disco rigido, comprimere/decomprimere i file e lanciare Linux.

doc/:

La documentazione base, come le FAQ, le istruzioni per la notifica dei bachi, ecc.

indices/:

I file dei Manutentori, ed i file override.

project/:

In gran parte materiale solo per sviluppatori, tipo:

project/experimental/:

Pacchetti e strumenti ancora in via di sviluppo, in fase alfa. I normali utenti non dovrebbero utilizzare i pacchetti qui contenuti, che possono essere pericolosi persino per i più esperti.

project/orphaned/:

Pacchetti lasciati dai loro vecchi manutentori e tolti dalla distribuzione.

2.1.2 Le distribuzioni Debian

Di norma sono tre le distribuzioni contenute nella directory dists. Sono definite come la distribuzione stable, la testing e la unstable. Talvolta se ne aggiunge una quarta, la frozen. Ogni distribuzione viene definita con un collegamento simbolico alla directory reale, tramite un nome proprio nella directory dists.

2.1.3 La distribuzione stable

Le voci dei pacchetti per la distribuzione stable, Debian Sarge (3.1r0), vengono inserite nella directory stable (collegamento simbolico a sarge/):

Ora, in aggiunta alle locazioni sopra descritte, i nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10).

Lo stato attuale dei bachi della distribuzione stable è riportato in sulla pagina Web Problemi di Stable.

2.1.4 La distribuzione testing

Le voci dei pacchetti per la distribuzione testing, Debian Etch, sono registrate nella directory testing (collegamento simbolico a etch) dopo aver subito un periodo di prova in unstable. Ora, in aggiunta alle locazioni sopra descritte, i nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10). La directory testing ha delle sottodirectory, main, contrib e non-free, che hanno le stesse funzioni che in stable.

I pacchetti devono essere sincronizzati in tutte le architetture per le quali sono stati compilati e non devono mostrare dipendenze tali da renderli non installabili; devono inoltre avere meno bachi release-critical delle versioni in unstable. In questo modo si auspica che testing sia sempre molto vicina ad essere candidata al rilascio. Per maggiori dettagli sul meccanismo che regola la distribuzione vedere http://www.debian.org/devel/testing.

Lo stato aggiornato della distribuzione testing è riportato presso:

2.1.5 La distribuzione unstable

Le voci dei pacchetti della distribuzione unstable, sempre con nome in codice "Sid", sono registrate nella directory unstable (collegamento simbolico a sid/) dopo essere state caricate nell'archivio Debian, rimanendovi finchè non vengono spostate in testing. I nuovi pacchetti sono fisicamente localizzati nella directory pool (La directory pool, Sezione 2.1.10). La directory unstable ha delle sottodirectory, main, contrib e non-free, che hanno le stesse funzioni che in stable.

La distribuzione unstable contiene le immagini più recenti del sistema in fase di sviluppo. Gli utenti possono liberamente usare e testare questi pacchetti, ma vengono avvisati del loro precario stato di preparazione. Il vantaggio di usare unstable è quello di essere sempre al massimo dell'aggiornamento del progetto Debian relativo al software—siate però pronti a raccogliere i pezzi se qualcosa va storto.

Lo stato aggiornato della distribuzione unstable è riportato presso la pagina Web Unstable Problems.

2.1.6 La distribuzione frozen

Una volta che la distribuzione testing è sufficientemente matura, diventa frozen; ciò significa che nessun nuovo codice viene più accettato, solo eliminazioni di bachi, se necessari. In aggiunta un nuovo albero testing viene creato nella directory dists, con un nuovo nome. La distribuzione frozen passa attraverso un ciclo di test (chiamato appunto "test cycles") di qualche mese caratterizzato da aggiornamenti intermittenti ed importanti stabilizzazioni.

Viene tenuto un registro dei bug della distribuzione frozen che possono impedire il rilascio di un pacchetto o di tutta la distribuzione. Una volta che il conteggio dei bug scende al di sotto di una valore massimo prestabilito, la distribuzione frozen diventa stable e viene rilasciata. La precedente distribuzione stable diventa obsoleta (e finisce in archivio).

2.1.7 Codice dei nomi della distribuzioni Debian

I nomi delle directory localizzate fisicamente nella directory dists, come sarge e etch, sono semplicemente dei nomi in codice. Quando una distribuzione Debian è nella fase di sviluppo le viene assegnato un nome in codice e non un numero di versione. Lo scopo di questi nomi è di rendere il mirroring delle distribuzioni Debian più semplice (se, ad esempio, una directory reale come unstable cambiasse improvvisamente di nome in stable, una gran quantità di programmi dovrebbe essere nuovamente scaricata senza motivo).

Attualmente stable è un collegamento simbolico a sarge e testing è un collegamento simbolico a etch. Ciò significa che Sarge è la distribuzione attualmente stable e Etch è l'attuale testing.

unstable è un collegamento simbolico permanente a sid, dato che Sid è sempre la distribuzione unstable.

2.1.8 Nomi in codice usati in passato

I nomi in codice che sono già stati utilizzati sono: "Buzz" per la release 1.1, "Rex" per la 1.2, "Bo" per la 1.3.x, "Hamm" per la 2.0, "Slink" per la 2.1, "Potato" per la 2.2, "Woody" per la 3.0 e "Sarge" per la 3.1.

2.1.9 Da dove vengono i nomi delle distribuzioni?

Finora sono stati presi dai nomi dei personaggi del film Toy Story della Pixar.

2.1.10 La directory pool

Storicamente i pacchetti erano contenuti nella subdirectory di dists corrispondente alla distribuzione di cui facevano parte. Questo portò a vari problemi, tipo un grosso consumo di banda di connessione dei mirror ogni volta che venivano fatti dei cambiamenti di grossa entità.

Ora i pacchetti vengono tenuti in una grossa "vasca" (pool), strutturata in accordo con il nome del pacchetto sorgente. Per rendere il tutto maneggevole, la vasca è suddivisa in sezioni (main, contrib e non-free) e per la prima lettera del nome del pacchetto sorgente. Queste directory contengono svariati file: binari per ciascuna architettura ed i pacchetti sorgente da cui i pacchetti binari sono stati generati.

E' possibile sapere dove ciascun pacchetto è situato eseguendo un comando tipo: apt-cache showsrc nomemiopacchetto ed andando a leggere la riga "Directory:". Per esempio, i pacchetti apache sono immagazzinati in pool/main/a/apache/. Essendo molteplici, i pacchetti lib* vengono trattati in maniera particolare: per esempio, i pacchetti libpaper sono immagazzinati in pool/main/libp/libpaper/.

Le directory dists vengono ancora utilizzate per i file indice usati da programmi tipo apt. Inoltre, al momento attuale le vecchie distribuzioni non sono state convertite ad usare le vasche, per cui si troveranno i percorsi contenenti distribuzioni tipo potato o woody nel campo "Filename" dell'intestazione.

Di norma non avete da preoccuparvi di ciò, poichè il nuovo apt e probabilmente il vecchio dpkg-ftp sono in grado di gestire la cosa senza problemi. Se volete maggiori informazioni, andate a vedere RFC: implementazione dei pool dei pacchetti.

2.1.11 Alcune note storiche su Sid

Quando il Sid attuale non esisteva, l'organizzazione dell'archivio Debian aveva un problema principale: l'assunto che quando un'architettura veniva creata nell'attuale unstable, sarebbe stata rilasciata quando la distribuzione diventava la nuova stable. Però per molte architetture questo non era il caso, con il risultato che quelle directory dovevano essere mosse al momento del rilascio. Fatto poco pratico, poichè lo spostamento avrebbe fagocitato grosse quantità di banda.

Gli amministratori dell'archivio hanno evitato questo problema per pacchetti anni piazzando i binari delle architetture ancora non rilasciate in una directory speciale chiamata sid. Al momento del loro rilascio esisteva un collegamento dall'architettura a quel momento stable a sid e da quel momento in poi essa veniva creata all'interno dell'albero unstable, come di norma. Tutto ciò era motivo di confusione per gli utenti.

Con l'avvento della vasca dei pacchetti (vedere La directory pool, Sezione 2.1.10) durante lo sviluppo della distribuzione Woody i pacchetti binari cominciarono ad essere immagazzinati in una locazione canonica nella vasca, indipendentemente dalla distribuzione; in tal modo il rilascio di una distribuzione non determina più la grossa dispersione di banda sui mirror (c'è, ovviamente, un notevole consumo, ma graduale, di banda durante la fase di sviluppo).

2.1.12 Pacchetti caricati in incoming

I pacchetti che vengono caricati nell'archivio vengono dapprima immagazzinati in http://incoming.debian.org/ prima di accertarsi che provengano realmente da uno sviluppatore Debian (e vengono piazzati nella sottodirectory DELAYED in caso di Non-Maintainer Upload (NMU)). Una volta al giorno, vengono mossi da incoming ad unstable.

In caso di emergenza, potreste voler installare i pacchetti da qui, prima che raggiungano unstable.

2.1.13 Recuperare un vecchio pacchetto

Mentre le distribuzioni Debian più recenti vengono tenute nella directory debian su ciascun Mirror Debian, gli archivi per le distribuzioni più vecchie, tipo Scollegamento , sono tenuti su http://archive.debian.org/ o sotto la directory debian-archive di ciascun mirror Debian.

I vecchi pacchetti testing ed unstable sono localizzati in http://snapshot.debian.net/.

2.1.14 Sezioni per architettura

All'interno di ciascun albero directory principale (dists/stable/main, dists/stable/contrib, dists/stable/non-free dists/unstable/main, etc.), le voci dei pacchetti binari risiedono all'interno di sottodirectory i cui nomi indicano l'architettura per la quale sono stati compilati.

Ricordate che i reali pacchetti binari per testing ed unstable non risiedono più in queste directory, ma al livello principale della directory pool. I file elenco (Packages e Packages.gz) sono stati comunque mantenuti, per compatibilità con il vecchio sistema.

Per sapere quali architetture sono al momento supportate, leggetevi le Note di Rilascio per ciascuna distribuzione. Possono essere trovate presso i siti delle Note di Rilascio per stable e testing.

2.1.15 Il codice sorgente

Il codice sorgente è disponibile per ogni cosa contenuta nel sistema Debian. In più, i termini di licenza della maggior parte dei programmi richiedono che il codice venga distribuito insieme ai programmi, o che un'offerta di fornire il codice li accompagni.

Di regola il codice viene reperito nelle directory source, che sono in parallelo a tutte le directory dei binari architettura-specifiche, o più di recente alla directory pool (vedere La directory pool, Sezione 2.1.10). Per scaricare il codice sorgente senza la necessità di essere addentro alla struttura dell'archivio Debian, provate un comando tipo apt-get source nomemiopacchetto.

Alcuni pacchetti, in particolare pine, sono disponibili solamente come sorgenti, a causa delle limitazioni delle licenze. (Recentemente è stato fornito il pacchetto pine-tracker per facilitare l'installazione di Pine). Le procedure descritte in Portare un pacchetto nel sistema stable, Sezione 6.4.10 e Creare pacchetti debian, Sezione 13.10 dovrebbero fornire tutto il necessario per compilare un pacchetto manualmente.

Il codice sorgente potrebbe non essere disponibile, invece, per i pacchetti delle directory contrib e non-free, che formalmente non fanno parte del sistema Debian.

2.2 Il sistema di gestione dei pacchetti Debian

2.2.1 Panoramica dei pacchetti Debian

Normalmente i pacchetti contengono tutti i file necessari all'implementazione di una serie di comandi o di funzionalità. Esistono due tipi di pacchetti:

L'installazione del software attraverso il sistema dei pacchetti utilizza delle "dipendenze", che sono state dichiarate dal responsabile (manutentore) del pacchetto. Le dipendenze vengono descritte nel file control, associato a ciascun pacchetto. Ad esempio, il pacchetto contenente il compilatore GNU C (gcc) "dipende" dal pacchetto binutils che include il collegamento e l'assembler. Se si prova ad installare gcc senza aver prima installato binutils, il sistema di gestione dei pacchetti (dpkg) invierà un messaggio di errore riguardo alla necessità di avere anche binutils e bloccherà l'installazione di gcc. (Questo comportamento può comunque essere scavalcato dall'utente tenace, vedere al riguardo dpkg(8).) Per dettagli aggiuntivi, vedere più sotto in Dipendenze dei pacchetti, Sezione 2.2.8.

Gli strumenti Debian per la gestione dei pacchetti possono essere usati per:

2.2.2 Il formato dei pacchetti Debian

Un "pacchetto" Debian, od un file dell'archivio Debian contiene gli eseguibili,le librerie e tutta la documentazione associata ad un gruppo o suite di programmi correlati. I file dell'archivio Debian, di norma, hanno il suffisso .deb. [1]

I dettagli dei pacchetti binari Debian sono descritti nella pagina di manuale deb(5). Il loro formato interno è soggetto a cambiamenti (tra una versione maggiore e l'altra di Debian), per cui leggete sempre dpkg-deb(1) prima di manipolare i.deb file.

Almeno fino a Sarge, gli archivi Debian sono sempre stati manipolabili anche dai normali comandi Unix, tipo ar e tar, anche quando i comandi dpkg non erano disponibili.

2.2.3 Convenzioni nei nomi dei pacchetti Debian

Il nome di un pacchetto Debian segue la convenzione seguente: 

     foo_ver-rev_arch.deb

Dove in genere foo sta per il nome del pacchetto. ver è la versione del programma originale, rev è il numero di revisione Debian e arch è l'architettura per la quale il pacchetto è stato compilato. I file vengono facilmente rinominati, naturalmente. Potete scoprire quale pacchetto è realmente contenuto in un dato file di none filename dando il comando seguente: 

     dpkg --info filename

Il numero di revisione Debian viene specificato dallo sviluppatore Debian o da chiunque compili il pacchetto. Un cambio nel numero di revisione in genere indica che qualche aspetto nel pacchetto è cambiato.

2.2.4 Mantenimento della configurazione locale

I file che sono considerati modificabili dall'amministratore locale si trovano in /etc. Le linee guida Debian prescrivono che tutte le modifiche ai file localmente configurabili vengano mantenute attraverso gli aggiornamenti dei pacchetti.

Se una versione predefinita di un file localmente configurabile viene fornita con il pacchetto stesso, allora il file viene etichettato come un "conffile". Il sistema di gestione dei pacchetti non aggiorna i conffile che sono stati modificati dall'amministratore dopo l'ultima installazione del dato pacchetto senza prima aver chiesto il permesso dell'amministratore stesso. D'altro canto, se il conffile non è stato modificato, allora verrà aggiornato insieme al resto del pacchetto. Ciò è sempre auspicabile, così è vantaggiorso minimizzare le modifiche ai conffile.

Per elencare i conffile appartenenti ad un dato pacchetto, lanciare: 

     dpkg --status package

L'elenco segue la riga "Confflies".

Per maggiori informazioni sui conffile potete leggere la sezione del Debian Policy Manual intitolata "Configuration files" (Vedere Riferimenti, Sezione 15.1).

2.2.5 Script di gestione Debian

Gli script di gestione Debian sono degli script eseguibili che vengono lanciati automaticamente prima o dopo l'installazione di un pacchetto. Insieme ad un file chiamato control, tutti questi file fanno parte della sezione "control" di un file Debian.

I singoli file sono:

preinst

Questo script viene eseguito prima che il pacchetto venga estratto dal file Debian (.deb). Molti script "preinst" interrompono i servizi per i pacchetti che devono essere aggiornati fino a che la loro installazione o aggiornamento non sono completati (a seguire dell'esecuzione con successo dello script "postinst").

postinst

Questo script tipicamente completa ogni configurazione richiesta da un pacchetto dopo che è stato estratto dal suo file Debian (.deb). Spesso gli script "postinst" richiedono all'utente determinate azioni e/o lo avvertono che, qualora accettasse le impostazioni di base, deve ricordarsi di riconfigurare il pacchetto se la situazione lo richiede. Molti script "postinst", poi, eseguono tutti i comandi necessari a lanciare o far ripartire i servizi, dopo che il pacchetto è stato aggiornato o installato.

prerm

Questo script ferma tutti i demoni associati con un pacchetto. Viene eseguito prima della rimozione di file associati ad un determinato pacchetto.

postrm

Modifica i collegamenti od altri file correlati ad un pacchetto e/o rimuove i files creati da esso.(Vedere anche Pacchetti Virtuali, Sezione 2.2.7.)

Tutti i file di controllo possono essere localizzati nella directory /var/lib/dpkg/info. I file correlati con il pacchetto foo iniziano, appunto, con il nome "foo" ed hanno le estensioni "preinst", "postinst", ecc. a seconda della funzione. Il file foo.list nella stessa directory elenca tutti i file installati con il pacchetto foo. (Notate che la localizzazione di questi file è interna a dpkg e può essere soggetta a modifiche.)

2.2.6 Priorità dei pacchetti

Ad ogni pacchetto viene assegnata una priorità dai responsabili della distribuzione, come aiuto al sistema di gestione dei pacchetti. Le priorità sono:

Notate le differenze fra "Priority: required", "Section: base" ed "Essential: yes" nella descrizione dei pacchetti. "Section: base" significa che il pacchetto viene installato prima tutti su un nuovo sistema. Molti dei pacchetti in "Section: base" hanno "Priority: required" o almenot "Priority: important" e molti di loro sono etichettati con "Essential: yes". "Essential: yes" significa che il pacchetto richiede di specificare un'ulteriore opzione force al sistema di gestione dei pacchetti, tipo dpkg quando viene rimosso dal sistema. Per esempio, libc6, mawk e makedev sono "Priority: required" and "Section: base" ma non "Essential: yes".

2.2.7 Pacchetti Virtuali

Il termine pacchetto virtuale è un termine generico che si applica a tutti i pacchetti di un gruppo che provvede alla medesima funzione. Per esempio, i programmi tin e trn sono entrambi dei newsreader, in grado di soddisfare qualsiasi dipendenza di un programma che richieda un newsreader su un sistema, al fine di funzionare correttamente. Entrambi, quindi, si dice che provvedano il "pacchetto virtuale" definito news-reader.

Allo stesso modo exim exim4, sendmail e postfix forniscono la funzionalità di un agente di trasporto posta (mail transport agent). Perciò, provvedono al pacchetto virtuale mail transport agent. Se uno di loro è installato, qualsiasi programma che dipenda dall'installazione di un agente di trasporto posta vedrà le proprie dipendenze soddisfatte dall'esistenza di questo pacchetto virtuale.

La Debian ha un meccanismo tale che, se più di un pacchetto che fornisce lo stesso pacchetto virtuale è installato, l'amministratore di sistema è in grado di sceglierne uno come pacchetto preferito. Il comando che viene chiamato in causa èupdate-alternatives e verrà descritto in dettaglio oltre, in Comandi alternativi, Sezione 6.5.3.

2.2.8 Dipendenze dei pacchetti

Il sistema dei pacchetti Debian ha una serie di dipendenze che sono utilizzate per esprimere il fatto che un pacchetto, per funzionare, o per funzionare meglio, ha bisogno dell'installazione di un altro pacchetto:

Informazioni più dettagliate possono essere trovate nel Packaging Manual e nel Policy Manual.

Notate che dselect ha un controllo molto più raffinato sui pacchetti contrassegnati da Raccomanda e Suggerisce rispetto ad apt-get, che prende semplicemente tutti i pacchetti specificati da Dipende e lascia quelli indicati da Raccomanda e Suggerisce. Entrambi i programmi nelle forme più moderne utilizzano come back-end APT.

2.2.9 Cosa significa "Pre-Depends"

dpkg conigura sempre un pacchetto da cui ne Dipende un altro prima di configurare quast'ultimo. Tuttavia, dpkg in genere spacchetterà il file seguendo un ordine arbitrario, indipendentemente dalle dipendenze. (Spacchettare il file vuol dire che estrarre i file e metterli al posto giusto). Se, però un pacchetto Pre-Dipende da un altro, allora quast'ultimo veràà spacchettato e configurato prima che quello che ne Pre-Dipende sia anche solo spacchettato. [2] L'uso di questo tipo di dipendenza è ridotto al minimo.

2.2.10 Lo stato dei pacchetti

Lo stato di un pacchetto può essere "sconosciuto", "installa", "rimuovi", "elimina" o "mantieni". Queste etichette "voglio", indicano il volere dell'utente riguardo ad un pacchetto (come indicato dalle azioni dell'utente nella sezione "Scegli" di dselect o dal richiamo diretto dell'utente di dpkg).

Il loro significato è il seguente:

2.2.11 Evitare l'aggiornamento dei pacchetti

Esistono due modi per evitare l'aggiornamento di un pacchetto, tramite dpkg o, da Woody in poi, tramite APT.

Con dpkg, dovete solo esportare la lista dei pacchetti selezionati con: 

     dpkg --get-selections > selections.txt

Dopodichè modificate il file risultante selections.txt, cambiando la riga che contiene il pacchetto da mantenere, tipo libc6, da: 

     libc6                       install

a: 

     libc6                       hold

Salvate il file e ricaricatelo nel database di dpkg con: 

     dpkg --set-selections < selections.txt

Se conoscete il nome del pacchetto da mantenere, basta eseguire: 

     echo libc6 hold | dpkg --set-selections

Questo processo evita l'aggiornamento dei pacchetti al momento dell'installazione di ciascun file.

Lo stesso risultato si ottiene tramite dselect. Basta accedere alla schermata [S]cegli, trovare il pacchetto da mantenere nello stato attuale e premere il tasto `=' (o `H'). I cambiamenti saranno effettivi non appena lasciata la schermata [S]cegli.

Il sistema APT nella nuova distribuzione Woody ha un meccanismo alternativo per mantenere i pacchetti durante il processo di raccolta di un archivio, utilizzando la Pin-Priority. Vedere la pagina di manuale apt_preferences(5), l'http://www.debian.org/doc/manuals/apt-howto/ o il pacchetto apt-howto.

2.2.12 Pacchetti sorgente

I pacchetti sorgente vengono distribuiti in una directory chiamata source e possono essere scaricati o manualmente, oppure tramite il comando 

     apt-get source foo

(vedere apt-get(8) la pagina man su come impostare APT all'uopo).

2.2.13 Compilare pacchetti binari dai sorgenti

Per un dato pacchetto foo avete bisogno di tutti i foo_*.dsc, foo_*.tar.gz e foo_*.diff.gz (nota bene: non esiste nessun .diff.gz per un pacchetto Debian nativo).

Una volta presi, se avete installato il pacchetto dpkg-dev il seguente comando: 

     $ dpkg-source -x foo_version-revision.dsc

estrarrà il pacchetto in una directory denominata foo-version.

Date i seguenti comandi per compilare il pacchetto binario: 

     $ cd foo-versione
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

poi 

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

per installarlo. Vedere Portare un pacchetto nel sistema stable, Sezione 6.4.10.

2.2.14 Creare nuovi pacchetti Debian

Per maggiori dettagli al riguardo, leggete la New Maintainers' Guide, reperibile nel pacchetto maint-guide oppure presso http://www.debian.org/doc/manuals/maint-guide/.

2.3 Aggiornare un sistema Debian

Uno degli scopi della Debian è di fornire un sentiero solido di ed un processo sicuro di aggiornamento. Il sistema di gestione dei pacchetti avverete l'amministratore delle modifiche importanti e talvolta gli chiede di prendere delle decisioni. Dovreste leggere anche le Note di Rilascio; vengono fornite con tutti i CD Debian e sono disponibili sul WWW presso http://www.debian.org/releases/stable/releasenotes oppure http://www.debian.org/releases/testing/releasenotes.

Una guida pratica viene fornita in Gestione dei pacchetti in Debian, Capitolo 6. Questa sezione fornisce una panoramica generale, cominciando con gli strumenti di gestione dei pacchetti.

2.3.1 dpkg

E' il programma principale per la manipolazione dei pacchetti. Per ulteriori informazioni, leggere la pagina di manuale dpkg(8).

dpkg è fornito con parecchi programmi supplementari di base.

dpkg-ftp e dpkg-mountable sono stati resi obsoleti dall'introduzione del sistema APT.

2.3.2 APT

APT (Advanced Packaging Tool) è un'interfaccia avanzata per il sistema Debian di gestione dei pacchetti e consiste di vari programmi i cui nomi iniziano tipicamente con "apt-". apt-get, apt-cache e apt-cdrom sono gli strumenti da riga di comando per maneggiare i pacchetti. Funzionano anche come programmi backend per l'utente di altri strumenti, come dselect ed aptitude.

Per maggiori informazioni, installare apt e leggere apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) (Woody), e /usr/share/doc/apt/guide.html/index.html.

Esistono fonti di informazione alternative, come APT HOWTO. Può essere installato tramite apt-howto in /usr/share/doc/Debian/apt-howto/.

apt-get upgrade e apt-get dist-upgrade prendono solo i pacchetti elencati sotto "Dipende", mentre lasciano quelli sotto "Raccomanda" e "Suggerisce". Per evitare ciò, usate dselect.

2.3.3 dselect

Questo programma rappresenta un'interfaccia utente basata su menu al sistema di gestione dei pacchetti. E' particolarmente utile per prime installazioni ed aggiornamenti su larga scala. Vedere dselect, Sezione 6.2.4.

Per ulteriori informazioni, installare install-doc e leggere /usr/share/doc/install-doc/dselect-beginner.en.html oppure Documentazione per dselect per Principianti.

2.3.4 Aggiornare un sistema in funzione

Il kernel (filesystem) in Debian supporta la sostituzione dei file anche mentre sono in uso. Quando i pacchetti vengono aggiornati, tutti i servizi forniti da essi vengono riavviati se sono configurati per girare nel runlevel corrente. Il sistema Debian non ha bisogno della modalità singolo utente per aggiornare un sistema in funzione.

2.3.5 File .deb scaricati e tenuti in cache

Se avete scaricato i pacchetti nel vostro disco rigido (cosa assolutamente non necessaria, vedere sopra per la descrizione di dpkg-ftp o di APT), dopo l'installazione dei pacchetti potete rimuoverli dal vostro sistema.

Se si usa APT, i file vengono tenuti nella directory /var/cache/apt/archives. Potete cancellarli dopo l'installazione (apt-get clean), oppure copiarli sulla stessa directory /var/cache/apt/archives di un'altra macchina, per evitare un nuovo download durante la successiva installazione.

2.3.6 Tenere una registrazione dell'aggiornamento

dpkg mantiene una registrazione dei pacchetti scompattati, configurati, rimossi e/o eliminati, ma (al momento) non tiene nessuna registrazione dell'attività scritta su terminale durante tali manipolazioni.

Il metodo più semplice per aggirare questo impedimento è di lanciare una qualsiasi sessione di dpkg, dselect apt-get, ecc. all'interno del programma script(1).

2.4 La sequenza di boot della Debian

2.4.1 Il programma init

Come ogni buon appartenente alla famiglia degli Unix, Debian esegue il boot eseguendo il programma init. Il file di configurazione di init (che è /etc/inittab) specifica che il primo script da eseguire deve essere /etc/init.d/rcS.

Quello che accade poi dipende se è installato il pacchetto sysv-rc oppure file-rc. Quanto segue assume che sia installato sysv-rc. (file-rc il proprio script /etc/init.d/rcS ed usa un file invece che collegamenti simbolici nelle directory rc per controllare quali servizi siano stati avviati ed in quali runlevel.)

Il file /etc/init.d/rcS del pacchetto sysv-rc lancia tutti gli script in /etc/rcS.d/ per eseguire l'inizializzazione, tipo controllo e montaggio dei filesystem, caricamento dei moduli, lancio dei servizi di rete, impostazione dell'orologio, e così via. Poi, per compatibilità, lancia tutti i file (tranne quelli con `.' nel filename) localizzati in /etc/rc.boot/. Quest'ultima è riservata all'amministratore di sistema, ed il suo utilizzo è deprecato. Vedere Inizializzazione del sistema, Sezione 9.1 e System run levels and init.d scripts nel Debian Policy Manual per maggiori informazioni.

Debian non usa una directory rc.local in stile BSD.

2.4.2 I Runlevel

Dopo il completamento del processo di boot, init lancia tutti i servizi configurati per girare nel runlevel predefinito. Questo è definito dalla riga per id in /etc/inittab. Debian arriva con id=2.

Debian usa i seguenti runlevel:

I runlevel 7, 8, e 9 possono essere utilizzati, ma le loro directory rc non vengono popolate quando i pacchetti vengono installati.

Scambiate i runlevel mediante il comando telinit.

Quando si entra in un runlevel tutti gli script in /etc/rcrunlevel.d/ vengono eseguiti. La prima lettera del nome determina il modo in cui lo script viene lanciato: quelli che iniziano con K vengono lanciati con l'argomento stop. Quelli che iniziano per S vengono lanciati con l'argomento start. Gli script vengono eseguiti in ordine alfabetico; per cui quelli "stop" vengono lanciati prima di quelli "start" e i numeri a due cifre che seguono K o S determinano l'ordine in cui venono eseguiti.

Gli script in /etc/rcrunlevel.d sono infatti semplici collegamenti simbolici agli script in /etc/init.d/. Essi accettano anche argomenti tipo "restart" e "force-reload"; questi ultimi metodi possono essere utilizzati dopo che un sistema è stato avviato per riavviare i servizi o forzarli a ricaricare i loro file di configurazione.

Per esempio: 

     # /etc/init.d/exim4 reload

2.4.3 Personalizzare i runlevel

La personalizzazione dei runlevel è un compito avanzato di amministrazione di sistema. Il suggerimento seguente vale per gran parte dei servizi.

Per abilitare il servizio service nel runlevel R create il collegamento simbolico /etc/rcR.d/Sxyservice con obiettivo ../init.d/service. Il numero di sequenza xy dovrebbe essere quello che è stato assegnato al servizio quando il pacchetto è stato installato.

Per disabilitare il servizio, rinominate il the collegamento simbolico in maniera che il nome inizi con K invece che con S ed il suo numero di sequenza sia 100 meno xy.

E' conveniente usare un editor di runlevel, come sysv-rc-conf o ksysv per questi scopi.

E' possibile cancellare il collegamento simbolico S ad un servizio in una data directory di un dato runlevel invece di rinominarlo. Ciò non disabilita il servizio, ma lo lascia in uno stato "fluttuante", finchè il sistema di inizio sysv-rc è interessato: al cambio di runlevel il servizio non sarà nè lanciato nè fermato, ma verrà lasciato così com'è, che stia girando o no. Notate comunque che un servizio lasciato in uno stato tale verrà lanciato se il pacchetto corrispondente verrà aggiornato, che girasse o meno prima dell'aggiornamento. Questo è un limite noto del sistema Debian attuale. Notate anche che dovreste mantenere i collegamenti simbolici K di un servizio nei runlevel 0 e 6. Se cancellate tutti i collegamenti simbolici di un servizio, allora durante un aggiornamento il pacchetto corrispodente ripristinerà tutti i collegamenti simbolici al loro stato predefinito iniziale.

Not è consigliabile modificare i collegamenti simbolici in /etc/rcS.d/.

2.5 Supportare le differenze

Debian offre parecchie opportunità per soddisfare le esigenze (e i desideri) degli amministratori di sistema, senza per questo renderlo inutilizzabile.

Tutti i file in /usr/local/ appartengono all'amministratore di sistema e Debian non li toccherà. Gran parte dei file in /etc sono conffiles e Debian non li sovrascriverà in caso di aggiornamento a meno che l'amministratore non lo richieda espressamente.

2.6 Internazionalizzazione

Il sistema Debian è internazionalizzato e fornisce il supporto per la visualizzazione e la scrittura dei caratteri in molte lingue, sia da console che sotto X. Molti documenti, pagine di manuali e messaggi di sistema sono stati tradotti in numero sempre crescente di lingue. Durante l'installazione Debian chiede all'utente di scegliere la lingua di installazione (e talvolta una variante locale della stessa).

Se il vostro sistema non supporta tutte le caratteristiche della lingua di cui avete bisogno, o se dovete cambiare la lingua od installare una diversa tastiera che supporti la vostra lingua, andate a leggere Localizzazione (l10n), Sezione 9.7.

2.7 Debian ed il kernel

Vedere Il kernel Linux su Debian, Capitolo 7.

2.7.1 Compilare un kernel da un sorgente non-Debian

Bisogna comprendere le linee guida Debian nei confronti degli header.

Le librerie C Debian sono compilate con le versioni stabili più recenti degli header del kernel.

Ad esempio, le versione Debian-1.2 usava la versione 5.4.13 degli header. Questa pratica è in contrasto con i pacchetti sorgente del kernel distribuiti in tutti gli archivi Linux FTP, pacchetti che usano versioni persino più recenti degli header. Gli header distribuiti con i sorgenti del kernel sono localizzati in /usr/include/linux/include/.

Se avete bisogno di compilare un programma con header più recenti di quelli di quelli forniti da libc6-dev, quando compilate dovete aggiungere alla riga di comando -I/usr/src/linux/include/. Un problema del genere è uscito, per esempio, quando si è creato il pacchetto del demone automounter (amd). Quando i nuovi kernel cambiavano alcune istruzioni relative al NFS, amd aveva necessità di esserne al corrente. Ciò ha richiesto l'inclusione degli header più recenti.

2.7.2 Gli strumenti per compilare un kernel personalizzato.

Gli utenti che desiderano (o devono) compilare un kernel personalizzato, sono incoraggiati a scaricare il pacchetto kernel-package. Il pacchetto contiene lo script per compilare il pacchetto del kernel e fornisce le capacità di creare un pacchetto Debian kernel-image, semplicemente dando il comando 

     # make-kpkg kernel_image

dalla directory principale del kernel sorgente. L'aiuto è disponibile dando il comando 

     # make-kpkg --help

o tramite la pagina di manuale make-kpkg(1) e Il kernel Linux su Debian, Capitolo 7.

L'utente deve scaricarsi a parte il sorgente per il kernel, sia esso il più recente o quello di scelta, dall'archivio Linux preferito, a meno che un pacchetto kernel-source-version non sia disponibile (dove version sta per la versione del kernel). Lo script di boot Debian initrd richiede una speciale patch del kernel, chiamata initrd; vedere http://bugs.debian.org/149236.

Le istruzioni dettagliate per usare il pacchetto kernel-package sono fornite nel file /usr/share/doc/kernel-package/README.gz.

2.7.3 Funzioni speciali per trattare con i moduli

Il pacchetto Debian modconf fornisce uno script di shell (/usr/sbin/modconf) che può essere utilizzato per personalizzare la configurazione dei moduli. Lo script presenta un'interfaccia a menu, chiedendo all'utente particolari circa i device drivers caricabili presenti sul proprio sistema. La risposte vengono utilizzate per personalizzare il file /etc/modules.conf (che elenca alias ed altri argomenti che devono essere utilizzati insieme ai vari moduli), tramite i file in /etc/modutils/, e /etc/modules (che elencano i moduli che devono essere caricati al boot).

Così come i (nuovi) file Configure.help ora disponibili per aiutare nella compilazione di kernel personalizzati, il pacchetto modconf arriva con tutta una serie di file di aiuto (in /usr/share/modconf/) che forniscono informazioni dettagliate sugli argomenti appropriati da dare a ciascun modulo. Vedere Kernel 2.4 modulare, Sezione 7.2 per gli esempi.

2.7.4 Disinstallare un vecchio pacchetto kernel

Si, lo script kernel-image-NNN.prerm controlla se il kernel attualmente in uso è lo stesso che state tentando di disinstallare. Perciò potete rimuovere pacchetti kernel che non volete più tramite il comando: 

     # dpkg --purge --force-remove-essential kernel-image-NNN

(sostituite NNN con la versione ed il numero di revisione del vostro kernel, naturalmente)

[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ successivo ]

La guida Debian

CVS, gio gen 18 11:52:32 UTC 2007

Osamu Aoki osamu#at#debian.org
Traduzione italiana: Davide Di Lazzaro mc0315#at#mclink.it
Autori, Sezione A.1