path: root/documentation/content/it/books/handbook/config/_index.adoc

---
title: Capitolo 11. Configurazione e Messa a Punto
part: Parte II. Compiti Ordinari
prev: books/handbook/partiii
next: books/handbook/boot
---

[[config-tuning]]
= Configurazione e Messa a Punto
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 11
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/audit/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[config-synopsis]]
== Sinossi

Uno degli aspetti importanti di FreeBSD è la configurazione del sistema. Una corretta configurazione del sistema aiuterà a prevenire mal di testa durante futuri aggiornamenti. Questo capitolo spiegherà molti dei processi di configurazione di FreeBSD, inclusi alcuni parametri che possono essere impostati per ottimizzare un sistema FreeBSD.

Dopo aver letto questo capitolo, saprai:

* Come lavorare in maniera efficiente con i file system e le partizioni di swap.
* Le basi dei sistemi di configurazione [.filename]#rc.conf# e di avvio [.filename]#/usr/local/etc/rc.d#.
* Come configurare e provare una scheda di rete.
* Come configurare host virtuali sui dispositivi di rete.
* Come usare i vari file di configurazione in [.filename]#/etc#.
* Come mettere a punto FreeBSD usando le variabili `sysctl`.
* Come ottimizzare la prestazioni del disco e modificare le limitazioni del kernel.

Prima di leggere questo capitolo, dovresti:

* Comprendere le basi di UNIX(R) e di FreeBSD (crossref:basics[basics,Basi di UNIX]).
* Avere dimestichezza nella configurazione/compilazione del kernel (crossref:kernelconfig[kernelconfig,Configurazione del Kernel di FreeBSD]).

[[configtuning-initial]]
== Configurazione Iniziale

=== Disposizione delle Partizioni

==== Partizioni di Base

Nel disegnare il tuo file system con man:bsdlabel[8] o man:sysinstall[8], ricorda che i dischi rigidi possono trasferire dati ad un ritmo maggiore dalle tracce esterne rispetto a quelle interne. Quindi i file system più piccoli e con un gran numero di accessi dovrebbero essere più vicini alla parte esterna del disco, mentre le partizioni più ampie, come [.filename]#/usr#, dovrebbero essere posizionate verso l'interno. È una buona idea creare le partizioni in un ordine simile al seguente: root, swap, [.filename]#/var#, [.filename]#/usr#.

Le dimensioni della partizione [.filename]#/var# riflettono l'uso che intendi fare della macchina. [.filename]#/var# viene usata per mantenere le caselle di posta, i file di log, e gli spool della stampante. Le caselle di posta e file di log potrebbero crescere in maniera imprevedibile in relazione al numero di utenti presenti sul tuo sistema e da quanto a lungo manterrai i file di log. La maggior parte degli utenti non avrà mai bisogno di un gigabyte, ma ricorda che [.filename]#/var/tmp# deve essere abbastanza ampia da contenere tutti i pacchetti.

La partizione [.filename]#/usr# contiene molti dei file richiesti per far funzionare il sistema, la collezioni dei man:ports[7] (raccomandata) e il codice sorgente (opzionale). Entrambi sono opzionali al momento dell'installazione. Almeno 2 gigabyte sono raccomandati per questa partizione.

Quando decidi le dimensioni delle partizioni, tieni a mente le richieste di spazio. Esaurire lo spazio in una partizione mentre ne usi poco in un'altra può essere molto fastidioso.

[NOTE]
====
Alcuni utenti hanno scoperto che il dimensionamento `auto-predefinito` di man:sysinstall[8] a volte crea partizioni [.filename]#/var# o [.filename]#/# più piccole del necessario. Partiziona saggiamente e generosamente.
====

[[swap-design]]
==== Partizione di Swap

Come regola generale, la partizione di swap dovrebbe essere tipicamente il doppio della quantità di memoria principale (RAM). Ad esempio, se la macchina avesse 128 megabyte di memoria, il file di swap dovrebbe essere di 256 megabyte. Sistemi con meno memoria potrebbero funzionare meglio con uno swap maggiore. Meno di 256 megabyte di swap non è raccomandato e dovresti pensare ad una espansione della memoria. Gli algoritmi di paginazione sono ottimizzati per funzionare al meglio quando la partizione di swap è almeno due volte la dimensione della memoria principale. Configurare uno swap troppo piccolo potrebbe portare ad una inefficienza nel codice di scansione della VM e potrebbe creare problemi in seguito, nel caso di aggiunta di memoria alla macchina.

Su sistemi più grandi con dischi SCSI multipli (o dischi IDE multipli collegati a diversi controller) è consigliabile che ci sia uno swap per ogni disco (fino a quattro dischi). Le partizioni di swap dovrebbero avere approssimativamente le stesse dimensioni. Il kernel può gestire dimensioni arbitrarie ma internamente le strutture dati scalano meglio fino a quattro volte la dimensione della partizione di swap più ampia. Avere partizioni di swap con dimensioni simili permetterà al kernel di distribuire al meglio lo spazio di swap tra i dischi. Partizioni di swap grandi vanno bene, anche se non vengono usate molto. Potrebbe essere più semplice recuperare il sistema da un programma impazzito prima di essere costretti a riavviare.

==== Perchè Partizionare?

Molti utenti pensano che un'unica grande partizione vada bene, ma ci sono molte ragioni per cui questa è una cattiva idea. Primo, ogni partizione ha differenti caratteristiche operative e separarle permette ai file system di ottimizzare se stessi di conseguenza. Ad esempio, le partizioni root e [.filename]#/usr# sono per lo più usate in lettura, senza molte operazioni di scrittura. Un sacco di letture e scritture potrebbero esserci in [.filename]#/var# e [.filename]#/var/tmp#.

Partizionando in maniera appropriata il sistema, la frammentazione introdotta nelle partizioni più piccole, con più carico in scrittura, non inciderà sulle partizioni per lo più di lettura. Mantenere le partizioni con maggiore carico in scrittura vicine al bordo del disco aumenterà le prestazioni di I/O nelle partizioni dove ne hai più bisogno. Ora, sebbene potresti avere bisogno di prestazioni di I/O anche nelle partizioni più ampie, spostarle verso il bordo del disco non porterebbe nessun miglioramento significativo delle prestazioni, al contrario dello spostamento di [.filename]#/var# all'esterno. Infine, ci sono problemi riguardanti la sicurezza. Una piccola, simpatica partizione di root che è essenzialmente di sola lettura ha ottime possibilità di sopravvivere intatta a un brutto crash.

[[configtuning-core-configuration]]
== Configurazione Principale

Il posto principale per le informazioni di configurazione del sistema è in [.filename]#/etc/rc.conf#. Questo file contiene un'ampia gamma di informazioni di configurazione, usate principalmente all'avvio della macchina per la configurazione del sistema. Il suo nome è autoesplicativo; si tratta di informazioni di configurazione per i file [.filename]#rc*#.

Un amministratore dovrebbe aggiungere dei campi nel file [.filename]#rc.conf# per cambiare le impostazioni predefinite di [.filename]#/etc/defaults/rc.conf#. Il file predefinito non dovrebbe essere semplicemente copiato in [.filename]#/etc# - esso contiene valori di default, non esempi. Tutti i cambiamenti specifici del sistema dovrebbero essere effettuati nel file [.filename]#rc.conf# stesso.

Nelle applicazioni cluster possono essere adottate differenti strategie per separare le configurazioni generali da quelle specifiche del sistema in maniera da mantenere basso l'impegno di amministrazione. L'approccio raccomandato è di porre le configurazioni generali in un altro file, ad esempio [.filename]#/etc/rc.conf.site#, e poi includerlo in [.filename]#/etc/rc.conf#, che conterrà solo le informazioni specifiche del sistema.

Visto che [.filename]#rc.conf# viene letto da man:sh[1] è semplice farlo. Ad esempio:

* rc.conf:
+
[.programlisting]
....
        . /etc/rc.conf.site
        hostname="node15.example.com"
        network_interfaces="fxp0 lo0"
        ifconfig_fxp0="inet 10.1.1.1"
....

* rc.conf.site:
+
[.programlisting]
....
        defaultrouter="10.1.1.254"
        saver="daemon"
        blanktime="100"
....

Il file [.filename]#rc.conf.site# potrà poi essere distribuito su ogni sistema usando `rsync` o un programma simile, mentre il file [.filename]#rc.conf# rimarrà unico.

L'aggiornamento del sistema tramite man:sysinstall[8] o `make world` non sovrascriverà il file [.filename]#rc.conf#, quindi le configurazioni del sistema non andranno perse.

[[configtuning-appconfig]]
== Configurazione delle Applicazioni

Tipicamente, le applicazioni installate hanno i propri file di configurazione, con la loro sintassi, ecc. È importante che questi file siano tenuti separati dal sistema di base, in maniera da essere facilmente individuati e gestiti dagli strumenti di gestione dei pacchetti.

In genere, questi file vengono installati in [.filename]#/usr/local/etc#. Nel caso in cui un'applicazione abbia un grande numero di file di configurazione, verrà creata una sottodirectory per contenerli.

Normalmente, quando viene installato un pacchetto, vengono installati anche file di configurazione d'esempio. In genere questi vengono identificati da un suffisso [.filename]#.default#. Se non ci sono file di configurazione esistenti per l'applicazione, verranno creati copiando i file [.filename]#.default#.

Ad esempio, considera il contenuto della directory [.filename]#/usr/local/etc/apache#:

....
-rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf
-rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf.default
-rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf
-rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf.default
-rw-r--r--  1 root  wheel  12205 May 20  1998 magic
-rw-r--r--  1 root  wheel  12205 May 20  1998 magic.default
-rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types
-rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types.default
-rw-r--r--  1 root  wheel   7980 May 20  1998 srm.conf
-rw-r--r--  1 root  wheel   7933 May 20  1998 srm.conf.default
....

Le differenze nelle dimensioni dei file mostrano che solo [.filename]#srm.conf# è stato modificato. Una successiva installazione di Apache dai port non sovrascriverà questo file modificato.

[[configtuning-starting-services]]
== Avvio dei Servizi

Molti utenti scelgono di installare software di terze parti in FreeBSD attraverso la collezione dei port. Nell magior parte dei casi potrebbe essere necessario configurare il software in un modo tale che sia avviato all'inizializzazione di sistema. Servizi, come package:mail/postfix[] o package:www/apache13[] sono solo due fra i molti pacchetti software che possono essere avviati durante l'inizializzazione di sistema. Questa sezione spiega le procedure disponibili per avviare software di terze parti.

In FreeBSD, molti servizi inclusi, come man:cron[8], sono avviati attraverso gli script di startup. Questi script possono differire a seconda della verione di FreeBSD o del produttore; comunque il più importante aspetto da considerare è che la configurazione di startup può essere gestita tramite semplici script di inizializzazione.

Prima dell'avvento di [.filename]#rc.d#, gli applicativi lasciavano un semplice script di avvio nella directory [.filename]#/usr/local/etc/rc.d# che sarebbe stato poi letto dagli script di inizializzazione di sistema. Questi script sarebbero poi eseguiti durante la fase di avvio del sistema.

Mentre molti individui hanno speso ore cercando di integrare il vecchio stile di configurazione nel nuovo sistema, resta il fatto che qualche utility di terze parti necessita ancora di uno script semplicemente lasciato nella succitata directory. Le sottili differenze negli script dipendono dal fatto se [.filename]#rc.d# sia usato o meno. Prima di FreeBSD 5.1 viene usato il vecchio metodo di configurazione ed in quasi tutti i casi uno script di nuovo tipo funzionerebbe perfettamente.

Mentre ogni script deve rispettare alcuni requisiti minimi, il più delle volte questi requisiti sono indipendenti dalla versioni di FreeBSD. Ogni script deve avere una estensione [.filename]#.sh# appesa alla fine ed ogni script deve essere eseguibile dal sistema. L'ultima richiesta può essere soddisfatta usando il comando `chmod` e impostando i permessi a `755`. Ci dovrebbe essere, come minimo, un'opzione per fare lo `start` dell'applicativo ed un'opzione per farne lo `stop`.

Il più semplice script di avvio probabilmente sembrerebbe simile al seguente:

[.programlisting]
....
#!/bin/sh
echo -n ' utility'

case "$1" in
start)
        /usr/local/bin/utility
        ;;
stop)
        kill -9 `cat /var/run/utility.pid`
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        exit 64
        ;;
esac

exit 0
....

Questo script fornisce un'opzione `stop` e `start` per l'applicazione a cui ci riferiamo semplicemente come `utility`.

Potrebbe essere avviata manualmente con:

[source,shell]
....
# /usr/local/etc/rc.d/utility.sh start
....

Mentre non tutto il software di terze parti richiede la linea in [.filename]#rc.conf#, quasi ogni giorno un nuovo port viene modificato per accettare questa configurazione. Controlla l'output finale dell'installazione per maggiori informazioni su un applicativo specifico. Ci sarà del software di terze parti che fornisce script di avvio che permettono all'applicativo di essere usato con [.filename]#rc.d#; tuttavia, questo sarà discusso nella successiva sezione.

=== Configurazione Estesa degli Applicativi

Ora che FreeBSD include [.filename]#rc.d#, la configurazione dell'avvio degli applicativi è diventata più semplice, e più flessibile. Usando le parole chiave discusse nella sezione <<configtuning-rcd,rc.d>>, gli applicativi ora possono essere configurati dopo certi altri servizi come ad esempio il DNS; possono permettere che siano passati flag extra nel codice attraverso [.filename]#rc.conf# al posto di flag statici negli script di avvio, e molto altro. Uno script basilare potrebbe assomigliare al seguente:

