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

The Debian GNU/Linux FAQ
Capitolo 10 - Personalizzare la propria installazione di Debian GNU/Linux

10.1 Come posso assicurarmi che tutti i programmi usino lo stesso formato carta?

Si installi il pacchetto libpaperg che chiederà un formato carta predefinito esteso a tutto il sistema. Questa impostazione sarà mantenuta nel file /etc/papersize.

Gli utenti possono sovrascrivere l'impostazione del formato carta usando la variabile d'ambiente PAPERSIZE. Per dettagli, si veda la pagina di manuale papersize(5).

10.2 Come posso fornire accesso alle periferiche hardware senza compromettere la sicurezza?

Molti file di device nella directory /dev appartengono ad alcuni gruppi predefiniti. Per esempio, /dev/fd0 appartiene al gruppo floppy e /dev/dsp appartiene al gruppo audio.

Se si vuole che un certo utente abbia accesso ad uno di questi device, si aggiunga l'utente al gruppo a cui appartiene il device, cioè si faccia:

     adduser utente gruppo

In questo modo non si dovranno cambiare i permessi dei file sul device.

10.3 Come carico un font di console all'avvio nel modo Debian?

I pacchetti kbd e console-tools lo supportano, si modifichi il file /etc/kbd/config o /etc/console-tools/config.

10.4 Come posso configurare i default di un'applicazione del programma X11?

I programmi X di Debian installeranno le loro risorse per le applicazioni nella directory /etc/X11/app-defaults/. Se si vogliono personalizzare globalmente le applicazioni X, si mettano le proprie personalizzazioni in questi file. Sono marcati come file di configurazione, quindi il loro contenuto sarà preservato durante gli aggiornamenti.

10.5 Ogni distribuzione sembra avere un metodo di avvio differente. Parlatemi di quello di Debian.

Come tutti gli Unix, Debian si avvia eseguendo il programma init. Il file di configurazione per init (che è /etc/inittab) specifica che il primo script da eseguire dovrebbe essere /etc/init.d/rcS. Questo script esegue tutti gli script in /etc/rcS.d/ usando il comando source o generando un sottoprocesso, a seconda della loro estensione, per effettuare un'inizializzazione come verificare e montare i file system, caricare moduli, avviare i servizi di rete, impostare l'orologio ed effettuare altre inizializzazioni. Poi, per compatibilità, esegue anche i file (eccetto quelli con un '.' nel nome del file) dentro /etc/rc.boot/. Ogni script in quest'ultima directory è solitamente riservato all'uso da parte degli amministratori di sistema e usarli nei pacchetti è deprecabile.

Dopo aver completato il processo di avvio, init esegue tutti gli script di avvio dentro una directory specificata dal livello di esecuzione (runlevel) predefinito (questo runlevel è dato dalla voce id in /etc/inittab). Come la maggior parte degli Unix compatibili con il System V, Linux ha 7 runlevel:

0 (ferma il sistema),

1 (modalità singolo-utente),

2 fino a 5 (varie modalità multi-utente) e

6 (riavvia il sistema).

I sistemi Debian funzionano con id=2, che indica che il runlevel predefinito sarà '2' quando si entra nello stato di multi-utente, e che gli script in /etc/rc2.d/ verranno eseguiti.

Infatti, gli script in ognuna delle directory, /etc/rcN.d/ sono solo link simbolici agli script in /etc/init.d/. Comunque, i nomi dei file in ognuna delle directory /etc/rcN.d/ sono selezionati per indicare il modo in cui gli script in /etc/init.d/ verranno eseguiti. Specificatamente, prima di entrare in ogni runlevel, tutti gli script che iniziano con 'K' sono eseguiti; questi script uccidono i servizi. Poi vengono eseguiti tutti gli script che iniziano con 'S'; questi script avviano i servizi. Il numero a due cifre che segue la 'K' o la 'S' indica l'ordine in cui lo script sarà eseguito. Gli script con un numero minore sono eseguiti prima.

