Come la pubblicità di Maxbon ci ha insegnato, sappiamo che “two is meglio che one” quindi perché avere una sola scheda ethernet all’interno del nostro server se con due possiamo avere un ottima ridondanza di rete e/o un ottimo bilanciamento del carico? Vediamo di mettere sù un ethernet bonding, un sistema che la ho lo scopo di unire due flussi ethernet al fine di formare un unico canale.

Prima di procedere all’installazione del software necessario, vediamo le modalità operative del channel bonding:

• mode=0 (balance-rr): avviene il round-robin tra le due interfacce. I pacchetti vengono trasmessi attraverso la scheda di rete scarica e se una delle due va ko viene usata solo la scheda di rete funzionanete. Questa  modalità fornisce sia il load balance e sia il fault tolerance e non prevede switch di rete con particolari funzionalità.
• mode=1 (active-backup): una sola schede di rete viene usata se questa si rompe il MAC address viene associato all’altra funzionante (di backup) e quindi il flusso di rete viene garantito. Questa modalità fornisce un sistema di fault tolerance e non è necessario uno switch che abbia funzionalità avanzate.
• mode=2 (balance-xor): il traffico di rete viene inoltrato sulla scheda in base a questa regola di XOR: ((source MAC) XOR (dest MAC)).  Questa modalità garantisce load balance e  fault tolerance e non necessità di particolati switch.
• mode=3 (broadcast): vengono usate entrambe le interfacce per trasmettere e ricevere. Il fault tolerance è garantito senza switch preposti.
• mode=4 (802.3ad): è una modalità si supporto allo standard IEEE 802.3ad Dynamic link aggregation, per questa modalità è necessario uno switch che supporti lo standard 802.3ad.
• mode=5 (balance-tlb): Adaptive Transmit Load Balancing. Il traffico in entrata è ricevuto solo sullo slave attivo, il traffico in uscita viene distribuito a seconda del carico su ogni slave. Non necessità di particolai switch.
• mode=5 (balance-alb): Adaptive Load Balancing. Fornisce bilanciamento del carico sia in ricezione che in trasmissione. Non necessità di switch particolari ma richiede la capacità di cambiare l’indirizzo MAC del dispisitivo di rete senza che questo interrompa il traffico. (continua…)

Stufi del Client FTP tradizionale ed in cerca di “qualcosa” che monti lo spazio FTP del nostro provider nella nostra Linux box?

La soluzione si chiama:  CurlFtpFS.

Installiamolo:

apt-get install curlftpfs

E’ importante caricare il modulo di fuse:

modprobe fuse

Montiamo la partizione remota FTP:

curlftpfs -o allow_other ftp://<user>:<pass>@<host_ftp> <directory_di_mount>

Per per montare la partizione all’avvio impostiamo fstab aggiungendo questa riga:

curlftpfs#<user>:<pass>@<host_ftp> <directory_di_mount> fuse rw,uid=500,user,noauto 0 0

Fine!:)

Ecco le caratteristiche principali di CurlFtpFS:

• support for SSLv3 and TLSv1
• connecting through tunneling HTTP proxies
• automatic reconnection if the server times out
• conversion of absolute symlinks to point back into the FTP filesystem

OpenVPN is a free and open source virtual private network (VPN) program for creating point-to-point or server-to-multiclient encrypted tunnels between host computers. It is capable of establishing direct links between computers across network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL).

Bene, procediamo.

Supponiamo di avere due host e di creare una VPN tra loro, installiamo su entrambi openvpn:

apt-get install openvpn

Adesso usiamo la Debian Way e quindi utilizziamo gli script per la creazione dei certificati e delle chiavi.

(continua…)

La gestione remota del server viene (ed è giusto così!) fatta tramite SSH perché garantisce sicurezza ed affidabilità che altri sistemi sognano.

Per fortificare ancor più questo sistema si può usare SSH con l’autenticazione a chiave pubblica. Esistono decine di siti che descrivono bene questo sistema e spiagano come creare la coppia di chiavi quindi io do per assodato la creazione delle chiavi.

Per prima cosa va copiata la nostra chiave pubblica nel server remoto:

scp -p id_rsa.pub <utente_remoto>@<hot_remoto>:

Il file nel mio caso si chiama id_rsa.pub perché ho generato una chiave RSA ma anche una di altro tipo va più che bene!

Adesso creiamo le directory opportune nella home del nostro utente sul server remoto:

mkdir ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
mv id_rsa.pub ~/.ssh

Adesso sul server remoto va configurato il demone SSH attraverso il file /etc/ssh/sshd_config.

Settiamo queste direttive:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

e riavviamo SSH:

/etc/init.d/ssh restart

Da adesso al nostro server ci si accede senza password…ma con la chiave!:)

Avevo la necessità di permettere l’accesso ad un determinato virtual host di Apache solo ad utenti italiani, ho risolto con mod_geoip.

Ecco come installarlo:

apt-get install libapache2-mod-geoip

Per la configurazione del modulo è necessario editare il file

/etc/apache2/mods-available/geoip.conf

e decommentare la riga:

GeoIPDBFile /usr/share/GeoIP/GeoIP.dat

Salviamo questo file ed editiamo il file di configurazione del virtual-host aggiungendo questa specifica:

SetEnvIf GEOIP_COUNTRY_CODE <codice_del_paese> AllowCountry

E le policy di accesso:

Order Deny,Allow
Deny from all
Allow from env=AllowCountry

Scarichiamo l’ultima versione del database contenente gli IP tramite wget:

wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz

Salviamo il file nella directory:

/usr/share/GeoIP/

Eliminiamo il file vecchio:

rm GeoIP.dat

Mettiamo il nuovo:

gunzip GeoIP.dat.gz

Riavviamo Apache:

/etc/init.d/apache2 restart

e solo la nazione a voi simpatica accederà al sito!:)

Il modulo GeoIP è usabile anche all’interno di PHP:

<?php
$country_name = apache_note("GEOIP_COUNTRY_NAME");
$country_code = apache_note("GEOIP_COUNTRY_CODE");
print "Nazione: " . $country_name . " - Codice nazione: ".$country_code;
?>

Per maggiori informazioni ralative a mod_geoip potete consultare questa pagina.

Nell’articolo precedente abbiamo visto come è semplice aggiornare la Debian Etch a Lenny.

Durante l’aggiornamento, quando cambiamo i repository sostituendo Etch con Lenny e lanciamo il comando

apt-get update

si può incappare in questo messaggio di warning:

W: There is no public key available for the following key IDs:

<numero_chiave_ssl>

W: È consigliabile eseguire apt-get update per correggere questi problemi

(continua…)

Il 14 Febbraio la comunità Debian ha rilasciato l’ultima versione stabile della sua nota distribuzione GNU/Linux, chiamata “Lenny“.
Per chi come me, ha installazioni di Debian Etch e vuole passare subito a Lenny la procedura è la seguente. 

Da linea di comando lanciamo i soliti:

apt-get update
apt-get upgrade

Adesso abbiamo una Etch aggiornata e quindi pronta per fare il passaggio a Lenny.

Bisogna editare il file /etc/apt/sources.list e sostituire Etch con Lenny. Prima il mio file era così:

deb http://ftp.it.debian.org/debian/ etch main
deb-src http://ftp.it.debian.org/debian/ etch main
deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib

Poi è diventato così:

deb http://ftp.it.debian.org/debian/ lenny main
deb-src http://ftp.it.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main contrib
deb-src http://security.debian.org/ lenny/updates main contrib

Salviamo e aggiorniamo la distribuzione con:

apt-get update
apt-get dist-upgrade

E’ importante seguire le istruzioni che compariranno per un corretto funzionamento del sistema.