Linux TIPS
I suggerimenti sono stati presi da riviste di informatica, da newsletters o da siti web
perciò ogni diritto rimane al legittimo proprietario.

 

http://www.openskills.info/view/search-engine.php?textsearch=&cerca=tutte&IDboxtype=all&LANGUAGE=ita&submit=Cerca+su+OpenSkills

Siti su Linux e Open Source in Italiano Siti sulla sicurezza in Italiano smbcacls (client per il management delle ACL dello share SMB in un server NT)
smbclient (condivisione risorse con Windows) smbcontrol (gestione dei deamon smb, nmbd e winbindd) smbd e nmdb (i demoni per la condivisione file e stampanti)
smbmnt, smbmount e smbwrapper (comendi Samba) smbpasswd (utlity per il cambio della password in Samba) smbtar
Software - il sistema operativo Software - Installazione di Linux Software - l'installazione
Software applicativo Software per server Internet Software RAID su Linux
sort (ordina le righe) ssh (client per l'accesso remoto) ssh -C user@server -L porta:serverportalocale
stat (visualizzazione informazioni utili sui file - dimensioni ecc) Status codes del protocollo HTTP Stop e restart di Apache
Storia dell'aggiornamento di un server LAMP (Linux, Apache, MySQL, PHP) in produzione Storia delle Applicazioni Web su (super user)
sudo (esegue un comando come un altro utente) Suse 9: logs management Suse 9: network configuration
Swat, utility di configurazione di Samba tar unmount
Upgrade di Apache uptime (visualizza da quanto tempo il sistema è attivo) Usare internet: panoramica sui software ed i protocolli
Usare pacchetti (RPM) per l'installazione di programmi linux userdel (cancella un account e i relativi files) usermod (cambia le impostazioni di un account creato precedentemente)
vi (Editor di testi) VPND, Virtual Private Network Daemon) Telnet e Principali comandi in Linux

Siti su Linux e OpenSource in italiano
La quantità di siti in lingua italiana che trattano di OpenSource e Linux è notevole.
Viene qui presentata una rassegna di quelli più significativi.
Alcuni sono siti di news e commenti, spesso basati sulla piattaforma PHP Nuke, altri sono informativi e divulgativi, altri presentano innumerevoli risorse e informazioni tecniche interessanti.
In tutti non mancano passione e intraprendenza da parte degli autori.
ZIO BUDDHA - www.ziobudda.net  - Italian Linux Portal
Uno dei primi e più conosciuti portali italiani su Linux: articoli, news, docs e info.
LINUX.HTML.IT - linux.html.it  - Risorse per gli utenti Linux
Una sezione completa di docs, info, software e articoli di HTML.it
LINUX.KUHT.IT - linux.kuht.it - Portale a tutto campo su Linux
Articoli, news, documentazione, link, risorse su Linux. Ottimo.
LINUX VALLEY - www.linuxvalley.it  - Portale su Linux
Informazioni, notizie, risorse, documentazioni e prodotti del mondo Linux.
WUP - www.wup.it  - L'alternativa italiana a Slashdot
Fra i siti ispirati a Slashdot, WUP è uno dei primi, più completi e più seguiti: Informazioni e news sul mondo informatico che cambia.
FEELING LINUX - www.feelinglinux.com  - Documentazione e approfondimenti.
Interessanti articoli sulla amministrazione e la programmazione Linux. Man Pages online.
PLUTO - www.pluto.linux.it  - Il Pluto è un gruppo di persone che, unito dalla passione per il software libero, realizza progetti per favorirne lo sviluppo sul territorio italiano.
DIFF - www.diff.org  - Il Vortal dei Sistemi Operativi Alternativi
Articoli, news e link su sistemi operativi e tecnologie informatiche alternative.
SPLATT - www.splatt.it  - Articoli e notizie sul mondo PHP Nuke.
Un buon punto di riferimento sull'universo Nuke e sul software Splatt Forum.
FREEX.CH - www.freex.ch  - News su Opensource e dintorni.
Sito Nuke con notizie, informazioni e articoli sull'opensource e il mondo IT.
ITALINUX - www.italinux.net  - News su Linux.
Sito Nuke on informazioni e notizie su Linux.
LINUX TOOLS - www.linux.it/ospiti/linuxtools/  - La bussola italiana del mondo Linux.
Completo elenco ragionato di link sull'universo Linux.
LINUX A SCUOLA - www.linuxascuola.it  - Info per scuole.
Informazioni sull'uso di Linux nelle scuole.
INFORMATICA E GNU/LINUX - vandali.org/DanieleMasini/infolinux.php  - E-Book FDL.
Completo e interessante e-book su Hardware, Informatica e Linux.
Questo elenco è in costante aggiornamento.
Usa i commenti di questo INFOBOX per segnalare ulteriori siti.

Siti sulla sicurezza in italiano
Fra i vari siti in lingua italiana che trattano di sicurezza si segnalano.
Portazero - http://www.portazero.info
News aggiornate e articoli interessanti sulla sicurezza.
Infosecurity - http://www.infosecurity.it
Una delle più importanti fiere in Italia esclusivamente dedicata all'Information Security
Sikurezza.org - http://www.sikurezza.org/
Home page di alcune delle più diffuse mailing list sulla sicurezza in italiano.
ClusIT - http://www.clusit.it/
Home Page della ASSOCIAZIONE ITALIANA PER LA SICUREZZA INFORMATICA, con documenti vari.
Bismark - http://www.bismark.it/
Portale su undeground, hacking e sicurezza informatica.

smbcacls
Client per il managment delle ACL delle share SMB in un server NT.
smbcacls //server1/share1 filename [options]
Opzioni Comuni:
-U Opzione per specificare l'utente utilizzato per conettersi al servizio remoto
-A [acls] Aggiunge una ACL all'access list specificata
-D [acls] Elimina le ACL specificate in linea di comando
-n Visualizza le ACL in formato numerico
Formato ACL:
Le ACL sono formate da singole o più entry separate dalla virgola o più semplicemente ogni entry deve corrispondere ad una nuova linea. Esempio:
Specifica il numero della revisione della ACL lato NT server
REVISION:<revision number>
Owner e Group specificano owner e group sid dell'oggetto
OWNER:<sid or name>
GROUP:<sid or name>
ACL
ACL:<sid or name>:<type>/<flags>/<mask>

smbclient
Ci sono diversi modi di accedere a risorse condivise con SMB e uno di questi è usare smbclient. Il suo uso non si discosta molto dall'usare un normale client ftp fuorchè il fatto che utilizza un diverso protocollo.
Questo comando è considerato tra i più usati della suite Samba. Non solo è una comoda utility per trasferire files da e verso risorse Samba ma ne permette anche l'archiviazione, è utile per il testing del server e per controllare quali servizi sono attivi.
La sua sintassi è:
smbclient //server/risorsa [-opzioni]
Le opzioni di smbclient sono molte, consultare la pagina man del comando per averne un prospetto completo, vediamo qui alcune delle più importanti.
-s config_file: Permette di specificare un file di configurazione di Samba da usare.
-M NetBIOS_name: Questa opzione permette di inviare un messaggio WinPopUp ad una macchina della rete. Una volta stabilita la connessione si digita il messaggio terminandolo con un ctrl+D. Non c'è modo di sapere se il messaggio è arrivato a destinazione o meno e il limite dato dal protocollo è che non si superino i 1600 bytes. Può essere utile il suo uso associato a cat, ad esempio cat messaggio.txt | smbclient -M PIPPO
-n NetBIOS_name: Con questo comando posso scegliere un nome NetBIOS a mio piacimento. Se non specificato Samba usa il nome del'host locale con lettere maiuscole.
-h: Stampa a monitor un brief delle principali opzioni.
-I: Permette di specificare l'indirizzo ip di una risorsa condivisa a cui si vuole accedere. In questo modo si forza il client a non cercare assolutamente di risolvere il nome della risorsa e di connettersi alla macchina specificata.
-U username[%password]: Con questa opzione mi è possibile specificare un utente e eventualmente una password da usare per accedere a una data risorsa.
-A nome_del_file: Questa opzione può essere utilizzata al posto di quella appena vista e permette di specificare un file da cui attingere lo USER e la PASSWD. E' stata studiata principalmente per l'uso negli script. Si può specificare anche il nome del dominio. La sintassi è:
username = valore
password = valore
domain = valore
-L: Questa opzione è utile in fase di testing e permette di listare tutte le risorse condivise di un dato host.
-W WORKGROUP: Questa opzione può essere necessaria per collegarsi ad alcuni server e permette di specificare un diverso WORKGROUP (dominio) da quello specificato nel smb.conf per la connessione in oggetto.
-T opzioni_di_tar: Questa opzione permette di lavorare sui file di una risorsa per scopi di backup e di restore. Ha numerose sotto-opzioni, fare riferimento alle pagine man di smbclient per un prospetto completo. Vediamo un esempio di sintassi:
smbclient //server/nome_risorsa -Tsotto-opzioni
Le sotto-opzioni sono quasi complementari a quelle che usa il comando tar originale.
c: Crea un nuovo archivio tar. Va seguito poi il nome dell'archivio.
x: Estrae i file da un archivio.
N: Sta per "newer than". Permette di archiviare solo i file più nuovi di un file che si specifica.
Quando si lancia senza paramentri smbclient si comporta come un client ftp da riga di comando e ci presenta un prompt così:
smb:\
In modalità interattiva si possono eseguire numerose operazioni, vediamone alcune:
?: Questo comando stampa un lista informativa dei comandi e ne descrive brevemente il significato. Si può farlo seguire da il nome di un comando e stamperà una descrizione della sua funzione. Si può usare anche help.
!: Apre una shell sulla macchina locale. Si può farlo seguire dal comando che si vuole eseguire.
cancel id_stampa: Permette di cancellare un job di stampa dalla coda sulla stampante. Va specificato il numero di job che si intende eliminare.
cd directory: Permette di cambiare directory. Se usato senza specificare il path si comporta come pwd mostrando la directory corrente.
del stringa: Cancella dal server tutti i file della directory corrente che hanno una corrispondenza della stringa.
dir stringa: Una lista di file contenenti la data stringa presenti nella directory di lavoro viene recuperata e mostrata.
exit: Termina la connessione con il server e esce.
get file_remoto nome_file_locale: Recupera un file definito e lo salva in locale con il nome specificato.
lcd directory: Cambia la directory locale. Anche qui se non specificata la directory stampa il path della directory locale corrente.
ls stringa: uguale a dir.
mget stringa: Permette di scaricare più di un singolo file o directory.
md o mkdir nome_directory: Crea una directory all'interno di quella attuale.
mput stringa: Permette di mandare in upload più file o directory che hanno in comune la stringa specificata
print nome_file_stampa: Stampa attraverso una stampante condivisa il file specificato.
put nome_file_locale nome_file_remoto: Esegue l'upload di un file locale e se specificato lo rinomina nel nome dato.
queue: Mostra la lista dei file in attesa di stampa.
rm stringa: Rimuove tutti i file che hanno corrispondenza con la stringa data.
rmdir nome_directory:rimuove la directory specificata.
tar: Oltre all'uso dell'opzione -T in modo interattivo si usa questo comando. Supporta le stesse opzioni di -T.

smbcontrol
Utility che permette di gestire (inviare comandi / messaggi ) ai demoni di smbd, nmbd e winbindd.
smbcontrol [ -d ] [ -s ] -i
oppure
smbcontrol [ -d ] [ -s ] destination message-type [ parameter ]
-d Specifica il livello di debug (Accetta valori interi da 0 a 10)
-s Specifica il file di configurazione
-i Abilita l'interctive mode,
destination Per destination si intende a quale processo dovrà essere inviato il messaggio, è possibile specificare sia l'ID oppure sia il nome: nmbd o smbd.
La differenza fra i due target nmbd e smbd oltre al nome del processo consiste nel fatto che il messaggio con destinazione nmbd viene mandato in modalità broadcast a tutti i processi nmbd attivi in quel momento mentre per smbd verrà inviato un singolo messaggio al processo con l'ID specificato nel pid file (smbd.pid)
message-type Specifici che tipo di messaggio viene inviato. Ecco alcuni esempi:
- close-share: Termina tutte le sessioni correnti dei client connessi alla share, come argomento si aspetta il nome della share.
- debug: Setta il debug level
- force-election: Forza l'elezione del master browser, unico target possibile è nmbd
- ping: Invia dei ping ai processi evidenziati, stessa modalità dei pacchetti ICMP.
Come parametro si aspetta il numero di ping da inviare di conseguenza i PONG dei singoli processi.
- profile: Invia un messagio ad un processo smbd per modificare i parametri del profile. I parametri possono essere settati ad on/off per attivarli o disattivarli oppure flush e count per azzerare o attivare i vari counter.
parameter Parametri richiesti dal messaggio inviato, Es il livello di debugging o il numero di ping da inviare ad un certo processo.
Esempi:
Invio di ping ai processi nmbd
[root@trinity root]# smbcontrol smbd ping 1
PONG from PID 585
PONG from PID 30423
PONG from PID 29124
PONG from PID 29220
PONG from PID 29414
PONG from PID 29139
PONG from PID 29151
Abilitazione dell'interactive mode
[root@trinity root]# smbcontrol -i
visualizzazione dell'help
smbcontrol> ?
<destination> <message-type> <parameters>
<destination> is one of "nmbd", "smbd" or a process ID
<message-type> is one of: debug, force-election, ping, profile, profilelevel, debuglevel, printer-notify, close-share

