Oggi si sente un gran parlare di servizi di streaming audio per portarsi appresso tutta la propria musica ovunque ci si trovi, servizi tipo Spotify o altre vaccate simili promettono mari e monti, salvo poi ritrovarsi inondati da una tale quantità di brani da non saper più quale scegliere…

Se anzichè dipendere da questi servizi preferite “degooglelizzarvi” e portarvi davvero ovunque la VOSTRA musica, sul VOSTRO hardware, con i VOSTRI servizi, allora vi consiglio di dare un’occhiata a questo fantastico servizio che risponde al nome di Subsonic.

Subsonic è ufficialmente un server di streaming audio completamente free che vi permette di ascoltare i vostri mp3 usando una comoda interfaccia web oppure delle applicazioni dedicate (anche per dispositivi mobile).
Tecnicamente parlando si tratta di una applicazione java disponibile sia come comodo package .war da deployare su un servlet container a piacimento (es Apache Tomcat), oppure come setup omnicomprensivo (applicazione + jetty) per Windows, GNU/Linux RedHat (rpm), Debian/Ubuntu (deb) oppure MacOS (pkg).

Tutto quello che dovete fare è lanciare il setup, attendere il completamento dell’operazione e poi collegarvi sulla porta standard 4040 (ovviamente personalizzabile a piacimento), loggarvi come amministratore e configurare i pochi semplici parametri necessari al funzionamento (es la directory che contiene i propri mp3).
Per esporre il servizio online potete scegliere se nattare il servizio oppure esporlo mediante un reverse proxy (io ho scelto quest’ultima strada), per fare in modo che il servizio utilizzi il protocollo https dovete seguire le semplici istruzioni che trovate in coda a questa pagina.

Riguardo alle applicazioni mobile (ma non solo) avete solo l’imbarazzo della scelta, a questo link trovate tutte le possibili alternative free o a pagamento; per utilizzarle vi basta installare la vostra prescelta sul dispositivo, puntare alla url del vostro server Subsonic e inserire le credenziali per autenticarvi.

Infine per raggiungere il vostro server Subsonic dalla fida ADSL di casa vi basterà registrarvi su uno dei tanti servizi di dns dinamico, crearvi un hostname pubblico e fare in modo che questo venga costantemente aggiornato con il vostro ip dinamico mediante le apposite utility fornite dal provider del servizio.

Beccatevi il mio gioiellino appena installato… e già, sono un fan sfegatato dei Dire Straits ;)

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!