Questo approccio funziona perché tutti gli script dentro a /etc/init.d/ accettano un argomento che può essere 'start, 'stop', 'reload', 'restart' o 'force-reload' e svolgeranno poi il compito indicato dall'argomento. Questi script possono essere usati anche dopo che un sistema è stato avviato, per controllare vari processi.

Per esempio, con l'argomento 'reload' il comando

     /etc/init.d/sendmail reload

invia al demone sendmail un segnale di rileggere il suo file di configurazione.

10.6 Sembra che Debian non usi `rc.local` per personalizzare il processo di avvio; che facilitazioni vengono fornite?

Si supponga che un sistema necessiti di eseguire lo script foo all'avvio o all'ingresso di un particolare runlevel (System V). Allora l'amministratore di sistema dovrebbe:

Mettere lo script foo nella directory /etc/init.d/.

Eseguire il comando Debian update-rc.d con gli argomenti appropriati, per impostare i link tra le directory (specificate da riga di comando) rc?.d e /etc/init.d/foo. Qui, '?' è un numero da 0 a 6 e corrisponde ad ognuno dei runlevel System V.

Riavviare il sistema.

Il comando update-rc.d imposterà i link tra i file nelle directory rc?.d e lo script in /etc/init.d/. Ogni link inizierà con una 'S' o una 'K', seguita da un numero, seguito dal nome dello script. Gli script in /etc/rcN.d/ che iniziano con 'S' vengono eseguiti quando si entra nel runlevel N. Gli script che iniziano con 'K' sono eseguiti quando si lascia il runlevel N.

Si può, per esempio, fare in modo che lo script foo venga eseguito all'avvio, mettendolo in /etc/init.d/ ed installando i link con update-rc.d foo defaults 19. L'argomento 'defaults' fa riferimento ai runlevel predefiniti, che sono dal 2 al 5. L'argomento '19' assicura che foo sia chiamato prima di qualunque script contenente il numero 20 o superiore.

10.7 Come si occupa il sistema di manutenzione dei pacchetti dei pacchetti che contengono file di configurazione per altri pacchetti?

Alcuni utenti desiderano creare, per esempio, un nuovo server installando un gruppo di pacchetti Debian ed un pacchetto generato localmente che consiste di file di configurazione. Questa non è generalmente una buona idea, perché dpkg non conoscerà quei file di configurazione se sono in un pacchetto differente, e può scrivere configurazioni in conflitto quando uno dei paccheti del "gruppo" iniziale viene aggiornato.

Piuttosto, si crei un pacchetto locale che modifichi i file di configurazione del "gruppo" di pacchetti Debian che interessano. Poi dpkg e il resto del sistema di gestione pacchetti vedrà che i file sono stati modificati dal "sysadmin" locale e non cercherà di sovrascriverli quando quei pacchetti verranno aggiornati.

10.8 Come sovrascrivo un file installato da un pacchetto in modo che ne venga usata una versione differente?

Si supponga che l'amministratore o un utente locale desideri usare un programma "login-local" piuttosto del programma "login" fornito dal pacchetto login di Debian.

Non:

Si sovrascriva /bin/login con login-local.

Il sistema di manutenzione pacchetti non saprà di questo cambiamento e semplicemente sovrascriverà il proprio /bin/login personale ogni volta che login (o qualsiasi altro pacchetto che fornisce /bin/login) verrà installato o aggiornato.

Invece,

Si esegua:
```
     dpkg-divert --divert /bin/login.debian /bin/login
```
in modo che tutte le future installazioni del pacchetto login di Debian scrivano, al posto del file /bin/login, /bin/login.debian.

Poi si esegua:
```
     cp login-local /bin/login
```
per muovere il proprio programma al suo posto.

I dettagli sono forniti nella pagina di manuale dpkg-divert(8).

10.9 Come posso avere il mio pacchetto generato localmente nella lista dei pacchetti disponibili che il sistema di gestione dei pacchetti conosce?

