Operazioni pianificate in Ubuntu

In Ubuntu il servizio cron serve per schedulare delle operazioni che il sistema deve eseguire periodicamente in modo automatico.

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!

Pubblicato su sysadmin

Usare PHP con il plugin GWT per Eclipse

Sulla guida ufficiale di GWT, nel capitolo JSON – PHP sulla comunicazione tra client e server, viene spiegato di usare Apache o IIS per servire le pagine PHP.  Questa soluzione non è molto pratica in fase di sviluppo perché non consente di sfruttare il server Jetty incluso e quindi la comodità di vedere istantaneamente il risultato delle modifiche al codice Java.

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>
Pubblicato su GWT, PHP

Usare Ruby Enterprise Edition come ruby di sistema in Ubuntu

Vari articoli spiegano come usare Passenger in modalità development. Ma non ho trovato nulla di pratico su come sostistuire il pacchetto ruby di Ubuntu con REE. Così ho deciso di prendere nota della procedura che sta funzionando per me usando Ubuntu 9.04 e REE 2.2.2.

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 rubygemsnon 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 :-).
Pubblicato su sysadmin

RSpec RESTful routes

Srivere le specifiche RSpec per le route REST di RubyOnRails è lungo e noioso. Fortunamente ci ha già pensato qualcun altro a risolvere il problema: Rspec Routes – Really?

Pubblicato su testing

Ez Publish, Drupal o Joomla?

Sto cercando di metter su un piccolo sito di commercio elettronico. Si tratta di rendere disponibili due o tre prodotti per l’acquisto on-line e pagamento tramite PayPal. Inoltre deve essere possibile aggiungere contenuti statici da utenti registrati, pubblicati previa moderazione da parte di un altro utente.

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:

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:

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!

Pubblicato su CMS, e-commerce
  • Si è verificato un errore; probabilmente il feed non è attivo. Riprovare più tardi.
  • Si è verificato un errore; probabilmente il feed non è attivo. Riprovare più tardi.