[.programlisting]
....
#!/bin/sh
#
# PROVIDE: utility
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=utility
rcvar=utility_enable

command="/usr/local/sbin/utility"

load_rc_config $name

#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
utility_enable=${utility_enable-"NO"}
pidfile=${utility_pidfile-"/var/run/utility.pid"}

run_rc_command "$1"
....

Questo script assicurerà che utility partirà dopo il servizio `daemon`. Fornisce inoltre un metodo per settare e tracciare il PID, o il file dell'ID di processo.

Questa applicazione potrebbe avere le seguenti linee piazzate in [.filename]#/etc/rc.conf#:

[.programlisting]
....
utility_enable="YES"
....

Questo metodo permette inoltre una semplice manipolazione degli argomenti di linea di comando, incluse le funzioni di default definite in [.filename]#/etc/rc.subr#, compatibilità con l'utility man:rcorder[8] e fornisce una più semplice configurazione attraverso il file [.filename]#rc.conf#.

=== Usare i Servizi per Avviare i Servizi

Altri servizi, come i demoni POP3, IMAP, etc. potrebbero essere avviati usando man:inetd[8]. Questo implica l'installazione del servizio dalla collezione dei port e l'aggiunta di una linea di configurazione al file [.filename]#/etc/inetd.conf# o togliendo dei commenti in una delle linee di configurazione del file stesso. L'uso di inetd e la sua configurazione è descritto in dettaglio nella sezione crossref:network-servers[network-inetd,inetd].

In alcuni casi, potrebbe essere più plausibile usare il demone man:cron[8] per avviare i servizi di sistema. Questo approccio ha alcuni vantaggi poichè `cron` esegue questi processi come l'utente proprietario del file [.filename]#crontab#. Questo permette ad utenti regolari di avviare e mantenere alcuni applicativi.

Il comando `cron` fornisce una caratteristica unica, `@reboot`, che potrebbe essere usato al posto della specifica del tempo. Questo farà sì che il job sia eseguito quando man:cron[8] è avviato, normalmente durante l'inizializzazione di sistema.

[[configtuning-cron]]
== Configurare l'Utility `cron`

Uno dei comandi più utili presenti in FreeBSD è man:cron[8]. L'utility `cron` viene eseguita in background e controlla costantemente il file [.filename]#/etc/crontab#. `cron` controlla anche la directory [.filename]#/var/cron/tabs#, alla ricerca di nuovi file [.filename]#crontab#. Questi file [.filename]#crontab# contengono informazioni sulle specifiche funzioni che ci si aspetta vengano compiute da `cron` a determinati intervalli temporali.

L'utility `cron` usa due differenti tipi di file di configurazione, il crontab di sistema ed il crontab utente. La sola differenza fra questi due file è nel sesto campo. Nel crontab di sistema, il sesto campo è il nome dell'utente sotto il quale viene eseguito il comando. Questo dà al crontab di sistema la capacità di eseguire comandi come ogni utente. Nel crontab utente, il sesto campo è il comando da eseguire, e tutti i comandi vengono eseguiti come l'utente che ha creato il crontab; questa è un'importante caratteristica di sicurezza.

[NOTE]
====
I crontab utenti permettono ad utenti individuali di schedulare task senza i privilegi di `root`. I comandi in un crontab utente vengono eseguiti con i permessi dell'utente che posseggono il file crontab.

L'utente `root` può possedere il crontab proprio come ogni altro utente. Qui c'è una differenza rispetto a [.filename]#/etc/crontab# (il crontab di sistema). Per via del crontab di sistema, di solito non c'è bisogno di creare un crontab per `root`.
====

Diamo un'occhiata al file [.filename]#/etc/crontab# (il crontab di sistema):

[.programlisting]
....
# /etc/crontab - il crontab di root per FreeBSD
#
# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $
## <.>
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin <.>
HOME=/var/log
#
#
#minute    hour    mday    month   wday    who command <.>
#
#
*/5    *   *   *   *   root    /usr/libexec/atrun <.>
....

<.> Come in molti file di configurazione di FreeBSD, il carattere `#` rappresenta un commento. Un commento può essere posto nel file come una nota su cosa si desidera fare con un certo comando. I commenti non possono essere nella stessa linea di un comando o saranno interpretati come parte di un comando; devono trovarsi su una linea a sè. Le linee vuote vengono ignorate.
<.> Anzitutto, deve essere definito l'ambiente. I segni di uguale (`=`) vengono usati per definire ogni impostazione dell'ambiente, come viene fatto in questo esempio per `SHELL`, `PATH`, e `HOME`. Se la linea relativa alla shell viene omessa, `cron` userà quella di default, che è `sh`. Se si omette la variabile `PATH`, non verrà usato nessun default e le locazioni dei file dovranno essere assolute. Se viene omessa `HOME`, `cron` userà la home directory dello user che lo ha richiamato.
<.> Questa linea definisce un totale di sette campi. Qui sono elencati i valori `minute`, `hour`, `mday`, `month`, `wday`, `who`, e `command`. Questi nomi sono più o meno autoesplicativi. `minute` è il tempo in minuti al quale dovrà essere eseguito il comando. `hour` è uguale, ma per le ore. `mday` rappresenta il giorno del mese. `month` è simile ad `hour` e `minute`, ma rappresenta il mese. L'opzione `wday` rappresenta il giorno della settimana. Tutti questi campi devono avere un valore numerico, e seguire l'orario di ventiquattro ore. Il campo `who` è speciale, ed esiste solo nel file [.filename]#/etc/crontab#. Questo campo specifica l'utente con il quale deve essere eseguito il comando. Quando un utente installa il suo file [.filename]#crontab#, non avrà a disposizione questa opzione. Infine, viene elencata l'opzione `command`. Questo è l'ultimo campo, e naturalmente indica il comando che deve essere eseguito.
<.> Quest'ultima linea definirà i valori discussi prima. Notate che abbiamo un `*/5`, seguito da parecchi caratteri `*`. Questi caratteri `*` significano "dalla prima all'ultima volta", e possono essere interpretati come _ogni_ volta. Dunque, basandosi su questa linea, sembra che il comando `atrun` debba essere invocato da `root` ogni cinque minuti, prescindendo da quale giorno o mese sia. Per maggiori informazioni sul comando `atrun`, vedere la pagina di manuale man:atrun[8].I comandi possono essere richiamati con qualsiasi numero di flag; i comandi che si estendono per più righe potrebbero però avere bisogno di essere spezzati con il carattere di continuazione "\".

Questa è l'impostazione di base per ogni file [.filename]#crontab#, anche se c'è qualcosa di particolare in questo. Il sesto campo, dove abbiamo specificato il nome utente, esiste solo nel file di sistema [.filename]#/etc/crontab#. Questo campo dovrebbe venire omesso nei [.filename]#crontab# dei vari utenti.

[[configtuning-installcrontab]]
=== Installare un Crontab

[IMPORTANT]
====
Non devi usare la procedura descritta qui per editare/installare il crontab di sistema. Semplicemente usa il tuo editor favorito: l'utility `cron` noterà che il file è cambiato e immediatamente inizierà ad usare la versione aggiornata. Vedi extref:{faq}[queste FAQ, ROOT-NOT-FOUND-CRON-ERRORS] per maggiori informazioni.
====

Per installare un [.filename]#crontab# appena scritto, prima usa il tuo editor preferito per creare un file nel formato corretto, e poi usa l'utility `crontab`. L'uso più corretto è:

[source,shell]
....
% crontab crontab-file
....

In questo esempio, [.filename]#crontab-file# è il nome di un file [.filename]#crontab# che era stato creato in precedenza.

C'è anche un'opzione per elencare i file [.filename]#crontab# già installati: passate semplicemente `-l` a `crontab` e date un'occhiata all'output.

Per gli utenti che desiderino scrivere il proprio file crontab da zero, senza usare un template, è disponibile `crontab -e`. Questa opzione permetterà loro di invocare l'editor prescelto su un file vuoto. Quando il file verrà salvato, esso verrà automaticamente installato dal comando `crontab`.

Se successivamente vuoi rimuovere il tuo [.filename]#crontab# completamente, usa `crontab` con l'opzione `-r`.

[[configtuning-rcd]]
== Usare rc con FreeBSD

Nel 2002 FreeBSD ha integrato il sistema di inizializzazione [.filename]#rc.d# di NetBSD. Gli utenti dovrebbero aver notato i file elencati nella cartella [.filename]#/etc/rc.d#. Molti di questi file sono servizi di base che possono essere controllati con opzioni `start`, `stop`, e `restart`. Ad esempio, man:sshd[8] può essere riavviato con il comando seguente:

[source,shell]
....
# /etc/rc.d/sshd restart
....

Questa procedura è simile a quella per altri servizi. Naturalmente, i servizi in genere vengono avviati automaticamente in fase di avvio secondo quanto specificato in man:rc.conf[5]. Ad esempio, per abilitare il demone per il NAT (Network Address Translation) all'avvio basta aggiungere la linea seguente a [.filename]#/etc/rc.conf#:

[.programlisting]
....
natd_enable="YES"
....

Se esiste già una linea `natd_enable="NO"`, allora basta cambiare il valore da `NO` a `YES`. Gli script rc caricheranno automaticamente ogni altro servizio durante il riavvio seguente, come descritto più avanti.

Poichè il sistema di [.filename]#rc.d# è inteso prevalentemente per avviare/bloccare i servizi al momento dell'accensione/spegnimento, le opzioni standard `start`, `stop` e `restart` avranno il comportamento appropriato solo seè stata impostata la variabile appropriata in [.filename]#/etc/rc.conf#. Ad esempio il comando precedente `sshd restart` funzionerà solo se in [.filename]#/etc/rc.conf# è stata impostata l'opzione `sshd_enable` a `YES`. Per avviare (`start`), fermare (`stop`) o riavviare (`restart`) un servizio, ignorandole impostazioni in [.filename]#/etc/rc.conf#, i comandi devono avere il prefisso "one". Ad esempio per riavviare `sshd` trascurando le impostazioni esistenti in [.filename]#/etc/rc.conf#, impartite il comando seguente:

[source,shell]
....
# /etc/rc.d/sshd onerestart
....

È semplice controllare se un servizio è stato abilitato in [.filename]#/etc/rc.conf# eseguendo lo script appropriato in [.filename]#rc.d# con l'opzione `rcvar`. Dunque, un amministratore può controllare che `sshd` sia effettivamente abilitato in [.filename]#/etc/rc.conf# eseguendo:

[source,shell]
....
# /etc/rc.d/sshd rcvar
# sshd
$sshd_enable=YES
....

[NOTE]
====
La seconda linea (`# sshd`) è l'output del comando `sshd`; non una console di `root`.
====

Per determinare se un servizio è attivo, è disponibile l'opzione `status`. Ad esempio per verificare che `sshd` sia effettivamente avviato:

[source,shell]
....
# /etc/rc.d/sshd status
sshd is running as pid 433.
....

In alcuni case è anche possibile effettuare il `reload` di un servizio. Questo tenterà di inviare un segnale al servizio, per fargli ricaricare il suo file di configurazione. Nella maggior parte dei casi si tratterà del segnale `SIGHUP`. Il supporto per questa caratteristica non è garantito per tutti i servizi.

La struttura di [.filename]#rc.d# non viene usata solo per i servizi di rete, ma contribuisce anche per buona parte all'inizializzazione del sistema. Ad esempio, considerate il file [.filename]#bgfsck#. Quando lo script viene eseguito, esso stamperà il seguente messaggio:

[source,shell]
....
Starting background file system checks in 60 seconds.
....

Dunque questo file viene usato per il controllo del file system in background, che avviene solo durante l'inizializzazione del sistema.

Molti servizi di sistema dipendono da altri servizi per poter funzionare in maniera appropriata. Ad esempio, il NIS ed altri servizi basati sulle RPC potrebbero non funzionare in assenza di `rpcbind` (portmapper). Per risolvere il problema, nei commenti all'inizio di ogni script di avvio ci sono informazioni sulle dipendenze ed altri metadati. Il programma man:rcorder[8] viene poi utilizzato per effettuare il parsing di questi commenti durante l'inizializzazione di sistema e per determinare l'ordine con il quale questi servizi devono essere avviati per avere le proprie dipendenze soddisfatte. In cima ad ogni file di avvio possono essere incluse le seguenti parole:

* PROVIDE: Specifica i servizi forniti dal file.
* REQUIRE: Elenca i servizi richiesti per far funzionare correttamente questo servizio. Questo file verrà eseguito _dopo_ i tali servizi.
* BEFORE: Elenca i servizi che dipendono da questo. Questo file verrà lanciato _prima_ dei servizi specificati.

Usando questo metodo, un amministratore può controllare facilmente i servizi di sistema senza il fastidio dei "runlevel" come alcuni altri sistemi operativi UNIX(R).

Informazioni addizionali sul sistema [.filename]#rc.d# possono essere trovate nelle pagine man di man:rc[8] e man:rc.subr[8]. Se sei interessato a scrivere un tuo script [.filename]#rc.d# o a migliorarne uno esisente, ti può essere utile extref:{rc-scripting}[questo articolo].

[[config-network-setup]]
== Configurazione delle Interfacce di Rete

Al giorno d'oggi non riusciamo a pensare ad un computer senza pensare ad una connessione di rete. Aggiungere e configurare una scheda di rete è un compito comune per ogni amministratore di FreeBSD.

