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.

Da circa due settimane AVG ha annunciato il rilascio del suo LinkScanner per Mac con l’espresso obiettivo di “garantire sicurezza agli utenti Mac contro l’aumentato numero di sempre più sofisticati attacchi web”. Molto probabilmente i fanatici Mac non l’hanno presa molto bene … tant’è che la stessa AVG si è sentita in dovere di rilasciare le seguenti dichiarazioni :

“E’ noto che la maggior parte degli utenti Mac credono di essere in qualche modo immuni da tutti i possibili rischi derivanti dal malware che si propaga tramite web. Questa convinzione è talmente forte per costoro da portarli a non installare qualsiasi software antivirus sui loro computer. Tuttavia i tempi stanno cambiando e il 2009 si è rilevato essere un anno piuttosto complicato per i rischi di sicurezza che coinvolgono le piattaforme Apple, compresi Mac OSX e l’iPhone. Durante l’ultimo anno i Mac sono stati oggetto dell’attacco del trojan iServices A, che ha comportato, per oltre 20.000 utenti, al download di un file infetto da un sito di software pirata.”

AVG continua dichiarando che il successivo trojan iServices B ha già colpito altre 5000 macchine ed ha sottolineato come altri virus (tra cui Tored-A e Jahlav-C) sono già causa di preoccupazione nella comunità Apple.

“Sono state scoperte delle vulnerabilità nel browser Safari, in iTunes e nel programma per la lettura dei PDF. Tra l’altro è da notare il fatto che lo scorso mese sono stati evidenziati dei report relativi a vulnerabilità non ancora corrette nel browser Safari 4.0. Sembra dunque che i Mac non siano più sicuri come un tempo.”

Ovviamente gli utenti Mac sono ancora molto lontani dall’incidenza pesantissima di malware esistente per la piattaforma Windows. Tuttavia è bene, a mio avviso, non sottovalutare troppo il problema. Sono stato sempre convinto del fatto che non esiste un sistema operativo intrinsecamente inattaccabile e che la distribuzione di virus e malware per un determinato OS è diretta conseguenza della sua popolarità. In fondo è anche logico: dal momento che scrivere codice malevolo non è (spesso) un’operazione banale ed in considerazione del fatto che il virus-writer punta a massimizzare l’effetto della propria opera, ovviamente si cercherà di colpire, preferenzialmente, la piattaforma di maggiore diffusione. E se le alternative a Windows iniziano ad aumentare le loro quote di diffusione è lecito attendersi anche una evoluzione del malware per computer.

E se qualcuno ancora vi dice che i Mac sono immuni dai virus … ecco qua un bel video istruttivo:

Alla prossima.

Non amo particolarmente la Suite Office di Microsoft, anzi, per meglio dire, la detesto proprio. Purtroppo per i clienti è considerato uno standard (blahhh) e farne a meno è quasi impossibile se si vuole lavorare. Tant’è …

Su una installazione di Windows 7 con Office 2007 mi sono ritrovato con dei file di Excel, contenenti delle macro in un progetto VBA, che si aprono con una lentezza estrema e, con altrettanta lentezza, si chiudono. Dopo varie prove con diverse impostazioni di sicurezzza in Excel, l’unico modo per ottenere una apertura rapida era quello di disabilitare l’esecuzione delle Macro (nonostante avessi rimosso tutta la parte attiva del progetto).

La domanda nasce spontanea: ma se non ci sono macro da eseguire o progetti VBA da pre-compilare … perchè diamine la disabilitazione dell’esecuzione macro ha un effetto sulla velocità di apertura ? Abilitata o meno, non essendoci macro, la velocità dovrebbe essere la stessa.

Dopo lungo peregrinare nelle pagine web alla ricerca di possibili soluzioni al problema ho trovato un post che dichiarava come il problema fosse stato risolto semplicemente disinstallando la toolbar di Google per Internet Explorer. Ma che ‘zzo c’entra ??? (si lo so … ve lo state chiedendo).
Dopo un secondo però ho smesso di farmi domande … Microsoft inserisce pezzi di IE ovunque (motivo per cui è praticamente impossibile disinstallarlo). Quindi mi rimaneva una sola opzione … dal momento che NON ho installato la Google Toolbar … quali altri BHO (Browser Helper Object) ho installato che possono dare fastidio ?.

Sul mio computer uno solo : AVG LinkScanner e AVG On-Line Shield.

Morale della favola … eseguita la rimozone dei componenti incriminati  di AVG e … voilà … Excel 2007 e le macro tornano a funzionare con tempi decenti.
La cosa divertente ? E’ che per farmi del male ho provato a reinstallare AVG cn tutti i moduli di protezione attivi (inclusi LinkScanner e On-Line shield) ed Excel ha continuato a funzionare correttamente.