rpc.mountd - Proglinux

Transcript

NFS con i sistemi GNU/Linux
program vers proto
100000
2
tcp
100000
2
udp
100024
1
udp
100024
1
tcp
100003
2
udp
100003
3
udp
100021
1
udp
100021
3
udp
100021
4
udp
100005
1
udp
100005
1
tcp
100005
2
udp
100005
2
tcp
100005
3
udp
100005
3
tcp
port
111
111
54407
38826
2049
2049
54411
54411
54411
54412
38827
54412
38827
54412
38827
1485
portmapper
portmapper
status
status
nfs
nfs
nlockmgr
nlockmgr
nlockmgr
mountd
mountd
mountd
mountd
mountd
mountd
Nello stesso modo, si può analizzare l’albero dei processi:
$ pstree[ Invio ]
init-+-...
...
|-lockd---rpciod
...
|-8*[nfsd]
...
|-portmap---portmap
...
|-rpc.mountd
|-rpc.statd
...
‘rpc.mountd’ è il demone che si occupa di gestire il montaggio del file system di rete dal lato
del servente:
rpc.mountd
[opzioni]
Generalmente, viene avviato dalla procedura di inizializzazione del sistema, in modo autonomo,
cioè indipendente dal supervisore dei servizi di rete. Mantiene aggiornato il file ‘/var/lib/
nfs/rmtab’ che elenca i montaggi in essere. Tuttavia, non è garantito che il contenuto di questo file sia esatto, per cui non lo si può utilizzare per determinare con certezza quali siano le
connessioni in corso.
‘rpc.nfsd’ è il demone che si occupa di gestire le richieste, da parte dei clienti, per i servizi
NFS, avvalendosi in pratica delle funzionalità del kernel Linux.
rpc.nfsd
[opzioni]
Deve essere in funzione nel servente. Viene avviato generalmente dalla procedura di inizializzazione del sistema, subito dopo ‘rpc.mountd’. Anche ‘rpc.nfsd’ funziona in modo autonomo
rispetto al supervisore dei servizi di rete.
Il demone ‘rpc.lockd’ si occupa di avviare la gestione del sistema di file di lock NFS, noto
come NLM, ovvero NFS lock manager:
rpc.lockd
In generale, con i kernel Linux recenti non dovrebbe essere necessaria la presenza di questo
programma; tuttavia, anche se così fosse, il suo avvio non provoca inconvenienti.
Il demone ‘rpc.statd’ serve al sistema di file di lock NFS per aggiornare la situazione quando
un elaboratore cliente viene riavviato o comunque si blocca:
rpc.statd
[opzioni]
1486
La configurazione del servizio avviene principalmente attraverso il file ‘/etc/exports’, il quale
contiene l’indicazione delle porzioni di file system locale da concedere in condivisione. Se il file
manca o è vuoto, non viene concesso l’utilizzo di alcuna parte del file system locale all’esterno.
Si tratta di un file di testo normale, in cui vengono ignorate le righe vuote, quelle bianche e quelle
che iniziano con il simbolo ‘#’; per il resto, le righe sono intese come dei record, ognuno dei quali
è composto da:
• l’indicazione di una directory a partire dalla quale si concede la condivisione;
• una serie di nodi o reti cui viene concesso l’utilizzo di questa directory con l’eventuale
specificazione di opzioni di accesso.
In pratica si utilizza la sintassi seguente:
directory_di_partenza
[host][(opzioni )]...
La configurazione di questo file potrebbe non dare sempre gli effetti previsti, a causa di difetti che possono essere presenti nei demoni che si occupano della gestione del servizio. In
generale, si è cercato sempre di garantire la sicurezza, a discapito della funzionalità. Se una
configurazione di ‘/etc/exports’ sembra non funzionare senza un motivo apparente, è bene provarne altre, limitando l’uso di opzioni particolari, o cercando di identificare meglio gli
elaboratori a cui si concede l’accesso. Eventualmente, si veda anche la pagina di manuale
exports(5).
Gli elaboratori a cui si concede l’accesso alla directory condivisa possono essere specificati in
vari modi, alcuni dei quali sono elencati di seguito:
• indicazione di un nodo singolo
quando si utilizza un nome o un indirizzo IP che fa riferimento da un elaboratore specifico;
• uso di caratteri jolly
possono essere utilizzati i caratteri jolly ‘*’ e ‘?’ per indicare un gruppo di nomi di elaboratore con una sola notazione, tenendo presente che questi simboli non possono sostituirsi
ai punti di un nome di dominio;
• rete IP
attraverso la notazione ‘indirizzo_ip /maschera_di_rete ’ è possibile indicare simultaneamente
tutti gli elaboratori collocati all’interno della rete o della sottorete a cui si fa riferimento.
Le opzioni tra parentesi tonde sono parole chiave particolari. Segue la descrizione di alcune di
queste:
•
ro
Consente l’accesso in sola lettura. Questa è la modalità di funzionamento predefinita.
•
rw
Consente l’accesso in lettura e scrittura.
•
insecure_lock
| no_auth_nlm
Questa opzione consente di usare un sistema di file di lock meno rigido, quando alcuni
elaboratori clienti mostrano difficoltà in questo senso.
•
1487
root_squash
Si tratta di un’opzione di sicurezza, di solito predefinita, attraverso la quale si impedisce
l’accesso come utente ‘root’. In pratica, quando un utente ‘root’ presso un elaboratore
cliente utilizza il file system condiviso, viene trattato come utente ‘nobody’.2
•
all_squash
La presenza di questa opzione fa sì che tutti gli accessi al file system condiviso, avvengano
con i privilegi dell’utente ‘nobody’.
no_root_squash
Non effettua la trasformazione dell’UID ‘root’ e ciò è necessario quando si utilizzano
clienti NFS senza disco fisso.
L’elenco seguente mostra alcuni esempi di record di questo file.
/usr *.brot.dg(ro)
/ roggen.brot.dg(ro,root_squash)
/home roggen.brot.dg(rw) weizen.mehl.dg(rw)
/
*(rw,no_root_squash)
Concede ai nodi del dominio
brot.dg l’accesso in lettura alla
directory ‘/usr/’ e seguenti.
Concede a roggen.brot.dg di accedere in sola lettura a partire dalla directory radice, escludendo i privilegi
dell’utente ‘root’.
Concede a roggen.brot.dg e
a weizen.mehl.dg di accedere
in lettura e scrittura alla directory
‘/home/’.
Questa definizione non dovrebbe funzionare più. Sembrerebbe voler concedere a tutta la rete di accedere in
lettura e scrittura a partire dalla directory radice, permettendo ai vari utenti ‘root’ di mantenere i loro privilegi. Tuttavia l’asterisco non dovrebbe riuscire a rimpiazzare i punti che
compongono i nomi di dominio, risolvendosi così in una directory che in
pratica non viene condivisa.
Quando si modifica il file ‘/etc/exports’, per garantire che queste siano prese in considerazione dal sistema di condivisione del file system, è necessario utilizzare il programma ‘exportfs’
nel modo seguente:
# exports -ra
Il programma ‘exportfs’ può anche essere usato per esportare al volo una directory, senza modificare il file ‘/etc/exports’. In generale, si tratta di una pratica non consigliabile,
ma della quale bisogna tenere conto. Eventualmente si può consultare la pagina di manuale
exportfs(8).
Infine, bisogna considerare che alcuni dei demoni che abilitano il servizio NFS potrebbero essere
stati compilati in modo da utilizzare i file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’ per
controllare l’accesso. L’elenco seguente mostra in che modo abilitare o disabilitare l’accesso
2
L’utente ‘nobody’ corrisponde spesso al numero UID 65534 o -2. Tuttavia, questo utente non ha un numero UID
standard, tanto che in alcuni sistemi si preferisce utilizzare un numero più basso di quelli assegnati agli utenti comuni.
1488
in modo selettivo per ogni demone coinvolto, tenendo conto che anche il Portmapper potrebbe
dipendere da questi file:
Demone
Portmapper
‘rpc.mountd’
‘rpc.nfsd’
‘rpc.lockd’
‘rpc.statd’
‘rpc.rquotad’
‘/etc/hosts.allow’
‘/etc/hosts.deny’
portmap: specifica_dei_nodi
mountd: specifica_dei_nodi
nfsd: specifica_dei_nodi
lockd: specifica_dei_nodi
statd: specifica_dei_nodi
rquotad: specifica_dei_nodi
È molto probabile che molti di questi demoni siano insensibili al contenuto dei file ‘/etc/
hosts.allow’ e ‘/etc/hosts.deny’; tuttavia, se nel proprio sistema si utilizzano questi file, è
meglio scrivere una riga di più in questi file, anche se inutile, piuttosto che dimenticarsene e avere
problemi in seguito. Pertanto, per abilitare l’accesso a tutti questi demoni, converrà utilizzare le
direttive seguenti nel file ‘/etc/hosts.allow’:
Per converso, può essere conveniente inserire le righe seguenti nel file ‘/etc/hosts.deny’, allo
scopo di escludere gli accessi che non provengano dai nodi autorizzati espressamente:
portmap: ALL
mountd: ALL
nfsd: ALL
lockd: ALL
statd: ALL
rquotad: ALL
Naturalmente, per una sicurezza maggiore, può essere conveniente inserire soltanto la direttiva
seguente nel file ‘/etc/hosts.deny’:
ALL: ALL
137.3 Verifica del servizio
Quando il servizio NFS è attivo, si può verificare il funzionamento e l’utilizzo di questo con il
programma ‘showmount’:
showmount
[opzioni] [host]
Se non si indica un nodo, viene interrogato il servizio NFS presso l’elaboratore locale.
Segue la descrizione di alcune opzioni:
-a
| --all
-e
| --exports
elenca i clienti che utilizzano il proprio servizio e anche le
directory che questi hanno montato;
elenca le directory esportate dal servente locale o dal servente
remoto (se indicato come ultimo argomento del comando).
Quando si interroga la situazione dell’utilizzo in corso, le informazioni vengono tratte dal file
‘/var/lib/xtab’, che però potrebbe mostrare l’utilizzo attuale di directory che in realtà non lo
sono più.
1489
137.4 Porte coinvolte
Il servizio NFS si avvale per il suo funzionamento del Portmapper e di altri demoni specifici. In
alcuni casi, questi demoni comunicano utilizzando porte TCP o UDP definite in modo dinamico,
pubblicizzate poi dal Portmapper stesso. I punti di riferimento costanti sono solo quelli seguenti:
Porta TCP o UDP
111
2049
Demone
Portmapper
‘rpc.nfsd’
137.5 Dal lato del cliente
Con i sistemi GNU/Linux, l’utilizzo di un file system di rete richiede solo che il kernel sia stato
predisposto per questo. Non occorrono programmi demone, basta il normalissimo ‘mount’.
Per montare un file system di rete si interviene in modo analogo a quello di una unità di memorizzazione locale, con la differenza fondamentale del modo di esprimere il dispositivo virtuale
corrispondente al file system remoto da connettere.
host_remoto :directory_remota
La notazione sopra riportata rappresenta la porzione di file system remoto cui si vuole accedere,
attraverso l’indicazione simultanea dell’elaboratore e della directory di partenza.
Supponendo che l’elaboratore dinkel.brot.dg conceda l’utilizzo della directory ‘/usr/’
e successive, l’elaboratore roggen.brot.dg potrebbe sfruttarne l’occasione attraverso il
programma ‘mount’ nel modo seguente:
mount -t nfs dinkel.brot.dg:/usr /usr
Inoltre, nell’elaboratore roggen.brot.dg si potrebbe aggiungere una riga nel file ‘/etc/
fstab’ in modo da automatizzarne la connessione (68.3.6).
dinkel.brot.dg:/usr
/usr
nfs
defaults
0
0
Sia attraverso il programma ‘mount’ (preceduti dall’opzione ‘-o’), che nel file ‘/etc/fstab’
(nel campo delle opzioni) possono essere specificate delle opzioni particolari riferite a questo
tipo di file system. L’elenco seguente mostra solo alcune di queste opzioni, che possono avere
rilevanza quando si monta un file system di rete.
rsize=n
wsize=n
timeo=n
hard
Permette di specificare la dimensione dei pacchetti utilizzati
in lettura da parte del cliente NFS. Il valore predefinito è di
1024 byte.
Permette di specificare la dimensione dei pacchetti utilizzati
in scrittura da parte del cliente NFS. Il valore predefinito è di
1024 byte.
Permette di definire il valore del timeout, espresso in decimi
di secondo, per il completamento delle richieste. In pratica, se
entro quel tempo non si ottiene una conferma, si verifica un
minor timeout e l’operazione viene ritentata con una durata di
timeout doppia. Quando si raggiunge un timeout massimo di
60 secondi si verifica un major timeout. Il valore predefinito
è sette, corrispondente a 0,7 secondi.
Stabilisce che la connessione deve essere ritentata all’infinito,
anche dopo un major timeout. È la modalità di funzionamento
predefinita.
1490
Stabilisce che venga generato un errore di I/O non appena si
verifica un major timeout. Questa modalità si contrappone a
quella ‘hard’.
Permette l’interruzione di una chiamata NFS attraverso l’uso
di segnali. Può essere utile per interrompere una connessione
quando il servente non risponde.
Evita di prendere in considerazione i permessi di tipo SUID e
SGID dei file eseguibili.
soft
intr
nosuid
In condizioni normali, conviene usare solo le opzioni ‘rw’, ‘hard’ e ‘intr’, come nell’esempio
seguente che rappresenta sempre una direttiva del file ‘/etc/fstab’:
dinkel.brot.dg:/home
/home
nfs
rw,hard,intr
0
0
Per motivi di sicurezza, può essere utile anche l’opzione ‘nosuid’, se si teme che un programma
compromesso, presente nel file system remoto, possa acquisire privilegi particolare e intaccare
l’elaboratore locale dal quale lo si avvia.
137.6 Riferimenti
• Tavis Barr, Nicolai Langfeldt, Seth Vidal, NFS HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org
Capitolo
138
NIS
Il NIS, 1 2 3 o Network information service, è un sistema di gestione di dati amministrativi
concentrati in una sola fonte, rendendoli disponibili a tutta una rete in modo uniforme.
Questo tipo di servizio è stato ideato e sviluppato originariamente dalla Sun Microsystems denominandolo Yellow pages (YP), ma successivamente il nome è stato cambiato perché questo
era già un marchio registrato in Gran Bretagna della società telefonica British Telecom. Questa
storia di NIS serve a spiegare il motivo per il quale molti programmi di servizio che riguardano
questa gestione hanno il prefisso ‘yp’, oltre al fatto che spesso si parli di «servizi YP» invece che
di «servizi NIS».
Il NIS è un meccanismo che si sovrappone alla gestione amministrativa di un sistema Unix tipico, ma questo avviene in un modo non perfettamente integrato. Quando si introduce il NIS, si
inserisce un livello di intermediazione tra l’utente e il sistema di amministratore preesistente.
138.1 Concentrazione amministrativa del NIS versione 2
Lo scopo del NIS è quello di concentrare in un solo elaboratore la gestione di una serie di file
amministrativi. La tabella 138.1 elenca alcuni file di configurazione, tipici di un sistema Unix,
che possono essere gestiti in questo modo.
Tabella 138.1. Elenco di alcuni dei file amministrativi gestibili comunemente attraverso
il NIS.
File
‘/etc/passwd’
‘/etc/group’
‘/etc/shadow’
‘/etc/aliases’
‘/etc/hosts’
‘/etc/networks’
‘/etc/protocols’
‘/etc/rpc’
‘/etc/services’
Descrizione
Informazioni sugli utenti.
Gruppi di utenti.
password shadow (quando gestibili).
Alias di posta elettronica.
Traduzione degli indirizzi IP dei nodi della rete locale.
Traduzione degli indirizzi IP delle sottoreti (locali).
Nomi e numeri dei protocolli di rete.
Numeri delle chiamate RPC.
Abbinamento dei servizi di rete ai numeri di porta
corrispondenti.
È bene chiarire subito che il supporto alle password shadow non è disponibile in tutti i NIS
esistenti; inoltre, il protocollo NIS (fino alla versione 2) rende difficile il loro utilizzo in modo
«sicuro», nel senso di mantenere effettivamente nascoste le stringhe cifrate corrispondenti alle
parole d’ordine di accesso degli utenti.
La concentrazione amministrativa si attua facendo in modo che le informazioni dei file che interessano siano gestite a partire da un solo nodo. Generalmente, l’utilità del NIS sta nella possibilità
di amministrare gli utenti da un’unica origine, facendo in modo che questi vengano riconosciuti
in tutti gli elaboratori di un certo «dominio», senza dover essere inseriti effettivamente in ognuno
di questi.
1
YP Server GNU GPL
YP Bind-mt GNU GPL
3
YP Tools GNU GPL
2
1491
NIS
1492
Gli esempi che si faranno in questo capitolo sono volti principalmente al raggiungimento di
questo risultato, concentrando così l’amministrazione dei file ‘/etc/passwd’, ‘/etc/group’ e
‘/etc/shadow’.
138.1.1 Mappe NIS
Il NIS non utilizza i file amministrativi così come sono, ne crea una copia; queste copie sono
denominate «mappe». I file di mappa sono in formato DBM, dove si memorizzano solo coppie di
dati: chiave-valore. Per questo motivo, a seconda della struttura dei file amministrativi originali,
si possono generare più mappe differenti.
Quando si attiva il NIS, non si possono più utilizzare i vecchi comandi amministrativi (come
‘passwd’, ‘chsh’, ecc.), o quantomeno non conviene, perché il NIS non si accorge (autonomamente) dei cambiamenti apportati ai file amministrativi tradizionali. Bisogna utilizzare i comandi
specifici del NIS, in modo che i cambiamenti siano annotati immediatamente nelle mappe e poi
siano propagati nei file amministrativi normali del servente NIS.
La tabella 138.2 riporta l’elenco di alcune delle mappe tipiche della gestione NIS. La collocazione di questi file dipende dal dominio NIS, descritto nella sezione seguente, e corrisponde in
pratica a ‘/var/yp/dominio_nis /’.
Tabella 138.2. Elenco di alcune mappe NIS.
Mappa
‘passwd.byname’
‘passwd.byuid’
‘group.byname’
‘group.bygid’
‘shadow.byname’
‘mail.aliases’
‘hosts.byname’
‘hosts.byaddr’
‘networks.byname’
‘networks.byaddr’
‘protocols.byname’
‘protocols.bynumber’
‘rpc.byname’
‘rpc.bynumber’
‘services.byname’
Descrizione
Utenti per nome.
Utenti per numero UID.
Gruppi per nome.
Gruppi per numero GID.
Utenti per nome (dal file ‘/etc/shadow’).
Alias di posta elettronica.
Nodi per nome.
Nodi per indirizzo.
Reti locali per nome.
Reti locali per indirizzo.
Protocolli di rete per nome.
Protocolli di rete per numero.
Chiamate RPC per nome.
Chiamate RPC per numero.
Servizi di rete per nome.
138.1.2 Dominio NIS
Quando si attiva un servizio NIS in un nodo, in modo che questo renda disponibili le informazioni
relative a un gruppo di elaboratori, si deve definire un dominio NIS corrispondente. Questo non
ha niente a che fare con i domini utilizzati dal servizio DNS, ma generalmente, anche se potrebbe
sovrapporsi perfettamente a un dominio di questo tipo, conviene utilizzare nomi distinti, che non
abbiano un nesso logico o intuitivo.
Più precisamente, è meglio dire che si stabilisce prima l’estensione del dominio NIS che si vuole
creare, quindi si deve «eleggere» il nodo più adatto a fungere da servente NIS. Infatti, questo
elaboratore deve trovarsi in una posizione adatta nella rete, in modo che sia accessibile facilmente
da tutti gli elaboratori del dominio NIS. Oltre a questo è bene che si tratti di una macchina
adeguata all’estensione del dominio: maggiore è il numero di clienti, maggiore sarà la frequenza
con cui dovrà rispondere a richieste del protocollo NIS.
NIS
1493
I file di mappa di un servente NIS sono raggruppati distintamente per dominio, nella directory
‘/var/yp/dominio_nis /’.
138.1.3 Servente principale e serventi secondari
Finora si è fatto riferimento a un servente NIS unico per tutto il suo dominio di competenza.
Quando si attiva un servizio di questo tipo, tutti gli elaboratori clienti di questo dominio dipendono completamente dal servente per tutte quelle informazioni che sono state concentrate sotto
la sua amministrazione. Se l’elaboratore che offre questo servizio dovesse venire a mancare per
qualsiasi motivo, come un guasto, tutti i suoi clienti sarebbero in grave difficoltà.
Per risolvere il problema, si possono predisporre dei serventi NIS secondari, o slave, che
riproducono le informazioni del servente principale, o master.
Il motivo per il quale si utilizza il servizio NIS è quello di uniformare e concentrare la gestione
di informazioni di un gran numero di elaboratori, altrimenti non sarebbe giustificato l’impegno necessario alla sua attivazione. Di conseguenza, è praticamente obbligatorio attivare dei
serventi secondari, sia per attenuare i rischi di blocco del sistema globale, sia per ridurre il
carico di richieste NIS su un’unica macchina.
La presenza di serventi secondari impone la creazione di meccanismi automatici per il loro
allineamento, generalmente attraverso il sistema Cron.
138.2 Distinzione dei ruoli tra servente e cliente
Finora è stato preso in considerazione il compito del servente NIS, senza valutare i clienti, ma
all’inizio la distinzione dei compiti può sembrare confusa.
Il cliente NIS è un programma demone che si occupa di fornire al sistema in cui è in funzione
le informazioni che altrimenti verrebbero ottenute dai soliti file di configurazione. La situazione
tipica è quella della procedura di accesso: se il nome dell’utente non viene trovato nel file ‘/etc/
passwd’ locale, il cliente NIS cerca di ottenerlo dal servente NIS.
In pratica, le funzionalità di servente e cliente sono indipendenti: ci possono essere elaboratori
che fungono da serventi, altri che utilizzano il programma cliente per accedere alle informazioni
e altri ancora che fanno entrambe le cose.
Se si pensa che il servente NIS principale deve contenere tutte le informazioni che vengono condivise dai programmi clienti presso gli altri elaboratori, potrebbe sembrare inutile l’attivazione
del programma cliente nello stesso servente. Tuttavia, le cose cambiano quando si considerano i
serventi secondari. Questi non dispongono delle informazioni che ha l’elaboratore corrispondente al servente principale; per ottenerle occorre attivare il cliente NIS in modo che si possa mettere
in comunicazione con il servente principale.
Nel sistema NIS così strutturato, i clienti cercano le informazioni, riferite al loro dominio, dal
servente che risponde più rapidamente. Ciò viene determinato generalmente attraverso una richiesta circolare (broadcast). Questo, tra le altre cose, è uno dei punti deboli del NIS: dal momento che qualunque elaboratore può rispondere a una chiamata circolare, chiunque è in grado
di intromettersi per cercare di catturare delle informazioni.
1494
NIS
138.2.1 Propagazione delle informazioni
Quando si deve intervenire per modificare qualche informazione di quelle che sono condivise attraverso il NIS, si presentano situazioni differenti a seconda delle circostanze. Queste si traducono
in modalità diverse di propagazione di queste modifiche nell’intero sistema NIS. Si distinguono
due situazioni fondamentali:
• la modifica di un’informazione nell’elaboratore di origine (il servente principale) sui dati
di partenza;
• la modifica di un’informazione attraverso gli strumenti offerti dal sistema NIS.
Nel primo caso le azioni da compiere sono:
1. aggiornare le mappe del servente principale;
2. aggiornare le mappe dei serventi secondari.
Nel secondo caso le azioni da compiere sono:
1. aggiornare i file di configurazione corrispondenti nel servente principale
2. aggiornare le mappe del servente principale
3. aggiornare le mappe dei serventi secondari
Quando si interviene manualmente sui file di configurazione di partenza del servente principale,
per esempio quando si vuole aggiungere o eliminare un utente, si deve poi comandare manualmente l’aggiornamento delle mappe NIS; eventualmente si può pilotare anche l’aggiornamento
dei serventi secondari, attraverso un cosiddetto push.
Quando si utilizzano gli strumenti offerti da NIS per modificare la configurazione dei dati condivisi, ciò può avvenire solo attraverso un cliente, il quale si occupa di contattare il servente
principale che poi deve provvedere ad aggiornare i file normali e le mappe.
La propagazione delle mappe modificate ai serventi secondari potrebbe essere un problema. Per
questo si utilizza generalmente il sistema Cron in ogni servente secondario, in modo da avviare
periodicamente il comando necessario a metterli in comunicazione con il servente principale e
verificare così la presenza di aggiornamenti eventuali.
Dalla precisione del funzionamento di questo sistema di propagazione derivano delle conseguenze pratiche che, a prima vista, possono sembrare assurde. Si può immaginare cosa può accadere
quando un utente cambia la propria parola d’ordine da un cliente NIS. Questo contatta il servente
principale che provvede ad aggiornare le mappe e il file ‘/etc/passwd’. Ma fino a che i serventi
secondari non ricevono l’aggiornamento, i clienti che li utilizzano continuano a permettere l’accesso con la parola d’ordine vecchia. Questo può capitare allo stesso elaboratore dal quale è stata
compiuta l’operazione di modifica, se questo utilizza il servizio di un servente secondario non
aggiornato. In queste condizioni, l’utente che ha appena cambiato parola d’ordine e tenta un altro
accesso sulla stessa macchina, potrebbe trovarsi spaesato di fronte al rifiuto che gli si presenta.
NIS
1495
138.3 NIS e DNS
Il NIS permette di distribuire le informazioni contenute nei file ‘/etc/hosts’ e ‘/etc/
networks’. Questi sono i file di configurazione che permettono di risolvere i nomi dei nodi
della rete locale, quando non si vuole fare uso di un DNS.
Attraverso questa possibilità è poi possibile configurare il file ‘/etc/host.conf’ dei vari clienti
NIS, in modo che venga utilizzata questa informazione. Di solito si tratta di indicare una riga
come quella seguente:
order hosts,nis
Tuttavia, nel momento stesso in cui si pensa di volere utilizzare il NIS, si decide che l’organizzazione della rete locale è un problema serio, pertanto, anche la risoluzione dei nomi della rete
deve essere considerato un problema ugualmente serio. In questo senso, diventa un controsenso
la pretesa di gestire la risoluzione dei nomi attraverso NIS, quando con poco impegno si può
attivare un servente DNS; al limite si possono unire le due cose:
order hosts,bind,nis
138.4 RPC
Il NIS utilizza le chiamate RPC per comunicare. Questo significa che è necessaria la presenza
del Portmapper in funzione sia nei nodi serventi che nei nodi clienti (si veda eventualmente il
capitolo 136).
È anche importante verificare che i servizi di sincronizzazione, time service, siano previsti nel
controllo del supervisore dei servizi di rete. Il file ‘/etc/inetd.conf’ potrebbe contenere le
righe seguenti:
#
# Time service is used for clock syncronization.
#
time
stream tcp
nowait root
internal
time
dgram
udp
wait
root
internal
In alternativa, il file ‘/etc/xinetd.conf’ potrebbe contenere invece le righe seguenti:
service time
{
socket_type
protocol
wait
user
type
id
}
service time
{
socket_type
protocol
wait
user
type
id
}
=
=
=
=
=
=
stream
tcp
no
root
INTERNAL
time-stream
=
=
=
=
=
=
dgram
udp
yes
root
INTERNAL
time-dgram
Se si devono apportare delle modifiche al file di configurazione del supervisore dei servizi di rete,
bisogna poi ricordarsi di riavviarlo (capitolo 135).
1496
NIS
138.5 Allestimento di un servente NIS versioni 1 e 2
Gli elementi indispensabili di un servente NIS sono i programmi ‘ypserv’ e ‘makedbm’. Il primo
svolge il ruolo di demone in ascolto delle richieste NIS per il dominio di competenza, il secondo
è necessario per convertire i file di configurazione normali in file DBM, cioè nelle mappe NIS.
Nel caso di un servente principale è anche opportuna la presenza di altri due demoni:
‘rpc.yppasswdd’ e ‘rpc.ypxfrd’. Il primo serve a permettere la modifica delle parole d’ordine degli utenti attraverso il sistema NIS, il secondo serve a facilitare l’aggiornamento ai serventi
secondari.
La configurazione di ‘ypserv’ e ‘rpc.ypxfrd’ può dipendere dal modo in cui sono stati compilati i sorgenti rispettivi. In generale si utilizza il file ‘/etc/ypserv.conf’ per definire il comportamento di entrambi i programmi; inoltre ‘ypserv’ può far uso di ‘/etc/ypserv.securenets’
per conoscere gli indirizzi di rete da cui può accettare interrogazioni NIS, oppure può riutilizzare
i tradizionali ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’. Per saperlo basta usare l’opzione
‘-version’, come nell’esempio seguente:
# ypserv -version[ Invio ]
ypserv - NYS YP Server version 1.1.7 (with tcp wrapper)
L’esempio mostra il risultato di un ‘ypserv’ compilato con il supporto per l’utilizzo dei file
‘/etc/hosts.allow’ e ‘/etc/hosts.deny’, gli stessi che utilizza il TCP wrapper allo scopo
di filtrare gli accessi ai programmi controllati dal supervisore dei servizi di rete.
ypserv - NYS YP Server version 1.3.12 (with securenets)
Questo esempio ulteriore riguarda invece il risultato di un ‘ypserv’ compilato con il supporto per
l’uso di ‘/etc/ypserv.securenets’ (o di un file analogo collocato in una posizione diversa
nel file system.
Prima di poter avviare il servente ‘ypserv’, oltre a provvedere per la sua configurazione,
occorre necessariamente che il Portmapper RPC sia in funzione e che il dominio NIS sia stato
definito. In assenza di una sola di queste due condizioni, il programma ‘ypserv’ non funziona,
nel senso che non si riesce ad avviarlo.
138.5.1 Dominio NIS
Il dominio NIS viene definito attraverso ‘domainname’, nel modo seguente:
domainname dominio_nis
Quando viene usato senza argomenti, si ottiene il nome del dominio NIS; in questo modo
si può controllare se l’impostazione è corretta. Per esempio, l’impostazione del dominio NIS
rost.nis-yp può essere fatta e controllata nel modo seguente:
# domainname rost.nis-yp[ Invio ]
# domainname[ Invio ]
rost.nis-yp
Mentre l’impostazione del dominio è di competenza dell’utente ‘root’, la verifica può essere
fatta anche da un utente comune.
Di solito, si può fare riferimento a questo programma anche con altri nomi:
NIS
1497
[opzioni] [dominio_nis ]
nisdomainname [opzioni] [dominio_nis ]
ypdomainname [opzioni] [dominio_nis ]
domainname
L’utilizzo tipico di ‘domainname’ è riservato agli script della procedura di inizializzazione del
sistema. Le istruzioni necessarie potrebbero essere organizzate nel modo seguente:
# Set the NIS domain name
if [ -n "$NISDOMAIN" ]
then
domainname $NISDOMAIN
else
domainname ""
fi
Oppure in modo alternativo anche come segue, dove il nome del dominio è contenuto in un
file. In tal caso, bisogna fare attenzione al fatto che il file in questione deve essere composto
esclusivamente da una riga, altrimenti viene presa in considerazione solo l’ultima, ma se questa
è vuota, il dominio non viene definito.
# Set the NIS domain name
if [ -f "/etc/nisdomain" ]
then
domainname -F /etc/nisdomain
else
domainname ""
fi
138.5.2 Avvio del servente
In condizioni normali, ‘ypserv’ non richiede l’uso di argomenti particolari, al massimo
si tratta di controllare il file di configurazione ‘/etc/ypserv.conf’ e l’eventuale ‘/etc/
ypserv.securenets’ (prima si deve verificare con l’opzione ‘-v’ se questo file è necessario,
o se al suo posto si usano i file di configurazione del TCP wrapper). In ogni caso, è importante
che la directory ‘/var/yp/’ sia stata creata (al suo interno si dovrebbe trovare un file-make, ma
questo verrà mostrato in seguito).
# ypserv[ Invio ]
Se tutto va bene, il programma si avvia sullo sfondo e si disassocia dalla shell, diventando un
processo figlio di quello iniziale (Init).
# pstree[ Invio ]
init-+-...
|-portmap
|-...
‘-ypserv
Se il Portmapper RPC non fosse attivo, oppure se non fosse stato definito il dominio NIS, l’avvio di ‘ypserv’ non dovrebbe riuscire. Eventualmente, si può verificare il funzionamento del
Portmapper stesso, attraverso il comando seguente:
# rpcinfo -p localhost[ Invio ]
program vers proto
100000
2
tcp
100000
2
udp
port
111
111
portmapper
portmapper
NIS
1498
Le righe che si vedono dall’esempio mostrato sono la dichiarazione esplicita del funzionamento del Portmapper. Per verificare espressamente la connessione con ‘ypserv’, si può usare il
comando seguente:
# rpcinfo -u localhost ypserv[ Invio ]
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
La sintassi per l’avvio di ‘ypserv’ è molto semplice:
ypserv
[opzioni]
L’elenco seguente descrive alcune opzioni della riga di comando di ‘ypserv’ che possono essere
utili.
-d
[percorso_yp]
--debug
[percorso_yp]
-b
| --dns
-v
| --version
Utilizzando questa opzione si fa in modo che ‘ypserv’ funzioni in modalità diagnostica. Per questo, invece di passare
sullo sfondo, continua a funzionare occupando il terminale
dal quale è stato avviato, emettendo informazioni particolareggiate su ciò che avviene attraverso lo standard error. Eventualmente si può indicare un percorso come argomento dell’opzione, intendendo fare in modo che ‘ypserv’ utilizzi le
mappe contenute a partire da quella directory, invece di quelle
che si trovano a partire da ‘/var/yp/’.
Specifica che se un nodo non viene identificato diversamente,
si deve utilizzare il servizio DNS.
Visualizza i dati riferiti alla particolare versione di ‘ypserv’.
Questa indicazione è molto importante, soprattutto per sapere
quali file vengono utilizzati per controllare gli indirizzi che
possono accedere al servizio.
‘ypserv’, quando tutto è configurato correttamente, viene controllato dalla procedura di ini-
zializzazione del sistema, attraverso uno dei suoi script. L’esempio che segue rappresenta un
modo semplice per ottenere questo, dove la variabile di ambiente ‘NISDOMAIN’ viene usata per
contenere il dominio NIS; se manca questa variabile non ha senso avviare il servente NIS.
if [ -n "$NISDOMAIN" ]
then
if [ -f /usr/sbin/ypserv ]
then
/usr/sbin/ypserv
echo ypserv
fi
fi
Quello mostrato è solo uno dei tanti modi; in generale bisogna ricordare che si può avviare il
servizio NIS solo dopo aver avviato il Portmapper.
Nelle distribuzioni più accurate, è normale trovare uno script apposito che permette di avviare e
di interrompere l’attività del servente NIS, assieme a tutto quello di cui potrebbe avere bisogno.
Questo genere di script può trovarsi nelle directory ‘/etc/rc.d/init.d/’, ‘/etc/init.d/’ e
altre possibili.
NIS
1499
138.5.3 Configurazione principale
La configurazione di ‘/etc/ypserv.conf’ riguarda il funzionamento di ‘ypserv’ e
‘rpc.ypxfrd’ in ogni caso. quando si fanno dei cambiamenti a questa configurazione occorre
riavviare i demoni o inviare loro un segnale ‘SIGHUP’.
L’impostazione di questo file può essere anche molto complicata. In linea di massima ci si può
fidare della configurazione predefinita, o dei suggerimenti posti nei suoi commenti.
Il file può contenere commenti, rappresentati inizialmente dal simbolo ‘#’, righe vuote o bianche,
direttive riferite a opzioni e direttive riferite a regole di accesso. Le direttive di opzione hanno la
forma seguente, dove la parola chiave ‘yes’ attiva l’opzione, mentre ‘no’ la disattiva.
[ | ]
opzione : yes no
L’elenco seguente descrive tali opzioni.
dns :
Attivando questa opzione, si fa in modo che il servente NIS
utilizzi il DNS quando gli vengono richieste informazioni sui
nodi che non può risolvere con le mappe ‘hosts.*’. Il valore predefinito è ‘no’ e questa opzione può essere attivata anche attraverso la riga di comando, ‘--dns’, cosa che
prende il sopravvento su quanto stabilito in questo file di
configurazione.
Attivando questa opzione, il servente principale deve utilizzare una porta inferiore al numero 1024. Il valore predefinito è
‘yes’.
[yes|no]
xfr_check_port :
[yes|no]
Le direttive di accesso hanno invece il formato seguente:
[
]
host :mappa :livello_sicurezza :soppressione :campo
• host
• Si tratta di un indirizzo IP che può rappresentare un solo nodo o un gruppo. La rappresentazione può essere fatta attraverso un indirizzo IP incompleto, o la coppia indirizzo/maschera.
Un indirizzo IP incompleto rappresenta tutti gli indirizzi che iniziano in quel modo, per cui,
per esempio, «192.168.» equivale alla notazione 192.168.0.0/255.255.0.0, dove il secondo
indirizzo è la maschera.
• mappa
Il nome della mappa, oppure un asterisco per identificare tutte le mappe.
• livello_sicurezza
Il livello, o il tipo di sicurezza, viene definito attraverso una parola chiave: ‘none’, ‘port’,
‘deny’, ‘des’. Il loro significato viene descritto di seguito.
‘none’
‘port’
‘deny’
‘des’
Concede qualunque accesso.
Permette di accedere se la richiesta viene da una porta inferiore al numero 1024, ma solo se è stata specificata la
soppressione.
Vieta l’accesso alla mappa in questione.
Richiede l’autenticazione DES. Può funzionare solo se
le librerie utilizzate sono in grado di gestire questa
funzionalità.
NIS
1500
• soppressione
Può contenere solo una tra le parole chiave ‘yes’ e ‘no’. ‘yes’ attiva la soppressione del
campo specificato. La soppressione implica che al suo posto viene collocata una «x», se il
controllo della porta rivela che la richiesta proviene da un accesso non privilegiato.
• campo
Serve a specificare quale campo deve essere soppresso. Quello predefinito è il secondo.
L’esempio seguente rappresenta una configurazione predefinita di una distribuzione GNU:
# The following, when uncommented, will give you shadow like passwords.
# Note that it will not work if you have slave NIS servers in your
# network that do not run the same server as you.
#
#
#
#
#
Host
: Map
: Security
: Passwd_mangle
*
*
*
: passwd.byname
: passwd.byuid
: *
: port
: port
: none
: yes
: yes
# This is the default - restrict access to the shadow password file,
# allow access to all others.
*
: shadow.byname
: port
*
: passwd.adjunct.byname : port
*
: *
: none
138.5.4 Configurazione dei diritti di accesso
Il file ‘/var/yp/securenets’ viene usato da ‘ypserv’ per sapere quali sono gli indirizzi ammessi a eseguire interrogazioni nel sistema NIS. Bisogna ricordare che ‘ypserv’ potrebbe essere stato compilato per non usare questo file, utilizzando al suo posto ‘/etc/hosts.allow’ e
‘/etc/hosts.deny’. Questo lo si determina utilizzando l’opzione ‘-v’.
Nel caso in cui ‘ypserv’ utilizzi questo file, se manca o è vuoto, vengono consentiti tutti gli
accessi in modo indiscriminato. Ogni volta che si modifica il file è necessario riavviare ‘ypserv’,
oppure gli si deve inviare un segnale ‘SIGHUP’.
A parte i commenti, rappresentati dalle righe che iniziano con il simbolo ‘#’, e le righe vuote,
questo file è fatto principalmente per annotare coppie di indirizzi IP, dove il primo è la maschera e
il secondo l’indirizzo della rete a cui si vuole concedere l’accesso. L’esempio seguente è simile a
quello che si trova nella pagina di manuale ypserv(8) e dovrebbe essere sufficiente a comprendere
il meccanismo.
# Consente le connessioni dallo stesso elaboratore locale (è necessario)
# Equivale a 255.255.255.255 127.0.0.1
#
host 127.0.0.1
#
#
# Permette le connessioni da tutti gli elaboratori della rete locale
# 192.168.1.0
#
255.255.255.0
192.168.1.0
Anche se potrebbe essere inutile, se il proprio sistema utilizza i file ‘/etc/hosts.allow’ e
‘/etc/hosts.deny’, è bene occuparsi della loro configurazione anche per ciò che potrebbe
riguardare il NIS. Quelle che seguono sono le direttive che potrebbero essere inserite in ‘/etc/
hosts.allow’:
NIS
1501
ypserv: specifica_dei_nodi
ypbind: specifica_dei_nodi
yppasswd: specifica_dei_nodi
Per converso, può essere conveniente inserire le righe seguenti nel file ‘/etc/hosts.deny’, allo
scopo di escludere gli accessi che non provengano dai nodi autorizzati espressamente:
portmap: ALL
ypserv: ALL
ypbind: ALL
yppasswd: ALL
Naturalmente, per una sicurezza maggiore, può essere conveniente inserire soltanto la direttiva
seguente nel file ‘/etc/hosts.deny’:
ALL: ALL
138.5.5 Configurazione e preparazione delle mappe
Le mappe NIS, come già accennato, sono collocate nella directory ‘/var/yp/dominio_nis /’. I
file delle mappe esistenti, per il solo fatto di esserci, definiscono implicitamente quali sono i
dati amministrativi che vengono gestiti in quel dominio NIS particolare. La loro creazione e il
loro aggiornamento, avvengono attraverso un file-make che si trova nella directory ‘/var/yp/’
e che generalmente viene utilizzato attraverso uno script. Il problema, semmai, sta nella necessità
eventuale di modificare tale file-make per definire quali mappe debbano essere costruite.
In generale è indispensabile la lettura di questo file, per verificare come sono le impostazioni
attuali. Si noteranno certamente molti commenti che spiegano il significato delle direttive che
vengono date (può trattarsi di assegnamenti a variabili che poi sono riutilizzate nel file-make
stesso). È molto importante osservare bene la conformazione dell’obiettivo ‘all’; nell’esempio
seguente, questo obiettivo richiede probabilmente la modifica manuale per includere le mappe
che si intendono gestire, secondo l’esempio commentato che lo precede:
#all
#
all:
ethers hosts networks protocols rpc services passwd group shadow \
passwd.adjunct netid netgrp publickey mail timezone locale netmasks
passwd group shadow ypservers
L’esempio successivo mostra invece un obiettivo ‘all’ controllato da una variabile, dove proprio
le mappe per la gestione del file ‘/etc/shadow’ sono controllate in modo automatico, in base
alla presenza del file stesso:
# If you don’t want some of these maps built, feel free to comment
# them out from this list.
ALL =
#ALL +=
#ALL +=
#ALL +=
passwd group hosts rpc services netid protocols netgrp networks
publickey mail ethers bootparams printcap
amd.home auto.master auto.home auto.local
timezone locale netmasks
# Autodetect /etc/shadow if it’s there
ifneq ($(wildcard $(SHADOW)),)
ALL += shadow
endif
# Autodetect /etc/passwd.adjunct if it’s there
ifneq ($(wildcard $(ADJUNCT)),)
ALL += passwd.adjunct
endif
all:
$(ALL)
NIS
1502
In questo file-make esiste comunque un’altra cosa molto importante da controllare:
# If we have only one server, we don’t have to push the maps to the
# slave servers (NOPUSH=true). If you have slave servers, change this
# to "NOPUSH=false" and put all hostnames of your slave servers in the file
# /var/yp/ypservers.
NOPUSH=true
Nella prima parte viene definito, attraverso una variabile, se il servente deve occuparsi di spedire
gli aggiornamenti (push) ai serventi secondari. In questo caso, commentando l’assegnamento
della variabile ‘NOPUSH’ si ottiene di mantenere attivo questo aggiornamento.4
Una volta predisposto il file-make, si può usare il programma ‘make’, senza argomenti, oppure
si può utilizzare un comando specifico (è la scelta più elegante, mentre ‘make’ è la scelta più
semplice quando si raggiunge una certa dimestichezza con il sistema).
# /usr/lib/yp/ypinit -m
Il vero vantaggio nell’utilizzo di questo programma (che poi è in realtà uno script), sta nel fatto
che provvede a costruire al volo il file ‘/var/yp/servers’, con l’elenco dei serventi competenti
per il dominio che si sta predisponendo.
At this point, we have to construct a list of the hosts which will run NIS
servers. dinkel.brot.dg is in the list of NIS server hosts.
Please continue to add the names for the other hosts, one per line.
When you are done with the list, type a <control D>.
next host to add: dinkel.brot.dg
next host to add:
Questa operazione va condotta dall’elaboratore che deve svolgere il ruolo di servente principale,
di conseguenza, il suo indirizzo deve apparire per primo. Supponendo di avere un secondo elaboratore da utilizzare come servente secondario, si può aggiungere il suo nome e quindi terminare
con la combinazione [ Ctrl+d ].
next host to add: roggen.brot.dg[ Invio ]
next host to add: [ Ctrl+d ]
The current list of NIS servers looks like this:
dinkel.brot.dg
roggen.brot.dg
Is this correct?
[y/n: y]
[ Invio ]
We need some minutes to build the databases...
Building /var/yp/rost.nis-yp/ypservers...
Running /var/yp/Makefile...
NIS Map update started on Thu Jul 25 12:00:00 CEST 2002
make[1]: Entering directory ‘/var/yp/rost.nis-yp’
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating shadow.byname...
make[1]: Leaving directory ‘/var/yp/rost.nis-yp’
NIS Map update completed.
4
Se non serve, o non funziona, si ottiene al massimo una segnalazione di errore nel momento in cui si utilizza il
file-make, senza altri effetti collaterali.
NIS
1503
Questo è il tipo di risultato che si può osservare quando tutto procede regolarmente. Se non
si utilizza lo script ‘ypinit’, si salta la predisposizione del file ‘/var/yp/rost.nis-yp/
ypservers’, che però potrebbe essere già stato ottenuto da un’esecuzione precedente di
‘ypinit’. In pratica, lo script ‘ypinit’ va utilizzato convenientemente la prima volta che si
allestisce il servente, mentre le altre volte è sufficiente utilizzare solo ‘make’ dalla directory
‘/var/yp/’:
# cd /var/yp[ Invio ]
# make[ Invio ]
138.5.6 Gestione delle parole d’ordine
Perché gli utenti del servizio NIS possano modificare la propria parola d’ordine di accesso, è
necessario che nel servente principale sia in funzione il demone ‘rpc.yppasswdd’:
rpc.yppasswdd
[opzioni]
Le opzioni disponibili dipendono molto dalla versione di questo programma e dal modo con cui
è stato compilato. È da questo programma che dipende anche la possibilità o meno di utilizzare
‘ypchsh’ e ‘ypchfn’. In generale, utilizzandolo senza opzioni particolari, è possibile solo la
modifica delle parole d’ordine.
138.6 Predisposizione del servente secondario
I serventi secondari, ammesso che se ne vogliano avere, devono poter comunicare con il servente
principale, ma naturalmente ciò richiede implicitamente che questi, oltre che serventi secondari,
siano anche dei clienti. Più avanti verrà spiegato come predisporre un cliente NIS; per il momento è bene affrontare ugualmente il problema, per mantenere mentalmente il collegamento con
quanto già trattato sul servente principale.
Un servente secondario richiede le stesse cose del servente principale, a eccezione del demone
‘rpc.yppasswdd’ che nel servente secondario non ha ragione di esistere. Questo significa che:
• si deve impostare il dominio NIS;
• si
deve
configurare ‘ypserv’ attraverso ‘/etc/ypserv.conf’
ypserv.securenets’, oppure gli altri file del TCP wrapper.
e
‘/etc/
Si è già accennato al fatto che il servente secondario deve avere il cliente NIS in funzione,
ma la differenza più interessante sta nell’assenza del file-make nella directory ‘/var/yp/’.
Naturalmente, il file-make può anche esserci, ma non deve essere preso in considerazione.
138.6.1 Riproduzione delle mappe nel servente secondario
Anche il servente secondario, per poter compiere il suo lavoro, deve disporre delle mappe NIS.
Queste vengono create, copiandole dal servente principale, attraverso il comando seguente:
/usr/lib/yp/ypinit -s servente_nis_principale
In pratica, si avvia ‘ypinit’ con l’opzione ‘-s’, indicando il nome dell’elaboratore che ospita
il servente principale. Per esempio, se il servente principale è dinkel.brot.dg, il comando
corretto è il seguente:
NIS
1504
# /usr/lib/yp/ypinit -s dinkel.brot.dg
Perché l’operazione funzioni correttamente, occorre che il cliente NIS sottostante sia configurato
e funzionante. In pratica, prima di utilizzare ‘ypinit’, si può verificare che sia tutto in ordine
con il comando seguente:
# ypwhich -m
Questo deve restituire il nome del servente principale.
138.6.2 Sincronizzazione
La presenza di serventi secondari introduce nel sistema NIS dei problemi di sincronizzazione di
questi con il servente principale. Oltre a tutto, lo stesso procedimento di sincronizzazione accresce i problemi di sicurezza, dal momento che periodicamente viaggiano informazioni delicate
nella rete.
Ci sono tre modi per sincronizzare i serventi secondari, ma non tutti funzionano sempre, a causa
degli accorgimenti utilizzati per ridurre i problemi di sicurezza.
1. Quando il servente principale viene aggiornato, dovrebbe essere in grado di inviare ai serventi secondari le modifiche alle mappe (push). Questa operazione non funziona se i serventi secondari non sono in ascolto in quel momento, inoltre non funziona anche in altre
circostanze, sempre per motivi di sicurezza.
2. I serventi secondari possono comunicare periodicamente con il servente principale per verificare la presenza di aggiornamenti delle mappe. Questa operazione richiede nel servente
principale la presenza in funzione del demone ‘rpc.ypxfrd’.
3. In ultima analisi, i serventi secondari si aggiornano con il comando ‘ypinit -s
servente_principale ’.
Per quanto riguarda il secondo punto, il NIS offre generalmente tre script predisposti opportunamente per eseguire i compiti di aggiornamento. Si tratta di: ‘ypxfr_1perhour’,
‘ypxfr_1perday’ e ‘ypxfr_2perday’. Questi si trovano nella directory ‘/usr/lib/yp/’ e
sono pensati per essere inclusi in un file crontab, come nell’esempio seguente che rappresenta
precisamente il file ‘/etc/crontab’.
20 *
* * * root /usr/lib/yp/ypxfr_1perhour
40 6
* * * root /usr/lib/yp/ypxfr_1perday
55 6,18 * * * root /usr/lib/yp/ypxfr_2perday
I diversi script si occupano di trasferire mappe differenti. In particolare, quello eseguito ogni ora
è predisposto per trasferire le informazioni sugli utenti (la cosa più urgente).
Dal momento che non si può fare affidamento sul sistema di aggiornamento pilotato dal servente principale (quello del primo punto), se per qualche motivo l’aggiornamento a mezzo di
‘ypxfr’ non funziona, occorre ripiegare necessariamente sull’uso periodico di ‘ypinit -s’,
eventualmente collocando anch’esso in un file crontab.
Come già accennato, il demone ‘rpc.ypxfrd’ viene utilizzato solo nel servente principale per facilitare l’aggiornamento delle mappe nei serventi secondari. La sua presenza non è
indispensabile, ma è utile per accelerare il processo di aggiornamento.
rpc.ypxfrd
[opzioni]
Generalmente può essere utilizzato senza argomenti e dovrebbe essere gestito direttamente dalla
procedura di inizializzazione del sistema.
NIS
1505
138.7 Organizzazione di una distribuzione
Quando la propria distribuzione GNU è ben organizzata, non è necessario intervenire direttamente nel file ‘/var/yp/Makefile’; inoltre, è normale che siano già predisposti correttamente gli
script per il controllo del NIS attraverso la procedura di inizializzazione del sistema.
Nel caso particolare delle distribuzioni Debian, lo script della procedura di inizializzazione del
sistema che controlla il NIS è ‘/etc/init.d/nis’. Questo script, a sua volta, utilizza le indicazioni contenute nel file ‘/etc/default/nis’ per sapere se deve essere attivato un servizio
NIS come servente principale, secondario, o come cliente. Nell’esempio seguente si intende allestire un servente principale, in cui i file contenenti le parole d’ordine si trovano nella directory
‘/etc/’ (come avviene di solito), che consente la modifica remota della shell:
#
# /etc/default/nis
#
Configuration settings for the NIS daemons.
# Are we a NIS server and if so what kind (values: false, slave, master)
NISSERVER=master
# Location of the master NIS password file (for yppasswdd).
# If you change this make sure it matches with /var/yp/Makefile.
YPPWDDIR=/etc
# Do we allow the user to use ypchsh and/or ypchfn ? The YPCHANGEOK
# fields are passed with -e to yppasswdd, see it’s manpage.
# Possible values: "chsh", "chfn", "chsh,chfn"
YPCHANGEOK=chsh
138.8 Cliente NIS
Gli elaboratori che devono condividere le informazioni amministrate con il NIS, devono utilizzare il demone ‘ypbind’, configurato opportunamente. In tal modo, su tali elaboratori, invece di
utilizzare le informazioni amministrative locali, verranno usate quelle concentrate dal NIS.
La configurazione di ‘ypbind’ avviene attraverso i file ‘/etc/yp.conf’ e ‘/etc/
nsswitch.conf’. Il primo serve a definire come raggiungere i serventi; il secondo definisce
l’ordine di utilizzo dei servizi (Name service switch).
Come nel caso dei serventi, anche i clienti richiedono la definizione del dominio NIS, attraverso
‘domainname’. Se il dominio non viene predisposto ‘ypbind’ non può funzionare.
Anche il cliente richiede la presenza della directory ‘/var/yp/’. Al suo interno viene creata la
directory ‘binding/’.
Anche il cliente richiede l’attivazione del Portmapper RPC.
138.8.1 Gli utenti
A seconda delle caratteristiche particolari del cliente, sono possibili delle configurazioni speciali
per ciò che riguarda l’accesso da parte degli utenti. Quando la loro gestione è compito del NIS, si
può configurare il cliente in modo da definire una graduatoria nella ricerca dei dati che identificano l’utente al momento dell’accesso. Di solito si cerca prima l’utente nel file ‘/etc/passwd’
locale, quindi si prova con il NIS.
A parte questo particolare abbastanza semplice, si può porre il problema di voler concedere
l’accesso su un certo elaboratore solo ad alcuni utenti definiti attraverso il NIS, oppure, più semplicemente, si può volere escludere l’accesso da parte di qualcuno. Per ottenere questo occorre
NIS
1506
intervenire sul file ‘/etc/passwd’ utilizzando record con notazioni particolari; cosa che qui non
viene descritta.
In generale, per fare in modo che gli utenti NIS del dominio a cui si fa riferimento possano accedere da un certo cliente, occorre aggiungere in coda un record speciale nei file ‘/etc/passwd’,
‘/etc/group’ e ‘/etc/shadow’:
• ‘/etc/passwd’
+::::::
• ‘/etc/group’
+:::
• ‘/etc/shadow’
+::::::
Questo record viene interpretato come il punto in cui si vogliono inserire virtualmente gli utenti
NIS.
138.8.2 Attivazione del demone
‘ypbind’ è il demone necessario all’attivazione dell’accesso alle informazioni fornite da un servente NIS; è in pratica il cliente NIS. Utilizza la directory ‘/var/yp/binding/’ per collocarci
all’interno un file contenente le informazioni sul dominio NIS per il quale è stato avviato.
ypbind
[opzioni]
‘ypbind’ utilizza la configurazione del file ‘/etc/yp.conf’ per trovare i serventi e quella del
file ‘/etc/nsswitch.conf’ per stabilire l’ordine di utilizzo delle informazioni amministrative.
In caso di difficoltà, può essere avviato con l’opzione ‘-debug’, in modo da farlo funzionare in
primo piano, per controllare le informazioni diagnostiche emesse attraverso lo standard error.
La configurazione principale di questo demone avviene per mezzo del file ‘/etc/yp.conf’, il
quale serve a definire come accedere ai serventi.
‘ypbind’ potrebbe essere in grado di utilizzare solo l’ultima riga di questo file. Di
conseguenza, è bene limitarsi a una sola direttiva.
Il file può contenere tre tipi di direttive, descritte dai modelli sintattici seguenti:
domain dominio_nis server host
domain dominio_nis broadcast
ypserv host
La prima definisce che per il dominio NIS indicato si deve interpellare il servente specificato;
la seconda definisce che per il dominio si devono usare delle chiamate circolari a tutta la rete
(locale); l’ultima definisce semplicemente un servente, indipendentemente dal dominio.
Quando si utilizza il sistema della chiamata circolare (broadcast), si rischia di ricevere la risposta
da un possibile servente fasullo, collocato appositamente per sostituirsi a quelli veri allo scopo di
carpire informazioni dai clienti. Se non si temono attacchi di questo tipo, la chiamata circolare è
il modo migliore che consente al cliente di scegliersi il servente (quello che risponde prima).
NIS
1507
Il servente può essere indicato per nome o per numero IP. Nel primo caso, è necessario che
il sistema sia in grado di risolvere il nome in modo indipendente dal NIS (evidentemente). In
generale, è conveniente utilizzare l’indirizzo IP per questo scopo.
L’esempio seguente mostra l’unica riga di un file ‘/etc/yp.conf’ in cui si stabilisce che per il
dominio rost.nis-yp si deve usare la chiamata circolare.
domain rost.nis-yp broadcast
Il file ‘/etc/nsswitch.conf’ viene usato dalla libreria C per attuare il NSS, ovvero il Name
service switch, che in pratica stabilisce l’ordine in cui devono essere cercate le informazioni (se
attraverso il NIS, file locali o altro). Pertanto, il modo corretto di configurare questo file dipende
strettamente dal tipo e dalla versione della libreria utilizzata. Si veda a questo proposito quanto
descritto nella pagina di manuale nsswitch.conf (5), oppure nell’ipertesto Info: libc.info.
Quello che segue è la configurazione proposta in una distribuzione GNU particolare.
#
#
#
#
#
#
/etc/nsswitch.conf
Example configuration of GNU Name Service Switch functionality.
If you have the ‘glibc-doc’ and ‘info’ packages installed, try:
‘info libc "Name Service Switch"’ for information about this file.
passwd:
group:
shadow:
compat
compat
compat
hosts:
networks:
files dns
files
protocols:
services:
ethers:
rpc:
db
db
db
db
netgroup:
nis
files
files
files
files
138.8.3 Altri programmi di contorno
Dal lato del cliente sono importanti altri programmi di contorno. Si tratta precisamente di
‘ypwhich’, ‘ypcat’, ‘ypmatch’ e ‘yppasswd’.
‘ypwhich’ permette di conoscere quale sia il servente NIS utilizzato dal cliente, quando viene
avviato senza opzioni, oppure quale sia precisamente il servente principale per una certa mappa.
ypwhich
[opzioni]
Opzione
-d dominio
-m
[mappa]
Descrizione
Utilizza un dominio differente da quello predefinito. Per usare
questa opzione occorre comunque che tale dominio diverso
sia stato collegato.
Permette di conoscere quale sia il servente principale per la
particolare mappa specificata, o per tutte quelle che vengono
raggiunte.
Seguono alcuni esempi di utilizzo di ‘ypwhich’.
$ ypwhich
NIS
1508
Emette il nome dell’elaboratore che funge da servente NIS per quel particolare cliente.
$ ypwhich -m
Emette l’elenco delle mappe gestire dal NIS con i rispettivi serventi principali competenti.
‘ypcat’ emette il contenuto di una mappa indicata come argomento della riga di comando.
Questo programma dipende da ‘ypbind’.
ypcat
[opzioni]
mappa
Opzione
Descrizione
-d dominio
L’esempio seguente serve a emettere il contenuto della mappa corrispondente all’elenco dei
gruppi per nome.
$ ypcat group.byname
‘ypmatch’ emette il valori corrispondenti a una o più chiavi di una mappa. Questo programma
dipende da ‘ypbind’.
ypmatch
[opzioni]
chiave ... mappa
Opzione
-d dominio
Descrizione
Seguono alcuni esempi di utilizzo di ‘ypmatch’.
$ ypmatch tizio caio passwd.byname
Emette i record corrispondenti agli utenti ‘tizio’ e ‘caio’.
$ ypmatch 500 passwd.byuid
Emette il record corrispondente all’utente identificato dal numero UID 500.
‘yppasswd’, ‘ypchsh’ e ‘ypchfn’ sono tre alias dello stesso programma. A seconda del nome
usato per avviarlo, si intende cambiare la parola d’ordine, la shell o le informazioni personali.
[utente]
ypchsh [utente ]
ypchfn [utente ]
yppasswd
Questi comandi si sostituiscono ai soliti ‘passwd’, ‘chsh’ e ‘chfn’, che hanno effetto solo localmente, quando si vuole intervenire sulle utenze gestite dal NIS. A questo proposito, è bene
considerare la possibiltà di fare «sparire» i comandi normali, in modo da non creare confusione
agli utenti, predisponendo dei collegamenti simbolici opportuni per fare in modo che ‘passwd’,
‘chsh’ e ‘chfn’ avviino rispettivamente i corrispondenti ‘yppasswd’, ‘ypchsh’ e ‘ypchfn’.
Questi comandi, quando vengono invocati, si mettono in contatto con il servente principale, nel
quale deve essere in funzione il demone ‘rpc.passwdd’. È da questo demone che dipende la
NIS
1509
possibilità di cambiare questi valori, ma potrebbe capitare che sia abilitata solo la sostituzione
delle parole d’ordine.
Solo l’utente ‘root’ può indicare il nome di un altro utente attraverso la riga di comando.
138.9 Directory personali
Quando si gestiscono gli utenti (e i gruppi) attraverso il NIS, si intende permettere a tutti questi utenti di utilizzare indifferentemente tutte le macchine su cui si fa funzionare il cliente NIS.
Per raggiungere questo obiettivo, occorre fare in modo che le rispettive directory personali (home) siano accessibili da qualunque postazione. Evidentemente è necessario usare uno spazio
condiviso in rete, attraverso il protocollo NFS.
Il modo più semplice potrebbe essere quello di predisporre una partizione apposita in un servente
NFS, montando tale file system nella directory ‘/home/’ di ogni cliente NIS. Come si può intuire
non si tratta di una soluzione ottimale, ma comunque è qualcosa di pratico, almeno inizialmente.
Il file system condiviso dovrà essere accessibile in lettura e scrittura.
La gestione del protocollo NFS è descritta nel capitolo 137.
138.10 Porte coinvolte
Il servizio NIS si avvale per il suo funzionamento del Portmapper e di altri demoni specifici,
come descritto nel capitolo. In generale, questi demoni comunicano utilizzando porte TCP o
UDP definite in modo dinamico, pubblicizzate poi dal Portmapper stesso. Pertanto, a parte il
Portmapper che opera alla porta 111, non esiste la possibilità di controllare il traffico NIS per
mezzo di filtri di pacchetto che usano come riferimento le porte TCP e UDP.
Eventualmente, molti dei demoni del servizio NIS possono accettare un opzione della riga di
comando con la quale si specifica espressamente un numero di porta; in questo modo di può
stabilire una convenzione interna e sfruttare questa per la configurazione di un firewall.
138.11 Riferimenti
• Thorsten Kukuk, The Linux NIS(YP)/NYS/NIS+ HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
Capitolo
139
DHCP
La sigla DHCP sta per Dynamic host configuration protocol e identifica un protocollo attraverso
il quale un gruppo di nodi può essere configurato in modo automatico e dinamico, per ciò che
riguarda la sua connessione nella rete.1
Per comprendere il problema, si immagini un ufficio con una rete locale chiusa, in cui si vogliono
poter collocare dei nodi senza troppi problemi, soprattutto senza dover stabilire prima gli indirizzi
IP e i nomi corrispondenti.
Per attuare questo meccanismo attraverso il protocollo DHCP, occorre un servente che sia in
grado di rispondere a una richiesta del genere, con dei clienti in grado di fare tale richiesta
adeguandosi alla risposta ricevuta.
Quando un cliente contatta un servente DHCP per la priva volta, tra i due viene concordato un
tempo di validità per la configurazione assegnata al cliente. Ciò permette all’elaboratore cliente
di mantenere quella configurazione per un certo tempo, senza che questa debba essere necessariamente ridefinita ogni volta che lo si riavvia. Questo tempo viene indicato con il termine lease
ed è compito del servente tenere memoria dei nodi che possono trovarsi nella rete di sua competenza; i clienti dovranno richiedere ogni volta al servente i dati per la loro configurazione, ma
almeno si cerca di fare in modo che questi restino uguali per il tempo di lease, che deve essere
configurato in modo conveniente in base alle caratteristiche della rete.2
139.1 Introduzione e sistemazioni generali
Il cliente che tenta di contattare un servente DHCP deve utilizzare una chiamata circolare. Per
questo, nel caso di un sistema GNU/Linux, i kernel utilizzati negli elaboratori clienti e quello del
servente, devono essere stati predisposti opportunamente per il multicasting (sezione 29.2.9).
Si verifica facilmente che sia disponibile questa caratteristica attraverso ‘ifconfig’, dando una
configurazione transitoria a un’interfaccia e quindi visualizzando il suo stato come nel caso
seguente:
# ifconfig eth0[ Invio ]
eth0
Link encap:Ethernet HWaddr 00:A0:24:77:49:97
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:87 errors:0 dropped:0 overruns:0
Interrupt:12 Base address:0xff80
In questo caso si vede apparire la parola ‘MULTICAST’, che rappresenta l’attivazione della
modalità corrispondente, risolvendo ogni dubbio.
Un servente DHCP potrebbe avere qualche difficoltà a funzionare correttamente con GNU/Linux.
Il servente DHCP deve essere in grado di trasmettere dei pacchetti all’indirizzo IP
255.255.255.255, corrispondente idealmente a «tutti i nodi». Può darsi che per poterlo fare, si
debba creare un instradamento apposito, su tutte le interfacce di rete attraverso cui il servente
deve essere raggiungibile e da cui deve poter rispondere.
# route add -host 255.255.255.255 dev eth0
1
Di solito, il protocollo DHCP serve solo per quanto riguarda IPv4, dal momento che IPv6 risolve già questi problemi
in modo autonomo.
2
Il termine inglese fa intendere che il cliente «affitta» la sua posizione nella rete.
1510
DHCP
1511
# route add -host 255.255.255.255 dev eth1
L’esempio, in particolare, mostra l’instradamento attraverso le interfacce ‘eth0’ e ‘eth1’.3
Nelle versioni 2.2. del kernel Linux, potrebbe essere necessario abilitare la funzionalità di IP
boot agent, attraverso un comando simile a quello seguente:
*
# echo 1 > /proc/sys/net/ipv4/ip_bootp_agent
139.1.1 Rete di competenza e router
Teoricamente, dovrebbe essere possibile fare in modo che il servente DHCP riceva le richieste dei
clienti anche se queste devono attraversare dei router. In pratica, ciò richiede che i router siano
in grado di trasferire tali richieste, oppure che presso di loro sia presente un servizio intermedio
di relè (relay). Comunque, si tratterebbe di una politica amministrativa discutibile.
In generale, il servente DHCP dovrebbe essere collocato nella rete fisica che si trova a servire,
mentre le richieste dei clienti non dovrebbero poter attraversare i router.
L’utilizzo del protocollo DHCP può costituire un problema serio di sicurezza; in questo senso, sarebbe meglio se i router non fossero in grado di trasferire le connessioni con questo
protocollo.
139.1.2 Conflitto con il supervisore dei servizi di rete
Normalmente, il protocollo DHCP utilizza la porta 67 UDP, che di solito è denominata ‘bootps’.
Pertanto, il supervisore dei servizi di rete potrebbe essere stato predisposto per la gestione del
servizio BOOTP su quella porta. Per esempio, nel file ‘/etc/inetd.conf’, che riguarda precisamente la configurazione di Inetd, dovrebbe essere presente una riga simile a quella seguente,
commentata nello stesso modo.
#bootps dgram
udp
wait
root
/usr/sbin/tcpd
bootpd
Se la gestione del servizio BOOTP fosse abilitata, ciò andrebbe in conflitto con i demoni usati
per il DHCP, sia nel nodo del servente, sia nei nodi clienti.
139.1.3 Informazioni gestibili attraverso DHCP
Attraverso il protocollo DHCP, i nodi clienti possono ricevere una serie di informazioni utili a
definire la loro collocazione nella rete circostante. Il minimo indispensabile di tali informazioni
è costituito normalmente dall’indirizzo IPv4 e dalla maschera di rete relativa. Dipende dalle
caratteristiche del servente la possibilità di offrire informazioni aggiuntive. L’elenco seguente è
solo un esempio delle informazioni che potrebbero essere date:
• l’indirizzo IPv4 e la maschera di rete;
• l’indirizzo broadcast;
• il nome del nodo e il dominio relativo;
• l’indirizzo del router predefinito;
3
Questo problema di GNU/Linux potrebbe essere risolto in modo più elegante nel prossimo futuro.
DHCP
1512
• l’indirizzo del servente DNS;
• l’indirizzo del servente di stampa;
• il dominio NIS.
139.2 Servente DHCP
Il servente DHCP che si trova di solito nelle distribuzioni GNU è quello la cui produzione è
finanziata da Internet Software Consortium. 4 Viene fatta questa precisazione, perché in seguito
verrà mostrato l’utilizzo di un cliente di origine differente.
Questo servente si compone del demone ‘dhcpd’, il quale si avvale della configurazione contenuta nel file ‘/etc/dhcpd.conf’, inoltre utilizza il file ‘/etc/dhcpd.leases’ per annotare gli indirizzi concessi ai vari clienti, finché questi restano validi. Questo ultimo file, ‘/etc/
dhcpd.leases’, deve esistere (vuoto) prima che il demone possa essere avviato la prima volta. Eventualmente, il demone ‘dhcpd’ è in grado di offrire anche un servizio BOOTP, se la
configurazione contiene le informazioni necessarie per la gestione di questo tipo di protocollo.
Il problema di organizzazione del servente si limita quindi alla configurazione del file ‘/etc/
dhcpd.conf’. Attualmente, questo tipo di servente è in corso di sviluppo e la documentazione
relativa alla sua configurazione potrebbe essere rimasta un po’ indietro rispetto alle potenzialità
offerte effettivamente.
Segue il modello sintattico per l’avvio del demone:
dhcpd
[opzioni] [interfacce ...]
In generale, ‘dhcpd’ non richiede alcun argomento nella riga di comando, limitandosi così a
leggere la configurazione e a porsi in ascolto di tutte le interfacce in grado di gestire il multicast, funzionando come demone. L’indicazione di una o più interfacce di rete, alla fine degli
argomenti, permette di specificare dove ‘dhcpd’ deve porre la sua attenzione, ignorando le altre
eventualmente presenti.
Opzione
-p n_porta
-cf file_di_configurazione
-lf file_lease
Descrizione
‘dhcpd’ è in ascolto normalmente della porta UDP numero
67 (‘bootps’), ma ciò può essere cambiato attraverso questa
opzione.
Permette di definire un file di configurazione alternativo a
quello predefinito.
Permette di definire un file alternativo a quello predefinito per
l’accumulo delle informazioni sui nodi che hanno ottenuto un
indirizzo IP.
La configurazione con il file ‘/etc/dhcpd.conf’ permette di definire il funzionamento di
‘dhcpd’, sia per la gestione del protocollo DHCP, che per BOOTP. Qui si intendono mostrare
solo le direttive utili per il protocollo DHCP.
In questo file sono ammessi i commenti, preceduti dal simbolo ‘#’ e terminati dalla fine della riga
in cui appaiono. È consentito inoltre spaziare le direttive attraverso righe vuote o righe bianche,
che vengono ignorate.
Le direttive sono organizzare in forma di struttura, in cui appare la dichiarazione di ciò a cui fa
riferimento tale struttura, seguita dall’indicazione di una serie di parametri specifici, racchiusi tra
4
DHCP ISC software libero con licenza speciale
DHCP
1513
parentesi graffe.
[parametro_globale ;]
[parametro_globale ;]
...
dichiarazione {
parametro_specifico ;
[
]
...
[sotto_dichiarazione {
[parametro_più_specifico ;]
...
}]
...
}
...
Lo schema sintattico è un po’ confuso a prima vista, ma significa che il file può iniziare con una
serie di direttive (facoltative) contenenti l’indicazione di alcuni parametri (si chiarirà in seguito
di cosa può trattarsi), il cui effetto ha valore globale, salvo la possibilità di essere offuscati da
definizioni contrastanti all’interno di direttive di dichiarazione.
Il file deve contenere almeno una direttiva di dichiarazione che può limitarsi a contenere dei
parametri specifici, oppure può inglobare delle sotto-dichiarazioni.
La cosa migliore, per cominciare, è introdurre un esempio. Si supponga di volere servire
la rete locale 192.168.1.0/255.255.255.0, specificando che gli indirizzi da 192.168.1.100 a
192.168.1.199 possono essere gestiti per le attribuzioni dinamiche di indirizzi IP. Il file di
configurazione può limitarsi a contenere quanto segue:
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.199;
}
La direttiva di dichiarazione ‘subnet’, come si può intuire, è quella più importante per la gestione del DHCP. Nella maggior parte dei casi, la configurazione si comporrà di una o più direttive
di questo tipo, contenenti probabilmente più parametri di quanto visto nell’esempio.
Prima di mostrare più in dettaglio le altre direttive, viene presentato un altro esempio, che potrebbe soddisfare le esigenze più comuni di chi utilizza ‘dhcpd’ (a parte i valori particolari che sono
stati indicati). Rispetto all’esempio precedente si nota la presenza di due intervalli di indirizzi
IP da utilizzare per l’attribuzione automatica; per il resto, momentaneamente, dovrebbe essere
intuitivo il significato.
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.149;
range 192.168.1.200 192.168.1.249;
default-lease-time 604800; # una settimana
max-lease-time 2592000;
# 30 giorni
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "brot.dg";
}
Prima di proseguire con la descrizione di alcuni tra dichiarazioni e parametri, si osservi che i
parametri sono terminati dal punto e virgola. È ammesso indicare più parametri sulla stessa riga,
anche se in generale è preferibile evitarlo.
DHCP
1514
Dichiarazione
shared-network nome {
parametro ;
[
]
...
dichiarazione {
...
}
...
}
group {
parametro ;
[
]
...
dichiarazione {
...
}
...
}
subnet indirizzo_di_rete netmask maschera_di_rete {
[parametro ;]
...
}
Parametro
default-lease-time n_secondi ;
max-lease-time n_secondi ;
range indirizzo_ip_iniziale indirizzo_ip_finale ;
option subnet-mask maschera_di_rete ;
option broadcast-address indirizzo_broadcast ;
option routers indirizzo_ip_del_router ;
Descrizione
Come si osserva dalla sintassi, una
dichiarazione ‘shared-network’ è
fatta per l’inclusione di altre dichiarazioni e non solo di parametri. Permette di specificare una rete condivisa, nel senso di due o più reti logiche che si trovano sulla stessa rete fisica. In questa situazione, è normale che la direttiva includa l’indicazione di più dichiarazioni ‘subnet’,
una per ogni rete logica. Il problema, semmai, è che quando si collocano dei nodi nuovi nella rete condivisa, non è possibile distinguere a quale
delle reti logiche dovrebbero appartenere; di conseguenza, ottengono semplicemente il primo indirizzo libero
nell’insieme globale.
La dichiarazione ‘group’ serve solo a
definire un raggruppamento di dichiarazioni, a cui attribuire una serie di parametri in modo predefinito. Evidentemente si tratta dei parametri che precedono le direttive delle dichiarazioni
annidate.
La dichiarazione ‘subnet’ serve a
contenere l’indicazione di parametri
specifici per la sottorete. Permette di
definire una sottorete, indicata attraverso l’indirizzo e la maschera di
rete.
Descrizione
Definisce il tempo predefinito per la
scadenza dell’associazione tra nodo e
indirizzo IP assegnato. Viene utilizzato se il cliente non richiede una durata
differente.
Definisce il tempo massimo per la scadenza dell’associazione tra nodo e indirizzo IP assegnato. Il cliente non
può ottenere un tempo maggiore (che
comunque può essere rinnovato).
Indica l’intervallo di indirizzi IP utilizzabili in modo dinamico. Più intervalli separati possono essere indicati utilizzando più volte questo tipo di
parametro.
Permette di specificare la maschera
di rete, modificando eventualmente
quanto stabilito in modo predefinito.
Permette di definire l’indirizzo broadcast.
Permette di indicare l’indirizzo IP del
router predefinito.
DHCP
1515
Parametro
[ ]
option domain-name-servers indirizzo_dns ,... ;
option domain-name "dominio ";
Descrizione
Permette di indicare un elenco di indirizzi di serventi DNS. Gli indirizzi
sono separati attraverso una virgola.
Stabilisce il nome di dominio. Di solito si tratta del dominio della rete o
della sottorete a cui si fa riferimento.
139.3 Relè DHCP
Nello stesso pacchetto del servente DHCP descritto nelle sezioni precedenti, si trova normalmente il demone ‘dhcrelay’. Questo è in grado di fungere da ripetitore per una richiesta fatta da un
cliente DHCP, quando questa, diversamente, non può attraversare un router.
All’inizio del capitolo si è accennato al fatto che sarebbe meglio evitare che un servizio DHCP
possa superare i router; tuttavia, chi desidera utilizzare ugualmente tale possibilità, lo può fare
attraverso questo programma.
dhcrelay
[opzioni]
servente_dhcp ...
‘dhcrelay’ è un demone in grado di ritrasmettere le richieste fatte da un cliente DHCP a un
servente che altrimenti non sarebbe raggiungibile. Nello stesso modo, le risposte vengono rinviate
all’origine.
‘dhcrelay’ non richiede configurazione; l’unica cosa indispensabile è l’indicazione di almeno
un servente DHCP alla fine della riga di comando.
Opzione
-p n_porta
-i interfaccia
Descrizione
Permette di specificare un numero di porta differente da
quello standard (67).
Permette di indicare in modo esplicito un’interfaccia di rete
da cui ‘dhcrelay’ può aspettarsi delle richieste da parte di
clienti DHCP. Per indicare più interfacce, occorre usare più
volte questa opzione. Questa opzione è utile in particolare per
escludere eventualmente un’interfaccia di una rete fisica su
cui potrebbe esserci già il servente DHCP relativo, in grado di
intervenire da solo.
139.4 Cliente DHCP
Il cliente DHCP ha il compito di interpellare un servente attraverso una chiamata circolare fatta nella rete fisica in cui si trova lo stesso cliente, ottenendo da questo l’indicazione dell’indirizzo IPv4 da utilizzare, assieme ad altre informazioni di contorno eventuali. Successivamente,
ha il compito di ripresentarsi presso il servente periodicamente, per evitare che scada il tempo
concesso per l’identificazione che gli è stata attribuita (lease).
Il problema maggiore, semmai, è fare in modo che il sistema presso cui è in funzione il cliente
DHCP sia in grado di adeguarsi alle informazioni ottenute in questo modo. Non basta sapere
quale indirizzo IPv4 si può utilizzare per una certa interfaccia di rete, occorre anche configurarla
e definire l’instradamento. A questo proposito, il cliente DHCP è un punto delicato, per cui la
scelta, ammesso che ce ne sia più di una, va fatta pensando all’integrazione con il proprio sistema
operativo.
DHCP
1516
Nelle distribuzioni GNU/Linux si trova normalmente il programma ‘dhcpcd’ 5 che non fa parte
dello stesso pacchetto del servente già descritto ed è anche ciò che verrà presentato in questo
capitolo.
dhcpcd
[opzioni] [interfaccia]
‘dhcpcd’ è un demone in grado di compiere il ruolo di cliente DHCP, per ottenere l’indicazione
dell’indirizzo IPv4, della maschera di rete relativa, dell’indirizzo del router, del servente DNS
oltre ad altre informazioni eventualmente fornite.
Il pregio principale di questo cliente è quello di essere capace di riconfigurare l’interfaccia di rete
e di ridefinire l’instradamento in modo autonomo, senza richiedere la predisposizione di script
appositi o di qualunque apparato di contorno.
Il limite di questo programma sta nel fatto di poter intervenire su una sola interfaccia di rete, che
in modo predefinito è ‘eth0’.
Per quanto riguarda l’informazione del DNS, ‘dhcpcd’ crea un file che riproduce il contenuto
di ‘/etc/resolv.conf’; si tratta di ‘/etc/dhcpc/resolv.conf’. Per le altre informazioni,
comprese quelle sull’interfaccia di rete e sull’instradamento, crea un altro file che ha l’aspetto
di un pezzo di script di shell, che potrebbe essere utilizzato in qualche tipo di procedura di
inizializzazione del sistema. Si tratta di ‘/etc/dhcpc/hostinfo-interfaccia ’.
Opzione
-k
-l n_secondi
Descrizione
Invia un segnale ‘SIGTERM’ al processo ‘dhcpcd’ in funzione
attualmente.
Specifica il tempo di lease da richiedere al servente. Il servente potrà accettarlo o concedere un tempo inferiore, a seconda
della sua configurazione.
Segue la descrizione di alcuni esempi.
# dhcpcd
Avvia ‘dhcpcd’ in modo normale, come demone, allo scopo di ottenere un indirizzo per
l’interfaccia ‘eth0’.
# dhcpcd eth1
Avvia ‘dhcpcd’ come demone, in modo da ottenere un indirizzo per l’interfaccia ‘eth1’.
Se il servente DHCP fornisce le indicazioni sui serventi DNS ed eventualmente anche il dominio
di competenza, ‘dhcpcd’ è in grado di creare il file ‘/etc/dhcpc/resolv.conf’, il cui scopo
è di sostituirsi a quello omonimo collocato nella directory ‘/etc/’.
Se si vuole sfruttare questa opportunità, conviene sostituire il file ‘/etc/resolv.conf’ con un
collegamento simbolico a questo file generato da ‘dhcpcd’.
# mv /etc/resolv.conf /etc/resolv.conf.orig
# ln -s /etc/dhcpc/resolv.conf /etc/resolv.conf
Il file ‘/etc/dhcpc/hostinfo-interfaccia ’ viene creato da ‘dhcpcd’ per contenere tutte le informazioni riferite a un’interfaccia particolare. Per esempio, quando si interviene su ‘eth0’, si
otterrà il file ‘/etc/dhcpc/hostinfo-eth0’.
5
DHCPcd GNU GPL
DHCP
1517
Il contenuto del file è realizzato in modo da essere compatibile con gli script per una shell derivata
da quella di Bourne (come Bash, o altre meno sofisticate), per cui è facile inglobare tale file in
uno script di una qualche procedura.
Capitolo
140
Accesso remoto
Una serie di programmi storici consente di eseguire delle operazioni su elaboratori remoti. I nomi
di questi iniziano convenzionalmente con una lettera «r» in modo da distinguerli da programmi
equivalenti che svolgono la loro funzione in ambito locale. Oltre ai programmi che richiedono
l’elaborazione, nel servente ci devono essere dei demoni in grado di attuare quanto richiesto. 1
140.1 Identificazione e fiducia
L’esecuzione di un’elaborazione remota richiede il riconoscimento dell’utente, in modo da potere stabilire l’ambito e i privilegi in cui si deve trovare presso l’elaboratore remoto. Il riconoscimento può avvenire attraverso una sorta di procedura di accesso, durante il funzionamento del
programma dal lato cliente, oppure può essere basato sulla semplice fiducia, concedendo l’accesso attraverso la preparazione di alcuni file di configurazione. Indubbiamente, la fiducia è un
metodo molto poco sicuro di amministrare il proprio sistema, ma quando una rete locale è ristretta a un ambito in cui tutto è comunque sotto controllo, la richiesta di una parola d’ordine può
essere effettivamente un fastidio inutile.
Il riconoscimento può avvenire nel modo tradizionale, attraverso i file ‘/etc/hosts.equiv’ e
‘~/.rhosts’, oppure attraverso un’autenticazione Kerberos. Questo ultimo metodo non viene
descritto.
Se si vuole concedere un accesso senza controlli particolari, si può predisporre il file ‘/etc/
hosts.equiv’ con un semplice elenco di nomi di nodi (o di indirizzi IP) a cui si concede
l’accesso, in modo generalizzato, senza la richiesta di una parola d’ordine. Parallelamente, o
alternativamente, ogni utente può predisporre il proprio elenco di nodi e di utenti da considerare
equivalenti alla propria «identità» locale, preparando il file ‘~/.rhosts’.
L’esempio seguente mostra il contenuto del file ‘/etc/hosts.equiv’ di un nodo per il quale si
vuole consentire l’accesso da parte di dinkel.brot.dg e di roggen.brot.dg.
dinkel.brot.dg
roggen.brot.dg
In questo modo, gli utenti dei nodi dinkel.brot.dg e roggen.brot.dg possono accedere al sistema locale senza la richiesta formale di alcuna identificazione, purché esista per loro
un’utenza con lo stesso nome.
L’elenco di nodi equivalenti può contenere anche l’indicazione di utenti particolari, per la precisione, ogni riga può contenere il nome di un nodo seguito eventualmente da uno spazio e dal
nome di un utente. Si osservi l’esempio seguente:
dinkel.brot.dg
roggen.brot.dg
dinkel.brot.dg tizio
dinkel.brot.dg caio
Come nell’esempio precedente, viene concesso agli utenti dei nodi dinkel.brot.dg e
roggen.brot.dg di accedere localmente se esistono utenze con lo stesso nome. In aggiunta
a questo, però, viene concesso agli utenti ‘tizio’ e ‘caio’ del nodo dinkel.brot.dg, di
accedere con qualunque nominativo-utente (locale), senza la richiesta di alcuna parola d’ordine.
1
netkit-rsh UCB BSD
1518
Accesso remoto
1519
Si può intuire che fare una cosa del genere significa concedere a tali utenti privilegi simili a
quelli di ‘root’. In generale, tali utenti non dovrebbero essere in grado di utilizzare UID molto
bassi, ma questo dipende da come sono stati compilati i sorgenti; comunque non è questo un
buon motivo per configurare così il file ‘/etc/hosts.equiv’.
Il nome o l’indirizzo di un nodo può essere preceduto da un segno, ‘+’ o ‘-’, con il quale si
intende, rispettivamente, includere o escludere il nodo stesso. Come si può intendere, il segno ‘+’
è predefinito.
Secondo la sintassi tradizionale di questo file, si può inserire una riga contenente soltanto il
segno ‘+’, allo scopo di consentire l’accesso a qualunque nodo. In questo senso si spiega poi
la presenza del segno ‘-’ per escludere poi qualche nodo particolare.
Come già accennato, indipendentemente dal fatto che il file ‘/etc/hosts.equiv’ sia presente
o meno, ogni utente può predisporre il proprio file ‘~/.rhosts’. La sintassi di questo file è la
stessa di ‘/etc/hosts.equiv’, ma si riferisce esclusivamente all’utente che predispone tale file
nella propria directory personale.
In questo file, l’indicazione di utenti precisi è utile e opportuna, perché quell’utente fisico,
potrebbe essere riconosciuto con nomi differenti presso i nodi da cui vuole accedere.
dinkel.brot.dg tizi
roggen.brot.dg tizio
L’esempio, mostra l’indicazione precisa di ogni nominativo-utente dei nodi che possono accedere
senza richiesta di identificazione.2
I dettagli sull’uso di questi file possono essere differenti da un sistema all’altro. In particolare
ci possono essere delle restrizioni ai permessi che può avere questo file; infatti, secondo il buon
senso, ‘/etc/hosts.equiv’ dovrebbe appartenere all’utente ‘root’, senza consentire accessi
in scrittura ad altri utenti; nello stesso modo, il file ‘~/.rhosts’ dovrebbe appartenere all’utente al quale si riferisce, senza che altri possano avere permessi di scrittura su questo. Inoltre,
dovrebbe essere impedito all’utente ‘root’, così come agli utenti speciali (cioè quelli corrispondenti a numeri UID particolarmente bassi), di accedere senza identificazione. Quindi, di solito,
la sola configurazione del file ‘/etc/hosts.equiv’ non basta a permettere l’accesso all’utente
‘root’ senza che questo fornisca la parola d’ordine, anche se normalmente è sufficiente predisporre il file ‘~root/.rhosts’.3 Si veda in ogni caso quanto descritto nelle pagine di manuale
hosts.equiv(5) e rhosts(5), se presenti nel proprio sistema.
140.2 Accesso remoto normale
L’accesso remoto tradizionale è qualcosa di molto simile all’utilizzo di una connessione TELNET e comunque rimane la base dei programmi di utilizzo remoto. Dal lato del servente occorre
un demone ‘in.rlogind’ (o solo ‘rlogind’) e dal lato del cliente il programma ‘rlogin’.
La sintassi per avviare demone dal lato del servente è molto semplice:
in.rlogind
[opzioni]
Il demone ‘in.rlogin’ è gestito dal supervisore dei servizi di rete e filtrato dal TCP wrapper.
Nell’esempio seguente, viene mostrata la riga di ‘/etc/inetd.conf’ in cui si dichiara il suo
possibile utilizzo per quanto riguarda il caso particolare di Inetd:
2
Si deve fare attenzione al fatto che tra il nome del nodo e il nome dell’utente, ci deve essere uno spazio.
Per quanto riguarda le limitazioni all’accesso dell’utente ‘root’, si tenta presente che potrebbe essere stato impedito
l’accesso da un elaboratore remoto a causa della configurazione del file ‘/etc/securetty’.
3
Accesso remoto
1520
login
stream
tcp
nowait
root
Opzione
/usr/sbin/tcpd
in.rlogind
Descrizione
Permette anche all’utente ‘root’ di utilizzare il file ‘~/
.rhosts’.
-h
Dal lato del cliente il programma ‘rlogin’ consente di accedere all’elaboratore remoto, come se
ci si trovasse sulla console di quello:
rlogin
[opzioni]
host_remoto
Opzione
Descrizione
Con questa opzione è possibile specificare già nella riga di
comando il nome dell’utente da utilizzare per l’accesso nel
sistema remoto. Quando ci si identifica in questo modo, viene
richiesta la parola d’ordine in ogni caso.
Abilita la connessione utilizzando una comunicazione a 8 bit
in modo da poter utilizzare caratteri speciali che vanno oltre
l’ASCII tradizionale.
-l utente
-8
140.3 Shell remota
Una shell remota è uno strumento per eseguire un comando in un elaboratore remoto dirigendo il
flusso normale di dati attraverso il programma utilizzato localmente. In pratica, per fare questo,
si utilizza il demone ‘in.rshd’ (o ‘rshd’) dal lato servente e ‘rsh’ dal lato cliente.
Quando si utilizza una shell remota come Rsh, è importante fare mente locale alla sequenza delle
operazioni che avvengono. Infatti, il comando viene interpretato inizialmente dalla shell locale
che poi passa gli argomenti a ‘rsh’, il quale poi eseguirà un comando presso l’elaboratore remoto.
Il problema sta quindi nel comprendere quale sia effettivamente il comando che verrà eseguito
nell’elaboratore remoto, tenendo conto anche della shell che verrà utilizzata lì, per determinare
il flusso di output che si ottiene (standard output e standard error), flusso che poi può essere
visualizzato, ridiretto o rielaborato localmente.
Segue la sintassi per l’avvio del demone che offre questo servizio:
[opzioni]
in.rshd
Il demone ‘in.rshd’ è gestito dal supervisore dei servizi di rete e filtrato dal TCP wrapper
(‘tcpd’). Nell’esempio seguente, viene mostrata la riga di ‘/etc/inetd.conf’ in cui si dichiara
il suo possibile utilizzo per quanto riguarda il caso particolare di Inetd:
shell
stream
tcp
nowait
root
Opzione
/usr/sbin/tcpd
in.rshd
Descrizione
Permette anche all’utente ‘root’ di utilizzare il file ‘~/
.rhosts’.
-h
Dal lato del cliente il programma ‘rsh’ permette di eseguire il comando richiesto nell’elaboratore
remoto specificato se su quell’elaboratore è abilitata questa possibilità:
rsh
[opzioni]
host_remoto
[comando]
Lo standard input ricevuto da ‘rsh’ viene inviato allo standard input del comando remoto; lo
standard output e lo standard error emessi dal comando remoto vengono ridiretti in modo che
Accesso remoto
1521
diventino rispettivamente lo standard output e lo standard error di ‘rsh’.
Questo meccanismo di ridirezione è l’elemento che rende utile questo programma e d’altra parte
è anche il suo limite: non possono essere utilizzati programmi che richiedono l’interazione con
l’utente, attraverso ‘rsh’.
Se ‘rsh’ viene utilizzata senza l’indicazione del comando remoto, si ottiene in pratica un accesso
puro e semplice, attraverso ‘rlogin’.
Opzione
Descrizione
Con questa opzione è possibile specificare già nella riga di
comando il nome dell’utente da utilizzare per l’accesso nel
sistema remoto. Quando ci si identifica in questo modo, viene
richiesta la parola d’ordine in ogni caso.
-l utente
Segue la descrizione di alcuni esempi per l’utilizzo di ‘rsh’.
• $ rsh roggen.brot.dg cat /etc/fstab > copia-locale
Esegue il ‘cat’ del file ‘/etc/fstab’ dell’elaboratore roggen.brot.dg e ne dirige
l’output verso il file locale ‘copia-locale’.
• $ rsh roggen.brot.dg cat /etc/fstab ">" copia-remota
Questo esempio sembra molto simile al precedente, ma utilizzando il simbolo di ridirezione tra virgolette, la shell locale non lo interpreta in questo modo, ma lo lascia tra gli argomenti di ‘rsh’. Così facendo, il simbolo di ridirezione viene gestito dal comando remoto
generando il file ‘copia-remota’ proprio nell’elaboratore remoto.
• $ rsh roggen.brot.dg tar czf - /home/pluto > ~/pluto.tgz
Esegue
l’archiviazione
della
directory
‘/home/pluto/’
dell’elaboratore
roggen.brot.dg generando l’archivio compresso ‘~/pluto.tgz’ nell’elaboratore
locale.
140.4 Copia tra elaboratori
Un modo per copiare dati tra un elaboratore e un altro può essere quello di sfruttare un file system
di rete. Un altro modo potrebbe essere quello di utilizzare ‘rsh’ per copiare dati da un elaboratore
remoto verso quello locale (viceversa è un po’ difficile).
Il modo più pratico è l’utilizzo di ‘rcp’ attraverso il quale si possono copiare file tra due
elaboratori remoti o tra un elaboratore remoto e quello locale.
‘rcp’ si avvale di ‘rsh’, di conseguenza, dal lato servente occorre il demone ‘rshd’ e dal lato
del servente serve anche ‘rsh’.
La sintassi per l’uso di ‘rcp’ ricalca in linea di massima quella di ‘cp’:
[opzioni]
rcp [opzioni]
rcp
origine destinazione
origine ... directory
I file o le directory indicati tra gli argomenti possono essere espressi nella forma seguente:
[[utente @]host :]file
Accesso remoto
1522
Se non viene indicato esplicitamente un utente, si intende fare riferimento a un utente remoto con lo stesso nome di quello usato localmente; se non viene indicato il nome o l’indirizzo
dell’elaboratore remoto, si intende quello locale.
Quando si fa riferimento a file remoti senza l’indicazione di un percorso assoluto, occorre tenere
presente che la directory corrente di un elaboratore remoto corrisponde alla directory personale
dell’utente a cui si fa riferimento. Nello stesso modo, occorre tenere presente che, dal momento
che ‘rcp’ si avvale di ‘rsh’, le cose possono cambiare un po’ a seconda del tipo di shell abbinato
all’utente remoto.
Opzione
-r
-p
Descrizione
Se all’interno dei file indicati come origine della copia, si trovano anche directory, queste vengono copiate assieme al loro
contenuto, in modo ricorsivo. In tal caso, necessariamente, la
destinazione deve essere una directory.
Preserve. Con questa opzione si intende fare in modo che
‘rcp’ tenti di riprodurre le stesse proprietà e gli stessi permessi nei file di destinazione, senza tenere conto del valore della
maschera dei permessi (umask). Quando questa opzione non
viene indicata, nel caso in cui il file di destinazione esista già,
vengono mantenuti i permessi e le proprietà di quello esistente, mentre se i file di destinazione vengono creati, si utilizzano
i permessi del file originale, filtrati attraverso la maschera dei
permessi.
Seguono alcuni esempi.
• $ rcp roggen.brot.dg:/home/tizio/letterina ./letterina
Copia
il
file
‘/home/tizio/letterina’
contenuto
roggen.brot.dg, nella directory corrente dell’elaboratore locale.
nell’elaboratore
• $ rcp roggen.brot.dg:\~/letterina ./letterina
Esegue un’operazione simile a quella dell’esempio precedente, ma in questo caso si utilizza
un codice macro che deve essere interpretato dalla shell remota. Per evitare che venga
invece interpretato dalla shell locale, viene utilizzata la barra obliqua inversa per proteggere
la tilde.
Capitolo
141
Informazioni sugli utenti della rete
I servizi di informazione sugli utenti della rete possono essere distinti in tre tipi, a seconda che si
basino sul servizio di uno dei demoni seguenti:
• ‘rwhod’
• ‘rpc.rusersd’
• ‘fingerd’
L’attivazione dei servizi che forniscono informazioni sugli utenti sono fonte di problemi di
sicurezza. In generale, sono molto utili nelle reti locali chiuse mentre sono pericolosi nei
sistemi accessibili dall’esterno.
141.1 Who remoto
Si tratta di un sistema che raccoglie le informazioni sugli utenti connessi nella rete locale. 1 Le
informazioni sono aggiornate frequentemente da un demone locale che, attraverso l’invio e la
ricezione di messaggi broadcast, informa e ottiene informazioni dagli altri sistemi dove si trova
in funzione lo stesso demone.
Attraverso questo meccanismo, ogni elaboratore che ha in funzione questo demone ha una directory ‘/var/spool/rwho/’ contenente una serie di file, uno per ogni elaboratore incontrato
nella rete locale. Questi file rappresentano il risultato finale di questo sistema di raccolta di informazioni e ognuno di questi contiene l’indicazione degli utenti che utilizzano gli elaboratori della
rete locale.
Il demone che si occupa di fornire e ricevere le informazioni sugli utenti connessi sui vari elaboratori della rete locale è ‘rwhod’. Come accennato, la comunicazione tra il demone locale e
quelli degli altri elaboratori avviene attraverso messaggi broadcast; pertanto la rete deve essere in
grado di gestire tali messaggi e il sistema di collezione delle informazioni risulta limitato all’ambito dell’indirizzo broadcast utilizzato. Il modello sintattico mostra che in generale non si usano
argomenti:
rwhod
Il compito di ‘rwhod’, dal punto di vista pratico, è quello di aggiornare i file contenuti all’interno
di ‘/var/spool/rwho/’.
‘rwhod’ può essere avviato solo come demone autonomo, senza il controllo del supervisore dei
servizi di rete. Se si ritiene che questo servizio sia importante occorre inserire l’avvio di ‘rwhod’
in uno degli script della procedura di inizializzazione del sistema.
All’interno di ogni elaboratore che partecipa al servizio di condivisione delle informazioni sugli
utenti, il programma ‘rwho’ è quello che legge i file contenuti in ‘/var/spool/rwho/’ per
informare sugli utenti connessi agli elaboratori della rete locale. Come spiegato in precedenza, i
file di queste informazioni, contenuti nella directory ‘/var/spool/rwho/’ sono aggiornati dal
demone ‘rwhod’.
rwho
1
[-a]
netkit-rwho UCB BSD
1523
1524
Opzione
Descrizione
Permette di non visualizzare le informazioni sugli utenti che
da molto tempo risultano non avere alcuna interazione con il
proprio sistema.
-a
141.2 Informazioni attraverso RPC
È possibile richiedere informazioni attraverso le RPC. Per ottenerle, occorre che l’elaboratore dal
quale si vogliono ricevere abbia in funzione il servizio ‘rusersd’ normalmente reso disponibile
dal demone ‘rpc.rusersd’. 2
Naturalmente, trattandosi di un servizio RPC, occorre che anche il Portmapper sia stato attivato
preventivamente (capitolo 136).
Come già accennato, ‘rpc.rusersd’ è il demone del servizio ‘rusersd’. Normalmente, per attivarlo è necessario avviarlo in maniera indipendente dal supervisore dei servizi di rete, attraverso
la procedura di inizializzazione del sistema:
rpc.rusersd
Il programma ‘rusers’, dal lato cliente, elenca gli utenti connessi agli elaboratori della rete
locale, svolgendo in pratica il compito del programma ‘users’, ma attraverso la rete. Per ottenere
queste informazioni, utilizza una chiamata RPC e quindi instaura un collegamento con il demone
‘rpc.rusersd’ presso gli elaboratori che rispondono:
rusers
[-a] [-l] [host ...]
Opzione
Descrizione
Mostra le informazioni di tutti i nodi che rispondono, anche
nessun utente vi accede in quel momento.
Mostra informazioni dettagliate sugli accessi.
-a
-l
141.3 Finger: informazioni personali
Quando si parla di Finger 3 si fa riferimento alle informazioni personali contenute nel quinto campo del file ‘/etc/passwd’, cioè al nominativo completo dell’utente. A volte, in questo campo si
trovano informazioni addizionali, come l’ufficio, il numero telefonico dell’ufficio e il numero di
casa. Sotto questo aspetto, tali informazioni sono effettivamente delicate, pertanto questo tipo di
servizio va attivato solo se richiesto.
Volendo, si possono rendere pubbliche queste informazioni, assieme ad altre che si raccolgono
all’interno di file di configurazione contenuti nelle directory personali degli utenti, attraverso il
demone ‘in.fingerd’ (o solo ‘fingerd’), controllato dal supervisore dei servizi di rete.
In molte distribuzioni GNU il demone ‘in.fingerd’ risulta attivo in modo predefinito. Pertanto,
se non lo si vuole, bisogna fare attenzione a non lasciarselo sfuggire. Il demone è gestito dal
supervisore dei servizi di rete, che di solito si avvale del TCP wrapper per controllare l’accesso a
tali informazioni:
in.fingerd
2
3
[opzioni]
netkit-rusers software libero con licenza speciale
Finger UCB BSD
1525
finger
stream
tcp
nowait
root
/usr/sbin/tcpd
in.fingerd
Se si vuole evitare che il servizio sia disponibile, conviene commentare tale direttiva del file
‘/etc/inetd.conf’:
# finger
stream
tcp
nowait
root
/usr/sbin/tcpd
in.fingerd
Segue la descrizione di alcune opzioni della riga di comando del demone ‘in.fingerd’.
Opzione
-w
-u
-l
Descrizione
Con questa opzione, gli utenti remoti del servizio ricevono
un benvenuto addizionale, contenente informazioni particolareggiate sul sistema in funzione. Dal momento che queste indicazioni possono essere utili a un ipotetico aggressore,
generalmente si evita di utilizzare tale opzione.
L’opzione ‘-u’ permette di non accogliere richieste remote
generalizzate. In pratica, si impedisce l’uso di un comando
del tipo ‘finger @host’, in cui non appare esplicitamente il
nome di un utente particolare.
Attiva l’annotazione delle richieste nel registro di sistema.
In generale, per motivi di sicurezza è meglio avviare il demone con l’opzione ‘-u’, in modo da
evitare le richieste generalizzate a tutti gli utenti del sistema.
Il programma ‘finger’ consente di visualizzare le informazioni utili a identificare gli utenti
indicati come argomento. Gli utenti possono essere specificati anche utilizzando il simbolo ‘@’
seguito dal nome dell’elaboratore. Se non vengono indicati nomi di utente, viene visualizzato
l’elenco degli utenti connessi. Se si specifica il nome di un elaboratore preceduto dal simbolo
‘@’, viene visualizzato l’elenco degli utenti connessi a quell’elaboratore:
finger
[opzioni] [utente ...] [[utente]@host ...]
Opzione
-s
-l
Descrizione
Visualizza il nominativo degli utenti, il nome reale, i terminali
a cui sono connessi (con l’aggiunta di un asterisco nel caso sia
impedita la scrittura), il tempo di inattività (questo non esclude che su quel terminale possa essere in uso un qualche programma interattivo), il momento in cui è avvenuto l’accesso e
le informazioni addizionali sull’ufficio.
Fornisce tutte le informazioni che si potrebbero ottenere attraverso l’opzione ‘-s’, assieme a tutte le altre disponibili: la
directory personale, il telefono privato, la shell iniziale, la situazione della posta elettronica, assieme al contenuto dei file
‘~/.plan’, ‘~/.project’ e ‘~/.forward’ (che si trovano
nella directory personale di quell’utente).
Questa è l’azione predefinita, che corrisponde in pratica a
fornire tutte le notizie disponibili sull’utente.
• $ finger
Fornisce l’elenco degli utenti connessi al sistema locale.
• $ finger @dinkel.brot.dg
1526
Se l’elaboratore dinkel.brot.dg lo consente, fornisce l’elenco degli utenti connessi a
quel sistema remoto. In caso contrario (quando il servente ‘in.fingerd’ è stato avviato
con l’opzione ‘-u’) si dovrebbe ottenere un messaggio simile a quello seguente:
Please supply a username
• $ finger -l @dinkel.brot.dg
Se l’elaboratore dinkel.brot.dg lo consente, fornisce tutte le informazioni disponibili
sugli utenti connessi a quel sistema remoto.
• $ finger -l [email protected]
Se l’elaboratore dinkel.brot.dg lo consente, fornisce tutte le informazioni disponibili
sull’utente ‘tizio’, indipendentemente dal fatto che questo sia connesso o meno.
141.3.1 File personali
Quando il programma ‘finger’ può funzionare, assieme alle informazioni personali dell’utente che può ottenere dal file ‘/etc/passwd’, può emettere anche il contenuto di alcuni file
predisposti dall’utente stesso:
• ‘~/.plan’;
• ‘~/.project’;
• ‘~/.forward’.
Il file ‘~/.forward’ serve a indicare un indirizzo di posta elettronica a cui viene dirottata la posta
in modo automatico. Non riguarda quindi direttamente ‘finger’, ma è una di quelle informazioni
che questo servizio fornisce opportunamente, anche se in modo indiscreto.
Gli altri due file possono essere usati da ogni utente per indicare informazioni addizionali. Generalmente si utilizza solo il primo, ‘~/.plan’, per lo scopo di pubblicizzare notizie attraverso il
servizio Finger.
Segue l’esempio di quello che si potrebbe ottenere interrogando le notizie disponibili di un certo
utente:
Login: daniele
Name: daniele giacomini
Directory: /home/daniele
Shell: /bin/bash
Office Phone: 123456
On since Thu Mar 26 07:49 (MET DST) on tty1
10 minutes 3 seconds idle
(messages off)
On since Thu Mar 26 09:37 (MET DST) on ttyp5 from :0.0
Mail forwarded to [email protected]
No mail.
Project:
Appunti di informatica libera
Alml
Textchk
Sgmltexi
Plan:
Ciao a tutti!
Capitolo
142
Messaggi sul terminale
Il modo normale di inviare un messaggio a una persona è quello di utilizzare la posta elettronica.
In alternativa, quando si desidera aprire una comunicazione istantanea, può essere conveniente
l’uso di programmi come ‘talk’, ammesso che il sistema di destinazione sia predisposto per
questo.
Il tipo di comunicazione che utilizza programmi come ‘talk’ e simili, parte dal presupposto
che si possa «scrivere» sul file di dispositivo corrispondente al terminale utilizzato dall’utente
destinatario.
142.1 Accesso al proprio terminale
Quando si accede normalmente attraverso un terminale a caratteri, il dispositivo corrispondente
dovrebbe appartenere all’utente che lo sta utilizzando e anche al gruppo ‘tty’. Ciò dovrebbe
avvenire automaticamente per opera del programma ‘login’. Nel caso dell’utente ‘tizio’ che
sta utilizzando la seconda console virtuale, si dovrebbero osservare le caratteristiche seguenti.
$ ls -l /dev/tty2[ Invio ]
crw--w----
1 tizio
tty
4,
2 dic 31 10:38 /dev/tty2
L’utente che utilizza il terminale dovrebbe avere i permessi di lettura e scrittura, inoltre, dovrebbe
essere concesso al gruppo il permesso di scrittura. Con questa convenzione, un programma che
sia stato avviato con i privilegi del gruppo ‘tty’ avrebbe la possibilità di scrivere su questo file
di dispositivo.
Scrivere sul file di dispositivo di un terminale significa andare a pasticciare lo schermo su cui
sta lavorando presumibilmente un utente. Esistendo questa possibilità, cioè che processi estranei
possano aggiungere informazioni allo schermo del terminale che si sta utilizzando, la maggior
parte degli applicativi prevede un comando che riscrive il contenuto dello schermo (di solito si
tratta della combinazione di tasti [ Ctrl+l ]). Tuttavia, gli utenti potrebbero desiderare di limitare
questa possibilità, eliminando il permesso di scrittura per il gruppo ‘tty’ per il terminale che si
sta utilizzando.
Per controllare il permesso di scrittura per il gruppo ‘tty’ del dispositivo corrispondente al
proprio terminale attivo, si può usare anche un programma molto semplice: ‘mesg’. 1
mesg
[y|n]
Il fatto di togliere il permesso di scrittura per il gruppo ‘tty’ al dispositivo del terminale, non è una garanzia che nessuno possa scriverci. Un processo con i privilegi dell’utente
‘root’ potrebbe farlo ugualmente. Tuttavia, si tratta di una convenzione che generalmente
viene rispettata.
Opzione
y
n
1
Descrizione
Permette agli altri utenti di scrivere sul proprio terminale
(aggiunge il permesso di scrittura al gruppo ‘tty’).
Impedisce agli altri utenti di scrivere sul proprio terminale
(toglie il permesso di scrittura al gruppo ‘tty’).
Se l’opzione non viene specificata, si ottiene la visualizzazione dello stato attuale.
Sysvinit GNU GPL
1527
1528
Per scrivere sullo schermo di un altro utente collegato allo stesso elaboratore locale, si usano
comunemente i programmi ‘write’ 2 e ‘wall’: 3
write utente
[terminale] [<
file_messaggio
]
Il programma ‘write’ rappresenta il sistema primordiale per inviare un messaggio a un altro
utente che utilizza un terminale dello stesso sistema locale. Il messaggio viene atteso dallo standard input e viene scritto nel dispositivo dell’utente destinatario quando questo viene concluso
con un codice di EOF (che di solito si ottiene con la combinazione [ Ctrl+d ]).
Dal momento che il programma ‘write’ non è destinato all’invio di messaggi attraverso la rete,
il nome dell’utente va indicato in modo semplice, senza specificare il nodo. Il dispositivo del
terminale può essere specificato e in tal caso si può indicare il percorso assoluto (‘/dev/tty*’)
oppure solo il nome finale. Se il terminale non viene specificato, ‘write’ cerca di determinarlo
da solo.
wall messaggio
wall
[<
file_messaggio
]
Il programma ‘wall’ è una variante di ‘write’, dove il messaggio viene inviato a tutti i terminali
attivi. Il messaggio può essere fornito anche attraverso la riga di comando.
Per poter scrivere sul dispositivo dell’utente destinatario, secondo le convenzioni, ‘write’ e
‘wall’, devono avere i privilegi del gruppo ‘tty’, per cui viene installato comunemente con
il bit SGID attivato, appartenendo al gruppo ‘tty’.
# chown root.tty /usr/bin/write
# chmod g+s /usr/bin/write
# chown root.tty /usr/bin/wall
# chmod g+s /usr/bin/wall
Dal momento che quando si invia un messaggio, si presume che il proprio corrispondente
voglia rispondere, ‘write’ e ‘wall’ non inviano il messaggio se il proprio terminale non
ammette la risposta, cioè se i permessi del proprio file di dispositivo non lo consentono.
142.2 Comunicazione diretta attraverso la rete
Per entrare in comunicazione diretta con un utente che sta utilizzando un terminale o una console di un certo nodo raggiungibile attraverso la rete, si può utilizzare il servizio ‘talk’ gestito
attraverso il demone ‘talkd’ 4
In tal caso, è il demone ‘talkd’ (o meglio, ‘in.talkd’) del nodo destinatario, che si occupa di scrivere sul dispositivo del terminale. Generalmente, questo programma viene avviato dal
supervisore dei servizi di rete con i privilegi dell’utente ‘root’, cosa che gli permetterebbe di scavalcare qualunque limitazione di accesso ai dispositivi di terminale. Tuttavia, è il demone stesso
che cerca di rispettare le convenzioni, evitando di scrivere se manca il permesso di scrittura per
il gruppo ‘tty’.
2
Write UCB BSD
Wall UCB BSD
4
Talk UCB BSD
3
1529
in.talkd
Il demone ‘in.talkd’ è gestito dal supervisore dei servizi di rete, che di solito ne controlla l’uso
attraverso il filtro del TCP wrapper.
talk
dgram
udp
wait
root
/usr/sbin/tcpd
in.talkd
Dal lato cliente, il programma ‘talk’ permette di entrare in comunicazione con una persona che
sta utilizzando un nodo all’interno della rete:
[
] [terminale]
talk utente @host
Il nome dell’utente può essere espresso identificando anche il nodo all’interno del quale è, o
dovrebbe essere connesso: utente @host . Se l’utente con cui si vuole comunicare è connesso
su più terminali all’interno dello stesso nodo, è possibile specificare il nome del terminale nella
forma ‘ttyxx ’. Quando si è chiamati attraverso ‘talk’, sullo schermo del terminale appare un
messaggio simile a quello seguente:
Message from Talk_Daemon@localhost at 11:31 ...
talk: connection requested by [email protected].
talk: respond with: talk [email protected]
In questo caso, si tratta dell’utente ‘tizio’ che cerca di contattarci; nel messaggio viene suggerito anche il modo corretto di rispondere. Evidentemente, l’utente che vuole rispondere deve
sospendere la propria attività, per avviare a sua volta una copia del programma ‘talk’.
Quando la comunicazione si instaura, viene utilizzato uno schermo suddiviso in due finestre per
distinguere i messaggi: nella parte superiore si vedono quelli inviati, mentre nella parte inferiore
appaiono quelli ricevuti.
Figura 142.1. Comunicazione attraverso ‘talk’.
[Connection established]
Io sto bene, grazie
|----------------------------------------------------------------------|
Ciao caio, come stai?
.
Durante la comunicazione, lo schermo può essere riscritto utilizzando la combinazione [ Ctrl+l ].
La comunicazione può essere terminata da uno qualunque dei due interlocutori utilizzando il
carattere di interruzione che di norma è [ Ctrl+c ].
Secondo le convenzioni, la chiamata attraverso ‘talk’ può essere impedita utilizzando il programma ‘mesg’, ovvero togliendo il permesso di scrittura al gruppo ‘tty’ del dispositivo del
proprio terminale.
1530
• $ talk tizio
Cerca di contattare l’utente ‘tizio’ nello stesso sistema locale.
• $ talk [email protected]
Cerca di contattare l’utente ‘tizio’ presso dinkel.brot.dg.
• $ talk [email protected] tty2
Cerca di contattare l’utente ‘tizio’ presso dinkel.brot.dg, al terminale ‘tty2’ (si
tratta probabilmente della seconda console virtuale).
Oltre al programma ‘talk’ tradizionale, è disponibile comunemente anche ‘ytalk’
consente la comunicazione tra più di due soli utenti:
ytalk
[-x]
5
che
utente ...
Il suo funzionamento è simile a ‘talk’ e può anche comunicare con utenti che usano lo stesso
‘talk’. L’utente può essere specificato in diversi modi:
nome
nome @host
nome #terminale
nome #terminale @host
un utente connesso presso lo stesso elaboratore locale;
un utente connesso presso un altro elaboratore;
un utente connesso presso lo stesso elaboratore locale
attraverso un terminale determinato;
un utente connesso presso un altro elaboratore, su un
terminale determinato.
Durante la comunicazione, è possibile richiamare un menù di funzioni premendo il tasto [ Esc ].
‘ytalk’ è più complesso rispetto al solito ‘talk’, tanto che è previsto l’uso di file di configurazione: ‘/etc/ytalkrc’ per le impostazioni generali e ‘~/.ytalkrc’ per la personalizzazione
da parte di ogni utente.
Eventualmente si possono approfondire le altre caratteristiche consultando la sua pagina di
manuale: ytalk(1).
142.3 Invio di un messaggio circolare
Se quello che si desidera è l’invio di un messaggio circolare senza la necessità di avere un colloquio con gli utenti destinatari, si può usare Rwall. 6 Il sistema si basa sulle RPC, di conseguenza,
è necessario che i nodi destinatari di questo messaggio abbiano in funzione il Portmapper, oltre
al demone particolare che si occupa di questo.
Rwall si compone in particolare di un demone, ‘rpc.rwalld’, oppure solo ‘rwalld’, che si avvia normalmente senza argomenti, di solito attraverso la procedura di inizializzazione del sistema,
in modo indipendente dal supervisore dei servizi di rete.
Il programma cliente che serve per sfruttare il servizio è ‘rwall’, il quale si utilizza con la sintassi
seguente:
rwall host_remoto
[file]
‘rwall’ consente di inviare un messaggio, eventualmente già preparato in un file, a tutti gli utenti
di un nodo remoto determinato. Se non viene fornito il nome di un file contenente il messaggio da
5
6
ytalk software libero con licenza speciale
Rwall UCB BSD
1531
inviare, questo messaggio può essere inserito attraverso la tastiera del terminale da cui si avvia
il programma. Per terminare l’inserimento si utilizza il codice di EOF che di solito si ottiene
premendo la combinazione [ Ctrl+d ].
Capitolo
143
TELNET
TELNET è un protocollo che permette di effettuare un collegamento con un altro elaboratore e
di operare su quello, come se si stesse utilizzando un suo terminale. Per fare questo, dal lato del
servente occorre il demone ‘telnetd’ (o meglio ‘in.telnetd’), mentre dal lato del cliente si
utilizza normalmente ‘telnet’.
Il cliente TELNET è molto importante anche come programma diagnostico per instaurare un
collegamento manuale con una porta e iniziare quindi un colloquio diretto con il protocollo TCP.
In questo caso, il demone ‘telnetd’ non viene utilizzato. 1
143.1 Dal lato del servente
Come già accennato, per eseguire un accesso in un elaboratore remoto attraverso il programma
‘telnet’, è necessario che il demone ‘in.telnetd’ sia in funzione in quell’elaboratore:
in.telnetd
[opzioni]
Il demone ‘in.telnetd’ è gestito normalmente dal supervisore dei servizi di rete e filtrato dal
TCP wrapper.
telnet
stream
tcp
nowait
root
/usr/sbin/tcpd
in.telnetd
Se è presente il file ‘/etc/issue.net’, viene utilizzato da ‘in.telnetd’ per visualizzare un
messaggio introduttivo, non appena si instaura un collegamento. Si tratta di un file di testo con lo
stesso ruolo del file ‘/etc/issue’ (51.3.1), che invece viene utilizzato da un programma Getty.
‘/etc/issue.net’ può contenere alcune sequenze di escape che vengono poi trasformate
in vario modo nel momento della visualizzazione del messaggio. La tabella 143.1 ne mostra
l’elenco.
Tabella 143.1. Elenco dei codici di escape utilizzabili all’interno del file ‘/etc/
issue.net’.
Codice
Descrizione
Il terminale corrente.
Il nome completo del sistema (FQDN).
Il nome del dominio NIS.
La data e l’ora attuale.
Il nome del sistema operativo.
Il tipo di hardware.
Il rilascio del sistema operativo.
La versione del sistema operativo.
Equivale a un carattere percentuale singolo.
%t
%h
%D
%d
%s
%m
%r
%v
%%
L’accesso a un elaboratore remoto viene fatto attraverso il programma ‘telnet’, il quale
permette di operare come se ci si trovasse su un terminale di quel sistema:
telnet
1
[opzioni] [host_remoto [porta]]
Telnet UCB BSD
1532
TELNET
1533
Se l’eseguibile ‘telnet’ viene avviato senza specificare il nodo con il quale ci si vuole
connettere, questo inizia a funzionare in modalità di comando, visualizzando l’invito: ‘telnet>’.
Quando l’eseguibile ‘telnet’ riesce a connettersi al sistema remoto, si opera come se si fosse
seduti davanti a un terminale di quel sistema.
Per poter dare dei comandi a ‘telnet’ occorre tornare temporaneamente alla modalità di comando, cosa che si ottiene utilizzando il carattere di escape. Questo carattere di escape non
corrisponde alla pressione del tasto [ Esc ], ma di solito alla combinazione [ Ctrl+] ] (control + parentesi quadra chiusa). Questa convenzione può essere cambiata ed è una cosa quasi necessaria
dal momento che utilizzando la tastiera italiana non è possibile ottenere le parentesi quadre se
non in combinazione con [ AltGR ]. Diversamente, l’unico modo per poter ottenere la combinazione [ Ctrl+] ] è quello di passare a un’altra console virtuale, attivare la mappa della tastiera USA,
tornare sulla console virtuale in cui è in funzione ‘telnet’ ed eseguire la combinazione.
La comunicazione tra il cliente TELNET e il sistema remoto può essere di tre tipi:
‘TELNET LINEMODE’
‘character at a time’
‘old line by line’
è il tipo preferito ed è il primo tipo di comunicazione che il
cliente TELNET tenta di instaurare con il sistema remoto;
in questa modalità ogni carattere viene trasmesso singolarmente al sistema remoto;
i dati vengono trasmessi a blocchi di righe e ciò che viene
scritto, riappare sul terminale locale.
Segue la descrizione di alcune opzioni e di alcuni argomenti della riga di comando.
Opzione o argomento
-4
-6
-8
-d
-a
-n file_traccia
-l utente
-e carattere_di_escape
host_remoto
porta
Descrizione
Richiede espressamente un collegamento con IPv4.
Richiede espressamente un collegamento con IPv6.
Tenta di negoziare una connessione a 8 bit.
Attiva inizialmente il controllo diagnostico.
Tenta di eseguire un accesso automatico.
Registra le azioni effettuate durante il collegamento all’interno del file indicato.
Definisce il nominativo-utente da utilizzare per l’accesso nel
sistema remoto.
Permette di definire una sequenza diversa per il cosiddetto carattere di escape. Il valore predefinito è ‘^]’ che non è tanto
compatibile con la tastiera italiana.
Identifica il sistema remoto con il quale collegarsi. Può essere
espresso in qualunque modo valido.
Identifica il numero di porta (in forma numerica o attraverso
il nome corrispondente). Se non viene specificato, si utilizza
il valore predefinito per le connessioni TELNET: 23.
Segue la descrizione di alcuni dei comandi che possono essere usati in modo interattivo.
Opzione o argomento
close
display
[argomento ...]
mode tipo_di_modalità
mode character
Descrizione
Chiude la connessione con l’elaboratore remoto.
Visualizza tutti o alcuni dei valori delle impostazioni che si
possono definire attraverso il comando ‘set’.
Permette di attivare una modalità particolare. L’attivazione della modalità richiesta dipende dal contesto e dalle
possibilità offerte dal sistema remoto.
Attiva la modalità di comunicazione a un carattere alla volta.
TELNET
1534
Opzione o argomento
mode line
| -isig
edit | -edit
softtab | -softtab
litecho | -litecho
mode isig
mode
mode
mode
mode ?
open host_remoto ←,→ -l utente
-porta
[
][
]
quit
send argomenti
set argomento valore
unset argomento valore
!
[comando]
status
?
[comando]
Descrizione
Tenta di abilitare la modalità di comunicazione ‘TELNET
LINEMODE’. Se non è possibile, si cerca di optare per la
modalità ‘old line by line’.
Abilita o disabilita la modalità ‘TRAPSIG’ che riguarda la
comunicazione ‘TELNET LINEMODE’.
Abilita o disabilita la modalità ‘EDIT’ che riguarda la
Abilita o disabilita la modalità ‘SOFT_TAB’ che riguarda la
Abilita o disabilita la modalità ‘LIT_ECHO’ che riguarda la
Visualizza una breve guida per il comando ‘mode’.
Apre una connessione con l’elaboratore remoto indicato. Se
non viene specificata la porta, si utilizza il valore predefinito
per le connessioni TELNET.
Chiude la connessione (se esiste una connessione) e termina l’esecuzione di ‘telnet’. Durante la modalità di comando, è sufficiente premere la combinazione di tasti necessaria a
ottenere il codice di EOF per terminare la sessione di lavoro.
Permette di inviare uno o più sequenze di caratteri al sistema
remoto.
‘set’ attiva o specifica il valore di una variabile determinata,
mentre ‘unset’ disabilita o pone al valore di Falso la variabile
specificata.
Permette di eseguire il comando indicato in una subshell
all’interno del sistema locale.
Visualizza lo stato corrente della connessione.
Visualizza una breve guida del comando indicato o l’elenco
dei comandi disponibili.
Se viene predisposto il file ‘/etc/telnetrc’ a livello globale, o anche il file ‘~/.telnetrc’
a livello personale, questi vengono letti quando si stabilisce un collegamento (naturalmente il
secondo prende il sopravvento sul primo). Se al loro interno appare un riferimento all’elaboratore
con il quale ci si è collegati, vengono eseguite le istruzioni relative.
Le righe che iniziano con il simbolo ‘#’ sono commenti che terminano alla fine della riga.
Le righe che non contengono spazi anteriori, dovrebbero iniziare con il nome di un nodo remoto.
Ciò che segue la stessa riga e quelle seguenti, che però cominciano con almeno uno spazio, sono
considerate come una serie di comandi da eseguire automaticamente all’atto della connessione
con quell’elaboratore.
143.3 Colloquiare con una porta
Un cliente TELNET è un ottimo strumento per eseguire una connessione TCP diagnostica con
una porta di un nodo, sia remoto che locale. Naturalmente, per poter utilizzare questo sistema
occorre conoscere il protocollo utilizzato dal demone con il quale ci si collega.2
L’esempio classico è l’invio di un messaggio di posta elettronica attraverso una connessione diretta con il servente SMTP. Dal file ‘/etc/services’ si determina che il servizio SMTP (Simple
mail transfer protocol) corrisponde alla porta 25, ma si può anche utilizzare semplicemente il nome ‘smtp’. Nell’esempio, si instaura un collegamento con il servente SMTP in funzione nel nodo
roggen.brot.dg.
2
Un cliente TELNET è in grado di utilizzare soltanto il protocollo TCP. I servizi che si basano sul TCP utilizzano un
proprio protocollo di livello superiore ed è questo ciò a cui si fa riferimento.
TELNET
1535
$ telnet roggen.brot.dg smtp[ Invio ]
Trying 192.168.1.2...
Connected to roggen.brot.dg.
Escape character is ’^]’.
220 roggen.brot.dg ESMTP Sendmail 8.8.5/8.8.5; Thu, 11 Sep 1997 19:58:15 +0200
HELO brot.dg[ Invio ]
250 roggen.brot.dg Hello dinkel.brot.dg [192.168.1.1], pleased to meet you
MAIL From: <[email protected]>[ Invio ]
250 <[email protected]>... Sender ok
RCPT To: <[email protected]>[ Invio ]
250 <[email protected]>... Recipient ok
DATA[ Invio ]
354 Enter mail, end with "." on a line by itself
Subject: Saluti.[ Invio ]
Ciao Antonio,[ Invio ]
come stai?[ Invio ]
Io sto bene e mi piacerebbe risentirti.[ Invio ]
Saluti,[ Invio ]
Daniele[ Invio ]
.[ Invio ]
250 TAA02951 Message accepted for delivery
QUIT[ Invio ]
221 dinkel.brot.dg closing connection
Connection closed by foreign host.
L’esempio mostrato dovrebbe funzionare senza bisogno di dare delle opzioni particolari all’eseguibile ‘telnet’; tuttavia, in certi casi può essere necessario l’uso dell’opzione ‘-8’ per evitare
che alcuni caratteri trasmessi o ricevuti possano essere alterati.
Capitolo
144
Trivial FTP
Il protocollo TFTP, o Trivial FTP, è un sistema di trasferimento di file senza autenticazione,
paragonabile alla condivisione del file system attraverso il protocollo NFS. Questo servizio consente l’utilizzo di sistemi senza disco (diskless), che attraverso questo protocollo ottengono ciò
che gli serve per avviare il sistema operativo. 1
È importante sapere che questo tipo di servizio esiste, anche se non si intende sfruttare la possibilità di installare sistemi senza disco nella propria rete locale, soprattutto per sapere controllare
che sia disattivato.
Per poter offrire il servizio TFTP, occorre che nel servente sia disponibile il demone ‘tftpd’ (o
meglio ‘in.tftpd’), avviato generalmente attraverso il supervisore dei servizi di rete.
Data la debolezza di questo servizio che non richiede alcuna forma di identificazione da parte dei
clienti, è necessario indicare una o più directory a partire dalle quali si consente di accedere. Se
questo non viene indicato, si fa riferimento a ‘/tftpboot/’ in modo predefinito.
in.tftpd
[directory...]
Dal momento che il demone viene controllato dal supervisore dei servizi di rete, conviene controllare la configurazione di questo e, probabilmente, commentare la riga che invece ne attiverebbe il servizio. L’esempio seguente si riferisce al file ‘/etc/inetd.conf’ per quanto riguarda il
caso particolare di Inetd:
#tftp
dgram
udp
wait
root
/usr/sbin/tcpd
in.tftpd
Dal lato del cliente non c’è bisogno di nulla in particolare, tranne il programma ‘tftp’. Quando
si effettua la connessione con un servente TFTP, non viene richiesta alcuna parola d’ordine e non
viene eseguito alcun ‘chroot()’; tuttavia è consentito l’accesso alle sole directory dichiarate
nella riga di comando del demone corrispondente, oppure della sola ‘/tftpboot/’.
tftp
[host]
Il programma ‘tftp’ si comporta in modo simile a un cliente FTP (descritto nella parte xxviii), ma molto semplificato in confronto a quello. Il programma funziona in modo interattivo,
attraverso una serie di comandi che vengono inseriti quando viene visualizzando l’invito:
tftp>
Si può ottenere l’elenco dei comandi disponibili con il comando ‘?’.
A titolo di esempio viene mostrata la sequenza di una connessione ipotetica con il servente dinkel.brot.dg, allo scopo di prelevare una copia del file remoto ‘/tftpboot/
192.168.1.10/etc/crontab’.
$ tftp[ Invio ]
tftp> connect dinkel.brot.dg[ Invio ]
tftp> get /tftpboot/192.168.1.10/etc/crontab /tmp/mio_crontab[ Invio ]
1
netkit-tftp UCB BSD
1536
Trivial FTP
tftp> quit[ Invio ]
1537
Capitolo
145
NTP
Il protocollo NTP, Network time protocol consente di gestire una serie di nodi di rete in grado
di sincronizzare tra loro l’orologio interno di ognuno. Il problema della gestione di un orologio
uniforme a livello globale terrestre, non è facile da gestire; nello stesso modo non è facile da
descrivere. Lo scopo di del capitolo è solo quello di mostrare in che modo utilizzare un servizio
pubblico di questo tipo, per l’allineamento di un nodo di rete locale, con il quale si possono poi
allineare gli altri nodi della propria rete.
La dipendenza dall’esterno per quanto riguarda la gestione degli orologi dei propri elaboratori,
può costituire un problema di sicurezza. A questo proposito, il protocollo NTP offre anche la
possibilità di utilizzare comunicazioni cifrate e altri sistemi di sicurezza, che comunque qui
non vengono descritti.
Per l’accesso a un servente NTP in qualità di cliente e per la gestione di servente in proprio, si
utilizza generalmente la «distribuzione NTP», 1 rappresentata in pratica da un pacchetto che dovrebbe chiamarsi Ntp, o qualcosa del genere. I componenti più importanti di questa distribuzione
sono il demone ‘ntpd’ (oppure ‘xntpd’) e il programma ‘ntpdate’.
145.1 Accesso a un servente NTP
Per lo scopo di questo capitolo, si accede a un servente NTP solo per ottenere l’informazione
sull’ora esatta. Questo si ottiene molto facilmente con il programma ‘ntpdate’, che è anche in
grado di aggiustare l’orario del sistema. Tuttavia, prima di vedere come funziona, occorre sapere
dove è possibile ottenere tale servizio e quali sono le regole di comportamento.
Trascurando i problemi legati alla gestione dei serventi NTP pubblici, quello che c’è da sapere
è che questi sono organizzati in modo gerarchico a due livelli. L’accesso ai serventi del primo
livello è da escludere in generale, a meno che questo serva per gestire un servizio privato dal
quale attingono un numero molto grande di altri clienti; l’accesso ai serventi di secondo livello
è consentito quasi a tutti (ognuno ha la sua politica) e in generale il risultato è accurato in modo
più che sufficiente. Una volta chiarito che si accede di norma solo ai serventi di secondo livello,
è opportuno sceglierne alcuni relativamente vicini (per quanto questo non sia indispensabile).
L’elenco dei serventi NTP, con l’indicazione delle politiche rispettive, si trova a partire dall’URI <http://www.eecis.udel.edu/~mills/ntp/servers.html>. Ai fini degli esempi che si vogliono mostrare,
verranno utilizzati gli indirizzi di fantasia a.ntp.dg, b.ntp.dg e c.ntp.dg.
Per acquisire l’ora esatta da uno o più serventi NTP e per aggiustare di conseguenza l’orario del
sistema locale, si può usare ‘ntpdate’:
ntpdate
[opzioni]
servente_ntp ...
L’utilizzo di ‘ntpdate’ è adatto particolarmente per gli elaboratori che sono connessi alla rete
esterna solo saltuariamente, dal momento che si può effettuare l’allineamento esattamente nel
momento in cui ciò è possibile. Con l’uso delle opzioni necessarie, si può evitare che ‘ntpdate’
allinei l’orario del sistema, limitandosi a mostrare il risultato; in questi casi, può essere utilizzato
anche dagli utenti comuni e non soltanto da ‘root’.
‘ntpdate’ non può essere avviato se è già in funzione il demone ‘ntpd’, o un altro analogo.
Segue la descrizione di alcune opzioni della riga di comando.
1
NTP software libero con licenza speciale
1538
NTP
1539
Opzione
-b
-d
-q
-s
Descrizione
In condizioni normali, ‘ntpdate’ può scegliere di aggiustare l’orario aggiungendo o sottraendo secondi, oppure intervenendo sulla frequenza della base dei tempi. Per evitare che
venga scelta la seconda ipotesi, si utilizza questa opzione, che
limita la possibilità alla modifica dell’orario senza altri interventi. In condizioni normali, dovrebbe essere preferibile l’uso
di ‘ntpdate’ con questa opzione.
Invece di allineare l’orario del sistema, vengono mostrati i
passi compiuti da ‘ntpdate’, a scopo diagnostico.
Invece di allineare l’orario del sistema, mostra solo il risultato
dell’interrogazione dei serventi.
Invece di mostrare i messaggi sullo schermo, li devia nel registro del sistema, cosa che facilita l’utilizzo di ‘ntpdate’
all’interno di script avviati automaticamente in circostanze
determinate.
Gli esempi seguenti completano la descrizione del funzionamento di ‘ntpdate’.
• # ntpdate -q a.ntp.dg b.ntp.dg c.ntp.dg
Visualizza l’ora esatta ottenuta dai serventi a.ntp.dg, b.ntp.dg e c.ntp.dg.
• # ntpdate -b a.ntp.dg b.ntp.dg c.ntp.dg
Aggiusta l’orario del sistema in base a quanto determinato dai serventi a.ntp.dg,
b.ntp.dg e c.ntp.dg.
• # ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg
Come nell’esempio precedente, con la differenza che ogni segnalazione viene inviata nel
registro del sistema.
145.2 Preparazione di un servente NTP per l’utilizzo locale
La preparazione di un servente NTP per offrire il servizio solo alla propria rete locale, senza
pretendere di contribuire alla rete NTP pubblica, è un’operazione abbastanza semplice. In particolare, se il nodo di rete che svolge tale ruolo è connesso continuamente alla rete esterna, si può
usare lo stesso demone ‘ntpd’ per allineare l’orologio dell’elaboratore in cui si trova a funzionare, senza bisogno di utilizzare ‘ntpdate’, che tra le altre cose non può essere avviato se è già
attivo il demone.
Il funzionamento del demone ‘ntpd’ dipende dalla configurazione stabilita attraverso il file
‘/etc/ntp.conf’, mentre il programma ‘ntpdate’ ignora questo file completamente.
Il file ‘/etc/ntp.conf’ è il più importante per ciò che riguarda il funzionamento del demone
‘ntpd’. È composto da direttive che occupano ognuna una riga; i commenti sono preceduti dal
simbolo ‘#’ e nello stesso modo sono ignorate le righe bianche e quelle vuote. Senza entrare nel
dettaglio delle varie direttive disponibili, viene descritto un esempio di massima.
NTP
1540
# /etc/ntp.conf
logfile /var/log/xntpd
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# Serventi
server a.ntp.dg
server b.ntp.dg
server c.ntp.dg
L’elenco seguente descrive alcune di queste direttive del file di configurazione.
Direttiva
logfile file_delle_registrazioni
driftfile file_dello_scarto
statsdir directory_dei_file_statistici
statistics tipo_statistica ...
filegen tipo_statistica ←,→ file file ←,→ type tipo_di_analisi ←,→ enable disable
[
[
[
]
|
server host
]
]
[prefer]
Descrizione
Con la direttiva ‘logfile’ viene dichiarato il percorso del file delle registrazioni. Se non venisse utilizzata tale direttiva, i
messaggi di questo tipo sarebbero diretti normalmente al registro del sistema. Nel caso dell’esempio, si fa riferimento al
file ‘/var/log/xntpd’.
Con la direttiva ‘driftfile’ viene dichiarato il percorso del
file utilizzato da ‘ntpd’ per annotarsi lo scarto tra la frequenza dell’oscillatore locale e ciò che dovrebbe essere in realtà.
Dal momento che ‘ntpd’ deve poter cambiare nome al file
e ricrearlo nuovamente, non può trattarsi di un collegamento
simbolico. In generale, è sufficiente lasciare che sia ‘ntpd’ a
occuparsi di creare e gestire questo file.
Con la direttiva ‘statsdir’ viene dichiarato il percorso di
una directory all’interno della quale possono essere creati dei file di informazioni statistiche, dichiarati a loro volta
attraverso le direttive ‘statistics’ e ‘filegen’.
I tipi di informazioni statistiche che si vogliono accumulare
sono definiti attraverso la direttiva ‘statistics’, per mezzo di parole chiave prestabilite: ‘loopstats’, ‘peerstats’
e ‘clockstats’. In generale, conviene attivare la gestione
di tutti i tipi di informazioni statistiche, così come si vede
nell’esempio.
Per abbinare all’accumulo di un tipo di statistica un file vero e proprio, si utilizza la direttiva ‘filegen’. Nell’esempio
vengono creati tre file, con il nome corrispondente al tipo di
statistica di cui si occupano.
Per la precisione, la direttiva ‘filegen’ serve anche per definire il modo in cui vanno gestite diverse generazioni dei file
che vengono creati. In pratica, il tipo stabilito attraverso l’argomento dell’opzione ‘type’, permette di indicare con quale
frequenza devono essere archiviati i file. L’esempio mostra
la richiesta di utilizzare generazioni giornaliere (l’argomento
‘day’) e questo, salvo esigenze particolari, dovrebbe andare
bene in generale.
Le direttive più importanti per lo scopo che ci si prefigge in
questo capitolo, sono quelle che stabiliscono i nomi dei serventi di riferimento per ottenere le informazioni sull’orario.
In generale, più sono questi serventi, meglio è.
Se uno di questi serventi viene considerato come quello più attendibile, si può aggiungere la parola chiave ‘prefer’, come
si vede nello schema sintattico.
NTP
1541
Il demone ‘ntpd’ (oppure ‘xntpd’) serve da una parte per allineare continuamente l’orario del
sistema locale, quando questo si trova connesso costantemente a una rete che gli consente di
accedere ai suoi serventi di riferimento, in base alla configurazione del file ‘/etc/ntp.conf’,
con le direttive ‘server’. Dall’altra parte, questo demone offre anche il servizio NTP, basandosi
sull’orologio del sistema locale:
ntpd
[opzioni]
In una rete chiusa, in cui non ci sia la possibilità di raggiungere altri serventi NTP, il demone
‘ntpd’ può essere utile per allestire il proprio servizio NTP locale, in modo da assicurare la
sincronizzazione degli altri elaboratori della propria rete.
All’interno di questi due estremi, in una rete in cui un nodo abbia saltuariamente accesso alla rete
esterna, quel nodo può essere allineato (quanto possibile), al tempo di riferimento ottenuto dall’esterno, fungendo da servente locale per l’allineamento successivo della propria rete. Tuttavia,
in questo caso si aggiunge il problema di procedere all’allineamento in base alle fonti esterne,
esattamente nel momento in cui il collegamento è disponibile; ma per questo si utilizza prevalentemente il programma ‘ntpdate’, che però non può essere avviato quando il demone è già in
funzione. Il problema viene riproposto in questo stesso capitolo.
Opzione
-c file_di_configurazione
-d
-l file_delle_registrazioni
-f file_dello_scarto
-s directory_dei_file_statistici
Descrizione
In generale, il file di configurazione utilizzato da ‘ntpd’ è
‘/etc/ntp.conf’. Con questa opzione si può indicare un file
differente, oppure si può confermare la collocazione standard,
nel caso i sorgenti siano stati compilati indicando posizioni
differenti.
La presenza di questa opzione, che può essere indicata anche
ripetutamente, aumenta il livello di dettaglio delle informazioni diagnostiche che si ottengono (nel registro del sistema o
in un altro file stabilito in base alla configurazione).
Equivalente alla direttiva ‘logfile’ nel file di configurazione.
Equivalente alla direttiva ‘driftfile’ nel file di configurazione.
Equivalente alla direttiva ‘statsdir’ nel file di configurazione.
L’esempio seguente mostra uno script molto semplificato per l’avvio e la conclusione del servizio
NTP, attraverso il controllo del demone ‘ntpd’. In pratica, il demone viene avviato senza opzioni
di alcun tipo, confidando che legga correttamente il file di configurazione.
#!/bin/sh
test -f /usr/sbin/ntpd || exit 0
case "$1" in
start)
echo -n "Avvio del servizio NTP: "
/usr/sbin/ntpd
echo
;;
stop)
echo -n "Disattivazione del servizio NTP: "
killall ntpd
echo
;;
*)
echo "Utilizzo: ntpd {start|stop}"
exit 1
esac
1542
NTP
Alcune distribuzioni GNU/Linux predispongono uno script del genere, in cui, prima dell’avvio
del demone ‘ntpd’ eseguono ‘ntpdate’ per iniziare con un orologio già allineato. In generale,
questa potrebbe essere una buona idea; tuttavia, se questo script viene avviato quando non si
può accedere ai serventi NTP a cui si vuole fare riferimento, ‘ntpdate’ blocca la procedura
di avvio troppo a lungo.
Il pezzo di script che segue rappresenta proprio il caso in cui viene avviato anche ‘ntpdate’
prima di mettere in funzione ‘ntpd’. Si osservi il fatto che nella riga di comando devono apparire
i serventi NTP, perché il file di configurazione di ‘ntpd’ non lo riguarda.
start)
echo -n "Avvio del servizio NTP: "
/usr/sbin/ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg
/usr/sbin/ntpd
echo
;;
145.3 Gestire una rete locale collegata saltuariamente
alla rete esterna
Da quanto scritto fino a qui, in questo capitolo dedicato a NTP, si dovrebbe riuscire già a immaginare in che modo ci si potrebbe comportare per allestire un servizio NTP locale, sfruttando un
accesso esterno saltuario, per esempio attraverso una connessione PPP con una linea commutata (PSTN o ISDN). Di certo, conviene collocare il servente locale nell’elaboratore che compie
saltuariamente questa connessione e che in quel momento ha un accesso normale all’esterno:
nel momento in cui si può accedere alla rete esterna, si può utilizzare ‘ntpdate’ per allineare
l’orario dell’elaboratore stesso.
Come è già stato accennato, si pone un problema a causa del fatto che lo stesso elaboratore deve
avere in funzione il demone ‘ntpd’, che impedisce l’avvio di ‘ntpdate’. Evidentemente, per
risolvere il problema, occorre giocare sulla conclusione e riavvio del demone. La soluzione proposta è molto semplice: per prima cosa, lo script che avvia il demone ‘ntpd’ nella procedura di
inizializzazione del sistema, non deve comprendere anche l’avvio di ‘ntpdate’; quindi occorre
predisporre l’avvio di ‘ntpdate’ solo quando la connessione PPP è disponibile (capitolo 127 e
successivi).
#!/bin/sh
/etc/init.d/ntpd stop
/usr/sbin/ntpdate -b -s a.ntp.dg b.ntp.dg c.ntp.dg
/etc/init.d/ntpd start
Quello che si vede è uno script molto semplice, il cui scopo è quello di disattivare il servizio
NTP, richiamando lo script ‘/etc/init.d/ntpd’ con l’argomento ‘stop’, prima di avviare
‘ntpdate’ (eventualmente questo script potrebbe trovarsi in un’altra directory e anche il suo
nome potrebbe essere differente). Dopo l’allineamento, il servizio NTP viene riavviato in modo
analogo.
Per fare in modo che tutto avvenga automaticamente, questo script potrebbe essere avviato attraverso ‘/etc/ppp/ip-up’, che è un altro script avviato dal demone ‘pppd’ ogni volta che si
attiva una connessione PPP.
La predisposizione dei clienti della rete locale non dovrebbe costituire alcun problema: si dispone
di un solo servente di riferimento e ci si può limitare a utilizzare ‘ntpdate’, eventualmente
riavviandolo periodicamente attraverso Cron.
NTP
1543
145.4 Riferimenti
• David L. Mills, Public NTP Time Servers
<http://www.eecis.udel.edu/~mills/ntp/servers.html>
Capitolo
146
IRC
IRC è un sistema di comunicazione in tempo reale per discussioni pubbliche, o private, in forma
scritta. Di per sé, IRC è l’evoluzione della comunicazione attraverso ‘talk’ (capitolo 142).
146.1 Infrastruttura
Lo scopo di IRC, ovvero la realizzazione di un sistema di discussione pubblica a livello globale,
richiede un’infrastruttura composta dai serventi IRC articolati in modo da formare una «rete»
IRC.
Ragionando in piccolo, si può pensare alla realizzazione di un servente IRC singolo, presso il
quale si devono connettere tutte le persone che vogliono instaurare una forma di discussione
qualunque. La distanza non è necessariamente un problema per chi si connette; tuttavia, diventa
un problema la quantità di connessioni che verrebbero a essere aperte in modo simultaneo. Nella
realtà, queste connessioni possono essere molto numerose (diverse migliaia), soprattutto a causa
della filosofia di IRC per la quale l’organizzazione dei canali di discussione è libera, per cui è
indispensabile la presenza di un’infrastruttura che sia in grado di recepire tale massa di utenze.
Si parla di reti IRC, a indicare i gruppi di elaboratori che gestiscono assieme gli stessi canali
di comunicazione. Tali reti sono composte secondo una struttura ad albero, dove esiste un solo
percorso possibile tra due nodi. Naturalmente, queste reti IRC si inseriscono praticamente sulla
rete Internet, sfruttando il protocollo TCP per il transito delle informazioni.
Figura 146.1. Rete di serventi IRC.
a
d--------e
|
|
|
|
|
|
b--------c--------f
k
|
|
|
|
|
|
g--------h--------i--------l
|
|
|
|
|
|
j
m
L’organizzazione della rete IRC è importante per fare in modo che transitino al suo interno solo
le informazioni che sono indispensabili, dal momento che il volume di messaggi gestiti è enorme.
A livello di rete IRC si può individuare una persone con un ruolo speciale: l’operatore IRC.
L’operatore IRC è l’amministratore di uno o più serventi IRC, nel senso che può impartire a
questi dei comandi speciali, relativi al loro funzionamento.
146.2 Canali, utenti e operatori
In una rete IRC, le comunicazioni avvengono all’interno di canali creati dinamicamente; gli
utenti della rete IRC sono individuati in base a un nominativo, definito nick. Non esiste una
regola nell’uso dei nominativi di identificazione degli utenti e nell’organizzazione dei canali di
comunicazione: l’utente che si presenta nella rete IRC chiede di usare un nominativo e lo ottiene
se questo non è già utilizzato; l’utente che chiede di accedere a un canale di comunicazione che
non esiste, lo crea automaticamente e ne diventa il suo operatore.
1544
IRC
1545
Naturalmente, un utente che cerca di accedere a una rete IRC lo fa connettendosi a un servente
IRC di quella rete; ma questo servente può definire una sua politica di accessi, per cui l’utente
in questione potrebbe anche non essere ammesso ad accedere.
È importante comprendere la filosofia di IRC per ciò che riguarda i canali: questi vengono creati
automaticamente nel momento in cui vengono richiesti per la prima volta; quindi scompaiono
nel momento in cui non ci sono più utenti collegati al loro interno. È importante anche chiarire
il senso dell’operatore: si tratta dell’utente che crea inizialmente il canale, ovvero dell’utente che
riceve questo privilegio da un altro operatore. L’operatore, noto anche con l’abbreviazione di
«oper», oppure solo «op», ha la possibilità di stabilire la modalità di funzionamento del canale e
può anche allontanare altri utenti dal canale stesso. Segue l’elenco delle modalità più importanti
di un canale che sono controllate dall’operatore:
• si può accedere al canale a richiesta, oppure solo a seguito di un invito;
• si può specificare una parola d’ordine per l’accesso al canale;
• si può specificare il numero massimo di accessi, oltre l’operatore;
• si può rendere il canale moderato, per cui in pratica scrive solo l’operatore e gli utenti da
lui autorizzati;
• si può bloccare la scrittura nel canale;
• si possono concedere i privilegi di operatore anche a un altro utente;
• si può rendere il canale privato, nel senso che non ne viene pubblicizzata la presenza;
• si può rendere il canale segreto, nel senso che non lo si vuole fare apparire nell’elenco dei
canali presenti.1
Oltre al controllo sul funzionamento del canale, l’operatore può intervenire in modo privilegiato:
• può specificare il fatto che si tratti di un canale a tema;
• può consentire a un utente di scrivere in un canale moderato;
• può allontanare un utente o gruppi di utenti;
• può concedere un’eccezione nel caso di un canale che richieda l’invito.
Ogni utente, tra le altre cose, ha la possibilità di configurare il proprio accesso al canale in modo
da rendersi parzialmente invisibile.
146.2.1 Divisione e ricongiunzione di reti IRC
Una rete IRC può essere spezzata nel momento in cui un nodo che non è terminale cessa di
funzionare per qualche ragione, oppure quando viene dato espressamente questo ordine da un
operatore IRC. In questa situazione si formano due reti, in cui continuano a funzionare i canali
per quanto possibile. Naturalmente, gli utenti che accedono a una di queste due reti risulteranno
isolati rispetto all’altra rete.
La divisione della rete provoca quindi una crisi temporanea che alla fine si riassesta in qualche
modo più o meno automatico. Il vero problema nasce nel momento in cui le reti vengono riunite:
i canali con lo stesso nome vengono fusi assieme, riunendo gli utenti. Questa riunione può creare
un po’ di scompiglio, considerando che la modalità di funzionamento dei canali viene riadattata
in modo da armonizzare le eventuali incompatibilità e che gli operatori vengono a sommarsi.
1
In generale un canale può essere privato, segreto oppure pubblico.
IRC
1546
146.3 Comportamenti spiacevoli
IRC è un sistema di comunicazione in cui gli utenti sono presenti simultaneamente nel momento
in cui scrivono e leggono i messaggi. Nelle discussioni più o meno pubbliche come queste è comune il fatto che chi non sa stare alle regole di una discussione civile decida invece di esprimersi
attraverso il dispetto, con la pretesa di dimostrare così la propria intelligenza.
Queste situazioni sono così comuni che ne derivano dei termini standard il cui significato
dovrebbe essere conosciuto:
• bot è un programma cliente automatico che funziona in modo autonomo (robot), senza un
utente che sta comunicando effettivamente;
• cloner è un utente che sta utilizzando presumibilmente più programmi clienti, ognuno dei
quali è un clone in questo contesto;
• flooder è colui che inonda in qualche modo un utente allo scopo di allontanarlo dalla
comunicazione.
Il bot, ovvero il programma che usa IRC da solo, è il mezzo attraverso cui si compiono degli
attacchi, altrimenti non ci sarebbe bisogno di un programma automatico, dato che IRC è fatta per
comunicare tra esseri umani.
Il fatto di utilizzare diversi programmi clienti, mentre ne basterebbe uno solo per comunicare anche su più canali, può rappresentare l’intenzione di fare qualcosa di più della semplice
comunicazione.
La realizzazione di un servente IRC isolato è un’operazione relativamente semplice, limitando
il problema alla definizione di una politica di accessi al servizio. Qui non viene mostrato in che
modo organizzare invece una vera rete IRC, che evidentemente è un problema più impegnativo.
146.5 Ircd
Ircd 2 è il servente IRC tipico dei sistemi Unix. In generale sono essenziali solo due file: l’eseguibile ‘ircd’ e il file di configurazione ‘ircd.conf’, che in un sistema GNU dovrebbe trovarsi
nella directory ‘/etc/ircd/’.
Ircd può essere avviato in modo autonomo, senza l’intervento del supervisore dei servizi di rete,
oppure sotto il suo controllo. Nel secondo caso, per quanto riguarda Inetd, si deve provvedere a
sistemare il file ‘/etc/inetd.conf’ aggiungendo la riga seguente:
ircd
stream
tcp
wait
irc
/usr/sbin/ircd ircd -i
Come si può osservare dall’esempio, conviene avviare l’eseguibile ‘ircd’ usando i privilegi di
un utente fittizio definito appositamente per la gestione del servizio IRC; in questo caso si tratta
di ‘irc’.
Come si può osservare ancora dall’esempio riferito al file ‘/etc/inetd.conf’, si fa riferimento alla porta TCP attraverso la denominazione ‘ircd’, che di solito, secondo il file ‘/etc/
services’ corrisponde al numero 6667:
2
Ircd GNU GPL con residui UCB BSD
IRC
ircd
ircd
1547
6667/tcp
6667/udp
# Internet Relay Chat
# Internet Relay Chat
Si intende che si tratta di una porta non privilegiata, giustificando la scelta di usare un utente
fittizio diverso da ‘root’ per avviare ‘ircd’.
Il demone ‘ircd’ può essere configurato in modo da gestire autonomamente il protocollo IDENT e altri sistemi di controllo. In questo senso, generalmente non viene inserito il
controllo del TCP wrapper.
146.5.1 Messaggio del giorno
Nel momento di una nuova connessione al servizio IRC, il servente mostra il messaggio del giorno, che in un sistema GNU/Linux potrebbe essere contenuto nel file ‘/etc/ircd/ircd.motd’
(si tratta di un file di testo normale).
In generale è importante predisporre questo file in modo da mostrare le notizie essenziali
che si vogliono far conoscere agli utenti IRC, soprattutto per ciò che riguarda le regole di
comportamento richieste.
146.5.2 Configurazione
La configurazione può essere molto semplice per la realizzazione di un servente IRC interno,
per una rete che non può essere raggiunta dall’esterno, ma ovviamente le cose cambiano nel
momento in cui si vuole realizzare una rete IRC. Qui vengono mostrati solo alcuni elementi della
configurazione, utili per realizzare un servente singolo, senza problemi di accesso.
Il file di configurazione è un file di testo normale, dove le righe che iniziano con il simbolo ‘#’
sono commenti e le righe vuote o bianche vengono ignorate. Le direttive hanno una forma un
po’ strana, dove tutto inizia con una lettera che descrive il tipo di informazione che viene fornita
dalla direttiva:
x :informazione_1 :informazione_2 :...:informazione_n
In generale si dovrebbe disporre di un file di configurazione di partenza commentato adeguatamente, con tutti gli esempi di queste direttive (anche se mostrate solo come commenti). Qui
vengono descritte alcune direttive essenziali per la realizzazione di un servente IRC locale e
isolato.
Una cosa da considerare nel caso il file contenga direttive che devono essere elaborate secondo
un ordine preciso è il fatto che il file viene letto in ordine inverso, ovvero vengono lette prima
le ultime direttive.
M
M:nome_del_servente :*:descrizione :porta:numero_servente
Questa direttiva serve a definire il nome di dominio del servente, la descrizione del servizio
IRC, la porta in cui resta in ascolto il servente e il numero di ordine nella rete IRC. Questo
ultimo numero è un intero che va da 1 a 64 e va stabilito in base alla gerarchia di una rete
IRC; se si tratta dell’unico servente, deve essere necessariamente indicato il numero uno,
come si vede nell’esempio seguente:
M:dinkel.brot.dg:*:Mia IRC:6667:1
IRC
1548
Nel caso in cui il demone ‘ircd’ venga utilizzato attraverso il controllo del supervisore dei
servizi di rete, potrebbe essere necessario indicare una porta diversa da quella standard, per
non interferire proprio con il supervisore stesso, che già apre quella porta. Per esempio:
È da considerare il fatto che un demone ‘ircd’ compilato espressamente per l’utilizzo
attraverso il supervisore dei servizi di rete potrebbe non essere in grado di funzionare in
modo autonomo, in ogni caso.
A
A:riga_1:riga_2:...:riga_n
Si tratta della direttiva con cui si definiscono una serie di informazioni amministrative, che
vengono elencate con il comando ‘/admin’. In pratica viene mostrato il contenuto dei campi in righe differenti. Si osservi l’esempio seguente che dovrebbe essere sufficientemente
intuitivo:
A:Mia IRC:Servente IRC:Amministratore <[email protected]>
I
I:maschera_ip :parola_d’ordine :maschera_dominio ::classe
Questa direttiva stabilisce i limiti di accesso al servizio in base a una maschera IP e a
una maschera del nome di dominio; queste maschere si riferiscono ovviamente ai nodi che
accedono come clienti. Le maschere in questione si realizzano facilmente utilizzando il
simbolo ‘*’ come variabile indefinita. In generale, l’esempio seguente consente qualsiasi
accesso:
I:*::*::1
Il campo finale, riferito alla classe, deriva dalla definizione delle classi attraverso le direttive
‘Y’ che qui non vengono descritte, non essendo indispensabili. In ogni caso, il numero uno
rappresenta tutte le classi possibili simultaneamente.
Il campo centrale riservato a una parola d’ordine serve a consentire l’accesso solo attraverso l’indicazione di questa. Tuttavia, a seconda di come è stato compilato il demone
‘ircd’, questa potrebbe dover essere inserita in modo cifrato. In tal caso dovrebbe anche
essere presente un programma apposito per generare tali parole d’ordine cifrate.
K
K:maschera_nodo :motivazione :maschera_utente
Questa direttiva, che non è obbligatoria, consente di escludere esplicitamente una combinazione di nodi e di utenti che tentano di accedere da questi nodi. Le maschere in questione
si realizzano con l’uso del carattere ‘*’, che rappresenta la solita stringa indefinita. In particolare, il nodo può essere indicato per nome (di dominio) oppure per numero IP. L’esempio
seguente esclude gli utenti il cui nome inizia per ‘dan’ e accedono dalla rete *.brot.dg:
K:*.brot.dg:Accesso sospeso per un mese:dan*
Per concludere la descrizione della configurazione, l’esempio seguente mostra il caso di una
configurazione minima, con le sole direttive indispensabili:
A:Mia IRC:Servente IRC:Amministratore <[email protected]>
I:*::*::1
IRC
1549
146.5.3 Avvio del demone
ircd
[opzioni]...
Il demone ‘ircd’ può funzionare in due modi diversi: legato al supervisore dei servizi di rete,
oppure indipendentemente da questo. Nel primo caso si utilizza l’opzione ‘-i’ e nel file ‘/etc/
inetd.conf’ non si inserisce il controllo di ‘tcpd’, perché si creerebbero dei problemi a causa
dell’uso del protocollo IDENT:
ircd
stream
tcp
wait
irc
/usr/sbin/ircd ircd -i
Diversamente, il demone può essere avviato come un comando normale, senza nemmeno dover
aggiungere la richiesta esplicita di funzionamento sullo sfondo. In effetti, dal momento che si
utilizza normalmente una porta TCP non privilegiata, ogni utente comune può, teoricamente,
avviare questo tipo di servizio.
Segue l’elenco di alcune opzioni della riga di comando di ‘ircd’.
Opzione
-t
-xn
-i
-f file_di_configurazione
-c
Descrizione
Fa in modo che il demone funzioni in primo piano, emettendo
tutte le sue informazioni diagnostiche attraverso lo standard
output.
Definisce il livello diagnostico richiesto: maggiore è il valore
n , maggiore la quantità di informazioni che si ottengono.
Stabilisce che il demone è sotto il controllo del supervisore
dei servizi di rete.
Stabilisce espressamente da quale file trarre la configurazione.
Si usa questa opzione quando si avvia il demone attraverso
uno script della procedura di inizializzazione del sistema, per
cui è necessario che il demone stesso si sganci dallo script e
diventi un processo dipendente direttamente da Init.
Il compito di un programma cliente IRC è quello di consentire la comunicazione effettiva tra
l’utente umano e il servente IRC. La prima cosa che avviene è la registrazione, attraverso la
quale l’utente ottiene l’accesso al servizio assieme alla definizione del proprio nominativo.
Una volta instaurata la connessione, l’utente ha la possibilità di unirsi a uno o più canali di
discussione, creandoli automaticamente se questi non sono già presenti.
146.7 ircII
ircII 3 è il programma cliente standard per comunicare con IRC. Si utilizza attraverso un terminale a caratteri normale, dove lo schermo è diviso in due parti: quella superiore per mostrare i
messaggi che scorrono verso l’alto; quella inferiore che è semplicemente la riga da cui si impartiscono i comandi. Il programma eseguibile è ‘irc’ e si avvia in maniera molto semplice, come
nell’esempio seguente, dove viene specificato il nominativo desiderato e l’indirizzo del servente
IRC:
$ irc tizio dinkel.brot.dg[ Invio ]
3
ircII software libero con licenza speciale
IRC
1550
*** Welcome to the Internet Relay Network tizio (from dinkel.brot.dg)
*** /etc/irc/script/local V0.5 for Debian finished. Welcome to ircII.
*** If you have not already done so, please read the new user information with
+/HELP NEWUSER
*** Your host is dinkel.brot.dg, running version u2.10.07.0
*** This server was created Fri Dec 17 1999 at 19: 54:56 CST
*** umodes available dioswkg, channel modes available biklmnopstv
*** There are 1 users and 0 invisible on 1 servers
*** This server has 1 clients and 0 servers connected
*** Highest connection count: 1 (1 clients)
*** - dinkel.brot.dg Message of the Day *** - 16/3/2001 20:44
*** - Benvenuto presso irc.brot.dg
*** *** on 1 ca 1(2) ft 10(10)
________________________________________________________________________________
[1] 20:45 tizio * type /help for help
_
In questo caso, il messaggio del giorno è soltanto «Benvenuto presso irc.brot.dg», che si vede in
basso; il resto è stato generato automaticamente dal servente. La riga contenente la stringa
[1] 20:45 tizio * type /help for help
è la linea di demarcazione tra la parte superiore contenente i messaggi e la parte inferiore riservata
ai comandi dell’utente. Come si può vedere, viene suggerito l’uso del comando ‘/help’ per
richiamare l’elenco dei comandi disponibili.
Se si impartisce il comando ‘/help’, come suggerito, si passa a un contesto differente, in cui si
possono ottenere informazioni dettagliate su questo o quel comando:
/help[ Invio ]
!
:
abort
admin
assign
away
basics
beep
brick
bye
cd
channel
commands
comment
connect
ctcp
dcc
deop
describe
die
dmsg
dquery
echo
encrypt
eval
exec
exit
expressions
foreach
help
history
hook
if
ignore
info
input
invite
ircii
ison
join
kill
lastlog
leave
links
load
lusers
me
menus
mode
motd
msg
names
newuser
nick
note
notice
on
oper
parsekey
part
query
quit
quote
rbind
rehash
restart
rules
save
send
sendline
server
servlist
signoff
sleep
squery
squit
summon
time
timer
topic
type
userhost
users
version
wallops
which
while
who
whowas
window
xecho
xtype
[1] 20:56 daniele * type /help for help
Help? _
alias
bind
clear
date
digraph
etiquette
flush
icb
intro
kick
list
mload
news
notify
ping
redirect
say
set
stats
trace
wait
whois
Si può osservare dalla figura che nella riga di comando appare un invito, che prima non era
presente: ‘Help?’, a significare che si può indicare il nome di un comando di quelli elencati per
conoscerne la sintassi. Per esempio:
IRC
1551
Help? help[ Invio ]
*** Help on help
Usage: HELP [<command> [<subcommands>]]
Shows help on the given command. The help documentation is
set up in a hierarchical fashion. That means that certain
help topics have sub-topics under them. For example, doing
HELP ADMIN
gives help on the admin command, while:
HELP SET
gives help on the set command and also displays a list of
sub-topics for SET. To get help on the subtopics, you would
do:
HELP SET <subtopic>
where <subtopic> is one of the subtopics. If you are using the
built in help, then you need only type the subtopic name. The
input prompt will indicate what help level you are on. Hitting
return will move you up one level.
At any time, you can specify a ? to get a list of subtopics
without the associated help file, for example:
HELP ?
gives a list of all main help topics. The following:
HELP BIND ?
gives the list of all BIND subtopics. If you use a ? with
[1] 21:00 daniele * type /help for help
*** Hit any key for more, ’q’ to quit ***
Come si vede, se non c’è abbastanza spazio per visualizzare tutto il testo disponibile, basta digitare un carattere qualunque per vedere la pagina successiva, oppure basta inserire la lettera ‘q’
per terminare.
Alla fine della navigazione nella guida interna, basta premere il tasto [ Invio ] senza specificare il
nome di alcun comando per ritornare alla modalità di funzionamento normale, dove non appare
alcun invito.
Help? [ Invio ]
I comandi impartiti a ircII sono preceduti dal simbolo ‘/’, per distinguerli dal testo dei
messaggi che invece vanno inviati al canale di discussione.
Generalmente, quando ci si trova di fronte all’invito normale, è possibile richiamare i comandi
precedenti scorrendo con i tasti [ freccia su ] e [ freccia giù ].
Si conclude il funzionamento di ircII con il comando ‘/quit’.
146.8 Tkirc
Tkirc 4 è un programma frontale per ircII. Il programma eseguibile è ‘tkirc’ e si avvia in maniera molto semplice, come nell’esempio seguente, dove viene specificato il nominativo desiderato
e l’indirizzo del servente IRC:
$ tkirc tizio dinkel.brot.dg
4
Tkirc GNU GPL
IRC
1552
Figura 146.2. Schermata iniziale all’avvio di Tkirc.
Utilizzando il menù a tendina, è possibile ottenere un’altra finestra con la quale comunicare in
un altro canale. Si utilizza precisamente la voce New window dal menù Project.
Nella colonna destra, vengono elencati gli utenti che partecipano al canale con cui si sta comunicando. Con un clic doppio del mouse si ottengono le informazioni su di loro, come si vede nella
figura 146.3.
Figura 146.3. Informazioni sugli utenti collegati allo stesso canale.
146.9 Utilizzo di massima di un cliente IRC
Generalmente, prima di entrare in un canale si può avere l’interesse di visualizzare l’elenco di
quelli disponibili. Questo si ottiene con il comando ‘/list’. Per esempio, con ircII:
/list[ Invio ]
IRC
*** Channel
*** #prova
*** #pippo
1553
Users
1
3
Topic
Come si vede, il nome di un canale inizia con il carattere ‘#’ per convenzione. In alternativa, il
nome di un canale può iniziare anche per ‘&’, ma in tal caso si tratta di un canale che riguarda
esclusivamente il servente al quale si è connessi, per cui non si diffonde agli altri serventi della
stessa rete IRC.
Nello stesso modo, può essere utile visualizzare l’elenco degli utenti collegati. Questo si ottiene
con il comando ‘/names’, che va usato comunque con parsimonia, considerando che una rete
IRC «normale» è sempre molto affollata.
/names[ Invio ]
Pub: #prova
Pub: #pippo
tizio @daniele
caio @sempronio
Nell’elenco degli utenti, gli operatori di canale sono evidenziati dal prefisso ‘@’. Eventualmente,
se si vede il simbolo ‘*’ come prefisso, si tratta di un operatore IRC.
Il programma cliente che si utilizza potrebbe attribuire automaticamente il nominativo per accedere alla rete IRC, sfruttando presumibilmente il nominativo utente usato per accedere al proprio
elaboratore. Se il nome in questione non è compatibile, eventualmente perché già utilizzato, è il
programma cliente stesso che richiede di indicare un altro nominativo. In ogni caso, è possibile
cambiare il proprio nome attraverso il comando ‘/nick’:
/nick pinco[ Invio ]
L’esempio mostra il caso in cui l’utente desideri usare il nome ‘pinco’, ammesso che questo non
sia già utilizzato nella rete IRC in cui si è connessi.
Il nominativo usato all’interno di una rete IRC non può essere più lungo di nove caratteri.
Ci si aggrega a un canale con il comando ‘/join’. Se il canale indicato non esiste ancora, viene
creato per l’occasione e l’utente che lo crea ne diventa l’operatore.
/join #prova[ Invio ]
L’esempio mostra il caso in cui ci si voglia aggregare al canale ‘#prova’. È importante ricordare
che è necessario il prefisso davanti al nome, come si vede dall’esempio.
Quando ci si trova in un canale, ciò che si digita senza il prefisso ‘/’, viene trasmesso al canale
stesso:
Ciao a tutti![ Invio ]
Come ci si unisce a un canale, ci si può allontanare. Questo si ottiene con il comando ‘/leave’:
/leave #prova[ Invio ]
Segue il riepilogo di alcuni comandi essenziali per l’uso di un cliente IRC.
Comando
[opzioni]
/names [opzioni] [canale]
/list
/nick nome
Descrizione
Elenca i canali presenti nella rete IRC.
Elenca gli utenti presenti nella rete IRC, oppure solo quelli
presenti in un canale particolare.
Consente di modificare, o di stabilire, il proprio nominativo
nell’ambito della rete IRC.
IRC
1554
Comando
/who canale
[
/whois nome ,nome
]...
/join canale
/msg nome messaggio
/dcc chat nome
/msg =nome messaggio
/quit
[messaggio]
Descrizione
Consente di elencare gli utenti che sono presenti nel canale
indicato.
Consente di elencare le informazioni disponibili sugli utenti
elencati. I nomi possono essere anche composti con caratteri
jolly, ovvero con l’uso dell’asterisco per indicare una stringa
qualunque.
Consente di entrare in un canale.
Consente di inviare un messaggio esclusivamente all’utente
indicato.
Invia all’utente indicato una richiesta per instaurare una
connessione privilegiata tra i due. Se l’altro utente risponde con lo stesso comando, si ottiene questa connessione.
Per comunicare in modo privato, i due usano il comando
‘msg =nome ...’.
Invia un messaggio esclusivamente all’utente indicato, che già
prima era stato collegato con un comando ‘/dcc chat’.
Chiude il funzionamento del programma cliente, ma prima si
allontana dal canale, se necessario, inviando eventualmente il
messaggio indicato.
146.10 Riferimenti
• Internet Relay Chat (IRC) help
<http://www.irchelp.org/>
• David Caraballo, Joseph Lo, The IRC prelude
<http://www.irchelp.org/irchelp/new2irc.html>
Capitolo
147
ICQ: «I-seek-you»
ICQ è un sistema di comunicazione, ideato allo scopo di consentire agli utenti di informare la
loro presenza nella rete, permettendo anche l’instaurazione di un contatto immediato, oltre alla possibilità di mostrare alcune informazioni personali. ICQ è un’invenzione di Mirabilis, oggi
ICQ Inc., che gestisce i serventi ICQ. In altri termini, almeno per ora, non si tratta di un servizio
pubblico come potrebbe essere Usenet, a cui si può partecipare anche con un proprio servente; tuttavia viene fornito gratuitamente e sono disponibili alcuni programmi cliente realizzati
secondo la filosofia del software libero.
Ciò che si conosce del protocollo di ICQ è stato ottenuto principalmente dalla sperimentazione,
anche analizzando i pacchetti trasmessi e ricevuti dai programmi standard. La documentazione
più importante al riguardo si può ottenere a partire da <http://www.student.nada.kth.se/~d95-mih/icq/>,
The ICQ protocol site.
147.1 Principio di funzionamento
Attraverso ICQ un utente si registra presso un servente, specificando una parola d’ordine. Il
servente assegna all’utente un numero, definito UIN, ovvero Universal Internet number, e da
quel momento si stabilisce l’abbinamento tra UIN e parola d’ordine. Successivamente l’utente
può abbinare a questo numero qualche informazione in più su di sé.
Da quel momento, l’utente si collega al servente ICQ quando desidera annunciare la sua presenza
nella rete. Il servente ICQ accetta l’utente dopo aver confrontato il numero UIN con la parola
d’ordine stabilita originariamente.
Quando un utente ICQ cerca un contatto con un altro utente, può fare una ricerca in base al numero UIN e poche altre informazioni. Quando ha determinato il numero UIN del suo interlocutore,
può ottenere dal servente ICQ l’indirizzo IP e la porta presso cui questa persona ha attivato il suo
programma cliente, iniziando così una connessione diretta (per colloquiare o per altri scopi).
Il servente ICQ è in ascolto normalmente alla porta 4000, o eventualmente anche ad altre porte
superiori. Tuttavia, va considerato il fatto che buona parte della comunicazione con il servente
avviene attraverso il protocollo UDP (non connesso), mentre le connessioni dirette con gli interlocutori usano il protocollo TCP. Da questo e da quanto esposto sopra, si arriva alle conclusioni
seguenti:
• si possono notare delle intermittenze nel funzionamento, per esempio quando si interroga
l’elenco degli utenti, per cui una volta sembra che non ci siano utenti con le caratteristiche
richieste, altre volte si ottiene un risultato soddisfacente;
• non si può accedere al servizio se si deve attraversare un firewall che blocca i pacchetti del
protocollo UDP;
• diventa difficile attraversare un NAT/PAT, ovvero un router speciale in grado di trasformazione indirizzi IP e porte di una rete privata (capitolo 176), perché di solito si interviene
a livello di protocolli basati su TCP e su ICMP, inoltre si aggiunge il problema di essere
reperibili nei confronti dell’esterno.1
1
Non ha senso pubblicizzare un indirizzo IP di una rete privata che non risulta accessibile da Internet.
1555
ICQ: «I-seek-you»
1556
147.2 Cliente ICQ:
ICQ non si basa su un protocollo pubblico e non è garantita la compatibilità con il passato, per cui
diventa difficile l’aggiornamento dei programmi realizzati per comunicare con questo servizio,
senza disporre di informazioni ufficiali sul protocollo stesso.
Esistono diversi programmi cliente liberi per comunicare con ICQ, ma pochi funzionano, a causa
degli aggiornamenti che ha subito il protocollo. Qui viene proposto GnomeICU, 2 ovvero «Gnome I-see-you» che, appartenendo a un progetto di ampio respiro, promette di essere aggiornato
adeguatamente nel futuro.
147.2.1 Avvio e utilizzo elementare
La prima volta che si avvia GnomeICU (con l’eseguibile ‘gnomeicu’), viene proposta la
registrazione presso un servente ICQ, in modo da ottenere un numero UIN (figura 147.1).
Figura 147.1. Avvio di GnomeICU la prima volta.
Se si seleziona la richiesta di un nuovo UIN, come proposto e come si vede nella figura, appare
successivamente la richiesta di inserimento della parola d’ordine.3 Se tutto procede come previsto, si ottiene il numero UIN e si potrà poi procedere a compilare le informazioni personali che
si intendono rendere pubbliche.
2
3
GnomeICU GNU GPL
Nel momento in cui si scrive questo capitolo, il programma limita l’inserimento a soli otto caratteri.
ICQ: «I-seek-you»
1557
Figura 147.2. Finestra principale di GnomeICU.
Dal menù ICQ della finestra principale di GnomeICU, si seleziona la voce Change user info per
compilare o modificare i propri dati personali pubblici, come si vede nella figura 147.3, dove in
particolare non è stata compilata la casella della data di nascita, volutamente.
Figura 147.3. Impostazione dei dati personali.
La finestra in questione è suddivisa in diverse parti a cui si accede attraverso la selezione del
lembo appropriato. Vale la pena di osservare cosa appare nelle informazioni riferite alla rete,
come si vede nella figura 147.4.
ICQ: «I-seek-you»
1558
Figura 147.4. Recapito telematico.
Il numero IP e la porta sono assegnati automaticamente. La figura mostra la situazione riferita a
un momento in cui manca la connessione con l’esterno. Quando la connessione c’è, il numero
IP diventa quello relativo alla rete pubblica (assegnato probabilmente da una connessione PPP).4
L’indicazione della porta presso cui GnomeICU è in ascolto per le comunicazioni, completa le
informazioni necessarie ai collegamenti personali. Infine, vale la pena di annotare che l’indirizzo
di posta elettronica è facoltativo, dal momento che la comunicazione può avvenire in modo diretto
con ICQ, tuttavia si tratta di una possibilità in più per farsi trovare, soprattutto quando questo
indirizzo viene modificato (si osservi il campo relativo all’indirizzo vecchio).
Per cercare una persona, si seleziona la voce Add Contact, dal menù ICQ. È possibile specificare
direttamente il numero UIN, oppure si può fare una ricerca in base al soprannome, al nome, al
cognome, o all’indirizzo di posta elettronica (sempre che questi dati siano stati annotati dalla
persona cercata).
4
Da questo si comprende che diventa praticamente impossibile attraversare un router NAT/PAT.
ICQ: «I-seek-you»
1559
Figura 147.5. Ricerca di un contatto.
Se si ha fortuna, si ottiene un elenco di contatti (non tutti i numeri UIN corrispondono effettivamente a persone reali), dal quale è possibile selezionare chi aggiungere al proprio elenco.
Successivamente sarà possibile tentare di comunicare con questi, oppure sarà possibile sapere
quando sono collegati alla rete anche loro.
Per mostrare la propria presenza attiva nella rete, bisogna selezionare il menù speciale che appare
in basso a sinistra, nella finestra principale di GnomeICU. Inizialmente, appare la voce Offline;
aprendo quel menù si potrà selezionare la voce Online, oppure anche Free for chat.
147.2.2 Gestione di più UIN simultaneamente
Una volta scoperto ICQ, si può incontrare l’esigenza di gestire più UIN simultaneamente, per
scopi diversi. Questo si può fare con GnomeICU, ma non è un’operazione intuitiva.
Per prima cosa occorre evitare di inserire GnomeICU in un’applet del pannello di Gnome, perché al riavvio successivo del pannello, viene persa l’indicazione del numero UIN specifico,
utilizzando soltanto la configurazione predefinita. Per questo si usa l’opzione ‘-a’.
L’eseguibile ‘gnomeicu’ consente di usare l’opzione ‘--uin’ per specificare un numero di
UIN all’avvio. In pratica, più che specificare un numero, si stabiliscono i file di configurazione da tenere in considerazione. In tal caso si tratterà di ‘~/.gnome/GnomeICU_numero_uin ’
e di ‘~/.gnome_private/GnomeICU_numero_uin ’. Il primo contiene la configurazione generale, mentre il secondo conserva la parola d’ordine relativa. Se non si usasse l’opzione ‘--uin’, ‘gnomeicu’ utilizzerebbe semplicemente i file ‘~/.gnome/GnomeICU’ e di ‘~/
.gnome_private/GnomeICU’.
Una volta ottenuto un numero UIN, si può cambiare nome ai file ‘~/.gnome/GnomeICU’ e ‘~/
.gnome_private/GnomeICU’, secondo il modello appena descritto, ricordando poi di avviare
‘gnomeicu’ con l’opzione corretta.
Utilizzando due o più finestre di GnomeICU, può diventare complicato ricordarsi quale sia attribuita a un numero rispetto agli altri. Per questo si può intervenire nella direttiva seguente che è
contenuta nel file ‘~/.gnome/GnomeICU_numero_uin ’, allo scopo di vedere apparire una nota
adeguata nel titolo della finestra:
[Window]
Title=1234567890 [email protected]
ICQ: «I-seek-you»
1560
In questo caso, Tizio ha sotto controllo il numero UIN, aggiungendo anche il riferimento
dell’indirizzo di posta elettronica abbinato a quel numero.
Per concludere, supponendo di disporre dei numeri 1234567890 e 2345678901, si può decidere
di intervenire nel file ‘~/.xsession’, oppure ‘~/.xinitrc’, più o meno nel modo seguente:
gnomeicu -a --uin=1234567890 &
gnomeicu -a --uin=2345678901 &
panel &
enlightenment
147.3 Note conclusive
ICQ può essere usato per comunicare a vario titolo. In generale conviene dichiarare le proprie
intenzioni nello spazio apposito, che appartiene alle informazioni personali che si intendono
pubblicizzare. Se un utente ICQ non mostra informazioni di questo tipo, è probabile che non stia
cercando contatti con persone sconosciute.
Figura 147.6. Configurazione delle informazioni varie che si intendono pubblicizzare,
visto con GnomeICU.
Bisogna tenere in considerazione anche un problema di sicurezza con ICQ: mostrando sempre su
quale indirizzo IP ci si trova, si dà il modo a un aggressore motivato di compiere le sue azioni,
per cui bisogna valutare l’opportunità di proteggere il proprio sistema, mancando il vantaggio
dato dal non essere sempre collegati alla rete esterna (parte xxxiv).
ICQ: «I-seek-you»
147.4 Riferimenti
• Magnus Ihse, The ICQ protocol site
<http://www.student.nada.kth.se/~d95-mih/icq/>
1561
1562
ICQ: «I-seek-you»
Parte xxviii
FTP
148 FTP: introduzione e uso del servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
148.1 Caratteristiche elementari del protocollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
148.2 Identificazione e privilegi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1564
148.3 Cliente FTP tradizionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
148.4 Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1571
148.5 Lftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574
149 Servente OpenBSD FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
149.1 Avvio del demone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1576
149.2 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577
150 Servente WU-FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
150.1 Avvio del demone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579
150.2 Configurazione elementare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1580
150.3 FTP anonimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1581
150.4 Configurazione con /etc/ftpaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583
150.5 Filtro individuale con /etc/ftphosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
150.6 Organizzazione del sistema di messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1590
150.7 Facilitare le ricerche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1592
150.8 File delle registrazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593
150.9 Informazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1594
1563
Capitolo
148
FTP: introduzione e uso del servizio
Quando il trasferimento di file riguarda un ambito che supera l’estensione di una piccola rete
locale, non è conveniente consentire l’utilizzo della condivisione del file system (NFS) o della
copia remota. A questo scopo si prestano meglio altri protocolli; storicamente, il più importante
è stato il protocollo FTP (File transfer protocol).
Il servizio FTP viene offerto da un demone che funge da servente e viene utilizzato da un programma cliente in grado di comunicare attraverso il protocollo FTP. Il funzionamento di un
programma cliente tradizionale è paragonabile a quello di una shell specifica per la copia di file
da e verso un sistema remoto.
148.1 Caratteristiche elementari del protocollo
In generale, il protocollo FTP si avvale di TCP al livello inferiore. Convenzionalmente, il servente
opera sulla porta 20, ma è prevista l’apertura di una connessione anche su una porta secondaria,
di solito la porta 21.
porta n
porta 20
cliente
servente
potra m
porta 21
Quando in una rete si attuano delle tecniche di trasformazione degli indirizzi e delle porte, oppure
si intende filtrare il traffico, il controllo del protocollo FTP diventa un problema, proprio a causa
dell’apertura di questa connessione secondaria.
148.2 Identificazione e privilegi
Il sistema di trasferimento di file attraverso FTP richiede una forma di autenticazione, in base
alla quale il servente può dare privilegi differenti agli utenti.
Di solito, perché un utente registrato venga accettato per una sessione FTP è necessario che presso
il servente abbia una parola d’ordine (non sono quindi ammessi utenti senza parole d’ordine) e
una shell valida, cioè compresa nell’elenco del file ‘/etc/shells’. Questo ultimo particolare
non è trascurabile, infatti, a volte si sospende l’utilizzo di un’utenza modificando il campo della
shell nel file ‘/etc/passwd’: di solito si tratta di uno script che emette un messaggio contenente
la motivazione di questa sospensione.
Oltre a queste limitazioni, si utilizza solitamente il file ‘/etc/ftpusers’ per determinare quali
utenti non possono essere accettati per una sessione di FTP normale. Di solito si tratta dell’elenco
degli utenti di sistema, come per esempio ‘root’, ‘bin’ e ‘mail’.
Se si vuole permettere l’accesso a utenti che non sono registrati nel proprio sistema (si parla di
utenti che non sono previsti nel file ‘/etc/passwd’), è possibile abilitare l’utilizzo dell’FTP anonimo. Per questo è necessario che sia stato previsto un utente speciale nel file ‘/etc/passwd’:
‘ftp’.1
1
I numeri UID e GID dipendono dall’organizzazione del proprio sistema
1564
1565
ftp:*:14:50:FTP User:/home/ftp:
A questo utente non viene abbinata alcuna parola d’ordine (l’asterisco non corrisponde ad alcuna
parola d’ordine) e nemmeno una shell (eventualmente, se si temono accessi indesiderati in altra
forma, si può indicare il programma ‘/bin/false’ come shell).
Per utilizzare un servizio FTP in modo anonimo si può accedere identificandosi come ‘ftp’,
oppure ‘anonymous’. Di norma, viene richiesta ugualmente una parola d’ordine che però non
viene (e non può essere) controllata: per convenzione si inserisce l’indirizzo di posta elettronica.2
Generalmente, un servente FTP che consente l’accesso anonimo, fa sì che tali utenti non identificati possano accedere solo alla directory personale dell’utente fittizio ‘ftp’, senza poter
esplorare il resto del file system.
La descrizione su come impostare un servente FTP viene ripresa in altri capitoli.
148.3 Cliente FTP tradizionale
Il programma cliente tradizionale per accedere a un servizio FTP, è «Netstd ftp»,
normalmente solo attraverso il nome del suo eseguibile: ‘ftp’.
ftp
3
conosciuto
[opzioni] [host]
Quando l’eseguibile ‘ftp’ viene avviato con l’indicazione del nome dell’elaboratore remoto, tenta immediatamente di effettuare il collegamento; diversamente si avvia e attende il comando con
il quale questo elaboratore verrà specificato. Se esiste il file ‘~/.netrc’, questo viene utilizzato
per automatizzare l’accesso nell’elaboratore remoto. Quando ‘ftp’ è in attesa di un comando da
parte dell’utente, presenta l’invito seguente: ‘ftp>’.
Segue l’elenco di alcune opzioni della riga di comando.
Opzione
-V
-n
-i
-d
-g
Descrizione
Vengono visualizzati tutti i messaggi.
Disabilita l’accesso automatico.
Disattiva la richiesta interattiva durante i trasferimenti
multipli di file.
Attiva la modalità diagnostica.
Disabilita l’uso dei caratteri jolly per l’indicazione di gruppi
di file.
Come già accennato, quando ‘ftp’ è in attesa di un comando da parte dell’utente, presenta
l’invito ‘ftp>’. Le tabelle che seguono elencano, per categorie, molti dei comandi che possono essere utilizzati. Se i parametri dei comandi contengono il carattere spazio, questi devono
essere delimitati da una coppia di apici doppi (‘"’).
Shell.
Comando
!
[comando [argomenti]]
Descrizione
Avvia una shell sull’elaboratore locale, oppure esegue il
comando indicato con gli argomenti che gli vengono forniti.
2
Di solito, quando si inserisce il proprio indirizzo di posta elettronica come parola d’ordine per accedere a un servizio
FTP anonimo, è sufficiente indicare la parte che precede il dominio, fino al simbolo ‘@’ incluso. Quindi, se l’indirizzo
fosse [email protected], basterebbe inserire ‘daniele@’.
3
Netstd ftp UCB BSD
1566
Macro.
Comando
$ macro
Descrizione
Esegue la macro indicata che si riferisce a un nome di una macro creata con il comando ‘macdef’. Gli argomenti vengono
passati alla macro già espansi.
Definisce una macro (macroistruzione) attribuendole un nome. La macro può contenere più righe purché consecutive: la
prima riga vuota viene interpretata come la fine dell’inserimento. Possono essere inserite un massimo di 16 macro che
occupano uno spazio complessivo di 4096 caratteri. Le macro
restano definite fino a che non viene immesso un comando
‘close’ che conclude la connessione con un sistema remoto
determinato.
La macro viene interpretata nel modo seguente.
Il simbolo ‘$’ seguito da una o più cifre numeriche (‘$n ’) viene interpretato come variabile contenente l’n -esimo argomento (della macro nel momento in cui viene richiamata).
Il simbolo ‘$’ seguito dalla lettera ‘i’ indica che l’esecuzione
della macro deve essere ripetuta tante volte quanti sono i parametri forniti alla macro quando viene richiamata. Ogni volta,
‘$i’ rappresenta il parametro per il quale si sta ripetendo l’esecuzione della macro.
Il simbolo ‘\’ seguito da un carattere (‘\x ’) indica il carattere stesso. Per esempio è necessario usare questo simbolo
per poter indicare il dollaro senza volersi riferire a uno dei
parametri.
[argomenti]
macdef macro
Identificazione.
Comando
account
[parola_d’ordine]
[parola_d’ordine]
]
user utente
,→ account
[
←-
Descrizione
Fornisce a ‘ftp’ l’informazione sulla parola d’ordine di account che a volte viene richiesta da alcuni sistemi per potervi
accedere. Se l’argomento non viene fornito, viene richiesto
all’utente di inserire la parola d’ordine.
Definisce l’identità dell’utente da utilizzare per l’accesso nel
sistema remoto. Se la parola d’ordine e l’account non vengono forniti, ma sono richiesti nel sistema con il quale ci si intende connettere, questi dovranno essere inseriti al momento
del collegamento.
Trasferimento dati.
Comando
append file_locale
[file_remoto]
[file_locale]
get file_remoto
[file_locale]
recv file_remoto
mget file_remoti
newer file_remoto
put file_locale
[file_remoto]
send file_locale
[file_remoto]
Descrizione
Aggiunge, in coda, il contenuto del file locale a quello del
sistema remoto. Se non viene fornito il nome del file di
destinazione, si intende lo stesso nome di quello di origine.
‘get’ e ‘recv’ sono sinonimi. Riceve il file remoto indicato,
eventualmente rinominandolo come indicato.
Esegue un ‘get’ multiplo, cioè su tutti i file che si ottengono
dall’espansione del nome indicato utilizzando i caratteri jolly.
Esegue un ‘get’ del file remoto, solo se risulta essere più
recente di quello presente nel sistema locale.
‘put’ e ‘send’ sono sinonimi. Copia il file specificato nel
sistema remoto eventualmente rinominandolo come indicato.
Comando
mput file_locali
reget file_remoto
[file_locale]
[ Ctrl+c ]
1567
Descrizione
Espande il nome indicato se contiene dei caratteri jolly ed esegue un ‘put’ per tutti questi file, trasmettendoli in sostanza nel
sistema remoto.
Permette di riprendere il ‘get’ di un file remoto quando l’operazione precedente è stata interrotta involontariamente. L’operazione non è sicura e si basa solo sul calcolo della dimensione del file locale per determinare la parte mancante ancora
da trasferire.
L’operazione di trasferimento può essere interrotta utilizzando la combinazione [ Ctrl+c ].
Modalità di trasferimento dei dati.
Comando
ascii
binary
cr
mode
[modalità_di_trasferimento ]
runique
sunique
struct
[struttura]
tenex
type
[tipo_di_trasferimento ]
Descrizione
Imposta il tipo di trasferimento in modalità ASCII. Questa è la
modalità normale e comunque non è adatta al trasferimento di
file i cui byte contengono informazioni anche dopo il settimo
bit. Questo tipo di modalità di trasferimento di dati può essere
conveniente (ma non necessaria) solo per i file di testo puro
che non contengono caratteri speciali di alcun tipo.
Imposta il tipo di trasferimento in modalità binaria. Questa
modalità è adatta al trasferimento di qualunque tipo i file.
Attiva o disattiva la trasformazione della sequenza
<CR><LF> in <LF> per i trasferimenti ASCII verso il
sistema locale. In pratica, converte i file di testo scritti in stile
Dos in file corrispondenti in stile Unix. Quando è attivata la
modalità, viene eseguita la conversione.
Configura la modalità di trasferimento. Il valore predefinito è
‘stream’.
Attiva o disattiva la modalità di unicità dei nomi in ricezione. Quando la modalità è attiva, se durante le operazioni di
‘get’ o ‘mget’, si incontrano nel sistema locale dei file con
gli stessi nomi, l’operazione di trasferimento avviene aggiungendo al nome il suffisso ‘.1’, oppure ‘.2’, fino a un massimo di ‘.99’. La condizione predefinita di questa modalità è di
disattivazione.
Attiva o disattiva la modalità di unicità dei nomi in trasmissione. Quando la modalità è attiva, se durante le operazioni di
‘put’ o ‘mput’, si incontrano nel sistema remoto dei file con
gli stessi nomi, l’operazione di trasferimento avviene aggiungendo al nome il suffisso ‘.1’, oppure ‘.2’, fino a un massimo di ‘.99’. La condizione predefinita di questa modalità è di
disattivazione.
Stabilisce il tipo di struttura da utilizzare per il trasferimento
dei dati. Il valore predefinito è ‘stream’.
Configura il tipo di trasferimento dati in modo da essere compatibile con il sistema usato da un elaboratore remoto che
utilizza questo tipo di protocollo.
Attiva o visualizza il tipo di trasferimento dei dati. Il valore predefinito è ‘ascii’. I tipi a disposizione sono: ‘ascii’,
‘ebcdic’, ‘image’ (trasferimento binario), ‘local byte
size’.
1568
Informazioni.
Comando
bell
debug
[livello_diagnostico]
hash
prompt
trace
verbose
Descrizione
Attiva o disattiva la segnalazione acustica alla fine di ogni
operazione di trasferimento di file.
Attiva o disattiva la modalità diagnostica. Quando questa è attiva, vengono visualizzati i comandi inviati al sistema remoto,
evidenziati dal simbolo ‘-->’.
Abilita o disabilita la visualizzazione della progressione delle operazioni di trasferimento utilizzando i simboli ‘#’ che
rappresentano un blocco di 1024 byte.
Attiva o disattiva la modalità di conferma. Se è attiva, durante
le operazioni di trasferimento di gruppi di file, viene richiesta
la conferma per ogni file.
Attiva o disattiva il tracciamento dei pacchetti. Normalmente
è disattivato.
Attiva o disattiva la modalità con la quale si visualizzano tutti
i messaggi legati alla comunicazione con il sistema remoto.
Connessione e chiusura.
Comando
bye
Descrizione
‘bye’ e ‘quit’ sono sinonimi. Termina il collegamento e
termina l’attività di ‘ftp’.
Termina la connessione senza uscire dal programma.
open host
Apre una connessione con l’elaboratore remoto indicato ed
eventualmente anche specificando la porta di comunicazione. Se la modalità di accesso automatico è attiva, ‘ftp’ tenta
anche di effettuare l’accesso nel sistema remoto.
| quit
close | disconnect
[porta]
Conversione dei nomi e filtri.
Comando
case
form formato
glob
Descrizione
Attiva o disattiva la modalità di trasformazione per cui i nomi dei file trasferiti dal sistema remoto attraverso il comando ‘mget’ vengono copiati nel sistema locale utilizzando solo
lettere minuscole.
Configura il filtro di trasferimento ‘form’ in base al formato
attribuito. Il valore predefinito è ‘file’.
Attiva o disattiva l’espansione dei nomi di file contenenti caratteri jolly per l’uso con ‘mdelete’, ‘mget’ e ‘mput’. L’utilità di disattivare l’espansione dei nomi sta nella possibilità
di identificare (e trasferire) file con nomi strani che utilizzano
simboli speciali che altrimenti sarebbero intesi come jolly (o
metacaratteri). L’espansione dei nomi viene fatta in maniera
differente a seconda che si riferisca a dati contenuti nell’elaboratore locale, oppure nell’elaboratore remoto. Per le operazioni con ‘mput’ che si riferiscono a dati locali da trasmettere,
si utilizza il modello della shell C.
Nel caso di ‘mget’ e ‘mdelete’ che si riferiscono all’acquisizione e alla cancellazione di dati remoti, valgono le regole
stabilite dal servente FTP in funzione nell’elaboratore remoto.
Per verificare il comportamento dell’espansione dei nomi in
un elaboratore remoto è possibile utilizzare il comando ‘mls’
in questo modo: ‘mls file_remoti -’.
Comando
[
nmap modello_in_ingresso ←,→ modello_in_uscita
]
[
ntrans caratteri_in_ingresso ←,→ caratteri_in_uscita
]
umask
[maschera]
1569
Descrizione
Definisce una regola per la trasformazione dei nomi dei file per il collegamento con il sistema remoto. Se non viene fornito alcun parametro, la regola di trasformazione viene
annullata.
Definisce una trasformazione dei caratteri in ingresso con i rispettivi caratteri in uscita per la trasformazione dei nomi dei
file quando ci sono incompatibilità con i nomi utilizzati nel sistema remoto. Se non viene fornito alcun parametro, la regola
di trasformazione viene annullata.
Definisce una nuova maschera dei permessi nel sistema remoto. Se non viene specificato l’argomento, si ottiene la
visualizzazione del valore corrente di questa maschera.
Operazioni sul sistema remoto.
Comando
cd
Descrizione
Cambia la directory corrente nel sistema remoto.
Cambia la directory corrente nel sistema remoto, portandosi
sul livello superiore.
Cambia i permessi sul file remoto.
Cancella il file indicato nel sistema remoto.
[directory_remota]
cdup
chmod permessi_file_remoto
delete file_remoto
[
]
dir directory_remota
,→ file_locale
[
]
[
[
]
]
ls directory_remota
,→ file_locale
[
←-
←-
]
nlist directory_remota
,→ file_locale
[
mdelete
←-
]
[file_remoti]
mdir file_remoti file_locale
mls file_remoti file_locale
mkdir directory_remota
modtime file_remoto
pwd
quote argomenti
remotestatus
[file_remoto]
rename origine destinazione
rmdir directory_remota
size file_remoto
status
system
‘dir’, ‘ls’, ‘nlist’ sono sinonimi. Elencano il contenuto della directory remota specificata, oppure di quella attuale se non viene indicata. L’elenco viene emesso attraverso
lo standard output, quando non viene specificato il file locale all’interno del quale si vuole immettere questo elenco.
L’aspetto dell’elenco dipende dal sistema con il quale si sta
comunicando. Di solito è molto simile a quello di un ‘ls -l’.
Cancella i file remoti espandendo i caratteri jolly prima di
procedere.
‘mdir’ e ‘mls’ sono sinonimi. Elencano i file remoti espandendo i caratteri jolly e ne immettono il risultato nel file locale
indicato. Se si vuole visualizzare l’elenco, invece di generare un file, si può utilizzare un trattino singolo (‘-’) al posto
del nome di questo file. Questo comando è particolarmente
importante per verificare la trasformazione dei simboli usati
come caratteri jolly sui file del sistema remoto prima di procedere con operazioni più delicate come il prelievo multiplo
(‘mget’) o la cancellazione multipla (‘mdelete’).
Crea una directory nel sistema remoto.
Visualizza la data e l’ora dell’ultima modifica del file indicato
nel sistema remoto.
Visualizza il nome della directory corrente del sistema
remoto.
Trasmette gli argomenti indicati al sistema remoto esattamente così come vengono scritti.
Se il comando viene dato senza l’argomento, si ottiene lo stato
del sistema remoto. Se viene fornito il nome di file remoto, si
ottiene lo stato di quel file nel sistema remoto.
Permette di cambiare il nome di un file nel sistema remoto.
Cancella una directory nel sistema remoto.
Restituisce la dimensione del file remoto.
Visualizza lo stato attuale del sistema remoto.
Visualizza il tipo di sistema operativo in funzione nel sistema
remoto.
1570
Operazioni sul sistema locale.
Comando
lcd
[directory]
Descrizione
Cambia la directory corrente all’interno dell’elaboratore locale. Se non viene specificato il percorso si intende la directory
personale dell’utente.
Guida dei comandi.
Comando
help
[comando]
[comando]
remotehelp [comando ]
?
Descrizione
‘help’ e ‘?’ sono sinonimi. Visualizza una breve guida dei
comandi.
Permette di richiedere la guida dei comandi al sistema remoto.
Proxy.
Comando
proxy comando_ftp
Descrizione
Invia il comando indicato a un altro elaboratore remoto. Questo è un modo per potersi connettere contemporaneamente a
due sistemi remoti e di conseguenza di trasferire file tra i due.
Per poter iniziare il collegamento con un elaboratore remoto
secondario, il primo comando sarà ‘proxy open’. Non tutti i
comandi sono disponibili anche per una connessione secondaria; per visualizzarne l’elenco, basta dare il comando ‘proxy
?’. Quando viene aperta la connessione con un elaboratore
secondario, i comandi ‘proxy’ riguardano il trasferimento
di file tra l’elaboratore remoto normale e quello secondario,
trattando questo ultimo come se fosse quello locale.
All’interno dei parametri dei comandi, quando viene richiesto un nome di file, può essere fornito
un trattino singolo (‘-’); in tal caso, si intende riferirsi a:
• standard input se si tratta di un file che viene aperto in lettura;
• standard output se si tratta di un file che viene aperto in scrittura.
Quando al posto del nome di un file viene fornita una barra verticale (‘|’) seguita da una qualche
stringa (eventualmente racchiusa tra apici doppi, nel caso contenga spazi), quella stringa viene
interpretata come un comando da inviare alla shell. Ciò in modo che venga sostituito l’insieme
‘|stringa ’ con il risultato di quel comando inviato alla shell.
‘ftp’ può essere configurato creando o modificando il file ‘~/.netrc’. Si tratta di un file di testo
normale in cui ogni riga corrisponde a un comando. Per separare i comandi dai loro parametri
possono essere usati sia spazi che caratteri di tabulazione. Le indicazioni contenute all’interno
del file sono precedute dal nome del nodo remoto a cui si riferiscono. In tal modo, quando ‘ftp’
riceve l’ordine di collegamento con un certo nodo, cerca all’interno di questo file per trovare il
profilo che lo riguarda. Segue la descrizione di alcune direttive.
Direttiva
machine nome
Descrizione
Il nome del nodo a cui fanno riferimento le direttive
successive.
Direttiva
default
login utente
password stringa_parola_d’ordine
account stringa_parola_d’ordine
macdef macro
1571
Descrizione
Rappresenta la configurazione predefinita per tutti i nodi
remoti non previsti all’interno di questo file.
Definisce il nominativo da utilizzare per il collegamento.
Definisce la parola d’ordine per l’accesso al sistema remoto.
Definisce una parola d’ordine ulteriore per i sistemi remoti
che lo richiedono.
Definisce una macro (macroistruzione) attribuendole un nome. La macro può contenere più righe purché consecutive: la
prima riga vuota viene interpretata come la fine dell’inserimento. Possono essere inserite un massimo di 16 macro che
occupano uno spazio complessivo di 4096 caratteri. Le macro
restano definite fino a che non viene immesso un comando
‘close’ che conclude la connessione con un sistema remoto
determinato.
La macro viene interpretata nel modo seguente.
Il simbolo ‘$’ seguito da una o più cifre numeriche (‘$n ’) viene interpretato come variabile contenente l’n -esimo argomento (della macro nel momento in cui viene richiamata).
Il simbolo ‘$’ seguito dalla lettera ‘i’ indica che l’esecuzione
della macro deve essere ripetuta tante volte quanti sono i parametri forniti alla macro quando viene richiamata. Ogni volta,
‘$i’ rappresenta il parametro per il quale si sta ripetendo l’esecuzione della macro.
Il simbolo ‘\’ seguito da un carattere (‘\x ’) indica il carattere stesso. Per esempio è necessario usare questo simbolo per
poter indicare il dollaro senza volersi riferire a uno dei parametri.
Se viene definita una macro con il nome ‘init’, questa viene eseguita automaticamente come ultima operazione
dell’accesso automatico.
148.4 Esempi
L’uso di un cliente FTP può essere anche semplice, se si lasciano da parte raffinatezze non
indispensabili. Seguono alcuni esempi di sessioni FTP.
Prelievo di file
daniele@roggen:~$ ftp dinkel.brot.dg[ Invio ]
Si richiede la connessione FTP all’elaboratore dinkel.brot.dg.
Connected to dinkel.brot.dg.
220 dinkel.brot.dg FTP server (Version wu-2.4.2-academ[BETA-12]) ready.
Name (roggen.brot.dg:daniele):
anonymous[ Invio ]
Si utilizza una connessione anonima e per correttezza si utilizza il proprio indirizzo di posta
elettronica abbreviato al posto della parola d’ordine.
331 Guest login ok, send your complete e-mail address as password.
Password:
daniele@[ Invio ]
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using ascii mode to transfer files.
1572
Come si vede, la modalità di trasferimento predefinita è ASCII (almeno così succede di
solito). Generalmente si deve utilizzare una modalità binaria. Questa verrà richiesta tra un
po’; per ora viene richiesta la guida interna dei comandi a disposizione.
ftp> help[ Invio ]
Commands may be abbreviated.
!
$
account
append
ascii
bell
binary
bye
case
cd
cdup
chmod
close
cr
delete
Commands are:
debug
dir
disconnect
exit
form
get
glob
hash
help
idle
image
lcd
ls
macdef
mdelete
mdir
mget
mkdir
mls
mode
modtime
mput
newer
nmap
nlist
ntrans
open
prompt
passive
proxy
sendport
put
pwd
quit
quote
recv
reget
rstatus
rhelp
rename
reset
restart
rmdir
runique
send
site
size
status
struct
system
sunique
tenex
tick
trace
type
user
umask
verbose
?
ftp> binary[ Invio ]
Come accennato, viene richiesto di passare alla modalità di trasferimento binario.
200 Type set to I.
ftp> prompt[ Invio ]
Anche la modalità interattiva viene disattivata per evitare inutili richieste.
Interactive mode off.
La struttura delle directory di un normale servizio FTP anonimo prevede la presenza della
directory ‘pub/’ dalla quale discendono i dati accessibili all’utente sconosciuto.
Anche se dal punto di vista del cliente FTP, che accede al servizio remoto, si tratta della
prima directory dopo la radice, in realtà questa radice è solo la directory iniziale del
servizio FTP anonimo. Di conseguenza, è quasi impossibile che corrisponda realmente
con la directory radice del file system remoto. Tutto questo serve solo a spiegare perché il
comando ‘cd /pub’ potrebbe non funzionare quando ci si collega a serventi configurati
male. Ecco perché nell’esempio che segue non si utilizza la barra obliqua davanti a ‘pub’.
ftp> cd pub[ Invio ]
250 CWD command successful.
ftp> pwd[ Invio ]
257 "/pub" is current directory.
ftp> ls[ Invio ]
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 4
dr-xr-sr-x
3 root
ftp
1024 Nov 12 21:04
drwxr-xr-x
6 root
root
1024 Sep 11 20:31
-rw-r--r-1 root
ftp
37 Nov 12 21:04
drwxrwsrwx
2 root
ftp
1024 Nov 2 14:04
226 Transfer complete.
.
..
esempio
incoming
Attraverso il comando ‘ls’ si vede che la directory ‘pub/’ contiene solo il file ‘esempio’
e la directory ‘incoming/’. Si decide di prelevare il file.
ftp> get esempio[ Invio ]
1573
local: esempio remote: esempio
150 Opening BINARY mode data connection for esempio (37 bytes).
37 bytes received in 0.00155 secs (23 Kbytes/sec)
Il file scaricato viene messo nella directory in cui si trovava l’utente quando avviava il
programma ‘ftp’.
ftp> quit[ Invio ]
221 Goodbye.
Invio di dati
daniele@roggen:~$ ftp dinkel.brot.dg[ Invio ]
Si richiede la connessione FTP all’elaboratore dinkel.brot.dg e si danno una serie di
comandi per raggiungere la directory ‘pub/incoming’.
220 dinkel.brot.dg FTP server (Version wu-2.4.2-academ[BETA-12](1) Wed Mar 5 12:37:21 EST 1997) rea
Name (dinkel.brot.dg:daniele):
anonymous[ Invio ]
331 Guest login ok, send your complete e-mail address as password.
Password:
daniele@[ Invio ]
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using ascii mode to transfer files.
ftp> binary[ Invio ]
200 Type set to I.
ftp> prompt[ Invio ]
Interactive mode off.
ftp> cd pub/incoming[ Invio ]
250 CWD command successful.
ftp> pwd[ Invio ]
Si verifica la posizione in cui ci si trova.
257 "/pub/incoming" is current directory.
ftp> mput al-1*[ Invio ]
Dal momento che la directory è giusta, si inizia la trasmissione di tutti i file che nella
directory locale corrente iniziano per ‘al-1’.
local: al-1 remote: al-1
150 Opening BINARY mode data connection for al-1.
2611649 bytes sent in 1.38 secs (1.9e+03 Kbytes/sec)
2612414 bytes sent in 2.51 secs (1e+03 Kbytes/sec)
1574
ftp> ls[ Invio ]
Si controlla il risultato nell’elaboratore remoto. A volte, i servizi FTP impediscono la lettura
del contenuto di questa directory.
150 Opening ASCII mode data connection for /bin/ls.
total 15379
drwxrwsrwx
2 root
ftp
1024 Dec 11 20:40
dr-xr-sr-x
3 root
ftp
1024 Nov 12 21:04
-rw-rw-r-1 ftp
ftp
2611649 Dec 11 20:40
-rw-rw-r-1 ftp
ftp
2612414 Dec 11 20:40
-rw-rw-r-1 ftp
ftp
2612414 Dec 11 20:40
-rw-rw-r-1 ftp
ftp
2612420 Dec 11 20:40
-rw-rw-r-1 ftp
ftp
2612409 Dec 11 20:40
-rw-rw-r-1 ftp
ftp
2612431 Dec 11 20:40
.
..
al-1
al-15
al-16
al-17
al-18
al-19
ftp> quit[ Invio ]
221 Goodbye.
148.5 Lftp
A fianco del cliente FTP tradizionale, di origine BSD, ne esistono altri, più o meno sofisticati.
Tra questi, merita attenzione Lftp, 4 che è in grado di usare anche il protocollo IPv6, quando
naturalmente anche il servente che si vuole contattare è predisposto per questo. In questo caso, il
programma eseguibile è ‘lftp’:
lftp
[opzioni] [host]
Il suo funzionamento è molto simile a quello di Netstd ftp, soprattutto per quanto riguarda i
comandi, con delle particolarità che possono essere approfondite leggendo la pagina di manuale
lftp(1). Appare evidente l’aspetto dell’invito è leggermente diverso:
lftp :~>
A differenza di Netstd ftp, quando si avvia Lftp con l’indicazione di un elaboratore, ma senza
il nominativo utente da utilizzare, questo tenta di accedere automaticamente in modo anonimo;
pertanto, diventa importante l’indicazione dell’utenza già al momento dell’avvio dell’eseguibile.
Per esempio così:
$ lftp [email protected]
Come si può intendere, si tratta dell’accesso all’elaboratore dinkel.brot.dg con il nominativo utente ‘tizio’. In questi casi, ancora prima di tentare l’accesso, Lftp chiede l’inserimento della parola d’ordine. In base all’esempio, dopo l’inserimento della parola d’ordine, l’invito
dovrebbe apparire così:
4
Lftp GNU GPL
1575
lftp [email protected]:~>
Tuttavia, Lftp tenta effettivamente di accedere all’elaboratore remoto solo quando si dà un
comando. Pertanto, ci si può accorgere solo dopo se il servizio FTP risulta attivo effettivamente.
Capitolo
149
Servente OpenBSD FTP
Il servente OpenBSD FTP 1 è un programma molto semplice da installare e configurare, anche
in un sistema GNU, con il vantaggio che è in grado di operare anche con il protocollo IPv6.
Eventualmente, se il tipo di configurazione disponibile non è sufficiente per le proprie esigenze,
si può optare per serventi FTP differenti, come WU-FTP che è descritto in un altro capitolo.
149.1 Avvio del demone
OpenBSD FTP, come altri serventi FTP mette a disposizione l’eseguibile ‘in.ftpd’ (o ‘ftpd’,
a seconda della distribuzione). Questo demone può funzionare in modo autonomo, oppure sotto
il controllo del supervisore dei servizi di rete. Nel primo caso si avvia con l’opzione ‘-D’, mentre
nel secondo si usa l’opzione ‘-q’:
[opzioni]
-q [opzioni]
in.ftpd -D
in.ftpd
Nell’esempio seguente viene mostrata la riga di ‘/etc/inetd.conf’ in cui si dichiara il suo
ftp
stream
tcp
nowait
root
/usr/sbin/tcpd
in.ftpd -q
Dal momento che OpenBSD FTP viene usato anche con IPv6, conviene vedere la configurazione
necessaria per il file ‘/etc/xinetd.conf’, nel caso il supervisore dei servizi di rete sia Xinetd:
service ftp
{
socket_type
protocol
wait
user
server
server_args
}
=
=
=
=
=
=
stream
tcp
no
root
/usr/sbin/in.ftpd
-q
Segue la descrizione di alcune opzioni della riga di comando di ‘ftpd’.
Opzione
-d
-l
-t n
-T n
-A
-u maschera_dei_permessi
1
Descrizione
Vengono aggiunte informazioni diagnostiche all’interno del
registro di sistema.
Ogni sessione FTP viene annotata all’interno del registro di
sistema; se viene usata due volte, le indicazioni sono più
dettagliate.
Permette di specificare la durata espressa in secondi (n ) del
tempo di inattività oltre il quale la sessione FTP viene conclusa automaticamente. Questo parametro è negoziabile anche da
parte del cliente. Il valore predefinito è di 15 minuti (900 s).
tempo massimo di inattività. In questo modo, un cliente non
può negoziare una durata superiore.
Consente solo l’accesso anonimo, oppure solo le utenze
elencate nel file ‘/etc/ftpchroot’.
Definisce un valore particolare della maschera dei permessi,
che è 0278 in modo predefinito.
OpenBSD FTP UCB BSD
1576
Opzione
-p
-q
-M
1577
Descrizione
Disabilita la modalità «passiva», in modo da non accettare la
creazione di connessioni a porte indicate dai clienti. Ciò serve
a facilitare l’attraversamento di un firewall (purché il firewall
consenta questo passaggio), ma può creare difficoltà ad alcuni
programmi cliente.
Non mostra informazioni sulla versione al cliente che si
collega.
Consente di gestire directory differenti per l’accesso anonimo, in base al nome di dominio presso cui giunge la richiesta,
secondo la forma ‘~ftp/nome_di_dominio/ ’.
149.2 Configurazione
La configurazione di OpenBSD FTP è molto semplice. Per prima cosa, l’accesso anonimo è consentito solo se nel sistema è previsto l’utente fittizio ‘ftp’, assieme alla sua directory personale
e a una shell valida.2
Teoricamente, OpenBSD FTP non richiede nemmeno la predisposizione di una struttura particolare della directory ‘~ftp/’, secondo la tradizione, perché gestisce internamente il comando
‘ls’ e di tutto il resto si può fare a meno.
Nel caso si utilizzi l’opzione ‘-M’, si dovrà provvedere a dividere la directory ‘~ftp/’ in sottodirectory corrispondenti ai nomi di dominio con cui si può accedere al servizio. Per esempio, se l’elaboratore che ospita il servente OpenBSD FTP è raggiungibile con i nomi dinkel.brot.dg
e weizen.mehl.dg, ci potranno essere le directory ‘~ftp/dinkel.brot.dg/’ e ‘~ftp/
weizen.mehl.dg/’; chi accede a ftp://dinkel.brot.dg in modo anonimo, vedrà la
prima directory, mentre chi accede a ftp://weizen.mehl.dg vedrà la seconda.
Si rammenta che l’utente anonimo accede solo alla porzione di file system che inizia da
‘~ftp/’, come se questa fosse la radice.
Dopo la sistemazione dell’accesso anonimo, conviene occuparsi del file ‘/etc/ftpchroot’,
all’interno del quale si possono elencare gli utenti che, pur potendo accedere con il proprio nominativo, possono entrare solo nella propria directory personale, come avviene per gli utenti
anonimi con la directory ‘~ftp/’.
tizio
caio
L’esempio che si vede sopra è molto breve e serve a fare in modo che gli utenti ‘tizio’ e
‘caio’ possano accedere limitatamente alla propria directory personale; tutti gli altri utenti hanno
accesso a tutto il file system, con le limitazioni normali date dai permessi dei file e delle directory.
OpenBSD FTP riconosce anche il file ‘/etc/ftpusers’, all’interno del quale vanno elencati
i nominativi degli utenti a cui non si consente l’accesso. Generalmente si tratta di utenti fittizi,
compreso ‘root’ per questioni di sicurezza, come nell’esempio seguente:
root
bin
2
Il particolare della shell valida va tenuto in considerazione perché altri serventi FTP si comportano diversamente.
1578
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
Naturalmente, per compilare correttamente questo file, è bene osservare il file ‘/etc/passwd’
del proprio sistema.
Infine, OpenBSD FTP riconosce anche il file ‘/etc/nologin’, in presenza del quale rifiuta gli
accessi; inoltre, è possibile definire un messaggio di benvenuto nel file ‘/etc/ftpwelcome’ e
anche il contenuto di ‘/etc/motd’ viene visualizzato all’accesso.
Capitolo
150
Servente WU-FTP
WU-FTP 1 è un servente FTP molto comune, anche se ormai si può considerare superato,
soprattutto a causa della complessità della sua configurazione.
WU-FTP si compone in pratica del demone ‘ftpd’, o ‘in.ftpd’, configurato attraverso diversi
file; inoltre, per consentire l’accesso anonimo, è necessario predisporre una directory apposita,
strutturata in modo appropriato.
150.1 Avvio del demone
Il demone ‘ftpd’ (o ‘in.ftpd’) è gestito normalmente dal supervisore dei servizi di rete.
[opzioni]
in.ftpd
Nell’esempio seguente viene mostrata la riga di ‘/etc/inetd.conf’ in cui si dichiara il suo
ftp
stream
tcp
nowait
root
/usr/sbin/tcpd
in.ftpd -l -a
Nelle comunicazioni, ‘ftpd’ interpreta i caratteri jolly, cioè i simboli per i riferimenti a gruppi
di file, secondo lo standard della shell C, utilizzando quindi i simboli ‘*’, ‘?’, ‘&’, ‘[’, ‘]’, ‘{’ e
‘}’.
Segue la descrizione di alcune opzioni della riga di comando di ‘ftpd’.
Opzione
-d
| -v
-l
-tn
-Tn
-a
-A
-L
-i
-o
-uumask
1
Descrizione
Vengono aggiunte informazioni diagnostiche all’interno del
registro di sistema.
Ogni sessione FTP viene annotata all’interno del registro di
sistema.
tempo di inattività oltre il quale la sessione FTP viene conclusa automaticamente. Questo parametro è negoziabile anche da
parte del cliente. Il valore predefinito è di 15 minuti (900 s).
tempo massimo di inattività. In questo modo, un cliente non
può negoziare una durata superiore.
Stabilisce l’uso da parte di ‘ftpd’ della configurazione
contenuta all’interno del file ‘/etc/ftpaccess’.
Disabilita l’uso da parte di ‘ftpd’ della configurazione contenuta all’interno del file ‘/etc/ftpaccess’. Questa è la
modalità predefinita.
Ogni comando inviato da parte degli utenti FTP viene
annotato all’interno del registro di sistema.
Vengono registrate le operazioni di invio di file da parte dei
clienti FTP all’interno di ‘/var/log/xferlog’.
Vengono registrate le operazioni di prelievo di file da parte dei
clienti FTP all’interno di ‘/var/log/xferlog’.
Definisce un valore particolare della maschera dei permessi.
WU-FTP software non libero: non è consentita la commercializzazione a scopo di lucro
1579
Servente WU-FTP
1580
150.2 Configurazione elementare
Il primo file da prendere in considerazione per la configurazione di WU-FTP è ‘/etc/
ftpusers’, che viene utilizzato per impedire l’accesso agli utenti indicati al suo interno. Si
tratta solitamente dell’utente ‘root’ e di utenti fittizi, come nell’esempio seguente:
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
Questi utenti sono esclusi da un accesso normale, mentre rimane aperta, eventualmente, la
possibilità di accedere come utenti anonimi.
WU-FTP ha la particolarità di poter gestire automaticamente l’archiviazione, la compressione e
l’estrazione di file, attraverso la configurazione del file ‘/etc/ftpconversions’. In generale,
si tratta di una funzionalità che viene ignorata dagli utilizzatori del servizio; tuttavia, vale la pena
di vedere un esempio di questo file, che di solito viene già fornito nella distribuzione di WU-FTP:
:.Z:
:
:
:.gz:
:
:
:
:
:
:
:
:
: :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
:.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
: :/bin/gzip -cd %s:T_REG|T_ASCII:O_UNCOMPRESS:GUNZIP
:.gz:/bin/gzip -9 -c %s:T_REG:O_COMPRESS:GZIP
:.tar:/bin/tar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
:.tar.Z:/bin/tar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
:.tar.gz:/bin/tar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP
In pratica, a seconda di come viene identificato un file durante una sessione FTP, con l’aggiunta
o l’eliminazione di un’estensione, si indica implicitamente una conversione di questo. La tabella
150.2 dovrebbe chiarire il meccanismo.
Tabella 150.2. Conversione automatica degli archivi in base alle estensioni utilizzate.
Nome reale
Nome specificato
radice.Z
radice
radice
radice.Z
radice.gz
radice
radice
radice
radice
radice
radice.gz
radice.tar
radice.tar.Z
radice.tar.gz
Azione compiuta prima della trasmissione del file
Viene trasmesso dopo essere stato decompresso con
‘uncompress’.
Viene trasmesso dopo essere stato compresso con
‘compress’.
Viene trasmesso dopo essere stato decompresso con
‘gunzip’.
Viene trasmesso dopo essere stato compresso con ‘gzip’.
Viene trasmesso dopo essere stato archiviato con ‘tar’.
Viene archiviato e compresso con ‘tar’ e ‘compress’.
Viene archiviato e compresso con ‘tar’ e ‘gzip’.
Di solito, questa tecnica di trasformazione automatica non viene utilizzata: i nomi dei file
vengono indicati esattamente come sono nella realtà e nessuna conversione ha luogo.
Servente WU-FTP
1581
150.3 FTP anonimo
Una volta effettuato il collegamento, l’utente anonimo (‘ftp’ o ‘anonymous’) viene posizionato
nella directory indicata nel file ‘/etc/passwd’ nella voce corrispondente dell’utente ‘ftp’. Di
solito si tratta della directory ‘/home/ftp/’ o di ‘/var/ftp/’. In altri termini, si tratta della
directory personale dell’utente fittizio ‘ftp’.
È bene precisare che l’utente anonimo, dopo la connessione, trova davanti a sé solo la gerarchia che si articola a partire da ‘~ftp/’, dal momento che il servente FTP esegue la funzione
‘chroot()’. È questo il motivo per cui è bene che da quel punto siano disponibili alcuni programmi di servizio nella directory ‘~ftp/bin/’, assieme ad altri elementi elementari di un
file system Unix.
Generalmente, le varie distribuzioni GNU organizzano già questa directory in modo ragionevolmente corretto. Segue un esempio di struttura di ‘~ftp/’ che può essere utilizzato in mancanza
d’altro. È da tenere presente che le soluzioni legate all’organizzazione e alla sicurezza possono
essere diverse da quelle proposte.
È opportuno che nessuna directory sia modificabile, a parte il caso di ‘incoming/’, descritta più
avanti.
Directory
Permessi
‘~ftp/’
05558
‘~ftp/bin/’
01118
‘~ftp/etc/’
01118
‘~ftp/lib/’
05558
‘~ftp/pub/’
05558
Descrizione
Contiene normalmente un file con un messaggio introduttivo. Si
tratta di solito del file ‘welcome.msg’ che deve essere protetto opportunamente: deve essere accessibile solo in lettura a tutti gli altri
utenti.
Serve a contenere alcuni programmi di servizio indispensabili per
le operazioni di FTP. Per esempio, non deve mancare ‘ls’.
Dal punto di vista dell’utilizzo, è sufficiente che tali file siano accessibili in esecuzione, mentre dal punto di vista della sicurezza è
necessario che non siano modificabili.
Serve a contenere essenzialmente i file ‘passwd’ e ‘group’. È importante che questi file non contengano parole d’ordine, o al massimo che queste non siano reali. La presenza di questi file serve solo
a ottenere una conversione tra UID e nome dell’utente, tra GID e
nome del gruppo. In pratica, vengono utilizzati da ‘ls’ per generare
un listato leggibile della proprietà dei file.
Se la directory ‘~ftp/lib/’ contiene delle librerie, oltre ai due file
già visti, è necessario che sia presente ‘ld.so.cache’.
I file contenuti in questa directory devono essere accessibili solo in
lettura.
Serve a contenere i file di libreria degli eseguibili contenuti in
‘~ftp/bin/’. Questi file di libreria devono essere accessibili in lettura e in esecuzione, ma naturalmente devono essere protetti dalla
scrittura.
Questa directory può essere organizzata in vario modo. Di solito è
il contenitore di file messi a disposizione per il prelievo. In tal caso
sarà conveniente che la directory non sia modificabile e che i file
siano accessibili solo in lettura.
Per poter rendere disponibile una directory per la ricezione di file, questa deve essere accessibile in scrittura. Di solito si crea
la directory ‘incoming/’ collocata al di sotto di ‘~ftp/pub/’
o di un’altra sottodirectory, dandole solo i permessi di esecuzione (attraversamento) e scrittura, impedendo così la lettura del suo
contenuto.
Servente WU-FTP
1582
Segue un esempio del contenuto delle directory appena esaminate.
bin:
total 534
---x--x--x
---x--x--x
---x--x--x
---x--x--x
---x--x--x
---x--x--x
lrwxrwxrwx
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
root
root
etc:
total 6
-r--r--r--r--r--r--r--r--r--
1 root
1 root
1 root
root
root
root
lib:
total 725
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
lrwxrwxrwx
1 root
-> libc.so.5.3.12
-rwxr-xr-x
1 root
root
root
root
root
root
root
14940
292160
45056
49432
56380
77560
4
Mar 3 1997
Mar 3 1997
Mar 3 1997
Mar 3 1997
Mar 3 1997
Mar 3 1997
Jul 12 11:29
53 Mar 3
4004 Feb 26
79 Mar 3
19704
19704
24576
24576
14
1997 group
1997 ld.so.cache
1997 passwd
Mar 3 1997
Mar 3 1997
Mar 3 1997
Mar 3 1997
Jul 12 11:29
644036 Mar
3
compress
cpio
gzip
ls
sh
tar
zcat -> gzip
ld-linux.so.1
ld-linux.so.1.7.14
ld.so
ld.so.1.7.14
libc.so.5
1997 libc.so.5.3.12
pub:
total 0
Quello che segue è l’esempio del contenuto del file ‘~ftp/etc/passwd’.
root:*:0:0:::
bin:*:1:1:::
operator:*:11:0:::
ftp:*:14:50:::
nobody:*:65534:65534:::
Quello che segue è l’esempio del contenuto del file ‘~ftp/etc/group’.
root::0:
bin::1:
daemon::2:
sys::3:
adm::4:
ftp::50:
Il massimo della sicurezza si ottiene:
• facendo in modo che le directory e i file di ‘~ftp/’ appartengano all’utente ‘root’;
• evitando di concedere permessi di scrittura;
• concedendo i permessi di lettura solo quando necessario.
Da un punto di vista di praticità, o di necessità, può essere opportuno che sia consentito all’utente
‘root’ di accedere in lettura e scrittura, altrimenti il lavoro di amministrazione dell’FTP anonimo
risulterebbe impedito.
Servente WU-FTP
1583
150.3.1 Collegamenti simbolici
Quando si utilizzano collegamenti simbolici all’interno della struttura di directory dell’FTP anonimo, occorre tenere presente che il programma servente FTP cambia la posizione della directory
principale. Se si creano dei collegamenti, è opportuno utilizzare solo riferimenti relativi (senza
la barra iniziale), in modo che siano validi anche quando si accede al file system normalmente,
senza questi vincoli particolari.
150.4 Configurazione con /etc/ftpaccess
In ordine di importanza, dopo il file ‘/etc/ftpusers’ che permette di escludere alcuni utenti (tipicamente gli utenti di sistema) viene il file ‘/etc/ftpaccess’, il quale viene preso in
considerazione dal demone ‘ftpd’ solo se questo è stato avviato con l’opzione ‘-a’. Purtroppo,
l’insieme della gestione di questo file è piuttosto complesso, tanto che di solito si evita di modificare quanto accompagna già la distribuzione di WU-FTP, ma in questi casi conviene forse
utilizzare un servente più semplice da amministrare.
Di seguito appare un esempio di questo, che dovrebbe corrispondere alla configurazione standard
di partenza.
class
all
real,guest,anonymous
*
email root@localhost
loginfails 5
readme
readme
README*
README*
login
cwd=*
message /welcome.msg
message .message
login
cwd=*
compress
tar
chmod
delete
overwrite
rename
all
all
guest,anonymous
guest,anonymous
guest,anonymous
guest,anonymous
yes
yes
no
no
no
no
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
Ai fini dei controlli di accesso, si distinguono tre tipi di utenti:
• ‘anonymous’ -- che possono accedere solo alla struttura di directory che discende da
‘~ftp/’;
• ‘guest’ -- che sono soggetti a restrizioni simili a quelle imposte agli utenti anonimi;
• ‘real’ -- corrispondenti a utenti normali che hanno libero accesso all’intero file system in
base ai permessi relativi.
Nelle sezioni seguenti vengono descritte alcune delle direttive che possono apparire in questo
file.
Servente WU-FTP
1584
150.4.1 Controlli di accesso
Gli utenti che accedono al servizio FTP vengono classificati in due modi: il tipo e la classe. I tipi
di utenti sono già definiti e si tratta di ‘anonymous’, ‘guest’ e ‘real’, come già descritto. Le
classi di utenti vengono invece definite all’interno del file ‘/etc/ftpaccess’, in base al tipo e
alla provenienza della richiesta di accesso al servizio. Queste distinzioni permettono di consentire
o negare l’accesso agli utenti e di distinguere tra altri privilegi.
Classi di utenti
class classe elenco_tipi_utente famiglia_di_indirizzi
...
Con la direttiva ‘class’ è possibile definire una classe di utenti in base al tipo di utente e
agli indirizzi da cui può provenire la richiesta di accesso al servizio. Gli indirizzi rappresentano l’elaboratore cliente e possono essere espressi in forma di nome di dominio o di
indirizzo numerico, con l’aiuto di caratteri jolly.
Per poter accedere al servizio, occorre appartenere a una delle classi dichiarate con questo
tipo di direttiva. Per esempio, la riga seguente è un modo per definire una classe generica
che rappresenta ogni tipo di utente.
class
all
*
L’esempio seguente, invece, serve a riconoscere gli utenti di tipo ‘guest’ che accedono dal
dominio ‘.dg’, o dalla sottorete 192.168. . , attribuendogli la classe ‘amici’.
**
class
amici
guest
*.dg
192.168.*
Quando un utente potrebbe appartenere a diverse classi simultaneamente, vale quella in
cui viene riconosciuto prima. Sotto questo aspetto, conviene elencare prima le classi più
restrittive, come nell’esempio seguente:
class
class
amici
all
guest
*.dg
*
192.168.*
Distinguere tra gli utenti anonimi
autogroup gruppo classe ...
È possibile utilizzare la direttiva ‘autogroup’ per fare in modo che gli utenti anonimi
appartenenti alle classi indicate, accedano con i privilegi del gruppo indicato.
Questa tecnica può permettere a gruppi di utenti anonimi di poter accedere a file che
risultano esclusi agli altri.
class
amici
class
all
...
autogroup
guest,anonymous
locali
*.dg
*
192.168.*
amici
Nell’esempio appena mostrato, gli utenti anonimi che accedono dal dominio ‘.dg’
ottengono i privilegi del gruppo di utenti denominato ‘locali’.
Il gruppo in questione deve essere stato dichiarato nel file ‘/etc/group’ e questo è sufficiente perché le cose funzionino. Ma per fare in modo che l’utente del servizio FTP possa vedere il nome di questo gruppo quando esegue un comando ‘ls -l’ occorre anche
aggiornare il file ‘~ftp/etc/group’.
Definizione degli utenti di tipo guest
guestgroup gruppo ...
Gli utenti di tipo ‘guest’ sono soggetti a limitazioni equivalenti a quelle riservate agli utenti
anonimi, con la differenza che in questo caso vengono individuati precisamente attraverso
Servente WU-FTP
1585
un nome di utente e una parola d’ordine. Inoltre, non possono accedere se la shell non è
valida.
Per gli utenti di questo tipo occorre predisporre una directory personale, strutturata come
‘~ftp/’, con le directory ‘bin/’, ‘etc/’ e ‘lib/’, proprio perché, anche in questo caso, il
servente trasforma tale directory nella directory radice.
La direttiva ‘guestgroup’ definisce i gruppi i cui utenti appartengono automaticamente al
tipo ‘guest’, per cui, se si appartiene al gruppo indicato in questa direttiva, si è limitati ad
accedere alla propria directory personale.
Per attuare questo è sufficiente creare un gruppo e abbinargli gli utenti a cui si vuole limitare
l’accesso in questo modo.
ftpguest:*:450:tizio,caio,semproni
L’esempio mostra una riga del file ‘/etc/group’ che dichiara il gruppo ‘ftpguest’ e gli
abbina alcuni utenti, anche se questi sono collegati normalmente a un gruppo differente.
Nel file ‘/etc/ftpaccess’, la direttiva seguente esclude dagli accessi normali tutti gli
utenti che appartengono, direttamente o indirettamente, al gruppo ‘ftpguest’: per loro è
ammissibile solo un accesso limitato alla propria directory personale.
guestgroup
ftpguest
L’utente che appartiene a questa categoria può avere l’indicazione di una directory personale composta da due parti, suddivise da ‘/./’, come nell’esempio seguente che mostra un
record del file ‘/etc/passwd’.
tizio:Ide2ncPYY:500:500:Tizio Tizi:/home/tizio/./archivio:/bin/bash
Se questo utente accede al sistema normalmente, al di fuori del servizio FTP, la sua directory personale è automaticamente ‘/home/tizio/archivio’, perché l’effetto del punto
intermedio si traduce con uno spostamento nullo. Per il servente FTP invece, la prima parte,
quella prima del punto, diventerà la directory radice; la parte seguente, sarà la directory di
partenza in cui si troverà l’utente.
Impedire l’accesso a categorie di indirizzi determinate
deny famiglia_di_indirizzi file_messaggio
La direttiva ‘deny’ permette di bloccare tutti gli utenti che accedono da un gruppo di indirizzi determinato, esprimibili sia in forma di nome di dominio che in forma numerica.
L’utente che si vede rifiutare l’accesso, riceve un messaggio contenuto nel file indicato come terzo argomento. Questo file può contenere delle metavariabili elencate nella tabella
150.5.
È il caso di sottolineare che il filtro di accesso vale per tutti gli utenti e non solo per una
classe particolare.
deny
deny
deny
*.mehl.dg
192.168.2.*
dinkel.*
/etc/ftpdeny.msg
/etc/ftpdeny.msg
/etc/ftpdeny.msg
L’esempio mostra una serie di filtri contro l’accesso da parte di utenti che provengono dal
dominio mehl.dg, dalla rete 192.168.2.0 e dai nodi che si chiamano ‘dinkel’, indipendentemente dal dominio cui appartengono. In tutti questi casi, viene inviato il contenuto del
file ‘/etc/ftpdeny.msg’ all’utente che viene respinto.
Al posto della famiglia di indirizzi da escludere, si può indicare la parola chiave
‘!nameserved’, che rappresenta tutti gli indirizzi per i quali non esiste un nome di dominio
corrispondente.
deny
!nameserved
/etc/ftpdeny.msg
Servente WU-FTP
1586
Limitare gli accessi simultanei in base alla classe
limit classe numero_accessi periodo file_messaggio
La direttiva ‘limit’ permette di limitare l’accesso simultaneo degli utenti appartenenti alla
classe indicata, per un periodo determinato. Gli utenti che non possono accedere ricevono il contenuto del file indicato come ultimo argomento. Questo file può contenere delle
metavariabili elencate nella tabella 150.5.
limit
all
10
any
/etc/ftplimit.msg
L’esempio mostra l’imposizione di un limite massimo di 10 utenti della classe ‘all’,
in qualunque momento (‘any’). Agli utenti che non possono accedere viene inviato il
messaggio contenuto nel file ‘/etc/ftplimit.msg’.
Quando un servizio FTP è riprodotto in altri siti speculari, il file utilizzato per informare gli utenti dall’esclusione dal servizio serve normalmente per elencare gli indirizzi
alternativi.
Impedire il prelievo di alcuni file
noretrieve file ...
Con la direttiva ‘noretrieve’ si impedisce il prelievo dei file indicati come argomento. Se
i file vengono indicati specificando un percorso assoluto, si vuole fare riferimento a un file
particolare, mentre se non viene indicato il percorso, si vuole impedire il prelievo di ogni
file con quel nome.
noretrieve
/etc/passwd core
Nell’esempio viene impedito il prelievo del file ‘/etc/passwd’ e di tutti i file ‘core’.
Impedire l’accesso in base a un limite di tentativi errati
loginfails n_tentativi
La direttiva ‘loginfails’ permette di porre un limite ai tentativi falliti di accesso agli
utenti reali, cioè a quelli provvisti di parole d’ordine.
loginfails 5
L’esempio mostra un limite di cinque tentativi di autenticazione all’interno della stessa
sessione FTP. Una volta superato il limite, l’utente viene disconnesso e deve ricominciare
la connessione.
Controllo sulla parola d’ordine dell’utente anonimo
password-check
{none|trivial|rfc822} [enforce|warn]
All’utente anonimo viene richiesto l’inserimento di una parola d’ordine, che in realtà serve solo come «firma» e dovrebbe corrispondere convenzionalmente all’indirizzo di posta elettronica di chi accede. L’utente anonimo può limitarsi a indicare la prima parte del
suo indirizzo, fino al simbolo ‘@’, lasciando al servente, il compito di determinare la parte
restante.
Con la direttiva ‘password-check’ si può definire un livello di controllo su questo indirizzo inserito. Segue l’elenco delle parole chiave che possono essere usate in questa direttiva,
assieme al loro significato.
Servente WU-FTP
1587
Tabella 150.4. Parole chiave utilizzabili nella direttiva ‘password-check’.
Parola chiave
Descrizione
Non viene fatto alcun controllo.
La parola d’ordine deve contenere il carattere ‘@’.
Verifica che il dominio sia corretto (in base alle specifiche
del RFC 822).
La parola d’ordine non valida viene accettata avvisando
l’utente per la prossima volta.
L’accesso viene negato se la parola d’ordine non viene
ritenuta corretta.
‘none’
‘trivial’
‘rfc822’
‘warn’
‘enforce’
Segue l’elenco di alcuni codici macro utilizzabili nei file di messaggi restituiti agli utenti
del servizio FTP.
Tabella 150.5. Codici macro.
Macro
Descrizione
Data e ora locale.
La directory corrente.
L’indirizzo di posta elettronica dell’amministratore del servizio.
Indirizzo del nodo remoto.
Indirizzo del nodo che offre il servizio FTP.
Il nome dell’utente utilizzato per accedere.
Numero massimo di accessi ammissibili per gli utenti della classe
cui appartiene chi accede.
Numero di accessi in corso nella classe cui appartiene l’utente in
questione.
‘%T’
‘%C’
‘%E’
‘%R’
‘%L’
‘%U’
‘%M’
‘%N’
150.4.2 Informazioni e messaggi
In varie occasioni, il servente FTP invia agli utenti dei messaggi contenuti in file appositi, oppure
invita alla lettura di questi.
Indirizzo di posta elettronica dell’amministratore del servizio
email indirizzo_email
Con questa direttiva si indica l’indirizzo di posta elettronica dell’amministratore del sistema. Questo è utile praticamente solo per i file di messaggi che possono contenere la
metavariabile ‘%E’, al posto della quale viene messo questo indirizzo.
Messaggio introduttivo
message file
{login | cwd=directory} [classe...]
Con la direttiva ‘message’ è possibile presentare all’utente che accede un messaggio contenuto nel file indicato come primo argomento. Questo file verrà presentato quando si verifica
una condizione particolare, specificata attraverso le parole chiave ‘login’ o ‘cwd’.
‘login’ indica che si vuole mostrare il messaggio solo all’inizio dell’accesso; ‘cwd’ serve
a farlo quando l’utente cambia directory spostandosi precisamente in quella indicata subito
dopo questa parola chiave.
message /welcome.msg
message .message
login
cwd=*
Nell’esempio, viene inviato il messaggio contenuto nel file ‘/welcome.msg’ tutte le volte che un utente accede; inoltre, ogni volta che cambia directory (l’asterisco rappresenta
Servente WU-FTP
1588
qualunque directory) viene inviato quanto contenuto nel file ‘.message’ della directory
corrente.2
La direttiva ‘message’ permette di distinguere anche tra diverse classi di utenti, se uno o
più nomi di classi vengono aggiunte alla fine della direttiva stessa.
È il caso di ricordare che il file di messaggi può contenere delle metavariabili secondo lo
schema della tabella 150.5.
Invito alla lettura dei file contenenti informazioni importanti
readme file
{login | cwd=directory} [classe...]
Si tratta di una direttiva analoga a ‘message’, con la differenza che qui non viene inviato il
file in questione, piuttosto viene invitato l’utente a scaricare e a leggere il contenuto di tali
file.
readme
readme
README*
README*
login
cwd=*
L’esempio mostra il caso in cui si vuole che l’utente sia avvisato della presenza di file che
iniziano per ‘README’ nella directory corrente. Ciò all’inizio dell’accesso e tutte le volte
che si cambia directory.
150.4.3 Registrazione delle azioni degli utenti
L’attivazione del controllo sulla registrazione degli eventi legati al servizio FTP può essere fatta
attraverso l’opzione ‘-L’ nella riga di comando di ‘ftpd’. La direttiva ‘log’, tuttavia, scavalca
l’utilizzo di questa opzione eventuale.
Registrazione dei comandi
log commands elenco_tipi_utenti
Utilizzando la direttiva ‘log’ in questo modo, si attiva la registrazione di tutti i comandi
inseriti dagli utenti che appartengono all’elenco di tipi indicato. I tipi possibili sono sempre
solo ‘anonymous’, ‘guest’ e ‘real’, già descritti in precedenza.
Registrazione dei trasferimenti
log transfers elenco_tipi_utenti elenco_direzioni
La direttiva ‘log’ utilizzata con la parola chiave ‘transfers’ permette di indicare i tipi di
utente per i quali attivare la registrazione delle operazioni di trasferimento dati. Si distingue
tra prelievi dal servizio FTP, ‘outbound’ (scarico o download), e consegna al servizio,
‘inbound’ (carico o upload).
log transfers anonymous,real inbound,outbound
L’esempio mostra la richiesta di registrare tutte le operazione di carico e di scarico dati
(‘inbound’ e ‘outbound’), per gli utenti che appartengono al tipo ‘anonymous’ e ‘real’.
150.4.4 Permessi e filtri sul caricamento dei file
Il caricamento dei file in un FTP è una cosa molto delicata e generalmente da impedire agli
utenti anonimi. Attraverso le direttive ‘upload’ e ‘path-filter’ si possono controllare queste
operazioni, oltre che con la gestione corretta dei permessi delle directory.
2
Quando si indica un percorso in un file di messaggi e l’utente ha a disposizione un file system limitato come nel caso
dell’utente anonimo, conta quel file system particolare. Quindi, nel caso dell’esempio, il file ‘welcome.msg’ si troverà
presumibilmente in ‘~ftp/welcome.msg’.
Servente WU-FTP
1589
Limitazione del caricamento di file
upload directory_iniziale directory_di_destinazione
|
{yes|no}
utente_proprietario gruppo_proprietario modalità
]
dirs nodirs
La direttiva ‘upload’ permette di controllare il caricamento di file, cioè l’invio nel servente
FTP, da parte degli utenti anonimi e da quelli di tipo ‘guest’.
La directory iniziale rappresenta la posizione di partenza del servizio e serve a identificare
gli utenti a cui si rivolge la direttiva stessa. Per esempio, se viene indicato ‘/home/ftp’,
corrispondente a ‘~ftp/’, cioè alla directory personale dell’utente fittizio ‘ftp’, si intende
che questa direttiva riguardi proprio gli utenti anonimi.
La directory di destinazione è quella in cui si vuole controllare il caricamento di file e può
essere rappresentata anche utilizzando caratteri jolly.
Le parole chiave ‘yes’ e ‘no’ permettono di stabilire se si intende permettere o impedire il
caricamento nella directory.
Quando si permette il caricamento di dati, si devono indicare l’utente e il gruppo che figureranno essere proprietari dei file caricati, quindi occorre anche specificare i permessi, in
forma numerica ottale.
Attraverso questa stessa direttiva è possibile concedere o impedire la creazione di directory
attraverso le parole chiave ‘dirs’ e ‘nodirs’.
upload
upload
/home/ftp
/home/ftp
*
/incoming
no
yes
ftp
daemon
0600
nodirs
Nell’esempio appena mostrato si intende che ‘/home/ftp’ corrisponda alla directory iniziale del servizio FTP anonimo. Nella prima direttiva viene impedito in modo generalizzato
di caricare file in qualunque directory; nella seconda viene concesso di caricare solo nella
directory ‘incoming/’ discendente da ‘/home/ftp/’, senza la possibilità di creare directory, attribuendo ai file la proprietà dell’utente fittizio ‘ftp’ e del gruppo ‘daemon’, con i
permessi di scrittura e di lettura solo per il proprietario.3
Limiti sul nome dei file
path-filter elenco_tipi_utente file_messaggio regexp_consentita
[regexp_vietata ...]
La direttiva ‘path-filter’ permette di definire un filtro per i nomi dei file che vengono
caricati. Si distingue tra tipi di utenti (e non di classi), si indica il file contente un messaggio
di spiegazione in caso l’utente tenti di caricare un file con un nome non consentito, quindi
si indica un’espressione regolare che deve essere valida per il tipo di nome. Eventualmente
si possono specificare altre espressioni regolari che non devono corrispondere ai nomi dei
file.
path-filter anonymous /etc/pathname.msg ^[A-Za-z0-9]*.*_*-*$ ^[0-9] ^_ ^-
Nell’esempio mostrato, gli utenti anonimi possono caricare file che però devono rispettare
regole molto rigide nei nomi: possono contenere solo lettere dell’alfabeto, cifre numeriche, il punto, il trattino basso e il trattino normale, ma non possono iniziare con una cifra
numerica, un trattino basso o un trattino normale.
È importante osservare che in queste espressioni regolari, il punto vale esattamente per
quello che è, per cui non rappresenta un carattere qualunque come avviene generalmente.
Il messaggio di errore indicato viene visualizzato anche quando il caricamento dei file
fallisce per altre ragioni diverse dal filtro sul nome.
Il meccanismo messo a disposizione dalla direttiva ‘path-filter’ può essere utile anche
per impedire il caricamento di file da parte di utenti di tipo ‘guest’, esclusi dal controllo
della direttiva ‘upload’, o da parte di utenti reali.
3
Solitamente, per ridurre il rischio di usi impropri del servizio di caricamento dati, si tolgono i permessi di lettura alla
directory utilizzata per questo scopo, per non mostrare all’esterno il suo contenuto.
[
Servente WU-FTP
1590
path-filter
real,guest
/etc/pathname.msg
^vietato$
^vietato$
Nell’esempio si indica che si può caricare solo file con il nome ‘vietato’, e subito dopo
si vieta di caricare lo stesso nome.
150.5 Filtro individuale con /etc/ftphosts
Il file ‘/etc/ftphosts’ viene utilizzato per filtrare l’accesso da parte di utenti determinati
da nodi determinati. Questa possibilità di filtro si affianca alla direttiva ‘deny’ del file ‘/etc/
ftpaccess’, con la quale si impedisce l’accesso a tutto un dominio o a una sottorete espressa in
forma numerica.
deny
{
|
utente tipo
}
host ...
L’utente, o il tipo di utenti indicato, non può accedere dagli indirizzi specificati in modo preciso
o attraverso l’aiuto di caratteri jolly.
deny anonymous *.mehl.dg
L’esempio mostra in che modo impedire a tutti gli utenti ‘anonymous’ di accedere dal dominio
mehl.dg.
deny caio 192.168.2.*
In questo caso, si impedisce all’utente ‘caio’ di accedere dalla sottorete 192.168.2.0.
150.6 Organizzazione del sistema di messaggi
Un’organizzazione corretta del sistema di file di messaggi è importante, sia per l’immagine del
servizio, sia per poter informare correttamente l’utente.
150.6.1 Messaggio di ingresso
Quando viene accettato l’accesso da parte di un utente è opportuno inviargli un messaggio di
benvenuto, contenente alcune informazioni sul proprio servizio. Si ottiene questo con la direttiva ‘message’ del file ‘/etc/ftpaccess’, specificando la parola chiave ‘login’, come
nell’esempio seguente:
message /etc/ftpbenvenuto.msg
login
Il file ‘etc/ftpbenvenuto.msg’ dell’esempio, indica un percorso relativo alla directory iniziale, cosa che cambia a seconda del tipo di utente. Tuttavia, questo permette di definire diversi file
per il messaggio introduttivo a seconda del tipo di utente. Il file ‘/etc/ftpbenvenuto.msg’
per gli utenti reali, il file ‘~/ftp/etc/ftpbenvenuto.msg’ per gli utenti anonimi e qualcosa
di simile per gli utenti di tipo ‘guest’. Un file di benvenuto del genere potrebbe essere composto
nel modo seguente:
Benvenuto %U. Questo è il servizio FTP di %L.
%T ora locale.
L’amministratore di questo servizio può essere contattato all’indirizzo
email %E.
Servente WU-FTP
1591
150.6.2 Messaggio di ingresso nelle directory
Prima di accedere a una directory particolare, potrebbe essere conveniente inviare un messaggio
di presentazione o spiegazione. Se non ci sono directory con contenuti particolari, questa è l’occasione per dare messaggi specifici. Si ottiene questo con la direttiva ‘message’ del file ‘/etc/
ftpaccess’, specificando la parola chiave ‘cwd’, seguita dall’indicazione della directory, o della
famiglia di directory, come nell’esempio seguente:
message .message
cwd=*
L’esempio mostra una soluzione molto semplice e pratica: si fa riferimento al file ‘.message’
della directory corrente, per gli ingressi in ogni directory. In questo modo, si possono fare tanti
file differenti, uno per ogni directory, collocati esattamente dove serve. Il punto iniziale nel nome
del file serve solo per non farlo apparire nell’elenco quando si usa ‘ls’.
Il testo del messaggio dovrebbe riguardare il contenuto della directory a cui si riferisce.
Eventualmente, può trattarsi di una semplice ripetizione del messaggio introduttivo.
150.6.3 Invito alla lettura dei file contenenti informazioni importanti
Per tradizione, i file readme sono quelli che contengono informazioni importanti per cui si invita l’utente a leggerli. Può trattarsi di istruzioni sul come utilizzare il materiale contenuto nella
directory, annotazioni di carattere legale e ogni altra cosa che sia ritenuta importante.
È importante definire in modo automatico un invito alla lettura di questi file, quando appaiono
nelle directory. Si ottiene questo con la direttiva ‘readme’ del file ‘/etc/ftpaccess’, come
nell’esempio seguente, che rappresenta lo standard.
readme
readme
README*
README*
login
cwd=*
In questo modo, si invita l’utente a leggere il contenuto dei file che iniziano per ‘README’, sia
all’atto dell’accesso, sia tutte le volte che si cambia directory.
150.6.4 Motivazione del rifiuto di concedere l’accesso
L’accesso al servizio può essere rifiutato per ragioni diverse:
• una direttiva nel file ‘/etc/ftphosts’;
• una direttiva ‘deny’ nel file ‘/etc/ftpaccess’;
• il superamento del limite massimo di accessi consentito per la classe cui appartiene l’utente.
Nel primo caso non è possibile predisporre un file di messaggi: l’utente vede semplicemente un
semplice access denied. Nel secondo caso si utilizza il file specificato nella direttiva ‘deny’, nel
terzo si utilizza il file della direttiva ‘limit’.
Il messaggio da inviare nel caso della direttiva ‘deny’ del file ‘/etc/ftpaccess’ può essere
fondamentalmente di due tipi, a seconda che si tratti del blocco a un gruppo di indirizzi particolare, oppure che si tratti del filtro contro gli utenti che accedono da macchine per le quali non
esiste un nome di dominio.
Segue l’esempio di un pezzo del file ‘/etc/ftpaccess’, seguito dal contenuto dei due ipotetici
file ‘/etc/ftpdeny.msg’ e ‘/etc/ftpdenydns.msg’.4
4
È il caso di sottolineare che il percorso di questi file di messaggi si riferisce al file system globale, dal momento che
il controllo avviene prima di qualunque identificazione dell’utente.
Servente WU-FTP
1592
deny
deny
deny
deny
*.mehl.dg
192.168.2.*
dinkel.*
!nameserved
/etc/ftpdeny.msg
/etc/ftpdeny.msg
/etc/ftpdeny.msg
/etc/ftpdenydns.msg
Siamo spiacenti.
Non si accettano accessi da %R.
Siamo spiacenti.
Per motivi di sicurezza non si accettano accessi da sistemi che non
dispongono di un nome di dominio.
Quando il problema è il superamento del limite posto agli accessi simultanei per una classe
determinata di utenti, si può avvisare semplicemente, pregando di avere pazienza, oppure si può
suggerire un elenco di URI alternativi. Questo limite viene fissato attraverso la direttiva ‘limit’
nel file ‘/etc/ftpaccess’, potendo definire limiti diversi per le varie classi di utenti. Volendo,
è possibile definire un solo file di spiegazioni, senza troppi dettagli.5
Segue un esempio molto semplice di questo tipo di messaggio.
Siamo spiacenti.
È stato raggiunto il limite massimo di accessi.
Si prega di riprovare in un altro momento.
150.7 Facilitare le ricerche
Il modo più semplice di fornire un indice del contenuto del proprio servizio FTP anonimo è quello
di posizionare nella sua directory di partenza un cosiddetto file ‘ls-lR’. Si tratta in pratica del
risultato dell’esecuzione del comando ‘ls -lR’, che ha quindi suggerito il nome del file indice in
questione. Generalmente si comprime questo file con ‘gzip’, per cui si usa il nome ‘ls-lR.gz’.
Il comando per generare questo file deve essere eseguito quando la directory corrente è quella di
partenza del servizio; in pratica, agendo nel modo seguente:
# cd ~ftp
# ls -lR | gzip -9 > ls-lR.gz
Se si decide di creare regolarmente questo file attraverso il sistema Cron, si può fare come
nell’esempio seguente che rappresenta un comando di Cron, nel file crontab dell’utente ‘root’,
16 6 * * *
cd /home/ftp; ls -lR | gzip -9 > ls-lR.gz
oppure si può modificare in modo da usarlo nel file ‘/etc/crontab’ (quello di sistema).
16 6 * * *
root
cd /home/ftp; ls -lR | gzip -9 > ls-lR.gz
In entrambi gli esempi, l’operazione è programmata per le ore 06:16 di ogni mattina.
150.7.1 Gestione degli errori
Quando si genera il file ‘ls-lR.gz’, si possono ottenere degli errori di vario tipo che vengono
emessi attraverso lo standard error. Questi errori possono essere generati dalla mancanza dei permessi necessari ad attraversare una directory durante la scansione, oppure quando i collegamenti
simbolici non raggiungono alcuna destinazione. Per evitare noie, si può correggere il comando
nel modo seguente:
5
Anche in questo caso, il percorso di tali file di messaggi si riferisce al file system globale.
Servente WU-FTP
ls -lR 2> /dev/null
1593
| gzip
-9 > ls-lR.gz
150.8 File delle registrazioni
Le registrazioni degli accessi e delle altre operazioni che si svolgono con il servizio FTP, vengono
fatte nel file ‘/var/log/xferlog’. A seconda della configurazione si possono avere più o meno
eventi registrati.
La struttura dei record di questo file è uniforme, per cui si possono costruire facilmente
dei programmi di rielaborazione statistica. A questo proposito, dovrebbe essere disponibile il
programma ‘xferstats’ (scritto in Perl), che fa sempre parte della distribuzione di WU-FTP:
xferstats
[opzioni]
‘xferstats’ è un programma per l’analisi statistica del file delle registrazioni del servente FTP.
Se non vengono dati argomenti, dovrebbe essere in grado di accedere da solo al file corretto,
generando una statistica semplificata.
Opzione
-f file
-r
-a
-h
-d
-t
-D dominio
-l profondità
-s sezione
Descrizione
Permette di specificare il nome del file contenente le registrazioni del servizio FTP. Può essere utile per analizzare
l’archivio delle registrazioni fatte in periodi precedenti.
Include le informazioni sugli utenti reali.
Include le informazioni sugli utenti anonimi.
Include il rapporto sul traffico orario.
Include il rapporto sul traffico in base al dominio.
Include il rapporto sul traffico totale per sezione (directory).
Limita la statistica al traffico con il dominio indicato.
Permette di limitare i dettagli nelle sottodirectory.
Permette di concentrare l’attenzione alle operazioni riferite a
una sezione determinata di directory.
Il programma può essere configurato parzialmente modificando la prima parte in modo da non
dover usare necessariamente le opzioni. È opportuno modificare la posizione in cui si attende di
trovare il file delle registrazioni, se questa è errata. Anche i domini separati potrebbero essere
modificati convenientemente.
...
# edit the next two lines to customize for your domain.
# This will allow your domain to be separated in the domain listing.
$mydom1 = "wustl";
$mydom2 = "edu";
# edit the next line to customize for your default log file
$usage_file = "/var/log/xferlog";
# Edit the following lines for default report settings.
# Entries defined here will be over-ridden by the command line.
$opt_h
$opt_d
$opt_t
$opt_l
...
=
=
=
=
1;
0;
1;
3;
Servente WU-FTP
1594
Il comando seguente genera un rapporto sui trasferimenti eseguiti con il dominio ‘.dg’:
# xferstats -D dg
Segue il risultato che si potrebbe ottenere.
Transfer Totals include the ’dg’ domain only.
All other domains are filtered out for this report.
TOTALS FOR SUMMARY PERIOD Sun Mar 15 1998 TO Tue Mar 24 1998
Files Transmitted During Summary Period
Bytes Transmitted During Summary Period
Systems Using Archives
23
8093489
0
Average Files Transmitted Daily
Average Bytes Transmitted Daily
12
4046744
Daily Transmission Statistics
Date
--------------Sun Mar 15 1998
Tue Mar 24 1998
Number Of
Files Sent
---------21
2
Number of
Bytes Sent
----------8093489
0
Average
Xmit Rate
---------207.5 KB/s
0.0 KB/s
Percent Of
Files Sent
---------91.30
8.70
Percent Of
Bytes Sent
---------100.00
0.00
Total Transfers from each Archive Section (By bytes)
---- Percent Of ---Archive Section
Files Sent Bytes Sent Files Sent Bytes Sent
------------------------- ---------- ----------- ---------- ---------/pub/free
15
6671985
65.22
82.44
/lib
8
1421504
34.78
17.56
Hourly Transmission Statistics
Time
--------------14
20
21
Number Of
Files Sent
---------2
10
11
Number of
Bytes Sent
----------0
7320378
773111
Average
Xmit Rate
---------0.0 KB/s
271.1 KB/s
64.4 KB/s
Percent Of
Files Sent
---------8.70
43.48
47.83
Percent Of
Bytes Sent
---------0.00
90.45
9.55
150.9 Informazioni
Alcuni programmi che fanno parte di WU-FTP possono informare sullo stato dell’utilizzo del
servizio FTP. Vale la pena di conoscere ‘ftpcount’ e ‘ftpwho’; entrambi si utilizzano senza
argomenti.
‘ftpcount’ visualizza la quantità di utenti connessi in modo ‘ftp’ per ogni classe e anche il
massimo numero di connessioni ammissibili.
# ftpcount[ Invio ]
Service class all
-
1 users ( -1 maximum)
L’esempio mostra la risposta di ‘ftpcount’ quando un solo utente accede al proprio sistema. Il
valore -1 rappresenta in realtà l’intero di dimensione massima che può essere gestito.
‘ftpwho’ visualizza le informazioni disponibili inerenti gli utenti connessi in modo ‘ftp’.
Servente WU-FTP
1595
# ftpwho[ Invio ]
Service class all:
592 ? S
0:00 ftpd: dinkel.brot.dg: anonymous/daniele@: IDLE
1 users ( -1 maximum)
L’esempio mostra la risposta di ‘ftpwho’ quando un solo utente accede al proprio sistema. Il
valore -1 rappresenta in realtà l’intero di dimensione massima che può essere gestito.
1596
Servente WU-FTP
Parte xxix
Posta elettronica
151 Utilizzo e gestione elementare della posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
151.1 Servizio di rete e servizio di consegna locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599
151.2 Uso della posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1600
151.3 Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1602
151.4 Recapito della posta elettronica: la variabile MAIL . . . . . . . . . . . . . . . . . . . . . . . 1605
151.5 Mail user agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1606
151.6 Mailx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607
151.7 Nail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
151.8 Pine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611
151.9 Balsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616
151.10 Configurazione compatibile tra Mailx, Nail, Pine e Balsa . . . . . . . . . . . . . . . . 1618
151.11 Ricerche nei file delle cartelle di messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1620
152 Messaggi giunti presso recapiti remoti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
152.1 Concetti generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1622
152.2 IMAP toolkit: ipop3d, ipop2d, imapd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1623
152.3 Popclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1624
152.4 Fetchmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1625
152.5 MUA completi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
153 Messaggi, allegati ed estensioni MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
153.1 Allegati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
153.2 Uuencode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1630
153.3 Involucro MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1631
153.4 Messaggi contenenti più parti MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
153.5 Sistemazione manuale di un allegato MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1635
153.6 Mpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638
153.7 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639
154 Gestione della posta elettronica in generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
154.1 Schema essenziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1640
154.2 Composizione di un messaggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1641
154.3 Messaggi contraffatti e punto di iniezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643
154.4 Identificazione della destinazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644
154.5 Misure di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
154.6 Referente per l’amministrazione del servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
154.7 Scelta dell’MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1645
1597
154.8 Scelta del servente SMTP per l’elaboratore personale . . . . . . . . . . . . . . . . . . . . . 1646
154.9 Pratica manuale con i protocolli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646
154.10 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649
155 Sendmail: introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
155.1 Destinatari e formati degli indirizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
155.2 Alias, inclusione e forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1650
155.3 Configurazione di Sendmail con il pacchetto di Berkeley . . . . . . . . . . . . . . . . . . 1652
156 Exim: introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1659
156.1 Compatibilità con Sendmail e differenze importanti . . . . . . . . . . . . . . . . . . . . . . 1659
156.2 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1660
156.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662
156.4 Avvio di Exim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1670
156.5 Code e registri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1673
157 sSMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
157.1 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674
157.2 Ricezione della posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
157.3 Considerazioni sulla sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1675
158 Liste di posta elettronica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
158.1 Lista elementare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676
158.2 SmartList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1678
158.3 Mailman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1685
1598
151
Utilizzo e gestione elementare della posta
elettronica
Capitolo
Generalmente, l’invio di messaggi di posta elettronica (email) si basa su un MTA (Mail transfer
agent) locale che, quando riceve una richiesta di invio di un messaggio, si occupa di mettersi in
contatto con un suo collega presso l’indirizzo di destinazione, o se necessario in una destinazione
intermedia, che si prenderà cura di consegnare il messaggio o di reinoltrarlo. Tutto quanto sembra
molto semplice a dirsi, in realtà la configurazione di un MTA potrebbe essere molto complessa.
Spesso, in presenza di una rete locale, il funzionamento corretto dell’MTA richiede la predisposizione di un servizio di risoluzione dei nomi locale. A tale proposito conviene consultare i capitoli
122 e 123.
L’invio di messaggi di posta elettronica avviene solitamente attraverso l’uso di un programma
adatto alla loro composizione, che poi si mette in comunicazione con l’MTA per l’inoltro del
messaggio. Più precisamente, un messaggio inviato a un utente dell’elaboratore locale non richiede alcun MTA, mentre l’invio a un altro elaboratore richiede almeno la presenza di un MTA
presso l’indirizzo di destinazione.
Storicamente, l’MTA più diffuso nei sistemi Unix è stato Sendmail; 1 tuttavia, è sempre più
comune l’uso di MTA alternativi, meno complicati, pur mantenendo un certo grado di compatibilità con quello tradizionale. Nella parte xxix l’argomento viene ripreso e trattato con maggiore
dettaglio.
151.1 Servizio di rete e servizio di consegna locale
La posta elettronica non è semplicemente un servizio di rete che si attua attraverso un protocollo
(SMTP). Il servizio di rete permette il trasferimento dei messaggi, ma l’MTA ha anche il compito
di recapitarli ai destinatari, in forma di file.
In questo senso, il meccanismo può sembrare un po’ confuso all’inizio, trattandosi effettivamente
di un sistema piuttosto complicato. In un sistema composto da un elaboratore isolato, anche se
provvisto di terminali più o meno decentrati, non c’è alcun bisogno di fare viaggiare messaggi
attraverso una rete, è sufficiente che questi vengano semplicemente messi a disposizione dell’utente destinatario (in un file contenuto nella sua directory personale, o in una directory pubblica,
in cui il file in questione possa essere accessibile solo a quell’utente particolare). In tal caso, chi
si occupa di attuare questo sistema è un MDA, ovvero Mail delivery agent.
Quando invece si deve inviare un messaggio attraverso la rete, perché l’indirizzo del destinatario
si trova in un nodo differente, si utilizza il protocollo SMTP, per contattare presso la destinazione un servente SMTP. Questo servente si prenderà carico di fare recapitare la posta elettronica
(presumibilmente presso il proprio sistema locale). Quindi, lo scopo del servente SMTP è quello
di recapitare i messaggi.
La trasmissione del messaggio, che richiede la connessione con il servente remoto della destinazione, non fa capo ad alcun servizio di rete nell’ambito locale. Questa connessione potrebbe
essere instaurata direttamente dal programma che si utilizza per scrivere il messaggio da trasmettere, oppure, come succede di solito, da un altro programma specifico, che in più si preoccupa di
ritentare l’invio del messaggio se per qualche motivo le cose non funzionano subito, rinviandolo
eventualmente all’origine se non c’è modo di recapitarlo.
L’MTA ha generalmente questi tre ruoli fondamentali: l’attivazione del servizio SMTP, per la
ricezione di messaggi dall’esterno; la gestione della trasmissione di questi, assieme a una coda
1
Sendmail software non libero: non è consentita la commercializzazione a scopo di lucro
1599
Utilizzo e gestione elementare della posta elettronica
1600
per ciò che non può essere trasmesso immediatamente; la consegna locale dei messaggi ricevuti
attraverso il protocollo SMTP oppure attraverso lo stesso sistema locale. Quindi, in generale, un
MTA integra anche le funzioni di un MDA.
151.2 Uso della posta elettronica
La posta elettronica, o email, è un modo di comunicare messaggi che richiede la conoscenza di
alcune convenzioni. Ciò, sia per evitare malintesi, sia per eliminare le perdite di tempo.
Un messaggio di posta elettronica è formato fondamentalmente da una «busta» e dal suo contenuto. La busta è rappresentata da tutte le informazioni necessarie a recapitare il messaggio,
mentre il contenuto è composto generalmente da un testo ASCII puro e semplice. Tutte le volte
che il testo è composto in modo diverso, si aggiungono dei requisiti nei programmi da utilizzare
per la sua lettura; in pratica, si rischia di creare un problema in più al destinatario del messaggio.
In generale, un messaggio di posta elettronica può contenere uno o più allegati, conosciuti frequentemente come attachment. L’allegato permette di incorporare in un messaggio un file che
poi, attraverso strumenti opportuni, può essere estrapolato correttamente come era l’originale.
Ciò che si deve evitare di fare in generale è l’invio del messaggio come un allegato. Questo,
purtroppo, capita frequentemente quando si usano programmi per la composizione di messaggi
di posta elettronica che permettono di introdurre elementi di formattazione del testo (Rich Text).
Quando si usano programmi grafici di composizione per i messaggi di posta elettronica è bene
controllare la configurazione per eliminare questa formattazione, che spesso è predefinita.
Figura 151.1. L’insidia dei programmi MUA grafici che utilizzano la composizione dei
messaggi in formato HTML in modo predefinito.
Le varie estensioni al codice ASCII hanno portato alla definizione di un gran numero di codifiche
differenti. Spesso è sufficiente configurare il proprio programma di composizione dei messaggi
di posta elettronica in modo da utilizzare la codifica ISO 8859-1, per poter scrivere correttamente
con le lingue di buona parte dei paesi europei (inglese inclusa). Tuttavia, anche la scelta di una
codifica come questa, che richiede l’utilizzo di 8 bit invece dei 7 bit tradizionali dell’ASCII, può
costituire un problema per qualcuno. In questo senso, quando si scrive in italiano, è «cortese»
utilizzare gli apostrofi alla fine delle vocali che avrebbero dovuto essere accentate.
151.2.1 Elementi di intestazione
Un messaggio di posta elettronica si compone inizialmente di una serie di indicazioni, tra cui
le più importanti sono quelle che servono a recapitarlo al destinatario. L’uso corretto di questi
elementi di intestazione è importante, non solo perché il messaggio raggiunga il destinatario o i
destinatari, ma anche per chiarire loro il contesto del messaggio e le persone coinvolte.
Campo
‘To:’
Descrizione
Il campo ‘To:’ viene utilizzato per definire i destinatari del messaggio. Quando si tratta di più di uno, convenzionalmente, i vari indirizzi vengono separati
attraverso una virgola.
L’indirizzo del destinatario va indicato secondo le regole consentite dagli MTA
interessati; generalmente è ammissibile una delle tre forme seguenti.
utente @host
nominativo_completo <utente @host >
"nominativo_completo " <utente @host >
Campo
‘Cc:’
‘Bcc:’
‘From:’
‘Reply-To:’
‘Subject:’
1601
Descrizione
Il campo ‘Cc:’ viene utilizzato per definire i destinatari del messaggio in copia
carbone. Nella corrispondenza normale, almeno in Italia, si utilizza la definizione «per conoscenza», intendendo che questi destinatari non sono chiamati in
causa direttamente.
In pratica, si utilizza il campo ‘Cc:’ per recapitare una copia del messaggio a dei
corrispondenti dai quali non si attende una risposta, ma che è importante siano
a conoscenza di queste informazioni.
Il campo ‘Bcc:’ viene utilizzato per definire i destinatari del messaggio a cui
deve essere inviata una copia carbone nascosta (Blind carbon copy). La differenza rispetto alla copia carbone normale sta nel fatto che i destinatari non vengono
messi a conoscenza della presenza di queste copie aggiuntive.
Il campo ‘From:’ viene utilizzato per definire l’indirizzo del mittente. Non
si tratta necessariamente del nome utilizzato dall’utente nel momento in cui
compone il messaggio, ma di quello al quale ci si aspetta di ricevere una risposta.
Il campo ‘Reply-To:’ viene utilizzato per indicare un indirizzo a cui si invita
a inviare un’eventuale risposta. Viene utilizzato in situazioni particolari, quando
per questo non si intende usare il campo ‘From:’. Tipicamente viene aggiunto
nei messaggi trasmessi da un sistema che gestisce le liste di posta elettronica (mailing-list) quando si vuole lasciare l’indicazione del mittente effettivo,
guidando la risposta verso la stessa lista.
Il campo ‘Subject:’ serve a indicare l’oggetto del messaggio. Anche se nella
corrispondenza normale l’oggetto viene usato solo nelle comunicazioni formali,
nella posta elettronica è opportuno aggiungere sempre questa indicazione.
Un oggetto chiaro permette al destinatario di capire immediatamente il conteso
per il quale viene contattato. Inoltre, quando da un messaggio si genera una
catena di risposte (cioè un thread), è importante l’oggetto che era stato scelto
inizialmente.
151.2.2 Risposta, proseguimento e riservatezza
La risposta a un messaggio viene inviata normalmente al mittente (‘From:’), a tutti i destinatari
normali (‘To:’) e a tutti quelli cui è stato inviato il messaggio per conoscenza (‘Cc:’). Questa
operazione viene fatta solitamente in modo automatico dal programma utilizzato per leggere e
comporre i messaggi: il Mail user agent (MUA). È importante però fare attenzione sempre che ciò
corrisponda alla propria volontà, o che le circostanze siano appropriate. Infatti, se sono coinvolte
diverse persone in una corrispondenza, è probabile che si giunga a un punto in cui non abbia più
significato continuare a «importunarle» quando la catena di risposte è degenerata in un contesto
differente.
I programmi MUA comuni aggiungono la sigla ‘Re:’ davanti all’oggetto, a meno che non inizi
già in questo modo, quando si risponde a un messaggio precedente. Il problema sta nel fatto
che non sempre viene rispettata questa convenzione, per cui se ne trovano altri che aggiungono
qualcosa di diverso, come ‘R:’. Così, se la catena di risposte prosegue si rischia di arrivare ad
avere un oggetto formato da una serie di ‘Re: R: Re: R:’.
Quando il messaggio a cui si risponde contiene l’indicazione del campo ‘Reply-To:’, si pone
un problema in più: la scelta corretta del destinatario. Infatti, la risposta va inviata all’indirizzo
‘Reply-To:’ solo se perfettamente conforme al contesto. Si è già accennato al fatto che questo campo viene aggiunto dai programmi di gestione delle liste di posta elettronica. In questa
situazione è molto diverso inviare una risposta alla lista o soltanto al mittente originario del
messaggio.
Quando si vuole rinviare a un altro indirizzo (forward in inglese), si dice che questo viene fatto proseguire (così come avviene nella posta normale quando l’indirizzo di destinazione non è
1602
più valido per qualche motivo). Per farlo si incorpora il messaggio originale con alcune informazioni sul mittente e sul destinatario originale, permettendo di aggiungere qualche commento
aggiuntivo.
Quando si riceve un messaggio, così come accade nella corrispondenza normale, occorre un
po’ di attenzione se si pensa di divulgarne il contenuto ad altri. Evidentemente dipende dalle
circostanze; in caso di dubbio occorre almeno chiedere il consenso della persona che lo ha scritto.
151.3 Sendmail
Come accennato, Sendmail 2 è stato l’MTA più diffuso nei sistemi Unix, tanto che anche nelle distribuzioni GNU è stato utilizzato spesso in modo predefinito. Il pregio di Sendmail è la
sua estrema configurabilità. Il suo difetto è lo stesso pregio: l’estrema configurabilità implica
un’estrema complessità.
A seconda delle opzioni con cui viene avviato l’eseguibile ‘sendmail’, si ottiene un demone in ascolto della porta SMTP (25), oppure si ottiene la trasmissione di un messaggio fornito
attraverso lo standard input, oppure si hanno altre funzioni accessorie.
Solitamente, Sendmail viene distribuito già configurato in modo standard, sia per l’attivazione
del servizio SMTP, sia per la gestione della trasmissione dei messaggi e della consegna locale;
qui si vuole solo vedere quel poco che può valere la pena di modificare, anche per un principiante. Sendmail viene trattato con maggiore dettaglio nel capitolo 155; inoltre, nel capitolo 156 si
introduce anche l’uso di Exim, un MTA alternativo e abbastanza compatibile con le convenzioni
operative di Sendmail.
151.3.1 Avvio
‘sendmail’ è l’eseguibile di Sendmail. Viene usato fondamentalmente in due modi: per
l’attivazione del servizio SMTP e per la trasmissione e la consegna locale dei messaggi.
sendmail
[opzioni]
Per l’attivazione del servizio SMTP, viene avviato normalmente come demone indipendente dal
supervisore dei servizi di rete, aggiungendo così l’opzione ‘-bd’. Naturalmente, si tratta solitamente di un’operazione che viene fatta dalla stessa procedura di inizializzazione del sistema.
Ecco come potrebbe apparire la riga che avvia ‘sendmail’ in uno script del genere:
/usr/sbin/sendmail -bd
Per l’invio di un messaggio, è sufficiente avviare ‘sendmail’, fornendogli questo attraverso lo
standard input, avendo cura di separare con una riga vuota l’intestazione dal testo. Segue un
esempio di questo tipo di utilizzo:.
$ cat | /usr/sbin/sendmail [email protected][ Invio ]
From: [email protected][ Invio ]
Subject: ciao ciao[ Invio ]
[ Invio ]
Ciao Tizio.[ Invio ]
2
1603
Quanto tempo che non ci si sente![ Invio ]
[ Ctrl+d ]
Questa forma di utilizzo dell’eseguibile ‘sendmail’ può essere utile per realizzare uno script
con qualche informazione definita in modo automatico.
Per questo tipo di utilizzo, è fondamentale la riga vuota (vuota e non solo bianca) prima del
testo del messaggio.
151.3.2 Configurazione di Sendmail
La configurazione di Sendmail è a dir poco «terribile» e si attua attraverso il file ‘/etc/
sendmail.cf’. Chi non è esperto è bene che lasci stare il file di configurazione che si ritrova,
oppure che ne scelga uno tra un gruppo già pronto e ben descritto per i suoi effetti.
È chiaro che in questa situazione ci si deve fidare della propria distribuzione GNU; di conseguenza occorre leggere la documentazione relativa che dovrebbe descrivere le scelte fatte nella
configurazione di questo servizio.
Per modificare la configurazione di Sendmail, si evita generalmente di intervenire direttamente
nel file ‘/etc/sendmail.cf’, utilizzando piuttosto dei linguaggi macro in grado di costruirne
uno con meno fatica (ciò è descritto nel capitolo 155).
151.3.3 Alias
Attraverso il file ‘/etc/aliases’ è possibile configurare una serie di alias per facilitare l’invio di messaggi di posta elettronica. Gli alias stabiliscono a chi, effettivamente, debbano essere
recapitati i messaggi.
In generale, non è conveniente che l’utente ‘root’ possa ricevere dei messaggi, per questo,
un alias potrebbe rimandare la sua posta elettronica verso il recapito corrispondente all’utente
comune riferito a quella stessa persona.
Inoltre, è importante che gli utenti fittizi (‘bin’, ‘daemon’, ecc.) non possano ricevere messaggi:
prima di tutto non esistono tali persone, inoltre ciò potrebbe servire per sfruttare qualche carenza
nel sistema di sicurezza dell’elaboratore locale.
Infine, è molto importante che vengano definiti degli alias usati comunemente per identificare il
responsabile del servizio SMTP presso il nodo locale.
L’esempio seguente mostra il file ‘/etc/aliases’ tipico, in cui si dichiarano gli alias del responsabile del servizio (‘postmaster’), gli alias degli utenti di sistema e infine l’alias dell’utente
‘root’.
postmaster: root
root: daniele
daemon: root
bin: root
sys: root
sync: root
games: root
man: root
lp: root
1604
mail: root
news: root
uucp: root
proxy: root
majordom: root
postgres: root
backup: root
msql: root
operator: root
list: root
irc: root
gnats: root
alias: root
qmaild: root
qmails: root
qmailr: root
qmailq: root
qmaill: root
qmailp: root
mailer-daemon: postmaster
webmaster: root
faxmaster: root
Purtroppo, questo file non può essere utilizzato da ‘sendmail’ così com’è, deve essere prima
tradotto nel file ‘/etc/aliases.db’ attraverso il comando ‘newaliases’.3
‘newaliases’ è un collegamento a ‘sendmail’. Quando ‘sendmail’ viene avviato con questo
nome, senza bisogno di altri argomenti, genera un nuovo file ‘/etc/aliases.db’ a partire dal
sorgente ‘/etc/aliases’.
Quindi, ogni volta che si modifica il file ‘/etc/alias’, occorre avviare ‘newaliases’.
151.3.4 Coda dei messaggi
Quando ‘sendmail’ viene avviato per ottenere l’invio di un messaggio, questo utilizza la directory ‘/var/spool/mqueue/’ per accodare ciò che non può essere trasmesso
immediatamente.
Per sapere se un messaggio è stato inviato effettivamente, occorre controllare che questa directory
sia vuota. Per questo, si può utilizzare il comando ‘mailq’ che restituisce lo stato di questa
directory.
‘mailq’ è un collegamento a ‘sendmail’. Quando ‘sendmail’ viene avviato con questo nome,
senza bisogno di altri argomenti, legge il contenuto di ‘/var/spool/mqueue/’ ed elenca in
breve i messaggi rimasti nella coda.
L’esempio seguente mostra i file di due messaggi che non sono stati recapitati per motivi diversi.
# ls -l /var/spool/mqueue[ Invio ]
total 4
-rw-------rw-------rw-------rw------3
1
1
1
1
root
root
root
root
mail
mail
mail
mail
16
10
507
535
Sep
Sep
Sep
Sep
12
12
12
12
21:01
21:09
21:02
21:09
dfVAA03244
dfVAA03507
qfVAA03244
qfVAA03507
Ci sono altri MTA, simili a Sendmail, che utilizzano questo file senza bisogno di trasformazioni.
1605
Con ‘mailq’ si ottiene invece una visione più chiara, ma soprattutto accessibile anche all’utente
comune.4
$ mailq[ Invio ]
Mail Queue (2 requests)
--Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient----------VAA03244
16
30065 Sep 12 21:01 root
(Deferred: No route to host)
[email protected]
VAA03507
10
30066 Sep 12 21:09 root
(Deferred: Connection refused by weizen.mehl.dg.)
[email protected]
L’uso di ‘mailq’ è molto importante per verificare che i messaggi siano stati inviati, specialmente
quando si utilizza un collegamento su linea commutata: prima di interrompere la comunicazione,
conviene verificare che non siano rimasti messaggi in coda.5
151.3.5 Rinvio
Il file ‘~/.forward’ può essere preparato da un utente (nella propria directory personale) per
informare il sistema di consegna locale della posta elettronica (MDA) di fare proseguire (rinviare)
i messaggi verso altri indirizzi. Il file si compone di una o più righe, ognuna contenente un
indirizzo di posta elettronica alternativo; i messaggi giunti per l’utente in questione verranno fatti
proseguire verso tutti gli indirizzi elencati in questo file.
[email protected]
L’esempio mostra semplicemente che tutti messaggi di posta elettronica ricevuti dall’utente a
cui appartiene la directory personale in cui si trova il file, devono essere rispediti all’indirizzo
[email protected].
È importante chiarire che non rimane copia dei messaggi per l’utente in questione. Si presume
che questo utente riceva la posta elettronica attraverso uno degli indirizzi elencati nel file ‘~/
.forward’.
151.4 Recapito della posta elettronica: la variabile MAIL
La posta elettronica viene recapitata normalmente all’interno di un file di testo unico, appartenente all’utente destinatario. Generalmente, si distinguono due possibilità sulla collocazione di
tale file: la directory ‘/var/mail/’ (o anche ‘/var/spool/mail’) e un file particolare nella
directory personale dell’utente.
Sendmail e altri programmi simili, utilizzano il primo modo, secondo la configurazione
predefinita, dove ogni utente ha un proprio file con un nome che corrisponde a quello dell’utenza.
I programmi utilizzati per leggere la posta elettronica devono sapere dove trovarla; in generale
si utilizza la convenzione della variabile di ambiente ‘MAIL’, che serve a definire il percorso
assoluto del file di destinazione dei messaggi.
Di solito, nel profilo di configurazione della shell appare un’istruzione simile a quella seguente,
dove si definisce l’uso di un file, il cui nome corrisponde a quello dell’utente destinatario, nella
directory ‘/var/mail/’ (si fa riferimento a una shell derivata da quella di Bourne).
MAIL="/var/mail/$USER"
export MAIL
4
In effetti, la directory ‘/var/spool/mqueue/’ e il suo contenuto non possono essere accessibili agli utenti comuni,
altrimenti i messaggi in partenza potrebbero essere letti.
5
Naturalmente, questo discorso vale se si sta usando un servente SMTP locale per ottenere l’invio del messaggio.
1606
151.5 Mail user agent
Per scrivere, inviare e leggere i messaggi di posta elettronica si utilizza normalmente un programma apposito, detto MUA o Mail user agent. Programmi di questo tipo se ne possono trovare in
grande quantità, ma difficilmente questi sono compatibili tra loro.
Il MUA storicamente più importante e quasi sempre presente nei sistemi Unix è Berkeley Mail,
ovvero Mailx.
151.5.1 Ricezione e invio dei messaggi da parte del MUA
La ricezione dei messaggi in un sistema Unix avviene principalmente dalla lettura del file usato
per il recapito di questi nel sistema locale, ovvero il file indicato nella variabile di ambiente
‘MAIL’. Questo è ciò che si limita a fare un programma come Mailx, mentre altri programmi più
sofisticati possono prelevarla direttamente da caselle remote attraverso i protocolli POP3 (a volte
anche POP2) e IMAP.
Per l’invio dei messaggi, il programma MUA di un sistema Unix ha a disposizione due possibilità. La più semplice è l’utilizzo dell’eseguibile ‘sendmail’ (inteso come MDA locale, anche se
poi l’eseguibile ‘sendmail’ può appartenere a un MDA diverso dal classico Sendmail, che però
aderisce alle convenzioni tradizionali), a cui viene passato il messaggio attraverso lo standard
input, dove poi è questo secondo programma che provvede da solo al recapito locale o all’invio ad altra destinazione attraverso il protocollo SMTP; la seconda possibilità consiste invece
nell’accedere direttamente a un servente SMTP.
Tanto per fare un esempio, Mailx è quel tipo di programma che si avvale dell’MDA locale per
spedire i messaggi, mentre tutti i programmi più sofisticati si avvalgono direttamente del protocollo SMTP. La differenza tra i due approcci è importante: se non si vuole gestire la posta
elettronica localmente, ma si ha una casella di posta remota (come quando si fa un contratto con
un ISP), si può fare affidamento esclusivamente su un servente SMTP remoto (offerto da quello
stesso ISP). Volendo invece utilizzare Mailx, o programmi simili, si è costretti a installare anche
Sendmail o un altro MUA compatibile.
In un sistema Unix comune, esistono diversi programmi che dipendono da un sistema di consegna dei messaggi locale compatibile con Sendmail. Pertanto, in generale la scelta migliore,
o anche solo obbligata, è quella di installare un MDA compatibile con Sendmail. Successivamente, partendo da questa base diventa conveniente utilizzare un programma come Fetchmail
(capitolo 152) per prelevare la posta da caselle remote per farla recapitare nuovamente attraverso il sistema di consegna locale. Pertanto, conviene poi configurare il proprio MUA per
prelevare i messaggi esclusivamente dal file indicato dalla variabile di ambiente ‘MAIL’.
151.5.2 Cartelle e formato dei dati
Un programma MUA comune consente di organizzare i messaggi ricevuti e le copie di quelli trasmessi all’interno di cartelle. Queste cartelle possono essere delle directory contenenti i messaggi
sotto forma di file differenti, oppure possono essere dei file singoli, a cui spesso si affiancano altri
file contenenti dei puntatori ai vari messaggi interni.
La forma tradizionale di queste cartelle è quella conosciuta con il nome mailbox , corrispondente
in pratica a quella del file usato per il recapito dei messaggi locali, come indicato dalla variabile
di ambiente ‘MAIL’.
1607
La gestione di cartelle in formato mailbox ha lo svantaggio di non offrire un metodo efficace
per l’accesso simultaneo da parte di più programmi, tuttavia la corrispondenza è qualcosa di
personale e difficilmente si useranno due o più programmi simultaneamente.
Nella situazione più semplice, il programma MUA gestisce le cartelle dei messaggi nel formato
mailbox, in una directory, senza aggiungere altri file (riconoscendo tutti i file della directory come
cartelle di messaggi). Eventualmente, alcune cartelle significative possono essere identificate dal
programma MUA con un nome particolare, differente dal nome reale del file corrispondente. Per
esempio, una di queste cartelle potrebbe chiamarsi «messaggi trasmessi» ed essere abbinata al
file ‘sentbox’.
Sono pochi i programmi che ancora oggi si limitano all’uso del formato mailbox, senza associare
degli indici, riconoscendo come cartelle tutti i file contenuti in una directory stabilita, ma sono
solo questi che consentono di usare la posta elettronica sia con Mailx, sia con altri programmi compatibili. Appartengono a questa categoria Pine e Balsa, che vengono descritti in questo
capitolo proprio per la loro compatibilità reciproca.
151.6 Mailx
Mailx 6 è il programma standard di gestione della posta elettronica, originariamente parte dello
Unix BSD. Si tratta di un programma piuttosto scomodo da gestire, ma rappresenta lo standard
ed è quasi indispensabile la sua presenza.
L’eseguibile ‘mail’ prevede due file di configurazione, uno generale per tutto il sistema e uno
particolare per ogni utente. Si tratta rispettivamente di ‘/etc/mail.rc’ e ‘~/.mailrc’.
Nella sua semplicità, ‘mail’ è comunque un programma ricco di opzioni e di comandi per l’utilizzo interattivo. Tuttavia, di solito, è apprezzato solo nelle situazioni di emergenza, per cui è
raro che venga sfruttato al massimo delle sue possibilità.
Per l’invio della posta, Mailx utilizza l’eseguibile ‘sendmail’, passandogli le informazioni attraverso la riga di comando e lo standard input. Questo particolare è importante se si considera
la possibilità di utilizzare un MTA differente da Sendmail. Per la lettura dei messaggi ricevuti,
Mailx legge il file specificato dalla variabile di ambiente ‘MAIL’; inoltre, generalmente salva i
messaggi letti e non cancellati nel file ‘~/mbox’ (nella directory personale dell’utente).
151.6.1 Avvio e funzionamento
‘mail’ è l’eseguibile di Mailx. Con la sua semplicità ha il vantaggio di poter utilizzare lo stan-
dard input come fonte per un testo da inviare. Di conseguenza, è ottimo per l’utilizzo all’interno
di script, anche se per questo si potrebbe richiamare direttamente l’eseguibile ‘sendmail’. La
sintassi della riga di comando è molto semplice:
mail
[opzioni] [destinatario ...]
Segue la descrizione di alcune opzioni.
Opzione
-v
-i
-I
-n
-N
6
Mailx UCB BSD
Descrizione
Visualizza un maggior numero di informazioni.
Ignora i segnali di interruzione.
Forza un funzionamento interattivo.
Non legge il file ‘/etc/mail.rc’ quando viene avviato.
Inibisce la visualizzazione delle intestazioni dei messaggi
quando viene letta o modificata la cartella della posta.
1608
Opzione
-s oggetto
-c elenco_destinatari
-b elenco_destinatari
-f cartella_della_posta
Descrizione
Permette di definire l’oggetto già nella riga di comando (se si
intendono utilizzare spazi, l’oggetto deve essere racchiuso tra
virgolette).
Permette di definire un elenco di destinatari di una copia
del documento (copia carbone). L’elenco degli indirizzi di
destinazione è fatto utilizzando la virgola come simbolo di
separazione.
Permette di definire un elenco di destinatari di una copia
carbone che non vengono menzionati nell’intestazione del
documento (blind carbon copy). L’elenco degli indirizzi di
destinazione è fatto utilizzando la virgola come simbolo di
separazione.
Permette di leggere la posta contenuta all’interno di un file
determinato.
‘mail’, se avviato allo scopo di leggere la posta, mostra un elenco dei messaggi presenti e attende
che gli vengano impartiti dei comandi in modo interattivo. Per questo mostra un invito (prompt),
formato dal simbolo ‘&’.
Ognuno di questi comandi ha un nome, che spesso può essere abbreviato alla sola iniziale. L’elenco di questi comandi è molto lungo e può essere letto dalla documentazione interna, mail(1).
Qui viene descritto solo l’utilizzo più comune, con i comandi relativi.
• Invio della posta
Per inviare della posta a una o più persone, è sufficiente avviare ‘mail’ utilizzando come
argomento gli indirizzi di destinazione delle persone da raggiungere. Per concludere l’inserimento del testo, generalmente è sufficiente inserire un punto (‘.’) all’inizio di una riga
nuova, oppure è possibile inviare il codice di EOF: [ Ctrl+d ]. Si osservi l’esempio seguente,
in cui si invia un messaggio molto semplice all’indirizzo [email protected]:
$ mail [email protected][ Invio ]
Subject: Vado in ferie[ Invio ]
Ciao Tizio,[ Invio ]
ti scrivo solo per avvisarti che parto per una settimana[ Invio ]
e durante tale periodo non potrò leggere la posta.[ Invio ]
A presto,[ Invio ]
Caio[ Invio ]
.[ Invio ]
Cc: [ Invio ]
Durante l’inserimento del messaggio è possibile impartire dei comandi speciali, definiti
attraverso delle sequenze di escape, rappresentate da una tilde (‘~’) seguita dal comando
vero e proprio. Attraverso queste sequenze di escape è possibile aggiungere indirizzi ai
destinatari in copia carbone, o in copia carbone nascosta, è possibile importare un file,
cambiare l’oggetto del messaggio... In particolare, è possibile anche passare alla scrittura
del testo attraverso un programma visuale più comodo (come VI o altro, a seconda della
configurazione).
1609
• Lettura della posta ricevuta
Per controllare la cartella della posta ricevuta e per leggere eventualmente i messaggi, è
sufficiente avviare ‘mail’ senza argomenti. ‘mail’ visualizzerà un elenco numerato delle
descrizioni dell’oggetto di ogni lettera ricevuta. Una volta avviato ‘mail’, questo presenta il
suo invito rappresentato da una e-commerciale (‘&’), dal quale è possibile dare dei comandi
a ‘mail’. In particolare, è possibile inserire il numero del messaggio che si vuole leggere.
Per leggere il successivo sarà sufficiente premere il tasto [ + ], mentre per rileggere quello
precedente è sufficiente premere il tasto [ - ]. Segue un esempio di lettura di un messaggio.
$ mail[ Invio ]
Mail version 8.1.2 01/15/2001. Type ? for help.
"/home/tizio/mail/inbox": 6 messages
>
1 [email protected]. Thu Mar 28 22:02
22/845
2 [email protected]. Sat Aug 24 09:23
15/484
Debconf: OpenLDAP Server C
Vado in ferie
& 2[ Invio ]
Message 2:
From [email protected] Sat Aug 24 09:23:39 2002
To: [email protected]
Subject: Vado in ferie
From: [email protected]
Date: Sat, 24 Aug 2002 09:23:39 +0200
Ciao Tizio,
ti scrivo solo per avvisarti che parto per una settimana
e durante tale periodo non potrò leggere la posta.
A presto,
Caio
& q[ Invio ]
Saved 1 message in /home/tizio/mbox
Held 1 message in /home/tizio/mail/inbox
• Gestione della posta ricevuta
Dopo aver letto un messaggio, lo si può cancellare con il comando ‘delete’ (‘d’) o si può
rispondere con il comando ‘reply’ (‘r’). La cancellazione della posta non è irreversibile.
Di solito si possono recuperare dei messaggi attraverso il comando ‘undelete’ (‘u’); però
i messaggi cancellati risultano di fatto invisibili.
Si distinguono due tipi di risposta che fanno riferimento a due comandi simili: ‘replay’
(‘r’), che è appena stato descritto, e ‘Replay’ (‘R’). Nel primo caso la risposta viene inviata
al mittente e a tutto l’elenco dei destinatari del messaggio di origine, mentre nel secondo la
risposta va esclusivamente al mittente del messaggio di origine.
• Gruppi di messaggi
Alcuni comandi di ‘mail’ accettano l’indicazione di gruppi di messaggi. Per esempio,
‘delete 1 5’ cancellerà i messaggi numero uno e numero cinque, ‘delete 1-5’ cancellarà i messaggi dal numero uno al numero cinque. L’asterisco (‘*’) viene utilizzato per
identificare tutti i messaggi, mentre il simbolo ‘$’ rappresenta l’ultimo messaggio. Un caso
tipico di utilizzo dell’asterisco come gruppo totale dei messaggi è il seguente: ‘top *’ che
permette così di visualizzare le prime righe di tutti i messaggi ricevuti.
• Conclusione dell’elaborazione della posta
Per concludere la sessione di lavoro con ‘mail’ è sufficiente utilizzare il comando ‘quit’
(‘q’). Di solito, salvo intervenire nella configurazione, la posta letta (e non segnata per
la cancellazione) viene trasferita nel file ‘~/mbox’, mentre quella non letta rimane nella
cartella originale.
1610
151.6.2 Configurazione di Mailx
Si è già accennato al fatto che Mailx utilizzi due file di configurazione: ‘/etc/mail.rc’ per
tutto il sistema e ‘~/.mailrc’ per le particolarità di ogni utente. Le direttive di questo file sono
gli stessi comandi che possono essere impartiti a ‘mail’ durante il suo funzionamento interattivo.
In generale, si utilizzano prevalentemente i comandi ‘set’ e ‘unset’, che permettono l’attivazione o la disattivazione di alcune modalità di funzionamento, consentendo anche la definizione
di alcune opzioni che prevedono l’indicazione di un’informazione precisa.
Segue la descrizione di alcune modalità di funzionamento controllate dai comandi ‘set’ e
‘unset’.
Direttiva
|
set unset append
|
set unset ask
|
set unset asksub
|
set unset askcc
|
set unset askbcc
|
set unset dot
|
set unset hold
|
set unset ignoreeof
Descrizione
L’attivazione di questa modalità fa sì che i messaggi salvati
nel file ‘~/mbox’ siano aggiunti in coda, invece che inseriti
all’inizio.
L’attivazione di questa modalità fa sì che ‘mail’ richieda l’indicazione dell’oggetto prima di consentire l’inserimento del
testo del messaggio.
L’attivazione di questa modalità fa sì che ‘mail’ richieda l’indicazione di destinatari aggiuntivi in copia carbone alla fine
dell’inserimento del messaggio.
L’attivazione di questa modalità fa sì che ‘mail’ richieda l’indicazione di destinatari aggiuntivi in copia carbone nascosta
(‘bcc’) alla fine dell’inserimento del messaggio.
L’attivazione di questa modalità fa sì che ‘mail’ consenta
l’uso di un punto isolato per terminare l’inserimento di un
messaggio.
L’attivazione di questa modalità fa sì che ‘mail’ conservi i
messaggi letti nella cartella (senza trasferirli in ‘~/mbox’), se
questi non vengono cancellati esplicitamente.
L’attivazione di questa modalità fa sì che ‘mail’ non permetta
l’uso del codice di EOF ([ Ctrl+d ]) per terminare l’inserimento
di un messaggio.
Segue la descrizione di altre opzioni.
Direttiva
set EDITOR=programma
set VISUAL=programma
set PAGER=programma
set crt=n-righe
set MBOX=percorso
Descrizione
Permette di definire il percorso assoluto del programma che
si vuole utilizzare per la modifica del testo di un messaggio, quando viene richiesto espressamente durante il suo
inserimento, attraverso la sequenza di escape ‘~e’.
si vuole utilizzare per la modifica del testo di un messaggio, quando viene richiesto espressamente durante il suo
inserimento, attraverso la sequenza di escape ‘~v’.
si vuole utilizzare per scorrere il contenuto di un messaggio
quando questo viene letto attraverso ‘mail’. Perché funzioni
correttamente, occorre definire anche l’opzione ‘crt’.
Permette di definire il numero di righe di altezza dello schermo, in modo da poter gestire correttamente il programma di
impaginazione visuale (‘more’ o ‘less’).
Permette di definire il percorso assoluto del file da utilizzare
per salvare i messaggi, al posto di ‘~/mbox’.
Direttiva
set record=percorso
set folder=percorso
1611
Descrizione
Permette di definire il percorso assoluto di un file da utilizzare
per salvare una copia dei messaggi che vengono inviati.
Permette di definire il percorso assoluto di una directory
contenenti file corrispondenti a cartelle di messaggi.
set append dot save asksub
Quello che si vede sopra è il contenuto del file di configurazione generale tipico (il file ‘/etc/
mail.rc’).
set MBOX=/home/tizio/mail/ricevuta
set record=/home/tizio/mail/spedita
set folder=/home/tizio/mail
L’esempio si riferisce a un file di configurazione personale, ovvero ‘~/.mailrc’, dove l’utente
vuole gestire la sua posta nella directory ‘~/mail/’ (si tratta dell’utente ‘tizio’), dove possono
trovarsi anche altri file intesi come cartelle di messaggi.
set MBOX="$HOME/mail/ricevuta"
set record="$HOME/mail/spedita"
set folder="$HOME/mail"
Questo esempio produce lo stesso risultato di quello precedente, con la differenza che i percorsi
includono la variabile di ambiente ‘HOME’, che si espande nella directory personale dell’utente; in
questo modo, tale configurazione potrebbe anche essere generalizzata e inserita nel file ‘/etc/
mail.rc’.
151.7 Nail
Nail 7 è un programma funzionalmente simile a Mailx, che consente l’uso di allegati MIME ed è
in grado di servirsi direttamente di un servente SMTP per l’invio dei messaggi.
Anche la configurazione è compatibile con quella di Mailx, tanto che viene utilizzato lo stesso
file ‘~/.mailrc’ per gli utenti, mentre la configurazione generale è contenuta nel file ‘/etc/
nail.rc’ per sicurezza.
151.8 Pine
Pine 8 è un programma per la gestione della posta più potente e pratico rispetto al normale Mailx,
che consente eventualmente anche la lettura delle news.
In particolare, per l’invio dei messaggi, Pine utilizza il protocollo SMTP, cosa che permette
di utilizzarlo anche senza avere installato Sendmail localmente, o un altro MTA simile. Infatti,
spesso si utilizza la posta elettronica soltanto per Internet, disponendo di un solo elaboratore
personale, senza alcuna necessità di gestire la posta elettronica locale. In questi casi, Sendmail e
Mailx, potrebbero essere considerati dei componenti inutili (o quasi) del sistema.
Generalmente si avvia l’eseguibile ‘pine’ senza argomenti. La prima volta che ogni utente
lo utilizza, crea una directory ‘~/mail’ contenente ‘~/mail/saved-messages’ e ‘~/mail/
sent-mail’ entrambi vuoti; inoltre prepara un file di configurazione, ‘~/.pinerc’. Dopo una
prima schermata di presentazione, Pine mostra il suo menù (figura 151.2).
7
8
Nail UCB BSD e altre
Pine software non libero: non è consentita la distribuzione di versioni modificate
1612
Figura 151.2. Menù principale di Pine.
?
HELP
-
Get help using Pine
C
COMPOSE MESSAGE
-
Compose and send a message
I
FOLDER INDEX
-
View messages in current folder
L
FOLDER LIST
-
Select a folder to view
A
ADDRESS BOOK
-
Update address book
S
SETUP
-
Configure or update Pine
Q
QUIT
-
Exit the Pine program
Copyright 1989-1999.
PINE is a trademark of the University of Washington.
? Help
P PrevCmd
O OTHER CMDS L [ListFldrs] N NextCmd
R RelNotes
K KBLock
Probabilmente, la cosa più utile da fare la prima volta che si utilizza questo programma, è quella
di configurarlo, utilizzando la lettera ‘S’ come sinonimo di Setup. Si ottiene un sottomenù:
Choose a setup task from the menu below :
? Help
P [Printer]
C Config
S Signature
^C Cancel
N Newpassword U Update
Premendo la lettera ‘C’ come sinonimo di Config si arriva alla maschera di configurazione. La
maschera non può essere contenuta tutta in una sola schermata, di conseguenza, si utilizzano la
[ barra spaziatrice ] per scorrerla in avanti e il segno [ - ] per scorrerla all’indietro. Quella seguente è
la prima parte della configurazione predefinita (cioè quella iniziale) dell’utente ‘tizio’.
personal-name
user-domain
smtp-server
nntp-server
inbox-path
folder-collections
news-collections
incoming-archive-folders
pruned-folders
default-fcc
default-saved-msg-folder
postponed-folder
read-message-folder
signature-file
global-address-book
address-book
...
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
<No
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Value
Set:
Set>
Set>
Set>
Set:
Set:
Set>
Set>
Set>
Set:
Set>
Set:
Set>
Set:
Set>
Set:
using "Tizio">
using "inbox">
using mail/[]>
using "sent-mail">
using "postponed-msgs">
using ".signature">
using .addressbook>
Vale la pena di definire almeno la prima parte. Per inserire un dato nuovo si usa la lettera ‘a’
come sinonimo di add, mentre per modificare un valore preesistente si uilizza la lettera ‘c’ come
sinonimo di change. Per cancellare una voce si utilizza la lettera ‘d’ come sinonimo di delete.
Alcune voci consentono l’inserimento di dati multipli utilizzando una successione di richieste di
inserimento.
151.8.1 Elementi di configurazione
Segue un elenco parziale degli elementi che possono essere configurati, assieme a una breve
descrizione del loro significato.
Direttiva
‘personal-name’
‘user-domain’
‘smtp-server’
‘nntp-server’
‘inbox-path’
‘folder-collections’
‘news-collections’
‘incoming-archive-folders’
‘pruned-folders’
‘default-fcc’
‘default-saved-msg-folder’
‘postponed-folder’
‘read-message-folder’
‘signature-file’
‘address-book’
‘feature-list’
1613
Descrizione
Si riferisce al nome che si vuole fare apparire come mittente
della posta inviata.
Si tratta del dominio dell’utente, ovvero l’indirizzo dell’elaboratore presso il quale si vuole ricevere la posta.
Si tratta dell’indirizzo dell’elaboratore attraverso il quale si
invia la posta: potrebbe trattarsi del nome completo del proprio elaboratore, nel caso si voglia gestire un servente SMTP
locale, di un altro all’interno della propria rete locale, o di
quello offerto dal fornitore di accesso a Internet.
È l’indirizzo dell’elaboratore utilizzato per il servizio NNTP
(Network news transfer protocol), quello che quindi permette
di accedere a Usenet. Possono essere indicati diversi serventi
NNTP.
Indica il percorso assoluto del file usato come cartella della
posta in ingresso. In un sistema normale potrebbe trattarsi di
‘/var/mail/utente ’, oppure di qualunque altro file se il proprio sistema è configurato diversamente per la gestione della
posta.
Letteralmente è la raccolta delle cartelle. Si riferisce alle directory contenenti file di posta. Pine crea la directory ‘~/
mail’, ma ne possono essere usate diverse contemporaneamente. Ogni directory indicata è seguita da due parentesi
quadre: una aperta e una chiusa.
Permette di definire le collezioni di news a cui si è interessati.
Permette di definire una serie di coppie di cartelle di posta (le
coppie sono separate da uno spazio) per il salvataggio automatico della posta letta. Quando si legge la posta contenuta
nelle cartelle di ingresso (la prima cartella di ogni coppia),
automaticamente, questa viene segnata come letta e trasferita
nelle cartelle di archiviazione (la seconda cartella di ogni coppia). Questa funzionalità viene attivata attraverso l’opzione
‘auto-move-read-messages’.
Permette di definire l’elenco di cartelle che possono essere
potate mensilmente come già definito automaticamente per la
cartella della posta inviata. Con questo termine, potatura, si
intende l’archiviazione delle cartelle in questione ogni mese,
utilizzando un nome preceduto dal nome del mese. Contemporaneamente si intende la cancellazione di eventuali archivi
della stessa serie di mesi precedenti.
Definisce il file destinatario di una copia carbone dei messaggi
inviati (File carbon copy). Il valore predefinito corrisponde in
pratica a ‘~/mail/sent-mail’.
Definisce il file predefinito per il salvataggio dei messaggi.
Definisce il file utilizzato per contenere i messaggi sospesi che
verranno inviati in seguito. Il valore predefinito corrisponde in
pratica a ‘~/mail/postponed-msgs’.
Permette di definire una cartella (cioè un file) da utilizzare per
scaricare automaticamente lì la posta letta.
Definisce il nome del file da utilizzare come firma, ovvero
come parte terminale standard dei propri messaggi.
Definisce il nome del file usato come rubrica personale di indirizzi. Il valore predefinito corrisponde a ‘~/
.address-book’.
Permette di configurare una serie di opzioni di Pine. Per selezionare o deselezionare una di queste opzioni, si utilizza la
lettera ‘X’.
1614
Direttiva
‘initial-keystroke-list’
‘default-composer-hdrs’
‘customized-hdrs’
‘sort-key’
‘addrbook-sort-rule’
‘character-set’
‘editor’
‘speller’
‘composer-wrap-column’
‘reply-indent-string’
Descrizione
Consente di indicare una sequenza di tasti (una macro) da
premere automaticamente ogni volta che si avvia Pine.
Permette di definire la parte di intestazione dei messaggi che
si intendono utilizzare. Se viene utilizzata questa indicazione,
occorre definire tutte le parti dell’intestazione dei messaggi.
Definisce la parte di intestazione aggiuntiva da utilizzare nei
messaggi quando si specifica espressamente di voler utilizzare la cosiddetta intestazione ricca .
In certi casi è importante poter definire un elemento particolare nell’intestazione, per esempio quando si ha la necessità
di comandare un programma di gestione di una lista di posta
elettronica. Nel caso particolare di SmartList, l’amministratore di una lista ha la necessità di aggiungere l’intestazione
‘X-Command’.
Permette di definire l’ordine in cui devono apparire i messaggi
all’interno delle varie cartelle.
Permette di definire l’ordine in cui devono apparire gli
indirizzi della rubrica.
Permette di definire la codifica utilizzata per la composizione del testo. Il valore predefinito è ‘US-ASCII’, altri valori
potrebbero essere ‘ISO-8859-n ’, dove n rappresenta un numero compreso tra uno e nove, oppure 13 o 15.
Per l’Italia e gran parte del mondo occidentale, si utilizza
normalmente la codifica ISO 8859-1.
Permette di specificare il nome di un programma per la
scrittura di testi alternativo a quello fornito da Pine, che poi
può essere utilizzato attraverso la combinazione [ Ctrl+_ ]
(ovvero [ Ctrl+- ] nel caso della tastiera italiana).
Per attivare questa funzione, oltre a indicare qui il nome del programma alternativo, occorre impostare anche
l’opzione
‘enable-alternate-editor-cmd’.
eventualmente, si può imporre l’uso sistematico di
questo programma esterno, attivando anche l’opzione
‘enable-alternate-editor-implicitly’.
Permette di indicare il programma da utilizzare per il controllo ortografico. Quando il controllo ortografico viene richiesto
durante la fase di composizione di un messaggio attraverso
la sequenza [ Ctrl+t ], Pine invia al programma indicato un file
temporaneo contenente il testo da controllare.
Permette di definire la larghezza massima del testo in fase di
composizione dei messaggi.
Permette di definire la stringa (ovvero il simbolo) da usare per
evidenziare il testo proveniente dal messaggio al quale si sta
rispondendo. Se si vuole che questa stringa contenga le iniziali del nome della persona che l’ha scritto, si può utilizzare la
variabile ‘_INIT_’ che verrà sostituita con questo nome. Per
esempio si potrebbe utilizzare la stringa seguente:
‘"_INIT_>"’
Direttiva
1615
Descrizione
Quando si invia posta utilizzando indirizzi solo su ‘Bcc’
(Blind carbon copy) e lasciando quindi vuoti i campi ‘To’,
‘Cc’ e ‘Newsgroup’, Pine mette un indirizzo speciale nel
campo ‘To’. Ciò viene fatto per evitare problemi con alcuni programmi per il trasferimento della posta che autonomamente tendono a riempire questo campo con il destinatario apparente del messaggio, vanificando il senso della posta inviata utilizzando il Blind carbon copy. Il valore predefinito di questo destinatario inesistente è ‘Undisclosed
recipients’.
Permette di definire il programma da utilizzare per visualizzare le immagini allegate ai messaggi (allegati
MIME).
Questa opzione viene utilizzata solo se non viene definita la voce ‘user-domain’ corrispondente al nome
dell’elaboratore presso il quale si vuole ricevere la posta.
‘empty-header-message’
‘image-viewer’
‘use-only-domain-name’
Alla fine, la parte iniziale della maschera di configurazione potrebbe apparire come la seguente:
personal-name
user-domain
smtp-server
nntp-server
inbox-path
folder-collections
news-collections
incoming-archive-folders
pruned-folders
default-fcc
default-saved-msg-folder
postponed-folder
read-message-folder
signature-file
global-address-book
address-book
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
Tizio Tizi
weizen.mehl.dg
weizen.mehl.dg
news.notiziario.dg
/var/mail/tizio
~/Mail/[]
<No Value Set>
<No Value Set>
<No Value Set>
sent-mail
saved-mail
postponed-msgs
<No Value Set>
~/.signature"
<No Value Set>
~/.addressbook
151.8.2 File di configurazione
La configurazione che si definisce in modo interattivo, viene salvata nel file ‘~/.pinerc’ (nella
directory personale dell’utente). Questo file risulta essere commentato molto bene e può essere
comodo ritoccare qualche direttiva direttamente al suo interno, senza passare per la procedura
interattiva.
Oltre ai file di configurazione personali, ne esiste uno generale, ‘/etc/pine.conf’, che serve
per definire un’impostazione generale predefinita, lasciando agli utenti la possibilità di modificare
ciò che interessa nella configurazione personale. La sintassi per le direttive di questo file è la
stessa di quella dei file personalizzati, ma in generale si lascia quanto fornito in modo predefinito
dalla distribuzione del programma.
Infine, esiste la possibilità di definire una configurazione generale che non può essere cambiata
dalla configurazione personale degli utenti. Si tratta del file ‘/etc/pine.conf.fixed’ e il suo
utilizzo può essere utile per evitare errori di configurazione agli utenti. Ecco un esempio di ciò
che potrebbe contenere questo file:
1616
#
#
/etc/pine.conf.fixed -- system wide pine configuration FIXED
# Path of (local or remote) INBOX, e.g. ={mail.somewhere.edu}inbox
# Normal Unix default is the local INBOX (usually /usr/spool/mail/$USER).
inbox-path=~/mail/inbox
# List of directories where saved-message folders may be. First one is
# the default for Saves. Example: Main {host1}mail/[], Desktop mail\[]
# Syntax: optnl-label {optnl-imap-hostname}optnl-directory-path[]
folder-collections=~/mail/[]
# List of SMTP servers for sending mail. If blank: Unix Pine uses sendmail.
smtp-server=mail.brot.dg
In questo modo, si impone agli utenti l’uso del file ‘~/mail/inbox’ per ricevere la posta, cosa
che deriva presumibilmente dalla configurazione del sistema di consegna locale; viene definito anche i file per la raccolta dei messaggi si trovano solo nella directory ‘~/mail/’; infine
si stabilisce che i messaggi devono essere inviati esclusivamente attraverso il servente SMTP
mail.brot.dg.
151.9 Balsa
Balsa 9 è un programma grafico per la gestione della posta elettronica, che consente l’accesso
diretto al servente SMTP per l’invio dei messaggi e ai serventi POP3 per il prelievo dei messaggi
ricevuti presso caselle postali remote.
La prima volta che si avvia Balsa, attraverso l’eseguibile ‘balsa’, viene proposta una configurazione iniziale e generalmente vengono creati dei file nella directory ‘~/mail/’. Inoltre, viene
cercato il file locale dei messaggi ricevuti nella directory ‘/var/spool/mail/’ (oppure ‘/var/
mail/’, a seconda dell’impostazione del proprio sistema). A parte il resto della configurazione
che dovrebbe essere abbastanza intuitivo, occorre tenere in considerazione che Balsa abbina il
nome di una cartella di posta a un file, che non ha necessariamente lo stesso nome.
Balsa genera e aggiorna da solo il proprio file di configurazione, che ovviamente varia per ogni
utente che lo utilizza, essendo ‘~/.gnome/balsa’. Alle volte può essere conveniente controllare
e modificare direttamente il contenuto di questo file, senza passare per la procedura grafica,
perché questa può far perdere di vista ciò che in realtà si sta cercando di modificare.
[mailbox-Inbox]
Path=/home/tizio/mail/inbox
Type=LibBalsaMailboxMbox
Name=Posta ricevuta
[mailbox-Outbox]
Path=/home/tizio/mail/outbox
Name=Posta in uscita
[mailbox-Sentbox]
Path=/home/tizio/mail/sentbox
Name=Posta inviata
[mailbox-Draftbox]
Path=/home/tizio/mail/draftbox
Name=Bozze
9
Balsa GNU GPL
1617
[mailbox-Trash]
Path=/home/tizio/mail/trash
Name=Cestino
[Globals]
MailDir=/home/tizio/mail
OpenInboxOnStartup=false
Debug=false
AutoCloseMailbox=true
AutoCloseMailboxTimeout=10
OpenMailboxes=Mailbox Mailbox Mailbox
RememberOpenMailboxes=false
EmptyTrash=false
[identity]
CurrentIdentity=default
[identity-default]
ReplyString=Re:
ForwardString=Fwd:
SignaturePath=/home/tizio/.signature
SigExecutable=false
SigSending=true
SigForward=false
SigReply=false
SigSeparator=false
SigPrepend=true
...
Purtroppo, è possibile commettere degli errori di configurazione, anche attraverso la guida
grafica offerta dal programma stesso. In presenza di errori gravi, si compromette il funzionamento di Balsa e l’unico modo per rimediare è intervenire a mano nel file di configurazione,
osservando intuitivamente il significato delle direttive contenute.
Osservando l’esempio di file di configurazione mostrato, si intuisce l’importanza di cinque
cartelle di posta:
• inbox è la cartella dei messaggi ricevuti;
• outbox è la cartella dei messaggi accodati per la spedizione, che per qualche ragione non
sono ancora stati inviati attraverso un servente SMTP (forse in attesa della connessione);
• sentbox è la cartella dei messaggi spediti, esclusi quelli che si trovano ancora nella cartella
outbox;
• draftbox è la cartella dei messaggi il cui invio è stato ritardato volontariamente, per
consentire una continuazione in un momento successivo;
• trash è la cartella in cui vengono salvati inizialmente i messaggi destinati all’eliminazione.
Oltre alle cartelle standard, tutti i file contenuti nella directory definita dalla direttiva
‘LocalMailDir’ (normalmente corrisponde a ‘~/mail/’), che non sono abbinati ad alcuna
cartella particolare, diventano cartelle ulteriori, con lo stesso nome del file relativo.
1618
Figura 151.3. La finestra principale di Balsa, con le cartelle di posta normali.
151.10 Configurazione compatibile tra Mailx, Nail, Pine e
Balsa
In questa sezione si vuole mostrare in che modo si possono configurare Mailx, Nail, Pine e per
consentire il loro utilizzo in modo indifferente, sulle stesse cartelle di messaggi.
Per prima cosa si deve decidere in quale directory verranno contenuti i file, in formato mailbox, delle cartelle. Si suppone di usare la directory ‘~/mail/’ per tutti gli utenti del sistema,
stabilendo anche che la posta in ingresso viene consegnata nel file ‘~/mail/inbox’.
In generale, per informare della presenza della cartella dei messaggi in ingresso basta impostare
la variabile di ambiente ‘MAIL’. Per intervenire su tutti gli utenti si può intervenire nel file ‘/etc/
profile’ (nel caso di una shell compatibile con quella di Bourne), come in questo esempio:
MAIL="$HOME/mail/inbox"
export MAIL
Naturalmente, si deve provvedere a configurare anche il sistema di consegna locale dei messaggi,
in modo che funzioni così, altrimenti la posta potrebbe risultare inserita in file all’interno della
directory ‘/var/mail/’, o ‘/var/spool/mail/’, nonostante tutte le buone intenzioni.
Il passo successivo è la definizione di alcune cartelle, più o meno standard. Per esempio è necessario stabilire la collocazione della posta inviata, di quella che è in coda e di quella che è stata
solo abbozzata (iniziata ma non completata). Si potrebbe stabilire questa associazione:
Cartella
posta in ingresso
posta in uscita o in coda per l’invio
posta spedita
posta letta
bozze di messaggi da trasmettere
messaggi in attesa di essere eliminati
File corrispondente
‘~/mail/inbox’
‘~/mail/outbox’
‘~/mail/sentbox’
‘~/mail/readbox’
‘~/mail/draftbox’
‘~/mail/trash’
1619
Non tutti i programmi che si intendono utilizzare richiedono tutte queste cartelle, ma almeno
sono in grado di accedervi.
Si può stabilire anche l’uso di un file contenente una «firma», ovvero alcune righe da accodare
a tutti i messaggi che vengono trasmessi. Per esempio, si può stabilire che debba trattarsi del
contenuto del file ‘~/.signature’.
Segue la porzione di configurazione da usare sia per il file ‘/etc/mail.rc’, sia per ‘/etc/
nail.rc’, in favore di Mailx e di Nail:
set
set
set
set
append
folder="$HOME/mail"
MBOX="$HOME/mail/readbox"
record="$HOME/mail/sentbox"
In questo modo, Mailx e Nail troveranno la posta in ingresso nel file ‘~/mail/inbox’, perché
così è annotato nella variabile di ambiente ‘MAIL’; inoltre i messaggi letti e quelli trasmessi
verranno inseriti correttamente nelle cartelle previste. L’accesso alle altre cartelle di messaggi
risulta comunque facilitato perché è stata indicata la directory ‘~/mail/’ in modo predefinito.
Nel caso particolare di Nail, si potrà aggiungere anche l’indicazione del file da usare come firma:
set signature="$HOME/.signature"
Per quanto riguarda Pine, si potrà intervenire nel file ‘/etc/pine.conf’, o addirittura in
‘/etc/pine.conf.fixed’, se si vuole evitare che gli utenti possano commettere degli errori di
configurazione:
inbox-path=~/mail/inbox
folder-collections=~/mail/[]
default-fcc=sentbox
postponed-folder=draftbox
default-saved-msg-folder=readbox
signature-file=~/.signature
Purtroppo, per Balsa non è facile definire una configurazione generale; quello che segue è il file
‘~/.gnome/balsa’ che l’utente ‘tizio’ potrebbe utilizzare inizialmente, coerentemente con
quanto già definito:
1620
[mailbox-Inbox]
Path=/home/tizio/mail/inbox
Name=Posta ricevuta
[mailbox-Outbox]
Path=/home/tizio/mail/outbox
Name=Posta in uscita
[mailbox-Sentbox]
Path=/home/tizio/mail/sentbox
Name=Posta inviata
[mailbox-Draftbox]
Path=/home/tizio/mail/draftbox
Name=Bozze
[mailbox-Trash]
Path=/home/tizio/mail/trash
Name=Cestino
[Globals]
MailDir=/home/tizio/mail
[identity-default]
SignaturePath=/home/tizio/.signature
151.11 Ricerche nei file delle cartelle di messaggi
I file delle cartelle di posta elettronica in formato mailbox, sono file di testo organizzati secondo
una certa struttura. All’interno di questi file è possibile eseguire delle ricerche con Grep, ma
il vero problema è quello di identificare il messaggio che contiene la stringa o l’espressione
cercata. Per questo conviene usare invece Grepmail, 10 ovvero un programma Perl che restituisce
il messaggio intero e non soltanto la riga che corrisponde al modello di ricerca.
Grepmail non si limita a questo, consentendo anche una ricerca selettiva nel corpo dei messaggi, nell’oggetto, escludendo eventualmente gli allegati. Il suo utilizzo più semplice è quello
rappresentato dall’esempio seguente:
$ grepmail "Tizi[oa]" ~/mail/sentbox | less
In questo caso si cercano tutti i messaggi contenuti nel file ‘~/mail/sentbox’ che corrispondono in qualche modo con l’espressione regolare ‘Tizi[oa]’. Con l’ausilio di ‘less’, si scorrono
facilmente sullo schermo.
Trattandosi di un programma scritto in Perl, le espressioni regolari che si possono utilizzare
devono avere le caratteristiche di questo linguaggio di programmazione.
grepmail
[opzioni] [-e]
espressione_regolare
[file_cartella_messaggi]...
Il modello sintattico mostra due particolarità: l’espressione regolare può essere indicata da sola
oppure come argomento dell’opzione ‘-e’; i file delle cartelle dei messaggi possono essere forniti
come argomenti finali della riga di comando, ma in loro mancanza, viene letto lo standard input.
La tabella 151.7 riepiloga le altre opzioni più importanti.
10
Grepmail GNU GPL
1621
Tabella 151.7. Opzioni più importanti di Grepmail.
Opzione
Descrizione
Esegue la ricerca esclusivamente nel corpo dei messaggi.
Esegue la ricerca esclusivamente nell’intestazione del
messaggi.
Non distingue tra lettere maiuscole e minuscole.
Emette solo il nome del file contenente i messaggi
corrispondenti.
Ignora gli allegati MIME di tipo binario.
Cerca ricorsivamente nelle sottodirectory.
Cerca i messaggi che non corrispondono al modello.
-b
-h
-i
-l
-M
-R
-v
|
-d today yesterday
Seleziona solo i messaggi di oggi o di ieri.
-d mm /gg/aaaa
Seleziona solo i messaggi di una certa data.
{
|
}
-d {before|after|since}data
Seleziona solo i messaggi di n giorni o settimane fa.
-d
n days ago n weeks ago
-d between data and data
-e espressione_regolare
I messaggi più vecchi, più recenti, o a partire da una data di
riferimento.
Seleziona solo i messaggi compresi tra due date.
Dichiara espressamente il modello di ricerca.
Vengono mostrati solo alcuni esempi.
$ grepmail -h -i "From: .*[email protected]" ~/mail/* | less
Cerca tutti i messaggi nella directory ‘~/mail/’ che sono stati inviati presumibilmente da
[email protected]. Il risultato viene fatto scorrere con l’aiuto di ‘less’.
$ grepmail -h -i "From: .*[email protected]" ~/mail/* > pinco
$ grepmail -h -i -v "From: .*[email protected]" ~/mail/* > altri
I due comandi servono a estrarre tutti i messaggi provenienti presumibilmente da
[email protected], per generare il file ‘pinco’, mettendo tutto il resto in un file
denominato ‘altri’.
$ grepmail -h -d "since 7 days ago" -i ←,→-e "From: .*[email protected]" ~/mail/* | less
Cerca tutti i messaggi nella directory ‘~/mail/’ che sono stati inviati presumibilmente da
[email protected] entro gli ultimi sette giorni. Il risultato viene fatto scorrere con
l’aiuto di ‘less’.
Capitolo
152
Messaggi giunti presso recapiti remoti
I messaggi di posta elettronica non vengono sempre recapitati presso l’elaboratore che si utilizza
abitualmente. Questa è la situazione tipica in cui ci si trova quando si è collegati a Internet tramite
un ISP, per mezzo di una linea commutata. Di solito si ottiene un accesso (account) presso un
elaboratore dell’ISP e questo diventa solitamente anche il recapito per la posta elettronica.
Il problema è comunque generale: si può avere la necessità di scaricare la posta ricevuta presso
un recapito remoto.
La prima idea che può venire in mente può essere quella di usare il protocollo TELNET e leggere
così la posta remota. Ma questa non è la soluzione corretta. Per trasferire la posta da un recapito
a un altro, si usa solitamente il protocollo POP3 (a volte POP2) oppure IMAP. Come si può
immaginare, si tratta di un servizio che deve essere gestito da un demone.
Il modo con cui vengono scaricati messaggi e inseriti nel sistema locale ha dei risvolti importanti.
Infatti, questi messaggi possono essere scaricati in un file locale, che normalmente corrisponde
alla cartella della posta in ingresso dell’utente, il quale può leggerla attraverso ‘mail’ o un altro
programma che sfrutta lo stesso meccanismo. In alternativa, i messaggi potrebbero essere inseriti
nel sistema locale attraverso un servizio SMTP, che in tal caso però, dovrebbe essere attivato
necessariamente.
152.1 Concetti generali
Quando la posta elettronica è giunta presso un recapito remoto, senza essere stata ridiretta da lì
attraverso un alias o un forward per il suo proseguimento, può essere prelevata per mezzo di vari
protocolli, tra cui i più importanti sono POP2, POP3 e IMAP.
Il prelievo fatto in questo modo, può tradursi poi:
• nello scarico dei messaggi in un file locale che rappresenta la cartella della posta in ingresso
dell’utente per cui si svolge l’operazione;
• nell’invio dei messaggi attraverso l’MDA locale;
• nell’invio dei messaggi attraverso un servente SMTP locale, o comunque uno più «vicino».
Ognuna delle scelte possibili ha dei vantaggi e degli svantaggi. Il primo tipo di operazione, non
richiede la presenza di un servente SMTP locale e nemmeno di un MDA, cioè di un Mail delivery agent, per la consegna locale del messaggio. Così si presta perfettamente all’uso presso
nodi isolati che possono connettersi a Internet attraverso una linea commutata, che solo allora
trasmettono e ricevono la posta elettronica.
Il secondo tipo di operazione richiede la presenza di un MDA, composto generalmente da un
programma in grado di ricevere i messaggi attraverso lo standard input, che poi sia in grado di
recapitarli localmente ed eventualmente di farli proseguire altrove attraverso gli alias e i forward
eventuali. In pratica però, l’MDA a cui si fa riferimento è quasi sempre Sendmail, o un altro
sistema compatibile. Il vantaggio di questa scelta è che per attuarla non occorre attivare il servizio
SMTP, cioè non è necessario che Sendmail sia stato avviato come demone in ascolto della porta
SMTP.
L’ultimo caso richiede invece che localmente sia presente un MTA completo, in grado di ricevere
le connessioni SMTP.
1622
1623
I motivi per cui non si riceve la posta direttamente nel nodo locale, possono essere vari: la connessione con l’esterno potrebbe essere discontinua, come nel caso di un collegamento PPP attraverso
linea commutata; il sistema remoto presso cui giunge la posta per qualche motivo, potrebbe avere delle politiche che impediscono il proseguimento dei messaggi (il forward); il sistema locale
potrebbe essere irraggiungibile dall’esterno a causa delle politiche di sicurezza adottate, per cui,
la posta elettronica potrebbe non essere trasferita localmente, lasciando l’onere a ogni nodo di
prelevarsela da un servente principale.
Negli ultimi due tipi di trasferimento, il programma che lo fa interviene come se fosse un MTA
vero e proprio. In tal senso, potrebbe essere attivato periodicamente attraverso il sistema Cron, a
intervalli brevi, oppure come un demone.
152.1.1 Autenticazione
Il prelievo della posta remota è un’operazione personale dell’utente che ha l’accesso presso il
sistema remoto. Il programma che si usa per accedere a uno di questi servizi che lo permettono,
deve identificarsi in qualche modo; di solito si tratta di fornire l’identità dell’utente remoto e la
parola d’ordine.
Il fatto di lasciare viaggiare la parola d’ordine in chiaro, attraverso la rete, è un problema da non
trascurare: finché la connessione è diretta (o quasi, come nel caso di una linea commutata), il
problema è minimo; quando la connessione attraversa più nodi, il problema diventa delicato.
Oltre a questo, occorre considerare che le informazioni delicate come le parole d’ordine non
possono apparire in una riga di comando, perché sarebbero leggibili semplicemente analizzando
l’elenco dei processi attivi. Per questo, quando si vuole automatizzare il processo di recupero
della posta remota senza dover ogni volta inserire la parola d’ordine, questa può essere annotata
soltanto in un file di configurazione, protetto opportunamente contro ogni accesso da parte di altri
utenti.
152.2 IMAP toolkit: ipop3d, ipop2d, imapd
IMAP toolkit è una raccolta di demoni per i servizi di trasferimento della posta locale verso i
clienti che lo richiedono, mostrando le credenziali necessarie. Si tratta precisamente dei programmi ‘ipop3d’, ‘ipop2d’ e ‘imapd’. Permettono rispettivamente di utilizzare i protocolli POP3,
POP2 e IMAP. Sono gestiti normalmente dal supervisore dei servizi di rete. 1
Nell’esempio seguente, vengono mostrate le righe di ‘/etc/inetd.conf’ in cui si dichiara il
loro possibile utilizzo per quanto riguarda il caso particolare di Inetd:
pop-2
pop-3
imap
stream
stream
stream
tcp
tcp
tcp
nowait
nowait
nowait
root
root
root
/usr/sbin/tcpd
/usr/sbin/tcpd
/usr/sbin/tcpd
ipop2d
ipop3d
imapd
In alcune distribuzioni GNU questi tre demoni potrebbero fare parte di un pacchetto unico, mentre in altri casi i pacchetti potrebbero essere distinti in base al servizio particolare che viene
offerto.
1
IMAP toolkit software libero con licenza speciale
1624
152.3 Popclient
Popclient 2 è un programma molto semplice che permette di scaricare la posta da un recapito
remoto utilizzando il protocollo POP2 o POP3, inserendola in un file che corrisponda alla cartella
della posta in ingresso dell’utente nel nodo locale, oppure passandola a un MDA (Mail delivery
agent) che faccia sostanzialmente la stessa cosa. In questo modo, una volta scaricata, la posta
può essere letta con un programma tradizionale come Mailx.
È importante sottolineare che per questo scopo, non è necessario che sia attivo un servente SMTP
locale. 3
‘popclient’ è l’eseguibile che compie tutto il lavoro di Popclient. Può essere predisposto anche
un file di configurazione, che permette l’automazione delle operazioni.
popclient
[opzioni] [host_remoto]
Nelle opzioni della riga di comando, si può osservare che non è stata indicata la possibilità di
inserire la parola d’ordine. Infatti, non è possibile; per non dover inserire la parola d’ordine ogni
volta che si scarica la posta, è necessario predisporre un file di configurazione.
Opzione
Descrizione
Viene utilizzato il protocollo POP2.
Viene utilizzato il protocollo POP3.
-2
-3
| --keep
-s | --silent
-v | --verbose
Copia i messaggi dal servente remoto senza cancellarli da lì.
-k
-u utente
Non mostra i messaggi di progressione dell’operazione.
| --username
|
-r cartella_remota
--remote cartella_remota
|
-o cartella_locale
--local cartella_locale
-c
| --stdout
Codice di uscita
0
1
2
3
4
5
6
7
10
utente
Visualizza attraverso lo standard error tutti i messaggi che
intercorrono tra il programma e il servente remoto.
Permette di specificare il nome dell’utente così come è registrato nel sistema remoto. Il valore predefinito è il nome
dell’utente così come è conosciuto nel sistema locale.
Permette di specificare una cartella della posta nel servente
remoto, diversa da quella predefinita. Dipende dal servente
remoto se questa cartella alternativa esiste. Questa opzione
può essere utilizzata solo con il protocollo POP2.
Permette di specificare una cartella della posta locale alternativa. Quando non viene specificata una cartella per la posta
ricevuta, si intende quella predefinita dal sistema locale.
Permette di emettere attraverso lo standard output la posta,
invece di utilizzare la cartella della posta.
Descrizione
Uno o più messaggi sono stati caricati.
Non c’è posta.
Errore nell’apertura di un socket.
L’autentificazione dell’utente è fallita: il nome dell’utente o la parola d’ordine
sono errati.
Errore generico nel protocollo di comunicazione.
Errore di sintassi nell’uso degli argomenti di ‘popclient’.
Errore generico nella registrazione della posta nella cartella locale.
Errore generico riportato dal servente remoto. Riguarda il protocollo POP3.
Errore indefinito.
Popclient può essere configurato in modo personale attraverso il file ‘~/.poprc’. In tal modo,
2
3
Popclient GNU GPL
È questo punto che può rendere vantaggioso l’utilizzo di Popclient al posto di Fetchmail.
1625
l’utente può predisporre tutti i dati necessari ad automatizzare la connessione senza la necessità
di utilizzare script o comandi pieni di opzioni. In particolare, attraverso il file personalizzato di
configurazione, si può predisporre anche la parola d’ordine necessaria a prelevare la posta.
L’esempio seguente riguarda il caso in cui si voglia prelevare la posta dal nodo
weizen.mehl.dg, utilizzando il protocollo POP3, con un nominativo-utente «tizio» e la
parola d’ordine «tazza», depositando i messaggi nel file ‘/home/tizio/mail/inbox’:
# .poprc
server
weizen.mehl.dg
\
proto pop3
\
user tizio
\
pass tazza
\
localfolder /home/tizio/mail/inbox
Si può leggere eventualmente la pagina di manuale popclient(1).
152.4 Fetchmail
Fetchmail 4 è un sistema di recupero della posta remota molto complesso. Permette di inserire
i messaggi ottenuti nel sistema di consegna locale attraverso un MDA come Sendmail; oppure
può utilizzare direttamente il protocollo SMTP per ottenere lo stesso risultato, o per inserire i
messaggi in un sistema di trasporto più vicino (quale quello di una rete locale).
Può funzionare anche come demone personale (di un utente) in modo da provvedere regolarmente
allo scarico dei messaggi.
Fetchmail ha il vantaggio di poter utilizzare una grande varietà di protocolli fatti per questo
scopo. In linea di massima ci si può concentrare sui soliti POP2, POP3 e IMAP, ma è bene tenere
presente che le possibilità sono maggiori, nel caso si presentasse l’occasione.
L’eseguibile ‘fetchmail’ può essere gestito molto bene attraverso la riga di comando, ma è
consigliabile anche la sua configurazione attraverso il file ‘~/.fetchmailrc’, che permette di
agevolare le operazioni di routine.
fetchmail
[opzioni]
host_remoto
Se si pone un conflitto tra quanto specificato tramite le opzioni della riga di comando e le direttive
del file di configurazione, le prime prendono il sopravvento.
Opzione
Descrizione
Scarica tutti i messaggi, compresi quelli che risultano già
visti.
Non cancella i messaggi che vengono scaricati.
| --all
-k | --keep
-a
|
-u utente_remoto
--username utente_remoto
|
-t n_secondi
--timeout n_secondi
4
Fetchmail GNU GPL
Specifica precisamente il nome da utilizzare per accedere al
servente remoto. Se non viene indicata questa informazione (attraverso la riga di comando, oppure attraverso la configurazione), si intende lo stesso nome utilizzato nel sistema
locale.
Permette di stabilire un tempo massimo per la connessione,
oltre il quale Fetchmail deve abbandonare il tentativo.
1626
Opzione
Descrizione
Avvia Fetchmail in modalità demone, cioè sullo sfondo, allo
scopo di eseguire la scansione dei serventi in modo regolare.
L’argomento esprime la durata dell’intervallo tra una scansione e l’altra, espresso in secondi.
Ogni utente può avviare una sola copia dell’eseguibile
‘fetchmail’ in modalità demone; tuttavia, se si tenta di avviare una nuova copia di ‘fetchmail’, quando è già attivo
il demone, ciò fa sì che venga eseguita immediatamente una
nuova scansione.
|
-d n_secondi
--daemon n_secondi
Il file di configurazione di Fetchmail è molto importante. È interessante notare che non esiste un
file di configurazione generale, ma solo quelli dei singoli utenti; infatti, il recupero della posta
elettronica è un’operazione personale.
Per motivi di sicurezza, dal momento che può contenere informazioni delicate, è necessario
che il file di configurazione abbia esclusivamente i permessi di lettura e scrittura per l’utente proprietario (06008). Se il file ha permessi maggiori, Fetchmail avverte e si rifiuta di
proseguire.
Prima di analizzare la sintassi che può essere utilizzata al suo interno, si può notare che i commenti vengono espressi nel modo consueto, attraverso il simbolo ‘#’ che li introduce, dove poi
tutto quello che segue, fino alla fine della riga, viene ignorato. Così anche le righe bianche e
quelle vuote vengono ignorate.
Ogni direttiva del file ‘~/.fetchmailrc’ contiene tutte le specifiche riferite al recupero della
posta elettronica da un servente determinato. Queste direttive possono impiegare più righe, senza
la necessità di indicare simboli di continuazione, distinguendosi perché iniziano con la parola
chiave ‘poll’, oppure ‘skip’.
Una direttiva ‘poll’ rappresenta un servente da interpellare, mentre una direttiva ‘skip’, uno
da saltare. Di fatto non serve una direttiva ‘skip’, ma può essere utile per evitare di cancellarla,
riservando per il futuro la possibilità di riutilizzarla rimettendo la parola chiave ‘poll’.
Le direttive sono composte da una serie di parole chiave che rappresentano delle opzioni, a volte
accompagnate da un argomento. Alcune parole chiave sono speciali, in quanto, pur non avendo alcun significato, sono utili per facilitare la lettura delle direttive. Tali parole sono: ‘and’,
‘with’, ‘has’, ‘wants’ e ‘options’. Nello stesso modo, possono essere usati la virgola, il punto
e virgola, i due punti, che vengono ignorati ugualmente.
All’interno di ogni direttiva, deve essere rispettato un certo ordine nell’indicazione delle opzioni.
Se ne distinguono due tipi: opzioni del servente e opzioni dell’utente. Le opzioni del servente
devono apparire prima di quelle dell’utente.
Per comprendere il senso di queste direttive, è bene fare mente locale al formato generale
semplificato, che queste possono avere.
poll servente
[protocol
] [username
protocollo
utente_remoto
] [password
]
parola_d’ordine
Gli argomenti delle opzioni che rappresentano delle stringhe, possono essere racchiusi tra apici
doppi, in modo da poter contenere simboli particolari, come gli spazi (specialmente quando si
tratta di indicare le parole d’ordine).
1627
Opzioni del servente
Opzione
poll servente
skip servente
Descrizione
Specifica l’accesso a un servente. Se si usa la parola chiave
‘skip’, tutta la direttiva viene ignorata.
Il tipo di protocollo da utilizzare, viene determinato normalmente in modo automatico. Con questa opzione può essere
proto protocollo
specificato espressamente, indicando una parola chiave determinata: ‘POP2’, ‘POP3’, ‘IMAP’, ‘IMAP-K4’, ‘IMAP-GSS’,
protocol protocollo
‘APOP’, ‘KPOP’. Si noti che queste parole chiave possono
essere espresse anche utilizzando solo lettere minuscole.
Permette di specificare il numero della porta da utilizzare, nel
port n_porta
caso il servente ne utilizzi una non standard.
Specifica il tempo massimo di inattività, dopo il quale si
timeout n_secondi
conclude la connessione, o il suo tentativo.
Permette di specificare un’interfaccia di rete, assieme al grupinterface interfaccia /numero_ip /maschera
po di indirizzi che deve avere, prima di tentare la connessione
con il servente remoto.
Opzioni dell’utente
Opzione
Descrizione
user utente_remoto
Specifica il nome da utilizzare per accedere al sistema remoto.
username utente_remoto
is utente_locale here
Rappresenta il nome dell’utente locale che deve ricevere il
messaggio. Di solito non si specifica, essendo quello che
effettua l’operazione di recupero.
pass parola_d’ordine
La parola d’ordine per accedere al sistema remoto.
password parola_d’ordine
fetchall
limit n_byte
syslog
Richiede espressamente il recupero di tutti i messaggi, compresi quelli già prelevati, ma mantenuti nel servente per
qualche motivo.
Fissa la dimensione massima dei messaggi che possono essere
prelevati. Quelli che eccedono tale limite vengono lasciati nel
servente e risultano «non letti».
Utilizza il registro di sistema per annotare gli errori.
poll roggen.brot.dg protocol pop3 username tizio password "frase segreta"
Rappresenta la scansione del servente roggen.brot.dg con il protocollo POP3, utilizzando il nominativo-utente ‘tizio’ che richiede la parola d’ordine ‘frase segreta’ (che appare
opportunamente tra virgolette).
poll roggen.brot.dg protocol pop3 username tizio password "frase segreta"
poll schwarz.brot.dg username tizio1 password "ciao ciao"
Qui si prevede la scansione di due serventi, dove nel secondo caso non viene specificato il
protocollo e anche il nominativo utilizzato risulta differente dal primo.
1628
poll roggen.brot.dg
protocol pop3
username tizio
password "frase segreta"
poll schwarz.brot.dg
username tizio1
password "ciao ciao"
Come nell’esempio precedente, ma più strutturato e più facile da leggere.
poll roggen.brot.dg protocol pop3
username tizio password "frase segreta" is tizio here
username caio password "ciao caio" is caio2 here
username pippo password "marameo maramao" is pippo here
In questo caso, per uno stesso servente sono stati indicati diversi utenti remoti e locali. Per
intendere il senso, si osservi che l’utente remoto ‘caio’ corrisponde all’utente locale ‘caio2’.
Evidentemente, per ottenere un tale risultato, è necessario che l’utente che avvia Fetchmail
conosca tutte le parole d’ordine di questi utenti.
152.5 MUA completi
Trattando l’argomento del trasferimento della posta remota, non bisogna dimenticare i programmi MUA (Mail user agent) che si arrangiano a scaricarsela. L’esempio più semplice di questo
genere di programmi è Balsa.
Utilizzando un MUA di questo tipo, se si dispone di un elaboratore connesso saltuariamente a
Internet, non serve alcun sistema di gestione della posta elettronica locale e nemmeno alcun programma per scaricarla dal recapito presso il fornitore di accesso, salve naturalmente le esigenze
di altri programmi.
Capitolo
153
Messaggi, allegati ed estensioni MIME
Il messaggio di posta elettronica tradizionale è composto utilizzando soltanto la codifica ASCII
a 7 bit e ha un aspetto simile all’esempio seguente:
Date: Tue, 17 Jul 2001 11:27:59 +0200
Subject: Messaggio tradizionale
Message-Id: <[email protected]>
Questo rappresenta un esempio di messaggio di posta elettronica
tradizionale, dove si utilizzano solo i primi 7 bit.
In pratica, per quanto riguarda la lingua italiana, non si possono
usare le lettere accentate.
Per garantire che un messaggio di posta elettronica viaggi in modo attraverso qualsiasi servente
SMTP, è necessario che si rimanga nell’ambito dei soli 7 bit, oltre al fatto di avere un limite alla
lunghezza delle righe.
La necessità di scrivere in lingue differenti dall’inglese e di poter trasmettere informazioni diverse
dal solito testo puro e semplice, ha fatto nascere lo standard multimediale MIME (Multipurpose
internet mail extentions).
Con le estensioni multimediali MIME è possibile definire come deve essere interpretato il contenuto di un messaggio di posta elettronica, che così può essere codificato in modo particolare, per
trasportare anche informazioni diverse dal solo testo ASCII puro, rispettando i limiti tradizionali
dei sistemi di trasporto dei messaggi.
Negli esempi che si mostrano in questo capitolo, viene omessa la riga di intestazione iniziale
del tipo
From [email protected] Tue Jul 17 12:28:15 2001 +0200
che è essenziale per completare il messaggio, ma che qui non serve per comprendere quanto
spiegato e rischia solo di creare confusione con il campo ‘From:’.
153.1 Allegati
L’invio di un file allegato a un messaggio di posta elettronica richiede un modo per inserire e
circoscrivere questo file, oltre alla sua trasformazione in modo tale che possa essere gestito come
un file di testo normale. In pratica, è come allegare un file a un file di testo, dal quale deve poter
essere estrapolato correttamente in un momento successivo.
Figura 153.1. Procedimento necessario a produrre un allegato.
file binario
File ASCII
Allegato ASCII
.-----------.
.-----------.
.-----------.
| lkjsdhèe9 |
| G;&MJ<V1H |
| begin
|
| 845ry#fgg |---------->| Z&4Y"C@T- |---------->| G;&MJ<V1H |
| fòéùìÌÀÒÈ |
| 7)Y(V9G9P |
| Z&4Y"C@T- |
| öüä$%&£K* |
| IF\NGY[,S |
| 7)Y(V9G9P |
‘-----------’
| ‘TL@*]OSD |
| IF\NGY[,S |
| )"4FHTLJ‘ |
| ‘TL@*]OSD |
‘-----------’
| )"4FHTLJ‘ |
| end
|
‘-----------’
Dal momento che in un messaggio di posta elettronica alcuni caratteri, che in condizioni normali appartengono già all’ASCII standard a 7 bit, hanno un significato speciale (senza contare
1629
1630
l’importanza di alcune parole chiave, quando collocate a partire dalla prima colonna), sono da
escludere anche questi nelle trasformazioni necessarie a creare gli allegati.
La figura 153.1 mostra in modo semplificato il problema che si tenta di descrivere: un file viene
prima trasformato, in base a un certo algoritmo, in un file di testo puro, che possa essere trasmesso
attraverso il sistema della posta elettronica; questa trasformazione genera necessariamente un
file più grande di quello di partenza; quindi, per diventare un allegato, occorre un modo per
circoscriverlo, aggiungendo anche le informazioni necessarie a riprodurre il file originale (che
nell’esempio della figura sono state omesse per semplicità).
153.2 Uuencode
Uuencode 1 è il sistema storico per la conversione di file di qualunque tipo in un allegato in forma
di file ASCII, che si utilizza senza gestire le estensioni MIME. Si compone di due eseguibili:
‘uuencode’ per la codifica e ‘uudecode’ per la decodifica.
‘uuencode’ si comporta in maniera differente a seconda che riceva il file da codificare dallo
standard input, oppure che questo gli sia indicato come argomento della riga di comando:
uuencode
[-m]
file_da_codificare nome_da_usare
cat file_da_codificare | uuencode
[-m]
nome_da_usare
In entrambi i casi, il risultato della codifica viene emesso attraverso lo standard output, con la
differenza che nel primo caso il file da codificare viene indicato come primo argomento, mentre
nel secondo viene fornito attraverso lo standard input. L’ultimo argomento è sempre obbligatorio
e rappresenta il nome che si vuole attribuire a questo file, ovvero il nome che verrà usato nel
momento dell’estrazione.
L’unica opzione disponibile, ‘-m’, consente di richiedere espressamente l’utilizzo della codifica
Base64.
Disponendo del file già visto nella figura 153.1, ovvero il testo
lkjsdhèe9
845ry#fgg
fòéùìÌÀÒÈ
öüä$%&£K*
supponendo che si tratti del file ‘prova.xxx’, si potrebbe codificare con ‘uuencode’ nel modo
seguente:
$ uuencode prova.xxx prova.xxx > allegato.txt
Si può osservare che il nome ‘prova.xxx’ appare due volte nella riga di comando: la prima
volta indica il file da leggere per la codifica; la seconda indica il nome da indicare nell’allegato,
in modo che al momento della decodifica si riottenga lo stesso file. Il file ‘allegato.txt’ che
si ottiene ha l’aspetto seguente:
begin 664 prova.xxx
G;&MJ<V1HZ&4Y"C@T-7)Y(V9G9PIF\NGY[,S‘TL@*]OSD)"4FHTLJ
‘
end
In alternativa, usando la codifica Base64,
$ uuencode -m prova.xxx prova.xxx > allegato.txt
1
GNU Sharutils GNU GPL
1631
si ottiene invece:
begin-base64 664 prova.xxx
bGtqc2Ro6GU5Cjg0NXJ5I2ZnZwpm8un57MzA0sgK9vzkJCUmo0sq
====
Evidentemente il principio è lo stesso, cambiando il modo di delimitare il file e di indicare le sue
caratteristiche.
Naturalmente, si possono creare anche situazioni più complesse, come nel caso in cui il file di
origine sia prima compresso, poi codificato e quindi trasmesso attraverso la posta elettronica:
$ cat prova.xxx | gzip | uuencode prova.xxx.gz ←,→| mail [email protected]
In questo caso, il messaggio che riceverà [email protected] sarà, più o meno, quello
seguente:
Date: Fri, 13 Jul 2001 16:26:48 +0200
begin 664 prova.xxx.gz
M’XL(‘"<%3SL‘‘\O)SBI.R7B1:LEE86):5*F<EI[.E?;IY<\W9PY<.L’U[<\3
/%56UQ=Y:‘#NWZ88G‘‘‘‘
‘
end
‘uudecode’ funziona in modo simmetrico rispetto a ‘uuencode’. In questo caso, dal momento
che il nome del file da rigenerare fa già parte delle informazioni necessarie dell’allegato, è sufficiente fornire a ‘uudecode’ il file di testo contenente l’allegato. Il file in questione può anche
essere un messaggio di posta elettronica, completo di intestazione, come nell’ultimo esempio
mostrato per la codifica.
uudecode
[-o
file_da_generare
]
cat file_con_allegato | uudecode
file_con_allegato ...
[-o
file_da_generare
]
In generale non si usa l’opzione ‘-o’, a meno che ci sia la necessità di generare un file con un
nome differente da quanto previsto da chi ha predisposto l’allegato.
$ uudecode allegato.txt
L’esempio soprastante è elementare, ma rappresenta l’uso normale di ‘uudecode’. In questo
caso, il file ‘allegato.txt’ è ciò che contiene l’allegato, dal quale viene estratto probabilmente
un file, il cui nome è già stato deciso in precedenza.
153.3 Involucro MIME
Un messaggio realizzato secondo le estensioni MIME contiene informazioni aggiuntive
specifiche nell’intestazione, come si vede nell’esempio seguente:
Date: Tue, 17 Jul 2001 12:28:23 +0200 (CEST)
Subject: Messaggio MIME semplice
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
1632
Content-Transfer-Encoding: QUOTED-PRINTABLE
Questo =E8 un messaggio un po’ pi=F9 complesso, perch=E9
consente l’uso di un insieme di caratteri pi=F9 ampio.
In generale appare il campo ‘MIME-Version:’, che dichiara l’utilizzo delle estensioni, secondo la versione indicata, anticipando così la presenza di altri campi specifici. L’elenco seguente
descrive quelli essenziali.
•
[
]...
Content-type: tipo/sottotipo ; opzione
Il campo ‘Content-type:’ serve a specificare il tipo e il sottotipo MIME del messaggio.
Esiste un tipo MIME particolare, che serve a dichiarare la presenza di più componenti; si
tratta di ‘multipart’ e verrà chiarito meglio nel seguito il suo significato.
Il campo ‘Content-type:’, oltre al tipo e al sottotipo MIME, consente l’indicazione
aggiuntiva di informazioni opzionali, precedute da un punto e virgola (‘;’), che chiariscono ulteriormente le caratteristiche dell’informazione contenuta. Per esempio, quando si tratta di ‘text/plain’, può essere specificato l’insieme di caratteri con l’opzione ‘charset=insieme_di_caratteri ’. In mancanza di indicazioni, l’insieme di caratteri corrisponde a ‘us-ascii’, mentre nell’esempio si vede l’uso dell’insieme ‘iso-8859-1’,
corrispondente a ISO 8859-1. Segue la descrizione delle opzioni più frequenti.
–
charset=insieme_di_caratteri
Definisce l’insieme di caratteri nel caso si tratti di un testo. Il valore predefinito è
‘us-ascii’, mentre ‘iso-8859-n ’ rappresenta una codifica secondo lo standard ISO
8859-n .
–
name=file
Definisce il nome del file nel caso il contenuto venga salvato.
–
boundary="stringa "
Definisce la stringa di delimitazione del confine delle componenti MIME multiple.
•
Content-Transfer-Encoding: codifica_per_il_trasferimento
Il campo ‘Content-Transfer-Encoding:’ serve a specificare in che modo avviene la
trasformazione delle informazioni stabilite nel campo ‘Content-type:’, per le esigenze
legate al trasferimento del messaggio. In pratica si tratta di indicare una parola chiave che
chiarisca come interpretare il contenuto del messaggio al momento della ricezione. L’esempio mostra l’uso del tipo ‘quoted-printable’ (non fa differenza l’uso delle maiuscole o
delle minuscole).
–
Content-Transfer-Encoding: 7bit
Si tratta della codifica predefinita, ovvero della situazione in cui non è necessario apportare alcuna trasformazione, perché si utilizzano solo i primi 7 bit e le righe di testo
non sono troppo lunghe.
–
In questo caso si tratta di un testo in cui vengono usati 8 bit, senza trasformazioni, con
righe non troppo lunghe. Tuttavia, si tratta di una codifica non conveniente, perché non
tutti i serventi SMTP sono in grado di mantenere invariate queste informazioni.
–
Content-Transfer-Encoding: binary
Le informazioni sono inserite così come sono, senza alcuna trasformazione. In
generale è impossibile trasmettere messaggi di questo tipo.
–
1633
Content-Transfer-Encoding: quoted-printable
I caratteri che richiedono l’uso di 8 bit, si rappresentano nella forma ‘=h h ’, dove la
coppia h h rappresenta un numero esadecimale, corrispondente al codice del carattere.
In pratica, la lettera «è» si rappresenta come ‘=E8’ (come si può vedere dall’esempio); inoltre, per evitare di avere righe troppo lunghe, queste vengono spezzate ponendo il simbolo ‘=’ alla fine della riga; infine, il carattere «=» viene rappresentato
necessariamente come ‘=3D’.
–
Content-Transfer-Encoding: base64
Si tratta di una trasformazione in cui ogni gruppo di 24 bit (3 byte) viene trasformato in
quattro caratteri (4 byte), su righe non troppo lunghe. Il nome della codifica deriva dal
fatto che per ogni byte si possono rappresentare solo 64 simboli, essendo necessario
escludere tutto ciò che può creare problemi alla trasmissione del messaggio. Pertanto:
224 = 643.
Questo tipo di codifica rende completamente illeggibile, a livello umano, il suo contenuto. In questo senso, si presta alla trasmissione di immagini o di altri tipi di file che
non sarebbero comunque leggibili in questo modo.
153.4 Messaggi contenenti più parti MIME
Il tipo MIME ‘multipart’ prevede la presenza di più componenti separate, con altrettante intestazioni specifiche. In questo caso si indica comunemente il confine tra una componente e l’altra
attraverso una stringa particolare (di solito creata in modo da essere univoca), dichiarata con l’opzione ‘boundary="stringa "’ nel campo ‘Content-Type:’, come si può osservare nell’esempio
seguente:
Date: Thu, 5 Jul 2001 16:38:22 +0200 (CEST)
Subject: Foto
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-324931406-994342670=:16889"
Il testo che appare qui viene ignorato.
---1463811839-324931406-994342670=:16889
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: 7BIT
Ciao Tizio,
ti allego le foto che ti ho promesso.
Caio
---1463811839-324931406-994342670=:16889
Content-Type: IMAGE/JPEG; NAME="caio-1.jpg"
Content-Transfer-Encoding: BASE64
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEB
AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/
2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB
...
...
45/Q+9TZ+XPtn9KAFopFORk9/wDGokdmdgcYAPT2IH9aAJqKqTyurooIAJ5/
L/P5fWrAJC/THX3AP9aAKU2nwzyGRgCSMc+g/D3orC1HWby2umii8rYFUjcj
E5Oc87x/KildXt/XT/NGijKytLp3Z//Z
---1463811839-324931406-994342670=:16889
1634
Content-Type: IMAGE/JPEG; NAME="caio-2.jpg"
/9j/4AAQSkZJRgABAQEAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL
DBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/
2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy
...
...
AgkiBwEifAQArSQpJAD/APah2keikDwgBeEj0iOUKXAFXKIZXKQ5PSJ54tdA
VIH7Innrwm9nlABJ8JpKcRQQDfKAGpD5TiEPhACHISI5TttBCigAcoHtO8IA
ikACvlJHj5SXAP/Z
---1463811839-324931406-994342670=:16889--
In questo caso, la stringa ‘-1463811839-324931406-994342670=:16889’ viene usata per
delimitare i vari componenti del messaggio. Si può osservare che quanto contenuto tra la fine
dell’intestazione del messaggio e il primo componente MIME viene ignorato dai programmi
utilizzati per leggerlo. Questa zona può essere usata per annotare informazioni tecniche destinate
alla lettura umana, nel caso di un accesso diretto al file.
Si noti che ogni componente MIME è preceduto dalla stringa di delimitazione, a cui si aggiungono inizialmente due trattini (‘--’). Alla fine, dopo l’ultimo componente la stringa di delimitazione
ha altri due trattini finali. Volendo schematizzare la cosa:
Date: data
From: mittente
To: destinatario
Subject: oggetto
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="delimitatore "
[commento ]
...
...
--delimitatore
Content-Type: tipo/sottotipo ; opzione ...
[
]
[
]
contenuto_codificato
...
...
[--delimitatore
Content-Type: tipo/sottotipo ; opzione ...
contenuto_codificato
...
...
]...
--delimitatore --
Teoricamente, un elemento MIME potrebbe scomporsi in altri sottoelementi, dichiarando
nuovamente un tipo ‘multipart’, ma questo modo di intervenire è sconsigliabile.
Un caso particolare di messaggi ‘multipart’ è quello che consente di trasmettere il contenuto
in forme alternative, come quando si affianca un messaggio in forma testuale a una copia più
appariscente in formato HTML. In tal caso si aggiunge il sottotipo ‘alternative’:
Content-Type: multipart/alternative; boundary="x x x x "
La composizione del messaggio è analoga a quanto già visto, con la differenza che il programma
che consente la lettura del messaggio ricevuto, sceglierà in che modo visualizzare il contenuto.
1635
153.5 Sistemazione manuale di un allegato MIME
I programmi usati generalmente per scrivere e inviare la posta elettronica sono in grado normalmente di gestire gli allegati, sia per inviarli, sia per estrarli. Ogni programma aggiunge a modo
suo dei campi particolari per qualche scopo, anche se non si tratta di informazioni essenziali.
Seguono due esempi, uno realizzato con Pine e l’altro con Mozilla.
Subject: Prova di trasmissione
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-1689890199-995042379=:579"
Content-ID: <[email protected]>
---1463811839-1689890199-995042379=:579
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Esempio di trasmissione con Pine.
---1463811839-1689890199-995042379=:579
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; NAME="prova.xxx"
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="prova.xxx"
bGtqc2Ro6GU5DQo4NDVyeSNmZ2cNCmby6fnszMDSyA0K9vzkJCUmo0sq
---1463811839-1689890199-995042379=:579--
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i586; en-US; m18) Gecko/20001103
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="------------050408090202040304080207"
This is a multi-part message in MIME format.
--------------050408090202040304080207
Content-Type: text/plain; charset=us-ascii; format=flowed
Ecco un esempio di allegato con Mozilla.
--------------050408090202040304080207
Content-Type: application/octet-stream;
name="prova.xxx"
Content-Disposition: attachment;
filename="prova.xxx"
--------------050408090202040304080207--
Purtroppo, alcune volte può capitare di ricevere messaggi in cui gli allegati sono stati inseriri
in modo non standard, oppure utilizzando standard troppo recenti. In questi casi capita di non
1636
riuscire a estrarre il contenuto in alcun modo, a meno di mettere mano direttamente al messaggio,
per correggere gli errori.
Date: Fri, 13 Jun 2001 17:30:00 +0200
Subject: Esempio di allegato non corretto
Message-ID: <B761F178.202%[email protected]>
Mime-version: 1.0
Content-type: multipart/mixed;
boundary="MS_Mac_OE_3076649336_173889_MIME_Part"
--MS_Mac_OE_3076649336_173889_MIME_Part
Content-type: multipart/alternative;
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Ecco, ti allego il file che tanto aspettavi.
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Esempio di allegato non corretto</TITLE>
</HEAD>
<BODY>

Ecco, ti allego il file che tanto aspettavi.
</BODY>
</HTML>
--MS_Mac_OE_3076649336_173889_MIME_Part--
Content-type: multipart/appledouble;
Content-type: application/applefile; name="prova.jpg"
Content-transfer-encoding: base64
Content-disposition: attachment
AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAACAAAAADAAAAXgAAABIAAAAC
AAAAcAAAO2xKUEVHOEJJTQUA//8CAQAAAAAAAAAAAAAAAAAAAAAAAEZSQU5DT18yIHNtYWxs
LmpwZwAAAQAAADrqAAA56gAAAIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...
...
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA66gAAOeoAAACCU09SVAN2AIAAHACCAARJQ04j
AAAAKlBJQ1QAAAA2U1RSIAAAAEJpY2w4AAAATnBub3QAAABav7n//wAAOOYM1aTQVHD//wAA
ABoAAAAAv/T//wAAAAAM1afMv7n//wAANOIM1afcAAD//wAANNAM1aTY
Content-type: image/jpeg; name="prova.jpg";
x-mac-creator="3842494D";
x-mac-type="4A504547"
Content-disposition: attachment
1637
/9j/4AAQSkZJRgABAgEBLAEsAAD/7Ro4UGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5m
bwAAAAB4ACgAAABIAEgAAAAAAxgCQf/3//cDQAJKIAIFewPgAAAAAAFoAWgAAAAAD3gLRQFs
ADILRUcYAFAAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZAAAAAAAAAAA
...
...
QI08T/rKM3l/9Q/kKl+d8gj10WjbW2szHqF/2lrR6pr9PfEGJ3+n7v5bdyk9rgdwcQ6AIjSe
SpO/nP7P/fgp92f69mo9fBGjnnHtyOoMy72AOxQ5mKxvg6Bde/8Al7Wtrr/cYrXpt+ltPMz8
uFK3+cPy/iif4H5JaXp9U+rr9H//2Q==
L’esempio che si vede sopra, è ovviamente abbreviato. L’intenzione di Caio era quella di inviare
un’immagine a Tizio. Si tratta precisamente del file ‘prova.jpg’, ma per qualche motivo, non
si riesce a estrarla.2
Il messaggio inizia con una breve descrizione, seguita dalla stessa cosa in HTML. Quindi appare un primo allegato, che in realtà non serve, quindi l’ultimo allegato, che è la vera immagine
cercata. Per rimediare, occorre salvare il messaggio in un file separato per poi metterci mano
direttamente. Il messaggio trasformato per estrarre esclusivamente l’immagine cercata, può avere l’aspetto seguente, tenendo conto che probabilmente è necessario lasciare la prima riga di
intestazione contenente il campo ‘From ...’, che però qui è stata omessa:
Date: Fri, 13 Jun 2001 17:30:00 +0200
Subject: Esempio di allegato non corretto
Mime-version: 1.0
Content-type: image/jpeg; name="prova.jpg";
...
...
Si può osservare che il messaggio non è più di tipo MIME multiplo, così non è necessario indicare
i confini con la stringa dell’opzione ‘boundary’.
Volendo, dal momento che l’immagine è stata codificata con la codifica Base64, si può usare
anche Uuencode senza preoccuparsi di rispettare le specifiche MIME. Il file si riduce all’estratto
seguente, dove il codice della figura è delimitato come si vede:
2
L’esempio proviene da un caso accaduto realmente, senza che sia stato possibile chiarire il motivo della composizione errata. Viene proposto questo esempio perché reale, anche se incompleto, considerato il fatto che il mittente e il
destinatario sono stati sostituiti, inoltre alcune informazioni sono state eliminate dal messaggio.
1638
begin-base64 664 prova.jpg
...
...
====
Per l’estrazione basta usare il programma ‘uudecode’, come è già stato descritto in precedenza.
153.6 Mpack
Mpack 3 consente di generare allegati MIME, ovvero allegati con più informazioni e per questo
più facili da estrarre. Anche in questo caso si distinguono due eseguibili: ‘mpack’ per la codifica
e ‘munpack’ per la decodifica. Il primo, tra le altre cose, è anche in grado di inviare direttamente
il risultato della codifica a un recapito di posta elettronica.
[
][
] [-m
n_caratteri
[
][
] [-m
n_caratteri
[
][
[
][
mpack -s oggetto
-d file_introduttivo
,→ file_da_codificare indirizzo_posta_elettronica ...
mpack -s oggetto
,→-o file_da_generare file_da_codificare
] [-c
sottotipo_mime
]
←-
] [-c
sottotipo_mime
]
←-
] [-c
sottotipo_mime
]
←-
mpack -s oggetto
-m n_caratteri
,→-n indirizzo_usenet ,indirizzo_usenet ... file_da_codificare
]
I tre modelli sintattici mostrano tutte le opzioni disponibili e i tre contesti di utilizzo di ‘mpack’.
Nel primo caso, il file codificato viene inviato direttamente attraverso la posta elettronica, agli
indirizzi specificati; nel secondo caso si crea un file; nell’ultimo caso si invia il file codificato a
uno o più gruppi di discussione di Usenet.
È importante chiarire il significato di alcune opzioni. ‘-d’ permette di indicare un file, il cui
contenuto verrà usato come introduzione all’allegato che si crea. In altri termini, permette di
spiegare di cosa si tratta, senza interferire con il file da codificare. ‘-m’ consente di indicare la
dimensione massima, espressa in caratteri, ovvero in byte, dei messaggi. Ciò permette di creare automaticamente diversi file, oppure di inviare diversi messaggi, ognuno non eccedente la
dimensione richiesta.4 Infine, l’opzione ‘-c’ consente di indicare un sottotipo MIME, dei tipi
‘application’, ‘audio’, ‘image’ e ‘video’. Se non si indica questa informazione, è ‘mpack’
a determinarla in modo automatico. È il caso di osservare che l’oggetto viene richiesto in modo
interattivo, se non si usa l’opzione ‘-s’ esplicitamente.
A titolo di esempio si può vedere cosa succede se l’utente ‘caio’ invia a
[email protected] il file già visto nell’introduzione del capitolo, denominato
‘prova.xxx’:
$ mpack -s "Prova di trasmissione" prova.xxx [email protected]
Ciò che viene ricevuto può assomigliare al messaggio seguente, dove si può notare che la stringa
di delimitazione è ridotta a un solo trattino:
3
Mpack software libero con licenza speciale
In realtà la dimensione indicata con questa opzione è solo un riferimento approssimato, dal momento che i messaggi
di posta elettronica e di Usenet tendono a espandersi, mano a mano che si aggiungono informazioni sul loro percorso.
4
1639
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="-"
Date: Fri, 13 Jul 2001 18:23:32 +0200
This is a MIME encoded message. Decode it with "munpack"
or any other MIME reading software. Mpack/munpack is available
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
--Content-Type: application/octet-stream; name="prova.xxx"
Content-Disposition: inline; filename="prova.xxx"
Content-MD5: JSc+xPLb3o3I5NlBYvyVJA==
-----
L’uso di ‘munpack’ è più semplice, dal momento che nella maggior parte dei casi è sufficiente
fornire il file contenente l’allegato, come argomento oppure attraverso lo standard input:
munpack
[opzioni]
file_con_allegato ...
cat file_con_allegato | munpack
[opzioni]
Il file che contiene l’allegato può anche essere un messaggio di posta elettronica, in cui appare
ancora l’intestazione. Tuttavia, è da tenere in considerazione che viene estratto solo il primo
messaggio che contiene un allegato, salvo il caso di allegati suddivisi in più messaggi.
In condizioni normali, se il file o il messaggio contenente l’allegato è preceduto da una
descrizione (un commento), questa informazione viene salvata in un file con estensione ‘.desc’.
153.7 Riferimenti
• Jerry Peek, MH & nmh: Email for Users & Programmers
<http://www.ics.uci.edu/~mh/book/>
– Introduction to MIME
<http://www.ics.uci.edu/~mh/book/overall/ch-itm.htm>
– Overview of MIME Messages
<http://www.ics.uci.edu/~mh/book/overall/ovofmime.htm>
– Multipart Messages
<http://www.ics.uci.edu/~mh/book/overall/mulmes.htm>
Capitolo
154
Gestione della posta elettronica in generale
Quando si gestisce un elaboratore che offre servizi di rete, sia in una rete locale, sia quando
questo è inserito nella rete globale, è importante conoscere almeno qualche concetto legato alla
trasmissione della posta elettronica. Generalmente, le distribuzioni GNU sono impostate in modo
da garantire il funzionamento di questo sistema, ma i problemi di sicurezza che si presentano
quando si amministra un servente di questo tipo, impongono una conoscenza maggiore rispetto
alla semplice messa in funzione del servizio.
154.1 Schema essenziale
Generalmente, lo schema essenziale di funzionamento del sistema di trasferimento dei messaggi
di posta elettronica è basato sul protocollo SMTP (Simple mail transfer protocol) e utilizza fondamentalmente due componenti: MTA (Mail transport agent), che include anche l’MDA (Mail
delivery agent), e MUA (Mail user agent). Il primo dei due è il sistema che si occupa del trasferimento e della consegna dei messaggi, mentre il secondo è il programma che viene utilizzato per
comporre i messaggi e passarli all’MTA.
Figura 154.1. Schema semplificativo del meccanismo di trasmissione della posta
elettronica tra MTA (MDA) e MUA.
Mittente
|
V
.-------.
.-------.
|
|
stdin |
|
| M U A |- - - - ->| M D A |
|
|
|
|
‘-------’
‘-------’
V
V
|
|
SMTP
|
| .- - - SMTP - - ’
| |
V V
.--------.
. - - - | M T A |
: M T A
|servente|-----SMTP----->:servente
| SMTP |
: SMTP
‘--------’
‘ - - - -
Consegna all’utente
destinatario
^
|
|
|
|
|
.
.--------.
:
| M T A |
:-----SMTP----->|servente|
:
| SMTP |
’
‘--------’
Eventualmente, l’MDA è un componente particolare di un MTA che permette di provvedere alla
consegna di un messaggio localmente, oppure alla trasmissione attraverso il protocollo SMTP,
dopo averlo ricevuto dallo standard input. I programmi MUA più semplici dipendono dall’MDA,
non essendo in grado di provvedere da soli a instaurare una connessione SMTP con un servente
di posta elettronica.
La sequenza di MTA, o meglio, di serventi SMTP utilizzati per trasmettere il messaggio a destinazione, dipende dall’organizzazione di ognuno di questi. La situazione più comune è quella
in cui ne sono coinvolti solo due: quello utilizzato per iniziare la trasmissione e quello di destinazione che si occupa anche della consegna. In realtà, si possono porre delle esigenze diverse,
a causa della struttura della rete nel punto di partenza e nel punto di destinazione. Per rendere
l’idea, si possono indicare i casi seguenti.
• L’MTA utilizzato nell’origine si avvale di uno smarthost, ovvero un altro MTA, collocato
in una posizione conveniente della rete, che si occupa di smistare i messaggi. Ciò è utile quando l’MTA di origine è collocato in una posizione della rete per cui esiste un solo
1640
1641
percorso per raggiungere la rete esterna: quando un messaggio è inviato a più di un destinatario è conveniente trasmetterlo una volta sola attraverso questo tratto di rete, lasciando
che sia l’MTA esterno a provvedere alla duplicazione dei messaggi per i vari destinatari.
Lo smarthost svolge quindi l’attività di relè, o di scambio.
• L’MTA di destinazione è il punto di ingresso a una rete privata, nella quale vengono poi
usati altri MTA per la consegna effettiva dei messaggi.
• L’MTA di destinazione è solo il punto di arrivo di un alias (da quel punto riprende l’invio
del messaggio all’indirizzo vero dell’utente).
154.2 Composizione di un messaggio
Un messaggio di posta elettronica è composto da due parti fondamentali: l’intestazione e il corpo. Il corpo è quella parte che contiene il testo del messaggio, mentre l’intestazione contiene
informazioni amministrative di vario genere, compreso l’oggetto (subject). All’interno dell’intestazione, si distingue in particolare la busta o envelope, cioè quelle informazioni amministrative
necessarie al trasporto del messaggio; queste appaiono nella parte superiore e si espandono mano
a mano che il messaggio attraversa i vari MTA necessari a raggiungere la destinazione.
L’esempio seguente mostra un breve messaggio trasmesso da [email protected] a
[email protected].
From [email protected] Mon Jun 8 21:53:16 1998
Return-Path: <[email protected]>
Received: from router.brot.dg ([email protected] [192.168.1.254])
by dinkel.brot.dg (8.8.7/8.8.7) with ESMTP id VAA00615
for <[email protected]>; Mon, 8 Jun 1998 21:53:15 +0200
Received: (from pippo@localhost)
by router.brot.dg (8.8.7/8.8.7) id AAA00384
for [email protected]; Tue, 9 Jun 1998 00:00:09 +0200
Date: Tue, 9 Jun 1998 00:00:09 +0200
Subject: Una vita che non ci si sente :-)
Ciao Daniele!
Quanto tempo che non ci si sente.
Fai un cenno se possibile :-)
Pippo
Per distinguere la conclusione dell’intestazione dall’inizio del corpo, si utilizza una riga vuota.
Nell’esempio, L’oggetto è l’ultimo elemento dell’intestazione, quindi appare una riga vuota di
separazione e finalmente inizia il testo del messaggio.
L’intestazione è composta da record separati dal codice di interruzione di riga. Ognuno di questi
record, definisce l’informazione contenuta in un campo nominato all’inizio del record stesso,
precisamente nella prima colonna del testo. Questi campi (field) terminano necessariamente con
il carattere due punti (‘:’), seguito da uno spazio; il resto del record descrive il loro contenuto. Un
record può continuare su più righe; la continuazione viene segnalata da un carattere di tabulazione
orizzontale, <HT>, all’inizio della riga che continua il record interrotto in quella precedente (si
osservino a questo proposito i campi ‘Received:’ dell’esempio).
Il programma usato come MUA genera l’intestazione necessaria a iniziare la trasmissione del
messaggio. In particolare, sono fondamentali i campi seguenti.
1642
Campo
‘Date:’
‘Message-Id:’
‘From:’
‘To:’
‘Subject:’
Descrizione
Contiene la data di invio del messaggio.
Contiene una stringa generata automaticamente, in modo da
essere unica per il messaggio. In un certo senso, serve a dare
un’impronta al messaggio che permette di distinguerlo e di
farvi riferimento.
Contiene le informazioni sul mittente del messaggio; generalmente si tratta dell’indirizzo di posta elettronica e
probabilmente anche il suo nome reale.
Contiene l’indirizzo di posta elettronica del destinatario.
L’oggetto del messaggio.
Oltre ai campi già visti, ne possono essere aggiunti altri, a seconda delle esigenze o
dell’impostazione del programma utilizzato come MUA.
Campo
‘Reply-To:’
‘Organization:’
‘X-...:’
Descrizione
Permette di indicare un indirizzo al quale si desidera siano
inviate le risposte.
Permette di definire l’organizzazione proprietaria della
macchina da cui ha origine il messaggio di posta elettronica.
I campi che iniziano per ‘X-’ sono ammessi, senza essere definiti. In pratica, vengono utilizzati per scopi vari, accordati
tra le parti.
Per una convenzione ormai consolidata, il primo record dell’intestazione di un messaggio di posta
elettronica inizia con la parola chiave ‘From’ seguita immediatamente da uno spazio. Questo
record è diverso da quello che definisce il campo ‘From:’ (cioè quello che termina con i due
punti), tanto che per distinguerlo viene spesso indicato come ‘From_’, per sottolineare il fatto
che non appaiono i due punti prima dello spazio.
La presenza di questo campo un po’ anomalo, fa sì che quando si scrive un messaggio, nel
corpo non possa apparire la parola ‘From’ scritta in questo modo e a partire dalla prima colonna.
Convenzionalmente, se ne esiste la necessità, viene aggiunto il carattere ‘>’ davanti a questa
(‘>From’). Il problema si pone essenzialmente quando si vuole incorporare un messaggio di
posta elettronica nel corpo di un nuovo messaggio; il programma che si usa per comporre il testo
dovrebbe provvedere da solo a correggere la riga in cui appare il record ‘From_’.
I vari MTA che si occupano di trasferire e consegnare il messaggio a destinazione sono responsabili dell’aggiunta dei campi ‘Received:’. Questi vengono aggiunti a ogni passaggio, dal basso
verso l’alto, allo scopo di tenere traccia degli spostamenti che il messaggio ha dovuto subire.
154.2.1 Tracciamento di un messaggio
I vari campi ‘Received:’ utilizzati per tenere traccia degli spostamenti di un messaggio di posta
elettronica permettono di ricostruirne il percorso. Nell’esempio mostrato in precedenza, venivano
utilizzati solo due MTA.
1. Il primo campo ‘Received:’ partendo dal basso rappresenta il primo MTA che è stato
interpellato.
Received: (from pippo@localhost)
by router.brot.dg (8.8.7/8.8.7) id AAA00384
for [email protected]; Tue, 9 Jun 1998 00:00:09 +0200
1643
Trattandosi dello stesso nodo da cui è stato inviato il messaggio, appare solo l’informazione dell’MTA, ‘by router.brot.dg’, e la destinazione, ‘for
[email protected]’.
2. Il secondo campo ‘Received:’ viene aggiunto dal secondo MTA interpellato, che in questo
caso è anche l’ultimo.
L’MTA provvede prima a identificare l’origine, ovvero l’MTA che gli ha trasmesso il
messaggio, attraverso l’indicazione ‘from router.brot.dg’; quindi identifica se stesso
attraverso l’indicazione ‘by dinkel.brot.dg’.
I vari record ‘Received:’ possono essere più o meno ricchi di informazioni e questo dipende dall’MTA che li genera. In particolare, l’indicazione della data permette eventualmente di
comprendere in che punto la trasmissione del messaggio è stata ritardata; inoltre, la presenza
dell’identificativo ‘id’ può permettere di ricercare informazioni su una trasmissione particolare
all’interno di registrazioni eventuali.
Alcuni MTA, per motivi di sicurezza, verificano l’origine della trasmissione attraverso il sistema DNS e includono il nome e l’indirizzo IP così ottenuto tra parentesi. Nell’esempio
mostrato, il secondo MTA ha indicato ‘from router.brot.dg ([email protected]
[192.168.1.254])’.
154.3 Messaggi contraffatti e punto di iniezione
La posta elettronica è stato il primo problema della comunicazione nella rete. Così, gli standard
che si sono ottenuti e i programmi a disposizione sono potentissimi dal punto di vista delle
possibilità che vengono offerte. Ciò, assieme al fatto che la trasmissione dei messaggi di posta
elettronica è un’operazione gratuita per il mittente, ha favorito chi usa la posta elettronica per
«offendere»: sia attraverso la propaganda indesiderata, sia attraverso altre forme più maliziose.
Non è l’intenzione di questo documento la classificazione dei vari tipi di offesa che si possono
subire attraverso la posta elettronica e nemmeno insegnare a usare queste tecniche. La conoscenza dei punti deboli di un MTA è importante per comprendere con quanta serietà vada presa la
sua amministrazione e anche con quanta prudenza vadano mosse delle accuse verso il presunto
mittente di un messaggio indesiderato.
Chi utilizza la posta elettronica per attaccare qualcuno, cerca di farlo in modo da non essere identificato. Per questo si avvale normalmente di un MTA di partenza diverso da quello normalmente
competente per la sua rete di origine (il proprio ISP). Oltre a tutto, di solito l’attacco consiste nell’invio di un messaggio a una grande quantità di destinatari, per cui, la scelta di un MTA estraneo
(e innocente) serve per scaricare su di lui tutto il lavoro di distribuzione. Il «lavoro» di ogni ipotetico aggressore sta quindi nella ricerca di un MTA che si lasci manovrare e nella composizione
di un messaggio con un’intestazione fasulla che lasci intendere che il messaggio è già transitato
da un’altra origine (che può esistere effettivamente o meno).
A parte il problema derivato dal fatto che la configurazione degli MTA è difficile, per cui capita
spesso che qualcosa sfugga cosicché l’MTA si trova a permettere accessi indesiderabili, lo standard SMTP è tale per cui l’MTA che riceve un messaggio deve accettare le informazioni che gli
vengono fornite riguardo ai punti di transito precedenti (i vari campi ‘Received:’ già esistenti).
Quando i campi ‘Received:’ sono stati contraffatti l’MTA dal quale ha origine effettivamente
la trasmissione è il cosiddetto punto di iniezione .
1644
L’esempio seguente mostra un messaggio di questo tipo, in cui l’origine, hotmail.com, si
è dimostrata fasulla. Probabilmente, il punto di iniezione è stato ‘cnn.Princeton.EDU’, ma
questo non può essere stabilito in modo sicuro.
X-POP3-Rcpt: daniele@tv
Return-Path: <[email protected]>
Received: from outbound.Princeton.EDU (outbound.Princeton.EDU [128.112.128.88])
by tv.calion.com (8.8.4/8.8.4) with ESMTP
id HAA02209 for <[email protected]>;
Tue, 9 Jun 1998 07:12:59 +0200
Received: from [email protected] (port 4578 [128.112.128.81])
by outbound.Princeton.EDU with SMTP
id <542087-18714>;
Tue, 9 Jun 1998 00:48:58 -0400
Received: from cnn.Princeton.EDU by Princeton.EDU (5.65b/2.139/princeton)
id AA09882; Tue, 9 Jun 98 00:17:18 -0400
Received: from hotmail.com by cnn.Princeton.EDU (SMI-8.6/SMI-SVR4)
id AAA12040; Tue, 9 Jun 1998 00:17:13 -0400
Date:
Mon, 08 Jun 98 11:09:01 EST
From: "Dreambuilders" <[email protected]>
Subject: Real Business
HOW WOULD YOU LIKE TO BE PAID LIKE THIS?
*How about if you received compensation on 12 months Business Volume for
every transaction in your entire organization and this made it possible for
you to earn over $14000.00 US in your first month ?
* How about if you were paid daily, weekly, and monthly ?...
* How about if you could do business everywhere in the world and be paid in
US dollars ?
* What if your only out of pocket expense was a $10 processing fee to get
started...
* Would you want to evaluate a business like that ?
If so
reply with "real business" in subject box to [email protected]
154.4 Identificazione della destinazione
In precedenza, in questo capitolo, si è accennato al meccanismo di trasferimento dei messaggi
tra diversi MTA. L’MTA di origine, o comunque quello utilizzato come distributore di origine
(relè), deve identificare l’MTA più adatto a ricevere il messaggio per ottenere la consegna di
questo all’utente destinatario. Generalmente, il problema si riduce alla trasformazione del nome
di dominio dell’indirizzo di posta elettronica del destinatario in un numero IP, per poi tentare di
contattare tale nodo con la speranza di trovare un MTA pronto a rispondere.
La realtà è spesso più complessa e può darsi benissimo che l’MTA competente per ricevere
la posta elettronica di un certo utente sia un nodo diverso da quello che appare nell’indirizzo
di posta elettronica. Per pubblicizzare questo fatto nella rete si utilizzano i record ‘MX’ nella
configurazione dei DNS. L’esempio seguente mostra un caso descritto meglio nel capitolo 122
in cui si stabilisce che, per consegnare messaggi di posta elettronica nel dominio brot.dg, è
competente il servente dinkel.brot.dg.
brot.dg.
IN
MX
10 dinkel.brot.dg.
1645
154.5 Misure di sicurezza
Le misure di sicurezza fondamentali attraverso cui si cerca di evitare l’uso improprio di un MTA
sono essenzialmente di due tipi: l’identificazione del sistema da cui proviene la richiesta di inoltro
di un messaggio (attraverso il DNS) e il rifiuto dei messaggi che sono originati da un dominio
estraneo e sono diretti anche a un dominio estraneo.
La prima delle due misure si concretizza nell’indicazione tra parentesi del nome di dominio
e del numero IP del nodo chiamante nel campo ‘Received:’. Nell’esempio visto in precedenza, l’MTA del nodo dinkel.brot.dg ha verificato l’indirizzo di chi lo ha contattato
(router.brot.dg).
^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
La seconda misura si avvale generalmente del servizio di risoluzione dei nomi (record ‘MX’),
attraverso il quale si può determinare quale sia il dominio di competenza per il recapito dei
messaggi, stabilendo così che i messaggi provenienti dall’esterno che non siano diretti al proprio
dominio di competenza, non possono essere accettati.
La maggior parte degli MTA sono (o dovrebbero essere) configurati in questo modo. Questo
dovrebbe spiegare il motivo per cui spesso è impossibile inviare messaggi di posta elettronica in
una rete locale se prima non si attiva un servizio DNS.
154.6 Referente per l’amministrazione del servizio
L’amministratore di un servizio di distribuzione di posta elettronica deve essere raggiungibile attraverso dei nominativi convenzionali. Fondamentalmente si tratta di postmaster@dominio .
Ultimamente, a causa della crescente invadenza di chi utilizza la posta elettronica in modo fraudolento, è diventato comune l’utilizzo dell’indirizzo abuse@dominio per identificare la persona
competente nei confronti di possibili abusi originati dal servizio di sua competenza.
Naturalmente, tali indirizzi sono generalmente degli alias attraverso cui i messaggi possono
essere rinivati al recapito dell’utente che incorpora effettivamente tali competenze.
154.7 Scelta dell’MTA
Nei sistemi Unix, così come in quelli GNU, la scelta tradizionale del sistema di gestione dei
messaggi di posta elettronica è Sendmail. Ci si può prendere il lusso di cambiare sistema solo se
si conosce bene il problema e le implicazioni rispetto agli altri programmi che hanno qualcosa a
che fare con il sistema di invio dei messaggi.
Di solito si abbandona Sendmail a causa della sua storica carenza nei confronti della sicurezza.
Con il tempo, Sendmail potrebbe diventare un pacchetto solido e affidabile, ma per il momento,
la continua scoperta di nuovi problemi di sicurezza dà a questo sistema una pessima reputazione.
Nella scelta del sostituto di Sendmail si pongono di fronte tre scelte comuni: Smail, Exim e
Qmail. I primi due hanno una buona compatibilità con le convenzioni introdotte da Sendmail,
mentre l’ultimo punta tutto sulla sicurezza abbandonando quasi tutte le tradizioni precedenti.
1646
154.8 Scelta del servente SMTP per l’elaboratore
personale
Quando si deve gestire un solo elaboratore con un solo utente umano, connesso a una rete che
fornisce qualche servizio come nel caso di un collegamento con un ISP, ovvero un fornitore di
accesso a Internet, si rischia di avere un’idea distorta del problema della posta elettronica.
Si ipotizza una situazione del tipo seguente: è stato ottenuto un accesso a una rete, grande o
piccola che sia, con una casella postale collocata presso un nodo di quella rete e con la possibilità
di utilizzare un servente SMTP per l’invio della posta elettronica. La connessione a questa rete
può essere continua, o discontinua.
In questa situazione, l’elaboratore che viene inserito in tale rete non ha bisogno (almeno in teoria) di gestire un servente SMTP locale e nemmeno di un sistema di consegna dei messaggi. È
sufficiente un programma MUA che per l’invio dei messaggi sia in grado di servirsi direttamente
del servente SMTP offerto dalla rete a cui ci si collega, quindi un programma per il prelievo dei
messaggi giunti presso la casella postale remota (protocollo POP2, POP3, o IMAP).
A parte la semplicità dell’approccio, il vantaggio di sfruttare un servente SMTP esterno al proprio
elaboratore locale, sta nel fatto che in tal modo è il servente SMTP esterno a preoccuparsi di
duplicare il messaggio tra tutti i destinatari (se ne è stato indicato più di uno); inoltre, è lui che
provvede a ritentare gli invii se necessario. Utilizzando per questo un servente SMTP locale, si
otterrebbe un maggior carico nel collegamento tra l’elaboratore locale e la rete esterna; inoltre,
non sarebbe possibile interrompere tale comunicazione finché i messaggi trasmessi non risultano
recapitati alla destinazione.
Nel caso si possa essere certi di avere una connessione stabile alla rete esterna in questione, se è
stato ottenuto anche un numero IP statico e quindi un nome di dominio per il proprio nodo, può
essere conveniente decidere di mantenere sempre acceso il proprio elaboratore e ricevere direttamente lì la posta. Per questo, occorre attivare un servente SMTP locale che poi provveda alla
consegna dei messaggi ricevuti. In pratica serve un MTA completo. In questa situazione, l’elaboratore può avere anche più utenti, gestendo così più caselle postali. Tuttavia, se si dispone sempre
di un servente SMTP esterno, è ancora conveniente il suo utilizzo per l’invio dei messaggi.
Nel momento in cui non si tratta più di un semplice elaboratore da collegare a una rete esterna,
ma si tratta di tutta una rete locale, il problema cambia aspetto, evidentemente. Ma questo verrà
trattato più avanti.
154.9 Pratica manuale con i protocolli
È importante avere un minimo di dimestichezza con i protocolli utilizzati per la gestione della
posta elettronica. Oltre all’aspetto puramente didattico, il loro utilizzo manuale attraverso un
cliente TELNET, può aiutare a verificare la configurazione di un servente SMTP, oppure di
manovrare all’interno di una propria casella postale remota.
In queste sezioni vengono mostrati solo i comandi elementari che si possono utilizzare con il
protocollo SMTP e POP3.
1647
154.9.1 SMTP attraverso un cliente TELNET
È già stato mostrato in precedenza un esempio di connessione con un servizio SMTP allo scopo
di inviare manualmente un messaggio. Lo stesso esempio viene mostrato nuovamente a vantaggio
del lettore.
$ telnet roggen.brot.dg smtp[ Invio ]
Trying 192.168.1.2...
Connected to roggen.brot.dg.
220 roggen.brot.dg ESMTP Sendmail 8.8.5/8.8.5; Thu, 11 Sep 1997 19:58:15 +0200
250 roggen.brot.dg Hello dinkel.brot.dg [192.168.1.1], pleased to meet you
MAIL From: <[email protected]>[ Invio ]
250 <[email protected]>... Sender ok
RCPT To: <[email protected]>[ Invio ]
250 <[email protected]>... Recipient ok
DATA[ Invio ]
354 Enter mail, end with "." on a line by itself
Subject: Saluti.[ Invio ]
Ciao Antonio,[ Invio ]
come stai?[ Invio ]
Io sto bene e mi piacerebbe risentirti.[ Invio ]
Saluti,[ Invio ]
Daniele[ Invio ]
.[ Invio ]
250 TAA02951 Message accepted for delivery
QUIT[ Invio ]
221 dinkel.brot.dg closing connection
Connection closed by foreign host.
L’esempio mostra tutto quello che serve fare per inviare un messaggio. I comandi ‘HELO’, ‘MAIL’,
‘RCPT’ e ‘DATA’, vanno inseriti rispettando questa sequenza e la loro sintassi dovrebbe essere
evidente dall’esempio.
Un problema importante che si incontra quando si configura il proprio servizio SMTP è quello
del filtro rispetto al relè, cioè all’attività di ritrasmissione dei messaggi. Solitamente si consente
di fare il relè senza alcuna limitazione per i messaggi provenienti dai nodi della propria rete
locale, mentre lo si impedisce quando il messaggio è di origine esterna a tale rete e in più la
stessa destinazione è esterna alla rete locale. Il concetto si esprime facilmente a parole, ma la
configurazione del servizio SMTP potrebbe essere complessa e si può rischiare di tagliare fuori
1648
dal servizio proprio alcuni nodi che invece dovrebbero poterlo utilizzare. L’esempio seguente
mostra un esempio di cattiva configurazione e da questo si intende quanto sia utile l’utilizzo
manuale del protocollo SMTP per controllare tali situazioni.
$ telnet dinkel.brot.dg smtp[ Invio ]
Dal nodo roggen.brot.dg si vuole inviare un messaggio al nodo weizen.brot.dg, utilizzando per questo il servente dinkel.brot.dg, il quale era inteso dovesse fare da relè,
almeno per la rete locale brot.dg.
Trying 192.168.1.1...
220 roggen.brot.dg ESMTP Exim 1.90 #1 Wed, 4 Nov 1998 09:47:05 +0100
250 dinkel.brot.dg Hello daniele at roggen.brot.dg [192.168.1.2]
MAIL From: [email protected][ Invio ]
250 <[email protected]> is syntactically correct
RCPT To: [email protected][ Invio ]
550 relaying to <[email protected]> prohibited by administrator
Come si può vedere, qualcosa non va: il servente ha accettato l’origine, ma da quell’origine non
accetta la destinazione.
QUIT[ Invio ]
221 roggen.brot.dg closing connection
154.9.2 POP3 attraverso un cliente TELNET
Anche l’utilizzo manuale del protocollo POP3 può essere utile. Il problema si pone normalmente
quando la propria casella postale remota è stata riempita in maniera abnorme da un aggressore.
Se si dispone di un collegamento troppo lento, è meglio evitare di scaricare tutta la posta, mentre
sarebbe opportuno eliminare direttamente i messaggi che sembrano essere inutili.
L’esempio seguente serve a capire in che modo è possibile visionare la situazione della propria
casella postale remota e come è possibile intervenire per eliminare i messaggi indesiderati.
$ telnet dinkel.brot.dg pop-3[ Invio ]
Trying 192.168.1.1...
+OK POP3 dinkel.brot.dg v4.47 server ready
La prima cosa richiesta è l’inserimento del nominativo-utente e subito dopo la parola d’ordine.
USER tizio[ Invio ]
+OK User name accepted, password please
PASS tazza[ Invio ]
Dopo l’indicazione della parola d’ordine, il servizio POP3 indica quanti messaggi sono presenti.
In questo caso solo due.
1649
+OK Mailbox open, 2 messages
Il comando ‘LIST’ consente di avere un elenco dei messaggi con a fianco la loro dimensione in
byte. Ciò può essere utile per individuare messaggi «bomba», dove l’indizio potrebbe essere dato
dalla dimensione esageratamente grande di un messaggio o dal ripetersi di messaggi con la stessa
identica dimensione.
LIST[ Invio ]
+OK Mailbox scan listing follows
1 520
2 498
.
In questo caso, i messaggi sembrano proprio innocui. Eventualmente, se si vede il ripetersi di un
messaggio breve, si può controllarne il contenuto, con il comando ‘RETR’.
RETR 2[ Invio ]
Viene letto il secondo messaggio.
+OK 498 octets
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Wed, 4 Nov 1998 10:06:30 +0100
Received: from daniele by dinkel.brot.dg with local (Exim 1.90 #1)
for [email protected]
id 0zayta-00009R-00; Wed, 4 Nov 1998 10:06:30 +0100
Subject: SPAM
Date: Wed, 4 Nov 1998 10:06:30 +0100
Status:
questo e‘ un messaggio SPAM.
.
La dimensione del messaggio comprende tutto ciò che lo compone, compresa la riga iniziale in
cui si informa che questa è di 498 ottetti (gruppi di 8 bit), ovvero byte.
Per cancellare un messaggio, si può utilizzare il comando ‘DELE’, seguito dal numero
corrispondente.
DELE 2[ Invio ]
+OK Message deleted
Per concludere si utilizza il comando ‘QUIT’.
QUIT[ Invio ]
+OK Sayonara
154.10 Riferimenti
• Olaf Kirch, NAG, The Linux Network Administrators’ Guide
• Doug Muth, The SPAM-L FAQ
<http://oasis.ot.com/~dmuth/spam-l/>
Capitolo
155
Sendmail: introduzione
Sendmail 1 è divenuto lo standard per quanto riguarda i programmi di gestione della posta elettronica in qualità di MTA. La sua adattabilità e la conseguente difficoltà nella definizione della
sua configurazione, sono estreme.
Nel capitolo 151 si è già accennato al funzionamento di Sendmail. Questo capitolo espande un
po’ i concetti, ma si tratta sempre di informazioni limitate; il documento di riferimento per questo
resta: Sendmail edito da O’Reilly.
155.1 Destinatari e formati degli indirizzi
Sendmail, per quanto riguarda la composizione degli indirizzi di posta elettronica, utilizza le
convenzioni seguenti.
• Ciò che appare tra parentesi viene eliminato, perché considerato un commento.
• Ciò che appare tra parentesi angolari (‘<>’) viene preferito rispetto a ogni altra indicazione. In pratica, ciò permette di comporre gli indirizzi inserendo anche il nome effettivo
del mittente o del destinatario, evidenziando l’indirizzo di posta elettronica vero e proprio
all’interno delle parentesi angolari. Per esempio,
‘Tizio Tizi <[email protected]>’
è un modo formalmente corretto per abbinare all’indirizzo [email protected] il
nome e cognome dell’utente: Tizio Tizi.
• Gli apici doppi permettono di delimitare una stringa. In questo modo, alle volte si delimita
il nominativo dell’utente, come nell’esempio seguente:
‘"Tizio Tizi" <[email protected]>’
Nello stesso modo, la barra obliqua inversa (‘\’) può essere usata per proteggere il carattere
successivo.
Per Sendmail, il destinatario di un messaggio di posta elettronica può essere anche un file o un
programma. In pratica, se l’indirizzo utilizzato inizia con una barra verticale (‘|’), si intende
trattarsi di una pipeline, all’interno della quale deve essere inviato il messaggio; se invece l’indirizzo inizia con una barra obliqua normale (‘/’), si intende trattarsi di un file, che viene creato
appositamente oppure gli viene aggiunto il testo del messaggio se esiste già.
L’utilizzo di questi indirizzi speciali, riferiti a file o a pipeline, può essere fatto ovunque; per
esempio nel file ‘~/.forward’ o come destinatario di un alias nel file ‘/etc/aliases’. Queste
possibilità, tra le altre cose, sono alla base del funzionamento delle liste di posta elettronica
(mailing-list).
155.2 Alias, inclusione e forward
All’interno di un sistema è possibile definire dei recapiti fittizi, definiti alias. La predisposizione
di questi viene fatta nel file ‘/etc/aliases’, ma prima che questi abbinamenti siano recepiti
da Sendmail, occorre rigenerare il file ‘/etc/aliases.db’ con il comando ‘newaliases’.
Attraverso gli alias è possibile:
1
1650
1651
• definire dei nominativi utenti lunghi e articolati, che non sarebbero ammissibili nella gestione normale di un sistema Unix (il quale pone generalmente il limite degli otto caratteri
di lunghezza per i nomi degli utenti),
• definire dei nominativi di utenti standard riferiti a determinate competenze amministrative tipiche, girando i messaggi loro rivolti alle persone che ricoprono effettivamente gli
incarichi corrispondenti;
• definire un elenco di destinatari differenti a cui deve essere inviata una copia dei messaggi
riferiti a un certo alias;
• definire una pipeline contenente un comando che deve occuparsi di elaborare i messaggi
riferiti a un certo alias;
• definire un file per l’archiviazione dei messaggi indirizzati a un certo alias;
• definire un elenco di destinatari differenti in base a un elenco di indirizzi contenuto in un
file esterno.
L’esempio seguente fa in modo che i messaggi inviati all’utente fittizio ‘Tizio.Tizi’ siano
girati al nome dell’utente gestito effettivamente nel sistema.
Tizio.Tizi:
tizio
L’esempio seguente riguarda la situazione tipica in cui i messaggi indirizzati a un utente fittizio
riferito a una competenza amministrativa vengono girati all’utente reale che svolge quel compito
particolare.
postmaster:
daniele
L’esempio seguente mostra un alias per il quale i messaggi vengono rinviati (vengono fatti proseguire, o meglio, secondo la tradizione postale, vengono proseguiti) e duplicati per una serie di
utenti che devono essere informati contemporaneamente.
abuse:
daniele, tizio, [email protected]
L’esempio seguente mostra un alias per il quale tutti i messaggi vengono elaborati da un comando, che li riceve attraverso lo standard input. Questo è il modo tipico attraverso cui si inviano i
messaggi a un programma di gestione di una lista di posta elettronica (mailing-list).
lista-pippo:
"| /home/liste/bin/ricezione-messaggi lista-pippo"
L’inclusione è un modo di definire un alias dinamico, riferito a un elenco di indirizzi contenuti
in un file di testo normale. La forma
:include:percorso_assoluto
equivale a includere tutti gli indirizzi definiti nel file specificato, che deve comprendere necessariamente il percorso assoluto per raggiungerlo. Utilizzando questa forma di definizione degli elenchi di destinatari, si evita di dover modificare ogni volta il file ‘/etc/aliases’, ma
soprattutto si evita di dover rieseguire il comando ‘newaliases’.
L’esempio seguente invia i messaggi destinati all’utente fittizio ‘lista-pippo-inv’ a tutto
l’elenco contenuto nel file ‘/home/liste/pippo/iscritti’.
lista-pippo-inv:
:include:/home/liste/pippo/iscritti
Il forward è la gestione di un alias personale (allo scopo di fare proseguire i messaggi verso altre destinazioni), che ogni utente può definire senza dover chiedere la modifica del file ‘/etc/
aliases’. Si possono fare proseguire i messaggi generando il file di testo ‘~/.forward’ che
può contenere uno o più indirizzi differenti, comprese le pipeline, i file e le inclusioni. Il risultato
1652
che si ottiene è che i messaggi destinati all’utente che ha predisposto questo file nella propria directory personale, vengono rinviati a tutti gli indirizzi contenuti nel file stesso. Generalmente, per
la sua natura, il file ‘~/.forward’ viene usato dagli utenti che hanno diversi recapiti e vogliono
concentrare la posta elettronica in un solo punto di destinazione. Per questo motivo, nel file ‘~/
.forward’ viene indicato quasi sempre un solo indirizzo di posta elettronica.
155.3 Configurazione di Sendmail con il pacchetto di
Berkeley
Si è già accennato al fatto che la configurazione di Sendmail, attraverso la modifica diretta del file
‘/etc/sendmail.cf’, sia un’impresa estrema. Fortunatamente, per alleviare queste difficoltà, si
sono sviluppati nel tempo diversi programmi in grado di generare automaticamente il file ‘/etc/
sendmail.cf’ utilizzando dei segmenti di codice già pronto da combinare opportunamente
assieme.
Attualmente, il tipo di configurazione più diffuso è quello predisposto dall’università di Berkeley.
Si tratta di una serie di file macro per M4, un macro-compilatore concettualmente analogo al
preprocessore del linguaggio C (si veda eventualmente il capitolo 321).
Il pacchetto viene installato da qualche parte, a seconda dell’organizzazione predisposta
dalla propria distribuzione GNU, ma probabilmente si tratta della directory ‘/usr/lib/
sendmail-cf/’. Da quella directory se ne diramano altre contenenti i diversi pezzi di
configurazione che possono essere combinati assieme.
155.3.1 Introduzione al sistema
A partire dalla directory di origine del pacchetto di configurazione di Sendmail, si trovano in
particolare i file readme che rappresentano tutta la documentazione disponibile, oltre a una serie
di directory contenenti a loro volta i file componenti del sistema di macro.
Directory
‘m4/’
‘cf/’
‘sh/’
altre directory
Descrizione
Contiene alcune macro di partenza, di cui, la più importante è
‘cf.m4’ che viene usata per iniziare il procedimento.
Contiene i file di configurazione utilizzati dalla macro ‘m4/
cf.m4’; questi file hanno l’estensione ‘.mc’. Di questi file
ne viene usato solo uno: quello predisposto per il proprio sistema. È molto probabile che la propria distribuzione GNU
inserisca il file utilizzato effettivamente per ottenere la configurazione di Sendmail che questa utilizza; potrebbe trattarsi
di ‘linux.mc’ oppure di un altro nome che ricorda quello
della distribuzione (per esempio ‘redhat.mc’).
Contiene degli script di shell utilizzati automaticamente da
M4, in base alle istruzioni contenute nelle macro utilizzate.
Le altre directory che discendono dall’origine del pacchetto di configurazione, sono utilizzate per classificare i vari file macro incorporabili in quello che si scrive all’interno della directory ‘cf/’. Per esempio, un’istruzione del
tipo ‘MAILER(local)’, fa riferimento al file ‘mailer/
local.m4’.
Quando si predispone un file di configurazione nella directory ‘cf/’, la sua compilazione avviene
nel modo seguente:
m4 ../m4/cf.m4 file_di_configurazione > file-risultato
1653
Per esempio, supponendo di avere realizzato il file di configurazione ‘cf/prova.mc’ e di voler
generare il file ‘cf/prova.cf’, si procede come segue:
# cd /usr/lib/sendmail-cf[ Invio ]
In questo modo ci si posiziona nella directory principale del pacchetto di configurazione.
# cd cf[ Invio ]
Prima di iniziare la compilazione occorre posizionarsi nella directory contenente il file di
configurazione.
# m4 ../m4/cf.m4 prova.mc > prova.cf[ Invio ]
A questo punto il file ‘cf/prova.cf’ è stato generato, quindi è sufficiente cambiargli nome e
sostituirlo al posto del vecchio ‘/etc/sendmail.cf’.
Naturalmente, perché Sendmail prenda atto della nuova configurazione, deve essere riavviato
(dovrebbe bastare l’invio di un segnale di aggancio, ‘SIGHUP’).
155.3.2 Struttura e contenuto del file di configurazione
Il file di configurazione inizia generalmente con delle annotazioni, che possono riguardare il copyright o lo scopo del file. Osservando i file già esistenti si potrebbe pensare che il simbolo ‘#’
rappresenti l’inizio di un commento; in realtà si tratta di un commento per il file ‘.cf’ che si
vuole generare, perché all’interno del sistema di macro di M4 è stato ridefinito opportunamente
il simbolo di commento in modo che ‘#’ venga trattato come un carattere qualunque senza significati particolari. Questo significa che le espansioni hanno luogo anche all’interno dei commenti
per il file ‘/etc/sendmail.cf’.
Il modo adottato comunemente per eliminare le intestazioni contenenti le informazioni sul copyright e le riserve all’uso dei vari file, è quello di dirigere l’output in modo da perderlo, attraverso
la macro ‘divert(-1)’.
In teorica, l’aspetto normale di un file di configurazione per questo pacchetto dovrebbe essere il
seguente:
divert(-1)
#
# Copyright (c) 1983 Eric P. Allman
# Copyright (c) 1988, 1993
#
The Regents of the University of California. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without...
# ...
divert(0)dnl
include(‘../m4/cf.m4’)
VERSIONID(‘@(#)generic-linux.mc 8.3 (Berkeley) 3/23/96’)
OSTYPE(linux)dnl
DOMAIN(generic)dnl
MAILER(local)dnl
MAILER(smtp)dnl
In pratica, questo potrebbe generare un file ‘.cf’ insufficiente al funzionamento corretto di
Sendmail.
Si può osservare all’inizio l’inclusione del file ‘m4/cf.m4’ che è il responsabile
dell’impostazione di questo sistema di macro.
Quasi tutte le macro specifiche che si utilizzano in questo file (quelle che appaiono in lettere maiuscole), rappresentano in realtà l’inclusione di un file, quello che appare come pa-
1654
rametro, proveniente dalla directory corrispondente al nome della macro stessa. Per esempio, ‘OSTYPE(linux)’ rappresenta in pratica l’inclusione del file ‘ostype/linux.m4’. Nelle
sezioni seguenti vengono descritte brevemente alcune di queste macro specifiche.
155.3.2.1 Macro VERSIONID
VERSIONID(descrizione_della_versione )
La macro ‘VERSIONID’ permette semplicemente di includere un’annotazione sulla versione della
configurazione, nei commenti del file ‘.cf’ generato. È utile per documentare diversi tipi di
configurazione, tenuto conto che la forma per definire la versione non è prestabilita.
155.3.2.2 Macro OSTYPE
OSTYPE(macro_da_includere )
Attraverso la macro ‘OSTYPE’ si può definire il nome del sistema operativo utilizzato. In pratica, si tratta di indicare il nome (senza estensione) di un file macro contenuto nella directory
‘ostype/’, da includere in quel punto.
Attraverso l’inclusione di questo file, si ottiene la definizione di alcune informazioni importanti
riguardo all’installazione di Sendmail nel proprio sistema operativo; per esempio si può definire
la collocazione del file contenente gli alias, il programma da usare per la consegna dei messaggi,
le opzioni e gli argomenti che questo programma deve avere. Tutte queste informazioni vengono
specificate attraverso la definizione di macro specifiche, come se si trattasse della definizione
di variabili. Se tali macro non vengono definite in questa occasione, verranno definite in un
altro momento, ricevendo un valore predefinito, come documentato regolarmente nei file che
accompagnano il pacchetto di configurazione.
L’esempio più semplice possibile del file ‘ostype/linux.m4’ è il seguente,
divert(-1)
#
# ...
divert(0)
define(‘LOCAL_MAILER_PATH’, /bin/mail)dnl
dove si definisce soltanto che il programma di consegna dei messaggi è ‘/bin/mail’. In pratica
però, normalmente, questo file viene modificato opportunamente da chi allestisce il pacchetto di
configurazione per una distribuzione GNU particolare.
La possibilità che questo file non sia conforme alla distribuzione standard del pacchetto di
configurazione di Sendmail, deve essere tenuto in considerazione quando si vuole provare
a generare un file ‘.cf’ differente dal ‘/etc/sendmail.cf’ già predisposto dalla propria
distribuzione. Infatti, le modifiche che potrebbero essere state apportate possono pregiudicare
l’effetto prevedibile delle altre macro.
155.3.2.3 Macro DOMAINS
DOMAINS(macro_da_includere )
Attraverso la macro ‘DOMAINS’ si può definire il nome di una configurazione riferita a un dominio
particolare. Si ottiene in pratica l’inclusione di un file contenuto nella directory ‘domains/’.
1655
Il pacchetto di configurazione fornisce il file ‘domains/generic.m4’, che dovrebbe adattarsi a
tutte le situazioni normali. Spesso, questo non viene utilizzato, inserendo direttamente quello che
serve nel file di configurazione normale.
Quello che segue è un estratto dal file ‘domains/generic.m4’.
divert(-1)
#
# ...
divert(0)
VERSIONID(‘@(#)generic.m4
8.3 (Berkeley) 3/24/96’)
define(‘confFORWARD_PATH’, ‘$z/.forward.$w:$z/.forward’)dnl
FEATURE(redirect)dnl
FEATURE(use_cw_file)dnl
155.3.2.4 Macro MAILERS
MAILERS(macro_da_includere )
Attraverso la macro ‘MAILERS’ si può definire il nome di una configurazione riferita a un tipo
particolare di sistema di invio dei messaggi. Si ottiene in pratica l’inclusione di un file contenuto
nella directory ‘mailers/’.
Normalmente, questa macro viene utilizzata più volte all’interno del file di configurazione, per
definire diverse possibilità. Tipicamente si tratta di:
MAILER(local)
che si occupa della gestione dei messaggi all’interno del sistema e viene utilizzato in modo
predefinito;
MAILER(smtp)
che si occupa di configurare la gestione dei messaggi attraverso il protocollo SMTP, cioè riguarda
la configurazione necessaria all’invio dei messaggi al di fuori del sistema.
Nel primo caso si ha l’inclusione del file ‘mailers/local.m4’, nel secondo di ‘mailers/
smtp.m4’
Dalla macro ‘MAILER(smtp)’ dipende la base del sistema di sicurezza contro gli utilizzi indesiderati del proprio servente SMTP. Infatti, è qui che vengono definite le istruzioni necessarie nel
file ‘.cf’ per impedire l’utilizzo da parte di nodi che non facciano parte della zona DNS di competenza. Cioè, quello che si vuole evitare è che un nodo diverso da quelli definiti nella zona per
cui è stato previsto un record ‘MX’, possa utilizzare il servente SMTP per raggiungere indirizzi al
di fuori del sistema locale (si veda eventualmente quanto discusso nel capitolo precedente).
155.3.2.5 Macro FEATURE
FEATURE(macro_da_includere )
Attraverso la macro ‘FEATURE’ si può definire il nome di una configurazione riferita a una particolarità che si vuole includere. Si ottiene in pratica l’inclusione di un file contenuto nella directory
‘feature/’.
Normalmente, questa macro viene utilizzata più volte all’interno del file di configurazione, ma
questo preferibilmente prima di ‘MAILER’.
1656
155.3.2.6 HACK
HACK(macro_da_includere )
Attraverso la macro ‘HACK’ si può definire il nome di una configurazione riferita a una particolarità sperimentale che si vuole includere. Si ottiene in pratica l’inclusione di un file contenuto
nella directory ‘hack/’.
Teoricamente, questa macro non dovrebbe essere utilizzata; in pratica succede spesso il contrario
a causa delle esigenze di definire dei filtri aggiuntivi contro gli accessi indesiderati.
155.3.3 Esempio di una distribuzione GNU/Linux
A titolo di esempio, viene presentata la configurazione utilizzata dalla distribuzione GNU/Linux
Red Hat 5.0, trattandosi precisamente del file ‘cf/redhat.mc’.
divert(-1)
include(‘../m4/cf.m4’)
define(‘confDEF_USER_ID’,‘‘8:12’’)
OSTYPE(‘linux’)
undefine(‘UUCP_RELAY’)
undefine(‘BITNET_RELAY’)
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
MAILER(procmail)
MAILER(smtp)
HACK(check_mail3,‘hash -a@JUNK /etc/mail/deny’)
HACK(use_ip,‘/etc/mail/ip_allow’)
HACK(use_names,‘/etc/mail/name_allow’)
HACK(use_relayto,‘/etc/mail/relay_allow’)
HACK(check_rcpt4)
HACK(check_relay3)
La prima cosa che si osserva è che il file inizia con la macro ‘divert(-1)’, senza commenti
da eliminare e senza il consueto ‘divert(0)’ successivo. In questo modo, dal momento che
nessuna delle macro utilizzate dopo deve restituire qualcosa, si evita di terminare le varie macro
con il solito ‘dnl’.
Per sicurezza, nel caso servisse, vengono cancellate le macro ‘UUCP_RELAY’ e ‘BITNET_RELAY’.
Invece di utilizzare una macro ‘DOMAIN’ vengono incluse direttamente le particolarità attraverso
l’uso della macro ‘FEATURE’. In particolare viene definito quanto segue.
• ‘FEATURE(redirect)’
Si tratta di una particolarità poco importante, con la quale si ottiene di emettere un avviso nel caso sia utilizzato un indirizzo di posta elettronica nella forma
‘indirizzo_normale .REDIRECT’. Si ottiene una segnalazione di errore in cui si invita a
utilizzare la parte di indirizzo precedente a ‘.REDIRECT’.
• ‘FEATURE(always_add_domain)’
Inserendo questa configurazione, si ottiene di aggiungere il nome di dominio all’utente
destinatario quando questo non viene specificato esplicitamente.
• ‘FEATURE(use_cw_file)’
In questo modo si ottiene di fare accettare a Sendmail l’identificazione del proprio nodo
attraverso uno dei nomi elencati nel file ‘/etc/sendmail.cw’.
1657
• ‘FEATURE(local_procmail)’
Fa in modo di utilizzare ‘procmail’ come sistema di consegna dei messaggi in ambito
locale.
Le macro ‘HACK’ inserite alla fine, sono state aggiunte per permettere una migliore gestione dei
filtri di accesso al servizio di invio dei messaggi, comprendendo in questo anche la definizione
di nodi per i quali il proprio servente SMTP può agire come relè.
Per la precisione, è consentito l’uso dei file descritti nelle sezioni seguenti.
155.3.3.1 /etc/mail/ip_allow
Si tratta di un file di testo contenente un elenco di indirizzi IP (uno per riga) riferiti a nodi
particolari o a intere reti. A questi elaboratori viene consentito di utilizzare il servente SMTP
come relè. Per esempio,
192.168.1.2
192.168.2
permette l’accesso al nodo 192.168.1.2 e a tutta la rete 192.168.2.
Questo file, al di fuori della configurazione particolare della distribuzione Red Hat, potrebbe
chiamarsi ‘/etc/mail/LocalIP’.
155.3.3.2 /etc/mail/name_allow
Si tratta di un file di testo contenente un elenco di nomi di dominio (uno per riga) riferiti a nodi
particolari o a tutti i nodi di un dominio particolare. A questi elaboratori viene consentito di
utilizzare il servente SMTP come relè. Per esempio,
roggen.brot.dg
mehl.dg
permette l’accesso al nodo roggen.brot.dg e a tutto il dominio mehl.dg.
Questo file, al di fuori della configurazione particolare della distribuzione Red Hat, potrebbe
chiamarsi ‘/etc/mail/LocalNames’.
155.3.3.3 /etc/mail/relay_allow
Si tratta di un file di testo contenente un elenco di indirizzi IP o di nomi di dominio (uno per riga)
riferiti a nodi particolari o a tutti i nodi di una rete particolare o di un dominio. Questi indirizzi
sono ammessi come destinatari di messaggi quando il servente SMTP viene utilizzato come relè.
Per esempio,
192.168
roggen.brot.dg
mehl.dg
permette di inviare messaggi alla rete 192.168. . , al nodo roggen.brot.dg e a tutto il
dominio mehl.dg, quando il servente SMTP funziona come relè.
**
Questo file, al di fuori della configurazione particolare della distribuzione GNU/Linux Red Hat,
potrebbe chiamarsi ‘/etc/mail/RelayTo’.
1658
155.3.3.4 /etc/mail/deny
Il file di testo ‘/etc/mail/deny’ viene utilizzato per annotare un elenco di indirizzi di posta
elettronica, nomi di dominio e indirizzi IP di mittenti indesiderati. A fianco di ogni indirizzo,
separato da un carattere di tabulazione (<HT>), si indica il messaggio di errore che si vuole sia
restituito all’MTA che ha contattato il servente per l’inoltro del messaggio.
Segue un esempio molto semplice di questo file.
[email protected]
spam.brot.dg
spammer.dg
192.168.13.13
192.168.17
"Spiacente sig. Spam, non accettiamo messaggi da Lei."
"Dal Vostro host non accettiamo email."
"Non vogliamo spam, grazie."
"Dal Vostro host non accettiamo email."
"Non vogliamo spam, grazie."
Questo file non può essere usato così com’è; occorre generare un file adatto a Sendmail. Si
utilizza in pratica il comando seguente:
# makemap -v hash /etc/mail/deny < /etc/mail/deny
Quello che si ottiene è il file ‘/etc/mail/deny.db’.
Capitolo
156
Exim: introduzione
In questo capitolo si introduce l’utilizzo di Exim, 1 un MTA che offre qualche piccolo vantaggio
rispetto all’uso di Sendmail: è abbastanza compatibile con le consuetudini di questo ultimo;
ha un sistema di configurazione meno criptico; è predisposto per IPv6; quando possibile utilizza
processi senza i privilegi dell’utente ‘root’, in modo da lasciare meno occasioni alle aggressioni.
156.1 Compatibilità con Sendmail e differenze importanti
Exim è compatibile con Sendmail per tutti quegli aspetti che coinvolgono gli utenti comuni e
anche per ciò che riguarda gli amministratori che non hanno o non desiderano avere conoscenze
troppo approfondite sulla gestione della posta elettronica. Questa compatibilità riguarda tre punti
fondamentali: il file ‘/etc/aliases’, i file ‘~/.forward’ e un collegamento che simula la
presenza dell’eseguibile ‘sendmail’. Per di più, l’eseguibile ‘exim’ accetta buona parte delle
opzioni standard di ‘sendmail’, in modo da permettere il funzionamento di programmi come
Mailx, o il funzionamento di script che si affidano alla presenza dell’eseguibile ‘sendmail’.
I file ‘/etc/aliases’ e ‘~/.forward’ si comportano in modo quasi identico rispetto a quando è
in funzione Sendmail. In particolare, con ‘~/.forward’ si possono usare anche delle estensioni.
Un’eccezione, rispetto alla compatibilità di questi file, riguarda l’indicazione di pipeline. Con
Sendmail, si presume che il comando sia elaborato da una shell; con Exim, no. Di conseguenza,
i comandi interni di questa non sono accessibili. Si osservino gli esempi seguenti, riferiti al contenuto del file ‘/etc/aliases’: si tratta della stessa pipeline a cui vengono ridiretti i messaggi
giunti per l’utente ipotetico, denominato ‘lista-pippo’.
# con Sendmail
lista-pippo: "| exec /home/liste/bin/ricezione-messaggi lista-pippo"
# con Sendmail senza exec
lista-pippo: "| /home/liste/bin/ricezione-messaggi lista-pippo"
# con Exim non si può usare exec che è un comando interno di shell
lista-pippo: "| /home/liste/bin/ricezione-messaggi lista-pippo"
# con Exim, avviando prima una shell e quindi il comando
lista-pippo: "| /bin/sh -c ’/home/liste/bin/ricezione-messaggi lista-pippo’"
Se si deve inserire una pipeline in un file ‘~/.forward’, vale lo stesso ragionamento, con la
differenza che qui non si mette più l’indicazione del destinatario perché è implicita (ma questo
vale anche per Sendmail).
Il primo vantaggio che si osserva rispetto a Sendmail è che il file ‘/etc/aliases’ non deve
essere «ricompilato» attraverso ‘newaliases’: basta modificarlo e non occorre nemmeno
riavviare il servizio perché viene riletto ogni volta dal sistema di consegna locale.
Se nel file ‘~/.forward’ si inserisce un indirizzo che crea un circolo senza fine, come per esempio quando si indica lo stesso indirizzo dell’utente per il quale è stato creato il file, i messaggi
vengono consegnati presso quello stesso recapito, invece di ignorarli semplicemente.
1
Exim GNU GPL
1659
1660
Exim: introduzione
I permessi del file ‘~/.forward’ non possono concedere la scrittura al gruppo e al resto degli
utenti. Questo particolare va considerato quando si utilizza una maschera dei permessi pari a
0028 (è così, solitamente, quando si usano i gruppi privati), che tende a concedere la scrittura
al gruppo in modo predefinito.
Come già accennato, Exim fornisce un collegamento denominato ‘sendmail’, per favorire il funzionamento dei programmi che dipendono dalla presenza di questo; inoltre, offre il collegamento
‘mailq’, come fa Sendmail, per permettere la verifica dei messaggi in coda.
156.2 Installazione
L’installazione di Exim può costituire un problema se non si parte da un pacchetto già predisposto
per la propria distribuzione GNU; quindi è decisamente preferibile cercare un tale pacchetto già
pronto. Purtroppo, in certi casi, anche questo non basta: occorre preparare qualcosa prima, forse
è necessario definire la configurazione; infine occorre fare delle sistemazioni finali dopo alcune
prove di verifica.
156.2.1 Utente specifico
Quando possibile, se la configurazione lo consente, Exim cerca di avviare processi con privilegi
inferiori a quelli dell’utente ‘root’. Per esempio, la consegna locale della posta avviene normalmente con un processo che utilizza i privilegi dell’utente destinatario. In tutte le altre circostanze,
si può stabilire un utente e un gruppo che Exim deve utilizzare: nei sistemi che utilizzano i gruppi privati (un gruppo per ogni utente), si potrebbe creare l’utente e il gruppo ‘exim’; negli altri
sistemi, può essere conveniente creare solo l’utente ‘exim’, a cui abbinare il gruppo ‘mail’.
Pertanto, la prima cosa da fare è la creazione di questo utente ed eventualmente del gruppo
corrispondente (se non è già previsto, o se si utilizzano i gruppi privati). Nel file ‘/etc/passwd’
potrebbe apparire una riga come quella seguente, dove il numero GID 12 è inteso corrispondere
a ‘mail’.
exim:*:501:12:Exim mailer:/:
Se si usano i gruppi privati, si potrebbero avere i record seguenti, rispettivamente nei file ‘/etc/
passwd’ e ‘/etc/group’.
exim:*:501:501:Exim mailer:/:
exim:x:501:
In ogni caso, come si è visto, è importante che l’accesso sia impossibile, cosa che si ottiene con
l’asterisco nel campo della parola d’ordine.
156.2.2 /etc/aliases
Dopo l’installazione di Exim, si può fare in modo di recuperare il vecchio ‘/etc/aliases’,
se c’era, oppure se ne deve creare uno nuovo. Per il momento, fino a che non è stata vista la
configurazione di Exim, è meglio lasciare stare gli alias che si traducono in file o in pipeline.
Exim può essere configurato per utilizzare un file diverso da ‘/etc/aliases’ con questo stesso
scopo, ma in generale dovrebbe essere conveniente mantenere la vecchia convenzione. In ogni
caso, Exim ha bisogno della definizione di alcuni alias indispensabili: in generale, Exim non
permette la consegna di messaggi direttamente all’utente ‘root’, quindi è necessario definire chi
Exim: introduzione
1661
sia l’utente corrispondente che deve ricevere la posta diretta a ‘root’. Di seguito viene mostrato
un esempio che dovrebbe andare bene in molte piattaforme GNU: l’alias di ‘root’ deve essere
modificato opportunamente.
# Obbligatori
MAILER-DAEMON:
abuse:
postmaster:
postmaster
postmaster
root
# Ridirezione per evitare trucchi con gli utenti speciali di sistema.
bin:
root
daemon:
root
adm:
root
lp:
root
sync:
root
shutdown:
root
halt:
root
mail:
root
news:
root
uucp:
root
operator:
root
games:
root
gopher:
root
ftp:
root
nobody:
root
postgres:
root
exim:
root
# Chi è root (modificare in base alla realtà del proprio sistema)
#root:
daniele
156.2.3 ~/.forward
Anche la gestione dei file ‘~/.forward’ può essere controllata (e stravolta) attraverso la configurazione di Exim; tuttavia, se si desidera mantenere le consuetudini, si possono recuperare
questi file che gli utenti potrebbero avere già utilizzato con Sendmail. Valgono naturalmente le
stesse riserve già espresse in riferimento a destinatari costituiti da file o da pipeline.
In ogni caso, perché tali file ‘~/.forward’ possano essere accettati da Exim, occorre che siano
assenti i permessi di scrittura per il gruppo e per gli altri utenti. Utilizzando la shell Bash, si
potrebbe usare un comando come quello seguente:
# find /home -name .forward -exec chmod go-w \{\} \;
156.2.4 Directory di destinazione dei messaggi locali
Sendmail utilizza una directory comune a tutti gli utenti per inserirvi i file contenenti i messaggi
di questi, quando giungono a destinazione. In passato si è trattato di ‘/var/spool/mail/’ e
attualmente dovrebbe essere ‘/var/mail/’, per conformità con lo standard FHS (capitolo 72).
Exim può funzionare nello stesso modo, oppure può consegnare i messaggi direttamente nelle
directory personali degli utenti. In generale, qualunque sia la scelta, è necessario che la variabile
di ambiente ‘MAIL’ contenga il percorso assoluto per raggiungere il file di destinazione, in modo
che i programmi di lettura della posta vi si possano adeguare. Questo lo si fa normalmente nella
definizione del profilo della shell personale.
Per esempio, se si utilizza la shell Bash, il file ‘/etc/profile’ potrebbe contenere le righe
seguenti per indicare che i file dei messaggi si trovano nella directory ‘/var/mail/’.
1662
Exim: introduzione
MAIL="/var/mail/$USER"
export MAIL
Nel caso la posta venisse consegnata nel file ‘~/Messaggi’ della directory personale di ogni
utente, l’istruzione per definire la variabile ‘MAIL’ potrebbe essere la seguente:
MAIL="$HOME/Messaggi"
export MAIL
Infine, si deve tenere presente che Exim utilizza i privilegi dell’utente destinatario per aprire i
file di destinazione, per cui i premessi della directory devono essere regolati convenientemente.
Il problema si pone quando si usa la directory ‘/var/mail/’, o un’altra simile, per tutti i file
di destinazione: è necessario che sia attribuita a questa directory la modalità 17778. Infatti, l’attivazione del bit Sticky, permette il blocco dei file (lock). Se non si ha l’accortezza di sistemare
questo particolare, la posta elettronica non può essere consegnata.
# chmod 1777 /var/mail
La configurazione di Exim è più semplice di Sendmail, ma resta comunque una cosa piuttosto
delicata, dati i problemi che sono coinvolti nella gestione della posta elettronica. Alla fine di
questo gruppo di sezioni viene mostrato un esempio completo di configurazione che dovrebbe
funzionare correttamente nella maggior parte delle situazioni.
La documentazione di Exim è voluminosa e abbastanza dettagliata. Questo è un fatto positivo;
purtroppo occorre dedicarvi un po’ di tempo per la sua lettura. Se si desidera utilizzare Exim a
livello professionale, ciò diventa necessario.
Il file di configurazione di Exim, volendo seguire lo standard dei sistemi GNU (e non solo di
quelli), dovrebbe trovarsi nella directory ‘/etc/’. In pratica però, potrebbe non essere così. Una
volta installato il pacchetto di Exim, occorre cercare il file di configurazione.
Il file di configurazione deve appartenere all’utente ‘root’, oppure all’utente specificato in
fase di compilazione dei sorgenti di Exim, attraverso l’opzione ‘EXIM_UID’; inoltre non può
essere accessibile in scrittura dal gruppo né dagli altri utenti.
Quando si avvia Exim, se il file di configurazione contiene errori sintattici, viene emesso un
messaggio di errore attraverso lo standard error, specificando anche la riga in cui questo si trova.
Dopo tale segnalazione, Exim termina di funzionare, per cui il servizio non viene avviato.
156.3.1 Struttura
Il file di configurazione si divide in sei parti che devono apparire nell’ordine previsto. Ognuna di
queste termina con la parola chiave ‘end’, posta da sola in una riga. Le varie parti sono elencate
di seguito.
1. Configurazione principale. Si tratta di direttive in cui si assegnano dei valori a delle opzioni
di funzionamento.
2. Configurazione dei driver di trasporto. Si tratta della definizione dei meccanismi attraverso cui i messaggi vengono recapitati alla destinazione, copiandoli all’interno dei file, o
inserendoli nelle pipeline.
Exim: introduzione
1663
3. Configurazione dei driver di direzione (director). Si tratta dei processi di consegna all’interno dei domini locali, cosa che include la gestione degli alias e del proseguimento dei
messaggi (forward).
4. Configurazione dei driver di instradamento. Si tratta dei processi di consegna a destinazioni
remote, ovvero, quelle destinazioni che non sono classificate come appartenenti ai domini
locali.
5. Configurazione delle regole per i tentativi ripetuti (retry).
6. Configurazione delle regole di riscrittura. Si tratta della definizione di modifiche
sistematiche a elementi dell’intestazione dei messaggi.
In ogni parte della configurazione possono apparire dei commenti; questi sono introdotti dal simbolo ‘#’ all’inizio della riga e conclusi dalla fine della riga stessa. Non sono ammessi commenti
alla fine delle direttive; in pratica, i commenti possono apparire solo su righe apposite. Inoltre, le
righe bianche e quelle vuote vengono ignorate come di consueto.
156.3.2 Elementi comuni
Prima di affrontare la descrizione di alcune direttive importanti che possono essere usate nel
file di configurazione, conviene conoscere alcune convenzioni comuni, o direttive particolari che
coinvolgono tutto l’insieme della configurazione.
156.3.2.1 Macro
All’interno della prima parte del file di configurazione, quella che riguarda le definizioni generali, è possibile inserire delle direttive che dichiarano delle macro. Queste si distinguono perché
devono avere l’iniziale maiuscola. In generale, per convenzione comune derivante da altri linguaggi di programmazione, le macro si dichiarano con nomi composti esclusivamente da lettere
maiuscole.
nome = valore_da_sostituire
Il nome può essere composto da lettere, numeri e dal trattino basso (‘_’); inoltre, come accennato,
la prima lettera deve essere maiuscola. Il valore che si abbina a questo nome, è tutto ciò che appare
dopo il simbolo ‘=’, escludendo eventuali spazi iniziali, fino alla fine della riga.
156.3.2.2 Assegnamento
In molti punti del file di configurazione si usano delle direttive che rappresentano in pratica
l’assegnamento di un valore a una sorta di variabile. La sintassi è semplice e intuitiva.
nome = valore
La differenza rispetto alla dichiarazione di macro sta nel fatto che i nomi utilizzati in questo caso
sono prestabiliti e non iniziano mai con una lettera maiuscola.
156.3.2.3 Valori booleani
Quando una variabile è fatta per definire l’attivazione o la disattivazione di qualcosa, può ricevere
solo i valori Vero o Falso, espressi attraverso le solite parole chiave: ‘true’ o ‘yes’ rappresenta
il valore Vero; ‘false’ o ‘no’ rappresenta il valore Falso.
1664
Exim: introduzione
In particolare, in presenza di variabili di questo tipo, è possibile fare a meno di indicare espressamente l’assegnamento, lasciando intuire il valore predefinito derivante dal nome della variabile. In generale, comunque, sarebbe bene esplicitare l’intenzione, se si vogliono utilizzare tali
variabili.
156.3.2.4 Interi
I numeri interi possono essere annotati utilizzando diverse basi di numerazione:
• un numero che inizia con il prefisso 0x... viene inteso essere espresso in base esadecimale;
• un numero che inizia con uno zero viene inteso essere espresso in base ottale;
• un numero che inizia con una cifra diversa da zero viene inteso essere espresso in base
decimale.
Tali numeri interi possono essere seguiti dalla lettera ‘K’ (maiuscola) o dalla lettera ‘M’, intendendo esprimere un multiplo di 1024, o di 1024*1024 rispettivamente (kibi e mebi delle convenzioni
che si usano in informatica).
156.3.2.5 Numeri con parte decimale
Un numero contenente una parte decimale può essere espresso solo utilizzando la numerazione a
base 10 (base decimale), indicando le cifre della parte frazionaria dopo un punto. Sono consentite
un massimo di tre cifre decimali dopo la parte intera.
156.3.2.6 Intervalli orari
Le indicazioni di valori riferiti a intervalli orari (periodi di tempo), fanno uso di una serie di
suffissi che descrivono il significato del numero che li precede.
• ‘s’ secondi;
• ‘m’ minuti;
• ‘h’ ore;
• ‘d’ giorni;
• ‘w’ settimane.
Per esempio, il valore ‘3h45m’ rappresenta 3 ore e 45 minuti. Questo formato di rappresentazione
viene usato anche nell’output.
156.3.2.7 Stringhe
Le stringhe possono essere rappresentate con o senza apici doppi di delimitazione. L’utilizzo o
meno di tale delimitazione ha delle conseguenze diverse.
Le stringhe non delimitate sono rappresentate da tutto ciò che appare dopo il simbolo ‘=’ utilizzato nell’assegnamento, letteralmente, escludendo eventuali spazi iniziali, continuando fino alla
fine della riga. Ciò significa in pratica che una stringa di questo tipo non può continuare nella
riga successiva.
Exim: introduzione
1665
Si utilizzano le stringhe delimitate tutte le volte in cui occorre rappresentare qualcosa di particolare, come dei caratteri speciali, attraverso il prefisso ‘\’ che assume il ruolo di carattere di
escape, oppure quando è necessario continuare la stringa nella riga successiva.
La tabella 156.1 mostra l’uso di queste sequenze di escape ottenute con la barra obliqua inversa.
Tabella 156.1. Elenco delle sequenze di escape utilizzabili all’interno delle stringhe
delimitate da apici doppi.
Simbolo
\\
\n
\r
\t
\n_ottale
\xn_esadecimale
Significato
Rappresenta una barra obliqua inversa singola.
Il carattere <NL>.
Il carattere <CR>.
Una tabulazione orizzontale (<HT>).
Identifica un carattere attraverso il suo numero ottale.
Identifica un carattere attraverso il suo numero esadecimale.
Inoltre, una barra obliqua inversa posta alla fine della riga, subito prima del codice di interruzione
di riga, rappresenta la continuazione della stringa nella riga successiva, eliminando gli spazi
iniziali aggiunti nella riga successiva.
Se si utilizza una barra obliqua inversa davanti a un carattere con il quale non forma alcuna
sequenza di escape prevista, si conferma semplicemente il carattere successivo alla barra. Dal
momento che all’interno delle stringhe possono essere usati altri simboli con significati speciali,
si può usare la barra obliqua inversa per dare loro un significato puramente letterale.
156.3.2.8 Elenchi di stringhe
In situazioni determinate si può indicare un elenco di stringhe. La rappresentazione di tali elenchi
avviene di fatto in una sola stringa, i cui elementi sono separati attraverso due punti verticali (‘:’).
Per esempio, ‘uno:due:tre’ è un elenco composto dalle sottostringhe ‘uno’, ‘due’ e ‘tre’. È
importante sapere subito che attorno ai due punti verticali, possono essere inseriti degli spazi, che
poi vengono eliminati dalle sottostringhe; quindi, tornando all’esempio già presentato, sarebbe
stata esattamente la stessa cosa scrivere ‘uno: due :tre’
A seconda delle esigenze, tali elenchi possono essere racchiusi globalmente attraverso gli apici
doppi delle stringhe normali, oppure possono farne senza, con le stesse considerazioni già fatte
su questo argomento.
Da quanto descritto, si intende che i due punti verticali abbiano un significato speciale, per cui
non possono essere usati per altri scopi, a meno che questi appaiano in coppia (‘::’), perché in
tal caso rappresentano esattamente due punti verticali testuali.
Gli elenchi di stringhe vengono usati per rappresentare vari tipi di informazioni, per i quali si distinguono una serie di particolari che possono essere molto utili per una configurazione efficace di
Exim. Qui viene trascurata la descrizione di queste indicazioni, che possono essere approfondite
leggendo la documentazione originale.
156.3.2.9 Espansione delle stringhe
All’interno delle stringhe possono essere inseriti degli elementi che vengono sostituiti in qualche
modo, in base a ciò che questi rappresentano. Per identificare tali elementi si utilizza il simbolo
dollaro (‘$’) seguito da un nome, che eventualmente può anche essere racchiuso tra parentesi
graffe, in caso si temano delle ambiguità.
$nome_di_variabile
| ${nome_di_variabile }
1666
Exim: introduzione
Esistono poi una serie di operazioni che possono essere compiute attraverso l’operatore di
sostituzione (il dollaro), che qui non vengono descritte.
Nel caso si debba inserire il simbolo ‘$’ in una stringa con un significato letterale, occorre
indicare ‘\$’ se si tratta di una stringa non delimitata, oppure ‘\\$’ se si tratta di una stringa
delimitata (incoerente, ma è così).
156.3.2.10 Espressioni regolari
In alcune situazioni, le stringhe possono servire a esprimere delle espressioni regolari. Tali
espressioni regolari si distinguono per il fatto che iniziano con l’accento circonflesso (‘^’) e
possono terminare o meno con il simbolo dollaro, che in tal caso rappresenta la fine della stringa
con cui avviene il confronto.
Le regole per la realizzazione di tali espressioni regolari sono simili a quelle di Perl 5, facendo
attenzione però alle barre oblique inverse, che se si trovano racchiuse tra apici doppi, devono
essere raddoppiate.
156.3.3 Configurazione principale
La prima parte del file di configurazione, fino al primo ‘end’, riguarda la definizione delle opzioni
principali. Come è già stato accennato, è in questa parte che possono essere create delle macro; la
loro definizione si distingue in quanto i nomi di queste devono iniziare con una lettera maiuscola.
Questa parte della configurazione è la più semplice, perché richiede solo l’assegnamento di qualche valore a delle variabili prestabilite. L’elenco di tali variabili è molto lungo, ma in ogni caso,
è sufficiente definire gli assegnamenti riferiti alle opzioni che si vogliono modificare rispetto a
quanto risulta predefinito.
Directory
exim_path = percorso_assoluto_di_exim
host_lookup = indirizzo_ip /n_bit_maschera
Descrizione
Permette di specificare il percorso assoluto dell’eseguibile ‘exim’. Questa
informazione serve quando la collocazione del programma non corrisponde all’informazione indicata in fase di
compilazione. La conoscenza di tale
percorso serve a Exim quando deve
avviare una copia di se stesso.
Permette di definire un gruppo di indirizzi per i quali verificare sempre il
nome attraverso il DNS. Generalmente, viene assegnato ‘*’ che rappresenta
ogni indirizzo possibile.
Exim: introduzione
1667
Directory
[
local_domains = nome_locale :nome_locale
]...
{true|false}
local_domains_include_host =
log_level = n_livello
message_size_limit = dimensione
[
never_users = utente :utente
]...
primary_hostname = nome_canonico
relay_domains = nome_di_dominio
[:nome_di_dominio ]...
Descrizione
Permette di definire i nomi di dominio
completo che fanno capo al sistema
locale, per i quali la posta elettronica
viene consegnata localmente, senza
attivare una connessione SMTP. In
pratica, consente di definire anche i
domini virtuali che fanno capo allo
stesso nodo locale.
Come si vede dalla sintassi, si tratta
di un elenco di stringhe, separato
attraverso due punti verticali.
Dovrebbe essere conveniente indicare
sempre almeno i domini localhost
e
localhost.localdomain,
nell’ipotesi che qualcuno usi indirizzi
del tipo tizio@localhost, per
quanto ciò possa sembrare strano
assurdo.
Attivando questa opzione (‘true’), si
fa in modo che il nome del nodo locale
ottenuto dal sistema operativo, venga
incluso automaticamente nell’elenco
di domini locali (‘local_domains’).
Permette di definire il livello di dettaglio per le informazioni memorizzate
nei file delle registrazioni. Il valore zero corrisponde al minimo; valori superiori aumentano le informazioni (sei
dovrebbe essere il valore che genera la massima quantità di notizie). Se
questa opzione non viene dichiarata, il
livello predefinito è cinque.
Permette di fissare un tetto massimo alla dimensione dei messaggi in
transito. Qui si usano normalmente i
moltiplicatori ‘K’ o ‘M’.
Permette di escludere il recapito di
messaggi a utenti determinati, a meno
che sia stato specificato un alias adatto
nel file ‘/etc/aliases’. In pratica,
serve per indicare l’elenco degli utenti di sistema, a cominciare da ‘root’,
che non possono o non dovrebbero
ricevere posta.
Permette di definire esplicitamente il
nome canonico primario del nodo locale. Se non viene specificata questa opzione, tale nome viene ottenuto dal sistema operativo, attraverso la
funzione ‘uname()’.
Permette di elencare i domini per
i quali si consente al servente di
funzionare come relè.
Exim: introduzione
1668
Directory
relay_domains_include_local_mx =
[
{true|false}
]...
host_accept_relay = host :host
spool_directory = directory
[
trusted_users = utente_fidato :utente_fidato
]...
[
trusted_groups = gruppo_fidato :gruppo_fidato
]...
Descrizione
Attivando l’opzione, si fa in modo di
consentire la funzionalità di relè verso i domini che, secondo il DNS, dovrebbero essere serviti dal nodo locale. In pratica, si fa in modo di seguire la configurazione definita attraverso il DNS, con i record ‘MX’, con cui
si stabilisce che tale servente SMTP
si deve occupare della consegna presso quei domini, accettando messaggi provenienti da qualunque dominio
esterno.
Permette di definire a quali nodi è
consentito usare il servente locale in
qualità di relè.
Definisce il percorso della directory usata come coda dei messaggi da
Exim. Generalmente potrebbe trattarsi di ‘/var/spool/exim/’, che poi
si articola ulteriormente.
Definisce quali processi possono passare messaggi a Exim, specificando il
mittente attraverso l’opzione ‘-f’ della riga di comando. Tali processi sono
accettati in quanto avviati con i privilegi dell’utente o del gruppo indicati. Se non viene specificata alcuna di
queste due opzioni, ciò può essere fatto solo da un processo con i privilegi
Solitamente si definisce in questo
modo l’utente ‘exim’ (senza indicare alcun gruppo); potrebbe essere conveniente aggiungere altri utenti nel caso si vogliano gestire delle
liste (mailing-list) con caratteristiche
particolari.
156.3.4 Configurazione dei driver
La seconda, la terza e la quarta parte del file di configurazione sono dedicate alla definizione
delle istanze dei driver di trasporto, di direzione (director) e di instradamento.
In queste parti, le direttive del file di configurazione sono suddivise a gruppetti, ognuno riferito
alla definizione di un’istanza particolare. In pratica, appare la dichiarazione del nome dell’istanza
che termina con due punti verticali, seguita da una riga contenente la dichiarazione del driver di
riferimento, oltre a una serie di altre righe opzionali contenenti le impostazioni che gli si devono
applicare (quando quelle predefinite non vanno bene).
nome_di_istanza_del_driver :
driver = nome_del_driver
direttiva_di_opzione
direttiva_di_opzione
[
[
]
]
...
Le opzioni che possono essere indicate, si distinguono in generiche e private. Le opzioni generiche possono essere utilizzate con tutti i driver di uno stesso tipo (trasporto, direzione, instrada-
Exim: introduzione
1669
mento), mentre quelle private si riferiscono solo a driver particolari. La direttiva che definisce il
driver è un’opzione generica, che deve essere posta all’inizio, come mostra lo schema sintattico.
In passato, nelle prime versioni di Exim, era necessario separare le opzioni con una virgola,
mettendo prima le opzioni generiche e dopo quelle specifiche; inoltre, il passaggio da opzioni
generiche a opzioni specifiche doveva essere segnalato con un punto e virgola. Attualmente,
queste restrizioni non esistono più e non è richiesta l’indicazione di virgole o punti e virgola.
Tuttavia, l’informazione viene riportata a spiegazione del motivo per il quale diversi esempi di
configurazione in circolazione hanno ancora queste virgole e questi punti e virgola, qua e là,
senza un motivo apparente.
A titolo di esempio vengono mostrate e descritte un paio di dichiarazioni significative, che
appaiono anche nell’esempio completo mostrato più avanti.
local_delivery:
driver = appendfile
file = /var/mail/${local_part}
Nella configurazione del trasporto, definisce l’istanza ‘local_delivery’ del driver
‘appendfile’. Dal nome si intende che si tratta del trasporto che si deve occupare di consegnare
localmente la posta elettronica.
Attraverso il driver ‘appendfile’ si ottiene di aggiungere i messaggi a un file già esistente, specificato attraverso l’opzione ‘file’: in questo caso si tratta di ‘/var/mail/${local_part}’,
che in pratica si espande in un file denominato come l’utente che deve riceverlo, collocato nella
directory ‘/var/mail/’.2
localuser:
driver = localuser
transport = local_delivery
Questo esempio fa riferimento alla configurazione del sistema di direzione; il nome dell’istanza è lo stesso di quello del driver, ma si tratta di cose differenti. Si può osservare la dichiarazione del trasporto utilizzato: ‘local_delivery’, cioè il tipo di trasporto (l’istanza) già vista
nell’esempio precedente.
156.3.5 Configurazione dei tentativi ripetuti
La penultima parte del file di configurazione, serve a definire il modo in cui scandire la ripetizione
dei tentativi di invio (o di consegna) della posta. Ciò permette di distinguere il comportamento
in base al dominio di destinazione e al tipo di errore che ha impedito la consegna del messaggio.
Generalmente si trova già un esempio generico sufficiente.
Gli intervalli con cui vengono ripetuti i tentativi, devono tenere conto della frequenza con cui
viene riavviato il processo di scansione della coda. Per esempio, se viene avviato ‘exim’ con
l’opzione ‘-q30m’, che, come verrà descritto, richiede il controllo della coda ogni 30 minuti, è
poco sensato specificare nella configurazione intervalli inferiori, perché non potrebbero essere
rispettati.
2
La directory in questione deve avere i permessi 17778, altrimenti non può funzionare il sistema di blocco dei file
(lock) e in pratica i messaggi non vengono recapitati.
Exim: introduzione
1670
156.3.6 Configurazione della riscrittura degli indirizzi
L’ultima parte della configurazione è generalmente assente, o senza direttive. Serve a definire
delle regole di alterazione sistematica degli indirizzi.
Per comprendere il problema viene descritto un caso pratico che potrebbe interessare. Quando
si passa da Sendmail a Exim, potrebbe sentirsi la necessità di fare in modo che gli indirizzi
nome +qualcosa @dominio , vengano consegnati a nome @dominio . Alcuni utenti potrebbero
utilizzare questo trucco (comune per Sendmail) per distinguere la fonte da cui lo scrivente può
avere tratto il loro indirizzo e avere implicitamente un’idea del contesto per il quale viene inviato
ogni messaggio.
Exim ha dei meccanismi più potenti, ma quando si passa da Sendmail a Exim, gli utenti potrebbero desiderare di mantenere le vecchie convenzioni. La direttiva seguente dovrebbe risolvere il
problema.
^(..*?)\+(.*)@(..*)$ $1@$3 T
Come si vede, attraverso un’espressione regolare vengono estratti gli elementi che contano
dall’indirizzo, che poi viene ricostruito senza la parte superflua che ne impedirebbe il recapito.
Un esempio più semplice di questo problema è quello di una rete locale che utilizza nomi di
dominio inesistenti nella rete esterna, pertanto si vuole sostituire l’indicazione dei domini locali
con un dominio che esiste realmente:
*@brot.dg
*@localhost
*@localhost.localdomain
[email protected] E
[email protected] E
[email protected] E
In questo modo, tutti i campi della busta del messaggio che corrispondono ai modelli indicati,
vengono rimpiazzati con un indirizzo del dominio linuxdidattica.org.
156.3.7 Configurazione generica
Le versioni più recenti di Exim vengono distribuite normalmente con una configurazione generica, ben commentata, sufficiente al recapito locale dei messaggi, senza la possibilità di ricevere
messaggi dall’esterno o di inviarne dall’interno.
L’attenzione maggiore va posta naturalmente a tutte quelle direttive che incorporano la parola
chiave ‘relay’, come ‘relay_domains’ per esempio; inoltre diventa indispensabile verificare
che la posta locale sia recapitata esattamente dove previsto, con la direttiva ‘local_delivery’.
156.4 Avvio di Exim
L’avvio di Exim, allo scopo di attivare il servizio SMTP, avviene di solito attraverso la procedura
di inizializzazione del sistema, come processo indipendente dal supervisore dei servizi di rete,
anche se questa ultima possibilità è comunque consentita. Ma Exim può essere avviato anche
per altri motivi, in particolare per ricevere un messaggio dallo standard input, da recapitare in
qualche modo, oppure per ripassare i messaggi rimasti in coda, per ritentare il loro invio.
A seconda dello scopo per il quale viene avviato l’eseguibile ‘exim’, possono essere richiesti dei
privilegi particolari. Per la precisione, si distingue tra utenti comuni e amministratori. L’amministratore è l’utente ‘root’, l’utente abbinato a Exim (normalmente ‘exim’) e gli utenti definiti
attraverso l’opzione ‘trusted_users’.
Uno dei motivi per cui può essere più conveniente avviare il servizio SMTP di Exim, in modo
indipendente dal supervisore dei servizi di rete, è il fatto di poter affidare al demone Exim, così
Exim: introduzione
1671
avviato, anche il compito di provvedere alla gestione dei messaggi in coda in modo automatico.
Se si utilizza il controllo del supervisore dei servizi di rete, occorre affidare il lavoro di gestione
della coda a un altro processo.
Quando si usa Exim come demone, cioè in modo autonomo dal supervisore dei servizi di rete,
si usa l’opzione ‘-bd’, seguita quasi sempre da ‘-qtempo ’, che serve a specificare l’intervallo di
scansione della coda di messaggi in attesa.
Se si vuole gestire il servizio SMTP attraverso il controllo del supervisore dei servizi di rete,
occorre specificare l’opzione ‘-bs’ e si deve dichiarare una riga simile a quella seguente nel file
‘/etc/inetd.conf’.
smtp
stream
tcp
nowait
root
/usr/sbin/exim
exim -bs
La riga di comando dell’eseguibile ‘exim’ si può rappresentare sinteticamente così:
exim
[opzioni]
Di seguito vengono elencate solo alcune opzioni assolutamente indispensabili, che servono a
rendere l’idea delle funzioni di questo eseguibile.
Directory
-bd
-bs
-bp
-bt
[
[indirizzo]
]
-d n_livello
-dm
Descrizione
Avvia ‘exim’ come demone in attesa di connessioni SMTP.
‘exim’ può essere avviato in questo modo solo da un amministratore; comunque ciò avviene di solito per mezzo della procedura di inizializzazione del sistema. Quando ‘exim’ viene
avviato con questa opzione, ma in modo manuale, può essere
conveniente aggiungere l’uso delle opzioni diagnostiche ‘-d’
o ‘-dm’.
Avvia ‘exim’ in modo che questo si metta in attesa di ricevere
messaggi dallo standard input, rispondendo poi a questi attraverso lo standard output. Questa opzione viene usata normalmente per gestire l’avvio di ‘exim’ attraverso il supervisore
dei servizi di rete.
Questa opzione permette di visualizzare l’elenco dei messaggi
rimasti in coda per qualche motivo. Il funzionamento non è
perfettamente identico a Sendmail, in quanto solo un utente
con i privilegi necessari può ottenere queste informazioni.
Avvia ‘exim’ in una modalità di verifica degli indirizzi. Se
viene indicato un indirizzo come argomento dell’opzione, si
ottengono le informazioni essenziali sulla consegna verso tale destinazione. Ciò permette di verificare la correttezza della
configurazione, dal momento che si ottiene anche l’indicazione del tipo di direzione e di trasporto utilizzati.
Se non viene specificato l’indirizzo nella riga di comando,
‘exim’ funziona in modo interattivo, proponendo un invito (il
simbolo ‘>’) per l’inserimento di ogni indirizzo da verificare
(per terminare si può utilizzare la combinazione [ Ctrl+c ]).
Permette di avviare ‘exim’ in modo diagnostico, allo scopo di
visualizzare informazioni attraverso lo standard error. Dopo la
lettera dell’opzione, può essere aggiunto un numero che serve
a rappresentare l’entità di informazioni desiderate: uno rappresenta un livello minimo, che viene utilizzato se non si specifica alcun numero, mentre un valore più grande rappresenta
più informazioni.
Permette di ottenere informazioni diagnostiche riferite
all’allocazione e alla deallocazione di memoria.
1672
Directory
-q
-qtempo
-v
Exim: introduzione
Descrizione
L’opzione ‘-q’ può avere un argomento, ma se usata da sola,
fa in modo che ‘exim’ esegua una scansione (una soltanto)
dei messaggi in coda, tentando di consegnare ogni messaggio trovato al suo interno. La scansione non segue un ordine
preciso e alla sua conclusione ‘exim’ termina di funzionare.
Questa opzione può essere usata solo da un amministratore.
L’opzione ‘-q’, seguita dall’indicazione di una durata temporale, fa in modo che ‘exim’ esegua una scansione della coda in
modo ripetitivo, a intervalli della durata specificata dall’argomento. In questo modo, ‘exim’ deve continuare a funzionare
a tempo indeterminato.
Questa opzione, con argomento, viene usata preferibilmente
per l’avvio di ‘exim’ come demone, in modo tale che possa
prendersi cura sia del servizio SMTP che della verifica della
coda.
L’intervallo specificato in questo modo, determina in pratica
il tempo minimo che può essere indicato nella configurazione
dei tentativi ripetuti.
È sinonimo di ‘-d1’ (diagnosi di livello minimo).
Come accade spesso nei sistemi Unix, l’eseguibile ‘exim’ può essere avviato utilizzando nomi
diversi che definiscono implicitamente l’uso di opzioni determinate, che potrebbero essere difficili da ricordare. Non sempre i pacchetti di Exim includono tutti i collegamenti che potrebbero
essere utili. Vale quindi la pena di riassumere quelli più comuni, che potrebbero essere realizzati
utilmente se mancano nel proprio pacchetto.
Directory
‘/usr/lib/sendmail’,
‘/usr/sbin/sendmail’
‘/usr/bin/mailq’
‘/usr/bin/runq’
Descrizione
Questi due collegamenti sono praticamente indispensabili se
si vogliono utilizzare gli MUA comuni, cioè i programmi come Mailx (‘mail’), che per l’invio dei messaggi si avvalgono proprio dell’eseguibile ‘sendmail’. Exim riconosce molte
delle opzioni di Sendmail e in tal modo è possibile usare tali
collegamenti.
Secondo la logica dei sistemi GNU, l’eseguibile ‘sendmail’
dovrebbe trovarsi esclusivamente nella directory ‘/usr/
sbin/’, ma per rispettare la tradizione è meglio aggiungere anche l’altro (‘/usr/lib/sendmail’) perché si vedono
ancora script che fanno affidamento su questo.
Quando ‘exim’ viene avviato con il nome ‘mailq’, permette
di conoscere lo stato della coda, come se fosse stato avviato
con l’opzione ‘-bp’.
Quando ‘exim’ viene avviato con il nome ‘runq’, fa in modo
che ‘exim’ esegua una singola scansione della coda, cercando
di inviare i messaggi rimasti in attesa. Ciò, in pratica, come se
fosse stato avviato con l’opzione ‘-q’.
Exim: introduzione
1673
156.5 Code e registri
Molto probabilmente (dipende da come è stato configurato in fase di compilazione), la directory ‘/var/spool/exim/’ si articola in varie sottodirectory destinate a contenere informazioni
variabili di vario tipo, tra cui le code dei messaggi e i file delle registrazioni.
La directory ‘input/’ contiene precisamente i file delle code. Per ogni singolo messaggio che
venga messo in attesa, si formano almeno due file: uno che termina con la sigla ‘-D’ (data),
che contiene il corpo del messaggio, e uno che termina con la sigla ‘-H’ (head), che contiene le
altre informazioni. Se un messaggio è diretto a diversi destinatari, la sua consegna può richiedere
molto tempo e l’annotazione delle destinazioni presso cui è stato recapitato con successo. In tal
caso viene creato un terzo file, che termina con la sigla ‘-J’ (journal), all’interno del quale si
annotano gli indirizzi già raggiunti.
Se un messaggio finisce in coda, ci deve essere un motivo. Nella directory ‘msglog/’ vengono
annotati file con gli stessi nomi utilizzati per i dati in coda, senza sigle finali, contenenti l’elenco
degli insuccessi accumulati durante i vari tentativi ripetuti.
Se si decide di intervenire in modo brutale nei file delle code, cancellandoli, ci si deve ricordare
di eliminare anche i file corrispondenti della directory ‘msglog/’.
Naturalmente sono disponibili anche dei file di registrazioni veri e propri, che potrebbero trovarsi
in ‘/var/spool/exim/log/’, oppure, più convenientemente, in ‘/var/log/exim/’. Si tratta
di tre file: ‘mainlog’, ‘rejectlog’, ‘processlog’ e ‘paniclog’. Il significato di questi nomi
dovrebbe essere intuitivo: ‘mainlog’ è l’archivio principale delle operazioni compiute, in cui
si segnalano l’arrivo e la consegna di ogni messaggio; ‘rejectlog’ registra le informazioni sui
messaggi il cui transito è rifiutato in funzione della configurazione; ‘processlog’ serve a segnalare l’effetto della ricezione di alcuni segnali (come ‘SIGHUP’ e ‘SIGUSR1’); infine, ‘paniclog’
permette di annotare le situazioni di errore che Exim non riesce a gestire.
Attraverso l’opzione ‘log_level’ del file di configurazione, è possibile definire il livello
di dettaglio delle informazioni che appaiono nel file delle registrazioni. Il valore predefinito
corrisponde comunque a un buon livello di dettaglio.
Con l’opzione ‘preserve_message_logs’, attivandola, è possibile evitare la cancellazione dei
file delle registrazioni collocati nella directory ‘msglog/’. Ciò può essere utile solo nel caso in
cui si volesse fare un controllo approfondito degli errori che si verificano durante i vari tentativi
di consegna.
156.5.1 Archiviazione dei file delle registrazioni
Le distribuzioni GNU dovrebbero essere organizzate per gestire in modo elegante l’archiviazione
dei file delle registrazioni, spezzando i file in parti che contengono periodi relativamente brevi,
solitamente distinte attraverso un’estensione numerica progressiva che indica l’età relativa del
file.
Exim fornisce un proprio script per svolgere questo compito, ‘exicyclog’, che può essere usato
quando la propria distribuzione GNU non dovesse già provvedere per conto proprio.
Per avviarlo, si potrebbe mettere un’istruzione come quella seguente nel file ‘/etc/crontab’
(ammesso che lo script si trovi nella directory ‘/usr/sbin/’).
01 0 * * * root /usr/sbin/exicyclog
Capitolo
157
sSMTP
sSMTP 1 è un sistema molto semplice per l’invio della posta elettronica a un servente SMTP.
Lo scopo di questo programma è quello di sostituire l’MTA tipico, quando non è necessaria
la gestione della consegna locale (MDA) e si può fare affidamento continuamente su un MTA
esterno, contattato attraverso il protocollo SMTP.
Figura 157.1. Esempio di una situazione in cui viene utilizzato sSMTP.
.----------------.
.----------------.
|
|
|
|
| dinkel.brot.dg |
| weizen.mehl.dg |
|
|. . . . . . . . . . . . . . . . . . . . . .|
|
|
sSMTP
|
| servente SMTP |
|
|
| standard
|
‘----------------’
‘----------------’
Utente
Utente
Utente
Utente
root -->
Tizio:
Caio:
Sempronio:
tizio
tizio
<[email protected]>
caio
<[email protected]>
semproni <[email protected]>
Per comprendere il funzionamento di sSMTP è necessario partire da un esempio, come si vede
nella figura 157.1. Nell’elaboratore dinkel.brot.dg è stato installato sSMTP; l’elaboratore
weizen.mehl.dg offre un servente SMTP a cui dinkel.brot.dg può accedere. Nell’elaboratore dinkel.brot.dg sono registrati tre utenti: Tizio, Caio e Sempronio, ognuno dei
quali riceve la propria posta elettronica presso una casella remota (come indicato nella figura
stessa); inoltre, è Tizio che svolge anche il ruolo di amministratore.
sSMTP non è un demone e viene avviato solo quando serve. In quel momento, contatta il servente SMTP indicato nella sua configurazione e gli affida il messaggio. Pertanto, il servente in
questione deve essere sempre disponibile, ovvero deve essere sempre disponibile la comunicazione verso quell’elaboratore remoto. Da questo si comprende che sSMTP non può essere usato
in un elaboratore che si collega alla rete esterna solo saltuariamente.
In generale, i messaggi destinati all’elaboratore locale non si possono consegnare, ma anche se
non si intende usare un programma come Mailx (‘mail’) non bisogna dimenticare che in un
sistema Unix standard vengono generati automaticamente dei messaggi che spesso sono diretti
all’amministratore, per aggiornarlo sullo svolgimento di operazioni periodiche o per avvisarlo
di qualunque tipo di problema. In altri termini, un sistema Unix non può fare a meno di un
programma che consenta almeno l’invio dei messaggi di posta elettronica. sSMTP è in grado di
ridirigere questi messaggi a un indirizzo di posta elettronica, che però deve esterno all’elaboratore
locale.
Quando un utente invia un messaggio, è necessario che sSMTP sia in grado di modificare il
campo ‘From:’, in modo che appaia un indirizzo di posta elettronica valido; diversamente, se
apparisse l’indirizzo dell’elaboratore locale (dinkel.brot.dg nell’esempio), non potrebbe
ricevere alcuna risposta dal suo interlocutore.
sSMTP utilizza solo due file per la configurazione. Si tratta di ‘/etc/ssmtp/ssmtp.conf’
e di ‘/etc/ssmtp/revaliases’. È sufficiente mostrare degli esempi compatibili con quanto visto in figura 157.1 per comprendere l’uso delle direttive di questi file. Si comincia con
‘/etc/ssmtp/ssmtp.conf’, dove i commenti relativi alle direttive non utilizzate sono rimasti
in inglese:
1
sSMTP GNU GPL
1674
sSMTP
1675
# /etc/ssmtp/ssmtp.conf
# La persona che riceve i messaggi diretti agli utenti con UID inferiore a 10
[email protected]
# Il servente SMTP per l’invio dei messaggi.
mailhub=weizen.mehl.dg
# Where will the mail seem to come from?
#rewriteDomain=dinkel.brot.dg
# Il nome completo del nodo locale
hostname=dinkel.brot.dg
# Set this to never rewrite the "From:" line (unless not given) and to
# use that address in the "from line" of the envelope.
#FromLineOverride=YES
Come si vede, i messaggi diretti a root@localhost vengono modificati e inviati a [email protected]; l’invio dei messaggi avviene facendo uso del servizio offerto da
weizen.mehl.dg; il nome dell’elaboratore locale è dinkel.brot.dg.
Quanto visto fino a questo punto basta per inviare i messaggi, ma non è sufficiente a modificare
il campo ‘From:’, perché si tratta di un compito affidato alla configurazione con il file ‘/etc/
ssmtp/revaliases’:
# /etc/ssmtp/revaliases
root:
tizio:
caio:
semproni:
[email protected]
[email protected]
[email protected]
[email protected]
Si può osservare che al nominativo-utente si abbina l’indirizzo di posta elettronica appropriato,
compreso il caso di ‘root’.
157.2 Ricezione della posta elettronica
La ricezione della posta elettronica è un’attività al di fuori della competenza di sSMTP, pertanto
la si dovrà prelevare attraverso il protocollo POP3 o un altro simile, ma questo direttamente
attraverso il programma utilizzato per la lettura della stessa. In altri termini, non si può usare
Fetchmail (152.4) e nemmeno altri programmi che rinviano i messaggi prelevati nel sistema di
recapito locale.
157.3 Considerazioni sulla sicurezza
L’utilizzo di sSMTP si giustifica solo quando si vuole evitare di dovere gestire un servente SMTP
standard, con tutti i problemi di sicurezza che ciò comporta. Inoltre, si evita di avere in funzione
continuamente il programma, riducendo così le risorse elaborative richieste.
Capitolo
158
Liste di posta elettronica
Una lista di posta elettronica, o mailing-list, o più semplicemente lista, è un servizio attraverso cui
un gruppo di persone può inviare dei messaggi di posta elettronica a tutti i partecipanti, creando
in pratica un mezzo per discutere di un certo argomento. Sotto questo aspetto, la mailing-list
compie lo stesso servizio di un newsgroup, con la differenza che ci si deve iscrivere presso il
servente (o il «robot») che offre il servizio e che i messaggi vengono inviati a tutti i partecipanti
iscritti.
Dal momento che la lista di posta elettronica richiede questa forma di iscrizione, tende a escludere
i visitatori occasionali (o casuali), ma permette ugualmente l’accesso a un numero di utenti più
vasto: tutti quelli che hanno la possibilità di usare la posta elettronica. Infatti, per quanto riguarda
i newsgroup, sono rari gli utenti di Internet che possono accedere a tutti i gruppi di discussione.
Il servizio di una lista di posta elettronica viene svolto normalmente da un programma che si
occupa di ricevere la posta da un certo indirizzo e conseguentemente di rispedire i messaggi a
tutti gli iscritti. Per iscriversi occorre inviare un messaggio speciale al programma che lo gestisce,
contenente il nome della lista e l’indirizzo di posta elettronica di colui che si iscrive; in modo
analogo si interviene per cancellare l’iscrizione.
Dal punto di vista amministrativo, si distinguono due tipi di liste: moderate e non moderate. Una
lista moderata è quella in cui tutti i messaggi, prima di essere ritrasmessi agli iscritti, vengono
controllati da uno o più moderatori; l’altro tipo di lista non viene controllata da alcuno.
In questo capitolo si fa riferimento implicitamente all’utilizzo di Sendmail. Tuttavia, le indicazioni date possono adattarsi a Exim, anche se non in modo identico. Quando necessario
vengono aggiunte delle note riferite alle particolarità di Exim.
158.1 Lista elementare
Prima di vedere il funzionamento di un applicativo organizzato per la gestione di una lista,
conviene apprenderne i rudimenti realizzandone una elementare attraverso la gestione degli alias.
Se l’obiettivo che ci si prefigge è solo quello di definire un indirizzo di posta elettronica che serva
come punto di riferimento per il proseguimento (forward) dei messaggi a un elenco di persone, si
può agire in due modi differenti: modificando il file ‘/etc/aliases’, oppure creando un utente
fittizio che possieda nella sua directory personale il file ‘~/.forward’.
158.1.1 Utente fittizio
Il secondo caso, quello dell’utente fittizio, è il più semplice da comprendere. Se si suppone di
voler creare la lista ‘prova’, basterà registrare un utente con lo stesso nome nel sistema operativo,
facendo opportunamente in modo che questo non abbia una parola d’ordine valida e nemmeno
una shell funzionante. Nella sua directory personale verrà creato e gestito il file ‘~/.forward’
nel quale verranno inseriti gli indirizzi degli utenti iscritti alla lista ‘prova’.
È tutto qui; spetta all’amministratore del servizio l’aggiornamento manuale di questo file. Eventualmente, questo amministratore potrebbe essere un utente diverso dall’utente ‘root’, per cui
si potrebbe anche fare in modo che l’utenza ‘prova’ possa funzionare regolarmente (con parola
d’ordine e shell), lasciandola usare a questo amministratore.
Il limite principale di questo sistema sta nel fatto che il nome utilizzato per la lista deve rispettare
i vincoli imposti dalla registrazione degli utenti nel sistema operativo.
1676
1677
158.1.2 Alias
Il metodo della creazione dell’alias è più efficace. Generalmente si crea un file contenente l’elenco degli indirizzi degli iscritti alla lista e si fa in modo che un alias faccia riferimento a tutti
questi indirizzi. Per esempio, se nel file ‘/etc/aliases’ viene inserita la riga seguente,
prova:
:include:/var/liste/prova/iscritti
si fa in modo che tutti i messaggi diretti all’indirizzo ‘prova’ siano poi rinviati a tutti gli indirizzi indicati nel file ‘/var/liste/prova/iscritti’. Dal momento che con questo sistema
si hanno maggiori possibilità nella definizione dei nomi, si può aggiungere convenientemente un
alias per l’amministratore del servizio, come nell’esempio seguente:
prova:
prova-admin
:include:/var/liste/prova/iscritti
daniele
Bisogna sempre ricordare, quando si interviene nel file ‘/etc/aliases’, che poi occorre rigenerare il file ‘/etc/aliases.db’ attraverso il comando ‘newaliases’. Tuttavia, una volta creata
la lista nel modo appena descritto, quando si interviene nel file degli iscritti non si deve più avviare ‘newaliases’, perché non c’è stato alcun intervento nel file ‘/etc/aliases’. Questo, tra le
altre cose, garantisce che l’amministratore della lista possa essere una persona diversa dall’utente
‘root’, purché abbia i privilegi necessari per intervenire nella directory di appoggio della lista
(‘/var/liste/prova/’ in questo caso).
158.1.3 Archiviazione di una copia dei messaggi
In entrambi i casi visti è possibile mantenere un archivio dei messaggi ricevuti dalla lista, con la
semplice aggiunta di un indirizzo che faccia riferimento a un file su disco. Per esempio, il file
‘~prova/.forward’ potrebbe iniziare nel modo seguente:
"/home/prova/archivio"
Tizio Tizi <[email protected]>
Caio Cai <[email protected]>
...
Nello stesso modo, il file ‘/var/liste/prova/iscritti’ potrebbe iniziare come segue:
"/var/liste/prova/archivio"
Tizio Tizi <[email protected]>
Caio Cai <[email protected]>
...
Bisogna fare attenzione ai permessi. È molto probabile che il file venga creato con i privilegi
dell’utente ‘mail’. La prima volta conviene fare in modo che la directory che deve accogliere
tale file abbia tutti i permessi necessari alla scrittura da parte di chiunque, in modo da vedere
cosa viene creato effettivamente. Successivamente si possono regolare i permessi in modo più
preciso.
158.1.4 Particolarità per Exim
Gli esempi mostrati possono adattarsi anche all’uso di Exim, con qualche differenza.
• Una volta modificato il file ‘/etc/aliases’ non è necessario eseguire ‘newaliases’,
perché ciò non avrebbe alcun significato.
• Occorre verificare la proprietà e i permessi che utilizza Exim nella creazione di un file
definito come alias all’interno di ‘/etc/aliases’. Potrebbe trattarsi di ‘nobody’.
1678
158.2 SmartList
SmartList 1 2 è un applicativo in grado di gestire una lista di posta elettronica. Il principio di
funzionamento è abbastanza semplice: attraverso una serie di alias del sistema di gestione dei
messaggi di posta elettronica (Sendmail per intenderci), SmartList riceve i messaggi destinati
all’indirizzo della lista e quindi li ritrasmette a tutti gli iscritti.
SmartList richiede la predisposizione di un utente e di un gruppo specifici per la gestione del
servizio; a seconda della distribuzione GNU può trattarsi di ‘list’ o ‘listserv’ o qualcosa di
simile.
L’applicativo si distribuisce in una serie di directory il cui punto di origine comune è la directory personale dell’utente fittizio del servizio (directory home). Questa sua particolarità fa sì che
SmartList non abbia una collocazione tradizionale nel file system di un sistema GNU. Alcune
distribuzioni GNU possono collocare l’applicativo da qualche parte al di sotto della gerarchia
‘/var/’, ma forse la posizione più corretta è a partire da ‘/home/’.
Negli esempi che verranno proposti si suppone di avere installato SmartList in modo che l’utente
fittizio corrispondente sia ‘listserv’ e che la directory personale di tale utente (cioè l’inizio
della gerarchia di SmartList) sia ‘/home/listserv/’.
158.2.1 /etc/passwd
Si è accennato al fatto che deve esistere un utente fittizio (e un gruppo corrispondente) e che
la sua directory personale deve coincidere al punto di inizio della gerarchia di SmartList. Dal
momento che la collocazione di questo applicativo non è scontata, può darsi che si debba ritoccare
il file ‘/etc/passwd’. Di sicuro deve essere controllato, per verificare che la directory iniziale
corrisponda a quanto esiste effettivamente.
listserv:!!:504:504::/home/listserv:/bin/bash
L’utente abbinato a SmartList ha anche una shell, ma non può avere una parola d’ordine valida.
158.2.2 Struttura della gerarchia di SmartList
Dalla directory iniziale di SmartList si diramano alcune directory e file «nascosti», nel senso che
iniziano con un punto.
listserv/
|-|-|-‘--
.bin/
.etc/
.examples/
.procmailrc
Questa impostazione conferma la sua natura di directory personale. La directory ‘.bin/’ contiene gli eseguibili e gli script che compongono l’applicativo; la directory ‘.etc/’ contiene file di
configurazione; la directory ‘.examples/’ contiene solo esempi. Infine, il file ‘.procmailrc’
è necessario a personalizzare il comportamento di ‘procmail’, utilizzato da SmartList per
l’elaborazione dei messaggi.
Per poter intervenire su SmartList, per esempio per creare o eliminare una lista, occorre usare
gli strumenti contenuti nella directory ‘.bin/’. Per questo, è opportuno che questa sia compresa
tra i percorsi di ricerca degli eseguibili, ovvero nell’elenco contenuto nella variabile di ambiente
1
2
SmartList GNU GPL o Artistic
Procmail GNU GPL o Artistic
1679
‘PATH’. Quando si interviene con questi programmi, occorre anche che la directory corrente sia
la directory iniziale di SmartList.
Quando si genera una lista nuova, viene creata una directory con lo stesso nome e al suo interno
vengono collocati una serie di file di configurazione contenenti, tra le altre cose, i messaggi che
vengono utilizzati automaticamente per guidare gli utenti che si iscrivono alla lista. SmartList
genera tali file a partire da quanto già predisposto all’interno della directory ‘.etc/’: in alcuni
casi vengono fatte delle copie, in altri dei collegamenti. Ciò permette di uniformare certi aspetti
della gestione delle liste. Tuttavia, gli script utilizzati per ottenere questo sono predisposti per
generare dei collegamenti fisici, mentre, forse, dei collegamenti simbolici sarebbero più pratici
da gestire; soprattutto quando si vuole cambiare qualcosa in una lista in modo indipendente dalla
configurazione generale, essendo i collegamenti simbolici più facili da individuare.
Se lo si desidera, si può modificare lo script responsabile della preparazione della directory di una
lista in modo che invece dei collegamenti fisici si possano generare dei collegamenti simbolici.
Si tratta di intervenire su ‘.bin/createlist’; precisamente, basta modificare la riga
ln=ln
# /bin/ln
in modo che diventi come quella seguente:
ln="ln -s"
# /bin/ln
158.2.3 Creazione ed eliminazione di una lista
Per creare o eliminare una lista ci si deve posizionare nella directory iniziale di SmartList e
da lì utilizzare ‘createlist’ o ‘removelist’. Ciò, tenendo presente che questi due script si
trovano all’interno di ‘.bin/’, che deve essere raggiungibile attraverso i percorsi di ricerca per
gli eseguibili.
La sintassi per creare una lista è la seguente:
createlist
[-a]
nome_lista
[email_amministratore ]
Se viene usata l’opzione ‘-a’, invece di creare una lista vera e propria si crea un archivio. Specificando l’indirizzo di posta elettronica di un amministratore, si vuole indicare esplicitamente
la persona da contattare in caso di problemi con la lista; inoltre, questa è la persona che (teoricamente) può intervenire nell’amministrazione della lista attraverso l’uso della stessa posta
elettronica.
L’esempio seguente crea la lista ‘prova’ amministrata da [email protected].
# cd ~listserv[ Invio ]
# createlist prova [email protected][ Invio ]
Installed the following files:
root
root
root
root
root
root
root
root
root
root
root
root
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
1024
4
1024
19
1024
62
16
4076
15
18
17
14
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
3
3
3
3
3
3
3
3
3
3
3
3
prova
prova/accept -> dist
prova/archive
prova/archive.txt -> ../.etc/archive.txt
prova/archive/latest
prova/dist
prova/help.txt -> ../.etc/help.txt
prova/rc.custom
prova/rc.init -> ../.etc/rc.init
prova/rc.request -> ../.etc/rc.request
prova/rc.submit -> ../.etc/rc.submit
prova/reject -> ../.etc/reject
1680
root
root
listserv
listserv
21 Jun
23 Jun
3 prova/subscribe.txt -> ../.etc/subscribe.txt
3 prova/unsubscribe.txt -> ../.etc/unsubscribe.txt
Lo script informa su quanto ha prodotto: precisamente ha creato la directory ‘prova/’ e vi ha
posto all’interno una serie di file. Se prima di utilizzare lo script, questo era stato modificato
come suggerito in precedenza (in modo da generare dei collegamenti simbolici), ciò che si vede
qui è il risultato che si ottiene.3
Subito dopo, ‘createlist’ suggerisce anche le modifiche da apportare al file ‘/etc/aliases’.
Now make the following entries in your /etc/aliases file:
########################################################################
prova: "|exec /home/listserv/.bin/flist prova"
prova-request: "|exec /home/listserv/.bin/flist prova-request"
prova-dist: :include:/home/listserv/prova/dist
########################################################################
And make sure to run newaliases afterwards.
Una volta inseriti questi alias, come suggerisce lo stesso ‘createlist’, si deve avviare
‘newaliases’.
# newaliases[ Invio ]
/etc/aliases: 18 aliases, longest 48 bytes, 313 bytes total
A questo punto la lista ‘prova’ è pronta e funzionante: l’indirizzo prova-request@... serve
per iscriversi, per ritirarsi e per ottenere informazioni; l’indirizzo prova@... è quello che viene
usato per l’uso normale della lista.
Per eliminare una lista, si utilizza lo script ‘removelist’ con la sintassi seguente:
remove nome_lista
L’esempio seguente, elimina la lista ‘prova’.
# removelist prova[ Invio ]
Expunging /home/listserv/prova, countdown initiated:
3
2
1
zero
Don’t forget to remove the corresponding entries from
the /etc/aliases file:
########################################################################
prova:
prova-request:
prova-dist:
########################################################################
L’effetto è abbastanza logico: viene eliminata la directory ‘prova/’ con tutto il suo contenuto di
file, collegamenti e sottodirectory. Come si può intuire, per finire l’operazione occorre eliminare
gli alias all’interno del file ‘/etc/aliases’.
158.2.4 Varianti per Exim
Se l’MTA è Exim, le righe da includere nel file ‘/etc/aliases’ devono essere un po’ diverse
e precisamente sono quelle seguenti. In pratica, non si può usare il comando interno di shell
‘exec’.
3
Il listato che si ottiene è generato attraverso il comando ‘ls -l’. Nell’esempio si mostra un listato con meno colonne
per non perdere le informazioni sulla parte destra, a causa del tipo di composizione tipografica adottato.
1681
prova:
"| /home/listserv/.bin/flist prova"
prova-request: "| /home/listserv/.bin/flist prova-request"
prova-dist:
:include:/home/listserv/prova/dist
Inoltre, dal momento che si usano delle pipeline tra gli alias, è necessario che sia stato stabilito
nella configurazione di Exim quale utente e gruppo usare come proprietari del processo relativo.
Nella parte della configurazione riferita ai driver di direzione (director), dovrebbe apparire la
definizione degli alias di sistema in un modo simile a quello seguente:
system_aliases:
driver = aliasfile;
file = /etc/aliases,
search_type = lsearch
user = exim
group = mail
Secondo questo esempio, le pipeline vengono avviate con i privilegi dell’utente ‘exim’ e del
gruppo ‘mail’.
È probabile che gli eseguibili di SmartList abbiano il bit SUID attivo, appartenendo all’utente
‘root’ (SUID-root). In tal caso, non è importante quali siano i privilegi utilizzati per l’avvio
della pipeline, perché tanto poi i programmi di SmartList acquistano automaticamente i privilegi
158.2.5 Organizzazione dei permessi e amministrazione delle liste
SmartList è organizzato in modo che tutto quello che serve per l’amministrazione del servizio
possa essere svolto da un utente che faccia parte anche del gruppo a cui appartiene l’utente fittizio
della gestione di questo sistema (‘listserv’ o altro). Per evitare errori, la directory iniziale di
SmartList deve avere il bit SGID attivo, assicurando così che tutto ciò che discende da questa
appartenga allo stesso gruppo della directory.
In questa situazione, il meccanismo può funzionare solo se, quando si interviene nei file delle
liste, si utilizza una maschera dei permessi pari a 0078. Questa consente di avere i permessi di
scrittura anche per il gruppo, mentre toglie tutti i permessi per chi non abbia i privilegi dell’utente
o del gruppo proprietari.
Dal momento che SmartList, per se stesso, richiede solo che il suo gruppo fittizio abbia tutti i
permessi necessari a intervenire nei file (e nelle directory) delle liste, si può affidare l’amministrazione di liste differenti ad amministratori diversi, senza che questi abbiano i privilegi del gruppo
di SmartList. Basta abbinare ai file delle liste rispettive la proprietà dell’utente amministratore.
In pratica, si utilizza lo script ‘donatelist’ secondo la sintassi seguente:
donatelist utente nome_lista
L’esempio seguente, affida la lista ‘prova’ all’utente ‘tizio’.
# donatelist tizio prova[ Invio ]
tizio
listserv
tizio
root
tizio
root
tizio
tizio
root
tizio
root
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
listserv
1024
1024
1024
4
1024
19
1024
62
16
4076
15
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
3
3
3
3
3
3
3
3
3
3
3
.
..
prova
prova/accept -> dist
prova/archive
prova/archive.txt -> ../.etc/archive.txt
prova/archive/latest
prova/dist
prova/help.txt -> ../.etc/help.txt
prova/rc.custom
prova/rc.init -> ../.etc/rc.init
1682
root
root
root
root
root
listserv
listserv
listserv
listserv
listserv
18
17
14
21
23
Jun
Jun
Jun
Jun
Jun
3
3
3
3
3
prova/rc.request -> ../.etc/rc.request
prova/rc.submit -> ../.etc/rc.submit
prova/reject -> ../.etc/reject
prova/subscribe.txt -> ../.etc/subscribe.txt
prova/unsubscribe.txt -> ../.etc/unsubscribe.txt
Anche in questo caso il listato che si ottiene rappresenta il contenuto della directory corrispondente alla lista, da cui si può osservare che è stata cambiata la proprietà dei soli file e directory,
mentre i collegamenti sono rimasti correttamente inalterati.
Ormai dovrebbe essere chiara la logica attraverso cui si configura una lista. Se certe impostazioni
globali, espresse attraverso i collegamenti, non vanno bene, basta eliminare i collegamenti desiderati e produrre delle varianti locali. Naturalmente, nello stesso modo in cui si hanno queste
impostazioni globali, si possono definire gruppi di configurazioni, a cui puntare i collegamenti
che si desiderano.
La configurazione di SmartList si divide in due parti: una globale, che riguarda potenzialmente
tutte le liste gestite, e una particolare per ogni lista. La configurazione globale è contenuta nella
directory ‘.etc/’ e viene usata per generare dei collegamenti nella directory di ogni lista, all’atto
della creazione (come è stato mostrato). La configurazione particolare è costituita dai file che
sono stati copiati nelle directory delle liste, la cui modifica, in tal modo, non può influenzare il
comportamento delle altre liste.
È chiaro che se in una lista si desidera personalizzare qualche aspetto che riguarda file condivisi,
basta cancellare il collegamento corrispondente e fare una copia locale di quel file.
I file più importanti da considerare sono ‘rc.init’, fornito generalmente alle directory delle
liste in forma di collegamento, e ‘rc.custom’ che viene copiato necessariamente perché non
può essere condiviso in ogni caso.
Vanno verificati entrambi i file: il primo almeno una volta quando si attiva il servizio; il secondo
alla creazione di ogni lista nuova. I file sono commentati adeguatamente e questo dovrebbe bastare per capire il senso delle varie definizioni. In particolare, è importante verificare la definizione
della variabile ‘domain’, all’inizio del file ‘rc.init’: deve contenere il dominio completo del
nodo in cui si trovano a funzionare le liste. Eventualmente, se si vogliono gestire liste differenti
su domini virtuali diversi, basta fare una copia del file ‘rc.init’ nella directory di ogni lista,
cambiando opportunamente la definizione di tali domini.
158.2.7 Iscrizione e ritiro dalla lista
L’utente qualunque che desidera iscriversi alla lista, deve inviare un messaggio all’indirizzo
lista-request@... (nel caso degli esempi proposti si tratta di prova-request@...), in cui,
nell’oggetto o nel corpo del messaggio, appaia esclusivamente la parola ‘subscribe’.
Nello stesso modo, l’utente che vuole eliminare la propria iscrizione alla lista, deve inviare un
messaggio contenente esclusivamente la parola ‘unsubscribe’.
1683
158.2.8 Manutenzione
L’amministratore della lista, definito al momento della sua creazione, può utilizzare la posta elettronica per dare alcuni comandi elementari. In pratica può aggiungere o eliminare degli iscritti.
Per ottenere ciò deve inviare un messaggio all’indirizzo lista-request@... (nel caso degli esempi proposti si tratta di prova-request@...) in cui la voce ‘X-Command’ deve essere usata per
contenere il comando. Naturalmente, il risultato è un messaggio di risposta contenente l’esito del
comando.
Si deve utilizzare la sintassi seguente:
email_amministratore parola_d’ordine comando
I comandi fondamentali sono:
subscribe email_nuovo_iscritto
unsubscribe email_vecchio_iscritto
help
| info
I primi due comandi servono per aggiungere o eliminare un iscritto alla lista; l’ultimo serve a
ottenere un riepilogo dei comandi disponibili (ne esistono altri).
La parola d’ordine viene definita all’interno del file ‘rc.custom’ (contenuto nella directory della
lista) e assieme a questa si può modificare il nome dell’intestazione da usare per inviare i comandi
di amministrazione. L’esempio seguente mostra una possibile modifica del file ‘rc.custom’ per
fare in modo di poter usare il campo del ‘X-Admin:’ al posto di ‘X-Command:’.
X_COMMAND
X_COMMAND_PASSWORD
=
=
X-Admin
Marameo
# put the password for
# X-Command mails here
In origine, nel file ‘rc.custom’, queste righe sono semplicemente commentate con il simbolo
‘#’. Bisogna togliere il commento e poi definire i valori da assegnare.
Si potrebbe essere tentati di utilizzare l’oggetto (il campo ‘Subject:’) come sostituto di
‘X-Command:’. Questa non è una buona idea, in quanto provoca degli effetti collaterali abbastanza pesanti. Precisamente, non è più possibile per gli utenti utilizzare l’oggetto per iscriversi o cancellarsi dalla lista e nemmeno per usare altri servizi: se viene fatto erroneamente, non
ricevono alcun avvertimento e solo l’amministratore ne è informato attraverso l’indicazione
di un «comando sospetto». Ciò significa oltretutto che l’amministratore verrebbe disturbato
continuamente con segnalazioni di errore fasulle.
Naturalmente, l’amministratore, per poter utilizzare l’intestazione ‘X-Command:’ deve configurare opportunamente il proprio programma MUA. Per esempio, nel caso di Pine, occorre
intervenire nel campo ‘customized-hdrs’ (151.8).
È bene considerare che, anche se non si vuole utilizzare questo meccanismo, esiste una parola
d’ordine predefinita che potrebbe essere usata da qualcun altro. Pertanto, è almeno opportuno
indicare una parola d’ordine in ogni caso.
L’amministratore della lista può intervenire ugualmente per cambiare l’elenco degli iscritti modificando direttamente il file che lo contiene. Si tratta di ‘dist’, composto semplicemente da una
serie di righe, ognuna delle quali riporta esclusivamente l’indirizzo di posta elettronica di uno dei
destinatari.
1684
158.2.9 Messaggi automatici
SmartList, come robot, deve inviare alcuni messaggi automatici a seguito dell’esecuzione di operazioni particolari, come l’iscrizione o la cancellazione in una lista. È evidente che sia opportuno
tradurli e adattarli alle proprie esigenze particolari.
Il file ‘help.txt’ contenuto nella directory della lista viene utilizzato come risposta a una richiesta ‘help’ inviata all’indirizzo lista-request@... (come sempre si può usare l’oggetto o il
corpo del messaggio per scrivere la parola ‘help’).
Tale file dovrebbe contenere le informazioni generali per usare tutte le liste che si gestiscono, per
cui è generalmente un collegamento a un file uguale per tutte.
Volendo, si può aggiungere nella directory della lista un file di informazioni aggiuntivo e specifico. Deve trattarsi di ‘info.txt’ e il suo contenuto viene accodato semplicemente a quello di
‘help.txt’.
General info
-----------Subcription/unsubscription/info requests should always be sent to the -request
address of a mailinglist.
If a mailinglist for example is called "[email protected]", then the -request
address can be inferred from this to be: "[email protected]".
To subscribe to a mailinglist, simply send a message with the word "subscribe"
in the Subject: field to the -request address of that list.
To unsubscribe from a mailinglist, simply send a message with the word (you
guessed it :-) "unsubscribe" in the Subject: field to the -request address of
that list.
...
SmartList, come altri applicativi del genere, mantiene un archivio dei messaggi ricevuti, che
può essere consultato (in modo piuttosto scomodo) attraverso alcuni comandi da inviare all’indirizzo lista-request@.... Il contenuto del file ‘archive.txt’ serve a descrivere la procedura
da utilizzare per questo scopo e si ottiene quando all’indirizzo lista-request@... si invia un
messaggio con il comando ‘archive help’ nell’oggetto.
This archive server knows the following commands:
get filename ...
ls directory ...
egrep case_insensitive_regular_expression filename ...
maxfiles nnn
version
...
158.2.10 Configurazione dell’archivio
L’archivio dei messaggi si trova nella directory ‘archive/latest/’ discendente dalla directory
della lista a cui si riferisce. Ogni messaggio viene memorizzato in un file differente.
La configurazione normale dell’archivio prevede che vengano conservati solo gli ultimi due messaggi; se si vuole amministrare un archivio, è evidente che tale numero deve essere aumentato. La
modifica alla configurazione deve essere fatta nel file ‘rc.custom’, come nell’esempio seguente,
in cui si stabilisce un massimo di 100 messaggi.
archive_hist
=
100
# number of messages left archived
1685
158.2.11 Consultazione dell’archivio
Per consultare l’archivio si utilizzano una serie di comandi specifici, da inserire nel corpo di un
messaggio di posta elettronica inviato all’indirizzo lista-request@.... Quello che conta è che
nell’oggetto venga indicata la parola ‘archive’. I comandi possono essere più di uno in uno
stesso messaggio e seguono le regole descritte nella guida contenuta nel file ‘archive.txt’.
Questa, come già accennato, si ottiene inviando la richiesta ‘archive help’.
158.2.12 Filtri di accesso
Una lista di discussione è il destinatario ideale di messaggi pubblicitari di vario tipo, o più semplicemente di spam. Sotto questo aspetto, lo studio di un valido sistema di filtro contro gli utilizzi
impropri è più che opportuno.
Per quanto riguarda il controllo dell’iscrizione alla lista, SmartList permette di intervenire nella
directory della lista da controllare, in particolare nel modo seguente:
• realizzando un file denominato ‘reject’, contenente un elenco di mittenti (identificati dai
rispettivi indirizzi di posta elettronica) da cui rifiutare gli accessi;
• creando un programma o uno script, denominato ‘subscreen’, che, ricevendo l’indirizzo
del mittente come primo argomento, deve restituire il valore zero quando l’accesso viene
consentito.
Anche l’invio dei messaggi alla lista può essere controllato, precisamente attraverso il file
‘accept’. Generalmente questo è un collegamento al file ‘dist’, quello che contiene l’elenco degli iscritti a cui inviare copia di tutti i messaggi della lista. In tal modo, solo gli iscritti
possono inviare messaggi alla lista.
158.2.13 Liste moderate
Fino a questo punto è stato descritto come creare e gestire una lista non moderata. Per ottenere una lista moderata occorre indicare gli indirizzi di posta elettronica dei moderatori nel file
‘moderators’. La sola esistenza di questo file, nella directory della lista da moderare, fa sì che i
messaggi vengano trasmessi solo ai moderatori; successivamente, uno di questi, dopo averli controllati ed eventualmente modificati, può ritrasmetterli aggiungendo la voce ‘Approved’, seguita
dal suo indirizzo di posta elettronica. I messaggi «firmati» in questo modo vengono rispediti a
tutti gli iscritti alla lista.
158.3 Mailman
Mailman 4 è un sistema per la gestione di una lista di posta elettronica, gestito attraverso programmi CGI (capitolo 162). Questo tipo di lista di posta elettronica dipende pertanto, oltre che
da un MTA adatto, anche da un servente HTTP (parte xxx) in grado di consentire il funzionamento di programmi CGI; inoltre richiede di configurare Cron per la gestione delle operazioni
periodiche.
Nella descrizione che qui viene fatta di Mailman, si trascura completamente, o quasi, ciò che
riguarda la configurazione di Cron, dell’MTA e del servente HTTP, perché è molto probabile che
la propria distribuzione GNU sia in grado di predisporre tutto questo in modo automatico, nel
momento dell’installazione del pacchetto che corrisponde a questo applicativo. Eventualmente si
può leggere la documentazione originale di Mailman che dovrebbe essere accessibile a partire da
<http://www.gnu.org/software/mailman/mailman.html>.
4
Mailman GNU GPL
1686
158.3.1 Privilegi durante il funzionamento
Quando un programma di Mailman viene messo in funzione, dovrebbe acquisire privilegi limitati.
Per questo, di solito gli si associa un utente e un gruppo particolari, che potrebbero corrispondere
a un nome del tipo ‘mailman’, oppure ‘list’. In condizioni normali, se si installa Mailman da
un pacchetto predisposto per la propria distribuzione GNU, tutto dovrebbe essere sistemato in
modo automatico, compreso l’aggiornamento del file ‘/etc/aliases’, con la ridirezione della
posta elettronica destinata a questo utente fittizio, verso l’utente ‘root’.
Nel caso particolare di Exim, può essere necessario stabilire l’utente e il gruppo con cui devono
funzionare i programmi avviati attraverso gli alias. Per esempio, se si usa l’utenza fittizia ‘list’
si potrebbe intervenire in un modo simile a quello seguente, nel suo file di configurazione:
system_aliases:
driver = aliasfile;
file = /etc/aliases,
search_type = lsearch
user = list
group = list
La configurazione particolare di Mailman è contenuta in un file denominato ‘mm_cfg.py’, che
potrebbe trovarsi nella directory ‘/etc/mailman/’. Come suggerisce l’estensione, si tratta di
uno script di Python.
La parte più significativa di questo file riguarda la dichiarazione di alcune variabili, come si vede
dall’estratto seguente:
##############################################################
# Put YOUR site-specific configuration below, in mm_cfg.py . #
# See Defaults.py for explanations of the values.
#
DEFAULT_HOST_NAME = ’dinkel.brot.dg’
DEFAULT_URL
= ’http://dinkel.brot.dg/cgi-bin/mailman’
DELIVERED_BY_URL = ’/doc/mailman/images/mailman.jpg’
MAILMAN_OWNER
= ’mailman-owner@%s’ % DEFAULT_HOST_NAME
PUBLIC_ARCHIVE_URL = ’/pipermail’
PRIVATE_ARCHIVE_URL = ’/mailman/private’
USE_ENVELOPE_SENDER = 0
Per prima cosa, si può osservare che i programmi CGI di Mailman dovrebbero essere accessibili a partire da http://dinkel.brot.dg/cgi-bin/mailman/; pertanto, il servente HTTP deve risultare configurato per consentire l’accesso in questo modo a tali file. In base all’esempio, si può verificare che ciò sia così provando a interrogare l’indirizzo http://
dinkel.brot.dg/cgi-bin/mailman/admin, dal quale si deve ottenere una pagina di
informazioni sull’amministrazione delle liste.
Come si può intuire dalla configurazione, si definisce che l’amministratore del sistema Mailman
si chiama mailman-owner@..., pertanto è necessario definire a chi deve corrispondere effettivamente questo indirizzo, intervenendo nel file ‘/etc/aliases’ e avviando successivamente ‘newaliases’ (se necessario). Supponendo che si tratti effettivamente dell’utente ‘tizio’,
potrebbe essere una riga come quella seguente:
mailman-owner: tizio
1687
Infine, è necessario definire una parola d’ordine per l’amministrazione complessiva. Per questo
si usa il programma ‘mmsitepass’:
# mmsitepass[ Invio ]
New password: digitazione_all’oscuro [ Invio ]
Again to confirm password: digitazione_all’oscuro [ Invio ]
In questo modo, la parola d’ordine viene annotata, in modo cifrato per evitare che possa essere
individuata facilmente.
158.3.3 Creazione e cancellazione di una lista
La creazione di una lista di Mailman è guidata dal programma ‘newlist’, che si usa in pratica
come nell’esempio seguente, in cui si crea la lista prova@...:
# newlist[ Invio ]
Enter the name of the new list: prova[ Invio ]
Enter the email of the person running the list: [email protected][ Invio ]
Initial prova password: digitazione_all’oscuro [ Invio ]
Entry for aliases file:
## prova mailing list
## created: 29-Aug-2002
prova:
prova-admin:
prova-request:
prova-owner:
root
"|/var/lib/mailman/mail/wrapper post prova"
"|/var/lib/mailman/mail/wrapper mailowner prova"
"|/var/lib/mailman/mail/wrapper mailcmd prova"
prova-admin
Hit enter to continue with prova owner notification...
Come si vede dal messaggio che si ottiene, è necessario intervenire poi manualmente nel file ‘/etc/aliases’, per aggiungere alcune righe. In questo modo, gli indirizzi prova@..., prova-admin@..., prova-request@... e prova-owner@... possono poi
funzionare regolarmente per la gestione e l’accesso alla lista.
Per eliminare una lista, si procede in modo analogo, con l’aiuto del programma ‘rmlist’, che se
usato con l’opzione ‘-a’, cancella anche l’archivio dei messaggi:
# rmlist -a prova[ Invio ]
Infine, è possibile consultare rapidamente l’elenco degli iscritti a una lista con il comando
‘list_members’:5
# list_members prova[ Invio ]
5
Sono disponibili anche altri comandi, ma in generale è più semplice il controllo attraverso l’interfaccia dei programmi
CGI.
1688
158.3.4 Amministrazione della lista
Mailman è fatto per essere utilizzato prevalentemente attraverso un navigatore, con il protocollo HTTP. Per verificare l’esistenza della lista appena creata, basta consultare il programma CGI
‘admin’, che secondo la configurazione già vista in precedenza, dovrebbe essere accessibile all’indirizzo http://dinkel.brot.dg/cgi-bin/mailman/admin. Ciò che si dovrebbe
vedere è rappresentato dal listato seguente:
dinkel.brot.dg mailing lists - Admin Links
Welcome!
Below is the collection of publicly-advertised mailman mailing lists
on dinkel.brot.dg. Click on a list name to visit the configuration
pages for that list. To visit the administrators configuration page
for an unadvertised list, open a URL similar to this one, but with a
’/’ and the list name appended.
General list information can be found at the mailing list overview
page.
(Send questions and comments to [email protected].)
List Description
Prova [no description available]
Per configurare meglio la lista prova@... è sufficiente seguire il riferimento ipertestuale che
si trova in corrispondenza del nome che appare sulla pagina, che in pratica porta all’indirizzo
http://dinkel.brot.dg/cgi-bin/mailman/admin/prova. Come spiega la stessa
pagina, se esistono delle liste non pubblicizzate, la loro configurazione si raggiunge in questo
modo, mettendo il loro nome dopo quello del programma CGI ‘admin’.
Prova Administrative Authentication
List Administrative Password:
______________________________
Let me in...
Important: From this point on, you must have cookies enabled in your
browser, otherwise no administrative changes will take effect.
Session cookies are used in Mailman’s administrative interface so that
you don’t need to re-authenticate with every administrative operation.
This cookie will expire automatically when you exit your browser, or
you can explicitly expire the cookie by hitting the Logout link under
Other Administrative Activities (which you’ll see once you
successfully log in).
La pagina che si ottiene serve a richiedere l’identificazione dell’amministratore della lista in base
alla parola d’ordine, come inserito quando era stato utilizzato il programma ‘newlist’. Superata
questa fase si raggiunge la pagina di configurazione vera e propria, che corrisponde però allo
stesso indirizzo precedente.6
Prova mailing list administration
General Options Section
---------------------------------------------------------------------6
Come spiega Mailman stesso, è necessario che il navigatore sia in grado di accettare i cookie.
*
*
*
*
*
*
*
*
*
Configuration Categories
General Options
Membership Management
Privacy Options
Regular-member (non-digest)
Options
Digest-member Options
Bounce Options
Archival Options
Mail-News and News-Mail gateways
Auto-responder
1689
Other Administrative Activities
* Tend to pending administrative
requests
* Go to the general list
information page
* Edit the HTML for the public list
pages
* Go to list archives
* Logout
---------------------------------------------------------------------Make your changes below, and then submit them using the button at the
bottom. (You can change your password there, too.)
General Options
Fundamental list characteristics, including descriptive info and basic
behaviors.
Description
Value
The public name of this list
(make case-changes only). Prova___________________________________
(Details)
The list admin’s email
address - having multiple [email protected]_____________________
admins/addresses (on ________________________________________
separate lines) is ok. ________________________________________
(Details)
A terse phrase identifying _________________________________________
this list. (Details)
An introductory description ________________________________________
- a few paragraphs - about ________________________________________
the list. It will be ________________________________________
included, as html, at the ________________________________________
top of the listinfo page. ________________________________________
Carriage returns will end a ________________________________________
paragraph - see the details ________________________________________
for more info. (Details)
Prefix for subject line of [Prova]_________________________________
list postings. (Details)
List-specific text prepended ________________________________________
to new-subscriber welcome ________________________________________
message (Details) ________________________________________
________________________________________
Text sent to people leaving ________________________________________
the list. If empty, no ________________________________________
special text will be added ________________________________________
to the unsubscribe message. ________________________________________
(Details)
Where are replies to list
messages directed? Poster is (*) Poster ( ) This
( ) Explicit
strongly recommended for
list
address
most mailing lists.
(Details)
Explicit Reply-To: header. _________________________________________
(Details)
(Administrivia filter) Check
postings and intercept ones
that seem to be ( ) No (*) Yes
administrative requests?
(Details)
Send password reminders to,
eg, "-owner" address instead (*) No ( ) Yes
of directly to user.
(Details)
1690
Suffix for use when this
list is an umbrella for
other lists, according to
setting of previous
"umbrella_list" setting.
(Details)
Send monthly password
reminders or no? Overrides
the previous option.
(Details)
Send welcome message when
people subscribe? (Details)
Should administrator get
immediate notice of new
requests, as well as daily
notices about collected
ones? (Details)
Should administrator get
notices of
subscribes/unsubscribes?
(Details)
Send mail to poster when
their posting is held for
approval? (Details)
Maximum length in Kb of a
message body. Use 0 for no
limit. (Details)
Host name this list prefers.
(Details)
Base URL for Mailman web
interface. The URL must end
in a single "/". See also
the details for an important
warning when changing this
value. (Details)
-owner___________________________________
( ) No (*) Yes
( ) No (*) Yes
( ) No (*) Yes
(*) No ( ) Yes
(*) Yes ( ) No
40______
dinkel.brot.dg____________________________
http://dinkel.brot.dg/cgi-bin/mailman/____
To Change The Administrator Password
+--------------------------------------+ +-------------------------------------+
|
Enter current|_____________________| |
Enter new|_____________________|
|
password:|
| |
password:|
|
+--------------------------------------+ |---------------+---------------------|
|
Confirm new|_____________________|
|
password:|
|
+-------------------------------------+
[ Submit Your Changes ]
Quello che si vede sopra riguarda solo la configurazione generale, mentre sono disponibili altre
voci per altre caratteristiche da configurare.
Al termine del lavoro, è bene indicare a Mailman la conclusione dell’attività selezionando la
voce ‘logout’.
158.3.5 Accesso alla lista da parte degli utilizzatori normali
Gli utenti che possono avere interesse a iscriversi a una lista di quelle amministrate devono
raggiungere l’indirizzo http://dinkel.brot.dg/cgi-bin/mailman/listinfo:
1691
dinkel.brot.dg Mailing Lists
Welcome!
Below is a listing of all the public mailing lists on dinkel.brot.dg.
Click on a list name to get more information about the list, or to
subscribe, unsubscribe, and change the preferences on your subscription.
To visit the info page for an unadvertised list, open a URL similar to
this one, but with a ’/’ and the list name appended.
List administrators, you can visit the list admin overview page to find
the management interface for your list.
(Send questions or comments to [email protected].)
List
Prova
Description
[no description available]
Seguendo il riferimento ipertestuale corrispondente al nome della lista a cui si è interessati, si
arriva alla pagina dalla quale ci si può iscrivere:
About Prova
To see the collection of prior postings to the list, visit the Prova
Archives.
Using Prova
To post a message to all the list members, send email to
[email protected].
You can subscribe to the list, or change your existing subscription, in
the sections below.
Subscribing to Prova
Subscribe to Prova by filling out the following form. You will be sent
email requesting confirmation, to prevent others from gratuitously
subscribing you. This is a public list, which means that the members
list is openly available (but we obscure the addresses so they are not
easily recognizable by spammers).
Your email
_______________________________
address:
You must enter a privacy password. This provides
only mild security, but should prevent others
from messing with your subscription. Do not use a
valuable password as it will occasionally be
emailed back to you in cleartext. Once a month,
your password will be emailed to you as a
reminder.
Pick a
________________
password:
Reenter
password to
________________
confirm:
Would you
like to
receive list (*) No ( ) Yes
mail batched
in a daily
digest?
[ Subscribe ]
Prova Subscribers
Click here for the list of Prova subscribers: [ Visit Subscriber list ]
To change your subscription (set options like digest and delivery modes,
get a reminder of your password, or unsubscribe from Prova), either
enter your subscription email address:
_______________________________ [ Edit Options ]
1692
... or select your entry from the subscribers list (see above).
Chi si iscrive, indicando l’indirizzo di posta elettronica e la parola d’ordine per poter gestire
la propria configurazione personale, viene richiesta successivamente una conferma via posta
elettronica, simile a questa:
Reply-To: [email protected]
Subject: Prova -- confirmation of subscription -- request 779881
Prova -- confirmation of subscription -- request 779881
We have received a request from 192.168.1.1 for subscription of your
email address, <[email protected]>, to the [email protected]
mailing list. To confirm the request, please send a message to
[email protected], and either:
- maintain the subject line as is (the reply’s additional "Re:" is
ok),
- or include the following line - and only the following line - in the
message body:
confirm 779881
(Simply sending a ’reply’ to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form.)
If you do not wish to subscribe to this list, please simply disregard
this message. Send questions to [email protected].
Di solito è sufficiente rispondere a questo messaggio, senza includere il testo precedente per ottenere l’iscrizione. A iscrizione avvenuta si riceve un messaggio di conferma, in cui è annotata la
parola d’ordine che era stata definita per la personalizzazione dell’iscrizione alla lista; in seguito
si riceverà mensilmente un promemoria del genere.
Per accedere alla gestione della configurazione personalizzata, si parte dalla stessa pagina
già vista in precedenza, mettendo soltanto il proprio indirizzo di posta elettronica nella parte
inferiore:
About Prova
...
Prova Subscribers
Click here for the list of Prova subscribers: [ Visit Subscriber list ]
To change your subscription (set options like digest and delivery modes,
get a reminder of your password, or unsubscribe from Prova), either
enter your subscription email address:
_______________________________ [ Edit Options ]
... or select your entry from the subscribers list (see above).
Da lì si accede a una pagina in cui è possibile richiedere la cancellazione dalla lista o la modifica
delle caratteristiche configurabili, con l’inserimento della parola d’ordine personale.
1693
1694
Parte xxx
HTTP
159 HTTP: introduzione e utilizzo del servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
159.1 Dal lato del servente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
159.2 Dal lato del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1697
159.3 Lynx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1698
159.4 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1705
159.5 W3M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1707
159.6 Altri clienti HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1708
160 Servente HTTP: Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
160.1 Visione generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709
160.2 Configurazione essenziale con httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1711
160.3 Configurazione delle risorse con srm.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715
160.4 Controllare l’accesso con access.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1720
160.5 Controllare l’accesso con .htaccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726
160.6 Considerazioni sulla sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1727
160.7 Utilizzo del sistema di autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1728
160.8 Siti virtuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1731
160.9 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1732
161 Servente HTTP: Boa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
161.1 Configurazione di Boa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733
161.2 Avvio e gestione del servizio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736
161.3 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1737
162 Servente HTTP-CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
162.1 HTTP e CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
162.2 URI e query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1738
162.3 Collocazione effettiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739
162.4 Protocollo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1740
162.5 Input dell’utente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1745
162.6 Primi approcci alla programmazione CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
162.7 Moduli FORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1751
162.8 Elementi dell’ambiente FORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1752
162.9 Metodi e variabili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756
162.10 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1761
163 Programmazione CGI in Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
1695
163.1 Problemi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
163.2 Decodifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762
163.3 Alcuni esempi elementari di applicazioni CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766
163.4 Ordini a distanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1773
163.5 Interfacciamento con una base di dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1782
163.6 Inserimento e interrogazione attraverso il programma di navigazione . . . . . . . 1789
163.7 Librerie CGI già pronte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1801
163.8 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1802
164 Programmi CGI per l’accesso alla documentazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
164.1 VH-man2HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1803
164.2 Info2www . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1804
1696
Capitolo
159
HTTP: introduzione e utilizzo del servizio
Il modo più comune per pubblicare informazioni attraverso la rete è quello di utilizzare un
servente HTTP (Hypertext transfer protocol).
Le informazioni pubblicate in questo modo sono rivolte a tutti gli utenti che possono raggiungere
il servizio, nel senso che normalmente non viene richiesta alcuna identificazione. Al massimo
si impedisce o si concede l’accesso in base al meccanismo di filtro gestito dal supervisore dei
servizi di rete o dal TCP wrapper.
Per offrire un servizio HTTP occorre un programma in grado di gestirlo. Di solito si tratta di
un demone. Analogamente al servizio FTP anonimo, il servente HTTP consente l’accesso a una
directory particolare e alle sue discendenti. Questa directory viene identificata spesso con il nome
document root e si tratta in pratica di una sorta di directory personale degli utenti (anonimi) che
accedono attraverso questo protocollo.
Un servente HTTP non offre solo un servizio di semplice consultazione di documenti: permette
anche di interpellare dei programmi. Questi programmi sono collocati normalmente al di fuori
della directory da cui si diramano i documenti (HTML o di altro tipo), per evitare che questi
possano essere letti. In questo contesto, tali programmi sono definiti gateway e normalmente
vengono chiamati programmi CGI , o cgi-bin.
L’avvio di programmi implica l’attribuzione di privilegi. Di solito si fa in modo che questi funzionino utilizzando i privilegi di un utente fittizio apposito (‘www’, ‘nobody’ o simile), per evitare
che possano compiere più azioni del necessario.
Secondo le consuetudini, di solito si configura il servente HTTP in modo da non consentire la
lettura del contenuto delle directory. In pratica, se si indica un indirizzo che rappresenta una
directory, si ottiene un file predefinito, che di solito corrisponde a ‘index.html’, contenuto
nella directory richiesta; mentre se questo è assente, non si ottiene alcunché.
Per poter usufruire di un servizio HTTP occorre un programma cliente adatto. In generale, tale
programma cliente è in grado di accedere anche ad altri servizi, pertanto, in questo senso viene
definito semplicemente «navigatore». Il programma di navigazione tipico dovrebbe consentire
anche la visualizzazione di immagini, ma un buon programma che utilizza soltanto un terminale
a caratteri può essere utilizzato in qualunque condizione, quindi, tale possibilità non deve essere
scartata a priori.
159.2.1 Uniform Resource Locator -- Uniform Resource Identifier
L’integrazione di diversi protocolli impone l’utilizzo di un sistema uniforme per indicare gli indirizzi, per poter conoscere subito in che modo si deve effettuare il collegamento. Per questo,
quando si utilizza un navigatore, si devono usare indirizzi espressi in modo standard, precisamente secondo il formato URI, o Uniform resource identifier. Attualmente, è ancora in uso la
vecchia definizione, URL, Uniform resource locator, che in pratica rappresenta la stessa cosa.1
Attraverso questa modalità, è possibile definire tutto quello che serve per raggiungere una risorsa: protocollo, nodo (host), porta, percorso. Il formato generale di un URI è descritto nel capitolo
259.
1
URL è precisamente un sottoinsieme di URI.
1697
1698
159.2.2 Tempi morti
Un problema che riguarda un po’ tutti i programmi clienti, sono i tempi morti. Questi programmi,
quando tentano di accedere a un risorsa senza riuscirci, restano a lungo in attesa prima di restituire
una segnalazione di errore. Se si utilizza un servente DNS e questo non risulta raggiungibile,
oppure a sua volta non riesce a raggiungere gli altri serventi DNS di livello superiore, le attese
sono dovute al ritardo nelle risposta date dal servizio di risoluzione dei nomi.
All’avvio, la maggior parte dei navigatori cerca di raggiungere la propria pagina di
presentazione (home page) e questo richiede un collegamento in funzione in quel momento.
Quando si vuole utilizzare un programma del genere soltanto per delle attività locali e si notano
questi problemi nelle risposte, se si gestisce un servente DNS locale che, almeno temporaneamente, non ha accesso alla rete esterna, si può provare a disattivarlo utilizzando il comando
seguente:
# rndc stop
In seguito, per riattivarlo basterà utilizzare il comando opposto.
# rndc start
Se la propria rete locale non accede mai all’esterno, non è necessario tentare di risolvere nomi
che non appartengono all’ambito locale. Se si utilizza un servizio di risoluzione dei nomi basta togliere (commentandola) la direttiva contenuta nel file ‘named.conf’ che fa riferimento al
dominio principale, rappresentato da un punto singolo.
options {
directory "/etc/bind";
};
//
//zone "." {
//
type hint;
//
file "named.root";
//};
//
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
};
159.3 Lynx
Lynx 2 è la prova di ciò che può fare un buon programma per i terminali senza grafica, anche
per la navigazione nella rete. A prima vista può risultare complicato da utilizzare, ma il tempo
necessario per imparare il suo funzionamento risulta poi ricompensato.
Lynx è un navigatore completo, a parte la limitazione dovuta alla mancanza della grafica. È
stato adattato a un gran numero di piattaforme, Dos inclusa (203.11). La sua semplicità lo rende
prezioso in tutte quelle situazioni in cui non è possibile utilizzare il sistema grafico X.
Prima di avviare Lynx la prima volta, conviene controllare il suo file di configurazione generale.
Molto probabilmente converrà modificare qualcosa. Si tratta di ‘/etc/lynx.cfg’.
Vale la pena di cambiare: l’indicazione della pagina iniziale, la posizione della guida e della
pagina indice. Infatti, in questi casi, si fa riferimento a pagine HTML in rete, mentre è normale
2
Lynx GNU GPL
1699
che ognuno si crei una propria pagina di inizio e che si abbiano a disposizione anche localmente
i file della guida.
Queste indicazioni potrebbero apparire come negli esempi seguenti.
STARTFILE:file://localhost/etc/lynx-inizio.html
HELPFILE:file://localhost/usr/share/doc/lynx/lynx_help/lynx_help_main.html
DEFAULT_INDEX_FILE:file://localhost/etc/lynx-indice.html
In tutti i casi mostrati, si fa riferimento a un file nell’elaboratore locale, localhost. Nel primo caso si fa riferimento al file ‘/etc/lynx-inizio.html’, nel secondo a ‘/usr/share/
doc/lynx/lynx_help/lynx_help_main.html’, nel terzo a ‘/etc/lynx-indice.html’.
Probabilmente, tutto il resto può essere lasciato come si trova.
159.3.1 Avvio di Lynx
lynx
[opzioni] [risorsa_iniziale]
Lynx si compone in pratica dell’eseguibile ‘lynx’. Questo può essere avviato con l’indicazione
di un indirizzo iniziale (di solito una pagina), espresso secondo lo standard URI, oppure può
trattarsi semplicemente di un file indicato senza formalità particolari. Se non è indicato alcun file
iniziale, viene utilizzato quanto specificato nella configurazione contenuta nel file ‘lynx.cfg’,
alla voce ‘STARTFILE’.
Per approfondire il funzionamento di Lynx si può consultare la pagina di manuale lynx(1) e
soprattutto la guida interna che si ottiene con il comando ‘lynx -help’.
Opzione
-anonymous
-cfg=file_di_configurazione
-ftp
-homepage=indirizzo_uri
-index=indirizzo_uri
-localhost
-term=terminale
-dump
Descrizione
Una particolarità di Lynx è la possibilità di concedere un numero limitato di funzionalità a utenti occasionali. Con questa
opzione, si fa in modo che Lynx possa essere utilizzato solo
come strumento di lettura ipertestuale, eliminando ogni possibilità di salvataggio di pagine o di dati e di stampa. Può essere
molto utile in quelle situazioni in cui si vuole permettere l’utilizzo del programma a persone non controllate, che non sono
state registrate nel sistema e che quindi non hanno un’utenza
corrispondente.
Permette di definire il file di configurazione, quando
non si vuole utilizzare quello predefinito corrispondente a
‘lynx.cfg’.
Disabilita l’utilizzo del protocollo FTP.
Permette di indicare una pagina iniziale differente da quella predefinita. Verrebbe utilizzata in particolare quando si
accede alla pagina principale.
Permette di indicare una pagina indice.
Impedisce l’accesso a indirizzi URI esterni all’elaboratore locale. In pratica, obbliga a rimanere all’interno dell’elaboratore
locale.
Normalmente, Lynx è in grado di determinare da solo il tipo di
terminale a disposizione, in modo da potervisi adattare. A volte questo riconoscimento non avviene correttamente; in quei
casi è necessario indicare espressamente il nome del terminale. Se utilizzando una console, o una finestra sotto X, non si
distingue il cursore, conviene provare indicando un terminale
‘vt100’.
Fa in modo che l’URI richiesto venga emesso attraverso lo
standard output, terminando subito dopo il funzionamento di
Lynx.
1700
Opzione
Descrizione
In condizioni normali, quando si utilizza l’opzione ‘-dump’
si ottiene alla fine del file l’elenco dei riferimenti ipertestuali contenuti nel documento. Con l’opzione ‘-nolist’ questi
vengono omessi.
-nolist
• $ lynx -term=vt100 file://localhost/home/tizio/indice.html
Avvia Lynx specificando il tipo di terminale (‘vt100’) e il file iniziale.
• $ lynx -dump file://localhost/home/tizio/indice.html
Fa in modo che Lynx restituisca attraverso lo standard output l’URI richiesto, dopo averlo
trasformato in un file di testo normale.
• $ lynx -dump -nolist file://localhost/home/tizio/indice.html
Come nell’esempio precedente, senza aggiungere in coda l’elenco dei riferimenti
ipertestuali contenuti nel documento.
• $ lynx
Avvia Lynx utilizzando esclusivamente la configurazione contenuta nel file ‘lynx.cfg’.
159.3.2 Funzionamento
Lynx permette l’utilizzo di una serie di comandi abbinati a tasti più o meno mnemonici. Non è
disponibile un menù, quindi occorre un minimo di preparazione prima di poter utilizzare Lynx.
L’abbinamento tra i comandi e i tasti corrispondenti è definito all’interno del file di
configurazione (‘lynx.cfg’), ma in generale conviene non alterare le definizioni predefinite.
Figura 159.1. Lynx dopo essere stato avviato con l’indicazione di un indirizzo specifico.
Clean the Clipper 5.2 (p1 of 80)
This page hosted by [gc_icon.gif] Get your own Free Home Page
_________________________________________________________________
[home] [step1][step2][step3] [step4][step5][step6] [step7][links]
Clean the Clipper 5.2
A different way to program using Clipper 5.2 without commands, that
is, without the file STD.CH.
All trade names referenced herein are either trademarks or registered
trademarks of their respective companies. In particular, Clipper
(CA-Clipper) is a registered trademark of Computer Associates
International.
!WARNING!
The informations contained inside this page are version dependent.
!WARNING!
_________________________________________________________________
-- press space for next page -Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
1701
La figura 159.1 mostra in che modo si presenta Lynx dopo essere stato avviato con l’indicazione
di una pagina HTML particolare. Nelle ultime righe dello schermo (o della finestra) appare un
riepilogo dei comandi principali. Prima di richiamare la guida (help) conviene configurare correttamente il file ‘lynx.cfg’ al riguardo: molto probabilmente i file della guida sono disponibili
localmente, mentre di solito la configurazione predefinita fa riferimento alla guida ottenibile attraverso la rete. Nella sezione dedicata alla configurazione è già stato spiegato come fare per
correggere questo particolare.
159.3.3 Navigazione e scorrimento del documento
La navigazione all’interno di un documento ipertestuale è relativamente semplice, anche se non
si può utilizzare il mouse. In particolare va ricordato l’uso dei tasti freccia, per cui [ freccia su ]
e [ freccia giù ] servono per spostare il cursore da un riferimento (link) a un altro, [ freccia sinistra ]
permette di tornare al documento precedente e [ freccia destra ] permette di seguire il riferimento su
cui si trova il cursore.
Lynx mantiene la traccia dei riferimenti attraverso cui si è giunti al documento attuale, [ Backspace ]
permette di visualizzarla in modo da poter selezionare un riferimento da lì.
Un’altra cosa importante è la possibilità di ottenere un elenco compatto di tutti i riferimenti contenuti nel documento visualizzato attualmente. Ciò si ottiene con il comando ‘LIST’ corrispondente
al tasto [ l ] oppure [ L ].
Figura 159.2. Il comando ‘LIST’ permette di ottenere un riassunto di tutti i riferimenti
contenuti nella pagina visualizzata.
List Page (p1 of 5)
List Page (Lynx Version 2.8.1pre.9), help
References in
file://localhost/home/daniele/Internet/www.geocities.com/SiliconValley
/7737/clipper52clean.html
1. http://www.geocities.com/
2. http://www.geocities.com/
3. (internal) in Clean the Clipper 5.2 - home
4. (internal) in Clean the Clipper 5.2 - step1
11. (internal) in Clean the Clipper 5.2 - links
12. http://www.cai.com/
13. (internal) in Clean the Clipper 5.2 - home
-- press space for next page -Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
La tabella 159.2 mostra l’elenco dei comandi utili per la navigazione di un documento
ipertestuale.
1702
Tabella 159.2. Elenco dei comandi di navigazione di Lynx.
Comando
Tastiera
freccia su
freccia giù
freccia sinistra
freccia destra
PREV_PAGE
pagina su
-
NEXT_PAGE
pagina giù
+
HOME
END
Home
Fine
Ctrl+a
Ctrl+e
Backspace
L
Descrizione
Sposta il cursore sul riferimento
precedente.
Sposta il cursore sul riferimento
successivo.
Torna al documento precedente.
Segue il riferimento su cui si trova il
cursore.
Visualizza la schermata precedente
del documento.
Visualizza la schermata successiva
del documento.
Visualizza l’inizio del documento.
Visualizza la fine del documento.
Visualizza i riferimenti seguiti precedentemente.
Visualizza un riassunto dei riferimenti contenuti.
Visualizza il documento iniziale
(main).
LIST
l
MAIN_MENU
m
INDEX_SEARCH
i
Visualizza il documento indice.
GOTO
g
INTERRUPT
z
RELOAD
Ctrl+r
REFRESH
Ctrl+l
WHEREIS
/
NEXT
n
Permette di indicare un indirizzo
URI da raggiungere.
Sospende un processo di I/O in
corso.
Ricarica il documento corrente.
Rigenera l’immagine visualizzata
sullo schermo.
Permette di cercare una stringa nel
documento.
La prossima corrispondenza della
stringa di ricerca.
Ctrl+w
159.3.4 Salvataggio, stampa e sorgenti
Il documento visualizzato può essere salvato o stampato in vari modi. Il comando di stampa
viene richiamato utilizzando il tasto [ p ], attraverso il quale si accede a un menù da cui è possibile
scegliere il tipo di stampa. In particolare potrebbe essere possibile anche l’invio di una copia a
un indirizzo di posta elettronica, o il salvataggio su un file.
Quando Lynx carica un documento, lo trasforma immediatamente nel formato da visualizzare.
Per ottenere il sorgente di quel documento occorre ripetere l’operazione di caricamento senza alcuna trasformazione. Questo si ottiene con il tasto [ \ ]. Una volta ottenuto un documento
visualizzato come si vuole, si può stampare (o salvare) nel modo visto poco sopra.
1703
Figura 159.3. Il sorgente della pagina può essere visualizzato dopo un’ulteriore
operazione di caricamento.
(p1 of 96)
<HTML>
<HEAD>
<TITLE>Clean the Clipper 5.2</TITLE>
<META NAME="description" CONTENT="Cleaning the code of your Clipper 5.2 prog
+rams from commands: no more the STD.CH.">
<META NAME="keywords" CONTENT="xBase, dBase, Clipper, CA-Clipper">
<META NAME="Author" CONTENT="Daniele Giacomini - daniele @ evo . it">
<META NAME="Description" CONTENT="Cleaning the code of your Clipper 5.2 prog
+rams from commands: no more the STD.CH.">
<META NAME="KeyWords" CONTENT="xBase, dBase, Clipper, CA-Clipper">
</HEAD>
<BODY>
<CENTER>This page hosted by <A HREF="http://www.geocities.com/"><IMG SRC=
+"gc_icon.gif" BORDER=0 HEIGHT=31 WIDTH=88 ALIGN=CENTER></A>
Get your own <A HREF="http://www.geocities.com/">Free Home Page</A>
<HR><A NAME="home"></A>[<A HREF="#home">home</A>] [<A HREF="#step1">step1</
+A>][<A HREF="#step2">step2</A>][<A HREF="#step3">step3</A>]
[<A HREF="#step4">step4</A>][<A HREF="#step5">step5</A>][<A HREF="#step6">step6
+</A>]
[<A HREF="#step7">step7</A>][<A HREF="#links">links</A>] </CENTER>
Currently viewing document source. Press ’\’ to return to rendered version.
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
Un documento, o più in generale un file, può essere caricato nella sua forma originale, normalmente per poterlo salvare. Questo si ottiene con il comando ‘DOWNLOAD’ abbinato normalmente
al tasto [ d ]: quando viene premuto si ottiene il caricamento del file a cui punta il riferimento
sul quale si trova il cursore in quel momento. Il file viene collocato in una posizione transitoria,
quindi viene richiesto all’utente cosa farne: salvarlo o altro. Anche quando si vuole avere un documento HTML senza trasformazioni conviene utilizzare questo sistema. Infatti, il caricamento
del sorgente con il tasto [ \ ] espande i caratteri di tabulazione.
Tabella 159.3. Elenco dei comandi di stampa e salvataggio di Lynx.
Comando
Tastiera
PRINT
p
SOURCE
\
DOWNLOAD
d
D
Descrizione
Stampa o salva il documento così
come appare.
Carica e visualizza il sorgente del
documento.
Carica il file a cui punta il riferimento evidenziato.
159.3.5 Menù di opzioni
Con il comando ‘OPTIONS’, normalmente richiamabile con il tasto [ o ], è possibile ottenere il
menù delle opzioni, attraverso il quale è poi possibile modificare alcuni comportamenti di Lynx.
La figura 159.4 mostra un esempio di ciò che può apparire. In particolare, per richiamare una
voce da modificare, si utilizza il tasto corrispondente alla lettera maiuscola della voce stessa.
1704
Figura 159.4. Durante il funzionamento, Lynx può essere configurato parzialmente.
Options Menu (Lynx Version 2.8.4rel.1)
Accept Changes - Reset Changes Left Arrow cancels changes HELP!
Save options to disk: [_]
(options marked with (!) will not be saved)
General Preferences
User mode
Editor
Type of Search
Cookies (!)
:
:
:
:
[Novice......]
__________________________________________
[Case insensitive]
[ask user..]
Keyboard Input
Keypad mode
Emacs keys
VI keys
Line edit style
:
:
:
:
[Numbers act as arrows.............]
[OFF]
[OFF]
[Bash-like Bindings]
Display and Character Set
Display character set
: [Western (ISO-8859-1)...........]
Assumed document character set(!): [iso-8859-1......]
Raw 8-bit (!)
: [ON.]
X Display (!)
: __________________________________________
Document Appearance
Show color
Show cursor
Popups for select fields
HTML error recovery (!)
Show images (!)
Verbose images
:
:
:
:
:
:
[ON....]
[OFF]
[ON.]
[strict (SortaSGML mode)]
[as labels]
[show filename]
Headers Transferred to Remote Servers
Personal mail address
: __________________________________________
Preferred document character set : _________________________________
Preferred document language
: _________________________________
User-Agent header (!)
: __________________________________________
Listing and Accessing Files
FTP sort criteria
Local directory sort criteria
Show dot files
Show transfer rate (!)
:
:
:
:
Special Files and Screens
Multi-bookmarks
Bookmarks file (!)
Visited Pages
: [OFF.....]
: __________________________________________
: [By Last Visit Reversed.]
[By Name]
[Mixed style......]
[OFF]
[Show KB/sec, ETA...]
Check your lynx.cfg here
Accept Changes - Reset Changes Left Arrow cancels changes
159.3.6 Segnalibro
I riferimenti più importanti possono essere salvati in un file apposito. Il nome e la posizione di
questo file è definito nel file di configurazione ‘lynx.cfg’ e comunque può essere cambiato con
il menù di configurazione appena descritto.
Per salvare un riferimento nel segnalibro, si utilizza il comando ‘ADD_BOOKMARK’ collegato normalmente al tasto [ a ]. Subito dopo viene richiesto di specificare cosa si intende salvare. Con il
1705
tasto [ d ] si intende salvare il riferimento alla pagina corrente, con il tasto [ l ] si intende salvare il
riferimento su cui si trova il cursore.
Per richiamare l’elenco dei riferimenti salvati, si utilizza semplicemente il tasto [ v ]. Mentre si
visualizza questo elenco, oltre che selezionare un riferimento, si può anche eliminare ciò che non
serve più, con il tasto [ r ].
159.3.7 Conclusione
Il funzionamento di Lynx viene concluso con il comando ‘QUIT’, [ q ], oppure ‘ABORT’, [ Q ]. Nel
primo caso viene chiesto di confermare la richiesta, mentre nel secondo ciò non avviene.
159.4 Links
Links 3 è un altro navigatore fatto per i terminali a caratteri, senza grafica. A differenza di Lynx
(del quale imita il suono del nome) ha una gestione migliore delle tabelle, che vengono incorniciate e rappresentate abbastanza bene; inoltre dispone di un menù a tendina, a cui si accede con
il tasto [ Esc ].
Links si compone in pratica dell’eseguibile ‘links’, che si avvia in modo simile a Lynx:
links
[opzioni] [risorsa_iniziale]
Il file iniziale va indicato in forma di URI; eventualmente, se si tratta di file locali si può indicare
il percorso senza URI. A ogni modo, l’URI di un file locale avrebbe la forma seguente:
file://percorso_del_file
Durante il funzionamento di Links, la navigazione con la tastiera è abbastanza intuitiva e anche
il mouse può essere utilizzato.
Tabella 159.4. Elenco dei comandi di navigazione di Links.
Tastiera
Ctrl+c
Esc
Ctrl+p
Ctrl+n
pagina su
pagina giù
freccia su
freccia giù
freccia destra
freccia sinistra
g
/
?
=
\
d
Maiuscole
Descrizione
Conclude il funzionamento.
Richiama il menù a tendina.
Fa scorrere il testo visualizzando una riga precedente.
Fa scorrere il testo visualizzando una riga successiva.
Fa scorrere il testo all’indietro di una schermata.
Fa scorrere il testo in avanti di una schermata.
Raggiunge il riferimento ipertestuale precedente.
Raggiunge il riferimento ipertestuale successivo.
Seleziona il riferimento ipertestuale evidenziato.
Torna indietro.
Richiede l’inserimento di un URI da raggiungere.
Richiede l’inserimento di una stringa di ricerca nella pagina attuale.
Come [ / ], ma ricerca all’indietro.
Mostra le informazioni sul documento.
Mostra il sorgente (si preme nuovamente per ritornare all’impaginazione
normale).
Consente di salvare il riferimento evidenziato in un file locale.
Consente di usare il mouse per le funzioni di copia-incolla standard.
Links può essere avviato utilizzando diverse opzioni nella riga di comando. Tuttavia, di solito
queste non si usano, potendo configurare il suo funzionamento attraverso il menù, ricordando poi
3
Links GNU GPL
1706
di salvare i cambiamenti selezionando l’apposita voce del menù: Save options. Le modifiche
vengono salvate nel file ‘~/.links/links.cfg’, che eventualmente può anche essere ritoccato
a mano, se si intuisce la sintassi delle sue direttive.
In generale, la prima cosa che conviene modificare è la codifica dei caratteri usata per la
visualizzazione, portandola normalmente a ISO 8859-1.
Figura 159.5. Links in funzione, con il menù di configurazione aperto.
File
View
Link
Downloads
Setup
Help
[successivo] [precedente] [inizio] [+--------------------+] [licenze]
[indice analitico] [tomo] [parte]
| Character set
> |
| Terminal options
|
----------------------------------| Network options
|-------------| Cache
|
Parte ii.
Int| Associations
> |
| File extensions > |
* 3
Introduzione all’uso dell’el|--------------------|
| Save options
|
* 3.1
Struttura
+--------------------+
* 4
* 3.2
Dispositivi per l’interazione tra l’utente e la macchina
* 3.3
Dispositivi di memorizzazione
* 3.4
Sistema operativo
* 3.5
Programmi applicativi
* 3.6
Riferimenti
Conversioni numeriche
file://a212.html
Figura 159.6. Esempio di visualizzazione di una pagina divisa in colonne attraverso una
tabella con Links.
LEGGI
E
DIFFONDI
LA
Lettera aperta al Ministro del
MIUR
La Redazione, Treviso, 6 giugno,
2002
[Logo LiNUX didattica]
Grazie per averci fatto visita
La Redazione di Software Libero
nella Scuola ;-)
Il sito originale è ospitato da
Keycomm: http://www.keycomm.it.
+--------------------------------------------------------------------------------------------+
|
Documentazione per la
|
Scuole
|
Informazioni
|
|
didattica
|
|
|
|------------------------------+-----------------------------+-------------------------------|
|
Appunti di informatica
|
IPCS - Besta - TREVISO
|
www.linuxvalley.it
|
| Libera D. Giacomini
|
|
|
|
|
ITIS E. Fermi - MANTOVA |
www.interlex.it
|
|
Le antologie dagli
|
|
|
| Appunti D. Giacomini
|
Altre esperienze di
|
punto-informatico.it
|
|
| scuole italiane
|
|
|
La rete: LiNUX per la
|-----------------------------|
UNESCO free software
|
| didattica U. Zanatta
|
Associazioni
| portal (ingl.)
|
|
|-----------------------------|
|
|
Masterizzare con LiNUX F. |
Amici di LiNUX
|
Lettera aperta al Ministro |
| Ferroni
|
| del MIUR
|
|
|
Associazione Software
|
La Redazione, Treviso, 6 |
|
Dispense su Samba F.
| Libero
| giugno, 2002
|
| Ferroni
|
|
|
|
|
Italian Linux Society
|
|
|
Linux facile D. Medri
|
|
|
|
|
PLUTO
|
|
|
|
|
|
|
|
ERLUG
|
|
|------------------------------+-----------------------------+-------------------------------|
|
Progetti e Materiali
|
Attività
|
Approfondimenti
|
|------------------------------+-----------------------------+-------------------------------|
|
I.F.T.S. - commercio
|
|
GNU home page Free
|
| elettronico
|
I documenti e le
| Software Foundation
|
1707
159.5 W3M
W3M 4 è un altro navigatore fatto per i terminali a caratteri, senza grafica. Anche in questo caso
la gestione delle tabelle è buona.
W3M si compone in pratica dell’eseguibile ‘w3m’, che si avvia in modo simile a Lynx:
w3m
[opzioni]
risorsa_iniziale
Il file iniziale va indicato in forma di URI; eventualmente, se si tratta di file locali si può indicare
il percorso senza URI.
Durante il funzionamento di W3M, la navigazione con la tastiera è abbastanza intuitiva e sono
disponibili anche altri comandi molto interessanti. Si veda la tabella 159.5.
Tabella 159.5. Alcuni dei comandi di W3M.
Tastiera
H
pagina su, b, Esc v
pagina giù, spazio, Ctrl+v
freccia su, Ctrl+p, k
freccia giù, Ctrl+n, j
Ctrl+b, h
Ctrl+f, l
J
K
<
>
,
.
Inizio, g
Fine, G
Ctrl+u, Esc Tab
Tab
Invio
a, Esc Invio
u
c
=
F
U
F
R
S
Esc s
s
o
Ctrl+s, /
Ctrl+r, ?
n
N
q
Q
4
W3M software libero con licenza speciale
Descrizione
Mostra il riepilogo dei comandi di navigazione.
Fa scorrere il testo all’indietro di una schermata.
Fa scorrere il testo in avanti di una schermata.
Porta il cursore sulla riga precedente.
Porta il cursore sulla riga successiva.
Porta il cursore sul carattere precedente.
Porta il cursore sul carattere successivo.
Fa scorrere il testo in alto di riga.
Fa scorrere il testo in basso di riga.
Fa scorrere il testo verso sinistra.
Fa scorrere il testo verso destra.
Fa scorrere il testo verso sinistra di una sola colonna.
Fa scorrere il testo verso destra di una sola colonna.
Raggiunge l’inizio del file.
Raggiunge la fine del file.
Raggiunge il riferimento ipertestuale precedente.
Raggiunge il riferimento ipertestuale successivo.
Accede al riferimento ipertestuale su cui si trova il cursore.
Salva il riferimento ipertestuale in un file.
Mostra alla base dello schermo l’URI corrispondente al
riferimento ipertestuale su cui si trova il cursore.
Mostra alla base dello schermo l’URI attuale.
Mostra le informazioni sull’URI attuale.
Cerca di elaborare una cornice (frame).
Permette di accedere a un URI da inserire manualmente.
Permette di accedere a un file da indicare manualmente.
Ricarica il documento.
Salva il documento su un file, come lo si vede sullo schermo.
Salva il documento su un file in forma originale.
Seleziona uno dei documenti visitati di recente.
Accede a una maschera di opzioni di funzionamento.
Richiede l’inserimento di una stringa di ricerca nella pagina
attuale.
Come [ / ], ma ricerca all’indietro.
Continua la ricerca in avanti.
Continua la ricerca all’indietro.
Conclude il funzionamento chiedendo conferma.
Conclude il funzionamento senza chiedere conferma.
1708
W3M può essere avviato utilizzando diverse opzioni nella riga di comando. Tuttavia, di solito
queste non si usano, potendo configurare il suo funzionamento attraverso il comando [ o ].
159.6 Altri clienti HTTP
Oltre a quelli descritti sono disponibili molti altri tipi di clienti HTTP. In particolare, è il caso di
segnalare Amaya (capitolo 264), Galeon e Mozilla.
Capitolo
160
Servente HTTP: Apache
Apache 1 è un servente HTTP derivato da quello di NCSA, che costituisce lo standard di fatto
per i sistemi GNU e molte altre piattaforme.
Le funzionalità che Apache mette a disposizione sono molte e di conseguenza la sua configurazione può anche essere complicata. Eventualmente, quando non ci sono esigenze particolari,
si può preferire l’installazione di un servente HTTP meno sofisticato, come Boa, descritto nel
capitolo 161.
160.1 Visione generale
Apache è costituito essenzialmente dall’eseguibile ‘httpd’, che si avvia di solito come demone
autonomo dal supervisore dei servizi di rete:
httpd
[opzioni]
Nelle sezioni seguenti si fa sempre riferimento a un’installazione in cui il servizio viene avviato
in modo indipendente dal supervisore dei servizi di rete. Eventualmente si può consultare la
documentazione originale per un’impostazione differente.
Opzione
-d directory_radice_del_servente
-f file_di_configurazione
Descrizione
Permette di definire la directory che funge come punto di partenza per il servizio che viene offerto. Questa è già stabilita in modo predefinito in fase di compilazione del programma e ciò dipende dalla scelta di chi ha compiuto questa operazione. Attraverso questa opzione, si può indicare in modo
esplicito una posizione diversa, che però può essere scavalcata dalla direttiva ‘ServerRoot’ del file di configurazione
‘httpd.conf’.
Permette di indicare in modo esplicito il file di configurazione che ‘httpd’ deve leggere ed eseguire prima di iniziare a
gestire il suo servizio. Se il file viene indicato utilizzando un
percorso relativo, se cioè manca la prima barra obliqua che
identifica la directory radice, si fa riferimento a una posizione
relativa che parte dalla directory ‘ServerRoot’, ovvero quella definibile con l’opzione ‘-d’.
Il valore predefinito di questa opzione, dipende dal modo
in cui è stato compilato il programma. In un sistema GNU
dovrebbe trattarsi di ‘/etc/apache/httpd.conf’.
Di solito, non occorre configurare nulla per vedere funzionare il servente in modo «normale»,
per la pubblicazione di qualche pagina senza esigenze particolari, ma la gestione di un sito vero
e proprio richiede quasi sempre un intervento nella configurazione.
Purtroppo, Apache gestisce più di un file configurazione e questo può creare un po’ di confusione.
In generale, questi file potrebbero trovarsi nella directory ‘/etc/apache/’ e si tratta almeno di:
‘httpd.conf’, ‘srm.conf’ e ‘access.conf’.
Prima di vedere i dettagli dell’impostazione del servente Apache, è il caso di descrivere alcune
caratteristiche che lo riguardano.
1
Apache software libero con licenza speciale
1709
1710
1. L’accesso al servizio HTTP avviene a partire da una parte del file system, che inizia dal
cosiddetto document root.
2. Il programma servente non esegue la funzione ‘chroot()’ in questa directory, pertanto è
possibile articolare le directory successive anche attraverso l’uso di collegamenti simbolici
in posizioni precedenti alla directory document root.
3. In linea di massima, ogni utente può realizzare una struttura personalizzata di documenti
HTML, a partire dalla propria directory personale (home).
4. Il servente è in grado di mettere in funzione dei programmi, detti CGI, per la gestione
interattiva di pagine HTML contenenti dei moduli.2
160.1.1 Struttura di directory
Nella configurazione di Apache si distinguono due directory che vengono definite attraverso un
nome particolare; si tratta di ServerRoot e DocumentRoot. A queste se ne affiancano altre che
derivano dalla configurazione consueta di questo programma servente.
• server root
La directory nota come server root è il punto di origine dei file amministrativi di Apache.
Viene dichiarata nel file ‘httpd.conf’ e gli altri file dichiarati all’interno di questo sono
intesi essere collocati in posizione relativa a tale directory.
• document root
La directory nota come document root è il punto di origine dei documenti HTML.
• Programmi CGI
Convenzionalmente, è opportuno collocare i programmi CGI in una posizione estranea
alla gerarchia che si articola a partire dalla directory document root, per facilitare la
configurazione della sua accessibilità.
• Icone di sistema
Il servente HTTP ha spesso la necessità di utilizzare icone per rappresentare delle informazioni in modo grafico, per esempio quando si visualizza il contenuto di una directory
appartenente alla gerarchia di document root. Sotto questo aspetto, è conveniente togliere
tali icone dalla struttura dei documenti normali, perché non fanno parte di questi.
• Documenti personali
In linea di massima è concesso agli utenti di creare una propria struttura di documenti
ipertestuali. La directory di partenza di questi documenti viene definita come user dir ed è
relativa alla directory personale di questi utenti. È importante tenere presente che gli utenti
hanno tale possibilità, per configurare opportunamente il servente in modo che questi non
possano creare danni.
2
moduli HTML.
1711
160.1.2 Avvio e conclusione dell’attività del servente
Come già descritto, il servizio viene gestito dal demone ‘httpd’ che può essere avviato direttamente dalla procedura di inizializzazione del sistema, oppure può essere controllato dal supervisore dei servizi di rete. In questo secondo caso, quando si fanno delle modifiche alla configurazione, non occorre fare in modo che ‘httpd’ le rilegga, perché è costretto a farlo ogni volta che
viene risvegliato dal supervisore dei servizi di rete.
Quando ‘httpd’ è indipendente dal supervisore dei servizi di rete (standalone), si può osservare
la presenza di una serie di processi ‘httpd’ discendenti da uno di origine.
# pstree -p[ Invio ]
init(1)-+-...
|
|-httpd(244)-+-httpd(859)
|
|-httpd(860)
|
|-httpd(861)
|
|-httpd(862)
|
‘-httpd(863)
|-...
...
Per fare in modo che tutti questi processi rileggano i file di configurazione, basta inviare un
segnale ‘SIGHUP’ a quello principale; in questo caso il numero 244.
# kill -HUP 244[ Invio ]
# pstree -p[ Invio ]
init(1)-+-...
|
|-httpd(244)-+-httpd(901)
|
|-httpd(902)
|
|-httpd(903)
|
|-httpd(904)
|
‘-httpd(905)
|-...
...
Come si può osservare, il processo ‘httpd’ principale rimane attivo, mentre quelli inferiori vengono conclusi e riavviati (lo si vede dal numero PID). Attenzione però: se si invia un segnale di
questo tipo al processo ‘httpd’ dopo aver modificato la configurazione in modo errato, questo
termina il suo funzionamento.
160.2 Configurazione essenziale con httpd.conf
‘httpd.conf’ è il file di configurazione principale di Apache. La sua collocazione dipende
dal modo in cui è stato compilato Apache, oppure dall’opzione ‘-f’ della riga di comando del
demone ‘httpd’. Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti.
Inoltre, nel capitolo 175 viene trattata la configurazione di Apache per la gestione di una cache
proxy, cosa che riguarda in modo particolare proprio questo file.
1712
160.2.1 Impostazioni varie
Alcune direttive sono importanti per definire se il demone ‘httpd’ funziona in modo autonomo
o meno; inoltre, nel primo caso, per sapere su quale porta deve restare in ascolto.
Tipo di gestione del demone
ServerType
{ standalone | inetd }
La direttiva ‘ServerType’ permette di informare Apache su come questo viene avviato: in
modo autonomo o attraverso il supervisore dei servizi di rete.3
ServerType standalone
Nell’esempio si mostra la dichiarazione per il funzionamento autonomo (standalone) che
corrisponde alla situazione più comune (e anche più adatta).
Porta del servizio
Port numero_porta
Si tratta dell’indicazione della porta (di solito è 80, corrispondente alla denominazione
‘http’), necessaria nel caso in cui il demone sia stato avviato in modo autonomo. Infatti,
diversamente, è il supervisore dei servizi di rete a stare in ascolto della porta corrispondente
al servizio ‘http’.
Port 80
Listen numero_porta
Se ‘httpd’ viene utilizzato in modo autonomo, è possibile richiedere che stia in ascolto
anche di un’altra porta, per mezzo della direttiva ‘Listen’.
Listen 80
Listen 8080
L’esempio mostra in che modo si possa indicare a ‘httpd’ di stare in ascolto sia della
porta 80 che della 8080; dove la seconda viene utilizzata normalmente per interrogare un
servente proxy.
Indirizzi numerici o nomi di dominio
HostnameLookups
{ on | off }
Permette di decidere se si intende annotare nei file delle registrazioni l’indirizzo numerico
o il nome dei nodi che accedono al servizio. Attivando questa direttiva (‘on’) si registrano i
nomi corrispondenti. L’attivazione di questa è necessaria se si intendono definire dei limiti
di accesso basati sul nome di dominio dei clienti, come si vede nell’esempio seguente:
HostnameLookups on
160.2.2 Identificazione
Spesso, un nodo che offre un servizio HTTP può essere identificato attraverso degli alias al nome
di dominio canonico. Nella configurazione è opportuno definire un nome corretto, che può corrispondere anche a un alias, purché sia valido. Nello stesso modo, è importante definire l’indirizzo
di posta elettronica presso cui può essere raggiunto l’amministratore del servizio (webmaster).
3
Quando ‘httpd’ viene controllato dal supervisore dei servizi di rete, per ogni richiesta bisogna aspettare l’avvio del
demone. Ciò genera un certo ritardo nelle risposte e può essere giustificato da particolari esigenze di sicurezza che si
possono attuare solo in questo modo.
1713
Webmaster
ServerAdmin email
La direttiva ‘ServerAdmin’ permette di definire l’indirizzo di posta elettronica dell’amministratore del servizio. Generalmente si tratterà dell’utente fittizio ‘webmaster’ che
dovrebbe essere ridiretto automaticamente all’utente ‘root’ dal sistema di gestione della
posta elettronica.
ServerAdmin [email protected]
L’utilità di utilizzare un indirizzo di posta elettronica specifico, sta nella facilità con cui poi
si intende il contesto a cui fanno riferimento questi messaggi.
Nome ufficiale del servente
ServerName nome_standard_del_servente
Attraverso questa direttiva si può dichiarare espressamente il nome di dominio del servente
HTTP. Può trattarsi alias di un alias definito nel sistema DNS, ma quello che conta è che si
tratti di un nome valido.
ServerName www.brot.dg
L’esempio dichiara che il nome del nodo che offre il servizio è www.brot.dg, anche se
magari il nome canonico di questo, secondo il DNS, è diverso. Quello che conta è che il
sistema DNS sia in grado di risolvere anche questo nome qui dichiarato.
160.2.3 Utenti
L’utilizzo di un servizio HTTP è qualcosa di prettamente anonimo, in quanto la natura di questo,
per cui tutto si traduce in semplici richieste seguite da risposte, impedisce una gestione sensata
di identificativi utente e delle parole d’ordine relative.
Utente e gruppo per l’accesso al servizio
User
{
Group
utente
{
| #n }
gruppo
| #n }
Queste due direttive permettono di definire l’utente e il gruppo fittizio da abbinare agli accessi fatti al servizio. In pratica, quando si legge un file HTML o si interpella un programma
CGI, lo si fa come se si fosse l’utente indicato da queste due direttive. Solitamente, per motivi di sicurezza, si utilizza l’utente e il gruppo ‘nobody’, oppure un utente e un gruppo
specifici per il servizio HTTP.
Se per qualche motivo si preferisce una notazione numerica, invece di indicare il nome
dell’utente e del gruppo si può usare il numero UID e GID, preceduto dal simbolo ‘#’.
User nobody
Group nobody
Perché queste direttive possano funzionare, occorre che il demone ‘httpd’ sia avviato con
i privilegi dell’utente ‘root’, altrimenti non ha modo di eseguire il cambiamento di utente
e gruppo, potendo solo continuare a funzionare con i privilegi ottenuti all’avvio.
1714
160.2.4 Collocazione e denominazione di file e directory
Il file ‘httpd.conf’ contiene l’indicazione della directory server root, della posizione dei file
delle registrazioni ed eventualmente anche degli altri file di configurazione.
ServerRoot
ServerRoot directory
Rappresenta la directory a partire dalla quale si diramano le informazioni sulla configurazione, sulla registrazione degli eventi e simili. Corrisponde solitamente a qualcosa come ‘/etc/httpd/conf/’ o ‘/etc/apache/’. Potrebbe essere definita anche attraverso
l’opzione ‘-d’ della riga di comando di ‘httpd’.
ServerRoot /etc/apache
L’esempio mostra la posizione più conveniente di questa directory per aderire allo standard
FHS sulla struttura del file system.
Altri file di configurazione
ResourceConfig config_srm
AccessConfig config_access
Le direttive mostrate servono per definire rispettivamente il nome e la collocazione del file
di configurazione delle risorse e del file di configurazione degli accessi. Generalmente, i
nomi e la collocazione di questi file non devono essere dichiarate espressamente, perché è
sufficiente quanto risulta predefinito all’interno del programma stesso.
ResourceConfig
AccessConfig
conf/srm.conf
conf/access.conf
L’esempio mostra la dichiarazione esplicita dei nomi utilizzati per gli altri file di configurazione. Mancando l’indicazione di un percorso assoluto, si intende che debbano essere
discendenti della directory server root.
File delle registrazioni
ErrorLog registro_degli_errori
TransferLog registro_dei_trasferimenti
Queste direttive definiscono i nomi e la collocazione dei file delle registrazioni. Generalmente i percorsi indicati sono relativi, in tal caso si riferiscono alla directory server root
come punto iniziale.
ErrorLog
TransferLog
/var/log/apache/error_log
/var/log/apache/access_log
L’esempio mostra la dichiarazione dei due file delle registrazioni, con un percorso assoluto:
‘/var/log/apache/’.
Processo del demone principale
PidFile file_pid
Definisce il nome e la collocazione del file utilizzato per contenere il numero di processo
del demone ‘httpd’ principale, quando questo funziona in modo autonomo.
PidFile /var/run/httpd.pid
L’esempio mostra l’indicazione del file ‘/var/run/httpd.pid’, con un percorso
assoluto, in modo da non finire al di sotto della directory server root.
1715
Comunicazione interna
ScoreBoardFile file_di_informazioni
Definisce il nome e la collocazione di un file contenente una serie di informazioni sul
funzionamento corrente del programma servente, necessarie al servente stesso per la
comunicazione tra processi.
ScoreBoardFile /var/run/apache_status
L’esempio mostra l’indicazione del file ‘/var/run/apache_status’, con un percorso
assoluto, in modo da non finire al di sotto della directory server root.
160.3 Configurazione delle risorse con srm.conf
Il file ‘srm.conf’ è il file di configurazione delle risorse di Apache. Viene letto subito dopo
quello di configurazione del servente. Definisce in particolare dove si trovino i documenti (la
directory document root e quella delle pagine degli utenti), gli alias di directory speciali e altre
informazioni correlate. La sua collocazione dipende dal modo in cui è stato compilato Apache,
oppure dalla direttiva ‘ResourceConfig’ del file ‘httpd.conf’.
Nelle edizioni più recenti di Apache, le direttive del file ‘srm.conf’ possono risiedere
direttamente nel file ‘httpd.conf’.
Nelle sezioni seguenti vengono descritte solo alcune direttive più importanti.
160.3.1 Documenti HTML
La funzione principale di ‘srm.conf’ è quella di definire la collocazione dei documenti
ipertestuali, oltre ad altre informazioni di contorno.
DocumentRoot
DocumentRoot directory_iniziale_documenti_html
La direttiva ‘DocumentRoot’ dichiara la directory da cui si possono diramare i documenti
HTML (per qualche motivo oscuro, è importante che non abbia la barra obliqua finale).
DocumentRoot /home/httpd/html
L’esempio mostra il caso in cui la directory ‘/home/httpd/html/’ corrisponda all’inizio
dei documenti HTML.
Pagine personali degli utenti
UserDir
{
directory_iniziale_documenti_utenti
| DISABLED [utente] }
La direttiva ‘UserDir’ dichiara la directory, relativamente alla posizione della directory
personale di ogni utente, all’interno della quale ognuno può collocare i propri documenti
HTML personali. Si accede a questi utilizzando l’URI ‘http://host /~utente ’.
UserDir public_html
L’esempio mostra la dichiarazione tipica di questa direttiva e significa che ogni utente può
creare la directory ‘~/public_html/’ all’interno della quale collocare le proprie pagine.
Supponendo di accedere all’URI ‘http://www.brot.dg/~tizio/elenco.html’ si
fa riferimento effettivamente al file ‘~tizio/public_html/elenco.html’. In questo
modo, tra le altre cose, si evita di esporre l’intera directory personale dell’utente.
1716
UserDir DISABLED
L’esempio mostra in che modo possa essere impedito ai singoli utenti di creare le proprie
pagine HTML nella loro directory personale.
Quando si concede agli utenti di realizzare le loro pagine HTML personali, occorre tenere presente che questo fatto può costituire un problema di sicurezza del sistema: un
utente potrebbe creare un semplice collegamento simbolico verso un file o una directory
che, pur risultando leggibile a tutti gli utenti, non avrebbe dovuto essere accessibile al
mondo intero. A questo si può porre rimedio, ma per farlo occorre intervenire sul file
‘access.conf’, come verrà mostrato in seguito.
UserDir DISABLED root
A partire dalla versione 1.3 di Apache è possibile specificare a quali utenti vietare la costruzione di pagine HTML personali, come nell’esempio mostrato, in cui questo viene impedito
all’utente ‘root’.
160.3.2 Indici e file di informazioni
Quando si tenta di accedere a una directory, invece che a un file particolare, si ottiene l’indice del
contenuto, come se si trattasse del protocollo FTP, oppure il contenuto di una pagina predefinita.
File indice
DirectoryIndex file_indice ...
Quando si accede a una directory invece che a un file specifico, se questa contiene un file tra quelli elencati nella direttiva ‘DirectoryIndex’ viene restituito quel file, invece del
semplice elenco del contenuto. Solitamente si utilizza il nome ‘index.html’. Questo meccanismo permette di mascherare il contenuto effettivo della directory, oltre che di guidare
l’utente del servizio in modo che non si perda in una miriade di file.
DirectoryIndex index.html index.htm
L’esempio dichiara due file (‘index.html’ e ‘index.htm’) come possibili indici da
utilizzare quando si fa riferimento a una directory senza indicare un file specifico.
Indice grafico
FancyIndexing
{ on | off }
La direttiva ‘FancyIndexing’ permette di definire se, quando viene restituito l’elenco
del contenuto di una directory, si vuole una rappresentazione a icone, oppure se si vuole
un testo puro e semplice. La parola chiave ‘on’ attiva la visualizzazione a icone; ‘off’ la
disabilita.
FancyIndexing on
Definizione delle icone
AddIconByEncoding (sigla,file_icona ) tipo_codifica ...
Questa direttiva abbina un’icona a uno o più tipi di codifica. La sigla rappresenta una stringa da utilizzare al posto dell’icona quando non è possibile la sua rappresentazione (per
esempio se si usa il navigatore Lynx).
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (sigla,file_icona ) tipo_mime /sottotipo
1717
Questa direttiva abbina un’icona a un tipo e sottotipo MIME, eventualmente utilizzando
l’asterisco nel sottotipo per includerli tutti. La sigla rappresenta una stringa da utilizzare al
posto dell’icona quando non è possibile la sua rappresentazione.
AddIconByType
AddIconByType
AddIconByType
AddIconByType
(TXT,/icons/text.gif) text/*
(IMG,/icons/image2.gif) image/*
(SND,/icons/sound2.gif) audio/*
(VID,/icons/movie.gif) video/*
AddIcon file_icona estensione ...
Questa direttiva abbina un’icona a una o più estensioni del nome dei file.
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
AddIcon
/icons/binary.gif .bin .exe
/icons/binhex.gif .hqx
/icons/tar.gif .tar
/icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
/icons/compressed.gif .Z .z .tgz .gz .zip
/icons/a.gif .ps .ai .eps
/icons/layout.gif .html .shtml .htm .pdf
/icons/text.gif .txt
/icons/c.gif .c
/icons/p.gif .pl .py
/icons/f.gif .for
/icons/dvi.gif .dvi
/icons/uuencoded.gif .uu
/icons/script.gif .conf .sh .shar .csh .ksh .tcl
/icons/tex.gif .tex
/icons/bomb.gif core
AddIcon
AddIcon
AddIcon
AddIcon
/icons/back.gif ..
/icons/hand.right.gif README
/icons/folder.gif ^^DIRECTORY^^
/icons/blank.gif ^^BLANKICON^^
DefaultIcon file_icona
Questa direttiva permette di definire un’icona predefinita per i file che non rientrano in una
classificazione diversa.
DefaultIcon /icons/unknown.gif
File da ignorare
IndexIgnore modello_da_ignorare ...
Quando si consente di accedere a una directory visualizzandone il contenuto (perché manca
il file ‘index.html’ o equivalente), si può fare in modo che alcuni file non appaiano in
elenco. Utilizzando questa direttiva, si possono indicare i modelli di file da non includere.
Per questo si possono usare i caratteri jolly consueti (punto interrogativo e asterisco).
IndexIgnore */.??* *~ *# */HEADER* */README* */RCS
L’esempio mostra l’esclusione dall’elenco di:
• tutti i file che iniziano con un punto e sono lunghi almeno tre caratteri, perché si vuole
continuare a includere il riferimento alla directory precedente;
• tutti i file che terminano con il simbolo tilde, che sono solitamente delle copie di
sicurezza di versioni precedenti;
• tutti i file che terminano con il simbolo ‘#’, dal momento che anche questi sono
generalmente copie di sicurezza di versioni precedenti;
• tutti i file il cui nome inizia per ‘HEADER’ o ‘README’, perché hanno un ruolo speciale;
• il file ‘RCS’.
File «readme»
HeaderName file_readme_iniziale
ReadmeName file_readme_finale
1718
Attraverso queste due direttive si possono specificare i nomi di file, il cui contenuto si vuole
sia incluso nell’elenco della directory. Per la precisione, la direttiva ‘HeaderName’ specifica
il nome di un file da mettere prima dell’elenco; la direttiva ‘ReadmeName’ specifica il nome
di un file da mettere dopo l’elenco. L’esempio permette di chiarire altri dettagli.
HeaderName HEADER
ReadmeName README
In questo caso, viene cercato prima il file ‘HEADER.html’. Se viene trovato, viene incluso
all’inizio dell’elenco della directory, mantenendo la formattazione HTML. Se manca, ma
esiste il file ‘HEADER’, questo viene incluso in modo testuale. La stessa cosa vale per il file
‘README.html’ o soltanto ‘README’, con la differenza che questo viene incluso alla fine,
dopo l’elenco.
160.3.3 Tipi di file
Il servente ha bisogno di conoscere il tipo di file che si preleva per sapere come comportarsi, ma
soprattutto per poterlo comunicare al cliente che lo ha richiesto. Questo si ottiene attraverso la
configurazione dei tipi MIME, ma è pur sempre necessario specificare il tipo predefinito, quando
non si riesce a determinarlo altrimenti.
Tipo predefinito
DefaultType tipo_e_sottotipo_mime ...
Permette di definire il tipo MIME predefinito di un documento per il quale non si riesca a
identificare diversamente. Di solito questo valore predefinito è ‘text/plain’.
DefaultType text/plain
Aggiunta di tipi nuovi
AddType tipo_mime /sottotipo estensione
Con questa direttiva si possono aggiungere dei tipi MIME senza intervenire nel file di definizione di questi, ‘mime.types’. Generalmente non è conveniente intervenire in questo
modo; è sempre meglio utilizzare il file dei tipi MIME.
Codifica
AddEncoding tipo_di_compressione estensione
Questa direttiva permette di abbinare un’estensione a un tipo di codifica. Ciò permette ad
alcuni programmi cliente di sapere come gestire tali dati.
AddEncoding x-compress Z
AddEncoding x-gzip gz
L’esempio mostra la configurazione tipica, che serve a informare i programmi cliente
quando viene inviato loro un file compresso con ‘compress’ o con ‘gzip’.
160.3.4 Directory alias
Per evitare confusione, oltre che per motivi di sicurezza, è opportuno dichiarare alcune directory
speciali in forma di alias.
Alias normale
Alias directory_fasulla directory_reale
1719
Questo tipo di direttiva, che può essere ripetuta, permette di definire delle directory in posizioni diverse da quelle reali. La directory fasulla fa riferimento a una directory indicata
nell’indirizzo URI richiesto, mentre quella reale indica la directory effettiva nel file system.
Alias /icons/ /home/httpd/icons/
L’esempio mostra la dichiarazione di una directory cui si accede attraverso l’alias
‘/icons/’. In pratica, tutte le volte che viene richiesta una risorsa contenuta nella directory
‘/icons/’, questa verrà prelevata dalla directory reale ‘/home/httpd/icons/’.
La dichiarazione dell’alias ‘/icons/’ è molto importante nella consuetudine, dal momento
che si tratta del riferimento alla directory contenente le icone utilizzare per la visualizzazione degli indici. Si è visto in un’altra sezione la dichiarazione dell’abbinamento delle
icone a seconda dell’estensione dei file, come nell’esempio seguente, dove si fa riferimento
a questo alias.
AddIcon /icons/binary.gif .bin .exe
Alias per i programmi CGI
ScriptAlias directory_fasulla directory_reale
Funziona come la direttiva ‘Alias’, ma si riferisce ai programmi CGI. Generalmente, i programmi CGI dovrebbero essere collocati esclusivamente all’interno di directory dichiarate
attraverso questa direttiva, per non rischiare di creare problemi di sicurezza del sistema.
ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/
160.3.5 Gestori specifici in base all’estensione
È possibile stabilire un comportamento particolare in base all’estensione dei file. Con questo si
intende qualcosa di diverso dalla semplice lettura e invio al cliente che ne fa richiesta. La sintassi
generale è la seguente:
AddHandler nome_dell’azione estensione
Il nome dell’azione definisce un tipo preciso di operazione da abbinare ai file che contengono
l’estensione indicata.
Esecuzione di programmi CGI
AddHandler cgi-script estensione
Questa direttiva, usata così, permette di abbinare a un’estensione l’esecuzione automatica
come programma CGI. È decisamente sconsigliabile di permettere l’utilizzo di programmi CGI al di fuori della directory dichiarata con la direttiva ‘ScriptAlias’. L’esempio
seguente mostra questa direttiva commentata opportunamente per sicurezza.
#
AddHandler cgi-script .cgi
160.3.6 Configurazione di accesso della directory
È possibile definire il nome di un file di configurazione che, se presente, serve per definire l’accesso alla directory in cui si trova. Il nome predefinito di questo è ‘.htaccess’. Per questo si
utilizza la direttiva ‘AccessFileName’, come nell’esempio seguente:
AccessFileName .htaccess
1720
160.3.7 File di messaggi
In occasione di determinate situazioni errore, il programma servente emette delle segnalazioni di
errore. Questi messaggi possono essere riscritti in forma di file HTML o di programma CGI. La
direttiva per controllare questi messaggi ha tre sintassi possibili.
ErrorDocument n_errore file_alternativo
ErrorDocument n_errore uri_esterno
ErrorDocument n_errore "messaggio
Nel primo caso, l’ultimo argomento è un file HTML o un programma CGI; nel secondo si tratta
di un URI esterno; nel terzo si tratta di una stringa, che viene identificata come tale perché inizia
con gli apici doppi (‘"’). La stringa non deve essere terminata, a meno di volere fare apparire gli
apici doppi finali.
ErrorDocument 500 "Errore del servente www.
L’esempio mostra il caso in cui si voglia fare apparire una stringa particolare in occasione del
verificarsi dell’errore 500.
ErrorDocument 404 /documento_mancante.html
In
questo
caso,
in
occasione dell’errore 404, viene inviato al cliente
‘documento_mancante.html’ che conterrà qualche utile suggerimento per l’utente.
il
file
ErrorDocument 404 /cgi-bin/documento_mancante.pl
Questa è una variante dell’esempio precedente, in cui, invece di inviare un file HTML viene
eseguito un programma CGI, ‘/cgi-bin/documento_mancante.pl’. Ciò può essere utile per
comporre una risposta personalizzata, utilizzando le informazioni cui può accedere il programma
stesso.
ErrorDocument 404 http://roggen.brot.dg/cgi-bin/documento_mancante.pl
Questa è una variante dell’esempio precedente, in cui si fa riferimento a una risorsa contenuta in
un URI esterno al servente dove si manifesta il problema.
160.4 Controllare l’accesso con access.conf
‘access.conf’ è il file di configurazione globale che permette di controllare l’accesso alle directory del sistema. La sua sintassi è diversa da quella degli altri due file di configurazione già visti.
In particolare, oltre a normali direttive, si utilizzano dei delimitatori simili a marcatori HTML
che permettono di definire il contesto a cui si riferiscono le direttive contenute. Più precisamente
si parla di sezioni.
Nelle edizioni più recenti di Apache, le direttive del file ‘access.conf’ possono risiedere
direttamente nel file ‘httpd.conf’.
160.4.1 Sezioni di controllo
Le sezioni del file di configurazione degli accessi hanno una forma simile a quella seguente:
<Nome
...> ...
</Nome>
Nel marcatore che ne dichiara l’apertura possono apparire delle opzioni; nella parte compresa
tra l’apertura e la chiusura si inseriscono delle direttive riferite a quella sezione particolare. A
1721
seconda del contesto, una sezione può contenere anche la dichiarazione di altre sezioni in modo
annidato.
160.4.2 Sezione «Directory»
Le sezioni ‘Directory’ raccolgono le direttive di controllo per una particolare directory e per
quelle successive. La direttiva di apertura, ovvero il marcatore ‘<Directory>’, deve contenere
l’indicazione della directory a cui si riferiscono le direttive della sezione, eventualmente usando
anche i caratteri jolly (‘*’ e ‘?’) o le espressioni regolari estese.
<Directory /home/httpd/html>
Options Indexes FollowSymLinks
</Directory>
Questo esempio è il più comune: si dichiara una sezione riferita alla directory ‘/home/httpd/
html/’, che qui si vuole intendere corrispondere alla document root.
<Directory "^/home/httpd/html/[0-9]{3}">
</Directory>
Questo esempio ulteriore, attraverso un’espressione regolare, dichiara una sezione riferita a tutte
le directory discendenti di ‘/home/httpd/html/’ che iniziano con tre cifre numeriche.
Quando una sezione si riferisce a una porzione già presa in considerazione da un’altra analoga,
conviene che queste appaiano in una sequenza tale da porre prima le sezioni generali e dopo
quelle più particolareggiate, come nell’esempio seguente:
<Directory />
AllowOverride None
</Directory>
...
AllowOverride All
</Directory>
Di seguito sono descritte alcune delle direttive che possono essere usate all’interno della sezione
‘Directory’.
Options
Options
[+|-]opzione ...
La direttiva ‘Options’ permette di definire alcune opzioni in forma di parole chiave. La
tabella 160.2 ne riporta l’elenco. In particolare, le opzioni ‘None’ e ‘All’ vanno usate da
sole.
Tabella 160.2. Alcune opzioni della direttiva ‘Options’ nella sezione ‘Directory’.
Parola chiave
None
All
FollowSymLinks
SymLinksIfOwnerMatch
ExecCGI
Indexes
Includes
IncludesNOEXEC
Significato
Disabilita tutto.
Abilita tutte le opzioni.
Abilita l’uso di collegamenti simbolici.
Abilita l’uso di collegamenti simbolici solo se il
proprietario coincide.
Permette l’esecuzione dei programmi CGI.
Permette di ottenere il listato del contenuto.
SSI è permesso.
SSI è permesso in parte.
Generalmente, se più direttive ‘Options’ possono applicarsi alla stessa directory, quella
riferita alla directory più specifica si sostituisce completamente alle altre. Tuttavia, se tutte
1722
le opzioni vengono precedute dal segno ‘+’ o ‘-’, queste vengono unite a quelle già dichiarate. Le opzioni precedute dal segno ‘+’ vengono aggiunte; quelle precedute dal segno ‘-’
vengono eliminate. In ogni caso, per facilitare la lettura sarebbe opportuno dichiarare ogni
volta le opzioni che si vuole siano abilitate.
L’esempio seguente mostra la semplice dichiarazione della directory ‘/home/httpd/
html/’ (corrispondente a document root), in cui è consentito visualizzare il listato del
contenuto e seguire i collegamenti simbolici.
</Directory>
AllowOverride
AllowOverride opzione ...
La direttiva ‘AllowOverride’ permette di definire quali opzioni possono essere scavalcate dalle dichiarazioni particolari contenute nei file di accesso delle singole directory
(‘.htaccess’). La tabella 160.3 ne riporta l’elenco. In particolare, le opzioni ‘None’ e
‘All’ vanno usate da sole.
Tabella 160.3. Alcune opzioni della direttiva ‘AllowOverride’ nella sezione
‘Directory’.
Parola chiave
None
All
Options
Limit
AuthConfig
FileInfo
Indexes
Significato
Impedisce che qualunque direttiva venga scavalcata.
Permette che siano scavalcate tutte le direttive.
Permette l’uso della direttiva ‘Options’.
Permette l’uso di direttive di controllo sugli accessi.
Permette l’uso di direttive di autorizzazione.
Permette l’uso di direttive di controllo del tipo di
documento.
Permette l’uso di direttive di controllo sul listato delle
directory.
L’esempio seguente mostra la semplice dichiarazione della directory ‘/home/httpd/
html/’ (corrispondente a DocumentRoot), in cui è consentito visualizzare il listato del
contenuto e seguire i collegamenti simbolici. Per questa directory (e per le successive) non
è possibile scavalcare alcuna direttiva utilizzando i file ‘.htaccess’.
AllowOverride None
</Directory>
Autorizzazioni
Attraverso una serie di direttive è possibile definire l’autorizzazione all’accesso alla directory, fornendo un nominativo e una parola d’ordine. Questi nominativi e le parole d’ordine cifrate relative devono essere contenuti in un file creato con un programma apposito,
‘htpasswd’, ed è necessario che non coincidano con nominativi e parole d’ordine già utilizzati per accedere al sistema. Infatti, il programma cliente memorizza queste informazioni
la prima volta che vengono inserite, quindi le fornisce automaticamente a ogni richiesta.4
A fianco del file di utenti e parole d’ordine, si può creare un file di gruppi che serve solo
a facilitare la definizione delle autorizzazioni, quando si vuole fare riferimento a un intero
gruppo di utenti, senza doverli elencare.
AuthName nome
La direttiva ‘AuthName’ permette di definire un nome per identificare il contesto dell’autorizzazione. Questa descrizione viene data all’utente quando gli viene richiesto di inserire il
4
È bene ricordare che il protocollo HTTP è privo di stato, per cui a ogni richiesta si ricomincia da capo.
1723
nominativo e la parola d’ordine, in modo da permettergli di distinguere tra autorizzazioni
diverse che possono richiedere un’identificazione differente.
AuthType Basic
Questa direttiva è obbligatorie e specifica il tipo di autorizzazione.
AuthUserFile file_di_utenti_e_parole_d’ordine
Specifica un file da utilizzare come elenco di utenti e parole d’ordine. Questo file viene
creato e aggiornato utilizzando il programma ‘htpasswd’.
AuthGroupFile file_dei_gruppi
Specifica un file da utilizzare come elenco di gruppi abbinati agli utenti. Non contiene
parole d’ordine e viene creato in modo manuale.
require user utente ...
require group gruppo ...
require valid-user
Una di queste direttive stabilisce la necessità dell’identificazione attraverso un nominativoutente e una parola d’ordine. Nel primo caso si indicano precisamente quali utenti possono accedere, nel secondo quali gruppi di utenti e nel terzo si afferma semplicemente che
possono accedere tutti.
L’esempio seguente definisce un accesso ristretto e condizionato al riconoscimento degli
utenti. In particolare però, solo gli utenti ‘tizio’, ‘caio’ e ‘semproni’ possono accedere.
<Directory /home/httpd/html/riservato>
AllowOverride None
Options Indexes
AuthName "Informazioni riservate"
AuthType Basic
AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /etc/apache/.htgroup
require user tizio caio semproni
</Directory>
Limitazione dell’accesso
In origine, queste direttive erano consentite solo nella sezione ‘Limit’. Se vi appaiono
fuori, indicano che si riferiscono a qualunque metodo di accesso. Quando si utilizzano
queste direttive, se si intende fare uso di nomi di dominio è indispensabile avere attivato la risoluzione dei nomi di dominio attraverso la direttiva ‘HostnameLookups’ nel file
‘httpd.conf’.
order allow,deny
order deny,allow
order mutual-failure
In questo modo si specifica l’ordine in cui devono essere prese in considerazione le direttive
‘deny’ e ‘allow’. Quando si specifica la parola chiave ‘mutual-failure’, si intende che
possono accedere solo i nodi che appaiono nella lista ‘allow’ e non appaiono in quella
‘deny’.
deny from
{ all |
host ...
}
Impedisce l’accesso da parte dei nodi elencati. Se si usa la parola chiave ‘all’ si impedisce
a tutti di accedere. I nodi possono essere indicati attraverso il nome di dominio, completo o
parziale, e attraverso l’indirizzo numerico, completo o parziale.
allow from
{ all |
host ...
}
1724
Consente l’accesso da parte dei nodi elencati. Se si usa la parola chiave ‘all’ si consente a
tutti di accedere. I nodi possono essere indicati attraverso il nome di dominio, completo o
parziale, e attraverso l’indirizzo numerico, completo o parziale.
L’esempio seguente stabilisce il blocco all’accesso da parte degli utenti del dominio
mehl.dg, a partire dalla directory dichiarata nell’apertura della sezione ‘Directory’.
<Directory /home/httpd/html/polenta>
AllowOverride None
Options Indexes
order allow,deny
allow from all
deny from .mehl.dg
</Directory>
L’esempio seguente, invece, concede solo al dominio mehl.dg di poter accedere.
AllowOverride None
Options Indexes
order deny,allow
deny from all
allow from .mehl.dg
</Directory>
L’esempio seguente è una variante del precedente, in cui si utilizza anche l’indicazione di
una sottorete in forma di indirizzo numerico.
AllowOverride None
Options Indexes
order deny,allow
deny from all
allow from .mehl.dg 192.168.2.
</Directory>
160.4.3 Sezione «Limit»
Le sezioni ‘Limit’ sono usate per racchiudere un gruppo di direttive di controllo di accesso, che
riguardano solo i metodi specificati. I metodi di accesso in questione sono, per esempio, GET e
POST.
AllowOverride None
Options Indexes
AuthType Basic
AuthUserFile /etc/apache/.htpasswd
AuthGroupFile /etc/apache/.htgroup
<Limit GET POST>
require valid-user
</Limit>
</Directory>
L’esempio mostra che per la directory specificata è richiesta l’autenticazione solo in caso di
utilizzo dei metodi GET e POST.
Quando si vuole che le direttive di controllo di accesso riguardino tutti i metodi di accesso, non
si usa la sezione ‘Limit’.
1725
In linea di massima, la sezione ‘Limit’ può contenere ogni direttiva, a esclusione della dichiarazione ulteriore di sezioni ‘Directory’ e ‘Limit’ annidate. In pratica, si utilizzano solo direttive
per cui abbia senso porre un limite basato sul metodo di accesso. Generalmente ha significato
l’utilizzo delle direttive indicate nella tabella 160.4.
Tabella 160.4. Alcune direttive utili nella sezione ‘Limit’.
Direttiva
require
order
deny
allow
Descrizione
Utenti che possono accedere attraverso autenticazione.
Ordine di valutazione delle direttive ‘deny’ e ‘allow’.
Specifica i nodi a cui viene negato l’accesso.
Specifica i nodi a cui viene concesso l’accesso.
160.4.4 Sezione «Location»
Le sezioni ‘Location’ raccolgono le direttive di controllo per un URI particolare. Si tratta di
qualcosa molto simile alla sezione ‘Directory’, con la differenza che il riferimento è fatto
all’URI piuttosto che alla directory del file system effettivo.
Questa sezione viene usata prevalentemente per abilitare l’accesso allo stato del servente
attraverso l’indicazione di un URI, da parte di un particolare indirizzo autorizzato.
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from dinkel.brot.dg
</Location>
Nell’esempio viene concesso al nodo dinkel.brot.dg di accedere all’URI ‘/status’ cui è
abbinata la generazione e la restituzione di informazioni sul sistema. Il risultato potrebbe essere
qualcosa di simile a quello che segue.
1726
Apache Server Status for dinkel.brot.dg
Current Time: Sun Sep 28 14:00:47 1997
Restart Time: Sun Sep 28 14:00:28 1997
Server uptime: 19 seconds
Total accesses: 0 - Total Traffic: 0 B
CPU Usage: u0 s0 cu0 cs0
0 requests/sec - 0 B/second Scoreboard:
K___W__...........................................
..................................................
..................................................
Key:
"_" Waiting for Connection, "S" Starting up,
"R" Reading Request, "W" Sending Reply,
"K" Keepalive (read), "D" DNS Lookup, "L" Logging
2 requests currently being processed, 5 idle servers
Srv PID
Acc M CPU SS Conn Child Slot
Host
Request
0
8449 0/0/0 K 0.00 10 0.0 0.00 0.00
4
8453 0/0/0 W 0.00 0 0.0 0.00 0.00 dinkel.brot.dg GET /status HTTP/1.0
-----------------------------------------------------------------------Srv Server number
PID OS process ID
Acc Number of accesses this connection / this child / this slot
M
Mode of operation
CPU CPU usage, number of seconds
SS
Seconds since beginning of most recent request
Conn Kilobytes transferred this connection
Child Megabytes transferred this child
Slot Total megabytes transferred this slot
160.5 Controllare l’accesso con .htaccess
I file ‘.htaccess’ possono essere usati per definire delle configurazioni specifiche riferite alla
directory in cui si trovano. Non è necessario il loro utilizzo; si tratta solo di una possibilità, che
peraltro deve essere controllata attraverso la direttiva ‘AllowOverride’ nel file ‘access.conf’.
In linea di massima, i file ‘.htaccess’ possono contenere le direttive elencate nella tabella 160.5
Tabella 160.5. Alcune direttive utili nel file ‘.htaccess’.
Direttiva
Options
DefaultType
ErrorDocument
AuthName
AuthType
require
order
deny
allow
Descrizione
Opzioni varie.
Definisce il tipo e il sottotipo MIME predefinito per la
directory.
Ridefinisce la risposta in caso si verifichino condizioni di
errore.
Nome o descrizione di una zona soggetta ad autenticazione.
Definizione del tipo di autenticazione.
Dichiarazione degli utenti autorizzati all’autenticazione.
Ordine di valutazione delle direttive ‘deny’ e ‘allow’.
Specifica i nodi a cui viene negato l’accesso.
Specifica i nodi a cui viene concesso l’accesso.
1727
160.6 Considerazioni sulla sicurezza
Dalla descrizione dei file di configurazione di Apache si possono intuire i punti su cui agire
per cercare di ottenere un servizio HTTP relativamente «sicuro». Vale comunque la pena di
sottolineare alcune cose.
• Il demone ‘httpd’ viene avviato normalmente con i privilegi dell’utente ‘root’, quindi,
attraverso delle opportune chiamate di sistema, ‘httpd’ cambia questi privilegi portandoli a quelli dell’utente e del gruppo specificati con le direttive ‘User’ e ‘Group’ del file
‘httpd.conf’.
È molto importante che l’utente e il gruppo corrispondano a ‘nobody’, dove questo utente
fittizio deve corrispondere idealmente al «perfetto sconosciuto» che accede al sistema, oppure, ancora meglio, che si tratti di un utente apposito. In questa ottica devono poi essere
regolati i permessi delle directory.
• I file amministrativi di Apache, cioè quelli di configurazione e di registrazione degli eventi,
non devono essere accessibili in scrittura da parte degli utenti comuni (di qualunque tipo
siano, escluso ‘root’). Nello stesso modo, non devono essere modificabili le directory che
li contengono.
I file che compongono i documenti ipertestuali devono essere accessibili solo in lettura agli
utenti comuni, così le directory non devono essere modificabili, eccetto i permessi che può
avere l’utente ‘root’.
È consigliabile utilizzare la direttiva ‘SymLinksIfOwnerMatch’ per evitare brutti scherzi
da parte degli utenti che hanno la possibilità di creare documenti HTML a partire dalla loro
directory personale.
• È bene evitare di permettere l’utilizzo di programmi CGI al di fuori della directory definita
con la direttiva ‘ScriptAlias’ nel file ‘srm.conf’.
• È opportuno evitare di concedere agli utenti comuni di modificare le impostazioni attraverso
i file ‘.htaccess’. Si ottiene questo con la direttiva ‘AllowOverride None’.
Segue un esempio molto semplice della configurazione del file ‘access.conf’.
# Prima si impedisce l’accesso alla radice del file system.
<Directory />
AllowOverride None
Options None
order deny,allow
deny from all
</Directory>
# Si definisce la directory DocumentRoot.
Options Indexes SymLinksIfOwnerMatch
AllowOverride None
order deny,allow
allow from all
</Directory>
# Si concede di accedere alle directory personali degli utenti.
<Directory /home/*/public_html>
AllowOverride None
order deny,allow
allow from all
1728
</Directory>
# Si concede l’esecuzione ai programmi CGI che si trovano a
# partire dalla directory predisposta per questo.
<Directory /home/httpd/cgi-bin>
AllowOverride None
Options ExecCGI
order deny,allow
allow from all
</Directory>
# Si concede l’accesso alla directory contenente le icone di sistema.
<Directory /home/httpd/icons>
AllowOverride None
Options None
order deny,allow
allow from all
</Directory>
# Abilita la lettura dello stato del servente.
<Location /status>
SetHandler server-status
order deny,allow
deny from all
allow from .brot.dg
</Location>
Come si può osservare, non è stato consentito in alcun caso di utilizzare i file ‘.htaccess’ e i
collegamenti simbolici sono tollerati se il proprietario del collegamento equivale a quello del file
o della directory di destinazione. Inoltre sono state prese le misure seguenti:
• è impedito l’accesso a partire dalla directory radice del file system, obbligando a dichiarare
l’accesso alle directory successive;
• viene concesso l’accesso alla directory da cui si diramano i documenti ipertestuali;
• viene concesso espressamente l’accesso alle directory personali degli utenti;
• i programmi CGI possono essere eseguiti solo nella directory preposta a questo, il cui
contenuto risulta illeggibile;
• l’accesso alla directory contenente le icone utilizzate da Apache è stato dichiarato espressamente, altrimenti sarebbero risultate inaccessibili a causa del divieto iniziale sulla directory
radice;
• è stata abilita la lettura dello stato del servente, concedendo l’accesso solo al dominio
brot.dg.
160.7 Utilizzo del sistema di autenticazione
Il sistema di autenticazione del programma servente permette di consentire l’accesso a directory determinate solo a utenti identificati in base a un nome e a una parola d’ordine. È molto
importante capire come funziona il meccanismo, per non farsi delle illusioni sull’efficienza del
sistema.
1729
Figura 160.1. Il programma cliente chiede all’utente di identificarsi quando per la
prima volta ciò viene richiesto dal servente HTTP.
La prima volta che l’utente accede, il programma cliente gli presenta la richiesta di inserire il nominativo e la parola d’ordine, poi tutto funziona normalmente. Però, essendo il protocollo HTTP
privo di stato, non si instaura una connessione stabile; ogni richiesta è una connessione a parte
e ognuna di queste richiede un’autenticazione. In effetti, il programma cliente memorizza i dati inseriti dall’utente e continua a fornirli al servente HTTP. Questo fatto ha due implicazioni:
la parola d’ordine viaggia continuamente attraverso la rete; più utenti possono accedere simultaneamente da postazioni differenti, utilizzando la stessa identificazione e la stessa parola d’ordine.
Sotto questo aspetto, è importante che le parole d’ordine che si adoperano per queste cose non
abbiano alcun nesso con quelle «serie».
Per gestire questo tipo di autenticazione, occorre generare un file di utenti e di parole d’ordine,
aggiungendo possibilmente anche un file di gruppi. Si utilizza il programma ‘htpasswd’ che
normalmente fa parte del pacchetto di Apache:
htpasswd
[-c]
file utente
‘htpasswd’ crea o aggiorna un file di utenti e di parole d’ordine per l’autenticazione degli accessi
a directory protette con il servente Apache. L’opzione ‘-c’ viene usata per creare il file la prima
volta, mentre si inserisce il primo utente. La parola d’ordine viene richiesta subito dopo l’avvio
del programma.
Vengono mostrati e descritti alcuni esempi.
# htpasswd -c passwd tizio[ Invio ]
Adding password for tizio.
New password:
Viene inserita la parola d’ordine seguita da [ Invio ].
Re-type new password:
Viene reinserita la parola d’ordine seguita da
corrente.
[ Invio ]
e si ottiene il file ‘passwd’ nella directory
# cat passwd[ Invio ]
tizio:njHIUkjjJLKn
Il file contiene solo i nomi degli utenti e le parole d’ordine cifrate relative.
# htpasswd passwd caio[ Invio ]
Quando si aggiungono utenti, non si utilizza l’opzione ‘-c’, altrimenti il file viene cancellato e
ricreato.
# htpasswd passwd caio[ Invio ]
1730
Lo stesso programma può essere usato per modificare la parola d’ordine di un utente già
registrato.
Per facilitare la gestione di utenti che utilizzano l’autenticazione per accedere a directory protette,
è possibile realizzare dei raggruppamenti e inserirli in un file senza parole d’ordine. Il formato
del file è molto semplice: ogni record è costruito secondo la sintassi seguente:
gruppo : utente ...
Quindi, i nominativi dei vari utenti sono separati da uno spazio, come nell’esempio seguente:
primo: tizio caio semproni
secondo: cane gatto topo
Nell’esempio sono dichiarati due gruppi: ‘primo’ e ‘secondo’. A ‘primo’ appartengono gli
utenti ‘tizio’, ‘caio’ e ‘semproni’; a ‘secondo’ appartengono gli utenti ‘cane’, ‘gatto’ e
‘topo’.
La configurazione delle directory che devono essere accessibili solo attraverso un’autenticazione, avviene nel file ‘access.conf’ in una sezione ‘Directory’. Sono indispensabili le direttive ‘AuthName’, ‘AuthType’ e ‘AuthUserFile’ con cui si dà un nome all’autenticazione,
si definisce il tipo e si indica il nome del file degli utenti e delle parole d’ordine. La direttiva
‘AuthGroupFile’ serve solo se si intende fare riferimento a gruppi di utenti.
AllowOverride None
Options Indexes
AuthType Basic
AuthUserFile /etc/apache/passwd
AuthGroupFile /etc/apache/group
require valid-user
</Directory>
La direttiva ‘require’ stabilisce a chi, tra gli utenti che sono dichiarati nel file di utenti e di
parole d’ordine, sia concesso di accedere. La parola chiave ‘valid-user’ rappresenta tutti gli
utenti che sono stati previsti. In alternativa possono essere elencati gli utenti a cui concedere
l’accesso, come nell’esempio seguente;
require user tizio caio semproni
oppure si può indicare il nome di uno o più gruppi.
require group primo terzo quinto
Solo nell’ultimo caso è necessario predisporre e dichiarare la posizione del file dei gruppi.
1731
160.8 Siti virtuali
Apache è in grado di gestire diversi siti virtuali indipendenti sullo stesso elaboratore. In pratica,
si distinguono diverse directory per le pagine HTML (diverse directory document root), dove
ognuna di queste viene selezionata in base al nome di dominio utilizzato per accedere al servizio.
Evidentemente, per arrivare a questo risultato, occorre che lo stesso elaboratore sia accessibile
utilizzando nomi di dominio differenti: si va dall’attribuzione di un semplice alias all’interno del
DNS (i record ‘CNAME’), fino alla sovrapposizione di indirizzi IP differenti sulle stesse interfacce
(con la conseguente attribuzione di nomi di dominio differenti). A proposito della gestione del
DNS, si vedano i capitoli 122 e 123.
Quanto visto su Apache fino a questo punto, riguarda la gestione di un sito unico: quello «reale».
Si osservi in particolare che la direttiva ‘DocumentRoot’ viene inserita nel file ‘srm.conf’. Per
definire dei siti virtuali alternativi si interviene nel file ‘httpd.conf’, attraverso delle sezioni
simili a quelle del file ‘access.conf’:
<VirtualHost nome_di_dominio >
direttiva_specifica
...
</VirtualHost>
In pratica, all’interno del marcatore di apertura dell’ambiente ‘VirtualHost’ si inserisce il nome del sito virtuale a cui si fa riferimento, mentre all’interno della sezione si inseriscono le
direttive specifiche per questo sito.
<VirtualHost prova.brot.dg>
ServerAdmin [email protected]
DocumentRoot /home/httpd/html2
ServerName prova.brot.dg
ErrorLog logs/prova.brot.dg-error_log
TransferLog logs/prova.brot.dg-access_log
</VirtualHost>
L’esempio mostra la predisposizione del sito virtuale prova.brot.dg. All’interno della
sezione si vedono le dichiarazioni:
• dell’indirizzo di posta elettronica dell’amministratore, con la direttiva ‘ServerAdmin’;
• della directory di partenza delle pagine HTML, con la direttiva ‘DocumentRoot’;
• del nome di dominio corretto per raggiungere il sito virtuale, con la direttiva
‘ServerName’;
• dei percorsi assoluti dei file delle registrazioni, con le direttive ‘ErrorLog’ e
‘TransferLog’.
È il caso di osservare la stranezza per la quale la direttiva ‘DocumentRoot’ può apparire nella
sezione ‘VirtualHost’ all’interno del file ‘httpd.conf’, mentre per il sito reale si usa il file
‘srm.conf’.
Nel momento in cui si dichiara l’utilizzo di una nuova directory per i dati (le pagine HTML), ci
si deve preoccupare anche di configurare l’accesso a tale directory. Questo si fa nel modo solito
all’interno del file ‘access.conf’. Seguendo l’esempio mostrato, potrebbe essere necessario
aggiungere la sezione seguente:
1732
<Directory /home/httpd/html2>
AllowOverride None
order deny,allow
allow from all
</Directory>
160.9 Riferimenti
• Apache
<http://www.apache.org/>
Capitolo
161
Servente HTTP: Boa
Boa 1 è un servente HTTP elementare ma efficace, in grado di offrire le funzionalità tipiche di
questo servizio. Si compone fondamentalmente di un demone, ‘boa’, e di un file di configurazione, ‘/etc/boa/boa.config’. Solitamente, al demone si affianca anche un programma utile
per la generazione degli indici: ‘boa_indexer’.
Nella sua semplicità, Boa mantiene alcune convenzioni comuni ad altri sistemi del genere. In particolare, esiste una directory di origine del programma servente (server root), intesa idealmente
come la directory corrente in diverse situazioni; nello stesso modo esiste una directory di origine
per i documenti pubblicati (document root).
Dalle direttive del file di configurazione si possono intendere in modo molto semplice le sue
caratteristiche.
161.1 Configurazione di Boa
Il file di configurazione di Boa va collocato in base alle scelte fatte in fase di compilazione. In
generale dovrebbe trattarsi precisamente di ‘/etc/boa/boa.conf’. Come in molti altri casi,
le righe vuote e quelle bianche sono ignorate, inoltre i commenti iniziano con il simbolo ‘#’ e
terminano alla fine della riga. Per il resto, le direttive possono avere una di queste due forme:
nome valore_assegnato
nome
Nel primo caso si attribuisce un valore a ciò che viene rappresentato dal nome a sinistra; nel
secondo si intende abilitare un’opzione booleana.
L’unica cosa che non si può modificare con la configurazione è la definizione della directory di
origine del servente, che viene definita in fase di compilazione del programma. In alternativa,
si può usare l’opzione ‘-c directory’ per imporla all’avvio del demone ‘boa’.
Nel seguito vengono descritte alcune delle direttive di configurazione di Boa.
Direttiva
Port n
Listen indirizzo_ip
User utente
Group gruppo
1
Boa GNU GPL
Descrizione
Stabilisce la porta di comunicazione attraverso la quale il demone deve restare in ascolto di richieste di connessione. Il
valore predefinito di questa è notoriamente 80. Se il numero
di questa porta è inferiore a 1024, il demone ‘boa’ deve essere
stato avviato con i privilegi dell’utente ‘root’.
Questa direttiva permette di limitare l’ascolto alle connessioni
dirette a un solo indirizzo IP locale particolare. Ciò potrebbe
servire per distinguere un servizio particolare per un solo dominio virtuale (ma la gestione dei domini virtuali conviene
attuarla in modo differente). In generale, non usando questa
direttiva, si fa in modo che Boa accetti connessioni destinate
a qualunque indirizzo che faccia capo al nodo in cui si trova a
funzionare.
Queste due direttive, servono rispettivamente per stabilire i
privilegi dell’utente e il gruppo da utilizzare per il funzionamento di Boa. In pratica, queste direttive hanno significato
solo se Boa è stato avviato inizialmente con i privilegi dell’utente ‘root’. In particolare, va osservato che l’utente e il gruppo possono essere specificati per nome o per numero (UID e
GID).
1733
1734
Direttiva
AccessLog registro_degli_accessi
VerboseCGILogs
CgiLog registro_errori_cgi
ServerName nome
DocumentRoot directory
VirtualHost
UserDir directory
DirectoryIndex file_indice
DirectoryMaker programma
Servente HTTP: Boa
Descrizione
Definisce la collocazione del file delle registrazioni degli accessi. Se non si usa un percorso assoluto, il punto di riferimento iniziale è la directory di origine del programma
servente.
Si tratta di un’opzione booleana. Se appare nel file di configurazione, serve a richiedere la registrazione dettagliata
dell’avvio e della conclusione dei programmi CGI.
Definisce la collocazione del file delle registrazioni relativo
agli errori dei programmi CGI. Per la precisione, vengono registrati in questo file i messaggi emessi attraverso lo standard
error di questi programmi. Se non si usa questa direttiva, i
messaggi in questione vengono perduti.
Il file indicato, andrebbe annotato opportunamente con tutto il
suo percorso assoluto; altrimenti si intende che la directory di
riferimento sia la directory di origine del programma servente.
Specifica il nome del nodo servente da inviare ai clienti,
se questo differisce da quanto prevederebbe la risoluzione
dell’indirizzo IP.
Stabilisce la directory di partenza per i documenti pubblicati
attraverso il servizio HTTP. Se non si indica un percorso assoluto, si intende che il riferimento iniziale sia relativo alla
directory di origine del servente.
Questa opzione booleana, se presente, fa in modo che le richieste di accesso abbiano di fronte una gerarchia differente,
in base all’indirizzo IP utilizzato effettivamente. Per la precisione, si tratta di ‘directory_origine_documenti /indirizzo_ip /’.
Per esempio, se con la direttiva ‘DocumentRoot’ è stata fissata come origine dei documenti la directory ‘/var/
www/’ e l’accesso proviene attraverso l’indirizzo IP locale
192.168.2.1, il programma cliente che ha fatto una richiesta
per l’indirizzo ‘http://192.168.2.1/’, vedrà in pratica la
directory ‘/var/www/192.168.2.1/’.
Stabilisce la directory di partenza per i documenti pubblicati
dagli utenti. Si tratta di ciò che poi si risolve con gli indirizzi nella forma ‘http://host /~utente /’. Solitamente si fa
riferimento alla directory ‘public_html/’.
Si tratta del nome del file da prendere in considerazione come
indice delle directory. In generale si tratta di ‘index.html’
e la sua presenza evita di mettere allo scoperto il contenuto
reale delle directory.
Questa direttiva serve a indicare quale programma usare per
generare il file HTML contenente l’indice dei file di una directory, quando non è già disponibile un file adeguato per questo
scopo (si veda la direttiva ‘DirectoryIndex’).
In generale, dovrebbe già essere disponibile per questo
scopo il programma ‘boa_indexer’ (‘/usr/lib/boa/
boa_indexer’); tuttavia è possibile realizzare il proprio,
tenendo conto che deve accettare due argomenti:
programma directory_da_indicizzare titolo
MimeTypes file
Si intuisce che il primo argomento sia indispensabile, mentre
il secondo rappresenti solo un elemento opzionale, che non
è indispensabile alla costruzione dell’indice. Naturalmente,
il programma in questione, deve emettere la pagina HTML
attraverso lo standard output.
Questa direttiva serve per fornire la collocazione del file
dei tipi MIME. In condizioni normali si tratta di ‘/etc/
mime.types’, ma va comunque indicato.

rpc.mountd - Proglinux

Transcript

Documenti analoghi

guida winmx

Corso Citect - Schneider Electric

COnFiGuRAziOne COn LineA ADSL PPPOA/PPPOe

Sms, passione e pericoli. Per molti è diventata una

CA Nimsoft Monitor per IBM Power Systems

MSN Switch - EB elettronica Srl

Panis angelicus (Messa Solenne Op.12) (César Auguste

Configurazione ADSL Zyxel ADSL Router 650R

UserID e password sono quelle che ti sono state communicate dal

Guida alla configurazione Outlook POP