Impostazioni di base per la configurazione del sistema operativo e della rete nel laboratorio 208 facente parte della rete piffa.net .
-Qui riportati per comodita' degli studenti (e del docente che non sara' **mai piu'** costretto a ripeterli continuamente! ). Gli altri lettori potranno tenerli presenti per cercare di comprendere gli esempi nel testo. Ad esempio: quando leggerete ``10.10.208.254:3128`` saprete che si tratta del nostro *proxy http*, stara' quindi a voi sostituire i dati con gli *ip* della vostra rete.
+Qui riportati per comodita' degli studenti (e del docente che non sara' **mai piu'** costretto a ripeterli continuamente! ). Gli altri lettori potranno tenerli presenti per cercare di comprendere gli esempi nel testo. Ad esempio: quando leggerete ``10.10.208.254:3128`` saprete che si tratta del nostro *proxy http*, stara' quindi a voi sostituire i dati con gli equivalenti *ip* della vostra rete.
Rete
------
netmask 255.255.255.0
broadcast 10.10.208.255
gateway 10.10.208.254
-gateway 10.10.208.250
- persistente
DNS 10.10.208.254
-DNS 10.10.208.250
- persistente
proxy http 10.10.208.254:3128
============= ================
-Sul portatile di Andrea, corrispondente all'ip 254, gira un DHCP, proxy http e mirror di Debian ( http://debian.piffa.net). Se Andrea non e' in aula (o ancora peggio non c'e' il suo portatile Net) gli studenti dovranno darsi un indirizzo ip manualmente e disabilitare il proxy (che pero' e trasparente, quindi fate pure come se non ci fosse ;) . Questo in attesa che si sappia se sara' nuovamente utilizzabile il vecchio server Bender.
+Sul portatile di Andrea, corrispondente all'ip 254, gira un DHCP, proxy http e mirror di Debian ( http://debian.piffa.net). Se Andrea non e' in aula (o ancora peggio non c'e' il suo portatile Net) gli studenti dovranno darsi un indirizzo ip manualmente e disabilitare il proxy (che pero' e trasparente, quindi fate pure come se non ci fosse ;) . Ad oggi il *lab208* e' servito dal server Bender (254 o 248) che ha ripreso le sue vecchie funzioni.
interfaces
~~~~~~~~~~~~~~~
# La prima scheda di rete (se si chiama eth0)
# (network, broadcast and gateway sono optional)
iface etho inet static
- # esempio con dhcp
+ # esempio con dhcp:
# iface etho inet dhcp
address 10.10.208.101
netmask 255.255.255.0
Se si usano *schede di rete virtuali* ( eth0:1 , eth0:1 , ...) ricordarsi che queste dipendono dalla scheda fisica a cui sono associate: abbattere con ``ifconfig down eth0`` la scheda principale fara' cadere anche queste. Tornando ad attivare la schda principale con ``ifconfig eth0 up`` la virtuale tornera' attiva: nel caso voleste disabilitarla dovrete quindi sempre abbattere manualmente la scheda virtuale *prima* della scheda reale.
+I DNS vanno indicati nel file ``/etc/resolv.conf`` , la cui sintassi e' spiegata al punto 4.6 .
+
Bash completion
-------------------
Vim e' l'editor di testo preferito dai sistemisti, quindi sara' conveniente impostare fin da subito alcune impostazioni per renderlo piu' comodo.
-Assicurarsi che sia installata nel sistema la versione completa dell'editor ``vim`` nstallando il pacchetto vimi::
+Assicurarsi che sia installata nel sistema la versione completa dell'editor ``vim`` installando il pacchetto ``vim``::
# apt-get install vim
source /etc/vim/vimrc.local
endif
+
+I principianti faranno bene ad esercitarsi con ``vimtutor it``.
+
VNC
------------
-I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visuallizare la sessione di lavoro di un altro computer sul proprio a scopo didattico. Installando un server VNC sulla propria macchina ed impostando una opportuna password si consente ai client VNC di ricevere una immagine dello schermo ed eventualmente di inviare input di tastiera e mouse al computer server (durante le lezioni questo non e' possibile per gli studenti, solo Andrea esegue i comandi). In pratica si può gestire il computer server da un'altra postazione, come se fosse il proprio computer fisico.
+I Virtual Network Computing (o VNC) sono software di controllo remoto e servono per amministrare il proprio computer a distanza o visuallizare la sessione di lavoro di un altro computer sul proprio a scopo didattico.
-Scaricare il pacchetto ``xtightvncviewer`` e lo script ``guarda.sh`` in una posizione (collocazione nel *path* degli utenti, es ``echo $PATH`` per visualizzare l'attuale path ) comoda per gli utenti ( in genere ``/bin`` ), rndere eseguibile lo script.
+Scaricare il pacchetto ``xtightvncviewer`` e lo script ``guarda.sh`` in una posizione (collocazione nel *path* degli utenti, es ``echo $PATH`` per visualizzare l'attuale path ) comoda per gli utenti ( in genere ``/bin`` ), rendere eseguibile lo script.
Procedura::
kde-core kdm kde-i18n-it xorg vim less xtightvncviewer
-.. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``, esiste anche un equivalente ``gnome-core gnome`` e il log-in manager ``gdm`` per il l'ambiente grafico Gnome.
+.. [#] ``kde-core`` e' piu' leggero del pacchetto ``kde``. Esiste un equivalente ``gnome-core gnome`` per chi preferisce gnome, nel caso si potrebbe installare il log-in manager ``gdm`` al posto di ``kdm``.
Apt configurazione
---------------------
# Archivio principale debian via http su piffa.net,
# non funziona al difuori dell'aula dei corsi
- deb http://debian.piffa.net/debian/ Lenny main
- # deb http://debian.piffa.net/debian/ Lenny non-free contrib
+ deb http://debian.piffa.net/debian/ lenny main
+ # Sono diponibili anche i rami non-free contrib
+ # deb http://debian.piffa.net/debian/ lenny non-free contrib
# Mirror da kernel.org da usare a casa:
- deb http://mirrors.eu.kernel.org/debian/ Lenny main
+ deb http://mirrors.eu.kernel.org/debian/ lenny main
# Security dal sito principale
- deb http://security.debian.org/ Lenny/updates main
- deb-src http://security.debian.org/ Lenny/updates main
+ deb http://security.debian.org/ lenny/updates main
+ deb-src http://security.debian.org/ lenny/updates main
# Debian volatile per le cose soggette a cambiamenti non legati
# a dinamiche di sicurezza
Squid
======
-Squid e' un proxy cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente piccole grazie alla semplicita' di configurazione che in scenari piu' complessi grazie alla possibilita' di gestirne in modo granulare le risorse partendo dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, la gestione degli accessi, il filtraggio dei contenuti (Squid e' una applicazione che si muove nel 4' livello del modello TCP/IP a differenza di un *ipfilter* limitato al 2') nel l bilanciamento del carico tra piu' hosts.
+Squid e' un proxy cache http (ma anche FTP e https) robusto e strutturato, puo' essere usato sia in reti relativamente piccole grazie alla semplicita' di configurazione che in scenari piu' complessi grazie alla possibilita' di gestirne in modo granulare le risorse. Si partira' dalle configurazioni piu' semplici per la semplice *condivisione della navigazione* internet, per poi poter ocnfigurare la gestione degli accessi, il filtraggio dei contenuti (Squid e' una applicazione che si muove nel 4' livello del modello TCP/IP a differenza di un *ipfilter* limitato al 2') nel l bilanciamento del carico tra piu' hosts.
-Inoltre svolge la funzione di *anonymizer*:
+Inoltre Squid svolge la funzione di *anonymizer*:
nasconde i client http alla rete internet: risulta solo il server proxy nei log dei server web frequentati dagli utenti di Squid.
Cosa a volte sottovalutata, squid permette la navigazione web a una rete basata su *indirizzi ip privati* (es una 192.168.0.0/24). E se la rete privata deve *solo navigare* in internet, non serve un *NAT* od altro, basta il solo Squid. Per altro non servira' neanche un servizio DNS dato che *sara' il solo squid a risolvere i nomi di dominio* per i suoi client http.
Utilizzare un servizio come ad es: https://www.dyndns.com/ per mappare nomi di dominio sul proprio indirizzo ip, comodo ad esempio se si dispone di un indirzzo ip pubblico (anche se dinamico) per la propria connessione ad internet.
*Dnsmasq* (DNS server)
- Utilizzabile a livello locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
+ Utilizzabile al livello della rete locale per fare dei test, utilizzando direttive come: ``address=/davide.piffa.net/10.10.208.178``
``/etc/hosts``
- Per prove *strettamente a livello locale* potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
+ Per prove sul propio sistema potete impostare i nomi dei vostri virtual server nel file /etc/hosts .
-::
+Query DNS con ``dig``::
# dig 177.piffa.net
;; ANSWER SECTION:
177.piffa.net. 0 IN A 10.10.208.177
- ;; Query time: 12 msec
- ;; SERVER: 10.10.208.254#53(10.10.208.254)
- ;; WHEN: Wed May 6 12:27:08 2009
- ;; MSG SIZE rcvd: 47
-La parte interessante e' ``177.piffa.net. 0 IN A 10.10.208.177`` . Il nome di dominio 177.piffa.net viene risolto sull'ip 10.10.208.177 , nel nostro Apache (che risponde all'ip 10.10.208.177 ) dovra' essere disponibile un virtual host che corrisponde al nome ``177.piffa.net`` .
+La parte interessante e' l'*ANSWER SECTION*: ``177.piffa.net. 0 IN A 10.10.208.177`` . Il nome di dominio 177.piffa.net viene risolto sull'ip 10.10.208.177 , nel nostro Apache (che risponde all'ip 10.10.208.177 ) dovra' essere disponibile un virtual host che corrisponde al nome ``177.piffa.net`` (``ServerName``) .
Virtual host
~~~~~~~~~~~~~~
Negoziazione accessi
---------------------
-Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo essere utile o necessario limitare gli accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
+Tipicamente quando si installa un server web il proprio desiderio e' di dare accesso ai materiali disponibili al maggior numero di visitatori possibile. Talvolta pero' puo essere utile poter limitare questi accessi, ad esempio per escludere un *bot* indesiderato che scansiona ininterottamente le nostre pagine o per creare una *Area Riservata* i cui materiali non devono essere disponibile a tutti.
-Limiti su base ip
+Limiti su base IP
~~~~~~~~~~~~~~~~~~~~~~
La forma piu' semplice di restrizine degli accessi e' su base degli indirizzi IP dei client: tipicamente i siti web sono settati per dare accesso a chiunque::
<VirtualHost *:80 >
# ...
<Directory "/var/www/177.piffa.net">
- Order allow,deny
- Allow from all
+ Order allow,deny
+ Allow from all
</Directory>
</VirtualHost>
Potremmo negare l'accesso a uno o piu' indirizzi IP in questo modo::
<VirtualHost *:80 >
+ # ...
<Directory "/var/www/177.piffa.net">
- Order allow,deny
- Allow from all
- Deny from 192.168.0.1
+ Order allow,deny
+ Allow from all
+ Deny from 192.168.0.1
</Directory>
</VirtualHost>
</Directory>
In questo modo solo la classe IP ``192.168.0.0/24`` potra' accedere alla directory ``/limitata``
-Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il propio indirizzo ip, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma e' comunque possibile mandare delle richieste ``GET`` per cercare di mandare in Denial Of Service il webserver.
+Si tenga pero' conto che e' relativamente facile per un malintenzionato cambiare il propio indirizzo ip, oppure collegarsi da un altra zona. Meno facile e' accedere ad una classe privata trovandosi all'esterno di questa, ma ci sono comunque soluzioni piu' eleganti.
User Authentication
---------------------
-A volte conviene negoziare gli accessi ad un area di un sito tramite autenticazione basata sull'accopiata *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client. Per quanto esistano soluzioni piu' granulari e sofisticate per ottenere questo, *mod-auth* puo'essere sufficente. E mod auth non richiede l'installazione di software aggiuntivi.
+Si puo' negoziare gli accessi ad un area del sito tramite autenticazione basata su *nome utente / password*. Questo puo' venire utile per creare una area download *intranet*, alla quale possano accedere solo gli utenti previsti a prescindere dagli indirizzi IP dei loro client.
+
+Tramite il modulo di Apache *mod-auth* e' possibile implementare questo paradigma, per quanto esistano soluzioni piu' granulari e sofisticate, che richiedono pero' l'implementazione di interpreti di linuguaggi di programmazione, criptazione delle passwords, gestione degli utenti ed eventualmente delle sessioni.
+Mod auth non richiede l'installazione di niente di tutto questo.
link: http://www.apacheweek.com/features/userauth
Definire la cartella
~~~~~~~~~~~~~~~~~~~~~~
-Decidere quale sara' il *path* della cartella da sottoporre ad autentizazione:(e creiamo la cartella):
+Decidere quale sara' il *path* della cartella da sottoporre ad autentizazione:
``mkdir /var/www/177.piffa.net/privata``
Configurazione di Apache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare il file di impostazione del virtual-host.
+Ora possiamo passare alla configurazione vera e propria di Apache, ma con una novita': andremo a inserire la voce in un ``.htaccess`` invece che modificare (tramite una direttiva ``<Directory>`` ) il file di impostazione del virtual-host.
Questo per motivi pratici: solo l'utente *root* puo' modificare l'impostazione del virtual host nel file ``/etc/apache2/sites-enabled/177.piffa.net``, ma spesso il motivo per cui creiamo i virtual hosts e' ospitare i siti di altri utenti, che possono solo pubblicare (generalmente tramite *FTP*) i loro documenti nella loro *DocumentRoot*, senza poter quindi modificare in alcun modo la configurazione del virtual host.
-Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamenteo del loro spazio web ci togliera' l'incombenza di dover intervenire suii vari virtual host.
+Dando agli utenti la possibilita' di modificare (*AllowOverride*) autonomamente alcuni parametri (in questo caso solo l'*AuthConfig*) relativi al funzionamenteo del loro spazio web ci togliera' l'incombenza di dover intervenire continuamente sui vari virtual host.
Abilitiamo l'AllowOverride nel file di configurazione del virtual host per la sola directory ``privata``::
/var/www/177.piffa.net/privata/.htaccess ::
- # Questo file viene incluso
- # nella configurazione del sito web
# Messaggio visualizzato al prompt per l'autenticazione
AuthName "Area privata soggetta ad autentizazione"
# tipo di autenticazione da usarsi
AuthType Basic
- # File generato precedentemente con htpasswd
+ # File precedentemente generato con htpasswd
AuthUserFile /home/utente/passwords
# Negoziazione degli accessi
Si noti che non e' necessario fare ripartire Apache per onorare i cambiamenti (un utente non avrebbe la possibilita' di farlo!).
+Oltre a ``valid-users`` si potrebbe scegliere di usare la formula ``users`` che permette di elencare esplicitamente gli utenti::
+ require user pippo pluto
+
+L'utente *paperino* che fosse comunque presente nel file generatoda htpasswd non potrebbe accedere alla risorsa.
+
+Nel caso ci foosero molti utenti conviene gestirli tramite *gruppi*::
+ require group staff studenti
+
+I gruppi vengono definiti in un file in modo simile a ``/etc/groups`` per gli utenti di sistema::
+
+ staff:andrea sara
+ studenti: lucap federico luca
+
+da richiamare tramite la direttiva ``AuthGroupFile``.
Cavets
-----------
Oppure potrebbe essere il nostro *PPP client* (per la connessione ADSL) a intervenire sul file ``//etc/resolv.conf``, si modifichi quindi ``/etc/ppp/peers/dsl-provider`` commentando ``usepeerdns``. Se la vostra connessione ad internet e' ADSL raramente dovreste aver bisogno di cambiare i DNS una volta impostati (a meno che non usiate un portatile!).
-DHCPd
----------
+Bind : DNS Autoritativo
+===========================
+
+Le soluzioni viste possono bastare per la rete locale o per fare delle prove, ma prima o poi verra' il momento in cui si e' chiamati a gestire dei domini su internet: lo standard e' da sempre *Bind* ( demone *named*), ora alla versione 9.
+
+Installare i pacchetti::
+
+ bind9
+
+DNS cache
+-------------
+
+Bind appena installato funzionera' come DNS cache: si faccia un test con un ``dig @localhost`` . Bind a diffrenza di Dnsmasq e' autonomo: non ha bisogno di forwardare (inoltrare) le query a un DNS esterno: queste verranno risolte direttamente da Bind partendo dai *DNS root servers*.
+
+E' comunque possibile impostare dei DNS forwarders, tipicamente i DNS server forniti dal propio provider, per velocizzare le query:
+
+/etc/bind/named.conf.options (riga 13)::
+
+ forwarders {
+ 10.10.208.254;
+ };
+
+Nel caso si voglia usare Bind solo come server DNS cache per la propia LAN senza ospitare delle zone DNS pubbliche sara' il caso di limitare gli accessi al server alla sola LAN:
+
+/etc/bind/named.conf.options (riga 19)::
+
+ // Se il propio server ha ip 10.10.208.254
+ // sulla rete LAN privata:
+ listen-on { 10.10.208.254; }
+
+E non si lasci il server in ascolto su uno degli eventuali indirizzi IP pubblici.
+
+Se questo non fosse possibile si puo' sempre lavorare su una *acl*:
+
+/etc/bind/named.conf ::
+
+ acl "localnet" {
+ 212.22.136.0/24 ; 127.0.0.0/8 ;
+ } ;
+
+Per poi aggiungere all'interno della stanza options la direttiva che abilita' l'entita' ``localnet``:
+
+/etc/bind/named.conf.options ::
+
+ allow-query {"localnet" ;} ;
+
-Dnsmasq puo' lavorare anche come DHCP server per la vostra LAN.
Samba
======
projects / doc / .git / commitdiff