%%
%% Dispense Amministrazione di rete
%%
%% Copyright (C) 2003-2018 Simone Piccardi and Truelite Srl.
%%
%% This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
%% International License. To view a copy of this license, visit
%% \url{http://creativecommons.org/licenses/by-sa/4.0/} or send a letter to
%% Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
%%
%% S. Piccardi Dec. 2005
%%
%% netlpi.tex: sezione delle parti aggiuntive da mettere per coprire
%%             gli argomenti di LPI. Separato dalla precedente sui servizi
%%             di base.
%%

%%
%% Materiale totalmente obsoleto, andrà a sparire
%%

\ifx\lpispecificsection\undefined

\relax
\else

\subsection{La configurazione con Bind4}
\label{sec:net_bind4}

Benché ormai la gran parte dei server sia passata alle versioni più recenti di
\texttt{bind} (la versione 8 o la 9) esistono ancora un certo numero di server
che mantengono la vecchia versione 4. Il passaggio da questa alle successive
ha visto un grosso cambiamento del server, ed in particolare della sua
configurazione. 

Il cambiamento principale (a parte la struttura interna del server stesso) è
stato quello nei file di configurazione; la versione 4 infatti non usa
\texttt{named.conf} ma un file \texttt{named.boot}, che ha una sintassi
completamente diversa; le differenze per fortuna si fermano qui, ed i file che
definiscono le zone sono sostanzialmente immutati.

Un possibile esempio di file \texttt{named.boot}, con una configurazione che è
sostanzialmente equivalente a quella vista nei paragrafi precedenti, è il
seguente:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
;
; Bind v4 configuration file
;
directory  /etc/bind
forwarders  213.234.128.211  213.234.132.130
cache           .                  db.root                     
; zone definitions
; type     domain                  file
primary    0.0.127.in-addr.arpa    db.127
primary    localhost               db.local
primary    earthsea.ea             db.earthsea
primary    1.168.192.in-addr.arpa  db.192.168.1
\end{Verbatim}

La direttiva \texttt{directory} specifica la directory di lavoro corrente del
server, così che tutti i pathname relativi impiegati in seguito faranno
riferimento ad essa. La direttiva \texttt{primary} permette di definire un
dominio per cui si è DNS primario; deve essere seguita dal nome del dominio e
dal file in cui sono contenute le informazioni sui relativi resource record.
La direttiva \texttt{secondary} invece permette di definire un dominio per cui
si è DNS secondario, deve essere seguita dal nome del dominio, dalla lista dei
server primari e dal file su cui salvare i dati. La direttiva
\texttt{forwarders} permette, come l'analoga opzione di bind8, di reinviare le
richiesta ad altri server DNS, la cui lista è a seguire. Infine la direttiva
\texttt{cache} permette di ottenere le informazioni su un dominio da un file
(è analoga ad una zona di tipo \texttt{hint} di bind8) e nel caso permette di
specificare la lista dei root DNS.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}[c]{|l|p{8cm}|}
    \hline
    \textbf{Direttiva} &\textbf{Significato}\\
    \hline
    \hline
     \texttt{domain <nome>}           & Imposta il nome di dominio di
                                        default. \\ 
     \texttt{directory <path>}        & Specifica la directory di lavoro del
                                        server.\\ 
     \texttt{primary <dominio> <file>}& Definisce un dominio per cui si è DNS
                                        primario.\\ 
     \texttt{secondary <dominio> <lista> <file>} & Definisce un dominio per
                                        cui si è DNS secondario. \\
     \texttt{cache <dominio> <file>}  & Definisce un file di cache per un
                                        dominio.\\ 
     \texttt{forwarders <list>}        & Imposta i DNS a cui reinviare le
                                        richieste.\\  
     \texttt{options <opzione>}       & Imposta una opzione.\\
    \hline    
  \end{tabular}
  \caption{Opzioni impostabili nel file \texttt{named.boot}.}
  \label{tab:net_named.boot}
\end{table}

L'elenco delle direttive principali è riportato in
tab.~\ref{tab:net_named.boot}; l'elenco completo delle opzioni si può trovare
nella pagina di manuale di \texttt{named.boot}, insieme alla documentazione di
bind4.


\chapter{Altri servizi}
\label{cha:network_other_service_for_lpi}


\section{Un firewall elementare}
\label{sec:net_firewall}