smbd e nmbd
Un server Samba si compone di due principali demoni:
smbd per i servizi di condivisione di file e stampanti.
nmbd per il servizio di risoluzione dei nomi NetBIOS e di assistenza al browsing delle risorse.
Entrambi questi demoni si appoggiano al file smb.conf per funzionare e hanno opzioni da riga di comando specialmente per effettuare test e debug dei rispettivi servizi.
Smbd e nmbd necessitano di essere avviati insieme per poter garantire un funzionamento corretto del server Samba. E' consigliabile infatti far gestire il loro avvio da uno script di avvio e le principali distribuzioni vengono già fornite di comodi script come /etc/init.d/samba anche se la loro posizione varia tra le diverse distribuzioni.
In altri casi si può usare il super-demone di gestione dei servizi inetd o infine si possono avviare da riga di comando ma a patto di essere l'utente root.
smbd: Come detto questo demone è responsabile della gestione delle risorse condivise, siano esse dischi o stampanti, tra il server Samba e i suoi client. Fornisce i servizi di condivisione dei file e delle stampanti, di browsing ai client di una o più sotto-reti e di gestione di tutti i messaggi di notifica che client e server si scambiano. Infine si occupa di autenticare gli utenti e di controllare le risorse condivise.
Smbd rilegge il suo file di configurazione automaticamente ogni minuto. Si può forzare il server a rileggere il suo file di configurazione con un SIGHUP. Ricaricare il file comunque non influirà sui client già connessi i quali dovranno sconnettersi e riconnetersi perchè le modifiche abbiano effetto.
Il modo esatto di lanciarlo e con l'opzione -D che lo porta ad avviarsi come demone. Questa è anche l'opzione di default.
Le sue opzioni a parte quella appena descritta sono finalizzate al debug e sono principalmente ad uso degli sviluppatori. Con -h si può avere la lista di queste, per approfondirle fare riferimento alla pagina di man.
nmbd: Questo demone è in realtà un semplice name server che imita le funzionalità di un WINS o di un NetBIOS name server. Ascolta e cattura le richieste per il name server e risponde con le informazioni in suo possesso. Si occupa inoltre di mantenere una lista per il browse delle risorse di rete e partecipa alla scelta del browsing. Se attivo il server WINS nmbd tiene il database dei nomi e degli indirizzi in un file chiamato wins.dat. Un demone nmbd può anche rispondere alle richieste del protocollo di browsing delle Risorse di Rete di Windows. Il browsing è una serie di protocolli di annuncio, annuncio di servizi o di directory condivise che fornisce una directory dinamica che contiene i server e i dischi e le stampanti presenti nella rete NetBIOS. Se nmbd è il master browser locale mantiene i databases di browsing nel file browse.dat.
Anch'esso se lanciato con l'opzione -D si comporta come un demone andando in background e ascoltando sulla sua porta. Il resto delle opzioni anche in questo caso serve principalmente per effettuare test particolari e verifiche per gli sviluppatori. Con l'opzione -h se ne può avere un brief veloce.

smbmnt, smbmount e smbwrapper
Se una volta configurato il server Samba si desidera accedere alle risorse condivise come se fossero parte del filesystem Unix e non come se si accedesse ad una risorsa esterna, ad esempio usando smbclient, si dovrà "montare" la risorsa così come si montano le diverse partizioni del disco.
In questo modo sarà possibile eseguire operazioni sui file condivisi da una macchina Windows ad esempio come se si trattasse di file unix e quindi usando tutti i fantastici e versatilissimi comandi unix, grep, sort, df, du, ls, etc... etc.
Per far questo si utilizzano alcune utility fornite con il pacchetto Samba.
Smbmount, ristretta esclusivamente ai sistemi Linux è equivalente a usare il comando mount -t smbfs. Per utilizzarla è necessario aver compilato i sorgenti assicurandosi che nel configure si sia abilitata l'opzione --with-smbmount e bisogna accertarsi che il kernel abbia abilitato il supporto per il filesystem smb/cifs.
Smbmount è un demone e quindi una volta lanciato anche se si è smontata la risorsa continuerà ad essere attivo tra i processi listabili con un ps o con top. Per eseguire le operazioni si avvale del comando smbmnt.
Vediamo la sintassi e le opzioni possibili.
smbmount servizio punto_di_mount [ -o opzioni ]
Le opzioni si specificano separate con una virgola e con il modello chiave=valore, le più importanti sono:
username=arg: Permette di specificare un utente con il quale accedere alla risorsa. Se non specificato verrà utilizzato l'utente dato dalle variabili di ambiente. Supporta anche l'uso di sintassi come user%password o user/workgroup o anche user/workgroup%password.
password=arg: Permette di specificare una password. Se non definita si userà la variabile di ambiente PASSWD e se non trova nessuna password che vada bene, a meno che non si sia definita l'opzione guest, ci restituirà un prompt per digitarla.
credentials=nome_del_file: Permette di definire un file esterno per la specifica dell'utente e della password. La sintassi del file sarà:
username = valore
password = valore
In questo modo si può evitare di avere queste specifiche in file condivisi da altri utenti nel sistema come /etc/fstab.
netbiosname=arg: Permette di specificare un nome netbios per la sorgente. Se non specificato viene usato il nome dell'host locale.
uid=arg: Permette di specificare un utente che sarà proprietario per tutti i file presenti nella risorsa, si può specificare usando l'id numerico per l'utente o il suo nome.
gid=arg: Permette di specificare il gruppo propietario per tutti i file della risorsa montata. Si può definire per id o per nome.
port=arg: Specifica una porta diversa dalla standard 139 per comunicare con la risorsa remota.
fmask=arg: Definisce i permessi dei file della risorsa montata. Se non specificato si usa la umask corrente.
dmask=arg: Come sopra ma per le directory.
debug=arg: Permette la specifica per il debug delle operazioni che si effettuano. Un valore consigliato può essere 4, se si specifica un valore troppo alto si rischia di avere troppi messaggi che impediscono poi la visualizzazione dei dati interessanti.
ip=arg: Setta l'ip o il nome dell'host remoto a cui ci si vuole connettere.
workgroup=arg: Permette di specificare il workgroup a cui si riferisce la risorsa condivisa da montare.
guest: Non richiede una password.
rw: Monta la risorsa in read and write mode.
ro: Monta la risorsa in read-only mode
Una volta montata la risorsa la si può smontare con l'equivalente di umount, smbumount. Per la verità si è pensato a questo eseguibile per dare ai normali utenti più versatilità sulle risorse montate. Infatti questo comando è setuid ed è immaginabile che mettere setuid umount sia una cosa da pazzi. Root potrà comunque smontare le risorse con umount.
Non ha opzioni e la sua sintassi è:
smbumount punto_di_mount
I comandi appena descritti valgono per l'uso su sistemi Linux ma se si sta usando Solaris? O HP-UX?
Per questo è stato studiato un'altro metodo che, purtroppo ancora imperfetto e in via di sviluppo, permette di effettuare operazioni sui file di risorse condivise senza avere un supporto smbfs. Si abilita il suo uso in fase di compilazione dei sorgenti con l'opzione, da passare al configure, --with-smbwrapper e si utilizza per le operazioni l'eseguibile smbsh.
Smbsh quando lanciato fornisce un albero di directory sotto /smb. Le sotto directory di /smb corrispondono ai server e le loro sottodirectory agli share su disco e di stampa. Crea di fatto una subshell e i comandi impartiti dal suo prompt interagiscono con i file come se si trattassero di file locali al sistema unix della macchina.
Ha varie opzioni:
-d: Setta il livello di debug dell'applicazione e quindi anche di log, i suoi valori vanno da 0 a 10. Il livello 0 registra solo i messaggi più importanti, l'uno è normale e da 3 in su è inteso solo per il debug visto il forte carico di lavoro a cui sottopone Samba.
-l file: Imposta il nome del file di log da usare.
-P prefisso: Imposta una divesa directory da /smb su cui montare il filesystem SMB.
-R ordine: Imposta l'ordine di risoluzione dei nameservers. Accetta i quattro paramentri lmhosts, host, wins e bcast in qualsiasi ordine.
-U utente: Supporta il modo username%password
-W workgroup: Imposta il workgroup NetBIOS al quale il client si connette.

smbpasswd
Utility per il cambio della password di Samba.
smbpasswd [opzioni] [utente] [password]
-L Permette di specificare le opzioni che solo l'utente root può utilizzare anche come utenti normali. Utilizzato per test o cambiamenti del file smbpasswd in locale.
-r remote hostname Opzione che permette di specificare l'host remoto su cui cambiare la password per samba. Se si omette il valore di defaul è localhost
-t Forza il cambiamento della password di un trusted machine account. Account creato per "registrare" la macchina nel dominio gestito dal smb server
-U username[%pass] Opzione che permette di specificare, l'utente a cui verrà modificata la password. Opzione utilizzabile solo se affiancata all'opzione -r
-a Opzione per aggiungere nuovi utenti nel file smbpasswd. L'utente che si vuole inserire deve già esistere come utente del sistema con la relativa entry nel file /etc/passwd
-s Abilita il silent mode e si aspetta di leggere la nuova e vecchia password dallo standard input
-S Permette di visualizzare il domain SID
-d Opzione per disabilitare l'utente dal file smbpasswd in locale
-e Opzione per abilitare l'utente dal file smbpasswd locale
-m Opzione per specificare l'account è un account relativo ad un host
-n Permette di settare la password a NULL
-x Opzione che permette di cancellare l'utente dal file smbpasswd locale
-j Domain Opzione utilizzata per registrare il server smb in un dominio
NTNel caso in cui non venga specificato l'utente il comando interpreterà utilizzerà l'utente stesso che ha lanciato il comando per eseguire le operazioni.
Esempio:
Cambio della password dell'utente neo sul server smb trinity
[neo@dido neo]$ smbpasswd -r trinity -U neo
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user neo

smbtar
Abbiamo visto che anche con smbclient si possono gestire i back-up di risorse condivise ma nella suite Samba esiste un comando prettamente dedicato a questo lavoro, smbtar.
In realtà smbtar è uno shell script che gira sopra smbclient e permette di eseguire back-ups e restores usando opzioni più comprensibili. Le sue funzionalità sono simili a quelle del comando unix tar.
Supporta svariate opzioni, vediamone alcune delle principali, consiglio comunque di dare sempre un'occhiata alla relativa pagina di man per un prospetto completo.
-d directory: Passa alla directory specificata prima di eseguire il backup o il restore dei file.
-N nomefile: Esegue il backup solo dei file più recenti dell'ultima modifica al file specificato. Utile per i backup incrementali (vedi man).
-p password: Indica la password da utilizzare per accedere alla risorsa condivisa.
-r: Esegue il restore della risorsa condivisa dal file .tar specificato.
-s nomeserver: Indica il nome della macchina che serve la risorsa condivisa interessata.
-t nastro: Può essere una device, un'unità nastro o un file. Se non definito il default è la variabile di ambiente $TAPE e se non esiste il file tar.out.
-u utente: Indica l'utente con il quale si desidera connettersi alla risorsa condivisa. Si può specificare anche la password nella forma nomeutente%password.
-x risorsacondivisa: Permette di specificare il nome della risorsa condivisa a cui si desidera accedere. Di default usa backup che è un nome comune per risorse dedicate al backup e al restore.
Vediamo un esempio dell'uso del comando:
smbtar -s nomepc -x nomeshare -u nomeutente -p password -t backup.tar

Software - il sistema operativo
Per sistema operativo (OS) si intende quel software che permette al computer di funzionare. Resta attivo da quando si accende il computer a quando si spegne.
Gestisce tutte le funzioni generali della macchina: l’aspetto grafico delle visualizzazioni su monitor, la scrittura e la lettura dai dischi, la messa in esecuzione e la chiusura dei vari programmi, la ricezione e trasmissione di dati attraverso tutti i dispositivi di I/O.
Come qualsiasi altro programma, anche il sistema operativo risiede sull'hard disk e viene caricato nella RAM al momento dell'accensione. Senza il sistema operativo un computer non sarebbe in grado di fare nulla oltre al boot.
Esistono molti sistemi operativi. I più comuni sono le varie versioni di Windows, il MacOS (solo per Macintosh), Linux e Unix. Esisteva l'MS-DOS che è ormai caduto in disuso.
La differenza principale tra Linux/Unix, MS-DOS e i vari Windows sta nel fatto che i primi sono detti sistemi a riga di comnado, mentre i secondi sono a interfaccia grafica (GUI).
Nei sistemi a riga di comando tutti i comandi devono essere inseriti da tastiera. È quindi necessario conoscere moltissimi comandi per poterlo far funzionare. Windows e MacOS, invece, hanno un'aspetto più accattivante e quasi tutti i comandi si presentano sotto forma di immagini (dette icone) piuttosto intutitive. Quasi tutta l'interazione avviene attraverso click del mouse. Questi ultimi sistemi operativi sono detti "user friendly" cioé amichevoli per l'utente in quanto, a differenza dei sistemi a riga di comando, possono essere utilizzati anche da utenti senza esperienza in campo informatico.

Software - Installazione su Linux
Le procedure di installazione descritte sopra sono valide sopratutto per Windows, MacOS o le ultime distribuzioni di Linux a interfaccia grafica.
In caso di un sistema operativo come Linux senza interfaccia grafica le cose si complicano un po'.
Esistono infatti dei "pacchetti" (chiamati RPM) che funzionano più o meno come i file di installazione automatica ma richiedono comunque delle conoscenze tecniche maggiori.
In alternativa, volendo installare software su Linux, bisogna compilare manualmente il codice. Come è facile intuire questa operazione non è alla portata di un utente poco esperto!
Per maggiori dettagli si rimanda alla sezione apposita.

Software - l'installazione
L'installazione è il processo attraverso il quale si inserisce nuovo software sul computer. In genere non basta semplicemente copiare i file in una cartella ma è necessario compiere un'operazione un po' più complessa. Il sistema operativo infatti richiede che vari file di sistema vengano modificati affinché il nuovo programma possa interagire con esso e quindi funzionare.
In quasi tutti i sistemi operativi di uso comune (Win o Mac o, ultimamente, anche le versioni ad interfaccia grafica di Linux) i programmi vengono corredati di un file eseguibile (di solito chiamato setup.exe o install.exe) che, lanciato, permette di eseguire un'installazione guidata piuttosto semplice. I parametri modificabili sono solitamente la posizione dove si vuole installare il programma e se si vuole un'installazione completa (copiando tutti i file su proprio hard disk) o ridotta (lasciando alcuni file sul CD-Rom, se si sta installando da CD).
Una volta terminata l'installazione il programma è pronto per essere usato (alcuni programmi richiedono che il computer venga riavviato per attivare le modifiche apportate ai file di sistema).

