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

Oggi ho scoperto che al mondo ci sono due tipi di imbecilli:

• quelli che per spedirti un dongle wifi da pochi grammi usano una scatola 33x12x12 cm
• quelli che scoprono di aver comprato il dongle wifi sbagliato e se ne accorgono solo dopo che è arrivato…

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 ;)