Nel capitolo 91 è già stato descritto questo servizio, parte della sua configurazione e il funzionamento del tipico client per questo protocollo. In questo capitolo si vuole approfondire un po' la configurazione e la gestione di questo servizio, quando si utilizza il server FTP della Washington University (WU-FTP).
Prima di vedere i dettagli dell'impostazione del server è il caso di ripassare in breve il suo funzionamento.
In linea di principio è ammesso l'accesso a utenti registrati e a utenti anonimi; se si tratta di utenti registrati, questi devono disporre di una shell valida e deve esistere una password.
Non possono accedere gli utenti elencati nel file /etc/ftpusers
.
L'accesso anonimo può avvenire solo se è stato previsto l'utente ftp
.
Quando l'accesso viene fatto da un utente registrato, la directory iniziale che gli appare è la sua directory personale (home), ma può attraversare anche altre directory se i permessi lo consentono.
L'utente anonimo non ha diritto di accedere ad altre directory che non siano quelle che si diramano da quella stabilita per l'utente fittizio ftp
. Per questo, la directory personale dell'utente anonimo corrisponde per lui alla radice del servizio FTP.
Nel capitolo 91 è già stata descritta la struttura fondamentale della directory iniziale del servizio FTP anonimo, senza però spiegare il perché siano necessari programmi, librerie e file di configurazione, che sarebbero già presenti nel filesystem normale.
~ftp/ | +--bin/ | +--etc/ | +--lib/ | +--pub/ | |--... |--... : |
Quando un utente anonimo accede, il server FTP non si limita a modificare la directory corrente in modo da trovarsi in ~ftp/
; per evitare che questo utente sconosciuto abbia accesso al resto del filesystem, esegue una chiamata di sistema specifica, chroot()
, per fare in modo che quella posizione divenga la directory radice.
In queste condizioni, quando un utente anonimo, attraverso il proprio client, utilizza il comando ls
, il server non è più in grado di avviare il programma ls
che si trova nel filesystem normale. Può utilizzare solo ciò che si trova a partire dalla ex directory ~ftp/
, divenuta la radice.
Questo dovrebbe spiegare la presenza di alcuni programmi nella directory bin/
, delle librerie corrispondenti in lib/
, e del file etc/ld.so.cache
necessario alle librerie.
I due file etc/passwd
e etc/group
servono solo a ls
per poter tradurre i numeri UID e GID in nomi di utenti e di gruppi. Di conseguenza dovranno contenere tutte le voci necessarie in base alla proprietà dei file che si vuole indicare in questa struttura di directory.
Quando si utilizzano collegamenti simbolici all'interno della struttura di directory dell'FTP anonimo, occorre tenere presente che il server 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 filesystem normalmente, senza questi vincoli particolari.
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
. Di seguito appare un esempio di questo secondo file, già presentato in precedenza, che dovrebbe corrispondere alla configurazione standard di partenza.
class all real,guest,anonymous * email root@localhost loginfails 5 readme README* login readme README* cwd=* message /welcome.msg login message .message cwd=* compress yes all tar yes all chmod no guest,anonymous delete no guest,anonymous overwrite no guest,anonymous rename no guest,anonymous 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 filesystem in base ai permessi relativi.
Nelle sezioni seguenti vengono descritte alcune delle direttive che possono apparire in questo file.
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.
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 client, 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 real,guest,anonymous * |
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 amici guest *.dg 192.168.* class all real,guest,anonymous * |
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 guest,anonymous *.dg 192.168.* class all real,guest,anonymous * ... autogroup locali 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
occorre anche aggiornare il file -
l~ftp/etc/group
.
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 un nome di utente e una password. 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 server 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 server 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.
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
165.2.
È il caso di sottolineare che il filtro di accesso vale per tutti gli utenti, e non solo per una classe particolare.
deny *.mehl.dg /etc/ftpdeny.msg deny 192.168.2.* /etc/ftpdeny.msg deny dinkel.* /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 |
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
165.2.
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. |
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
.
loginfails <n-tentativi> |
La direttiva loginfails
permette di porre un limite ai tentativi falliti di accesso agli utenti reali, cioè a quelli provvisti di password.
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.
password
|
All'utente anonimo viene richiesto l'inserimento di una password, 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 server, il compito di determinare la parte restante.
Con la direttiva password
si può definire un livello di controllo su questo indirizzo inserito. La tabella
165.1 elenca le parole chiave che possono essere usate in questa direttiva, e il loro significato.
-
check
Parola chiave | Descrizione |
none | Non viene fatto alcun controllo. |
trivial | La password deve contenere il carattere @ . |
rfc822 | Verifica che il dominio sia corretto (in base alle specifiche del RFC 822). |
warn | La password non valida viene accettata avvisando l'utente per la prossima volta. |
enforce | L'accesso viene negato se la password non viene ritenuta corretta. |
password-
check
.
Macro | Descrizione |
%T | Data e ora locale. |
%C | La directory corrente. |
%E | L'indirizzo di posta elettronica dell'amministratore del servizio. |
%R | Indirizzo del nodo remoto. |
%L | Indirizzo del nodo che offre il servizio FTP. |
%U | Il nome dell'utente utilizzato per accedere. |
%M | Numero massimo di accessi ammissibili per gli utenti della classe cui appartiene chi accede. |
%N | Numero di accessi in corso nella classe cui appartiene l'utente in questione. |
In varie occasioni, il server FTP invia agli utenti dei messaggi contenuti in file appositi, oppure invita alla lettura di questi.
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.
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, e precisamente in quella indicata subito dopo.
message /welcome.msg login message .message cwd=* |
Nell'esempio, viene inviato il messaggio contenuto nel file /welcome.msg
tutte le volte che un utente accede, e ogni volta che cambia directory (l'asterisco rappresenta qualunque directory) viene inviato quanto contenuto nel file .message
della directory corrente.
*1*
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 165.2.
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 leggere il contenuto di tali file.
readme README* login readme README* 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.
L'attivazione del controllo sulla registrazione degli eventi legati al servizio FTP può essere fatta attraverso l'opzione
nella riga di comando di -
Lftpd
. La direttiva log
, tuttavia, scavalca l'utilizzo di questa opzione eventuale.
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.
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
, outbound
), per gli utenti che appartengono al tipo anonymous
e real
.
Il caricamento dei file in un FTP è una cosa molto delicata e generalmente da impedire agli utenti anonimi. Attraverso le direttive upload
e path
si possono controllare queste operazioni, oltre che con la gestione corretta dei permessi delle directory.
-
filter
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 server 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 /home/ftp * no upload /home/ftp /incoming 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 in scrittura e lettura solo per il proprietario.
*2*
path
|
La direttiva path
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.
-
filter
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 sottolineato e il trattino, e non possono iniziare con una cifra numerica, un sottolineato o un trattino.
È importante osservare che in queste espressioni regolari, il punto vale esattamente per quello che è, e 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
può essere utile anche per impedire il caricamento di file da parte di utenti di tipo -
filterguest
, esclusi dal controllo della direttiva upload
, o da parte di utenti reali.
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.
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 quest'altro caso, si impedisce all'utente caio
di accedere dalla sottorete 192.168.2.0.
Un'organizzazione corretta del sistema di file di messaggi è importante, sia per l'immagine del servizio, sia per poter informare correttamente l'utente.
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. |
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.
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* login readme README* 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.
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
, e di seguito il contenuto dei due ipotetici file /etc/ftpdeny.msg
e /etc/ftpdenydns.msg
.
*3*
deny *.mehl.dg /etc/ftpdeny.msg deny 192.168.2.* /etc/ftpdeny.msg deny dinkel.* /etc/ftpdeny.msg deny !nameserved /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 determinata classe 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
, e si possono definire limiti diversi per le varie classi di utenti. Volendo, è possibile definire un unico file di spiegazioni, senza troppi dettagli.
*4*
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. |
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
, che ha quindi suggerito il nome del file indice in questione. Generalmente, è consigliabile che questo file sia compresso con -
lRgzip
, e in tal caso 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 6:16 di ogni mattina.
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:
ls |
Se si vuole migliorare l'accessibilità al proprio servizio FTP anonimo, conviene registrarlo nel sistema di indicizzazione Archie. Per farlo si può visitare http://www.bunyip.com/products/archie dove si trovano tutte le istruzioni necessarie.
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).
xferstats [<opzioni>] |
xferstats
è un programma per l'analisi statistica del file delle registrazioni del server FTP. Se non vengono dati argomenti, dovrebbe essere in grado di accedere da solo al file corretto, generando una statistica semplificata.
|
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 = 1; $opt_d = 0; $opt_t = 1; $opt_l = 3; ... |
#
xferstats
-
D dg
Genera un rapporto sui trasferimenti eseguiti con il dominio .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 23 Bytes Transmitted During Summary Period 8093489 Systems Using Archives 0 Average Files Transmitted Daily 12 Average Bytes Transmitted Daily 4046744 Daily Transmission Statistics Number Of Number of Average Percent Of Percent Of Date Files Sent Bytes Sent Xmit Rate Files Sent Bytes Sent --------------- ---------- ----------- ---------- ---------- ---------- Sun Mar 15 1998 21 8093489 207.5 KB/s 91.30 100.00 Tue Mar 24 1998 2 0 0.0 KB/s 8.70 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 Number Of Number of Average Percent Of Percent Of Time Files Sent Bytes Sent Xmit Rate Files Sent Bytes Sent --------------- ---------- ----------- ---------- ---------- ---------- 14 2 0 0.0 KB/s 8.70 0.00 20 10 7320378 271.1 KB/s 43.48 90.45 21 11 773111 64.4 KB/s 47.83 9.55 |
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) Quando si indica un percorso in un file di messaggi, e l'utente ha a disposizione un filesystem limitato come nel caso dell'utente anonimo, conta quel filesystem particolare. Quindi, nel caso dell'esempio, il file welcome.msg
si troverà presumibilmente in ~ftp/welcome.msg
.
2.) 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.
3.) È il caso di sottolineare che il percorso di questi file di messaggi si riferisce al filesystem globale, dal momento che il controllo avviene prima di qualunque identificazione dell'utente.
4.) Anche in questo caso, il percorso di questi file di messaggi si riferisce al filesystem globale.