Oh antivirus! Croce e delizia di ogni sistema Windows!
Se vi ritrovate nella spiacevole condizione di amministrare qualche server Windows è possibile che da un giorno con l’altro vi capiti a tiro qualche burocrate che “pretende” (non si sa bene in base a quale astrusa norma o principio) sia installato un antivirus, che questo sia aggiornato quotidianamente e che sia schedulata una scansione del sistema.

In questa situazione una persona normale e ragionevole proporrebbe di fare una veloce analisi per capire l’utilità e il rapporto costi/benefici di questa soluzione, ad esempio:

• sui filesystem del server vengono scritti file?
• che origine hanno i file che eventualmente vengono scritti sui filesystem?
• i servizi che girano sul server come reagiscono a fronte di una scansione?
• quali sono le esclusioni che è necessario definire sull’antivirus per fare in modo che le scansioni non interferiscano con i servizi esistenti?

Tutte domande sensate, ma che dalla mia esperienza nella maggioranza dei casi cadono nel vuoto, per molti utenti l’antivirus è un must, ci deve essere punto e basta, è un tabù intoccabile…

In questi casi Clamwin è una discreta soluzione, è leggero, è poco invasivo, di default non prevede rilevazione realtime (possibile tramite Clam Sentinel) che può compromettere le performance del sistema e infine è free e opensource (cosa utile se questi sono requisiti imposti dal cliente di turno).
Per contro Clamwin non è accurato come altri antivirus più blasonati e rispetto a questi rileva un numero eccessivo di falsi positivi, ma soprattutto ha uno schedulatore un po’ dozzinale che funziona solo se c’è un utente loggato sul sistema.

A tal proposito l’approccio degli sviluppatori è sensato, clamwin funziona splendidamente da CLI, perchè inventarsi uno schedulatore quando il sistema operativo stesso ne ha uno che funziona egregiamente? Della serie KISS (Keep It Simple Stupid…)

Per schedulare aggiornamento e scansione comprensiva di notifiche email bastano questi strumenti:

• notepad
• un file .bat
• blat

Create un semplice file di testo con estensione .bat o .cmd (es clamsched.bat) con questa sintassi:

@echo off
rem ###### Personalizzate queste variabili
SET TARGET=c:\ d:\
SET LOG=c:\temp\clam-results.txt
SET BLATEXE=C:\utils\blat\full\blat.exe
SET BLATLOG=C:\utils\blat\blat.log
SET SMTPSERVER=smtp.domain.local
SET [email protected]
SET [email protected]
SET ESCLUSIONIDIR=--exclude-dir="C:\\directory-da-escludere" --exclude-dir="C:\\Program Files\\directory-da-escludere2"
SET ESCLUSIONIFILE=--exclude="c:\\directory-esempio\\user\\Administrator\\.bash_history" --exclude="d:\pagefile.sys"
date /T
time /T

rem ###### Aggiornamento db antivirus
echo Aggiorno db antivirus
"c:\Program Files\clamwin\bin\freshclam.exe"
echo.

rem ###### Inizio scansione
echo Scansione avviata
echo.
"c:\Program Files\clamwin\bin\clamscan.exe" -d "C:\Documents and Settings\All Users\.clamwin\db" %ESCLUSIONIFILE% %ESCLUSIONIDIR% -i -r %TARGET% >%LOG% 2>&1
echo.
goto answer%errorlevel%

:answer0
rem # Commentate per non ricevere mail in caso di scansione negativa
 echo Nessun virus rilevato
 %BLATEXE% %LOG% -to %RCPTMAIL% -server %SMTPSERVER% -f %SENDERMAIL% -subject "Scansione antivirus OK" -q -log %BLATLOG%
 echo Scansione completa
 goto end

:answer1
 echo Possibile virus rilevato
 %BLATEXE% %LOG% -to %RCPTMAIL% -server %SMTPSERVER% -f %SENDERMAIL% -subject "PROBLEMA SCANSIONE ANTIVIRUS" -q -log %BLATLOG%
 echo Controlla il file %LOG%
 goto end

:answer2
 echo Errore nell'esecuzione dello script
 %BLATEXE% %LOG% -to %RCPTMAIL% -server %SMTPSERVER% -f %SENDERMAIL% -subject "PROBLEMA ESECUZIONE SCRIPT ANTIVIRUS" -q -log %BLATLOG%
 goto end
:end
echo.
date /T
time /T
echo ===========================
echo.
exit

Per schedulare aggiornamento e scansione vi basta aprire il task scheduler di Windows e creare un nuovo job che esegue il seguente comando:

C:\utils\clamsched.bat >> C:\utils\clamsched.log 2>&1

Lavorando su server datati o che sono passati attraverso innumerevoli contratti o gruppi di lavoro può capitare tutto e il contrario di tutto.

