UNIX: introduzione elementare

Alcuni strumenti per l'uso della rete Internet

I sistemi Unix sono spesso inseriti in un ambiente di rete TCP/IP, dove vengono utilizzati da numerosi utenti connessi da terminali locali o remoti; in molti casi sono proprio dei server in ambiente Unix a gestire servizi importanti come la posta elettronica e la gestione di siti web sulla rete Internet. In effetti un sistema Unix si integra alla perfezione in un ambiente di connettività vasta ed eterogenea come quello di Internet, dove devono comunicare tra loro, in modo del tutto trasparente agli utenti, macchine e sistemi operativi anche molto diversi.

La Rete delle reti

Originariamente Internet nasce con il nome di ARPANET, un progetto del Ministero della Difesa americano, che doveva definire un modello di rete di telecomunicazioni inattaccabile dal nemico. Siamo nei primi anni '60, in piena guerra fredda, l'esercito americano è ossessionato dal pensiero di come ci si possa difendere da un eventuale attacco nucleare sovietico: il compito della rete ARPANET è quello di collegare i principali centri di comando degli Stati Uniti, in modo tale che se uno di questi centri dovesse essere colpito, la rete non venga distrutta, ma possa comunque continuare a funzionare (trasmettere messaggi) utilizzando gli altri nodi. L'aspetto innovativo era costituito proprio dalla possibilità di definire una rete priva di una "gerarchia trasmissiva", in cui potessero essere presenti percorsi differenti per connettere due nodi e in cui la ricerca del percorso migliore (più breve o più efficiente) per trasmettere dati da un nodo della rete ad un altro, potesse essere calcolato dinamicamente sulla base dello stato dei nodi della rete stessa.

Inizialmente esistevano solo pochi nodi sperimentali di questa rete militare, ma ben presto il progetto, che rivestiva anche un grande interesse dal punto di vista teorico oltre che applicativo, si è allargato a numerose università e centri di ricerca degli Stati Uniti, così che dai pochi nodi iniziali si è passati nel giro di pochi anni alla rete informatica più grande del mondo: 4 nodi nel 1969, 15 nel 1971, più di 1.000 nel 1984, più di 10.000 nel 1987, più di 100.000 nel 1989, ... una crescita irrefrenabile! Col passare del tempo il progetto ha perso il suo significato militare e strategico (nel frattempo è finita anche la guerra fredda) ed ha acquistato un grandissimo interesse pratico, tanto che nel 1990 il progetto ARPANET ha cessato di esistere. Oggi i nodi collegati alla rete Internet sono milioni e sono sparsi in tutto il mondo.

Naturalmente è necessario che esista una forma di coordinamento tra gli utenti della rete per far sì che un sistema talmente vasto funzioni in modo congruente. Sebbene il protocollo di comunicazione adottato per la trasmissione dei dati (il TCP/IP -- Transmission Control Protocol/Internet Protocol) non stabilisca delle gerarchie tra i nodi della rete, è necessario un certo coordinamento per definire la modalità con cui i nodi possono continuare ad aggiungersi alla rete; al tempo stesso, per non ostacolare la crescita del sistema e per evitare che si creino isole di incompatibilità con il resto della rete, è necessario da un lato delegare e distribuire le responsabilità di gestione dei segmenti di rete e, dall'altro, garantire un coordinamento tecnico anche per la definizione di standard per lo sviluppo di nuove soluzioni tecnologiche.

Per questo sono stati creati negli anni diversi organismi internazionali, coordinati fra loro, finalizzati a definire gli standard tecnici ed anche a delegare la gestione degli indirizzi di rete assegnati ad ogni macchina collegata alla rete Internet. Tra questi organismi possiamo ricordare la Internet Society, il World Wide Web Consortium (W3C), la Internet Corporation for Assigned Names and Numbers (ICANN), la Internet Assigned Number Authority (IANA), il RIPE (Réseaux IP Européens) e, in Italia, NIC-IT (Italian Network Information Center) e il GARR (Gruppo di Armonizzazione delle Reti di Ricerca). Le linee guida di sviluppo tecnico vengono definite e proposte alla comunità degli utenti della rete dalla Internet Engineering task Force (IETF) che periodicamente pubblica il risultato dei propri lavori nelle note conosciute come RFC (Request for Comments) disponibili al pubblico ad esempio sul sito Internet http://www.ietf.org/rfc.html.

Un contributo determinante all'introduzione e alla diffusione di Internet in Italia è stato offerto dall'associazione "i2u" (Italian Unix Users), l'associazione italiana degli utenti Unix, di cui facevano parte le principali aziende di informatica italiane (prima fra tutte Olivetti) e numerosi centri di ricerca pubblici ed istituti universitari italiani.

IP address e routing

A livello fisico la rete Internet è costituita da un insieme eterogeneo di computer collegati fra loro mediante le connessioni più diverse: convivono sulla Rete macchine Unix, personal computer e server in ambiente Microsoft Windows, supercomputer con sistemi operativi proprietari, apparati di rete dedicati alla gestione del traffico con sistemi operativi specializzati nell'esecuzione di tali operazioni e moltissimi altri sistemi e macchinari. Le connessioni di rete sono basate su linee seriali e telefoniche a bassa velocità, segmenti di collegamento su fibra ottica o su cavi di rete Ethernet, connessioni frame relay a banda larga, connessioni satellitari, wireless, cellulari GSM/GPRS/UMTS e molte altre ancora. L'unico aspetto che unifica questo minestrone di tecnologie è il protocollo di comunicazione TCP/IP che, a livelli e con implementazioni diverse, consente a questi apparati di integrarsi in modo del tutto trasparente per l'utente: fortunatamente non è necessario conoscere questi aspetti tecnologici per poter utilizzare la rete Internet. Nelle pagine seguenti faremo solo qualche accenno agli aspetti che riguardano più da vicino un utente di un sistema Unix.

Ad ogni singola macchina collegata alla rete Internet viene assegnata dall'organismo di coordinamento regionale un indirizzo di rete univoco, chiamato Internet number o anche IP address. È costituito da una quaterna di numeri compresi tra 0 e 255. Ad esempio un numero valido può essere 193.204.165.209.

