Capitolo 27. Server di rete

27.1. Sinossi

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.

Dopo aver letto questo capitolo, sarai in grado di:

  • Gestire il demone inetd.

  • Installare un file system di rete.

  • Installare un server NIS per condividere account utenti.

  • Installare impostazioni automatiche di rete usando DHCP.

  • Installare un server di risoluzione dei nomi.

  • Installare il server HTTP Apache.

  • Installare un File Transfer Protocol (FTP) Server.

  • Installare un file server e server di stampa per client Windows® usando Samba.

  • Sincronizzare la data e l’ora ed installare un time server, col protocollo NTP.

Prima di leggere questo capitolo, dovresti:

27.2. Il "Super-Server"inetd

27.2.1. Uno sguardo d’insieme

inetd(8) viene talvolta definito l'"Internet Super-Server" perchè gestisce le connessioni verso molti servizi. Quando una connessione viene ricevuta da inetd, 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 inetd 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.

Principalmente, inetd è usato per lanciare altri demoni, ma molti protocolli triviali sono gestiti direttamente, come ad esempio i protocolli chargen, auth, e daytime.

Questa sezione coprirà le basi della configurazione di inetd attraverso le opzioni da linea di comando ed il suo file di configurazione, /etc/inetd.conf.

27.2.2. Impostazioni

inetd viene inizializzato attraverso il sistema rc(8). L’opzione inetd_enable è impostata a NO di default, ma può essere attivata da sysinstall durante l’installazione, a seconda della configurazione scelta dall’utente. Inserendo:

inetd_enable="YES"

o

inetd_enable="NO"

in /etc/rc.conf si abiliterà o meno la partenza di inetd al boot. Il comando:

# /etc/rc.d/inetd rcvar

può essere utilizzato per mostrare le impostazioni attive al momento.

Inoltre, diverse opzioni di linea di comando possono essere passate a inetd attraverso l’opzione inetd_flags.

27.2.3. Opzioni su linea di comando

Come molti server di rete, inetd ha un numero di opzioni che possono essergli passate per modificare il suo comportamento. La lista di tutte le opzioni è:

inetd synopsis:

inetd [-d] [-l] [-w] [-W] [-c maximum] [-C rate] [-a address | hostname] [-p filename] [-R rate] [configuration file]

Si possono passare opzioni ad inetd usando l’opzione inetd_flags in /etc/rc.conf. Di default, inetd_flags è impostato a -wW -C 60, il che attiva il TCP wrapping per i servizi di inetd, ed impedisce ad ogni singolo indirizzo IP di richiedere qualsiasi servizio piùdi 60 volte al minuto.

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 inetd(8) può essere trovata nel manuale di inetd(8).

-c maximum

Specifica il numero massimo di invocazioni simultanee per ogni servizio; il default è illimitato. Può essere sovrascritto per ogni servizio dal parametro max-child.

-C rate

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 max-connections-per-ip-per-minute.

-R rate

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.

-s maximum

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 max-child-per-ip.

27.2.4. inetd.conf

La configurazione di inetd è fatta attraverso il file /etc/inetd.conf.

Quando viene apportata una modifica a /etc/inetd.conf, si può forzare inetd a rileggere il suo file di configurazione eseguendo il comando:

Esempio 1. Ricaricare il file di configurazione di inetd
# /etc/rc.d/inetd reload

Ogni linea del file di configurazione specifica un singolo demone. I commenti nel file sono preceduti da un "#". Il formato di ogni riga del file /etc/inetd.conf è il seguente:

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

Un esempio di linea per il demone ftpd(8) usando l’IPv4:

ftp     stream  tcp     nowait  root /usr/libexec/ftpd       ftpd -l
nome-del-servizio

È il nome del servizio per il demone. Deve corrispondere ad un servizio elencato in /etc/services. Questo determina su quale porta inetd deve restare in ascolto. Se viene creato un nuovo servizio, deve essere messo prima in /etc/services.

tipo-di-socket

Una a scelta fra stream, dgram, raw, o seqpacket. stream deve essere usata per demoni basati sulla connessione, tipo TCP, mentre dgram è usato per demoni che usano il protocollo di trasporto UDP.

protocollo

Uno dei seguenti:

ProtocolloSpiegazione

tcp, tcp4

TCP IPv4

udp, udp4

UDP IPv4

tcp6

TCP IPv6

udp6

UDP IPv6

tcp46

Entrambi TCP IPv4 e v6

udp46

Entrambi UDP IPv4 e v6

{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]

wait|nowait indica se il demone invocato da inetd è in grado di gestire la sua socket o meno. Il tipo di socket dgram deve usare l’opzione wait, mentre i demoni con socket stream, che sono in genere multi-thread, devono usare nowait. wait in genere fornisce socket multiple ad un singolo demone, mentre nowait lancia un demone figlio per ogni nuova socket.

Il massimo numero di demoni figli che inetd può lanciare si imposta attraverso l’opzione max-child. Se è richiesto un limite di dieci istanze per un particolare demone, un /10 dovrebbe essere inserito dopo l’opzione nowait. Specificando /0 si lascia un numero illimitato di figli.

Oltre all’opzione max-child, possono essere attivate due altre opzioni che limitano il massimo numero di connessioni da un singolo ip verso un particolare demone. max-connections-per-ip-per-minute 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. max-child-per-ip 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.

In questo campo, wait o nowait sono obbligatorie. max-child e max-connections-per-ip-per-minute e max-child-per-ip sono opzionali.

Un demone tipo-stream multi-thread senza i limiti max-child o max-connections-per-ip-per-minute dovrebbe essere semplicemente: nowait.

Lo stesso demone con un limite massimo di dieci demoni dovrebbe avere: nowait/10.

In aggiunta, la stessa impostazione con un limite di venti connessioni per IP al minuto ed un limite massimo di dieci demoni figli avrebbe: nowait/10/20.

Queste opzioni sono tutte utilizzate di default nelle impostazioni del demone fingerd(8) come si vede di seguito:

finger stream  tcp     nowait/3/10 nobody /usr/libexec/fingerd fingerd -s

Alla fine, un esempio di questo campo con 100 figli in tutto, con un massimo di 5 per singolo indirizzo IP sarebbe: nowait/100/0/5.

user

Questo è lo username sotto il quale un particolare demone dovrebbe girare. Di frequente, i demoni girano come utente root. Per motivi di sicurezza, è normale trovare alcuni server che girano con l’utente daemon, o il meno privilegiato utente nobody.

server-program

Il percorso assoluto del demone che deve essere eseguito quando è ricevuta una connessione . Se il demone è un servizio offerto da inetd internamente, bisogna usare internal.

server-program-arguments

Questa opzione funziona in congiunzione con server-program specificando gli argomenti, cominciando con argv[0], passati al demone al momento dell’invocazione. Se mydaemon -d è la linea di comando, mydaemon -d sarà il valore dell’opzione server-program-arguments. Ancora, se un demone è un servizio interno, usa internal.

27.2.5. Sicurezza

A seconda delle scelte fatte all’installazione, molti servizi di inetd potrebbero essere attivi di default. Se non c’è necessità apparente per un particolare demone, considera di disabilitarlo. Usa un "#" a capo della riga del demone in questione in /etc/inetd.conf, e quindi ricarica la configurazione di inetd. Alcuni demoni, come fingerd, potrebbero non essere assolutamente desiderati, poichè forniscono all’attaccante informazioni che gli potrebbero risultare utili.

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 max-connections-per-ip-per-minute e max-child o max-child-per-ip su certi demoni se scopri di avere troppe connessioni.

Di default, il TCP wrapping è attivo. Consulta la pagina del manuale di hosts_access(5) per impostare delle restrizioni TCP su certi demoni invocati da inetd.

27.2.6. Miscellanei

daytime, time, echo, discard, chargen, e auth sono tutti servizi interni di inetd.

Il servizio auth fornisce servizi di rete di identificazione ed è configurabile fino ad un certo punto, mentre gli altri possono solo essere accesi o spenti.

Consulta la paigna di manuale di inetd(8) per dettagli più approfonditi.

27.3. Network File System (NFS)

Fra i molti differenti file system che FreeBSD supporta c’è il Network File System, conosciuto anche come NFS. NFS permette ad un sistema di condividere directory e file con altri sistemi in rete. Usando NFS, utenti e programmi possono accedere a file su sistemi remoti quasi come se fossero files locali.

Alcuni dei più notevoli benefici che NFS ci fornisce sono:

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

  • Non c’è bisogno per gli utenti di avere home directory separate su ogni macchina in rete. Le home directory possono essere poste sul server NFS e rese disponibili attraverso la rete.

  • Device di storage come floppy disk, drive CDROM, e drive Zip® possono essere usati da altre macchine sulla rete. Questo può ridurre il numero di device di storage rimuovibili sulla rete.

27.3.1. Come Funziona NFS

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

Il server deve avere attivi i seguenti demoni:

DemoneDescrizione

nfsd

Il demone NFS che serve richieste da client NFS.

mountd

Il demone di mount NFS che serve le richieste che nfsd(8) gli passa.

rpcbind

Questo demone permette ai client NFS di scoprire quali porte il server NFS sta usando.

Il client può anche eseguire un demone, noto come nfsiod. Il demone nfsiod serve le richieste dal server NFS. E' opzionale, aiuta a migliorare le prestazioni ma non è indispensabile per operazioni corrette. Consultare la pagina di manuale di nfsiod(8) per più informazioni.