Una casistica non proprio rara su sistemi linux a 64bit è la presenza di installazioni multiple degli stessi package sia in versione x86 che x64 (prima di mettere mano ad una macchina ricordate sempre di lanciare “uname -a” per verificare la versione del kernel e l’architettura).

Questo genera confusione e a volte può bloccare l’installazione o l’upgrade di alcuni package, a ciò si somma l’output non sempre chiaro del comando rpm che non aiuta certo a risolvere questo genere di conflitti.

Prendiamo il caso seguente, un server RedHat Enterprise 4 x64 sul quale è necessario effettuare l’upgrade del client mysql.
L’upgrade con “rpm -Uvh <nuovo package>” genera un sacco di errori causati da conflitti con la versione esistente di mysql, il bravo sistemista verifica quali rpm sono installati:

[root@columbia ~]# rpm -qa | grep mysql-
mysql-4.1.7-4.RHEL4.1
mysql-4.1.7-4.RHEL4.1

Due versioni dello stesso package?!? Che diavolo stai dicendo Willis?!?! (cit)
Proviamo a disinstallare l’rpm (ovviamente solo dopo aver verificato che questo non risulti bloccante per altro):

[root@columbia ~]# rpm -e mysql-4.1.7-4.RHEL4.1
error: "mysql-4.1.7-4.RHEL4.1" specifies multiple packages

DAMN!! :\
Proviamo allora a verificare l’architettura dei singoli package installati utilizzando l’opzione –queryformat

[root@columbia ~]# rpm -q --queryformat "%{name}.%{arch}\n" mysql
mysql.i386
mysql.x86_64

Ecco svelato l’arcano! Qualche premio Nobel ha pensato bene di installare il client mysql a 32bit oltre a quello a 64bit!
Nel 99% dei casi questo sarà successo per disattenzione, incompetenza o il solito cliente/capo progetto che vuole tutto “per ieri”, una volta verificato che il client sbagliato non sia stato installato per qualche ragione specifica si può procedere alla sua disinstallazione (con le opportune dipendenze da verificare)…

[root@columbia ~]# rpm -e mysql.i386
error: Failed dependencies:
 libmysqlclient.so.14 is needed by (installed) cyrus-sasl-sql-2.1.19-5.EL4.i386

[root@columbia ~]# rpm -e mysql.i386 cyrus-sasl-sql-2.1.19-5.EL4.i386

[root@columbia ~]# rpm -qa | grep mysql-
mysql-4.1.7-4.RHEL4.1

… e procedere con l’upgrade o il resto del lavoro ;)

Al giorno d’oggi le analisi di log per webserver sembrano una cosa preistorica, con l’avvento dei sistemi di analisi degli accessi (es Piwik) servizi gloriosi come Webalizer o Awstats sono ormai considerati antiquati e non più adatti alle esigenze “dell’uomo che non deve chiedere mai” :\

In realtà l’analisi di log è una pratica che ha ancora una grande utilità, soprattutto per il monitoraggio dei servizi e di alcune risorse (es traffico generato dalle richieste http).

Come dicevo poco sopra i due indiscussi protagonisti in questo ambito software sono Awstats e Webalizer, il primo fornisce un report più dettagliato e utile in ottica di analisi degli accessi, il secondo risulta infinitamente più veloce e versatile, non richiede setup particolari ne ha requisiti di alcun tipo, basta lanciare il binario passando le opportune opzioni e il gioco è fatto.
Per questi motivi Webalizer è ancora oggi il mio software di riferimento per le analisi estemporanee “prima di subito”, tra colleghi però vedo che spesso viene scartato per il semplice fatto che non permette analizzare più file con un solo comando.

Per ovviare a questa limitazione basta lanciare un banale ciclo for per analizzare tutti i file di log richiesti con un unico comando, ovviamente utilizzando l’opzione -p per effettuare una analisi incrementale (altrimenti l’analisi di un mese verrebbe sovrascritta al passaggio tra un log e il successivo).

Ecco un semplice script bat per fare tutto questo:

@echo off
set webalizerbase=c:\utils\webalizer

rem personalizzare le tre variabili che seguono
set logdir=%webalizerbase%\log\domain
set analisidir=%webalizerbase%\analisi\domain
set hostname=www.domain.tld

del /F %webalizerbase%\logs.txt
dir %logdir%\* /O /B /S > %webalizerbase%\logs.txt

for /F %%v in (%webalizerbase%\logs.txt) do %webalizerbase%\webalizer.exe -o %analisidir% -n %hostname% -Q -p %%v

Una cosa banalissima che di default tutte le distribuzioni redhat (e derivate) fanno è ripulire lo schermo una volta fatto il boot e il logoff di un utente dalla console di sistema.