Software applicativo
Viene definito software applicativo (o semplicemente "applicativi") tutto il software che non sia il sistema operativo.
In pratica qualsiasi programma, dalla videoscrittura (per es. Word della Microsoft) al foto ritocco (Adobe Photoshop) agli scompattatori (WinZip) ai programmi di posta (Outlook o Eudora), è un applicativo. Di fatto se su un computer ci fosse installato solo il sistema operativo funzionerebbe perfettamente ma l'utente non sarebbe in grado di farci nulla.
Indicativamente potremmo dividere i software applicativi in 5 categorie:
- Utilità di Sistema: programmi che servono per migliorare la gestione e la sicurezza della macchina, come ad esempio gli stessi antivirus, oppure programmi per l'ottimizzazione delle risorse, per il controllo dello stato del sistema, la ripulitura dell'hard disk, ecc.
Office Automation: programmi di ausilio nei normali lavori d'ufficio, quindi creazione e elaborazione di testi (word processor), gestione di basi di dati (database), fogli di calcolo, posta elettronica, navigazione in Internet, ecc.
Applicazioni aziendali : programmi creati per le necessità specifiche delle aziende, come ad esempio i programmi per la fatturazione o per la gestione del personale, dei magazzini, dei macchinari industriali. Spesso si tratta di programmi creati ad hoc da aziende di produzione software.
Strumenti di sviluppo : programmi per la creazione di oggetti multimediali (pagine Web, animazioni e CD interattivi), elaborazione audio/video/immagini, programmi che servono per la creazione di nuovi applicativi (authoring tools).
Giochi e svago : giochi, emulatori, lettori audio e video.

Software per server Internet
Viene qui fatta una rassegna essenziale del software che viene maggiormente utilizzato per gestire servizi comuni.
Va vista come indicazione sui software mainstream, quelli sui quali più facilmente ci si può trovare ad operare.
Quasi tutti i prodotti sotto elencati sono OpenSource e disponibili su Linux come su altre piattaforme. Windows Incluso.
File sharing
Samba Windows networking. Condivisione di file e stampanti, avanzata e performante compatibilità con NetBios.
NFS Server File sharing attraverso il protocollo NFS, richiede un kernel con tale supporto abilitato.
Web Server e Application Server
Apache Il server web utilizzato dal 60% dei siti Internet. Flessibile ed estendibile con moduli.
Tomcat Java Application Server del progetto Apache. Interessante ma poco performante.
PHP HTML embedded scripting language. L'alternativa OpenSource ad ASP di Microsoft. Molto diffuso.
Mod Perl Modulo PERL per Apache. Fondamentale per chi sviluppa in Perl.
Mail & News Server
Sendmail SMTP server, cresciuto con la Rete. Molto utilizzato, molto flessibile.
Postfix Alternativa SMTP a Sendmail. Facilmente configurabile. Con enfasi sulla sicurezza.
Qmail Altro SMTP server alternativo a Sendmail. Dal design recente e sicuro.
INN Server NEWS dell'ISC.
DNS & DHCPD
bind Il server di DNS più utilizzato. Presente in tutte le distribuzioni.
dhcpd Il server DHCP dell'Internet Software Consortium, incluso in tutte le distribuzioni disponibili sul mercato.
DB Server & LDAP
mysql SQL server Open Source. Molto veloce, con qualche limitazione sulle funzioni più complesse.
postgreSQL Alternativa a Mysql, prodotto Open Source.
openldap L'implementazione Open Source di Ldap.
Altri servizi: FTP, WEB CACHE...
Wu-ftpd Washington University FTP server.
proftpd Server ftp alternativo.
Squid Proxy server. Web cache engine. La soluzione OpenSource più diffusa.
VNC Virtual Netwrok Computing. Per gestire macchine remote tramite interfaccia grafica.

Software Raid su Linux
Il kernel di Linux garantisce sia la possibilità di fare raid software (su dischi IDE o SCSI) che il supporto di un gran numero di controller SCSI che permettono la gestione di raid hardware.
Il supporto RAID software del Kernel vale per Raid 0, Raid 1, Raid 4, Raid 5 e il semplice linear mode anche se varie distribuzioni come RedHat non utilizzano Raid 4 (per'altro poco usato in genere).
Nel kernel 2.4 e successivi è stato riscritto il codice e gli strumenti in userland (raidtools) per la gestione del Raid software. Tutto quello che viene riferito qui si riferisce alla nuova versione, per informazioni sulla vecchia implementazione, ancora usata su kernel 2.0 e 2.2 non patchati fare riferimento al relativo HowTo. I vecchi comandi come mdrun, mdadd, mdstop e ckraid non vengono più utilizzati.
La configurazione di RAID a livello software viene fatta tramite i metadevice /dev/md# (# è un numero progressivo, a partire da zero) che possono normalmente essere montati su delle directory del filesystem:
mount -t ext3 /dev/md0 /usr.
Il metadevice md viene trattato come un normale filesystem, che va formattato, montato e utilizzato in modo trasparente, a prescindere dai dispositivi fisici che questo utilizza.
Il file dove si configurano gli md è /etc/raidtab. Qui si definisce il nome dei metadevice virtuali che si vogliono utilizzare (/dev/md0, /dev/md1 ecc) e come questi sono composti: le partizioni fisiche che ne fanno parte (es: /dev/hda1, /dev/sda4), il tipo di Raid che va utilizzato (linear, 0, 1, 4, 5), la presenza di eventuali dischi spare di standy, che possono automaticamente essere utilizzati in caso di guasti sui dischi che fanno parte del metadevice, la dimensione delle unità "atomiche" di dati (chunk) per ogni operazione di I/O.
Possono far parte di un metadevice sia partizioni di dischi SCSI che partizioni di dischi IDE e, curiosamente, anche altri metadevice. In questo modo, per esempio, è possibile fare Raid 10 facendo un raid 1 di un device già in raid 0.
Per creare un metadevice con il livello di raid scelto su un sistema esistente con le seguenti procedure:
- Creazione di un file /etc/raidtab opportunamente e correttamente configurato
- Creazione del metadevice con il comando mkraid (Ad esempio mkraid /dev/md0 crea /dev/md0 sulla base di quanto definito in /etc/raidtab).
- Formattazione del nuovo device (mkfs.ext3 -b 4096 -R stride=8 /dev/md0) Notare che le partizioni fisiche facenti parte di md0 (specificate in /etc/raidtab) vengono cancellate, per cui non devono contenere dati utili. I parametri aggiuntivi forniti servono per specificare la dimensione dei blocchi (qui 4Kb) e il numero di blocchi per chunk (qui 8). Con questi parametri ci si aspetta un chunk-size 32 (Kb) nel file /etc/raidtab.
- Mount del device sul filesystem (es: mount -t ext3 /dev/mdo /opt)
- E' possibile verificare informazioni sul raid con cat /proc/mdstat. Consultando questo file è possibile visualizzare anche informazioni come lo stato di avanzamento di un rebuilding dei device e di fatto rimane la fonte di informazioni più diretta e chiara. Se il file manca, il proprio kernel non supporta Raid software.

sort
Il comando sort permette di ordinare le righe contenute in un file secondo criteri configurabili.
E' un comando comune in tutti gli Unix e viene tipicamente utilizzato come filtro.
sort [opzioni] [file]
-b Ignora gli spazi e i caratteri di tabulazioni all'inizio e alla fine delle righe
-c Verifica se i file sono già ordinati e, in tal caso non produce output
-f Ignora la differenza fra caratteri minuscoli e maiuscoli
-i Ignora i caratteri non stampabili
-n Effettua un ordinamento numerico
-o file Memorizza l'output nel file specificato
-r Inverte l'ordinamento
-u Le righe doppie vengono riportate in output una sola volta
-M Tratta i primi tre caratteri come sigla di mese (Jan, Feb, etc...)
-t carattere Utilizza il carattere indicato come delimitatore di campo (default è lo spazio)
+# Esegue l'ordinamento sulla base del campo #+1

ssh
Client per il login o lancio di comandi da remoto attravero la suite di ssh.
ssh [-l login_name] [hostname | user@hostname] [command]
ssh [-afgknqstvxACNPTX1246] [-c cipher_spec] [-e escape_char] [-i identity_file] [-l login_name] [-m mac_spec] [-o option] [-p port] [-L port:host:hostport] [-R port:host:hostport] [hostname | user@hostname] [command]
-l Specifica il nome dell'utente con cui aprire la connessione sull'host remoto.
user@hostname Come sopra
-f Manda in background ssh prima di lanciare il comando
-i [identity_file] Specifica il file contenente la chiave privata (rsa e dsa)
-v Abilita il verbose mode.
-x Disabilita x11 forwarding
-X Abilita x11forwarding
-C Richiede la compressione dati
-1 Forza l'uso del protocollo 1
-2 Forza l'uso del protocollo 2

ssh -C user@server -L porta:server:portalocale
Ssh può essere un comodo e sicuro strumento per crittografare connessioni a server che non supportano la cifratura delle loro comunicazioni. In sostanza si usa ssh per creare un tunnel cifrato in cui far passare i dati non cifrati del servizio in oggetto.
Questo metodo si può utilizzare per molti servizi diversi (X11, vnc, pop3, swat) unico suo difetto è generare un traffico maggiore e dev'essere preso in considerazione nel caso in cui la rete sia lenta.
Poniamo di essere costretti a connetterci da remoto per configurare samba con swat.
Come si sa swat non cripta le password inviate sul network.
root@adminhost#ssh -C root@sambaserver -L 901:sambaserver:901
root@sambaserver's password:
Last login: Tue Jun 3 23:49:04 2003 from 192.168.0.111
Linux 2.4.20.
root@sambaserver#
In questo modo con l'opzione -C abilito la compressione dati e con l'opzione -L faccio in modo di forwardare la porta locale specificata con la porta server. In parole povere tutti i dati che sono diretti alla porta 901 dell'host locale vengono inviati alla porta 901 su cui ascolta swat.
Ora se dalla macchina adminhost mi collego con un browser a http://localhost:901/ sarò automaticamente connesso al tool di gestione di samba swat e mi verrà richiesta la password ma questa volta non sarà trasmessa in chiaro sulla rete.

stat
E' un comando che permette di visualizzare informazioni utili sui file come dimensione, permessi, inode, owner, data di ultimo accesso, di creazione e di modifica. In pratica tutto quello che è necessario conoscere di un file.
Ha opzioni, inoltre, che forniscono informazioni sul file system che contiene il file e che permettono di esportare i dati in modo sequenziale e poco user friendly ma comodo per essere gestiti all'interno di script.
stat [-l] [-f] [-v] [-t] file-name [file-name]...
-l Flag da utilizzare per i links
-f Visualizza le informazioni del file system che contiene il file
-t Visualizza lo stdout in modo tale da essere processato da un secondo programma o comando
Esempi
stat /etc/rc.local Fornisce informazioni, in formato "human readable" sul file /etc/rc.local (nel nostro caso un link simbolico)
stat -l /etc/rc.local Fornisce informazioni sul file a cui punta il link simbolico /etc/rc.local
stat -t /etc/group Fornisce informazioni su /etc/group dando solo l'elenco dei risultati senza specificarne la natura, utile per "passare" il risultato ad un altro comando all'interno di uno script.

Status codes del protocollo HTTP
I server HTTP rispondono utilizzando linee di status che informano il client sull'esito della richiesta.
Gli status contengono 3 campi: versione del protocollo HTTP, status code e descrizione.
Lo status code è dato da un numero a 3 cifre con i seguenti significati:
1XX - Informational
2XX - Client request successful
3XX - Client request redirected, futher action necessary
4XX - Client request incomplete
5XX - Server errors
1xx - INFORMATIONAL
Questa classe di status consiste solo nella status line e in headers opzionali. HTTP/1.0 non definisce nessuno status code 1XX.
100 Continue - Il client può continuare con la sua richiesta. Questa risposta intermedia è inviata al client dal server per informarlo che la parte iniziale della sua richiesta non è stata respinta. Il client ora può completarla o ignorare la risposta se la richiesta è gia stata inviata per intero. Quando la richiesta è stata completamente inviata il server invierà una risposta finale.
101 Switching Protocols - Il server riceve una richiesta per il cambiamento del protocollo per quella connessione.
2xx - SUCCESSFUL CLIENT REQUEST
I seguenti status code indicano che la richiesta da parte del client è stata ricevuta, capita e accettata.
200 OK - La richiesta è stata accolta, il server risponde con i dati richiesti. E' la risposta normale per un file correttamente trasferito.
201 Created - La richiesta è stata effettuata ed una nuova risorsa è stata creata. L'URI rinviato nella risposta fa riferimento alla nuova risorsa creata.
202 Accepted - La richiesta è stata accettata ma non ancora processata.
203 Non-Authorative Information - L'insieme delle informazioni rimandate contenute nell'entity-header non è l'insieme di informazioni mandate dal server di origine ma provengono da una copia fatta in locale o da terzi.
204 No Content - Il server ha effettuato la richiesta ma non si necessita il rinvio dell'entity-body. A questa risposta il browser non dovrebbe aggiornare il documento visualizzato.
205 Reset Content - Il browser alla ricezione di questo status code dovrebbe resettare il contenuto del form che ha causato l'invio della richiesta.
206 Partial Content - Il server ha effettuato un GET parziale della risorsa. Questo succede quando risponde a una richiesta contenente un Range header.
3xx - CLIENT REQUEST REDIRECTED
Questa classe di status indica che si necessita di un'ulteriore azione per far si che la richiesta sia correttamente effettuata.
300 Multiple Choices L'URI richiesto corrisponde a piu documenti (per esempio un documento disponibile in piu lingue).
301 Moved Permanently - La risorsa richiesta è stata assegnata definitivamente ad un nuovo URI.
302 Moved Temporarily - La risorsa richiesta è stata assegnata temporaneamente ad un nuovo URI. Il client può usare il nuovo URI per le attuali richieste, ma in futuro (quando non vi sarà piu redirezione) dovrà usare il vecchio URI.
303 See Other - La risorsa richiesta si trova in un altro URI specificato nel Location header.
304 Not Modified - Il Client ha effettuato una richiesta GET condizionale usando l'If-Modified-Since header, ma la risorsa non è stata ancora modificata. La risorsa non viene mandata in quanto il client la possiede gia in locale.
305 Use Proxy - La risorsa richiesta deve passare per un proxy il cui l'URI è dato nel Location field.
4xx - CLIENT REQUEST ERRORS
La classe di status 4XX è riservata ai casi in cui il client commette degli errori.
400 Bad Request - Richiesta non capita dal server causa sintassi errata.
401 Authorization Required - Questo risultato è dato dal WWW-Authenticate header per indicare che la richiesta era sprovvista dell'autorizzazione che quella determinata risorsa richiede.
402 Payment Required - Questo codice è riservato ad usi futuri.
403 Forbidden - Il server capisce la richiesta ma si rifiuta di compierla. La richiesta non dovrebbe essere ripetuta.
404 Not Found - Il server non ha trovato nulla che corrisponda all'URI richiesto. Dopo il codice 200, questo è tipicamente quello più riscontrato nei log dei server web.
405 Method Not Allowed - Il metodo specificato nella request line non è disponibile per l'URI richiesto
406 Not Acceptable (encoding) - La risorsa identificata tramite richiesta può solo generare una risposta che ha caratteristiche incompatibili con gli accept headers contenuti nella richiesta.
407 Proxy Authentication Required - Questo codice indica che il client deve prima autenticarsi con il proxy, usando l'header Proxy-Authenticate.
408 Request Timed Out - Il client non ha fornito una richiesta nel tempo massimo di attesa del server.
409 Conflict - La richiesta non puo essere completata causa conflitto con il corrente stato della risorsa.
410 Gone - La risorsa richiesta non è piu disponibile sul server e il server non conosce indirizzi su cui ridirezionare.
411 Length Required - Il server si rifiuta di accettare la richiesta in quanto il client non ha definito il Content-Length.
412 Precondition Failed - Una o piu condizioni specificate negli IF request headers è risultata falsa al momento del test del server.
413 Request Entity Too Large - La richiesta è piu grande rispetto a quello che il server può processare.
414 Request URI Too Long - L'URI richiesto è troppo lungo per essere interpretato dal server.
415 Unsupported Media Type - Il corpo della richiesta è in un formato non supportato.
5xx - SERVER ERRORS
Questa classe di status è riservata ai casi in cui il server commette un errore o non è in grado di performare la richiesta. In genere richiede un intervento sistemistico sul server.
500 Internal Server Error - Il server è in una situazione inaspettata e non può rispondere alle richieste.
501 Not Implemented - Il server non è implementato per rispondere correttamente alla richiesta effettuata.
502 Bad Gateway - Il server collegato ad un gateway o ad un proxy, riceve una risposta non valida da questo.
503 Service Unavailable - Il server non può rispondere causa temporaneo overload.
504 Gateway Timeout - Il server collegato ad un gateway o ad un proxy, non riceve una risposta da questo nel tempo di attesa massimo impostato.
505 HTTP Version Not Supported - Il server non supporta la versione del protocollo HTTP utilizzato per fare la richiesta.

Stop e restart di Apache
Se si controllano i processi in esecuzione sul proprio server web, si potranno vedere svariati processi httpd che stanno girando, tutti con PPID coincidente con il PID del processo httpd padre, l'unico che dovrebbe girare come utente root.
Ogni operazione di controllo del server web, gestita tramite l'invio di segnali, va quindi fatta sul PID del processo httpd padre.
Se per esempio si vuole fermare il servizio si può scrivere:
[root@eberk diego]# kill -TERM `cat /usr/local/apache/logs/httpd.pid`
Qui 'cat /usr/local/apache/logs/httpd.pid' indica semplicemente il PID del processo, che viene generalmente scritto in un file chiamato httpd.pid, il cui path completo può cambiare a seconda di come si è impostata l'opzione --runtimedir in fase di compilazione.
E' possibile verificare il progresso delle nostre operazioni analizzando i file di log, per esempio con:
[root@eberk diego]# tail -f /usr/local/apache/logs/error_log
Notare che i path dei file di pid e di log indicati possono variare anche tramite httpd.conf, per impostare le loro posizioni si usano le direttive PidFile e ErrorLog nel file di configurazione.
Ci sono 3 tipi di segnali che sono comunemente usati: TERM, HUP e USR1.
Segnale TERM: stop
Mandando il segnale TERM al processo padre, si causa l'immediato kill di tutti i processi figlio e il processo padre termina. Tutte le richieste http in gestione terminano immediatamente, e fino a quando il server non viene restartato nessuna richiesta verrà accolta. Il delay tra quando si lancia il comando e l'effettivo stop del server è di qualche secondo (in funzione di quanti sono i processi figlo).
Segnale HUP: restart
Mandando il segnale HUP al processo padre, si causa l'immediato kill di tutti i processi figlio, ma non del processo padre. Il processo padre rilegge il file di configurazione e riapre i file di log. Una volta fatto ciò ricrea i processi figlio che continueranno ad accogliere richieste.
Segnale USR1: graceful restart
Nota: Nelle versioni precedenti alla 1.2b9, questo segnale è leggermente instabile, e si consiglia di non usarlo.
Lanciando questo segnale, il processo padre dirà ai processi figli di terminare non appena hanno finito di gestire le richieste correnti (o di stopparsi immediatamente se non ne stanno gestendo), nel frattempo rilegge il file di configurazione, riapre i file di log e rigenera nuovi figli.
Questo è il metodo migliore per modificare e ricaricare la configurazione su un server che sta gestendo del traffico, senza interrompere alcuna sessione corrente.
Tramite lo script apachectl presente con i sorgenti di Apache, è possibile gestire in modo semplice l'avvio e la chiusura del web server, oltre ad avere la possibilità di invocare altre opzioni come il controllo dello stato del servizio e la verifica della configurazione.
Provare ad eseguire /usr/local/apache/bin/apachectl (o in un PATH diverso da quello di default, dopo averlo cercato con un locate apachectl) senza argomenti per visualizzare le opzioni disponibili.

Storia dell'aggiornamento di un server LAMP in produzione
Socrate è la macchina che gestisce il sito Openskills.info, un assemblato generico in via di obsolescenza informatica discretamente carrozzato per fare un buon LAMP (Linux, Apache, MySql, PHP) in grado di gestire traffici medio-bassi.
Raccontare come si è gestito il suo aggiornamento è probabilmente un azzardo in termini di sicurezza, ma, vista la natura del sito che vive su Socrate, ci sembra una scelta coerente e dovuta.
Ci piace pensare a Socrate come un sistema ed un esperimento aperto, la cui stessa natura è spiegata, testata, condivisa ed esposta, nella speranza che di questo non apra troppe porte ad abusi.
Un buon modo per gestire l'aggiornamento di un singolo server in produzione, senza la comodità di avere una farm ridondata da cui è possibile aggiungere e togliere macchine senza interruzioni del servizio, è quello di preparare una nuova macchina, sincronizzare i dati con l'alter ego online e poi procedere ad uno switch degli indirizzi delle rispettive macchine, portando il nuovo sistema in produzione e ripulendo le arp table sui dispositivi di rete che hanno a che fare con questo server.
Questo approccio assicura un rollback rapido in caso di problemi ed evita interventi a livello di DNS.
In questo caso, invece, abbiamo voluto procedere in modo diverso:
Si vuole mantenere l'hardware esistente ed eseguire l'installazione del nuovo sistema su un hard disk separato, momentaneamente collegato ad una macchina muletto, con l'intento, al momento dello switch, di sostituire fisicamente solo l'hard disk del computer su cui gira il sito.
Si prevede quindi una normale installazione, aggiornamento e sincronizzazione del nuovo Socrate, basato su RedHat 9.0, mentre il vecchio Socrate, su RedHat 7.3 continua ad erogare il servizio.
Il downtime previsto è quello fisicamente necessario per spegnere la macchina in produzione, cambiargli l'hard disk e riavviarla. I tempi di un eventuale rollback sono analoghi.
Il tutto dovrebbe risolversi in pochi minuti, salvo rifiniture e aggiustamenti successivi o interventi pesanti dell'amico Murphy.
INSTALLAZIONE
Si è fatta una normale installazione di RedHat 9.0 in modalità testuale con la scelta predefinita dei pacchetti per un server.
Al primo reboot si è proceduto a sfrondare dall'avvio i servizi non necessari tramite ntsysv e si sono lasciati solo questi servizi attivi:
crond - Indispensabile. Non usandoli, abbiamo disattivato anacron e atd.
httpd - Apache. Apre la porta 80 al pubblico.
kudzu - Non è necessario su un server in cui non cambia l'hardware, ma sarà fondamentale per gestire lo switch sulla macchina in produzione.
network - Indispensabile per un server in rete.
random - Utile e innocuo.
rsync - Lo usiamo per eseguire un backup remoto. Porta 873.
sendmail - Per inviare mail, il servizio di default è bindato su 127.0.0.1 porta 25 e non raggiungibile via rete.
sshd - Amministrazione remota, porta 22.
syslog - I log sono indispensabili.
vfsftpd - FTP server fornito di default da RedHat 9 (è una relativa novità, in passato sono stati usati wu-ftpd e proftpd). Per l'upload dei contenuti web. Porta 21.
xinetd - Necessario per gestire i servizi NON standalone (in questo caso solo rsync)
Fra le porte aperte solo la 80 verrà lasciata accessibile da Internet, le altre rimarranno accessibili solo da IP di amministrazione.
Aggiornamento dei pacchetti
L'aggiornamento degli RPM di un sistema RH viene fatto di default con up2date direttamente sul RedHat Network, in questo caso preferiamo autorpm, che va scaricato via rete.
La procedura di aggiornamento di tutti i pacchetti installati è relativamente rapida e viene fatta da repository locale con tutti gli rpm dei CDROM sincronizzati con un pool di mirror redhat-updates ufficiale.
Viene aggiornato anche il kernel e per gestire senza problemi lo switch sull'hardware diverso si mantiene l'abbondante kernel modulare di RedHat. In totale vengono aggiornati circa una trentina di pacchetti in pochissimi minuti.
Per evitare warning sulla provenienza degli RPM, si procede ad importare la chiave GPG ufficiale di RPM: rpm --import /usr/share/doc/redhat-release-9/RPM-GPG-KEY.
Durante l'aggiornamento di mutt, che tral'altro non usiamo, abbiamo fatto l'infelice scelta di procedere alla risoluzione delle sue dipendenze, invischiandoci in un imprevisto ritardo dovuto al fatto che autorpm si è messo a scaricare e controllare tutti gli rpm sul repository per risolvere una dipendenza di una dipendenza.
Customizzazioni
Successivamente verranno scaricati ed installati a mano altri pachetti:
tripwire - Il più comune Host IDS su Linux. La configurazione, l'inizializzazione del database e il relativo tuning vengono fatti in tempi successivi.
mysql - Non è stato installato di default e, fondamentalmente per maggiore familiarità, lo preferiamo a PostGreSQL
php_mysql - Il modulo Mysql per Php è un rpm autonomo e non è stato installato di default.
sysstat - Interessante e comodo per monitorare con sar lo storico sullo stato del sistema
Si sono impostate poche comode customizzazioni post-installazione:
- /root/.forward è stato editato aggiungendo una mail esterna a cui forwardare tutte le mail di sistema destinate a root.
- E' stato creato un semplice script /etc/cron.daily/ntpdate che ogni notte sincronizza l'ora sul server.
MIGRAZIONE DEI DATI
Abbiamo provveduto a copiare tramite rsync -av dal vecchio Socrate a quello nuovo vari file di configurazione e script custom:
/openskills/ - E' una directory in cui abbiamo mantenuto tutti gli script custom fatti per le varie funzionalità del sito
/etc/crontab - /etc/cron.* - Si riproduce quanto viene attualmente crontabbato sul vecchio server (dopo una rapida verifica che tutti i comandi invocati siano installati)
/var/log/apache - Viene fatta una prima, lunga, copia dei log di Apache, una copia successiva, solo con le differenze nei contenuti, verrà fatta appena prima di procedere allo switch.
/usr/local/apache/conf - Viene copiata la configurazione di Apache. Sul vecchio Socrate era stato compilato a mano, su quello nuovo per pigrizia, spirito di documentazione e test, si mantiene quello ufficiale distribuito tramite rpm. Il passaggio da un Apache 1.3 ad un Apache 2.0 ci ha fatto optare per la scelta di partire dalla conf 2.0 di default e su questa aggiungere le parti custom, piuttosto che una copia brutale della precedente configurazione.
/etc/rsyncd.conf - La configurazione di rsync (comodo, come si vede, sia per i backup che per il trasferimento di grossi file fra server (scp è una alternativa altrettanto valida, più praticabile (ssh è più diffuso di rsync) ma meno rapida nel gestire grossi file).
/etc/rc.d/rc.firewall - Il file che imposta le regole di iptables sul server. Sul nuovo Socrate abbiamo salvato le regole che questo script impone sul file di configurazione standard: iptables-save > /etc/sysconfig/iptables, in modo da gestire il firewalling come un nomale servizio: /etc/init.d/iptables start|stop.
/dump.db - Il dump dell'intero database MySql viene eseguito sul vecchio Socrate con mysqldump --add-drop-table --all-databases > /dump.db, il file viene copiato sul nuovo e importato una prima volta con mysql < /dump.db per verificare se ci sono problemi di importazione e se il sito funziona correttamente, prima dello switch verrà fatto un ulteriore dump-copia-restore del database. Un simile approccio, piuttosto grezzo, è possibile su Openskills perchè gli inserimenti nel database non sono molto frequenti e le sue dimensioni non sono esagerate. In altri casi potrebbero essere necessarie più complesse procedure di sincronizzazione dinamica del database.
Configurazione di Apache
Socrate non deve gestire una gran quantità di traffico (ha massimo 512Kbit a disposizione e questo risulta essere il suo collo di bottiglia) per cui la configurazione è fatta in base alla sicurezza e alle feature che servono, senza eccessiva attenzione alle performance.
Rispetto all'httpd.conf di default si sono cambiate le seguenti parti:
- Impostato KeepAlive On - Per evitare nuovi handshake TCP/IP ad ogni GET dello stesso client al server
- E' stato commentato il caricamento di vari moduli non utilizzati: proxy* , alcuni auth*, include, cern_met, expires, headers,usertrack, unique_id, dav, asis, dav_fs, imap, speling, userdir.
- Sono stati rinominati i file di configurazione per python, perl, ssl in /etc/apache/conf.d in modo da non caricare i rispettivi moduli.
- Sono state scommentate le righe relative alla location server-status in modo da renderla pubblicamente accessibile (sconsigliato su un normale server).
La configurazione del server ftp è piuttosto semplice se non si hanno esigenze particolari (in questo caso l'accesso ftp è solo per un numero limitato di utenti fidati), di fatto, rispetto al /etc/vsftpd/vsftpd.conf di default si è aggiunta la riga: chroot_local_user=YES che chroota alla loro home gli utenti che si collegano.
LO SWITCH: CRONACHE DI UN SUCCESSO SUDATO
Dobbiamo ammetterlo, questo è il secondo tentativo di aggiornamento di Socrate che abbiamo fatto.
Il primo, qualche settimana fa, è miseramente fallito: il sistema si bloccava dopo Grub, il kernel non veniva nemmeno caricato.
Il motivo era probabilmente l'imperdonabile leggerezza di installare il sistema su un hardware basato su Athlon Amd, mentre Socrate ha un Pentium 3 Intel, si presume che l'installazione abbia messo un kernel ottimizzato per Athlon e incompatibile con l'Intel definitivo.
Questa volta è andata decisamente meglio, anche se abbiamo passato lo stesso i nostri 10 minuti di sudore.
Poco prima di spegnere il muletto su cui è stata fatta la nuova installazione abbiamo di nuovo reimportato il database e eseguita la sincronizzazione dei log.
Staccato l'hard disk dal muletto, si è spento il vecchio Socrate, si è sostituito l'hard disk e riavviato.
Tutto è filato liscio: il kernel ha bootato senza problemi e kudzu, come sempre, ha fatto il suo lavoro: rimosse le configurazioni del vecchio hardware (scheda di rete, bus USB) ha riconosciuto senza sbavature quello nuovo e migrata la configurazione del network.
Il reboot si è completato in meno di 1 minuto e se avessimo fatto le cose con più attenzione il downtime totale sarebbe stato di un paio di minuti, che nel nostro caso sono più che accettabili.
Ma ovviamente abbiamo sbagliato qualcosa e ci abbiamo messo tempi diversi per capirlo:
- Default gateway: ci siamo dimenticati di impostare quello nuovo. Ovviamente la connettività di rete è stata una delle prime cose che abbiamo verificato e il problema si è risolto in pochi secondi.
- Il Sito non si vedeva! Eppure i processi httpd e mysqld erano attivi, gli access log fluivano apparentemente regolari e alcune pagine (statiche) si vedevano. Qui abbiamo perso tempo, 10 o 15 minuti, a verificare configurazione di Apache, accesso da IP diversi, regole di firewalling, log ecc.
Alla fine è stata risolutiva un'occhiata un minimo attenta di un netstat -nat: le connessioni al db venivano fatte ad un IP sbagliato, quello temporaneo che aveva la macchina appena installata prima di andare in produzione. A quel punto è bastato correggere il file /etc/hosts assegnando a Socrate il suo giusto IP pubblico.
CONSIDERAZIONI FINALI
La procedura che abbiamo adottato per l'aggiornamento di un server in produzione NON è certo quella ideale, ma risulta essere interessante, relativamente rapida e di fatto efficace se ci si può permettere un downtime di alcuni minuti, se non si ha un database in costante aggiornamento e si vuole mantenere l'hardware esistente (hard disk escluso, ovviamente).
Le cose sono andate nel verso previsto, gli unici problemi avuti sono imputabili a nostre disattenzioni e leggerezze, nonchè una fretta generale nel pianificare e gestire la migrazione.
Va notata la grande capacità di "adattamento" di un Linux con kernel modulare ad hardware diverso, una cosa simile con il plug&play di Windows sarebbe impensabile (e con Windows XP comporterebbe probabilmente l'invalidazione della chiave di attivazione).
In tutto, dall'inizio dell'installazione sul muletto al primo boot in produzione, abbiamo riavviato il nuovo Socrate 3 volte: la prima a fine installazione, la seconda, dopo tutti gli aggiornamenti di software e kernel, per testare il corretto ripristino del sistema, la terza direttamente in produzione su hardware diverso. In totale sono state impiegate circa 6 ore, oltretutto interrotte da altre attività.
Con Linux questo ed altro è possibile, ed è per questo che ci piace.

Storia delle Applicazioni Web
Il linguaggio Java fu concepito inizialmente per essere utilizzato in piccoli dispositivi integrati. Inizialmente venne publicizzato come linguaggio per lo sviluppo di contenuto elaborato sul lato client sotto forma di Applet. Ora invece Java è riuscito a farsi riconoscere come linguaggio ideale per lo sviluppo di applicazioni lato server.
La capacità di Java di abbracciare diverse piattaforme si rivela particolrmante utile per le organizzazioni che dispongono di un insieme eterogeneo di Server che eseguono diverse varianti di sistemi operativi Unix e Windows (e sempre piu' anche Mac OS X).
La moderna concezione a oggetti e a memoria protetta di Java permette agli sviluppatori di ridurre i cicli di sviluppo per incrementare l'affidabilità del loro codice.
Oltre a questo, il supporto incorporato di Java per le API di rete e a livello di impresa consente di accedere ai dati gestiti di sistemi legacy come i mainframe, agevolando la transizione dai sistemi client/server più datati.
Le servlet Java sono componenti chiave dello sviluppo Java con un grado di portabilità, flessibilità e facilità d'uso finora sconosciuto.
Sebbene le servlet possano essere impiegate per estendere la fuzionalità di qulunque server con supporto Java, nella maggior parte dei casi esse vengono utilizzate per estendere i server Web, configurandosi come potenti ed efficienti sostituti degli script CGI.
Quando si utilizza una servlet per la creazione di contenuto dinamico per una pagina Web o per estendere in altro modo la funzionalità di un server Web, ciò che in effetti avviene è la creaziione di un'applicazione Web.
Mentre una pagina Web si limita a visualizzare un contenuto statico e permette all'utente di spostarsi al suo interno, un'applicazione Web offre agli utenti un'esperienza più interattiva.
Un'applicazione Web può essere una semplice funzione di ricerca con parola chiave in un archivio di documenti oppure un complesso sito di commercio elettronico.
Le applicazioni Web interessano sia Internet sia le Intranet ed Extranet aziendali, dove sono in grado di aumentare la produttività e cambiare il modo in cui società grandi e piccole gestiscono la loro attività commerciale.
Per comprendere la potenza delle servlet, dobbiamo però fare un passo indietro ed esaminare alcune delle altre soluzioni che è possibile adottare per creare applicazioni Web.
Common Gateway Interface (CGI)
La Common Gateway Interface, nota comunemente come CGI, è stata una delle prime tecniche pratiche per la creazione di contenuto dinamico. Grazie a essa un server Web passa determinate richieste a un programma esterno, il cui output viene poi inviato al client al posto di un file statico. L'avvento della tecnologia CGI ha reso possibile l'implementazione di funzionalità nuove di ogni genere nelle pagine Web, tanto che essa è diventata rapidamente uno standard di fatto, implementato su tantissimi sever Web.
E' interessante osservare che la capacità dei programmi CGI di creare pagine Web dinamiche è un effetto collaterale dello scopo originale per il quale questa tecnica era stata concepita, ossia definire un metodo standard che consentisse a un server di informazioni di comunicare con le applicazioni esterne.
Questa origine spiega perchè il ciclo di vita di CGI è forse il peggiore che si possa immaginare.
Quando un server riceve una richiesta che accede a un programma CGI, deve creare un nuovo processo per eseguire il programma CGI e poi passare a quest'ultimo, tramite variabili di ambiente e standard input, tutte le informazioni che potrebbero essere necessarie per generare una risposta.
La creazione di un processo per tutte le richieste di questo tipo richiede tempo e impegna notevolmente le risorse del server, fattori che limitano il numero di richieste che un server può gestire contemporeanemente.
Anche se un programma CGI può essere scritto con quasi tutti i linguaggi oggi conosciuti, il linguaggio di programmazione Perl è diventata la scelta predominante.
Un altro problema spesso trascurato della tecnica CGI è che questo genere di programm non può interagire con il server Web o sfruttare le capacità di quest'ultimo una volta che inizia l'esecuzione in quanto essa ha luogo in un processo separato. Per esempio, uno script CGI non può scrivere sul file log del server.
FastCGI
Una società denominata Open Market ha sviluppato un'alternativa alla tecnologia CGI standard denominata FastCGI. Per molti aspetti FastCGI funziona come CGI, con l'importante differenza che la prima crea un singolo processo persistente per ogni programma FastCGI. Ciò elimina la necessita di creare un nuovo processo per ogni richiesta e aumenta considerevolmente la velocità di risposta alle richieste dei client.
Sebbene costituisca un passo in avanti, FastCGI presenta ancora un problema di proliferazione: esiste infatti almeno un processo per ogni programma FastCGI. Se un programma FastCGI deve gestire richieste concorrenti, ha bisogno di un pool di processi, uno per richiesta.
Se si considera che ciascun processo potrebbe esesguire un interprete Perl, questo metodo non riduce il carico sul sistema nella misura che si potrebbe sperare. Va detto comunque a favore di FastCGI che è una tecnica in grado di distribuire i suoi processi su più server.
Un altro problema di FastCGI è che non contribuisce in alcun modo a far si che il programma FastCGI interagisca in modo più stretto con il Web server. Infine,i programmi FastCGI sono portabili solo nella misura in cui lo è il linguaggio nel quale sono scritti. Per maggiori informazioni su FastCGI, si veda il sito http://www.fastcgi.con
PerlEx
Perl,sviluppato da ActiveState, migliora le prestazioni degli script CGI scritti in Perl che vengono eseguiti su server Web Windows (Internet Information Server di Microsoft, WebSite Professional di O'Reilly e Enterprise Server di iPlanet). Esso presenta vantaggi e svantaggi simili a quelli di FastCGI.
Per maggiori informazioni su PerlEx, si veda il sito http://www.activestate.com/plex.
mod_perl
Se si utilizza il Web Server Apache, per migliorare la prestazione della tecnologia CGI si puo ricorrere a mod_perl, un modulo per server Apache che incorpora una copia dell'interprete Perl nell'eseguibile di Apache, offrendo un accesso completo alla funzionalità Perl all'interno di Apache. Gli script CGI vengono precompilati da server ed eseguiti senza operazioni di forking, consentendo pertanto una maggiore velocità ed efficienza nelle operazioni.
Lo svantaggio è che l'applicazione è compatibile solo con il server Apache.
Per maggiori informazioni su mod_perl, si veda il sito http://perl.apache.org.
API di estensione del server
Sono diverse le società che hanno creato delle API di estensione del server proprietarie per i loro server Web. Per esempio,iPlanet/Netscape offre un'API interna chiamata WAI (inizialmente NSAPI), mentre Microsoft fornisce ISAPI. Con una di queste API è possibile scivere estensioni del server che ne potenziano o ne cambiano le funzionalità di base, permettendogli di gestire operazioni un tempo relegate a programmi CGI esterni. Le estensioni del server esistono all'interno del processo principale di un Server Web. Dato che le API specifiche del server usano codice C o C++ collegato tramite un linker, le estensioni del server possono offrire un'esecuzione molto rapida e sfruttare appieno le risorse del sistema. Le estensioni del server sono tuttavia ben lungi dall'essere una soluzioni perfetta. Oltre a presentare difficoltà di sviluppo e manutenzione, pongono seri rischi di sicurezza e affidabilità: un'estensione in crash può interrompere il funzionamento dell'intero server, mentre una maligna potrebbe sottrarre informazioni, come le password e i numeri di carta di credito degli utenti di un sito. Inoltre, le estensioni del server proprietarie sono ovviamente legate in modo inscindibile alle API del server per la quale sono state scritte e spesso anche a un particolare sistema operativo.
Server-Side JavaScript
Anche iPlanet/Netscape offre una tecnica per lo scripting sul lato server chiamata SSJS (Server-Side JavaScript). Come ASP, SSJS permette di incorporare frammenti di codice nelle pagine HTML per generare un contenuto Web dinamico. La differenza è che SSJS utilizza JavaScript come linguaggio di scipting. Con SSJS le pagine Web vengono precompilate per migliorare le prestazioni. Il supporto per Server-Side JavaScript e' disponibile solo con i server iPlanet/Netscape.
Active Server Pages (ASP)
Microsoft ha messo a punto una tecnica per la generazione di contenuto Web dinamico chiamata ASP (Active Server Pages), per mezzo della quale una pagina HTML sul server Web può contenere frammenti di codice incorporato (in genere VBScript o JScript, anche se è possibile utilizzare quasi tutti i linguaggi). Tale codice viene letto ed eseguito dal server Web prima che questo invii la pagina al client, ASP è ottimizzato per la gnerazione di piccole parti di contenuto dimamico, sfruttando i componenti COM per compiere il lavoro pesante.
Il supporto per ASP è integrato in MIcrosoft Internet Information Server versione 3.0 e successive, disponibile gratuitamente all'indirizzo http://www.microsoft.com/iis.
Il supporto per altri server Web è disponibile come prodotto commerciale presso Chili!Soft, http://www.chilisoft.com. E' importante tenere presente che le pagine ASP in esecuzione su una piattaforma differente da Windows potrebbero incontrare difficoltà nello svolgimento di operazioni avanzate senza la libreria COM di Windows.
PHP
PHP, che significa "PHP: Hypertext Preprocessor", è un linguaggio di scripting general-purpose Open Source molto utilizzato, è specialmente indicato per lo sviluppo Web e può essere integrato nell'HTML. La sua sintassi è basata su quella di C, Java e Perl, ed è molto semplice da imparare. L'obiettivo principale del linguaggio è quello di permettere agli sviluppatori web di scrivere velocemente pagine web dinamiche, ma con PHP si possono fare molte altre cose.
Tra i vantaggi di PHP sicuramente sta nel fatto che è completamente open source, quindi molto usato e conosciuto. Inoltre è integrabile in numerosi server Web.
Tra i contro è poco orientato agli oggetti, le librerie standard hanno aspetto procedurale e caratteristiche importanti sono disponibili soltanto nelle recenti versioni.
Il manuale e maggiori informazioni dono disponibili sul sito http://www.php.net/.
JavaServer Pages
JSP(JavaSeverPages) è un'alternativa ad ASP basata su Java, inventata e standardizzata da Sun. JSP utilizza una sintassi simile a quella di ASP, con la differenza che il linguaggio di scripting è Java.
A differenza di ASP, JSP è uno standard aperto implementato da moltissimi produttori su tutte le piattaforme. JSP è strettamente legato alle servlet, perchè una pagina JSP viene trasformata in un servlet come parte della sua esecuzione. Per maggiori informazioni su JSP, si veda il sito http://java.sun.com/products/jsp.
Servlet Java
Una servlet è un'estensione del server generica, una classe Java che può essere caricata in modo dinamico per espandere la funzionalità di un server. Le servlet sono utilizzate comunemente con i server Web, dove possono prendere il posto degli script CGI. Una servlet è simile a un'estensione del server proprietaria, tranne per il fatto che la sua esecuzione ha luogo all'interno di una JVM(Java Virtual Machine) sul server e pertanto è sicura e portabile.
Le servlet operano unicamente all'interno del dominio del server. A differenza delle applet, non richiedono che il browser Web offra il supporto Java.
A differenza di CGI e FastCGI, che devono usare più processi per gestire programmi e/o richieste separati, tutte le servlet possono essere gestite da thread separati all'interno dello stesso processo o da thread a più processi diffusi su diversi server backend. Ciò significa che le servlet sono sia efficienti sia scalabili. Instaurando una comunicazione bidirezionale con il server Web, le servlet possono interagire in modo molto stretto con il server per fare ciò che non è possibile con gli script CGI.
Un altro vantaggio delle servlet è la loro portabilità, relativa sia ai sistemi operativi, caratteristica già presente in Java, sia ai server Web.
Lo svantaggio maggiore è una certa pesantezza dovuta alla necessità di avere in memoria un intera Java Virtual Machine al cui interno devono andare in esecuzione le servlet.

Strumenti per diagnosticare problemi con Samba
Il mondo delle reti CIFS presenta insidie di varia natura, il protocollo è a suo modo contorto e le implementazioni di diversi produttori possono dar luogo a problematiche diverse.
Per diagnosticare problemi con Samba esistono vari strumenti a disposizione degli utenti:
- I log di Samba stesso
- I vari tool Samba presenti nel pacchetto ufficiale
- Genericamente, i vari strumenti di sistema disponibili su Unix e Windows per diagnosticare problemi di rete e servizi.
I LOG DI SAMBA
Sono tipicamente fra le prime cose da guardare. Nel file di configurazione è possibile definire vari parametri tra cui:
log file = %m.log - Il nome e la logica con cui vengono salvati i log (possono essere divisi per utente, macchina ecc);
debug level = 2 - La verbosità dei log stessi, con valori che vanno da 0 (nessun logging) a 10 (maggimo debugging). Un valore di debug di 3 o superiore è già fin troppo verboso e va usato solo per diagnosi, in quanto tende a rallentare il sistema.
E' possibile modificare il livello di logging inviando al processo smbd i segnali SIGUSR1 per incrementarlo di uno e SIGUSR2 per diminuirlo di uno.
UTILITY SAMBA
Varie sono le utility di Samba per diagnosticare problemi.
testparm serve per verificare la correttezza della sintassi del file di configurazione e per verificare se un dato host può collegarsi alla macchina Samba locale (sulla base delle access list di smb.conf, altri impedimenti dovuti a iptables o altro non sono contemplati): testparm hostname 10.0.0.150, per esempio, elenca per tutte le condivisioni del proprio sistema, se l'host 10.0.0.150 ha diritto di accesso.
smbclient è comodo per enumerare le condivisioni di un server e capire come e cosa esporta. smbclient -L 10.0.0.150 enumera tutte le condivisioni di 10.0.0.150. Viene chiesta una password, dare invio per fare un accesso anonimo o specificare -U utente (e poi relativa password) per accedere con specifiche credenziali.
nmblookup si usa per ottenere i nomi NetBIOS e i relativi IP degli Host in rete, tramite broadcast o query diretta, nmblookup -d 3 '*', per esempio, individua, nella propria rete (dominio di broadcast), gli host che rispondono ad una query nmb.
UTILITY UNIX
La diagnosi di problemi con Samba coinvolge anche problematiche di rete: server e client devono poter comunicare via IP e avere accesso alle porte netbios-ns 137/udp, netbios-dgm 138/udp, netbios-ssn 139/tcp e microsoft-ds 445/tcp (usata da CIFS, se non è raggiungibile si usa la 139) non ci devono quindi essere firewall o altri impedimenti che impediscano lo scambio di dati.
La diagnosi inoltre coinvolge l'effettiva esistenza di un server in ascolto sulla porta 139 o 445 e l'eventuale sniffing dei pacchetti in transito. Comandi utili per queste attività sono:
ping Comando tipico per testare la connettività di rete IP fra due host, in ogni caso da affiancare a un test diretto tipo telnet 10.0.0.150 139 per verificare se alla porta 139 del server indicato risponde qualcosa.
Su un server Samba, per verificare che il servizio sia partito e sia in ascolto e disponibile in rete, digitare netstat -natp e cercare righe tipo tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 4608/smbd che indicano che il processo smbd è in ascolto (LISTEN) sulla porta 139 su tutti gli indirizzi (0.0.0.0, basterebbe anche l'indirizzo dell'interfaccie di rete).
Verificare inoltre che non si siano firewall esterni o interni che impediscano l'accesso alla prota 139 tcp (con iptables -L -n si visualizzano le regole di firewalling sul proprio Linux).
Se il client può accedere via rete al server e su questo è in esecuzione il processo che gestisce SMB, eventuali problemi possono essere dovuti al protocollo SMB/CIFS stesso (autenticazione, ecc), per cui possono essere utilizzati i comandi Samba sopra indicati o si può provare a diagnosticare cosa accade sniffando direttamente i pacchetti con strumenti come tcpdump (analizza solo le intestazioni dei pacchetti) o ethereal (visualizza e analizza tutto il contenuto di un pacchetto).
A livello applicativo, sul server Samba, può servire utilizzare strumenti come ps -adef per verificare che i processi smbd e nmbd siano in esecuzione, strace -p #PID per analizzare a basso livello le chiamate di sistema del processo di cui si è indicato il PID, lsof per visualizzare i file aperti dai processi in esecuzione.

su
Permette di aprire una shell avendo i permessi di un altro utente. Se non viene specificato l'utente, viene usato il superuser (root) di default. Se l'operazione comporta un aumento dei propri poteri viene richiesta la password dell'utente specificato.
Presente anche in Unix, in alcuni casi con la sola opzione -.
su [opzioni] [-] [-c comando] [nome_utente] [argomenti_shell]
-, -l, --login Invoca la shell eseguendo tutti i relativi script di startup e ricreando l'environment dell'utente (se non specificato viene mantenuto l'environment dell'utente che l'ha eseguito)
-c comando Esegue il comando specificato in una nuova shell e termina immediatamente.

sudo
Utility che permette di eseguire un comando come se fosse un altro utente.
Tipicamente utilizzato per lanciare comandi come root da utenti "normali".
sudo [opzioni] commando
Opzioni comunemente utilizzate:
-l Visualizza i comandi permessi e negati dell'utente corrente
-b Esegue il comando in background
-s Esegue la shell dell'utente specificato, se non si specifica nessun utente viene richiamata una shell con i permessi di root
-p prompt Visualizza il "prompt" specificato e sovrascrive quello di default
-a auth_type Specifica il tipo di autenticazione utente utilizzato da sudo
-u username|#uid Specifica con quale utente dovrà essere lanciato il comando, se l'opzione è omessa sudo interpreterà il comando come se dovesse lanciare il comando da utente root
Esempi:
Lancio di un singolo comando
[neo@dido neo]$ sudo /etc/rc.d/init.d/cups restart
Password:
Stopping cups: [ OK ]
Starting cups: [ OK ]
Richiamare la shell di root
[neo@dido neo]$ sudo -s
Password:
[root@dido neo]#
Visualizzazione dei comandi che si possono lanciare tramite sudo:
[neo@dido neo]$ sudo -l
User neo may run the following commands on this host:
(ALL) ALL

Suse 9: Logs management
SuSE's log management is similar to the one used on every Unix.
The Syslog service, configured via the usual /etc/syslog.conf file manages the system's logs.
Its default configurations are quite common in some parts:
/var/log/messages receives every log except mail and news;
/var/log/mail has all the logs about the mail system, who are also divided in further files according to the debug level: mail.info mail.warn mail.err;
/var/log/news/ directory contains all the logs about the news service;
Other useful settings are:
/var/log/localmessages receives all the messages from the local facilities (from local0 to local 7);
/dev/tty10 displays kernel warnings and all the errors (Alt+F10 to see them).
/var/log/warn collects all the system warnings, errors and critical messages.
The syslogd used is the typical Linux variant of the BSD syslogd with support for a separated kernel logging daemon (klogd).
Log rotation facilities are, by deafult, left in the flexible hands of logrotate whose main configuration file /etc/logrotate.conf is configured to add all the configuration includes in the /etc/logrotate.d/ directory.
The default settings provide a weekly rotation with a total retention of 4 weeks, but the configuration includes for single services (apache, samba, squid, fetchmail etc) tend to rotate logs when they reach a fixed size and keep a retention of 99 archived log files.
Other interesting logs are:
/var/log/update-messages displays verbose messages and readmes about some updated packages;
/var/log/SaX.log /var/log/XFree86.0.log /var/log/kdm.log all provide (similar) logs about the X Window system;
/var/log/boot.msg sums up both the kernel and the system's services log related to the last boot;
/var/log/YaST2/ directory contains all the logs about YaST, amonth these you find y2logRPM (the list of the installed RPMs).
If you install the sysreport package you can find the sar logs in the /var/log/sa/ directory.

Suse 9: Network configuration
Network configuration on Suse has substantially evolved since version 8.0 and resembles the one found in various other Linux distributions.
As usual Yast2 can be used to fully configure network devices nad TCP/IP settings and since we presume you already know how to do it with a graphical interface, let's see, more deeply the involved files.
Configuration files
/etc/sysconfig/network/ifcfg-*
These are the systems's configuration files for every network interface where "*" can be the name of the inteface (eth0, eth1, lo, ppp0...), its MAC address (ex: 00c09f2dc8a4) or indicate what hardware is used (usb, pcmcia).
The main parameters used in these files are:
BOOTPROTO - Can be static (IP configured manually), dhcp (IP oubtained through DHCP)
IPADDR BROADCAST NETMASK NETWORK - Define typical IP parameters: IP address, broadcast, netmask and network address
MTU - Defines the Maximum Transfer Unit (the size of every IP packet). Default on ethernet devices is 1500.
STARTMODE - Indicates the to activate the interface: onboot (at system's boot), hotplug (when a pluggable network device is inserted), manual (manually).
Other parameters can be used and can vary according to the interface type.
/etc/sysconfig/network/config
Contains various, well commented, variables that are applied to every interface, they include also what actions can be done when the interface status is changed. The same values can be specified in the single /etc/sysconfig/network/ifcfg-* files, for a more granular control on the single interfaces.
/etc/sysconfig/network/dhcp, similarly, sets parameters related to dhcp use (logging, lease time, timouts, modification of system's settings, wait time at boot and so on).
/etc/sysconfig/network/wireless sets and describes the various parameters that can be applied to wireless devices (wieless mode, essid, frequency, sensibility, encryption key...). As usual they can be used in the ifcfg files of the single wireless devices, but it's useful to know the options than can be used.
/etc/sysconfig/network/routes
Defines all the (general) static routes. It's possible to specify routes exclusively related to the activation of single interfaces with the files /etc/sysconfig/network/ifroute-interface.
The format of this file is:
DESTINATION GATEWAY NETMASK|PREFIX INTERFACE [TYPE] [OPTIONS]
/etc/resolv.conf
Defines, as in most Unixes, the address of the DNS server to be used by the system.
Some services (pppd, ipppd, dhcpclient, hotplug, pcmcia, pptpclient) can temporarily modify this file in order to use, according to the new connection established, the appropriate DNS server. This is done by Suse's nice shell script /sbin/modify_resolvconf which has various options to handle and manage different dynamic entries in /etc/resolv.conf and /etc/named.conf.
/etc/hosts
As in most Unixes, in this file you can statically assign IP addresses to host names. You can also use /etc/networks for IP networks. The resolver by default first checks this file, before querying the DNS servers in /etc/resolv.conf. This order and other settings about how the system assigns names to resources can be changed (as in every Linux) in /etc/host.conf (old configuration file used by libc4 and libc5 linked programs) or /etc/nsswitch.conf (used by every recent program linked with glibc libraries).
/etc/HOSTNAME
Contains the hostname of the system, used by various startup scripts.
Commands
SuSE features typical Linux network related commands as ifconfig route netstat ip and other commands which can be found in various distros such as ifup (can be invoked also by the symlinks ifstatus or ifdown giving status info on the specified interface or shutting it down) .
Similarly to RedHat's service command, SuSE provides a set of scripts, or better symlinks, to manage to init scripts for the various services:
/sbin/rcnetwork restart restarts the network services as would do the command /etc/init.d/network restart.

Swat, utility di configurazione di Samba
Quando ci si appresta a configurare approfonditamente un samba server ci si scontra inevitabilmente con la grande quantita di opzioni globali e di share. Averne un prospetto completo a mente è un'impresa titanica e a questo scopo ci si può avvalere di un comodo strumento di configurazione, swat.
Swat, Samba Web Administation Tool, viene comunemente installato con il pacchetto Samba e se si utilizza una distribuzione che installa la suite non necessita di ulteriori modifiche, a parte forse scommentarne la voce relativa nel file /etc/inetd.conf a seconda della distribuzione.
In effetti si tratta di un servizio che viene generalmente invocato da inetd e fornisce un'interfaccia web utile per creare e modificare il file smb.conf e per studiarne le opzioni.
E' buona norma comunque se si vuole utilizzarlo controllare prima di tutto due file:
- /etc/services e verificare che sia presente ed eventualmente aggiungere la voce:
swat 901/tcp
Definizione non ufficiale e che in alcune reti potrebbe entrare in conflitto con altri servizi
- /etc/inetd.conf e verificare o aggiungere la riga:
swat stream tcp nowait.400 root /percorso/eseguibile/swat swat
Dove il percorso al file può variare a seconda della distribuzione usata o dove si è deciso di installare Samba
Una volta eseguite queste semplici operazioni si può aprire il nostro web browser preferito e digitare: http://localhost:901/
Ci apparirà una finestra che ci chiede di inserire nome utente e password e dovremo usare l'utente root e la sua relativa password di sistema.
A questo punto si ha accesso ad una serie di menu che in poco tempo ci permetterà di creare un file di configurazione per Samba. La cosa che trovo più utile e importante è che per ogni opzione settabile si ha un link ad un help che ne descrive il significato, i valori di default e così via. Non solo, prima l'ho descritto come tool anche per studiare, infatti sotto il menu HOME si ha la possibilità di accedere comodamente a un grande quantità di documentazione, pagine man e vari how-to, permettendo così di iniziare la nostra configurazione con un comodo appoggio per imparare.
Va ricordato che nonostante sia possibile collegarsi anche da macchine remote, swat non ha di default la possibilità di usare password crittografate con di conseguenza il rischio che qualcuno sulla rete possa sniffare i pacchetti e leggere in chiaro la password dell'utente root sul samba server. Esiste la possibilità di criptare le password anche se swat non lo supporta nativamente. Si può trovare un breve how-to introduttivo su www.samba.org chiamato swat_ssl.html.
Un'altro grande difetto di swat è il fatto che utilizzato su un file esistente ne modificherà anche il layout. Tutti i commenti eventualmente aggiunti e le opzioni include e copy verranno cancellati.
Questo ne fa a mio avviso un ottimo punto di partenza per il principiante, permettendo di creare un primo file di configurazione e in seguito editarlo finemente con un editor di testi.

tar
Programma di archiviazione progettato per immagazzinare ed estrarre file da un archivio conosciuto come un tarfile.
Un tarfile può essere fatto su un'unità a nastro magnetico o su un file normale.
tar [opzioni] file1, file2, ... , fileN
-A, --catenate, --concatenate aggiunge i file ad un archivio
-c, --create crea un nuovo archivio
--delete elimina dall'archivio (da non usare sui nastri magnetici!)
-r, --append aggiunge i file alla fine di un archivio
-t, --list elenca il contenuto di un archivio
-u, --update aggiunge solamente i file che sono pi recenti della copia nell'archivio
-x, --extract, --get estrae i file da un archivio
-f, --file [NOME_HOST:]F usa il file di archivo o dispostivo F (default /dev/rmt0)
-L, --tape-length N cambia il nastro dopo aver scritto N*1024 byte
-p, --same-permissions, --preserve-permissions estrae tutte le informazioni relative ai permessi
-v, --verbose elenco minuzioso dei file elaborati
-z, --gzip, --ungzip filtra l'archivio attraverso gzip

umount
Smonta il file system specificato e lo rende inaccessibile al sistema.
E' il comando che esegue l'operazione opposta a mount.
Qualsiasi operazione in corso sul filesytem da smontare viene conclusa e la struttura del file system segnata come pulita (clean).
umount [opzioni] [device|directory]
-a Smonta tutti i file system montati (visualizzati in /etc/mtab)
-n Smonta tutti i file system montati SENZA memorizzare le modifche in /etc/mtab
-t tipo Smonta tutti i file system del tipo specificato.
Esempi
umount /dev/fd0 Smonta il floppy (operazione necessaria prima di estrarre fisicamente il dischetto). Questo comando è analogo a umount /mnt/floppy (se il floppy è montato sulla directory /mnt/floppy.
umount /mnt/cdrom Smonta il CDROM (se è montato sulla directory /mnt/cdrom). Nello specifico per i CDROM può essere usato il comando eject che smonta ed espelle il CD.

Upgrade di Apache
Aggiornare Apache con regolarità e sopratutto in caso di patching di nuovi buchi di sicurezza è un'attività fondamentale che non richiede molto tempo.
Segue lo standard output della procedura di aggiornamenti di Apache dalla versione 1.3.26 alla versione 1.3.27. Quanto qui riportato è ovviamente fattibile anche con altre versioni (ma non con un passaggio dalla 1.3 alla 2.0).
In questo caso la compilazione viene eseguita sul server stesso su cui gira Apache e usando la base directory di default ( /usr/local/apache ).
Per sicurezza si fa un backup preventivo di tutta la basedir di Apache
[root@socrate al]# tar -zcvf backup.tar.gz /usr/local/apache
Download dei sorgenti con wget
[root@socrate al]# wget http://nagoya.apache.org/dist/httpd/apache_1.3.27.tar.gz
--09:46:37-- http://nagoya.apache.org/dist/httpd/apache_1.3.27.tar.gz
=> `apache_1.3.27.tar.gz'
Resolving nagoya.apache.org... done.
Connecting to nagoya.apache.org[192.18.49.131]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,306,052 [application/x-tar]
100%[====================================>] 2,306,052 16.80K/s ETA 00:00
09:48:52 (16.80 KB/s) - `apache_1.3.27.tar.gz' saved [2306052/2306052]
Scompattazione del tarball
[root@socrate al]# tar -zxvf apache_1.3.27.tar.gz
apache_1.3.27/
apache_1.3.27/cgi-bin/
apache_1.3.27/cgi-bin/printenv
apache_1.3.27/cgi-bin/test-cgi
apache_1.3.27/ABOUT_APACHE
apache_1.3.27/Announcement
apache_1.3.27/INSTALL
apache_1.3.27/LICENSE
apache_1.3.27/Makefile.tmpl
apache_1.3.27/README
[...]
apache_1.3.27/src/Configuration
Si entra nella directory appena scompattata. Allo stesso livello si ha la directory apache_1.3.26 con i sorgenti della versione precedente
[root@socrate al]# cd apache_1.3.27/
Si esegue lo script config.status in apache_1.3.26 che contiene il ./configure con i parametri utilizzati nell'ultima compilazione. Ovviamente la compilazione la si fa sui sorgenti della versione 1.3.27 (trovandosi nella relativa directory).
[root@socrate apache_1.3.27]# ../apache_1.3.26/config.status
Configuring for Apache, Version 1.3.27
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ checking for system header files
+ adding selected modules
[...]
Si compilano i sorgenti...
[root@socrate apache_1.3.27]# make
===> src
make[1]: Entering directory `/home/al/apache_1.3.27'
[...]
Si installano i binari compilati. Se si vuole evitare potenziali complicazioni di conflitti sui file, a questo punto è possibile stoppare il server web. In questo caso non lo si è fatto e non si sono avuti problemi.
[root@socrate apache_1.3.27]# make install
make[1]: Entering directory `/home/al/apache_1.3.27'
===> [mktree: Creating Apache installation tree]
./src/helpers/mkdir.sh /usr/local/apache/bin
[...]
Si riavvia il server Web. Il file di configurazione non è stato cambiato e tutto torna a funzionare correttamente
[root@socrate apache_1.3.27]# /usr/local/apache/bin/apachectl restart
/usr/local/apache/bin/apachectl restart: httpd restarted
Per scrupolo si verifica la versione corrente:
[root@socrate apache_1.3.27]# httpd -V
Server version: Apache/1.3.27 (Unix)
Server built: Nov 6 2002 09:53:02
Server's Module Magic Number: 19990320:13
Server compiled with....
-D HAVE_MMAP
[...]

uptime
Visualizza da quanto tempo il sistema è attivo.
Uptime visualizza una riga contenente l'ora corrente, da quanto tempo il sistema è up, quanti utenti sono loggati attualmente sul sistema, il carico medio di utilizzo del sistema nell' ultimo minuto, negli ultimi 5 e negli ultimi 15 minuti. Le informazioni visualizzate vengono ricavate da /var/run/utmp, /proc e /proc/loadavg.
homer@Joker:~$ uptime
10:13:24 up 1:44, 3 users, load average: 0.06, 0.02, 0.00
Sono le ore 10.13, il sistema è up da 1 ora e 44 minuti, al momento ci sono 3 utenti loggati e il carico medio della cpu negli ultimi 1,5, e 15 minuti è stato rispettivamente 0.06, 0.02, 0.00

Usare Internet: panoramica sui software ed i protocolli
Fruire dei contenuti della Rete, e comunicare tramite essa, è possibile grazie a diversi software e protocolli che permettono lo scambio di molteplici tipi di informazioni.
WEB
Le pagine Web, scritte in linguaggio HTML (Hyper Text Markup Language), vengono visualizzate da un applicazione chiamata Web Browser o più semplicemente Browser, il quale avvalendosi del protocollo HTTP (Hyper Text Transfer Protocol) o HTTPS trasferisce i dati da un Web Server (un host in rete sul quale è in funzione un software che fornisce le pagine richieste) ai Web Browser, ovvero i client in funzione sui computer degli utenti.
Nella sua forma base, un Web Server è un computer generalmente online 24 ore su 24 (come ogni server su Internet), ha un indirizzo IP fisso a cui è associato un nome tipo www.dominio.com e, tramite un software dedicato (Apache, IIS, Zeus...) non fa altro che fornire file ai client che li richiedono.
Questi file sono tipicamente sia immagini (di solito in formato GIF e JPEG) e pagine HTML, che normali file ASCII contenenti il testo di un linguaggio di programmazione ipertestuale che permette di formattare testo, grafica e link all'interno di schermate visualizzabili dal browser. Il gran numero di server web, i quali contengono una enorme quantità di pagine html che a loro volta includono innumerevoli link ipertestuali che collegano altre pagine, costituiscono l'ossatura di questa ragnatela globale che collega logicamente pagine e server fisicamente dislocati in ogni parte del globo.

Tra i Web Browser più conosciuti è possibile annoverare tra i piu anziani, Netscape Navigator ed Explorer mentre tra i più recenti troviamo nomi come Mozilla, Opera, Safari o Firebird. Browser che si sono evoluti nel tempo, passando da semplice supporto per la visualizzazione del testo, a quello per la grafica, all'utilizzo come client FTP ed alla gestione di stream audio e video.
E-MAIL
La scrittura, l'invio e la ricezione dei messaggi di posta elettronica E-Mail (Electronic Mail) avviene tramite un software chiamato Mail Client. L'utente destinatario del messaggio viene individuato tramite il suo E-Mail Address (Indirizzo di posta elettronica) scritto nella forma nome@dominio (Es. homer@nuclear-plant.com).Il client di posta grazie al protocollo SMTP (Simple Mail Transfer Protocol) lo inoltrerà ad un mail server il quale provvederà a recapitarlo a destinazione. Sempre grazie al client di posta, una volte connesso propria mailbox tramite i protocolli POP3 (Post Office Protocol versione 3) oppure IMAP (Internet Message Access Protocol), è possibile leggere i messaggi ricevuti.
Tra i client di posta elettronica abbiamo software quali Eudora, Outlook, Mozilla Mail, Kmail, Evolution, oppure il recente Thunderbird. La quasi totalità dei fornitori di caselle di posta, permette oggi di accedere alla propria mailbox anche tramite browser, grazie allo sviluppo di apposite interfacce web.
NEWSGROUP
La consultazione dei newsgroup avviene contattando un news server tramite un news client, scaricandone l'elenco e sottoscrivendo quelli di proprio interesse. Il protocollo utilizzato prende il nome di NNTP (Network News Protocol).
I news client, possono essere incorporati all'interno di un client di posta come nel caso di Outlook, Mozilla o Thunderbird oppure come Knode o Free Agent sviluppati apossitamente per lo scopo. vengono utilizzati per visualizzare i messaggi sui newsgroup (Gruppi di discussione) la cui rete era originariamente chiamata Usenet.
FILE TRANSFER
Sebbene l'utilizzo di Internet comporti praticamente sempre il trasferimento di informazioni e file anche senza che l'utente ne sia consapevole (HTTP per esempio), esistono software e protocolli specificatamente sviluppati per questo scopo, si tratta di FTP (File Transfer Protocol) e di TFTP (Trivial File Transfer Protocol).
Il primo più largamente usato, mentre il secondo utilizzato per compiti particolari quali il trasferimento di configurazioni e file su router o su stampanti in ambito LAN.
SESSIONI REMOTE
Un possibilità forse poco utilizzata attualmente da un utente Internet è quella di instaurare una sessione di lavoro in remoto tramite Telnet, il quale è sia il nome del software lato client e server, sia il nome del protocollo che viene utilizzato per l'emulazione di terminale.
Il suo utilizzo riguarda ormai principalmente la connessione a server o router per da parte di un amministratore di sistema al fine di gestirne la configurazione. Preferito a Telnet per maggior sicurezza è SSH (Secure Shell) che permette di utilizzare un terminale remoto in modo protetto grazie alla crittografia.
CHAT e INSTANT MESSAGING, VIDEOCONFERENZA, TV ON DEMAND e TELEFONIA
Tra le opportunità che la rete offre ai propri utenti c'è la comunicazione in tempo reale, possibile con limitate risorse in termini di banda per quanto riguarda Chat e Messengers, decisamente più avara di risorse per quanta riguarda la Videoconferenza, o la Tv on Demand o la telefonia.
Una sessione di chat si svolge collegandosi ad un IRC Server (a sua volta collegato in rete con altri server). Il protocollo utilizzato da questo servizio prende il nome di IRC (Internet Relay Chat). Tra i client più diffusi possiamo trovare mIRC, X-Chat, Bigfun, Pirch o KVirc. Anche in questo tipo di servizio si sono inseriti i browser che permettono di utilizzare chat appositamente create solitamente tramite tecnologie Java chiamate Web-Chat.
Tra i programmi di messaggistica, una sorta di evuluzione delle chat, i nomi più diffusi sono ICQ, AOL, MSN, Yahoo Messenger o C6.
Per l'utilizzo dei programmi di videoconferenza è necessario avere microfono, webcam e scheda audio ed una sufficiente ampiezza di banda al fine di ottenere una chiara comunicazione con gli altri partecipanti. Tra i software utilizzati in questo campo: CU-SeeMe, NetMeeting oppure GnomeMeeting su Linux.
Per quanto riguarda invece la Tv on demand vengono utilizzati hardware di tipo particolare come per esempio i decoder ed altri apparati dedicati i quali con l'ausilio di un televisore e grazie a collegamenti in fibra ottica o ADSL permettono la visualizzazione dei programmi scelti dall'utente.
La telefonia tramite Internet avviene grazie alla tecnologia Voice Over IP, la quale permette inviare su reti IP lo voce con pacchetti ad altissima priorità.
DNS
Dietro le quinte, lavora il protocollo DNS (Domain Name System) il quale grazie ai DNS Server permette di associare ad un URL come per esempio www.coresis.com  oppure irc.tin.it un indirizzo IP grazie al quale computer dell'utente può raggiungere la risorsa desiderata.

Usare pacchetti (rpm) per l'installazione di programmi su Linux
Per installare dei programmi su Linux esistono vari modi:
- compilare il sorgente, pratica che può essere complessa ma è utile in casi particolari;
- utilizzare pacchetti (packages) che contengono i programmi già compilati e pronti per l'uso, facilitando e standardizzando la gestione del software sul sistema.
I sistemi di package più comuni su Linux sono RPM e DEB.
I pacchetti .deb vengono usati nelle distribuzioni derivate da Debian, gli .rpm sono stati definiti da RedHat e risultano essere i più diffusi.
Slackware pacchettizza il suoi programmi con normali tar gzippati: .tgz.
Affrontiamo qui l'uso di RPM, Red Hat Package Manager, sottolineando che file .deb e, in parte, .tgz vengono gestiti con comandi diversi ma hanno una logica simile.
Un package costruito con RPM è un archivio di file e informazioni che può essere installato, rimosso, interrogato sul sistema.
RPM permette di installare programmi, già compilati, con una facilità e rapidità estrema sul proprio Linux (è paragonabile ad un unico setup.exe su Windows).
Si sottolinea che ogni distribuzione e anche ogni versione della stessa distribuzione richiede pacchetti dedicati, adatti per il proprio sistema: un RPM realizzato per RedHat 6.2, per esempio, difficilmente funzionerà su RedHat 7.2.
RPM gestisce automaticamente le "dependencies": se si prova ad installare un RPM che richiede librerie o programmi non presenti o non abbastanza aggiornati sul sistema, l'installazione fallisce e viene indicato quali file mancano.
Analogamente, se si prova a rimuovere un package che contiene file utilizzati da altri programmi, viene dato un messaggio di errore.
Gli RPM automaticamente distribuiscono i file di un pacchetto nelle directory giuste (logs in /var/log, file di configurazione in /etc/, binari in /usr/bin o /usr/sbin, script di startup in /etc/rc.d/init.d/ ecc.) e verificano la presenza di conflitti o installazioni più recenti.
La rimozione di un RPM non cancella mai nulla che non abbia installato. Se deve sostituire o cancellare un file di configurazione, per esempio, viene mantenuto il file esistente con il suffisso .rpmsave.
Le opzioni più comuni per usare il comando rpm per gestire file .rpm sono:
rpm -i [opzioni] pacchetto Installa il pacchetto .rpm specificato.
rpm -U [opzioni] pacchetto Aggiorna il pacchetto con una versione più recente.
rpm -e [opzioni] pacchetto Disinstalla il pacchetto, rimuovendone i file dal sistema.
rpm -q [opzioni] [pacchetto] Visualizza informazioni varie sul pacchetto (descrizione, file contenuti ecc.)
Le comuni distribuzioni Linux offrono svariati tool grafici per una semplice gestione dei pacchetti installati sul sistema. Di fatto questi programmi eseguono le stesse operazioni del comando rpm, ma sono più semplici ed immediate da usare.
La tendenza, sempre più diffusa, è quella di prevedere meccanismi di update automatizzato, per gestire il sempre alto numero di aggiornamenti (per sicurezza e bug fix) di programmi.
E' un principio analogo al Windows Update su sistemi Microsoft, ma si applica a tutti i programmi installati, e non solo al sistema operativo.

userdel
Cancella un account e i relativi file
userdel [-r] login-name
-r Oltre a cancellare l'account vengono cancellate anche la home directory (di default viene lasciata inalterata) e la posta.

usermod
Comando che permette di cambiare le impostazioni di un account creato precedentemente.
usermod [opzioni] login-name
-c comment Modifica, aggiunge il commento
-d home_dir Modifica la home_dir dell'utente
-e expire_date Modifica l'expire_date, ovvero quando l'account verrà disabilitato
-f inactive_days Modifica il numero di giorni che intercorrono fra la scadenza della password e la disabilitazione dell'account
-g initial_group Modifica il gruppo primario
-G groups Modifica i Gruppi secondari
-l login Cambia il nome di login dell'utente
-p password Modifica la password (criptata)
-s shells Modifica la shell di default dell'utente
-u UID Modifica l'UID
-L Esegue il lock dell'account
-U Operazione inversa del lock, ovvero riabilita l'account

vi oppure vedi qui
VI è un editor di testi molto comune e diffuso su ogni Unix.
Per la sua natura testuale, lanciabile direttamente da shell, per le antiche origini e la larga diffusione è, insieme ad Emacs, l'editor di testi più utilizzato su Unix.
vi [file] Apre il file con VI
vi [+n][file] Apre il file con VI alla riga corrispondente al numero
Se non si specifica il nome del file VI apre una sessione nuova.

VPND, Virtual Private Network Daemon
Vpnd è una alternativa relativamente semplice e piuttosto funzionale per realizzare VPN interamente basate su Linux (e altri Unix). I dati tra le due reti remote vengono criptati, dai gateway dove gira il demone VPND con l'algoritmo Blowfish, dopo uno scambio manuale preventivo di chiavi.
Necessita delle libreirie zlip e del supporto SLIP sul kernel per funzionare.
INSTALLAZIONE
Prima di installare verificare che il kernel supporti l'interfaccia SLIP (Serial Line Internet Protocol), che viene utilizzata da vpnd per effettuare la connessione tramite linea seriale (modem) o IP.
Decompressi i sorgenti lanciare i soliti configure/make:
root@urano:/usr/src/vpnd#./configure
root@urano:/usr/src/vpnd# make
gcc -DCOMPRESS -DLINUX -DLINUX2 -Wall -O3 -fno-inline -DCRYPTOX86 -DMD5_HMAC_FAST -DSHA1_HMAC_FAST -DRMD160_HMAC_FAST -c -o vpnd.o vpnd.c
.....
CONFIGURAZIONE
Il file di configurazione di Vpnd è di default /etc/vpnd.conf, nel caso si usi il modem per effettuare la VPN è necessario configurare anche il file di inizializzazione della connessione vpnd.chat.
In aggiunta anche un file contente la "key" di codifica dei dati, che può essere vpnd.key nel caso si abbia scelto il formato base (con il comando ./vpnd -m), vpnd.lcl.key o vpnd.rmt.key
nel caso del formato esteso (cioè una key sul server e una key sul client remoto con il comando ./vpnd -x dir/key/).
In entrambi i casi la key di codifica deve essere copiata nella macchina client attraverso, ovviamente una modalità sicura (es: scp) prima di poter stabilire il tunnel.
Effettuare la stessa procedura di installazione per la macchina Linux all'altro capo della VPN.
GESTIONE
Si può lanciare il demone con il comando vpnd oppure aggiungendo le seguenti opzioni:
vpnd -f /dir/vpnd.conf utilizza un file di configurazione con path diverso dallo standard(/etc/vpnd.conf)
vpnd -n forza vpnd a non diventare un demone

Telnet e Principali comandi in Linux
Telnet é una applicazione che consente ad un utente di collegarsi dall´esterno a un computer server e di lavorare dal proprio PC  (client) come si trovasse di fronte al server. Per effettuare una connessione remota di questo tipo é necessario un apposito programma (client telnet) in grado di comunicare con il server. Tra questi programmi, spesso scaricabili liberamente dalla rete, troviamo Putty, che é il client consigliato per questa esercitazione.
Scarica Putty: Windows95/98/Me (185Kb) |
Altre versioni

Una volta scaricato il programma é possibile effettuare la connessione:

ESERCIZIO:
Spostati nella cartella appena creata e crea una nuova cartella di nome Prova.
Proviamo adesso a copiare il file “sequenza.txt” che si trova nella cartella Test nella cartella  in cui ci troviamo adesso.
Per copiare il file devi usare il comando cp seguito dal file di origine e dalla cartella in cui vuoi copiare il file. Per indicare il file di origine devi anche specificare dove si trova, per fare questo puoi usare una localizzazione “assoluta” rispetto alla direcotry “home” o una localizzazione “relativa” rispetta alla cartella in cui ti trovi.
Localizzazione relativa:
~/Tuo_nome cp ../../Test/sequenza.txt Prova
Come abbiamo visto in precedenza i due punti consecutivi indicano la cartella precedente, quindi ripetendo due volte il segno “..” indichiamo al comando di tornare indietro di due cartelle. A questo punto il programma, che é tornato indietro di due cartelle si trova nella directory “home” dove trova la cartella Test e, al suo interno, il file “sequenza.txt”. “Prova” é il nome della cartella in cui deve essere copiato il file.
Localizzazione assoluta:
~/Tuo_nome cp ~/Test/sequenza.txt Prova
La localizzazione assoluta del file di origine viene ottenuta specificando la sua posizione rispetto la directory “home” che viene indicata dalla “tilde” (~). Per ottenere questo carattere digita 126 mentre tieni premuto il tasto “Alt”.
Se la cartella Prova non esistesse, il comado cp copierebbe ugualmente il file “sequenza.txt” ma le cambierebbe il nome in “Prova”. Per varificarlo provate a scrivere “prova” invece di “Prova” e guardate cosa succede.
La tabella che segue riporta i principali comandi linux: dopo averla letta prova a svolgere i seguenti esercizi

cd

Serve per muoversi tra le cartelle
·
cd nome_cartella    per spostarsi nella cartella "nome_cartella"
· cd ..      per tornare nella cartella a monte
· cd ~      per tornare nella direcory "home" (il carattere ~ si chiama "tilde" e si ottiene digitando 126 mentre si tiene premuto il tasto ALT)

ls

Mostra il contenuto della cartella corrente
· ls -l       mostra una serie di informazioni sul file

mkdir

Crea una nuova cartella
·
mkdir nuova_cartella      crea la cartella "nuova_cartella"

cp

Copia un file o una cartella
· cp file_origine cartella_destinazione  Copia il file_origine nella cartella di destinazione
Se il file di origine non si trova nella cartella da cui si lancia il comando é necessario specificare la sua localizzazione
rm Cancella un file
·
rm nome_file
rmdir Cancella una cartella
· rmdir nome_cartella
Per cancellare una cartella piena e tutto il suo contenuto puoi usare:
·
rm -R nome cartella
mv Sposta un file o cambia il nome
· mv file destinazione   Sposta il file nella cartella "destinazione"
· mv file_nome_vecchio file_nome_nuovo     Cambia nome al file

CONSIGLI:
- Ricordati che linux é “case sensitive”
- Non mettere mai spazi o caratteri “strani” nel nome dei files o delle cartelle
- Cerca di assegnare a files e cartelle dei nomi che indichino il loro contenuto
- Linux NON perdona: se non fai molta atenzione a quello che digiti puoi cancellare in un solo istante TUTTI i tuoi dati
- Scrivendo man seguito dal nome di un comando viene mostrata una descrizione del comando e dei parametri che é possibile specificare