<?xml version="1.0" encoding="iso-8859-15"?>
<!--
The FreeBSD Italian Documentation Project
$FreeBSD$
Original revision: 1.102
-->
<chapter id="network-servers">
<chapterinfo>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Riorganizzato da </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Server di rete</title>
<sect1 id="network-servers-synopsis">
<title>Sinossi</title>
<para>Questo capitolo coprirà alcuni dei servizi di rete usati
più di frequente sui sistemi &unix;. Fra gli argomenti
toccati, ci saranno l'installazione, la configurazione,
il test ed la manutenzione di molti tipi diversi di
servizi di rete. Per vostro beneficio
in tutto il capitolo saranno inclusi file di
configurazione di esempio.</para>
<para>Dopo aver letto questo capitolo, sarai in grado
di:</para>
<itemizedlist>
<listitem>
<para>Gestire il demone <application>inetd</application>.</para>
</listitem>
<listitem>
<para>Installare un file system di rete.</para>
</listitem>
<listitem>
<para>Installare un server NIS per condividere
account utenti.</para>
</listitem>
<listitem>
<para>Installare impostazioni automatiche di rete usando DHCP.</para>
</listitem>
<listitem>
<para>Installare un server di risoluzione dei nomi.</para>
</listitem>
<listitem>
<para>Installare il server HTTP
<application>Apache</application>.</para>
</listitem>
<listitem>
<para>Installare un File Transfer Protocol (FTP) Server.</para>
</listitem>
<listitem>
<para>Installare un file server e server di stampa per client
&windows; usando <application>Samba</application>.</para>
</listitem>
<listitem>
<para>Sincronizzare la data e l'ora ed installare un
time server, col protocollo NTP.</para>
</listitem>
</itemizedlist>
<para>Prima di leggere questo capitolo, dovresti:</para>
<itemizedlist>
<listitem>
<para>Comprendere le basi dell'organizzazione degli scripts
<filename>/etc/rc</filename>.</para>
</listitem>
<listitem>
<para>Avere familiarità con la terminologia di rete di
base.</para>
</listitem>
<listitem>
<para>Sapere come installare software aggiuntivo di terze parti
(<xref linkend="ports"/>).</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="network-inetd">
<sect1info>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<contrib>Aggiornato per &os; 6.1-RELEASE da </contrib>
<othername>The &os; Documentation Project</othername>
</author>
</authorgroup>
</sect1info>
<title>Il
<quote>Super-Server</quote> <application>inetd</application></title>
<sect2 id="network-inetd-overview">
<title>Uno sguardo d'insieme</title>
<para>&man.inetd.8; viene talvolta definito l'<quote>Internet
Super-Server</quote> perchè gestisce le connessioni verso
molti servizi. Quando una connessione
viene ricevuta da <application>inetd</application>, questo
determina per quale programma la connessione sia
destinata, esegue quel particolare processo e affida a
lui la socket (il programma è invocato con la socket
del servizio come descrittore di standard input, output
ed error). Eseguire <application>inetd</application>
per server dal carico non troppo alto può ridurre il carico
complessivo di sistema, rispetto all'esecuzione individuale
di ogni demone in modalità stand-alone.</para>
<para>Principalmente, <application>inetd</application> è
usato per lanciare altri demoni, ma molti protocolli
triviali sono gestiti direttamente, come ad esempio
i protocolli <application>chargen</application>,
<application>auth</application>, e
<application>daytime</application>.</para>
<para>Questa sezione coprirà le basi della configurazione
di <application>inetd</application> attraverso le
opzioni da linea di comando
ed il suo file di configurazione,
<filename>/etc/inetd.conf</filename>.</para>
</sect2>
<sect2 id="network-inetd-settings">
<title>Impostazioni</title>
<para><application>inetd</application> viene inizializzato
attraverso il sistema &man.rc.8;.
L'opzione <literal>inetd_enable</literal> è
impostata a <literal>NO</literal> di default, ma può essere
attivata da <application>sysinstall</application>
durante l'installazione, a seconda della configurazione
scelta dall'utente. Inserendo:</para>
<programlisting>inetd_enable="YES"</programlisting>
<para>o</para>
<programlisting>inetd_enable="NO"</programlisting>
<para>in
<filename>/etc/rc.conf</filename> si abiliterà o meno
la partenza di
<application>inetd</application> al boot.
Il comando:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/inetd rcvar</userinput></screen>
<para>può essere utilizzato per mostrare le impostazioni
attive al momento.</para>
<para>Inoltre, diverse opzioni di linea di comando possono
essere passate a <application>inetd</application> attraverso
l'opzione <literal>inetd_flags</literal>.</para>
</sect2>
<sect2 id="network-inetd-cmdline">
<title>Opzioni su linea di comando</title>
<para>Come molti server di rete, <application>inetd</application>
ha un numero di opzioni che possono essergli passate
per modificare il suo comportamento. La lista di tutte le opzioni è:</para>
<para><application>inetd</application> synopsis:</para>
<para><option>inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate]
[-a address | hostname] [-p filename] [-R rate] [configuration
file]</option></para>
<para>Si possono passare opzioni ad <application>inetd</application> usando
l'opzione <literal>inetd_flags</literal> in
<filename>/etc/rc.conf</filename>. Di default,
<literal>inetd_flags</literal> è impostato a
<literal>-wW -C 60</literal>, il che attiva il TCP wrapping per i servizi di
<application>inetd</application>, ed impedisce ad ogni singolo
indirizzo IP di richiedere qualsiasi servizio piùdi 60 volte
al minuto.</para>
<para>Gli utenti novizi possono notare con piacere che
questi parametri di solito non devono essere modificati,
anche se bisogna menzionare il fatto che le opzioni di
limitazione delle connessioni sono utili solo se ci si accorge
di ricevere un numero eccessivo di connessioni. L'intera lista
delle opzioni di &man.inetd.8; può essere trovata
nel manuale di &man.inetd.8;.</para>
<variablelist>
<varlistentry>
<term>-c maximum</term>
<listitem>
<para>Specifica il numero massimo di invocazioni simultanee
per ogni servizio; il default è illimitato.
Può essere sovrascritto per ogni servizio dal
parametro <option>max-child</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-C rate</term>
<listitem>
<para>Specifica un numero massimo di volte in cui
un servizio può essere invocato da un singolo
indirizzo IP in un
minuto; il default è illimitato. Può essere
sovrascritto per ogni servizio con il parametro
<option>max-connections-per-ip-per-minute</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-R rate</term>
<listitem>
<para>Specifica il numero massimo di volte che un servizio
può essere invocato in un minuto; il default è
256. L'impostazione 0 permette un numero illimitato di
invocazioni.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-s maximum</term>
<listitem>
<para>Specifica il numero massimo di volte
che un servizio può essere invocato per ogni periodo di
tempo; il default è illimitato. Può essere sovrascritto
per ogni singolo servizio con il parametro <option>max-child-per-ip</option>.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="network-inetd-conf">
<title><filename>inetd.conf</filename></title>
<para> La configurazione di <application>inetd</application>
è fatta attraverso il file
<filename>/etc/inetd.conf</filename>.</para>
<para>Quando viene apportata una modifica a
<filename>/etc/inetd.conf</filename>,
si può forzare <application>inetd</application>
a rileggere il suo file di configurazione
eseguendo il comando:</para>
<example id="network-inetd-reread">
<title>Ricaricare il file di configurazione
di <application>inetd</application>
</title>
<screen>&prompt.root; <userinput>/etc/rc.d/inetd reload </userinput></screen>
</example>
<para>Ogni linea del file di configurazione specifica un
singolo demone. I commenti nel file sono preceduti da un
<quote>#</quote>. Il formato di ogni riga del file
<filename>/etc/inetd.conf</filename> è il seguente:</para>
<programlisting>nome del servizio
tipo della socket
protocollo
{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]
utente[:gruppo][/classe-di-login]
programma-server
argomenti-del-programma-server</programlisting>
<para>Un esempio di linea per il
demone &man.ftpd.8;
usando l'IPv4:</para>
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
<variablelist>
<varlistentry>
<term>nome-del-servizio</term>
<listitem>
<para>È il nome del servizio per il demone.
Deve corrispondere ad un servizio elencato in
<filename>/etc/services</filename>. Questo
determina su quale porta
<application>inetd</application> deve restare
in ascolto. Se viene creato un nuovo servizio,
deve essere messo prima
in <filename>/etc/services</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tipo-di-socket</term>
<listitem>
<para>Una a scelta fra <literal>stream</literal>,
<literal>dgram</literal>, <literal>raw</literal>, o
<literal>seqpacket</literal>.
<literal>stream</literal>
deve essere usata per demoni basati sulla
connessione, tipo TCP, mentre
<literal>dgram</literal> è usato per demoni che usano
il protocollo di trasporto <acronym>UDP</acronym>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>protocollo</term>
<listitem>
<para>Uno dei seguenti:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Protocollo</entry>
<entry>Spiegazione</entry>
</row>
</thead>
<tbody>
<row>
<entry>tcp, tcp4</entry>
<entry>TCP IPv4</entry>
</row>
<row>
<entry>udp, udp4</entry>
<entry>UDP IPv4</entry>
</row>
<row>
<entry>tcp6</entry>
<entry>TCP IPv6</entry>
</row>
<row>
<entry>udp6</entry>
<entry>UDP IPv6</entry>
</row>
<row>
<entry>tcp46</entry>
<entry>Entrambi TCP IPv4 e v6</entry>
</row>
<row>
<entry>udp46</entry>
<entry>Entrambi UDP IPv4 e v6</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</listitem>
</varlistentry>
<varlistentry>
<term>{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]</term>
<listitem>
<para><option>wait|nowait</option> indica se il demone
invocato da <application>inetd</application> è
in grado di gestire la sua socket o meno.
Il tipo di socket <option>dgram</option> deve usare
l'opzione <option>wait</option>, mentre i demoni
con socket stream,
che sono in genere multi-thread, devono usare
<option>nowait</option>. <option>wait</option> in
genere fornisce socket multiple ad un singolo demone,
mentre <option>nowait</option> lancia un demone figlio
per ogni nuova socket.</para>
<para>Il massimo numero di demoni figli che
<application>inetd</application> può lanciare si imposta
attraverso l'opzione <option>max-child</option>.
Se è richiesto un limite di dieci istanze per un
particolare demone, un
<literal>/10</literal> dovrebbe essere inserito
dopo l'opzione <option>nowait</option>. Specificando
<literal>/0</literal> si lascia un numero illimitato di figli.</para>
<para>Oltre all'opzione <option>max-child</option>,
possono essere attivate due altre opzioni che limitano
il massimo numero di connessioni da un singolo ip
verso un particolare demone.
<option>max-connections-per-ip-per-minute</option> limita
il numero di connessioni da un particolare indirizzo IP per
minuto, ad esempio un valore di dieci limiterebbe ogni
singolo indirizzo IP a connettersi verso un certo servizio
a dieci connessioni al minuto.
<option>max-child-per-ip</option>
limita il numero di figli che possono essere avviati su richiesta
di un singolo indirizzo IP in ogni momento.
Queste opzioni sono utili per prevenire
eccessivo consumo delle risorse intenzionale o non intenzionale
e attacchi Denial of Service (DoS) ad una macchina.</para>
<para>In questo campo, <option>wait</option> o
<option>nowait</option> sono obbligatorie.
<option>max-child</option> e
<option>max-connections-per-ip-per-minute</option>
e <option>max-child-per-ip</option> sono
opzionali.</para>
<para>Un demone tipo-stream multi-thread senza
i limiti <option>max-child</option> o
<option>max-connections-per-ip-per-minute</option>
dovrebbe essere semplicemente:
<literal>nowait</literal>.</para>
<para>Lo stesso demone con un limite massimo di
dieci demoni dovrebbe avere:
<literal>nowait/10</literal>.</para>
<para>In aggiunta, la stessa impostazione con
un limite di venti connessioni per IP al
minuto ed un limite massimo di
dieci demoni figli avrebbe:
<literal>nowait/10/20</literal>.</para>
<para>Queste opzioni sono tutte utilizzate
di default nelle impostazioni del demone
&man.fingerd.8; come si vede di seguito:</para>
<programlisting>finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s</programlisting>
<para>Alla fine, un esempio di questo campo
con 100 figli in tutto, con un massimo di 5 per singolo
indirizzo IP sarebbe:
<literal>nowait/100/0/5</literal>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>user</term>
<listitem>
<para>Questo è lo username sotto il quale un
particolare demone dovrebbe girare. Di
frequente, i demoni girano
come utente <username>root</username>.
Per motivi di sicurezza, è normale
trovare alcuni server che girano con l'utente
<username>daemon</username>, o il meno privilegiato
utente <username>nobody</username>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>server-program</term>
<listitem>
<para>Il percorso assoluto del demone che deve essere
eseguito quando è ricevuta una connessione . Se
il demone è un servizio
offerto da <application>inetd</application> internamente,
bisogna usare <option>internal</option>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>server-program-arguments</term>
<listitem>
<para>Questa opzione funziona in congiunzione con
<option>server-program</option> specificando gli
argomenti, cominciando con <literal>argv[0]</literal>,
passati al demone al momento dell'invocazione.
Se <command>mydaemon -d</command> è la linea di comando,
<literal>mydaemon -d</literal> sarà il valore
dell'opzione <option>server-program-arguments</option>.
Ancora, se un demone è un servizio interno,
usa <option>internal</option>.</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
<sect2 id="network-inetd-security">
<title>Sicurezza</title>
<para>A seconda delle scelte fatte all'installazione,
molti servizi di <application>inetd</application>
potrebbero essere attivi di default. Se
non c'è necessità
apparente per un particolare demone,
considera di disabilitarlo. Usa un <quote>#</quote> a capo della
riga del demone in questione in <filename>/etc/inetd.conf</filename>,
e quindi <link linkend="network-inetd-reread">ricarica la
configurazione di inetd</link>. Alcuni demoni, come
<application>fingerd</application>, potrebbero
non essere assolutamente desiderati,
poichè forniscono all'attaccante informazioni che gli potrebbero
risultare utili.</para>
<para>Alcuni demoni non sono stati creati coll'obiettivo
della sicurezza ed hanno timeout lunghi, o non esistenti.
Questo permette ad un attaccante di inviare
lentamente connessioni
ad un particolare demone, saturando in questo modo
le risorse disponibile. Può essere una buona idea
impostare le limitazioni
<option>max-connections-per-ip-per-minute</option> e
<option>max-child</option> o <option>max-child-per-ip</option> su certi
demoni se scopri di avere troppe connessioni.</para>
<para>Di default, il TCP wrapping è attivo.
Consulta la pagina del manuale
di &man.hosts.access.5; per impostare
delle restrizioni TCP su certi demoni
invocati da <application>inetd</application>.</para>
</sect2>
<sect2 id="network-inetd-misc">
<title>Miscellanei</title>
<para><application>daytime</application>,
<application>time</application>,
<application>echo</application>,
<application>discard</application>,
<application>chargen</application>, e
<application>auth</application> sono tutti servizi interni
di <application>inetd</application>.</para>
<para>Il servizio <application>auth</application>
fornisce servizi di rete di identificazione
ed è configurabile fino ad un certo punto,
mentre gli altri possono solo essere accesi o spenti.</para>
<para>Consulta la paigna di manuale di &man.inetd.8;
per dettagli più approfonditi.</para>
</sect2>
</sect1>
<sect1 id="network-nfs">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Riorganizzato e migliorato da </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Bill</firstname>
<surname>Swingle</surname>
<contrib>Scritto da </contrib>
</author>
</authorgroup>
</sect1info>
<title>Network File System (NFS)</title>
<indexterm><primary>NFS</primary></indexterm>
<para>Fra i molti differenti file system che
FreeBSD supporta c'è il Network File System,
conosciuto anche come <acronym role="Network
File System">NFS</acronym>. <acronym role="Network File
System">NFS</acronym> permette ad un sistema di
condividere directory
e file con altri sistemi in rete. Usando <acronym
role="Network File System">NFS</acronym>,
utenti e programmi possono
accedere a file su sistemi remoti quasi
come se fossero files locali.</para>
<para>Alcuni dei più notevoli benefici che
<acronym>NFS</acronym> ci fornisce sono:</para>
<itemizedlist>
<listitem>
<para>Workstation locali usano meno spazio su
disco perchè i dati usati in locale possono
essere conservati su una singola
macchina e restano accessibili agli altri sulla rete.</para>
</listitem>
<listitem>
<para>Non c'è bisogno per gli utenti di avere
home directory separate su ogni macchina in rete.
Le home directory possono essere poste sul
server <acronym>NFS</acronym> e
rese disponibili attraverso la rete.</para>
</listitem>
<listitem>
<para>Device di storage come floppy disk, drive
CDROM, e drive &iomegazip; possono essere usati
da altre macchine sulla rete.
Questo può ridurre il numero di device di
storage rimuovibili sulla rete.</para>
</listitem>
</itemizedlist>
<sect2>
<title>Come Funziona <acronym>NFS</acronym></title>
<para><acronym>NFS</acronym> consiste di almeno due parti:
un server ed uno o più client. Il client
accede da remoto ai dati conservati sulla macchina
server. Affinchè questo funzioni, alcuni processi
devono essere configurati
e devono essere attivi.</para>
<para>Il server deve avere attivi i seguenti demoni:</para>
<indexterm>
<primary>NFS</primary>
<secondary>server</secondary>
</indexterm>
<indexterm>
<primary>file server</primary>
<secondary>UNIX clients</secondary>
</indexterm>
<indexterm>
<primary><application>rpcbind</application></primary>
</indexterm>
<indexterm>
<primary><application>mountd</application></primary>
</indexterm>
<indexterm>
<primary><application>nfsd</application></primary>
</indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Demone</entry>
<entry>Descrizione</entry>
</row>
</thead>
<tbody>
<row>
<entry><application>nfsd</application></entry>
<entry>Il demone <acronym>NFS</acronym> che serve
richieste da client <acronym>NFS</acronym>.</entry>
</row>
<row>
<entry><application>mountd</application></entry>
<entry>Il demone di mount <acronym>NFS</acronym>
che serve le richieste
che &man.nfsd.8; gli passa.</entry>
</row>
<row>
<entry><application>rpcbind</application></entry>
<entry> Questo demone permette ai client
<acronym>NFS</acronym> di scoprire quali porte il server
<acronym>NFS</acronym> sta usando.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Il client può anche eseguire un demone,
noto come <application>nfsiod</application>.
Il demone <application>nfsiod</application>
serve le richieste dal server
<acronym>NFS</acronym>. E' opzionale, aiuta a
migliorare le prestazioni ma non è indispensabile
per operazioni corrette. Consultare la pagina
di manuale di &man.nfsiod.8;
per più informazioni.
</para>
</sect2>
<sect2 id="network-configuring-nfs">
<title>Configurare <acronym>NFS</acronym></title>
<indexterm>
<primary>NFS</primary>
<secondary>configurazione</secondary>
</indexterm>
<para>La configurazione di <acronym>NFS</acronym>
è un processo relativamente semplice.
I processi che devono essere attivi
possono essere tutti avviati al boot della macchina
con poche modifiche al tuo file
<filename>/etc/rc.conf</filename>.</para>
<para>Sul server <acronym>NFS</acronym> assicurati
che le seguenti opzioni sono configurati nel file
<filename>/etc/rc.conf</filename>:</para>
<programlisting>rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"</programlisting>
<para><application>mountd</application> viene
eseguito automaticamente in caso il server
<acronym>NFS</acronym> sia abilitato.</para>
<para>Sul client, accertati che questa riga sia
attiva nel file
<filename>/etc/rc.conf</filename>:</para>
<programlisting>nfs_client_enable="YES"</programlisting>
<para>Il file <filename>/etc/exports</filename>
specifica quali file system <acronym>NFS</acronym>
dovrebbe esportare (talora
chiamate anche <quote>share</quote>). Ogni linea di
<filename>/etc/exports</filename> specifica un
file system che deve essere esportato e quali
macchine hanno accesso a quel file system.
Assieme alle macchine che hanno accesso a quel file system,
possono esserci specificate anche opzioni. Ci
sono molte opzioni di questo tipo che possono essere
usate in questo file ma solo poche saranno menzionate
qui. Puoi facilmente
scoprire le altre opzioni leggendo la pagina di manuale
di &man.exports.5;.</para>
<para>Queste sono alcune linee di esempio del file
<filename>/etc/exports</filename>:</para>
<indexterm>
<primary>NFS</primary>
<secondary>esempi di export</secondary>
</indexterm>
<para>I seguenti esempi danno un'idea di
come esportare file system, anche se le
impostazioni possono essere diverse
a seconda del tuo ambiente e della tua
configurazione di rete.
Ad esempio, per esportare la directory
<filename>/cdrom</filename>
a tre macchine di esempio che hanno lo
stesso nome di dominio del server (da qui
la mancanza di nome dominio per ognuno)
o hanno delle linee nel vostro file
<filename>/etc/hosts</filename>.
L'opzione <option>-ro</option> rende il
file system esportato read-only. Con
questo flag, il sistema remoto non sarà in grado
di scrivere alcun cambiamento sul file system
esportato.</para>
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
<para>La seguente linea esporta la directory
<filename>/home</filename> a tre host
identificati da indirizzo IP. E' una
impostazione utile in caso tu abbia
una rete privata senza un <acronym>DNS</acronym> server
configurato. Opzionalmente il file
<filename>/etc/hosts</filename>
può essere configurato per hostname interni.
Per favore rileggi
&man.hosts.5; per più informazioni. Il flag
<option>-alldirs</option> permette alle sottodirectory
di fungere da mount point. In altre parole, non monterà
le sottodirectory ma permetterà ai client di montare
solo le directory che necessita o di cui ha bisogno.</para>
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
<para>La linea seguente esporta <filename>/a</filename>
cosicchè due client da diversi domini possono accedere
al file system. L'opzione <option>-maproot=root</option>
permette all'utente <username>root</username> sul
sistema remoto di scrivere dati
sul file system esportato come utente <username>root</username>.
Se il flag <literal>-maproot=root</literal> non
è specificato, anche se l'utente ha accesso come
<username>root</username> sul file system remoto,
non sarà in grado di modificare files sul file system
esportato.</para>
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
<para>Affinchè un client abbia accesso ad
un file system, questo deve avere permessi adeguati.
Assicurati che il client sia elencato nel
file <filename>/etc/exports</filename>.</para>
<para>In <filename>/etc/exports</filename>, ogni
linea rappresenta le informazioni per un
file system esportato ad un host. Un
host remoto può essere specificato solo
una volta per file system, e può
avere solo una entry di default. Ad esempio,
supponi che <filename>/usr</filename> sia
un singolo file system. Il seguente
<filename>/etc/exports</filename> sarebbe
invalido:</para>
<programlisting># Invalid when /usr is one file system
/usr/src client
/usr/ports client</programlisting>
<para>Un file system, <filename>/usr</filename>,
ha due linee che specificano exports verso lo stesso
host, <hostid>client</hostid>.
Il formato corretto per questa situazione è:</para>
<programlisting>/usr/src /usr/ports client</programlisting>
<para>Le proprietà di un file system esportato
ad un dato host devono essere tutte su una
riga. Linee senza un cliente specificato
sono trattate come un singolo host. Questo
limita il modo di esportare file system, ma
per la maggior parte delle persone
non è un problema.</para>
<para>Il seguente è un esempio di valida
lista di esportazione, dove
<filename>/usr</filename> e <filename>/exports</filename>
<filename>/usr</filename> and <filename>/exports</filename>
sono file system locali:</para>
<programlisting># Export src and ports to client01 and client02, but
only
# client01 has root privileges on it
/usr/src /usr/ports -maproot=root client01
/usr/src /usr/ports client02
# The client machines have root and can mount anywhere
# on /exports. Anyone in the world can mount /exports/obj read-only
/exports -alldirs -maproot=root client01 client02
/exports/obj -ro</programlisting>
<para>Il demone <application>mountd</application> deve
essere forzato a rileggere il file <filename>/etc/exports</filename>
ogni volta che lo modifichi,
cosicchè i cambiamenti abbiano effetto.
Questo può essere ottenuto inviando un segnale HUP
al processo <command>mountd</command>:</para>
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
<para>o invocando lo script <command>mountd</command> &man.rc.8;
con i parametri appropriati:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/mountd onereload</userinput></screen>
<para>Sei invitato a far riferimento a <xref linkend="configtuning-initial"/> per
maggiori informazioni sugli script rc.</para>
<para>Alternativamente, un reboot farà sì
che FreeBSD imposti tutto
correttamente. Non è necessario tuttavia effettuare
un reboot. L'esecuzione del seguente comando da
utente <username>root</username>
dovrebbe avviare tutto.</para>
<para>Sul server <acronym>NFS</acronym>:</para>
<screen>&prompt.root; <userinput>rpcbind</userinput>
&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
&prompt.root; <userinput>mountd -r</userinput></screen>
<para>Sul client <acronym>NFS</acronym>:</para>
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
<para>Ora dovrebbe essere tutto pronto per montare
un file system remoto.
In questi esempi il nome del server
sarà <hostid>server</hostid> e quello del client
sarà <hostid>client</hostid>. Se vuoi solo
temporaneamente montare un file system remoto o
anche testare la configurazione, basta che
esegui un comando come questo
come utente <username>root</username> sul client:</para>
<indexterm>
<primary>NFS</primary>
<secondary>mounting</secondary>
</indexterm>
<screen>&prompt.root; <userinput>mount server:/home
/mnt</userinput></screen>
<para>Questo monterà la directory
<filename>/home</filename> del server
sopra <filename>/mnt</filename> sul client. Se
tutto è impostato correttamente dovresti
essere in grado di entrare nella directory
<filename>/mnt</filename> sul client e vedere
tutti i file che sono sul server.</para>
<para>Se vuoi montare automaticamente un
file system remoto ogni volta che il
computer fa boot, aggiungi il file system
al file <filename>/etc/fstab</filename>.
Questo è un esempio:</para>
<programlisting>server:/home /mnt nfs rw 0 0</programlisting>
<para>La pagina di manuale di &man.fstab.5;
elenca tutte le possibili opzioni.</para>
</sect2>
<sect2>
<title>Locking</title>
<para>Alcune applicazioni (es. <application>mutt</application>)
richiedono il lock dei file per operare in modo corretto.
In caso di <acronym>NFS</acronym>, può essere utilizzato
<application>rpc.lockd</application> per il lock dei file.
Per abilitarlo, aggiungi la seguente riga al file
<filename>/etc/rc.conf</filename> sia sul client che sul
server (assumendo che il client e server <acronym>NFS</acronym>
siano già configurati):</para>
<programlisting>rpc_lockd_enable="YES"
rpc_statd_enable="YES"</programlisting>
<para>Avvia l'applicazione con:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/nfslocking start</userinput></screen>
<para>Se non è richiesto un lock reale tra il server
e il client <acronym>NFS</acronym>, è possibile
dire al client <acronym>NFS</acronym> di fare un lock locale
passando l'opzione <option>-L</option> a &man.mount.nfs.8;.
Ulteriori dettagli possono essere trovati nella pagina man di
&man.mount.nfs.8;.</para>
</sect2>
<sect2>
<title>Usi Pratici</title>
<para><acronym>NFS</acronym> ha molti usi
pratici. Alcuni
dei più usati sono elencati di seguito:</para>
<indexterm>
<primary>NFS</primary>
<secondary>usi</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para>Fa sì che alcune macchine
condividano un CDROM o un altro media
fra di loro. Questo è un metodo
più economico e spesso più convieniente
di installare software su molte macchine.</para>
</listitem>
<listitem>
<para>Su grandi reti, potrebbe essere più
conveniente configurare un server
<acronym>NFS</acronym> centrale in cui
conservare tutte le home directory degi utenti.
Queste home directory
possono essere esportate sulla rete cosicchè
gli utenti abbiano sempre la stessa directory,
indipendentemente dalla workstation dalla quale
effettuino il login.</para>
</listitem>
<listitem>
<para>Molte macchine potrebbero avere una
directory comune
<filename>/usr/ports/distfiles</filename>.
In questo modo, quando hai bisogno di
installare un port su molte macchine,
puoi velocemente accedere al sorgente senza
scaricarlo su ogni macchina.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2 id="network-amd">
<sect2info>
<authorgroup>
<author>
<firstname>Wylie</firstname>
<surname>Stilwell</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Riscritto da </contrib>
</author>
</authorgroup>
</sect2info>
<title>Mount automatici con <application>amd</application></title>
<indexterm><primary>amd</primary></indexterm>
<indexterm><primary>demone di mount automatico</primary></indexterm>
<para>&man.amd.8; (il demone di mount automatico)
monta automaticamente un file system remoto
ogni volta che un file o una directory in quel
file system viene acceduto. I file system che sono
inattivi per un certo periodo di tempo possono
anche essere smontati automaticamente da
<application>amd</application>. L'uso di
<application>amd</application> fornisce una semplice
alternativa a mount permanenti, dato che i mount
permanenti sono di solito
elencati in <filename>/etc/fstab</filename>.</para>
<para><application>amd</application> opera connettendosi
ad un server NFS sulle directory
<filename>/host</filename> e
<filename>/net</filename>. Quando si accede ad un file
all'interno di una di queste directory,
<application>amd</application>
fa una ricerca del mount remoto corrispondente e lo
monta automaticamente. <filename>/net</filename>
è usato per montare
un file system esportato da un indirizzo IP,
mentre <filename>/host</filename>
è usato per montare un export da un hostname remoto.</para>
<para>Un accesso ad un file in
<filename>/host/foobar/usr</filename> dovrebbe
comunicare a <application>amd</application> di
cercare di montare
l'export <filename>/usr</filename> sull'host
<hostid>foobar</hostid>.</para>
<example>
<title>Montare un export con
<application>amd</application></title>
<para>Puoi osservare i mount disponibili di un
host remoto con il comando
<command>showmount</command>. Ad esempio, per
vedere i mounts di un host chiamato
<hostid>foobar</hostid>, puoi usare:</para>
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
Exports list on foobar:
/usr 10.10.10.0
/a 10.10.10.0
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
</example>
<para>Come si vede nell'esempio,
il comando <command>showmount</command> mostra
<filename>/usr</filename> come un export.
Quando si cambia directory in
<filename>/host/foobar/usr</filename>,
<application>amd</application>
cerca di risolvere <hostid>foobar</hostid> e
automaticamente monta l'export desiderato.</para>
<para><application>amd</application> può essere
avviato dagli scripts di startup inserendo le
seguenti linee in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>amd_enable="YES"</programlisting>
<para>Inoltre, altri flags personalizzati possono essere
ad <application>amd</application> con le opzioni
<varname>amd_flags</varname>. Di default,
<varname>amd_flags</varname> è impostato a:</para>
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map
/net /etc/amd.map"</programlisting>
<para>Il file <filename>/etc/amd.map</filename>
definisce le opzioni di default con le quali
gli export sono montati. Il file
<filename>/etc/amd.conf</filename> definisce
alcune delle più avanzate caratteristiche di
<application>amd</application>.</para>
<para>Consulta le pagine di manuale di &man.amd.8;
e &man.amd.conf.5;
per maggiori informazioni.</para>
</sect2>
<sect2 id="network-nfs-integration">
<sect2info>
<authorgroup>
<author>
<firstname>John</firstname>
<surname>Lind</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
</sect2info>
<title>Problemi nell'integrazione con altri sistemi</title>
<para>Alcuni adapter Ethernet per sistemi PC hanno
limitazioni che possono portare a seri
problemi seri di rete, in particolare con NFS.
Questa difficoltà non è specifica a FreeBSD,
ma i sistemi FreeBSD ne sono affetti.</para>
<para>I problemi avvengono quasi sempre
quando sistemi PC (FreeBSD) sono
connessi in rete con workstation ad alta
performance, tipo quelli di
Silicon Graphics, Inc., e Sun Microsystems, Inc.
Il mount NFS funziona, ed alcune operazioni possono
avere successo, ma d'improvviso sembra che il
server non dia più risposte al client,
anche se le richieste da e verso altri sistemi
continuano ad essere processate.
Questo avviene sul sistema client, sia che
il client sia il sistema
FreeBSD sia che sia la workstation. Su molti sistemi,
non c'è modo di effettuare lo shutdown del client
in modo pulito una volta che questo problema si
sia manifestato. L'unica soluzione
è spesso quella di resettare il client,
poichè la situazione NFS
non può essere risolta.</para>
<para>Anche se la soluzione <quote>corretta</quote>
è usare un adapter Ethernet dalle migliori
prestazioni e capacità , c'è un semplice
workaround che permetterà operazioni soddisfacenti.
Se il sistem FreeBSD è il <emphasis>server</emphasis>,
includi le opzioni <option>-w=1024</option> al
mount dal client. Se il sistema FreeBSD
è il <emphasis>client</emphasis>, allora monta
il file system NFS con l'opzione <option>-r=1024</option>.
Queste opzioni possono essere specificate usando
il quarto campo della linea di
<filename>fstab</filename> sul client per
mount automatici, o usa il parametro <option>-o</option>
del comando &man.mount.8; per mount manuali.</para>
<para>Bisognerebbe notare che c'è un problema diverso,
a volte confuso con questo, quando il server NFS ed
il client sono su reti diverse. Se è questo
il caso, <emphasis>accertatevi</emphasis>
che i vostri router indirizzino correttamente l'informazione
necessaria su <acronym>UDP</acronym>, o non andrai
da nessuna parte, indipendentemente da cosa tu
stia cercando di fare.</para>
<para>Nei seguenti esempi, <hostid>fastws</hostid> è
il nome host (interfaccia) di una workstation
ad alte prestazioni, e <hostid>freebox</hostid>
è il nome host (interfaccia) di un sistema FreeBSD con
un adapter Ethernet a basse prestazioni. Inoltre,
<filename>/sharedfs</filename> sarà il file system esportato
(vedi &man.exports.5;), e <filename>/project</filename>
sarà il mount point sul client per il file system
montato. In tutti i casi, nota che le opzioni
<option>hard</option> o <option>soft</option> e
<option>bg</option> possono essere utili
nella tua applicazione.</para>
<para>Esempi dal sistema FreeBSD (<hostid>freebox</hostid>)
come client da <filename>/etc/fstab</filename> su
<hostid>freebox</hostid>:</para>
<programlisting>fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
<para>Come comando manuale di mount da
<hostid>freebox</hostid>:</para>
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
<para>Esempi dal sistema FreeBSD come server in
<filename>/etc/fstab</filename> su
<hostid>fastws</hostid>:</para>
<programlisting>freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
<para>Come comando di mount manuale su
<hostid>fastws</hostid>:</para>
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
<para>Praticamente ogni Ethernet adapter a 16-bit permetterà
operazioni senza le succitate restrizioni sulla dimensione
di lettura e scrittura.</para>
<para>Per chiunque è interessato, ecco cosa succede quando
occorre il problema, il che spiega anche perchè sia
non riparabile. NFS tipicamente lavora con una dimensione
di <quote>block</quote> di 8 K (anche se può creare
frammenti di dimensione minore). Dal momento che la
massima dimensione dei pacchetti Ethernet è attorno
a 1500 bytes, il <quote>block</quote> NFS sarà
diviso in molti pacchetti Ethernet
anche se è pur sempre una singola unità per il codice
di più alto livello e deve essere ricevuto, assemblato
e <emphasis>riconosciuto</emphasis> come una unità .
La workstation ad alta performance può inviare
pacchetti che comprendono le unità NFS una dietro l'altra,
l'una vicino all'altra come permette lo standard.i
Sulla scheda a minore capacità , gli ultimi pacchetti
sovrascrivono i precedenti pacchetti della stessa
unità prima che possano essere trasferiti all'host
e l'unità nella
sua interezza non può essere ricostruita
o riconosciuta. Come risultato, la workstation andrà
in timeout e cercherà ancora di ripetere l'operazione,
ma cercherà con la stessa unità da 8 K, ed il
processo sarà ripetuto ancora, all'infinito.</para>
<para>Mantenendo la dimensione dell'unità al di sotto
della limitazione dei pacchetti Ethernet, ci assicuriamo che
ogni completo pacchetto Ethernet ricevuto possa essere
ricono sciuto individualmente, evitando così la
situazione deadlock.</para>
<para>Sovrascritture possono anche capitare quando una
workstation ad alte prestazioni riversi dati verso
un sistema PC, ma con la scheda di rete migliore,
sovrascritture di questo tipo non sono garantite su
<quote>unità </quote> NFS. Quando una sovrascrittura
avviene, le unità affette saranno ritrasmesse,
e c'è una buona probabilità che saranno
ricevute, assemblate, e riconosciute.</para>
</sect2>
</sect1>
<sect1 id="network-nis">
<sect1info>
<authorgroup>
<author>
<firstname>Bill</firstname>
<surname>Swingle</surname>
<contrib>Scritto da </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Eric</firstname>
<surname>Ogren</surname>
<contrib>Migliorato da </contrib>
</author>
<author>
<firstname>Udo</firstname>
<surname>Erdelhoff</surname>
</author>
</authorgroup>
</sect1info>
<title>Network Information System (NIS/YP)</title>
<sect2>
<title>Cos'è?</title>
<indexterm><primary>NIS</primary></indexterm>
<indexterm><primary>Solaris</primary></indexterm>
<indexterm><primary>HP-UX</primary></indexterm>
<indexterm><primary>AIX</primary></indexterm>
<indexterm><primary>Linux</primary></indexterm>
<indexterm><primary>NetBSD</primary></indexterm>
<indexterm><primary>OpenBSD</primary></indexterm>
<para><acronym role="Network Information System">NIS</acronym>,
che sta per Network Information Services, fu sviluppato
da Sun Microsystems per centralizzare l'amministrazione
di sistemi &unix; (in origine &sunos;). Ora in sostanza
è diventato uno standard di settore; tutti i sistemi
&unix; like (&solaris;, HP-UX, &aix;, Linux, NetBSD,
OpenBSD, FreeBSD, etc) supportano
<acronym role="Network Information
System">NIS</acronym>.</para>
<indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
<para><acronym role="Network Information System">NIS</acronym>
in precedenza era noto come Yellow Pages, ma per una questione
di marchi, Sun ha cambiato il nome. Il vecchio termine (e yp)
è ancora si incontra ancora spesso.</para>
<indexterm>
<primary>NIS</primary>
<secondary>domini</secondary>
</indexterm>
<para>E' un sistema client/server basato su RPC che
permette ad un gruppo di macchine in un dominio
NIS di condividere un insieme comune di file di
configurazione. Questo permette ad un amministratore
di sistema di installare sistemi client
NIS con il minimo di dati di configurazione e di aggiungere,
rimuovere o modificare dati di configurazione da una singola
macchina.</para>
<indexterm><primary>Windows NT</primary></indexterm>
<para>E' simile al sistema di domini di &windowsnt;; anche
se le implementazioni interne dei due sistemi sono del tutto
diverse, le funzionalità base possono essere
paragonate.</para>
</sect2>
<sect2>
<title>Termini/Processi che Dovresti Conoscere</title>
<para>Ci sono parecchi termini e molti importanti processi
utente che incontrerai quando cercherai di implementare
NIS su FreeBSD, sia che cerchi di creare un server NIS
sia che cerchi di installare un client NIS:</para>
<indexterm>
<primary><application>rpcbind</application></primary>
</indexterm>
<indexterm>
<primary><application>portmap</application></primary>
</indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Termine</entry>
<entry>Descrizione</entry>
</row>
</thead>
<tbody>
<row>
<entry>Nome dominio NIS</entry>
<entry>Un server NIS master e tutti i suoi client
(inclusi i suoi server slave) hanno un nome
dominio NIS. Analogamente al nome dominio di
&windowsnt;, il nome dominio NIS non ha nulla
a che fare
con il <acronym>DNS</acronym>.</entry>
</row>
<row>
<entry><application>rpcbind</application></entry>
<entry>Deve essere in esecuzione al fine
di abilitare <acronym>RPC</acronym> (Remote
Procedure Call, un protocollo di rete usato da NIS).
Se <application>rpcbind</application> non è attivo,
sarà impossibile portare in esecuzione un server NIS
o fungere da client NIS
</entry>
</row>
<row>
<entry><application>ypbind</application></entry>
<entry>Esegue il <quote>bind</quote> di un client NIS
al suo server. Prenderà il nome dominio NIS dal
sistema, e, usando <acronym>RPC</acronym>, si
connetterà al server.
<application>ypbind</application>
è il fulcro di una comunicazione client-server in
ambiente NIS; se <application>ypbind</application>
muore su un client, questo non sarà in grado di
accedere il server NIS.</entry>
</row>
<row>
<entry><application>ypserv</application></entry>
<entry>Dovrebbe essere in esecuzione solo sui
server NIS;è il processo NIS vero e
proprio. Se &man.ypserv.8;
muore, il server non sarà più in grado di
rispondere a richieste NIS (si spera ci sia
un server slave per sostituirlo). Ci sono
alcune implementazioni di NIS
(ma non quello di FreeBSD) che non cerca di
ricollegarsi ad un altro server se il server
che stava usando muore. Spesso, l'unica cosa
che aiuta in questo caso è riavviare il
processo server (o anche
l'intero server o il processo
<application>ypbind</application> sul client).</entry>
</row>
<row>
<entry><application>rpc.yppasswdd</application></entry>
<entry>Un altro processo che dovrebbe essere in
esecuzione solo sui server master NIS; è un demone
che permette a client NIS di cambiare le proprie
password NIS. Se questo demone non è attivo,
gli utenti dovranno loggarsi al server master NIS
e cambiare le proprie password da lì.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</sect2>
<sect2>
<title>Come funziona?</title>
<para>Ci sono tre tipi di host in ambiente NIS:
master server, slave server e client. I server
fungono da magazzino centralizzato per le
informazioni sulla configurazione degli host. I
server master mantengono la copia "ufficiale"
di queste informazioni, mentre i server slave effettuano
il mirror di queste informazioni per ridondanza. I client
si affidano al server per ottenere queste informazioni.</para>
<para>Le informazioni in molti file possono essere
condivise in questo modo. I file
<filename>master.passwd</filename>
,<filename>group</filename> e <filename>hosts</filename> sono
in genere condivisi in questo modo via NIS. Qualora un
processo su un client necessiti di informazioni che
normalmente sarebbero trovate in questi file in locale,
fa una query al server NIS a cui è legato.</para>
<sect3>
<title>Tipi di macchine</title>
<itemizedlist>
<indexterm>
<primary>NIS</primary>
<secondary>master server</secondary>
</indexterm>
<listitem>
<para>Un <emphasis>server master NIS</emphasis>. Questo
server, analogamente a primary domain controller
&windowsnt; , mantiene i file usati da tutti i client
NIS. Il file <filename>passwd</filename>,
il file <filename>group</filename>, e vari altri
file usati da client NIS vivono sul
server master.</para>
<note>
<para>E' possibile per una macchina agire
da master server NIS per più di un dominio
NIS. Comunque, questo caso non sarà
coperto in questa introduzione,
che presuppone un ambiente NIS relativamente piccolo.</para>
</note>
</listitem>
<listitem>
<indexterm>
<primary>NIS</primary>
<secondary>slave server</secondary>
</indexterm>
<para><emphasis>NIS slave server</emphasis>. Analogamente
a backup domain controller &windowsnt;, i server
slave NIS mantengono copie dei file di dati
del server master NIS. I server slave NIS garantiscono
la ridondanza che viene richiesta in ambienti
importanti. Inoltre aiutano a bilanciare il carico
del server master: i client NIS si legano sempre
al NIS server che risponde per primo alla loro richiesta,
compresi i server slave.</para>
</listitem>
<listitem>
<indexterm>
<primary>NIS</primary>
<secondary>client</secondary>
</indexterm>
<para><emphasis>NIS client</emphasis>. I client NIS,
come la maggior parte delle workstation &windowsnt;
, si autenticano nei confronti del NIS server
(o del domain controller &windowsnt; nel caso di
workstation &windowsnt;) per effettuare il login.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<sect2>
<title>Usare NIS/YP</title>
<para>Questa sezione riguarderà l'installazione
di un ambiente di esempio NIS.</para>
<sect3>
<title>Il Piano</title>
<para>Supponiamo che tu sia l'amministratore di un piccolo
laboratorio universitario. Questo laboratorio, che
consiste di 15 macchine FreeBSD, al momento non ha
un sistema centralizzato di amministrazione; ogni
macchina ha il suo <filename>/etc/passwd</filename> e
<filename>/etc/master.passwd</filename>. Questi file
sono tenuti sincronizzati fra di loro attraverso
intervento manuale; al momento, quando aggiungi un utente
al laboratorio, devi eseguire <command>adduser</command>
su tutte e 15 le macchine. Chiaramente, questa situazione
è provvisoria, così hai deciso di convertire il
laboratorio a NIS, usando due delle macchine
come server.</para>
<para>Così la configurazione del laboratorio adesso
sembra questa:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="3">
<thead>
<row>
<entry>Nome della macchina</entry>
<entry>Indirizzo IP</entry>
<entry>Ruolo della macchina</entry>
</row>
</thead>
<tbody>
<row>
<entry><hostid>ellington</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
<entry>NIS master</entry>
</row>
<row>
<entry><hostid>coltrane</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
<entry>NIS slave</entry>
</row>
<row>
<entry><hostid>basie</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.4</hostid></entry>
<entry>Workstation della facoltà</entry>
</row>
<row>
<entry><hostid>bird</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.5</hostid></entry>
<entry>Macchina client</entry>
</row>
<row>
<entry><hostid>cli[1-11]</hostid></entry>
<entry><hostid role="ipaddr">10.0.0.[6-17]</hostid></entry>
<entry>Altre macchine client</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Se stai installando uno schema NIS per la
prima volta, è una buona idea riflettere
su come affrontarlo. Indipendemente dalla
dimensione della rete, ci sono alcune
decisioni che devono essere prese.</para>
<sect4>
<title>Scegliere un nome dominio NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>Nome dominio</secondary>
</indexterm>
<para>Questo può non essere il
<quote>nome dominio</quote> a
cui sei abituato. Per la precisione viene chiamato
<quote>nome dominio NIS</quote>. Quando un client
fa il broadcast della sua richiesta per informazioni,
include il nome del dominio NIS di cui fa parte.
In questo modo molti server su una rete possono distinguere
a quale server la richiesta è riferita. Considerate
il nome dominio NIS come il nome per un gruppo di host
che sono collegati per qualche motivo.</para>
<para>Alcune organizzazioni scelgono di usare il loro
nome dominio Internet come nome dominio NIS. Questo non
è raccomandabile in quanto può causare confusione
quando si cerchi di debuggare problemi di rete.
Il nome dominio NIS dovrebbe essere unico all'interno
della tua rete ed è utile che sia descrittivo
del gruppo di macchine che rappresenta. Per
esempio, il dipartimento di Arte della Acme Inc. può
essere nel dominio <quote>acme-art</quote>. Per questo
esempio, si presume tu abbia scelto il nome
<literal>test-domain</literal>.</para>
<indexterm><primary>SunOS</primary></indexterm>
<para>Comunque, alcuni sistemi operativi (principalmente
&sunos;) usano il loro nome dominio NIS come loro nome
dominio Internet. Se una o più macchine sulla tua rete
hanno questa restrizione, tu <emphasis>devi</emphasis>
usare il nome dominio Internet come il tuo
nome dominio NIS.</para>
</sect4>
<sect4>
<title>Requisiti fisici dei server</title>
<para>Ci sono molte cose da tener in mente quando si
sceglie quale macchina usare come server NIS. Una
delle caratteristiche più sfortunate di NIS
è il livello di dipendenza che i client hanno
verso il server. Se un client non riesce a
contattare il server per
il suo dominio NIS, molto spesso la macchina risulta
inutilizzabile. La mancanza di informazioni utente e
di gruppo fa sì che molti sistemi si blocchino. Tenendo
questo in mente dovresti accertati di scegliere una
macchina che non sia soggetta a reboot frequenti o
una che non sia usata per sviluppo. Il server
NIS dovrebbe essere in teoria una macchina
stand alone il cui unico
scopo di esistenza è essere un server NIS. Se hai una
rete non pesantemente trafficata,
è accettabile installare
il server NIS su una macchina che esegue altri servizi,
basta ricordarsi che se il server NIS diventa
irrangiungibile, <emphasis>tutti</emphasis> i tuoi
client NIS ne saranno affetti in modo negativo.</para>
</sect4>
</sect3>
<sect3>
<title>Server NIS</title>
<para> Le copie canoniche di tutte le informazioni NIS
sono conservate su una singola macchina chiamata
il server master NIS. I database usati per conservare
le informazioni sono chiamate mappe NIS. In FreeBSD,
queste mappe sono conservate in
<filename>/var/yp/[nome-dominio]</filename> dove
<filename>[nome-dominio]</filename> è il nome del dominio
NIS che si server. Un singolo server NIS può supportare
molti domini al tempo stesso, di conseguenza è
possibile avere molte directory di questo tipo,
una per ogni dominio supportato. Ogni dominio
avrà il suo insieme indipendente di mappe.</para>
<para>I server NIS master e slave gestiscono tutte le
richieste NIS col demone <command>ypserv</command>.
<command>ypserv</command> è responsabile per
la ricezione delle richieste in entrata dai client NIS,
traducendo il dominio richiesto e il nome mappa ad un
percorso verso il file di database e trasmettendo
i dati indietro al client.</para>
<sect4>
<title>Installare un server master NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>configurazione del server</secondary>
</indexterm>
<para>Installare un server master NIS può essere
relativamente semplice, a seconda delle tue
necessità . FreeBSD presenta un supporto nativo
per NIS. Tutto quello che devi fare è aggiungere
le seguenti linee a <filename>/etc/rc.conf</filename>,
e FreeBSD farà il resto.</para>
<procedure>
<step>
<para><programlisting>nisdomainname="test-domain"</programlisting>
Questa linea imposterà il nome domino NIS a
<literal>test-domain</literal>
al momento della configurazione di rete
(ad esempio dopo il reboot).</para>
</step>
<step>
<para><programlisting>nis_server_enable="YES"</programlisting>
Questa linea dirà a FreeBSD di avviare i processi
NIS server la prossima volta che la rete
è riavviata.</para>
</step>
<step>
<para><programlisting>nis_yppasswdd_enable="YES"</programlisting>
Questo avvierà il demone
<command>rpc.yppasswd</command> che, come accennato
prima, permetterà agli utenti di cambiare la loro
password NIS dalle macchine client.</para>
</step>
</procedure>
<note>
<para>A seconda delle tue impostazioni NIS, potresti
aver bisogno di aggiungere altre linee. Leggi
la <link linkend="network-nis-server-is-client">
sezione sui NIS server che sono anche NIS client
</link>, di seguito, per dettagli.</para>
</note>
<para>Ora, tutto quello che devi fare è eseguire
il comando <command>/etc/netstart</command>
come super-utente. Questo imposterà
il sistema, usando i valori che hai specificato
in <filename>/etc/rc.conf</filename>.</para>
</sect4>
<sect4>
<title>Inizializzare le mappe NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>mappe</secondary>
</indexterm>
<para>Le <emphasis>mappe NIS</emphasis> sono file di
database, che sono conservati nella directory
<filename>/var/yp</filename>. Sono generati
da file di configurazione nella directory
<filename>/etc</filename> del NIS master, con
una eccezione: il file
<filename>/etc/master.passwd</filename>.
C'è un buon motivo per questo, infatti
normalmente non vuoi che siano
propagate le password a <username>root</username>
e ad altri account amministrativi a tutti gli
altri server nel dominio NIS. Così prima
di inizializzare le mappe
NIS, dovresti:</para>
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>vi master.passwd</userinput></screen>
<para>Dovresti rimuovere tutte le linee che riguardano
account di sistema (<username>bin</username>,
<username>tty</username>, <username>kmem</username>,
<username>games</username>, etc.), così come altri
account che non vuoi siano propagate ai client NIS
(per esempio <username>root</username> ed ogni altro
account con UID 0 (super-utente)).</para>
<note>
<para>Accertati che il file
<filename>/var/yp/master.passwd</filename> non
sia nè leggibile dal gruppo nè dal resto
del mondo (modo 600)!
Usa il comando <command>chmod</command>, se
appropriato.</para>
</note>
<indexterm><primary>Tru64 UNIX</primary></indexterm>
<para>Quando hai finito, è il momento di inizializzare
le mappe NIS! FreeBSD include uno script chiamato
<command>ypinit</command> che lo fa per te (leggi
la sua pagina di manuale per dettagli). Nota che
questo script è disponibile sulla maggior parte dei
sistemi operativi &unix; ma non su tutti. Su
Digital Unix/Compaq Tru64 UNIX è chiamato
<command>ypsetup</command>. Poichè stiamo generando
mappe per un NIS master, passeremo l'opzione
<option>-m</option> al comando <command>ypinit</command>.
Per generare le mappe NIS, supponendo che tu abbia già
eseguito i passi di cui sopra, esegui:</para>
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n]
<userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server : ellington
next host to add: <userinput>coltrane</userinput>
next host to add: <userinput>^D</userinput>
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct? [y/n: y] <userinput>y</userinput>
[..output from map generation..]
NIS Map update completed.
ellington has been setup as an YP master server without any errors.</screen>
<para><command>ypinit</command> dovrebbe aver creato
<filename>/var/yp/Makefile</filename> da
<filename>/var/yp/Makefile.dist</filename>.
Quando creato, questo file assume che tu stia operando
su un ambiente NIS a server singolo con solo macchine
FreeBSD. Dal momento che <literal>test-domain</literal>
ha anche un server slave, devi editare
<filename>/var/yp/Makefile</filename>:</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput></screen>
<para>Dovresti commentare la linea che dice</para>
<programlisting>NOPUSH = "True"</programlisting>
<para>(se non è già commentata).</para>
</sect4>
<sect4>
<title>Impostare un server slave NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>slave server</secondary>
</indexterm>
<para>Impostare un server NIS slave è anche
più semplice che impostare il master. Loggati
al server slave ed edita
il file <filename>/etc/rc.conf</filename>
esattamente come hai fatto col server master.
L'unica differenza è che
ora dobbiamo usare l'opzione <option>-s</option> quando
eseguiamo <command>ypinit</command>. L'opzione
<option>-s</option> richiede che il nome del
server NIS sia passato, così la nostra linea
di comando assomiglia
alla seguente:</para>
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington
test-domain</userinput>
Server Type: SLAVE Domain: test-domain Master: ellington
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n]
<userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.</screen>
<para>Ora dovresti avere una directory chiamata
<filename>/var/yp/test-domain</filename>. Copie
delle mappe NIS del master server dovrebbero risiedere
in questa directory. Dovresti accertarti che siano
aggiornate. La seguente linea di
<filename>/etc/crontab</filename> sul tuo server slave
dovrebbe far ciò:</para>
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
<para>Queste due linee forzano lo slave a sincronizzare
le sue mappe con le mappe del server master.
Anche se queste entry non sono obbligatorie,
dal momento che il server
master cerca di assicurarsi che tutte le modifiche
alle sue mappe NIS siano comunicate ad i suoi slave
e perchè le informazioni sulle password sono vitali
per i sistemi che dipendono dal server, è una buona idea
forzare gli aggiornamenti. Questo è ancora più
importante su reti trafficate dove gli aggiornamenti
delle mappe potrebbero non essere completi.</para>
<para>Adesso, esegui il comando
<command>/etc/netstart</command> anche sullo slave,
per avviare il server NIS.</para>
</sect4>
</sect3>
<sect3>
<title>Client NIS</title>
<para>Un client NIS stabilisce quello che è
chiamato un binding ad un particolare NIS
server usando il demone
<command>ypbind</command>. <command>ypbind</command>
controlla il dominio di default del sistema
(impostato dal comando <command>domainname</command>),
ed inizia a fare broadcast di richieste RPC sulla rete
locale. Queste richieste specificano il nome del
dominio per il quale <command>ypbind</command> sta
cercando di stabilire un binding. Se un server è stato
configurato a servire il dominio richiesto, risponderà
a <command>ypbind</command>, che registrerà l'indirizzo
del server. Se ci sono molti server disponibili
(ad esempio un master e molti slave),
<command>ypbind</command> userà l'indirizzo del primo
che risponde. Da quel momento in poi, il sistema client
dirigerà tutte le sue richieste NIS a quel server.
<command>ypbind</command> occasionalmente farà un
<quote>ping</quote> del server per accertarsi che sia su
ed attivo. Se non riceve una risposta di uno dei suoi
ping in un tempo accettabile, <command>ypbind</command>
segnerà il dominio come non connesso e inizierà
di nuovo a fare broadcasting nella speranza di
localizzare un altro server.</para>
<sect4>
<title>Impostare un client NIS</title>
<indexterm>
<primary>NIS</primary>
<secondary>configurazione del client</secondary>
</indexterm>
<para>Impostare una macchina FreeBSD perchè sia un client
NIS è abbastanza semplice.</para>
<procedure>
<step>
<para>Edita il file <filename>/etc/rc.conf</filename> e
aggiungi le seguenti linee per impostare il nome
dominio NIS ed avviare <command>ypbind</command>
all'avvio della rete:</para>
<programlisting>nisdomainname="test-domain"
nis_client_enable="YES"</programlisting>
</step>
<step>
<para>Per importare tutte le possibili linee di
password dal server NIS, rimuovi tutti gli account
utente dal tuo <filename>/etc/master.passwd</filename>
ed usa <command>vipw</command> per aggiungere
la seguente linea alla fine del file:</para>
<programlisting>+:::::::::</programlisting>
<note>
<para>Questa linea permetterà a chiunque con un
valido account nella mappa delle password
del server NIS di loggarsi sul client. Ci
sono molti modi per
configurare il tuo client NIS cambiando questa
linea. Leggi la
<link linkend="network-netgroups">sezione
sui netgroups</link> di seguito per maggiori
informazioni. Per letture più dettagliate vedere
il libro della O'Reilly
<literal>Managing NFS and NIS</literal>.</para>
</note>
<note>
<para>Dovresti tenere almeno un account locale (non
importato via NIS) nel tuo file
<filename>/etc/master.passwd</filename> e questo
account dovrebbe essere anche un membro del gruppo
<groupname>wheel</groupname>. Se c'è qualche
problema con NIS, questo account può essere usato
per loggarsi da remoto, diventare
<username>root</username> e riparare le cose.</para>
</note>
</step>
<step>
<para>Per impostare tutte le possibili linee dei gruppi
dal server NIS, aggiungi questa linea al tuo file
<filename>/etc/group</filename>:</para>
<programlisting>+:*::</programlisting>
</step>
</procedure>
<para>Dopo aver completato questi passi, dovresti
essere in grado di eseguire <command>ypcat passwd</command>
e vedere la mappa delle password del NIS server.</para>
</sect4>
</sect3>
</sect2>
<sect2>
<title>Sicurezza di NIS</title>
<para>In generale, ogni utente remoto può eseguire una RPC
a &man.ypserv.8; ed ottenere i contenuti delle tue mappe NIS,
ammesso che l'utente remoto conosca il tuo nome dominio.
Per prevenire tali transazioni non autorizzate,
&man.ypserv.8; supporta una caratteristica chiamata
<quote>securenets</quote> che può essere usata per
restringere l'accesso ad un dato insieme di host. All'avvio
&man.ypserv.8; cercherà di caricare le informazioni
delle securenets da un file chiamato
<filename>/var/yp/securenets</filename>.</para>
<note>
<para>Questo percorso varia a secondo del percorso
specificato con l'opzione <option>-p</option>. Questo
file contiene linee che consistono di una
specificazione della rete e di una maschera di
rete separate da spazi vuoti. Le linee che
cominciano con <quote>#</quote> sono
considerati commenti. Un esempio di file securenets può
assomigliare al seguente:</para>
</note>
<programlisting># allow connections from local host -- mandatory
127.0.0.1 255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0 255.255.240.0</programlisting>
<para>Se &man.ypserv.8; riceve una richiesta da un indirizzo
che coincide con una di queste regole, processerà
la richiesta normalmente. Se l'indirizzo non coincide
la richiesta sarà ignorata ed un messaggio di warning
sarà loggato. Se il file
<filename>/var/yp/securenets</filename> non esiste,
<command>ypserv</command> permetterà connessioni
da ogni host.</para>
<para>Il programma <command>ypserv</command> ha
anche supporto per il pacchetto di Wietse Venema
<application>TCP Wrapper</application>. Questo
permette all'amministratore di usare i file
di configurazione di <application>TCP Wrapper</application>
per controlli sull'accesso al posto di
<filename>/var/yp/securenets</filename>.</para>
<note>
<para>Pur essendo entrambi questi meccanismi di accesso
di controllo abbastanza sicuri,
questi, come il test di porta privilegiata,
sono vulnerabili agli attacchi
<quote>IP spoofing</quote>. Tutto il traffico
relativo a NIS dovrebbe essere bloccato al firewall.</para>
<para>I server che usano
<filename>/var/yp/securenets</filename>
possono non riuscire a servire client NIS legittimi che
abbiano implementazioni TCP/IP obsolete. Alcune
di queste implementazioni impostano a zero tutti i
bit degli host quando fanno broadcast e/o non
riescono a osservare la maschera di sotto-rete
quando calcolano l'indirizzo
broadcast. Mentre alcuni di questi problemi possono
essere corretti cambiando la configurazione del client,
altri problemi possono causare il ritiro dei client
in questione o l'abbandono di
<filename>/var/yp/securenets</filename>.</para>
<para>Usando <filename>/var/yp/securenets</filename> su un
server con una tale obsoleta implementazione del TCP/IP
è sicuramente una cattiva idea e causerà alla
perdita della funzionalità NIS per gran parte della tua
rete.</para>
<indexterm><primary>TCP Wrappers</primary></indexterm>
<para>L'uso del pacchetto
<application>TCP Wrapper</application>
aumenta la latenza del tuo server NIS. Il ritardo
addizionale può essere lungo a sufficienza tanto
da causare dei timeout in programmi client, specialmente
su reti trafficate o con server NIS lenti. Se uno o
più client soffre di questi sintomi, dovresti convertire
il sistema dei client in questione a server NIS slave
e forzarli a non fare il binding a loro stessi.</para>
</note>
</sect2>
<sect2>
<title>Impedire ad Alcuni Utenti di Loggarsi</title>
<para>Nel nostro laboratorio c'è una macchina
<hostid>basie</hostid> che si suppone sia una workstation
solo della facoltà . Non vogliamo togliere questa
macchina dal dominio NIS, tuttavia il file
<filename>passwd</filename> sul server NIS master
contiene account che sono sia della
facoltà sia degli studenti. Cosa possiamo fare?</para>
<para>C'è un modo di impedire a specifici utenti di loggarsi
ad una macchina, anche se sono presenti nel database NIS.
Per farlo, tutto quello che devi fare è
aggiungere
<literal>-<replaceable>username</replaceable></literal>
alla fine del file <filename>/etc/master.passwd</filename>
sulla macchina client, dove
<replaceable>username</replaceable> è lo username
dell'utente di cui vuoi impedire l'accesso.
E' meglio fare questo con
<command>vipw</command> dato che <command>vipw</command>
farà un controllo di correttezza dei tuoi cambiamenti a
<filename>/etc/master.passwd</filename>, e ricostruirà
automaticamente il database delle password quando hai finito
di editarlo. Ad esempio, se vogliamo impedire l'accesso
all'utente <username>bill</username> verso l'host
<hostid>basie</hostid> faremmo:</para>
<screen>basie&prompt.root; <userinput>vipw</userinput>
<userinput>[aggiungi -bill alla fine del file, poi esci]</userinput>
vipw: rebuilding the database...
vipw: done
basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP
pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill
basie&prompt.root;</screen>
</sect2>
<sect2 id="network-netgroups">
<sect2info>
<authorgroup>
<author>
<firstname>Udo</firstname>
<surname>Erdelhoff</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
</sect2info>
<title>Usare i Netgroups</title>
<indexterm><primary>netgroups</primary></indexterm>
<para>Il metodo mostrato nella sezione precedente funziona
ragionevolmente bene se hai bisogno di regole speciali
per un numero molto piccolo di utenti e/o macchine. Su
reti più grandi, <emphasis>certamente</emphasis> ti
dimenticherai di impedire l'accesso di certi utenti
a macchine dal ruolo critico, oppure potresti perfino
finire a modificare ogni macchina separatamente, in questo
modo perdendo il beneficio centrale di NIS:
l'amministrazione <emphasis>centralizzata</emphasis>.</para>
<para>La soluzione degli sviluppatori NIS a questo problema
è chiamata <emphasis>netgroups</emphasis>. Il
loro scopo e la loro semantica possono essere
paragonate ai normali gruppi utenti usati dal
file system &unix;. L'unica differenza
è la mancanza di un ID numerico e l'abilità di
definire un netgroup che includa sia gruppi utenti che altri
netgroup.</para>
<para>I netgroup furono sviluppati per gestire grandi reti
complesse con centinaia di utenti e macchine. Da un lato
questa è una Buona Cosa se sei obbligato a gestire una
simile situazione. Dall'altro, questa complessità rende
praticamente impossibile spiegare i netgroup con esempi
relativamente semplici. L'esempio usato nel resto di questa
sezione dimostra questo problema.</para>
<para>Assumiamo che la favorevole introduzione di NIS nei tuoi
laboratori catturi l'interesse dei tuoi superiori. Il tuo
prossimo compito è di estendere il tuo dominio NIS per
coprire alcune altre macchine del campo. Le due tabelle contengono
i nomi dei nuovi utenti e delle nuove macchine, con una breve
descrizione.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>User Name(s)</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><username>alpha</username>,
<username>beta</username></entry>
<entry>Impiegato normale del dipartimento IT</entry>
</row>
<row>
<entry><username>charlie</username>,
<username>delta</username></entry>
<entry>Il nuovo apprendista del dipartimento IT</entry>
</row>
<row>
<entry><username>echo</username>,
<username>foxtrott</username>,
<username>golf</username>, ...</entry>
<entry>Impiegato ordinario</entry>
</row>
<row>
<entry><username>able</username>, <username>baker</username>,
...</entry>
<entry>Gli interni correnti</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>Machine Name(s)</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<!-- Names taken from "Good Omens" by Neil Gaiman and Terry
Pratchett. Many thanks for a brilliant book. -->
<entry><hostid>war</hostid>, <hostid>death</hostid>,
<hostid>famine</hostid>,
<hostid>pollution</hostid></entry>
<entry>Il tuoi server più importanti. Solo
gli impiegati IT hanno il permesso di loggarsi
in queste macchine.</entry>
</row>
<row>
<!-- gluttony was omitted because it was too fat -->
<entry><hostid>pride</hostid>, <hostid>greed</hostid>,
<hostid>envy</hostid>, <hostid>wrath</hostid>,
<hostid>lust</hostid>, <hostid>sloth</hostid></entry>
<entry>Server meno importanti. Tutti i membri
del dipartimento IT hanno il permesso di loggarsi
a queste macchine.</entry>
</row>
<row>
<entry><hostid>one</hostid>, <hostid>two</hostid>,
<hostid>three</hostid>, <hostid>four</hostid>,
...</entry>
<entry>Workstation normali. Solo
<emphasis>veri</emphasis> impiegati hanno permesso
di accedere a queste macchine.</entry>
</row>
<row>
<entry><hostid>trashcan</hostid></entry>
<entry>Una macchina molto vecchia senza alcun dato
critico. Anche gli interni hanno permesso di usare
questa macchina.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Se provi ad implementare queste restrizioni bloccando
separatamente ogni utente, dovresti aggiungere una linea
<literal>-<replaceable>user</replaceable></literal>
ad ogni <filename>passwd</filename> per ogni utente che
non ha il permesso di loggarsi in quel sistema. Se ti
dimentichi anche solo di una linea, potresti essere nei
pasticci. Può essere ragionevole fare ciò
correttamente durante l'installazione iniziale, comunque
<emphasis>certamente</emphasis> ti dimenticherai alla fine
di aggiungere le linee per i nuovi utenti durante le
operazioni giornaliere. Dopo tutto, Murphy era un
ottimista.</para>
<para>Gestire questa situazione con i netgroup offre
molti vantaggi. Non c'è bisogno di gestire
separatamente ogni utente; basta assegnare un utente ad
uno o più netgroup e permettere o impedire il login
a tutti i membri del netgroup. Se aggiungi una
nuova macchina, dovrai solo definire restrizioni di
login per i netgroup. Se un nuovo utente viene
aggiunto, dovrai solo aggiungere l'utente
ad uno o più netgroup. Questi cambiamenti sono indipendenti
l'uno dall'altro: non più <quote>per ogni combinazione di
utenti e macchine fai ...</quote>Se la tua installazione
NIS è pianificata con attenzione, dovrai solo modificare
esattamente un file centrale di configurazione per garantire
o negare l'accesso alle macchine.</para>
<para>Il primo passo è l'inizializzazione della mappa NIS
netgroup. &man.ypinit.8; di FreeBSD non crea questa mappa
di default, ma la sua implementazione NIS la supporterà
una volta che è stata creata. Per aggiungere una linea alla
mappa, semplicemente usa il comando</para>
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
<para>e poi inizia ad aggiungere contenuti. Per i nostri esempi
abbiamo bisogno di almeno quattro netgroup: impiegati IT,
apprendisti IT, impiegati normali ed interni.</para>
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
<para><literal>IT_EMP</literal>, <literal>IT_APP</literal> etc.
sono i nomi dei netgroup. Ogni gruppo fra parentesi tonde
aggiunge uno o più account utente. I tre campi dentro il
gruppo sono:</para>
<orderedlist>
<listitem>
<para>Il nome degli host dove le seguenti caratteristiche
sono valide. Se non specifichi un nome host, la linea
è valida per tutti gli host. Se specifichi un nome host,
entrerai nel regno dell'oscurità , dell'orrore
e della confusione assoluta.</para>
</listitem>
<listitem>
<para>Il nome dell'account che appartiene a questo
netgroup.</para>
</listitem>
<listitem>
<para>Il dominio NIS per l'account. Puoi
importare account da altri domini NIS nel tuo netgroup
se sei uno di quei ragazzi sfortunati con più di
un dominio NIS.</para>
</listitem>
</orderedlist>
<para>Ognuno di questi campi può contenere
wildcards. Leggi &man.netgroup.5; per dettagli.</para>
<note>
<indexterm><primary>netgroups</primary></indexterm>
<para>Nomi netgroup più lunghi di 8 caratteri
non dovrebbero essere usati, specialmente se hai macchine
che eseguono altri sistemi operativi all'interno del
tuo dominio NIS. I nomi sono case sensitive; usare
le lettere maiuscole per il tuo netgroup è
un modo semplice per distinguere fra utenti,
macchine e nomi di netgroup.</para>
<para>Alcuni client NIS (non FreeBSD) non possono
gestire netgroup con un numero troppo grande di linee.
Ad esempio, alcune vecchie versioni di &sunos; iniziano
ad avere problemi se un netgroup contiene più di 15
<emphasis>linee</emphasis>. Puoi superare questo
limite creando molti sotto-netgroup con 15 o meno utenti
ed un vero netgroup che consiste dei sotto-netgroup:</para>
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain)
(,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe31,domain) (,joe32,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
<para>Puoi ripetere questo processo se hai bisogno di più
di 225 utenti all'interno di un singolo netgroup.</para>
</note>
<para>Attivare e distribuire la tua nuova mappa NIS
è facile:</para>
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
ellington&prompt.root; <userinput>make</userinput></screen>
<para>Questo genererà le tre mappe NIS
<filename>netgroup</filename>,
<filename>netgroup.byhost</filename> e
<filename>netgroup.byuser</filename>. Usa
&man.ypcat.1; per controllare che le tue
nuove mappe NIS siano disponibili:</para>
<screen>ellington&prompt.user; <userinput>ypcat -k
netgroup</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
ellington&prompt.user; <userinput>ypcat -k
netgroup.byuser</userinput></screen>
<para>L'output del tuo primo comando dovrebbe assomigliare
a <filename>/var/yp/netgroup</filename>. Il secondo
comando non produrrà output se non hai specificato
netgroup specifici agli host. Il terzo comando può
essere usato per ottenere una lista dei netgroup di un
utente.</para>
<para>L'installazione del client è abbastanza semplice.
Per configurare il server <hostid>war</hostid>, devi solo
eseguire &man.vipw.8; e sostituire la linea</para>
<programlisting>+:::::::::</programlisting>
<para>con</para>
<programlisting>+@IT_EMP:::::::::</programlisting>
<para>Ora, solo i dati per l'utente definito nel netgroup
<literal>IT_EMP</literal> sono importati nel
database delle password di <hostid>war</hostid> e solo
questi utenti hanno permesso di accesso.</para>
<para>Sfortunatamente, questa limitazione si applica anche
alla funzione della shell <literal>~</literal> ed a
tutte le routine che convertono fra nomi utenti e user ID
numerici. In altre parole,<command>cd ~<replaceable>user
</replaceable></command> non funzionerà ,
<command>ls -l</command> mostrerà gli ID numerici
invece dello username e
<command>find . -user joe -print</command>
darà l'errore <errorname>No such user</errorname>. Per
riparare questo, dovrai importare tutte le linee dell'utente
<emphasis>senza permettere a loro di loggarsi sui tuoi
server</emphasis>.</para>
<para>Questo può essere ottenuto aggiungendo un'altra
linea a <filename>/etc/master.passwd</filename>. Questo
dovrebbe contenere:</para>
<para><literal>+:::::::::/sbin/nologin</literal>, dal significato
<quote>Importa tutte le entry ma imposta la shell di
login a <filename>/sbin/nologin</filename> nelle linee
importate</quote>. Puoi sostituire ogni campo nella linea
<literal>passwd</literal> piazzando un valore di default
nel tuo <filename>/etc/master.passwd</filename>.</para>
<!-- Been there, done that, got the scars to prove it - ue -->
<warning>
<para>Accertati che la linea
<literal>+:::::::::/sbin/nologin</literal> sia piazzata
dopo <literal>+@IT_EMP:::::::::</literal>. Altrimenti
tutti gli account utente importati da NIS avranno
<filename>/sbin/nologin</filename> come loro shell
di login.</para>
</warning>
<para>Dopo questo cambiamento, dovrai solo cambiare
una mappa NIS se un nuovo impiegato si unisce
al dipartimento IT. Puoi usare un simile
approccio per i server meno importanti
sostituendo <literal>+:::::::::</literal> nella tua versione
locale di <filename>/etc/master.passwd</filename>
con qualcosa del tipo:</para>
<programlisting>+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>Le linee corrispondenti per le workstation normali
potrebbero essere:</para>
<programlisting>+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>E tutto sarebbe a posto fino a che non c'è un
cambiamento di policy dopo poche settimane:
il dipartimento IT inizia ad assumere interni.
Gli interni IT hanno permesso di usare le normali
workstation ed i server meno importanti; e gli
apprendisti IT hanno permesso di loggarsi ai
server principali. Aggiungi un nuovo netgroup
<literal>IT_INTERN</literal>, aggiungi i nuovi interni IT
a questo nuovo netgroup <literal>IT_INTERN</literal>,
e inizia a cambiare la configurazione su ogni nuova macchina...
Come il vecchio adagio dice:<quote>Errori nella pianificazione
centralizzata porta a caos globale</quote>.</para>
<para>L'abilità NIS di creare netgroup da altri netgroup
può essere usata per prevenire situazioni come queste. Una
possibilità è la creazione di netgroup basati sul
ruolo. Per esempio, potresti creare un netgroup chiamato
<literal>BIGSRV</literal> per definire le restrizioni di login
per i server importanti, un altro netgroup chiamato
<literal>SMALLSRV</literal> per i server meno importanti
ed un terzo netgroup chiamato <literal>USERBOX</literal>
per le workstation normali. Ognuna di questi netgroup
contiene i netgroup che hanno permesso di accesso a
queste macchine. Le nuove linee della tua mappa NIS
dovrebbero assomigliare a questa:</para>
<programlisting>BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS</programlisting>
<para>Questo metodo di definire restrizioni di login
funziona ragionevolmente bene se puoi definire gruppi
di macchine con restrizioni identiche. Sfortunatamente
questa è l'eccezione, non la regola. La maggior parte del
tempo, avrai necessità di definire restrizioni di login
macchina per macchina.</para>
<para>Definizioni di netgroup specifiche per ogni
macchina sono l'altra possibilità per gestire
il cambiamento di policy delineato sopra.
In questo scenario il
<filename>/etc/master.passwd</filename> di ogni macchina
deve contenere due linee che iniziano con
<quote>+</quote>. La prima di queste aggiunge un netgroup
con l'account che ha il permesso di loggarsi alla macchina,
il secondo aggiunge tutti gli altri account con
<filename>/sbin/nologin</filename> come shell. E' buona
norma usare la versione <quote>MAIUSCOLA</quote> del nome
macchina come nome del netgroup. In altre parole, le linee
dovrebbero assomigliare a questa:</para>
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>
<para>Una volta che hai completato questo task per tutte
le macchine, non dovrai mai più modificare la versione locale
di <filename>/etc/master.passwd</filename>. Tutti
gli ulteriori cambiamenti possono essere
gestiti modificando la mappa NIS. Di
seguito un esempio di una possibile
mappa netgroup per questo scenario con altri vantaggi
addizionali:</para>
<programlisting># Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
DEPT2 (,golf,test-domain) (,hotel,test-domain)
DEPT3 (,india,test-domain) (,juliet,test-domain)
ITINTERN (,kilo,test-domain) (,lima,test-domain)
D_INTERNS (,able,test-domain) (,baker,test-domain)
#
# Now, define some groups based on roles
USERS DEPT1 DEPT2 DEPT3
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR BIGSRV
FAMINE BIGSRV
# User india needs access to this server
POLLUTION BIGSRV (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH IT_EMP
#
# The anti-virus-machine mentioned above
ONE SECURITY
#
# Restrict a machine to a single user
TWO (,hotel,test-domain)
# [...more groups to follow]</programlisting>
<para>Se stai usando qualche tipo di database per
gestire i tuoi account utente, dovresti essere in
grado di creare la prima parte della mappa con i
tuoi tool di report del database. In
questo modo, i nuovi utenti avranno accesso automaticamente
alle macchine.</para>
<para>Un ultima nota di avvertimento: può non essere sempre
consigliabile usare netgroup basati sulle macchine. Se
stai per mettere in produzione qualche dozzina o perfino qualche
centinaia di macchine identiche per laboratori studente,
dovresti usare netgroup basati sul ruolo invece che netgroup
basati sulla macchina, per tenere la dimensione della mappa
NIS al di sotto di un limite ragionevole.</para>
</sect2>
<sect2>
<title>Cose Importanti da Ricordare</title>
<para>Ci sono ancora un paio di cose che dovrai cambiare
ora che operi in ambiente NIS.</para>
<itemizedlist>
<listitem>
<para>Ogni volta che devi aggiungere un utente al
laboratorio devi aggiungerlo
<emphasis>solo</emphasis> al server
master NIS e <emphasis>devi ricordarti di ricostruire
le mappe NIS</emphasis>. Se ti dimentichi di farlo
il nuovo utente non sarà in grado di loggarsi in alcuna
macchina eccetto che sul server NIS master. Per esempio,
se abbiamo bisogno di aggiungere un nuovo utente
<username>jsmith</username> al laboratorio,
faremmo:</para>
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>make test-domain</userinput></screen>
<para>Puoi anche eseguire <command>adduser jsmith</command>
invece di <command>pw useradd jsmith</command>.</para>
</listitem>
<listitem>
<para><emphasis>Tieni gli account amministrativi fuori
dalle mappe NIS</emphasis>. Normalmente non vuoi che
gli account amministrativ e le password si propaghino
a macchine che avranno utenti che non dovrebbero avere
accesso a quegli account.</para>
</listitem>
<listitem>
<para><emphasis>Tieni al sicuro il NIS master e slave,
e minimizza il tempo in cui sono giù</emphasis>. Se
qualcuno hackera o semplicemente spegne queste macchine
riesce a privare molte persone della possibilità di
loggarsi al laboratorio.</para>
<para>Questa è la principale debolezza di ogni
sistema centralizzato di amministrazione. Se non proteggi
il tuo server NIS, avrai un mucchio di utenti
arrabbiati!</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Compatibilità con NIS v1</title>
<para><application>ypserv</application> di FreeBSD supporta
fino ad un certo punto client NIS v1. L'implementazione
di NIS di FreeBSD usa solo il protocollo NIS v2, comunque
altre implementazioni includono supporto per il protocollo
v1 per compatibilità all'indietro coi vecchi sistemi. Il
demone <application>ypbind</application> fornito con questi
sistemi proverà a stabilire un binding con un server
NIS v1 anche se potrebbero non averne mai bisogno
(e possono continuare a fare broadcast in ricerca di
uno anche dopo che hanno ricevuto risposta da un
server v2). Nota che mentre il supporto per i
client normali viene garantito, questa versione
di <application>ypserv</application> non
gestisce richieste di trasferimento di mappe v1; di
conseguenza, non può essere usato come master o slave in
congiunzione con server NIS più vecchi che
supportano solo il protocollo v1. Fortunatamente,
probabilmente non ci sono
server del genere in uso oggi.</para>
</sect2>
<sect2 id="network-nis-server-is-client">
<title>Server NIS che Sono Anche Client</title>
<para> Bisogna prestare molta attenzione quando
si esegue <application>ypserv</application> in
un dominio multi-server dove le macchine server
sono anche client NIS.
E' generalmente una buona idea forzare i server
ad effettuare il binding a sè stessi piuttosto
che permettere loro di effettuare il broadcast
delle richieste binding e
potenzialmente possono fare il bind una all'altra.
Possono risultare strani errori quando un
server va giù e gli altri sono dipendenti da
lui. Alla fine, tutti i client andranno in timeout
e cercheranno di effettuare il bind ad altri server,
ma il ritardo di questa operazione può essere
considerevole e l'uscita
di errore è ancora presente dato che i server possono
fare il binding fra di loro di nuovo.</para>
<para>Puoi forzare un host a fare il binding ad un server
in particolare usando <command>ypbind</command> con
l'opzione <option>-S</option>. Se non vuoi fare
questa azione a mano ogni volta che fai il reboot
del tuo server NIS, puoi aggiungere queste linee al tuo
<filename>/etc/rc.conf</filename>:</para>
<programlisting>nis_client_enable="YES" # run client stuff as well
nis_client_flags="-S <replaceable>NIS
domain</replaceable>,<replaceable>server</replaceable>"</programlisting>
<para>Consulta &man.ypbind.8; per ulteriori informazioni.</para>
</sect2>
<sect2>
<title>Formato delle Password</title>
<indexterm>
<primary>NIS</primary>
<secondary>formato delle password</secondary>
</indexterm>
<para>Uno dei problemi più comuni in cui la gente incappa
quando tenta di implementare NIS è la compatibilità
del formato delle password. Se il tuo server NIS usa password
criptate con DES, supporterà solo client che usano anche loro
DES. Ad esempio, se hai client NIS &solaris; nella rete,
dovrai quasi certamente usare password criptate
con DES.</para>
<para>Per controllare quale formato il tuo server
e client usano, dai un'occhiata a
<filename>/etc/login.conf</filename>. Se l'host
è configurato per usare password criptate
DES, la classe <literal>default</literal> conterrà
una linea simile a questa:</para>
<programlisting>default:\
:passwd_format=des:\
:copyright=/etc/COPYRIGHT:\
[Further entries elided]</programlisting>
<para>Altri valori possibili per l'opzione
<literal>passwd_format</literal> includono
<literal>blf</literal> e <literal>md5</literal>
(per password criptate con Blowfish e con MD5,
rispettivamente).</para>
<para>Se hai fatto modifiche a
<filename>/etc/login.conf</filename>,
dovrai anche ricostruire il database
delle possibilità di login, il che si
ottiene eseguendo il seguente comando
come <username>root</username>:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
<note>
<para>Il formato delle password che sono
già in <filename>/etc/master.passwd</filename> non
sarà aggiornato finchè un utente cambia la
sua password per la prima volta
<emphasis>dopo</emphasis> che il
database delle possibilità di login
è ricostruito.</para>
</note>
<para>Dopodichè per assicurarti che le password siano
criptate con il formato che hai scelto, dovresti
anche controllare che <literal>crypt_default</literal>
in <filename>/etc/auth.conf</filename> dia precedenza
al formato delle password scelto. Per farlo,
inserisci il formato che hai scelto per primo
nella lista. Ad esempio, quando usi password
criptate DES, la linea dovrebbe essere:</para>
<programlisting>crypt_default = des blf md5</programlisting>
<para>Seguendo i passi sopra citati su ognuno dei &os;
basati su NIS server e client, puoi star sicuro che tutti
siano d'accordo su quale formato delle password sia usato
all'interno della rete. Se hai problemi nell'identificazione
su un client NIS, questo è un buon punto di partenza per
cercare possibili problemi. Ricordati: se vuoi mettere
in produzione un server NIS per una rete eterogenea,
dovrai probabilmente usare DES su tutti i sistemi
poichè questo è il minimo standard comune.</para>
</sect2>
</sect1>
<sect1 id="network-dhcp">
<sect1info>
<authorgroup>
<author>
<firstname>Greg</firstname>
<surname>Sutter</surname>
<contrib>Scritto da </contrib>
</author>
</authorgroup>
</sect1info>
<title>Configurazione Automatica della Rete (DHCP)</title>
<sect2>
<title>Cos'è il DHCP?</title>
<indexterm>
<primary>Dynamic Host Configuration Protocol</primary>
<see>DHCP</see>
</indexterm>
<indexterm>
<primary>Internet Software Consortium (ISC)</primary>
</indexterm>
<para>DHCP, il Protocollo di Configurazione Host Dinamico,
descrive i passi attraverso i quali un sistema
si può connettere ad una rete ed ottenere
l'informazione necessaria per comunicare attraverso
quella rete. Le versioni di FreeBSD prima della 6.0
usano l'implementazione DHCP client (&man.dhclient.8;)
dell'ISC (Internet Software Consortium). Le ultime versioni
usano il <command>dhclient</command> di OpenBSD preso
da OpenBSD 3.7.
Tutte le informazioni specifiche all'implementazione
di <command>dhclient</command> in questa sede
sono riferite all'uso dei client DHCP sia di ISC che di OpenBSD.
Il server DHCP è quello incluso nella
distribuzione ISC.</para>
</sect2>
<sect2>
<title>Cosa Copre Questa Sezione</title>
<para>Questa sezione descrive sia il lato client
del sistema DHCP di ISC e di OpenBSD che il lato server del
sistema DHCP ISC. Il
programma client, <command>dhclient</command>,
è già
integrato con FreeBSD, e la parte server è
disponibile nel port <filename
role="package">net/isc-dhcp3-server</filename>. Le
pagine di manuale &man.dhclient.8;, &man.dhcp-options.5;, e
&man.dhclient.conf.5;, oltre ai riferimenti
elencati oltre, sono risorse utili.</para>
</sect2>
<sect2>
<title>Come Funziona</title>
<indexterm><primary>UDP</primary></indexterm>
<para>Quando <command>dhclient</command>, il client
DHCP, viene eseguito sulla macchina client, inizia
a fare broadcasting di richieste per informazioni
di configurazione. Di default
queste richieste sono sulla porta UDP 68. Il server
risponde sulla porta UDP 67, dando al client un
indirizzo IP ed altre informazioni rilevanti di rete
come la netmask, il router ed il DNS server. Tutte
queste informazioni
arrivano sotto forma di un <quote>rilascio</quote> DHCP
e sono valide sono per un certo periodo di tempo
(configurato dall'amministratore del server DHCP).
In questo modo, gli indirizzi IP bloccati da client
che non sono più connessi alla rete possono
essere riutilizzati automaticamente.</para>
<para>I client DHCP possono ottenere molti tipi
di informazione dal server. Una lista esauriente
può essere trovata in
&man.dhcp-options.5;.</para>
</sect2>
<sect2>
<title>L'Integrazione con FreeBSD</title>
<para>&os; integra completamente il client
DHCP ISC o OpenBSD, <command>dhclient</command>
(a seconda della versione di &os; utilizzata). Viene fornito
supporto al client DHCP sia con l'installazione
sia con il sistema base, rendendo inutile il bisogno
di una conoscenza dettagliata della configurazione
di rete su ogni rete che abbia un server DHCP.
<command>dhclient</command> è stato incluso
in tutte le distribuzioni FreeBSD a partire
dalla 3.2.</para>
<indexterm>
<primary><application>sysinstall</application></primary>
</indexterm>
<para>DHCP è supportato da
<application>sysinstall</application>. Quando
configuri una interfaccia di rete con
<application>sysinstall</application>, la seconda
domanda che ti pone è:
<quote> Vuoi provare a configurare
l'interfaccia via DHCP?</quote>. Una risposta
affermativa eseguirà <command>dhclient</command>,
e, se ha successo, riempirà le informazioni
di configurazione della rete in automatico.</para>
<para>Ci sono due cose che devi fare per far sì
che il tuo sistema usi il DHCP all'avvio:</para>
<indexterm>
<primary>DHCP</primary>
<secondary>prerequisiti</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para>Accertati che il device
<devicename>bpf</devicename>
sia compilato nel tuo kernel. Per fare
ciò, aggiungi <literal>device bpf</literal>
al tuo file di
configurazione del kernel, e ricompilalo.
Per maggiori informazioni su come ricompilare
i kernel, vedi <xref
linkend="kernelconfig"/>.</para> <para>Il device
<devicename>bpf</devicename> è già
parte del kernel <filename>GENERIC</filename>
che è fornito con FreeBSD, così
se non hai un kernel custom, non dovresti
aver bisogno di crearne uno al fine di far funzionare
il DHCP.</para>
<note>
<para>Quelli di voi che sono particolarmente
attenti alla sicurezza, dovrebbero sapere che il
device <devicename>bpf</devicename> è
anche il device che permette agli sniffer di
pacchetti di
funzionare correttamente (anche se devono sempre
essere eseguiti come <username>root</username>).
<devicename>bpf</devicename>
<emphasis>è</emphasis>
richiesto per l'uso del DHCP, ma se siete molto
attenti alla sicurezza, non dovreste probabilmente
aggiungere <devicename>bpf</devicename> al
vostro kernel in previsione di un uso
futuro del DHCP.</para>
</note>
</listitem>
<listitem>
<para>Edita il tuo <filename>/etc/rc.conf</filename>
per includere la seguente linea:</para>
<programlisting>ifconfig_fxp0="DHCP"</programlisting>
<note>
<para>Accertati di sostituire
<literal>fxp0</literal> con il
nome dell'interfaccia che intendi configurare
dinamicamente, come descritto in
<!--<xref linkend="config-network-setup"/>-->.</para>
</note>
<para>Se stai usando una locazione diversa
per <command>dhclient</command>, o se desideri
passare flags addizionali a
<command>dhclient</command>
includi anche le linee seguenti (editandole
come necessario):</para>
<programlisting>dhcp_program="/sbin/dhclient"
dhcp_flags=""</programlisting>
</listitem>
</itemizedlist>
<indexterm>
<primary>DHCP</primary>
<secondary>server</secondary>
</indexterm>
<para>Il server DHCP, <application>dhcpd</application>,
è incluso come parte del port
<filename role="package">net/isc-dhcp3-server</filename>
nella collezione dei ports. Questo port contiene il
server DHCP ISC e la documentazione.</para>
</sect2>
<sect2>
<title>Files</title>
<indexterm>
<primary>DHCP</primary>
<secondary>file di configurazione</secondary>
</indexterm>
<itemizedlist>
<listitem><para><filename>/etc/dhclient.conf</filename></para>
<para><command>dhclient</command> richiede
un file di configurazione,
<filename>/etc/dhclient.conf</filename>. Tipicamente
il file contiene solo commenti, essendo i default
ragionevolmente corretti. Questo file di
configurazione è descritto dalla
pagina di manuale &man.dhclient.conf.5;.</para>
</listitem>
<listitem>
<para><filename>/sbin/dhclient</filename></para>
<para><command>dhclient</command> è
linkato staticamente e risiede in
<filename>/sbin</filename>.
Le pagine di manuale di &man.dhclient.8; danno
maggiori informazioni su <command>dhclient</command>.</para>
</listitem>
<listitem>
<para><filename>/sbin/dhclient-script</filename></para>
<para><command>dhclient-script</command> è
lo script di configurazione del client DHCP
specifico di FreeBSD. Viene descritto in
&man.dhclient-script.8;
ma non dovrebbe aver bisogno di nessuna
modifica utente
per funzionare correttamente.</para>
</listitem>
<listitem>
<para><filename>/var/db/dhclient.leases</filename></para>
<para>Il client DHCP mantiene un database di
validi rilasci in questo file, che viene
scritto come un log.
&man.dhclient.leases.5; ne dàuna descrizione
leggermente più estesa.</para>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Ulteriori Letture</title>
<para>Il protocollo DHCP è
descritto in maniera estesa in
<ulink url="http://www.freesoft.org/CIE/RFC/2131/">RFC 2131</ulink>.
Informazioni aggiuntive sono presenti a questo URL:
<ulink url="http://www.dhcp.org/"></ulink>.</para>
</sect2>
<sect2 id="network-dhcp-server">
<title>Installare e Configurare un Server DHCP</title>
<sect3>
<title>Cosa Copre Questa Sezione</title>
<para>Questa sezione fornisce informazioni su come
configurare un sistema FreeBSD che funzioni come
un server DHCP usando l'implementazione del server
DHCP dell'ISC (Internet Software Consortium).</para>
<para>Il server non viene
fornito come parte di FreeBSD, così
dovrai installare il port
<filename role="package">net/isc-dhcp3-server</filename>
per fornire questo servizio. Vedi
<xref linkend="ports"/> per
più informazioni su come usare la Collezione
dei Port.</para>
</sect3>
<sect3>
<title>Installazione del DHCP Server</title>
<indexterm>
<primary>DHCP</primary>
<secondary>installazione</secondary>
</indexterm>
<para>Per configurare il tuo sistema FreeBSD
come un server DHCP, assicurati che il
device &man.bpf.4; sia compilato nel
kernel. Per farlo, aggiungi
<literal>device bpf</literal>
al file di configurazione del kernel, e ricompilalo. Per
maggiori informazioni su come compilare un kernel,
vedi <xref linkend="kernelconfig"/>.</para>
<para>Il device <devicename>bpf</devicename>
è già
parte del kernel <filename>GENERIC</filename>
che viene fornito con FreeBSD, così
non hai bisogno di creare
un kernel custom per far funzionare il DHCP.</para>
<note>
<para>Quelli di voi che sono particolarmente
attenti alla sicurezza, dovrebbero notare che
<devicename>bpf</devicename> è anche il
device che permette agli sniffer di pacchetti
di funzionare correttamente (anche se tali
programmi hanno bisogno di accesso privilegiato).
<devicename>bpf</devicename> <emphasis>è
</emphasis> richiesto per il funzionamento del DHCP,
ma se siete molto attenti alla sicurezza,
probabilmente non dovreste includere
<devicename>bpf</devicename>
nel vostro kernel semplicemente perchè vi
aspettate di usare il DHCP in qualche momento.</para>
</note>
<para>La prossima cosa che devi fare è
editare il file <filename>dhcpd.conf</filename> che
è stato installato dal port
<filename role="package">net/isc-dhcp3-server</filename>.
Di default, questo sarà
<filename>/usr/local/etc/dhcpd.conf.sample</filename>
e dovresti copiare questo file in
<filename>/usr/local/etc/dhcpd.conf</filename>
prima di procedere con i cambiamenti.</para>
</sect3>
<sect3>
<title>Configurare il Server DHCP</title>
<indexterm>
<primary>DHCP</primary>
<secondary>dhcpd.conf</secondary>
</indexterm>
<para><filename>dhcpd.conf</filename> è
composto di dichiarazioni riguardanti
sottoreti ed host, e forse lo si spiega
meglio con un esempio:</para>
<programlisting>option domain-name "example.com";<co id="domain-name"/>
option domain-name-servers 192.168.4.100;<co id="domain-name-servers"/>
option subnet-mask 255.255.255.0;<co id="subnet-mask"/>
default-lease-time 3600;<co id="default-lease-time"/>
max-lease-time 86400;<co id="max-lease-time"/>
ddns-update-style none;<co id="ddns-update-style"/>
subnet 192.168.4.0 netmask 255.255.255.0 {
range 192.168.4.129 192.168.4.254;<co id="range"/>
option routers 192.168.4.1;<co id="routers"/>
}
host mailhost {
hardware ethernet 02:03:04:05:06:07;<co id="hardware"/>
fixed-address mailhost.example.com;<co id="fixed-address"/>
}</programlisting>
<calloutlist>
<callout arearefs="domain-name">
<para>Questa opzione specifica il dominio che
verrà servito ai client come il dominio
di default di ricerca. Si veda
&man.resolv.conf.5; per più informazioni.</para>
</callout>
<callout arearefs="domain-name-servers">
<para>Questa opzione specifica una lista di server
DNS separata da virgole, che i client
dovrebbero usare.</para>
</callout>
<callout arearefs="subnet-mask">
<para>La netmask che sarà fornita ai client.</para>
</callout>
<callout arearefs="default-lease-time">
<para>Un client potrebbe richiedere una lunghezza di
tempo specifica per la quale il rilascio sarà
valido. Altrimenti il server assegnerà
un tempo di rilascio con questa durata (in secondi).</para>
</callout>
<callout arearefs="max-lease-time">
<para>Questa è la lunghezza massima di
tempo per la quale un server effettuerà
un rilascio. Se un client dovesse richiedere
un rilascio più lungo, sarà effettuato
un rilascio, anche se sarà valido solo per
<literal>max-lease-time</literal> secondi.</para>
</callout>
<callout arearefs="ddns-update-style">
<para>Questa opzione specifica se il server DHCP
dovrà cercare di modificare il DNS
quando un rilascio è accettato o
liberato. Nella implementazione ISC
questa opzione è
<emphasis>richiesta</emphasis>.</para>
</callout>
<callout arearefs="range">
<para>Questo identifica quale indirizzo IP
dovrà essere usato nel pool riservato
per l'allocazione ad i client. Gli indirizzi
IP fra, ed inclusi, quelli dichiarati sono
assegnabili agli utenti.</para>
</callout>
<callout arearefs="routers">
<para>Dichiara il default gateway che sarà
assegnato ad i client.</para>
</callout>
<callout arearefs="hardware">
<para>L'indirizzo hardware MAC di un host
(cosicchè il server DHCP
possa riconoscere un host quando
fa una richiesta).</para>
</callout>
<callout arearefs="fixed-address">
<para>Specifica che all'host dovrebbe sempre
essere fornito lo stesso indirizzo IP.
Nota che usare un hostname è
corretto in questo caso,
dato che il DHCP server risolverà
l'hostname stesso prima di restituire
l'informazione sul rilascio.</para>
</callout>
</calloutlist>
<para>Una volta che hai finito di scrivere
il tuo <filename>dhcpd.conf</filename>,
puoi abilitare il server DHCP in
<filename>/etc/rc.conf</filename>, aggiungendo:</para>
<programlisting>dhcpd_enable="YES"
dhcpd_ifaces="dc0"</programlisting>
<para>Sostituisci il nome dell'interfaccia
<literal>dc0</literal> con l'interfaccia
(o le interfacce, separate da spazi) su cui il tuo server DHCP
dovrebbe stare in ascolto per le richieste DHCP dei client.</para>
<para>Quindi, puoi procedere ad avviare il server con il
seguente comando:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/isc-dhcpd.sh start</userinput></screen>
<para>Se hai bisogno di fare altri cambiamenti
alla configurazione del server in futuro,
è importante notare che l'invio di
un segnale <literal>SIGHUP</literal>
a <application>dhcpd</application>
<emphasis>non</emphasis> fa sì che il file
di configurazione sia ricaricato, come avviene
con la maggior parte dei demoni. Dovrai inviare
un segnale <literal>SIGTERM</literal> per fermare
il processo, e poi riavviarlo usando il comando
sopracitato.</para>
</sect3>
<sect3>
<title>Files</title>
<indexterm>
<primary>DHCP</primary>
<secondary>file di configurazione</secondary>
</indexterm>
<itemizedlist>
<listitem>
<para><filename>/usr/local/sbin/dhcpd</filename></para>
<para><application>dhcpd</application> è
linkato staticamente e risiede in
<filename>/usr/local/sbin
</filename>. La pagina di manuale di
&man.dhcpd.8; installata con il port
dà più informazioni
su <application>dhcpd</application>.</para>
</listitem>
<listitem>
<para><filename>/usr/local/etc/dhcpd.conf</filename></para>
<para><application>dhcpd</application> richiede
un file di configurazione,
<filename>/usr/local/etc/dhcpd.conf
</filename>, prima che possa iniziare a
fornire il servizio ai client. Questo
file deve contenere tutte le informazioni
che devono essere fornite ai client che
sono serviti, oltre alle informazioni
riguardanti le operazioni del server. Questo
file di configurazione è descritto
dalla pagina di manuale &man.dhcpd.conf.5;
installata dal port.</para>
</listitem>
<listitem>
<para><filename>/var/db/dhcpd.leases</filename></para>
<para>Il server DHCP mantiene un database dei
rilasci che ha effettuato in questo file, che
viene scritto come un log. La pagina di manuale
&man.dhcpd.leases.5;, installata dal port
ne dà una descrizione leggermente pi`
lunga.</para>
</listitem>
<listitem>
<para><filename>/usr/local/sbin/dhcrelay</filename></para>
<para><application>dhcrelay</application> è
usata in ambienti avanzati dove un server
DHCP reinvia le richieste da un client ad un
altro server DHCP su una rete separata. Se
hai bisogno di questa
funzionalità, installa il port
<filename role="package">net/isc-dhcp3-relay</filename>.
La pagina di manuale &man.dhcrelay.8; fornita
col port contiene più dettagli.</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
</sect1>
<sect1 id="network-dns">
<sect1info>
<authorgroup>
<author>
<firstname>Chern</firstname>
<surname>Lee</surname>
<contrib>Grazie al contributo di </contrib>
</author>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</author>
<author>
<firstname>Daniel</firstname>
<surname>Gerzo</surname>
</author>
</authorgroup>
</sect1info>
<title>Domain Name System (<acronym>DNS</acronym>)</title>
<sect2>
<title>Uno sguardo d'insieme</title>
<indexterm><primary>BIND</primary></indexterm>
<para>&os; utilizza, di default, una versione di
BIND (Berkeley Internet Name Domain), che è
la più completa implementazione del protocollo
<acronym>DNS</acronym>. <acronym>DNS</acronym> è il protocollo
attraverso il quale nomi sono mappati ad indirizzi <acronym>IP</acronym>,
e viceversa. Per esempio, una query per
<hostid role="fqdn">www.FreeBSD.org
</hostid> riceverà una replica con l'indirizzo
<acronym>IP</acronym> del web server del The &os; Project, mentre una
query per <hostid role="fqdn">ftp.FreeBSD.org</hostid>
ritornerà l'indirizzo <acronym>IP</acronym> della corrispondente
macchina <acronym>FTP</acronym>. Allo stesso modo, può
avvenire l'opposto. Una
query per un indirizzo <acronym>IP</acronym> può risolvere il suo
nome host. Non è necessario avere in esecuzione
un name server per fare <acronym>DNS</acronym> lookups su un sistema.
</para>
<para>&os; al momento viene distribuito con software <acronym>DNS</acronym>
<acronym>BIND</acronym>9 di default. La nostra installazione fornisce
caratteristiche di sicurezza migliorate, un nuovo layout del file
system e configurazione &man.chroot.8; automatica.</para>
<indexterm><primary>DNS</primary></indexterm>
<para>DNS è coordinato su Internet attraverso
un sistema alquanto complesso di name server autoritativi,
ed altri name server di più piccola scala che
ospitano e gestiscono cache di informazioni individuali
sui domini.</para>
<para>Al momento corrente, BIND è mantenuto
dall'Internet Software Consortium
<ulink url="http://www.isc.org/"></ulink>.
</para>
</sect2>
<sect2>
<title>Terminologia</title>
<para>Per comprendere questo documento, alcuni termini
relativi al <acronym>DNS</acronym> devono essere capiti.</para>
<indexterm><primary>risolutore</primary></indexterm>
<indexterm><primary>DNS inverso</primary></indexterm>
<indexterm><primary>zona root</primary></indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*"/>
<colspec colwidth="3*"/>
<thead>
<row>
<entry>Termine</entry>
<entry>Definizione</entry>
</row>
</thead>
<tbody>
<row>
<entry>Forward <acronym>DNS</acronym></entry>
<entry>La mappa da hostname ad indirizzi IP.</entry>
</row>
<row>
<entry>Origine</entry>
<entry>Si riferisce al dominio coperto in
un particolare file di zona.</entry>
</row>
<row>
<entry><application>named</application>,
BIND, name server</entry>
<entry>Nomi comuni per il pacchetto name server BIND
all'interno di &os;.</entry>
</row>
<row>
<entry>Risolutore</entry>
<entry>Un processo di sistema attraverso il quale
una macchina fa query su un name server
per informazioni di zona.</entry>
</row>
<row>
<entry><acronym>DNS</acronym> inverso</entry>
<entry>L'opposto del forward <acronym>DNS</acronym>; mappare
indirizzi <acronym>IP</acronym> su nomi host.</entry>
</row>
<row>
<entry>Zona root</entry>
<entry>L'inizio della gerarchia della zona
Internet. Tutte le zone cadono sotto la
zona root, analogamente
a come tutti i file nel file system cadono sotto
la directory root.</entry>
</row>
<row>
<entry>Zona</entry>
<entry>Un dominio individuale, sottodominio, o
porzione del <acronym>DNS</acronym> amministrato dalla stessa
autorità</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<indexterm>
<primary>zone</primary>
<secondary>esempi</secondary>
</indexterm>
<para>Esempi di zone:</para>
<itemizedlist>
<listitem>
<para><hostid>.</hostid> è la zona root</para>
</listitem>
<listitem>
<para><hostid>org.</hostid> è una zona
Top Level Domain (<acronym>TLD</acronym>) sotto la zona root</para>
</listitem>
<listitem>
<para><hostid role="domainname">example.org.</hostid>
è una zona sotto la zona
<hostid>org.</hostid> <acronym>TLD</acronym></para>
</listitem>
<listitem>
<para>
<hostid>1.168.192.in-addr.arpa</hostid> è una zona
che referenzia tutti gli indirizzi <acronym>IP</acronym> che cadono
sotto lo spazio <acronym>IP</acronym> <hostid role="ipaddr">192.168.1.*</hostid>.
</para>
</listitem>
</itemizedlist>
<para>Come si può vedere, la parte più
specifica di un nome host appare a sinistra. Per esempio
<hostid role="domainname">example.org.</hostid> è
più specifico di <hostid>org.</hostid>, come
<hostid>org.</hostid> è più specifico
della zona root. La disposizione di ogni parte di un nome
host è analoga ad un file system: la
directory <filename>/dev</filename> cade
all'interno della root, e così via.</para>
</sect2>
<sect2>
<title>Ragioni per Avere in Esecuzione un Name Server</title>
<para>Attualmente vengono usati due tipi di name server:
un name server autoritativo, ed un name server cache.</para>
<para>Un name server autoritativo è necessario
quando:</para>
<itemizedlist>
<listitem>
<para>uno vuole servire informazioni <acronym>DNS</acronym> a tutto
il mondo, rispondendo in maniera autoritativa
alle query.</para>
</listitem>
<listitem>
<para>un dominio, tipo
<hostid role="domainname">example.org</hostid>, è
registrato e gli indirizzi <acronym>IP</acronym> devono essere
assegnati ad hostname sotto questo.</para>
</listitem>
<listitem>
<para>un blocco di indirizzi <acronym>IP</acronym> richiede
entry di <acronym>DNS</acronym> inverso (da <acronym>IP</acronym>
ad hostname).</para>
</listitem>
<listitem>
<para>un name server di backup, chiamato uno
slave, deve rispondere alle query.</para>
</listitem>
</itemizedlist>
<para>Un name server cache è necessario quando:</para>
<itemizedlist>
<listitem>
<para>un server locale DNS può tenere in cache e
rispondere più velocemente rispetto ad effettuare
query ad un name server all'esterno.</para>
</listitem>
<listitem>
<para>una riduzione nel traffico complessivo di
rete è desiderato (è stato
calcolato che il traffico DNS
conta più del 5% sul traffico totale di
Internet).</para>
</listitem>
</itemizedlist>
<para>Quando uno fa una query per risolvere
<hostid role="fqdn">www.FreeBSD.org</hostid>, il
risolutore di solito fa una query al name
server dell'<acronym>ISP</acronym> a cui si è connessi,
ed ottiene una risposta. Con un server <acronym>DNS</acronym>
locale, che fa cache,
la query deve essere effettuata una volta sola dal
server <acronym>DNS</acronym> che fa cache. Ogni
query aggiuntiva non dovrà cercare all'esterno
della rete locale, dato che l'informazione
è tenuta in cache localmente.</para>
</sect2>
<sect2>
<title>Come Funziona</title>
<para>In &os;, il demone BIND è chiamato
<application>named</application> per ovvie ragioni.</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<thead>
<row>
<entry>File</entry>
<entry>Descrizione</entry>
</row>
</thead>
<tbody>
<row>
<entry><application>&man.named.8;</application></entry>
<entry>Il demone BIND.</entry>
</row>
<row>
<entry><application>&man.rndc.8;</application></entry>
<entry>Programma di controllo del name server.</entry>
</row>
<row>
<entry><filename class="directory">/etc/namedb</filename></entry>
<entry>Directory dove risiedono le
informazioni di zona di BIND.</entry>
</row>
<row>
<entry><filename>/etc/namedb/named.conf</filename></entry>
<entry>File di configurazione del demone.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
A seconda di come certe zone sono configurate
sul server, i file relativi a quelle zone possono essere
trovate nelle sottodirectory <filename
class="directory">master</filename>, <filename
class="directory">slave</filename>, or <filename
class="directory">dynamic</filename> della directory
<filename class="directory">/etc/namedb</filename>.
Questi file contengono le informazioni <acronym>DNS</acronym>
che saranno distribuite dal name server in risposta alle query.</para>
</sect2>
<sect2>
<title>Avviare BIND</title>
<indexterm>
<primary>BIND</primary>
<secondary>avvio</secondary>
</indexterm>
<para>Dato che BIND è installato di default,
configurarlo è relativamente semplice.</para>
<para>La configurazione di default di <application>named</application>
è quella di un name server basilare, eseguito in
ambiente &man.chroot.8;. Per avviare il server una volta
con questa configurazione, usa il seguente comando:</para>
<screen>&prompt.root; <userinput>/etc/rc.d/named forcestart</userinput></screen>
<para>Per assicurarsi che il demone
<application>named</application>
sia avviato alla partenza, metti la seguente riga
in <filename>/etc/rc.conf</filename>:</para>
<programlisting>named_enable="YES"</programlisting>
<para>Ci sono ovviamente molte opzioni di configurazione
per <filename>/etc/namedb/named.conf</filename> che sono al di là
dello scopo di questo documento. Comunque, se siete interessati
nelle opzioni di avvio per <application>named</application> su &os;,
dai un'occhiata ai flags <literal>named_</literal> in
<filename>/etc/defaults/rc.conf</filename> e consulta la pagina
di manuale &man.rc.conf.5;. Anche la sezione <xref linkend="configtuning-initial"/>
è una buona base di partenza.</para>
</sect2>
<sect2>
<title>File di Configurazione</title>
<indexterm>
<primary>BIND</primary>
<secondary>file di configurazione</secondary>
</indexterm>
<para>I file di configurazione per <application>named</application>
al corrente risiedono nella directory <filename class="directory">
/etc/named</filename> e necessiteranno di modifiche prima
dell'uso, a meno che non si voglia un semplice resolver.
Qui è dove la maggior pare della configurazione viene
effettuata.</para>
<sect3>
<title>Usando <command>make-localhost</command></title>
<para>Per configurare una zona master per il localhost
visita la directory <filename class="directory">/etc/namedb</filename>
ed esegui il seguente comando:</para>
<screen>&prompt.root; <userinput>sh make-localhost</userinput></screen>
<para>Se tutto è andato bene, un nuovo file dovrebbe
esistere nella sottodirectory
<filename class="directory">master</filename>.
I nomi dei file dovrebbero essere <filename>localhost.rev</filename>
per il local domain name e<filename>localhost-v6.rev</filename>
per le configurazioni <acronym>IPv6</acronym>.
Come il file di configurazione di default, l'informazione
richiesta sarà presente nel file <filename>named.conf</filename>.
</para>
</sect3>
<sect3>
<title><filename>/etc/namedb/named.conf</filename></title>
<programlisting>// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works. Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.
options {
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };
// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
// forward only;
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
forwarders {
127.0.0.1;
};
*/</programlisting>
<para>Proprio come dicono i commenti, per beneficiare
di una cache di un server superiore, può
essere abilitato <literal>forwarders</literal>.
Sotto circostanze normali, un name
server farà query ricorsive attraverso Internet
cercando certi name server fino a chè non trova
la risposta che sta cercando. Averlo abilitato farà
sì che sarà fatta prima una query verso il
name server superiore (o il name server fornito),
avvantaggiandosi della sua cache. Se il name
server superiore è un name server molto
trafficato e veloce, può valere la pena di
abilitarlo.</para>
<warning>
<para><hostid role="ipaddr">127.0.0.1</hostid>
<emphasis>non</emphasis> funzionerà qui.
Cambia questo indirizzo <acronym>IP</acronym> in un name server
superiore.</para>
</warning>
<programlisting> /*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND versions 8 and later
* use a pseudo-random unprivileged UDP port by default.
*/
// query-source address * port 53;
};
// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "master/localhost.rev";
};
// RFC 3152
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
type master;
file "master/localhost-v6.rev";
};
// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries. It can be convenient to become
// a slave at least for the zone your own domain is in. Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
// (This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
// Before starting to set up a primary zone, make sure you fully
// understand how DNS and BIND works. There are sometimes
// non-obvious pitfalls. Setting up a slave zone is simpler.
//
// NB: Don't blindly enable the examples below. :-) Use actual names
// and addresses instead.
/* An example master zone
zone "example.net" {
type master;
file "master/example.net";
};
*/
/* An example dynamic zone
key "exampleorgkey" {
algorithm hmac-md5;
secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "dynamic/example.org";
};
*/
/* Examples of forward and reverse slave zones
zone "example.com" {
type slave;
file "slave/example.com";
masters {
192.168.1.1;
};
};
zone "1.168.192.in-addr.arpa" {
type slave;
file "slave/1.168.192.in-addr.arpa";
masters {
192.168.1.1;
};
};
*/</programlisting>
<para>In <filename>named.conf</filename>, ci sono esempi
di linee slave per zone di forward ed inverse.</para>
<para>Per ogni nuova zona servita, una nuova linea di
zona deve essere aggiunta a
<filename>named.conf</filename>.</para>
<para>Per esempio, la più semplice entry per
<hostid role="domainname">example.org</hostid> può
assomigliare a:</para>
<programlisting>zone "example.org" {
type master;
file "master/example.org";
};</programlisting>
<para>La zona è una master, come indicato
dall'entry <option>type</option>,
e conserva le informazioni di zona su
<filename>/etc/namedb/master/example.org</filename>
indicata dalla entry
<option>file</option>.</para>
<programlisting>zone "example.org" {
type slave;
file "slave/example.org";
};</programlisting>
<para>Nel caso slave, l'informazione di zona è
trasferita dal name server master per quella zona
particolare, e salvata nel file specificato. Se e
quando il master muore o è irraggiungibile,
il name server slave avrà le informazioni di
zona trasferite e sarà in grado di servirlo.</para>
</sect3>
<sect3>
<title>File di Zona</title>
<indexterm>
<primary>BIND</primary>
<secondary>zone files</secondary>
</indexterm>
<para>Un esempio di file di zona master per <hostid
role="domainname">example.org</hostid> (che esiste
all'interno di <filename>/etc/namedb/master/example.org
</filename>) è la seguente:</para>
<programlisting>$TTL 3600 ; 1 hour
example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ; Minimum TTL
)
; DNS Servers
IN NS ns1.example.org.
IN NS ns2.example.org.
; MX Records
IN MX 10 mx.example.org.
IN MX 20 mail.example.org.
IN A 192.168.1.1
; Machine Names
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5
; Aliases
www IN CNAME @</programlisting>
<para>Nota che ogni hostname che finisce in
un <quote>.</quote> è
un nome esatto, mentre ogni entità senza un
<quote>.</quote> è referenziato all'origine.
Per esempio <literal>www</literal> è trasformato
in <literal>www.<replaceable>origin</replaceable></literal>.
Nel nostro file di zone fittizio, la nostra origine
è <hostid>example.org</hostid>, così
<literal>www</literal> si trasformerebbe in
<hostid>www.example.org</hostid>.</para>
<para>Il formato di un file di zona è
il seguente:</para>
<programlisting>recordname IN recordtype
value</programlisting>
<indexterm>
<primary>DNS</primary>
<secondary>records</secondary>
</indexterm>
<para>I record DNS usati più di frequente:</para>
<variablelist>
<varlistentry>
<term>SOA</term>
<listitem>
<para>inizio di una zona di
autorità</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NS</term>
<listitem>
<para>un name server
autoritativo</para>
</listitem>
</varlistentry>
<varlistentry>
<term>A</term>
<listitem>
<para>un indirizzo host</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CNAME</term>
<listitem>
<para>il nome canonico per un
alias</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MX</term>
<listitem>
<para>mail exchanger</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PTR</term>
<listitem>
<para>un puntatore a nome di dominio (usato nel
DNS inverso)</para>
</listitem>
</varlistentry>
</variablelist>
<programlisting>
example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1
day</programlisting>
<variablelist>
<varlistentry>
<term><hostid role="domainname">example.org.</hostid></term>
<listitem>
<para>il nome di dominio, inoltre è
l'origine per questo file di zona.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><hostid role="fqdn">ns1.example.org.</hostid></term>
<listitem>
<para>il name server primario/autoritativo
per questa zona.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>admin.example.org.</literal></term>
<listitem>
<para>la persona responsabile per questa
zona, un indirizzo email con <quote>@</quote>
sostituito. (<email>admin@example.org</email>
diventa <literal>admin.example.org</literal>)</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>2006051501</literal></term>
<listitem>
<para>il numero di serie del file. Questo
deve essere aumentato ogni volta che il file di
zona è modificato. Al giorno d'oggi
molti amministratori preferiscono un formato
<literal>yyyymmddrr</literal> per il numero
di serie.
<literal>2006051501</literal> significherebbe
modificato l'ultima volta il 05/15/2006, l'ultimo
<literal>01</literal> essendo la prima volta che
il file di zona è stato modificato in
questo giorno. Il numero di serie è
importante dato che avverte
name server slave per una zona quando questa
` modificata.</para>
</listitem>
</varlistentry>
</variablelist>
<programlisting>
IN NS ns1.example.org.</programlisting>
<para>Questa è una linea NS. Ogni name server che
replicherà in maniera autoritativa la zona deve
avere una di queste linee. Il <literal>@</literal> come
visto potrebbe essere stato <hostid role="domainname">
example.org.</hostid>
Il <literal>@</literal> si traduce nell'origine.</para>
<programlisting>
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5</programlisting>
<para>Il record A indica un nome macchina. Come visto
sopra, <hostid role="fqdn">ns1.example.org</hostid>
risolverebbe in <hostid role="ipaddr">192.168.1.2</hostid>.
</para>
<programlisting>
IN A 192.168.1.1</programlisting>
<para>Questa linea assegna l'indirizzo IP
<hostid role="ipaddr">192.168.1.1</hostid> alla corrente origine,
in questo caso <hostid role="domainname">example.org</hostid>.</para>
<programlisting>
www IN CNAME @</programlisting>
<para>Il record nome canonico è usato per dare alias
ad una macchina. Nell'esempio, <hostid>www</hostid>
è tramutato in alias nella macchina <quote>master</quote>
che corrisponde al domain name <hostid role="domainname">example.org
</hostid> (<hostid role="ipaddr">192.168.1.1</hostid>).
CNAME possono essere usati per fornire alias
ad hostname o distribuire in round robin un
hostname fra molte macchine.</para>
<indexterm>
<primary>MX record</primary>
</indexterm>
<programlisting>
IN MX 10 mail.example.org.</programlisting>
<para>Il record MX ` usato per specificare quali
mail server sono responsabili per gestire mail
entranti per la zona.
<hostid role="fqdn">mail.example.org
</hostid> è l'hostname del mail
server, e 10 è la priorità di
quel mail server.</para>
<para>Uno può avere molti mail server, con
priorità di 10, 20 e così via. Un mail server che
cerca di consegnare una mail a
<hostid role="domainname">example.org</hostid>
proverà prima l'MX con la più alta
priorità (il record con il numero di priorita' minimo)
poi il secondo, etc., fino a
chè la mail non sia
consegnata correttamente.</para>
<para>Per file di zona in-addr.arpa (DNS inverso), lo stesso
formato è usato, eccetto con linee PTR
al posto di A o CNAME.</para>
<programlisting>$TTL 3600
1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
3600 ) ; Minimum
IN NS ns1.example.org.
IN NS ns2.example.org.
1 IN PTR example.org.
2 IN PTR ns1.example.org.
3 IN PTR ns2.example.org.
4 IN PTR mx.example.org.
5 IN PTR mail.example.org.</programlisting>
<para>Questo file da la corretta mappa da indirizzi
IP ad hostname per il nostro dominio fittizio.</para>
</sect3>
</sect2>
<sect2>
<title>Caching Name Server</title>
<indexterm>
<primary>BIND</primary>
<secondary>caching name server</secondary>
</indexterm>
<para>Un name server caching è un name server
che non è autoritativo per nessuna zona.
Fa semplicemente query, e ne memorizza le risposte
per uso successivo. Per impostarne uno, configura
il name server come al solito, omettendo ogni
inclusione di zona.</para>
</sect2>
<sect2>
<title>Sicurezza</title>
<para>Anche se BIND è la più comune
implementazione del DNS, c'è sempre la questione
della sicurezza. Talvolta vengono trovati possibili
e sfruttabili buchi di sicurezza.</para>
<para>Mentre &os; tiene <application>named</application>
automaticamente in un ambiente &man.chroot.8;,
ci sono molti altri meccanismi di sicurezza che
potrebbero essere sfruttati per attacchi al servizio
<acronym>DNS</acronym>.</para>
<para>È una buona idea leggere
gli avvisi sulla sicurezza di <ulink
url="http://www.cert.org/">CERT</ulink> e
sottoscrivere le &a.security-notifications;
per stare aggiornato con le questioni
correnti di sicurezza di Internet e FreeBSD.</para>
<tip>
<para>Se sorge un problema, tenere i
sorgenti aggiornati e fare una compilazione
al volo di <application>named
</application> non farebbe male.</para>
</tip>
</sect2>
<sect2>
<title>Ulteriori letture</title>
<para>Pagine di manuale di
BIND/<application>named</application>:
&man.rndc.8; &man.named.8; &man.named.conf.5;</para>
<itemizedlist>
<listitem>
<para><ulink
url="http://www.isc.org/products/BIND/">Official ISC BIND
Page</ulink></para>
</listitem>
<listitem>
<para><ulink
url="http://www.isc.org/sw/guild/bf/">Official ISC BIND
Forum</ulink></para>
</listitem>
<listitem>
<para><ulink
url="http://www.nominum.com/getOpenSourceResource.php?id=6">
BIND FAQ</ulink></para>
</listitem>
<listitem>
<para><ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly
DNS and BIND 4th Edition</ulink></para>
</listitem>
<listitem>
<para><ulink
url="ftp://ftp.isi.edu/in-notes/rfc1034.txt">RFC1034
- Domain Names - Concepts and Facilities</ulink></para>
</listitem>
<listitem>
<para><ulink
url="ftp://ftp.isi.edu/in-notes/rfc1035.txt">RFC1035
- Domain Names - Implementation and Specification</ulink></para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="network-apache">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
</sect1info>
<title>Apache HTTP Server</title>
<indexterm>
<primary>web server</primary>
<secondary>installare</secondary>
</indexterm>
<indexterm><primary>Apache</primary></indexterm>
<sect2>
<title>Uno sguardo d'insieme</title>
<para>&os; è usato per far girare
alcuni dei siti web più trafficati
al mondo. La maggioranza dei web server
su Internet usano attualmene
<application>Apache HTTP Server</application>.
Il pacchetto software di
<application>Apache</application>
dovrebbe essere incluso nel tuo media di
installazione di FreeBSD. Se non hai
installato <application>Apache</application>
quando hai installato FreeBSD per la prima volta,
lo puoi installare dal port
<filename role="package">www/apache13</filename>
o <filename role="package">www/apache22</filename>.</para>
<para>Una volta che <application>Apache</application>
è stato installato con successo, deve essere
configurato.</para>
<note>
<para>Questa sezione copre la versione 1.3.X
di <application>Apache HTTP Server</application>
dato che è la versione più usata per
&os;. <application>Apache</application> 2.X
introduce molte nuove tecnologie ma queste non
saranno discusse in questa sede. Per maggiori
informazioni su
<application>Apache</application> 2.X, per favore
consulta <ulink
url="httpd://httpd.apache.org/"></ulink>.</para>
</note>
</sect2>
<sect2>
<title>Configurazione</title>
<indexterm>
<primary>Apache</primary>
<secondary>file di configurazione</secondary>
</indexterm>
<para>Il principale file di configurazione
di <application>Apache HTTP Server</application>
è installato in
<filename>/usr/local/etc/apache/httpd.conf</filename>
su &os;. Questo file è un tipico file di testo
di configurazione di &unix; con linee di commento
che cominciano col carattere <literal>#</literal>.
Una descrizione comprensiva di tutte le possibili
opzioni di configurazione è al di fuori dello
scopo di questo libro, così solo le direttive
usate più di frequente saranno descritte
di seguito.</para>
<variablelist>
<varlistentry>
<term><literal>ServerRoot "/usr/local"</literal></term>
<listitem>
<para>Questo specifica la gerachia di directory
di default per l'installazione di
<application>Apache</application>. I binari
sono conservati nelle sottodirectory
<filename class="directory">bin</filename> e
<filename class="directory">sbin</filename>
sotto la server root, ed i file di configurazione
sono conservati sotto
<filename class="directory">etc/apache</filename>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ServerAdmin you@your.address</literal></term>
<listitem>
<para>L'indirizzo email al quale i problemi
riguardanti il server dovrebbero essere
inviati. Questo indirizzo appare su alcune
pagine generate dal server,
come alcuni documenti di errore.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>ServerName www.example.com</literal></term>
<listitem>
<para><literal>ServerName</literal> ti permette di
impostare un nome host che viene inviato
ai client per il tuo server, se questo
è differente da quello per il quale l'host
è configurato (ad esempio usi <hostid>www
</hostid> invece del vero nome host).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>DocumentRoot "/usr/local/www/data"</literal></term>
<listitem>
<para><literal>DocumentRoot</literal>: La directory
dalla quale servirai documenti. Di default
tutte le richieste sono girate a questa
directory, ma link simbolici ed alias
possono essere usati per puntare ad altre
locazioni.</para>
</listitem>
</varlistentry>
</variablelist>
<para>È sempre una buona idea fare copie di
backup del tuo file di configurazione di
<application>Apache</application> prima di
modificarlo. Una volta che sei soddisfatto dalla
tua configurazione iniziale sei pronto per
iniziare ad eseguire <application>Apache</application>.</para>
</sect2>
<sect2>
<title>Eseguire <application>Apache</application></title>
<indexterm>
<primary>Apache</primary>
<secondary>avviarlo o fermarlo</secondary>
</indexterm>
<para><application>Apache</application> non viene eseguito
dal super server <application>inetd</application>
a differenza di molti altri server di
rete. È configurato
per girare standalone per migliori performance
per gestire le richieste HTTP in entrata dai client
web browser. Un wrapper shell script è
incluso per rendere il più semplice
possibile lo start, lo stop ed il restart del
server. Per avviare <application>Apache</application>
per la prima volta, esegui:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl start</userinput></screen>
<para>Puoi fermare il server in ogni istante
digitando:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl stop</userinput></screen>
<para>Dopo aver fatto modifiche al file
di configurazione per una qualsiasi ragione,
avrai bisogno di riavviare
il server:</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl restart</userinput></screen>
<para>Per riavviare <application>Apache</application>
senza mandare in abort le connessioni correnti,
esegui.</para>
<screen>&prompt.root; <userinput>/usr/local/sbin/apachectl graceful</userinput></screen>
<para>Informazioni addizionali sono
disponibili sulla pagina di manuale
di &man.apachectl.8;.</para>
<para>Per eseguire <application>Apache</application>
all'avvio del sistema, aggiungi la seguente
linea ad <filename>/etc/rc.conf</filename>:</para>
<programlisting>apache_enable="YES"</programlisting>
<para>o per <application>Apache</application> 2.2:</para>
<programlisting>apache22_enable="YES"</programlisting>
<para>Se volessi fornire opzioni addizionali
di linea di comando al programma
<application>Apache</application>
<command>httpd</command>
avviato al boot di sistema, puoi specificarle
con una linea addizionale in
<filename>rc.conf</filename>:</para>
<programlisting>apache_flags=""</programlisting>
<para>Ora che il web server è in esecuzione
puoi navigare il tuo sito web puntando
il tuo web browser ad
<literal>http://localhost/</literal>.
La pagina di default che viene mostrata
è
<filename>/usr/local/www/data/index.html</filename>.</para>
</sect2>
<sect2>
<title>Virtual Hosting</title>
<para><application>Apache</application> supporta due
tipi diversi di Virtual Hosting. Il primo metodo
è Virtual Hosting basato sul nome. Il
Virtual Hosting basato sul nome usa gli header
HTTP/1.1 per scoprire l'hostname. Questo permette
a molti domini diversi di condividere lo stesso
indirizzo IP.</para>
<para>Per fare sì che
<application>Apache</application>
usi Virtual Hosting basato sui nomi aggiungi una
entry come la seguente al tuo file
<filename>httpd.conf</filename>:</para>
<programlisting>NameVirtualHost *</programlisting>
<para>Se il tuo webserver era nominato
<hostid role="fqdn">www.domain.tld</hostid> e
tu avessi voluto installare un dominio virtuale
per <hostid role="fqdn">www.someotherdomain.tld
</hostid> avresti dovuto aggiungere le seguenti entry
a <filename>httpd.conf</filename>:</para>
<screen><VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain.tld
</VirtualHost>
<VirtualHost *>
ServerName www.someotherdomain.tld
DocumentRoot /www/someotherdomain.tld
</VirtualHost></screen>
<para>Sostituisci gli indirizzi con gli indirizzi
che vuoi usare ed i percorsi dei documenti con quelli
che usi.</para>
<para>Per maggiori informazioni sull'impostazione
dei virtual host, per favore consulta la
documentazione ufficiale a
<ulink url="http://httpd.apache.org/docs/vhosts/">
</ulink>.</para>
</sect2>
<sect2>
<title>Moduli Apache</title>
<indexterm>
<primary>Apache</primary>
<secondary>moduli</secondary>
</indexterm>
<para>Ci sono molti diversi moduli
<application>Apache</application> disponibili
per aggiungere funzionalità al server base.
La Collezione Port di FreeBSD fornisce un modo
semplice di installare <application>Apache</application>
assieme ad alcuni dei più popolari moduli
aggiuntivi.</para>
<sect3>
<title>mod_ssl</title>
<indexterm>
<primary>server web</primary>
<secondary>sicuri</secondary>
</indexterm>
<indexterm><primary>SSL</primary></indexterm>
<indexterm><primary>crittografia</primary></indexterm>
<para>Il modulo <application>mod_ssl</application>
usa la libreria OpenSSL per fornire una forte
crittografia attraverso i protocolli Secure
Sockets Layer (SSL v2/v3) e Transport Layer
Security (TLS v1). Questo modulo fornisce tutto
il necessario per richiedere
un certificato firmato da un'autorità fidata
che emette certificati, cosicchè puoi eseguire
un web server sicuro su &os;.</para>
<para>Se non hai ancora installato
<application>Apache</application>, una versione
di <application>Apache</application> 1.3.X
che includa <application>mod_ssl</application>
può essere installata con il port
<filename role="package">www/apache13-modssl</filename>.
Il supporto ad SSL è anche disponibile per
<application>Apache</application> 2.X nel port
<filename role="package">www/apache22</filename>,
dove viene abilitato di default.</para>
</sect3>
<sect3>
<title>Siti web dinamici con Perl & PHP</title>
<para>Negli ultimi anni, molte aziende si sono rivolte a Internet
per migliorare i loro ricavi e aumentare la loro esposizione.
Questo ha anche aumentato il bisogno di contenuti interattivi
web. Mentre alcune società come µsoft; hanno introdotto
soluzioni nei loro prodotti proprietari, la comunità
open source ha risposto all'appello. Due opzioni per contenuti
web dinamici includono <application>mod_perl</application>
& <application>mod_php</application>.</para>
<sect4>
<title>mod_perl</title>
<indexterm><primary>Perl</primary></indexterm>
<para>Il progetto di integrazione
<application>Apache</application>/Perl
mette assieme la grande potenza del linguaggio
di programmazione Perl e
l'<application>Apache HTTP Server</application>.
Con il modulo <application>mod_perl</application>
è possibile scrivere moduli <application>Apache
</application> interamente in Perl. In aggiunta
l'interprete persistente integrato nel server
evita l'overhead di avviare un interprete esterno
e la penalizzazione del tempo di
caricamento Perl.</para>
<para><application>mod_perl</application> è disponibile
in alcuni modi diversi. Per usare <application>mod_perl
</application> ricorda che <application>mod_perl</application>
1.0 funziona solo con <application>Apache</application> 1.3
e <application>mod_perl</application> 2.0 funziona solo
con <application>Apache</application> 2.X.
<application>mod_perl</application> 1.0 è disponibile
in <filename role="package">www/mod_perl</filename> ed una versione
compilata staticamente è disponibile in
<filename role="package">www/apache13-modperl</filename>.
<application>mod_perl</application> 2.0 è disponibile in
<filename role="package">www/mod_perl2</filename>.</para>
</sect4>
<sect4>
<sect4info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Scritto da </contrib>
</author>
</authorgroup>
</sect4info>
<title>mod_php</title>
<indexterm>
<primary>mod_php</primary>
<secondary>PHP</secondary>
</indexterm>
<para>PHP, anche noto come <quote>Hypertext Prepocessor</quote>
è un linguaggio di scripting di scopo generale che è
particolarmente adatto per lo sviluppo Web. Adatto ad essere
usato all'interno dell'<acronym>HTML</acronym>, la sua sintassi
deriva dal C, &java;, e Perl con l'intenzione di permettere agli
sviluppatori web di scrivere pagine web generate dinamicamente
in modo veloce.</para>
<para>Per integrare supporto a <acronym>PHP</acronym>5 per
il web server <application>Apache</application>, inizia
con l'installare il port
<filename role="package">lang/php5</filename>.
</para>
<para>Se il port <filename role="package">lang/php5</filename>
viene installato per la prima volta, le <literal>OPTIONS</literal>
disponibili saranno mostrate automaticamente.
Se non viene mostrato un menu, ad esempio perché
il port <filename role="package">lang/php5</filename>
è stato installato qualche volta in passato,
è sempre possibile rivedere il menu a dialogo
con le opzioni eseguendo:</para>
<screen>&prompt.root; <userinput>make config</userinput></screen>
<para>nella directory dei port.</para>
<para>Nel menu a dialogo delle opzioni,
flagga l'opzione <literal>APACHE</literal>
per compilare <application>mod_php5</application>
come modulo caricabile per il web server
<application>Apache</application>.</para>
<note>
<para>Molti siti stanno ancora usando
<acronym>PHP</acronym>4 per varie ragioni (ad esempio
questioni di compatibilità o applicativi web già
costruiti). Se si necessita del modulo <application>mod_php4</application>
invece che di <application>mod_php5</application>, siete pregati
di usare il port <filename role="package">lang/php4</filename>.
Il port <filename role="package">lang/php4</filename> supporta
molte delle configurazioni e delle opzioni di build-time
del port <filename role="package">lang/php5</filename>.</para>
</note>
<para>Questo installerà e
configurerà i moduli richiesti
per supportare applicazioni web dinamiche <acronym>PHP</acronym>.
Controlla che le seguenti linee siano state aggiunte al file
<filename>/usr/local/etc/apache/httpd.conf</filename>:</para>
<programlisting>LoadModule php5_module libexec/apache/libphp5.so
AddModule mod_php5.c
<IfModule mod_php5.c>
DirectoryIndex index.php index.html
</IfModule>
<IfModule mod_php5.c>
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
</IfModule></programlisting>
<para>Una volta completato, una semplice chiamata
al comando <command>apachectl</command> per un tranquillo
restart è richiesto per caricare il modulo
<acronym>PHP</acronym>:</para>
<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>
<para>Per upgrade futuri di <acronym>PHP</acronym>, il comando
<command>make config</command> non sarà richiesto;
le <literal>OPTIONS</literal> selezionate sono salvate automaticamente
dal sistema dei Ports di &os;.</para>
<para>Il supporto a <acronym>PHP</acronym> in &os; è
estremamente modulare così l'installazione
base è molto limitata. È molto facile
aggiungere supporto usando il port
<filename role="package">lang/php5-extensions</filename>.
Questo port fornisce un interfaccia a menu per l'installazione
di estensioni a <acronym>PHP</acronym>. Alternativamente
le singole estensioni possono essere installate usando
il port appropriato.</para>
<para>Ad esempio, per aggiungere supporto al database
<application>MySQL</application> a <acronym>PHP</acronym>5,
semplicemente installa
<filename role="package">databases/php5-mysql</filename>.</para>
<para>Dopo aver installato un'estensione, il server
<application>Apache</application> deve essere riavviato per
caricare i cambiamenti della nuova configurazione:</para>
<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>
</sect4>
</sect3>
</sect2>
</sect1>
<sect1 id="network-ftp">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Grazie al Contributo di </contrib>
</author>
</authorgroup>
</sect1info>
<title>File Transfer Protocol (FTP)</title>
<indexterm><primary>Server FTP</primary></indexterm>
<sect2>
<title>Uno sguardo d'insieme</title>
<para>Il File Transfer Protocol (FTP) fornisce
agli utenti un semplice modo di trasferire
file da e verso un server
<acronym role="File Transfer Protocol">FTP</acronym>.
&os; include software per server
<acronym role="File Transfer Protocol">FTP</acronym>
nel sistema base. Questo rende l'installazione
e l'ammininistrazione di un server
<acronym role="File Transfer Protocol">FTP</acronym>
molto semplice.</para>
</sect2>
<sect2>
<title>Configurazione</title>
<para>Il più importante passo di
configurazione è decidere a quali
account saraà permesso
accedere al server FTP. Un sistema normale
FreeBSD ha un certo numero di account di sistema
usati per vari demoni, ma agli utenti estranei
non dovrebbe essere permesso di loggarsi con questi
account. Il file
<filename>/etc/ftpusers</filename> è una lista
di utenti a cui è negato l'accesso FTP.
Di default include gli account di sistema sopra citati
ma è possibile aggiungere utenti specifici
che non dovrebbero avere accesso FTP.</para>
<para>Può essere che tu voglia restringere
l'accesso ad alcuni utenti senza impedir loro
di usare completamente FTP. Ciò
può essere ottenuto
con il file <filename>/etc/ftpchroot</filename>.
Questo file elenca utenti e gruppi soggetti a
restrizioni di accesso FTP. La pagina di manuale
&man.ftpchroot.5; ha tutti i dettagli così
non sarà descritta qui.</para>
<indexterm>
<primary>FTP</primary>
<secondary>anonimo</secondary>
</indexterm>
<para>Se tu volessi abilitare accesso anonimo
FTP al tuo server, devi creare un utente chiamato
<username>ftp</username> sul tuo sistema &os;.
Gli utenti allora potranno loggarsi al tuo server FTP
con uno username di <username>ftp</username>
o <username>anonymous</username> e con
una password qualsiasi
(di norma dovrebbe essere usato un indirizzo email
dell'utente come password). Il server FTP
chiamerà &man.chroot.2; quando un utente
anonimo si logga, per restringere l'accesso solo
alla home directory di <username>ftp</username>.</para>
<para>Ci sono due file di testo che specificano
messaggi di benvenuto per i client FTP. Il contenuto
del file <filename>/etc/ftpwelcome</filename> sarà
mostrato agli utenti prima che raggiungano il prompt
del login. Dopo un login di successo, il contenuto
del file <filename>/etc/ftpmotd</filename> sarà
mostrato. Nota che il percorso di questo file è
relativo all'ambiente di login, così
saraà mostrato il file
<filename>~ftp/etc/ftpmotd</filename>.</para>
<para>Una volta che il server FTP è
stato configurato
correttamente, deve essere abilitato in
<filename>/etc/inetd.conf</filename>. Tutto ciò
che viene richiesto è rimuovere il simbolo
di commento <quote>#</quote> dall'inizio della linea
relativa a <application>ftpd</application>:</para>
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
<para>Come spiegato in <xref linkend="network-inetd-reread"/>,
la configurazione di <application>inetd</application>
deve essere ricaricata dopo che
che questo file di configurazione è stato cambiato.</para>
<para>Ora puoi loggarti al tuo server FTP digitando:</para>
<screen>&prompt.user; <userinput>ftp localhost</userinput></screen>
</sect2>
<sect2>
<title>Manutenzione</title>
<indexterm><primary>syslog</primary></indexterm>
<indexterm>
<primary>file di log</primary>
<secondary>FTP</secondary>
</indexterm>
<para>Il demone <application>ftpd</application> usa
&man.syslog.3; per loggare i mesaggi. Di default
il demone dei log di sistema girerà
i messaggi relativi a FTP nel file
<filename>/var/log/xferlog</filename>. La posizione
del log FTP può essere modificata cambiando
la seguente linea in
<filename>/etc/syslog.conf</filename>:</para>
<programlisting>ftp.info /var/log/xferlog</programlisting>
<indexterm>
<primary>FTP</primary>
<secondary>anonimo</secondary>
</indexterm>
<para>Presta attenzione ai problemi potenziali
correlati all'esecuzione di un server FTP anonimo.
In particolare, dovresti pensarci due volte prima di
permettere agli utenti anonimi di fare upload di file.
Potresti scoprire che il tuo sito FTP è
diventato un forum per il commercio di software
commerciale senza licenza o anche peggio.
Se hai veramente bisogno di permettere upload FTP
anonimi, allora dovresti impostare i permessi
in modo che questi file non possano essere letti
da altri utenti fino a che non siano
stati revisionati.</para>
</sect2>
</sect1>
<sect1 id="network-samba">
<sect1info>
<authorgroup>
<author>
<firstname>Murray</firstname>
<surname>Stokely</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
</sect1info>
<title>Servizi di File e Stampa per client
µsoft.windows; (Samba)</title>
<indexterm><primary>Server Samba</primary></indexterm>
<indexterm><primary>Microsoft Windows</primary></indexterm>
<indexterm>
<primary>file server</primary>
<secondary>Windows client</secondary>
</indexterm>
<indexterm>
<primary>print server</primary>
<secondary>Windows client</secondary>
</indexterm>
<sect2>
<title>Uno sguardo d'insieme</title>
<para><application>Samba</application> è un
popolare pacchetto software open source che
fornisce servizi di file e stampa per client
µsoft.windows;. Tali client possono connettersi
ed usare un file system FreeBSD
come se fosse un disco locale, o stampanti
FreeBSD come se fossero stampanti locali.</para>
<para>Il pacchetto software
<application>Samba</application>
dovrebbe essere incluso nel tuo media di
installazione FreeBSD. Se non hai
installato <application>Samba</application>
quando hai installato per la prima volta FreeBSD,
puoi sempre installarlo dal port o pacchetto
<filename role="package">net/samba3</filename>.</para>
</sect2>
<sect2>
<title>Configurazione</title>
<para>Un file di configurazione di
<application>Samba</application> di default è
installato in
<filename>/usr/local/share/examples/smb.conf.default</filename>.
Questo file deve essere copiato in
<filename>/usr/local/etc/smb.conf</filename>
e personalizzato prima che
<application>Samba</application> possa essere usato.</para>
<para>Il file <filename>smb.conf</filename> contiene
informazione di configurazione runtime per
<application>Samba</application>, come le definizioni
delle stampanti e <quote>share di file system</quote>
che vorresti condividere con &windows; client.
Il pacchetto <application>Samba</application> include
un tool basato sul web chiamato
<application>swat</application> che fornisce
un modo semplice di configurare il file
<filename>smb.conf</filename>.</para>
<sect3>
<title>Usare il Samba Web Administration Tool (SWAT)</title>
<para>Il Samba Web Administration Tool (SWAT) viene
eseguito come demone da
<application>inetd</application>.
Quindi, dovresti togliere i commenti
alla seguente linea in
<filename>/etc/inetd.conf</filename>
prima che <application>swat</application> possa essere
usato per configurare
<application>Samba</application>:</para>
<programlisting>swat stream tcp nowait/400 root /usr/local/sbin/swat swat</programlisting>
<para>Come spiegato in
<xref linkend="network-inetd-reread"/>,
la configurazione di <application>inetd</application>
deve essere ricaricata dopo che
questo file di configurazione è
stato cambiato.</para>
<para>Una volta che <application>swat</application>
è stato abilitato in
<filename>inetd.conf</filename>,
puoi usare un browser per connetterti a
<ulink url="http://localhost:901"></ulink>.
Dovrai prima loggarti con l'account di sistema
<username>root</username>.</para>
<!-- XXX screenshots go here, loader is creating them -->
<para>Una volta che ti sei loggato con successo
alla pagina principale di configurazione di
<application>Samba</application>, puoi navigare
la documentazione di sistema, o iniziare
cliccando sul tab
<guimenu>Globals</guimenu>. La sezione
<guimenu>Globals</guimenu> corrisponde alle variabili
che sono impostate nella sezione
<literal>[global]</literal> di
<filename>/usr/local/etc/smb.conf</filename>.</para>
</sect3>
<sect3>
<title>Impostazioni Globali</title>
<para>Sia che tu stia usando
<application>swat</application>
o che tu stia editando direttamente
<filename>/usr/local/etc/smb.conf</filename>,
le prime direttive che tu puoi incontrare quando
configuri <application>Samba</application> sono:</para>
<variablelist>
<varlistentry>
<term><literal>workgroup</literal></term>
<listitem>
<para>Nome dominio NT o nome Workgroup
per i computer che accedono a questo server.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>netbios name</literal></term>
<listitem>
<indexterm><primary>NetBIOS</primary></indexterm>
<para>Questo imposta il nome NetBIOS attraverso
il quale un <application>Samba</application>
è conosciuto. Di default è
lo stesso della prima parte del nome host
DNS.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>server string</literal></term>
<listitem>
<para>Questo imposta la stringa che sarà
mostrata con il comando <command>net view</command>
e con alcuni altri strumenti di rete che cercano
di mostrare testo descrittivo sul
server.</para>
</listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
<title>Impostazioni di Sicurezza</title>
<para>Due delle più importanti impostazioni
in <filename>/usr/local/etc/smb.conf</filename>
sono i modelli di sicurezza usati, ed il formato
delle password di backend per utenti client.
Le seguenti direttive controllano queste
opzioni:</para>
<variablelist>
<varlistentry>
<term><literal>security</literal></term>
<listitem>
<para>Le due più comuni opzioni in
questo caso sono
<literal>security = share</literal>
e <literal>security = user</literal>.
Se i tuoi client usano nomi utente che sono
gli stessi dei nomi utenti sulla tua macchina
&os;, allora vorrai sicurezza di tipo
user. Questa è la policy di sicurezza
di default e richiede ai client prima di
loggarsi prima che possano accedere a risorse
condivise.</para>
<para>Nel modello di sicurezza di tipo share,
i client non hanno bisogno di loggarsi al server
con una valida coppia username e password
prima che provino a connettersi a risorse
condivise. Questo è il modello di sicurezza
di default per versioni precedenti di
<application>Samba</application>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>passdb backend</literal></term>
<listitem>
<indexterm><primary>NIS+</primary></indexterm>
<indexterm><primary>LDAP</primary></indexterm>
<indexterm><primary>SQL database</primary></indexterm>
<para><application>Samba</application> ha molti
modelli diversi di backend di autenticazione.
Puoi autenticare i client con LDAP, NIS+, un
database SQL, o un file di password modificato.
Il metodo di autenticazione di default
è <literal>smbpasswd</literal>, e questo
sarà l'unico coperto qui.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Assumendo che il backend usato sia
quello di default, <literal>smbpasswd</literal>,
il file <filename>/usr/local/private/smbpasswd</filename>
deve essere creato per permettere a
<application>Samba</application> di autenticare i
client. Se tu volessi dare ai tuoi account
&unix; accesso da client &windows;, usa il seguente
comando:</para>
<screen>&prompt.root; <userinput>smbpasswd -a username</userinput></screen>
<para>Per favore consulta l' <ulink
url="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/">Official Samba HOWTO</ulink>
<ulink
url="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/">HOWTO
Ufficiale di Samba</ulink>
per informazioni addizionali sulle opzioni
di configurazione.
Con le basi delineate qui, dovresti avere tutto
ciò di cui hai bisogno per avviare
<application>Samba</application>.</para>
</sect3>
</sect2>
<sect2>
<title>Avviare <application>Samba</application></title>
<para>Il port <filename role="package">net/samba3</filename>
aggiunge un nuovo script di avvio, che può essere
usato per controllare
<application>Samba</application>. Per abilitare questo script,
in modo tale da essere usato per esempio per avviare
fermare o far ripartire
<application>Samba</application>, aggiungi la riga seguente
al file <filename>/etc/rc.conf</filename>:</para>
<programlisting>samba_enable="YES"</programlisting>
<para>Oppure, per un controllo più accurato:</para>
<programlisting>nmbd_enable="YES"</programlisting>
<programlisting>smbd_enable="YES"</programlisting>
<note>
<para>In questo modo <application>Samba</application>
viene avviato automaticamente ad ogni avvio
del sistema.</para>
</note>
<para>Per avviare
<application>Samba</application> digita:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba start</userinput>
Starting SAMBA: removing stale tdbs :
Starting nmbd.
Starting smbd.</screen>
<para>Fai riferimento alla <xref linkend="configtuning-rcd"/> per
ulteriori informazioni sull'uso degli script rc.</para>
<para><application>Samba</application> attualmente
consiste di tre demoni separati. Dovresti
osservare che entrambi <application>nmbd</application>
e <application>smbd</application> siano avviati
dallo script <filename>samba</filename>. Se
hai abilitato servizi di risoluzione di nomi
winbind in <filename>smb.conf</filename>, allora
osserverai che anche il demone
<application>winbindd</application> è avviato.</para>
<para>Puoi anche fermare <application>Samba</application>
in ogni istante digitando:</para>
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba stop</userinput></screen>
<para><application>Samba</application> è una suite
complessa di software con funzionalità che permette
una larga integrazione con reti µsoft.windows;.
Per maggiori informazioni sulle funzionalità
al di là dell'installazione di base descritta qui
per favore consulta <ulink url="http://www.samba.org">
</ulink>.</para>
</sect2>
</sect1>
<sect1 id="network-ntp">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Hukins</surname>
<contrib>Grazie al contributo di </contrib>
</author>
</authorgroup>
</sect1info>
<title>Sincronizzazione del Clock con NTP</title>
<indexterm><primary>NTP</primary></indexterm>
<sect2>
<title>Uno sguardo d'insieme</title>
<para>Al passare del tempo, il clock di un computer tende
a perdere la sincronizzazione. Il Network Time Protocol
(NTP) fornisce un modo per assicurarti che il tuo
clock sia accurato.</para>
<para>Molti servizi Internet si basano sul fatto che
il clock del computer sia accurato, o comunque
traggono notevole beneficio
da questo fatto. Per esempio, un web server
può ricevere richieste di inviare un file se
questo è stato modificato da una certa
data. In un ambiente locale di rete, è
essenziale che i computer che condividono
i file dallo stesso file server abbiano clock
sincronizzati cosicchè i timestamp dei file
siano consistenti. Anche servizi come &man.cron.8;
si basano su un clock di sistema accurato per eseguire
comandi al momento specificato.</para>
<indexterm>
<primary>NTP</primary>
<secondary>ntpd</secondary>
</indexterm>
<para>FreeBSD è dotato del server &man.ntpd.8;
<acronym role="Network Time Protocol">NTP</acronym>
che può essere usato per interrogare altri
server <acronym role="Network Time Protocol">NTP</acronym>
per impostare il clock sulla tua macchina o fornire
servizi di time ad altri.</para>
</sect2>
<sect2>
<title>Scegliere Server NTP Appropriati</title>
<indexterm>
<primary>NTP</primary>
<secondary>scegliere i server</secondary>
</indexterm>
<para>Per sincronizzare il tuo
clock, avrai bisogno di scegliere uno o più
server <acronym role="Network Time Protocol">NTP</acronym>
da usare. Il tuo amministratore di rete o ISP
potrebbe aver impostato un server NTP, a questo scopo
— controlla la loro documentazione per vedere se
questo è il caso. C'è una
<ulink url="http://ntp.isc.org/bin/view/Servers/WebHome">
lista online di server NTP pubblicamente accessibili
</ulink> che tu puoi usare per trovare un server NTP
vicino a te. Accertati di essere al corrente della
politica di ogni server che scegli, e chiedi il
permesso se necessario.</para>
<para>Scegliere molti server NTP non connessi
fra loro è una buona idea in caso uno
dei server che stai usando diventa irraggiungibile
o il suo clock è inaffidabile.
&man.ntpd.8; usa le risposte che riceve
da altri server in modo intelligente;
favorirà server inaffidabili meno di quelli
affidabili.</para>
</sect2>
<sect2>
<title>Configurare la tua Macchina</title>
<indexterm>
<primary>NTP</primary>
<secondary>configurazione</secondary>
</indexterm>
<sect3>
<title>Configurazione Base</title>
<indexterm><primary>ntpdate</primary></indexterm>
<para>Se desideri solo sincronizzare il tuo clock
al momento del boot della macchina, puoi usare
&man.ntpdate.8;. Questo può essere
appropriato per alcune macchine desktop che sono
rebootate di frequente e richiedono
sincronizzazione non frequente, ma le altre macchine
dovrebbero eseguire &man.ntpd.8;.</para>
<para>Usare &man.ntpdate.8; al momento del boot
è una buona idea per le macchine che eseguono
&man.ntpdate.8;. Il programma &man.ntpd.8; cambia il
clock gradualmente, mentre &man.ntpdate.8; imposta
il clock, indipentemente da quanto grande sia la
differenza fra l'impostazione di clock corrente di una
macchina e l'ora corretta.</para>
<para>Per abilitare &man.ntpdate.8; al momento del boot,
aggiungi <literal>ntpdate_enable="YES"</literal>
a <filename>/etc/rc.conf</filename>. Avrai anche
bisogno di specificare tutti i server
con i quali ti desideri
sincronizzare ed ogni flags passato a &man.ntpdate.8;
in <varname>ntpdate_flags</varname>.</para>
</sect3>
<sect3>
<title>Configurazione Generale</title>
<indexterm>
<primary>NTP</primary>
<secondary>ntp.conf</secondary>
</indexterm>
<para>NTP è configurato dal file
<filename>/etc/ntp.conf</filename> nel formato
descritto da &man.ntp.conf.5;. Questo è
un semplice esempio:</para>
<programlisting>server ntplocal.example.com prefer
server timeserver.example.org
server ntp2a.example.net
driftfile /var/db/ntp.drift</programlisting>
<para>L'opzione <literal>server</literal> specifica
quali server siano da usare, con un server elencato
su ogni linea. Se un server è specificato con
l'argomento <literal>prefer</literal>, come con
<hostid role="fqdn">ntplocal.example.com</hostid>,
quel server saraà preferito rispetto ad
altri. Una risposta da un server preferito
sarà scartata se differisce
in modo significativo dalle risposte di altri server,
altrimenti sarà usata senza nessuna
considerazione delle altre risposte. L'argomento
<literal>prefer</literal> è normalmente usato
per server NTP che sono noti per
essere molto accurati, come quelli con hardware a
monitoraggio speciale del tempo.</para>
<para>L'opzione <literal>driftfile</literal> specifica
quale file sia usato per conservare la frequenza di
scostamento dal clock di sistema. Il programma
&man.ntpd.8; usa questo dato per compensare
automaticamente le imprecisioni naturali del clock,
permettendo di mantenere una impostazione ragionevolmente
corretta anche se gli è impedito di accedere
a tutte le sorgenti di sincronizzazione tempo esterne
per un certo periodo di tempo.</para>
<para>L'opzione <literal>driftfile</literal> specifica
quale file sia usato per conservare informazioni sulle
risposte precedenti dai server NTP che usi. Questo file
contiene informazioni interne per NTP. Non dovrebbe
essere modificato da altri processi.</para>
</sect3>
<sect3>
<title>Controllare l'Accesso ad i tuoi Server</title>
<para>Di default, il tuo server NTP sarà accessibile
a tutti gli host su Internet. L'opzione
<literal>restrict</literal> in
<filename>/etc/ntp.conf</filename> ti permette
di controllare quali macchine possano accedere al tuo
server.</para>
<para>Se vuoi negare a tutte le macchine accesso
al tuo server NTP, aggiungi la seguente linea a
<filename>/etc/ntp.conf</filename>:</para>
<programlisting>restrict default ignore</programlisting>
<note>
<para>Inoltre questo settaggio vieta l'accesso
al tuo server dai server elencati nella tua configurazione
locale. Se hai bisogno di sincronizzare il tuo
server NTP con un server NTP esterno devi permettere
il server che vuoi usare. Guada la pagina man
&man.ntp.conf.5; per ulteriori dettagli.</para>
</note>
<para>Se vuoi permettere solo alle macchine della tua rete
di sincronizzare il loro clock con il tuo server,
ma assicurarti che non gli sia permesso configurare
il server o che non sianousate
come punto di riferimento per
sincronizzarsi, aggiungi</para>
<programlisting>restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap</programlisting>
<para>invece, dove<hostid role="ipaddr">192.168.1.0</hostid>
è un indirizzo IP sulla tua rete e
<hostid role="ipaddr">255.255.255.0</hostid>
è la netmask della tua rete.</para>
<para><filename>/etc/ntp.conf</filename> può
contenere molte opzioni <literal>restrict</literal>.
Per maggiori dettagli, consulta la sezione
<literal>Access Control Support</literal> di
&man.ntp.conf.5;.</para>
</sect3>
</sect2>
<sect2>
<title>Eseguire il Server NTP</title>
<para>Per assicurarsi che il server NTP sia avviato
al momento del boot, aggiungi la linea
<literal>ntpd_enable="YES"</literal> a
<filename>/etc/rc.conf</filename>. Se desideri
passare flag addizionali a &man.ntpd.8;, edita
il parametro <varname>ntpd_flags</varname>
in <filename>/etc/rc.conf</filename>.</para>
<para>Per avviare il server senza riavviare la tua
macchina, esegui <command>ntpd</command> accertandoti
di specificare ogni parametro addizionale in
<varname>ntpd_flags</varname> presente in
<filename>/etc/rc.conf</filename>. Per esempio:</para>
<screen>&prompt.root; <userinput>ntpd -p /var/run/ntpd.pid</userinput></screen>
</sect2>
<sect2>
<title>Usare ntpd con una Connessione Temporanea
ad Internet</title>
<para>Il programma &man.ntpd.8; non necessita di una
connessione permanente ad Internet per funzionnare
correttamente. Comunque, se hai una connessione
temporanea che è configurata per effettuare
una chiamata su richiesta, è una buona idea
evitare che il traffico NTP causi la chiamata
o mantenga la connessione attiva. Se stai usando
PPP utente, puoi usare le direttive
<literal>filter</literal> in
<filename>/etc/ppp/ppp.conf</filename>.
Per esempio:</para>
<programlisting> set filter dial 0 deny udp src eq 123
# Prevent NTP traffic from initiating dial out
set filter dial 1 permit 0 0
set filter alive 0 deny udp src eq 123
# Prevent incoming NTP traffic from keeping the connection open
set filter alive 1 deny udp dst eq 123
# Prevent outgoing NTP traffic from keeping the connection open
set filter alive 2 permit 0/0 0/0</programlisting>
<para>Pre maggiori dettagli consulta la sezione
<literal>PACKET FILTERING</literal> in &man.ppp.8;
e gli esempi in
<filename>/usr/share/examples/ppp/</filename>.</para>
<note>
<para>Alcuni provider di accesso ad Internet bloccano
le porte dal numero basso, impedendo ad NTP di
funzionare dato che le repliche non raggiungono mai
la tua macchina.</para>
</note>
</sect2>
<sect2>
<title>Informazioni Ulteriori</title>
<para>La documentazione per il server NTP
può essere trovata in formato HTML in
<filename>/usr/share/doc/ntp/</filename>.</para>
</sect2>
</sect1>
</chapter>