set up and management of an integrated information system on linux
TRANSCRIPT
UNIVERSITÀ DEGLI STUDI DI PISA - FACOLTÀ DI INGEGNERIA
CORSO DI LAUREA TRIENNALE IN INGEGNERIA DELLE
TELECOMUNICAZIONI
Andrea Marchetti Michele Bartoli
CCOONNFFIIGGUURRAAZZIIOONNEE EE GGEESSTTIIOONNEE,,
SSUU PPIIAATTTTAAFFOORRMMAA LLIINNUUXX,,
DDII UUNN SSIISSTTEEMMAA IINNFFOORRMMAATTIIVVOO
IINNTTEEGGRRAATTOO
Tutori interni:
Prof. Ing. Stefano Giordano
Ing. Rosario G. Garroppo
Tutore esterno:
Dott.ssa Ilaria Bertolucci
2
INDICE
Profilo dell’azienda 5
Ringraziamenti 5
Introduzione 6
1. Come avvicinarsi a Linux? 10
1.1. Le distribuzioni 11
1.2. Scelta della distribuzione Linux 19
1.3. Requisiti di sistema Intel 20
1.4. Macchine utilizzate per i test 20
1.5. Prima di installare 20
1.6. Installazione di Red Hat Linux 22
1.7. Configurazione del sistema 42
1.8. Creare un account utente 45
2. Alcuni segreti dei tool di Linux 46
2.1. La shell 46
Completamento automatico della digitazione 46
Ripetizione dei comandi digitati 46
Ridirigere l’input e l’output 47
La documentazione 48
2.2. File e directory 49
Creare un file vuoto 50
2.3. Lavorare con i file 51
Trovare i file 53
Analisi del testo 54
2.4. Gestione dei dischi 55
Un solo disco più piattaforme 57
Usare i dischi rimovibili 58
2.5. L’elaborazione del testo 60
Vi 60
Emacs 60
La selezione del testo 61
3. Samba 62
3.1. File samba.conf 63
3.2. SWAT 69
3.3. Configurazione di Samba su Windows NT 70
3.4. Configurazione di Samba su Windows 95/98 71
3.5. Utilizzo di Samba 73
4. Le routine di avvio: i primi minuti dopo il lancio del sistema operativo 75
4.1. Init: il processo 1 75
4.2. L’organizzazione degli script di avvio 83
4.3. Gli script di attivazione e disattivazione dei servizi 84
5. Lan browsing 87
5.1. LAN Information Server – LISa 87
3
5.2. Come funziona LISa? 88
5.3. Accesso alle informazioni – client 90
5.4. resLISa 90
5.5. Installazione 91
5.6. Configurazione 92
5.7. Quattro differenti esempi di file di configurazione 95
5.8. Opzioni e segnali della riga di comando 96
6. X-Win32 v.5.5.2 98
6.1. Nuove caratteristiche 99
6.2. X-Win32 + SSH 99
6.3. Lingue 99
6.4. Altre importanti caratteristiche 100
6.5. Filosofia del prodotto 100
6.6. Font aggiuntivi 100
6.7. Configurazione di X-Win32 101
7. Web Server Linux 104
7.1. Quale Web Server scegliere: Apache, NCSA o Netscape 104
7.2. Installazione del Web Server 106
7.3. Configurazione 106
7.4. Ottimizzazione del Web Server 108
7.5. Apache Server Status 109
7.6. La sicurezza del Web Server 110
7.7. Hosting virtuale 111
7.7.1. Hosting basato su indirizzo IP 111
7.7.2. Hosting virtuale basato su nome 112
7.7.3. Hosting virtuale basato sulla porta 113
7.7.4. File httpd.conf 114
7.8. Sommario delle caratteristiche del Web Server Apache HTTP Server 1.3 125
8. TWiki 127
8.1. Introduzione 127
8.2. Requisiti di sistema di TWiki 129
8.3. Requisiti del server 129
8.4. Requisiti dei client 130
8.5. Guida di installazione di TWiki 130
8.6. Abilitare l’autenticazione degli utenti 134
8.6.1. File .htaccess 135
8.7. Aggiungere un sito web 138
8.8 TWiki Access Control 138
8.9. Nascondere i settaggi di controllo 142
8.10. Il SuperAdminGroup 142
8.11. Gestione file allegati 143
8.12. Sistema di gestione dei documenti 143
8.13. Condivisione file 143
8.14. Web Authoring 143
8.15. Upload dei file 144
8.16. Download dei file 144
8.17. Spostare i file allegati 144
8.18. Eliminare gli allegati 144
4
8.19. Link ai file allegati 144
8.20. Form TWiki 146
8.21. Templates TWiki 146
9. Java 2 SDK, Standard Edition Versione 1.4.0 Linux 148
9.1. Presentazione di Java 148
9.2. Java come strumento di programmazione 148
9.3. Java virtual machine 149
9.4. Struttura della Java virtual machine 150
9.5. Vantaggi di Java 151
9.6. Caratteristiche di Java 152
Appendice 159
Red Hat: disponibile la versione 7.3 159
I contenuti 159
Installazione 160
Le prime impressioni 160
L’ambiente grafico e il software multimediale 161
Il software da ufficio 162
Gli strumenti d’amministrazione 163
Conclusioni 163
Requisiti Hardware 164
Indirizzi Internet utili 164
I costi 164
Bibliografia 165
5
Profilo dell’azienda
Gruppo Servizi progetta, sviluppa e rende operativi sistemi informativi per il management aziendale
ed offre attività di consulenza nelle aree d’intervento dei software proposti, ponendosi sul mercato
nazionale come sintesi efficace ed innovativa fra software house e società di consulenza.
Il consolidamento civilistico e gestionale di bilanci, la pianificazione finanziaria e patrimoniale, il
budgeting, forecasting e il financial report, ma anche il datawarehousing, la business intelligence e
la logistica, rappresentano aree di forte competenza nelle quali sono nate soluzioni particolarmente
efficaci.
Gruppo Servizi è una delle poche realtà presenti sul mercato a possedere la caratteristica della
“doppia competenza”: al know how tecnologico affianca skill organizzativi, al software abbina
consulenza qualificata. Queste caratteristiche consentono di fornire ai clienti “soluzioni a problemi”
pronte all’uso, efficaci, affidabili e facili da utilizzare.
Ringraziamenti
Ringraziamo la ditta che ci ha dato la possibilità di svolgere il tirocinio aziendale per completare il
nostro corso di studi. Siamo grati in particolare all’Ing. Duccio Vigolo ed ai suoi collaboratori per
l’aiuto che ci hanno fornito.
6
Introduzione
Mappa di massima della rete aziendale:
7
L’obiettivo da raggiungere è realizzare una postazione Server Linux configurata per ospitare un
Web Server in grado di interpretare applicazioni Java Based integrata in un dominio Windows 2000
(con protocolli di tipo Samba). Il Server dovrà poi poter essere amministrato da remoto (tramite
Telnet, X-Win32, ecc.) da macchine Windows e dovrà vedere i Server ed i Client della rete
Windows (per la condivisione di cartelle, file e stampanti). Dovrà inoltre ospitare uno spazio di
sviluppo di progetti, gestione documenti e database di informazioni per facilitare lo sviluppo di
gruppo, sia sulla rete intranet sia su quella internet. La funzione del Server in azienda sarà quella di
offrire un banco di test per la compatibilità multipiattaforma delle applicazioni Web Java Based
sviluppate da Gruppo Servizi e file sharing.
Una bozza di struttura della intranet e dei relativi servizi per il file sharing è di seguito
rappresentata:
Area Pubblica: l'accesso a questa parte della intranet è soggetto a Login e Password (solo i
clienti abilitati potranno entrare) ed è visibile anche agli utenti interni.
Programma X (pagina accessibile a tutti gli utenti registrati):
o Segnalazione Bug (per ogni programma un utente può inserire informazioni relative a
presunti bug).
o Segnalazione Migliorie (per ogni programma gli utenti possono inserire suggerimenti
per nuove implementazioni).
o FAQ (i clienti possono solo leggere).
o Releases e Patches (con possibilità di download) (i clienti possono solo leggere).
o History ed Elenco versioni rilasciate (i clienti possono solo leggere).
Programma Y:
o ...
o ...
o ...
Pagina privata utente: ogni utente ha accesso a questa pagina in cui può modificare informazioni
e gestire allegati (questa pagina è la candidata per sostituire l'area di scambio).
Pagina di News di Gruppo Servizi: in questa pagina potrebbero essere pubblicate informazioni
che Gruppo Servizi vuol rendere disponibile a tutti gli utenti ma in forma riservata, ovvero
senza pubblicarle sul sito ufficiale.
Area Privata: l'accesso a questa parte è visibile solo agli utenti interni, che tipicamente potranno
accedere a tutte le pagine.
Richieste di intervento/acquisto HW
8
Installazioni (trasversale a tutti i prodotti dovrebbe fornire indicazioni sul cliente, prodotto,
Consulente Responsabile, Tecnico Responsabile, Data Scadenza).
Gestione Documenti (potrebbe essere implementato un db di documenti reperibili via Web con
possibilità di ricerca sui contenuti... ecc. ecc...)
Gestione Programmi Software:
o Programma X:
Elenco lavori schedulati (con indicazione di assegnazione risorse, tempistiche, ecc...)
Elenco proposte per new release
...
o Programma Y:
...
...
...
Knowledge Base (in questa sezione - correlata da funzionalità di ricerca- gli utenti inseriscono e
trovano informazioni e trucchi sui vari argomenti):
o Visual Basic
o Power Builder
o Database
o Oracle
o SQLServer
o Java
o HTML e/o JavaScript
o ...
Utenti e Gruppi
Dovranno esistere 2 gruppi: "GruppoServizi" e "Cliente". Gli utenti del primo gruppo potranno
tipicamente modificare e vedere tutte le pagine della intranet. Gli utenti del secondo gruppo vedono
solo la parte pubblica e di tale parte possono modificare solo alcune pagine/sezioni. Inoltre avranno
accesso ad una propria pagina personale non visibile dagli altri utenti "Cliente". Dovrà esistere un
utente Amministratore in grado di creare nuovi utenti per la parte pubblica. Si potrà accedere alla
parte pubblica solo se si è utenti di "GruppoServizi" o "Cliente". La parte privata (non accessibile
dall'esterno) potrà consentire ai nuovi utenti di creare nuovi account (un utente può essere creato da
chiunque).
9
Riassumendo:
- installazione e configurazione di un Server Linux (versione da definire);
- installazione della virtual machine Java;
- installazione e configurazione di Web Server Apache;
- installazione di un’architettura sistemistica in grado di integrare il Server Linux con il
dominio Windows 2000 (tipo Samba);
- creazione di uno spazio di sviluppo di progetti, gestione documenti e database di
informazioni (ad esempio TWiki).
10
1. Come avvicinarsi a Linux?
Dieci anni fa uno studente universitario di nome Linus Torvalds annunciava sul newsgroup
comp.os.minix che aveva iniziato a lavorare su un sistema operativo per piattaforma Intel 386,
leggero e ispirato a Unix. ”Semplicemente un hobby”: cosi egli stesso definiva il proprio lavoro:
oggi quel sistema operativo, Linux gira su macchine di qualunque tipo, a partire dai portatili e dai
dispositivi embedded per arrivare a grossi mainframe.
Linux viene rilasciato sotto la Gnu General Public License (Gpl), che impone la distribuzione del
codice sorgente assieme ai programmi e la distribuzione sempre sotto licenza Gpl dunque anch’esso
deve essere liberamente distribuibile.
Un argomento spesso portato a sostegno dell’open-source è che il software open–source sia di
qualità superiore rispetto a quello commerciale perché “se ci sono abbastanza occhi aperti, tutti i
bug vengono a galla”. In molti ambienti, la semplice definizione di sistema operativo è un
argomento in grado di scatenare vere e proprie guerre di religione. La maggior parte degli utenti
Windows potrebbe indicare con questo termine una singola applicazione che include diversi
software creati per interagire con il proprio computer. Per un utente Linux, invece, il termine è
sinonimo di una raccolta di molti programmi piccoli e indipendenti, ma strettamente legati fra di
loro.
Di questo concetto è permeato Linux (e più in generale l’intero mondo Unix), popolato da piccoli
componenti ben distinti tra loro che interagiscono in modo tale da fornire un servizio complesso.
Questo principio offre indubbi vantaggi in termini di flessibilità e robustezza del codice: i
sostenitori di Linux, ad esempio, deridono gli utenti di altre piattaforme sulle quali è necessario
riavviare il sistema dopo aver installato del software, operazione necessaria molto di rado in tale
ambiente. D’altro canto, per l’utente medio, la presenza di molti tool dalle funzionalità
assolutamente specifiche può rendere più complessa la gestione del sistema. Il cuore di ogni sistema
operativo Unix -incluso Linux – è il kernel, che comunica direttamente con l’hardware, gestisce la
memoria di sistema, distribuisce le risorse ai vari processi ed effettua lo scheduling dei processi in
esecuzione. È assieme il contabile, il vigile e il buttafuori del sistema operativo. Il kernel in se,
tuttavia, non fa nulla di particolarmente interessante: deve essere accompagnato da una certa
quantità di tool, utilità e programmi alcuni dei quali agiscono quasi al livello del kernel stesso, che
si occupano di compiti come la gestione dei file system, l’allocazione della memoria e il controllo
dell’hardware. Gli utenti spesso si sorprendono quando vengono a sapere che molti dei comandi che
usano, per esempio ls e cd, sono in realtà piccoli programmi indipendenti, la maggior parte dei
quali non è stata nemmeno scritta dagli sviluppatori Linux, ma da quelli della Free Software
11
Fondation. Anche l’interfaccia utente (GUI, Grafical User Intreface), il componente maggiormente
visibile del sistema operativo, non è per Linux altro che una semplice applicazione, per quanto di
grosse dimensioni e molto complessa. L’interfaccia grafica si compone di un sistema a finestre,
solitamente Xfree86, e di un window manager: fra questi ultimi i più diffusi sono oggi KDE e
Gnome.
Ciò significa che, a differenza di quanto accade per Windows, gli utenti Linux possono decidere
con la massima libertà quale interfaccia grafica utilizzare per il sistema operativo.
1.1. Le distribuzioni
Ogni utente abbastanza esperto può in teoria costruirsi il proprio Linux assemblando manualmente
tutti i componenti, anche se il processo è decisamente complicato e piuttosto dispendioso in termini
di tempo. Numerose aziende hanno fatto cosi il loro ingresso nel mondo dell’open-source creando
le cosiddette “distribuzioni Linux”, che eliminano la maggior parte del lavoro noioso di
acquisizione dei dati, installazione e amministrazione delle applicazioni, aggiungendo al semplice
sistema operativo tool per l’installazione dei pacchetti e la gestione del sistema e di altre utilità. Per
le caratteristiche della licenza Gpl, le aziende che producono le distribuzioni non modificano
comunque il sistema operativo ma, al contrario, sviluppano i propri prodotti raccogliendo i tool per
l’installazione e la gestione attorno al cuore di Linux, riunendoli su uno o più cd-rom e vendendo il
pacchetto completo di un contratto di supporto.
Data la natura estremamente personalizzabile di Linux, ciascuna azienda può dedicarsi ad una
nicchia di mercato e costruire un prodotto che si adatti ad essa..Mandrake è la distribuzione più
semplice da installare, oltre che quella più adatta a agli utenti non familiari con il mondo Unix.
Debian invece ha fatto una scelta diversa, focalizzando la propria attenzione sull’aderenza agli
standard, sulla sicurezza e del software e della sua stabilità.
12
Tu
rbo
Lin
ux S
erver 6
.5
Su
Se L
inu
x 7
.3
Red
Hat P
rofessio
nal 7
.2
Man
drak
e Lin
ux
Pro
Su
ite Ed
itino
8.1
Deb
ian G
nu
/Lin
ux
2.2
(po
tato)
Cald
era Op
en L
inux
Serv
er 3.1
Distrib
uzio
ne
Tu
rbo
linu
x In
c.
Su
SE
Gm
bH
Red
Hat In
c.
Man
drak
eSo
ft S.A
.
Th
e Deb
ian P
roject
Cald
era Intern
ation
al
Inc.
Azien
da
Do
llari US
A 2
00
Eu
ro 6
8
Eu
ro 2
11
,67
Eu
ro 1
49
Gratu
ito
Eu
ro 7
69
,52
Prezzo
Ap
plicazio
ni sp
ecializzate
ed en
terprise d
i alto
livello
; cluster e serv
er
datab
ase.
Ap
plicazio
ni m
idran
ge p
er
wo
rkstatio
n e serv
er;
simile a R
ed H
at per
l’adattab
ilità a camp
i
div
ersi, con
alcun
e
differen
ze di d
esign
.
Qu
alsiasi tipo
di u
tente
softw
are adatto
a og
ni
situazio
ne.
L’u
tente fin
ale; Man
drak
e
forn
isce po
tenti stru
men
ti
di co
nfig
urazio
ne p
er l’uso
della d
istribu
zion
e sul
pro
prio
desk
top
o su
l
po
rtatile.
Uten
ti esperti ch
e
desid
erano
i pacch
etti
essenziali e u
na
distrib
uzio
ne p
riva d
i
fron
zoli.
Seg
men
to d
i mercato
En
terprise. O
pen
Lin
ux
offre p
acchetti p
er la
sicurezza d
el server p
er
l’e-com
merce.
Targ
et
Pacch
etti per sp
ecifiche
app
licazion
i com
e i
datab
ase e per sp
ecifici usi
com
e servizi d
i clusterin
g.
Installazio
ne sem
plice e
com
plete u
tility d
i
con
figurazio
ne.
Distrib
uzio
ne b
en
bilan
ciata.
Installazio
ne im
peccab
ile e
ottim
a integ
razion
e deg
li
strum
enti d
i config
urazio
ne
pro
prietari; n
on
richied
e
trop
pa co
mp
etenza su
Lin
ux
.
È “p
uro
Lin
ux
”; u
tile agli
amm
inistrato
ri che
desid
erano
avere il
con
trollo
com
pleto
sul
sistema.
Ottim
o su
pp
orto
aziend
ale e
gran
de in
tegrazio
ne fra
server e w
ork
station
.
Pu
nti d
i forza
1 C
d-R
om
; rou
tine d
i
installazio
ne n
ella
med
ia.
7 C
d-R
om
+ 1
Dvd
-
Ro
m; Y
aST
2 è m
olto
semp
lice da u
tilizzare.
10
Cd
-Ro
m +
1 D
vd
-
Ro
m; b
uo
ne le ro
utin
e di
installazio
ne e il to
ol d
i
partizio
nam
ento
del
disco
.
9 C
d-R
om
+ 1
Dvd
-
Ro
m; o
ttime ro
utin
e di
installazio
ne.
3 im
mag
ini Iso
disp
on
ibili o
n-lin
e;
l’installazio
ne rich
iede
qu
alche co
mp
etenza
tecnica.
5 C
d-R
om
; rou
tine d
i
installazio
ne n
ella
med
ia.
Med
ia e istallazion
e
13
Tu
rbo
To
ols fo
rnisce le
fun
zion
alità di
amm
inistrazio
ne d
i base.
YaS
T2
è un
eccellente e
com
pleto
too
l di
con
figurazio
ne.
Set d
i utilità d
i
con
figurazio
ne stab
ile e
stand
ard.
Gran
de q
uan
tità di u
tilità
di co
nfig
urazio
ne
pro
prietarie.
Pacch
etto p
oten
te e
priv
o d
i abb
ellimen
ti.
Vo
lutio
n,
un
’app
licazion
e a livello
enterp
rise per la g
estion
e
della rete.
Utility
di co
nfig
urazio
ne
On
-line in
form
ato P
df.
Am
pia 6
man
uali
inclu
si.
Am
pia 4
man
uali
inclu
si.
Man
uali u
tente e d
i
riferimen
to; d
ispo
nib
ili
anch
e in H
tml e p
df in
sei ling
ue d
ifferenti.
On
-line, p
df su
CD
-
Ro
m.
Su
cd ro
m e o
n-lin
e; la
cop
ia cartacea dei
man
uali d
i riferimen
to è
disp
on
ibile co
n i
pacch
etti avan
zati.
Do
cum
entazio
ne
Div
erse sotto
scrizion
i e pacch
etti di
sup
po
rto su
lla base d
elle richieste d
i
interv
ento
; supp
orto
tramite sito
web
.
60
gio
rni d
i supp
orto
po
st-
installazio
ne; su
pp
orto
tramite m
ailing
list e sito W
eb.
Div
erse sotto
scrizion
i e pacch
etti di
sup
po
rto su
lla base d
elle richieste d
i
interv
ento
; amp
ia kno
wled
ge b
ase sul
sito W
eb, ch
e inclu
de il su
pp
orto
per
pro
do
tti, app
licazion
i e svilu
pp
o.
Div
erse sotto
scrizion
i e pacch
etti d
i
sup
po
rto su
lla base d
elle richieste d
i
interv
ento
.
Riso
rse per la ricerca o
n-lin
e “tra
com
un
ità di u
tenti”; co
mun
ità di
svilu
pp
atori m
olto
attiva.
Sito
Web
; sup
po
rto in
ternazio
nale p
er
gli sv
ilup
pato
ri bu
siness e g
li uten
ti
finali; d
iverse so
ttoscrizio
ni, co
ntratti
di assisten
za e pacch
etti di su
pp
orto
sulla b
ase delle rich
ieste di in
terven
to.
Su
pp
orto
tecnico
Su
pp
orto
garan
tito in
gen
ere
attraverso
app
lication e so
lutio
n
pro
vid
er..
Do
po
Red
Hat, u
na d
elle aziend
e
di m
agg
ior p
eso su
l mercato
.
Div
ersi pro
gram
mi p
recom
pilati
solo
per R
ed H
at e Su
Se.
La p
osizio
ne d
i Red
Hat assicu
ra
ottim
izzazion
i a livello
di
con
figurazio
ni h
ardw
are e la
disp
on
ibilità d
i app
licazion
i per
qu
esta piattafo
rma.
Man
drak
e ben
eficia della
deriv
azion
e da R
ed H
at; gli u
tenti
po
sson
o g
od
ere dei v
antag
gi d
el
do
min
io d
i Red
Hat n
el campo
delle d
istribu
zion
i Lin
ux
.
Alle sp
alle di D
ebian
vi è l’in
tera
com
un
ità di sv
ilup
pato
ri op
en-
sou
rce che assicu
ra il rilascio d
i
app
licazion
i stabili e ag
gio
rnate.
Su
pp
orto
garan
tito in
gen
ere
attraverso
app
lication e so
lutio
n
pro
vid
er.
Su
pp
orto
di m
ercato
Giu
dizio
glo
bale
= Eccellente
= Molto buono
= Buono
= Discreto
= Scarso
14
La flessibilità di Linux, il suo basso costo e la capacità di girare anche su hardware non troppo
recente, sono le qualità che hanno convinto coloro che per primi hanno adottato questa piattaforma
a introdurla in molte reti aziendali. Un altro vantaggio di Linux è la sua spiccata propensione
all’utilizzo in rete, ad esempio per condividere i file e stampanti su reti NetWare, Unix e Windows.
La penetrazione di Linux nel mercato desktop, tradizionalmente riservato a Windows e Mac Os, è
però ancora piuttosto limitata: mentre i fan di Unix e gli sviluppatori in genere spesso usano Linux
anche sulle proprie workstation, questo sistema operativo continua a suscitare la maggior attenzione
in ambito server. Occorre comunque sottolineare i passi compiuti per rendere Linux un sistema
operativo utilizzabile dall’utente medio a partire dall’interfaccia dei window manager, le cui
versioni più recenti iniziano a potersi confrontare, per semplicità d’uso, con Windows e Mac Os.
In ogni caso la complessità del core Unix rimane immutata, anche se ben nascosta, e forse anche per
questo Linux richiede qualche competenza in più da parte dell’utente. Secondo uno studio svolto da
Idg, il primo impedimento all’adozione di Linux in azienda è la mancanza di personale interno
competente; altri aspetti che scoraggiano l’adozione di Linux sono la mancanza di supporto da parte
dal produttore e la riluttanza ad introdurre all’interno dell’azienda un sistema operativo
completamente nuovo.
Dunque visti questi potenziali aspetti negativi, perché un’azienda dovrebbe passare a Linux?
Sicuramente perché una volta superato il primo impatto con il nuovo sistema operativo, si
guadagnano notevoli benefici, il più importante dei quali e nel contempo quello più citato è la
mancanza di una software house di riferimento assoluto che possano comportarsi in modo
monopolistico. Si possono elencare altri vantaggi, fra i quali l’incremento del tasso di sviluppo e di
supporto delle applicazioni Linux. Le ultime release del kernel, dotate di migliori capacità di
multiprocessing simmetrico (Smp, Symmetrical Multi Processing), hanno permesso a Linux di
occupare posti sempre più importanti sui server aziendali. I nuovi file system con funzionalità di
journaling sono inoltre in grado di mantenere un log delle modifiche dei dati su disco, in modo da
ripristinarli in caso di crash e rendono assai poco probabili la perdita dei dati. Inoltre diversi
produttori di hardware rilasciano oggi driver per Linux oltre che per Windows, e aziende come IBM
hanno addirittura a listino sistemi con una distribuzione Linux gia preinstallata.
Ora il problema rimane nel decidere quale distribuzione scegliere.
A differenza di Windows, Linux richiede una conoscenza di base dell’architettura del sistema. Il
cuore di Linux è il kernel, che gestisce tutte le funzioni di “basso livello”. Il codice del kernel è in
realtà molto ristretto: Linux carica infatti al volo molte delle funzionalità di cui necessita, lasciando
libera la memoria per altri compiti. Per inciso oggi la maggior parte dei sistemi operativi carica
invece la maggior parte dei propri componenti direttamente all’avvio della macchina, a prescindere
15
dal fatto che queste siano utilizzate o meno. Le interfacce grafiche di Linux iniziano inoltre a far
competere Linux con Windows in termini di utilizzabilità nella maggior parte delle più comuni
operazioni.
I requisiti minimi hardware per far girare Linux sono modesti: sono sufficienti un microprocessore
Pentium, 16 MByte di Ram e 50 MByte di spazio su disco, e se si vuole usare anche l’interfaccia
grafica c’è bisogno di altri 100Mbyte di spazio su disco. I sistemi sui quali gira Linux possono
essere utilizzati per mesi senza che un crash o un blocco di sistema ne renda necessario un riavvio.
Tuttavia, così come accade sotto Windows, anche le applicazioni Linux non devono passare un test
formale di qualità, e un codice colmo di bug può talvolta causare il blocco di alcuni processi o
dell’interfaccia grafica. Sotto Linux, però, l’interfaccia grafica stessa è un programma come tutti gli
altri e come tale può essere chiusa e rieseguita senza per questo dover riavviare la macchina.
Il kernel di Linux è sicuro, ma il framework che lo circonda può aprire falle che possono permettere
a un malintenzionato l’ingresso non autorizzato del sistema. Virus e worm colpiscono inoltre anche
macchine Linux, ma va detto che questo sistema operativo è in genere più protetto rispetto ad altre
piattaforme.
Solo dopo aver provato Linux si potrà apprezzare la disponibilità di applicazioni e tool gratuiti il cui
prezzo sarebbe assai elevato in un ambiente commerciale, facendo cosi emergere rapidamente le
vere potenzialità di questo sistema operativo.
Andando ad esaminare le varie distribuzioni sono venuti fuori i seguenti aspetti.
Per Caldera Open Linux 3.1: è un supporto di ottimo livello e una grande quantità di prodotti, tra
cui alcune soluzioni orientate al commercio elettronico, rendono Caldera OpenLinux Server 3.1 una
scelta decisamente attraente. La decisione di caldera di fare una netta distinzione tra le piattaforme
client e server sottolinea la volontà di rendere i propri prodotti appetibili al mercato aziendale.
Openlinux 3.1 offre un proprio prodotto per l’installazione e la configurazione del sistema: Lizard è
il nome dato da Caldera a una sofisticata routine di installazione curata nei particolari quanto
DrakConf di Mandrake, con cui si possono scegliere cinque configurazioni predefinite per la
piattaforma server e semplificare così il processo di installazione.
Openlinux Workstation 3.1 non è certo migliore di altre distribuzioni ma è senz’altro un’ottima
scelta se si progetta un’infrastruttura basata su Linux e si desidera affidarsi a un unico produttore.
Distinguendosi dal resto del mondo Linux, Caldera pone un particolare risalto sul ridotto costo di
possesso in ambiente corporate. Per raggiungerlo l’azienda ha sviluppato diversi tool e pacchetti,
primo tra tutti Volution, un software di gestione e amministrazione del sistema basato su
un’interfaccia Web. Costruito intorno a Ldap, Volution è progettato per aiutare gli amministratori
16
nell’implementazione di profili e policy di rete, inventari hardware e software, installazioni
centralizzate, upgrade, rilevamenti di intrusioni e monitoraggio dello stato dei sistemi aziendali.
Il servizio di supporto di Caldera è di ottimo livello.
Esaminando ora Debian Gnu/Linux 2.2 (potato) è risultato che: è la meno commerciale fra le
distribuzioni Linux, è gestita da una comunità di utenti piuttosto che da un’azienda. Date queste
premesse e ricordato lo stretto legame tra Debian e Free Software Foundation è facile comprendere
come Debian abbia la reputazione di essere la distribuzione scelta dai guru di Linux, fama che può
rivelarsi a doppio taglio.
Da un punto di vista aziendale il più grosso svantaggio di Debian è la mancanza di una casa madre
che fornisca un supporto adeguato: si tratta di “free software” nel senso più puro della parola, e
questo fatto potrebbe non essere gradito da alcuni amministratori e responsabili IT. I creatori di
Debian hanno fatto poco per semplificare il processo di apprendimento, quindi chi si avvicina a
Linux per la prima volta è meglio che si rivolga verso altre distribuzioni che offrono miglior
documentazione. I servizi di rete e gli strumenti per lo sviluppo di Debian Gnu/Linux sono
paragonabili a quelli delle altre distribuzioni: mantenendo fede alla natura prudente e conservatrice
di coloro che l’hanno creata, Debian spesso utilizza software in versioni non troppo recenti. I
responsabili di questa distribuzione infatti preferiscono utilizzare pacchetti ben collaudati e che
abbiano dato prova di stabilità e assenza di bug. Per esempio Debian non include le versioni più
recenti del kernel di Linux, dell’interprete Perl e del sistema X window. Ciò la rende inadatta a
sistemi dotati di hardware particolarmente recente (per esempio periferiche usb e schede video
appena uscite): la rivelazione e la configurazione dell’hardware può rivelarsi, in questi casi,
un’operazione poco agevole anche per l’utente più esperto, se non addirittura impossibile senza
adottare software più aggiornato. Uno dei motivi di vanto della maggior parte dei sostenitori di
Debian è il sistema di gestione dei pacchetti, APT (Advanced Package Tool è la risposta di Debian
al gestore di pacchetti di Red Hat, utilizzabile per installare, aggiornare e disinstallare software sia
in locale sia da diversi Ftp remoti.
Mandrake Linux ProSuite Edition 8.1: è un prodotto di qualità e decisamente stabile. Mandrake si è
dimostrata nei nostri test una delle più amichevoli e intuitive distribuzioni disponibili. Basata su
Red Hat, Mandrake è la miglior scelta per gli utenti alle prime armi, che non dovrebbero incontrare
nessun problema nell’utilizzare le applicazioni di questa distribuzione, tuttavia non può ancora
competere con caldera e Red Hat per quanto concerne la disponibilità di supporto. E’ da ritenere
giusto l’utilizzo di questa distribuzione sia per desktop che per notebook.
Le procedure di installazione, basate su interfacce testuali, erano spesso un primo scoglio di fronte a
cui molti utenti si arenavano. Con il tool di installazioni di Mandrake non c’è questo problema: in
17
15 passi, illustrati in modo chiaro, l’utente viene guidato verso l’installazione e la configurazione
del sistema, senza che sia necessario intervenire manualmente su alcun file di configurazione.
Una delle caratteristiche più apprezzate di Mandrake è il meccanismo di selezione dei pacchetti,
spesso uno dei punti più critici e macchinosi delle procedure di installazione. L’installer divide i
pacchetti in due gruppi logici, rispettivamente per server e workstation. All’interno delle due
categorie i software sono raggruppati in base alle funzioni e al loro utilizzo sul sistema, ed è
possibile scegliere liberamente pacchetti appartenenti alle diverse categorie fino ad ottenere la
selezione più adatta alle proprie esigenze. Ottime sono anche le procedure di installazione
automatica della stampante, dei wizard di rete, della configurazione della connessione remota e del
meccanismo di attivazione dei servizi. Distribuzione corredata da due manuali abbastanza chiari: la
guida all’installazione conduce gli utenti poco esperti nel processo di installazione di Mandrake
mentre gli argomenti più approfonditi come la sicurezza o la configurazione dettagliata del sistema
sono trattati nel secondo manuale. Rendere sicuro il proprio sistema è ancora un compito complesso
ma con l’utility Bastile risulta un po’ più semplice. Con questa utilità è possibile scegliere fra tre
tipi diversi di sicurezza predefiniti.
In ogni segmento del mercato del software si può trovare un prodotto considerato leader e per
quanto riguarda Linux questo viene svolto da Red Hat. Questa distribuzione viene considerata come
uno standard per gli sviluppatori. Con la versione 7.2, che l’azienda ha acquistato, Red Hat rimane
all’altezza della sua fama. Debian può essere l’alternativa più indicata per i puristi del free software,
Mandrake la più adatta per gli utenti desktop alla ricerca di un ambiente semplice da utilizzare:
tuttavia in un ambiente aziendale, Red Hat è a nostro parere la scelta più sicura. La versione
acquistata è corredata da una grande quantità di tool e di software: Red Hat mette a disposizione
dell’utente il kernel 2.4.7 compilato in diverse versioni, compilatori per tutti i principali linguaggi di
programmazione e strumenti di vario genere. L’installazione, priva di inutili fronzoli, è una delle
più sicure fra quelle disponibili per Linux. A tutt’oggi i punti più critici nell’installazione dei
sistemi operativi Linux sono il partizionamento dei dischi, il riconoscimento dell’hardware e
l’installazione del software, ambiti in cui Red Hat 7.2 eccelle. Per il partizionamento del disco Red
Hat fa ricorso all’utility Disk Druid, utility caratteristica di questa distribuzione. Il software
permette di applicare in modo automatico tre schemi predefiniti per la distribuzione dello spazio su
disco per configurare il computer rispettivamente come workstation, server o laptop, ma lascia
liberi gli utenti più esperti di gestire in prima persona tale operazione. L’elenco delle periferiche
riconosciute da Red Hat è molto ampio e cresce in maniera costante.
Le distribuzioni di Linux forniscono solitamente un’enorme quantità di software. Riconoscendo che
questo fatto potrebbe indurre in confusione l’utente, Red Hat effettua una selezione dei programmi
18
a seconda dell’utilizzo del sistema indicato durante l’installazione anche se la lista di pacchetti può
essere modificata e personalizzata. La gestione dei pacchetti si basa su RPM (Red Hat Manager),
tool in grado di aiutare gli amministratori nel compito di installare, aggiornare, rimuovere e gestire
il software. Nonostante gli amministratori esperti solitamente mettono mano a Linux direttamente
tramite la linea di comando, Red Hat offre una buona serie di strumenti basati sull’interfaccia
grafica, fra cui citiamo il tool Linuxconf. La documentazione cartacea e quella elettronica sono ben
bilanciate nell’offrire un certo livello di dettaglio pur mantenendosi comprensibili ai nuovi utenti.
Passando alla versione SuSe Linux 7.3 Professional Edition: è corredata da un’ampia e aggiornata
quantità di software free e open-source. La distribuzione include tutti i tool di sviluppo Gnu, i
servizi di rete standard (Apache, Bind, Samba e così via), i principali data base server (MySql, e
PostgreSql) e il supporto per la maggior parte dei linguaggi di programmazione. Durante
l’installazione gli utenti hanno modo di familiarizzare con YaST2 (Yet Another Setup Tool),
l’utilità di gestione del sistema fornita da SuSe. YaST2 si occupa di partizionare i dischi,
configurare l’hardware, selezionare il software e completarne l’installazione. L’utility è veramente
notevole: ha un aspetto curato, è semplice da utilizzare e muovendosi fra i suoi menu è abbastanza
facile amministrare molti degli aspetti del sistema operativo. Ha delle ottime routine di rivelazione
dell’hardware. L’installazione di SuSe Lnux Professional 7.3 è in grado di rivelare e configurare
non solo le schede di rete, le schede audio e i modem, ma anche le stampanti, gli adattatori isdn e le
schede Tv eventualmente presenti sul sistema.
Un aspetto che può creare qualche confusione è quello legato al particolare utilizzo che la
distribuzione fa del file system. SuSe tende a “personalizzare” le posizioni predefinite per diverse
componenti del sistema, ad esempio installando il software applicativo nella directory /opt invece
che in /usr più frequentemente utilizzata. Questo significa che gli utenti gia familiari con le altre
versioni di Linux devono porre attenzione a riservare spazio sul disco durante la partizione che
conterrà tale directory. L’approccio di SuSe è poco diffuso nel mondo Linux, e se anche si tratta
tecnicamente di una maniera accettabile di partizionare e gestire il sistema, potrebbe essere fonte di
spiacevoli sorprese a causa della sua scarsa diffusione.
Passando a TurboLinux 6.5: mentre tutte le altre distribuzioni hanno posto l’accento su elementi
quali la facilità d’uso e l’ampiezza dell’offerta di software, TurboLinux ha seguito una sua strada,
creando differenti versioni mirate a specifici ambienti di utilizzo: in questo modo possono
risparmiare molto tempo ad esempio gli utenti aziendali cui è sufficiente la soluzione pacchettizzata
fornita dall’azienda, perché ogni elemento della distribuzione è preconfigurato e testato per
funzionare perfettamente integrandosi con il resto del software incluso.
19
TurboLinux fornisce i medesimi servizi di rete delle altre distribuzioni, ma si distingue per una
scelta conservatrice del kernel 2.2.18 in luogo dei più recenti kernel 2.4.x. Se così da una parte, a
TurboLinux mancano alcune nuove caratteristiche, occorre però sottolineare come tale distribuzione
risulti più probabilmente esente da bug. Anche per TurboLinux possiamo dire che la propensione
all’uso di sistemi desktop è piuttosto scarsa. La dotazione software non proprio aggiornata rende
particolarmente complesso il lavoro di configurazione delle periferiche più recenti.
TurboLinux pone la sua attenzione nel garantire agli utenti la sicurezza della propria distribuzione,
cercando di impedire potenziali exploit di servizi di rete come telnet e Ftp. A differenza di molti dei
prodotti concorrenti, questi servizi sono tra l’altro disattivati secondo le impostazioni di default.
Turbolinux è corredata da una versione sicura di Apache, dal software di controllo del server
Tripwire e da OpenSsh. La routine di installazione di Turbolinux sono semplici e pratiche ma prive
degli abbellimenti grafici che caratterizzano alcune delle altre distribuzioni da noi esaminate.
Coloro che sono poco pratici con le procedure di installazione Unix si troveranno probabilmente più
a proprio agio con i tool forniti da altre distribuzioni.
Le utilità in Turbolinux, chiamate Turbo Tools, forniscono un’interfaccia grafica per la
configurazione e l’amministrazione dei servizi più comuni e delle applicazioni, in modo non
completo come avviene con Linuxconf o YaST2 ma comunque funzionale. Come la maggior parte
delle distribuzioni, Turbolinux utilizza RPM per l’installazione, la gestione, la disinstallazione del
software, vero standard nel settore anche se alcuni utenti più esperti potrebbero preferire il sistema
APT (Advanced Package Tool) di Debian. Fedele alla sua natura di distribuzione orientata alla
praticità, la documentazione Turbolinux è disponibile solo in formato elettronico (.pdf) e sul sito
Web dell’azienda. Turbolinux offre 60 giorni di supporto via e-mail, oltre a vari tipi di contratti di
supporto.
1.2. Scelta della distribuzione Linux
Nell’azienda abbiamo discusso a lungo per decidere a quale distribuzione affidarci per creare una
postazione Web Server sulla rete interna, ma alla fine siamo stati tutti d’accordo nello scegliere Red
Hat Linux Professional 7.2. Molti fattori hanno influenzato il giudizio a favore di Red Hat: i più
importanti sono la sua qualità, la semplicità d’uso e l’ottima fama di cui essa gode in ambito
aziendale. Nonostante altre distribuzioni le siano superiori nello svolgere specifici compiti, nessuna
è così ben bilanciata e versatile. La longevità di Rad Hat nel mercato Linux sta inoltre a
testimoniare la sua compatibilità con i sistemi usati in azienda. Molto vicino a Red Hat giunge,
seconda scelta possibile, SuSE, la distribuzione più diffusa sul mercato europeo.
20
1.3. Requisiti di sistema Intel
Linux è in grado di funzionare in quasi tutti i computer moderni che usano processori intel. Se il
computer può usare il sistema operativo Dos o Windows potrà generalmente eseguire Linux.
Secondo Red Hat si elencano i requisiti di sistema necessari per eseguire Red Hat Linux sulle
piattaforme Intel:
Processore Intel 386 o superiore.
Spazio disponibile su disco. 850 MB per l’installazione Workstation e 1.7 GB per
un’installazione Server. E’ possibile ridurre la dimensione dell’installazione ed installare
meno software eseguendo l’installazione nella modalità expert mode.
Si raccomanda di usare almeno 32 MB di memoria o più; se non si usa X11, si possono
usare 16 MB di RAM, mentre si consiglia di usare almeno 64 MB se si pensa di usare X11 e
di eseguire diversi client contemporaneamente.
Il supporto alle schede video è migliore per quelle rilasciate da almeno un anno. Il supporto
alle schede grafiche più recenti, con maggiori funzionalità, potrebbe essere solo parziale.
Per facilitare la procedura di installazione è consigliabile impostare il BIOS per consentire
l’avvio da Cd-Rom.
Drive floppy da 3,5 pollici per creare il disco di ripristino o per eseguire installazioni
speciali per mezzo di PCMCIA, PLIP, FTP, NFS o HTTPD.
Per effettuare il multiboot è necessario creare una partizione separata o installare un disco
separato per Linux.
1.4. Macchine utilizzate per i test
Il server Linux (Linux Red Hat 7.2) è un Pentium-II a 400 MHz, 256 MB di RAM, Hard
Disk da 9 GB, collegamento alla rete Microsoft aziendale.
Il client Windows (Windows 98 SE) è un Pentium-S a 166 MHz con 64 MB di RAM e Hard
Disk 2 GB, collegamento alla rete Microsoft aziendale.
Server Windows (Windows 2000 Professional Server) aziendale.
Altri vari client Windows (Windows 2000 Professional Workstation, Windows 2000
Professional Server) appartenenti alla rete aziendale.
1.5. Prima di installare
Red Hat Linux offre cinque differenti classi di installazione:
21
Workstation
E’ la più appropriata per i nuovi utenti del mondo Linux. L’installazione workstation creerà
un sistema per l’utilizzo home. Verrà installata l’interfaccia grafica.
Server
E’ la più appropriata se si vuole creare un sistema basato su un server Linux, e se l’utente
vuole personalizzare pesantemente la configurazione del sistema.
Laptop
E’ stata progettata per essere istallata sui portatili in modo molto semplice. Installerà i
pacchetti necessari offrendo un’installazione automatica ed intuitiva.
Custom
Permette all’utente una grande flessibilità durante l’installazione. Possono essere scelti il
boot loader, i pacchetti desiderati, ecc. Questa installazione è la più appropriata per utenti
esperti di Red Hat o per chi ha paura di perdere la completa flessibilità.
Upgrade
Se è già presente una versione di Red Hat Linux (3.03 o superiore), verranno istallati solo gli
aggiornamenti del kernel e dei nuovi pacchetti.
L’installazione più appropriata per il nostro Web Server è quella Server:
Qui sotto sono riportati i minimi spazi su disco richiesti per tale tipo di installazione in una sola
lingua (ad esempio Italiano).
Server (installazione minima, senza interfaccia grafica): 1GB
Server (installazione completa, senza interfaccia grafica): 1.3 GB
Server (installazione completa, con interfaccia grafica GNOME e KDE): 2 GB
Se si pensa di installare tutti i gruppi di pacchetti, oppure selezionare individualmente pacchetti
aggiuntivi, ci sarà bisogno di un minimo di 1.2 GB o più. Durante l’installazione X Window System
non sarà configurato e nessuna GUI verrà caricata per default all’avvio del sistema, a meno che
non vengano scelti manualmente i pacchetti appropriati.
La dimensione della partizione swap è determinata dalla quantità di RAM che è presente sul
sistema e dall’ammontare dello spazio disponibile sull’hard disk. Per esempio, se il pc
dispone di 128 MB di RAM sarà creata una partizione di swap tra i 128 MB ed i 256 MB (il
doppio della RAM), che dipende dalla disponibilità di spazio libero sul disco.
Una partizione 384 MB (montata come /).
Una partizione di almeno 1.4 GB (montata come /usr).
Una partizione di almeno 512 MB (montata come /home).
22
Una partizione di 256 MB (montata come /var).
Una partizione di 50 MB (montata come /boot) nella quale risiedono il kernel ed i relativi
file.
Questo schema di partizionamento risulta appropriata per la maggior parte dei server; in ogni caso è
possibile effettuarlo manualmente.
Per effettuare l’installazione per la prima volta, è necessario effettuare il boot da Cd-Rom oppure
avere a disposizione i dischetti di avvio nel caso in cui il pc non preveda il boot da questa periferica.
Per effettuare il boot da floppy inserire un dischetto formattato ed eseguire l’utilità rawrite inclusa
nel Cd-Rom nella directory dosutils. A questo punto digitare dalla shell Dos i seguenti comandi:
C:\> d:
D:\> cd \dosutils
D:\dosutils> rawrite
Enter disk image source file name: ..\images\boot.img
Enter target diskette into drive: a:
Please insert a formatted diskette into drive A: and press --
ENTER-- : [Enter]
D:\dosutils>
Nel primo menu che compare è possibile scegliere in che modo effettuare l’installazione. Le scelte
possibili sono:
Installazione o upgrade in modalità grafica: [Enter]
Installazione o upgrade in modalità testo: text [Enter]
Abilitazione modalità expert: expert [Enter]
Abilitazione modalità rescue: rescue [Enter]
Se si dispone di un disco driver: linux dd [Enter]
1.6. Installazione di Red Hat Linux
A seguito sono riportati i menu d’installazione e le scelte da noi effettuate.
23
Selezione della lingua
Italiano
Selezione della tastiera
Modello: Generic 102-key (INTL) PC
Layout: Italiano
Dead Key: Abilita Dead Key
24
Configurazione mouse
3 button mouse PS/2
Opzioni d’installazione
Server
Setup della partizione del disco
Partizionamento automatico
25
Rimuovere tutte le partizioni sul sistema
La scelta del partizionamento automatico ha generato sulla nostra macchina una suddivisione del
disco come in tabella:
Dispositivo Inizio Fine Dimensione (MB) Tipo Mountpoint Formattare
/dev/hda
| /dev/hda1
1 6 47 ext3 /boot Sì
| /dev/hda2 7 794 6181 ext3 /usr Sì
| /dev/hda3 795 1082 2259 ext3 /home Sì
| /dev/hda4 1083 1229 1153 estesa
| /dev/hda5 1083 1131 384 ext3 / Sì
| /dev/hda6 1132 1196 510 swap Sì
| /dev/hda7 1197 1229 259 ext3 /var Sì
26
Installazione del boot loader
GRUB
Configurazione del boot loader
Installa il record del boot loader su MBR
Configurazione della rete
No DHCP
Attiva all’avvio
Indirizzo IP: 192.9.200.211
27
Netmask: 255.255.255.0
Network: 192.9.200.0
Broadcast: 192.9.200.255
Hostname: Linux01
Gateway: 192.9.200.2
DNS primario: 192.9.200.1
DNS secondario: 192.9.200.2
Configurazione del firewall
Nessun firewall
28
Selezione lingua di sistema
Italiano
Selezione dell’ora
Ora e fuso orario locale
Configurazione degli account
Password per root
Username e password per altri utenti
29
Selezione dei gruppi di pacchetti
KDE
Sistema X Window
Files Server Windows (SMB)
Server Web (WWW)
Selezione individuale dei pacchetti
Quelli riportati sono solo i pacchetti da noi installati
30
Package Name Version Description
4Suite 0.11 Python tools and libraries for XML processing and databases.
GConf 1.0.4 The Gnome Config System.
LPRng 3.7.4 The LPRng print spooler.
MAKEDEV 3.2 A program used for creating the device files in /dev.
Mesa 3.4.2 A 3-D graphics library similar to OpenGL.
ORBit 0.5.8 A high-performance CORBA Object Request Broker.
PyXML 0.6.5 XML libraries for python.
VFlib2 2.25.1 A vector font library used for Japanese document processing.
XFree86-100dpi-fonts 4.1.0 X Window System 100dpi fonts.
XFree86 4.1.0 The basic fonts, programs and documentation for an X workstation.
XFree86-75dpi-fonts 4.1.0 A set of 75 dpi resolution fonts for the X Window System.
XFree86-ISO8859-15-100dpi-fonts 4.1.0 ISO8859-15-100dpi-fonts
XFree86-ISO8859-15-75dpi-fonts 4.1.0 ISO8859-15-75dpi-fonts
XFree86-libs 4.1.0 Shared libraries needed by the X Window System.
XFree86-tools 4.1.0 Various tools for XFree86.
XFree86-twm 4.1.0 A simple, lightweight window manager for X.
XFree86-xdm 4.1.0 The X display manager.
XFree86-xf86cfg 4.1.0 A configuration tool for XFree86.
XFree86-xfs 4.1.0 A font server for the X Window System.
Xaw3d 1.5 A version of the MIT Athena widget set for X.
Xconfigurator 4.9.39 The Red Hat Linux configuration tool for the X Window System.
alchemist 1.0.18 A multi-sourced configuration back-end.
apache 1.3.20 The most widely used web server on the Internet.
apache-manual 1.3.20 Documentation for the Apache web server.
apacheconf 0.8.1 A configuration tool for Apache.
arpwatch 2.1a11 Network monitoring tools for tracking IP addresses on a network.
arts 2.2 A modularized sound system for KDE.
ash 0.3.7 A smaller version of the Bourne shell (sh).
asp2php 0.75.17 An ASP to PHP converter.
asp2php-gtk 0.75.17 This package contains a GUI GTK+ interface for the asp2php file format converter.
audiofile 0.2.1 A library for accessing various audio file formats.
aumix 2.7 An ncurses-based audio mixer.
auth_ldap 1.4.8 An LDAP authentication module for Apache.
authconfig 4.1.19 Text-mode tool for setting up NIS and shadow passwords.
autoconf 2.13 A GNU tool for automatically configuring source code.
autofs 3.1.7 A tool for automatically mounting and unmounting filesystems.
automake 1.4p5 A GNU tool for automatically creating Makefiles.
autorun 2.7 A CD-ROM mounting utility.
basesystem 7.0 The skeleton package which defines a simple Red Hat Linux system.
bash 2.05 The GNU Bourne Again shell (bash).
bdflush 1.5 The daemon which starts the flushing of dirty buffers back to disk.
bind 9.1.3 A DNS (Domain Name System) server.
bind-utils 9.1.3 Utilities for querying DNS name servers.
bindconf 1.6.1 A Red Hat DNS configuration tool.
bonobo 1.0.7 Library for compound documents in GNOME.
31
bzip2 1.0.1 A file compression utility.
bzip2-libs 1.0.1 Libraries for applications using bzip2
chkconfig 1.2.24 A system tool for maintaining the /etc/rc*.d hierarchy.
chkfontpath 1.9.5 Simple utility for editing the font path for the X font server.
compat-libstdc++ 6.2 Standard C++ libraries for Red Hat 6.2 backwards compatibility.
console-tools 19990829 Tools for configuring the console.
cracklib 2.7 A password-checking library.
cracklib-dicts 2.7 The standard CrackLib dictionaries.
curl 7.8 A utility for getting files from remote servers.
cyrus-sasl 1.5.24 The Cyrus SASL library.
cyrus-sasl-md5 1.5.24 CRAM-MD5 and DIGEST-MD5 support for Cyrus SASL.
cyrus-sasl-plain 1.5.24 PLAIN and LOGIN support for Cyrus SASL.
db1 1.85 The BSD database library for C (version 1).
db2 2.4.14 The BSD database library for C (version 2).
db3 3.2.9 The Berkeley DB database library (version 3) for C.
dev 3.2 The most commonly-used entries in the /dev directory.
diffutils 2.7.2 A GNU collection of diff utilities.
dosfstools 2.7 Utilities for making and checking MS-DOS FAT filesystems on Linux.
e2fsprogs 1.23 Utilities for managing the second extended (ext2) filesystem.
Eel 1.0.1 Eazel Extensions Library.
efax 0.9 A program for faxing using a Class 1, 2 or 2.0 fax modem.
eject 2.0.9 A program that ejects removable media using software control.
emacs 20.7 The libraries needed to run the GNU Emacs text editor.
emacs-X11 20.7 The Emacs text editor for the X Window System.
emacs-nox 20.7 The Emacs text editor without support for the X Window System.
esound 0.2.22 Allows several audio streams to play on a single audio device.
expat 1.95.1 A library for parsing XML.
Fam 2.6.4 FAM, the File Alteration Monitor.
File 3.35 A utility for determining file types.
filesystem 2.1.6 The basic directory layout for a Linux system.
fileutils 4.1 The GNU versions of common file management utilities.
findutils 4.1.7 The GNU versions of find utilities (find and xargs).
firewall-config 0.95 A configuration tool for IP firewalls and masquerading.
foomatic 1.1 Foomatic printer database.
fortune-mod 1.0 A program which will display a fortune.
freetype 2.0.3 A free and portable TrueType font rendering engine.
ftp 0.17 The standard UNIX FTP (File Transfer Protocol) client.
gawk 3.1.0 The GNU version of the awk text processing utility.
gdbm 1.8.0 A GNU set of database routines which use extensible hashing.
gdk-pixbuf 0.11.0 An image loading library used with GNOME.
gdk-pixbuf-gnome 0.11.0 GnomeCanvas support for displaying images.
gdm 2.2.3.1 The GNOME Display Manager.
gedit 0.9.4 A text editor for GNOME.
ghostscript 6.51 A PostScript(TM) interpreter and renderer.
ghostscript-fonts 5.50 Fonts for the Ghostscript PostScript(TM) interpreter.
glib 1.2.10 A library of functions used by GDK, GTK+ and many applications.
32
glibc 2.2.4 The GNU libc libraries.
glibc-common 2.2.4 Common binaries and locale data for glibc.
gmp 3.1.1 A GNU arbitrary precision library.
gnome-core 1.4.0.4 The core programs for the GNOME GUI desktop environment.
gnome-libs 1.2.13 The main GNOME libraries.
gnome-linuxconf 0.67.1 The GNOME front-end for linuxconf.
gnome-print 0.29 Printing libraries for GNOME.
gnome-vfs 1.0.1 The GNOME virtual file-system libraries.
gnupg 1.0.6 A GNU utility for secure communication and data storage.
gpm 1.19.3 A mouse server for the Linux console.
gq 0.4.0 A GUI LDAP directory browser and editor.
grep 2.4.2 The GNU versions of grep pattern matching utilities.
groff 1.17.2 A document formatting system.
grub 0.90 GRUB - the Grand Unified Boot Loader.
gtk+ 1.2.10 The GIMP ToolKit (GTK+), a library for creating GUIs for X.
gzip 1.3 The GNU data compression program.
hdparm 4.1 A utility for displaying and/or setting hard disk parameters.
hexedit 1.2.1 A hexadecimal file viewer and editor.
hotplug 2001_04_24 A helper application which loads modules for USB devices.
htmlview 1.2.0 A script which calls an installed HTML viewer.
hwbrowser 0.3.5 A hardware browser.
im 140 Perl scripts to replace MH, for use with the Mew mail reader.
indexhtml 7.2 The web page you'll see after installing Red Hat Linux.
info 4.0b A stand-alone TTY-based reader for GNU texinfo documentation.
initscripts 6.40 The inittab file and the /etc/init.d scripts.
ipchains 1.3.10 Tools for managing Linux kernel packet filtering capabilities.
iproute 2.2.4 Advanced IP routing and network device configuration tools.
iptables 1.2.3 Tools for managing Linux kernel packet filtering capabilities.
iptables-ipv6 1.2.3 IPv6 support for iptables.
iptraf 2.4.0 A console-based network monitoring utility.
iputils 20001110 Network monitoring tools including ping.
junkbuster 2.0.2 An ad-blocking application for Web browsers.
kbdconfig 1.9.14 A text-based interface for setting and loading a keyboard map.
kde-i18n-Italian 2.2 Italian language support for KDE.
kdeaddons-kate 2.2 Plugins for the Kate text editor
kdeaddons-kicker 2.2 Plugins and additional applets for Kicker (the KDE panel)
kdeaddons-konqueror 2.2 Plugins extending the functionality of Konqueror
kdeadmin 2.2 Administrative tools for KDE.
kdebase 2.2 Basic files needed for KDE.
kdelibs 2.2 Various libraries for KDE.
kdelibs-sound 2.2 KDE libraries needed to support sound.
kdemultimedia 2.2 Multimedia applications for the K Desktop Environment (KDE).
kdemultimedia-devel 2.2 Development files for kdemultimedia.
kdenetwork 2.2 Networking applications for KDE.
kdenetwork-ppp 2.2 PPP configuration utilities for KDE.
kdepim 2.2 Personal information management tools for KDE.
33
kdepim-cellphone 2.2 KDE support for synchronizing data with cellphones.
kdepim-devel 2.2 Development files for kdepim.
kdepim-pilot 2.2 KDE support for synchronizing data with a Palm(tm) or compatible PDA.
kdesdk 2.2 KDE SDK
kdesdk-devel 2.2 Development files for kdesdk
kdeutils 2.2 KDE utilities.
kdoc 2.2 Documentation for the K Desktop Environment (KDE) 2.0.
kernel 2.4.7 The Linux kernel (the core of the Linux operating system).
krb5-libs 1.2.2 The shared libraries used by Kerberos 5.
ksconfig 1.9.8 A graphical interface for making kickstart files.
ksymoops 2.4.1 The kernel oops and error message decoder.
kudzu 0.99.23 The Red Hat Linux hardware probing tool.
less 358 A text file browser similar to more, but better.
libcap 1.10 Library for getting and setting POSIX.1e capabilities
libglade 0.16 The libglade library for loading user interfaces.
libgnomeprint15 0.29 Printing libraries for GNOME.
libjpeg 6b A library for manipulating JPEG image format files.
libmng 1.0.2 A library which supports MNG graphics.
libpcap 0.6.2 A system-independent interface for user-level packet capture.
libpng 1.0.12 A library of functions for manipulating PNG image format files.
librep 0.13.6 A shared library that implements a Lisp dialect.
librsvg 1.0.0 An SVG library based on libart.
libstdc++ 2.96 The GNU Standard C++ Library v3.
libtermcap 2.0.8 A basic system library for accessing the termcap database.
libtiff 3.5.5 A library of functions for manipulating TIFF format image files.
libtool 1.4 The GNU libtool, which simplifies the use of shared libraries.
libtool-libs 1.4 Runtime libraries for GNU libtool.
libungif 4.1.0 A library for manipulating GIF format image files.
libuser 0.32 A user account administration library.
libvorbis 1.0rc2 The Vorbis General Audio Compression Codec.
libxml 1.8.14 An XML library.
libxml2 2.4.2 Library providing XML and HTML support.
libxslt 1.0.1 Library providing the Gnome XSLT engine
links 0.96 A text-mode web browser.
linuxconf 1.25r7 A system configuration tool.
lm_sensors 2.5.5 Hardware monitoring tools.
locale_config 0.3.2 A tool for configuring your system's locale.
lockdev 1.0.0 A library for locking devices.
logrotate 3.5.9 Rotates, compresses, removes and mails system log files.
logwatch 2.1.1 A log file analysis program.
lokkit 0.50 Firewall configuration application for an average end user.
losetup 2.11g Programs for setting up and configuring loopback devices.
m4 1.4.1 The GNU macro processor.
mailcap 2.1.6 Associates helper applications with particular file types.
make 3.79.1 A GNU tool which simplifies the build process for users.
man 1.5i2 A set of documentation tools: man, apropos and whatis.
34
man-pages 1.39 Man (manual) pages from the Linux Documentation Project.
man-pages-it 0.3.0 Italian man pages from the Linux Documentation Project.
mgetty 1.1.26 A getty replacement for use with data and fax modems.
minicom 1.83.1 A text-based modem control and terminal emulation program.
mkbootdisk 1.4.2 Creates an initial ramdisk image for preloading modules.
mkinitrd 3.2.6 Creates an initial ramdisk image for preloading modules.
mktemp 1.5 A small utility for safely making /tmp files.
mm 1.1.3 A shared memory library.
mod_dav 1.0.2 A DAV module for Apache.
mod_perl 1.24_01 An embedded Perl interpreter for the Apache web server.
mod_ssl 2.8.4 Cryptography support for the Apache web server.
modutils 2.4.6 Kernel module management utilities.
mount 2.11g Programs for mounting and unmounting filesystems.
mouseconfig 4.23 The Red Hat Linux mouse configuration tool.
mozilla 0.9.2.1 A web browser.
mtools 3.9.8 Programs for accessing MS-DOS disks without mounting the disks.
nautilus 1.0.4 Nautilus is a network user environment
nautilus-mozilla 1.0.4 Nautilus component for use with Mozilla
ncompress 4.2.4 Fast compression and decompression utilities.
ncurses 5.2 A CRT screen handling and optimization package.
net-tools 1.60 Basic networking tools.
netconfig 0.8.11 A text-based tool for simple configuration of ethernet devices.
netpbm-progs 9.14 Tools for manipulating graphics files in netpbm supported formats.
netscape-common 4.78 Files shared by Netscape Navigator and Communicator.
netscape-communicator 4.78 The Netscape Communicator suite of tools.
netscape-navigator 4.78 The Netscape Navigator web browser.
newt 0.50.33 A development library for text mode user interfaces.
nfs-utils 0.3.1 NFS utilities and supporting daemons for the kernel NFS server.
nmap 2.54BETA22 A utility for port scanning large networks (or single hosts).
nmap-frontend 2.54BETA22 A GUI front end for the nmap port scanner.
nscd 2.2.4 A Name Service Caching Daemon (nscd).
nss_ldap 172 NSS library and PAM module for LDAP.
ntp 4.1.0 Synchronizes system time using the Network Time Protocol (NTP).
ntsysv 1.2.24 A tool to set the stop/start of system services in a runlevel.
nvi-m17n-nocanna 1.79 The nvi multiligualized text editor without support for Canna.
oaf 0.6.5 Object activation framework for GNOME.
openjade 1.3 A DSSSL implementation.
openldap 2.0.11 The configuration files, libraries and documentation for OpenLDAP.
openldap-clients 2.0.11 Client programs for OpenLDAP.
openldap-servers 2.0.11 OpenLDAP servers and related files.
openldap12 1.2.12 Shared libraries for OpenLDAP 1.2 applications.
openssh 2.9p2 The OpenSSH implementation of SSH.
openssh-askpass 2.9p2 A passphrase dialog for OpenSSH and X.
openssh-clients 2.9p2 OpenSSH clients.
openssh-server 2.9p2 The OpenSSH server daemon.
openssl 0.9.6b The OpenSSL toolkit.
35
openssl-perl 0.9.6b Perl scripts provided with OpenSSL.
pam 0.75 A security tool which provides authentication for applications.
pam_smb 1.1.6 A Pluggable Authentication Module (PAM) for use with SMB servers.
parted 1.4.16 The GNU disk partition manipulation program.
passwd 0.64.1 The passwd utility for setting/changing passwords using PAM.
patch 2.5.4 The GNU patch command, for modifying/upgrading files.
pciutils 2.1.8 PCI bus related utilities.
pciutils-devel 2.1.8 Linux PCI development library.
pcre 3.4 Perl-compatible regular expression library
perl 5.6.0 The Perl programming language.
perl-DateManip 5.39 DateManip module for perl
perl-Digest-MD5 2.13 A perl interface to the MD5 digest algorithm.
perl-HTML-Parser 3.25 HTML-Parser module for perl (World_Wide_Web_HTML_HTTP_CGI/HTML)
perl-HTML-Tagset 3.03 This module contains data tables useful in dealing with HTML.
perl-MIME-Base64 2.12 Perl module for MIME encoding/decoding (base64 and quoted-printable)
perl-Parse-Yapp 1.04 Parse-Yapp module for perl
perl-SGMLSpm 1.03ii A Perl library for parsing the output of nsgmls.
perl-Storable 0.6.11 Storable module for perl
perl-URI 1.12 URI module for perl (World_Wide_Web_HTML_HTTP_CGI/URI)
perl-XML-Dumper 0.4 Perl module for dumping Perl objects from/to XML
perl-XML-Encoding 1.01 XML-Encoding module for perl
perl-XML-Grove 0.46alpha XML-Grove module for perl
perl-XML-Parser 2.30 A perl module for parsing XML documents
perl-XML-Twig 2.02 XML-Twig module for perl
perl-libnet 1.0703 The libnet module for perl (../authors/id/GBARR)
perl-libwww-perl 5.53 Libwww-perl module for perl
perl-libxml-enno 1.02 libxml-enno module for perl
perl-libxml-perl 0.07 libxml-perl module for perl
php 4.0.6 The PHP HTML-embedded scripting language.
pidentd 3.0.14 An implementation of the RFC1413 identification server.
pinfo 0.6.1 An info file viewer.
pmake 1.45 The BSD 4.4 version of make.
pnm2ppa 1.04 Drivers for printing to HP PPA printers.
popt 1.6.3 A C library for parsing command line parameters.
portmap 4.0 A program which manages RPC connections.
ppp 2.4.1 The PPP (Point-to-Point Protocol) daemon.
printconf 0.3.44 A printer configuration backend/frontend combination.
printconf-gui 0.3.44 A GUI frontend for printconf.
procps 2.0.7 System and process monitoring utilities.
psmisc 20.1 Utilities for managing processes on your system.
pwdb 0.61.1 The password database library.
pygnome 1.4.1 Python bindings for the GNOME libraries.
pygnome-libglade 1.4.1 GNOME support for the libglade Python wrapper.
pygtk 0.6.8 Python bindings for the GTK+ widget set.
pygtk-libglade 0.6.8 A wrapper for the libglade library for use with PyGTK.
python 1.5.2 An interpreted, interactive object-oriented programming language.
36
python-xmlrpc 1.5.0 A set of Python modules for XML-RPC support.
qt 2.3.1 The shared library for the Qt GUI toolkit.
quota 3.01pre9 System administration tools for monitoring users' disk usage.
rarpd ss981107 The RARP daemon.
rcs 5.7 Revision Control System (RCS) file version management tools.
rdate 1.0 Tool for getting the date/time from a remote machine.
rdist 6.1.5 Maintains identical copies of files on multiple machines.
redhat-config-network 0.9 The Network Adminstration Tool for Red Hat Linux.
redhat-config-users 0.9.2 A graphical interface for administering users and groups.
redhat-logos 1.1.3 Red Hat-related icons and pictures.
redhat-release 7.2 The Red Hat Linux release file.
reiserfs-utils 3.x.0j Tools for creating, repairing and debugging ReiserFS filesystems.
rep-gtk 0.15 GTK+ bindings for librep Lisp environment.
rep-gtk-gnome 0.15 GNOME bindings for the librep Lisp interpreter.
rhn_register 2.7.2 The Red Hat Network Services registration program.
rootfiles 7.2 The basic required files for the root user's directory.
routed 0.17 The routing daemon which maintains routing tables.
rpm 4.0.3 The Red Hat package management system.
rpm-build 4.0.3 Scripts and executable programs used to build packages.
rpm-perl 4.0.3 Native bindings to the RPM API for Perl.
rpm-python 4.0.3 Python bindings for apps which will manipulate RPM packages.
rsh 0.17 Clients for remote access (rsh, rlogin, rcp).
rsh-server 0.17 Servers for remote access (rsh, rlogin, rcp).
rsync 2.4.6 A program for synchronizing files over a network.
rusers 0.17 Displays the users logged into machines on the local network.
rusers-server 0.17 Server for the rusers protocol.
rwall 0.17 Client for sending messages to a host's logged in users.
rwall-server 0.17 Server for sending messages to a host's logged in users.
rwho 0.17 Displays who is logged in to local network machines.
samba 2.2.1a The Samba SMB server.
samba-client 2.2.1a Samba (SMB) client programs.
samba-common 2.2.1a Files used by both Samba servers and clients.
samba-swat 2.2.1a The Samba SMB server configuration program.
sawfish 0.38 An extensible window manager for the X Window System.
screen 3.9.9 A screen manager that supports multiple logins on one terminal.
scrollkeeper 0.2 ScrollKeeper is a cataloging system for documentation on open systems.
sed 3.02 A GNU stream text editor.
serviceconf 0.6.6 Serviceconf is an initscript and xinetd configuration utility.
setup 2.5.7 A set of system configuration and setup files.
setuptool 1.8 A text mode system configuration tool.
sgml-common 0.5 Common SGML catalog and DTD files.
sh-utils 2.0.11 A set of GNU utilities commonly used in shell scripts.
shadow-utils 20000902 Utilities for managing accounts and shadow password files.
shapecfg 2.2.12 A configuration tool for setting traffic bandwidth parameters.
sharutils 4.2.1 The GNU shar utilities for managing shell archives.
slang 1.4.4 The shared library for the S-Lang extension language.
37
squid 2.4.STABLE1 The Squid proxy caching server.
stat 2.5 A tool for finding out information about a specified file.
sudo 1.6.3p7 Allows restricted root access for specified users.
switchdesk 3.9.7 A desktop environment switcher.
switchdesk-kde 3.9.7 A KDE interface for the Desktop Switcher.
symlinks 1.2 A utility which maintains a system's symbolic links.
sysctlconfig 0.14 A configuration tool for operating system tunable parameters.
sysklogd 1.4.1 System logging and kernel message trapping daemons.
syslinux 1.52 A simple kernel loader which boots from a FAT filesystem.
sysreport 1.2 Gathers system hardware and configuration information.
sysstat 4.0.1 The sar and iostat system monitoring commands.
talk 0.17 Talk client for one-on-one Internet chatting.
talk-server 0.17 The talk server for one-on-one Internet chatting.
tar 1.13.19 A GNU file archiving program.
tcp_wrappers 7.6 A security tool which acts as a wrapper for TCP daemons.
tcpdump 3.6.2 A network traffic monitoring tool.
tcsh 6.10 An enhanced version of csh, the C shell.
telnet 0.17 The client program for the telnet remote login protocol.
telnet-server 0.17 The server program for the telnet remote login protocol.
termcap 11.0.1 The terminal feature database used by certain applications.
textutils 2.0.14 A set of GNU text file modifying utilities.
time 1.7 A GNU utility for monitoring a program's use of system resources.
timeconfig 3.2.2 Text mode tools for setting system time parameters.
tmpwatch 2.8 A utility for removing files based on when they were last accessed.
traceroute 1.4a12 Traces the route taken by packets over a TCP/IP network.
tree 1.2 A utility which displays a tree view of the contents of directories.
ttfonts 1.0 A set of TrueType fonts.
ttfonts-ja 1.0 Free Japanese TrueType fonts
unzip 5.42 A utility for unpacking zip files.
up2date 2.7.2 Determines which system packages need to be updated via RHN.
urw-fonts 2.0 Free versions of the 35 standard PostScript fonts.
usbview 1.0 A USB topology and device viewer.
usermode 1.43 Graphical tools for certain user account management tasks.
utempter 0.5.2 A privileged helper for utmp/wtmp updates.
util-linux 2.11f A collection of basic system utilities.
vim-X11 5.8 The VIM version of the vi editor for the X Window System.
vim-common 5.8 The common files needed by any version of the VIM editor.
vim-enhanced 5.8 A version of the VIM editor which includes recent enhancements.
vim-minimal 5.8 A minimal version of the VIM editor.
vixie-cron 3.0.1 The Vixie cron daemon for executing specified programs at set times.
vlock 1.3 A program which locks one or more virtual consoles.
vnc 3.3.3r2 A remote display system.
vnc-doc 3.3.3r2 Complete documentation for VNC.
vnc-server 3.3.3r2 A VNC server.
webalizer 2.01_06 A flexible Web server log file analysis program.
which 2.12 Displays where a particular program in your path is located.
38
whois 1.0.9 An Internet whois client.
words 2 A dictionary of English words for the /usr/dict directory.
xinetd 2.3.3 A secure replacement for inetd.
xinitrc 3.20 The default startup script for the X Window System.
xloadimage 4.1 An X Window System based image viewer.
xpdf 0.92 A PDF file viewer for the X Window System
xscreensaver 3.33 A set of X Window System screensavers.
yp-tools 2.5 NIS (or YP) client programs.
Ypbind 1.8 The NIS daemon which binds NIS clients to an NIS domain.
Ypserv 1.3.12 The NIS (Network Information Service) server.
Zip 2.3 A file compression and packaging utility compatible with PKZIP.
Zlib 1.1.3 The zlib compression and decompression library.
Dipendenze non risolte:
Installa i pacchetti per soddisfare le dipendenze
39
Configurazione interfaccia grafica (X)
Intel 740 (Generic)
8 MB
Installazione dei pacchetti
40
Creazione del dischetto d’avvio
Crea dischetto d’avvio
Configurazione del monitor
Unprobed monitor
Sync orizzontale: 31.5 – 48.5
41
Sync verticale: 50 – 70
Configurazione personalizzata di X
Profondità di colore: High Color (16 bit)
Screen resolution: 1024 x 768
Login type: Graphical
42
1.7. Configurazione del sistema
Una volta effettuato il login come root, si hanno tutti i privilegi necessari per effettuare le modifiche
alla configurazione. E’ consigliabile utilizzare l’account root solo per effettuare l’amministrazione
del sistema. Creare un account non-root per un uso generale e diventare su (superuser) per
apportare veloci modifiche. Queste regole base limitano le possibilità di digitare un comando
incorretto che potrebbe danneggiare il sistema.
Uno dei maggiori vantaggi di possedere Red Hat Linux è nei numerosi strumenti (sia grafici che
testuali), inseriti nel pacchetto di distribuzione per facilitare la gestione del sistema. Questi vanno a
scrivere su diversi file di configurazione (di solito ***.conf) i quali sono editabili da qualsiasi text
editor. Un utente esperto si troverà più a suo agio modificando i file manualmente, poiché vedrà
direttamente i cambiamenti apportati. Di seguito riportiamo l’elenco dei tool che riteniamo
particolarmente utili:
linuxconf
Può essere richiamato dalla riga comandi in una finestra terminale, mentre si esegue X, da
una riga comandi dello schermo console, oppure attraverso il browser web che si preferisce.
I motivi per cui si può usare linuxconf sono:
fornisce una comoda interfaccia grafica per l’amministrazione del sistema;
consente di salvare configurazioni di sistema diverse, che permettono di avviare il
proprio computer come macchina desktop o server Internet con un semplice comando
dalla riga comandi;
effettua la manutenzione e sostituisce utility d’utente, di file e di rete; il programma è
usato come strumento di configurazione e d’attivazione di servizi;
ha la capacità di usare moduli per aggiungere nuove funzioni;
consente di fare la manutenzione in rete, ne deriva una più efficiente gestione locale o
remota del computer e della rete.
linuxconf si trova nella directory /bin. Quando il programma viene usato senza le
librerie GNOME (gnome-linuxconf) o dalla console, risponde ai comandi da tastiera come
uno strumento d’installazione di Linux di Red Hat. Occorre spostarsi mediante un tasto Tab
e usare Invio per confermare la scelta quando il cursore è sull’argomento che interessa. Può
essere usato non solo interattivamente, ma anche dalla riga comandi. Il comando
linuxconf aiuta anche ad avviare e terminare servizi sotto Linux mentre il sistema è in
43
esecuzione. linuxconf può essere configurato anche tramite browser Web attraverso la
porta 98. Per prima cosa è necessario avviare il servizio linuxconfweb attraverso il tool
serviceconf. Da linuxconf bisogna abilitare l’accesso alla rete che è disabilitato per
default. E’ anche necessario specificare i computer o le reti che possono accedervi. Infine
basta far puntare il browser all’indirizzo http://tuo_calcolatore:98. A questo
punto viene visualizzata una pagina Web dalla quale è possibile apportare le modifiche al
sistema; comunque è necessaria la password.
dnsconf
Utilità per la configurazione del server DNS.
fsconf
Utilità che manipola la tabella di filesystem /etc/fstab.
netconf
Utilità di configurazione dei servizi TCP/IP.
netconfig
Uguale alla precedente ma in modalità testo.
userconf
Configurazione d’utenti e gruppi (per aggiungere e togliere utenti e gruppi).
serviceconf
Applicazione grafica sviluppata da Red Hat per configurare i servizi che devono partire
durante il boot, o far partire o arrestare i servizi.
44
swat
Utilità grafica che è stata aggiunta alla suite di software Samba per assistere gli
amministratori nella configurazione del file smb.conf.
apacheconf
Utilità grafica per la configurazione del Web server. Vengono modificati i file:
httpd.conf
Contiene informazioni di configurazione per il daemon del Web server (httpd), tra
cui i numeri di porta o gli indirizzi su cui stare in ascolto, quali permessi sono
necessari per l’esecuzione del daemon, il numero dei daemon e informazioni in
merito agli host virtuali.
access.conf
Contiene informazioni d’accesso su base per-directory; qui si trovano le definizioni
di ciò che è consentito con esattezza su ciascuna directory.
srm.conf
Questo file contiene direttive che definiscono le directory e i file utilizzati dal Web
server, oltre a definire risorse che determinano la gestione delle richieste da parte dei
browser Web.
xf86cfg
45
Utilità grafica per configurare le periferiche quali monitor, scheda grafica, mouse, tastiera. Il
programma va a modificare il file di testo chiamato /etc/X11/XF86config che
contiene tutte le informazioni di configurazione per X.
xf86config
Come la precedente ma in modalità testo.
Xconfigurator
Come la precedente ma in modalità testo all’interno della shell.
1.8. Creare un account utente
Ci sono due metodi per creare o aggiungere nuovi utenti: attraverso la GUI, usando il tool di
configurazione User Manager, o attraverso il prompt della shell. Per creare un nuovo account è
necessario conoscere la password di root oppure aver effettuato il log in come tale. Per creare un
account dalla shell:
Aprire un terminale ed effettuare log in come root.
Scrivere useradd seguito da uno spazio e il nome del nuovo utente. Premere [Enter].
Scrivere passwd seguito da uno spazio e dal nome utente.
La shell chiederà la password per il nuovo utente. Immetterne una e premere [Enter].
Verrà chiesto di digitare nuovamente la password per conferma. La creazione del nuovo
utente verrà confermata dal messaggio:
passwd: all authentication tokens updated successfully
Gli account degli utenti si trovano sul server Microsoft. Ogni utente ha la possibilità di accedere, da
qualsiasi client e/o server collegato in rete, alle risorse del server Linux che sono state rese
pubbliche. Se l’account dell’utente è presente anche sul server Linux sarà possibile vedere la
propria cartella oltre alle risorse pubbliche. E’ inoltre possibile effettuare il log in direttamente sulla
macchina Linux. Dato l’elevato numero d’utenti in azienda, abbiamo preferito creare delle risorse
condivise visibili a tutti, evitando così di ricopiare tutti gli utenti sul server Linux. Inoltre abbiamo
preferito che solo l’amministratore potesse entrare direttamente sulla macchina Linux in quanto
server. Per poter inserire il nostro server nella nostra rete Microsoft abbiamo utilizzato il protocollo
Samba, uno dei progetti Open Source maggiormente riusciti.
46
2. Alcuni segreti dei tool di Linux
Spiegare in poche parole quali siano le differenze che esistono tra Windows e Linux non è un
compito semplice. Guardando il tutto dal punto di vista dell’utente medio, le due piattaforme non
sono troppo distanti: ormai esistono applicazioni simili per le due famiglie di sistemi e, come se non
bastasse, le principali interfacce grafiche per Linux prendono più di una semplice ispirazione dalla
struttura del desktop di Windows. Un aspetto differenzia però ancora i due sistemi operativi
(sempre parlando dal punto di vista dell’utente): la riga di comando. Nel mondo Windows ormai si
tende ad utilizzare soltanto applicazioni a finestra, spesso anche per amministrare il sistema, mentre
nel mondo Linux ancora oggi è quasi impossibile prescindere dagli strumenti a caratteri.
2.1. La shell
La shell è l’interprete dei comandi, il componente del sistema che legge ciò che l’utente scrive nella
finestra di terminale e lancia di conseguenza applicazioni e altri strumenti. Linux prevede diversi
tipi di shell, ciascuna con le sue peculiarità: solo per citare i nomi delle più note si può ad esempio
parlare di bash (Bourne-Again Shell, usata per default in molte distribuzioni), tcsh (TC Shell), ksh
(Korn Shell). Le differenze tra le diverse shell sono rilevanti soltanto per determinati compiti, come
l’impostazione delle variabili di sistema o l’automazione dei comandi attraverso script eseguibili.
> Completamento automatico della digitazione
Il completamento automatico permette di scrivere i comandi in modo molto più rapido di quanto
permetta la semplice digitazione. Per utilizzarla basta premere il tasto Tab sulla riga di comando: in
questo modo la shell cerca di completare la parola alla sinistra del cursore al meglio delle sue
capacità.
Il completamento funziona sia sui nomi di file sia su quelli dei comandi, a seconda della posizione
in cui si trova il cursore nel momento in cui si preme Tab.
> Ripetizione dei comandi digitati
La cronologia dei comandi è l’elenco sequenziale dei comandi digitati nella sessione corrente della
shell o in quelle precedenti. I comandi contenuti in quest’elenco cronologico sono definiti eventi. La
cronologia dei comandi è memorizzata in un file di testo all’interno della directory home chiamato
.bash_history; questo file può essere visualizzato o modificato, proprio come un qualsiasi file di
testo.
47
Due aspetti molto interessanti della cronologia dei comandi sono la possibilità di ripetere l’ultimo
comando digitato e la capacità di eseguire una ricerca incrementale a ritroso nella cronologia.
Per visualizzare la cronologia dei comandi si utilizza lo strumento history.
[root@linux01 root]# history
1who
2apropos shell>shell-commands
3apropos bash>bash-commands
4history
Questo comando mostra il contenuto del file con la cronologia dei comandi, visualizzando un
comando per riga preceduto dal relativo numero d’evento. Si può specificare un vecchio evento
dalla cronologia sulla riga di comando per eseguirlo nuovamente: il metodo più semplice consiste
nell’utilizzare i tasti freccia rivolti verso l’alto e verso il basso al prompt della shell. Per eseguire un
evento della cronologia utilizzando il numero d’evento corrispondente, basta digitare un punto
esclamativo seguito dal numero d’evento:
[root@linux01 root]# !15
E’ possibile utilizzare con la combinazione di tasti Ctrl+R la funzione di ricerca incrementale
offerta da bash, per eseguire una ricerca a ritroso nella cronologia dei comandi. Questa funzione è
utile se si ricorda di aver digitato una riga di comando contenente una determinata parola e si
desidera ripetere il comando senza doverlo ridigitare da capo. Per questo basta digitare Ctrl+R
seguito dal testo desiderato, per vedere visualizzato al prompt l’ultimo comando digitato
corrispondente al criterio dato.
> Ridirigere l’input e l’output
La shell sposta il testo in stream specificati. Lo standard output è il luogo in cui la shell invia
l’output in formato testo dei comandi e, per impostazione predefinita è costituito dallo schermo del
terminale. Lo standard input è tipicamente la tastiera. Se durante l’esecuzione di un comando viene
riscontrato un errore, il messaggio d’errore è solitamente inviato allo schermo sotto forma di flusso
separato chiamato standard error.
Questi stream vengono ridiretti ad un file o anche ad un altro comando mediante la ridirezione.
Ridirigere l’input ad un file
Per ridirigere lo standard input ad un file si utilizza l’operatore “<”. L’operazione viene eseguita
facendo seguire il comando da “<” e dal nome del file da cui il comando deve prendere l’input.
Esempio:
[root@linux01 root]# apropos < keywords
48
Ridirigere l’input ad un file
Con l’operatore “>” si ridirige lo standard output ad un file. Per utilizzarlo bisogna far seguire un
comando da “>” e dal nome del file a cui inviare l’output. Esempio:
[root@linux01 root]# apropos shell bash > commands
Lo standard output ridiretto ad un file esistente sovrascrive il file; se invece dell’operatore “>” si
utilizza il “>>” l’output del comando non viene sostituito al vecchio contenuto del file ma
semplicemente aggiunto. Esempio:
[root@linux01 root]# apropos shells >> commands
Ridirigere i messaggi d’errore ad un file
Per ridirigere lo stream di standard error ad un file l’operatore da usare è “2>”. Esempio:
[root@linux01 root]# apropos shell bash 2> command.error
Come nel caso dello standard output, si può utilizzare l’operatore “2>>” per aggiungere lo standard
error al contenuto di un file esistente. Esempio:
[root@linux01 root]# apropos shell 2>> command.error
Ridirigere l’output all’input di un altro comando
Il piping si verifica quando si connette lo standard output di un comando allo standard input di un
altro comando. Quest’operazione viene eseguita specificando i due comandi in sequenza separati
dal carattere “|” (definito per l’appunto pipe). I comandi così costruiti prendono il nome di pipeline.
Per esempio, è spesso utili ridirigere in questo modo i comandi che visualizzano un output con
molto testo a less. Esempio:
[root@linux01 root]# apropos bash shell | less
Un esempio che mette assieme le tecniche viste finora, vale a dire l’analisi dell’history, della shell e
la ridirezione d’input ed output, permette di cercare all’interno di un lungo file di comandi digitati
solo le righe che contengono una determinata stringa di testo, utilizzando lo strumento grep. grep è
uno strumento che accetta in ingresso uno stream di testo e mostra soltanto le righe contenenti un
testo specificato. Esempio:
[root@linux01 root]# history | grep apropos
> La documentazione
I sistemi Linux dispongono di numerose funzioni di guida, tra cui completi manuali in formato
elettronico. Il problema della documentazione di Linux risiede paradossalmente nella sua
abbondanza, che spesso costringe gli utenti a passare al vaglio montagne di materiale nel tentativo
di trovare le informazioni desiderate.
49
Una delle risorse principali di documentazione dei comandi e degli strumenti è il manuale che si
richiama con il comando man. Per visualizzare la pagina di manuale relativa ad uno strumento
bisogna digitare al prompt:
[root@linux01 root]# man nome_strumento
E’ possibile spostarsi nel testo ed interrompere la visualizzazione premendo il tasto “Q”
Nonostante il nome, una pagina di manuale non sempre contiene la documentazione completa di un
programma, ma assomiglia più ad una guida rapida di consultazione. Di solito, offre una
descrizione breve del programma ed elenca le opzioni e gli argomenti che quest’accetta.
Il comando man può anche servire a visualizzare un elenco di tutti gli strumenti le cui pagine nel
manuale del sistema contengono un riferimento ad un determinato termine. Per questo bisogna
usare lo switch –k: Ad esempio per conoscere tutti gli strumenti che contengono nella loro pagina di
manuale il termine “console”:
[root@linux01 root]# man –k console
In alternativa è possibile verificare se all’interno dello strumento stesso è prevista una descrizione
sommaria delle funzioni disponibili. Per questo si può provare a lanciare lo strumento con l’opzione
--help, che fornisce informazioni sull’utilizzo dello strumento, incluse le opzioni e gli argomenti
accettati dallo strumento.
Altra fondamentale risorsa è la documentazione di sistema che si trova nella directory /usr/doc:
HowTo, Faq e file di documentazione forniti insieme ai comandi ed ai programmi specifici.
Il Linux Documentation Project (LDP, www.linuxdoc.org, con filiale italiana all’indirizzo
www.pluto.linux.it/ildp) ha visto la creazione di oltre 100 file “HowTo” e di numerose Faq,
ciascuno dei quali copre un aspetto particolare dell’installazione o dell’impiego dei sistemi basati
sul Linux. Gli HowTo e le Faq oggi sono disponibili in più lingue ed in vari formati, tra cui l’Html.
2.2. File e directory
File e directory sono rappresentati in modo gerarchico, ad albero: c’è una directory radice,
rappresentata dalla “/”, da cui partono tutte le altre directory e sottodirectory, alcune della quali
hanno una precisa importanza nell’ambito del sistema operativo. Ogni directory ha al suo interno
due file speciali identificati rispettivamente da uno e due punti. Come in Ms-Dos, questi file
indicano la directory corrente e quella immediatamente superiore.
I nomi dei file possono essere costituiti da lettere maiuscole e minuscole, numeri, punti, trattini e
sottolineature. I file system di Linux sono inoltre case sensitive, cioè viene fatta distinzione tra
caratteri maiuscoli e minuscoli. Linux non obbliga ad utilizzare le estensioni di file, che risultano
50
comunque comode per identificare immediatamente tipi di file e non hanno particolare limite di
lunghezza.
Le directory di Linux
/ La capostipite di tutte le directory presenti sul sistema
/bin Strumenti essenziali ed altri programmi di sistema
/dev File che rappresentano le varie periferiche del sistema
/etc File di configurazione e d’avvio del sistema
/home Le directory home degli utenti
/lib File delle librerie utilizzate dagli strumenti in /bin
/proc File che forniscono informazioni sui processi attivi
/root La directory home del superuser, il cui nome utente è root
/sbin Strumenti essenziali per l’amministratore del computer e programmi di sistema
/tmp File temporanei
/usr Sottodirectory con file relativi agli strumenti ed alle applicazioni utente
/usr/X11R6 File relativi al sistema X Window, compresi quei programmi (in /usr/X11R6/bin)
che vengono eseguiti unicamente in X
/usr/bin Strumenti ed applicazioni per gli utenti
/usr/dict Dizionari ed elenchi di parole (che vengono lentamente superati da /usr/share/dict)
/usr/doc Documentazione varia di sistema
/usr/games Giochi e passatempi
/usr/info File per il sistema ipertestuale GNU Info
/usr/lib Librerie utilizzate dagli strumenti /usr/bin
/usr/local File locali, ossia file esclusivi dei singoli sistemi, che includono la
documentazione (in /usr/local/doc) ed i programmi (in /usr/local/bin) locali
/usr/man I manuali in linea che vengono letti con il comando man
/usr/share Dati per applicazioni installate indipendenti dall’architettura e che possono essere
condivisi dai sistemi. Questa directory comprende inoltre svariate sottodirectory
con equivalenti in /usr, comprese /usr/share/doc, /usr/share/info e /usr/share/icons
/usr/src Codice sorgente dei programmi per il software installato sul sistema
/usr/tmp Un’altra directory per i file temporanei
/var File variabili di dati come code dello spooler e file di log
> Creare un file vuoto
Può essere talvolta necessario creare un file vuoto che funzioni da “segnaposto”. Per eseguire
quest’operazione, si fornisce come argomento a touch il nome desiderato per il file. Esempio:
[root@linux01 root]# touch prova.txt
Creare una directory
Per creare una nuova directory si utilizza mkdir, utilizzando come unico argomento il nome del
percorso della nuova directory. I nomi delle directory seguono le stesse convenzioni adottate per
altri file e di conseguenza è sconsigliato l’utilizzo di spazi, barre o altri caratteri insoliti. Esempio:
[root@linux01 root]# mkdir /tmp/work
51
Cambiare la directory corrente
Come in Dos, si utilizza il comando cd per cambiare la directory di lavoro corrente fornendo come
argomento il nome della nuova directory. Esempio:
[root@linux01 root]# cd work
Per tornare alla directory superiore:
[root@linux01 root]# cd..
Ottenere il nome della directory corrente
Per determinare qual è la directory di lavoro corrente si utilizza pwd, che ne visualizza il nome di
percorso completo.
Visualizzare il contenuto delle directory
ls è lo strumento che si usa per visualizzare ciò che c’è dentro una directory. Si può utilizzare senza
argomenti, in tal caso viene visualizzato l’intero contenuto della directory corrente, oppure si può
indicare il nome di una directory (per vederne il contenuto) o di un file, per sapere se tale file è
presente nella directory attuale. ls ha molte opzioni di visualizzazione, tutte elencata all’interno
della documentazione elettronica presente nel sistema operativo. I principali switch disponibili, da
indicare al prompt appena dopo il comando ls sono:
--color Attribuisce un colore ai nomi dei file a seconda del loro tipo
-R Produce una visualizzazione ricorsiva delle sottodirectory
-a Visualizza tutti i file in una directory, compresi i file nascosti, o “dot”
-s Mostra a video la dimensione di ciascun file in KByte
-l Visualizza le dimensioni e gli attributi dei file
Midnight Commander
Le operazioni sui file che abbiamo descritto e molte altre ancora possono essere svolte molto più
comodamente con uno strumento quasi sempre fornito a corredo del sistema operativo: Midnight
Commander.
Midnight Commander (che si richiama attraverso il comando mc) visualizza contemporaneamente
due directory e permette di compiere tra le altre cose operazioni di copia e spostamento dei file,
gestione delle cartelle.
2.3. Lavorare con i file
Linux è da sempre un sistema operativo multiutente. Il sistema utilizzato per proteggere la privacy
di ciascun utente è quello dei privilegi d’accesso, che consiste nello specificare per ogni file e
directory diversi permessi per ciascun utente o gruppo d’utenti. Ogni file dispone di permessi che
specificano il tipo d’accesso degli utenti. Esistono tre tipi di permessi: lettura, scrittura ed
esecuzione.
52
Di solito gli utenti dispongono di permessi di scrittura su file contenuti nelle loro directory home.
Solo l’utente root gode del permesso di scrittura sui file contenuti in directory importanti, come /bin
ed /etc, e i normali utenti non devono in linea di massima avere timore di modificare o cancellare
per errore un importante file di sistema.
I permessi funzionano in maniera diversa per le directory rispetto ai file. Se si dispone del permesso
di lettura ma non del permesso d’esecuzione su una directory, è possibile solo leggere i nomi dei
file contenuti in detta directory, ma non leggere altri attributi, esaminarne il contenuto, modificarli o
eseguirli. Con il permesso d’esecuzione, ma senza il permesso di lettura su una directory, si può
leggere, modificare o eseguire qualsiasi file contenuto nella directory a condizione di conoscerne il
nome e di godere dei permessi appropriati su detto file.
Ogni file dispone di permessi separati per tre categorie d’utenti: l’utente che possiede il file, il
gruppo a cui appartiene l’utente che possiede il file e il resto degli utenti presenti sul sistema.
Quando si crea un nuovo file, questo ha una serie di permessi predefinita: generalmente, di lettura e
scrittura per l’utente e di lettura per il gruppo e tutti gli altri utenti.
Visualizzare i permessi di un file
Per visualizzare i permessi d’accesso ad un file si utilizza ls con l’opzione “-l”. Esempio:
[root@linux01 root]# ls –l cruise
-rwxrwx-r-- 1 captain crew 8,420 Jan 12 21:42 cruise
Il primo carattere (“-“) è il tipo di file; gli altri tre caratteri specificano I permessi per l’utente che
possiede il file(“rwx”), gli altri tre (“rw-“) specificano I permessi per tutti I membri del gruppo che
possiede il file ad esclusione dell’utente che lo possiede. Gli ultimi tre caratteri della colonna (“r--)
specificano i permessi per gli utenti sul sistema. Tutte e tre le sezioni relative ai permessi hanno lo
stesso formato ed indicano da sinistra a destra il permesso di lettura, scrittura ed esecuzione. Un
trattino (“-“) al posto di una di queste lettere indica che il permesso non è accordato.
Modificare i permessi di un file
Per modificare la modalità d’accesso di qualsiasi file si utilizza lo strumento chmod. Questo
strumento si usa specificando prima quali siano i permessi da concedere o revocare per determinati
utenti, e quindi i nomi dei file su cui lavorare. In primo luogo vanno specificate le categorie d’utenti
da includere utilizzando una combinazione dei seguenti caratteri.
Carattere Categoria
u Utente che possiede il file
g Tutti gli altri membri del gruppo che possiede il
file
o Tutti gli altri utenti presenti sul sistema
a Tutti gli altri utenti sul sistema; equivale a “ugo”
Bisogna aggiungere l’operatore che indica l’azione da eseguire.
53
Operazione Azione
+ Aggiunge permessi ai permessi esistenti
dell’utente
- Rimuove permessi dai permessi esistenti
dell’utente
Infine specificare i permessi
Carattere Permesso
r Imposta il permesso di lettura
w Imposta il permesso di scrittura
x Imposta il permesso d’esecuzione
> Trovare i file
Una volta imparato a gestire file e cartelle è opportuno dare anche qualche indicazione su
com’effettuare ricerche all’interno del file system.
Oltre al comando ls, ci sono infatti altri strumenti per la ricerca dei file su disco.
Il metodo più semplice per trovare il file è lo strumento locate di GNU. Si utilizza locate per
visualizzare tutti i file sul sistema il cui nome del percorso completo corrisponde ad un particolare
modello. locate visualizza un elenco di tutti i file sul sistema che corrispondono al modello e
fornisce il loro percorso completo. Quando si specifica un modello, è possibile utilizzare anche i
caratteri jolly “?” (che indica un carattere qualsiasi) e “*” (che indica un qualunque gruppo di
caratteri).
Un comando più elaborato per la ricerca di file e directory è find. Allo strumento find bisogna prima
indicare la directory in cui iniziare a cercare i documenti, poi i criteri di ricerca, che vanno al di là
del semplice nome del file da trovare.
Opzioni del comando find
-name abc cerca tutti i file con il teso abc all’interno del nome, senza fare distinzione
tra lettere maiuscole e minuscole
-size 123k cerca tutti i file dalle dimensioni di 123KByte; se s’inserisce un segno “+” o
un segno “-“ prima del numero vengono individuati i file di dimensioni
maggiori o minori di quella specificata
-mmin 123 cerca tutti i file modificati da esattamente 123 minuti; se s’inserisce un
segno “+” o un segno “-“ prima del numero vengono individuati i file
modificati da un periodo di tempo superiore o inferiore di quello specificato
-mtime 123 cerca tutti i file modificati da esattamente 123 giorni; se s’inserisce un segno
“+” o un segno “-“ prima del numero vengono individuati i file modificati da
un periodo di tempo superiore o inferiore di quello specificato
-empty cerca tutti i file vuoti
-newer abc cerca solo i file modificati più recentemente rispetto al file abc
-user pippo cerca tutti i file appartenenti all’utente pippo
-group pluto cerca tutti i file appartenenti ai membri del gruppo pluto
-exec cmd esegue in modo automatico l’istruzione cmd sui file individuati
54
Altro strumento rilevante nella ricerca dei file è which, che serve ad individuare con certezza la
posizione di applicazioni e strumenti.
> Analisi del testo
Tra gli strumenti disponibili in ogni distribuzione Linux ci sono alcuni piccoli tool per l’analisi del
testo. Si tratta di strumenti dalle dimensioni ridottissime e dalle funzioni ben definite, di per sé non
particolarmente potenti ma in grado di fornire, se usati in combinazione, risultati eccellenti.
Leggere un testo
[root@linux01 root]# cat articolo.txt
Questa riga di comando fa in modo che ciò che è contenuto nel file articolo.txt venga mostrato sullo
schermo. Se il testo è troppo lungo per rientrare nel video del pc, cat non prevede la possibilità di
visualizzare il testo una schermata alla volta. Per questo è spesso necessario utilizzarlo in
congiunzione con il comando less, che permette all’utente di navigare all’interno dell’output di un
comando come cat, spostandosi in avanti e all’indietro con i tasti direzionali. Oppure andando
avanti di una schermata alla volta premendo la barra spaziatrice. Altri comandi utili possono essere
q (per uscire) e la ricerca di un pattern di testo che si effettua con il simbolo “/”. Ad esempio se si
vuol cercare la parola “computer” in un testo visualizzato con less bisogna digitare:
/computer.
Contare il testo
Per contare il numero di caratteri, parole o righe presenti in un testo, sotto Linux c’è lo strumento
wc. Per visualizzare il numero di righe, parole e caratteri nel file outline.txt, basta digitare:
[root@linux01 root]# wc outline
Utilizzando wc bisogna indicare come argomento il nome del file da analizzare, di cui vengono così
riportate in tre colonne separate i conteggi per le righe, le parole ed i caratteri presenti. Le principali
opzioni di wc sono:
-c specifica che deve essere contato e visualizzato solo il numero dei caratteri del file
-w specifica che deve essere contato e visualizzato solo il numero delle parole del file
-l specifica che deve essere contato e visualizzato solo il numero delle righe del file
Cercare una stringa di testo
Per cercare ad esempio la parola “pollo” nel file ricette.doc:
[root@linux01 root]# grep pollo ricette.doc
L’output del comando consiste nelle righe in cui il testo cercato viene individuato.
55
Ancor più di altri strumenti, grep dimostra la sua potenza se utilizzato in congiunzione con più
comandi: sfruttando il già citato meccanismo della ridirezione di input ed output si può sfruttare
grep in molte situazioni.
Modificare le password
Per modificare la propria password bisogna utilizzare lo strumento passwd. Questo chiede di
indicare la password corrente (per essere sicuro di trovarsi di fronte all’utente giusto) e quindi la
nuova password che s’intende usare. Per motivi di sicurezza, né la password vecchia né quella
nuova vengono visualizzate sullo schermo. Per garantire che la nuova password sia stata scritta
correttamente, passwd chiede di immettere la nuova password due volte. Se questa non viene
digitata nello stesso modo entrambe le volte, passwd non effettua il cambiamento. Esempio:
[root@linux01 root]# passwd
Changing password for kurt
Old password: [vecchia password]
Enter the new password (minimum of 5, maximum of 8 characters)
Please use a combination of upper and lower case letters and
numbers.
New password: [nuova password]
Re-enter new password: [ridigitare nuova password]
Password changed
Le password possono comprendere caratteri sia maiuscoli sia minuscoli, le cifre da 0 a 9 e simboli
di punteggiatura; inoltre dovrebbero avere una lunghezza compresa tra cinque ed otto caratteri.
2.4. Gestione dei dischi
In un sistema Linux sono previsti due tipi di memorizzazione su disco: fissa e rimovibile. La prima
fa riferimento ad un disco permanente collegato al sistema e non prevede alcuna rimozione casuale.
La seconda categoria di dispositivi di memorizzazione su disco è quella dei dischi rimovibili, di cui
cioè si prevede l’estrazione per l’archiviazione od il trasferimento in un altro sistema.
Nei sistemi Linux, i dischi vengono impiegati dopo essere stati montati in una directory, che rende
disponibili i contenuti dell’albero delle directory del disco in quel determinato mount point. Questo
vuol dire che tutti i dischi appartengono alla medesima struttura logica di directory, e non esiste il
concetto di unità così come invece accade nel mondo Dos/Windows. I dischi possono essere
montati in qualsiasi directory del sistema, ma qualsiasi divisione tra dischi è trasparente: così, un
sistema che possiede, oltre al disco del file di sistema principale montato in /, anche diversi dischi
rigidi separati per l’albero delle sottodirectory /home, /usr e /usr/local, agli occhi dell’utente questo
non risulterà differente dai sistemi che hanno un unico disco fisso.
Gli amministratori del sistema spesso montano lettori a capacità elevata su alberi delle directory che
siano in grado di contenere molti dati e, per motivi di sicurezza, spesso si servono di diversi dischi
56
rigidi in un unico sistema, in modo da ridurre la perdita di dati in caso di danneggiamento di un
singolo disco.
Visualizzare lo spazio disponibile su disco
Per visualizzare quanto spazio è ancora disponibile in un disco si utilizza lo strumento df. Senza
alcun’opzione, df elenca tutti i file di sistema montati disponibili. L’output è costituito da sei
colonne con le informazioni di ciascun disco: il nome del dispositivo nella directory /dev (che
contiene i riferimenti alle periferiche del pc sotto forma di file); il numero di blocchi da 1.024 byte
utilizzati dal sistema; il numero di blocchi attualmente impiegati; il numero di blocchi disponibili; la
percentuale del dispositivo utilizzata e, infine, il nome dell’albero della directory in cui è stato
montato il dispositivo.
[root@linux01 root]# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda1 195167 43405 141648 23% /
/dev/hda2 2783807 688916 1950949 26% /usr
/dev/hdb1 2039559 1675652 258472 87% /home/utente
Visualizzare lo spazio utilizzato dai file
du è uno strumento che serve ad elencare lo spazio su disco occupato dai file. Se si utilizza senza
specificare alcun nome di file o di directory, du analizza l’intera directory corrente, altrimenti si
occupa solo di ciò che l’utente ha specificato. Questo comando scrive una riga per ogni
sottodirectory dell’albero, con tanto di spazio utilizzato espresso in KByte; l’ultima riga mostra la
quantità di spazio totale impiegata dall’intero albero della directory.
[root@linux01 root]# du
8 ./projects/documentation
12 ./projects/source
4 ./projects/etc
24 ./projects
3 ./temp
27 .
Dischi floppy
Per leggere o salvare su un disco formattato è necessario montare il disco floppy in una directory
vuota, per rendere disponibile il file di sistema nella directory specificata. Solitamente i sistemi
Linux sono per questo dotati di un’apposita directory vuota chiamata /floppy (o /mnt/floppy).
Quando si monta un disco in una directory, questa apparentemente contiene tutti i file e le directory
del filesystem del disco; quando successivamente si smonta il disco, tale directory viene svuotata:
57
tutti i file e le directory del disco non vengono cancellati dal file system corrispondente, ma
quest’ultimo non risulta più accessibile.
Quando si termina di utilizzare un disco floppy, è necessario smontarlo prima di estrarlo dal lettore.
In caso contrario si rischia di danneggiare o eliminare alcuni dei file in esso contenuti, che
potrebbero essere stati messi “in attesa” e non ancora del tutto scritti fisicamente sul disco; il
sistema operativo potrebbe inoltre cercare di utilizzare i file montati anche dopo l’estrazione del
disco e provocare errori e malfunzionamenti ai programmi.
Cd-Rom
Come nel caso dei dischi floppy, prima di poter utilizzare un Cd di dati nel sistema, questo deve
prima essere montato in una directory vuota. Successivamente, prima di poterlo estrarre dal lettore
Cd-Rom, questo deve essere smontato. I Cd-Rom vengono in genere montati in una sottodirectory
di /mnt (/mnt/cdrom o /mnt/dvd), e se directory simili non esistono consigliamo di crearne una
appositamente, prestando attenzione a non chiamarla semplicemente /mnt/cd per evitare confusioni
con l’omonimo comando di cambio della directory corrente. La questione dello smontare i Cd-Rom
dopo l’uso è importante ma meno delicata di quanto sia con i floppy. Innanzi tutto perché, a meno
di non utilizzare un masterizzatore sotto Linux, in genere sui Cd si compiono solo operazioni di
lettura, quindi non si rischia la perdita di dati non ancora scritti. In secondo luogo, Linux esegue
solitamente il lock dei Cd-Rom per tutto il tempo in cui questi rimangono montati nel file system e
impedisce all’utente di estrarre il disco attraverso il pulsante d’espulsione.
> Un solo disco, più piattaforme
Molti utenti Linux sono anche utenti Windows. Questo perché Windows è almeno per il momento il
sistema operativo più utilizzato negli ambienti lavorativi italiani, e perché oggi come oggi non è
facile abbandonare del tutto la piattaforma Microsoft: buona parte degli utenti Linux tiene installati
i due sistemi operativi, e qualche volta si trova davanti alla necessità di scambiare tra questi
documenti e risorse.
Il pacchetto mtools, presente praticamente in tutte le distribuzioni, fornisce una raccolta di strumenti
utili per facilitare la gestione di file e dischi rimovibili normalmente utilizzati sotto Ms-Dos. I
mtools sono un’implementazione dei più comuni comandi Dos e Windows per la gestione di file, e
riconoscono le estensioni del formato Ms-Dos impiegate dai diversi sistemi operativi Microsoft.
L’uso di questi strumenti è in generale più semplice della procedura di montare e smontare i dischi.
I comandi di mtools sono tutti simili alle controparti Dos, con l’aggiunta della lettera “m” prima del
nome dei comandi.
Le principali funzioni fornite da mtools sono:
58
mdir
Visualizza file e directory presenti in un disco Dos. Vuole come parametro il disco a cui si vuole
fare riferimento. Esempio:
[root@linux01 root]# mdir a:
mcopy
copia i file su un disco Dos (o da quest’ultimo in una normale directory del file system). Per copiare
un file in un disco Dos, si assegnano come argomenti il nome del file sorgente da copiare e la lettera
del drive contenente il disco su cui effettuare la copia. Esempio:
[root@linux01 root]# mcopy readme.txt a:
Al contrario, per copiare un file da un disco Dos, bisogna scambiare gli argomenti ed eseguire, dalla
directory corrente, il comando:
[root@linux01 root]# mcopy b:resume.doc
Per copiare tutti i file da un disco Dos alla directory corrente, s’indica semplicemente la lettera del
drive senza alcun nome di file:
[root@linux01 root]# mcopy a:
mdel
elimina un file da un disco Dos. Esempio:
[root@linux01 root]# mdel a:resume.doc
mformat
formatta un dischetto in modo che sia riconosciuto sotto Ms-Dos. Viene creato, all’interno del
dischetto nel floppy principale, un filesystem compatibile con i sistemi operativi Microsoft, pronto
ad essere usato sia sotto Windows sia sotto Linux. Esempio:
[root@linux01 root]# mformat a:
> Usare i dischi rimovibili
Formattare un disco floppy
Si usa mke2fs, specificando il nome del dispositivo floppy da utilizzare. Solitamente, si tratta del
primo drive per dischi rimovibili, /dev/fd0. Qualsiasi dato sul floppy viene eliminato. Esempio:
[root@linux01 root]# mke2fs /dev/fd0
Montare un disco rimovibile
Si utilizza il comando mount specificando il nome del dispositivo da inserire nel file system di
Linux. Per montare un disco floppy:
[root@linux01 root]# mount /mnt/floppy
59
Per montare un Cd-Rom in una directory specificata (hdc indica la terza unità collegata al controller
eide):
[root@linux01 root]# mount /dev/hdc /home/utente/cdrom
Dopo aver montato un disco rimovibile, i suoi contenuti compaiono nella directory specificata e si
può utilizzare qualsiasi comando su di essi.
Smontare un disco floppy
Si utilizza umount aggiungendo il nome della directory in cui questo è montato. Esempio:
[root@linux01 root]# umount /mnt/floppy
Attenzione: non è possibile smontare un disco se la directory corrente, quella in cui si trova
attualmente la shell, è nell’albero della directory del disco stesso. In tal caso, quando si tenta di
smontare il disco, compare l’errore che indica che il file di sistema /mnt/floppy è attualmente in uso;
bisogna perciò passare ad una directory diversa e tentare nuovamente di smontare il disco. Talvolta,
quando si smonta un disco floppy, la luce sul lettore rimane accesa per alcuni secondi successivi
alla chiusura. Questo accade perché Linux mantiene talvolta in memoria le modifiche ai file, prima
di salvarle su disco; esso si assicura che i file contenuti nel disco floppy siano aggiornati. Bisogna
perciò attendere semplicemente che la luce si spenga, prima di estrarre il disco floppy dal lettore.
Consentire agli utenti di accedere alle periferiche hardware
Alcune periferiche hardware, come i lettori Cd-Rom e le schede audio, richiedono normalmente i
privilegi dell’utente root per accedervi. Questi dispositivi hanno solitamente dei gruppi propri, così
che un utente normale possa accedervi quale membro di tale gruppo.
I gruppi di cui possono far parte gli utenti normali includono ad esempio audio (la scheda audio) e
dialout (i modem dial-out).
L’utente root può usare addgroup per aggiungere un utente al gruppo associato ad un dispositivo
hardware, indicando come argomenti il nome utente da aggiungere ed il nome del gruppo di
destinazione. Esempio:
[root@linux01 root]# addgroup utente audio
Consentire agli utenti di montare i drive
Un caso particolare d’accesso all’hardware è la possibilità di montare nel file system di Linux
dischi rimovibili di varia natura. Il file /etc/fstab specifica i dettagli sul file system in uso sul
sistema, inclusi quelli che possono essere montati dai drive floppy o dai Cd-Rom. Al fine di
consentire agli utenti di montare dischi in questi drive, l’utente root deve assicurarsi che vi sia una
riga in /etc/fstab sia per il drive floppy che per il Cd-Rom, contenenti entrambe il flag “user”:
/dev/fd0 /floppy auto defaults,noauto,user 0 0
/dev/cdrom /cdrom auto defaults,noauto,user 0 0
60
2.5. L’elaborazione del testo
L’elaborazione di testo è una delle principali attività svolte quotidianamente sui pc. Linux mette a
disposizione dei suoi vari utenti validi strumenti per questo scopo, molti dei quali nascono per
essere utilizzati proprio in modalità a carattere. Tra gli editor abbiamo scelto Vi ed Emacs.
> Vi
E’ di gran lunga il più famoso editor di testo sotto Unix, e tutti gli utenti di un sistema operativo di
questa famiglia prima o poi si ritrovano a doverlo utilizzare. Vi è un editor a caratteri basato sulla
separazione tra la modalità editing e la modalità comandi: per passare dall’una all’altra si usa il
tasto Esc, e mentre in modalità inserimento si possono semplicemente aggiungere nuovi caratteri o
eliminare quelli già scritti, in modalità a comandi si ha davanti una lunga serie di possibilità. Molti
comandi sono composti da più di un carattere: ad esempio per salvare sul disco il file scritto si usa
“:w”, per chiudere il programma “:q” e per chiudere il programma tralasciando le modifiche
apportate al file dall’ultimo salvataggio “:q!”.
L’editor Vi comprende un tutorial pratico, che permette di prendere confidenza con gli strumenti di
lavoro e con le funzioni del pacchetto. Il tutorial è memorizzato sotto forma di file compresso nella
directory /usr/doc/nvi.
> Emacs
Definire Emacs un editor di testo significa non rendergli giustizia: Emacs è un applicazione ampia,
capace di eseguire molte funzioni, tra cui la lettura della posta elettronica e delle news Usenet, e la
navigazione sul World Wide Web. esistono più versioni di Emacs. Gnu Emacs è l’Emacs ha le
medesime funzioni offerte da Emacs , ma comprende anche funzioni proprie da utilizzarsi con il
sistema a finestre X.
Emacs si avvia nel modo consueto, selezionando dal menu fornito dal gestore di finestre in X
oppure digitandone il nome (in caratteri minuscoli) al prompt della shell. Per lanciare Gnu Emacs al
prompt della shell, basta digitare:
[root@linux01 root]# emacs
Un file o un altro testo aperto in Emacs viene conservato in un’area chiamata buffer. per
impostazione predefinita, il buffer corrente appare nell’area grande sotto la barra dei menu. Per
scrivere un testo nel buffer, basta digitarlo. Il luogo in cui si trova il cursore nel buffer è detto punto
d’inserzione e al punto fanno riferimento molti comandi Emacs. La barra orizzontale sotto la
finestra Emacs è direttamente sotto il buffer corrente si chiama linea di modo; fornisce informazioni
sul buffer corrente. La riga di modo elenca anche i modi attivi nel buffer. I modi Emacs sono stati
61
generali che ne controllano il comportamento; ad esempio quando viene impostato il modo
Overwrite, il testo digitato sovrascrive il testo in corrispondenza del punto; nel modo Insert, viene
invece inserito in corrispondenza del punto. Di solito, nell’elenco compaiono il modo Fundamental
o il modo Text. L’area echo è l’area in cui Emacs scrive brevi messaggi di stato, come i messaggi di
errore; si tratta dell’ultima riga nella finestra Emacs. Quando si digita un comando che richiede un
input, l’input viene richiesto in quest’area.
Normalmente i comandi Emacs cominciano con una combinazione di tasti comprendente il tasto
Ctrl o Esc. Per esempio la funzione find-file chiede il nome di un file e apre una copia del file in un
nuovo buffer, e la scelta rapida da tastiera corrisponde a Ctrl-x, Ctrl-b.
Emacs può avere più di un buffer aperto per volta.
> La selezione del testo
A differenza di altri sistemi operativi, Linux prevede, sia nella modalità a caratteri sia in quella
grafica, un utilizzo per il terzo tasto del mouse: la copia del testo. Prima si selezionano, utilizzando
il pulsante sinistro del mouse, le parole da copiare; quindi spostandosi con il mouse in un altro
punto della pagina (o in un’altra finestra sotto X), con un click del tasto centrale il testo selezionato
viene istantaneamente incollato nella nuova posizione. Se si possiede un mouse con solo due
pulsanti, è possibile configurare gpm in modo da emulare il terzo pulsante alla pressione
contemporanea dei tasti sinistro e destro del mouse.
62
3. Samba
E’ un’implementazione del protocollo SMB/CIFS. SMB (Server Message Block) è il protocollo che
sotto Windows si occupa della condivisione di file e stampanti. Può anche essere utilizzato per le
autenticazioni di un server, proprio come NIS. In questo caso Samba rappresenta quello che per
Unix è NFS e lpd. In più è multipiattaforma. Infatti, oltre che su Windows e Linux è possibile
utilizzare il protocollo SMB praticamente su tutti i sistemi operativi (tutti gli altri Unix, OS/2,
Macintosh, AmigaOS e altri).
Pur essendo disponibili delle soluzioni che permettono di utilizzare NFS anche su Dos e Windows,
è altamente sconsigliabile il loro uso per problemi legati alla sicurezza: per la natura non
multiutente di Dos è impossibile impedire un uso “maldestro” o “malintenzionato” di directory
esportate con NFS (l’uso di NFS su sistemi Unix rimane, invece, una scelta preferibile in quanto
l’integrità del sistema è garantita dalla necessaria autenticazione dell’utente). Il protocollo Samba è
fatto in modo da appoggiarsi a NetBIOS (Network Basic Input Output System), un protocollo
studiato da IBM per fornire una base allo sviluppo di software per Dos.
Questi due protocolli non sono in grado di “transitare” su una rete se non vi è un terzo protocollo
che si occupi del trasporto. L’implementazione originaria di questo protocollo era studiata per
utilizzare NetBEUI (NetBIOS Extended User Interface), in seguito lo si è reso compatibile anche
con IPX di Novell. Ma, con la diffusione di Internet, il suo utilizzo con il protocollo TCP/IP è stato
quello che ha riscosso maggior successo, in quanto questo protocollo è praticamente presente
ovunque.
Samba utilizza proprio quest’implementazione. All’uso di SMB attraverso TCP/IP, Microsoft ha
dato il nome di CIFS (Common Internet File System). Samba è costituito da due demoni: smbd e
nmbd. Il primo si occupa della condivisione vera e propria, aprendo la connessione coi client dopo
averli autenticati. Il secondo, invece, è il demone che agisce come il cosiddetto “network browser”,
quello che è in grado di far vedere la nostra condivisione in “Risorse di Rete”. Può essere utilizzato
anche come server WINS (Windows Internet Name Server). Samba è uno strumento molto potente
e flessibile, sono tantissime le opzioni a nostra disposizione, ma la sua configurazione non risulta
tanto complessa come potrebbe sembrare. Infatti esiste un unico file di configurazione
/etc/samba/smb.conf. E’ strutturato come un file .INI di Windows e permette di avere delle
linee commentate con il # o con ;.
Samba è quasi sempre incluso nell’installazione di default. In caso non fosse presente sicuramente
si può trovare sul cd di installazione oppure sul sito http://www.samba.org. Su Red Hat è
63
necessario installare i pacchetti samba, samba-common e samba-client. E’ anche essenziale
aver già configurato correttamente le schede di rete dei pc presenti sulla LAN.
Passiamo ora all’analisi del nostro file di configurazione già modificato per permettere operazioni:
inserimento del server Linux all’interno del dominio
workgroup = MYGROUP workgroup = GRUPPOSERVIZI
autenticazione degli utenti da parte del server Microsoft (IP: 192.9.200.1)
domain = USER domain = SERVER
;passwordserver = x.x.x.x passwordserver = 192.9.200.1
accesso lettura/scrittura ad una directory resa pubblica a tutti gli utenti
1. scommentare le voci del [public] in lettura/scrittura
2. scrivere nel path una directory precedentemente creata (ad esempio:
./home/condivisione) con permessi di lettura/scrittura
# A publicly accessible directory, read/write to all users. Note that all files
# created in the directory by users will be owned by the default user, so
# any user with access can delete any other user's files. Obviously this
# directory must be writable by the default user. Another user could of course
# be specified, in which case all files would be owned by that user instead.
[public]
path = /home/condivisione
public = yes
only guest = yes
writable = yes
printable = no
accesso alle home directory da parte dei rispettivi utenti
1. opzione già attiva per default
3.1. File samba.conf
# This is the main Samba configuration file. You should read the
# smb.conf(5) manual page in order to understand the options listed
# here. Samba has a huge number of configurable options (perhaps too
# many!) most of which are not shown in this example
#
# Any line which starts with a ; (semi-colon) or a # (hash)
# is a comment and is ignored. In this example we will use a #
# for commentry and a ; for parts of the config file that you
# may wish to enable
#
# NOTE: Whenever you modify this file you should run the command "testparm"
# to check that you have not made any basic syntactic errors.
#
#======================= Global Settings =====================================
[global]
64
# workgroup = NT-Domain-Name or Workgroup-Name
workgroup = GRUPPOSERVIZI
# server string is the equivalent of the NT Description field
server string = Samba Server
# This option is important for security. It allows you to restrict
# connections to machines which are on your local network. The
# following example restricts access to two C class networks and
# the "loopback" interface. For more examples of the syntax see
# the smb.conf man page
; hosts allow = 192.9.200. 127.
# if you want to automatically load your printer list rather
# than setting them up individually then you'll need this
printcap name = /etc/printcap
load printers = yes
# It should not be necessary to spell out the print system type unless
# yours is non-standard. Currently supported print systems include:
# bsd, sysv, plp, lprng, aix, hpux, qnx
printing = lprng
# Uncomment this if you want a guest account, you must add this to /etc/passwd
# otherwise the user "nobody" is used
; guest account = pcguest
# this tells Samba to use a separate log file for each machine
# that connects
log file = /var/log/samba/%m.log
# Put a capping on the size of the log files (in Kb).
max log size = 0
# Security mode. Most people will want user level security. See
# security_level.txt for details.
security = SERVER
# Use password server option only with security = server
# The argument list may include:
# password server = My_PDC_Name [My_BDC_Name] [My_Next_BDC_Name]
# or to auto-locate the domain controller/s
# password server = *
password server = 192.9.200.1
# Password Level allows matching of _n_ characters of the password for
# all combinations of upper and lower case.
; password level = 8
; username level = 8
# You may wish to use password encryption. Please read
# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd
# The following is needed to keep smbclient from spouting spurious errors
# when Samba is built with support for SSL.
; ssl CA certFile = /usr/share/ssl/certs/ca-bundle.crt
# The following are needed to allow password changing from Windows to
# update the Linux sytsem password also.
# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.
65
# NOTE2: You do NOT need these to allow workstations to change only
# the encrypted SMB passwords. They allow the Unix password
# to be kept in sync with the SMB password.
; unix password sync = Yes
; passwd program = /usr/bin/passwd %u
; passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*all*authentication*tokens*updated*successfully*
# Unix users can map to different SMB User names
; username map = /etc/samba/smbusers
# Using the following line enables you to customise your configuration
# on a per machine basis. The %m gets replaced with the netbios name
# of the machine that is connecting
; include = /etc/samba/smb.conf.%m
# This parameter will control whether or not Samba should obey PAM's
# account and session management directives. The default behavior is
# to use PAM for clear text authentication only and to ignore any
# account or session management. Note that Samba always ignores PAM
# for authentication in the case of encrypt passwords = yes
; obey pam restrictions = yes
# Most people will find that this option gives better performance.
# See speed.txt and the manual pages for details
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
# Configure Samba to use multiple interfaces
# If you have multiple network interfaces then you must list them
# here. See the man page for details.
; interfaces = 192.168.12.2/24 192.168.13.2/24
# Configure remote browse list synchronisation here
# request announcement to, or browse list sync from:
# a specific host or from / to a whole subnet (see below)
; remote browse sync = 192.168.3.25 192.168.5.255
# Cause this host to announce itself to local subnets here
; remote announce = 192.168.1.255 192.168.2.44
# Browser Control Options:
# set local master to no if you don't want Samba to become a master
# browser on your network. Otherwise the normal election rules apply
; local master = no
# OS Level determines the precedence of this server in master browser
# elections. The default value should be reasonable
; os level = 33
# Domain Master specifies Samba to be the Domain Master Browser. This
# allows Samba to collate browse lists between subnets. Don't use this
# if you already have a Windows NT domain controller doing this job
; domain master = yes
# Preferred Master causes Samba to force a local browser election on startup
# and gives it a slightly higher chance of winning the election
; preferred master = yes
# Enable this if you want Samba to be a domain logon server for
# Windows95 workstations.
; domain logons = yes
# if you enable domain logons then you may want a per-machine or
66
# per user logon script
# run a specific logon batch file per workstation (machine)
; logon script = %m.bat
# run a specific logon batch file per username
; logon script = %U.bat
# Where to store roving profiles (only for Win95 and WinNT)
# %L substitutes for this servers netbios name, %U is username
# You must uncomment the [Profiles] share below
; logon path = \\%L\Profiles\%U
# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable it's WINS Server
; wins support = yes
# WINS Server - Tells the NMBD components of Samba to be a WINS Client
# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
; wins server = w.x.y.z
# WINS Proxy - Tells Samba to answer name resolution queries on
# behalf of a non WINS capable client, for this to work there must be
# at least one WINS Server on the network. The default is NO.
; wins proxy = yes
# DNS Proxy - tells Samba whether or not to try to resolve NetBIOS names
# via DNS nslookups. The built-in default for versions 1.9.17 is yes,
# this has been changed in version 1.9.18 to no.
dns proxy = no
# Case Preservation can be handy - system default is _no_
# NOTE: These can be set on a per share basis
; preserve case = no
; short preserve case = no
# Default case is normally upper case for all DOS files
; default case = lower
# Be very careful with case sensitivity - it can break things!
; case sensitive = no
#============================ Share Definitions ==============================
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
# If you want users samba doesn't recognize to be mapped to a guest user
; map to guest = bad user
# Un-comment the following and create the netlogon directory for Domain Logons
;[netlogon]
; comment = Network Logon Service
; path = /usr/local/samba/lib/netlogon
; path = /
; guest ok = yes
; writable = no
; share modes = no
# Un-comment the following to provide a specific roving profile share
# the default is to use the user's home directory
;[Profiles]
67
; path = /usr/local/samba/profiles
; browseable = no
; guest ok = yes
# NOTE: If you have a BSD-style print system there is no need to
# specifically define each individual printer
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
# Set public = yes to allow user 'guest account' to print
guest ok = no
writable = no
printable = yes
# This one is useful for people to share files
;[tmp]
; comment = Temporary file space
; path = /tmp
; read only = no
; public = yes
# A publicly accessible directory, but read only, except for people in
# the "staff" group
;[public]
; comment = Public Stuff
; path = /home/samba
; public = yes
; writable = yes
; printable = no
; write list = @staff
# Other examples.
#
# A private printer, usable only by fred. Spool data will be placed in fred's
# home directory. Note that fred must have write access to the spool directory,
# wherever it is.
;[fredsprn]
; comment = Fred's Printer
; valid users = fred
; path = /home/fred
; printer = freds_printer
; public = no
; writable = no
; printable = yes
# A private directory, usable only by fred. Note that fred requires write
# access to the directory.
;[fredsdir]
; comment = Fred's Service
; path = /usr/somewhere/private
; valid users = fred
; public = no
; writable = yes
; printable = no
# a service which has a different directory for each machine that connects
# this allows you to tailor configurations to incoming machines. You could
# also use the %U option to tailor it by user name.
# The %m gets replaced with the machine name that is connecting.
;[pchome]
; comment = PC Directories
68
; path = /usr/local/pc/%m
; public = no
; writable = yes
# A publicly accessible directory, read/write to all users. Note that all files
# created in the directory by users will be owned by the default user, so
# any user with access can delete any other user's files. Obviously this
# directory must be writable by the default user. Another user could of course
# be specified, in which case all files would be owned by that user instead.
[public]
; path = /usr/somewhere/else/public
path = /home/condivisione
public = yes
only guest = yes
writable = yes
printable = no
# The following two entries demonstrate how to share a directory so that two
# users can place files there that will be owned by the specific users. In this
# setup, the directory should be writable by both users and should have the
# sticky bit set on it to prevent abuse. Obviously this could be extended to
# as many users as required.
;[myshare]
; comment = Mary's and Fred's stuff
; path = /usr/somewhere/shared
; valid users = mary fred
; public = no
; writable = yes
; printable = no
; create mask = 0765
Ogni parola racchiusa tra [ ] rappresenta una sezione.
[global] contiene le opzioni globali e le impostazioni di default. “workgroup” indica il
gruppo di lavoro al quale il nostro server Samba appartiene. “server string” ci permette di
scrivere un breve commento. “printing” indica il sistema di stampa utilizzato sul nostro sistema.
Potremmo scegliere tra: BSD, AIX, LPRNG, PLP, SYSV, HPUX, QNX, SOFTQ e CUPS.
Dobbiamo dedicare maggiore attenzione alle restanti tre voci della sezione [global]. A
“security” può essere assegnato il valore “user” che permette ad ogni utente di autenticarsi
utilizzando la propria username e password, altrimenti possiamo usare “share”. E’ possibile
mettere anche “domain” e “server”, come nel nostro caso, per far autenticare un utente
attraverso un server NT. “encrypt password = yes” ci permette di poter utilizzare Samba
anche con Windows 98, NT, 2000 ed XP. Questo perché, per motivi di sicurezza, questi sistemi
operativi non inviano più la password in chiaro, ma criptata. L’ultima voce della sezione
“smbpasswd file” indica il file contenente le password, che per default è
/etc/samba/smbpasswd.
[homes] fa in modo di esportare la home directory di ogni utente. L’utente viene riconosciuto in
base alla combinazione username/password. Con “browseable” decidiamo se far visualizzare o
69
meno questa cartella come condivisa tra le “Risorse di Rete”. Per default è assegnato il valore “no”,
perché la cartella condivisa appare già con il nome dell’utente (altrimenti apparirebbero due cartelle
condivise, una con il nome homes e una con il nome dell’utente). “read only = no” permette
di poter scrivere sulla condivisione, se i permessi lo consentono.
[printers] “guest ok = yes” permette l’utilizzo della stampante a tutti gli utenti e non
richiede un’autenticazione. A “printable” dovrebbe sempre essere assegnato il valore “yes”
per le stampanti. Le stampanti condivise nella nostra rete sono già installate sotto il server Microsoft
ed il server Linux le utilizza come una qualsiasi risorsa condivisa. Quindi le voci nella sezione
[printers] non hanno, per noi, alcuna importanza.
Una volta verificata la correttezza del file di configurazione possiamo avviare i demoni smbd e
nmbd attraverso il tool serviceconf oppure digitando nella shell
# service smb restart
3.2. SWAT
Nel caso non si voglia configurare a mano il file samba.conf esiste un’utilità grafica per assistere
l’amministratore nella configurazione di suddetto file. Samba Web Administration Tool (SWAT) è
un’utilità basata su Web che assiste nella configurazione del file mediante finestre molto facili da
usare. La posizione di default di SWAT è /usr/local/sbin/swat, con i file utilizzati per la
pagina Web localizzati nella directory /usr/local/samba/swat. SWAT viene avviata tramite
il processo inetd in Linux. Per eseguire SWAT è necessario creare una voce nel file
/etc/services in modo che Linux sappia a quale porta TCP essa sarà in ascolto. Potete
selezionare qualsiasi porta TCP disponibile anche se attualmente si verifica un errore se selezionate
una porta superiore a 1024. La documentazione SWAT corrente utilizza la porta TCP 901 come
esempio, quindi essa è quella che abbiamo impiegato. La voce in /etc/services dovrebbe
avere il seguente aspetto: swat 901/tcp. Successivamente deve essere aggiunta una voce nel
file /etc/inetd.conf in modo che il processo inetd sappia cosa generare quando riceve una
richiesta di connessione alla porta SWAT:
swat stream tcp nowait.400 root /usr/local/sbin/swat swat
E’ necessario riavviare il processo inetd per leggere le nuove configurazioni. Una volta riavviata
inetd possiamo utilizzare il nostro Web browser preferito e connetterci al nostro server Samba
tramite la porta definita nel file /etc/services/ (per esempio http://tuo_computer:901/). Prima
della connessione SWAT invierà una interrogazione per ricevere un ID utente ed una password.
Bisogna fare attenzione in quanto questi valori vengono inviati sulla rete in formato testo semplice;
70
una volta effettuato il log in nell’utilità SWAT, essa dovrebbe produrre la home page Web illustrata
nella figura sottostante.
Dalla home page è possibile visualizzare, aggiungere, eliminare o modificare tutti i parametri
contenuti nel file smb.conf. SWAT ci permetterà anche di avviare e riavviare i demoni smbd e
nmbd se avete modificato il file smb.conf.
3.3. Configurazione di Samba su Windows NT
Adesso che abbiamo un server Samba attivo vogliamo avere dei client che si collegano ad esso. Il
server Samba si comporta come un normale device in una rete CIFS di Microsoft e connettersi ad
esso è come collegarsi ad altri device CIFS presenti sulla rete. Perché una workstation Windows NT
si connetta ad un server Samba, deve essere configurata come un client per una rete Microsoft. Ci
sono tre differenti protocolli che possono essere utilizzati in reti CIFS di Microsoft: NetBEUI, IPX
e TCP/IP. Attualmente Samba supporta soltanto reti Microsoft che utilizzano il protocollo TCP/IP,
quindi tutti i client che hanno bisogno di connettersi al server Samba devono avere TCP/IP
configurato in modo adeguato, oltre ad avere istallato il normale software Client per Microsoft
Network. Per configurare la rete su una workstation Windows NT bisogna attivare la finestra di
71
configurazione Network facendo click su Start Settings Control Panel e poi selezionando
l’icona Network.
Con i seguenti passi è possibile configurare le impostazioni Network in modo da permettere a tutte
le workstation di connettersi al server Samba.
1. Configurare la scheda di rete. Selezionare la scheda Adapter. Se non è configurata la scheda
basta aggiungerla facendo click sul pulsante Add e selezionandola dall’elenco di schede
disponibili oppure facendo click sul pulsante Have Disk per utilizzare il driver fornito con la
scheda.
2. Configurare l’identificazione del PC. Ciascun device in un gruppo di lavoro di rete deve
avere un nome di rete univoco. E’ inoltre conveniente ma non necessario unirlo allo stesso
gruppo di lavoro o dominio in cui si trova il server Samba (perché in questo modo il server
appare nelle Risorse di Rete).
3. Configurare il protocollo TCP/IP. E’ necessario selezionare la scheda Protocols. Se il
protocollo non è installato bisogna cliccare sul pulsante Add e selezionarlo dall’elenco dei
protocolli di rete. Una volta installato deve essere configurato in modo adeguato perché il pc
possa comunicare con la rete. Selezionando TCP/IP Protocol e facendo click sul pulsante
72
Properties è possibile modificarne le impostazioni. L’indirizzo IP deve essere valido per la
rete locale.
4. Configurare i servizi Microsoft Network. Questi servizi sono impostati per default su una
workstation NT.
Una volta configurata adeguatamente la workstation siamo in grado di vedere il server Samba dalle
Risorse di Rete, da cui è possibile mappare drive e stampanti condivise. Se è visibile il server ma è
impossibile vedere le condivisioni, è probabile che ci sia un problema di ID utente o di password.
L’ID utente utilizzato dalla workstation Windows NT per collegarsi al server Linux è lo stesso
utilizzato per il login nella workstation stessa; da ricordare che dopo il Service Pack 3 Windows NT
impiega per default le password codificate.
3.4. Configurazione di Samba su Windows 95/98
E’ possibile collegarsi al server Samba mediante workstation Windows 95 e 98. Affinché si
colleghino a Samba, queste devono essere configurate per supportare Microsoft Network ed avere il
protocollo TCP/IP configurato. Questi componenti possono essere configurati mediante la finestra
di configurazione Network.
73
1. Configurare la scheda di rete. Selezionare la scheda Adapter. Se non è configurata la scheda
basta aggiungerla facendo click sul pulsante Add e selezionandola dall’elenco di schede
disponibili oppure facendo click sul pulsante Have Disk per utilizzare il driver fornito con la
scheda.
2. Configurare TCP/IP. Selezionare Microsoft, nella scheda Protocol, nell’elenco dei
fabbricanti e poi fare clic su TCP/IP, potete configurare le impostazioni IP.
3. Configurare il client per Microsoft Networks. Selezionare Microsoft dall’elenco dei
fabbricanti e poi scegliere Microsoft Client for Microsoft Networks
4. Configurare l’identificazione della workstation. Ogni device in un gruppo deve di lavoro
deve avere un Computer Name unico. E’ anche conveniente unirsi allo stesso gruppo di
lavoro o dominio su cui si trova il server Samba, anche se non è necessario.
Una volta completata la configurazione siamo in grado di vedere il server Samba fra le risorse di
rete della workstation.
3.5. Utilizzo di Samba
Adesso che abbiamo un server Samba pienamente funzionale con client che si collegano a
condivisioni e stampanti, è interessante poter monitorare tutte le nuove attività.
Samba mantiene dettagliati log file di tutte le connessioni alle condivisioni. La posizione di default
per i log file è la directory /usr/local/samba/var. I due log file principali per Samba sono.
log.smb e log.nmb. Questi file documentano l’attuale stato dei processi smbd e nmbd, oltre ai
tentativi di connessione alle condivisioni. Segue una breve descrizione delle utilità relative a
Samba.
smbstatus
Può essere utilizzata per monitorare lo stato delle connessioni Samba correnti. Mostra le
connessioni correnti oltre che i file attualmente bloccati e l’attuale stato della memoria del
server. Questo permette di monitorare connessioni alle condivisioni sul server Samba.
smbclient
Può essere utilizzata per la connessione ad altre condivisioni di rete dal server Samba.
Questo programma utilizza un interfaccia di tipo FTP quando si connette alla condivisione
remota che permette di sfogliare, inviare e ricevere file dalla condivisione. La sintassi del
comando di smbclient è la seguente:
smbclient service <password> [options]
Il parametro service è il nome della condivisione alla quale ci si vuole connettere
mediante le convenzioni di denominazione standard CIFS.
74
testparm
Programma utile agli amministratori. Testa il file smb.conf alla ricerca di errori di
configurazione e di incoerenze, ma non lo testa per individuare errori logici come
condivisioni configurate con privilegi di accesso errati, anche se le informazioni da esso
fornite possono aiutare a localizzare problemi di quel genere. Il formato di testparm è:
testparm [configfilename] [hostname hostIP]
configfilename è impostato per default al file standard smb.conf, sebbene possa
essere modificato qualora si voglia modificare un diverso file di configurazione. Il
programma testparm elenca i valori di tutti o parametri server come sono impostati dal
file di configurazione smb.conf.
testprns
Il programma testprns testa le stampanti definite nel file smb.conf. Verifica se la
stampante esiste nel file /etc/printcap. Il formato di testprns è:
testprns printername [printcap name]
In cui printername è il nome della stampante che si desidera testare.
nmblookup
Questo tool permette alle richieste dei nomi NetBIOS di essere effettuate da un host Unix.
make_smbcodepage
Questa utilità provvede a creare i file di definizione di codice di pagina SMB per il demone
smbd.
smbpasswd
Questo comando è un tool per cambiare gli hashes delle password di LanMan e Windows
NT sui server Samba e Windows NT.
75
4. Le routine di avvio: i primi minuti dopo il lancio del sistema operativo
Gli utenti che provengono dal mondo Dos/Windows 9x spesso si domandano se esista (e quale sia)
l’equivalente Linux del file autoexec.bat e config.sys che, già nelle prime versioni di Ms-
Dos, erano responsabili dell’esecuzione, all’avvio del sistema operativo, di programmi o di semplici
script personalizzati. Il processo di bootstrap ha inizio al momento dell’accensione del sistema.
Viene per prima cosa eseguito il codice residente nel bios della macchina che, terminati i test
sull’hardware, ha il compito di leggere il programma di boot residente sull’unità di avvio (di solito
si trova sul Master Boot Record del disco rigido). Il programma di boot ha il compito di caricare e
passare il controllo al kernel del sistema operativo installato, sia esso Ms-Dos, Windows 9x o NT,
2000 o XP, Linux, Unix, Mac-Os o quant’altri.
I meccanismi di gestione del processo di boot dei “dialetti” Unix (e Linux fra essi) prevedono che il
kernel effettui il probing del bus alla ricerca dei dispositivi connessi al sistema e che lanci alcuni
processi indispensabili al funzionamento del sistema operativo. Il kernel rimarrà residente in
memoria fino al riavvio del sistema operativo: tuttavia, dopo aver eseguito i compiti di cui sopra,
cederà il controllo ad un processo, il cui ruolo è molto importante, chiamato init.
I sistemi Unix vengono classificati in due categorie che si distinguono per alcune scelte
architetturali, le quali si riflettono anche sulla gestione delle routine di inizializzazione del sistema:
l’architettura System V prende il nome dallo Unix di AT&T; mentre l’architettura BSD trae il
proprio nome dall’Università della California di Berkeley nella quale è stata sviluppata. Le
principali differenze fra i due modelli, per quanto concerne il processo di inizializzazione del
sistema, si trovano nella diversa struttura del file system in relazione agli script di boot e nella scelta
dei processi lanciati dal kernel all’avvio del sistema (in particolare per quanto concerne il processo
0 che, nelle architetture System V, è lo scheduler dei processi – sotto BSD il processo 0 è invece il
demone swapper che si occupa dello spostamento delle pagine di memoria da quella fisica a
quella virtuale).
La maggior parte delle distribuzioni Linux oggi in commercio adottano il meccanismo di
inizializzazione System V, che viene ritenuto più flessibile e configurabile di quello BSD.
4.1. Init: il processo 1
Init è il processo principale di tutti i sistemi Unix, radice dell’albero dei processi correntemente
in esecuzione sulla macchina (l’unica eccezione è rappresentata dal già menzionato processo 0). Il
suo PID (Process IDentifier) è sempre 1. Il PID è un numero, assegnato automaticamente secondo
sequenza dal sistema, che identifica univocamente un processo, sia esso automatico (cioè avviato in
76
automatico dal sistema operativo) oppure lanciato da un utente. Come possiamo dimostrare che
init ha PID uguale ad uno? Utilizzando il comando ps, che visualizza i processi attivi, con
l'opzione x, che riporta i processi avviati senza terminale di controllo: nel risultato possiamo
leggere qualcosa del genere:
PID TTY STAT TIME COMMAND
1 ? S 0:05 init [2]
Le colonne che ci interessano sono PID, TTY (terminale su cui è in esecuzione il programma),
STAT (lo stato del programma stesso; S è sinonimo di sleeping) e COMMAND, che ovviamente
mostra il nome del programma.
Uno dei tanti modi di arrestare un sistema Unix è quello di inviare, con il comando kill, un signal
(direttiva Unix di comunicazione tra processi) di terminazione al processo 1. Il programma init si
trova solitamente nella directory /sbin, almeno per quanto concerne le architetture System V, e
viene caricato ed eseguito direttamente dal kernel di Linux. Esso legge il file /etc/inittab che
contiene le informazioni per attivare i processi necessari all’avvio del sistema ed alla gestione dei
terminali; ricava inoltre dal medesimo file l’indicazione del livello di esecuzione esaminando le
indicazioni della direttiva initdefault in esso contenuta: nel caso di Red Hat e sue derivate è il
5, anche se fosse stato 3, 4 o 5 non ci sarebbe stata differenza.
Con il termine runlevel (livello di esecuzione) si intende riferirsi allo stato corrente del sistema, la
qual cosa può dare un’indicazione sufficientemente precisa di quali possono essere i servizi in
esecuzione. I livelli di esecuzione per un sistema Linux sono 7, identificati da una cifra che varia da
0 a 6. Anche se esistono il settimo, l’ottavo e il nono, non vengono però utilizzati dai normali Unix
(e Linux con loro).
>Runlevel 0 Il sistema viene arrestato (halt). Il passaggio a questo livello equivale (in linea di
massima) all’esecuzione del comando halt o, equivalentemente, del comando shutdown –h
now.
>Runlevel 1 Single user (modalità monoutente): il sistema attiva un numero estremamente ridotto di
servizi; il file system radice viene montato in sola lettura; questo livello di esecuzione è utile
quando ogni tentativo di boot ai livelli più elevati fallisce.
>Runlevel 2 Multi user without network (modalità multiutente senza supporto di rete): è attiva la
maggior parte dei servizi con l’eccezione di quelli di rete (httpd, nfs, bind e così via).
>Runlevel 3 Multi user: tutti i servizi vengono attivati.
>Runlevel 4 Solitamente non usato dalle distribuzioni Linux.
77
>Runlevel 5 Graphical login: tutti i servizi sono attivi e viene proposto il login grafico anziché
quello tramite console testuale.
>Runlevel 6 Il sistema viene riavviato (reboot). Il passaggio a questo livello equivale (in linea di
massima) all’esecuzione del comando reboot o, equivalentemente, del comando shutdown -r
now.
Il comando init può essere lanciato solo dall’utente root con lo scopo di cambiare il livello di
esecuzione oppure di far riesaminare il file di configurazione /etc/inittab. Per esempio, per
porre il sistema in modalità monoutente (livello 1), occorre che l’amministratore digiti sulla shell il
comando:
[root@linux01 root]# init 1
Un modo “alternativo” per arrestare (livello 0) o riavviare (livello 6) il sistema potrebbe essere
rappresentato rispettivamente dai comandi:
[root@linux01 root]# init 0
e
[root@linux01 root]# init 6
Un’utile opzione è -t, che permette di specificare il numero di secondi di attesa prima di passare al
livello specificato (in mancanza di questo parametro si sottintendono 20 secondi). Per far invece
riesaminare la configurazione del file /etc/inittab, senza riavviare il sistema, è sufficiente che
l’utente root digiti il comando:
[root@linux01 root]# init Q
oppure
[root@linux01 root]# init q
In particolari casi, le lettere S oppure s possono indicare la modalità monoutente (single user). In
questi casi i comandi:
[root@linux01 root]# init S
oppure
[root@linux01 root]# init s
sono equivalenti al comando:
[root@linux01 root]# init 1
Ricordiamo come sia possibile eseguire init seguito da una delle prime tre lettere dell’alfabeto (a,
b o c) imponendo così l’esecuzione dei comandi, indicati nel file /etc/inittab, che riportano
un livello di esecuzione equivalente alla lettera specificata. Per esempio, per eseguire i comandi
associati al livello b è sufficiente che l’amministratore digiti dalla shell:
[root@linux01 root]# init b
78
Occorre tuttavia sottolineare come le tre lettere a, b e c non rappresentino dei reali runlevel: il loro
uso è limitato al testing ed all’utilizzo di particolari configurazioni del sistema e del file
/etc/inittab. Essi saranno eventualmente presenti all’interno del file di configurazione
inittab e trattati come on demand runlevel (livelli di esecuzione a richiesta).
Il file di configurazione /etc/inittab serve per specificare quali processi il comando init
deve lanciare nei diversi livelli di esecuzione (runlevel) cui abbiamo accennato sopra. Per ogni
livello di esecuzione init può lanciare uno o più programmi.
Ogni riga del file /etc/inittab deve rispettare la seguente sintassi:
id:runlevel:azione:processo
dove id rappresenta una sequenza di due caratteri che identifica univocamente la singola riga
all’interno del file; runlevel verrà sostituito con il livello (oppure i livelli) di esecuzione per i quali il
comando processo deve venire eseguito; infine azione specifica le modalità di esecuzione del
processo. In particolare, menzioniamo come particolarmente significative le seguenti keyword per il
campo azione:
>respawn Quando il processo termina, viene automaticamente riavviato.
>wait Il comando viene eseguito una sola volta; inoltre init attende il completamento
dell’esecuzione del processo prima di proseguire.
>once Il comando viene eseguito una sola volta senza attendere il completamento dell’esecuzione
del processo prima di proseguire.
>boot Il comando viene eseguito contestualmente all’avvio del sistema, dopo l’esecuzione dei
comandi associati all’azione sysinit (vedi); il campo runlevel viene ignorato.
>bootwait Simile a boot ma viene atteso il completamento dell’esecuzione del processo prima di
proseguire.
>ondemand Le righe che riportano la keyword ondemand nel campo azione permettono di
specificare i comandi che vanno eseguiti nel caso venga lanciato il comando init seguito dal
parametro a, b o c ad identificare uno degli pseudo runlevel visti prima. Nel caso venga specificata
la keyword ondemand occorre che il campo runlevel contenga una combinazione delle lettere
a, b e c in luogo delle consuete cifre da 0 a 6.
>initdefault Permette di specificare il livello di esecuzione predefinito per l’avvio del sistema. Si
presti particolare attenzione a non indicare il livello 0 (arresto del sistema) o 6 (riavvio del sistema).
>sysinit Il comando viene eseguito contestualmente all’avvio del sistema, prima di eseguire i
comandi associati alle azioni boot e bootwait; il campo runlevel viene ignorato.
79
>powerwait Il comando viene eseguito quando init riceve il segnale SIGPWR a segnalare un
problema con l’alimentazione elettrica; viene atteso il completamento dell’esecuzione del processo
prima di proseguire.
>powerfail Simile all’azione powerwait ma init non attende il completamento dell’esecuzione
del processo.
>powerokwait Il comando viene eseguito quando init riceve il segnale SIGPWR (a segnalare un
problema con l’alimentazione elettrica) e il file /etc/powerstatus contiene la stringa OK. Ciò
viene interpretato coma ritorno dell’alimentazione allo stato normale.
>ctrlaltdel Il comando viene eseguito quando init riceve il segnale SIGINT (ad esempio per la
pressione della combinazione di tasti Ctrl-Alt-Del).
>kbrequest Specifica quale comando init dovrà lanciare alla pressione della combinazione
kbrequest (di solito Alt-FrecciaSu).
Alcuni esempi ci permetteranno di chiarire meglio i concetti espressi.
id:5:initdefault:
Imposta a 5 (login grafico) il livello di esecuzione predefinito per il sistema.
si:l:bootwait:/etc/init.d/boot
Impone ad init di eseguire lo script boot posto nella directory /etc/init.d prima di ogni
altro script, attendendone il completamento prima di proseguire con l’esecuzione dei comandi
successivi.
si::sysinit:/etc/rc.d/rc.sysinit
Impone a init di eseguire lo script rc.sysinit posto nella directory /etc/rc.d prima
d’ogni altro script.
l0:1:wait:/etc/init.d/rc 1
Impone al sistema di eseguire lo script rc posto nella directory /etc/init.d passandogli il
parametro 1 nel caso l’esecuzione sia pari ad 1 (modalità monoutente), attendendo la fine della sua
esecuzione prima di procedere.
ls:S:wait:/etc/init.d/rc S
~~:S:respawn:/sbin/sulogin
80
Impone al sistema di eseguire lo script rc posto nella directory /etc/inid.d passandogli il
parametro S, nel caso il livello d’esecuzione sia S (modalità monoutente – vedi sopra), attendendo
la fine della sua esecuzione (wait), prima di lanciare il comando /sbin/sulogin per aprire una
shell d’amministrazione che deve essere riavviata non appena viene chiusa (respawn).
ca:ctrlaltdel:/sbin/shutdown –r –t 4 now
Indica il comando (/sbin/shutdown –r –t 4 now) da eseguire nel caso in cui init riceva
il segnale SIGINT (di solito con la pressione della combinazione di tasti Ctrl-Alt-Del). Si noti come
in questo caso non venga specificato alcun livello d’esecuzione.
sh:12345:powerfail:/sbin/shutdown –h now “THE POWER IS FAILING”
Impone ad init di effettuare uno shutdown immediato segnalando su tutte le console il messaggio
indicato nel caso in cui il processo riceva un signal SIGPWR (problemi d’alimentazione elettrica); il
comando deve essere eseguito se il sistema è in uno dei livelli d’esecuzione da 1 a 5.
1:2345:respawn:/sbin/mingetty –noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
Avvia le console virtuali per i livelli di esecuzione da 2 a 5 (per la modalità monoutente viene
utilizzato il comando sulogin di cui sopra). La console sul dispositivo tty1 (ove vengono
visualizzati i messaggi di avvio del sistema) non deve ripulire lo schermo prima di avviarsi. Ogni
console deve essere riavviata non appena chiusa (respawn) così da rendere sempre disponibile il
prompt di login al sistema.
x:5:respawn:/usr/bin/X11/sdm -nodaemon
In caso d’esecuzione del livello 5 (login grafico), viene lanciato il comando xdm posto nella
directory /usr/bin/X11, cui viene passato il parametro –nodaemon. xdm si occupa di
mostrare lo schermo di login grafico in ambiente X. L’azione respawn garantisce che all’uscita
dell’ambiente grafico venga nuovamente presentata la finestra di login di xdm.
81
Ma cos'è il runlevel 5 e cosa lo differenzia dagli altri? La definizione di runlevel è già stata data in
precedenza, quello che si vuole mettere qui in evidenza è cosa comporta nel sistema il
raggiungimento di tale runlevel. A questo scopo, dobbiamo rivolgerci ancora al file
/etc/inittab, nel quale sono presenti le righe:
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
Quindi, al runlevel che c’interessa esaminare, il quinto, viene invocata l'azione "wait", che indica ad
init di avviare il processo ed attenderne la terminazione; il processo che viene avviato è
/etc/init.d/rc con un 5 come argomento. Cos'è questo programma rc che viene richiamato?
Esso non è altro che uno script di shell, che, dopo opportuni controlli ed accorgimenti, si porta nella
directory /etc/rcX.d e n’esegue gli script contenuti. Alla "X" che abbiamo utilizzato va
comunque sostituito l'argomento passato come opzione al comando rc: quindi, nel caso del
runlevel 5, rc si porterà nella directory /etc/rc5.d.
Una volta che ogni servizio dispone del proprio file di script in grado di provvedere alla sua
attivazione e disattivazione, occorre poter segnalare al sistema quale, fra i servizi disponibili, debba
venir avviato (in quale ordine) per ciascun livello d’esecuzione. Il problema è stato risolto in
maniera piuttosto semplice. Nella directory /etc/rc.d si trovano tante directory quanti sono i
possibili livelli d’esecuzione. All’interno di ciascuna di esse si troveranno una serie di collegamenti
simbolici agli script: essi avranno un nome che inizia con la lettera S oppure con la lettera K seguita
da due cifre. Com’è facilmente intuibile, i link simbolici che iniziano con la lettera S (start)
individuano gli script da utilizzare per l’avvio dei servizi (verranno dunque eseguiti gli script di cui
i link “puntano”, seguiti dal parametro start), mentre quelli che iniziano con la lettera K (kill)
individuano gli script da utilizzare per la disattivazione degli stessi (verranno dunque eseguiti gli
script cui i link “puntano”, seguiti dal parametro stop). Gli script vengono eseguiti in rigoroso
ordine alfabetico: da qui la presenza delle due cifre che seguono la prima lettera del nome del link e
che permettono di stabilire l’ordine d’esecuzione degli script.
82
E’ facile rendersi conto di come le directory rc0.d e rc6.d contengano per la maggior parte script
che iniziano con la lettera K, in quanto i livelli d’esecuzione 0 e 6 servono rispettivamente
all’arresto ed al riavvio del sistema operativo.
Detto questo, esaminiamo il contenuto della directory /etc/rc5.d. Vediamo intanto cosa
contengono, utilizzando il noto comando dir (comunque di solito utilizzeremo solo il comando
ls):
dir /etc/rc5.d
il cui output è qualcosa di simile alle righe seguenti:
S10sysklogd S20anacron S20gpm S20makedev S50proftpd
S99rmnologin S12kerneld S20apmd S20inetd S20postgresql
S89cron S14ppp S20exim S20logoutd S20xfs
S91apache
Come si vede, ogni file ha il nome composto dalle tre parti descritte sopra: la lettera, il numero ed il
nome del processo.
Vediamo un esempio: l'avvio di gpm (il demone che gestisce il mouse) è precedente all'avvio di
apache, visto che gpm ha un id numerico 20 contro il 91 di apache. L'id numerico qui riportato
non ha comunque nulla a che fare con il PID che il programma si vedrà assegnato dal sistema: il
numero che qui precede il nome del programma è utilizzato per definire la priorità con la quale
vengono avviati i processi. Quindi, una volta che init verrà avviato, lancerà il programma rc che
s’incaricherà di avviare i servizi citati in /etc/rc5.d.
Precedentemente abbiamo detto che i runlevel 2, 3, 4 e 5 sono equivalenti. Alla luce di quanto detto,
adesso è possibile dimostrarlo. A parte forzare un cambiamento di runlevel (attuabile con il
comando telinit seguito dal numero di runlevel) e notare che non succede niente, vediamolo più
tecnicamente. Utilizziamo il programma diff che visualizza in output le differenze fra due file o
due directory: lanciando in sequenza
diff /etc/rc2.d /etc/rc3.d
diff /etc/rc2.d /etc/rc4.d
diff /etc/rc2.d /etc/rc5.d
il comando non darà alcun output. Se invece lanciamo:
diff /etc/rc2.d /etc/rc1.d
verranno stampate a video le differenze fra le directory.
I file presenti in, ad esempio, /etc/rc5.d, non sono veri e proprio file, bensì dei link che
puntano a degli script che portano il nome del link senza la S o la K ed il numero presenti in
83
/etc/init.d; ad esempio, /etc/rc5.d/S91apache punta a /etc/init.d/apache.
Tutti gli script linkati in /etc/rcX.d sono presenti in /etc/init.d, così che possano essere
utilizzati come e quando serve all'entrata d’ogni runlevel.
Sono stati descritti init e runlevel abbastanza approfonditamente, più che altro per rendere
chiari i meccanismi di avvio del sistema; tutti i link e gli script necessari saranno installati
automaticamente all'installazione del sistema o di un nuovo programma che avrà bisogno di essere
lanciato all'avvio, a meno che non si voglia scrivere un proprio programma che debba essere
automaticamente avviato al boot e interrotto allo shutdown del sistema.
4.2. L’organizzazione degli script di avvio
Una delle prime differenze tra una distribuzione Linux e l’altra è l’organizzazione degli script di
avvio dei servizi. Se le procedure di inizializzazione, il comando init e il suo file di
configurazione /etc/inittab sono elementi comuni e standard per tutte le distribuzioni di
Linux, per quanto riguarda gli script successivi la situazione può variare a seconda della
distribuzione presa in esame.
In generale, ogni distribuzione include una directory (solitamente /etc/rc.d) nella quale sono
raccolti tutti gli script di inizializzazione. In particolare, essi si trovano nella directory
/etc/rc.d/init.d. Come abbiamo visto tra gli esempi di cui sopra, nel file /etc/inittab
si trova una riga responsabile dell’avvio dello script di sistema /etc/rc.d/rc.sysinit. Il suo
nome è facilmente individuabile in quanto associato alle azioni boot, bootwait oppure
sysinit nel file /etc/inittab.
Inoltre è possibile notare, all’interno dello script inittab, il richiamo allo script
/etc/rc.d/init.d/rc cui viene passato come parametro il livello di esecuzione selezionato:
questo script si occupa di eseguire tutti i comandi e script necessari all’attivazione dei servizi
associati ad un determinato livello di esecuzione.
Oltre agli rc.sysinit ed a rc nella medesima directory dovrebbe trovarsi lo script rc.local,
che viene normalmente eseguito alla fine della procedura di inizializzazione del sistema: questo file
può essere paragonato allo script autoexec.bat dei sistemi Ms-Dos o Windows 9x ed è
solitamente utilizzato dagli amministratori per effettuare le più svariate operazioni in fase di avvio
di sistema.
84
4.3. Gli script di attivazione e disattivazione dei servizi
Gli script della procedura di inizializzazione hanno il compito di avviare il sistema operativo e di
fermarlo, attivando e disattivando tutti i servizi necessari, cioè intervenendo sull’avvio e la
conclusione del funzionamento dei demoni relativi.
Come già detto sopra, questi script si trovano di solito nella directory /etc/rc.d/init.d e
provvedono a fornire le funzionalità di avvio e disattivazione dei servizi, oltre che di verifica dello
stato degli stessi in modo da evitare di lanciare più volte istanze diverse del medesimo demone. Gli
script si occupano di avviare o chiudere il servizio lanciando o fermando i corrispondenti demoni:
un singolo servizio potrebbe richiedere l’esecuzione di più di un demone: è questo, per esempio, il
caso di Samba, che richiede il lancio dei demoni smbd per lo sharing dei file e nmbd per la
risoluzione dei nomi. Gli stessi script provvedono a mettere in atto tutte le azioni necessarie a poter
interagire con i demoni medesimi: per esempio, spesso viene annotato in un file l’identificatore del
processo (PID) del demone oppure viene creato un file di lock con lo scopo di segnalare che ne è in
esecuzione un’istanza.
Abbiamo già visto precedentemente l’avvio dei programmi "automatizzato" da init, esaminando
il contenuto della varie directory /etc/rcX.d (ove la lettera X andrà sostituita con la cifra da 0 a
6 corrispondente al livello di esecuzione). Ci siamo però fermati al fatto che un servizio viene
avviato richiamato dal programma rc. Questa cosa è comunque ricollegabile a qualcosa di cui ci
siamo già occupati: i messaggi del boot; richiamiamo quindi qualcosa di già visto:
Starting system log daemon: syslogd klogd.
Starting anac(h)ronistic cron: anacron.
Starting advanced power management daemon: apmd.
Starting mouse interface server: gpm.
Starting internet superserver: inetd.
Starting PostgreSQL postmaster
Starting X font server: xfs.
Starting professional ftp daemon: proftpd.
Starting periodic command scheduler: cron.
Starting web server: apache.
Questi sono gli ultimi messaggi che si vedono al boot prima che si presenti la richiesta di login. Si
nota certamente che tutti questi programmi vengono eseguiti nello stesso ordine che ci si aspetta
leggendo il numero che, in /etc/rc5.d, precede il nome del programma da avviare.
85
La loro caratteristica fondamentale, a differenza dei normali programmi, è che i demoni sono
normalmente in esecuzione per tutta una sessione di lavoro (che, per un server, potrebbe essere
anche di qualche mese!), dall’avvio allo shutdown. Il motivo è semplice: questi programmi, infatti,
devono sempre essere in ascolto per soddisfare eventuali richieste provenienti dall’utente o
dall’esterno, nel caso la macchina sia in rete. Prendiamo ad esempio il server FTP, proftpd,
supponendo che la macchina sia collegata in rete: se esso non fosse in esecuzione, ogni connessione
alla macchina sarebbe categoricamente rifiutata, e l’amministratore dovrebbe agire manualmente
per avviarlo; ma se viene installato un servizio, probabilmente è perché si intende utilizzarlo, quindi
perché lasciarlo inattivo?
La questione dei "servizi sempre attivi" su una macchina spesso porta a qualche perplessità: molti,
infatti, si chiedono perché avere dei programmi sempre attivi anche se non vengono utilizzati. Se da
un lato questa perplessità è più che giustificata, dall’altra bisogna andare a vedere come funziona
tecnicamente un demone, utilizzando il programma ps, che fornisce altre importanti informazioni.
Un demone, normalmente, è un programma che resta in attesa su una porta del sistema in attesa che
qualcuno o qualcosa richieda una connessione. Lo stato in cui normalmente questo programma si
trova è detto "sleep", come se il programma fosse "in letargo": le risorse occupate dal demone,
quindi, risultano minime, poiché di fatto il programma sta solamente "sopravvivendo".
Vediamo ora la cosa con qualche dato in più: tramite il programma ps si ricava qualche utile
informazione: monitoriamo il demone Apache (legato al protocollo HTTP) in sleep ed in attività:
USER PID %CPU %MEM [...] TTY STAT START TIME COMMAND
root 179 0.0 6.7 [...] ? S 22:50 0:01 /usr/sbin/apache
In questo primo caso, Apache è in Sleep (dimostrato dalla "S" nella colonna "STAT"), non occupa
per nulla la CPU (visto che nella colonna CPU c’è un chiaro 0.0%) ed utilizza una piccola parte di
memoria, che probabilmente avrà utilizzato per l’avvio e per restare in vita. Come si vede, quindi,
un programma in sleep occupa solamente una parte della memoria (che comunque occuperebbe
anche se fosse avviato su richiesta) e nessun’altra risorsa di sistema. E, soprattutto, non forza
l’utente ad avviare un servizio quando non ce ne sia il reale bisogno, visto che questo saprà
rispondere automaticamente una volta interrogato.
Il fatto di avere molti servizi attivi nella macchina, comunque, potrebbe comportare seri problemi
di sicurezza.
In generale gli script possono essere richiamati con una riga di comando simile alla seguente:
[root@linux01 root]# /etc/rc.d/init.d/nome_servizio {start|stop}
86
ove i parametri start e stop (naturalmente mutuamente esclusivi) servono per indicare se
avviare o fermare il servizio specificato. Col tempo gli script hanno subito una certa evoluzione e
sono stati sottoposti ad un naturale processo di raffinamento: spesso parametri validi sono quelli che
permettono il riavvio o il ricaricamento della configurazione (restart, refresh) oppure la
verifica dello stato del demone (status) e così via.
Riprendiamo Apache per gli esempi. Di default, esso è in ascolto sulla porta 80 ma, per qualche
motivo, si potrebbe decidere di modificare questa impostazione, mettendolo in ascolto, ad esempio,
sulla porta 8080. Dopo aver modificato il file di configurazione, se Apache non viene riavviato
esso sarà sempre in ascolto sulla porta 80, fino al successivo reboot quando il file di configurazione
verrà riletto. Ma, soprattutto per un server di rete, i periodi di uptime (ossia il periodo di attività
senza interruzioni di una macchina) sono assai lunghi, e non sarebbe pensabile di, come si dice in
gergo, "buttare giù" il server. Per questo motivo, è prevista la possibilità di riavviare un solo
servizio senza che nessun’altra applicazione ne risenta.
Di base, il comando è
/etc/rc.d/init.d/apache stop
per interromperlo e
/etc/init.d/apache start
per avviarlo. In alternativa, un metodo più rapido è:
/etc/init.d/apache restart
tramite il quale le azioni stop e start vengono chiamate in successione.
Inoltre, alcuni servizi prevedono anche altre azioni che comunque, rispetto alle precedenti, vengono
usate molto più di rado.
87
5. Lan browsing
5.1. LAN Information Server – LISa
LISa è un piccolo demone che può funzionare su sistemi end user. Fornisce qualcosa di simile a
“Network Neighborhood” di Windows, ma si appoggia solamente allo stack del protocollo TCP/IP
e non a SMB o altri. Le informazioni sugli host appartenenti alla rete sono fornite via TCP tramite
la porta 7741.
LISa supporta due modalità di ricerca degli host, il primo metodo è quello di inviare pacchetti di
richiesta echo ICMP (Internet Control Message Protocol) agli host, il secondo è quello di inviare
broadcast NetBIOS utilizzando nmblookup. Per mantenere basso il carico della rete sono
implementate diverse strategie. C’è anche un meccanismo di sicurezza di base. Per funzionalità di
sicurezza più ristretta esiste un’altra versione chiamata resLISa.
LISa può funzionare sotto diverse piattaforme Unix (Linux, BSD, Solaris, …), potrebbe avere
problemi su macchine a 64bit e non funziona affatto con Ipv6. Fornisce qualche speciale supporto
per KDE, ma è completamente indipendente, non richiede né la libreria Qt né altri componenti di
KDE.
Questo screenshot mostra cosa LISa è in grado di fare:
88
5.2. Come funziona LISa?
Nel file di configurazione di LISa si possono inserire range d’indirizzi IP che LISa deve controllare
quando sono disponibili. Nel caso più semplice il range è composto dagli indirizzi e dalla
subnetmask della rete aziendale interna, in modo che LISa possa controllare ogni possibile host
della rete quando questi sono connessi. Gli host sono controllati utilizzando richieste echo ICMP.
Per poter ricevere richieste echo ICMP e risposte, il programma deve aprire il così detto “raw
socket”. Quindi ha bisogno dei privilegi di root. Questo socket viene aperto subito dopo l’avvio del
programma, dopo averlo aperto con successo, i privilegi di root vengono rilasciati immediatamente
(vedi main.cpp e strictmain.cpp). Configurando LISa in questo modo, così che utilizzi anche
nmblookup, si aprirà e visualizzerà i risultati.
89
Dato che le richieste ICMP ed i broadcast possono causare del traffico sulla rete se c’è più di un
server attivo, i server collaborano tra di loro. Prima di effettuare dei ping (o nmblookup), inviano un
broadcast sulla porta 7741. Se qualcuno risponde a questo broadcast, verrà recuperata da questo
host la lista completa degli host funzionanti via TCP sulla porta 7741 senza bisogno di effettuare
ulteriori ping. Se nessuno risponde, l’host che ha inviato il broadcast inizierà ad effettuare dei ping
verso gli host (o nmblookup) e quindi aprirà un socket che ascolta i broadcast menzionati. Se un
host riceve una risposta al suo broadcast, non avrà un socket disponibile per ascoltare i broadcast
aperti. Quindi di solito un solo determinato server avrà questo socket aperto e solo quest’ultimo
effettuerà dei ping (o nmblookup) verso gli host. In altre parole, i server sono pigri, e fanno un
ragionamento del tipo “Farò qualcosa solo se nessun altro può fare qualcosa per me”. C’è un’altra
caratteristica che riduce il carico sulla rete. Supponiamo di configurare LISa in modo che effettui un
update ogni dieci minuti. Da questo momento non ci sono accessi al server molto frequenti. Se
nessuno ha effettuato un accesso al server durante l’ultimo periodo di update, sarà il server stesso a
fare l’update (o da se stesso o da un altro in rete) ed in seguito raddoppia il suo periodo di update,
cioè l’update successivo verrà effettuato dopo venti minuti. Questo avviene quattro volte, così se
nessuno accede al server con periodo di update di dieci minuti per lungo tempo, il suo intervallo di
update crescerà fino a centosessanta minuti, quasi tre ore. Se poi qualcuno accede ai dati dal server,
si troverà con una lista vecchia (fino ad un massimo di centosessanta minuti). Accedendo al server,
questo resetterà l’intervallo di update al valore iniziale, per esempio dieci minuti e inizierà
immediatamente l’update se quello precedente è stato effettuato più di dieci minuti prima. Questo
significa che se ci troviamo davanti una lista vecchia, basta ricontrollarla di nuovo alcuni secondi
dopo per ottenere la versione corrente. Questo avrà un effetto veloce per i server, che non effettuano
ping (o nbmlookup), dato che di solito un solo utente vi accede, e avrà un minore effetto per il
server che effettua il ping (o nmblookup), dato che tutti gli altri server della rete accedono a questo
server.
In questo modo è possibile che molti host in una rete utilizzino questo server, ma il carico della rete
rimane basso. Per l’utente non è necessario conoscere se c’è un altro server (ad esempio un server di
nomi, di file o altro) nella rete che utilizza LISa. Può sempre utilizzare LISa localmente e LISa
controllerà se ce n’è un altro, in modo trasparente per l’utente.
Se non si vuole che LISa prenda parte al broadcast, ma che effettui un ping per conto proprio, basta
fargli utilizzare un’altra porta attraverso la riga di comando con l’opzione –port o –p.
Quest’operazione non è in ogni caso raccomandata!
Inviando a LISa il segnale HUP, questo leggerà di nuovo il file di configurazione. Inviando invece
il segnale USR1, stamperà qualche informazione di stato sulla periferica d’output standard (stdout).
90
5.3. Accesso alle informazioni - client
Il primo client di LISa è uno ioslave per KDE2, quindi l’utente può entrare con
lan://localhost/ o lan:/, entrambi i quali contattano LISa sul sistema locale. Se c’è un
server sempre attivo e l’utente è cosciente che anche questa macchina utilizza LISa, può utilizzare il
suo client LISa direttamente con questo server scrivendo sulla barra degli indirizzi del browser:
lan://nome_del_server/. I dati che transitano attraverso il socket hanno un formato
semplice:
"decimal IP address in network byte order\0x20\full hostname\0\n"
e l’ultima linea:
0 succeeded<'\n'>
Ad esempio:
"17302538 some_host.whatever.de
18285834 linux.whatever.de
17827082 nameserver.whatever.de
0 succeeded
"
Questo dovrebbe permettere una facile frammentazione dei dati.
Se nella propria rete ci sono forti regole di sicurezza, alcuni potrebbero considerare il ping come un
potenziale attacco. Se si hanno problemi di questo tipo, è possibile provare una versione più sicura,
resLISa.
5.4. resLISa
Se nella propria rete ci sono strette regole di sicurezza e non si vuole un’altra porta aperta o cose
simili, si può utilizzare resLISa.
Con resLISa si possono effettuare ping verso tutte le reti e range d’indirizzi, si possono assegnare a
resLISa fino a sessantaquattro host attraverso i loro nomi nel suo file di configurazione. Su questi
verranno effettuati dei ping. L’utente sarà ancora in grado di utilizzare nmblookup. resLISa fornirà
anche solo l’informazione su un socket con dominio Unix, ad esempio non sulla rete. Il nome del
socket è /tmp/resLisa-NomeLogin, così resLISa può essere utilizzato tranquillamente da più
utenti su una sola macchina. Dato che non dovrebbe produrre rischi di sicurezza d’alcun tipo, è più
sicuro attivare l’opzione set UID per l’amministratore (root). I privilegi di root verranno rilasciati
subito dopo l’avvio (vedi strictmain.cpp), sono solo necessari per creare un raw socket per inviare
richieste echo ICMP. Non invierà né riceverà alcun broadcast.
Il primo client per questo è anch’esso uno ioslave per KDE2. Per utilizzarlo basta scrive sulla barra
degli indirizzi del browser: rlan:/.
91
5.5. Installazione
Sia resLISa che LISa aprono un così detto raw socket per inviare e ricevere richieste echo ICMP
(pings). Per fare questo hanno bisogno dei privilegi di root.
LISa offre un servizio sulla porta TCP 7741, dovrebbe essere installato dall’amministratore (root) e
avviato insieme al sistema. La configurazione per il boot automatico dei due servizi dipende dalla
distribuzione utilizzata.
Per avviare LISa su Red Hat Linux basta scrivere le seguenti linee sul file
/etc/rc.d/rc.local:
if [ -x /usr/bin/lisa ]; then
echo “Starting LISa daemon…”
/usr/bin/lisa –config=/root/.kde/share/config/lisarc
fi
oppure:
if [ -x /usr/bin/lisa ]; then
echo “Starting LISa daemon…”
/usr/bin/lisa –kde2
fi
In quest’ultimo caso, il file lisarc viene ricercato nelle directory visualizzate dal comando:
kde-config --path config
Quest’ultima soluzione potrebbe essere più rischiosa perché in caso di cambiamento del path, i file
di configurazione non verrebbero più trovati dal programma. Nel nostro caso non c’è alcuna
differenza in quanto il path impostato manualmente è il medesimo impostato dal KDE Control
Center.
Per quanto riguarda resLISa è necessario scrivere nel medesimo file righe simili alle precedenti:
/etc/rc.d/rc.local:
if [ -x /usr/bin/reslisa ]; then
echo “Starting resLISa daemon…”
/usr/bin/reslisa –config=/root/.kde/share/config/reslisarc
fi
oppure:
if [ -x /usr/bin/reslisa ]; then
echo “Starting resLISa daemon…”
/usr/bin/reslisa –kde2
fi
In ogni caso è necessario utilizzare il path corretto.
resLISa deve essere avviato per tutti gli utenti, non offre niente alla rete. Ha bisogno di essere
installato con l’opzione set UID root attiva.
92
Utilizzando rlan-ioslave da KDE2, resLISa può essere avviato automaticamente dal resLISa ioslave
(rlan:/).
LISa legge il file lisarc (/root/.kde/share/config/lisarc), resLISa legge il file reslisarc
(/root/.kde/share/config/reslisarc). Nel caso in cui si voglia configurare entrambi i
file dal KDE Control Center, bisogna avviarli con l’opzione –k o –kde2 dalla riga di comando.
5.6. Configurazione
Un esempio di file di configurazione lisarc, con tutte le opzioni supportate:
PingAddresses = 192.168.100.0/255.255.255.0;192.168.100.10-
192.168.199.19;192.168.200.1;192-192.168-168.100-199.0-9;
PingNames = bb_mail;
AllowedAddresses = 192.168.0.0/255.255.0.0
BroadcastNetwork = 192.168.100.0/255.255.255.0
SearchUsingNmblookup = 1 #also try nmblookup
FirstWait = 30 #30 hundredth seconds
SecondWait = -1 #only one try
#SecondWait = 60 #try twice, and the second time wait 0.6
seconds
UpdatePeriod = 300 #update after 300 secs
DeliverUnnamedHosts = 0 #don't publish hosts without name
MaxPingsAtOnce = 256 #send up to 256 ICMP echo requests at
once
Il nostro file di configurazione lisarc è il seguente ed è stato creato automaticamente dal KDE
Control Panel tramite l’opzione “Configurazione Automatica”:
AllowedAddresses=192.9.200.211/255.255.255.0;
BroadcastNetwork=192.9.200.211/255.255.255.0;
FirstWait=30
MaxPingsAtOnce=256
PingAddresses=
PingNames=
SearchUsingNmblookup=1
SecondWait=-1
UpdatePeriod=300
Per quanto riguarda reslisarc, il nostro file di configurazione creato automaticamente dal
programma di configurazione è il seguente:
AllowedAddresses=192.9.200.211/255.255.255.0;
FirstWait=30
MaxPingsAtOnce=256
PingNames=
SearchUsingNmblookup=0
SecondWait=-1
UpdatePeriod=300
Vediamo una descrizione di tutti i parametri:
PingAddresses
Questo è forse il parametro più importante.
93
Qui si scrivono gli indirizzi sui quali deve essere effettuato il ping. Si possono specificare range
multipli, sono divisi da semicolonne. Ci sono quattro possibili modi di definire gli indirizzi:
indirizzo di rete/maschera di rete: 192.168.100.0/255.255.255.0
un indirizzo IP e la maschera di rete assegnata. L’indirizzo scritto sopra non è reale e quindi
può variare. Ad esempio se si ha 10.0.0.0/255.0.0.0 si potrebbero specificare
10.1.2.0/255.255.255.0 se si è interessati solamente a questi indirizzi. La combinazione fra
indirizzo IP e netmask deve essere divisa da uno slash “/” e l’indirizzo non deve essere
obbligatoriamente un reale indirizzo di rete, potrebbe anche essere l’indirizzo di un host
della rete desiderata, ad esempio 10.12.34.67/255.0.0.0 è lo stesso che 10.0.0.0/255.0.0.0.
range dei seguenti indirizzi IP: 192.168.100.10-192.168.199.19
un primo indirizzo IP da cui inizierà il ping e un secondo indirizzo IP sul quale finirà il ping.
Entrambi gli indirizzi devono essere divisi da un “-“. In questo esempio questo produce 199-
100=99, 99*256=25.344, 25.344+(19-10+1)=25.354 indirizzi.
un indirizzo IP può essere determinato dai suoi quattro numeri decimali, è possibile
specificare dei range per ognuno di questi quattro numeri: 192-192.169-171.100-199.0-9
In questo esempio verranno effettuati ping su tutti gli indirizzi IP con il primo numero 192,
il secondo da 169 a 171, il terzo da 100 a 199 e l’ultimo da 0 a 9. Questo fornirà
1*3*100*10=3000 indirizzi. Questa possibilità è utile solo in rari casi. Qui bisogna inserire
un range per ognuno dei quattro numeri, sempre divisi da un “-“.
indirizzo IP singolo: 192.168.200.1
singolo indirizzo IP o nome dell’host. Questo campo può anche essere lasciato vuoto.
PingNames
Qui si possono specificare ulteriori host su cui effettuare il ping utilizzando i loro nomi. I nomi
devono essere divisi da semicolonne. Questo campo può anche essere lasciato vuoto.
AllowedAddresses
Questo è molto importante. LISa effettua solo ping sugli indirizzi, accetta client risponde ai
broadcast dagli indirizzi corrispondenti a quelli scritti in questo campo. Si possono aggiungere fino
a 32 indirizzi di rete/maschere di rete o singoli indirizzi. Devono essere divisi da “;” e non devono
essere messi spazi vuoti tra gli indirizzi.
Ad esempio: 192.168.0.0/255.255.0.0;192.169.0.0
Sono validi anche una rete completa ed un singolo indirizzo. Di solito l’indirizzo di rete/maschera
di rete è una buona scelta.
94
BroadcastNetwork
Questo parametro contiene esattamente un indirizzo di rete/maschera di rete. Specifica la rete sulla
quale verrà inviato il broadcast. Di solito questo parametro corrisponde al proprio indirizzo di
rete/maschera di rete.
Ad esempio: 192.168.0.0/255.255.0.0
SearchingUsingNmblookup
Si può inserire 0 o 1, il default è 0.
1 significa che LISa eseguirà nmblookup ed elaborerà l’output da questo comando. Questo
produce minor traffico sulla rete rispetto al ping, ma rivelerà solo gli host che hanno un smb service
attivo (macchine Windows od altre macchine che utilizzano samba). nmblookup invierà un
broadcast NetBIOS e le macchine che utilizzano smb risponderanno. Questo non raggiungerà altre
reti. Abilitando questa opzione verranno assegnati anche gli indirizzi IP su cui effettuare il ping,
quindi prima verrà eseguito nmblookup, poi inizierà la fase di ping. Sarà effettuato il ping solo
sugli indirizzi che non sono già stati determinati da nmblookup. Questo dovrebbe diminuire
leggermente il carico della rete.
FirstWait
Se LISa effettua dei ping (ad esempio se invia richieste echo ICMP, invia un mucchio di richieste in
una volta sola e poi attenderà per i centesimi di secondo specificate in questo campo. Di solito
dovrebbero andare bene valori compresi fra 5 e 50, il massimo impostabile è 99 (cioè un’attesa di
0,99 secondi, un periodo piuttosto lungo). Bisogna cercare di impostare un valore più piccolo
possibile per il quale è possibile trovare tutti gli host funzionanti. Il default è 5.
SecondWait
Dopo che LISa ha inviato tutte le richieste echo per la prima volta, è possibile che qualche host non
venga trovato. Per migliorare i risultati, LISa può effettuare il ping per la seconda volta. Questa
volta manderà dei ping solo agli host dai quali non ha ricevuto alcuna risposta.. Se sono stati
ottenuti buoni risultati dopo un solo ping, è possibile disabilitare SecondWait impostando un valore
pari a –1.
Altrimenti potrebbe essere una buona idea impostare un valore di poco più grande di quello del
FirstWait, dato che gli host che non sono stati trovati durante il primo tentativo, sono probabilmente
più lenti o momentaneamente non disponili e quindi potrebbero necessitare di alcuni millisecondi in
più per poter rispondere.
95
Di solito dovrebbero andare bene valori compresi fra 5 e 50 o –1 per disabilitare la seconda
scansione. Il massimo impostabile è 99 (cioè un’attesa di 0,99 secondi, un periodo piuttosto lungo).
Il default è 15.
UpdatePeriod
Questo è un intervallo in secondi dopo il quale LISa effettuerà l’update della sua lista degli host
attivi (ad esempio effettuerà ping o nmblookup o preleverà la lista degli host dal server LISa che sta
già effettuando il ping). I valori validi sono compresi fra 30 secondi e 1800 secondi (mezz’ora). Se
si dispone di una grande rete, è consigliabile impostare un intervallo non troppo piccolo, così da
mantenere basso il carico sulla rete. Impostare valori da 300 a 900 secondi (da 5 a 15 minuti) può
esse una buona scelta. Bisogna tenere in mente che il periodo di update viene raddoppiato se
nessuno accede al server, fino a 4 volte, così l’intervallo diventerà 16 volte più grande del valore
qui impostato e verrà resettato al valore impostato quando qualcuno accede di nuovo al server. Il
valore di default è 300.
DeliverUnnamedHosts
Se è stata ricevuta una risposta ad una richiesta echo da un indirizzo IP, per il quale LISa non può
determinare un nome, questo verrà visualizzato solo se tale valore è impostato a –1. Questo
parametro non sembra essere di una qualche utilità, ma ci possono essere alcune periferiche
all’interno della rete che non hanno un nome assegnato e quindi non devono essere visualizzate.
Bisogna impostare tale valore a 0 se si vogliono mantenere segrete. In caso di dubbio lasciare il
valore 0 impostato di default.
MaxPingsAtOnce
Quando si inviano i ping (richieste echo), LISa invia un mucchio di richieste in una sola volta e poi
attende le risposte. Di default ci sono 256 ping inviati in una sola volta, di solito non c’è alcuna
necessità di cambiare questo valore. Se questo viene impostato troppo grande, i buffer di ricezione
interna per le risposte alle richieste di echo possono diventare troppo piccoli. Se invece viene
impostato un valore troppo piccolo, l’update sarà lento.
5.7. Quattro differenti esempi di file di configurazione:
1. Appartenenza ad una piccola rete con 24 bit di maschera di rete, ad esempio fino a 256 host:
PingAddresses = 192.168.100.0/255.255.255.0
AllowedAddresses = 192.168.100.0/255.255.255.0
BroadcastNetwork = 192.168.100.0/255.255.255.0
96
FirstWait = 20 #20 hundredth
seconds
SecondWait = 30 #30 hundredth
seconds on the seconds try
UpdatePeriod = 300 #update after 300
secs
2. Considerazione dei soli host su cui sono avviati servizi samba senza che ci sia un router
all’interno della rete:
AllowedAddresses = 192.168.100.0/255.255.255.0
BroadcastNetwork = 192.168.100.0/255.255.255.0
SearchUsingNmblookup = 1 #use nmblookup
UpdatePeriod = 300 #update after 300 secs
3. Stessa rete, ma utilizzando sia nmblookup che ping. Viene inoltre controllato l’host con nome
“bb_mail”:
PingAddresses = 192.168.100.0/255.255.255.0
PingNames = bb_mail
AllowedAddresses = 192.168.0.0/255.255.0.0
BroadcastNetwork = 192.168.100.0/255.255.255.0
SearchUsingNmblookup = 1 #also try nmblookup
FirstWait = 30 #30 hundredth seconds
SecondWait = -1 #only one try
UpdatePeriod = 300 #update after 300 secs
MaxPingsAtOnce = 256 #send up to 256 ICMP echo
requests at once
4. Configurazione per resLISa, né PingAddresses né BroadcastNetwork sono utilizzati da resLISa:
PingNames = bb_mail;some_host;some_other_host
AllowedAddresses = 192.168.0.0/255.255.0.0
SearchUsingNmblookup = 1 # use nmblookup
FirstWait = 30 #30 hundredth seconds
SecondWait = -1 #only one try
UpdatePeriod = 300 #update after 300 secs
DeliverUnnamedHosts = 1 #also publish hosts
without name
MaxPingsAtOnce = 256 #send up to 256 ICMP echo
requests at once
5.8. Opzioni e Segnali della riga di comando
Opzioni
Sono supportate le seguenti opzioni della riga di comando:
-v, --version
stampa una breve informazione sulla versione.
-h, --help
fornisce una aiuto sulla linea di comando.
97
-p, --port PORTNR
inizializza il server sul numero di porta specificato (PORTNR) invece che sulla porta di
default 7741. Utilizzando questa opzione, LISa non sarà capace di cooperare con altri LISa
sulla rete. E’ disponibile solo per LISa ma non per resLISa.
Alcune opzioni che riguardano l’ordine di ricerca per i file di configurazione. Per resLISa il file si
chiama reslisarc anziché lisarc.
-u, -unix
ricerca prima nella directory $HOME/.lisarc, poi /etc/lisarc, questo per default
-k, --kde1
ricerca prima nella directory $HOME/.kde/share/config/lisarc, poi
$KDEDIR/share/config/lisarc
-K, --kde2
ricerca il file lisarc in ogni directory fornita dal comando kde-config –path config
-c, --config=/SOME/PATH/FILE
legge il file nel percorso specificato
Segnali
Inviando il segnale di Hangup al LISa od al resLISa, questi rileggeranno il loro file di
configurazione. La riga di comando è la seguente:
killall –HUP lisa
Inviando il segnale User1 al LISa od al resLISa, verranno stampate delle informazioni di stato
sull’output standard:
killall –USR1 lisa
Non verrà visualizzato alcun messaggio se la console da cui erano stati lanciati LISa o resLISa è
terminata.
98
6. X-WIN32 v.5.5.2
La Versione 5.5.2 di X-Win32 è la più recente applicazione X terminal di StarNet per i computer
Windows, che includono Windows 95, 98, ME, NT 4.0 e Windows 2000. X-Win32 consente agli
utenti di Windows di connettersi ai server Linux/Unix su una rete locale o tramite Internet.
Le applicazioni X che vengono eseguite su questi server vengono visualizzate sul desktop di
Windows. Le applicazioni X possono essere eseguite facilmente insieme alle applicazioni Windows
e si possono effettuare operazioni di copia-incolla di dati tra applicazioni X e applicazioni
Windows. Grazie all'opzione di connessione XDMCP, è possibile importare un intero desktop Unix
o Linux, come ad esempio CDE, KDE o Gnome, e convertire efficacemente Windows PC in una
potente stazione di lavoro Unix o Linux.
Con X-Win32 possono essere eseguite sul desktop Windows molteplici applicazioni X
99
6.1. Nuove Caratteristiche
Le nuove caratteristiche includono per esempio:
X-Config, un'interfaccia amichevole basata su pulsanti selezionabili da tastiera per
configurare Windows PC, per impostare le sessioni che connettono ad un server Unix/Linux.
Windows Terminal Server Support che permette agli amministratori del sistema di
impostare X-Win32 su un server terminale per consentire ai terminali Windows, perfino ai
terminali client leggeri privi di unità disco, di connettersi a un server Linux o Unix.
Un SSH Connect Module, primo nel settore, che permette di impostare sessioni basate su
SSH quando il software client SSH “SSH per Windows” di F-Secure viene installato sul PC.
Sessioni Multiple XDMCP, che consentono agli utenti di connettersi a molteplici server
Linux/Unix e di selezionare e accedere dal desktop ai differenti server.
Una Sessione Guidata sviluppata per i nuovi utenti al fine di semplificare la configurazione
delle sessioni che connettono a un server Linux o Unix.
Individual User Settings Support su Windows NT e 2000.
Multiple Monitor Support per Windows 98 e per Windows 2000.
Le finestre di dialogo a comparsa presentano ora un bottone di aiuto amichevole che
rimanda alle pagine corrispondenti nell'Help system.
Sono ora supportate schede di rete multiple per gli utenti che usano più di una scheda di rete
nei loro Windows PC.
La funzionalità per l'editing della tastiera, che consente agli utenti di personalizzare le
proprie tastiere, è stata ridisegnata per essere più versatile e semplice da usare.
6.2. X-Win32 + SSH
X-Win32 è l'unico X server per PC disponibile con un'opzione incorporata di connessione SSH che
cripta automaticamente i dati trasmessi tra il PC e il server.
SSH Connect Module è stato sviluppato in collaborazione con F-Secure, un importante sviluppatore
di soluzioni a gestione centralizzata per la sicurezza delle imprese. Il modulo di connessione
funziona con SSH di F-Secure per Windows Versione 4.3. Acquistando il prodotto X-Win32 + SSH
sono inclusi sia l'X server per PC X-Win32 5.1.1, sia il client F-Secure SSH 4.3.
6.3. Lingue
X-Win32 è attualmente disponibile in Inglese e Tedesco. Una versione Francese è in fase di
realizzazione e saranno prese in considerazione versioni in altre lingue.
100
6.4. Altre importanti caratteristiche
Sia X-Win32 sia X-Win32 + SSH offrono le seguenti importanti caratteristiche aggiuntive:
Supporto LBX
Help System avanzato e interattivo
Hide Windows tiene in ordine il desktop e la barra delle applicazioni mettendo le finestre
delle applicazioni X in "stand-by".
Last Session Terminate chiude automaticamente X-Win32 quando l'utente finisce di usarlo.
Mouse Wheel Support
Use/Send Xauth è una funzionalità per la sicurezza, consistente nell'invio di dati di X
authorization attraverso una connessione rsh o rexec.
Auto Restart riavvia automaticamente l'ultima sessione XDMCP dopo aver chiuso la
connessione X.
6.5. Filosofia del Prodotto
X-Win32 è stato progettato per essere un X server estremamente mirato, veloce, facile da usare e
conveniente. Funzioni periferiche come condivisione dei file, FTP e Telnet non fanno parte del
programma. Questi programmi si possono ottenere gratuitamente da Internet o presso altri editori a
prezzi molto competitivi. In molti casi, l'utente finale non richiede queste funzioni o ha già accesso
ad esse.
Aggiungere funzioni periferiche renderebbe X-Win32 inutilmente pesante, difficile da usare, e più
costoso. La sua semplicità e la sua elevata prestazione rappresentano la ragione fondamentale per la
quale 1,5 milioni di utenti Windows nel mondo stanno utilizzando X-Win32. X-Win32 si installa
velocemente e si avvia quasi all'istante.
Una copia di valutazione di X-Win32, pienamente funzionante, è disponibile al download sul sito
http://www.starnet.com. Quando si scarica X-Win32 per la prima volta, il produttore invia in
automatico via e-mail una chiave di licenza valida per 45 giorni in modo da poter valutare il
prodotto senza la limitazione di due ore di tempo o senza dover sopportare i messaggi di avviso
della versione demo.
6.6. Font aggiuntivi
Per utilizzare X-Win32 con certe applicazioni X, potrebbero essere necessari font aggiuntivi.
Bisogna controllare la serie di font, che è possibile scaricare dalla Pagina Download.
101
6.7. Configurazione di X-Win32
I requisiti richiesti dal sistema per installare X-Win32 sono:
Microsoft Windows 95, 98, ME, NT, 2000
TCP/IP
Disk space: A minimum of 8 MB free
Ci sono tre possibili modi per far partire l’X client X-Win32 su una macchina remota: rsh, rexec e
XDMCP. Sia rsh (remote shell) che rexec (remote execution) permettono la connessione ad una
macchina remota (sul quale si trova un sistema operativo Unix) ed eseguono un comando su quella
macchina, di solito un’applicazione X. XDMCP (X Display Manager Control Protocol) permette
una connessione ai processi xdm o CDE sulla macchina remota per effettuare una sessione di login.
In X-Win32 si utilizza una sessione per mantenere informazioni su rsh, rexec e XDMCP. Le
sessioni vengono create con l’utility X-Config e richiamate dal menu Sessions di X-Win32.
Sotto sono riportati alcuni esempi di sessione:
rsh
Connect mode: rsh
Login: jsmith
Command: /usr/bin/X11/xterm -ls -display $DISPLAY
XDMCP
Connect mode: XDMCP
Host name: sun1.StarNet.com
XDMCP mode: Query
rexec
Connect mode: rexec
Login: jsmith
Command: xterm -ls -display 184.237.104.23:0 (IP address of PC)
Le applicazioni rsh e rexec permettono di richiedere che un file di comandi o un programma
eseguibile siano eseguiti su un elaboratore remoto invece che sull'elaboratore locale.
Poiché è un sistema client/server, il sistema X Windows ha importanti differenze se comparato con
altri software client/server del tipo mail o HTTP. Un utente alle prime armi potrebbe rimanere
confuso dal fatto che le applicazioni X (come xterm e mailtool) sono client, mentre un X display
(come X-Win32) è un server. Questo significa che quando si avvia X-Win32, si avvia un X server
che deve attendere che i client si connettano ad esso.
102
Di solito un utente si connette ad un client (tipicamente una macchina Unix) che è chiamata host
remoto. Tutti i comandi o programmi che vengono eseguiti sull’host remoto sono un’applicazione X
(per esempio xterm, xclock, netscape, ecc.)
La prima richiesta X Window fatta da un programma è una connessione DISPLAY
dall’applicazione X al server X (X-Win32) avviata sul pc dell’utente.
Quando si utilizzano connessioni del tipo rsh o rexec, è necessario un comando che dica a X di
utilizzare la variabile $DISPLAY per segnalare dove deve essere visualizzata la connessione
remota. La variabile $DISPLAY contiene il nome del pc sul quale sta girando X-Win32 seguito da
due punti e dal numero del display “:0” (NomePC:0 : $DISPLAY). Se l’host remoto riporta che il
nome nella variabile $DISPLAY non è valido, può essere usata la dicitura $MYIP:$DNUM. E’
necessario che sul server Linux siano avviati i servizi rsh e rexec.
Nel nostro caso abbiamo scelto di creare una sessione rexec.
Una connessione rexec invia un comando per inizializzare un’applicazione X. Il comando viene
inviato quando l’host remoto ha riconosciuto il nome dell’host, il nome di login e il comando.
Per creare la connessione:
1. Avviare l’utility X-Config.
2. Cliccare sulla scheda Session.
3. Premere il bottone Add
4. Scegliere “rexec” come metodo di connessione nella finestra di dialogo Metodo di
Connessione.
5. Nella nuova finestra di dialogo Session, inserire il nome della sessione.
6. Inserire il nome dell’host. L’host name è il nome o l’indirizzo IP dell’host remoto a cui
ci si vuole connettere (ad esempio Linux01 oppure 192.9.200.211).
7. (Opzionale) Inserire un login. Questo è il nome che è stato assegnato per accedere
all’host remoto. Se non è stato inserito, viene comunque richiesto una volta aperta la
sessione. Il login deve essere presente sulla macchina Linux a cui si accede e non può
essere quello di root.
8. Inserire un comando. Come riferimento si può utilizzare il comando già impostato per
default.
9. (Opzionale) Inserire la propria password. Se nessuna password è stata inserita, viene
comunque richiesta una volta aperta la sessione (non può essere inserita la password di
root).
10. Cliccare sul pulsante Save.
103
Una volta avviato X-Win32, compare una finestra con la shell. A questo punto digitare startkde
per far partire Linux con l’interfaccia grafica KDE.
Per avviare una connessione come root è necessario scrivere su prima di digitare startkde. Sarà
richiesto di inserire la password di root. Aprendo una shell dopo l’avvio dell’interfaccia grafica sarà
quindi visualizzato il prompt: [root@my_computer root]#. Nel caso in cui l’utente diventi
superuser dopo l’avvio dell’interfaccia grafica sarà invece visualizzato il prompt
[root@my_computer nome_utente]#. Nel primo caso l’utente entra effettivamente come
se root, mentre nel secondo l’utente può utilizzare i privilegi di root nella shell, ma è possibile che
per altre applicazioni sia comunque negato l’accesso.
104
7. Web Server Linux
Non ci sono dubbi sul fatto che se esiste un oggetto responsabile di ciò che internet è oggi questo è
il browser Web. Per la maggior parte delle persone, la parola “Internet” è sinonimo di quello che è
in effetti il World Wide Web o i suoi browser. E’ ovvio che i browser sarebbero inutili senza i Web
server.
7.1. Quale Web Server scegliere: Apache, NCSA o Netscape
Di solito requisiti diversi portano alla scelta di prodotti differenti, ma in questo caso la scelta è quasi
sempre la stessa: Apache.
Il server NCSA è il più vecchio dei tre, non viene più sviluppato e non contiene funzionalità
importanti che non siano offerte anche da Apache, quindi ci sono ben pochi motivi per utilizzarlo.
Netscape fornisce una varietà di Web server commerciali per un assortimento di piattaforme. La
versione minima dei suoi web server, FastTrack, è stato adattato a Linux, ma ci vuole tutta per
trovarlo. I server Netscape forniscono facili funzionalità d’installazione e configurazione basate su
HTML. Esistono strumenti di configurazione basati sui GUI anche per Apache, ma non sono facili
da utilizzare quanto quelli di Netscape.
Secondo un’indagine Apache è da molto tempo il Web server più diffuso su internet (oltre la metà
dei Web server ospitano Apache). Un tale risultato si spiega in parte con la grande popolarità di cui
Apache gode praticamente da sempre presso le società di Web hosting e gli Isp (Internet Service
Provider). Apache gira su un’ampia varietà di piattaforme: è disponibile sia come eseguibile binario
precompilato per Windows, Mac OS X e molte varianti di Unix, sia in forma di codice sorgente per
chi volesse adattarlo per l’uso su altre piattaforme. Il progetto modulare di questo server significa
che è facile dotarlo di nuove funzionalità senza dover intervenire in profondità sul nocciolo del
prodotto.
E’ possibile scaricare la versione base del server Apache dal sito www.apache.org, ma il corredo
funzionale di questa release è piuttosto limitato. Chi ha bisogno di moduli di espansione come l’Ssl
dovrà ricercare gli opportuni moduli di espansione, che variano anche di molto in quanto a maturità
e raffinatezza, oppure acquistare una versione commerciale di Apache come Stronghold Secure
Web Server 3 di Red Hat (www.redhat.it). Un vantaggio del progetto modulare di Apache è che
rende possibile espanderlo solo con i componenti strettamente necessari, rendendo il server meno
complesso e quindi più affidabile, sicuro e gestibile. Un ulteriore vantaggio deriva dal fatto che è
105
possibile scegliere da un vasto assortimento di moduli prodotti sia dalla comunità open-source sia
da società commerciali: esistono plug-in praticamente per tutto quello che può servire,
dall’abilitazione delle estensioni FrontPage fino all’esecuzione di sofisticati reindirizzamenti basati
su regole e, naturalmente, è anche possibile espandere Apache con moduli personalizzati scritti ad
hoc.
I server Web, in ogni caso, sono quasi sempre espandibili tramite componenti di terze parti; noi
abbiamo utilizzato la versione base fornita nel pacchetto di Red Hat. Nonostante il suo retaggio e la
crescente abbondanza di moduli di espansione, Apache inizia a mostrare la sua età. Questo server è
rimasto essenzialmente statico, mentre gli altri prodotti guadagnavano in termini sia di funzioni sia
di prestazioni.
La configurazione richiede la modifica a mano delle direttive presenti in una serie di file di testo. Si
tratta di un approccio che può essere apprezzato dagli amministratori che preferiscono intervenire
tramite programma (tipicamente con un linguaggio di scripting), ma non è certo molto comodo per
chi invece è abituato ad usare un’interfaccia grafica o basata su browser. Abbiamo comunque
potuto constatare che le varie impostazioni sono ben documentate, e che lo svolgimento di attività
quali l’impostazione di un nuovo server virtuale, la modifica delle restrizioni sull’accesso in base
all’indirizzo IP del client e l’aggiunta di tipi Mime è molto lineare. In ogni caso per la
configurazione di Apache esistono plug-in ad interfaccia grafica, come Comanche. Questo server
non supporta però la configurazione dinamica, quindi una modifica alle impostazioni richiede il
riavvio manuale.
Nella versione base di Apache le opzioni per la sicurezza è l’autenticazione sono piuttosto limitate.
L’autenticazione utente e il controllo dell’accesso sono gestiti principalmente tramite il file
htaccess (/usr/share/doc/mrtg-2.9.6/contrib/servers/htaccess); il
supporto di Ldap è disponibile soltanto per mezzo di un modulo di espansione e non è prevista la
capacità di effettuare transazioni sicure.
Ancora, la versione base del server non offre funzioni quali il throttling della banda passante, la
rotazione dinamica dei log, la suddivisione dei server virtuali in classi e il clustering, tutte
prerogative molto apprezzate dalle aziende più grandi e dai siti di hosting.
Come piattaforma di sviluppo, Apache gestisce direttamente gli script Cgi ed i comandi server-side
include (commenti Html che indicano al server di generare dinamicamente dei dati per la pagina
Web). Tramite plug-in è poi disponibile il supporto del Perl, di Php, di Asp (in emulazione) e di
altri linguaggi di scripting e di generazione di pagine. Anche il supporto di Nsapi e servlet java può
essere ottenuto con un plug-in.
106
A livello di prestazioni Apache si comporta leggermente meglio sotto Linux nei test basati sulla
fornitura di pagine statiche.
Apache 2.0, attualmente in fase di test (non è stata ancora fissata la data di rilascio) si appoggerà ad
un nuovo strato di run time che, secondo gli sviluppatori, tra l’altro permetterà di migliorare sia le
prestazioni sia l’affidabilità del server in ambiente Windows. In attesa della nuova versione, Apache
1.3 rimane la scelta valida per chi vuole un server Web gratuito sotto Unix, in particolare per i
creatori di siti Web che intendono sfruttare la sua espansibilità modulare.
La via verso il Web che abbiamo scelto è quella open source:
Sistema operativo: Linux
Server Web: Apache
Api: Cgi
Standard per le pagine dinamiche: Php
Linguaggio di programmazione: Perl, Pike, Python
Modello a componenti: Corba
Server applicativo: Jboss, Tomcat, Zope
Connettore ai database: Odbc
Gestore di database: MySQL, Postgres
Apache è gratuito, estremamente potente ed estensibile e viene fornito praticamente con tutte le
versioni di Linux.
7.2. Installazione del Web Server
La maggior parte delle installazioni offre la possibilità di installare il Web server Apache nel corso
dell’installazione. Nelle distribuzioni che utilizzano RPM è possibile controllare se Apache è
installato o meno digitando il seguente comando:
# rpm –q apache
Se Apache non è installato probabilmente basta installare il pacchetto rpm che si può trovare sul
CD-ROM oppure basta scaricarlo da internet.
7.3. Configurazione
Secondo quale versione viene installata, si dispone di uno o tre file di configurazione che si possono
modificare. I file si trovano nella directory /etc/httpd/conf/.
Le versioni più vecchie di Apache utilizzano tre file di configurazione separati, httpd.conf per
la configurazione dei demoni del Web server, access.conf per il controllo dell’accesso, e delle
107
directory e srm.conf per la configurazione delle risorse. Per evitare confusione, questi tre file
sono stati combinati tutti in httpd.conf.
Anche se Apache è fornito senza nessuno strumento di configurazione con interfaccia grafica,
esistono prodotti di terze parti per la sua gestione. Il pacchetto linuxconf può fornire alcune
funzionalità, come anche il progetto Comanche. Il pacchetto comanche-0.6a-1.noarch.rpm
può essere scaricato direttamente dal sito di Red Hat.
Se non si vogliono modificare manualmente i file di configurazione, è possibile utilizzare un
programma grafico come Comanche.
Come tutte le utility grafiche di Linux, non si riesce ad avere un completo controllo delle modifiche
apportate ai file di configurazione da parte di questi programmi. In caso di modifiche indesiderate
risulta difficile ritornare alla configurazione precedente.
108
7.4. Ottimizzazione del Web Server
Ci sono molte piccole cose che è possibile fare per ottenere maggiori prestazioni dal Web server,
incluso l’aumento o la diminuzione della quantità di processi in esecuzione, il frequente controllo
dei log file, il cambiamento dei permessi e così via.
Il web server Apache mantiene un log di tutti gli accessi al sito Web. Gli host che vi si collegano
sono identificati soltanto tramite il loro indirizzo IP, quindi anche Apache deve effettuare una
ricerca inversa dei DNS per trovare l’hostname, un processo che può richiedere da un secondo a
molti secondi, tempo durante il quale l’host remoto deve attendere con il risultato che l’accesso al
nostro sito appare lento. La cosa peggiore è che di solito la ricerca dei DNS è un’operazione di
blocco e questo significa che altri processi httpd possono essere costretti ad attendere, cosa che
può rallentare il sistema in maniera incredibile. Questo problema non è per noi molto rilevante in
quanto gli accessi in ambito aziendale risultano molto ridotti. E’ preferibile in ogni caso lasciare
disattivata la risoluzione degli hostname. Se si vuole comunque ricercare un hostname, basta
utilizzare il programma nslookup. Per disattivare la ricerca degli hostname è necessario accertarsi
che la direttiva Hostnamelookups sia impostata ad off nel file httpd.conf.
Apache tenta di mantenere un server pool, pronto a rispondere a molti accessi simultanei, e lo fa
attraverso il controllo di quanti processi httpd stanno aspettando richieste e dell’aumento e della
diminuzione delle dimensioni di pool, a seconda del carico e delle impostazioni di configurazione
predeterminate nel file httpd.conf. Le seguenti sono direttive che dovrebbero essere impostate:
StartServers 10
MinSpareServers 10
MaxSpareServers 20
StartServers determina quanti processi Apache eseguirà non appena sarà avviato. Controllerà
periodicamente quanti di questi processi sono impegnati e si accerterà che il numero di quelli di
riserva sia almeno pari a quello definito in MaxSpareServers e non superi quello definito in
MaxSpareServers.
Apache contiene un gestore predefinito che permette di visualizzare ondine lo stato del server.
Bisogna aggiungere (o decommentare) la seguente sezione nel file access.conf:
#<Location /server-status>
#SetHandler server-status
#Order deny,allow
#Deny from all
#Allow from your_domain.com
#</Location>
109
Questo permette di accedere all’URL http://NomeServerLinux/server-status tramite un server
appartenente al domino your_domain.com e di ottenere informazioni in merito al Web server
attualmente in esecuzione. Queste informazioni includono la versione di Apache, l’ora e la data in
cui il server è stato avviato, il traffico totale, lo stato del processo httpd ed altro ancora.
7.5. Apache Server Status
La pagina visualizzata è del tipo:
Apache Server Status for _default_
Server Version: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b DAV/1.0.2
PHP/4.0.6 mod_perl/1.24_01
Server Built: Sep 5 2001 23:12:29
Current Time: lunedì, 08-apr-2002 16:19:03 CEST
Restart Time: lunedì, 08-apr-2002 16:18:59 CEST
Parent Server Generation: 0
Server uptime: 4 seconds
1 requests currently being processed, 7 idle servers W_______........................................................
................................................................
................................................................
................................................................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"L" Logging, "G" Gracefully finishing, "." Open slot with no current process
PID Key:
3798 in state: W , 3799 in state: _ , 3800 in state: _
3801 in state: _ , 3802 in state: _ , 3803 in state: _
3804 in state: _ , 3805 in state: _ ,
To obtain a full report with current status information you need to use the ExtendedStatus On
directive.
Apache/1.3.20 Server at _default_ Port 80
E’ possibile determinare quanti accessi il nostro Web server sta ricevendo digitando quanto segue:
# tail –f /var/log/httpd/access_log
E’ possibile visualizzare gli errori che si sono verificati digitando quanto segue:
# tail –f /var/log/httpd/error_log
110
Questo comando visualizza le ultime 10 righe del log file e continua ad aggiungerne finché non
viene interrotto. La velocità con cui il Web server scrive sul suo log file indica la quantità d’accessi
che sta ricevendo.
Per visualizzare la lista completa degli accessi e degli errori basta aprire i rispettivi file con un
editor di testo.
7.6. La Sicurezza del Web Server
Anche chi non ha la responsabilità di proteggere una montagna di dati aziendali riservati, ma si
ritrova solo sporadicamente a vestire i panni dell’amministratore di un sito Web, non può fare a
meno di interessarsi delle problematiche di sicurezza. Gli errori di programmazione che possono dar
luogo ad una falla di sicurezza sono di fatto inevitabili in qualunque programma complesso,
compresi i server Web. Proteggere i dati e le risorse aziendali da intrusioni, sguardi indiscreti ed
utilizzi non autorizzati è un problema non solo di prodotti ma anche di persone e di processi.
Esistono alcune misure di base che dovrebbero essere considerate essenziali da chiunque operi un
server Web.
1. Disabilitare i servizi non necessari. Se non c’è bisogno del server FTP (File Transfer
Protocol) fornito a corredo del server Web, è necessario assicurarsi che non sia in
esecuzione, evitare di installarlo o disinstallarlo nel caso sia stato automaticamente
installato. In questo modo si evita di fornire ai potenziali attaccanti un altro bersaglio che
può rivelarsi ancora più facile di quello principale. Similmente, disabilitare i linguaggi di
scripting e gli script d’esempio a meno che non siano assolutamente necessari.
2. Mantenersi aggiornati sui problemi di sicurezza. La prima cosa da fare è abbonarsi al
servizio di notifica di chi produce il server Web. Non sempre però le comunicazioni sono
tempestive: una risorsa indispensabile da usare in parallelo è la mailing list Bugtraq,
mantenuta da SecurityFocus (www.securityfocus.com). Un’altra fonte utile d’informazioni
sono i bollettini del Cert (Computer Emergency Response Team), consultabili all’indirizzo
www.cert.org/advisories/. E’ essenziale tenere sott’occhio non solo gli allarmi e le patch
relativi al server Web ma anche quelli per il sistema operativo sul quale gira.
3. Usare politiche sensate per le password. Evitare di impostare parole chiave troppo
semplici e quindi facili da indovinare, in particolare per gli account degli amministratori, ma
non definire nemmeno regole talmente complicate da costringere gli utenti ad annotarsi le
password nell’impossibilità di mandarle a memoria. Modificare sempre le password di
default ed eliminare gli account non necessari (come guest). Assicurarsi che le password
siano effettivamente abilitate per aree sensibili e le funzioni d’amministrazione.
111
4. Tenere sotto controllo cosa accade sulla propria rete. Molti server Web sono gratuiti e
facili da installare, ma possono creare una falla di sicurezza. Bisogna dunque fare attenzione
al software che installano gli utenti della Lan.
5. Sfruttare il sistema d’autorizzazioni del sistema operativo. Di solito il server Web lavora
con i permessi di un utente specifico. E’ necessario assicurarsi quindi che i diritti d’accesso
di un certo utente siano opportunamente limitati.
6. Monitorare i log. Il server Web tiene traccia di tutte le richieste che gli pervengono: cercare
periodicamente nei log eventuali indizi d’attività anomale.
7. Separare i dati pubblici da quelli privati. Non memorizzare i dati riservati su sistemi usati
anche come server Web, a meno che non sia assolutamente necessario. Per un’extranet, si
potrebbe prendere in considerazione l’idea di adottare un server Web posto esternamente al
firewall in modo da non mettere a rischio i dati aziendali dietro al firewall.
8. Prestare molta attenzione alla configurazione del server. Mettere i file eseguibili
all’interno di directory specifiche e fare in modo che non sia possibile scaricarne il codice
sorgente. Disattivare funzionalità quali l’indicizzazione automatica delle directory e il
supporto di WebDAV, se non se ne ha davvero bisogno. Procurarsi e mettere in funzione
tutti i tool di sicurezza messi a disposizione dal produttore del server Web o dal sistema
operativo.
9. Controllare le falle di sicurezza dei programmi. Gli script Cgi sui server Web sono
spesso soggetti a violazioni di sicurezza, in particolare se non convalidano i parametri forniti
dall’utente prima di accedere ai file o ai servizi del sistema operativo.
7.7. Hosting virtuale
L’hosting virtuale permette di ospitare più siti Web sulla stessa macchina e questa di solito è una
soluzione migliore che non procurarsi una nuova macchina dedicata per ogni sito Web che si
intende ospitare. Questo significa naturalmente che tutti i siti Web condivideranno le risorse, quindi
può darsi che questa soluzione non sia appropriata in tutti i casi. Ci sono due metodi per l’hosting
virtuale: basato su indirizzo IP e basato sul nome.
7.7.1. Hosting basato su indirizzo IP
Questo è il metodo più affidabile perché non richiede nessuna caratteristica speciale sul lato
browser e richiede soltanto che la macchina abbia un indirizzo IP separato per ciascun sito Web che
si intende ospitare. E’ possibile fare ciò installando schede di rete aggiuntive o utilizzando l’IP
aliasing.
112
Supponiamo che una certa macchina abbia due indirizzi IP: 192.168.0.1 che risolve come
www.domain1.com e 192.168.0.2 che risolve come www.domain2.com. Ci sono due metodi per
impostare host virtuali su IP: daemon multipli o daemon singoli.
DAEMON MULTIPLI
Anche se impostare i file di configurazione per questo metodo è molto più semplice, esso richiede
un’installazione completamente separata di Apache per ciascun host virtuale. Questo significa che
bisogna installare dal pacchetto di codice sorgente perché è necessario modificare alcune delle
directory predefinite. Inoltre bisogna aggiungere la direttiva Listen al file httpd.conf. Per
esempio, il file httpd.conf, per www.domain1.com conterrà la riga:
Listen 192.168.0.1:80
DAEMON SINGOLI
Questo metodo richiede una sola installazione di Apache ma esige una maggiore configurazione del
file httpd.conf. La direttiva VirtualHost viene utilizzata per definire i valori di ognuno degli
host virtuali. E’ possibile impostare diverse directory document root, amministratori di server e log
file per ciascun host. Quanto segue è un esempio della sezione del file httpd.conf richiesta per
impostare i due host virtuali www.domain1.com e www.domain2.com:
<VirtualHost 192.168.0.1>
ServerAdmin [email protected]
DocumentRoot /usr/local/web/domain1
ServerName www.domain1.com
ErrorLog logs/domain1_error_log
TransferLog logs/domain1_access_log
</VirtualHost>
<VirtualHost 192.168.0.2>
ServerAdmin [email protected]
DocumentRoot /usr/local/web/domain2
ServerName www.domain2.com
ErrorLog logs/domain2_error_log
TransferLog logs/domain2_access_log
</VirtualHost>
7.7.2. Hosting virtuale basato su nome
Per quanto più affidabile, l’hosting virtuale basato su IP può non essere sempre disponibile. Per
esempio può darsi che non siano immediatamente disponibili nuovi indirizzi IP. Il protocollo
HTTP/1.1 supporta metodi che permettono al server di sapere quale indirizzo il browser stia
richiedendo, rendendo possibile a più server la condivisione di un indirizzo IP.
L’impostazione dell’hosting virtuale basato su nome è molto simile a quella dell’hosting virtuale
basato su IP a daemon singolo. La maggiore differenza consiste nel fatto che bisogna utilizzare la
113
direttiva NameVirtualHost nel file httpd.conf. Anche con questo metodo è possibile
specificare diverse directory document root, amministratori di server e log file.
Quanto segue è un esempio della sezione del file httpd.conf necessaria per impostare host
virtuali basati sul nome. Consideriamo che www.domain1.com e www.domain2.com vengano
risolti in 192.168.0.1 e 192.168.0.2.
NameVirtualHost 192.168.0.1
<VirtualHost 192.168.0.1>
ServerAdmin [email protected]
DocumentRoot /usr/local/web/domain1
ServerName www.domain1.com
ErrorLog logs/domain1_error_log
TransferLog logs/domain1_access_log
</VirtualHost>
<VirtualHost 192.168.0.2>
ServerAdmin [email protected]
DocumentRoot /usr/local/web/domain2
ServerName www.domain2.com
ErrorLog logs/domain2_error_log
TransferLog logs/domain2_access_log
</VirtualHost>
7.7.3. Hosting virtuale basato sulla porta
Nel nostro caso abbiamo sfruttato la possibilità di utilizzare porte differenti per siti web diversi. La
nostra macchina ha un solo indirizzo IP che, sulla nostra rete viene risolto con il nome
linux01.grupposervizi.it. Immettendo il numero della porta dopo il nome si accede al
sito web assegnato a quella data porta. Questa opzione è comoda nel caso in cui non si abbia la
possibilità di avere un altro indirizzo IP od un alias per il nostro server. E’ necessario andare a
modificare il file /etc/httpd/conf/httpd.conf aggiungendo, attraverso il comando
listen, le porte sulle quali il server web dovrà restare in ascolto. Bisogna poi specificare gli host
virtuali assegnando loro il numero di porta desiderato. Ogni host virtuale va poi configurato
specificando la directory nella quale vanno cercati i file e la sequenza di ricerca. Ad ogni directory
utilizzata dal server Web è possibile impostare alcuni permessi. Il file httpd.conf conterrà
quindi delle linee simili alle seguenti:
...
Listen 80
Listen 8080
ServerName www.domain.tld
DocumentRoot /www/domain
114
<VirtualHost 111.22.33.44:8080>
DocumentRoot /www/domain2
...
</VirtualHost>
...
7.7.4. File httpd.conf
Riportiamo di seguito il file httpd.conf modificato per utilizzare la porta 80 e la 8080 in modo da
accedere a due siti web differenti:
## httpd.conf - configuration for the Apache web server
#
# Generated automatically... if you edit manually, the changes will be lost
# the next time you run "apacheconfig".
#
# What we listen to
#
ServerType StandAlone
ServerRoot /etc/httpd/
# We don't handle this yet...
#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Please read the file README.DSO in the Apache 1.3 distribution for more
# details about the DSO mechanism and run `httpd -l' for the list of already
# built-in (statically linked and thus always available) modules in your httpd
# binary.
#
# Note: The order is which modules are loaded is important. Don't change
# the order below without expert advice.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#LoadModule mmap_static_module modules/mod_mmap_static.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule env_module modules/mod_env.so
LoadModule config_log_module modules/mod_log_config.so
LoadModule agent_log_module modules/mod_log_agent.so
LoadModule referer_log_module modules/mod_log_referer.so
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule mime_module modules/mod_mime.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule status_module modules/mod_status.so
LoadModule info_module modules/mod_info.so
LoadModule includes_module modules/mod_include.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule asis_module modules/mod_asis.so
LoadModule imap_module modules/mod_imap.so
LoadModule action_module modules/mod_actions.so
#LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
115
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule anon_auth_module modules/mod_auth_anon.so
LoadModule db_auth_module modules/mod_auth_db.so
#LoadModule digest_module modules/mod_digest.so
#LoadModule proxy_module modules/libproxy.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule example_module modules/mod_example.so
#LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule bandwidth_module modules/mod_bandwidth.so
#LoadModule put_module modules/mod_put.so
<IfDefine HAVE_PERL>
LoadModule perl_module modules/libperl.so
</IfDefine>
<IfDefine HAVE_PHP>
LoadModule php_module modules/mod_php.so
</IfDefine>
<IfDefine HAVE_PHP3>
LoadModule php3_module modules/libphp3.so
</IfDefine>
<IfDefine HAVE_PHP4>
LoadModule php4_module modules/libphp4.so
</IfDefine>
<IfDefine HAVE_DAV>
LoadModule dav_module modules/libdav.so
</IfDefine>
<IfDefine HAVE_ROAMING>
LoadModule roaming_module modules/mod_roaming.so
</IfDefine>
<IfDefine HAVE_SSL>
LoadModule ssl_module modules/libssl.so
</IfDefine>
# Reconstruction of the complete module list from all available modules
# (static and shared ones) to achieve correct module execution order.
# [WHENEVER YOU CHANGE THE LOADMODULE SECTION ABOVE UPDATE THIS, TOO]
ClearModuleList
#AddModule mod_mmap_static.c
AddModule mod_vhost_alias.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_log_agent.c
AddModule mod_log_referer.c
#AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
#AddModule mod_speling.c
AddModule mod_userdir.c
116
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_auth_anon.c
AddModule mod_auth_db.c
#AddModule mod_digest.c
#AddModule mod_proxy.c
#AddModule mod_cern_meta.c
AddModule mod_expires.c
AddModule mod_headers.c
#AddModule mod_usertrack.c
#AddModule mod_example.c
#AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c
#AddModule mod_bandwidth.c
#AddModule mod_put.c
<IfDefine HAVE_PERL>
AddModule mod_perl.c
</IfDefine>
<IfDefine HAVE_PHP>
AddModule mod_php.c
</IfDefine>
<IfDefine HAVE_PHP3>
AddModule mod_php3.c
</IfDefine>
<IfDefine HAVE_PHP4>
AddModule mod_php4.c
</IfDefine>
<IfDefine HAVE_DAV>
AddModule mod_dav.c
</IfDefine>
<IfDefine HAVE_ROAMING>
AddModule mod_roaming.c
</IfDefine>
<IfDefine HAVE_SSL>
AddModule mod_ssl.c
</IfDefine>
ServerName linux01
ServerAdmin root@localhost
Listen 80
Listen 8080
Port 80
ScoreBoardFile /var/run/httpd.scoreboard
# Where do we put the lock and pif files?
LockFile /var/lock/httpd.lock
PidFile /var/run/httpd.pid
CoreDumpDirectory "/etc/httpd"
# Documents
DocumentRoot /var/www/html
UserDir public_html
IndexOptions FancyIndexing
# Who runs the server?
117
User apache
Group apache
# Performance parameters
MaxClients 150
TimeOut 300
KeepAlive false
MaxKeepAliveRequests 100
MaxRequestsPerChild 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 20
StartServers 8
# Error documents
# Misc
AccessFileName .htaccess
UseCanonicalName on
TypesConfig /etc/mime.types
DefaultType "text/plain"
# Defaults for virtual hosts
ServerSignature on
# Logs
ErrorLog /var/log/httpd/error_log
LogLevel warn
HostNameLookups Off
# Need to fix this
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /var/log/httpd/access_log common
Alias /icons/ "/var/www/icons/"
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "/var/www/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
#
# Redirect allows you to tell clients about documents which used to exist in
118
# your server's namespace, but do not anymore. This allows you to tell the
# clients where to look for the relocated document.
# Format: Redirect old-URI new-URL
#
#
# Directives controlling the display of server-generated directory listings.
#
#
# FancyIndexing: whether you want fancy directory indexing or standard
#
IndexOptions FancyIndexing
#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions. These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*
AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core
AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^
#
# DefaultIcon: which icon to show for files which do not have an icon
# explicitly set.
#
DefaultIcon /icons/unknown.gif
#
# AddDescription: allows you to place a short description after a file in
# server-generated indexes. These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
119
#
# ReadmeName: the name of the README file the server will look for by
# default, and append to directory listings.
#
# HeaderName: the name of a file which should be prepended to
# directory indexes.
#
# The server will first look for name.html and include it if found.
# If name.html doesn't exist, the server will then look for name.txt
# and include it as plaintext if found.
#
ReadmeName README
HeaderName HEADER
#
# IndexIgnore: a set of filenames which directory indexing should ignore
# and not include in the listing. Shell-style wildcarding is permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
#
# AddEncoding: allows you to have certain browsers (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz
#
# AddLanguage: allows you to specify the language of a document. You can
# then use content negotiation to give a browser a file in a language
# it can understand. Note that the suffix does not have to be the same
# as the language keyword --- those with documents in Polish (whose
# net-standard language code is pl) may wish to use "AddLanguage pl .po"
# to avoid the ambiguity with the common suffix for perl scripts.
#
AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it
#
# LanguagePriority: allows you to give precedence to some languages
# in case of a tie during content negotiation.
# Just list the languages in decreasing order of preference.
#
LanguagePriority en fr de
#
# AddType: allows you to tweak mime.types without actually editing it, or to
# make certain files to be certain types.
#
# The following is for PHP4 (conficts with PHP/FI, below):
<IfModule mod_php4.c>
AddType application/x-httpd-php .php4 .php3 .phtml .php
AddType application/x-httpd-php-source .phps
</IfModule>
# The following is for PHP3:
120
<IfModule mod_php3.c>
AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
</IfModule>
# The following is for PHP/FI (PHP2):
<IfModule mod_php.c>
AddType application/x-httpd-php .phtml
</IfModule>
AddType application/x-tar .tgz
#
# AddHandler: allows you to map certain file extensions to "handlers",
# actions unrelated to filetype. These can be either built into the server
# or added with the Action command (see below)
#
# If you want to use server side includes, or CGI outside
# ScriptAliased directories, uncomment the following lines.
#
# To use CGI scripts:
#
#AddHandler cgi-script .cgi
#
# To use server-parsed HTML files
#
AddType text/html .shtml
AddHandler server-parsed .shtml
#
# Uncomment the following line to enable Apache's send-asis HTTP file
# feature
#
#AddHandler send-as-is asis
#
# If you wish to use server-parsed imagemap files, use
#
AddHandler imap-file map
#
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and browsers that
# spoof it. There are known problems with these browser implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
#
# The following directive disables HTTP/1.1 responses to browsers which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
# If the perl module is installed, this will be enabled.
<IfModule mod_perl.c>
121
Alias /perl/ /var/www/perl/
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>
</IfModule>
#
# Allow http put (such as Netscape Gold's publish feature)
# Use htpasswd to generate /etc/httpd/conf/passwd.
# You must unremark these two lines at the top of this file as well:
#LoadModule put_module modules/mod_put.so
#AddModule mod_put.c
#
#Alias /upload /tmp
#<Location /upload>
# EnablePut On
# AuthType Basic
# AuthName Temporary
# AuthUserFile /etc/httpd/conf/passwd
# EnableDelete Off
# umask 007
# <Limit PUT>
# require valid-user
# </Limit>
#</Location>
#
# Allow server status reports, with the URL of http://servername/server-status
# Change the ".your_domain.com" to match your domain to enable.
#
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
#</Location>
#
# Allow remote server configuration reports, with the URL of
# http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your_domain.com" to match your domain to enable.
#
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
#</Location>
# Allow access to local system documentation from localhost
Alias /doc/ /usr/share/doc/
<Location /doc>
order deny,allow
deny from all
allow from localhost
Options Indexes FollowSymLinks
</Location>
#
<IfDefine HAVE_SSL>
##
122
## SSL Virtual Host Context
##
# Apache will only listen on port 80 by default. Defining the virtual server
# (below) won't make it automatically listen on the virtual server's port.
Listen 443
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot "/var/www/html"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
#SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with `make certificate' under
# built time. Keep in mind that if you've both a RSA and a DSA
# certificate you can configure both in parallel (to also allow
# the use of DSA ciphers, etc.)
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
#SSLCertificateFile /etc/httpd/conf/ssl.crt/server-dsa.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
#SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server-dsa.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/httpd/conf/ssl.crt/ca.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/httpd/conf/ssl.crt
#SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
123
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/httpd/conf/ssl.crl
#SSLCARevocationFile /etc/httpd/conf/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o CompatEnvVars:
# This exports obsolete environment variables for backward compatibility
# to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this
# to provide compatibility to existing CGI scripts.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
124
SSLOptions +StdEnvVars
</Directory>
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog /var/log/httpd/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</IfDefine>
# Virtual hosts
# Virtual host Default Virtual Host
<VirtualHost 192.9.200.211:80>
ServerName _default_
ServerSignature email
DocumentRoot /var/www/html/
DirectoryIndex index.php index.html index.htm index.shtml
LogLevel debug
HostNameLookups off
</VirtualHost>
# Virtual host Virtual Host 0
<VirtualHost 192.9.200.211:8080>
. ServerName _default_
. ServerSignature email
. DocumentRoot /home/httpd/twiki/
. DirectoryIndex index.php index.html index.htm index.shtml
LogLevel debug
HostNameLookups off
</VirtualHost>
# Directories...
<Directory "/">
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "/var/www/html">
Options Indexes Includes FollowSymLinks
AllowOverride None
Allow from from all
Order Deny,Allow
</Directory>
#Directory "/var/www/html2">
# Options Indexes Includes FollowSymLinks
# AllowOverride None
# Allow from from all
# Order Deny,Allow
#</Directory>
<Directory "/var/www/icons">
Options Indexes MultiViews
125
AllowOverride None
Allow from from all
Order allow,deny
</Directory>
<Directory "/var/www/cgi-bin">
Options ExecCGI
AllowOverride None
Allow from from all
. Order allow,deny
</Directory>
In conclusione, i siti Web sono diventati una delle componenti di maggiore importanza in ogni rete
e una gran quantità dei siti Web pubblici presenti su Internet è in esecuzione sotto Linux. In pratica,
qualsiasi distribuzione di Linux viene fornita con tutto ciò che serve per configurare qualsiasi tipo
di sito, da un piccolo sito Web interno ad un’azienda, fino ad un sito che conti milioni d’accessi al
mese. Installando il pacchetto rpm Apache sotto Red Hat abbiamo un Web server pronto dove è
sufficiente aggiungere il contenuto, e con l’hosting virtuale viene eliminata la limitazione ad un solo
server.
7.8. Sommario delle caratteristiche del Web Server Apache HTTP Server 1.3
Prezzo: gratuito
Installazione
Sistemi operativi (SO) supportati: BSD, Mac OS X; Unix, Windows
Disponibilità di codice sorgente
Supporto: documentazione
Architettura modulare
Modello di elaborazione: multiprocessing
Interfacce di programmazione
Cgi in-progress
Isapi
Scalabilità
Caching dei contenuti statici: funzionalità disponibile tramite un modulo open-source
Negoziazione dei contenuti multilingua
Amministrazione
Tramite linea di comando
Standard supportati
Estensioni server per Front Page: funzionalità disponibile tramite un modulo open-source
Logging e monitoraggio
126
Log di tipo “reliable piped”
Condivisione dei file di log tra i server virtuali
Filtri per dominio/utente/indirizzo IP
Siti virtuali
Regolazione individuale della banda: funzionalità disponibile tramite un modulo open-
source
Controllo di accesso individuale per i siti virtuali
Impostazioni di sicurezza per i siti virtuali
Monitoraggio dell’utilizzo dei siti virtuali: funzionalità disponibile tramite un modulo open-
source
Porte multiple/reindirizzamento degli Url
Sicurezza
Certificati per il server Web/certificati Ssl: funzionalità disponibile tramite un modulo open-
source
Supporta htaccess
127
8. TWiki
8.1. Introduzione
TWiki è un tool con licenza GPL di collaborazione basato su Web flessibile, potente e di semplice
utilizzo. TWiki è utilizzabile come uno spazio di sviluppo di progetti, gestione documenti e
database di informazioni o come altro strumento di sviluppo di gruppo, su una rete intranet o su
internet. Il contenuto Web può essere creato in modo collaborativi utilizzando un browser. Gli
sviluppatori possono creare nuove applicazioni Web basate su plugin API.
TWiki sembra un normalissimo sito Web intranet o internet. In ogni caso ha un link “Edit” in ogni
pagina dove ognuno, se abilitato, può cambiare una pagina o aggiungere nuovo contenuto usando
un browser.
TWiki è mantenuto e sviluppato sul sito TWiki.org. Su questo sito è possibile navigare e
aggiungere/modificare il contenuto per avere un’idea di come funziona TWiki.
TWiki è un sistema di collaborazione Web maturo e pieno di funzioni.
Qualsiasi web browser: E’ possibile editare o creare nuove pagine usando qualsiasi
browser. Non c’è alcuna necessità di ftp o http per effettuare l’upload delle pagine.
Link “Edit”: Per editare una pagina basta cliccare semplicemente sul bottone in fondo ad
ogni pagina.
Link automatici: Le pagine web vengono linkate automaticamente. Non c’è bisogno di
imparare comandi HTML per creare link.
Formattazione del testo: Le regole di formattazione del testo sono semplici, potenti e facili
imparare. Semplicemente il testo va scritto come quando si scrive un’email.
Webs: Le pagine sono raggruppate in siti web (o collezioni). Questo permette di organizzare
gruppi di collaborazione separati.
Search: Funzione che permette la ricerca con/senza espressioni regolari.
128
E-mail notification: Quando è stato cambiato qualcosa su un sito web, l’utente viene
informato automaticamente.
Contenuto strutturato: Si possono utilizzare i form TWiki per classificare pagine web non
strutturate e creare l'automatizzazione di un processo (parziale o completa) nel corso del
quale dei documenti, delle informazioni o dei compiti passano da un partecipante all'altro,
all'interno del gruppo di lavoro, conformemente ad un insieme di regole predefinite.
File allegati: E’ possibile effettuare upload e download di qualsiasi file come allegati
utilizzando il browser. Ciò è simile a quando si allegano dei file alle e-mail, ma su una
pagine web.
Controllo delle revisioni: Tutti i cambiamenti su una pagina e gli allegati vengono
controllati. E’ possibile vedere le revisioni e le differenze precedenti. Scoprire chi e quando
ha effettuato delle modifiche.
Controllo degli accessi: Si possono definire gruppi e impostare restrizioni in modo preciso
sia in lettura sia in scrittura, basati su gruppi e utenti.
Variabili: E’ possibile usare delle variabili per creare pagine dinamicamente. Questo
permette per esempio di costruire una tabella di contenuti dinamica: includere altre pagine o
mostrare risultati di ricerca concatenati in una pagina.
Plugins di TWiki: Sono programmi che permettono il miglioramento di TWiki e facilmente
installabili. Gli sviluppatori possono creare i plugin in Perl, con il TWiki plugin API.
Templates e skins: Un flessibile sistema di template separa la logica e la presentazione del
programma. Gli skin sovrascrivono le intestazioni dei template e delle cartelle, il contenuto
delle pagine rimane invariato.
Gestione delle pagine: le pagine possono essere rinominate, spostate e cancellate attraverso
il browser.
Gestione degli utenti: La registrazione e la variazione delle password degli utenti possono
essere effettuati via web.
Statistiche: Vengono create automaticamente statistiche dei siti web, in questo modo è
possibile sapere quali sono le pagine più popolari ed i relatori più frequenti.
Preferenze:Esitono tre livelli di preferenze: “TwikiPreferences” a livello del sito;
“WebPreferences” per ogni sito web; e quelle a livello d’utente.
Bloccaggio pagine: Gli utenti sono avvisati se la pagine viene editata da un'altra persona.
Questo serve a prevenire che due o più utenti editino la stessa pagina simultaneamente.
Referred-By: In questo modo è possibile trovare i link che puntano alla pagina.
… altre funzioni che non vengono elencate.
129
TWiki è uno script cgi-bin scritto in Perl. Legge un file di testo, collegamenti ipertestuali e li
converte al volo in HTML.
TWiki è installato su molti siti, solitamente dietro un firewall aziendale. TWiki viene usato da molte
delle maggiori compagnie perché è veramente user friendly rispetto ad altri sistemi commerciali
come Lotus Notes.
Le compagnie stanno schierando TWiki in vari campi e TWiki è piuttosto flessibile per adattarsi
alle più svariate necessità. Di seguito una lista non esaustiva di come TWiki può essere utilizzato:
Per rimpiazzare una intranet statica. Il contenuto è mantenuto dagli impiegati, così da
eliminare la sindrome “del solo ed unico webmaster” così da avere contenuti sempre
aggiornati.
Come un sistema knowledge base e di FAQ.
Per progettare e documentare progetti software.
Per tenere traccia di oggetti come bachi o altro. TWiki stesso funziona in questo modo.
Come tool per la gestione di documenti.
Per collaborare ad obiettivi comuni.
Come archivio software.
Come una message board interna della compagnia.
8.2. Requisiti di sistema di TWiki
I bassi requisiti di sistema sono il punto di forza di TWiki, che gli permette di funzionare su una
vasta gamma di piattaforme e versioni browser.
8.3. Requisiti del server
TWiki è scritto in Perl 5, utilizza un numero di comandi shell, e richiede RCS (Revision Control
System), ed un pacchetto software GNU. TWiki è sviluppato per funzionare sulla base di
Linux/Apache, ma funziona anche con Microsoft Windows, e non dovrebbe avere alcun problema
su qualsiasi altra piattaforma compatibile con i suoi requisiti.
130
Requisiti Richiesti
Risorsa Unix Windows
Perl 5.005_03 o superiore
Non standard Perl modules Net::SMTP (o sendmail) Net::SMTP,MIME::Base64,Digest::SHA1
RCS 5.7 o superiore
Altri programmi esterni ls, fgrep, egrep
Cron/scheduler cron equivalente cron
Web server Apache; altri con supporto CGI, autenticazione, path esteso
8.4. Requisiti dei client
L’installazione standard di TWiki richiede requisiti del browser molto bassi:
compatibilità HTML 3.2
genera pagine XHTML 1.0 che sono compatibili con HTML 3.2
utilizzo minimo di JavaScript nell’interfaccia utente
nessun utilizzo di cookies
nessun utilizzo di CSS
E’ possibile aggiungere delle funzionalità facilmente personalizzando “TWikiTemplates”, in modo
da adattare il browser alle proprie esigenze.
8.5. Guida di installazione di TWiki
Questi passi di installazione sono basati sul Web Server Apache su Linux. In caso si voglia
installare TWiki sotto Windows è consigliabile controllare il sito: http://twiki.org/cgi-
bin/view/Codev/TWikiOnWindows.
1. Creare & Configurare le Directory
E’ necessario innanzi tutto aver effettuato il login come root.
Creare la directory /home/httpd/twiki e unzipppare l’archivio TWiki in questa
directory.
La directory twiki/bin di TWiki deve essere settata come directory cgi-bin. Aggiungere
la directory /home/httpd/twiki/bin al file /etc/httpd/httpd.conf con
l’opzione ExecCGI.
La directory twiki/pub di TWiki deve essere settata in modo tale che sia visibile come URL.
Aggiungere /home/httpd/twiki al file httpd.conf con le opzioni di accesso
normali (copiarle da /home/httpd/html).
131
Aggiungere ScriptAlias per /twiki/bin/ e Alias per /twiki al file
httpd.conf. NOTA: ScriptAlias deve essere scritto prima di Alias, altrimenti
Apache non riuscirà a settare /twiki/bin, considerandola come un’altra subdirectory
dell’alias /twiki/.
Le directory twiki/data e twiki/templates devono essere configurate per non
essere visibili come url. Aggiungerle ad httpd.conf con l’opzione deny from all.
Sotto riportiamo un esempio delle righe da aggiungere al file httpd.conf:
ScriptAlias /twiki/bin “/home/httpd/twiki/bin/”
Alias /twiki/ “/home/httpd/twiki/”
<Directory “/home/httpd/twiki/bin”>
Options +ExecCGI
SetHandler cgi-script
Allow from all
</Directory>
<Directory “/home/httpd/twiki/pub”>
Options FollowSymLinks +Includes
Allow from all
AllowOverride All
</Directory>
<Directory “/home/httpd/twiki/data”>
deny from all
</Directory>
<Directory “/home/httpd/twiki/templates”>
deny from all
</Directory>
Riavviare Apache tramite la riga /etc/rc.d/rc5.d/S58httpd restart nel caso di
Apache 1.3 oppure /etc/local/apache2/bin/httpd restart nel caso di Apache
2.0.
Controllare che la directory twiki/bin sia abilitata CGI cercando di visitarla dal browser:
o Inserire l’URL per la directory bin,
http://yourdomain.com/twiki/bin/.
o Se i settaggi sono giusti sarà visualizzato un messaggio come: “Forbidden. You
don’t have the permission to access /twiki/bin/ on this
server”.
o I settaggi non sono corretti se viene visualizzato un messaggio del tipo “Index of
/twiki/bin”. In questo caso ricontrollare il file httpd.conf.
2. Impostare i permessi dei file
Controllare che Perl 5 e le librerie Perl CGI siano installate sul sistema. La posizione di
default del Perl è /usr/bin/perl. Se è altrove, cambiare il path al Perl nella prima linea
132
di ogni script nella directory twiki/bin o creare un link simbolico da
/usr/bin/perl. In alcuni casi gli script Perl CGI richiedono l’estensione .cgi per
funzionare. Altri sistemi necessitano dell’estensione .pl, la normale estensione del Perl. Se
necessario modificare tutti i nomi degli script in twiki/bin.
Impostare i permessi di tutti gli script Perl nella directory twiki/bin come eseguibili a –
rwxr-xr-x (755).
Perché sia possibile editare gli script Perl ed i file .tmpl è necessario utilizzare il comando
chown e chgrp –R twiki così che tutti i file abbiano il proprietario desiderato. Per
default, tutti i file utilizzati dagli script CGI (eseguiti dal Web server) hanno come
proprietario l’utente nobody; mentre per quanto riguarda tutti gli altri file, il proprietario è
twiki. Bisogna cambiare nobody con un altro utente se il server esegue gli script con un
nome utente differente. Avviare lo script testenv dal browser:
http://yourdomain.com/twiki/bin/testenv. Verrà mostrato il nome utente degli script CGI,
una tabella che lista tutte le variabili d’ambiente CGI ed un test del file di configurazione
twiki/lib/TWiki.cfg. Cambiare l’utente twiki con il proprio username.
Impostare i permessi dei file sotto twiki/data così che siano scrivibili dall’utente
nobody. Un modo semplice è di utilizzare chmod ed impostarli a -rw-rw-r-- (664) e
chown ed impostarli a nobody.
Impostare i permessi della directory twiki/data e le sue sottodirectory in modo tale che i
file siano scrivibili da nobody. Un modo semplice è usare chmod ed impostarli a
drwxrwxr-x (775) e chown per impostarli a nobody.
Impostare i permessi della directory twiki/pub e tutte le sue sottodirectory in modo tale
che tutti i file siano scrivibili da nobody. Un modo semplice è usare chmod ed impostarli a
drwxrwxr-x (775) e chown per impostarli a nobody.
I file RCS twiki/data/*/*.txt,v nel pacchetto di installazione sono bloccati
dall’utente nobody. Se gli script CGI non stanno funzionando come utente nobody, non è
possibile di effettuare controlli nei file (si nota dal fatto che il numero di revisione non viene
incrementato dopo il salvataggio di una pagina). In questo caso è necessario sbloccare i file
e ribloccarli con un utente diverso. Altrimenti è possibile cancellare questi file, che verranno
ricreati automaticamente quando una pagina viene editata e verranno bloccati dall’utente
attualmente in uso. Un modo semplice per cambiare proprietario è utilizzare un comando di
ricerca/sostituzione in tutti i file, per esempio utilizzando sed:
cd twiki/data
133
for f in */*,v; do sed ‘s/nobody\:/apache\:/’ $f > x; mv –f x
$f; done
3. Impostare il File di Configurazione Principale
Editare il file twiki/lib/TWiki.cfg, settare le variabili secondo le proprie esigenze.
Impostare le estensioni a cgi o pl nella variabile $scriptSuffix se richiesto.
Controllare che sia installato RCS. Impostare $rcsDir in twiki/lib/TWiki.cfg in
modo che il path sia il medesimo dei file binari RCS. E’ possibile controllare ciò tramite il
comando rcs nella shell. Il risultato dovrebbe essere del tipo “rcs: no input file”.
Per motivi di sicurezza le directory twiki/data, twiki/templates e tutte le
sottodirectory devono essere impostate in modo tale che non siano visibili come url. Per fare
ciò bisogna aggiungere la riga “deny from all” a tali directory nel file httpd.conf.
Oppure spostare le directory in una locazione in cui non sono visibili e cambiare di
conseguenza le variabili nel file twiki/lib/TWiki.cfg.
Per controllare le nuove impostazioni utilizzare lo script testenv dal browser:
http://yourdomain.com/twiki/bin/testenv. Controllare che tutti i settaggi del file
twiki/lib/TWiki.cfg siano corretti.
4. Concludere dal browser
Far puntare il Web browser all’indirizzo http://yourdomain.com/twiki/bin/view ed iniziare
ad utilizzare TWiki. Oppure puntare all’indirizzo http://yourdomain.com/twiki/ per ottenere
il pre-Twiki index.html, con un link allo script view. Personalizzare questa pagina in
caso si voglia un’introduzione pubblica con un link di login, invece di richiamare la finestra
di dialogo login di .htaccess richiamando direttamente lo script view.
Editare la pagina TWikiPreferences nel sito Web TWiki:TWiki per impostare
l’email WIKIWEBMASTER e altre preferenze.
Editare la pagina WebPreferences in ogni sito web, se necessario: impostare i singoli
messaggi WEBCOPYRIGHT e altre preferenze.
Abilitare la notifica via email dei cambiamenti delle pagine.
Editare la pagina WebNotify in tutti i siti Web ed aggiungere gli utenti che si vogliono
notificare.
E’ possibile aggiungere nuove %VARIABLES%. Definire le variabili a livello di sito nella
pagina TWikiPreferences. Vedere anche TWikiVariables.
134
8.6. Abilitare l’autenticazione degli utenti
HTAccess è un metodo per fornire una protezione tramite password per documenti HTML e le
directory su un Web server. Una volta implementato, HTAccess chiederà all’utente (attraverso il
browser) di inserire un username e una password. L’utente sarà abilitato a vedere le pagine Web
richieste solamente se sono stati inseriti un username ed una password validi.
HTAccess può essere implementato da qualsiasi utente del sistema su qualsiasi directory nella
directory public_html dell’utente. L’implementazione richiede solamente due semplici passi:
1. Creazione del file .htaccess nella directory da proteggere.
2. Creazione di un file .htpasswd.
Il file .htaccess è il file di controllo per l’interfaccia HTAccess. Specifica il path al file
.htpasswd oltre alle istruzioni di accesso (che determinano chi è abilitato ad accedere alle
pagine Web nella directory).
Il file .htpasswd contiene la lista di coppie degli username validi e delle password criptate per
essere utilizzate dal file .htaccess. Solo perché le pagine Web sono protette correttamente
dall’utente con HTAccess, non è detto che tali pagine siano accessibili solo dall’utente medesimo.
Il file .htaccess dovrebbe essere creato nella directory che si vuole proteggere. Questa potrebbe
essere tutta la directory public_html o una sottodirectory della directory public_html. Una volta che
il file .htaccess è stato posizionato in una directory, tutti gli oggetti all’interno di tale directory
(incluse tutte le sottodirectory e loro contenuto) saranno protetti.
Il file .htaccess contiene le istruzioni per determinare chi è abilitato ad accedere alla directory.
Esistono due sezioni nel file .htaccess:
1. La prima sezione di .htaccess deve contenere 3 linee:
AuthUserFile {path al file .htpasswd}
AuthName {titolo della finestra di dialogo}
AuthType Basic
2. La seconda sezione deve contenere 3 parti:
<Limit GET>
{istruzione di accesso che deve essere eseguita}
</Limit>
Il set di istruzioni che sono poste tra <Limit GET> e </Limit> determina le modalità di
accesso alla directory, ad esempio chi è abilitato all’accesso delle pagine Web nella directory e chi
non lo è.
Ci sono alcuni tipi di istruzioni di accesso che possono essere usate:
Per permettere l’accesso ad un utente specifico digitare l’istruzione:
require user {username}
135
Per permettere l’accesso ad ogni utente all’interno di un determinato dominio digitare
l’istruzione:
order deny,allow
deny from all
allow from {nome dominio}
dove nome dominio è il nome del dominio al quale si vuole abilitare l’accesso. Notare che
non ci sono spazi tra re parole “deny” e “allow” nella prima riga.
Da notare anche che si vuole abilitare o negare l’accesso a specifici domini, le prime quattro
linee “Auth” del file .htaccess possono essere omesse (queste linee vengono utilizzate
solo per l’autenticazione di gruppi o utenti).
Per negare l’accesso ad ogni utente all’interno di un determinato dominio digitare
l’istruzione:
order allow,deny
allow from all
deny from {nome dominio}
dove nome dominio è il nome del dominio al quale si vuole negare l’accesso.
8.6.1 File .htaccess
Riportiamo come esempio il nostro file .htaccess.
Redirect /twiki/index.html http://localhost/twiki/bin/view
AuthUserFile /home/httpd/twiki/data/.htpasswd
AuthName ByPassword
AuthType Basic
SetHandler cgi-script
ErrorDocument 401 /twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth
<Files ~ "[^/]*\.html$">
SetHandler blabla
allow from all
</Files>
<Files "edit">
require valid-user
</Files>
<Files "preview">
require valid-user
</Files>
<Files "save">
require valid-user
</Files>
136
<Files "attach">
require valid-user
</Files>
<Files "upload">
require valid-user
</Files>
<Files "rename">
require valid-user
</Files>
<Files "installpasswd">
require valid-user
</Files>
<Files "*">
allow from all
</Files>
<Files "view">
require valid-user
</Files>
Il file .htpasswd contiene tutti gli username e password validi per il sito. Il path completo del file
.htpasswd deve essere specificato nel file .htaccess alla voce AuthUserFile.
E’ importante considerare che username e password sono completamente arbitrarie, non c’è
assolutamente alcuna corrispondenza tra gli username e le password utilizzate nel file .htaccess
con quelle di sistema utilizzate dei medesimi utenti.
Il comando htpasswd serve per creare le coppie di username e password. Il path completo del
completo del comando è /usr/local/apache2/bin/htpasswd. Da notare che il comando
htpasswd cripta immediatamente ogni password prima di scrivere nel file .htpasswd.
Per creare il file .htpasswd, utilizzare il comando htpasswd con il seguente formato:
htpasswd –c .htpasswd {username}
Il comando chiederà una password per quell’utente e poi chiederà di confermare tale password. La
password appena digitata non verrà riportata sullo schermo durante la digitazione e verrà criptata
immediatamente.
L’output del comando htpasswd è un .htpasswd con una voce della forma:
{user}:{password criptata}
Quando si aggiunge un altro utente, utilizzare il comando .htpasswd senza l’opzione –c:
htpasswd .htpasswd {username}
Il metodo di seguito descritto permette di autenticare gli utenti nel caso in cui si disponga di un
server non autenticato e/o che non utilizza SSL.
137
1. Rinominare il file .htacces.txt in .htaccess nella directory twiki/bin e
modificarlo secondo le proprie esigenze. In particolare devono essere ben configurate le
seguenti righe:
Redirect /urlpathto/twiki/index.html
http://yourdomain.com/urlpathto/twiki/bin/view
AuthUserFile /filepathto/twiki/data/.htpasswd
ErrorDocument 401
/urlpathto/twiki/bin/oops/Twiki/TWikiRegistration?template=oopsa
uth
Il browser chiederà un login name ed una password quando si clicca sul link Edit. Nel caso in
cui il file .htaccess non abbia l’effetto desiderato bisogna abilitarlo aggiungendo la riga
AllowOverride All
nella sezione Directory nel file httpd.conf per la directory twiki/bin.
2. Copiare la pagina TWikiRegistrationPub nella pagina TWikiRegistration. Par fare
ciò editare le pagine nel TWiki Web oppure rinominare i file .txt e .txt,v nella directory
twiki/data/TWiki.
E’ possibile personalizzare il form di registrazione cancellando od aggiungendo i tag. Il
parametro name=“ ” del tag deve iniziare con: “Twk0…” se è un campo opzionale o
“Twk1…” se è un campo obbligatorio. Ciò assicura che i campi siano elaborati correttamente.
3. Registrarsi nella pagina TWikiRegistration. Quando un utente si registra viene aggiunta
una nuova linea nel file data/.htpasswd con username e password criptata. Il file
.htpasswd fornito con l’installazione di TWiki include degli account utenti dei membri del team
di TWiki, che vengono utilizzati per effettuare test su TWiki.org. E’ possibile editare e
cancellare queste linee.
4. Creare una nuova pagina per verificare il corretto funzionamento dell’autenticazione.
5. Editare la pagina TWikiAdminGroup nel web TWiki:Main per includere un utente con i
permessi di amministratore.
6. Editare la pagina TWikiPreferences nel web TWiki:TWiki per impostare i privilegi di
accesso.
7. Editare la pagina WebPreferences in ogni web, se necessario, ed impostare i privilegi di
accesso.
138
8.7. Aggiungere un sito web
Per creare un nuovo sito web:
1. Creare una nuova directory sotto twiki/data e controllare i permessi dei file della directory.
Utilizzare un nome composto dai caratteri A…Z, a…z ma che non siano in WikiNotation. Il
nome dovrebbe iniziare con una o più maiuscole, ma non avere altre maiuscole dopo il primo
gruppo.
2. Copiare tutti i file dalla directory twiki/data/_default nella nuova directory,
mantenendo i proprietari originali dei file, gruppi e permessi. I file devono essere scrivibili dal
proprietario degli script CGI utilizzati. E’ possibile impostare i permessi dei file .txt e
.txt,v a -rw-rw-rw- (666) e poi editare la pagina utilizzando il browser; RCS ripristinerà
correttamente i permessi dei file quando la pagina verrà salvata.
3. Aggiungere un nuovo sito web alla lista dei siti (visibile nell’angolo in alto a destra di ogni
pagina) editando le preferenza a livello di sito, TWikiPreferences. Aggiungere il nuovo
Web alla variabile %WIKIWEBLIST%.
4. Aggiornare le impostazioni Web editando la pagina WebPreferences nel nuovo Web.
Personalizzare la variabile %WEBTOPICLIST% in modo che contenga i link Web specifici da
utilizzare. Impostare la variabile %WEBBGCOLOR% ad un colore. Il numero rappresenta il colore
unico per il sito Web. Impostare i Plugins, privilegi di accesso, variabili personalizzate ed altre
opzioni a livello di sito.
5. Aggiungere il nuovo Web alla tabella colorata della directory Web editando la pagina
TWikiWebsTable.
6. Testare il nuovo Web: visitare le pagine e crearne di nuove.
Le home page degli utenti sono situate nel Web TWiki.Main. Non cercare di spostarle o crearle
in altri Web. Da ogni altro Web, la firma dell’utente deve puntare al Web TWiki.Main, usando il
formato Main.UserName o %MAINWEB%.UserName. La variabile %MAINWEB% è vantaggiosa
se viene cambiato il nome del Web Main.
8.8. TWiki Access Control
TWikiAccessControl permette di restringere l’accesso alle singole pagine e ad interi Web, da
parte di un solo utente o gruppo di utenti, in tre aree principali: view; edit & attach;
rename/move/delete. Questi controlli, combinati con TWikiUserAuthentication, permettono
di creare e mantenere facilmente un’estrema flessibilità dei privilegi di sistema.
139
Un’importante considerazione sul controllo.
L’editing libero ed aperto è l’essenza della WikiCulture. Questo fa sì che TWiki sia diverso e
spesso molto più potente di altri applicativi di collaborazione. Perciò è fortemente raccomandabile
che la decisione di restringere i permessi di lettura e scrittura ad un Web o ad una pagina sia fatta
con cautela. L’esperienza insegna che un accesso di scrittura non ristretto funziona molto bene
perché:
La parità influenza è sufficiente ad assicurare che sia inviato solo il contenuto rilevante.
La parità di editing, la capacità di modificare tutti gli oggetti di una pagina, mantiene le
pagine focalizzate.
Tutto il contenuto è mantenuto sotto un controllo di revisione. Le versioni precedenti
possono essere cancellate dal TWikiAdminGroup.
Gli utenti sono incoraggiati ad editare e concentrare una lunga pagina, poiché c’è una rete di
sicurezza.
Utenti e gruppi
Il controllo d’accesso è basato su utenti e gruppi. Gli utenti sono definiti dai loro WikiNames, e
successivamente organizzati sotto una combinazione illimitata sotto differenti gruppi utente.
Amministrazione Utenti
Un utente viene creato tramite il form TWikiRegistration. Il processo genera una pagina nel
Web Main con il nuovo WikiName dell’utente. Il nome di default del visitatore è TWikiGuest.
Gli utenti possono essere autenticati usando una Basic Authentication o SSL. E’ richiesta
TWikiUserAuthentication per tener traccia delle identità degli utenti.
Amministrazione Gruppi
I gruppi sono definiti dalle pagine dei gruppi nel Web Main, come TWikiAdminGroup. Per
creare un nuovo gruppo:
1. Creare una nuova pagina con un nome che finisce con Group, SomeGroup.
2. Definire due variabili:
a. Set GROUP=<lista degli utenti e gruppi>
b. Set ALLOWTOPICCHANGE=<lista degli utenti e gruppi>
GROUP è una lista di utenti e gruppi separati da una virgola, mentre ALLOWTOPICCHANGE
definisce chi è abilitato a cambiare la pagina del gruppo. Anch’essa è una lista di utenti e gruppi
separati da una virgola.
140
Restringere i permessi di scrittura.
E’ possibile definire chi è abilitato a fare cambiamenti di un sito web o di una pagina.
Vietare l’editing di una pagina.
Vietare l’editing di una pagina toglie anche la possibilità di allegarvi file; entrambi i privilegi
vengono assegnati insieme. Per fare ciò bisogna definire in una pagina una o entrambe delle
seguenti variabili, preferibilmente alla fine della pagina:
Set DENYTOPICCHANGE=<lista degli utenti e gruppi>
Set ALLOWTOPICCHANGE=<lista degli utenti e gruppi>
La prima definisce gli utenti ed i gruppi che non sono abilitati ad effettuare cambiamenti nella
pagina. E’ una lista di utenti e gruppi separati da una virgola e viene definita per prima. La seconda
definisce utenti e gruppi che invece sono abilitati ad apportare cambiamenti ad una pagina. Anche
questa è una lista di utenti e gruppi separati da una virgola. L’accesso e consentito se le variabili
sono lasciate vuote.
Vietare l’editing dell’intero sito.
Vietare l’editing a livelli di web blocca anche il permesso di creare nuove pagine, cambiarle o
allegarvi file. Per fare ciò bisogna definire nella pagina WebPreferences una o entrambe delle
seguenti variabili:
Set DENYWEBCHANGE=<lista degli utenti e gruppi>
Set ALLOWWEBCHANGE=<lista degli utenti e gruppi>
Le medesime regole vengono applicate per restringere pagine, con queste aggiunte:
DENYTOPICCHANGE (nella pagina) ha priorità su DENYWEBCHANGE (in
WebPreferences);
ALLOWTOPICCHANGE (nella pagina) ha priorità su ALLOWWEBCHANGE (in
WebPreferences).
Vietare la rinominazione delle pagine
E’ possibile definire chi è abilitato a rinominare, spostare o cancellare una pagina o rinominare un
Web.
141
Vietare rinominazione di una pagina
Per permettere ad un utente di rinominare una pagina, spostare o cancellarne una, questo deve avere
permessi di scrittura (editing). Per fare ciò bisogna definire in una pagina una o entrambe delle
seguenti variabili, preferibilmente alla fine della pagina:
Set DENYTOPICRENAME=<lista degli utenti e gruppi>
Set ALLOWTOPICRENAME=<lista degli utenti e gruppi>
La prima definisce gli utenti ed i gruppi che non sono abilitati a rinominare la pagina. E’ una lista di
utenti e gruppi separati da una virgola e viene definita per prima. La seconda definisce utenti e
gruppi che invece sono abilitati a rinominare la pagina. Anche questa è una lista di utenti e gruppi
separati da una virgola. L’accesso e consentito se le variabili sono lasciate vuote.
Vietare rinominazione di un web
E’ possibile definire restrizioni per chi è abilitato a rinominare un Web TWiki. Per fare ciò definire
una o entrambe delle seguenti variabili nella pagina WebPreferences:
Set DENYWEBRENAME=<lista degli utenti e gruppi>
Set ALLOWWEBRENAME=<lista degli utenti e gruppi>
Le solite regole si possono applicare alle pagine con queste aggiunte:
DENYTOPICRENAME (nella pagina) ha priorità su DENYWEBRENAME (in
WebPreferences);
ALLOWTOPICRENAME (nella pagina) ha priorità su ALLOWWEBRENAME (in
WebPreferences).
Restringere l’accesso in lettura
E’ possibile definire chi è abilitato a vedere un Web TWiki. Per fare ciò definire una o entrambe le
seguenti variabili nella pagina WebPreferences:
Set DENYWEBVIEW=<lista degli utenti e gruppi>
Set ALLOWWEBVIEW=<lista degli utenti e gruppi>
La restrizione di accesso in lettura non è consigliabile in caso di contenuto molto importante poiché
c’è un modo per aggirare la restrizione di accesso in lettura.
La restrizione di accesso in lettura funziona solamente se lo script view è autenticato, questo
significa che gli utenti devono effettuare il login anche solo per vedere una pagina.
142
Accesso Web Selettivo Non Ristretto
C’è un’alternativa nel caso si preferisca avere un accesso non ristretto per vedere delle pagine
situate nei normali Web e per autenticare gli utenti solamente per il Web dove sono abilitate le
restrizioni di lettura.
1. Togliere lo script view dal file .htaccess.
2. Abilitare il flag %DoRememberRemoteUser nel file lib/TWiki.cfg come
descritto in TWikiUserAuthentication. A questo punto TWiki ricorderà
l’indirizzo IP di un utente autenticato.
3. Copiare lo script view in viewauth (o meglio creare un link simbolico).
4. Aggiungere viewauth alla lista degli script autenticati nel file .htaccess. Quando
un utente accede ad un Web dove è stata abilitata la restrizione in lettura, TWiki
reindirizzerà una volta dallo script view allo script viewauth (questo accede
solamente se l’utente non ha mai editato una pagina): Facendo ciò verrà richiesta
l’autenticazione. Lo script viewauth mostrerà la pagina richiesta se l’utente può
effettuare il login e se è autorizzato a vedere quel Web. Se è stato abilitata la restrizione
in lettura di un Web è consigliato restringere la funzione di ricerca in modo che questa
non elenchi i Web che non devono essere visibili. Per fare ciò impostare la seguente
variabile in WebPreferences:
Set NOSEARCHALL = on
Non è consigliato restringere l’accesso in lettura per una determinata pagina poiché il
suo contenuto è ricercabile all’interno di un Web.
8.9. Nascondere i settaggi di controllo
Per nascondere i settaggi di controllo quando si visita una pagina, basta scriverli fra i marcatori di
commento.
<!--
Set DENYTOPICCHANGE = Main.SomeGroup
-->
8.10. Il SuperAdminGroup
Nel caso si sbagli a scrivere il nome di un utente o di un gruppo per la variabile
ALLOWTOPICCHANGE, è possibile che questa pagina rimanga bloccata in modo tale che
nessuno possa editarla dal browser. Per evitare ciò impostare la variabile $superAdminGroup
143
nel file lib/TWiki.cfg con il nome di un gruppo di utenti che sono sempre abilitati ad
editare/vedere le pagine. Per default non esiste nessun superAdminGroup.
8.11. Gestione File Allegati
Ogni pagina può avere file allegati, come nelle email. Utilizzare il browser per effettuare l’upload o
il download dei file. Gli allegati sono soggetti a controllo di revisione, così gli upload non possono
essere perduti ed i cambiamenti sui file possono essere effettuati con un’opzione che permette di
recuperare tutte le precedenti versioni. Gli allegati possono essere utilizzati per creare soluzioni di
gruppo(condivisione di file, gestione documenti) è per velocizzare la creazione del Web.
8.12. Sistema di gestione dei documenti
E’ possibile utilizzare gli allegati per immettere o recuperare documenti (in qualsiasi formato, con
grafica associata ed altri file multimediali); allegare documenti ad una specifica pagina di TWiki;
collaborare sui documenti con pieno controllo delle revisione; distribuire documenti in modo
semplice; creare una libreria centrale di riferimento che sai facilmente accessibile a gestibile da un
intero gruppo di utenti.
8.13. Condivisione File
Per la condivisione file, FileAttachments può essere utilizzato su una serie di pagine per creare
velocemente un centro di download ben documentato ed ordinato per qualsiasi tipo di file:
documenti, grafica ed altri file multimediali; driver e patch; applicazioni; qualsiasi altra cosa possa
essere caricata.
8.14. Web Authoring
Attraverso il Web browser, si può facilmente effettuare l’upload di file grafici (o musicali, o
qualsiasi altra cosa si voglia mettere all’interno di una pagina) e posizionarli nel posto desiderato su
ogni singola pagina o per l’utilizzo attraverso un Web o su tutto il sito. Da notare che è possibile
aggiungere file grafici direttamente, tipicamente utilizzando l’upload via FTP. Questo metodo
richiede l’accesso al server e risulta più conveniente se bisogna caricare un gran numero di file o se
questi vanno posizionati in una directory specifica. Questi file non possono essere gestiti utilizzando
i controlli di attachment basati su browser.
144
8.15. Upload dei file
Per effettuare l’upload di un file sulla pagina cliccare su Attach in fondo ad essa. Verrà visualizzato
un form dove è possibile specificare il percorso del file che si vuole allegare. Il file appena caricato
viene quindi visualizzato all’interno di una tabella. Può essere caricato qualsiasi tipo di file. Alcuni
file che possono creare falle nella sicurezza vengono rinominati aggiungendo l’estensione .txt. Al
momento non c’è alcuna limitazione sulla dimensione del file se non lo spazio libero sul server. Per
semplicità viene mantenuto il percorso precedente di upload. Nel caso si effettui qualche
cambiamento al file locale e si vuole effettuare l’upload, di nuovo si può copiare il percorso del
precedente upload nel campo Local del file.
8.16. Download dei file
Per scaricare un file è sufficiente cliccare sul relativo link all’interno della tabella contente i file.
Non esiste alcun controllo individuale sugli allegati. Se si necessita di questo tipo di controllo
bisogna creare una pagina separata e definire le restrizioni di accesso per pagina.
8.17. Spostare i file allegati
Un allegato può essere spostato da una pagina all’altra. Per far ciò è sufficiente cliccare sulla voce
Action vicino al file. Sulla pagina di controllo, selezionare il nuovo Web e la nuova pagina e
cliccare su Move. L’allegato e la sua lista delle revisioni vengono spostati. La posizione originale è
memorizzata come pagina Meta Data.
8.18. Eliminare gli allegati
Nella versione corrente di TWiki non è possibile cancellare gli allegati. In ogni caso possono essere
spostati su un’altra pagina. E’ sufficiente creare una pagina Trash.TrashAttachments e spostarvi gli
allegati che non sono più necessari.
8.19. Link ai file allegati
Una volta che un file è stato allegato è possibile creare un riferimento a questo in una pagina. Ad
esempio:
1. Allegare un file con Attach: Sample.txt
2. Effettuare l’Edit della pagina e scrivere: %ATTACHURL%/Sample.txt
3. La Preview di %ATTACHURL% appare come un link
http://twiki.org/p/pub/TWiki/FileAttachment/Sample.txt
145
Per riferire un allegato situato in un’altra pagina scrivere:
%PUBURL%/%WEB%/OtherTopic/Sample.txt (per lo stesso Web);
%PUBURL%/OtherWeb/OtherTopic/Sample.txt (per un Web diverso).
File allegati HTML e di testo possono essere inseriti in una pagina. Ad esempio:
1. Allegare un file con Attach: Sample.txt
2. Effettuare l’Edit della pagina e scrivere:
%INCLUDE{“%ATTACHURL%/Sample.txt”}%
Immagini GIF, JPG e PNG possono essere allegate e mostrate in una pagina. Ad esempio:
1. Allegare un file con Attach: Smile.gif
2. Effettuare l’Edit della pagina e scrivere: %ATTACHURL%/Smile.gif
3. Nella preview appare un’immagine .
Qui sotto è riportato un esempio della tabella che viene creata automaticamente dopo che sono stati
inseriti degli allegati.
Attachment: Action: Size: Date: Who: Comment:
Sample.txt action 30 22 Jul 2000 - 19:37 AdminAdmin Just a sample
Smile.gif action 94 22 Jul 2000 - 19:38 AdminAdmin Smiley face
Cliccando su Action compaiono le due tabelle sottostanti.
La prima è una lista di tutti gli allegati, inclusi i loro attributi. Una h significa che l’allegato è
nascosto e non è visibile quando si consulta la pagina che lo contiene.
Attachment: Action: Size: Date: Who: Comment: Attribute:
Sample.txt action 30 22 Jul 2000 - 19:37 AdminAdmin Just a sample
Smile.gif action 94 22 Jul 2000 - 19:38 AdminAdmin Smiley face
La seconda mostra tutte le versioni degli allegati. Cliccando su view è possibile vedere la versione
specifica. Se è la versione più recente, l’utente verrà riportato ad un URL che mostra sempre
l’ultima versione, che è quella che di solito si desidera.
Version: Action: Date: Who: Comment:
1.1 view 2001.08.30.09.28.56 AdminAdmin
146
E’ possibile cambiare il commento ad un allegato inserendo un nuovo commento nell’apposito
campo. Per nascondere/mostrare l’allegato, spuntare la casella “Hide file”.
Previous
upload: C:\DATA\Sample.txt (AdminAdmin)
Local file:
Comment: Just a sample
Link: Create a link to the attached file at the end of the topic.
Hide file: Hide attachment in normal topic view.
Diversamente dalle pagine, gli allegati non sono bloccati durante l’editing. Per aggirare l’ostacolo
basta cambiare il commento per indicare un allegato su cui si sta lavorando. Il commento sulla
versione specifica non viene perso, ma ricompare nella lista delle versioni dell’allegato.
8.20. Form TWiki
E’ possibile strutturare le pagine con categorie illimitate, facilmente ricercabili, aggiungendo dei
form al loro contenuto. Quando i form sono abilitati per un Web e selezionati in una pagina,
compare un singolo form durante l’edit, ed il suo contenuto è formattato come una tabella quando
viene visto nella pagina. E’ possibile definire un numero di form illimitato per ogni Web. Per ogni
pagina è possibile selezionare un template se ne sono stati definiti più di uno o rimuovere
interamente i form. I valori d’input del form (nome della pagina, campi e valori) sono memorizzati
come TWkiMetaData; l’ordine delle coppie campo/valore sono le stesse di quelle nel template.
TWikiForms accetta dati dall’utente. Meta data contiene anche informazioni sui cambiamenti,
sugli allegati, ecc., generate dal programma.
8.21. Templates TWiki
Il nuovo sistema modulare di template offre controllo semplice e flessibile sul layout di tutte le
pagine TWiki. Il master template avvicina gruppi d’oggetti che sono condivisi da più template
(come le intestazioni e le note a piè di pagina) in un file comune. Variabili speciali permettono
layout individuali per includere parti dal master template. Le variabili sono mescolate con normali
marcatori HTML per quanto riguarda il contenuto specifico dei template.
Esistono tre tipi di template:
Master Template
Memorizza parti comuni, incluse da altri template. Parti comuni, che compaiono in due o più
template, possono essere definite in un master template e poi condivise dagli altri:
twiki.tmpl è il master template di default.
147
HTML Page Templates
Definisce il layout delle pagine TWiki. TWiki utilizza file di template HTML per tutte le
azioni, come la consultazione delle pagine, l’editing e le preview. Questo permette all’utente
di cambiare il look di tutte la pagine editando solamente pochi file template. I template si
trovano nella directory twiki/templates.
Template Topics
Definisce il testo di default quando viene creata una nuova pagina. Esistono tre tipi di questo
template: WebTopicViewTemplate (pagina d’errore visualizzata quanto si cerca di
visualizzare una pagina inesistente), WebTopicNonWikiTemplate (pagina
d’avvertimento mostrata quando si tenta di visualizzare una pagina inesistente con un nome
non WikiName), WebTopicEditTemplate (testo di default visualizzato quando viene
creata una nuova pagina). Tutte la pagine di template sono situate nel Web TWiki.
148
9. Java 2 SDK, Standard Edition Versione 1.4.0 Linux
9.1. Presentazione di Java
Con la maturazione del linguaggio, la tecnologia diventa sempre più stabile ed affidabile e le
aspettative si riducono a livelli accettabili. Java viene sempre più utilizzato come “middleware” per
la comunicazione tra i client ed i database o le altre risorse dei server. Anche se poso appariscente,
questa è un’area importante in cui Java, principalmente grazie alla sua portabilità ed alle sue
funzionalità di multithreading e di rete, può aggiungere valore reale. Java si sta insinuando con
grande successo nei sistemi embedded, dove ha tutte le carte per diventare uno standard per i
dispositivi tascabili, i chioschi internet, i computer di bordo delle automobili e così via. Tuttavia, i
primi tentativi di riscrivere i consueti programmi per PC in Java non sono stati incoraggiati: le
applicazioni risultavano lente e scarsamente potenti. Con la versione attuale di Java, alcuni di questi
problemi potrebbero essere risolti, ma in ogni caso agli utenti generalmente non interessa quale
linguaggio di programmazione sia stato impiegato per scrivere le applicazioni: i vantaggi di Java si
riveleranno nei nuovi tipi di dispositivi e programmi, non nella rielaborazione di quelli esistenti.
9.2. Java come strumento di programmazione
Java è sicuramente un buon linguaggio di programmazione, senza dubbio uno dei migliori a
disposizione dei programmatori professionisti. Potenzialmente avrebbe potuto essere un grande
linguaggio di programmazione, ma probabilmente ormai è troppo tardi: una volta che il linguaggio
è immesso sul mercato, bisogna fare i conti con la brutta realtà della compatibilità con il codice
esistente. Inoltre, anche qualora sia possibile apportare modifiche senza distruggere il codice
esistente, è difficile che i creatori di un linguaggio apprezzato come Java possano riconoscere di
aver sbagliato e proporre con disinvoltura una nuova alternativa. In sintesi, anche se sono
prevedibili alcuni miglioramenti nel tempo, essenzialmente la struttura futura del linguaggio sarà
analoga a quella attuale.
In che cosa consistono i sensazionali miglioramenti di Java? La risposta è che essi derivano non
tanto dalla modifica del linguaggio della programmazione di base, quanto dai sensibili cambiamenti
149
nelle librerie Java. Nel corso del tempo Sun Microsystems ha cambiato tutto, dai nomi di molte
funzioni delle librerie (per uniformarli) alla modalità di funzionamento della grafica (modificando il
modello di gestione degli eventi e riscrivendone ex novo alcune parti), fino all’aggiunta di funzioni
importanti quali la stampa che non esistevano in Java 1.0. Ne è risultato uno strumento di
programmazione molto più utile e, anche se non ancora completamente robusto, molto meno fragile
rispetto alle versioni precedenti.
Ogni versione di Java ha cambiato radicalmente le librerie del predecessore e la versione attuale
non fa eccezione. Le innovazioni apportate alle librerie in Java 2 sono anzi di gran lunga le più
estese.
Microsoft sta creando un prodotto dal nome J++ affine a Java. Come Java, J++ è interpretato da una
macchina virtuale compatibile con la Java Virtual Machine per l’esecuzione di bytecode Java, ma
presenta differenze sostanziali nell’interfaccia con il codice esterno. La sintassi essenziale del
linguaggio è quasi identica a quella di Java. Microsoft ha peraltro aggiunto costrutti linguistici di
dubbia utilità, se non per l’interfaccia con le API di Windows. Oltre a condividere una sintassi
comune, Java e J++ possiedono librerie di base (stringhe, utilità, collegamenti in rete,
multithreading, matematica, ecc.) essenzialmente identiche. Le librerie per la grafica, le interfacce
utente e l’accesso agli oggetti remoti sono invece completamente differenti.
9.3. Java virtual machine
La Java virtual machine è la pietra miliare della piattaforme Java e Java 2. E’ il componente della
tecnologia che ha la caratteristica d’essere indipendente dall’hardware e dal sistema operativo, di
avere un codice compilato di dimensioni ridotte e di proteggere gli utenti da programmi
malintenzionati.
La Java virtual machine è un calcolatore astratto. Come un calcolatore reale, ha un set d’istruzioni e
manipola varie aree di memoria. E’ molto comune implementare un linguaggio di programmazione
usando una virtual machine; la più conosciuta virtual machine può essere la P-Code machine di
UCSD Pascal.
Il primo prototipo di implementazione della Java virtual machine, fatta dalla Sun Microsystem, Inc.,
emulava in software il set di istruzioni della Java virtual machine contenuto in un apparecchio
portatile che assomigliava ad un Personal Digital Assistant (PDA) contemporaneo. Le attuali
implementazioni della virtual machine di Java, componenti di Java 2 SDK e Java 2 prodotti
dell’ambiente runtime, emulano la Java virtual machine su host Win32 e Solaris in modi molto più
sofisticati. In ogni caso, la Java virtual machine non comporta alcuna implementazione tecnologica
particolare, host hardware o sistemi operativi host. Non è intrinsecamente interpretata, ma può
150
essere velocemente implementata compilando il suo set di istruzioni su una CPU di silicio. Può
anche essere implementata in microcode o direttamente in silicio.
La Java virtual machine non conosce niente del linguaggio di programmazione Java, ma solo un
formato binario particolare, il formato file class. Un file class contiene le istruzioni della Java
virtual machine (o bytecodes) una tabella di simboli e altre informazioni aggiuntive.
Per motivi di sicurezza, la Java virtual machine utilizza un formato forte ed una soggezione
strutturale sul codice in un file class. Comunque, ogni linguaggio con una funzionalità che può
essere espressa in termini di un file class valido, può essere gestito dalla Java virtual machine.
Attratti da una disponibilità generale e dalla piattaforma indipendente, gli implementatori di altri
linguaggi sono portati ad utilizzare la Java virtual machine come veicolo di consegna per i loro
linguaggi.
9.4. Struttura della Java virtual machine
Per implementare la Java virtual machine, c’è bisogno solo di essere capaci di leggere il formato del
file class e comprendere correttamente le operazioni scritte al suon interno. I dettagli
dell’implementazione che non fanno parte delle specifiche della Java virtual machine non limitano
necessariamente la creatività dell’implementatore. Per esempio, il layout di memoria delle aree dati
run-time, l’algoritmo usato garbage-collection e ogni ottimizzazione interna delle istruzioni della
Java virtual machine (per esempio, la loro traduzione in codice macchina) sono lasciate alla
discrezione dell’implementatore.
Il codice compilato che deve essere eseguito dalla virtual machine è rappresentato da un formato
binario indipendente dall’hardware e dal sistema operativo, tipicamente (ma non necessariamente)
inserito in un file, conosciuto come formato file class. Il formato file class definisce esattamente
la rappresentazione di una classe o interfaccia, includendo dettagli come l’ordinamento byte che
potrebbero essere presi per scontato in un formato di file oggetto specifico della piattaforma.
La Java virtual machine si avvia creando una classe iniziale, che è specificata in un modo
dipendente dall’implementazione, utilizzando il bootstrap class loader. La Java virtual machine
quindi collega la classe iniziale, la inizializza e richiama public< class method
voidmain(String[]). Il richiamo di questo metodo guida tutte le esecuzioni successive.
L’esecuzione delle istruzioni della Java virtual machine che costituiscono in metodo principale
possono causare collegamenti (e conseguentemente creazione) di classi o interfacce aggiuntive,
oltre a richiamare metodi aggiuntivi.
151
9.5. Vantaggi di Java
Un vantaggio evidente è una libreria runtime che auspica di conseguire l’indipendenza dalla
piattaforma, consentendo di utilizzare lo stesso codice in Windows 95/98/NT/2000/XP, Solaris,
Unix, Macintosh e così via. Questo è sicuramente necessario per la programmazione in Internet
tuttavia, le implementazioni su altre piattaforme solitamente non sono all’altezza di quelle di
Windows e Solaris.
Un altro vantaggio per la programmazione è che Java ha una sintassi simile a quella di C++ ed è
pertanto un linguaggio economico ma non complicato. I programmatori avvezzi a Visual Basic
(VB) probabilmente non troveranno di loro gradimento la sintassi ed avvertiranno la mancanza di
alcuni dei più simpatici costrutti sintattici di VB, come Select Case.
Java è inoltre completamente ad oggetti, perfino più di C++. Tutto in Java, ad eccezione di alcuni
tipi basilari come i numeri, è un oggetto: la progettazione ad oggetti ha sostituito le prime tecniche
strutturate perché presenta molti vantaggi nel gestire progetti sofisticati. Per quanti non hanno
confidenza con la programmazione ad oggetti (OOP, Object Oriented Programming).
Tuttavia, avere un ulteriore dialetto di C++, alquanto migliorato non sarebbe abbastanza. Il punto
essenziale è questo: è molto più facile produrre un codice privo di bug con Java che con C++.
152
Gli autori di Java hanno, infatti, meditato a fondo su quello che provoca così tanti errori nel codice
C++ ed hanno aggiunto in Java funzioni che eliminano la possibilità di creare codice con i tipi più
frequenti di bug (secondo alcune stime, circa una riga ogni 50 di codice C++ contiene almeno un
bug).
L’allocazione e la deallocazione manuali della memoria sono state eliminate in Java.
La memoria in Java viene automaticamente sottoposta a garbage collection (ripulitura di
spazio). Gli sprechi di memoria non devono mai costituire una preoccupazione.
Sono stati introdotti veri array ed è stata eliminata l’aritmetica dei puntatori. Non bisognerà mai
preoccuparsi di sovrascrivere un’area di memoria essenziale a causa di un errore quando si
lavora con un puntatore.
E’ stata eliminata la possibilità di confondere un’assegnazione con una verifica dell’uguaglianza
in un’istruzione condizionale. Non è neanche possibile compilare: if (ntries = 3)… I
programmatori in VB forse non ne vedranno il problema, ma si tratta di una causa frequente di
confusione nel codice C/C++.
E’ stata eliminata l’ereditarietà multipla, sostituita dal nuovo concetto di interfaccia, trattato da
Object C. Le interfacce presentano i vantaggi dell’ereditarietà multipla senza la complessità che
comporta la gestione di più gerarchie di ereditarietà.
La specifica del linguaggio Java è pubblica. E’ possibile trovarla nel Web accedendo alla home
page Java e seguendo i collegamenti presenti in essa (http://java.sun.com).
9.6. Caratteristiche di Java
Semplice
Si desiderava costruire un sistema che potesse essere programmato facilmente, senza richiedere una
formazione pesante e riservata a pochi adepti, e che facesse leva sull’attuale pratica standard. Così,
anche se il C++ non è stato ritenuto idoneo, Java è stato progettato attenendosi quanto più possibile
a C++, per rendere il sistema più comprensibile. In Java sono state omesse molte funzioni raramente
utilizzate, mal comprese e fuorvianti di C++ che, secondo l’esperienza, arrecano più dolori che
benefici.
La sintassi di Java è, in effetti, una versione “ripulita” di quella di C++. Non richiede file di
intestazione, un’aritmetica dei puntatori (né peraltro una sintassi dei puntatori), strutture, unioni,
ridefinizione degli operatori, classi e basi virtuali e così via. Gli autori non hanno tuttavia migliorato
alcune caratteristiche poco pratiche di C++, quali l’istruzione switch. Chi conosce C++ passerà
agevolmente alla sintassi Java.
153
I programmatori VB non troveranno invece semplice il linguaggio Java. Vi sono molti elementi
strani nella sintassi (anche se non è richiesto molto tempo per impararli). Ancora più importante, in
Java è necessaria molta più programmazione. Il lato positivo di VB è che il suo ambiente visivo
fornisce quasi automaticamente buona parte dell’infrastruttura per un’applicazione. La funzionalità
equivalente in Java deve essere programmata manualmente, di norma con abbondante codice. Allo
stato attuale, Java è piuttosto semplice, come tutti i linguaggi ad oggetti. Esistono tuttavia molte
sottigliezze che occorre conoscere per risolvere problemi reali. Con il passare del tempo, un numero
crescente di questo dettagli sarà demandato alle librerie ed agli ambienti di sviluppo. Prodotti come
Java WorkShop, Symantec Visual Cafè e Inprise Jbuilder possiedono generatori di form che
facilitano l’impostazione dell’interfaccia dei programmi. Questi componenti sono tutt’altro che
preferiti ma rappresentano un passo avanti. Una dotazione in costante crescita di librerie di classi di
terze parti e numerosi esempi di codice (tra cui molte librerie) sono disponibili gratuitamente sulla
rete. Un altro aspetto della semplicità è la dimensione limitata. Uno degli obiettivi di Java consiste
nel consentire la costruzione di software “stand alone” in piccoli computer. La dimensione
dell’interprete di base e del supporto delle classi è di circa 40Kb; aggiungendo le librerie standard di
base ed il supporto dei thread (essenzialmente un microkernel autonomo), la dimensione aumenta di
altri 175Kb.
Questo è un grande risultato. Si noti tuttavia che le librerie di GUI sono significativamente più
voluminose.
Ad oggetti
In termini semplici, la progettazione ad oggetti è una tecnica di programmazione che si concentra
sui dati (oggetti) e sulle relative interfacce. Per seguire un’analogia con la falegnameria, un
falegname “orientato agli oggetti” si preoccuperebbe principalmente della sedia che sta costruendo
e secondariamente degli strumenti impiegati per crearla, mentre un falegname “non orientato agli
oggetti” penserebbe prima agli strumenti. I servizi ad oggetti di Java sono essenzialmente quelli di
C++. La programmazione ad oggetti ha dimostrato il suo valore negli ultimi 30 anni ed è
inconcepibile che un linguaggio moderno non l’adotti. Le funzioni ad oggetti di Java sono di fatto
paragonabili a quelle di C++. Le differenze principali tra Java e C++ risiedono nell’ereditarietà
multipla, che in Java è stata sostituita da una soluzione migliore, e nel modello di metaclassi di
Java. Il meccanismo di riflessione e la funzione di serializzazione degli oggetti facilitano
sensibilmente l’implementazione di oggetti persistenti e costruttori di GUI che possono integrare
componenti pronti all’uso.
154
Distribuito
Java possiede un’estesa libreria di routine per gestire i protocolli TCP/IP quali http e FTP. Le
applicazioni Java possono aprire oggetti ed accedere ad essi attraverso la rete tramite URL con la
stessa agevolezza con cui accedono ad un file system locale.
Le funzionalità di rete di Java sono risultate solide e facili da usare. Chiunque abbia cercato di
programmare in internet, avvalendosi di un altro linguaggio, potrà confermare quanto Java
semplifichi le operazioni onerose quali l’apertura di una connessione socket. Java facilità perfino la
creazione di script CGI (Common Gateway Interface). Un meccanismo elegante, dal nome servlet,
rende estremamente efficienti le elaborazioni per i server in Java. Molti diffusi server Web
supportano il meccanismo servlet. Il meccanismo di chiamata con metodo remoto consente la
comunicazione tra oggetti distribuiti.
Robusto
Java è destinato a scrivere programmi che devono essere affidabili in vari modi. Java insiste molto
sul controllo iniziale degli eventuali problemi, al successivo controllo dinamico (runtime) e
sull’eliminazione di situazioni che possano comportare errori. La principale differenza tra Java e
C/C++ è che Java ha un modello di puntatori che esclude la possibilità di sovrascrivere la memoria
e rovinare i dati.
Anche questa funzione è molto utile. Il compilatore Java (sia nella versione originale, sia nelle varie
versioni perfezionate di terze parti) riscontra molti problemi che, in altri linguaggi, si rivelano solo
in fase di esecuzione (e forse neanche allora). Per quanto riguarda il secondo punto, chiunque abbia
perso ore intere alla ricerca del danno alla memoria causato da un bug di un puntatore apprezzerà
molto questa funzione di Java.
Chi proviene da un linguaggio come VB, che non usa esplicitamente i puntatori, probabilmente si
chiederà perché ciò sia tanto importante. I programmatori in C sono meno fortunati: necessitano,
infatti, dei puntatori per accedere a stringhe, array, oggetti e perfino file. In VB non vengono
utilizzati puntatori per alcuna di queste entità, né occorre preoccuparsi della loro allocazione di
memoria. Viceversa, se vengono realizzate alcune delle strutture di dati più complesse di VB che
richiedono i puntatori con i moduli di classi, occorre gestire manualmente la memoria. Java offre il
meglio di entrambi i sistemi: i puntatori non sono necessari per i costrutti quotidiani quali le
stringhe e gli array, ma la loro potenza è disponibile all’occorrenza, per esempio per gli elenchi
collegati. Inoltre, la sicurezza assoluta è sempre garantita, in quanto non è mai possibile accedere ad
un puntatore pericoloso o commettere errori di allocazione della memoria, né ci si deve mai
preoccupare degli sprechi di memoria.
155
Sicuro
Java è destinato all’impiego in ambienti di rete/distribuiti. A questo fine si è molto insistito sulla
sicurezza. Java consente la costruzione di sistemi privi di virus ed al sicuro da interferenze
indesiderate, anche se questo non è possibile al cento per cento. Infatti, un gruppo di esperti di
sicurezza ha continuato a riscontrare dei bug nei meccanismi di sicurezza di tutte le versioni di Java.
E’ consigliabile visitare l’indirizzo http://www.cs.princeton.edu/sip/ (URL del gruppo di Princeton)
ed il newsgroup comp.risks per conoscere opinioni di consulenti esperti riguardo allo stato
attuale dei meccanismi di sicurezza di Java.
Il lato positivo è che l’equipe di Java ha affermato di avere una “tolleranza zero” nei confronti delle
lacune in materia di sicurezza e che pertanto si metterà immediatamente all’opera per correggere gli
eventuali bug rilevati nel meccanismo di sicurezza delle applet (anche i produttori di browser si
sono messi subito al lavoro). In particolare, rendendo pubbliche le specifiche interne della modalità
di funzionamento dell’interprete Java, Sun facilità sensibilmente il reperimento dei bug nelle
funzioni di sicurezza di Java, coinvolgendo la comunità esterna nel delicatissimo compito di
rilevamento dei bug di sicurezza. Questo consente di sperare che presto si riuscirà ad ovviare agli
errori della sicurezza. In ogni caso, è estremamente difficile ingannare i meccanismi di sicurezza di
Java: i bug trovati finora sono impercettibili e relativamente scarsi. L’URL di Sun per le questioni
legate alla sicurezza è attualmente http://java.sun.com/sfaq.
Riportiamo un esempio delle operazioni che le funzioni di sicurezza di Java impediscono ad un
programma Java di compiere:
1. Overrun dello stack runtime, come ha fatto lo scellerato “worm” di Internet.
2. Danneggiamento della memoria all’esterno del suo spazio di elaborazione.
3. Lettura o scrittura di file locali richiamati tramite un’applicazione di caricamento di classi
sensibili alla sicurezza, come un browser Web programmato per impedire questo tipo di
accesso.
Tutte queste funzioni sono installate e per lo più sembrano conformi alle aspettative. Java è
sicuramente il linguaggio di programmazione finora più sicuro, ma la cautela è sempre d’obbligo:
anche se i bug finora riscontrati nel meccanismo di sicurezza non sono risultati banali da trovare
neanche se i dettagli completi sono soventemente tenuti segreti, può essere comunque impossibile
dimostrare che Java è sicuro. Non resta quindi che ribadire che nessun software è sicuro al cento per
cento.
Al momento le classi sono firmate: una classe firmata consente di sapere con certezza chi è l’autore.
Una volta installato un meccanismo di firma, le classi di un autore ritenuto affidabile possono
ricevere più privilegi in un computer.
156
Un meccanismo concorrente di trasmissione di codice, elaborato da Microsoft e basato sulla
tecnologia ActiveX, affida la sicurezza esclusivamente alle firme digitali. Evidentemente, questo
non è sufficiente: come può confermare qualsiasi utente dei prodotti Microsoft, i prodotti di case
costruttrici famose si bloccano e creano in tal modo danni. Java possiede un modello di sicurezza
molto più forte di ActiveX, in quanto controllo l’applicazione mentre viene eseguita e le impedisce
di compiere scempi (per esempio, è possibile impedire l’input e l’output di file locali anche per le
classi firmate).
Indipendente dall’architettura
Il compilatore genera un formato di file oggetto indipendente dall’architettura: il codice compilato è
eseguibile in molti processori, data la presenza del sistema runtime Java. Il compilatore Java genera,
infatti, istruzioni di bytecode che non hanno nulla a che vedere con una specifica architettura di
computer e che sono invece progettati per risultare facilmente interpretabili in qualsiasi computer e
facilmente traducibili “al volo” nel codice macchina nativo.
Questa idea non è nuova: più di 20 anni fa, il sistema UCSD Pascal svolgeva la stessa funzione in
un prodotto commerciale; ancora prima, l’implementazione originale di Pascal realizzata da Niklaus
Wirth adottava lo stesso concetto. Con l’impiego dei bytecode, le prestazioni risultano
sensibilmente peggiori (ma i compilatori just in time riducono in molti casi questo effetto). Gli
autori di Java hanno sviluppato un ottimo set di istruzioni di bytecode, ben funzionante nelle
architetture di computer attualmente più diffuse. Il codice è stato progettato in modo tale da essere
facilmente traducibile in vere e proprie istruzioni macchina.
Portabile
Contrariamente a C e C++, la specifica di Java non prevede aspetti “dipendenti
dall’implementazione”. Le dimensioni dei tipi di dati primitivi sono specificate, così come il
comportamento della loro aritmetica. Per esempio, in Java un int è sempre un intero a 32 bit,
mentre in C/C++ può significare un intero a 16 bit, un intero a 32 bit o qualsiasi altra dimensione
che il produttore del compilatore desidera. L0unico limite è che il tipo int deve avere un numero
di byte almeno pari a quello di short int e non superiore a quello di long int. La
dimensione fissa dei tipi di numeri ovvia ad un serio inconveniente relativo alla portabilità: i dati
binari vengono memorizzati in un formato fisso, eliminando la confusione tra “estremità grande” e
“estremità piccola”. Le stringhe vengono salvate in formato Unicode standard.
Le librerie appartenenti al sistema definiscono interfacce portabili. Per esempio, esiste una classe
Window astratta e una sua implementazione per Unix, Windows e Macintosh.
157
Scrivere un programma che si presenti bene in Windows, Macintosh e in 10 varianti di Unix è uno
sforzo di proporzioni immense. Java ha compito la prodezza epica, fornendo un toolkit semplice che
mappava gli elementi comuni dell’interfaccia utente in numerose piattaforme. Sfortunatamente ne è
scaturita una libreria che, oberata di lavoro, riusciva a dare risultati appena accettabili nei diversi
sistemi (si verificavano inoltre bug diversi sulle implementazioni grafiche delle diverse
piattaforme). In molte applicazioni la portabilità è più importante del grado eccelso di abilità: queste
applicazioni hanno tratto vantaggio dalle prime versioni di Java. Il toolkit dell’interfaccia utente è
stato ormai completamente riscritto in modo tale da non basarsi più sull’interfaccia utente dell’host.
Il risultato è molto più uniforme e più gradevole di quello delle versioni iniziali di Java.
Interpretato
L’interprete Java può eseguire bytecode Java direttamente in qualsiasi computer in cui sia stato
trasportato l’interprete. Poiché il linking è un processo più incrementale è leggero, il processo di
sviluppo può essere molto più rapido ed esplorativo.
Questo è forse un vantaggio mentre si sviluppa un’applicazione, ma è chiaramente espresso in
termini esagerati. In ogni caso, sì è riscontrato che il compilatore Java è piuttosto lento. Chi è
abituato alla velocità del ciclo di sviluppo di VB p di Delphi probabilmente rimarrà deluso.
Ad alte prestazioni
Anche se le prestazioni dei bytecode interpretati sono solitamente più che adeguate, vi sono
situazioni in cui sono necessarie prestazioni superiori. I bytecode possono essere tradotti al volo (in
fase di esecuzione) nel codice macchina della CPU specifica in cui l’applicazione è in esecuzione.
Se si usa l’interprete Java standard per tradurre i byte code, “alte prestazioni” non sembra essere il
termine esatto: “da mediocre a scarso” è probabilmente la definizione più precisa. Anche se è
sicuramente vero che la velocità dei bytecode interpretati può essere accettabile, non si può dire che
essi siano veramente rapidi (nel migliore dei casi, Java nel corso delle prove è risultato solo
leggermente più veloce di VB4 e non altrettanto veloce quanto le ultime versioni di VB). Viceversa,
può essere utile eseguire molti programmi Java tramite un vero compilatore e non limitarsi
all’interpretazione dei bytecode. Per esempio, questo sarà quasi sicuramente necessario per
qualsiasi programma destinato a diventare applicazione autonoma in una macchina specifica. In
definitiva, occorrerà un compilatore per ogni piattaforma.
Sono disponibili alcuni compilatori di codice nativo per Java, prodotti per esempio da Asymetrics,
Symantec e IBM. Esiste anche un’altra forma di compilazione, quella dei compilatori just in time
(JIT), che funzionano compilando una volta i bytecode nel codice nativo, inserendo in una cache i
158
risultati e quindi richiamandoli nuovamente all’occorrenza. Questa impostazione accelera
sensibilmente i loop, in quanto l’interpretazione deve essere eseguita una sola volta. Sebbene sia
sempre leggermente più lento di un vero e proprio compilatore di codice nativo, un compilatore just
in time può accelerare di 10 o perfino di 20 volte l’esecuzione di alcuni programmi e quasi sempre
risulta significativamente più veloce dell’interprete Java. Questa tecnologia è in continuo
miglioramento e potrebbe finire per dare risultati non raggiungibili dai sistemi di compilazione
tradizionali. Per esempio, un compilatore just in time può verificare quale codice viene eseguito
frequentemente ed ottimizzare solo tale codice per la velocità.
Multithreaded
I vantaggi del multithreading sono una migliore risposta interattiva ed un comportamento in tempo
reale.
Chi ha già provato a realizzare il multithreading in un altro linguaggio rimarrà piacevolmente
sorpreso nel riscontrare quanto esso sia facile in Java. I thread in Java hanno anche la possibilità di
avvalersi dei sistemi multiprocessore, se il sistema operativo di base è in grado di gestirli. Il lato
negativo è che le implementazioni dei thread sulle principali piattaforme differiscono sensibilmente
e Java non compie alcuno sforzo per ottenere l’indipendenza dalla piattaforma a questo proposito.
Solo il codice per chiamare il multithreading rimane invariato in tutte la macchine; Java demanda la
realizzazione del multithreading al sistema operativo sottostante. Tuttavia, l’agevolezza del
multithreading è uno dei motivi principali per cui Java è un linguaggio che esercita una forte
attrattiva nei riguardi dello sviluppo dei server.
Dinamico
Da molti punti di vista, Java è un linguaggio più dinamico di C o C++. E’ studiato per adattarsi ad
un ambiente in evoluzione. Le librerie possono aggiungere liberamente nuovi metodi e nuove
variabili istanza senza alcun effetto sui rispettivi client. In Java è semplice trovare informazioni sui
tipi runtime.
Questa è una funzione importante nelle situazioni in cui occorre aggiungere codice ad un
programma in esecuzione. Un ottimo esempio è il codice prelevato da internet per essere eseguito in
un browser. In Java 1.0, il reperimento di informazioni sui tipi runtime era tutt’altro che semplice,
ma le versioni attuali di Java danno al programmatore un quadro approfondito sia della struttura sia
del comportamento dei suoi oggetti. Questo è estremamente utili per i sistemi che richiedono di
analizzare gli oggetti in fase di esecuzione, quali i costruttori di GUI, i debugger intelligenti, i
componenti plugin ed i database di oggetti.
159
Appendice
Red Hat: disponibile la versione 7.3 Professional
Durante la stesura di questa tesi, Red Hat ha rilasciato la versione 7.3 Professional della sua
distribuzione Linux. Abbiamo quindi pensato di scrivere una breve recensione in modo da
evidenziarne le novità e le migliorie rispetto alla precedente versione.
L’offerta di Red Hat nel campo delle distribuzioni Linux si compone di un prodotto, Red Hat Linux
7.3, rilasciato in due edizioni destinate a fasce di pubblico differenti: Red Hat Linux 7.3 Personal,
distribuzione adatta all’uso personale e indirizzata a tutti coloro che fossero interessati a provare
Linux, e Red Hat Linux 7.3 Professional, più adatta a un uso aziendale e in grado di ospitare server
Web, di posta elettronica o firewall di piccole e medie dimensioni.
Occorre notare come Red Hat abbia recentemente affiancato a questi prodotti una distribuzione che
si rivolge al mercato hi-end: Red Hat Linux Advanced Server è il primo componente di una
piattaforma che intende offrire una valida per le medie e le grosse aziende che attualmente
utilizzano i sistemi Unix di Sun e HP. Il prodotto, rilasciato nel mese di Aprile 2001, include
funzionalità destinate ai server di fascia alta, come il supporto alle interfacce di connessione a banda
larga, funzionalità di bilanciamento del carico, capacità di clustering e software par la gestione dei
failover, inoltre a questo prodotto sono associati servizi di supporto adatti al mercato enterprise
(assistenza 24 ore su 24, garanzia di tempi minimi di risposta e così via).
> I contenuti
La confezione di Red Hat Linux 7.3 Professional è composta da 9 Cd-Rom (3 contenenti il sistema
operativo, 2 i codici sorgenti, 1 per le applicazioni commerciali di produttività e 1 per le
applicazioni server, 1 con la documentazione e infine 1 per StarOffice 5.2) cui aggiungerne uno
ulteriore di dimensioni ridotte, contenente gli strumenti per l’amministratore di sistema. Inoltre sono
presenti 3 manuali in lingua italiana e una Quick Installation Guide che guida l’utente in 19
passaggi fino al completamento dell’installazione del prodotto.
Fra i contenuti dei Cd-Rom contenenti le applicazioni commerciali di produttività citiamo Acrobat
Reader per Linux, Forte per Java e Java2 Platform di Sun Microsystems per gli sviluppatori e
l’utility di compressione Stuffit Expander; inoltre si trovano le versioni dimostrative del sistema di
modellazione tridimensionale AC3D, del fax server Fax2Send 2.1, dello strumento per l’analisi dei
dati Dataplore di Datan, di Compupix di Photodex per l’editing delle immagini e infine il pacchetto
Cad 2D/3D VediCad 8.1. Il Cd-Rom delle applicazioni server contiene invece il sistema di gestione
160
degli account e dei privilegi Novell eDirectory 8.6.2 (basato su Ldap), Novell Internet Messaging
System 3.0, sistema che offre servizi di posta elettronica di calendaring, oltre che le versioni
dimostrative del sistema di gestione dello storage NetVault 6.5.1 di BackBone Software, il
pacchetto di backup Arkeia 4.2.8 di Knox Software ed infine Coldfusion Server 5 e JRun Server 3.1
di Macromedia per lo sviluppo di e il deployment di applicazioni Web basate sulle tecnologie Java e
ColdFusion. Con l’edizione Personal del prodotto vengono offerti 60 giorni di assistenza telefonica
o via Web all’installazione e un periodo di 60 giorni del servizio di base di Red Hat Network, che
permette di creare un profilo personalizzato per il download e l’aggiornamento automatico del
software installato. Red Hat offre inoltre la possibilità di estendere il periodo di assistenza mettendo
a disposizione diversi tipi di contratti (a questo proposito si faccia riferimento alla pagina Web
www.redhat.it/products/).
L’edizione Personal si distingue dalla Professional per l’assenza del Cd-Rom contenente le
applicazioni server e dei 3 manuali, oltre che per il ridotto periodo di assistenza (fornito
esclusivamente via Web) e di utilizzo di Red Hat Network, ambedue limitati a 30 giorni.
> Installazione
Le procedure d’installazione non hanno subito notevoli modifiche rispetto alle precedenti release
della serie 7.x: dopo le consuete fasi di autorilevamento dell’hardware e di selezione della lingua, in
pochi passi si potrà giungere alla schermata, tipica delle distribuzioni Red Hat, nella quale l’utente
può scegliere la modalità d’installazione. Le opzioni sono, come di consueto, Workstation, che
permette di includere i pacchetti office e i client di rete, Server, per installare la maggior parte dei
servizi di rete quali, ad esempio, Apache, Sendmail, i database server MySql e PostgreSql e così
via, e Laptop, da selezionare nel caso si stia installando il sistema operativo su un portatile.
Selezionando una di queste opzioni, il programma d’installazione tenterà di completare molte
operazioni in maniera automatica: per avere un maggior controllo non solo sui pacchetti da
installare, ma anche sulle procedure di partizionamento del disco e sull’installazione del boot
loader, occorrerà scegliere un’installazione di tipo Custom, più adatta agli utenti esperti e mirata
all’ottenimento di configurazioni particolari. Le procedure di installazione sono prive di inutili
fronzoli e pur non essendo le migliori del lotto per quanto riguarda semplicità d’uso, risultano
comunque di buon livello e ottime per quanto concerne la rilevazione dell’hardware.
> Le prime impressioni
Terminata l’installazione, il sistema viene riavviato e, qualora sia stato installato il server XFree e
un window manager, presenta all’utente la schermata grafica di login. Red Hat 7.3 è corredata da
161
una discreta quantità di tool e di software: da questo punto di vista la situazione è migliorata rispetto
alle precedenti versioni (soprattutto nell’ambito del software multimediale), ma non è ancora al
livello d’alcune distribuzioni concorrenti. Occorre tuttavia rimarcare come questa scelta rifletta il
pubblico cui questa distribuzione si rivolge: Red Hat ha privilegiato l’utenza aziendale che necessita
di un numero contenuto di pacchetti cui poter affidare alcuni compiti, piuttosto che quella degli
“smanettoni”, che invece sono maggiormente attratti dalla possibilità di provare e adattare il
software alle proprie esigenze.
La distribuzione si basa sul recente kernel 2.4.18, compilato in diverse versioni ottimizzate sia per
piattaforme a singolo processore che multiprocessore, e mette a disposizione dell’utente il
compilatore Gnu C (gcc) e tutti gli strumenti di sviluppo disponibili, così come i demoni per la
maggior parte dei servizi Internet. Sono supportati tutti i principali linguaggi di programmazione.
La gestione del software si basa, come di consueto per le distribuzioni dal cappello rosso, su Rpm
(Red Hat Package Manager), tool in grado di aiutare gli amministratori nel compito di installare,
aggiornare, rimuovere e gestire il software. Occorre notare come la maggior parte del software
precompilato scaricabile da Internet sia fornito in questo formato, che nel corso degli anni è stato
adottato come standard “de facto” da molte distribuzioni.
Red Hat 7.3 Professional offre un aggiornamento per la maggior parte dei pacchetti rispetto alle
precedenti edizioni: notiamo come sia stato scelto di includere l’ultima versione del server Web
Apache release 1.3, serie notevolmente più sperimentata rispetto alla più recente 2.0.
> L’ambiente grafico e il software multimediale
Le più grandi novità rispetto alla versione 7.3 sono relative all’interfaccia grafica: Red Hat 7.3
include infatti la nuova versione 3.0 di Kde. Così come il suo concorrente Gnome 2.0, non ancora
disponibile ma che probabilmente sarà già stato rilasciato al momento in cui leggerete questa
recensione, Kde 3.0 non è un semplice window manager: esso, infatti, oltre all’ambiente grafico
(localizzato in 50 lingue) fornisce un ambiente integrato di sviluppo e applicazioni di ogni genere
(amministrazione, entertainment, ambienti di sviluppo, giochi, applicazioni multimediali e così via).
Una delle principali nuove funzionalità integrate in Kde 3.0 è il nuovo framework per la stampa, in
grado di supportare differenti sistemi di stampa, quali Cups, Lprng, Lpr, Lpd ed altri. Le principali
novità di Kde 3 rispetto alle release precedenti si trovano comunque in Konqueror, il browser/file
manager. Il motore di rendering di Konqueror, che dispone finalmente di un’implementazione
integrale del modello Dom, supporta ora in maniera completa JavaScript e DHtml (così come Java).
E’ compatibile con gli standard Xml 1.0 e Html 4.0 e supporta i fogli di stile (CCS-1 e CCS-2). E’
inoltre compatibile con i plug-in di Netscape Communicator (per esempio Flash, RealAudio e
162
RealVideo) e, grazie ad add-on commerciali di Codeweavers (www.codeweavers.com), anche con i
plug-in Windows come, ad esempio, Macromedia Shockwave Player, Quicktime e Windows Media
Player 6.5. Come file manager, il nuovo Konqueror è in grado di visualizzare una serie di
informazioni addizionali riguardo ai file (come il tag ID3 dei file Mp3 oppure i commenti per le
immagini Jpeg). Inoltre è in grado di fornire “preview” dei file multimediali al semplice passaggio
del mouse sulle icone.
Le caratteristiche multimediali di Kde 3 sono ulteriormente arricchite dai numerosi strumenti di cui
era già dotata la release precedente dell’ambiente grafico. In particolare il player multimediale
noatun supporterà un maggior numero di formati: oltre a .wav ed .mp3, noatun può essere utilizzato
per ascoltare musica in formato OggVorbis e vedere filmati in formato DivX.
> Il software da ufficio
L’aggiornamento di Gnome alla versione 1.4, e conseguentemente la presenza di Nautilus in
versione 1.0, ha portato all’inclusione nella distribuzione delle più recenti versioni degli altri
pacchetti di Ximian, e nello specifico del Pim (Personal Information Manager) Evolution. Il
pacchetto integra funzionalità relative alla gestione della posta elettronica, all’organizzazione degli
appuntamenti e alla gestione del calendario. Evolution è compatibile con i protocolli Smtp (anche
con autorizzazione), Pop3 e Imap4; è inoltre disponibile un add-on (non gratuito) per l’integrazione
del client con i server Microsoft Exchange 2000 (Ximian Connector – si consulti a questo proposito
la pagina Web www.ximian.com/products/connector/). Evolution è in grado di importare mailbox
create con Netscape, Outlook Express, Eudora e altri software per la gestione della posta
elettronica. Gli utenti abituati all’utilizzo di Microsoft Outlook si troveranno a proprio agio nel
nuovo ambiente, dotato in pratica d’ogni funzionalità propria della controparte per i sistemi
operativi della casa di Redmond.
Per quanto riguarda la suite per ufficio, segnaliamo KOffice, la suite integrata in Kde, e il più
evoluto StarOffice 5.2. KOffice, di cui è attualmente disponibile la beta della versione 1.2 ed è
incluso in Red Hat 7.3 nella versione 1.1, si compone di tutti gli strumenti essenziali al lavoro da
ufficio: KWord è il word processor, KSpread il foglio elettronico, KPresenter il programma di
presentazione, Kivio è il tool per la creazione di diagrammi, Kontour l’applicazione di disegno
vettoriale, Krita il programma di fotoritocco, Kougar server per la creazione dei report e infine
KChart per la creazione di grafici. Occorre segnalare l’ottima integrazione della suite con ambiente
grafico Kde e la buona maturità dei prodotti patisce il grosso limite di non essere compatibile con il
formato dei file della suite Microsoft Office, ormai uno standard con il quale le suite per ufficio si
devono confrontare se vogliono sperare di essere adottate in ambiente aziendale.
163
StarOffice di Sun Microsystems, l’altra suite inclusa nell’offerta di Red Hat 7.3, si è invece
dimostrata molto valida, anche se non perfetta, nel trattare i documenti di Word ed Excel, ma
risente invece del difetto di non essere per nulla integrata negli ambienti grafici Kde o Gnome. La
suite, inclusa nella versione 5.2 in luogo della recentissima 6.0 che è ora disponibile solo a
pagamento, suscita da tempo interesse da parte di moltissimi utenti in quanto alternativa al già citato
pacchetto Microsoft Office: StarOffice è infatti disponibile non solo per Linux, ma anche per i
sistemi operativi Windows. La suite si compone di diversi applicativi: StarOffice Writer, il word
processor; StarOffice Calc, il foglio elettronico; StarOffice Impress, il programma di presentazione;
StarOffice Draw, il modulo per il disegno vettoriale; StarOffice Base, il tool di gestione delle basi di
dati. Infine sono presenti i moduli di StarOffice Schedule e StarOffice Mail and Discussion per la
gestione degli appuntamenti (organizer) e della posta elettronica e dei messaggi Usenet.
Gli applicativi di StarOffice si dimostrano certamente validi per il normale lavoro da ufficio: gli
utenti già abituati a Microsoft Office o ad altre suite si troveranno prevedibilmente a proprio agio e
non avranno alcuna difficoltà nel nuovo ambiente di lavoro.
> Gli strumenti d’amministrazione
Uno dei settori nei quali maggiormente le distribuzioni si differenziano le une dalle altre, oltre alle
routine d’installazione, è quello degli strumenti d’amministrazione. Molti dei “guru” di Linux
preferiscono usare tool a linea di comando per portare a termine compiti di amministrazione, così da
poter creare script per l’automatizzazione delle procedure ed evitare inoltre di installare sui propri
server interfacce grafiche che appesantirebbero inutilmente il sistema e potrebbero essere causa di
bug e problemi di sicurezza. Tuttavia Linux non avrebbe alcuna speranza di conquistare sempre
maggiore attendibilità per gli utenti aziendali se non offrisse strumenti d’amministrazione più
semplici, amichevoli e dotati di un’interfaccia grafica.
Red Hat offre all’utente e all’amministratore molti strumenti che garantiscono la possibilità di
configurare e personalizzare ogni aspetto del sistema e dei servizi di rete senza che sia necessario
ricorrere a criptici comandi da digitare alla console. L’ottima qualità dei molti strumenti non ci
impedisce tuttavia di avanzare qualche annotazione in merito alla mancanza di un unico tool di
gestione centralizzata che integri l’amministrazione di ogni aspetto del sistema, sul modello
dell’eccellente YaST2 di cui è da tempo dotata la distribuzione SuSE Linux.
> Conclusioni
Red Hat 7.3 non tradisce le attese, fornendo un upgrade dei pacchetti inclusi nella versione 7.2 e
introducendo, tra le principali novità, la nuova versione 3.0 dell’interfaccia grafica Kde che offre
164
rinnovati e potenziati strumenti soprattutto nell’ambito del software multimediale. Una citazione
particolare merita l’eccellente documentazione cartacea fornita nella confezione. I tre manuali in
lingua italiana coprono ogni argomento in maniera precisa ed esaustiva: la Getting stated guide è
indirizzata all’utente alle prime armi che viene guidato nelle più semplici operazioni quali l’utilizzo
del software e degli ambienti grafici e le prime configurazioni del sistema.
Il manuale intitolato Customization guide copre gli aspetti della configurazione del sistema (rete,
stampanti, procedure di avvio, moduli del kernel) con l’ausilio degli stumenti di amministrazione.
Infine la Reference guide si rivolge all’amministratore e copre aspetti quali, ad esempio, la struttura
del file system/proc, il file system journaled ext3, Pam, Kerberos, l’installazione e la configurazione
del pacchetto Tripwire oltre che l’attivazione dei principali servizi di rete, quali Nfs, Ldap e Bind.
> Requisiti Hardware
Si consulti l’hardware compatibility list all’indirizzo segnalato per informazioni sull’hardware
supportato. I requisiti minimi per la versione destinata alle piattaforme Intel o compatibili sono una
Cpu Intel di classe Pentium o superiore (è raccomandata una Cpu con frequenza di clock superiore a
200 MHz), almeno 650 MByte di spazio su disco (sono raccomandati 2,5 GByte per
un’installazione tipica e 4,5 GByte per l’installazione completa), almeno 32 MByte di memoria
Ram per l’utilizzo del sistema operativo in modalità testuale ed almeno 64 MByte per disporre
dell’interfaccia grafica (sono raccomandati almeno 96 MByte).
> Indirizzi Internet utili
Hardware compatibility list: http://hardware.redhat.com/
Download: www.redhat.com/download/howto_download.html
Red Hat Network: http://rhn.redhat.com
StarOffice 6.0: http://wwws.sun.com/software/product_family/staroffice.html
Upgrade per gli utenti di Red Hat Linux 6.2 o successiva, SuSE Linux 7.3 o 8.0, Mandrake Linux
8.1 o 8.2: www.europe.redhat.com/upgrade_rebate/
> I costi
Red Hat 7.3 Personal: € 117,01
Red Hat 7.3 Professional: € 320,43
Red Hat 7.3 Personal Upgrade: € 10,00
Red Hat 7.3 Professional Upgrade: € 20,00
165
Bibliografia
1. AAVV, PC Professionale n°106 Gennaio 2000, Mondadori Informatica
2. AAVV, PC Professionale n°107 Febbraio 2000, Mondadori Informatica
3. AAVV, PC Professionale n°112 Luglio 2000, Mondadori Informatica
4. AAVV, PC Professionale n°114 Settembre 2000, Mondadori Informatica
5. AAVV, PC Professionale n°138 Settembre 2002, Mondadori Informatica
6. http://www.redhat.com (Sito ufficiale Red Hat inglese) e www.redhat.it/products/ (Info su
prodotti ed assistenza)
7. http://www.redhat.it (Sito ufficiale Red Hat italiano)
8. http://www.linuxdoc.org (Linux Documentation Project versione inglese)
9. http://www.pluto.linux.it/ildp (Linux Documentation Project versione italiana)
10. http://www.samba.org
11. http://lisa-home.sourceforge.net (LAN Browsing)
12. http://www.starnet.com (X-Win32)
13. http://www.apache.org
14. www.securityfocus.com (Mailing list Bugtraq mantenuta da SecurityFocus sulla sicurezza di
Apache)
15. www.cert.org/advisories/ (Bollettini del Cert (Computer Emergency Response Team sulla
sicurezza di Apache)
16. http://www.twiki.org
17. http://java.sun.com e http://java.sun.com/sfaq (Sito ufficiale per le questioni legate alla
sicurezza di Java)
18. Cay S. Horstmann, Gary Cornell, Java 2 I Fondamenti, Mc Graw Hill, 1999
19. http://www.cs.princeton.edu/sip/ (Gruppo di Princeton di esperti sulla sicurezza che cerca di
riscontrare dei bug nei meccanismi di sicurezza di Java)
20. Newsgroup comp.risks (Opinioni di consulenti esperti riguardo allo stato attuale dei
meccanismi di sicurezza di Java)
21. www.codeweavers.com (Add-On commerciali di Codeweavers per Konqueror)
22. www.ximian.com/products/connector/ (Add-On per l’integrazione con i server Microsoft
Exchange 2000)