iFixIt dot com

Un sito decisamente interessante per il DIY (Do it Yourself) per i possessori dell’hardware marcato Mela è il seguente:

http://www.ifixit.com

Un sito da tenere in considerazione ogni qualvolta si vuole cambiare/sostituire un pezzo del vostro Mac, qui vengono descritti i vari passi da seguire per la sostituzione di batterie, memorie, harddisk, schede madri, … per quasi tutta la gamma dei prodotti della casa di Cupertino. I vari passaggi sono ben descritti con fotografie ed indicazione degli strumenti necessarri per portare a termine l’operazione chirurgica. Purtroppo è in inglese, ma spesso le immagini parlano da sole… Buona cura del vostro Mac.

subversion con websvn e svnmanager

Vogliamo implementare un sistema di controllo versione con un interfaccia web (amministrazione e visualizzazione) sulla vostra distribuzione preferita? Vediamo come installare subversion, websvn su debian lenny.

Subversion (noto anche come svn, che è il nome del suo client a riga di comando) è un sistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere il naturale successore di CVS, oramai considerato superato.

Come prerequisiti dobbiamo avere un server con installati apache2, php, mysql e pear funzionanti, se non avete questo potete facilemente reperire delle ottime guide (ad esempio su howtoforge.com). Procediamo con l’installazione di quanto necessitiamo (subversion, supporto ad apache2 come modulo a sv con webdav, libreria di PEAr per svnmanager), durante il processo rispondere “no” alla richiesta di configurazione di websvn:

apt-get install subversion libapache2-svn websvn
pear install -d preferred_state=alpha VersionControl_SVN

Procediamo con la creazione della struttura (directory e file di configurazione che non vengono generati automaticamente dall’applicazione) per contenente le nostre future repository (repos) e file di configurazione e diamo i privilegi compliti ad apache:

mkdir /var/lib/svn
cd /var/lib/svn
mkdir repos
mkdir sysconfig
touch passwdfile
touch accessfile
chown -R www-data:www-data /var/lib/svn

Ora bisogna modificare il file di configurazione del modulo webdav per svn di apache, che si trova al seguente indirizzo:

/etc/apache2/mods-available/dav_svn.conf

Dal file dobbiamo attivare le seguenti funzioni (decommentare le righe):

<Location /svn>
  DAV svn
  SVNParentPath /var/lib/svn/repos
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/lib/svn/passwdfile
  AuthzSVNAccessFile /var/lib/svn/accessfile
  Require valid-user
</Location>

In questo modo abbiamo abilittao il servizio, definito un percorso all’interno dei quali si troveranno i nostri repos ed un sistema di autenticazione a livello di accesso http e svn. Procedere quindi con il download di svnmanager (la versione al momento della scrittura di questo post è la 1.0.8). Scarichiamo (o carichiamo) sul server l’ultima versione in /var/www e procediamo con l’installazione:

unzip svnmanager-1.08.zip
ln -s svnmanager-1.08 svnmanager
cd svnmanager
cp config.php.linux config.php

Abbiamo definito un nome più semplice da ricordarsi (svnmanager) ed attivata la configurazione per piattaforma linux. Editiamo quindi il file di configurazione (config.php) ed andiamo a modificare quanto segue:

$svn_config_dir  = "/var/lib/svn/svnconfig";
$svn_repos_loc   = "/var/lib/svn/repos";
$svn_passwd_file = "/var/lib/svn/passwdfile";
$svn_access_file = "/var/lib/svn/accessfile";
$smtp_server     = "localhost";
$dsn             = "mysqli://svnmanager:PASSWORD@localhost/svnmanager"; // change PASSWORD with your password :-)

Come vedete abbiamo ripreso la struttura precedentemente creata e definito il nostro DSN (connettore al db attraverso un dbal). Procediamo quindi alla creazione in MySQL dell’account e del database come specificato nel DSN configurato precedentemente. Riavviamo quindi il servizio apache.

/etc/init.d/apache2 restart

Se vi collegate all’indirizzo del vostro server indicando la direcotory svnmanager la prima volta viene generata la struttura del DB ed in seguito avrete accesso all’interfaccia amministrativo di subversion.