Per consentire una gestione "delegata" del processo di assegnazione degli indirizzi a tutti gli enti, le aziende e gli organismi che ne fanno richiesta, l'insieme di tutti i possibili indirizzi IP (sono più di quttro miliardi!) è stato suddiviso in classi; una classe o parte di essa viene assegnata in gestione ad ogni organismo che ne fa richiesta. A seconda delle esigenze dell'ente che richiede di entrare in possesso di una classe di indirizzi IP, possono essere assegnate classi (o sottoclassi) che contengono pochi indirizzi o anche molte migliaia. Le classi di tipo "A" contengono circa 16 milioni di indirizzi; le classi di tipo "B" ne contengono circa 65.000 ciascuna ed infine le classi di tipo "C" contengono ognuna 254 indirizzi. Tra queste classi ne sono state individuate alcune che sono costituite da indirizzi riservati alle reti TCP/IP private, che non possono quindi essere collegate direttamente alla rete pubblica Internet perché altrimenti entrerebbero in conflitto con gli stessi indirizzi utilizzati da altre reti private. Per collegare una rete privata ad Internet è necessario quindi predisporre un gateway che consenta di veicolare i pacchetti di dati dalla rete privata verso l'esterno e viceversa. Le reti private sono generalmente identificate da indirizzi del tipo 10.x.y.z, per reti di grandi dimensioni, o 192.168.x.y, per reti di dimensioni più modeste. L'indirizzo IP 127.0.0.1 è un indirizzo riservato e viene assegnato ad ogni macchina che supporta il protocollo TCP/IP per indicare l'indirizzo locale (localhost).