=== Individuazione del Driver Corretto

Prima di cominciare, dovresti conoscere il modello della scheda di rete che possiedi, il chip che usa, e se si tratta di una scheda PCI o ISA. FreeBSD supporta un'ampia varietà sia di schede PCI che ISA. Verifica l'Hardware Compatibility List della tua release per vedere se la scheda è supportata.

Una volta sicuro che la tua scheda sia supportata, hai bisogno di determinare il driver appropriato per la scheda. I file [.filename]#/usr/src/conf/NOTES# e [.filename]#/usr/src/sys/arch/conf/NOTES# ti forniranno un elenco di driver per le interfacce di rete con alcune informazioni su chipset/schede supportate. Se hai dubbi su quale sia il driver corretto, leggi la pagina man del driver. La pagina man fornirà ulteriori informazioni sull'hardware supportato ed anche sui possibili problemi che potrebbero capitare.

Se sei in possesso di una scheda comune, la maggior parte delle volte non dovrai cercare molto per trovare un driver. I driver per le schede di reti comuni sono presenti nel kernel [.filename]#GENERIC#, quindi la tua scheda dovrebbe presentarsi durante l'avvio, in questo modo:

[source,shell]
....
dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38
000ff irq 15 at device 11.0 on pci0
dc0: Ethernet address: 00:a0:cc:da:da:da
miibus0: <MII bus> on dc0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30
000ff irq 11 at device 12.0 on pci0
dc1: Ethernet address: 00:a0:cc:da:da:db
miibus1: <MII bus> on dc1
ukphy1: <Generic IEEE 802.3u media interface> on miibus1
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
....

In questo esempio, vediamo che nel sistema sono presenti due schede che usano il driver man:dc[4].

Se il driver per la tua NIC non è presente in [.filename]#GENERIC#, dovrai caricare i driver appropriati per usare la tua NIC. Questo dovrà essere fatto in uno di questi due modi:

* Il modo più semplice è caricare un modulo del kernel con man:kldload[8] o caricarlo automaticamente al momento del boot aggiungendo le linee appropriate a [.filename]#/boot/loader.conf#. Non tutti i driver NIC sono disponibili come moduli; esempi notevoli di driver per i quali non esistono moduli sono schede ISA.
* Alternativamente, puoi compilare staticamente il supporto per la tua scheda nel kernel. Controlla [.filename]#/usr/src/sys/conf/NOTES#, [.filename]#/usr/src/sys/arch/conf/NOTES# e la pagina di manuale del driver per sapere cosa aggiungere nel tuo file di configurazione del kernel. Per maggiori informazioni sul modo di ricompilare il kernel, per favore consulta il crossref:kernelconfig[kernelconfig,Configurazione del Kernel di FreeBSD]. Se la tua scheda era riconosciuta al boot dal tuo kernel ([.filename]#GENERIC#) non devi ricompilare un nuovo kernel.

[[config-network-ndis]]
==== Usare driver NDIS Windows(R)

Sfortunatamente, ci sono ancora molti venditori di hardware che non forniscono specifiche dei loro driver alla comunità open source perchè ritengono che tale informazione sia un segreto commerciale. Conseguentemente, gli sviluppatori di FreeBSD e di altri sistemi operativi hanno due scelte: sviluppare i driver con un lungo ed arduo processo di reverse engineering o usare i driver binari disponibili per le piattaforme Microsoft(R) Windows(R). La maggior parte degli sviluppatori, inclusi quelli coinvolti in FreeBSD, ha preso la seconda strada.

Grazie al contributo di Bill Paul (wpaul), a partire da FreeBSD 5.3-RELEASE c'è supporto "nativo" per Network Driver Interface Specification (NDIS). Il NDISulator di FreeBSD (anche noto come Progetto Evil) prende un driver binario per Windows(R) e sostanzialmente crea un inganno fingendo di eseguirlo in Windows(R). Poichè il driver man:ndis[4] sta usando un binario Windows(R), è usabile solo su sistemi i386(TM) e amd64.

[NOTE]
====
Il driver man:ndis[4] è designato per supportare principalmente device PCI, CardBus e PCMCIA, i device USB non sono ancora supportati.
====

Per usare il NDISulator, hai bisogno sostanzialmente di tre cose:

. Sorgenti del kernel
. binari dei driver di Windows(R) XP (estensione [.filename]#.SYS#)
. file di configurazione dei driver per Windows(R) XP (estensione [.filename]#.INF#)

Localizza i file per la tua carta specifica. Generalmente, posso essere trovati nel CD incluso o sui siti web dei venditori. Nei seguenti esempi, useremo [.filename]#W32DRIVER.SYS# e [.filename]#W32DRIVER.INF#.

[NOTE]
====
Non puoi usare un driver Windows(R)/i386 con FreeBSD/amd64, devi trovare un driver Windows(R)/amd64 per farlo funzionare correttamente.
====

Il prossimo passo è compilare il binario del driver in un modulo caricabile dal kernel. Per fare questo, come `root`, usa man:ndisgen[8]:

[source,shell]
....
# ndisgen /path/to/W32DRIVER.INF /path/to/W32DRIVER.SYS
....

L'utility man:ndisgen[8] è interattiva e chiederà altre informazioni di cui necessita; produrrà un modulo del kernel nella presente directory che può essere caricato in questo modo:

[source,shell]
....
# kldload ./W32DRIVER.ko
....

In aggiunta al modulo del kernel generato, devi caricare i moduli [.filename]#ndis.ko# e [.filename]#if_ndis.ko#. Questo dovrebbe avvenire automaticamente quando uno carica un modulo che dipende da man:ndis[4]. Se vuoi caricarli manualmente, usa il seguente comando:

[source,shell]
....
# kldload ndis
# kldload if_ndis
....

Il primo comando carica il wrapper del driver miniport NDIS, il secondo carica l'interfaccia di rete in questione.

Ora controlla man:dmesg[8] per vedere se c'era qualche errore durante il caricamento. Se tutto è andato bene, dovresti ottenere dell'output che somiglia a questo:

[source,shell]
....
ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps
....

D'ora in poi, puoi trattare il device [.filename]#ndis0# come ogni altra scheda di rete (ad esempio [.filename]#dc0#).

Puoi configurare il sistema perché carichi il modulo NDIS al momento del boot nello stesso modo di ogni altro modulo. Per prima cosa, copia il modulo generato [.filename]#W32DRIVER.ko#, nella directory [.filename]#/boot/modules#. Quindi, aggiungi le seguenti linee a [.filename]#/boot/loader.conf#:

[.programlisting]
....
W32DRIVER_load="YES"
....

=== Configurazione della Scheda di Rete

Una volta che il driver giusto per la scheda di rete è stato caricato, la scheda ha bisogno di essere configurata. Come molte altre cose, la scheda di rete potrebbe essere già stata configurata al momento dell'installazione tramite sysinstall.

Per mostrare la configurazione delle interfacce di rete sul tuo sistema, immetti il seguente comando:

[source,shell]
....
% ifconfig
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:a0:cc:da:da:da
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        ether 00:a0:cc:da:da:db
        media: Ethernet 10baseT/UTP
        status: no carrier
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
....

[NOTE]
====
Vecchie versioni di FreeBSD potrebbero richiedere l'opzione `-a` dopo man:ifconfig[8], per maggiori dettagli sulla sintassi corretta di man:ifconfig[8], fai riferimento alla pagina man. Nota anche che le voci relative all'IPv6 (`inet6` ecc.) sono state omesse in questo esempio.
====

In questo esempio, vengono mostrati i seguenti dispositivi:

* [.filename]#dc0#: La prima interfaccia Ethernet
* [.filename]#dc1#: La seconda interfaccia Ethernet
* [.filename]#lp0#: L'interfaccia della porta parallela
* [.filename]#lo0#: Il dispositivo di loopback
* [.filename]#tun0#: Il dispositivo tunnel usato da ppp

FreeBSD usa il nome del driver seguito dall'ordine nel quale la scheda è stata rilevata all'avvio del kernel per dare un nome alla scheda di rete. Ad esempio [.filename]#sis2# sarebbe la terza scheda di rete nel sistema che usa il driver man:sis[4].

In questo esempio, il dispositivo [.filename]#dc0# è attivo. Gli indicatori chiave sono:

. `UP` significa che la scheda è pronta e configurata.
. La scheda ha un indirizzo Internet (`inet`) (in questo caso `192.168.1.3`).
. Ha una maschera di sotto-rete valida (`netmask`; `0xffffff00` è lo stesso di `255.255.255.0`).
. Ha un indirizzo di broadcast valido (in questo caso, `192.168.1.255`).
. L'indirizzo MAC della scheda (`ether`) è `00:a0:cc:da:da:da`.
. La selezione del mezzo fisico è in modalità auto selezione (`media: Ethernet autoselect (100baseTX <full-duplex>)`). Vediamo che [.filename]#dc1# è stata configurata con un mezzo fisico `10baseT/UTP`. Per ulteriori informazioni sui tipi di mezzi disponibili per un driver, fai riferimento alla sua pagina man.
. Lo stato del collegamento (`status`) è `active`, ovvero è stata rilevata la portante. Per [.filename]#dc1#, vediamo `status: no carrier`. Questo è normale quando un cavo Ethernet non è stato inserito nella scheda.

Se l'output di man:ifconfig[8] avesse mostrato qualcosa di simile a:

[source,shell]
....
dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
                ether 00:a0:cc:da:da:da
....

ciò avrebbe indicato che la scheda non era stata ben configurata.

Per configurare la tua scheda, avrai bisogno dei privilegi di `root`. La configurazione della scheda di rete può essere effettuata da riga di comando con man:ifconfig[8], ma avresti bisogno di farlo ad ogni riavvio del sistema. Il file [.filename]#/etc/rc.conf# è il posto giusto dove scrivere la configurazione della scheda di rete.

Apri [.filename]#/etc/rc.conf# con il tuo editor preferito. Avrai bisogno di aggiungere una riga per ogni scheda di rete presente nel sistema, ad esempio nel nostro caso, abbiamo aggiunto queste linee:

[.programlisting]
....
ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"
ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"
....

Dovrai sostituire [.filename]#dc0#, [.filename]#dc1#, e così via, con i dispositivi corretti per la tua scheda, e gli indirizzi con quelli appropriati. Dovresti leggere le pagine man del driver e di man:ifconfig[8] per maggiori dettagli sulle opzioni permesse ed anche la pagina man di man:rc.conf[5] per maggiori informazioni sulla sintassi di [.filename]#/etc/rc.conf#.

Se hai configurato la rete durante l'installazione, alcune linee relative alle schede di rete potrebbero essere già presenti. Controlla due volte [.filename]#/etc/rc.conf# prima di aggiungere ogni linea.

Avrai anche bisogno di modificare il file [.filename]#/etc/hosts# per aggiungere i nomi e gli IP delle varie macchine della LAN, se non sono già lì. Per maggiori informazioni, fai riferimento a man:hosts[5] ed a [.filename]#/usr/shared/examples/etc/hosts#.

=== Verifica e Risoluzione dei Problemi

Una volta che hai effettuato i cambiamenti necessari a [.filename]#/etc/rc.conf#, dovresti riavviare la macchina. Ciò farà sì che i cambiamenti alle interfacce vengano applicati, e verificherà che il sistema si riavvii senza nessun errore di configurazione.

Una volta che il sistema è stato riavviato, dovresti testare le interfacce di rete.

==== Test della Scheda Ethernet

Per verificare che una scheda Ethernet sia configurata correttamente, si devono provare due cose. Prima, effettuare un ping verso l'interfaccia stessa, e poi un ping verso un'altra macchina sulla LAN.

Prima proviamo l'interfaccia:

[source,shell]
....
% ping -c5 192.168.1.3
PING 192.168.1.3 (192.168.1.3): 56 data bytes
64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms

--- 192.168.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms
....

Ora dobbiamo effettuare un ping verso un'altra macchina della LAN:

[source,shell]
....
% ping -c5 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms

--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms
....

Puoi usare il nome della macchina invece di `192.168.1.2` se hai sistemato il file [.filename]#/etc/hosts#.

==== Risoluzione dei Problemi

Risolvere i problemi delle varie configurazioni hardware e software è sempre una faticaccia, ma è una fatica che può essere diminuita controllando da subito le cose semplici. Avete collegato il cavo di rete? Avete configurato i servizi di rete? Avete configurato il firewall correttamente? La scheda di rete che state usando è supportata da FreeBSD? Controllate sempre le note sul vostro hardware prima di inviare un bug report. Aggiornate la vostra versione di FreeBSD all'ultima versione STABLE disponibile. Controllate gli archivi delle mailing list, o magari cercate su Internet.

Se la scheda funziona, ma le prestazioni sono scadenti, potrebbe esservi utile la lettura della pagina man man:tuning[7]. Potreste anche verificare la vostra configurazione della rete, poichè una configurazione scorretta può essere la causa di connessioni lente.

Alcuni utenti riscontrano dei `device timeouts`, il che è normale per alcune schede. Se questi continuano, o se sono fastidiosi, potreste voler ricontrollare che non ci siano conflitti con altri dispositivi. Controllate due volte la connessione di rete. Forse dovreste procurarvi un'altra scheda.

Alcune volte, gli utenti notano alcuni errori `watchdog timeout`. La prima cosa da fare è controllare il cavo di rete. Alcune schede di rete richiedono uno slot PCI che supporti il Bus Mastering. Su alcune vecchie schede madri, ciò è permesso solo per uno slot PCI (tipicamente lo slot 0). Controllate la documentazione della scheda di rete e della scheda madre per determinare se possa essere quello il problema.

Messaggi `No route to host` vengono generati se il sistema non è in grado di effettuare il routing di un pacchetto verso una certa destinazione. Ciò può accadere se non è specificata una route di default, o se il cavo è scollegato. Controllate l'output di `netstat -rn` ed assicuratevi che ci sia una route valida per l'host che state cercando di raggiungere. Se non c'è, leggete il crossref:advanced-networking[advanced-networking,Networking Avanzato].

I messaggi d'errore `ping: sendto: Permission denied` sono spessi causati da un firewall mal configurato. Se `ipfw` è abilitato nel kernel ma non ci sono regole definite, allora la politica di default è di negare tutto il traffico, comprese le richieste di ping! Leggete il crossref:firewalls[firewalls,Firewall] per maggiori informazioni.

Talvolta le prestazioni della scheda di rete sono scadenti, o sotto la media. In questi casi è preferibile cambiare la selezione del media da `autoselect` ad una selezione corretta. Anche se questo sistema funziona con la maggior parte dell'hardware, potrebbe non risolvere il problema per tutti. Ancora una volta, controllate tutte le impostazioni di rete, e leggete la pagina man man:tuning[7] .

[[configtuning-virtual-hosts]]
== Host Virtuali

Un uso piuttosto comune di FreeBSD è come hosting di siti virtuali, dove un solo server appare alla rete come molti server distinti. Ciò viene effettuato assegnando indirizzi di rete multipli ad una sola interfaccia.

Una data interfaccia di rete ha un solo indirizzo "reale", e può avere un numero qualsiasi di indirizzi "alias". Questi alias vengono normalmente aggiunti mettendo dei campi alias in [.filename]#/etc/rc.conf#.

Un campo alias per l'interfaccia [.filename]#fxp0# appare così:

[.programlisting]
....
ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"
....

Nota che il campo alias deve iniziare con `alias0` e aumentare in ordine, (ad esempio, `_alias1`, `_alias2`, e così via). Il processo di configurazione si fermerà al primo numero mancante.

Il calcolo delle maschere di sotto-rete degli alias è importante, ma, fortunatamente, è anche abbastanza semplice. Per una data interfaccia, deve esserci un indirizzo che rappresenta correttamente la maschera di sotto-rete. Ogni altro indirizzo che ricada in questa rete deve avere una maschera di sotto-rete con tutti `1` (espressi come `255.255.255.255` o `0xffffffff`).

Ad esempio, considera il caso in cui l'interfaccia [.filename]#fxp0# sia connessa a due reti, la rete `10.1.1.0` con maschera di sotto-rete `255.255.255.0` e la rete `202.0.75.16` con maschera di sotto-rete `255.255.255.240`. Vogliamo che il sistema sia visibile come `10.1.1.1` fino a `10.1.1.5` e come `202.0.75.17` fino a `202.0.75.20`. Come notato sopra, solo il primo indirizzo in un dato range di sotto-rete (in questo caso, `10.0.1.1` e `202.0.75.17`) dovrebbe avere una vera netmask; tutto il resto ( `10.1.1.2` fino a `10.1.1.5` e `202.0.75.18` fino a `202.0.75.20`) dovrebbe essere configurato con una netmask di `255.255.255.255`.

Le seguenti righe configurano il dispositivo correttamente per questo scopo:

[.programlisting]
....
 ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
 ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
 ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
 ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
 ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
 ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
 ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
 ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
 ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"
....

[[configtuning-configfiles]]
== File di Configurazione

=== Struttura di [.filename]#/etc#

Ci sono molte directory nelle quali vengono tenute le informazioni di configurazione. Tra queste ci sono:

[.informaltable]
[cols="1,1", frame="none"]
|===

|[.filename]#/etc#
|Informazioni generiche sulla configurazione del sistema; questi dati sono specifici del sistema.

|[.filename]#/etc/defaults#
|Versioni di default dei file di configurazione del sistema.

|[.filename]#/etc/mail#
|Configurazioni extra di man:sendmail[8], o file di configurazione di altri MTA.

|[.filename]#/etc/ppp#
|Configurazione ppp sia per i programmi a livello utente che a livello kernel.

|[.filename]#/etc/namedb#
|Posizione predefinita per i dati di man:named[8]. Normalmente qui si trova [.filename]#named.conf# insieme ai file di zona.

|[.filename]#/usr/local/etc#
|File di configurazione per le applicazioni installate. Può contenere sottodirectory.

|[.filename]#/usr/local/etc/rc.d#
|Script start/stop per i programmi installati.

|[.filename]#/var/db#
|File di dati specifici del sistema generati automaticamente, come il database dei package, il database di locate, e così via.
|===

=== Nomi degli Host

==== [.filename]#/etc/resolv.conf#

[.filename]#/etc/resolv.conf# detta il modo in cui il sistema di risoluzione dei nomi di FreeBSD accede al DNS (Internet Domain Name System).

I campi più comuni in [.filename]#resolv.conf# sono:

[.informaltable]
[cols="1,1", frame="none"]
|===

|`nameserver`
|L'indirizzo IP di un name server al quale dovrà rivolgersi il sistema di risoluzione. I server vengono interrogati nell'ordine in cui sono elencati, fino a un massimo di tre.

|`search`
|Lista di ricerca per i nomi degli host. Normalmente questo viene determinato dal dominio dell'host locale.

|`domain`
|Il nome del dominio locale.
|===

Un [.filename]#resolv.conf# tipico:

[.programlisting]
....
search example.com
nameserver 147.11.1.11
nameserver 147.11.100.30
....

[NOTE]
====
Si dovrebbe usare solo una tra le due opzioni `search` e `domain`.
====

Se stai usando DHCP, man:dhclient[8] generalmente sovrascriverà [.filename]#resolv.conf# con le informazioni ricevute dal server DHCP.

==== [.filename]#/etc/hosts#

[.filename]#/etc/hosts# è un semplice database testuale, reminiscenza della vecchia rete Internet. Esso lavora in congiunzione con DNS e NIS fornendo una mappatura da nome a indirizzo IP. Computer locali connessi ad una LAN possono essere messi in questo file per una gestione semplice dei nomi, invece di mettere su un server man:named[8]. Inoltre, [.filename]#/etc/hosts# può essere usato per fornire un registro locale dei nomi di Internet, riducendo la necessità di effettuare richieste esternamente per i nomi ad accesso frequente.

[.programlisting]
....
# $FreeBSD$
#
# Host Database
# Questo file dovrebbe contenere gli indirizzi e gli alias
# per gli host locali che condividono questo file.
# In presenza di DNS o NIS, questo file potrebbe non essere consultato affatto;
# guarda /etc/nsswitch.conf per l'ordine di risoluzione.
#
#
::1                     localhost localhost.my.domain myname.my.domain
127.0.0.1               localhost localhost.my.domain myname.my.domain

#
# Rete immaginaria.
#10.0.0.2               myname.my.domain myname
#10.0.0.3               myfriend.my.domain myfriend
#
# In accordo all'RFC 1918, puoi usare le seguenti classi di IP per reti private
# che non verranno mai connesse ad Internet:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# In caso volessi essere in grado di collegarti ad Internet, avrai bisogno
# di veri numeri ufficiali assegnati.  PER FAVORE PER FAVORE PER FAVORE
# non tentare di inventarti i numeri della tua rete ma fattene assegnare
# uno dal tuo provider (se ne hai uno) o dall'Internet Registry (ftp su
# rs.internic.net, directory `/templates').
#
....

[.filename]#/etc/hosts# accetta il semplicissimo formato:

[.programlisting]
....
[Indirizzo Internet ] [nome host ufficiale] [alias1] [alias2] ...
....

Ad esempio:

[.programlisting]
....
10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2
....

Consulta man:hosts[5] per maggiori informazioni.

=== Configurazione dei File di Log

==== [.filename]#syslog.conf#

[.filename]#syslog.conf# è il file di configurazione per il programma man:syslogd[8]. Indica quale tipo di messaggi `syslog` verranno scritti su ogni file di log.

[.programlisting]
....
# $FreeBSD$
#
#       Gli spazi SONO validi separatori dei campi in questo file. Ad ogni modo,
#       altri sistemi *nix-like insistono ancora nell'usare tab come separatori
#       di campo. Se condividi questo file tra più sistemi, potresti
#       voler usare solo dei tab come separatori.
#       Consulta la pagina man di syslog.conf(5).
*.err;kern.debug;auth.notice;mail.crit          /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.*                                      /var/log/security
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
cron.*                                          /var/log/cron
*.err                                           root
*.notice;news.err                               root
*.alert                                         root
*.emerg                                         *
# togli il commento a questo per loggare tutte le scritture su /dev/console
# in /var/log/console.log
#console.info                                   /var/log/console.log
# togli il commento a questo per abilitare il logging di tutti i messaggi di log
# su /var/log/all.log
#*.*                                            /var/log/all.log
# togli il commento a questo per abilitare il logging su un host remoto di nome
# loghost
#*.*                                            @loghost
# togli i commenti a questi se hai inn in funzione
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
!startslip
*.*                                             /var/log/slip.log
!ppp
*.*                                             /var/log/ppp.log
....

Consulta la pagina man di man:syslog.conf[5] per maggiori informazioni.

==== [.filename]#newsyslog.conf#

[.filename]#newsyslog.conf# è il file di configurazione di man:newsyslog[8], un programma che normalmente viene eseguito da man:cron[8]. man:newsyslog[8] determina quando i file di log richiedono un'archiviazione o un riordinamento. [.filename]#logfile# viene rinominato in [.filename]#logfile.0#, [.filename]#logfile.0# in [.filename]#logfile.1# e così via. Alternativamente, i file potranno essere archiviati in formato man:gzip[1], e quindi diventeranno: [.filename]#logfile.0.gz#, [.filename]#logfile.1.gz#, e così via.

[.filename]#newsyslog.conf# indica quali file di log devono essere gestiti, quanti devono essere mantenuti, e quando devono essere toccati. I file di log possono essere riordinati e/o archiviati quando raggiungono una certa dimensione, o a una certa data/ora periodica.

[.programlisting]
....
# file di configurazione per newsyslog
# $FreeBSD$
#
# filename          [owner:group]    mode count size when [ZB] [/pid_file] [sig_num]
/var/log/cron                           600  3     100  *     Z
/var/log/amd.log                        644  7     100  *     Z
/var/log/kerberos.log                   644  7     100  *     Z
/var/log/lpd-errs                       644  7     100  *     Z
/var/log/maillog                        644  7     *    @T00  Z
/var/log/sendmail.st                    644  10    *    168   B
/var/log/messages                       644  5     100  *     Z
/var/log/all.log                        600  7     *    @T00  Z
/var/log/slip.log                       600  3     100  *     Z
/var/log/ppp.log                        600  3     100  *     Z
/var/log/security                       600  10    100  *     Z
/var/log/wtmp                           644  3     *    @01T05 B
/var/log/daily.log                      640  7     *    @T00  Z
/var/log/weekly.log                     640  5     1    $W6D0 Z
/var/log/monthly.log                    640  12    *    $M1D0 Z
/var/log/console.log                    640  5     100  *     Z
....

Consulta la pagina man di man:newsyslog[8] per maggiori informazioni.

[[configtuning-sysctlconf]]
=== [.filename]#sysctl.conf#

[.filename]#sysctl.conf# assomiglia molto a [.filename]#rc.conf#. I valori vengono impostati nella forma `variabile=valore`. I valori specificati vengono impostati dopo che il sistema è entrato in modalità multiutente. Non tutte le variabili sono gestibili in questo modo.

Per disabilitare il log sulle uscite dei processi per segnale fatale ed impedire agli utenti di vedere che i processi sono avviati con altre utenze, puoi settare in [.filename]#sysctl.conf# la riga seguente:

[.programlisting]
....
# Do not log fatal signal exits (e.g. sig 11)
kern.logsigexit=0

# Prevent users from seeing information about processes that
# are being run under another UID.
security.bsd.see_other_uids=0
....

[[configtuning-sysctl]]
== Messa a Punto con sysctl

man:sysctl[8] è un'interfaccia che permette di effettuare cambiamenti ad un sistema FreeBSD già attivo. Questo include molte opzioni avanzate dello stack TCP/IP e del sistema di memoria virtuale che possono permettere di migliorare drammaticamente le prestazioni ad un sistemista che abbia esperienza. Più di cinquecento variabili di sistema possono essere lette e modificate usando man:sysctl[8].

In sostanza, man:sysctl[8] serve a due cose: a leggere e a modificare le impostazioni di sistema.

Per visualizzare tutte le variabili leggibili:

[source,shell]
....
% sysctl -a
....

Per leggere una particolare variabile, ad esempio, `kern.maxproc`:

[source,shell]
....
% sysctl kern.maxproc
kern.maxproc: 1044
....

Per impostare una particolare variabile, usa l'intuitiva sintassi _variabile_=_valore_:

[source,shell]
....
# sysctl kern.maxfiles=5000
kern.maxfiles: 2088 -> 5000
....

I valori validi per le variabili di sysctl sono generalmente o stringhe, o numeri, o valori booleani (un valore booleano può valere `1` per sì o `0` per no).

Se vuoi settare in modo automatico alcune variabile ad ogni avvio della macchina, usa il file [.filename]#/etc/sysctl.conf#. Per maggiori informazioni guarda la pagina man di man:sysctl.conf[5] e la <<configtuning-sysctlconf>>.

[[sysctl-readonly]]
=== man:sysctl[8] in sola lettura

In alcuni casi può essere desiderabile modificare i valori di man:sysctl[8] in sola lettura. Anche se questo talvolta è inevitabile, può essere fatto solo con un riavvio.

Ad esempio in alcuni modelli di laptop il dispositivo man:cardbus[4] non effettuerà il controllo sugli intervalli di memoria, e fallirà con errori che assomigliano a questi:

[source,shell]
....
cbb0: Could not map register memory
device_probe_and_attach: cbb0 attach returned 12
....

Casi come il precedente richiedono tipicamente la modifica di alcuni valori predefiniti di man:sysctl[8] che sono impostati come sola lettura. Per superare queste situazioni un utente può mettere degli "OID" di man:sysctl[8] nel proprio [.filename]#/boot/loader.conf.local#. I valori predefiniti sono indicati nel file [.filename]#/boot/defaults/loader.conf#.

Per risolvere i problemi menzionati qui sopra sarà necessario modificare `hw.pci.allow_unsupported_io_range=1` nel file suddetto. Ora man:cardbus[4] funzionerà correttamente.

[[configtuning-disk]]
== Messa a Punto dei Dischi

=== Variabili Sysctl

==== `vfs.vmiodirenable`

La variabile sysctl `vfs.vmiodirenable` può essere impostata a 0 (inattivo) o 1 (attivo); di default è 1. Questa variabile controlla il modo in cui le directory vengono messe nella cache dal sistema. La maggior parte delle directory sono piccole, e usano solo un singolo frammento (tipicamente 1 K) nel file system e meno (tipicamente 512 byte) nella cache. Con questa variabile impostata a 0, il buffer manterrà soltanto un numero fissato di directory nella cache anche se hai una quantità enorme di memoria. Attivando questa sysctl si permette al buffer di usare la VM Page Cache per immagazzinare le directory, rendendo disponibile tutta la memoria disponibile per il caching delle directory. In ogni caso, la minima quantità di memoria usata per memorizzare una directory sarà la dimensione della pagina fisica (in genere 4 K) invece di 512 byte. Noi consigliamo di attivare questa opzione se si hanno in esecuzione dei servizi che manipolano un grosso numero file. Servizi di questo tipo sono le cache web, i grandi sistemi di posta, e quelli di news. Attivare questa opzione in generale non ridurrà le prestazioni nonostante la memoria sprecata, ma dovresti sperimentare tu stesso per verificare.

==== `vfs.write_behind`

La variabile sysctl `vfs.write_behind` ha il valore predefinito di `1` (attivo). Essa dice al file system di effettuare le scritture sul media quando vengono raccolti cluster completi, il che accade tipicamente quando si scrivono grossi file sequenziali. L'idea è di evitare la saturazione del buffer cache con buffer "sporchi" quando le prestazioni dell'I/O non ne trarrebbero giovamento. Ad ogni modo, questo può causare uno stallo dei processi, ed in alcune circostanze potreste desiderare di disabilitarlo.

==== `vfs.hirunningspace`

La variabile sysctl `vfs.hirunningspace` determina quanto grande deve essere la coda I/O in tutti i controller dei dischi nel sistema in un dato momento. Il valore predefinito in genere è sufficiente ma su macchine con molti dischi potreste voler aumentarlo a quattro o cinque _megabyte_. Notate che impostandolo ad un valore troppo alto (superando i limiti della cache) potreste avere delle performance peggiori. Non impostate un valore troppo alto arbitrariamente! Valori più alti aumentano la latenza nelle letture contemporanee.

Ci sono altre sysctl relative alla buffer-cache ed alle cache delle pagine VM. Non vi consigliamo di cambiare questi valori, il sistema di VM fa già un ottimo lavoro di messa a punto automatica.

==== `vm.swap_idle_enabled`

La variabile sysctl `vm.swap_idle_enabled` è utile in grossi sistemi multiutente dove si hanno molti utenti che entrano ed escono lasciando molti processi inattivi. Questi sistemi tendono a generare un grande pressione sulle riserve di memoria libera. Attivando questa caratteristica e manipolando l'isteresi di swap (in secondi di inattività) tramite `vm.swap_idle_threshold1` e `vm.swap_idle_threshold2` potete abbassare la priorità delle pagine di memoria associate con i processi inattivi più velocemente che con il normale algoritmo di paginazione. Ciò dà una mano al demone di paginazione. Non attivate questa opzione a meno che non ne abbiate bisogno, poichè il compromesso che state accettando è essenzialmente di pre-paginare la memoria in anticipo piuttosto che in ritardo, consumando dunque più swap e banda di trasmissione verso il disco. In un piccolo sistema questa opzione avrà un effetto ridotto ma in un grosso sistema che è già sottoposto a un moderato carico di paginazione questa opzione permette al sistema VM di spostare facilmente interi processi dentro e fuori la memoria.

==== `hw.ata.wc`

FreeBSD 4.3 ha giocato un pò con l'idea di disattivare il caching IDE in scrittura. Questo ha ridotto la larghezza di banda in scrittura verso i dischi IDE ma è stato considerato necessario a causa di gravi problemi di consistenza dei dati introdotti dai venditori di dischi rigidi. Il problema è che il disco IDE rimane inattivo dopo che una scrittura è stata completata. Con il caching in scrittura attivo, i dischi IDE non scrivono soltanto i dati sui dischi in maniera disordinata, ma talvolta rimandano la scrittura indefinitamente sotto carichi di lavoro del disco pesanti. Un crash o un calo di tensione possono condurre a seri problemi di corruzione del file system. L'impostazione predefinita di FreeBSD fu cambiata in favore della sicurezza. Sfortunatamente, il risultato è stato una perdita di prestazioni talmente tremenda che abbiamo dovuto reinserire il caching in scrittura di default dopo quella release. Dovresti verificare il valore di default sul tuo sistema osservando la variabile sysctl `hw.ata.wc`. Se il caching IDE in scrittura è disattivato, potete attivarlo reimpostando la variabile del kernel a 1. Questo dovrebbe essere effettuato dal boot loader all'avvio. Tentare di effettuare questo cambiamento dopo che il kernel è stato avviato non avrà nessun effetto.

Per maggiori informazioni, guarda man:ata[4].

==== `SCSI_DELAY` (`kern.cam.scsi_delay`)

La configurazione del kernel `SCSI_DELAY` può ridurre il tempo di avvio del sistema. I valori di default sono piuttosto alti e possono essere responsabili anche di `15` secondi di ritardo nel processo di avvio. Ridurre il valore a `5` secondi funziona in molti casi (specialmente con i dispositivi moderni). Nuove versioni di FreeBSD (5.0 e superiori) dovrebbero essere in grado di usare `kern.cam.scsi_delay` come un'opzione da boot. Quest'ultima e l'opzione di configurazione del kernel accettano valori in _millisecondi_ , e _non_ in _secondi_.

[[soft-updates]]
=== Soft Update

Il programma man:tunefs[8] può essere usato per mettere a punto con accuratezza un file system. Questo programma ha molte opzioni differenti, ma per ora noi ci preoccuperemo solo di attivare e disattivare i Soft Update, che verrà effettuato tramite:

[source,shell]
....
# tunefs -n enable /filesystem
# tunefs -n disable /filesystem
....

Un file system non potrà essere modificato con man:tunefs[8] mentre è montato. Un buon momento per attivare i Soft Update è prima che le partizioni siano montate, in modalità singolo utente.

I Soft Update migliorano drasticamente le prestazioni dei meta-dati, principalmente la creazione e la cancellazione di file, attraverso l'uso di una memoria cache. Consigliamo di attivare i Soft Update su tutti i file system. Ci sono due lati negativi relativi ai Soft Update dei quali dovresti essere a conoscenza: primo, i Soft Update garantiscono la consistenza del file system in caso di crash ma è più che probabile che passino molti secondi (anche un minuto!) prima che venga aggiornato fisicamente il disco. Se il sistema va in crash potresti perdere molto più lavoro in questo modo. Secondo, i Soft Update rallentano la liberazione dei blocchi liberi del file system. Se hai un file system (come il file system root) che è quasi pieno, la realizzazione di un grosso aggiornamento, come un `make installworld`, potrebbe essere causa di un superamento dei limiti di spazio del file system e di un fallimento dell'aggiornamento.

==== Maggiori Dettagli sui Soft Update

Ci sono due approcci tradizionalmente nella scrittura dei meta-dati del file system su disco. (Gli aggiornamenti dei meta-dati sono aggiornamenti ai dati che non sono contenuto, come gli inode o le directory.)

Storicamente, il comportamento predefinito era di scrivere gli aggiornamenti dei meta-dati in maniera sincrona. Se una directory veniva modificata, il sistema attendeva finchè il cambiamento venisse effettivamente scritto su disco. I buffer con i dati dei file (i contenuti dei file) venivano passati attraverso la cache e salvati su disco in seguito, in maniera asincrona. Il vantaggio di questa implementazione è che avviene in maniera sicura. Se si verifica un problema durante un aggiornamento, i meta-dati sono sempre in uno stato consistente. Un file viene creato completamente o non viene creato affatto. Se i blocchi dati di un file non sono riusciti ad uscire dalla cache e arrivare al disco prima del crash, man:fsck[8] è in grado di capirlo e riparare il file system impostando a zero la lunghezza del file. Inoltre, l'implementazione è chiara e semplice. Lo svantaggio è che i cambiamenti dei meta-dati sono lenti. Un `rm -r`, ad esempio, tocca tutti i file in una directory consecutivamente, ma ogni cambiamento della directory (la cancellazione del file) verrà scritto su disco in maniera sincrona. Questo include gli aggiornamenti alla directory stessa, alla tabella degli inode, e magari anche ai blocchi indiretti allocati dal file. Simili considerazioni si applicano nell'elenco di grosse gerarchie (`tar -x`).

Il secondo caso è l'aggiornamento asincrono dei meta-dati. Questo è il comportamento predefinito per Linux/ext2fs e `mount -o async` per *BSD/ufs. Anche tutti gli aggiornamenti dei meta-dati vengono semplicemente fatti passare attraverso la cache, cioè vengono mescolati con gli aggiornamenti dei dati contenuti nel file. Il vantaggio di questa implementazione è che non c'è bisogno di attendere che ogni aggiornamento dei meta-dati venga scritto su disco, dunque tutte le operazioni che causano enormi quantità di aggiornamenti dei meta-dati lavorano molto più velocemente che nel caso sincrono. Inoltre, l'implementazione è ancora semplice e chiara, dunque c'è un basso rischio che si annidino dei bug nel codice. Lo svantaggio è che non c'è nessuna garanzia di uno stato consistente del file system. Se si verifica un problema durante un'operazione che ha aggiornato grandi quantità di meta-dati (ad esempio un abbassamento di tensione, o qualcuno che preme il tasto reset), il file system verrà lasciato in uno stato imprevedibile. Non c'è opportunità di esaminare lo stato del file system quando il sistema viene riavviato; i blocchi dati di un file potrebbero essere già stati scritti sul disco mentre gli aggiornamenti della tabella degli inode o la directory associata non lo sono. È praticamente impossibile implementare un `fsck` che sia in grado di ripulire il caos risultante (perchè i dati necessari non sono disponibili sul disco). Se il file system è stato danneggiato più del riparabile, la sola scelta è di usare man:newfs[8] per ricrearlo e recuperarlo da un backup.

La soluzione comune di questo problema era implementare _la registrazione delle regioni sporche_, a cui spesso si fa riferimento come _journaling_, anche se questo termine non viene usato coerentemente e talvolta viene applicato ad altre forme di logging delle transazioni. Gli aggiornamenti dei meta-dati sono ancora scritti in maniera sincrona, ma solo in una piccola regione del disco. In seguito vengono spostati nella posizione appropriata. Poichè l'area di registrazione è una piccola regione contigua sul disco, non ci sono lunghe distanze da percorrere per le testine del disco, anche durante le operazioni pesanti, dunque queste operazioni sono più veloci degli aggiornamenti sincroni. Inoltre la complessità dell'implementazione è piuttosto limitata, dunque il rischio che si presentino dei bug è basso. Uno svantaggio è che tutti i meta-dati vengono scritti due volte (una volta nella regione di logging ed un'altra nella posizione appropriata) e quindi per un lavoro normale si può avere un "peggioramento" delle prestazioni. D'altro canto, in caso di crash, tutte le operazioni sui meta-dati in sospeso possono essere velocemente annullate o recuperate dall'area di registrazione quando il sistema è di nuovo attivo, e come risultato si ha un avvio veloce del file system.

Kirk McKusick, lo sviluppatore del Berkeley FFS, ha risolto questo problema con i Soft Update: tutti gli aggiornamenti dei meta-dati vengono tenuti in memoria e vengono scritti su disco in sequenza ordinata ("aggiornamenti ordinati dei meta-dati"). Ciò porta all'effetto che, in caso di operazioni pesanti sui meta-dati, gli ultimi aggiornamenti ad un elemento "recuperano" i precedenti se questi sono ancora in memoria e non sono già stati scritti su disco. Dunque tutte le operazioni, diciamo su una directory, vengono effettuate principalmente in memoria prima che l'aggiornamento sia scritto su disco (i blocchi dei dati vengono ordinati in relazione alla loro posizione, in modo che non vengano scritti su disco prima dei loro meta-dati). Se il sistema va in crash, ciò causa un implicito "riavvolgimento del log": tutte le operazioni che non hanno ancora trovato posto sul disco appariranno come mai effettuate. Viene mantenuto uno stato consistente del file system che sarà quello di 30 o 60 secondi prima. L'algoritmo usato garantisce anche che tutte le risorse in uso siano marcate come tali nelle appropriate tabelle di bit: blocchi e inode. Dopo un crash, il solo errore di allocazione è che vengono marcate come "usate" anche risorse che sono effettivamente "libere". man:fsck[8] riconosce questa situazione, e libera le risorse che non sono più in uso. Non c'è pericolo nell'ignorare lo stato di _sporcizia_ del file system dopo un crash montandolo di forza con `mount -f`. Per poter liberare le risorse che potrebbero essere non usate, man:fsck[8] ha bisogno di essere avviato in seguito. Questa è l'idea di un _fsck in background_: all'avvio del sistema, viene registrata solo una _immagine_ del file system. `fsck` può essere eseguito in seguito. Tutti i file system possono essere montati "sporchi", quindi il processo di avvio del sistema procede in modalità multiutente. In seguito, `fsck` viene avviato in background su tutti i file system dove è necessario, per liberare le risorse che potrebbero essere inutilizzate. (I file system che non usano i Soft Updates hanno ancora bisogno del solito `fsck`, comunque.)

Il vantaggio è che le operazioni sui meta-dati sono veloci quasi come gli aggiornamenti asincroni (cioè più veloci che con il _logging_, che deve scrivere i meta-dati due volte). Gli svantaggi sono nella complessità del codice (che implica un maggiore rischio di trovare bug in un'area molto sensibile, essendo legata alla perdita dei dati degli utenti), ed un consumo di memoria maggiore. Inoltre ci sono alcune idiosincrasie alle quali ci si deve abituare. Dopo un crash, lo stato del file system appare in qualche modo "vecchio". In situazioni dove l'approccio sincrono avrebbe causato la permanenza di alcuni file di lunghezza zero dopo un `fsck`, questi file non esistono affatto con un file system con Soft Update, perchè nè i meta-dati nè i contenuti dei file sono mai stati scritti su disco. Lo spazio su disco non viene rilasciato finchè gli aggiornamenti non sono stati scritti su disco, il che può avvenire qualche tempo dopo che è stato eseguito `rm`. Questo potrebbe causare problemi durante l'installazione di grandi quantità di dati su un file system che non avesse abbastanza spazio per contenere tutti i file due volte.

[[configtuning-kernel-limits]]
== Messa a Punto dei Limiti del Kernel

[[file-process-limits]]
=== Limiti dei File/Processi

[[kern-maxfiles]]
==== `kern.maxfiles`

`kern.maxfiles` può essere aumentato o abbassato a seconda dei requisiti del tuo sistema. Questa variabile indica il numero massimo di descrittori di file sul tuo sistema. Quando la tabella dei descrittori di file è piena, apparirà ripetutamente la scritta `file: table is full` nel buffer dei messaggi di sistema, che può essere visualizzato con il comando `dmesg`.

Ogni file, socket, o fifo aperta usa un descrittore di file. Un server di produzione di larga scala può richiedere facilmente molte migliaia di descrittori di file, in relazione al tipo e al numero di servizi in esecuzione insieme.

Nelle vecchie release di FreeBSD, il valore predefinito di `kern.maxfile` viene dettato dall'opzione `maxusers` nel file di configurazione del kernel. `kern.maxfiles` cresce proporzionalmente al valore di `maxusers`. Quando si compila un kernel personalizzato, è una buona idea impostare questa opzione di configurazione del kernel in base agli usi del proprio sistema. Da questo numero, dipendono molti dei limiti predefiniti del kernel. Anche se una macchina in produzione potrebbe non avere effettivamente 256 utenti connessi contemporaneamente, le risorse necessarie potrebbero essere simili a quelle di un server web su larga scala.

A partire da FreeBSD 4.5, `kern.maxusers` è automaticamente dimensionato sulla base della memoria disponibile nel sistema, e può essere determinato a run-time leggendo il valore del sysctl read-only `kern.maxusers`. Alcuni siti richiedono valori minori o maggiori di `kern.maxusers` e questo può essere impostato come un parametro modificabile dal loader; valori di 64, 128 o 256 non sono fuori dal comune. Non raccomandiamo di andare oltre i 256 a meno che non si necessiti di un numero esagerato di file descriptor; molti dei valori modificati nel loro default da `kern.maxusers` possono essere singolarmente sovrascritti a boot-time o a run-time in [.filename]#/boot/loader.conf# (leggi la pagina di manuale man:loader.conf[5] o il file [.filename]#/boot/defaults/loader.conf# per alcuni suggerimenti) o come descritto altrove in questo documento. Sistemi precedenti a FreeBSD 4.4 devono invece impostare questo valore attraverso l'opzione di man:config[8] `maxusers`.

Nelle release precedenti, il sistema setterà in modo automatico `maxusers` se lo imposti a `0`. Quando usi quest'opzione, impostalo almeno a 4, specialmente se stai usando il sistema a finestre X o se compili software. Questo è dovuto al fatto che la tabella più importante settata da `maxusers` è quella relativa al numero massimo di processi, risultato di `20 + 16 * maxusers`, e quindi se setti `maxusers` a 1, puoi avere solo 36 processi in modo simultaneo, inclusi i 18 o più di avvio del sistema e i 15 o più che verranno creati all'avvio del sistema a finestre X. Perfino una semplice attività come la lettura di una pagina man avvia fino a 9 processi per filtrare, decomprimere, e visualizzare la pagina. Settando `maxusers` a 64 avrai fino a 1044 processi simultanei, che dovrebbero essere sufficienti per quasi tutti gli utenti. Ad ogni modo, se vedi il temuto errore  quando tenti di avviare un programma, o se stai usando un server con molti utenti simultanei (come `ftp.FreeBSD.org`), puoi sempre incrementare il numero e ricompilare.

[NOTE]
====
`maxusers` _non_ limita il numero degli utenti che possono loggarsi sulla tua macchina. Semplicemente setta la dimensione di alcune tabelle a un valore ragionevole considerando il numero massimo di utenti che probabilmente avrai sul tuo sistema e quanti processi ognuno di loro avranno in esecuzione. Un'opzione che limita il numero di login remoti simultanei e di terminali windows è crossref:kernelconfig[kernelconfig-ptys,`pseudo-device pty 16`]. Con FreeBSD 5.X, non ti devi preoccupare di questo numero poichè il driver man:pty[4] è "auto-cloning"; semplicemente usa la linea `device pty` nel tuo file di configurazione.
====

==== `kern.ipc.somaxconn`

La variabile sysctl `kern.ipc.somaxconn` limita la dimensione della coda in ascolto per le connessioni TCP. Il valore predefinito è di `128`, generalmente troppo basso per una gestione robusta di nuove connessioni in ambienti come i web server molto carichi. Per tali ambienti, è consigliato aumentare questo valore a `1024` o maggiore. Il demone di servizio può a sua volta limitare la dimensione della coda (e.g. man:sendmail[8], o Apache) ma spesso avrà una direttiva nel proprio file di configurazione per correggere la dimensione della coda. Grosse code di ascolto aiutano anche ad evitare attacchi di tipo Denial of Service ().

[[nmbclusters]]
=== Limiti di Rete

L'opzione di configurazione del kernel `NMBCLUSTERS` decide la quantità di Mbuf di rete disponibili al sistema. Un server molto trafficato con un numero basso di Mbuf ostacolerebbe le possibilità di FreeBSD. Ogni cluster rappresenta approssimativamente 2 K di memoria, dunque un valore di 1024 rappresenta 2 megabyte di memoria del kernel riservata per i buffer di rete. Può essere effettuato un semplice calcolo per capire quanti ne siano necessari. Se hai un web server che arriva al massimo a 1000 connessioni simultanee, ed ogni connessione consuma un buffer di 16 K in ricezione e un altro di 16 K in trasmissione, avrai bisogno approssimativamente di 32 MB di buffer di rete per coprire il web server. Una buona regola generale è di moltiplicare per 2, dunque 2x32 MB / 2 KB = 64 MB / 2 KB = 32768. Consigliamo valori compresi tra 4096 e 32768 per macchine con grandi quantità di memoria. In nessun caso dovreste specificare un valore alto arbitrario per questo parametro, poichè potrebbe portare ad un crash all'avvio. L'opzione `-m` di man:netstat[1] può essere usata per osservare l'uso della rete.

L'opzione del loader `kern.ipc.nmbclusters` può essere usata per impostare questi valori all'avvio. Solo versioni vecchie di FreeBSD richiedono l'uso dell'opzione `NMBCLUSTERS` come configurazione del kernel (man:config[8]).

Per server sotto carico che fanno un uso massiccio della chiamata di sistema man:sendfile[2], potrebbe essere necessario aumentare il numero di buffer man:sendfile[2] tramite l'opzione di configurazione del kernel `NSFBUFS` o impostando il suo valore in [.filename]#/boot/loader.conf# (vedere man:loader[8] per maggiori dettagli). Un indicatore comune che questo parametro deve essere corretto è la comparsa di processi nello stato `sfbufa`. La variabile sysctl `kern.ipc.nsfbufs` è solo un riferimento read-only alla variabile configurata nel kernel. Questo parametro aumenta nominalmente con `kern.maxusers`, in ogni caso potrebbe essere necessario effettuare piccole correzioni per farli concordare.

[IMPORTANT]
====
Anche se un socket è stato segnalato come non-bloccante, richiamando man:sendfile[2] su di esso si potrebbe avere un blocco della chiamata man:sendfile[2] fino a quando non sono disponibili delle `struct sf_buf`.
====

==== `net.inet.ip.portrange.*`

La variabili sysctl `net.inet.ip.portrange.*` controllano i numeri di porta automaticamente assegnate a socket TCP ed UDP. Ci sono tre intervalli: uno basso, uno predefinito, ed uno alto. La maggior parte dei programmi usa l'intervallo predefinito che è controllato da `net.inet.ip.portrange.first` e `net.inet.ip.portrange.last`, che hanno valori predefiniti di 1024 e 5000. Questi intervalli sono usati per le connessioni in uscita, ed è possibile che il sistema esaurisca le porte in alcune circostanze. Ciò accade per lo più quando avete un web proxy molto carico. L'intervallo di porte non è un problema quando si usano server che abbiano per lo più connessioni in ingresso, come i normali web server, o un numero limitato di connessioni in uscita, come i relay di posta. Per situazioni nelle quali potreste terminare le porte, è consigliato aumentare leggermente `net.inet.ip.portrange.last`. Un valore di `10000`, `20000` o `30000` può essere ragionevole. Dovreste anche considerare gli effetti relativi ad un firewall nel cambiare il range di porte. Alcuni firewall potrebbero bloccare grandi intervalli di porte (tipicamente le porte basse) ed aspettarsi che i sistemi usino porte più alte per le connessioni in uscita - per questa ragione si consiglia di non abbassare il valore di `net.inet.ip.portrange.first`.

==== Prodotto del Ritardo di Banda TCP

Il limite del Prodotto del Ritardo di Banda TCP è simile a TCP/Vegas in NetBSD. Può essere abilitato impostando la variabile sysctl `net.inet.tcp.inflight_enable` ad `1`. Il sistema tenterà di calcolare il prodotto del ritardo di banda per ogni connessione e limiterà l'ammontare di dati accodati per la trasmissione su rete al livello migliore per garantire il massimo throughput.

Questa funzionalità è utile quando si inviano dati su modem multipli, su Ethernet Gigabit, o su collegamenti WAN ad alta velocità (o qualsiasi altro collegamento con un alto prodotto a banda di ritardo), in particolar modo se state usando anche il window scaling o se avete configurato una finestra TCP molto ampia. Se abilitate questa opzione, dovreste anche assicurarvi di impostare a `0 net.inet.tcp.inflight_debug` (per disabilitare il debugging), e per un uso di produzione può essere utile impostare `net.inet.tcp.inflight_min` ad almeno `6144`. Notate comunque che impostando dei livelli minimi alti può in pratica disabilitare la limitazione di banda, su alcuni tipi di collegamento. La funzionalità di limitazione della banda riduce la quantità di dati creati in rotte intermedie e fa circolare le code di pacchetti così come riduce la quantità di dati creati nella coda di interfaccia dell'host locale. Con meno pacchetti accodati, le connessioni interattive, specialmente sopra modem lenti, opereranno con lenti _Round Trip Times_ (tempi di andata e ritorno). Comunque, nota che questa feature ha effetto solo sulla trasmissione dati (uploading / lato server). Non ha effetto sulla ricezione (downloading).

Modificare `net.inet.tcp.inflight.stab` non è raccomandato. Questo parametro è di default a 20, rappresentando 2 pacchetti massimi aggiunti al ritardo del prodotto della banda della finestra. La finestra addizionale è richiesta per stabilizzare l'algoritmo e migliorare la risposta alle condizioni che cambiano ma può risultare in tempi lunghi sui ping sopra link lenti (anche se molto più lento di quello che otterresti senza l'algoritmo di inflight). In questi casi, puoi voler ridurre questo parametro a 15, 10 o 5; e puoi anche ridurre `net.inet.tcp.inflight.min` (per esempio, a 3500) per ottenere l'effetto desiderato. Ridurre questi parametri dovrebbe essere fatto solo come ultima spiaggia.

=== Memoria Virtuale

==== `kern.maxvnodes`

Un vnode è la rappresentazione di un file o una directory. Aumentare il numero di vnodi disponibili sul sistema operativo aumenterà l'I/O di disco. Normalmente questo viene gestito dal sistema operativo e non deve essere cambiato. In pochi casi dove l'I/O di disco è un collo di bottiglia ed il sistema sta finendo i suoi vnodi, questo parametro sarà aumentato. L'aumento di RAM libera ed inattiva sarà tenuto in conto.

Per vedere il numero corrente di vnodi in uso:

[source,shell]
....
# sysctl vfs.numvnodes
vfs.numvnodes: 91349
....

Per vedere il numero massimo di vnodi:

[source,shell]
....
# sysctl kern.maxvnodes
kern.maxvnodes: 100000
....

Se l'uso del nodo corrente è vicino alla fine, aumentare `kern.maxvnodes` di un valore di 1.000 è probabilmente una buona idea. Tenete un occhio sul numero di `vfs.numvnodes`. Se scala al massimo, `kern.maxvnodes` dovrà essere incrementato ancora. Dovrebbe essere visibile con man:top[1] uno spostamento nell'uso della memoria. Molta memoria dovrebbe essere attiva.

[[adding-swap-space]]
== Aggiunta di Spazio di Swap

Non importa con quanta cura pianifichi tutto, a volte un sistema non funziona come ti aspetti. Se ti trovi ad avere bisogno di maggiore spazio di swap, è abbastanza semplice aggiungerlo. Ci sono tre modi per aumentare lo spazio di swap: aggiungere un nuovo disco rigido, abilitare lo swap su NFS, e creare un file di swap su una partizione esistente.

Per informazioni su come criptare lo spazio di swap, quali opzioni esistono e perchè dovrebbe essere fatto, vedere la sezione swap-encrypting del Manuale.

[[new-drive-swap]]
=== Swap su un Nuovo Disco Rigido

Il modo migliore per aggiungere dello swap, ovviamente, è usare questa come scusa per aggiungere un altro disco rigido. Puoi sempre aggiungere un nuovo disco, dopo tutto. Se puoi fare così, vai a rileggere la discussione sullo spazio di swap nella <<configtuning-initial>> del Manuale per alcuni suggerimenti su come organizzare al meglio lo spazio di swap.

[[nfs-swap]]
=== Swap su NFS

Lo swap su NFS è consigliato solo se non hai un disco locale su cui realizzare lo swap. Lo swap via NFS è limitato dalla larghezza di banda disponibile sulla rete e aggiunge ulteriore lavoro per il server NFS.

[[create-swapfile]]
=== File di Swap

Puoi creare un file delle dimensioni specifiche per usarlo come file di swap. In questo nostro esempio useremo un file di 64MB chiamato [.filename]#/usr/swap0#. Puoi usare qualsiasi nome vuoi, ovviamente.

.Creare un file di Swap su FreeBSD
[example]
====
. Accertati che il tuo file di configurazione del kernel includa il memory disk driver (man:md[4]). È di default nel kernel [.filename]#GENERIC#.
+
[.programlisting]
....
device   md   # Memory "disks"
....

. Crea un file di swap ([.filename]#/usr/swap0#):
+
[source,shell]
....
# dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
....

. Imposta i permessi appropriati su ([.filename]#/usr/swap0#):
+
[source,shell]
....
# chmod 0600 /usr/swap0
....

. Riavvia la macchina o per abilitare il file di swap immediatamente scrivi:
+
[source,shell]
....
# mdconfig -a -t vnode -f /usr/swap0 -u 0 && swapon /dev/md0
....

====

[[acpi-overview]]
== Gestione dell'Energia e delle Risorse

È importante utilizzare le risorse hardware in maniera efficiente. Prima che ACPI fosse introdotto era difficile e per nulla flessibile per il sistema operativo gestire l'energia e le proprietà termiche del sistema. L'hardware era controllato dal BIOS e quindi l'utente aveva meno controllo e visibilità per il settaggio della gestione dell'energia. Una configurazione limitata era disponibile tramite _Advanced Power Management (APM)_. La gestione dell'energia e delle risorse è uno dei concetti fondamentali di un moderno sistema operativo. Per esempio, puoi far sì che un sistema operativo faccia il monitoraggio dei limiti di sistema (e possibilmente ti avvisi) in caso la temperatura del sistema cresca in maniera incontrollata.

In questa sezione del Manuale di FreeBSD, ti forniremo informazioni esaustive circa ACPI. Alla fine saranno forniti maggiori riferimenti per ulteriori letture.

[[acpi-intro]]
=== Cos'è ACPI?

ACPI (Advanced Configuration and Power Interface) è uno standard scritto da un gruppo di venditori per fornire un'interfaccia standard per risorse hardware e gestione dell'energia (da qui il nome). È un elemento centrale nella _configurazione diretta del sistema operativo e nella gestione dell'energia_, ad esempio: fornisce più controllo e flessibilità al sistema operativo (OS). I sistemi moderni "stressano" i limiti delle interfacce correnti Plug and Play, prima della introduzione di ACPI. ACPI è il diretto successore di APM (Advanced Power Management).

[[acpi-old-spec]]
=== Riassunto della Gestione Avanzata dell'Energia (APM)

La tecnologia _Advanced Power Management (APM)_ controlla l'uso dell'energia di un sistema basandosi sulla sua attività. Il BIOS APM è fornito dal venditore del sistema ed è specifico alla piattaforma hardware. Un driver APM nell'OS media l'accesso all'_Interfaccia Software APM_ che permette la gestione dei livelli di energia. APM dovrebbe essere usato per sistemi prodotti nel o prima dell'anno 2000.

Ci sono quattro problemi maggiori in APM. Primo, la gestione dell'energia è fatta dal BIOS (specifico del venditore) e l'OS non ne ha conoscenza. Un esempio di questo è quando l'utente imposta i valori di pausa per un disco nell'APM BIOS, che quando vengono ecceduti, il BIOS rallenta il disco, senza il consenso dell'OS. Secondo, la logica di APM è integrata nel BIOS, e opera al di fuori lo scopo dell'OS. Questo significa che gli utenti possono riparare i problemi nel loro BIOS APM facendo un flash di una nuova memoria nel ROM; il che è una procedura molto difficile con il pericolo potenziale di lasciare il sistema in uno stato irrecuperabile se fallisce. Terzo, APM è una tecnologia specifica del venditore il che significa che c'è un sacco di duplicazione degli sforzi e bachi trovati nel BIOS di un venditore che non possono essere risolti in altri. In ultima analisi, il BIOS APM non ha abbastanza spazio per implementare una politica sofisticata, o una che può adattarsi molto bene allo scopo della macchina.

_Plug and Play BIOS (PNPBIOS)_ era inaffidabile in molte situazioni. PNPBIOS era una tecnologia a 16 bit, così il sistema operativo doveva usare l'emulazione a 16 bit per "interfacciarsi" con i metodi PNPBIOS.

Il driver APM di FreeBSD è documentato nella pagina di manuale man:apm[4].

[[acpi-config]]
=== Configurare ACPI

Il driver [.filename]#acpi.ko# è caricato di default all'avvio dal man:loader[8] e _non_ dovrebbe essere compilato nel kernel. Il ragionamento dietro a questo è che è più facile lavorare coi moduli, ad esempio se si passa ad un altro [.filename]#acpi.ko# senza fare un rebuild del kernel. Questo ha il vantaggio di rendere il testing più facile. Un altro motivo è che avviare ACPI dopo che un sistema è stato riavviato spesso non funziona bene. Se incontri dei problemi, puoi disabilitare completamente ACPI. Questo driver non dovrebbe e non può essere scaricato perchè il bus di sistema lo usa per diverse interazioni hardware. ACPI può essere disabilitato settando `hint.acpi.0.disabled="1"` in [.filename]#/boot/loader.conf# o al prompt del man:loader[8].

[NOTE]
====
ACPI ed APM non possono coesistere e dovrebbero essere usati separatamente. L'ultimo ad essere caricato terminerà se il driver nota che l'altro è già in funzione.
====

ACPI può essere usato per mettere il sistema in modalità sleep con man:acpiconf[8], l'opzione `-s` ed un'opzione `1-5`. La maggior parte degli utenti avranno bisogno solo di `1` o `3` (sospensione della RAM). L'opzione `5` farà un morbido shutdown che è la stessa azione di:

[source,shell]
....
# halt -p
....

Sono disponibili altre opzioni via man:sysctl[8]. Controlla la pagina man di man:acpi[4] e man:acpiconf[8] per maggiori informazioni.

[[ACPI-debug]]
== Usare e Debuggare ACPI di FreeBSD

ACPI è un modo fondamentalmente nuovo di utilizzare dispositivi, gestire le risorse elettriche, e fornire accesso standardizzato all'hardware gestito precedentemente dal BIOS. Si stanno facendo progressi per far funzionare ACPI su tutti i sistemi, ma continuano ad apparire bachi nel codice del _Linguaggio Macchina ACPI_ (AML), incompletezza nel sottosistema kernel di FreeBSD, e bachi nell'interprete ACPI-CA di Intel(R).

Questo documento è creato per aiutarti ad assistere i manutentori di ACPI di FreeBSD nell'identificare le cause primarie dei problemi che riscontri e debuggare e sviluppare una soluzione. Grazie per l'attenzione e speriamo di poter risolvere i problemi del tuo sistema.

[[ACPI-submitdebug]]
=== Fornire Informazione di Debug

[NOTE]
====
Prima di sottomettere un problema, accertati di avere in esecuzione l'ultima versione del BIOS e, se disponibile, la versione del firmware del controller integrato.
====

Per quelli di voi che vogliono sottomettere un problema subito, per favore inviate la seguente informazione a link:mailto:freebsd-acpi@FreeBSD.org[ freebsd-acpi@FreeBSD.org]:

* Descrizione del comportamento affetto da bachi, inclusi il tipo di sistema ed il modello e tutto quello che fa sì che il baco appaia. Inoltre, per favore annotati il più accuratamente possibile quando il baco è iniziato ad apparire se è nuovo per il tuo sistema.
* L'output del comando man:dmesg[8] dopo `boot -v`, incluso ogni messaggio di errore generato dal tuo sistema mentre investigavi questo baco.
* L'output del comando man:dmesg[8] dopo `boot -v` con ACPI disabilitato, se disabitarlo ti aiuta a rimettere a posto il sistema.
* L'output di `sysctl hw.acpi`. Anche questo è un buon modo di figurarti quali caratteristiche il tuo sistema offre.
* URL dove il tuo _ACPI Source Language_ (ASL) risiede. _Non_ inviare la ASL direttamente alla lista dato che può essere molto grande. Generate una copia della vostra ASL eseguendo questo comando:
+
[source,shell]
....
# acpidump -dt > name-system.asl
....

+ 
(Sostituite _name_ con la vostra login ed il modello/manifattura del _sistema_. Ad esempio [.filename]#njl-FooCoo6000.asl#)

Molti degli sviluppatori seguono la {freebsd-current} ma per favore sottomettete i vostri problemi a {freebsd-acpi} per essere sicuri che siano visti. Per favore siate pazienti, abbiamo tutti lavori full-time altrove. Se i vostri bachi non sono chiarissimi, vi chiederemo di sottomettere un PR attraverso man:send-pr[1]. Quando si invia un PR, per favore includete le stesse informazioni sopracitate. Questo aiuterà a tracciare il problema e risolverlo. Non inviare un PR senza prima inviare una email a {freebsd-acpi}, dato che noi usiamo PR come promemoria di problemi esistenti, non come meccanismo di reporting. È probabile che i vostri problemi siano stati riportati da qualcun altro prima.

[[ACPI-background]]
=== Background

ACPI è presente su tutti i computer moderni che conformi all'architettura ia32(x86), ia64 (Itanium), e amd64 (AMD). L'intero standard ha molte caratteristiche che includono la gestione della performance della CPU, il controllo dei piani energetici, delle zone termiche, delle batterie del sistema, controller incorporati, ed enumerazione dei bus. Molti sistemi implementano meno dello standard completo. Per esempio, un sistema desktop di solito implementa le parti di enumerazione dei bus mentre un laptop potrebbe avere il raffreddamento ed anche il supporto alla gestione della batteria. I laptop hanno anche sospensioni e riavvii, con la loro complessità associata.

Un sistema ACPI-compliant ha molte componenti. Il BIOS ed i venditori di chipset forniscono varie tabelle fisse in memoria (ad esempio FADT) che specificano cose come la mappa APIC (usata per SMP), i registri di configurazione, e semplici valori di configurazione. Inoltre viene fornita una tabella di codici di byte (la _Differentiated System Description Table_ DSDT) per specificare uno spazio dei nomi ad albero di dispositivi e metodi.

Il driver ACPI deve fare il parse delle tabelle fisse, implementare un interprete per il codice di byte, e modificare i device driver ed il kernel per accettare informazioni dal sottosistema ACPI. Per FreeBSD, Intel(R) ha fornito un interprete (ACPI-CA) che è condiviso fra Linux e NetBSD. Il path al codice sorgente ACPI-CA è [.filename]#src/sys/contrib/dev/acpica#. Il codice che permette ad ACPI-CA di lavorare con FreeBSD è in [.filename]#src/sys/dev/acpica/Osd#. Finalmente, i driver che implementano vari dispositivi ACPI si trovano in [.filename]#src/sys/dev/acpica#.

[[ACPI-comprob]]
=== Problemi Comuni

Affincè ACPI funzioni correttamente tutte le parti devono funzionare correttamente. Ci sono alcuni problemi comuni, in ordine di frequenza di apparizione, ed alcuni possibili workaround o mezzi per aggiustarli.

==== Questioni di Mouse

In alcuni casi, ripartire dopo una operazione di sospensione, fa sì che il mouse non riparta. Un noto workaround è aggiungere `hint.psm.0.flags="0x3000"` al file [.filename]#/boot/loader.conf#. Se questo non funziona allora per favore considera l'invio di un report del baco come descritto in precedenza.

==== Sospensione/Riavvio

ACPI ha tre stati di sospensione RAM (STR), `S1`-`S3` ed un stato di sospensione disco (`STD`), chiamato `S4`. `S5` è il "soft off" ed è il normale stato in cui il tuo sistema si trova quando è collegato ma non acceso. `S4` può essere implementato in due modi separati. ``S4``BIOS è una sospensione BIOS-assistita da disco. ``S4``OS è implementato direttamente dal sistema operativo.

Inizia a controllare `sysctl hw.acpi` per le entry relative alla sospensione. Questi sono i risultati per un Thinkpad:

[source,shell]
....
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0
....

Questo significa che possiamo usare `acpiconf -s` per testare `S3`, ``S4``OS, `S5`. Se `s4bios` fosse stato uno (`1`), avremmo supporto a ``S4``BIOS invece di ``S4``OS.

Quando si testa la sospensione/riavvio, inizia con `S1`, se supportato. È più probabile che funzioni questo stato dato che non richiede molto supporto dal driver. Nessuno ha implementato `S2`, ma se tu lo hai, è simile a `S1`. La prossima cosa da provare è `S3`. Questo è lo stato più profondo STR e richiede molto supporto dal driver per reinizializzare il tuo hardware. Se hai problemi a riavviarlo, sentiti libero di segnalarlo via mail alla lista {freebsd-acpi} ma non aspettarti che il problema sia risolto dato che ci sono molti driver/hardware che hanno bisogno di test e di lavoro aggiuntivo.

Per aiutare ad isolare il problema, rimuovi quanti più driver possibile dal tuo kernel. Se funziona, puoi scoprire quale driver causa il problema caricando dei driver fino a che il problema si ripresenta. Tipicamente i driver binari come [.filename]#nvidia.ko#, i driver di display di X11, e USB avranno la maggior parte dei problemi mentre interfacce Ethernet funzioneranno bene. Se puoi caricare/scaricare driver correttamente, puoi automatizzare questo piazzando i comandi appropriati in [.filename]#/etc/rc.suspend# e [.filename]#/etc/rc.resume#. C'è un esempio commentato su come caricare e scaricare un driver. Prova a impostare `hw.acpi.reset_video` a zero (`0`) se il tuo display è confuso dopo il riavvio. Prova a impostare valori più lunghi o corti per `hw.acpi.sleep_delay` per vedere se aiuta.

Un'altra cosa da provare è caricare una distribuzione Linux recente con supporto ACPI e testare il loro supporto sospensione/riavvio sullo stesso hardware. Se funziona su Linux, è probabile che sia un problema driver relativo a FreeBSD e restringere il campo di indagine su quale driver causi il problema può aiutare a risolvere il problema. Notate che i manutentori di ACPI non mantengono altri driver (ad esempio suono, ATA, etc.) così ogni lavoro fatto sull'identificazione del problema del driver dovrebbe alla fine essere risolto dalla lista {freebsd-current} e inviato via mail al manutentore del driver. Se ti senti avventuroso, vai avanti e inizia a porre qualche man:printf[3] in un driver che dà problemi per tracciare in quale driver nella sua funzione di resume vada in palla.

Alla fine, cerca di disabilitare ACPI ed ad abilitare APM invece. Se la sospensione ed il riavvio funziona con APM, è meglio che tu continui con APM, specialmente su hardware vecchio (pre-2000). Ci vuole un pò di tempo per i venditori per ottenere un supporto corretto all'ACPI e l'hardware più vecchio è più probabile che abbia problemi BIOS con ACPI.

==== Blocco del Sistema (temporanea o permanente)

La maggior parte dei blocchisono causati da interrupt persi o da una tempesta di interrupt. I chipset hanno un sacco di problemi su come il BIOS configuri gli interrupt prima del boot, la correttezza delle tabelle ACPI (MADT) ed il routing del _System Control Interrupt_ (SCI).

Le tempeste di interrupt possono essere distinte da interrupt persi controllando l'output di `vmstat -i` e guardando alla linea che riguarda `acpi0`. Se il contatore sta avanzando più di un paio di secondi per volta, hai una tempesta di interrupt. Se il sistema si blocca, cerca di di entrare in DDB (kbd:[CTRL+ALT+ESC] sulla console) e digita `show interrupts`.

Il modo migliore in caso di problemi di interrupt è provare a disabilitare il supporto APIC con `hint.apic.0.disabled="1"` in [.filename]#loader.conf#.

==== Panici

I panici sono relativamente rari per ACPI e sono il primo problema ad essere corretto. Il primo passo da fare è riprodurre il panico (se possibile) ed ottenere un backtrace. Segui l'avvertimento per abilitare `options DDB` e imposta una console seriale (vedi la crossref:serialcomms[serialconsole-ddb,Accesso al Debugger DDB dalla Linea Seriale]) o imposta una partizione di man:dump[8]. Puoi ottenere un backtrace in DDB con `tr`. Se hai scritto a mano il backtrace, accertati di ottenere le ultime cinque (5) e le prime cinque (5) linee nella traccia.

Poi, prova ad isolare il problema facendo boot con ACPI disabilitato. Se funziona, puoi isolare il sottosistema ACPI usando vari valori di `debug.acpi.disable`. Leggi la pagina di manuale di man:acpi[4] per alcuni esempi.

==== Riavvii di sistema dopo Sospensioni o Spegnimenti

Prima, cerca di impostare `hw.acpi.disable_on_poweroff="0"` in man:loader.conf[5]. Questo fa sì che ACPI abbia disabilitato alcuni eventi durante il processo di shutdown. Alcuni sistemi hanno bisogno di impostare questo valore a `1` (il default) per la stessa ragione. Questo di solito aggiusta il problema di un sistema che si accende spontaneamente dopo una sospensione o uno spegnimento.

==== Altri problemi

Se hai altri problemi con ACPI (lavorare con un docking station, dispositivi non trovati, ecc.), per favore invia via mail una descrizione anche alla mailing list; comunque, alcune di queste questioni possono essere correlate a parti del sottosistema ACPI così può volerci un pò prima che siano implementate. Per favore sii paziente e preparato a testare le patch che ti vengono inviate.

[[ACPI-aslanddump]]
=== ASL, `acpidump`, e IASL

Il più comune problema è il BIOS di venditori che forniscono bytecode incorretto (o addirittura con bachi). Questo si deduce usualmente da messaggi del kernel come questo:

[source,shell]
....
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
(Node 0xc3f6d160), AE_NOT_FOUND
....

Spesso puoi risolvere questi problemi aggiornando il tuo BIOS all'ultima versione. La maggior parte dei messaggi di console non indica nulla di notevole, ma se hai altri problemi come lo stato della batteria non funzionante, questi sono un buon inizio per iniziare a cercare problemi in AML. Il bytecode, noto come AML, è compilato da un insieme di codici sorgenti chiamato ASL. L'AML, è trovato nella tabella nota come come DSDT. Per trovare una copia del tuo ASL usa man:acpidump[8]. Dovresti usare entrambe le opzioni `-t` (mostra i contenuti della tabella fissa) e la `-d` (disassembla AML ad ASL). Vedi la sezione <<ACPI-submitdebug,Fornire Informazione di Debug>> per un esempio della sintassi.

Il tuo primo controllo che puoi fare è ricompilare il tuo ASL per controllare errori. Possono essere ignorati i 'warning' ma gli errori sono bachi che impediranno all'ACPI di funzionare correttamente. Per ricompilare il tuo ASL, usa il comando seguente:

[source,shell]
....
# iasl your.asl
....

[[ACPI-fixasl]]
=== Aggiustare il tuo ASL

Alla lunga, il nostro obiettivo è avere ACPI che funzioni per tutti senza intervento. A questo punto, comunque stiamo ancora sviluppando workaround per errori comuni fatti dal venditore del BIOS. L'interprete Microsoft(R) ([.filename]#acpi.sys# e [.filename]#acpiec.sys#) non è strettamente conforme agli standard, e così molti venditori BIOS che testano solo ACPI sotto Windows(R) non aggiustano mai il loro ASL. Vogliamo continuare a identificare e documentare esattamente quali comportamenti non standard sono concessi dall'interprete Microsoft(R) e replicarlo cosicchè FreeBSD può funzionare senza forzare gli utenti ad usare ASL. Come workaround e per aiutarci ad identificare il comportamento puoi fissare la ASL manualmente. Se questo funziona per favore invia un man:diff[1] del vecchio e del nuovo ASL, cosicchè possiamo lavorare attorno al comportamento bacato di ACPI-CA e così rimettere a posto il necessario.

Qui c'è una lista di messaggi di errori comuni, le loro cause e come fissarli:

==== Dipendenze OS

Alcuni AML assumono che il mondo consiste di varie versioni Windows(R). Puoi far sì che FreeBSD simuli qualsiasi OS per vedere se questo risolve il problema che hai. Un modo facile per sovrascrivere questo è porre `hw.acpi.osname="Windows 2001"` in [.filename]#/boot/loader.conf# o altre stringhe simili che trovi nella ASL.

==== Valori di Ritorno Mancanti

Alcuni metodi non ritornano esplicitamente un valore come i requisiti standard. Mentre ACPI-CA non gestisce questo, FreeBSD ha un workaround che permette di ritornare i valori implicitamente. Puoi anche aggiungere espliciti Valori di Ritorno dove si richiede se sai quale valore dovrebbe essere ritornato. Per forzare `iasl` a compilare l'ASL usa il flag `-f`.

==== Sovrascrivere il Default AML

Dopo che personalizzi il tuo [.filename]#your.asl#, potresti volerlo compilare, esegui:

[source,shell]
....
# iasl your.asl
....

Puoi aggiungere il flag `-f` per forzare la creazione dell'AML, anche se ci sono errori durante la compilazione. Ricorda che alcuni errori (ad esempio valori di Ritorno mancanti) sono automaticamente riaggiustati dall'interprete.

[.filename]#DSDT.aml# è il nome del file di default del comando `iasl`. Puoi caricare questo invece della copia difettosa del tuo BIOS (che è ancora presente in memoria) editando il file [.filename]#/boot/loader.conf# come segue:

[.programlisting]
....
acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"
....

Assicurati di copiare il tuo file [.filename]#DSDT.aml# nella directory [.filename]#/boot#.

[[ACPI-debugpoint]]
=== Ottenere Output di Debug da ACPI

Il driver ACPI ha una facility di debug molto utile. Permette di specificare un insieme di sottosistemi come anche un livello di verbosità. I sottosistemi che desideri debuggare sono specificati come "strati" e sono divisi in componenti ACPI-CA (ACPI_ALL_COMPONENTS) e supporto hardware ACPI (ACPI_ALL_DRIVERS). La verbosità dell'output di debug è specificata come "livello" e varia da ACPI_LV_ERROR (riporta solo gli errori) ad ACIP_LV_VERBOSE (tutto). Il "livello" è una bitmask che fa sì che molte opzioni possano essere impostate una alla volta, separate da spazi. In pratica, puoi usare una console seriale per loggare l'output se è così lungo da riempire il buffer di messaggi della console. Una lista completa degli strati individuali e dei livelli è disponibile nella pagina man man:acpi[4].

L'output di debug non è abilitato di default. Per abilitarlo, aggiungi `options ACPI_DEBUG` al tuo file di configurazione del kernel se ACPI è compilato nel kernel. Puoi aggiungere `ACPI_DEBUG=1` al tuo [.filename]#/etc/make.conf# per abilitarlo in modo globale. Se è un modulo, puoi ricompilare soltanto il tuo modulo [.filename]#acpi.ko# come segue:

[source,shell]
....
# cd /sys/modules/acpi/acpi
&& make clean &&
make ACPI_DEBUG=1
....

Installa [.filename]#acpi.ko# in [.filename]#/boot/kernel# ed aggiungi il tuo livello desiderato e gli strati in [.filename]#loader.conf#. Questo esempio abilita i messaggi per tutti i componenti ACPI-CA e tutti i driver hardware ACPI (CPU, LID, etc.). Produrrà solo messaggi di errore, i meno verbosi.

[.programlisting]
....
debug.acpi.layer="ACPI_ALL_COMPONENENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"
....

Se l'informazione che vuoi ottenere è prodotta da un evento specifico (ad esempio, una sospensione ed un riavvio), puoi tralasciare i cambiamenti di [.filename]#loader.conf# ed invece usare `sysctl` per specificare lo strato ed il livello dopo il boot e preparare il tuo sistema per l'evento specifico. I `sysctl` sono nominati allo stesso modo dei parametri in [.filename]#loader.conf#.

[[ACPI-References]]
=== Riferimenti

Maggiori informazioni su ACPI possono essere trovate nei seguenti posti:

* La {freebsd-acpi}
* Gli archivi della mailing list ACPI http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/]
* I vecchi archivi della mailing list ACPI http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/]
* La specificazione ACPI 2.0 http://acpi.info/spec.htm[http://acpi.info/spec.htm]
* Le pagine man di FreeBSD: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8]
* http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[ Le risorse di debugging di DSDT]. (Usa Compaq come esempio ma è sempre utile.)