Gestire i tickets con RequestTracker

Quando venni nominato Responsabile della Telefonia di Ateneo, nel 2010 (se non ricordo male), la mia prima preoccupazione fu quella di adottare un sistema di lavoro che mi permettesse di tenere traccia di tutti gli interventi realizzati e lo stato di ognuno, comprensivo delle varie tappe della lavorazione.

In parole povere, di adottare un sistema informatico di gestione dei lavori: una assoluta novità per il contesto in cui sono, abituato ad una gestione più “casareccia” delle incombenze. Ricordo ancora le prime telefonate di sorpresa alle prime e-mail di risposta automatica…:-)

Dopo una indagine piuttosto approfondita, la mia scelta cadde su RequestTracker, sviluppato da Best Practical, un prodotto di cui sono ancora assolutamente soddisfatto:

RT is a battle-tested issue tracking system which thousands of organizations use for bug tracking, help desk ticketing, customer service, workflow processes, change management, network operations, youth counselling and even more. Organizations around the world have been running smoothly thanks to RT for over 10 years.

Questo sistema, usato da compagnie del calibro della Nasa, Nike, University of Cambridge…, mi ha subito fatto capire che quell’interfaccia un pò spartana e non molto accattivante nascondeva un motore solido, ben fatto, potente e veloce, totalmente open source e sviluppato in Perl.

Inoltre, e questa è la bellezza dell’open source, si trovano centinaia di contributi da parte di numerosi utilizzatori nel mondo che rendono RT eccezionalmente flessibile secondo necessità.

Ad esempio, ho interfacciato la nostra installazione di RT con il server LDAP di Ateneo, permettendomi di poter sfruttare adeguatamente il SSO universitario con la Password Unica e semplificando la vita a tutti i colleghi.

Per coloro che lo volessero provare è disposizione una piattaforma demo all’indirizzo http://rt.easter-eggs.org/demos/stable/

Passiamo ora alla parte tecnica, per veri nerds.

Il server è una macchina virtuale con Linux Debian 7.1 “Weezy” con la partizione di / (root) da 5GByte (ad installazione terminata, senza il database MySQL, lo spazio utilizzato è di 2,1Gbyte) ed una di /var da 7Gbyte (per il DB).

Installiamo subito i prerequisites:

apt-get install apache2 libapache2-mod-perl2 libgd-gd2-perl libxml-perl mysql-client

e se volete avere anche il DBMS sulla medesima macchina, non dimenticate il server MySQL:

apt-get install mysql-server

A questo punto possiamo andare a scaricate il pacchetto dal sito web della BestPractical (attualmente la versione 4.0.13):

http://bestpractical.com/rt/download.html

che scompatteremo:

tar xzf rt-4.0.13.tar.gz

per ottenere la directory rt-4.0.13 che contiene:

root@tickets:~/rt-4.0.13# ls
aclocal.m4 config.layout config.pld configure COPYING docs install-sh Makefile README sbin t
bin config.log config.status configure.ac devel etc lib Makefile.in README.Oracle share

importantissimo adesso leggere il file README, che provo a sintetizzare con questi passaggi dell’installazione:

1) Creazione del Makefile: è necessario specificare tutta una serie di opzioni, ad esempio i miei parametri sono i seguenti:

./configure --with-apachectl --with-web-user=www-data --with-web-group=www-data --with-db-host=localhost --with-db-dba=root --with-db-database=rt4 --with-db-database=rt4 --with-db-rt-user=rt4 --with-db-rt-pass=[password] --enable-gd --enable-graphviz

per la panoramica completa delle opzioni, lanciare:

 ./configure --help

2) Verifica delle dipendenze e prerequisiti Perl:

make testdeps

Questo comando deve essere lanciato più volte fino alla completa soddisfazione di tutti i requisiti (“All dependencies have been found.”), altrimenti l’installazione di RT non verrà effettuata.

3) Installazione dei files nella directory /opt/rt4:

make install

4) A questo punto si procede con l’inizializzazione del database, con:

make initialize-database

Se tutto va a buon fine, siamo già a buon punto. Altrimenti bisognerà procedere con un:

make dropdb

e riprovare.

5) Adesso si impostano i cronjobs con:

crontab -e # as the RT administrator (probably root)
 # insert the following lines:
 0 0 * * * /opt/rt4/sbin/rt-email-digest -m daily
 0 0 * * 0 /opt/rt4/sbin/rt-email-digest -m weekly
 0 * * * * /opt/rt4/sbin/rt-email-dashboards

ed ora si passa alla configurazione del server di posta elettronica che si occuperà di convertire le e-mail degli utenti in richieste di intervento (“tickets“).

Personalmente sono un adepto di Postfix, che installiamo velocemente con:

apt-get install postfix

Tralascio il tuning e l’hardening di Postfix, per passare direttamente alla creazione degli alias all’interno del file /etc/aliases:

rt: "|/opt/rt4/bin/rt-mailgate --queue [myQueue] --action correspond --url http://[myURL]/"
 rt-comment: "|/opt/rt4/bin/rt-mailgate --queue [myQueue] --action comment --url http://[myURL]/"

Nota bene: in caso di necessità trovate tantissime informazioni utili sul Wiki http://requesttracker.wikia.com

Per ogni coda che andremo a configurare nel nostro sistema sarà necessario creare due alias come questi sopra, avendo cura di sostituire [myQueue] con il nome della coda e [myURL] con l’indirizzo del sistema (nel mio caso è tickets.unisi.it).

Ok, adesso passiamo a configurare il server web Apache2.

All’interno della directory /etc/apache2/sites-available creiamo il file rt4 che conterrà:

<VirtualHost [myURL]>
   AddDefaultCharset UTF-8
   DocumentRoot "/opt/rt4/share/html"

   <Location />
      Order allow,deny
      Allow from all
      SetHandler modperl
      PerlResponseHandler Plack::Handler::Apache2
      PerlSetVar psgi_app /opt/rt4/sbin/rt-server
   </Location>
   <Perl>
      use Plack::Handler::Apache2;
      Plack::Handler::Apache2->preload("/opt/rt4/sbin/rt-server");
   </Perl>
</VirtualHost>

Abilitiamo il nuovo host virtuale con:

a2ensite rt4

e riavviamo il server apache2, come suggerito:

service apache2 restart

Login

Se tutto va bene, ed il comando restituisce un “ok” verde, verifichiamo che l’installazione sia andata buon fine aprendo il browser e puntando sul nostro nuovo host virtuale http://[myURL]/ che dovrebbe mostrare la prima schermata di login.

Le credenziali di default sono root:password, che consiglio di cambiare immediatamente.

La fase successiva comporta la configurazione dei parametri del sistema. Il file di configurazione si trova in /opt/rt4/etc, dove trovate diversi files. A noi interessano solo i seguenti due:

root@tickets:~# ls /opt/rt4/etc/ -l
[...]
-r--r----- 1 root www-data 72897 giu 18 14:23 RT_Config.pm
-rw-r----- 1 root www-data 3102 giu 20 14:57 RT_SiteConfig.pm
[...]

RT_Config.pm contiene tutti i parametri di configurazione di default, pertanto non deve essere modificato. Le eventuali modifiche vanno nel file RT_SiteConfig.pm, dove possiamo anche sovrascrivere le impostazioni di default.

Ad esempio, ecco alcuni parametri da impostare:

Set( $rtname, '[myURL]');
Set( $WebDomain, '[myURL]');

Set($LogToFile, info);
Set($LogDir, q{var/log});
Set($LogToFileNamed, "rt.log"); #log to rt.log

Set($RTAddressRegexp , '[clicca qui per sapere come impostare questo valore]');

I parametri per la creazione del LOG sono importantissimi in questa fase di configurazione, perché ci permette di risalire alle cause degli eventuali problemi. In questo caso il file di log lo trovate sotto /opt/rt4/var/log/rt4.log.

Crea una coda

A questo punto, dopo la configurazione base, torniamo all’interfaccia web come amministratori del sistema e procediamo alla creazione della nostra bella prima coda.

La parte più importante, di cui dobbiamo tenere conto, per la creazione dell’alias nel file /etc/aliases, è il nome della coda.

Sarebbe buona consuetudine creare un alias di posta elettronica con lo stesso nome della coda. Ad esempio, per una coda relativa alle richieste di manutenzione, possiamo inserire come nome della stessa “Manutenzione” e come indirizzo e-mail per le richieste manutenzione@[myUrl]. In questo caso, nel file /etc/aliases inseriremo le righe:

manutenzione: "|/opt/rt4/bin/rt-mailgate --queue 'Manutenzione' --action correspond --url http://[myURL]/"
manutenzione-comment: "|/opt/rt4/bin/rt-mailgate --queue 'Manutenzione' --action comment --url http://[myURL]/"

Importante: ogni qualvolta modifichiamo il file /etc/aliases deve essere eseguito il comando:

newaliases

che aggiorna il relativo db aliases.db.

Prima di continuare con le operazioni di configurazione, due parole su come funziona RT.

Ci sono tre elementi: gli UTENTI, i GRUPPI, le CODE.

Le code sono i “contenitori” per le richieste (“tickets”), che sono gestite dal gruppo composto dagli utenti afferenti allo stesso. Ogni utente può afferire ad “n” gruppi così come una coda può essere gestita da “n” gruppi.

Crea gruppo

Per semplificare la gestione, ho preso la consuetudine di impostare un gruppo omonimo per ogni coda.

Detto questo, definiamo adesso il primo gruppo di utenti per la nostra coda di esempio “Manutenzione“, direttamente dal menu Strumenti→Configurazione→Gruppi→Crea.

La creazione di un gruppo è molto semplice: scegli un Nome ed una Descrizione !