Ai computer facenti parte di una stessa rete locale (la rete interna di un'azienda, di un ufficio o di un dipartimento universitario), vengono assegnati indirizzi selezionati nella classe IP dell'organizzazione. Tali indirizzi saranno tutti piuttosto simili, a meno di almeno uno dei quattro numeri della quaterna che forma un Internet number. Ad esempio, se è stata assegnata la classe C 192.106.24.x, allora tutti gli host di quella rete avranno indirizzi che iniziano con 192.106.24 e terminano con un ultimo numero che è differente per ogni macchina (192.106.24.1, 192.106.24.2, fino a 192.106.24.254; il numero 192.106.24.0 rappresenta l'intera rete). Ad una stessa macchina possono essere attribuiti, per ragioni tecniche particolari, anche due o più indirizzi IP.

Ogni rete è collegata al resto della rete Internet attraverso un gateway costituito da un apparato denominato router. Queste macchine hanno almeno due interfacce di rete: ad una viene collegata la rete "interna", mentre l'altra viene utilizzata per connettersi alla rete "esterna" e da questa al resto di Internet. Ogni router ha quindi almeno due indirizzi IP: uno per il collegamento con la rete esterna e l'altro della stessa classe della rete IP interna.

Quando una macchina intende comunicare con un altro computer identificato da un certo indirizzo IP, verifica innanzi tutto se l'indirizzo di destinazione appartiene o meno alla propria rete; se gli indirizzi IP delle due macchine (mittente e destinatario) fanno parte della stessa classe, allora la comunicazione avviene in modo diretto. Altrimenti la macchina "mittente", contatta il gateway della propria rete che provvederà ad inoltrare il pacchetto di dati verso la rete esterna fino a raggiungere il destinatario, sfruttando i gateway delle reti limitrofe.

L'utilizzo degli indirizzi IP numerici è piuttosto scomodo, dal momento che i numeri di per sé non dicono nulla dell'identità dell'ente o dell'organizzazione della cui rete fa parte un certo computer. È per questo che dal 1984 è stato introdotto sulla rete Internet un sistema denominato DNS (Domain Name System), che consente di associare un "nome di dominio" ad ogni rete e ad ogni host collegato ad Internet. Si tratta di una specie di grande "elenco telefonico" che è in grado di associare ad ogni Internet number un nome facilmente identificabile. Anche in questo caso è stato adottato un meccanismo in grado di poter delegare la gestione dell'assegnazione dei nomi ad un insieme di organismi di coordinamento territoriali. Dunque l'insieme dei nomi che è possibile assegnare ai nodi della rete Internet è stato suddiviso in domini su vari livelli: in cima a questa gerarchia "ad albero" ci sono i cosiddetti Top Level Domains (TLDs), che possono essere di tipo geografico o non geografico: si distinguono così i "country code Top Level Domains" (ccTLDs), come "it" per l'Italia, "es" per la Spagna, "uk" per il Regno Unito, ..., ed i TLD che non fanno riferimento a nessuno specifico Paese: "com" usato da molte aziende commerciali, "org" per le organizzazioni internazionali, "net" per gli enti di gestione della rete, ed altri ancora.

Ognuno di questi Top Level Domain viene gestito da un organismo nazionale o sovranazionale, che controlla il processo di registrazione ed assegnazione di un nome di dominio di "secondo livello" da collocare sotto alla gerarchia del proprio TLD. Sono stati così registrati moltissimi (milioni) domini di secondo livello che identificano bene o male tutte le organizzazioni, gli enti, le aziende, le istituzioni che in qualche modo sono connesse alla rete Internet (magari anche solo per la pubblicazione di un sito web). Ad esempio "uniroma3.it" è il dominio Internet di secondo livello assegnato all'Università Roma Tre, mentre "ibm.it" ed "ibm.com" sono due domini di secondo livello assegnati rispettivamente alla filiale italiana dell'IBM e alla IBM americana.

Nell'ambito del proprio dominio ogni organizzazione è responsabile della assegnazione e della gestione di eventuali sottodomini e degli hostname assegnati ad ogni singola macchina. Così organizzazioni più piccole possono decidere di mantenere un solo livello gerarchico nei propri nomi di dominio, mentre altre strutture più articolate possono suddividere il contesto generale in ulteriori domini di livello inferiore; ad esempio il dominio di secondo livello dell'Università Roma Tre contiene altri domini di terzo livello per ogni dipartimento della stessa Università: il dipartimento di Matematica ha il dominio "mat.uniroma3.it", quello di Fisica ha il dominio "fis.uniroma3.it", e così via.

All'interno di ogni dominio vengono assegnati gli hostname alle singole macchine collegate alla rete: archimede.mat.uniroma3.it, venere.mat.uniroma1.it, sono rispettivamente gli hostname delle macchine archimede e venere del Dipartimento di Matematica dell'Università Roma Tre e dell'Università di Roma "La Sapienza". Quando un hostname è composto anche dai nomi di dominio fino al TLD di appartenenza, allora quel nome è un fully qualified domain name.

È chiaro quindi che per tentare di decifrare il nome dell'organizzazione che "si cela" dietro ad un certo indirizzo Internet, dovremo leggerlo da destra verso sinistra: in questo modo viene letto per primo il dominio di più alto livello, per poi specificare via, via i vari sottodomini a cui tale macchina appartiene, come in un gioco di scatole cinesi.

Quando una macchina deve comunicare con un'altra di cui conosce il fully qualified domain name, ma non l'indirizzo IP, deve tradurre quel nome in un indirizzo (in gergo si dice che deve "risolvere" quel nome) prima di potergli spedire il pacchetto di dati. Per far questo deve contattare un DNS server che, collegato con tutti gli altri DNS server presenti sulla rete Internet, è in grado di tradurre il nome in un indirizzo, oppure di affermare con certezza che quel nome non corrisponde a nessun indirizzo presente in rete. Ogni dominio Internet fa riferimento ad uno o più DNS server "autoritativi" per tale dominio: ogni volta che viene modificato l'indirizzo di una macchina all'interno di un dominio, deve essere aggiornato il DNS server autoritativo per quella zona, in modo tale da poter gestire correttamente la risoluzione dei nomi e degli indirizzi.

Risoluzione di nomi e di indirizzi

In ambiente Unix sono disponibili moltissimi comandi che consentono di verificare la configurazione della rete e di acquisire informazioni circa i nomi e gli indirizzi assegnati a sistemi facenti parte della nostra o di altre reti connesse ad Internet. Di seguito vedremo soltanto alcuni fra i comandi principali.

Il primo comando di questa breve rassegna è hostname che, naturalmente, consente di visualizzare l'hostname del nostro computer. Lo stesso comando può essere utilizzato anche dall'utente root, con l'opzione "-s", per assegnare un nome al sistema.

Per risolvere un indirizzo traducendo un nome in un IP address o viceversa, si può utilizzare il comando nslookup che consente di interrogare i DNS server. Questo comando può essere utilizzato in modalità diretta (specificando opzioni e parametri sulla linea di comando) o interattiva, entrando in un ambiente in cui è possibile effettuare diverse richieste. Ogni interrogazione consiste nello specificare il tipo di informazione che si desidera ricevere e l'indirizzo che si vuole risolvere. Di seguito riportiamo una sessione di lavoro interattiva con nslookup.

$ nslookup
> set type=ns
> www.mat.uniroma3.it.
Server:         192.106.1.1
Address:        192.106.1.1#53

Non-authoritative answer:
www.mat.uniroma3.it     canonical name = web2.mat.uniroma3.it.

Authoritative answers can be found from:
mat.uniroma3.it
        origin = dns.uniroma3.it
        mail addr = root.dns.uniroma3.it
        serial = 2005041400
        refresh = 86400
        retry = 1800
        expire = 2592000
        minimum = 172800
> server dns.uniroma3.it
Default server: dns.uniroma3.it
Address: 193.205.139.10#53
> set type=a
> www.mat.uniroma3.it.
Server:         dns.uniroma3.it
Address:        193.205.139.10#53

www.mat.uniroma3.it     canonical name = web2.mat.uniroma3.it.
Name:   web2.mat.uniroma3.it
Address: 193.204.165.209
> exit
$ _

Nell'esempio il nostro scopo è quello di stabilire quale sia l'indirizzo IP assegnato alla macchina identificata dal nome www.mat.uniroma3.it. Per prima cosa quindi, con il comando "set type=ns" abbiamo selezionato una interrogazione per conoscere l'indirizzo del DNS server autoritativo per l'hostname di nostro interesse; quindi abbiamo interrogato il nostro DNS server di default a proposito dell'indirizzo www.mat.uniroma3.it. Questo ci ha risposto che la risposta che ci stava fornendo non è autoritativa e che il DNS server da interrogare è dns.uniroma3.it. Abbiamo quindi cambiato DNS server con il comando "server dns.uniroma3.it"; quindi abbiamo cambiato il tipo di query con il comando "set type=a" che ci permette di conoscere l'indirizzo (address) associato ad un certo nome (e viceversa) ed abbiamo interrogato il nuovo DNS server a proposito dell'indirizzo www.mat.uniroma3.it. Questo finalmente ci ha risposto dicendo che l'indirizzo IP associato a quel nome è 193.204.165.209.

È possibile effettuare una interrogazione del DNS server anche per la risoluzione inversa: ad esempio supponiamo di voler conoscere il nome associato all'indirizzo 192.106.24.10; possiamo utilizzare il seguente comando, questa volta utilizzando il programma nslookup in modalità non interattiva:

$ nslookup 192.106.24.10
Server:         192.106.1.1
Address:        192.106.1.1#53

10.24.106.192.in-addr.arpa      name = sole.isinet.it.
$ _

Possiamo conoscere più da vicino le organizzazioni a cui sono stati assegnati i nomi di dominio Internet interrogando il cosiddetto database WHOIS, ossia il grande archivio in cui sono memorizzate le informazioni relative a tutti i domini registrati sulla rete Internet. In questo caso il comando da utilizzare è whois. La sintassi del comando è molto semplice, ma può variare da un sistema all'altro: in sostanza si tratta di indicare il nome del dominio di cui vogliamo ottenere informazioni ed eventualmente il nome di uno specifico WHOIS server. Vediamo un esempio:

$ whois uniroma3.it
domain:      uniroma3.it
org:         Terza Universita' degli Studi di Roma
descr:       Italian 2-th level domain
descr:       of the Third University of Rome
admin-c:     MRC25-ITNIC
tech-c:      PC1670-ITNIC
postmaster:  PC1670-ITNIC
zone-c:      PC1670-ITNIC
nserver:     193.205.139.10 dns.uniroma3.it
nserver:     193.204.5.4 decsrv.caspur.it
nserver:     193.205.245.66 dns3.nic.it
mnt-by:      GARR-MNT
created:     before 19960129
expire:      20060129
source:      IT-NIC

person:      Maria Rosaria Cagnazzo
address:     Rettorato Terza universita' di Roma
address:     Via Ostiense, 159
address:     I-00154 Roma
address:     Italy
nic-hdl:     MRC25-ITNIC
source:      IT-NIC

person:      Paolo Cursi
address:     Rettorato Terza universita' di Roma
address:     Via Ostiense, 159
address:     I-00154 Roma
address:     Italy
nic-hdl:     PC1670-ITNIC
source:      IT-NIC
$ _

Tra le molte informazioni visualizzate ce ne sono alcune particolarmente interessanti, quali gli indirizzi dei DNS server primari per il dominio e i riferimenti delle persone che si occupano della gestione della rete (tech-c, zone-c) e della posta elettronica (postmaster) per il dominio stesso. Il nominiativo identificato dall'etichetta admin-c è il cosiddetto "contatto amministrativo", ossia il nome del rappresentante dell'ente a cui è stato intestato il dominio.

Per verificare lo stato della connessione di rete nel tratto che va dal nostro sistema ad un determinato altro computer, si possono utilizzare i comandi ping e traceroute. Ultimamente, con l'introduzione di apparati di controllo e filtraggio delle reti connesse ad Internet l'attendibilità dell'output di questi strumenti è un po' diminuita, ma consentono comunque di effettuare un test preliminare sullo stato di efficienza della rete.

Il comando ping consente di inviare (ripetutamente o una sola volta) un pacchetto di dati alla macchina di destinazione, attendendo poi da questa un feedback circa l'avvenuta ricezione del pacchetto. Il comando traceroute consente invece di tracciare il percorso (routing) dei pacchetti di dati che transitano dalla nostra macchina fino a quella di destinazione. Vediamo un esempio:

$ ping www.mat.uniroma3.it
PING web2.mat.uniroma3.it (193.204.165.209): 56 data bytes
64 bytes from 193.204.165.209: icmp_seq=0 ttl=52 time=13.765 ms
64 bytes from 193.204.165.209: icmp_seq=1 ttl=52 time=12.853 ms
64 bytes from 193.204.165.209: icmp_seq=2 ttl=52 time=13.416 ms
^C
--- web2.mat.uniroma3.it ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.853/13.345/13.765/0.376 ms

$ traceroute www.mat.uniroma3.it
traceroute to www.mat.uniroma3.it (193.204.165.209), 64 hops max, 40 byte
packets
 1  192.168.1.1 (192.168.1.1)  2.546 ms  1.204 ms  0.965 ms
 2  151.6.146.65 (151.6.146.65)  9.410 ms  11.336 ms  11.306 ms
 3  rmcc-b01-ge2-0.31.wind.it (151.6.73.65)  9.981 ms rmcc-b01-ge10-0.41.wi
nd.it (151.6.73.81)  11.631 ms rmcc-b02-ge2-0.31.wind.it (151.6.73.66)
13.102 ms
 4  151.6.4.53 (151.6.4.53)  36.969 ms  9.861 ms 151.6.5.41 (151.6.5.41)
9.993 ms
 5  fici-b01-rmid-t01-po01.wind.it (151.6.1.78)  11.496 ms 151.6.5.58 (151.
 6.5.58)  12.779 ms  10.602 ms
 6  garr-nap.namex.it (193.201.28.15)  11.399 ms  12.267 ms  10.618 ms
 7  rt-rm2-rt-rm1-1.rm1.garr.net (193.206.134.197)  11.799 ms  11.040 ms
11.879 ms
 8  193.206.131.146 (193.206.131.146)  12.805 ms  12.513 ms  11.900 ms
 9  * * *
10  natamm.cab.uniroma3.it (193.204.167.85)  31.213 ms  13.786 ms 14.578 ms
11  168ext7.cab.uniroma3.it (193.204.163.2)  14.290 ms  14.250 ms 13.095 ms
12  168ext7.cab.uniroma3.it (193.204.163.2)  16.111 ms  19.129 ms 34.813 ms
13  www.mat.uniroma3.it (193.204.165.209)  14.806 ms !<10> 15.855 ms !<10>
14.751 ms !<10>
$ _

L'output del comando ping ci dice che la connessione funziona piuttosto bene, dal momento che nessuno dei pacchetti di dati trasmessi è andato perso. Per interrompere il comando ping sono stati battuti i tasti   Ctrl-c   . L'output di traceroute ci permette di scoprire che per comunicare i due computer devono passare attraverso 12 nodi intermedi: il primo (identificato dall'indirizzo di rete privata "192.168.1.1") è l'indirizzo del gateway della rete di partenza, gli altri sono nodi intermedi, mentre l'ultimo (il tredicesimo nodo dell'elenco) è la macchina di destinazione.

Sessioni di lavoro su server remoti

Una delle funzionalità più interessanti offerte da un server Unix è la possibilità di aprire delle sessioni di lavoro con la shell da postazioni remote, ossia sfruttando come un terminale un computer collocato anche a grande distanza dal server Unix su cui intendiamo lavorare; il collegamento tra la postazione di lavoro ed il server Unix remoto è una connessione di rete TCP/IP e non un collegamento "diretto" mediante una linea seriale, come avviene con i tradizionali terminali alfanumerici. Per attivare una sessione di lavoro da remoto si sfruttano dei sistemi di tipo client/server in cui la macchina Unix su cui vogliamo operare gioca il ruolo di server per la connessione effettuata dal client costituito dalla postazione di lavoro su cui ci troviamo; questa può essere un personal computer in ambiente Windows, un Macintosh, un'altra macchina Unix o qualunque altro genere di computer e sistema operativo, purché dotato del software client necessario per gestire la sessione di lavoro remota in collegamento via rete con il server Unix.

In sostanza ciò che si ottiene aprendo una sessione di lavoro remota non è altro che una shell di comandi Unix che viene eseguita sul server remoto, ma con cui è possibile interagire utilizzando i dispositivi di input/output della postazione di lavoro locale (essenzialmente il video con cui visualizzare l'output dei processi eseguiti sul server remoto e la tastiera per impartire i comandi). In questo modo, anche per eseguire programmi piuttosto impegnativi che richiedono notevoli risorse di calcolo, non è necessario disporre di una postazione di lavoro molto potente, dal momento che il programma che intendiamo utilizzare sarà eseguito sul server remoto sfruttando le sue risorse di memoria e di CPU.

Storicamente uno dei primi sistemi client/server per attivare sessioni di lavoro remote è Telnet. Si tratta di un sistema costituito da due programmi, il server o "demone Telnet" (telnetd) che consentiva di accettare e gestire le connessioni dalle postazioni di lavoro remote, e il client Telnet, implementato praticamente su ogni sistema operativo (anche Windows ha un suo client Telnet). In ambiente Unix il client può essere richiamato con il comando telnet, specificando poi sulla riga di comando l'indirizzo o l'hostname del server con cui si intende stabilire la connessione.

marco@aquilante ~$ telnet venere.mat.uniroma1.it
Trying 141.108.5.85...
Connected to venere.mat.uniroma1.it.
Escape character is `^]'.

SunOS UNIX (venere)
login: liverani
Password:

Last login: Mon Aug 29 11:22:11 from woodstock.mat.uniroma3.it
SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:48:35 PDT 1993
Venere (Sun4/60 del Dipartimento di Matematica)

liverani@venere ~> who
liverani   pts/1    Sep  4 11:28    (aquilante.isinet.it)
liverani@venere ~> _

Al momento del login vengono visualizzati alcuni messaggi che ci informano sull'ultima data di connessione e sulle caratteristiche del server su cui abbiamo aperto la sessione di lavoro. Ho utilizzato un prompt più sofisticato per evidenziare che il comando telnet è stato eseguito sulla postazione locale denominata "aquilante", mentre la sessione remota e l'esecuzione del comando who sono effettuati sul server denominato "venere"; anche lo username dell'utente è cambiato: su "aquilante" l'utente è identificato dallo username "marco", mentre su "venere" lo username è "liverani". Per scollegarsi dal sistema e terminare la sessione di lavoro remota si utilizzano i consueti comandi exit o logout.

Il messaggio "Escape character is..." indica che, in questo esempio, la sequenza di tasti   Ctrl-]   ci permette di rientrare nel sistema locale per chiudere la connessione, sospenderla, ecc. Premendo   Ctrl-]   ci viene presentato il prompt "telnet>" del programma telnet; ad esempio per chiudere la sessione a questo punto possiamo usare il comando close.

Il sistema Telnet negli ultimi anni è andato in disuso, venendo rapidamente sostituito da altri sistemi più sofisticati. Su molti server Unix il demone telnetd non è attivo e spesso non è neanche installato. Il motivo che ha fatto cadere in disgrazia un sistema che è stato molto utilizzato fino a qualche anno fa è costituito dal fatto che la sessione di lavoro in rete effettuata con il protocollo Telnet avviene "in chiaro": è abbastanza facile, quindi, utilizzando appositi strumenti di monitoraggio del traffico di rete (ad esempio tcpdump e snoop) intercettare i pacchetti scambiati tra il client ed il server Telnet durante la sessione di lavoro; in questo modo sono state intercettate moltissime password di utenti del tutto ignari del pericolo che stavano correndo.

La soluzione al problema non ha tardato ad arrivare ed è costituita da un nuovo protocollo di comunicazione che consente di stabilire delle sessioni di lavoro remote in tutta sicurezza, dal momento che ogni pacchetto di dati scambiato tra il client ed il server viene cifrato utilizzando algoritmi crittografici molto potenti e robusti.

Il metodo più diffuso oggi è quello offerto dal sistema SSH2 (Secure Shell versione 2): anche in questo caso il sistema si compone di due programmi, un client ed un server, che dialogano fra loro utilizzando un protocollo di comunicazione (SSH2); il protocollo prevede che entrambe le controparti eseguano la cifratura delle informazioni scambiate con algoritmi di crittografia asimmetrica. In questo modo è impossibile decifrare il contenuto dei pacchetti di dati trasmessi durante la sessione di lavoro. Per aprire una sessione di lavoro sicura su un server su cui è attivo il demone sshd (la componente server del sistema) si può utilizzare il comando ssh2(1) che attiva il client per la connessione al server remoto. Anche sui sistemi operativi non Unix sono disponibili client SSH2 con cui è possibile aprire una sessione di lavoro sicura su un server Unix remoto; ad esempio per l'ambiente Windows si possono facilmente reperire in rete ed installare i programmi WinSSH e PuTTY.

Sulla linea di comando di ssh2 si deve specificare anche l'indirizzo o l'hostname del server a cui intendiamo collegarci e lo username dell'account che vogliamo utilizzare su tale sistema, se è differente da quello utilizzato sulla macchina locale, usando la sintassi "username@hostname":

marco@aquilante ~$ ssh2 liverani@venere.mat.uniroma1.it

The authenticity of host 'venere.mat.uniroma1.it (141.108.5.85)'
can't be established.
DSA key fingerprint is 91:2f:65:b6:58:2e:8b:96:97:63:61:f4:89:0f:ad.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'venere.mat.uniroma1.it,141.108.5.85'
(DSA) to the list of known hosts.

liverani@venere.mat.uniroma1.it's password: 
Last login: Mon Aug 29 2005 16:25:49
SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:48:35 PDT 1993
Venere (Sun4/60 del Dipartimento di Matematica)

You have new mail.
liverani@venere ~> _

I messaggi relativi all'autenticità del server visualizzati all'inizio della connessione indicano che è la prima volta che l'utente si connette via SSH2 a quell'indirizzo e dunque la chiave di identificazione del server viene aggiunta in un file presente nella home directory locale dell'utente (~/.ssh/known_hosts) in modo tale che nelle connessioni successive non venga più visualizzato questo messaggio di allarme.

La sessione di lavoro può essere chiusa digitando i soliti comandi exit o logout.

Il sistema SSH2 consente di sostituire il tradizionale processo di autenticazione dell'utente basato sulla coppia username/password, con un meccanismo più sofisticato basato sul concetto di chiave publica e chiave privata che è alla base degli algoritmi di crittografia asimmetrica (come RSA e DSA, utilizzati da SSH2).

Se un utente si collega frequentemente in SSH2 da una stessa postazione di lavoro ad un insieme di host ben noti, allora può trovare più comodo usare le chiavi asimmetriche, anziché dover digitare ogni volta la propria password. Per predisporre le chiavi da usare per l'identificazione dell'utente si deve utilizzare il programma ssh-keygen, che genererà due file, uno contenente la chiave privata dell'utente (id_rsa) e l'altro la sua chiave pubblica (id_rsa.pub). Durante il processo di generazione delle chiavi viene richiesta l'immissione di una password facoltativa: siccome vogliamo effettuare il login sulla macchina remota senza dover digitare una password per sbloccare la chiave, è necessario non digitare nessuna password; questo non indebolisce in modo significativo il meccanismo di autenticazione. Il programma ssh-keygen deve essere eseguito sulla macchina da cui vogliamo stabilire la connessione remota (il client SSH2). Nell'esempio che segue chiediamo di generare una coppia di chiavi RSA (opzione "-t rsa"):

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/marco/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/marco/.ssh/id_rsa.
Your public key has been saved in /home/marco/.ssh/id_rsa.pub.
The key fingerprint is:
53:e4:ac:41:9b:17:cc:4b:22:3d:15:6a:59:e4:d6:a4 marco@woodstock
$ ls .ssh/
id_rsa         id_rsa.pub     known_hosts
$ _

Per completare la configurazione del meccanismo di autenticazione con chiavi RSA, si deve copiare la chiave pubblica (il contenuto del file "~/.ssh/id_rsa.pub") in un file denominato "~/.ssh/authorized_keys" sui server remoti a cui intendiamo collegarci. Il file "authorized_keys" può contenere anche più di una chiave pubblica (una per ogni postazione di lavoro da cui avviene la connessione SSH2), purché queste siano contenute ognuna su una sola riga di testo del file. Su altri sistemi la chiave pubblica deve essere copiata in un file a sé stante (es.: "~/.ssh/chiave.pub") e nel file "~/.ssh/authorization" deve essere riportato un riferimento a quel file in una riga scritta con la seguente sintassi "key filename" (es.: "key chiave.pub").

A questo punto la connessione sicura può essere effettuata senza la necessità di digitare nessuna password:

marco@aquilante ~$ ssh2 liverani@venere.mat.uniroma1.it
Last login: Sun Sep 4 2005 12:46:17
SunOS Release 4.1.3_U1 (GENERIC) #1: Wed Oct 13 17:48:35 PDT 1993
Venere (Sun4/60 del Dipartimento di Matematica)

You have mail.
liverani@venere ~> _

Con SSH2 è possibile aprire una sessione di lavoro remota su un server e creare un tunnel cifrato sul canale di comunicazione stabilito tra il client ed il server, entro cui far passare anche i messaggi scambiati nell'ambito della gestione dell'output grafico in ambiente X Window. Questo garantisce che anche l'esecuzione di applicazioni che richiedono una interazione con l'utente attraverso un server grafico X11, avvenga in tutta sicurezza impedendo ad altri utenti connessi in rete di interpretare i messaggi scambiati tra le applicazioni eseguite sul server e la workstation grafica su cui opera l'utente. Per aprire il tunnel SSH per la sessione X Window è necessario che il server sia stato configurato per sfruttare questa caratteristica. In tal caso il client ssh2 può essere eseguito con l'opzione "-X": sul server viene intercettato l'output grafico diretto al display localhost:10.0 che viene invece cifrato ed inviato al display della workstation remota.

Navigazione nel World Wide Web

Il web (o più esattamente il World Wide Web o WWW) oggi è sicuramente uno degli aspetti più appariscenti e utilizzati della rete Internet; è diventato molto rapidamente uno dei principali canali di promozione e diffusione delle informazioni. È il risultato di studi iniziati negli anni '80 da Tim Berners Lee(2) e da pochi altri ricercatori del CERN di Ginevra, che con questo nuovo potente strumento hanno reso accessibile a milioni di nuovi utenti "non tecnici" l'uso della rete Internet.

Il web si basa fondamentalmente su su un protocollo di comunicazione chiamato HTTP (HyperText Transfer Protocol) utilizzato da appositi software che operano in modalità client/server: il server HTTP (o anche HTTP daemon -- httpd) ed il client costituito da un web browser. I documenti, i file, le immagini vengono pubblicati sulla rete da un server web che permette di identificare ogni singolo file pubblicato con un indirizzo denominato URI (Uniform Resource Identifier) o URL (Uniform Resource Locator). Utilizzando un client HTTP (un web browser) si può visualizzare il file identificato da una determinato indirizzo URL pubblicato in rete da un web server. I singoli documenti ipertestuali pubblicati sul WWW sono spesso codificati con un linguaggio di marcatura del testo chiamato HTML (HyperText Markup Language), che consente di dare una struttura logica al documento, di collegarlo a risorse di tipo multimediale (come immagini o sequenze audio/video) e di costruire riferimenti "ipertestuali" che consentono di "navigare" da un documento ad un altro ad esso collegato e che probabilmente è di contenuto affine.

In ambiente Unix il web server più diffuso è il programma open source Apache HTTP Server. Se sul server è disponibile ed è attivo Apache, allora probabilmente la configurazione del server web consente agli utenti di pubblicare sul web una propria home page personale. Nella configurazione di default di Apache la home page di ogni utente di un sistema Unix è costituita dai file contenuti nella directory "~/public_html" presente nella home directory dell'utente; tale home page è accessibile sul web mediante un indirizzo URL di questo tipo: "http://hostname/~username/" (ad esempio http://www.isinet.it/~marco/).

Per accedere alle risorse disponibili sul web in ambiente Unix sono disponibili numerosi programmi client. Il principale e più diffuso è il potente web browser grafico Mozilla, che oltre ad offrire la possibilità di navigare sul web, mette a disposizione dell'utente anche un client di posta elettronica ed un news reader. Per lanciare il browser da un xterm sotto X Window si deve semplicemente digitare il comando "mozilla &". In alternativa a Mozilla è possibile utilizzare il programma Netscape; anche in questo caso è sufficiente digitare il comando "netscape &".

Per gli utenti che non hanno la possibilità di accedere ad un terminale grafico in ambiente X Window è disponibile un web browser che funziona in modalità testuale su qualsiasi terminale alfanumerico. Si chiama Lynx e può essere lanciato utilizzando il comando "lynx".

Se, invece di "navigare" sul web in modalità interattiva si desidera semplicemente scaricare nella directory locale un file di cui si conosce l'indirizzo URL, allora può essere utile il comando wget. Specificando l'indirizzo del file come parametro sulla linea di comando, questo verrà trasferito usando il protocollo HTTP e salvato in locale:

$ wget http://www.isinet.it/~marco/unix/manuale-unix.pdf
--16:39:05--  http://www.isinet.it/%7Emarco/unix/manuale-unix.pdf
           => `manuale-unix.pdf'
Resolving www.isinet.it... done.
Connecting to www.isinet.it[192.106.24.10]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 453,502 [application/pdf]
100%[==============================>] 453,502  142.59K/s ETA 00:00
16:39:08 (142.59 KB/s) - `manuale-unix.pdf' saved [453502/453502]
$ _

Il comando wget può essere anche utilizzato con l'opzione "-r" (recursive) per scaricare in locale un sito web a partire da una pagina specificata attraverso il suo indirizzo URL: wget seguirà i collegamenti ipertestuali presenti in quella pagina web e nelle pagine ad essa collegate, fino a raggiungere la "distanza" specificata dall'utente con l'opzione "-l" (di default è 5) dalla pagina iniziale. I file vengono salvati sul filesystem locale e, se viene specificata l'opzione "-k" i link ipertestuali vengono tradotti in modo tale che il sito web possa essere esplorato anche localmente. Ad esempio: "wget -r -k -l 2 http://www.w3.org".

Scambio di file con sistemi remoti

FTP significa File Transfer Protocol e serve appunto per trasferire file da una macchina all'altra collegate fra loro in rete TCP/IP (dunque anche su Internet). Si tratta ancora una volta di un protocollo di comunicazione adottato da appositi programmi in una modalità client/server: è necessario che su una macchina server sia attivo un demone FTP (ftpd) in modo tale che l'utente si possa collegare utilizzando un client FTP per scambiare (prelevare o depositare) file con il server. In ambiente Unix il programma client può essere richiamato con il comando ftp (lo stesso comando è anche disponibile sul sistema operativo Microsoft Windows). Per stabilire il collegamento FTP con un server bisogna specificare il comando seguito dall'indirizzo o dall'hostname del server a cui ci si intende connettere.

Anche in questo caso, connettendosi con un computer remoto per prelevare o depositare file mediante FTP, viene richiesto all'utente di farsi riconoscere mediante il suo username e la sua password. In alcuni casi sono disponibili dei servizi FTP "anonimi", ossia che consentono il collegamento e lo scambio di file anche ad utenti privi di un account di accesso al sistema stesso. In questi casi come username bisogna usare la parola riservata "anonymous" (o anche "ftp") e, come password, il proprio indirizzo di posta elettronica. In questo modo è possibile accedere al server FTP prelevando o depositando file in un'area pubblica in cui chiunque può avere accesso. È questo uno dei principali canali di scambio di informazioni, guide, manuali e software di pubblico dominio, che arricchisce e rende per certi versi unica la comunità degli utenti Internet.

Durante una sessione FTP si possono fare poche cose: sostanzialmente spostarsi all'interno del filesystem della macchina remota, prelevare o depositare file. Per far questo si deve utilizzare un ristretto set di comandi; riportiamo di seguito solo i principali, rimandando alla documentazione del comando ftp ("man ftp") per una illustrazione più chiara ed esauriente di tutti gli altri.

cd
ha lo stesso uso e significato dell'omonimo comando della shell Unix: serve per cambiare la directory corrente nel filesystem del server FTP remoto;
lcd
è analogo al comando cd, ma consente di cambiare directory sul filesystem della postazione locale;
pwd
serve per visualizzare il nome della directory corrente sul server remoto (print working directory);
bin
serve per indicare che le operazioni di trasferimento file devono avvenire in modalità "binaria" (per trasferire programmi, file in formato compresso, immagini, ecc.);
ascii
serve per indicare che le operazioni di trasferimento file devono avvenire in modalità "plain text" (per trasferire file di testo ASCII);
get
serve per trasferire un file dal sistema remoto al computer locale; la sintassi è "get fileremoto filelocale", dove fileremoto indica il nome del file che si trova sul server FTP remoto, e filelocale (che può anche essere omesso) indica il nome da assegnare al file quando sarà salvato nel disco del sistema locale;
put
svolge la funzione inversa del comando get, trasferendo sul sito remoto un file residente sul disco del sistema locale; la sintassi è "put filelocale fileremoto";
mget
consente di prelevare con uno stesso comando più di un file; accetta il carattere "*" per specificare il nome dei file da trasferire;
hash
durante il trasferimento di un file visualizza lo stato di avanzamento della trasmissione, rappresentando sullo schermo una specie di "progress bar";
dir
elenca i file contenuti nella directory corrente;
quit
termina la sessione di collegamento FTP.

Un esempio di una sessione FTP è il seguente, che riporta un collegamento con il server finlandese "ftp.funet.fi", uno dei più grandi server FTP europei:

$ ftp ftp.funet.fi
Connected to ftp.funet.fi.
Name (ftp.funet.fi:marco): anonymous
331-Welcome to the FUNET anonymous ftp archive
331-
331-THIS is a four processor SUN 450/4GB/2.5TB system 
331-Please mail to problems@nic.funet.fi in case of problems
Password:
Remote system type is UNIX.
ftp> cd pub/doc/unix
250 OK. Current directory is /.m/pub/doc/unix
ftp> dir
227 Entering Passive Mode (193,166,3,2,123,145)
150 Accepted data connection
-rw-r--r--    1 8129     999       2158072 Jul 26  1993 doc.tar.gz
drwxr-xr-x   11 8129     999          8192 Aug 11  1999 misc
drwxr-xr-x   20 8129     999          8192 Aug 11  1999 ps1
drwxr-xr-x    2 8129     999          8192 Aug 11  1999 run
drwxr-xr-x   36 8129     999          8192 Aug 11  1999 usd
ftp> bin
200 TYPE is now 8-bit binary
ftp> hash
Hash mark printing on (1024 bytes/hash mark).
ftp> get doc.tar.gz
local: doc.tar.gz remote: doc.tar.gz
227 Entering Passive Mode (193,166,3,2,89,115)
150-Accepted data connection
####################################################
226-File successfully transferred
2158072 bytes received in 00:19 (107.13 KB/s)
ftp> quit
221-Goodbye. You uploaded 0 and downloaded 2108 kbytes.
$ _

Nell'esempio ci siamo collegati con il sistema entrando come utenti "anonimi", ci siamo spostati nella directory "/pub/doc/unix", contenente documentazione sul sistema operativo Unix ed abbiamo prelevato il file doc.tar.gz in modalità binaria. Come al solito sperimentare questi comandi di persona aiuterà a capire il funzionamento di FTP molto più di qualsiasi spiegazione.

Un altro strumento assai utile per trasferire un file da una macchina ad un'altra è costituito dal comando scp (Secure Copy), una componente del sistema SSH2. Questo comando è simile al comando cp utilizzato per copiare file all'interno del filesystem, ma a differenza di quest'ultimo, consente la copia del file tra due macchine distinte, cifrando con gli stessi algoritmi utilizzati da ssh2 tutti i dati trasmessi durante il trasferimento. Per l'identificazione dell'utente sulla macchina remota si utilizza la coppia username/password oppure, se sono state create e configurate le chiavi RSA/DSA, l'autenticazione con chiavi asimmetriche.

Sulla linea di comando si deve specificare il nome del file da copiare e poi il nome del file di destinazione; il file "remoto" deve essere specificato con la sintassi "username@hostname:filename". Nel seguente esempio trasferiamo il file "relazione.pdf" dal computer locale a quello remoto e il file "dijkstra.c" dal server remoto alla macchina locale:

$ scp relazione.pdf liverani@aquilante.mat.uniroma3.it:relazfin.pdf
liverani@aquilante.mat.uniroma3.it's password: 
relazione.pdf             100%    14329     11.0KB/s   00:00
$ scp liverani@aquilante.mat.uniroma3.it:src/dijkstra.c dijkstra.c
liverani@aquilante.mat.uniroma3.it's password: 
src/dijkstra.c            100%      562      9.0KB/s   00:00
$ _

Le News Usenet

La posta elettronica è un sistema privato di comunicazione tra utenti. Teoricamente nessuno, oltre al mittente e al destinatario del messaggio, può leggere il contenuto del messaggio stesso. Spesso può essere utile far sì che un proprio messaggio su un determinato tema venga condiviso con molti altri utenti della Rete, anche sconosciuti. A questo scopo, su Internet sono stati creati dei gruppi di discussione a tema (newsgroup), che raccolgono ognuno gli articoli dei propri lettori su un determinato argomento. Chiunque può inviare un articolo ad un newsgroup che verrà letto da tutti gli utenti che seguono (leggono periodicamente) i nuovi messaggi di quel gruppo.

Oggi i newsgroup attivi sono diverse migliaia, e il numero è destinato a crescere di giorno in giorno, vista la frequenza con cui vengono creati nuovi gruppi di discussione. Per orientarsi in questo mare di articoli, sarà bene chiarire che anche i newsgroup sono organizzati in una struttura ad albero in cui le varie aree (i rami dell'albero) sono chiamate gerarchie. Di seguito sono elencate alcune delle gerarchie principali (di primo livello nella struttura ad albero):

alt
È la gerarchia "alternativa", in cui si ritrovano i newsgroup più impensabili ed in cui ogni argomento è trattato in modo assai particolare;
biz
Gruppi di tipo "business";
comp
È la gerarchia dei newsgroup riguardanti argomenti tecnici di computer science;
gnu
Gruppi concernenti il software e le attività dello GNU Project e della Free Software Foundation;
sci
Gerarchia dei gruppi riguardanti le discipline scientifiche;
soc
Gruppi relativi agli aspetti sociali e culturali delle diverse nazioni del mondo.

Per gli utenti di lingua italiana è utile indicare l'esistenza dei gruppi della gerarchia "it" (di cui fa parte il newsgroup "it.comp.os.unix", dedicato al sistema operativo Unix) e del newsgroup "soc.culture.italian".

Alcuni gruppi sono "moderati", ossia esiste un utente (o un gruppo di utenti) che svolgono la funzione di moderatore della discussione e vagliano a priori l'inserimento o la cancellazione dei messaggi nel newsgroup.

Andremmo ben oltre le finalità di questa breve introduzione descrivendo le numerose "buone maniere" che è necessario adottare nella partecipazione ad un gruppo di discussione su Internet per non attirare su di noi le maledizioni degli altri utenti; ci limitiamo quindi a ricordare che non sempre sono gradite "firme" eccessivamente lunghe o "artistiche" alla fine dei messaggi e che è bene evitare di entrare in sterili polemiche (flames) con gli altri utenti del newsgroup o di intraprendere inutili guerre di religione (holy war) a favore di questo o quell'argomento. In poche parole è bene discutere pacatamente ed in un certo senso anche con umiltà, visto che i nostri interlocutori sono migliaia e sparsi in tutto il mondo (è difficile pensare di avere sempre ragione o di essere il migliore in una situazione di questo genere...).

Per accedere in lettura e in scrittura ai newsgroup delle News Usenet, si deve utilizzare un news reader, come i programmi tin o rtin o lo stesso pine di cui abbiamo già parlato in precedenza. Tutti questi programmi permettono di selezionare (evidenziandoli con il cursore all'interno di una lista) il gruppo in cui "entrare" e, all'interno del gruppo, i nuovi messaggi che non abbiamo ancora letto. Con il news reader è possibile, come su un normale programma di posta elettronica, leggere i nuovi messaggi, ed inviare al newsgroup le nostre risposte o i nostri articoli originali. La gestione del newsgroup avviene su una macchina remota (news server) a cui il news reader si collega mediante il protocollo NNTP (Network News Transport Protocol). Ulteriori dettagli sulle modalità operative del programma utilizzato per leggere le news è possibile reperirle sulla documentazione del proprio sistema.

Una Digital Alphastation e un VAX in ambiente OpenVMS
Una Digital Alphastation e un VAX in ambiente OpenVMS

NOTE:

1. Su alcuni sistemi questo comando non esiste: si deve utilizzare il comando "ssh -2".

2. La home page di Tim Berners Lee è disponibile all'indirizzo http://www.w3.org/People/Berners-Lee/.

Home page

Indice

Introduzione

Organizzazione del sistema

Comandi fondamentali

Editing di file di testo

L'interfaccia grafica X Window

Alcuni strumenti per l'uso della rete Internet

Sintesi dei comandi principali

Elenco alfabetico delle sigle

Bibliografia

HOME

Valid HTML 4.01! Valid CSS!
Author: Marco Liverani - Last modified: Sunday November 20, 2011 - URI: http://www.aquilante.net/unix/6.shtml