Capitolo 27. Server di rete

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.

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:

o

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

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.

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

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:

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:

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

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.

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.

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:

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.

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:

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

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

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.

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.

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.

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:

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

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:

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:

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

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:

Sul client NFS:

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:

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:

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

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

Avvia l’applicazione con:

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

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

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.

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:

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

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.

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:

Come comando manuale di mount da freebox:

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

Come comando di mount manuale su fastws:

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.

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.

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:

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.

Questa sezione riguarderà l’installazione di un ambiente di esempio 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.

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.

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:

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.

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

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, 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:

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

Attivare e distribuire la tua nuova mappa NIS è facile:

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:

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

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.

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:

Le linee corrispondenti per le workstation normali potrebbero essere:

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:

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:

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:

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.

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

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.

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:

Consulta ypbind(8) per ulteriori informazioni.

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:

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:

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:

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.

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.

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.

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

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:

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.

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

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

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

Esempi di zone:

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.

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

Un name server autoritativo è necessario quando:

Un name server cache è necessario quando:

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.

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

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.

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:

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

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.

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.

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.

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.

Pagine di manuale di BIND/named: rndc(8) named(8) named.conf(8)

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.

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.

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

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:

Puoi fermare il server in ogni istante digitando:

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

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

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:

o per Apache 2.2:

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:

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.

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:

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:

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

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.

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.

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:

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:

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:

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.

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.

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.

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:

Oppure, per un controllo più accurato:

Per avviare Samba digita:

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:

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.

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.

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.

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:

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:

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

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