27.3.2. Configurare NFS

La configurazione di NFS è un processo relativamente semplice. I processi che devono essere attivi possono essere tutti avviati al boot della macchina con poche modifiche al tuo file /etc/rc.conf.

Sul server NFS assicurati che le seguenti opzioni sono configurati nel file /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"

mountd viene eseguito automaticamente in caso il server NFS sia abilitato.

Sul client, accertati che questa riga sia attiva nel file /etc/rc.conf:

nfs_client_enable="YES"

Il file /etc/exports specifica quali file system NFS dovrebbe esportare (talora chiamate anche "share"). Ogni linea di /etc/exports 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 exports(5).

Queste sono alcune linee di esempio del file /etc/exports:

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 /cdrom 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 /etc/hosts. L’opzione -ro 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.

/cdrom -ro host1 host2 host3

La seguente linea esporta la directory /home a tre host identificati da indirizzo IP. E' una impostazione utile in caso tu abbia una rete privata senza un DNS server configurato. Opzionalmente il file /etc/hosts può essere configurato per hostname interni. Per favore rileggi hosts(5) per più informazioni. Il flag -alldirs 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.

/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4

La linea seguente esporta /a cosicchè due client da diversi domini possono accedere al file system. L’opzione -maproot=root permette all’utente root sul sistema remoto di scrivere dati sul file system esportato come utente root. Se il flag -maproot=root non è specificato, anche se l’utente ha accesso come root sul file system remoto, non sarà in grado di modificare files sul file system esportato.

/a  -maproot=root  host.example.com box.example.org

Affinchè un client abbia accesso ad un file system, questo deve avere permessi adeguati. Assicurati che il client sia elencato nel file /etc/exports.

In /etc/exports, 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 /usr sia un singolo file system. Il seguente /etc/exports sarebbe invalido:

# Invalid when /usr is one file system
/usr/src   client
/usr/ports client

Un file system, /usr, ha due linee che specificano exports verso lo stesso host, client. Il formato corretto per questa situazione è:

/usr/src /usr/ports  client

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.

Il seguente è un esempio di valida lista di esportazione, dove /usr e /exports /usr and /exports sono file system locali:

# 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

Il demone mountd deve essere forzato a rileggere il file /etc/exports ogni volta che lo modifichi, cosicchè i cambiamenti abbiano effetto. Questo può essere ottenuto inviando un segnale HUP al processo mountd:

# kill -HUP `cat /var/run/mountd.pid`

o invocando lo script mountd rc(8) con i parametri appropriati:

# /etc/rc.d/mountd onereload

Sei invitato a far riferimento a Configurazione Iniziale per maggiori informazioni sugli script rc.

Alternativamente, un reboot farà sì che FreeBSD imposti tutto correttamente. Non è necessario tuttavia effettuare un reboot. L’esecuzione del seguente comando da utente root dovrebbe avviare tutto.

Sul server NFS:

# rpcbind
# nfsd -u -t -n 4
# mountd -r

Sul client NFS:

# nfsiod -n 4

Ora dovrebbe essere tutto pronto per montare un file system remoto. In questi esempi il nome del server sarà server e quello del client sarà client. Se vuoi solo temporaneamente montare un file system remoto o anche testare la configurazione, basta che esegui un comando come questo come utente root sul client:

# mount server:/home
/mnt

Questo monterà la directory /home del server sopra /mnt sul client. Se tutto è impostato correttamente dovresti essere in grado di entrare nella directory /mnt sul client e vedere tutti i file che sono sul server.

Se vuoi montare automaticamente un file system remoto ogni volta che il computer fa boot, aggiungi il file system al file /etc/fstab. Questo è un esempio:

server:/home /mnt nfs rw 0 0

La pagina di manuale di fstab(5) elenca tutte le possibili opzioni.

27.3.3. Locking

Alcune applicazioni (es. mutt) richiedono il lock dei file per operare in modo corretto. In caso di NFS, può essere utilizzato rpc.lockd per il lock dei file. Per abilitarlo, aggiungi la seguente riga al file /etc/rc.conf sia sul client che sul server (assumendo che il client e server NFS siano già configurati):

rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Avvia l’applicazione con:

# /etc/rc.d/nfslocking start

Se non è richiesto un lock reale tra il server e il client NFS, è possibile dire al client NFS di fare un lock locale passando l’opzione -L a mount_nfs(8). Ulteriori dettagli possono essere trovati nella pagina man di mount_nfs(8).

27.3.4. Usi Pratici

NFS ha molti usi pratici. Alcuni dei più usati sono elencati di seguito:

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

  • Su grandi reti, potrebbe essere più conveniente configurare un server NFS 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.

  • Molte macchine potrebbero avere una directory comune /usr/ports/distfiles. In questo modo, quando hai bisogno di installare un port su molte macchine, puoi velocemente accedere al sorgente senza scaricarlo su ogni macchina.

27.3.5. Mount automatici con amd

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 amd. L’uso di amd fornisce una semplice alternativa a mount permanenti, dato che i mount permanenti sono di solito elencati in /etc/fstab.

amd opera connettendosi ad un server NFS sulle directory /host e /net. Quando si accede ad un file all’interno di una di queste directory, amd fa una ricerca del mount remoto corrispondente e lo monta automaticamente. /net è usato per montare un file system esportato da un indirizzo IP, mentre /host è usato per montare un export da un hostname remoto.

Un accesso ad un file in /host/foobar/usr dovrebbe comunicare a amd di cercare di montare l’export /usr sull’host foobar.

Esempio 2. Montare un export con amd

Puoi osservare i mount disponibili di un host remoto con il comando showmount. Ad esempio, per vedere i mounts di un host chiamato foobar, puoi usare:

% showmount -e foobar
Exports list on foobar:
/usr                               10.10.10.0
/a                                 10.10.10.0
% cd /host/foobar/usr

Come si vede nell’esempio, il comando showmount mostra /usr come un export. Quando si cambia directory in /host/foobar/usr, amd cerca di risolvere foobar e automaticamente monta l’export desiderato.

amd può essere avviato dagli scripts di startup inserendo le seguenti linee in /etc/rc.conf:

amd_enable="YES"

Inoltre, altri flags personalizzati possono essere ad amd con le opzioni amd_flags. Di default, amd_flags è impostato a:

amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map
/net /etc/amd.map"

Il file /etc/amd.map definisce le opzioni di default con le quali gli export sono montati. Il file /etc/amd.conf definisce alcune delle più avanzate caratteristiche di amd.

Consulta le pagine di manuale di amd(8) e amd.conf(8) per maggiori informazioni.

27.3.6. Problemi nell’integrazione con altri sistemi

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.

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.

Anche se la soluzione "corretta" è usare un adapter Ethernet dalle migliori prestazioni e capacità , c’è un semplice workaround che permetterà operazioni soddisfacenti. Se il sistem FreeBSD è il server, includi le opzioni -w=1024 al mount dal client. Se il sistema FreeBSD è il client, allora monta il file system NFS con l’opzione -r=1024. Queste opzioni possono essere specificate usando il quarto campo della linea di fstab sul client per mount automatici, o usa il parametro -o del comando mount(8) per mount manuali.

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, accertatevi che i vostri router indirizzino correttamente l’informazione necessaria su UDP, o non andrai da nessuna parte, indipendentemente da cosa tu stia cercando di fare.

Nei seguenti esempi, fastws è il nome host (interfaccia) di una workstation ad alte prestazioni, e freebox è il nome host (interfaccia) di un sistema FreeBSD con un adapter Ethernet a basse prestazioni. Inoltre, /sharedfs sarà il file system esportato (vedi exports(5)), e /project sarà il mount point sul client per il file system montato. In tutti i casi, nota che le opzioni hard o soft e bg possono essere utili nella tua applicazione.

Esempi dal sistema FreeBSD (freebox) come client da /etc/fstab su freebox:

fastws:/sharedfs /project nfs rw,-r=1024 0 0

Come comando manuale di mount da freebox:

# mount -t nfs -o -r=1024 fastws:/sharedfs /project

Esempi dal sistema FreeBSD come server in /etc/fstab su fastws:

freebox:/sharedfs /project nfs rw,-w=1024 0 0

Come comando di mount manuale su fastws:

# mount -t nfs -o -w=1024 freebox:/sharedfs /project

Praticamente ogni Ethernet adapter a 16-bit permetterà operazioni senza le succitate restrizioni sulla dimensione di lettura e scrittura.

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 "block" 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 "block" 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 riconosciuto 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.

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.

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 "unità " NFS. Quando una sovrascrittura avviene, le unità affette saranno ritrasmesse, e c’è una buona probabilità che saranno ricevute, assemblate, e riconosciute.

27.4. Network Information System (NIS/YP)

27.4.1. Cos’è?

NIS, 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 NIS.

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

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.

E' simile al sistema di domini di Windows NT®; anche se le implementazioni interne dei due sistemi sono del tutto diverse, le funzionalità base possono essere paragonate.

27.4.2. Termini/Processi che Dovresti Conoscere

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:

TermineDescrizione

Nome dominio NIS

Un server NIS master e tutti i suoi client (inclusi i suoi server slave) hanno un nome dominio NIS. Analogamente al nome dominio di Windows NT®, il nome dominio NIS non ha nulla a che fare con il DNS.

rpcbind

Deve essere in esecuzione al fine di abilitare RPC (Remote Procedure Call, un protocollo di rete usato da NIS). Se rpcbind non è attivo, sarà impossibile portare in esecuzione un server NIS o fungere da client NIS

