Capitolo 11. Personalizzare il proprio sistema Debian GNU/Linux

# Capitolo 11. Personalizzare il proprio sistema 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/sr0` appartiene al gruppo `cdrom`.

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?

Il pacchetto `kbd` lo permette: modificare il file `/etc/kbd/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. Come si avvia un sistema Debian?

Come tutti i simil-UNIX, Debian si avvia eseguendo il programma `init`. Come la maggior parte delle distribuzioni Linux, un sistema Debian predefinito usa `systemd` come implementazione di `init`. Sono anche supportati il tradizionale init in stile System-V e altri metodi. [6]

Per controllare l'ordine in cui i servizi sono avviati i sistemi Unix tradizionali in stile System V usano i runlevel. Questi in systemd sono rimpiazzati da target. Per visualizzare il target predefinito al quale systemd porta il sistema, eseguire il comando

    systemctl get-default

Durante l'avvio systemd fa partire i servizi o gli altri target elencati in file del target predefinito `/lib/systemd/system/default.target`. I file per questi servizi e target vengono installati e il servizio è abilitato durante l'installazione dei pacchetti Debian. Se si desidera specificatamente di non avviare un servizio all'avvio di sistema, invece di rimuovere il pacchetto corrispondente si può eseguire il comando

    systemctl disable servizio.service

usando il nome del file di servizio installato in `/lib/systemd/system` (solitamente basato sul nome del pacchetto).

Il file di servizio `/lib/systemd/system/rc-local.service` fornisce un modo semplice per eseguire dopo l'avvio script personalizzati nel file `/etc/rc.local`, in modo simile a ciò che viene offerto nei sistemi Debian che eseguono un init in stile System V. Attenzione: questo script fallisce se cerca di interagire con la console, ad esempio per chiedere una password utente o per cercare di pulire lo schermo.

Si può controllare lo stato di ogni servizio con il comando

    service pacchetto status

. Per avviare o fermare un servizio eseguire

    service pacchetto start

e

    service pacchetto stop

. Il comando `service` funziona con qualsiasi sistema init gestito su un sistema Debian, non solo con systemd. Se tuttavia si preferisce usare lo stesso comando su qualsiasi sistema Linux con systemd, per controllare lo stato eseguire

    systemctl status pacchetto.service

per ottenere le stesse informazioni.

Per ulteriori informazioni su systemd per Debian vedere https://wiki.debian.org/systemd.

## 11.6. Cosa ne è dell'init System V tradizionale in Debian?

Debian gestisce l'avvio attraverso l'init tradizionale System V attraverso il pacchetto sysvinit-core. Il file di configurazione per l'`init` System V (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/` facendo il fork di sottoprocessi 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.

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:

- 0 (ferma il sistema),

- 1 (modalità singolo-utente),

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

- 6 (riavvia il sistema).

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 usa l'ordine di avvio basato su dipendenze attraverso insserv, usando le intestazioni LSB in ogni script in `/etc/init.d/`, oltre all'avvio concorrente parallelo attraverso l'utilizzo di startpar per velocizzare il processo di avvio.

Gli script in ognuna delle directory `/etc/rcN.d/` sono solo collegamenti 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/` vengono eseguiti. Specificatamente, prima di entrare in qualsiasi runlevel, sono eseguiti tutti gli script che iniziano con "K"; 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 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

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

Notare che invoke-rc.d non dovrebbe essere usato per chiamare gli script `/etc/init.d/`, ma dovrebbe essere usato invece service.

## 11.7. Esistono ancora altri modi di avviare un sistema Debian?

Se ci si trova bene con l'init System V, ma non piaciono i collegamenti /etc/rc?.d/* si può installare il pacchetto `file-rc`. Questo converte i collegamenti in un singolo file di configurazione /etc/runlevel.conf

Se non piace né System V né systemd, si può provare `openrc`, `runit` o `daemontools`.

## 11.8. 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.9. 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:

- Sovrascrivere `/bin/login` con `login-local`.

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 --divert /bin/login.debian /bin/login

  in modo che tutte le future installazioni del pacchetto `login` di Debian scrivano invece il file `/bin/login` in `/bin/login.debian`.

- Poi eseguire:

      cp login-local /bin/login

  per spostare il proprio programma al suo posto.

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.10. 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:

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

- OVERRIDE_FILE è un file che viene modificato dai manutentori della distribuzione ed è solitamente situato, per i pacchetti Debian nella sezione "main", in `indices/override.main.gz` nell'archivio Debian. Può essere ignorato per pacchetti locali.

- PREFISSOPERCORSO è una stringa opzionale che può essere posta prima del file `mio_Packages` prodotto.

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

[6] Nel 2014 Debian ha cambiato il proprio sistema init predefinito da Sytem V a systemd. Nell'aprile 2015 Debian 8 "jessie" è stato il primo rilascio fornito con systemd come init predefinito. A questo proposito ci sono state quattro decisioni del Debian Technical Committee: Bug #7277082014-02-11: "Il comitato ha deciso che il sistema init predefinito per le architetture Linux in jessie deve essere systemd." Bug #7467152014-08-01: "Il comitato tecnico si aspetta che i manutentori continuino a supportare i sistemi init multipli disponibili" e che venga fatto il merge di contributi ragionevoli. Bug #7465782014-11-15: "Il comitato ha deciso che systemd-shim debba essere il primo nell'elenco delle dipendenze alternative di libpam-systemd invece di systemd-sysv." Questa decisione ha reso più facile continuare ad utilizzare un sistema Debian non systemd. Bug #7621942017-11-04: "Sul cambiamento automatico del sistema init durante l'aggiornamento"

Capitolo 10. Debian e il kernel |  | Capitolo 12. Ottenere supporto per Debian GNU/Linux