Si esegua il comando:

     dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > my_Packages

dove:

BIN-DIR è la directory dove i file di archivio Debian (che solitamente hanno estensione ".deb") sono situati.

OVERRIDE_FILE è il file che viene modificato dal manutentore della distribuzione ed è solitamente situato su un archivio FTP Debian su indices/override.main.gz per i pacchetti Debian nella distribuzione "main". Può essere ignorato per pacchetti locali.

PATHPREFIX è una stringa opzionale che può precedere il file my_Packages. [NdT: precede il nome del pacchetto nel campo Filename del file my_Packages creato]

Una volta che si è creato il file my_Packages, lo si dica al sistema di manutenzione pacchetti usando il comando:

     dpkg --merge-avail my_Packages

Se si sta usando APT, si può anche aggiungere il deposito locale al proprio file sources.list(5).

10.10 Ad alcuni utenti piace mawk, ad altri piace gawk; ad alcuni piace vim, ad altri piace elvis; ad alcuni piace trn, ad altri piace tin; come supporta Debian le diversità?

Ci sono diversi casi in cui due pacchetti forniscono due versioni differenti di un programma, i quali forniscono entrambi le stesse funzionalità fondamentali. Gli utenti possono preferire l'uno rispetto all'altro per abitudine o perché l'interfaccia utente di un pacchetto è in qualche modo più piacevole di quella di un altro. Altri utenti sullo stesso sistema possono fare una scelta differente.

Debian usa un sistema di pacchetti "virtuali" per permettere agli amministratori di sistema di scegliere (o lasciare che gli utenti scelgano) i propri strumenti preferiti quando ce ne sono due o più che forniscono la stessa funzionalità di base e che ancora soddisfano i requisiti delle dipendenze senza specificare un particolare pacchetto.

Per esempio, potrebbero esistere due differenti versioni di lettori di news su un sistema. Il pacchetto del server delle news potrebbe 'raccomandare' che esistano alcuni lettori di news sul sistema, ma la scelta di tin o trn è lasciata all'utente. Ciò è realizzato avendo entrambi i pacchetti tin e trn che forniscono il pacchetto virtuale news-reader. Quale programma viene richiamato è determinato da un link che punta dal file con il nome del pacchetto virtuale /etc/alternatives/news-reader al file selezionato, p.e., /usr/bin/trn.

Un solo link è insufficiente per supportare pienamente l'uso di un programma alternativo; normalmente, le pagine di manuale e possibilmente anche altri file di supporto devono essere selezionati. Lo script Perl update-alternatives fornisce un mezzo per assicurarsi che tutti i file associati con uno specifico pacchetto siano selezionati come un default di sistema.

Per esempio, per verificare quale eseguibile fornisce 'x-window-manager', si esegua:

     update-alternatives --display x-window-manager

Se lo si vuole cambiare, si esegua:

     update-alternatives --config x-window-manager

E si seguano le istruzioni sullo schermo (sostanzialmente, si prema il numero vicino alla voce che si preferisce).

Se, per alcune ragioni, un pacchetto non si registra da solo come un window manager (si riporti il baco se c'è un errore) o se si usa un window manager dalla directory /usr/local, le selezioni sullo schermo non conterranno la propria voce preferita. Si può aggiornare il link attraverso opzioni da riga di comando, così:

     update-alternatives --install /usr/bin/x-window-manager \
       x-window-manager /usr/local/bin/wmaker-cvs 50

Il primo argomento dell'opzione '--install' è il link simbolico che punta a /etc/alternatives/NAME, dove NAME è il secondo argomento. Il terzo argomento è il programma al quale /etc/alternatives/NAME dovrebbe puntare e il quarto argomento è la priorità (un grande valore significa che l'alternativa sarà ottenuta più probabilmente automaticamente).

Per rimuovere un'alternativa che si è aggiunta si esegua semplicemente:

     update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs