Se, come me, vi trovate ad aver installato diversi server CentOS nella stessa rete, sicuramente vi sarete posti il problema di come cercare di evitare i ripetuti download dal web degli aggiornamenti per ogni singola macchina. Non sarebbe meglio scaricarli una volta e distribuirli tramite rete locale ?
La risposta è semplice : basta creare un repository locale di Yum su uno dei server. I requisiti sono davvero minimi e, molto probabilmente, sono già soddisfatti nella vostra installazione standard : un web server (Apache) e l’utilità rsync.

Comunque, nel caso voleste essere certi di avere a disposizione questi strumenti, accedete alla console del server che avete deciso conterrà il repository ed installate quanto necessario. Per far questo aprite una finestra terminal, passate a privilegio di root e digitate:

yum install httpd rsync

Yum scaricherà ed installerà le versioni più aggiornate del server Apache e dell’utilità rsync. Se questi componenti già installati verranno semplicemente aggiornati alla versione più recente.

A questo punto possiamo avviare Apache ed assicurarci che venga avviato automaticamente all’avvio del server. Quindi, sempre da riga di comando:

/etc/init.d/httpd start
chkconfig httpd on

Ecco fatto. I prerequisiti sono soddisfatti.

Ora … bisogna sapere che per impostazione predefinita di CentOS, la directory principale dei documenti di Apache è /var/www/html. Al di sotto di essa andremo a creare le directory che conterrano il repository di Yum. Per l’esempio corrente creiamo il repository relativo alla versione 5 di CentOS con architettura i386 (quindi non 64bit). Ovviamente potete creare repository anche per architetture diverse.

Stando sempre nella console da riga di comando creiamo dunque le due directory che ci servono maggiormente: la os e la updates. Ovviamente i repository ufficiali supportano anche altri contenitori come addons ed extra, ma, nel mio caso, ho preferito focalizzarmi sui contenitori di maggiore importanza. A voi la scelta di scaricarne altre:

mkdir -pv /var/www/html/centos/5/{os,updates}/i386

Ecco fatto. Le directory sono state create.

Ora … assumendo che il vostro server si chiami mioserver.miodominio.com provate, da un’altra postazione, ad accedere con un browser all’indirizzo http://mioserver.miodominio.com/centos/5/os/i386 … dovreste ricevere un messaggio di Apache.  Fatto questo tornate alla console del server che state configurando.

Ok … a questo punto bisogna trovare la corretta sorgente da cui attingere per copiare i file del repository … ovvero un mirror tra i tanti di CentOS che supporti rsync. Per l’italia l’unico al momento è il mirror del GARR/CILEA. Siamo pronti per avviare il comando che creerà una copia esatta del repository sorgente sul nostro server. Vi consiglio a questo proposito di creare uno script in modo che i comandi possano essere schedulati. Create quindi in /etc/cron.daily un file che si chiama yum-update-repo e copiateci dentro il seguente testo:

#!/bin/sh
rsync -avrt --bwlimit=100 rsync://mi.mirror.garr.it/CentOS/5/os/i386  /var/www/html/centos/5/os/
rsync -avrt --bwlimit=100 rsync://mi.mirror.garr.it/CentOS/5/updates/i386  /var/www/html/centos/5/updates/

Salvate il file e rendetelo eseguibile:

chmod 755 /etc/cron.daily/yum-update-repo

Qualche commento sui comandi appena descritti. Il tool rsync creerà una copia degli archivi presenti nell’origine ed in tutte le sottodirectory. Lo switch –bwlimit serve a limitare l’utilizzo della banda (che io ho impostato a 100KBPS) al fine di evitare che la copia avvenga intasandovi la linea di connessione ad internet. Al primo ciclo ovviamente verranno scaricati tutti i file, ma dal secondo in avanti verranno scaricati solo i file variati e verranno elminiati (dalla copia locale) tutti i file non più presenti sulla sorgente.

A questo punto, visto che abbiamo preparato il nostro repository locale, dobbiamo informare tutti i nostri server CentOS della rete (incluso quello su cui state lavorando) del fatto che gli aggiornamenti non devono più essere scaricati dalla rete ma da un server locale.

Con l’editor di testo che preferite aprite il file /etc/yum.repos.d/CentOS-Base.repo. Per la sezione [base] e [updates] (quelle che ho attivato per questo esempio) dovrete togliere il commento dalla riga baseurl e completarla con l’indirizzo http del server che avete appena creato:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
baseurl=http://mioserver.miodominio.com/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
baseurl=http://mioserver.miodominio.com/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5


Salvate il file.

Siete pronti per lanciare l’esecuzione di un aggiornamento.

Come è noto Scalix offre un connettore per Outlook che funziona quale strato di emulazione MAPI: in parole povere Outlook funziona connesso a Scalix come se dietro ci fosse Exchange. Tra le caratteristiche salienti di questo connettore vi è la possibilità di implementare un sistema di SSO (Single Sign On) ovvero quella tecnica per la quale, all’apertura di Outlook, l’utente non dovrà inserire alcuna password nè vi sarà necessità di memorizzarne una nel profilo. In questo modo le policy di scadenza delle password di Windows potranno essere tranquillamente mantenute e l’autenticazione a Scalix avverrà tramite scambio di gettoni (token) Kerberos.

La parte propedeutica alla attivazione del sistema SSO prevede la configurazione di agreement di sincronizzazione con Active Directory (ovviamente dovete avere un Dominio AD configurato) tramite il quale Scalix “carica” e mantiene aggiornati gli utenti secondo quanto specificato in AD. Questa parte non è argomento di questo post.

Quello di cui mi voglio occupare invece è la parte in cui la documentazione Scalix richiede la creazione di un account speciale “scalix-ual” che serve per lo scambio dei messaggi Kerberos tra il server Scalix ed il server Windows. La procedura prevede la creazione, appunto, di un normale account utente chiamato scalix-ual (potrebbe anche essere un altro nome ma bisognerebbe spippolare poi nella configurazione di Scalix per cambiare il principal name), assegnargli una password, generare un file keytab tramite i Support Tools di Windows, ed importare il keytab generato nel database del server Scalix. (Scalix Setup and Administration Guide 11.3 pagina 54 e successive).

La procedura è corretta … tranne in un caso : ovvero quando avete configurato Samba sul vostro server Scalix e avete fatto il join al dominio di Windows.

In questo secondo scenario, infatti, la procedura con cui Samba si aggancia al dominio prevede la creazione di un account per il computer nel container Computer di AD e contestualmente genera anche un database keytab per Kerberos. Se, essendo in questa situazione, seguite la procedura indicata da Scalix per l’implementazione del Kerberos SSO vi troverete con :

• Diversi errori nel log degli eventi del server Windows (sezione Sistema) con ID Evento 11 e origine KDC. Il messaggio (in inglese) recita così : There are multiple accounts with name scalix-ual/HOST.FQDN of type DS_SERVICE_PRINCIPAL_NAME.
• L’autenticazione dei client Outlook fallisce sistematicamente

Questo comportamento è dovuto al fatto che già l’account del computer inserito in dominio ricopre la funzione di Principal per lo scambio di messaggi Kerberos e accoglie in maniera jolly tutte le richieste di servizio Kerberos. Creare un secondo account utente per questo scopo causa l’errore KDC 11.

Se avete inserito il server Scalix in un dominio AD tramite Samba tutto quello che dovete fare è editare, in active directory, l’account del computer, accedere al tab Delega ed abilitare l’opzione “Considera attendibile per tutti i servizi (Solo Kerberos)”.

Non c’è null’altro da fare.

Sappiamo tutti quanto stia diventando intrusiva la pubblicità che troviamo inserita a forza nelle pagine dei siti internet durante la normale navigazione. Ma se il singolo utente la considera più una seccatura (alla stregua della pubblicità che interrompe il programma televisivo preferito), per gli amministratori di rete diventa anche un problema tecnico: le pagine richieste dagli utenti della rete, con le loro continue inclusioni di banner, script ed immagini di varia natura, succhiano banda riducendo, per tutti, le risorse disponibili. Senza contare che, in genere, gli utenti, sapendo di essere protetti da un gateway aziendale, cliccano qua e là senza curarsi troppo della sicurezza e della miriade di informazioni di profilazione che vengono raccolte. Insomma, attivare una linea di difesa contro l’intrusione della pubblicità, aumenta non solo la sicurezza ma anche la velocità complessiva di navigazione.

Intendiamoci : non mi ritengo un integralista che ha deciso di abbattere il modello di revenue più diffuso sul web e, parimenti, sono convinto del fatto che per molte iniziative sia forse l’unico modello di sostentamento possibile. Ma certamente alcuni siti esagerano davvero esprimendo contenuti originali che, in rapporto alla pubblicità, stanno a 10Kb contro 200Kb o più. Animazioni, spesso ridondanti, pop-up automatici, immagini a tutto schermo ecc.

Esistono diversi motivi per approcciare la soluzione del problema: da quelli squisitamente personali (un esempio ne è l’eccellente AdBlock Plus per Mozilla Firefox) fino a sistemi di protezione a livello di gateway aziendale.

In questo articolo vedremo come configurare SQUID in modo che possa validamente aiutarci in questo scopo. Alla data di scrittura di questo documento ci occuperemo di come configurare Squid 2.6 su una distribuzione CentOS 5.4 (ovviamente do per scontato che già tutti i client della vostra rete possano navigare solo per il tramite del proxy).

Probabilmente già molti di voi sono a conoscenza del fatto che tra le moltissime direttive offerte dal file di configurazione di Squid è possibile impostare delle ACL (Access Control List) che, con opportuni filtri basati su espressioni regolari, ci consentono di creare dei divieti (deny) allo scaricamento di contenuti provenienti da specifici indirizzi (URL). Il rovescio della medaglia di questa tecnica è che, una volta individuate le origini dei contenuti da bloccare, chi naviga può vedersi comporre delle pagine con diversi riquadri che riportano informazioni di errore. Ed ecco che entra in gioco una eccellente caratteristica di Squid: la caratteristica di redirection delle richeste.

La redirection (o rewrite se preferite) utilizza uno script che dice a Squid di tenere d’occhio degli specifici indirizzi (URL) nelle richieste che riceve (per esempio ad.doubleclick.com). Quando un browser della rete inoltra una richiesta con questo URL a Squid, lo script reindirizza la richiesta ad un file locale, come ad esempio una immagine gif che contiene solo un pixel trasparente. E siccome questa richiesta in realtà non esce mai dalla rete locale, l’intera navigazione risulterà estremamente veloce oltre all’indubbio beneficio dato dal fatto che là dove ci si aspetta di trovare un bel banner animato, non vedremo (o meglio, gli utenti non vedranno) assolutamente nulla.

Ma come fare tutto questo ? E’ molto semplice … avete bisogno di tre cose :

1. Squid … ovviamente installato e funzionante
2. Un web server interno alla rete aziendale (che sia IIS o Apache non importa)
3. Squid.redir … un piccolo script ideato e mantenuto da Craig Sanders che potete scaricare direttamente da questo link

Ecco come procedere all’installazione :

1. Accedete alla shell console del vostro server Linux (CentOS per me)
2. Create una directory di lavoro sotto la vostra home : mkdir ~/squid.redir [Enter]
3. Accedete alla directory appena creata e scaricate il pacchetto che contiene lo script:
   wget http://taz.net.au/block/squid-redir.tar.gz [Enter]

4. Estrate i file contenuti nell’archivio :
   tar -xzvf squid.redir.tar.gz [Enter]

5. Verranno estratti i seguenti file : closeme.html, do_nothing.js, dot.gif, gen.squid.redir, Makefile, README, redir
6. Cancellate il file gen.squid.redir appena estratto e sostituitelo con quello che trovate qui : gen.squid.redir
   rm -f gen.squid.redir [Enter]
wget http://www.anlan.com/upload/gen.squid.redir [Enter]

7. Copiate i seguenti file nella directory /usr/lib/squid: con privilegi di superuser eseguite i seguenti comandi:
   cp Makefile /usr/lib/squid
cp gen.squid.redir /usr/lib/squid
cp redir /usr/lib/squid

8. Copiate i seguenti file nella web root di un vostro webserver interno alla rete.
   closeme.htm (verrà sostituito ai pop-up)
   do_nothing.js (per sostituire gli script come ad esempio quelli dei contatori dei siti)
   dot.gif (un’immagine trasparente di un solo pixel)
   
9. Ora accedete alla cartella/libreria di squid : cd /usr/lib/squid [Enter]
10. Con un editor di testo (io uso nano) aprite il file gen.squid.redir (quello scaricato al punto 6 e copiato al punto 7). Individuate la seguente riga:
    $BASE_URL=”//YOUR-WEB-SERVER-HERE”;
    e sostituite YOUR-WEB-SERVER-HERE con l’indirizzo IP oppure il nome di host del web server in cui avete copiato i file al punto 8. Se per esempio il vostro webserver risponde all’indirizzo IP 192.168.1.4 allora dovrete modificare la riga in questo modo:
    $BASE_URL=”//192.168.1.4″;
    Dopo aver effettuato la modifica salvate il file e chiudete l’editor.
11. Ancora con l’editor aprite ora il file redir. Noterete che vi sono già diverse righe compilate. La sintassi del file è molto semplice. Ogni riga è divisa in due da uno o più caratteri di tabulazione. Nella parte di sinistra trovate la regular expression che deve essere ricercata all’interno dell’URL richiesto e nella parte destra, se si verifica una corrispondenza, la variabile che contiene l’indirizzo da ritornare a squid. Le variabili possibili sono 4 :
    • $1 -> ritorna lo stesso indirizzo senza modifiche
    • BLANK -> ritorna l’URL in cui, presso il TUO webserver, si trova l’immagine dot.gif
    • CLOSEME -> ritorna l’URL in cui, presso il TUO webserver, si trova il file closeme.html
    • NULLJS -> ritorna l’URL in cui, presso il TUO webserver, si trova il file do_nothing.js

    In pratica funziona così: squid riceve una richiesta da un browser della rete, passa la richiesta al programma di reindirizzamento che stiamo preparando, e quest’ultimo lo confronta con le espressioni regolari inserite. Se trova una corrispondenza ritornerà a squid l’URL “corretto” in modo che non venga inviata una richiesta ad internet ma solo una richiesta al web server per recuperare il file “fantasma”.

12. Chiudete pure ora il file redir
13. Aprite ora il file di configurazione di squid (per CentOS o RedHat si trova in /etc/squid/squid.conf): cercate il tag url_rewrite_program. Dopo esservi letti bene la spiegazione di questo tag attivatelo inserendo una riga non commentata:
    url_rewrite_program /usr/lib/squid/squid.redir
    salvate il file e chiudete.
14. Tornate ora alla directory /usr/lib/squid. Digitate make e premete invio. La procedura genera il file squid.redir, lo contrassegna come eseguibile ed esegue automaticamente un reload di squid.

Okay … ora provate a navigare utilizzando il vostro squid come proxy. Probabilmente non vi accorgerete di nessuna variazione nelle pagine web visitate. E’ molto probabile: infatti le regular expressions fornite come standard in questo redirector sono piuttosto obsolete e riferite in massima parte a procedure di advertising di server americani. Vi servirà un po’ di analisi del file access.log di squid per capire cosa dovete reindirizzare.

Un aiuto ? Bene … supponiamo di NON voler mai far scaricare ai browser dei nostri utenti di rete dei javascript che abbiamo individuato provenire sempre da http://www.qualcuno.com/scripts/pippo.js . Come fare ? Semplice :

1. Accedete alla console di comando del server squid
2. Entrate nella directory /usr/lib/squid
3. Con un editor di testo aprite il file di redir
4. In fondo al file aggiungete una nuova riga come questa :
   //www.qualcuno\.com/scripts/.*\.js [TAB] NULLJS
   ovviamente [TAB] significa il tasto TAB
5. Salvate il file e chiudete l’editor
6. Eseguite : make [Enter]
7. Squid viene ricaricato ed il reindirizzatore applicherà le sostitituzioni.

Tempo addietro avevo scritto due brevi note su come installare correttamente Virtual Box Additions per openSUSE 11.1. Oggi mi sono trovato ad installare una nuova openSUSE 11.2 utilizzando il nuovo Virtual Box di Sun/Oracle.

Piacevole è stata la sorpresa di scoprire che, a differenza di quanto accadeva nelle versioni precedenti (di entrambi i software) questa volta … non serve fare assolutamente nulla.

Installando openSUSE 11.2 su Virtual Box 3.1.4 r57640, la distro Linux si “accorge” di essere all’interno del virtualizzatore e installa automaticamente i driver che normalmente si dovrebbe aggiungere ad installazione ultimata. E quindi già durante l’installazione potrete avere il capture/release automatico del puntatore del mouse, ed al primo boot operativo potrete subito ridimensionare lo schermo a piacimento, disporre dell’emulazione audio ecc.

Va da sè che non dovrete più quindi installare i pacchetti aggiuntivi di openSUSE specifici per il make delle Virtual Box Guest Additions.

Ganzo !

Graziosamente, mamma Microsoft, di tanto in tanto si diletta a “togliere” da sotto i piedi di collaudati impianti di rete, importanti caratteristiche. Proprio recentemente alcuni client “ospiti” di una rete, il cui accesso ad Internet è gestito e protetto da Squid + DansGuardian ( installati su un server Linux con autenticazione degli utenti tramite NTLM ), dotati del nuovissimo Windows 7, fallivano sistematicamente l’autenticazione e venivano bloccati nella navigazione (che invece con le stesse credenziali era garantita ai guest XP e Vista).

La soluzione per ovviare al problema è attivare in Windows 7 il livello di compatibilità NTLM V1 e V2.

1. Sulla macchina Windows 7 avviare Regedit (con privilegi di amministratore)
2. Navigare alla chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Controllare che esista la chiave LmCompatibilityLevel. Se non esiste create la chiave di tipo DWORD.
4. Modificate il valore della chiave LmCompatibilityLevel al valore 1
5. Chiudete regedit
6. Riavviate il pc con Windows 7

Per riferimenti su cosa significhi questa chiave potete trovare informazioni sulla Technet Microsoft.

Grazie Rob per la segnalazione.