Proprietà gruppo

Successivamente, si dovrà aggiungere gli utenti afferenti al gruppo. Potete anche scegliere di procedere in ordine inverso, ovvero prima creare gli utenti, poi il/i gruppo/i e successivamente la/e coda/e ma credo che, concettualmente, sia più chiaro fare questo tipo di workflow.

Procediamo pertanto a creare i nostri utenti.

Creazione utente

Si può creare i singoli utenti “a mano” dal menù Strumenti→Configurazione→Utenti→Crea oppure importarli da un server LDAP utilizzando l’estensione (plugin) RT::Extension::LDAPImport seguendo le istruzioni contenute nel README. In questo caso, che poi è la configurazione da me adottata,conviene affiancare questo plugin a RT::Authen::ExternalAuth che permette di autenticare ogni singolo utente su un server esterno, che può essere LDAP o un db MySQL o un sistema di SSO basato su cookies (anche qui, leggere il README).

Pagina utente

La pagina delle proprietà degli utenti è piuttosto semplice e chiara, pertanto non mi soffermerò sui dettagli.

Una volta creati gli utenti del sistema, procediamo ad assegnarli al nostro gruppo andando alla voce di menù Strumenti→Configurazione→Gruppi→Seleziona e scegliendo, dalla lista, il gruppo desiderato.

Utenti dei gruppi

Cliccando, in alto a destra, la voce di menù “Appartenenti”, otteniamo l’elenco degli utenti già assegnati e il form per aggiungere di nuovi. Il sistema ha una funzione di auto-completamento pertanto iniziando a digitare le prime lettere del nome o dell’username, compariranno tutti gli utenti corrispondenti.

Siamo a buon punto: abbiamo la nostra coda, il nostro gruppo ed i relativi utenti assegnati a tale gruppo.

Elenco code

Adesso è necessario indicare al sistema che la nostra coda ha i permessi per far creare i ticket a chiunque ma la gestione è permessa solamente agli utenti del gruppo “Manutenzione”.

Proprietà della coda

Andiamo pertanto su Strumenti→Configurazione→Code→Seleziona e scegliamo la nostra coda. Da qui, clicchiamo in alto a destra su “Diritti di gruppo” e concediamo il permesso, a “Chiunque“, di:

• Aggiungere commenti ai ticket
• Create tickets
• Rispondi ai ticket

Aggiungiamo poi, dal form in basso, il nostro gruppo “Manutenzione” ed spuntiamo i diritti, sotto General rights:

• Aggiungere commenti ai ticket
• Create tickets
• Rispondi ai ticket
• Registra come richiede o come Cc del ticket o della coda
• View custom field values
• View queue
• View ticket summaries

mentre sotto Rights for Staff spuntiamo:

Diritti di gruppo

 

• Cancella ticket
• Inoltra messaggi al di fuori di RT
• Modifica i valori dei campi personalizzati
• Modifica i ticket
• Registra come AdminCc del ticket o della coda
• Sottrae ticket
• Prendi in carico ticket
• View exact outgoing email messages and their recipients
• View ticket private commentary

A questo punto dovremmo essere arrivati ad aver configurato la nostra prima “coda”. Proviamo adesso ad inviare una mail all’indirizzo della coda (manutenzione@[myURL]) tenendo sotto controllo il log rt.log:

[info]: <rt-4.0.13-4157-1371728971-353.95-14-0@example.com> #95/131567 - Scrip 14 Alla creazione di un ticket (/opt/rt4/sbin/../lib/RT/Action/SendEmail.pm:285)
[info]: <rt-4.0.13-4157-1371728971-353.95-14-0@example.com> sent To: test@domain.ext (/opt/rt4/sbin/../lib/RT/Action/SendEmail.pm:316)
[info]: Ticket 95 created in queue 'Manutenzione' by test@domain.ext (/opt/rt4/sbin/../lib/RT/Ticket.pm:694)

e nell’elenco dei tickets, alla pagina “Quadro di insieme”, troverò la richiesta.

I prossimi step saranno la personalizzazione dei messaggi automatici, i Template, che vengono inviati tramite attivazione degli Scrip. Ma questo ve lo spiegherò nella seconda puntata !

DISCLAIMER: Questo post, ovviamente, non vuole avere la pretesa di essere un tutorial completo all’installazione e uso di RequestTracker. RT è un sistema abbastanza complesso e potente, che necessita di qualche ora di studio per comprenderne il paradigma ed imparare a muoversi attraverso di esso. Personalmente ho impiegato, in assenza di una guida esaustiva, diversi giorni prima di capire come configurarlo ed usarlo adeguatamente: spero che con queste poche righe possa essere di aiuto a tutti coloro che decidessero di usarlo per le loro necessità.

Non mi assumo, come è evidente, alcuna responsabilità né garanzia di funzionamento del sistema. Queste righe sono da considerarsi una semplice panoramica sulle funzionalità del programma.

Detto questo…buon lavoro !