ypbind

Esegue il "bind" di un client NIS al suo server. Prenderà il nome dominio NIS dal sistema, e, usando RPC, si connetterà al server. ypbind è il fulcro di una comunicazione client-server in ambiente NIS; se ypbind muore su un client, questo non sarà in grado di accedere il server NIS.

ypserv

Dovrebbe essere in esecuzione solo sui server NIS;è il processo NIS vero e proprio. Se 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 ypbind sul client).

rpc.yppasswdd

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

27.4.3. Come funziona?

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.

Le informazioni in molti file possono essere condivise in questo modo. I file master.passwd ,group e hosts 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.

27.4.3.1. Tipi di macchine

  • Un server master NIS. Questo server, analogamente a primary domain controller Windows NT® , mantiene i file usati da tutti i client NIS. Il file passwd, il file group, e vari altri file usati da client NIS vivono sul server master.

    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.

  • NIS slave server. Analogamente a backup domain controller Windows NT®, 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.

  • NIS client. I client NIS, come la maggior parte delle workstation Windows NT® , si autenticano nei confronti del NIS server (o del domain controller Windows NT® nel caso di workstation Windows NT®) per effettuare il login.

27.4.4. Usare NIS/YP

Questa sezione riguarderà l’installazione di un ambiente di esempio NIS.

27.4.4.1. Il Piano

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 /etc/passwd e /etc/master.passwd. Questi file sono tenuti sincronizzati fra di loro attraverso intervento manuale; al momento, quando aggiungi un utente al laboratorio, devi eseguire adduser 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.

Così la configurazione del laboratorio adesso sembra questa:

Nome della macchinaIndirizzo IPRuolo della macchina

ellington

10.0.0.2

NIS master

coltrane

10.0.0.3

NIS slave

basie

10.0.0.4

Workstation della facoltà

bird

10.0.0.5

Macchina client

cli[1-11]

10.0.0.[6-17]

Altre macchine client

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.

27.4.4.1.1. Scegliere un nome dominio NIS

Questo può non essere il "nome dominio" a cui sei abituato. Per la precisione viene chiamato "nome dominio NIS". 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.

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 "acme-art". Per questo esempio, si presume tu abbia scelto il nome test-domain.

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 devi usare il nome dominio Internet come il tuo nome dominio NIS.

27.4.4.1.2. Requisiti fisici dei server

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, tutti i tuoi client NIS ne saranno affetti in modo negativo.

27.4.4.2. Server NIS

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 /var/yp/[nome-dominio] dove [nome-dominio] è 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.

I server NIS master e slave gestiscono tutte le richieste NIS col demone ypserv. ypserv è 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.

27.4.4.2.1. Installare un server master NIS

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 /etc/rc.conf, e FreeBSD farà il resto.

nisdomainname="test-domain"
  1. Questa linea imposterà il nome domino NIS a test-domain al momento della configurazione di rete (ad esempio dopo il reboot).

    nis_server_enable="YES"
  2. Questa linea dirà a FreeBSD di avviare i processi NIS server la prossima volta che la rete è riavviata.

    nis_yppasswdd_enable="YES"
  3. Questo avvierà il demone rpc.yppasswd che, come accennato prima, permetterà agli utenti di cambiare la loro password NIS dalle macchine client.

A seconda delle tue impostazioni NIS, potresti aver bisogno di aggiungere altre linee. Leggi la sezione sui NIS server che sono anche NIS client , di seguito, per dettagli.

Ora, tutto quello che devi fare è eseguire il comando /etc/netstart come super-utente. Questo imposterà il sistema, usando i valori che hai specificato in /etc/rc.conf.

27.4.4.2.2. Inizializzare le mappe NIS

Le mappe NIS sono file di database, che sono conservati nella directory /var/yp. Sono generati da file di configurazione nella directory /etc del NIS master, con una eccezione: il file /etc/master.passwd. C’è un buon motivo per questo, infatti normalmente non vuoi che siano propagate le password a root e ad altri account amministrativi a tutti gli altri server nel dominio NIS. Così prima di inizializzare le mappe NIS, dovresti:

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

Dovresti rimuovere tutte le linee che riguardano account di sistema (bin, tty, kmem, games, etc.), così come altri account che non vuoi siano propagate ai client NIS (per esempio root ed ogni altro account con UID 0 (super-utente)).

Accertati che il file /var/yp/master.passwd non sia nè leggibile dal gruppo nè dal resto del mondo (modo 600)! Usa il comando chmod, se appropriato.

Quando hai finito, è il momento di inizializzare le mappe NIS! FreeBSD include uno script chiamato ypinit 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 ypsetup. Poichè stiamo generando mappe per un NIS master, passeremo l’opzione -m al comando ypinit. Per generare le mappe NIS, supponendo che tu abbia già eseguito i passi di cui sopra, esegui:

ellington# ypinit -m test-domain
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]
n
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:  coltrane
next host to add:  ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] y

[..output from map generation..]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.

ypinit dovrebbe aver creato /var/yp/Makefile da /var/yp/Makefile.dist. Quando creato, questo file assume che tu stia operando su un ambiente NIS a server singolo con solo macchine FreeBSD. Dal momento che test-domain ha anche un server slave, devi editare /var/yp/Makefile:

ellington# vi /var/yp/Makefile

Dovresti commentare la linea che dice

NOPUSH = "True"

(se non è già commentata).

27.4.4.2.3. Impostare un server slave NIS

Impostare un server NIS slave è anche più semplice che impostare il master. Loggati al server slave ed edita il file /etc/rc.conf esattamente come hai fatto col server master. L’unica differenza è che ora dobbiamo usare l’opzione -s quando eseguiamo ypinit. L’opzione -s richiede che il nome del server NIS sia passato, così la nostra linea di comando assomiglia alla seguente:

coltrane# ypinit -s ellington
test-domain

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]
n

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.

Ora dovresti avere una directory chiamata /var/yp/test-domain. Copie delle mappe NIS del master server dovrebbero risiedere in questa directory. Dovresti accertarti che siano aggiornate. La seguente linea di /etc/crontab sul tuo server slave dovrebbe far ciò:

20      *       *       *       *       root /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

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.

Adesso, esegui il comando /etc/netstart anche sullo slave, per avviare il server NIS.

27.4.4.3. Client NIS

Un client NIS stabilisce quello che è chiamato un binding ad un particolare NIS server usando il demone ypbind. ypbind controlla il dominio di default del sistema (impostato dal comando domainname), ed inizia a fare broadcast di richieste RPC sulla rete locale. Queste richieste specificano il nome del dominio per il quale ypbind sta cercando di stabilire un binding. Se un server è stato configurato a servire il dominio richiesto, risponderà a ypbind, che registrerà l’indirizzo del server. Se ci sono molti server disponibili (ad esempio un master e molti slave), ypbind userà l’indirizzo del primo che risponde. Da quel momento in poi, il sistema client dirigerà tutte le sue richieste NIS a quel server. ypbind occasionalmente farà un "ping" del server per accertarsi che sia su ed attivo. Se non riceve una risposta di uno dei suoi ping in un tempo accettabile, ypbind segnerà il dominio come non connesso e inizierà di nuovo a fare broadcasting nella speranza di localizzare un altro server.

27.4.4.3.1. Impostare un client NIS

Impostare una macchina FreeBSD perchè sia un client NIS è abbastanza semplice.

  1. Edita il file /etc/rc.conf e aggiungi le seguenti linee per impostare il nome dominio NIS ed avviare ypbind all’avvio della rete:

    nisdomainname="test-domain"
    nis_client_enable="YES"
  2. Per importare tutte le possibili linee di password dal server NIS, rimuovi tutti gli account utente dal tuo /etc/master.passwd ed usa vipw per aggiungere la seguente linea alla fine del file:

    +:::::::::

    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 sezione sui netgroups di seguito per maggiori informazioni. Per letture più dettagliate vedere il libro della O’Reilly Managing NFS and NIS.

    Dovresti tenere almeno un account locale (non importato via NIS) nel tuo file /etc/master.passwd e questo account dovrebbe essere anche un membro del gruppo wheel. Se c’è qualche problema con NIS, questo account può essere usato per loggarsi da remoto, diventare root e riparare le cose.

  3. Per impostare tutte le possibili linee dei gruppi dal server NIS, aggiungi questa linea al tuo file /etc/group:

    +:*::

Dopo aver completato questi passi, dovresti essere in grado di eseguire ypcat passwd e vedere la mappa delle password del NIS server.

27.4.5. Sicurezza di NIS

In generale, ogni utente remoto può eseguire una RPC a 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, ypserv(8) supporta una caratteristica chiamata "securenets" che può essere usata per restringere l’accesso ad un dato insieme di host. All’avvio ypserv(8) cercherà di caricare le informazioni delle securenets da un file chiamato /var/yp/securenets.

Questo percorso varia a secondo del percorso specificato con l’opzione -p. 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 "#" sono considerati commenti. Un esempio di file securenets può assomigliare al seguente:

# 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

Se 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 /var/yp/securenets non esiste, ypserv permetterà connessioni da ogni host.

Il programma ypserv ha anche supporto per il pacchetto di Wietse Venema TCP Wrapper. Questo permette all’amministratore di usare i file di configurazione di TCP Wrapper per controlli sull’accesso al posto di /var/yp/securenets.