http://your-ip/svnmanager

SVNManager - login

Accedete all’interfaccia amministrativa con l’accaunt definito nel file di configurazione e create un nuovo utente (date i privilegi amministrativi). Create quindi un progetto ed utilizzando il vostro tools prferito e caricate dei files. Accedete poi via browser e vedrete quanto caricato (previo autenticazione).

Mentre con un indirizzo di questo tipo:

http://your-ip/svn/repo-name

vi collegate (previo autenticazione) via webdav al vostro progetto.

Ora però vogliamo visualizzare tutto questo in una forma più consona al web, quindi avendo accesso alle informazioni in una maniera strutturata, potento utilizzare quei strumenti che ci permettono di capire l’evoluzione del nostro progetto (diff, formattazione, …). Procediamo quindi con la configurazione di websvn.

dpkg-reconfigure websvn

e procediamo con le scelte di default (chiaramente vogliamo configurare il servizio), afcendo però attenzione ad inserire i valori mostrati di seguito per quanto riguarda i repos di svn.

svn parent repositories: /var/lib/svn/repos
svn repositories: [nothing]

A questo punto potremmo già accedere alle nostre repository al seguente indirizzo:

http://your-ip/websvn/

websvn - home

ma vedete che non abbiamo nessun tipo di protezione/autenticazione. Possiamo implementare il medesimo meccanismo di autenticazione utilizzato per webdav, ma al momento senza un controllo diretto sui files, ma unicamente sull’accesso. Modifichiamo il seguente file:

/etc/websvn/apache.conf

e aggiungiamo all’interno della direttiva Directory

AuthType Basic
AuthName "Subversion Repository"
Require valid-user
AuthUserFile /var/lib/svn/passwdfile

Cosi facendo facciamo riferimento alla medesima lista di username/password (senza riferimenti ai repository). Per evitare questo andiamo a modificare il seguente parametro (in questo modo indichiamo al sistema di far riferimento anche agli accessi di subversion):

$config->useAuthenticationFile('/var/lib/svn/accessfile'); // Global access file

in

/etc/websvn/config.php

Se vogliamo rendere il tutto più sicuro dobbiamo implementare un’accesso tramite un protocollo sicuro, quindi l’unica soluzione che fa al nostro caso è quella di utilizzare https (quindi ssl). Procediamo quindi alla configurazione dei nostri certificati ed alla loro installazione/abilitazione nelle diverse configurazioni.

mkdir/etc/apache2/ssl
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

viene generato un certificato di tipo selfsigned (quindi siete voi l’authority). Attenzione che alla domanda del commonName dovete inserire esattamente il nome del vostro dominio, ad esempio svn.mioserver.com. Il certificato avrà come validità 10 anni. Editiamo di nuovo i files /etc/apache2/mods-available/dav_svn.conf e /etc/websvn/apache.conf ed aggiungiamo ad entrambi la direttiva

SSLRequireSSL

in modo da richiedere la presenza del protocollo SSL, quindi l’accesso avverrà tramite https, al momento dell’autenticazione. A questo punto configurate il vostro dominio (usando il commonName definito nella creazione del vostro certificato SSL) per configuare il vostro dominio namebased, di seguito un esempio per la condivisione della /var/ww:

<VirtualHost your-ip:443>
  ServerName commonNAme
  ServerAdmin email@domain
  DocumentRoot "/var/www/"
  <Directory /var/www/>
    Options -Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
  </Directory>
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/apache.pem
  ErrorLog "/var/logs/ssl.error.log"
  CustomLog "/var/logs/ssl.access.log" combined
</VirtualHost>

Non vi basta che riavviare apache e questo punto avrete messo in sicurezza l’accesso a svn (ed ai tools per gestirlo). E questo è tutto, se avete domande, migliorie o commenti fatemi sapere.

Munin per monitorare le risorse

