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


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


11.1 Come ci si può assicurare che tutti i programmi usino lo stesso formato per la carta?

Si installi il pacchetto libpaper1 che chiederà il formato carta predefinito per tutto il sistema. Questa impostazione sarà memorizzata nel file /etc/papersize.

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


11.2 Come si può fornire accesso alle periferiche hardware senza compromettere la sicurezza?

Molti file di device nella directory /dev appartengono a 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, aggiungere l'utente al gruppo a cui appartiene il device, usare cioè:

     adduser utente gruppo

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

Se lo si fa dall'interno di una shell utente o di un ambiente con interfaccia grafica si deve fare il logout e nuovamente il login per poter diventare un membro effettivo del gruppo specificato. Per controllare a quali gruppi si appartiene eseguire groups.

Si noti che, a partire dall'introduzione di udev, se si cambiano i permessi di una periferica hardware questi potrebbero essere modificati all'avvio per alcuni device; se ciò accade alle periferiche hardware a cui si è interessati, sarà necessario modificare in modo appropriato le regole in /etc/udev.


11.3 Come caricare un tipo di carattere per la console all'avvio nella maniera Debian?

I pacchetti kbd e console-tools lo supportano: modificare il file /etc/kbd/config o /etc/console-tools/config.


11.4 Come si possono configurare le impostazioni predefinite per l'applicazione di un programma X11?

I programmi X di Debian installano i loro dati di risorsa dell'applicazione 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.


11.5 Ogni distribuzione sembra avere un metodo di avvio differente. Cosa dire di quello di Debian?

Like all Unices, Debian boots up by executing the program init [6]. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by forking subprocess to perform initialization such as to check and to mount file systems, to load modules, to start the network services, to set the clock, and to perform other initialization.

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 Uni* compatibili con il System V, Linux ha 7 runlevel:

I sistemi Debian vengono forniti con id=2, che indica che il runlevel predefinito sarà "2" quando si entra nello stato multiutente, e che verranno eseguiti gli script in /etc/rc2.d/.

Debian uses dependency-based boot ordering through insserv, using the LSB headers in each script under /etc/init.d/, as well as parallel concurrent booting through the use of startpar to speed up the boot process.

The scripts in any of the directories, /etc/rcN.d/ are just symbolic links back to scripts in /etc/init.d/. However, the names of the files in each of the /etc/rcN.d/ directories are selected to indicate the way the scripts in /etc/init.d/ will be run. Specifically, before entering any runlevel, all the scripts beginning with 'K' are run; these scripts kill services. Then all the scripts beginning with 'S' are run; these scripts start services. The two-digit number following the 'K' or 'S' indicates the order in which the script is run. Lower numbered scripts are executed first.

Questo approccio funziona perché tutti gli script in /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

sends the sendmail daemon a signal to reread its configuration file.

Note that invoke-rc.d should not be used to call the /etc/init.d/ scripts, service should be used instead.


11.6 What other facilities are provided to customize the boot process besides rc.local?

The rc.local script is executed at the end of each multiuser runlevel. In Debian it is configured to do nothing. This provides customisation of the boot process, but might not be sufficient for all situations.

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

Si può, per esempio, fare in modo che lo script pippo venga eseguito all'avvio, mettendolo in /etc/init.d/ ed eseguendo update-rc.d pippo defaults 19. L'argomento "defaults" fa riferimento ai runlevel predefiniti, il che significa (almeno in assenza di blocchi di commento LSB che specifichino diversamente) che il servizio viene avviato nei runlevel dal 2 al 5 e che viene fermato nei runlevel 0, 1 e 6. (Quasiasi direttiva LSB Default-Start e Default-Stop in pippo ha la precedenza quando si usa la versione sysv-rc di update-rc.d, ma viene ignorata dalla versione attuale (v0.8.10) di file-rc di update-rc.d.) L'argomento "19" assicura che pippo venga chiamato dopo che siano stati completati tutti gli script il cui numero è minore di 19 e prima di tutti gli script con numero uguale o maggiore di 20.


11.7 Come si comporta il sistema di manutenzione dei pacchetti nel caso di 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 saprà nulla di quei file di configurazione se sono in un pacchetto differente, e potrebbe 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. Allora dpkg e il resto del sistema di gestione dei pacchetti vedono che i file sono stati modificati dall'"amministratore di sistema" locale e non cercheranno di sovrascriverli quando quei pacchetti verranno aggiornati.


11.8 Come sovrascrivere 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:

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

Invece,

Eseguire dpkg-divert --list per vedere quali deviazioni siano attualmente attive sul proprio sistema.

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


11.9 Come si può far sì che un pacchetto generato localmente venga incluso nella lista dei pacchetti disponibili che il sistema di gestione dei pacchetti conosce?

Eseguire il comando:

     dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PREFISSOPERCORSO] > mio_Packages

dove:

Una volta che si è creato il file mio_Packages, si informi il sistema di gestione dei pacchetti usando il comando:

     dpkg --merge-avail mio_Packages

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


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

Ci sono diversi casi in cui due pacchetti forniscono due versioni differenti di un programma, che forniscono entrambe le stesse funzionalità fondamentali. Gli utenti possono preferire l'una rispetto all'altra 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 pur continuando ancora a soddisfare i requisiti in termini di dipendenze dei pacchetti senza specificare un particolare pacchetto.

Per esempio, potrebbero esistere due differenti versioni di lettori di newsgroup su un sistema. Il pacchetto del server per newsgroup potrebbe "raccomandare" la presenza di un qualche lettore di newsgroup sul sistema, ma la scelta tra tin e trn è lasciata all'utente. Ciò è realizzato avendo entrambi i pacchetti tin e trn che forniscono il pacchetto virtuale news-reader. Quale programma venga chiamato è determinato da un collegamento che punta dal file con il nome del pacchetto virtuale /etc/alternatives/news-reader al file selezionato, per esempio /usr/bin/trn.

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

Per esempio, per verificare quale eseguibile fornisce "x-window-manager", eseguire:

     update-alternatives --display x-window-manager

Se lo si desidera cambiare, eseguire:

     update-alternatives --config x-window-manager

e seguire le istruzioni sullo schermo (sostanzialmente premere il numero vicino alla voce che si preferisce).

Se, per qualche ragione, un pacchetto non si registra da solo come un window manager (si segnali il bug 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 collegamento 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 collegamento simbolico che punta a /etc/alternatives/NOME, dove NOME è il secondo argomento. Il terzo argomento è il programma al quale /etc/alternatives/NOME dovrebbe puntare e il quarto argomento è la priorità (maggiore è il valore maggiore è la probabilità che l'alternativa sia scelta automaticamente).

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

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

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


The Debian GNU/Linux FAQ

versione 5.0.3, 16 October 2014

Gli autori sono elencati in Autori delle FAQ di Debian