Il principio di funzionamento è molto semplice: basta indicare quando e/o ogni quanto tempo eseguire un dato comando. Meno semplice è far sì che eventuali problemi siano immediatamente segnalati, perché bisogna assicurarsi che cron possa inviare correttamente le mail e, di default, su Ubuntu l’invio di mail è disabilitato.

Perché le mail? Perché ogni volta che un comando genera dell’output, cron lo invia tramite mail a chi ha schedulato il comando. Quindi basta far sì che un qualsiasi problema provochi la scrittura di un qualche messaggio, per ricevere una mail con questo messaggio… sempre che la mail sia configurata correttamente.

Se avete esigenze sofisticate vi conviene usare postfix. Ma se siete comuni mortali vi potete accontentare di ssmtp, non perché è più semplice da configurare, ma perché non richiede manutenzione. Per l’uso di cui stiamo parlando, il solo vantaggio di postfix è quello di gestire le code di messaggi, cioè di essere in grado di ritardare la consegna della mail nel caso in cui non sia possibile inviarla immediatamente. Questo però non ci garantisce che la mail arriverà, perché il problema che ne impedisce l’invio potrebbe non risolversi mai. Se quello che ci serve è la ragionevole certezza che tutto stia funzionando, allora è più semplice ed efficace inviare una mail non solo in caso di problemi, ma anche per notificare che il lavoro è stato fatto. In questo modo la mancanza di notifiche è sufficiente a metterci in allarme, con il solo svantaggio di dover impostare qualche filtro per digerire meglio tutte queste mail.

Ecco un esempio di /etc/ssmtp/ssmtp.conf:

root=mioindirizzo@email.it
mailhub=out.alice.it
rewriteDomain=miodominio.it
hostname=miohost.miodominio.it

Qui sto usando il server SMTP di Alice, usate il vostro. Mettete il vostro indirizzo mail in “root” e scegliete un dominio e un nome host che vi facciano capire da dove arrivano le mail. Fatto!

La soluzione è semplice: configurare Jetty per eseguire il codice PHP.

Ho trovato due modi per farlo:

1. Configurare Quercus.
2. Usare la servlet CGI fornita con Jetty

Preferisco la seconda soluzione perché più simile all’ambiente di produzione usando l’eseguibile “standard” di PHP.

Su Ubuntu è stato sufficiente installare il pacchetto php5-cgi ed aggiungere in  war/WEB-INF/web.xml il seguente frammento di configurazione:

 <servlet>
   <servlet-name>PHP Servlet</servlet-name>
   <servlet-class>org.mortbay.servlet.CGI</servlet-class>
   <init-param>
     <param-name>commandPrefix</param-name>
     <param-value>php5-cgi</param-value>
   </init-param>
 </servlet>

 <servlet-mapping>
   <servlet-name>PHP Servlet</servlet-name>
   <url-pattern>*.php</url-pattern>
 </servlet-mapping>

Uso REE e Passenger per il deploy di applicazioni ROR e, per ridure al minimo le sorprese, uso lo stesso ambiente in fase di sviluppo.

Una nota importante: seguendo questa procedura tutti i comandi ruby e rubygems (in particolare ruby, gem e rake) e tutte le librerie ruby (per esempio il driver ODBC) saranno installati nella cartella /opt/ruby-enterprise-VERSIONE-DI-REE. Quindi, quando si aggiorna REE bisognerà reinstallare le gem e le librerie non comprese nella distribuzione.  Questo è certamente uno svantaggio, ma in compenso si ha il grande vantaggio di poter fare facilmente il rollback in seguito ad un aggiornamento problematico e di poter tenere facilmente più versioni di ruby e relative librerie sullo stesso sistema.

1. Scaricare e installare REE
2. Seguire anche le istruzioni per l’installazione di Passenger
3. Installare i comandi di sistema:

   cd /opt
   sudo ln -s ruby-enterprise-1.8.6-20090520 ruby-enterprise
   sudo aptitude --purge remove ruby rubygems
   sudo update-alternatives \
     --install /usr/bin/ruby ruby /opt/ruby-enterprise/bin/ruby 50 \
     --slave /usr/bin/gem gem /opt/ruby-enterprise/bin/gem \
     --slave /usr/bin/erb erb /opt/ruby-enterprise/bin/erb \
     --slave /usr/bin/testrb testrb /opt/ruby-enterprise/bin/testrb

4. Aggiornare il PATH per “vedere” i comandi installati con rubygem aggiungendo a ~/.bashrc:

   export PATH='/opt/ruby-enterprise/bin':"$PATH"

Ricordarsi di aggiornare il link /opt/ruby-enterprise ad ogni aggiornamento di REE, altrimenti si continuerà ad usare sempre la stessa versione di REE e relative librerie.

Alcune note:

• “aptitude --purge remove ruby rubygems” non rimuove l’installazione ruby di sistema (vedi i pacchetti ruby1.8 e ruby1.9), ma solo i link ai comandi gem, ruby, erb e testrb. Con i comandi update-alternatives si ricreano questi link in modo che puntino all’installazione di REE.
• sudo ignora il PATH dell’utente, quindi per lanciare con sudo un comando installato con rubygems (per esempio rake) bisogna specificare il path assoluto del comando. In alternativa si può impostare il PATH di sistema… ma questo è lasciato come esercizio .

L’hosting che ho a disposizione fornisce PHP-5.2, MySQL-5, Tomcat. Per non essere sopraffatto dall’enorme numero di scelte disponibili, ho temporaneamente scelto di usare il PHP.

Prima ho provato dei CMS pensati appositamente per l’e-commerce:

• OXID eShop
• osCommerce
• Zen Cart
• osCMax
• Magento

Li ho trovati tutti troppo complessi per le mie modeste richieste. Quindi ho valutato l’uso di un CMS generico che offrisse anche funzionalità di e-commerce. In due giorni di ricerche ho ristretto la lista a:

• Drupal con e-Commerce
• Joomla! con VirtueMart
• eZ Publish con Website Interface

All’inizio il più allettante è Joomla. Per vari motivi: è semplicissimo da installare anche nei servizi di hosting più restrittivi; è semplicissimo da ottimizzare per i motori di ricerca; è semplicissimo ottenere delle URL brevi, chiare e con l’estensione “.html”; i temi di default sono sufficienti per costruire un sito carino.

Joomla però ha presto rivelato diverse pecche di immaturità. La più grave è che quando un utente crea un articolo e questo articolo viene pubblicato da un moderatore, l’utente iniziale può modificare a piacere l’articolo pubblicato senza che le modifiche siano sottoposte al moderatore. Questo di fatto annulla la possibilità di moderare la pubblicazione dei contenuti di un articolo.

Drupal, sebbene più complesso, sembra essere un prodotto più maturo rispetto a Joomla. Tuttavia dopo un giorno speso ad utilizzarlo non mi ha entusiasmato ed ho voluto provare quacos’altro prima di perderci altro tempo.

Ho trovato così eZ Publish. Ricordo di averlo provato sei o sette anni fa e di averlo poi abbandonato per la pessima documentazione. Da allora la documentazione è molto migliorata.

Dei tre eZ Publish è sicuramente il più difficile da installare ma, una volta installato e configurato, è il più semplice da personalizzare. Moltissime cose possono essere fatte senza scrivere una riga di codice. Ogni cosa è facilmente estendibile e personalizzabile direttamente dall’interfaccia Web. Le ACL possono essere estese a piacere e con un’alta granularità. Supporta in modo molto semplice la pubblicazione di documenti scritti off-line con OpenOffice o Word. Insomma molte caratteristiche utili e pochi fronzoli. Provatelo!