Munin è un progetto decisamente interessante per la sua semplicità d’uso, d’installazione e configurazione e per la sua versatilità. Di cosa si tratta? Di un sistema per monitorare le risorse utilizzate dalla (o dalle) vostre macchine quali:

  • CPU
  • Disco
  • Rete
  • Servizi vari (MySQL, Dovecot, Apache, …)

Ha un architettura di tipo client/server dove abbiamo un Master il quale raccoglie e mostra attraverso grafici generati con RRDTool i dati provenienti da uno o più nodi (che chiaramente posso essere distribuiti su macchine diverse).

muninVediamo ora una semplice configurazione di Munin prendendo come requisiti per il nostro sistema i seguenti punti:

  • Piattaforma Debian 5.0 (Lenny) ma dovrebbe funzionare anche su versioni precedenti
  • Master e nodo sono la stessa macchina

Procediamo con l’installazzione dei pacchetti necessari a far funzionare il servizio, per installare munin utilizzate il seguente comando:

apt-get install munin

Se volete avere un elenco più preciso di quello che sta per fare mettete l’opzione -s al comando e vedrete quali pacchetti verranno installati (e quali potrebbe essere interessante aggiungere, suggested). L’installazione provvederà anche ad attivare il servizio.

A questo punto il Master ed il Nodo sono sulla stessa macchina ma non viene ancora monitorizzato nessun servizio, periferica o quantaltro. Procediamo quindi con la configurazione dei servizi che riteniamo opportuno monitorare. La seguente istruzione

munin-node-configure --suggest

stampa un elenco di plugin attivabili sul nostro server in base alla configurazione, disponibilità, …

apache_volume              | no   | [LWP::UserAgent not found]
courier_mta_mailqueue      | no   | [spooldir not found]
courier_mta_mailstats      | no   | [could not find executable]
courier_mta_mailvolume     | no   | [could not find executable]
cpu                        | no   | yes
cupsys_pages               | no   | [could not find logdir]
df                         | no   | yes
df_inode                   | no   | yes

Dove i campi rappresentano il nome, se è attiva ed eventuali note (attivabile, errori, …). Una volta configurato il sistema per essere compatibile con le nostre esigenze di monitoraggio possiamo eseguire il seguente comando:

munin-node-configure --suggest --shell

attraverso il quale abbiamo l’elenco delle istruzione da eseguire (tramite copia/incolla) per attivare le plugin.

ln -s /usr/share/munin/plugins/cpu /etc/munin/plugins/cpu
ln -s /usr/share/munin/plugins/df /etc/munin/plugins/df
ln -s /usr/share/munin/plugins/df_inode /etc/munin/plugins/df_inode
ln -s /usr/share/munin/plugins/entropy /etc/munin/plugins/entropy
ln -s /usr/share/munin/plugins/forks /etc/munin/plugins/forks
ln -s /usr/share/munin/plugins/if_ /etc/munin/plugins/if_eth0
ln -s /usr/share/munin/plugins/if_err_ /etc/munin/plugins/if_err_eth0

Questo non fa altro che generare un link sombolico della plugin in /usr/share/munin/plugins in /etc/munin/plugins ed è poi possibile configuare ulterioremente il comportamento in :/etc/munin/plugin-conf.d

Una volta configurato riavviamo il servizio cosi da ricaricare la configurazione e le diverse plugin, a questo punto i dati vengono registrati:

/etc/init.d/munin-node restart

Il servizio è ora attivo e funzionante, è possibile (e auspicabile) però ad esempio implementare un meccanismo di sicurezza sull’accesso (attraverso IP o autenticazione) alle statistiche.

Se si vogliono monitorare dati di applicazioni o servizi al momento non implementati si può verificare se è disponibile una plugin per questo al seguente indirizzo:

Link interessanti:

Come installare moduli beta di pear

PEAR (PHP Extension and Application Repository) è un framework o un sistema di distribuzione per codice scritto in PHP.

PEAR fu fondato nel 1999 per promuovere il riuso di codice per lo svolgimento di operazioni comuni. Un pacchetto PEAR consiste di codice sorgente, codice binario o entrambi. I package PEAR non hanno dipendenze implicite, deve esplicitamente dichiarare tutte le dipendenze verso altri pacchetti.