Pur essendo entrambi questi meccanismi di accesso di controllo abbastanza sicuri, questi, come il test di porta privilegiata, sono vulnerabili agli attacchi "IP spoofing". Tutto il traffico relativo a NIS dovrebbe essere bloccato al firewall.

I server che usano /var/yp/securenets 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 /var/yp/securenets.

Usando /var/yp/securenets 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.

L’uso del pacchetto TCP Wrapper 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.

27.4.6. Impedire ad Alcuni Utenti di Loggarsi

Nel nostro laboratorio c’è una macchina basie che si suppone sia una workstation solo della facoltà . Non vogliamo togliere questa macchina dal dominio NIS, tuttavia il file passwd sul server NIS master contiene account che sono sia della facoltà sia degli studenti. Cosa possiamo fare?

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 -username alla fine del file /etc/master.passwd sulla macchina client, dove username è lo username dell’utente di cui vuoi impedire l’accesso. E' meglio fare questo con vipw dato che vipw farà un controllo di correttezza dei tuoi cambiamenti a /etc/master.passwd, e ricostruirà automaticamente il database delle password quando hai finito di editarlo. Ad esempio, se vogliamo impedire l’accesso all’utente bill verso l’host basie faremmo:

basie# vipw
[aggiungi -bill alla fine del file, poi esci]
vipw: rebuilding the database...
vipw: done

basie# cat /etc/master.passwd

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/shared/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#

27.4.7. Usare i Netgroups

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, certamente 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 centralizzata.

La soluzione degli sviluppatori NIS a questo problema è chiamata netgroups. 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.

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.

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.

User Name(s)Description

alpha, beta

Impiegato normale del dipartimento IT

charlie, delta

Il nuovo apprendista del dipartimento IT

echo, foxtrott, golf, …​

Impiegato ordinario

able, baker, …​

Gli interni correnti

Machine Name(s)Description

war, death, famine, pollution

Il tuoi server più importanti. Solo gli impiegati IT hanno il permesso di loggarsi in queste macchine.

pride, greed, envy, wrath, lust, sloth

Server meno importanti. Tutti i membri del dipartimento IT hanno il permesso di loggarsi a queste macchine.

one, two, three, four, …​

Workstation normali. Solo veri impiegati hanno permesso di accedere a queste macchine.

trashcan

Una macchina molto vecchia senza alcun dato critico. Anche gli interni hanno permesso di usare questa macchina.

Se provi ad implementare queste restrizioni bloccando separatamente ogni utente, dovresti aggiungere una linea -user ad ogni passwd 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 certamente ti dimenticherai alla fine di aggiungere le linee per i nuovi utenti durante le operazioni giornaliere. Dopo tutto, Murphy era un ottimista.

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ù "per ogni combinazione di utenti e macchine fai …​"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.

Il primo passo è l’inizializzazione della mappa NIS netgroup. 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

ellington# vi /var/yp/netgroup

e poi inizia ad aggiungere contenuti. Per i nostri esempi abbiamo bisogno di almeno quattro netgroup: impiegati IT, apprendisti IT, impiegati normali ed interni.

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)

IT_EMP, IT_APP etc. sono i nomi dei netgroup. Ogni gruppo fra parentesi tonde aggiunge uno o più account utente. I tre campi dentro il gruppo sono:

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

  2. Il nome dell’account che appartiene a questo netgroup.

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

Ognuno di questi campi può contenere wildcards. Leggi netgroup(5) per dettagli.

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.

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 linee. Puoi superare questo limite creando molti sotto-netgroup con 15 o meno utenti ed un vero netgroup che consiste dei sotto-netgroup:

BIGGRP1  (,joe1,domain)  (,joe2,domain)
(,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

Puoi ripetere questo processo se hai bisogno di più di 225 utenti all’interno di un singolo netgroup.

Attivare e distribuire la tua nuova mappa NIS è facile:

ellington# cd /var/yp
ellington# make

Questo genererà le tre mappe NIS netgroup, netgroup.byhost e netgroup.byuser. Usa ypcat(1) per controllare che le tue nuove mappe NIS siano disponibili:

ellington% ypcat -k
netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k
netgroup.byuser

L’output del tuo primo comando dovrebbe assomigliare a /var/yp/netgroup. 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.

L’installazione del client è abbastanza semplice. Per configurare il server war, devi solo eseguire vipw(8) e sostituire la linea

+:::::::::

con

+@IT_EMP:::::::::

Ora, solo i dati per l’utente definito nel netgroup IT_EMP sono importati nel database delle password di war e solo questi utenti hanno permesso di accesso.

Sfortunatamente, questa limitazione si applica anche alla funzione della shell ~ ed a tutte le routine che convertono fra nomi utenti e user ID numerici. In altre parole,cd ~user ` non funzionerà , `ls -l mostrerà gli ID numerici invece dello username e find . -user joe -print darà l’errore No such user. Per riparare questo, dovrai importare tutte le linee dell’utente senza permettere a loro di loggarsi sui tuoi server.

Questo può essere ottenuto aggiungendo un’altra linea a /etc/master.passwd. Questo dovrebbe contenere:

+:::::::::/sbin/nologin, dal significato "Importa tutte le entry ma imposta la shell di login a /sbin/nologin nelle linee importate". Puoi sostituire ogni campo nella linea passwd piazzando un valore di default nel tuo /etc/master.passwd.

Accertati che la linea +:::::::::/sbin/nologin sia piazzata dopo +@IT_EMP:::::::::. Altrimenti tutti gli account utente importati da NIS avranno /sbin/nologin come loro shell di login.

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 +::::::::: nella tua versione locale di /etc/master.passwd con qualcosa del tipo:

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

Le linee corrispondenti per le workstation normali potrebbero essere:

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

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 IT_INTERN, aggiungi i nuovi interni IT a questo nuovo netgroup IT_INTERN, e inizia a cambiare la configurazione su ogni nuova macchina…​ Come il vecchio adagio dice:"Errori nella pianificazione centralizzata porta a caos globale".

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 BIGSRV per definire le restrizioni di login per i server importanti, un altro netgroup chiamato SMALLSRV per i server meno importanti ed un terzo netgroup chiamato USERBOX 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:

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

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.

Definizioni di netgroup specifiche per ogni macchina sono l’altra possibilità per gestire il cambiamento di policy delineato sopra. In questo scenario il /etc/master.passwd di ogni macchina deve contenere due linee che iniziano con "+". 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 /sbin/nologin come shell. E' buona norma usare la versione "MAIUSCOLA" del nome macchina come nome del netgroup. In altre parole, le linee dovrebbero assomigliare a questa:

+@BOXNAME:::::::::
+:::::::::/sbin/nologin

Una volta che hai completato questo task per tutte le macchine, non dovrai mai più modificare la versione locale di /etc/master.passwd. 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:

# 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]

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.

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.

27.4.8. Cose Importanti da Ricordare

Ci sono ancora un paio di cose che dovrai cambiare ora che operi in ambiente NIS.

  • Ogni volta che devi aggiungere un utente al laboratorio devi aggiungerlo solo al server master NIS e devi ricordarti di ricostruire le mappe NIS. 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 jsmith al laboratorio, faremmo:

    # pw useradd jsmith
    # cd /var/yp
    # make test-domain

    Puoi anche eseguire adduser jsmith invece di pw useradd jsmith.

  • Tieni gli account amministrativi fuori dalle mappe NIS. 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.

  • Tieni al sicuro il NIS master e slave, e minimizza il tempo in cui sono giù. Se qualcuno hackera o semplicemente spegne queste macchine riesce a privare molte persone della possibilità di loggarsi al laboratorio.

    Questa è la principale debolezza di ogni sistema centralizzato di amministrazione. Se non proteggi il tuo server NIS, avrai un mucchio di utenti arrabbiati!

27.4.9. Compatibilità con NIS v1

ypserv 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 ypbind 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 ypserv 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.

27.4.10. Server NIS che Sono Anche Client

Bisogna prestare molta attenzione quando si esegue ypserv 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.

Puoi forzare un host a fare il binding ad un server in particolare usando ypbind con l’opzione -S. Se non vuoi fare questa azione a mano ogni volta che fai il reboot del tuo server NIS, puoi aggiungere queste linee al tuo /etc/rc.conf:

nis_client_enable="YES"  # run client stuff as well
nis_client_flags="-S NIS
domain,server"

Consulta ypbind(8) per ulteriori informazioni.

27.4.11. Formato delle Password

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.

Per controllare quale formato il tuo server e client usano, dai un’occhiata a /etc/login.conf. Se l’host è configurato per usare password criptate DES, la classe default conterrà una linea simile a questa:

default:\
:passwd_format=des:\
:copyright=/etc/COPYRIGHT:\
[Further entries elided]

Altri valori possibili per l’opzione passwd_format includono blf e md5 (per password criptate con Blowfish e con MD5, rispettivamente).

Se hai fatto modifiche a /etc/login.conf, dovrai anche ricostruire il database delle possibilità di login, il che si ottiene eseguendo il seguente comando come root:

# cap_mkdb /etc/login.conf

Il formato delle password che sono già in /etc/master.passwd non sarà aggiornato finchè un utente cambia la sua password per la prima volta dopo che il database delle possibilità di login è ricostruito.

Dopodichè per assicurarti che le password siano criptate con il formato che hai scelto, dovresti anche controllare che crypt_default in /etc/auth.conf 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:

crypt_default  =  des blf md5

Seguendo i passi sopra citati su ognuno dei FreeBSD 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.

27.5. Configurazione Automatica della Rete (DHCP)

27.5.1. Cos’è il DHCP?

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 (dhclient(8)) dell’ISC (Internet Software Consortium). Le ultime versioni usano il dhclient di OpenBSD preso da OpenBSD 3.7. Tutte le informazioni specifiche all’implementazione di dhclient in questa sede sono riferite all’uso dei client DHCP sia di ISC che di OpenBSD. Il server DHCP è quello incluso nella distribuzione ISC.

27.5.2. Cosa Copre Questa Sezione

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, dhclient, è già integrato con FreeBSD, e la parte server è disponibile nel port net/isc-dhcp3-server. Le pagine di manuale dhclient(8), dhcp-options(5), e dhclient.conf(5), oltre ai riferimenti elencati oltre, sono risorse utili.

27.5.3. Come Funziona

Quando dhclient, 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 "rilascio" 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.

I client DHCP possono ottenere molti tipi di informazione dal server. Una lista esauriente può essere trovata in dhcp-options(5).

27.5.4. L’Integrazione con FreeBSD

FreeBSD integra completamente il client DHCP ISC o OpenBSD, dhclient (a seconda della versione di FreeBSD 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. dhclient è stato incluso in tutte le distribuzioni FreeBSD a partire dalla 3.2.

DHCP è supportato da sysinstall. Quando configuri una interfaccia di rete con sysinstall, la seconda domanda che ti pone è: " Vuoi provare a configurare l’interfaccia via DHCP?". Una risposta affermativa eseguirà dhclient, e, se ha successo, riempirà le informazioni di configurazione della rete in automatico.

Ci sono due cose che devi fare per far sì che il tuo sistema usi il DHCP all’avvio:

  • Accertati che il device bpf sia compilato nel tuo kernel. Per fare ciò, aggiungi device bpf al tuo file di configurazione del kernel, e ricompilalo. Per maggiori informazioni su come ricompilare i kernel, vedi Configurazione del Kernel di FreeBSD.

    Il device bpf è già parte del kernel GENERIC 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.

    Quelli di voi che sono particolarmente attenti alla sicurezza, dovrebbero sapere che il device bpf è anche il device che permette agli sniffer di pacchetti di funzionare correttamente (anche se devono sempre essere eseguiti come root). bpfè richiesto per l’uso del DHCP, ma se siete molto attenti alla sicurezza, non dovreste probabilmente aggiungere bpf al vostro kernel in previsione di un uso futuro del DHCP.

  • Edita il tuo /etc/rc.conf per includere la seguente linea:

    ifconfig_fxp0="DHCP"

    Accertati di sostituire fxp0 con il nome dell’interfaccia che intendi configurare dinamicamente, come descritto in .

    Se stai usando una locazione diversa per dhclient, o se desideri passare flags addizionali a dhclient includi anche le linee seguenti (editandole come necessario):

    dhcp_program="/sbin/dhclient"
    dhcp_flags=""

Il server DHCP, dhcpd, è incluso come parte del port net/isc-dhcp3-server nella collezione dei ports. Questo port contiene il server DHCP ISC e la documentazione.

27.5.5. Files

  • /etc/dhclient.conf

    dhclient richiede un file di configurazione, /etc/dhclient.conf. Tipicamente il file contiene solo commenti, essendo i default ragionevolmente corretti. Questo file di configurazione è descritto dalla pagina di manuale dhclient.conf(5).

  • /sbin/dhclient

    dhclient è linkato staticamente e risiede in /sbin. Le pagine di manuale di dhclient(8) danno maggiori informazioni su dhclient.

  • /sbin/dhclient-script

    dhclient-script è lo script di configurazione del client DHCP specifico di FreeBSD. Viene descritto in dhclient-script(8) ma non dovrebbe aver bisogno di nessuna modifica utente per funzionare correttamente.

  • /var/db/dhclient.leases

    Il client DHCP mantiene un database di validi rilasci in questo file, che viene scritto come un log. dhclient.leases(5) ne dàuna descrizione leggermente più estesa.

27.5.6. Ulteriori Letture

Il protocollo DHCP è descritto in maniera estesa in RFC 2131. Informazioni aggiuntive sono presenti a questo URL: http://www.dhcp.org/.

27.5.7. Installare e Configurare un Server DHCP

27.5.7.1. Cosa Copre Questa Sezione

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

Il server non viene fornito come parte di FreeBSD, così dovrai installare il port net/isc-dhcp3-server per fornire questo servizio. Vedi Installazione delle Applicazioni. Port e Package per più informazioni su come usare la Collezione dei Port.

27.5.7.2. Installazione del DHCP Server

Per configurare il tuo sistema FreeBSD come un server DHCP, assicurati che il device bpf(4) sia compilato nel kernel. Per farlo, aggiungi device bpf al file di configurazione del kernel, e ricompilalo. Per maggiori informazioni su come compilare un kernel, vedi Configurazione del Kernel di FreeBSD.

Il device bpf è già parte del kernel GENERIC che viene fornito con FreeBSD, così non hai bisogno di creare un kernel custom per far funzionare il DHCP.

Quelli di voi che sono particolarmente attenti alla sicurezza, dovrebbero notare che bpf è anche il device che permette agli sniffer di pacchetti di funzionare correttamente (anche se tali programmi hanno bisogno di accesso privilegiato). bpf _è _ richiesto per il funzionamento del DHCP, ma se siete molto attenti alla sicurezza, probabilmente non dovreste includere bpf nel vostro kernel semplicemente perchè vi aspettate di usare il DHCP in qualche momento.

La prossima cosa che devi fare è editare il file dhcpd.conf che è stato installato dal port net/isc-dhcp3-server. Di default, questo sarà /usr/local/etc/dhcpd.conf.sample e dovresti copiare questo file in /usr/local/etc/dhcpd.conf prima di procedere con i cambiamenti.

27.5.7.3. Configurare il Server DHCP

dhcpd.conf è composto di dichiarazioni riguardanti sottoreti ed host, e forse lo si spiega meglio con un esempio:

option domain-name "example.com";(1)
option domain-name-servers 192.168.4.100;(2)
option subnet-mask 255.255.255.0;(3)

default-lease-time 3600;(4)
max-lease-time 86400;(5)
ddns-update-style none;(6)

subnet 192.168.4.0 netmask 255.255.255.0 {
  range 192.168.4.129 192.168.4.254;(7)
  option routers 192.168.4.1;(8)
}

host mailhost {
  hardware ethernet 02:03:04:05:06:07;(9)
  fixed-address mailhost.example.com;(10)
}
1Questa opzione specifica il dominio che verrà servito ai client come il dominio di default di ricerca. Si veda resolv.conf(5) per più informazioni.
2Questa opzione specifica una lista di server DNS separata da virgole, che i client dovrebbero usare.
3La netmask che sarà fornita ai client.
4Un 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).
5Questa è 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 max-lease-time secondi.
6Questa opzione specifica se il server DHCP dovrà cercare di modificare il DNS quando un rilascio è accettato o liberato. Nella implementazione ISC questa opzione è richiesta.
7Questo 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.
8Dichiara il default gateway che sarà assegnato ad i client.
9L’indirizzo hardware MAC di un host (cosicchè il server DHCP possa riconoscere un host quando fa una richiesta).
10Specifica 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.

Una volta che hai finito di scrivere il tuo dhcpd.conf, puoi abilitare il server DHCP in /etc/rc.conf, aggiungendo:

dhcpd_enable="YES"
dhcpd_ifaces="dc0"

Sostituisci il nome dell’interfaccia dc0 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.

Quindi, puoi procedere ad avviare il server con il seguente comando:

# /usr/local/etc/rc.d/isc-dhcpd.sh start

Se hai bisogno di fare altri cambiamenti alla configurazione del server in futuro, è importante notare che l’invio di un segnale SIGHUP a dhcpd_non_ fa sì che il file di configurazione sia ricaricato, come avviene con la maggior parte dei demoni. Dovrai inviare un segnale SIGTERM per fermare il processo, e poi riavviarlo usando il comando sopracitato.

27.5.7.4. Files

  • /usr/local/sbin/dhcpd

    dhcpd è linkato staticamente e risiede in /usr/local/sbin. La pagina di manuale di dhcpd(8) installata con il port dà più informazioni su dhcpd.

  • /usr/local/etc/dhcpd.conf

    dhcpd richiede un file di configurazione, /usr/local/etc/dhcpd.conf, 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 dhcpd.conf(5) installata dal port.

  • /var/db/dhcpd.leases

    Il server DHCP mantiene un database dei rilasci che ha effettuato in questo file, che viene scritto come un log. La pagina di manuale dhcpd.leases(5), installata dal port ne dà una descrizione leggermente pi` lunga.

  • /usr/local/sbin/dhcrelay

    dhcrelay è 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 net/isc-dhcp3-relay. La pagina di manuale dhcrelay(8) fornita col port contiene più dettagli.

27.6. Domain Name System (DNS)

27.6.1. Uno sguardo d’insieme

FreeBSD utilizza, di default, una versione di BIND (Berkeley Internet Name Domain), che è la più completa implementazione del protocollo DNS. DNS è il protocollo attraverso il quale nomi sono mappati ad indirizzi IP, e viceversa. Per esempio, una query per www.FreeBSD.org ` riceverà una replica con l’indirizzo IP del web server del The FreeBSD Project, mentre una query per `ftp.FreeBSD.org ritornerà l’indirizzo IP della corrispondente macchina FTP. Allo stesso modo, può avvenire l’opposto. Una query per un indirizzo IP può risolvere il suo nome host. Non è necessario avere in esecuzione un name server per fare DNS lookups su un sistema.

FreeBSD al momento viene distribuito con software DNSBIND9 di default. La nostra installazione fornisce caratteristiche di sicurezza migliorate, un nuovo layout del file system e configurazione chroot(8) automatica.

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.

Al momento corrente, BIND è mantenuto dall’Internet Software Consortium http://www.isc.org/.

27.6.2. Terminologia

Per comprendere questo documento, alcuni termini relativi al DNS devono essere capiti.

TermineDefinizione

Forward DNS

La mappa da hostname ad indirizzi IP.

Origine

Si riferisce al dominio coperto in un particolare file di zona.

named, BIND, name server

Nomi comuni per il pacchetto name server BIND all’interno di FreeBSD.

Risolutore

Un processo di sistema attraverso il quale una macchina fa query su un name server per informazioni di zona.

DNS inverso

L’opposto del forward DNS; mappare indirizzi IP su nomi host.

Zona root

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.

Zona

Un dominio individuale, sottodominio, o porzione del DNS amministrato dalla stessa autorità

Esempi di zone:

  • . è la zona root

  • org. è una zona Top Level Domain (TLD) sotto la zona root

  • example.org. è una zona sotto la zona `org.`TLD

  • 1.168.192.in-addr.arpa è una zona che referenzia tutti gli indirizzi IP che cadono sotto lo spazio IP`192.168.1.*`.

Come si può vedere, la parte più specifica di un nome host appare a sinistra. Per esempio example.org. è più specifico di org., come org. è più specifico della zona root. La disposizione di ogni parte di un nome host è analoga ad un file system: la directory /dev cade all’interno della root, e così via.

27.6.3. Ragioni per Avere in Esecuzione un Name Server

Attualmente vengono usati due tipi di name server: un name server autoritativo, ed un name server cache.

Un name server autoritativo è necessario quando:

  • uno vuole servire informazioni DNS a tutto il mondo, rispondendo in maniera autoritativa alle query.

  • un dominio, tipo example.org, è registrato e gli indirizzi IP devono essere assegnati ad hostname sotto questo.

  • un blocco di indirizzi IP richiede entry di DNS inverso (da IP ad hostname).

  • un name server di backup, chiamato uno slave, deve rispondere alle query.

Un name server cache è necessario quando:

  • un server locale DNS può tenere in cache e rispondere più velocemente rispetto ad effettuare query ad un name server all’esterno.

  • una riduzione nel traffico complessivo di rete è desiderato (è stato calcolato che il traffico DNS conta più del 5% sul traffico totale di Internet).

Quando uno fa una query per risolvere www.FreeBSD.org, il risolutore di solito fa una query al name server dell’ISP a cui si è connessi, ed ottiene una risposta. Con un server DNS locale, che fa cache, la query deve essere effettuata una volta sola dal server DNS che fa cache. Ogni query aggiuntiva non dovrà cercare all’esterno della rete locale, dato che l’informazione è tenuta in cache localmente.

27.6.4. Come Funziona

In FreeBSD, il demone BIND è chiamato named per ovvie ragioni.

FileDescrizione

named(8)

Il demone BIND.

rndc(8)

Programma di controllo del name server.

/etc/namedb

Directory dove risiedono le informazioni di zona di BIND.

/etc/namedb/named.conf

File di configurazione del demone.

A seconda di come certe zone sono configurate sul server, i file relativi a quelle zone possono essere trovate nelle sottodirectory master, slave, or dynamic della directory /etc/namedb. Questi file contengono le informazioni DNS che saranno distribuite dal name server in risposta alle query.

27.6.5. Avviare BIND

Dato che BIND è installato di default, configurarlo è relativamente semplice.

La configurazione di default di named è quella di un name server basilare, eseguito in ambiente chroot(8). Per avviare il server una volta con questa configurazione, usa il seguente comando:

# /etc/rc.d/named forcestart

Per assicurarsi che il demone named sia avviato alla partenza, metti la seguente riga in /etc/rc.conf:

named_enable="YES"

Ci sono ovviamente molte opzioni di configurazione per /etc/namedb/named.conf che sono al di là dello scopo di questo documento. Comunque, se siete interessati nelle opzioni di avvio per named su FreeBSD, dai un’occhiata ai flags named_ in /etc/defaults/rc.conf e consulta la pagina di manuale rc.conf(5). Anche la sezione Configurazione Iniziale è una buona base di partenza.

27.6.6. File di Configurazione

I file di configurazione per named al corrente risiedono nella directory /etc/named 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.

27.6.6.1. Usando make-localhost

Per configurare una zona master per il localhost visita la directory /etc/namedb ed esegui il seguente comando:

# sh make-localhost

Se tutto è andato bene, un nuovo file dovrebbe esistere nella sottodirectory master. I nomi dei file dovrebbero essere localhost.rev per il local domain name e localhost-v6.rev per le configurazioni IPv6. Come il file di configurazione di default, l’informazione richiesta sarà presente nel file named.conf.

27.6.6.2. /etc/namedb/named.conf

// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/shared/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;
  };
*/

Proprio come dicono i commenti, per beneficiare di una cache di un server superiore, può essere abilitato forwarders. 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.

127.0.0.1 non funzionerà qui. Cambia questo indirizzo IP in un name server superiore.

  /*
   * 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;
  };
};
*/

In named.conf, ci sono esempi di linee slave per zone di forward ed inverse.

Per ogni nuova zona servita, una nuova linea di zona deve essere aggiunta a named.conf.

Per esempio, la più semplice entry per example.org può assomigliare a:

zone "example.org" {
   type master;
   file "master/example.org";
};

La zona è una master, come indicato dall’entry type, e conserva le informazioni di zona su /etc/namedb/master/example.org indicata dalla entry file.

zone "example.org" {
   type slave;
   file "slave/example.org";
};

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.

27.6.6.3. File di Zona

Un esempio di file di zona master per example.org (che esiste all’interno di /etc/namedb/master/example.org) è la seguente:

$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   @

Nota che ogni hostname che finisce in un "." è un nome esatto, mentre ogni entità senza un "." è referenziato all’origine. Per esempio www è trasformato in www.origin. Nel nostro file di zone fittizio, la nostra origine è example.org, così www si trasformerebbe in www.example.org.

Il formato di un file di zona è il seguente:

recordname      IN recordtype
value

I record DNS usati più di frequente:

SOA

inizio di una zona di autorità

NS

un name server autoritativo

A

un indirizzo host

CNAME

il nome canonico per un alias

MX

mail exchanger

PTR

un puntatore a nome di dominio (usato nel DNS inverso)

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
example.org.

il nome di dominio, inoltre è l’origine per questo file di zona.

ns1.example.org.

il name server primario/autoritativo per questa zona.

admin.example.org.

la persona responsabile per questa zona, un indirizzo email con "@" sostituito. (admin@example.org diventa admin.example.org)

2006051501

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 yyyymmddrr per il numero di serie. 2006051501 significherebbe modificato l’ultima volta il 05/15/2006, l’ultimo 01 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.

       IN NS           ns1.example.org.

Questa è una linea NS. Ogni name server che replicherà in maniera autoritativa la zona deve avere una di queste linee. Il @ come visto potrebbe essere stato ` example.org.` Il @ si traduce nell’origine.

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

Il record A indica un nome macchina. Come visto sopra, ns1.example.org risolverebbe in 192.168.1.2.

                IN      A       192.168.1.1

Questa linea assegna l’indirizzo IP 192.168.1.1 alla corrente origine, in questo caso example.org.

www             IN CNAME        @

Il record nome canonico è usato per dare alias ad una macchina. Nell’esempio, www è tramutato in alias nella macchina "master" che corrisponde al domain name example.org ` (`192.168.1.1). CNAME possono essere usati per fornire alias ad hostname o distribuire in round robin un hostname fra molte macchine.

               IN MX   10      mail.example.org.

Il record MX ` usato per specificare quali mail server sono responsabili per gestire mail entranti per la zona. `mail.example.org ` è l’hostname del mail server, e 10 è la priorità di quel mail server.

Uno può avere molti mail server, con priorità di 10, 20 e così via. Un mail server che cerca di consegnare una mail a example.org 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.

Per file di zona in-addr.arpa (DNS inverso), lo stesso formato è usato, eccetto con linee PTR al posto di A o CNAME.

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

Questo file da la corretta mappa da indirizzi IP ad hostname per il nostro dominio fittizio.

27.6.7. Caching Name Server

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.

27.6.8. Sicurezza

Anche se BIND è la più comune implementazione del DNS, c’è sempre la questione della sicurezza. Talvolta vengono trovati possibili e sfruttabili buchi di sicurezza.

Mentre FreeBSD tiene named automaticamente in un ambiente chroot(8), ci sono molti altri meccanismi di sicurezza che potrebbero essere sfruttati per attacchi al servizio DNS.

È una buona idea leggere gli avvisi sulla sicurezza di CERT e sottoscrivere le mailing list sugli avvisi di sicurezza su FreeBSD per stare aggiornato con le questioni correnti di sicurezza di Internet e FreeBSD.

Se sorge un problema, tenere i sorgenti aggiornati e fare una compilazione al volo di named non farebbe male.

27.7. Apache HTTP Server

27.7.1. Uno sguardo d’insieme

FreeBSD è usato per far girare alcuni dei siti web più trafficati al mondo. La maggioranza dei web server su Internet usano attualmene Apache HTTP Server. Il pacchetto software di Apache dovrebbe essere incluso nel tuo media di installazione di FreeBSD. Se non hai installato Apache quando hai installato FreeBSD per la prima volta, lo puoi installare dal port www/apache13 o www/apache22.

Una volta che Apache è stato installato con successo, deve essere configurato.

Questa sezione copre la versione 1.3.X di Apache HTTP Server dato che è la versione più usata per FreeBSD. Apache 2.X introduce molte nuove tecnologie ma queste non saranno discusse in questa sede. Per maggiori informazioni su Apache 2.X, per favore consulta httpd://httpd.apache.org/.

27.7.2. Configurazione

Il principale file di configurazione di Apache HTTP Server è installato in /usr/local/etc/apache/httpd.conf su FreeBSD. Questo file è un tipico file di testo di configurazione di UNIX® con linee di commento che cominciano col carattere #. 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.

ServerRoot "/usr/local"

Questo specifica la gerachia di directory di default per l’installazione di Apache. I binari sono conservati nelle sottodirectory bin e sbin sotto la server root, ed i file di configurazione sono conservati sotto etc/apache.

ServerAdmin you@your.address

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.

ServerName www.example.com

ServerName 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 `www ` invece del vero nome host).

DocumentRoot "/usr/local/www/data"

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

È sempre una buona idea fare copie di backup del tuo file di configurazione di Apache prima di modificarlo. Una volta che sei soddisfatto dalla tua configurazione iniziale sei pronto per iniziare ad eseguire Apache.

27.7.3. Eseguire Apache

Apache non viene eseguito dal super server inetd 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 Apache per la prima volta, esegui:

# /usr/local/sbin/apachectl start

Puoi fermare il server in ogni istante digitando:

# /usr/local/sbin/apachectl stop

Dopo aver fatto modifiche al file di configurazione per una qualsiasi ragione, avrai bisogno di riavviare il server:

# /usr/local/sbin/apachectl restart

Per riavviare Apache senza mandare in abort le connessioni correnti, esegui.

# /usr/local/sbin/apachectl graceful

Informazioni addizionali sono disponibili sulla pagina di manuale di apachectl(8).

Per eseguire Apache all’avvio del sistema, aggiungi la seguente linea ad /etc/rc.conf:

apache_enable="YES"

o per Apache 2.2:

apache22_enable="YES"

Se volessi fornire opzioni addizionali di linea di comando al programma Apache`httpd` avviato al boot di sistema, puoi specificarle con una linea addizionale in rc.conf:

apache_flags=""

Ora che il web server è in esecuzione puoi navigare il tuo sito web puntando il tuo web browser ad http://localhost/. La pagina di default che viene mostrata è /usr/local/www/data/index.html.

27.7.4. Virtual Hosting

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

Per fare sì che Apache usi Virtual Hosting basato sui nomi aggiungi una entry come la seguente al tuo file httpd.conf:

NameVirtualHost *

Se il tuo webserver era nominato www.domain.tld e tu avessi voluto installare un dominio virtuale per `www.someotherdomain.tld ` avresti dovuto aggiungere le seguenti entry a httpd.conf:

<VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain.tld
</VirtualHost>

<VirtualHost *>
ServerName www.someotherdomain.tld
DocumentRoot /www/someotherdomain.tld
</VirtualHost>

Sostituisci gli indirizzi con gli indirizzi che vuoi usare ed i percorsi dei documenti con quelli che usi.

Per maggiori informazioni sull’impostazione dei virtual host, per favore consulta la documentazione ufficiale a http://httpd.apache.org/docs/vhosts/.

27.7.5. Moduli Apache

Ci sono molti diversi moduli Apache disponibili per aggiungere funzionalità al server base. La Collezione Port di FreeBSD fornisce un modo semplice di installare Apache assieme ad alcuni dei più popolari moduli aggiuntivi.

27.7.5.1. mod_ssl

Il modulo mod_ssl 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 FreeBSD.

Se non hai ancora installato Apache, una versione di Apache 1.3.X che includa mod_ssl può essere installata con il port www/apache13-modssl. Il supporto ad SSL è anche disponibile per Apache 2.X nel port www/apache22, dove viene abilitato di default.

27.7.5.2. Siti web dinamici con Perl & PHP

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 Microsoft® hanno introdotto soluzioni nei loro prodotti proprietari, la comunità open source ha risposto all’appello. Due opzioni per contenuti web dinamici includono mod_perl & mod_php.

27.7.5.2.1. mod_perl

Il progetto di integrazione Apache/Perl mette assieme la grande potenza del linguaggio di programmazione Perl e l’Apache HTTP Server. Con il modulo mod_perl è possibile scrivere moduli Apache 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.

mod_perl è disponibile in alcuni modi diversi. Per usare mod_perl ricorda che mod_perl 1.0 funziona solo con Apache 1.3 e mod_perl 2.0 funziona solo con Apache 2.X. mod_perl 1.0 è disponibile in www/mod_perl ed una versione compilata staticamente è disponibile in www/apache13-modperl. mod_perl 2.0 è disponibile in www/mod_perl2.

27.7.5.2.2. mod_php

PHP, anche noto come "Hypertext Prepocessor" è un linguaggio di scripting di scopo generale che è particolarmente adatto per lo sviluppo Web. Adatto ad essere usato all’interno dell’HTML, 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.

Per integrare supporto a PHP5 per il web server Apache, inizia con l’installare il port lang/php5.

Se il port lang/php5 viene installato per la prima volta, le OPTIONS disponibili saranno mostrate automaticamente. Se non viene mostrato un menu, ad esempio perché il port lang/php5 è stato installato qualche volta in passato, è sempre possibile rivedere il menu a dialogo con le opzioni eseguendo:

# make config

nella directory dei port.

Nel menu a dialogo delle opzioni, flagga l’opzione APACHE per compilare mod_php5 come modulo caricabile per il web server Apache.

Molti siti stanno ancora usando PHP4 per varie ragioni (ad esempio questioni di compatibilità o applicativi web già costruiti). Se si necessita del modulo mod_php4 invece che di mod_php5, siete pregati di usare il port lang/php4. Il port lang/php4 supporta molte delle configurazioni e delle opzioni di build-time del port lang/php5.

Questo installerà e configurerà i moduli richiesti per supportare applicazioni web dinamiche PHP. Controlla che le seguenti linee siano state aggiunte al file /usr/local/etc/apache/httpd.conf:

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>

Una volta completato, una semplice chiamata al comando apachectl per un tranquillo restart è richiesto per caricare il modulo PHP:

# apachectl graceful

Per upgrade futuri di PHP, il comando make config non sarà richiesto; le OPTIONS selezionate sono salvate automaticamente dal sistema dei Ports di FreeBSD.

Il supporto a PHP in FreeBSD è estremamente modulare così l’installazione base è molto limitata. È molto facile aggiungere supporto usando il port lang/php5-extensions. Questo port fornisce un interfaccia a menu per l’installazione di estensioni a PHP. Alternativamente le singole estensioni possono essere installate usando il port appropriato.

Ad esempio, per aggiungere supporto al database MySQL a PHP5, semplicemente installa databases/php5-mysql.

Dopo aver installato un’estensione, il server Apache deve essere riavviato per caricare i cambiamenti della nuova configurazione:

# apachectl graceful

27.8. File Transfer Protocol (FTP)

27.8.1. Uno sguardo d’insieme

Il File Transfer Protocol (FTP) fornisce agli utenti un semplice modo di trasferire file da e verso un server FTP. FreeBSD include software per server FTP nel sistema base. Questo rende l’installazione e l’ammininistrazione di un server FTP molto semplice.

27.8.2. Configurazione

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 /etc/ftpusers è 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.

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 /etc/ftpchroot. Questo file elenca utenti e gruppi soggetti a restrizioni di accesso FTP. La pagina di manuale ftpchroot(5) ha tutti i dettagli così non sarà descritta qui.

Se tu volessi abilitare accesso anonimo FTP al tuo server, devi creare un utente chiamato ftp sul tuo sistema FreeBSD. Gli utenti allora potranno loggarsi al tuo server FTP con uno username di ftp o anonymous e con una password qualsiasi (di norma dovrebbe essere usato un indirizzo email dell’utente come password). Il server FTP chiamerà chroot(2) quando un utente anonimo si logga, per restringere l’accesso solo alla home directory di ftp.

Ci sono due file di testo che specificano messaggi di benvenuto per i client FTP. Il contenuto del file /etc/ftpwelcome sarà mostrato agli utenti prima che raggiungano il prompt del login. Dopo un login di successo, il contenuto del file /etc/ftpmotd sarà mostrato. Nota che il percorso di questo file è relativo all’ambiente di login, così saraà mostrato il file ~ftp/etc/ftpmotd.

Una volta che il server FTP è stato configurato correttamente, deve essere abilitato in /etc/inetd.conf. Tutto ciò che viene richiesto è rimuovere il simbolo di commento "#" dall’inizio della linea relativa a ftpd:

ftp  stream  tcp  nowait  root  /usr/libexec/ftpd ftpd -l

Come spiegato in Ricaricare il file di configurazione di inetd, la configurazione di inetd deve essere ricaricata dopo che che questo file di configurazione è stato cambiato.

Ora puoi loggarti al tuo server FTP digitando:

% ftp localhost

27.8.3. Manutenzione

Il demone ftpd usa syslog(3) per loggare i mesaggi. Di default il demone dei log di sistema girerà i messaggi relativi a FTP nel file /var/log/xferlog. La posizione del log FTP può essere modificata cambiando la seguente linea in /etc/syslog.conf:

ftp.info      /var/log/xferlog

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.

27.9. Servizi di File e Stampa per client Microsoft® Windows® (Samba)

27.9.1. Uno sguardo d’insieme

Samba è un popolare pacchetto software open source che fornisce servizi di file e stampa per client Microsoft® 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.

Il pacchetto software Samba dovrebbe essere incluso nel tuo media di installazione FreeBSD. Se non hai installato Samba quando hai installato per la prima volta FreeBSD, puoi sempre installarlo dal port o pacchetto net/samba3.

27.9.2. Configurazione

Un file di configurazione di Samba di default è installato in /usr/local/shared/examples/smb.conf.default. Questo file deve essere copiato in /usr/local/etc/smb.conf e personalizzato prima che Samba possa essere usato.

Il file smb.conf contiene informazione di configurazione runtime per Samba, come le definizioni delle stampanti e "share di file system" che vorresti condividere con Windows® client. Il pacchetto Samba include un tool basato sul web chiamato swat che fornisce un modo semplice di configurare il file smb.conf.

27.9.2.1. Usare il Samba Web Administration Tool (SWAT)

Il Samba Web Administration Tool (SWAT) viene eseguito come demone da inetd. Quindi, dovresti togliere i commenti alla seguente linea in /etc/inetd.conf prima che swat possa essere usato per configurare Samba:

swat   stream  tcp     nowait/400      root    /usr/local/sbin/swat    swat

Come spiegato in Ricaricare il file di configurazione di inetd, la configurazione di inetd deve essere ricaricata dopo che questo file di configurazione è stato cambiato.

Una volta che swat è stato abilitato in inetd.conf, puoi usare un browser per connetterti a http://localhost:901. Dovrai prima loggarti con l’account di sistema root.

Una volta che ti sei loggato con successo alla pagina principale di configurazione di Samba, puoi navigare la documentazione di sistema, o iniziare cliccando sul tab Globals. La sezione Globals corrisponde alle variabili che sono impostate nella sezione [global] di /usr/local/etc/smb.conf.

27.9.2.2. Impostazioni Globali

Sia che tu stia usando swat o che tu stia editando direttamente /usr/local/etc/smb.conf, le prime direttive che tu puoi incontrare quando configuri Samba sono:

workgroup

Nome dominio NT o nome Workgroup per i computer che accedono a questo server.

netbios name

Questo imposta il nome NetBIOS attraverso il quale un Samba è conosciuto. Di default è lo stesso della prima parte del nome host DNS.

server string

Questo imposta la stringa che sarà mostrata con il comando net view e con alcuni altri strumenti di rete che cercano di mostrare testo descrittivo sul server.

27.9.2.3. Impostazioni di Sicurezza

Due delle più importanti impostazioni in /usr/local/etc/smb.conf sono i modelli di sicurezza usati, ed il formato delle password di backend per utenti client. Le seguenti direttive controllano queste opzioni:

security

Le due più comuni opzioni in questo caso sono security = share e security = user. Se i tuoi client usano nomi utente che sono gli stessi dei nomi utenti sulla tua macchina FreeBSD, 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.

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

passdb backend

Samba 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 è smbpasswd, e questo sarà l’unico coperto qui.

Assumendo che il backend usato sia quello di default, smbpasswd, il file /usr/local/private/smbpasswd deve essere creato per permettere a Samba di autenticare i client. Se tu volessi dare ai tuoi account UNIX® accesso da client Windows®, usa il seguente comando:

# smbpasswd -a username

Per favore consulta l' Official Samba HOWTO HOWTO Ufficiale di Samba per informazioni addizionali sulle opzioni di configurazione. Con le basi delineate qui, dovresti avere tutto ciò di cui hai bisogno per avviare Samba.

27.9.3. Avviare Samba

Il port net/samba3 aggiunge un nuovo script di avvio, che può essere usato per controllare Samba. Per abilitare questo script, in modo tale da essere usato per esempio per avviare fermare o far ripartire Samba, aggiungi la riga seguente al file /etc/rc.conf:

samba_enable="YES"

Oppure, per un controllo più accurato:

nmbd_enable="YES"
smbd_enable="YES"

In questo modo Samba viene avviato automaticamente ad ogni avvio del sistema.

Per avviare Samba digita:

# /usr/local/etc/rc.d/samba start
Starting SAMBA: removing stale tdbs :
Starting nmbd.
Starting smbd.

Fai riferimento alla Usare rc con FreeBSD per ulteriori informazioni sull’uso degli script rc.

Samba attualmente consiste di tre demoni separati. Dovresti osservare che entrambi nmbd e smbd siano avviati dallo script samba. Se hai abilitato servizi di risoluzione di nomi winbind in smb.conf, allora osserverai che anche il demone winbindd è avviato.

Puoi anche fermare Samba in ogni istante digitando:

# /usr/local/etc/rc.d/samba stop

Samba è una suite complessa di software con funzionalità che permette una larga integrazione con reti Microsoft® Windows®. Per maggiori informazioni sulle funzionalità al di là dell’installazione di base descritta qui per favore consulta http://www.samba.org.

27.10. Sincronizzazione del Clock con NTP

27.10.1. Uno sguardo d’insieme

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.

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 cron(8) si basano su un clock di sistema accurato per eseguire comandi al momento specificato.

FreeBSD è dotato del server ntpd(8) NTP che può essere usato per interrogare altri server NTP per impostare il clock sulla tua macchina o fornire servizi di time ad altri.

27.10.2. Scegliere Server NTP Appropriati

Per sincronizzare il tuo clock, avrai bisogno di scegliere uno o più server NTP 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 lista online di server NTP pubblicamente accessibili 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.

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. ntpd(8) usa le risposte che riceve da altri server in modo intelligente; favorirà server inaffidabili meno di quelli affidabili.

27.10.3. Configurare la tua Macchina

27.10.3.1. Configurazione Base

Se desideri solo sincronizzare il tuo clock al momento del boot della macchina, puoi usare 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 ntpd(8).

Usare ntpdate(8) al momento del boot è una buona idea per le macchine che eseguono ntpdate(8). Il programma ntpd(8) cambia il clock gradualmente, mentre 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.

Per abilitare ntpdate(8) al momento del boot, aggiungi ntpdate_enable="YES" a /etc/rc.conf. Avrai anche bisogno di specificare tutti i server con i quali ti desideri sincronizzare ed ogni flags passato a ntpdate(8) in ntpdate_flags.

27.10.3.2. Configurazione Generale

NTP è configurato dal file /etc/ntp.conf nel formato descritto da ntp.conf(5). Questo è un semplice esempio:

server ntplocal.example.com prefer
server timeserver.example.org
server ntp2a.example.net

driftfile /var/db/ntp.drift

L’opzione server specifica quali server siano da usare, con un server elencato su ogni linea. Se un server è specificato con l’argomento prefer, come con ntplocal.example.com, 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 prefer è normalmente usato per server NTP che sono noti per essere molto accurati, come quelli con hardware a monitoraggio speciale del tempo.

L’opzione driftfile specifica quale file sia usato per conservare la frequenza di scostamento dal clock di sistema. Il programma 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.

L’opzione driftfile 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.

27.10.3.3. Controllare l’Accesso ad i tuoi Server

Di default, il tuo server NTP sarà accessibile a tutti gli host su Internet. L’opzione restrict in /etc/ntp.conf ti permette di controllare quali macchine possano accedere al tuo server.

Se vuoi negare a tutte le macchine accesso al tuo server NTP, aggiungi la seguente linea a /etc/ntp.conf:

restrict default ignore

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 ntp.conf(5) per ulteriori dettagli.

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

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

invece, dove`192.168.1.0` è un indirizzo IP sulla tua rete e 255.255.255.0 è la netmask della tua rete.

/etc/ntp.conf può contenere molte opzioni restrict. Per maggiori dettagli, consulta la sezione Access Control Support di ntp.conf(5).

27.10.4. Eseguire il Server NTP

Per assicurarsi che il server NTP sia avviato al momento del boot, aggiungi la linea ntpd_enable="YES" a /etc/rc.conf. Se desideri passare flag addizionali a ntpd(8), edita il parametro ntpd_flags in /etc/rc.conf.

Per avviare il server senza riavviare la tua macchina, esegui ntpd accertandoti di specificare ogni parametro addizionale in ntpd_flags presente in /etc/rc.conf. Per esempio:

# ntpd -p /var/run/ntpd.pid

27.10.5. Usare ntpd con una Connessione Temporanea ad Internet

Il programma 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 filter in /etc/ppp/ppp.conf. Per esempio:

 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

Pre maggiori dettagli consulta la sezione PACKET FILTERING in ppp(8) e gli esempi in /usr/shared/examples/ppp/.

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.

27.10.6. Informazioni Ulteriori

La documentazione per il server NTP può essere trovata in formato HTML in /usr/shared/doc/ntp/.


Questo, ed altri documenti, possono essere scaricati da https://download.freebsd.org/ftp/doc/

Per domande su FreeBSD, leggi la documentazione prima di contattare <freebsd-questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a <freebsd-doc@FreeBSD.org>.