In Linux il kernel implementa un firewall molto sofisticato, in grado di
manipolare e controllare l'ingresso e l'uscita dei pacchetti dal sistema a
tutti i vari livelli dei protocolli di rete. L'argomento è molto complesso e
richiede una conoscenza approfondita dei vari protocolli e dei principi di
funzionamento dei firewall, per questo daremo solo delle indicazioni relative
ad un uso elementare.


\subsection{L'uso di \texttt{iptables}}
\label{sec:net_iptables}

A partire dal kernel 2.4 il programma che permette di configurare il filtro
dei pacchetti è \texttt{iptables}, tratteremo solo questo dato che le capacità
dei kernel precedenti erano assolutamente limitate. Nel caso vi troviate ad
avere a che fare con uno di questi il comando invece è \texttt{ipchains} per i
kernel della serie 2.2 e \texttt{ipfwadmin} per quelli della serie 2.0.

In genere si usa un firewall in una macchina interposta fra l'esterno e la
vostra rete locale, per proteggere quest'ultima da eventuali aggressioni e far
accedere alla rete esterna attraverso un unico IP. La modalità più sicura per
fare ciò è quella di mettere su una macchina due schede di rete, una delle
quali (che supporremo essere associata all'interfaccia \texttt{eth0})
agganciata direttamente al router, e l'altra (che supporremo essere associata
all'interfaccia \texttt{eth1}) alla vostra rete locale, usando questa la
macchina stessa come gateway.

In questo caso la prima cosa che dovete fare è abilitare il forwarding dei
pacchetti fra le due interfacce come detto in sez.~\ref{sec:net_route} quando
abbiamo affrontato questo problema per il routing. Il passo successivo è
definire delle regole; in questa configurazione elementare tutto quello che
serve è attivare il cosiddetto \textit{masquerading}, cioè far apparire tutte
le macchine della rete interna con un unico IP pubblico, in modo che nessuno
ossa collegarcisi dall'esterno, e far passare solo i pacchetti relativi a
connessioni create da esse.

Le regole per ottenere tutto questo sono molto semplici, basterà eseguire i
seguenti comandi (ad esempio lanciandoli con uno script eseguito all'avvio):
\begin{verbatim}
# Flush tables
iptables -F
iptables -t nat -F

# Masquerade out eth0
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Disallow NEW and INVALID incoming or forwarded packets from eth0.
iptables -A INPUT -i eth0 -m state --state NEW,INVALID -j DROP
iptables -A FORWARD -i eth0 -m state --state NEW,INVALID -j DROP

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
\end{verbatim}
i primi due comandi (opzione \texttt{-F}) servono per cancellare le eventuali
regole esistenti, il secondo comando serve per attivare il
\textit{masquerading} (con \texttt{-j MASQUERADE}) dei pacchetti uscenti
sull'interfaccia \texttt{eth0} (specificata con \texttt{-o eth0}), che si
suppone essere quella collegata verso l'esterno.

I due successivi comandi bloccano (usando \texttt{-j DROP}) l'accesso a
qualsiasi pacchetto proveniente dalla interfaccia di ingresso (\texttt{-i
  eth0}) e diretto verso la macchina (\texttt{-A INPUT}) o verso la rete
interna (\texttt{-A FORWARD}), che non sia relativo ad una connessione già
attivata (per questo si attiva il controllo sugli stati con \texttt{-m state}
per bloccare gli stati \texttt{NEW} e \texttt{INVALID} con \texttt{-{}-state
  NEW,INVALID}).

In questo modo solo i pacchetti relativi alle connessioni originanti dal
firewall, o da una delle macchine interne (che vengono mascherate) possono
attraversare il firewall. Informazioni sull'uso di \texttt{iptables} possono
essere trovate nel \textit{Packet Filtering HOWTO}, e le varie opzioni sono al
solito descritte in dettaglio nella pagina di manuale.


\subsection{L'uso di \texttt{ipchains}}
\label{sec:net_ipchains}

Esistono dei casi in cui non si può disporre di un kernel 2.4, ad esempio
alcune distribuzioni per firewall realizzate su dischetti usano ancora il 2.2
per ragioni di spazio, oppure si può avere una macchina critica che non può
essere reinstallata o riavviata.

In questo caso il firewall del kernel non è \textit{stateful}, e ha delle
caratteristiche molto più limitate; in ogni caso per l'uso elementare mostrato
nella sezione precedente è più che sufficiente, solo che al posto di
\texttt{iptables} occorre usare un diverso programma: \texttt{ipchains}. 

La sintassi è molto simile a quella di \texttt{iptables}, solo che in questo
caso non esistono tabelle diverse, come nel \textit{netfilter}, mentre sono
predefinite tre \textsl{catene}: \texttt{input}, \texttt{output} e
\texttt{forward} (si noti che i nomi sono in questo caso minuscoli), che hanno
circa lo stesso significato. Inoltre non esiste più un filtro basato sugli
stati, per cui si potrà filtrare solo in base alle caratteristiche dei
pacchetti. Infine il \textit{masquerading} si applicherà sulla catena di
\texttt{forward}. Per questo motivo, delle regole simili alle precedenti per
\texttt{iptables} potranno essere scritte come:
\begin{verbatim}
# Flush tables
ipchains -F input
ipchains -F output
ipchains -F forward

# Masquerade out 
ipchains -A forward -s 192.169.1.0/24 -d ! 192.169.1.0/24 -j MASQ

# Disallow NEW and INVALID incoming or forwarded packets from eth0.
ipchains -A input -i eth0 --syn -j DENY
ipchains -A forward -i eth0 --syn -j DENY

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
\end{verbatim}

In questo caso le catene devono essere svuotate con \texttt{-F} singolarmente.
Dopo di che per abilitare il masquerading occorre usare con \texttt{-j} il
target \texttt{MASQ} (valido solo sulla catena \texttt{forward}) specificando
qual'è l'intervallo degli indirizzi di origine (nel caso
\texttt{192.169.1.0/24}, specificati con \texttt{-s}) e per quali indirizzi di
destinazione (specificati con \texttt{-d}) che nel caso sono tutti eccetto i
precedenti (si è infatti usato \texttt{! 192.169.1.0/24}).

Infine si è abilitato la protezione per le connessioni entranti, riconosciute
tramite l'opzione \texttt{-{}-syn}, chiedendo al firewall di scartare i
relativi pacchetti con il target \texttt{DENY}.


\section{La gestione di base posta elettronica}
\label{sec:net_email_base}

La posta elettronica è uno dei principali servizi disponibili sui sistemi
Unix. Essa nasce, insieme con i servizi di news, ben prima di Internet, e uno
dei primi protocolli di trasmissione di allora, UUCP, è ancora usato.  A
tutt'oggi, insieme alle pagine web, la posta elettronica è una delle
principali componenti del traffico su Internet.

\subsection{La posta elettronica con \texttt{sendmail}}
\label{sec:net_sendmail}

Il programma più diffuso per la ricezione e l'invio della porta elettronica è
\texttt{sendmail}. Esso è stato il primo server SMTP (\textit{Simple Mail
  Network Protocol}, questo è il nome del servizio) ed a questo deve la sua
diffusione. A questo deve però anche tutti i suoi difetti, a partire da una
lunga storia di vulnerabilità, per finire con una sintassi di configurazione
considerata una fra le più (inutilmente) complicate.

In questa sezione affronteremo comunque solo gli aspetti della configurazione
di base. A parte RedHat tutte le altre distribuzioni usano degli SMTP server
più moderni, progettati intorno a criteri di sicurezza, e molto più facili da
configurare. Il principale di questi è \texttt{postfix}, che fornisce una
serie di comandi di compatibilità con \texttt{sendmail} per cui quanto diremo
riguardo ai vari comandi di gestione usati da quest'ultimo, varrà anche per il
primo.

Il file di configurazione di \texttt{sendmail} è \texttt{sendmail.cf}, che
usualmente risiede nella directory \texttt{/etc/mail}. Il file è progettato
per essere analizzato velocemente dal programma, e non da un essere umano, un
piccolo estratto del suo contenuto (preso dall'inizio dello stesso) è il
seguente: 
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
V10/Berkeley
Cwlocalhost
# file containing names of hosts for which we receive email
Fw/etc/mail/local-host-names %[^\#]
# my official domain name
#Dj$w.Foo.COM
CP.
# "Smart" relay host (may be null)
DS
# operators that cannot be in local usernames (i.e., network indicators)
CO @ % !
# a class with just dot (for identifying canonical names)
C..
# a class with just a left bracket (for identifying domain literals)
C[[
# Resolve map (to check if a host exists in check_mail)
Kresolve host -a<OKR> -T<TEMP>
C{ResOk}OKR
# Hosts for which relaying is permitted ($=R)
FR-o /etc/mail/relay-domains %[^\#]
# my name for error messages
DnMAILER-DAEMON

Cwgont.earthsea.ea

#####                   REWRITING RULES
Scanonify=3
# handle null input (translate to <@> special case)
R$@                     $@ <@>
# strip group: syntax (not inside angle brackets!) and trailing semicolon
R$*                     $: $1 <@>                       mark addresses
R$* < $* > $* <@>       $: $1 < $2 > $3                 unmark <addr>
R@ $* <@>               $: @ $1                         unmark @host:...
R$* [ IPv6 : $+ ] <@>   $: $1 [ IPv6 : $2 ]             unmark IPv6 addr
R$* :: $* <@>           $: $1 :: $2                     unmark node::addr
R:include: $* <@>       $: :include: $1                 unmark :include:...
R$* : $* [ $* ]         $: $1 : $2 [ $3 ] <@>           remark if leading colon
R$* : $* <@>            $: $2                           strip colon if marked
R$* <@>                 $: $1                           unmark
R$* ;                      $1                           strip trailing semi
R$* < $+ :; > $*        $@ $2 :; <@>                    catch <list:;>
R$* < $* ; >               $1 < $2 >                    bogus bracketed semi
...
\end{Verbatim}
%$


Il file è lungo oltre il migliaio di righe.  Per questo si dice nessun vero
sistemista unix abbia mai affrontato due volte il compito di modificarlo a
mano. Per gli scopi di queste dispense l'unico parametro che vale la pena
segnalare è \texttt{DS} che permette di impostare uno \textit{smart host},
cioè un sito a cui reinviare la posta in uscita (in genere il server SMTP del
nostro provider), questo può essere fatto scrivendo una riga del tipo:
\begin{verbatim}
# "Smart" relay host (may be null)
DSsmtp.linux.it
\end{verbatim}
\noindent al posto della riga corrispondente nell'estratto appena mostrato.

Vista la complessità di \texttt{sendmail.cf} in genere esso non viene mai
gestito direttamente ma attraverso un altro file, \texttt{sendmail.mc}, che
contiene una serie di macro che (utilizzando il linguaggio M4) gli permettono
di generare un \texttt{sendmail.cf} a partire da un file più comprensibile. Un
estratto di questo file, usato per generare il \texttt{sendmail.cf} illustrato
prima, è il seguente:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
define(`_USE_ETC_MAIL_')dnl
include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
VERSIONID(`$Id: netinter.tex,v 1.11 2004/07/08 12:26:47 piccardi Exp $')
OSTYPE(`debian')dnl
DOMAIN(`debian-mta')dnl
dnl #
dnl # General defines
dnl #
dnl # SAFE_FILE_ENV: [undefined] If set, sendmail will do a chroot()
dnl #   into this directory before writing files.
dnl #   If *all* your user accounts are under /home then use that
dnl #   instead - it will prevent any writes outside of /home !
dnl #   define(`confSAFE_FILE_ENV',             `')dnl
LOCAL_CONFIG
FEATURE(`masquerade_envelope')dnl
LOCAL_CONFIG
Cwgont.earthsea.ea
FEATURE(`use_cw_file')dnl
FEATURE(`use_ct_file')dnl
FEATURE(`smrsh')dnl
dnl #
dnl # Dialup/LAN connection overrides
dnl #
include(`/etc/mail/dialup.m4')dnl
include(`/etc/mail/provider.m4')dnl
dnl #
MAILER_DEFINITIONS
MAILER(local)dnl
MAILER(smtp)dnl
LOCAL_CONFIG
## Custom configurations below (will be preserved)
\end{Verbatim}

Il file prevede una serie di direttive che
permettono di creare il rispettivo \texttt{sendmail.cf} invocando il
processore M4 con un comando del tipo:
\begin{verbatim}
m4 sendmail.mc > sendmail.cf
\end{verbatim}

Le direttive principali sono \texttt{include}, che permette di includere altri
file di macro, \texttt{define} che definisce una macro con un argomento e
\texttt{feature} che permette di abilitare ulteriori funzionalità nel
server. In corrispondenza a dette direttive saranno generate le opportune
righe nel file di configurazione. 

Ad esempio per utilizzare uno smart host (ed ottenere la corrispondente riga
in \texttt{sendmail.cf}, basterà aggiungere a \texttt{sendmail.mc} una riga
del tipo:
\begin{verbatim}
define(`SMART_HOST', `smtp.linux.it')dnl
\end{verbatim}


\subsection{La gestione del servizio}
\label{sec:sendmail_commands}

In generale un server SMTP oltre alla posta che arriva dalla rete si occupa
anche dello smistamento della posta in locale; \texttt{sendmail} inoltre è
grado di gestire anche meccanismi di trasmissione come UUCP che non prevedono
necessariamente l'uso di Internet. Per questo di solito il servizio è
indipendente (non viene cioè gestito attraverso uno dei superdemoni di
sez.~\ref{sec:net_servizi}), e viene avviato attraverso un suo apposito script
di inizializzazione in \texttt{/etc/init.d/}.

Dato che gli utenti possono avere nomi diversi, che non è bene che
\texttt{root} legga la posta,\footnote{è buona norma usare root il meno
  possibile, per questo la posta va letta sempre come utente normale. Benché
  non esistano praticamente virus via posta su GNU/Linux, qualora venissero
  fatti potrebbero fare pochi danni, se eseguiti da un utente normale.} e che
si possono creare dei nomi relativi ai servizi (come \texttt{postmaster} o
\texttt{webmaster}) che non corrispondono ad utenti reali, una delle
caratteristiche più utili supportate da qualunque server SMTP è quella
dell'\textit{aliasing}; è cioè possibile definire una serie di
\textsl{pseudonimi} (degli \textit{alias} appunto) e far si che la posta ad
essi inviata venga reindirizzata verso altri. Questo viene gestito attraverso
il file \texttt{/etc/aliases}, un cui estratto è il seguente:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
# This is the aliases file - it says who gets mail for whom.
# It was originally generated by `eximconfig', part of the exim package
# distributed with Debian, but it may edited by the mail system administrator.
# This file originally generated by eximconfig at Thu Dec  7 22:28:50 CET 2000
# See exim info section for details of the things that can be configured here.

postmaster: root
root: piccardi

daemon: root
bin: root
sys: root
sync: root
games: root
man: root
lp: root
mail: root
news: root
uucp: root
proxy: root
majordom: root
postgres: root
www-data: root
backup: root
msql: root
operator: root
list: root
irc: root
gnats: root
nobody: root
\end{Verbatim}

Nel file si mantengono le corrispondenze fra un alias (indicato in prima
colonna e terminato da un \texttt{:}) e l'utente cui si vuole la posta ad esso
inviata arrivi. Si noti che l'alias può indicare sia il nome di un utente
realmente esistente sulla macchina, come \texttt{root}, di cui si vuole girare
la posta ad un altro, o di utenti fittizi, come \texttt{postmaster}. Si noti
anche come è possibile usare il sequenza gli alias (nel caso si redirige
\texttt{postmaster} su \texttt{root} e quest'ultimo su \texttt{piccardi}).

Se un utente desidera essere contattato via posta con altri nomi oltre al suo
username, questo è il file in cui inserire questi nuovi alias, così ad esempio
per ricevere la posta come \texttt{simone.piccardi} o \texttt{spiccardi} si
potranno aggiungere ad \texttt{/etc/alias} le righe:
\begin{verbatim}
spiccardi: piccardi
simone.piccardi: piccardi
\end{verbatim}

Una volta che si sia modificato il file degli alias occorre notificare a
\texttt{sendmail} che esso è cambiato, questo può essere fatto con il comando
\texttt{newaliases}. Oltre agli alias, che come si vede devono essere gestiti
dall'amministratore, i singoli utenti hanno la possibilità di redirigere la
propria posta verso un altro indirizzo scrivendo quest'ultimo dentro un file
\texttt{.forward} da porre nella loro home directory. In questo modo il
server, all'atto di recapitare la posta all'utente, la reinvierà
automaticamente all'indirizzo specificato.

Un altro comando usato per la gestione della posta è \texttt{mailq}, che
mostra la coda dei messaggi in attesa di spedizione. Questo comando, come il
precedente \texttt{newaliases}, non è altro che un link simbolico al programma
\texttt{sendmail}; quest'ultimo, se invocato direttamente permette di inviare
delle istruzioni al server.\footnote{questo è vero nel caso si usi lo stesso
  \texttt{sendmail} come server; nel caso di \texttt{postfix} invece il
  servizio è gestito da un altro demone, ma viene comunque fornito il comando
  \texttt{sendmail} per compatibilità.} I due comandi sono equivalenti
rispettivamente a \texttt{sendmail -I} e \texttt{sendmail -bp}.


\section{La configurazione base di Apache}
\label{sec:net_apache}

Apache è il web server più diffuso su Internet. Deve la sua popolarità alle
ottime prestazioni, alla stabilità ed alla flessibilità che gli consente di
utilizzare, grazie ad una architettura modulare, una grande quantità di
estensioni e supporto per l'utilizzo di una grande varietà di linguaggi di
scripting.


\subsection{La gestione del servizio}
\label{sec:net_apache_management}

Di norma per non penalizzarne le prestazioni, Apache viene lanciato
direttamente, e non si ricorre ad \texttt{inetd}. Qualora lo si voglia fare
comunque si deve avere cura di impostare correttamente la direttiva
\texttt{ServerType}, che di norma è \texttt{standalone}, ad \texttt{inetd}
(vedi sez.~\ref{sec:net_apache_conf}), provvedendo poi ad aggiungere la riga
opportuna a \texttt{inetd.conf}.

La situazione normale comunque prevede l'utilizzo di un opportuno script di
avvio (in Debian lo script è \texttt{/etc/init.d/apache}) che prende gli
usuali parametri utilizzati dal sistema di inizializzazione di System V. Il
programma può comunque anche essere eseguito direttamente (a seconda delle
distribuzioni lo si può lanciare con \texttt{httpd} o direttamente come
\texttt{apache}); le principali opzioni sono \texttt{-t}, che esegue un
controllo sulla sintassi della configurazione controllando la \textit{document
  root} mentre \texttt{-T} non esegue questo controllo, \texttt{-S} che mostra
la scansione dei virtual host, \texttt{-f} che permette di indicare un file di
configurazione alternativo.

Il pacchetto di Apache inoltre prevede anche l'utilizzo di un programma di
controllo apposito, \texttt{apachectl}, che permette di gestire, a server
avviato, le varie operazioni. In genere il comando si usa per avviare e
fermare il server ma rispetto all'invocazione diretta fornisce alcune
funzionalità ulteriori, permettendo ad esempio di riavviare il server
completando le connessioni sospese o controllando preventivamente la
configurazione. L'elenco delle opzioni si ottiene con direttamente con
\texttt{apachectl help} è il relativo significato è riportato in
tab.~\ref{tab:net_apachectl_command}.

\begin{table}[htb]
  \centering
  \footnotesize
  \begin{tabular}{|l|p{8cm}|}
    \hline
    \textbf{Comando}&\textbf{Effetto}\\
    \hline
    \hline
    \texttt{start}     & Avvia il servizio.\\
    \texttt{stop}      & Ferma il servizio.\\
    \texttt{restart}   & Avvia il servizio se non attivo, altrimenti causa la
                         rilettura della configurazione con l'invio di un
                         \texttt{SIGHUP}. \\ 
    \texttt{status}    & Stampa un breve rapporto sullo stato del
                         server. Richiede la presenza del browser testuale
                         \texttt{lynx} e l'attivazione di
                         \texttt{mod\_status}.\\ 
    \texttt{fullstatus}& Stampa un rapporto più esteso sullo stato del
                         server. Richiede la presenza del browser testuale
                         \texttt{lynx} e l'attivazione di
                         \texttt{mod\_status}. \\
    \texttt{graceful}  & Riavvia il servizio attendendo la conclusione di
                         tutte le connessioni pendenti.\\
    \texttt{configtest}& Esegue un controllo della configurazione. Si tenga
                         conto che viene solo controllata la sintassi. \\
    \hline
  \end{tabular}
\caption{Valori dei comandi di controllo disponibili con \texttt{apachectl}.}
\label{tab:net_apachectl_command}
\end{table}


\subsection{La configurazione}
\label{sec:net_apache_conf}

In origine i file di configurazione di Apache erano tre:
\texttt{httpd.conf} per la configurazione del server,
\texttt{access.conf} per la gestione degli accessi e \texttt{srm.conf}
per la gestione dei tipi di file e documenti. Le ultime versioni fanno
riferimento ad un unico file di configurazione \texttt{httpd.conf},
dal quale è comunque possibile includere altri file con la direttiva
\texttt{Include}.

Un primo estratto del file di configurazione, in cui si sono eliminati i
commenti e riportati solo le direttive iniziali, è il seguente:
\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
ServerType standalone
ServerRoot /etc/apache
LockFile /var/lock/apache.lock
PidFile /var/run/apache.pid
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
...
ServerAdmin webmaster@gont.earthsea.ea
#ServerName new.host.name
DocumentRoot /var/www
\end{Verbatim}

La direttiva \texttt{ServerType} permette di specificare la modalità di
esecuzione del server (se diretta, come nel caso o attraverso \texttt{inetd}).
La direttiva \texttt{ServerRoot} indica la radice in cui vengono controllati i
file di configurazione e tutti i file indicati con pathname relativi; dato che
questa è su \texttt{/etc} le due direttive successive indicano delle locazioni
più opportune dove salvare il file di lock ed il PID del processo.

In genere seguono poi una serie di direttive che riguardano le modalità di
funzionamento del server, che vanno al di là di quanto si possa affrontare in
questa sede, le altre direttive rilevanti sono \texttt{ServerAdmin} che
definisce l'indirizzo di posta del gestore del servizio, \texttt{ServerName}
che indica l'hostname del server, da usarsi per inviare ai client un valore
diverso rispetto all'hostname della macchina, ad esempio per usare un nome che
inizi con \texttt{www.} invece di quello effettivo. Infine con
\texttt{DocumentRoot} si specifica la directory radice delle pagine web, cioè
la directory in cui dovranno trovarsi i file che compaiono nella URL dopo
l'indirizzo del server.



\section{Il protocollo NIS}
\label{sec:net_NIS}

Il protocollo NIS (\textit{Network Information Service}) è un protocollo per
la gestione centralizzata delle informazioni di autenticazione, creato da Sun
come complemento a NFS per permettere di gestire centralmente attraverso la
rete non solo i filesystem, ma anche utenti, gruppi, password. Il protocollo
consente anche la creazione di domini NIS, cioè gruppi di macchine che fanno
riferimento ad uno stesso server con amministrazione centralizzata.

In presenza di un server NIS cioè, una macchina su cui sia stato installato il
relativo client, potrà autenticarsi contro il server centrale. Così l'utente
avrà lo stesso username e la stessa password su tutte le macchine, userà lo
stesso UID ed sarà associato agli stessi gruppi per tutte le macchine
all'interno del dominio.  Basterà quindi tenere aggiornata l'informazione sul
server per averla coerentemente distribuita su tutti i client.

Il servizio pertanto può essere, in una rete locale con molte macchine, di
grande utilità; inoltre permette di risolvere in maniera trasparente i
problemi (si ricordi quanto detto alla fine di sez.~\ref{sec:net_NFS_client})
che si presentano con NFS. Il può però è d'obbligo, in quanto il protocollo
presenta un difetto fondamentale, e cioè che tutta l'informazione viene
trasmessa in chiaro sulla rete e chiunque può pertanto leggersi le password
degli utenti. Per questo motivo al giorno d'oggi l'uso di NFS è in continuo
declino, soprattutto per la presenza di alternative come LDAP che non
presentano questo problema e che sono in grado di fornire supporto per la
centralizzazione di informazioni generiche e non solo per quelle di
autenticazione.



\section{Il protocollo LDAP}
\label{sec:net_LDAP}

LDAP è l'acronimo di \textit{Lightweight Directory Access Protocol}; si tratta
di un protocollo che permette di accedere ad un servizio di
\textsl{elenco}\footnote{non ho trovato una traduzione migliore del termine
  \textit{directory} in questo contesto.} in versione elettronica, analogo a
quello che potrebbe essere un elenco telefonico, ma generalizzato nei
contenuti.

I servizi di \textsl{elenco} sono stati standardizzati a livello
internazionale nello standard X.500, che prevede sia un modello di dati che un
protocollo di accesso (il DAP, da \textit{Directory Access Protocol}). LDAP
parte dal modello di dati di X.500 ma implementa un protocollo di accesso
semplificato basato su TCP/IP, che è stato standardizzato
dall'\href{http://www.ietf.org/rfc/rfc2251.txt}{RFC~2251}.

Un elenco è abbastanza simile ad un database; le informazioni sono però
memorizzate in forma descrittiva, ed associate a specifici attributi che sono
organizzati ad albero, a partire da una radice (di formato standardizzato) che
identifica ogni elenco.  L'albero è costruito su una serie di classi (che sono
a loro volta voci all'interno dell'elenco) al cui interno è possibile inserire
ulteriori dati.  Il protocollo permette in questa maniera di suddividere le
informazioni in maniera gerarchica, ed eventualmente di tenerle separate su
diversi alberi, che in generale possono stare su server diversi, gestendo in
maniera naturale la distribuzione dei dati.

Infine un elenco LDAP è ottimizzato per fornire risposte rapide in lettura,
può essere facilmente replicato, e supporta la distribuzione del carico.  Per
questo il protocollo, contrariamente a quanto è richiesto per i database,
considera come accettabili delle inconsistenze temporanee nelle informazioni.

Uno degli usi più interessanti di LDAP è quello che permette di sostituire
l'elenco degli utenti e gruppi di un computer, al posto dei classici file
\texttt{/etc/passwd} e \texttt{/etc/groups}; essendo il protocollo trasparente
alla rete questo può essere immediatamente esteso ad un gruppo di macchine
diverse, diventando una alternativa praticabile al posto di NIS, quando si
debba gestire un sistema di autenticazione centralizzata di uno stesso gruppo
di utenti su macchine diverse.

Rispetto a NIS infatti LDAP presenta numerosi vantaggi: anzitutto
l'informazione mantenuta nel database può essere utilizzata anche per altri
scopi (come per la gestione degli account di posta o di altre informazioni
generali), inoltre LDAP permette un controllo di accesso alle varie
informazioni memorizzate nell'elenco molto più dettagliato attraverso l'uso di
\textit{access list}, ed infine supporta la replicazione e la ridondanza, ed è
pertanto in grado di rispondere ad esigenze di resistenza agli incidenti.

Il vantaggio più importante rispetto a NIS però è quello della sicurezza: LDAP
può essere utilizzato attraverso TSL/SSL, consentendo la trasmissione cifrata
dei dati, la autenticazione di client e server, e la verifica dell'integrità
dei dati.



%\end{document}

\fi

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "corso"
%%% End: 

% LocalWords:  Bind bind named conf configuration forwarders cache db root type
% LocalWords:  definitions domain primary localhost local earthsea ea pathname
% LocalWords:  DNS resource secondary hint path list options tab firewall eth
% LocalWords:  kernel iptables ipchains ipfwadmin router gateway forwarding sez
% LocalWords:  routing masquerading MASQUERADE FORWARD INVALID Packet Filtering
% LocalWords:  HOWTO stateful netfilter forward MASQ syn DENY news UUCP SMTP cf
% LocalWords:  sendmail Simple Protocol RedHat postfix Cwlocalhost containing
% LocalWords:  names of hosts for which we receive official name Smart relay to
% LocalWords:  host may null operators that cannot usernames indicators class
% LocalWords:  with just dot identifying canonical left bracket literals map if
% LocalWords:  Resolve exists relaying is permitted error messages DAEMON RULES
% LocalWords:  REWRITING handle translate group syntax not inside angle and IPv
% LocalWords:  brackets trailing semicolon mark addresses unmark addr remark DS
% LocalWords:  leading marked bogus bracketed smart define dnl VERSIONID tex it
% LocalWords:  netinter Exp OSTYPE General defines SAFE ENV undefined will into
% LocalWords:  chroot this before writing files all your accounts under home at
% LocalWords:  then instead prevent any writes outside CONFIG FEATURE Dialup lp
% LocalWords:  masquerade connection overrides MAILER smtp Custom below feature
% LocalWords:  configurations preserved superdemoni postmaster webmaster dell'
% LocalWords:  aliasing the aliases says who gets whom was originally generated
% LocalWords:  part exim package distributed but edited system administrator my
% LocalWords:  eximconfig Thu Dec CET See info section details things can here
% LocalWords:  configured daemon bin sys sync games uucp proxy majordom msql bp
% LocalWords:  postgres irc gnats nobody username spiccardi newaliases mailq Di
% LocalWords:  scripting inetd ServerType standalone httpd document virtual mod
% LocalWords:  apachectl restart SIGHUP lynx fullstatus graceful configtest srm
% LocalWords:  access ServerRoot LockFile PidFile KeepAlive KeepAliveTimeout
% LocalWords:  MaxKeepAliveRequests ServerAdmin ServerName DocumentRoot lock
% LocalWords:  PID l'hostname client all'hostname URL NIS Information Service
% LocalWords:  Sun NFS filesystem UID LDAP Lightweight DAP TCP dall' RFC TSL
% LocalWords:  SSL