La maggior parte dei pacchetti sono disponibili senza problemi, è sufficente egeuire la chiamata d’installazione e questi sono pronti per l’uso:

./pear install <nome_pacchetto>

si viene automaticamente informati se questo è ancora valido oppure se è deprecrato in favore di un nuovo pacchetto, ad esempio DB attualmente è deprecato in favore del più nuovo e performante MDB2.

Ci sono però casi in cui un pacchetto non è disponibile poiché ancora in fase beta, ma perfettamente funzionante, in questo caso esistono 3 metodi per procedere con l’installazione:

Il metodo classico

in questo caso impostiamo nelle prferenze la variabile preferred_state a beta, procediamo conl’installazione del pacchetto e poi re-impostiamo il valore a stable (importante è ricordarsi di rimettere il valore altrimenti tutte le successive installazioni ed aggiornamenti faranno riferimento alle versioni beta).

./pear config-set preferred_state beta
./pear install Session2
./pear config-set preferred_state stable

La forzatura

In questo caso forziamo l’installazione senza prendere in considerazione il warning, attenzione che se viene generato anche un warning per altri motivi (non solo la versione) questo viene ignorato ed il sistema potrebbe essere compromesso.

./pear install -f Session2

L’abbreviazione

la soluzione migliore, poiché equivale alla prima ma è decisamente più breve, imposta il parametro delle preferenze a beta ma ha una validità temporanea (giusto il processo d’installazione).

./pear -d preferred_state=beta install Session2

Flurry – Mobile Application Analytics

Se avete necessità di monitorare come la vostra applicazione mobile funziona, quindi come/dove/quando/… questa viene utilizzata allora avete a disposizione flurry. Si tratta di una specie di google analytics però specifico per le applicazioni mobili e funziona su diverse piattaforme (iphone, android, blackberry e j2me) e cosa non da ultima, è liberamente utilizzabile se le vostre esigenze sono quelle di un normale sviluppatore.

Per quanto mi riguarda sto provando il servizio in una mia applicazione sviluppata per iPhone, ma andiamo con ordine, innazitutto è necessario registrarsi sul sito, procedura rapida, gratuita e senza compicazioni, quindi procedere con il download del framework da integrare nel proprio progetto.

Procediamo quindi con il login all’interno dell’area dedicata agli sviluppatori al seguente link dev.flurry.com e registriamo la nostra applicazione. A questo punto di quali servizi disponiamo e come facciamo ad integrarli?

Dobiamo integrare il Framework all’interno del nostro progetto in Xcode ma prima dobbiamo decidere se vogliamo implementare la geolocalizzazione della nostra applicazione oppure no. Questo servizio utilizza il sistema GPS per determiare la posizione di chi sta utilizzando la vostra applicazione (utile per delle statistiche localizzate).

Import del framework nel progetto
Import del framework nel progetto

Attualemente la versione disponibile è la 1.3, se questa viene aggiornata al vostro prossimo login sul sito di flurry verrete avvisati della disponibilità della nuova versione e potrete (se lo riterrete necessario) provevdere all’aggiornamento, questo chiaramente comporta il rinvio dell’applicazione alla Apple per il processo di approvazione.

Alla registrazione della vostra applicazione viene pure genereta una chiave (API Key) che dovrete integrare nel codice della vostra applicazione. Il sistema più semplice per implementare il servizio è quello di eseguire la chiamata all’interno del vostro AppDelegate come segue:

#import "FlurryApi.h";
...
[FlurryApi startSessionWithLocationServices:@"apikey"];

A questo punto la vostra applicazione è già pronta per supportare la geolocalizzazione ed il tracciamento degli utenti (modalità d’uso, tempi, …), cioé tutte quelle informazioni che vi permettono di capire meglio che tipo d’uso viene fatto del vostro sudore.

Ma non è tutto qui quello che potete fare, ad esempio il sistema permette di registare degli eventi che seguono specifiche chiamate, cosi da poter registarare casi particolari, … ma di questo parlerò in un prossimo post.

Buona statistica a tutti.