Può sembrare una cosa banale e inutile, quando però ci si ritrova a lavorare in un ced sconclusionato dove l’unica utenza per accedere al KVM over ip centralizzato è condivisa con millemilioni di altri utenti, e magari si ha a che fare con servizi “birbanti” che richiedono di passare le credenziali amministrative come argomento di un comando (qualcuno ha parlato di WebSphere Portal?), beh allora in quel caso capite bene che anche una feature apparentemente banale acquista magicamente un’importanza vitale.

Di default su Debian questa feature non c’è, per abilitarla basta passare il codice di escape di clear al file /etc/issue, per farlo:

[root@booger etc]#cp /etc/issue /tmp/

[root@booger etc]#clear > /etc/issue

[root@booger etc]#cat /tmp/issue >> /etc/issue

[root@booger etc]#rm /tmp/issue

Piece of cake!

Mi capita abbastanza frequentemente di discutere di software open source e uno dei dubbi che spesso sorgono è come contribuire ad un progetto.

Il modello di sviluppo open è una realtà che oggettivamente ha cambiato l’information technology, questo è un dato di fatto incontrovertibile, ed è un fenomeno sorprendente sia dal punto di vista tecnico che sociale.
Basta provare a lavorare in gruppo per un qualche ora per rendersi conto di quanto sia difficile coordinarsi e fare davvero “team”, già perchè è facile scrivere sul CV cazzate false tipo “ottima predisposizione al lavoro di gruppo”, un altro paio di maniche è metterlo in pratica, figuriamoci quando il gruppo è distribuito su un intero pianeta e composto dal più ampio e variegato campionario umano.

La domanda che però molti si pongono è come contribuire concretamente ad un progetto che ci sta particolarmente a cuore, oppure che semplicemente ci è risultato utile.
Dal punto di vista tecnico lo sviluppo di un progetto è una attività complessa che richiede competenze specifiche che solo una percentuale ridottissima degli utenti possiede; poi ci sono altri compiti altrettanto utili e meno impegnativi dal punto di vista tecnico (test, traduzione di documentazione, moderazione di forum e mailing list, creazione di how-to e guide di vario tipo) ma anche questi non sempre sono alla portata di tutti, quantomeno non della maggior parte degli utenti.

Ci sono però due altre cose che un progetto open-source necessità e su cui tutti possono impegnarsi:

1. pubblicità
2. risorse (banda e storage)

Riguardo alla prima c’è poco da dire, non perchè sia poco importante (anzi!) ma perchè è abbastanza autoesplicativa, riguardo al punto due invece qualche considerazione possiamo farla.

Anni fa i progetti open source venivano distribuiti mediante mirror, ovvero server che venivano aggiornati con i rilasci del progetto e che mettevano a disposizione spazio e connettività per permettere alla comunità di scaricare i file e poter beneficiare dei software.
Chiaramente nell’era delle connessioni analogiche (ricordate il vecchio modem 56k?) tutto questo era ad esclusivo appannaggio di pochi, principalmente aziende che in cambio di queste risorse venivano citate tra i “contributors” del progetto.

Se ci pensiamo al giorno d’oggi praticamente tutti (digital divide permettendo) godono di una connessione adsl flat con tagli di banda generosi, connessioni che generalmente sono inutilizzate per la stragrande maggioranza del tempo.
Come se non bastasse oggi esistono sistemi (il celebre Raspberry PI ne è un esempio) dal costo ridicolo (a partire da poche decine di euro) e dall’assorbimento ridottissimo (2-3W per il già citato Raspberry PI, meno di una TV in standby) che sono perfette per questo scopo, a questo aggiungiamo che gran parte dei progetti utilizza come sistema di distribuzione sistemi di file sharing come bittorrent.

Quindi quale miglior modo per contribuire ad un progetto open source offrendo un po’ di banda della propria connessione domestica, magari organizzandosi con dei semplici script per attivare il client bittorrent nelle ore in cui non utilizziamo la linea, siamo fuori casa, al lavoro, oppure semplicemente stiamo dormendo.

Ad esempio con una qualsiasi distribuzione linux e l’ottimo client bittorrent Transmission basta mettere in download una qualsiasi versione di un progetto e lasciare il tutto in seed una volta terminato il download, inserendo dei banalissimi cronjob per arrestare il servizio (schedulato ad esempio quando pensate di tornare a casa dopo una giornata di lavoro, nell’esempio alle ore 19):

00 19 * * * /etc/init.d/transmission-daemon stop > /dev/null 2>&1

e per farlo ripartire (quando generalmente ve ne andate a letto la notte, nell’esempio alle 2):

00 02 * * * /etc/init.d/transmission-daemon start > /dev/null 2>&1

Si tratta di una cosa semplice, alla portata di tutti, che ha un impatto economico ridicolo, ma di grande utilità, pensateci