Systém RT v prostředí CESNET, z. s. p. o.

Technická zpráva CESNETu číslo 16/2002
k dispozici též ve formátech PDF, PostScript a XML.

Jakub Urbanec, Jan Okrouhlý
1. prosinec 2002

1   Úvod

Dokument se zabývá současným stavem nasazení systém RT v CESNET, z. s. p. o. (tj. systém podpory řešení provozních problémů a konfiguračních požadavků), jeho konfigurací a budoucím vývojem. Dnes se RT (dříve Request Tracker) používá při řešení provozních problémů jako prostředník mezi řešiteli, provozní částí i okolním světem. RT systémem dnes prochází objednávky, provozní výpadky, žádosti uživatelů, stížnosti (a snad i pochvaly).

2   Terminologie

Pro zjednodušení orientace v dokumentu je třeba nejprve uvést základní pojmy, se kterými se uživatel běžně setká rovněž i v RT samém.

Požadavek (Ticket)
Požadavek je celý zaznamenaný dotaz se všemi jeho atributy, jako je vlastník, fronta, stav, pozorovatelé a korespondence.
Vlastník (Owner)
Osoba, které požadavek patří (je za něj odpovědná či jí konkrétně byl dán k vyřízení).
Pozorovatel (Watcher)
Někdo, kde je zaznamenán že má zájem o požadavek. Mohou jím být žadatelé, Cc: i AdminCc:. Účinnost není limitována na jeden požadavek, ale může být rovněž pozorovatelem celé fronty. Pozorovatelům se zasílají kopie při korespondenci náležící požadavku.
Fronta (Queue)
Sada požadavků dané problematiky, např. nákupy nebo veřejné vztahy. Podle potřeby lze přidělovat přístup k dané frontě na prohlížení či úpravy požadavků.
Klíčová slova (Keywords)
Mohou být přiřazena požadavkům pro usnadnění klasifikace a vyhledávání požadavků.
Korespondence (Correspondence)
Jsou zde základní dva druhy korespondence: Komentáře a Odpovědi. Komentáře se nezasílají žadatelům a jedná se typicky o poznámky během práce na požadavku. Odpovědi se naopak běžně zasílají všem pozorovatelům.
Stav (Status)
Nabývá hodnot: new, open, stalled, resolved a dead. Je východiskem při klasifikaci vývoje požadavku:
New
Nově vytvořený požadavek - žádná práce nebyla na základě tohoto požadavku vykonána
Open
Vlastník je zaměstnám zpracováním požadavku (požadavek je zpracováván)
Stalled
Vlastník čeká na odezvu třetí strany
Resolved
Požadavek byl uspokojen a uzavřen
Dead
Požadavek je bezpředmětný a je smazán. RT neumožňuje přímo rušení požadavků, pouze je převádí do tohoto stavu.
Scrips
Silný mechanizmus, kterým lze v RT definovat, za jaké podmínky se má při provádění vnitřní transakce vykonat jaká funkce a nad jakým vzorovým souborem. Základní sada podmínek, funkcí a vzorů je k dispozici hned po instalaci systému, ale lze ji relativně jednoduše rozšířit dle specifickým potřeb. Například, že při vyřešení požadavku se má žadateli zaslat elektronickou poštou krátká zpráva informující o této změně.
Privilegovaný uživatel
Uživatel RT, kterému mohou být následně explicitně přidělována přístupová práva ke konkrétním činnostem. Prakticky je to každý, kdo může manipulovat s požadavky v systému (operátor, správce nějaké služby atp.). Není jím tedy běžný žadatel, ale typicky někdo z kolegů řešících požadavky v RT.

3   Současný stav nasazení RT v síti Cesnet2

Aktuálně se systém aktivně používá pro vyřizování požadavků na nákupy (fronta order), kde se ročně zpracuje kolem 120 požadavků. Převážně pasivně se používá ke sledování problémů na uzlech sítě (fronty NOC, pop a tickets), kde se zpracuje celkem cca 6000 požadavků za rok. Ostatní použití je z hlediska statistik zanedbatelné - jedná se o řešení běžných provozních požadavků například na centrální autentizační a autorizační systém (fronta AAA), komunikaci mezi správci uzlů (fronta Admin) či třeba správu systému samého (fronta RT).

Požadavky do systému vstupují převážně prostřednictvím rozhraní elektronické pošty a jsou přístupné pouze uživatelům registrovaným v centrální autorizačním systému (CAAS). Výstup je pak buď opět formou elektronické pošty či pouze dostupností na WWW (přístup je zabezpečen prostřednictvím SSL).

4   Realizace a konfigurace

Pro realizaci RT se zatím používá jeden stroj s volně šiřitelným operačním systémem i programy, klientem je libovolná stanice s WWW prohlížečem a poštovním klientem.

4.1   Server

Hardware a OS
V současné době je hardware rt.cesnet.cz jeden stroj PC v konfiguraci:
  • Dell PowerEdge 1300
  • 2xPentiumIII 700 MHz
  • 512 MB RAM
  • 9 GB SCSI disk
Operační systém tvoří Linux distribuce Debian. Jádro je řady 2.4.
Software
Hlavními komponentami jsou:
  • databáze MySQL (verze 3.23.51)
  • webserver Apache (verze 1.3.26 s moduly pro autentizaci proti CAAS/LDAP)
  • poštovní server Postfix (verze 1.1.7)
  • systém RT (verze 2.0.15)
K provozu RT verze 2 je dále třeba instalace apache modulu mod_perl, webové nadstavby Mason a množství CPAN perlovských modulů (instalace RT jejich přítomnost naštěstí ošetří). Provozně se používá RT s lokálními úpravami pro CESNET, z. s. p. o., což vyžaduje navíc instalaci autentizačního modulu do apache serveru (pro autentizaci proti CAAS), programu ldap_search (pro autorizaci z CAAS) a programu recode (pro ukládání dat v jednotném kódování lokálních znakových sad). Výhledově do tohoto seznamu přibude modul GnuPG pro možnost ověřování identity uživatelů pracujících se systémem elektronické pošty.

4.2   Klient

WWW
Prohlížení, správa a zadávání požadavků, správa systému
Pozn.: Prohlížeč musí mít povoleny tzv. Cookies.
Elektronická pošta
Zadávání a správa požadavků
Pozn.: Výhledově bude správa požadavků možná pouze s klienty umožňujícími podepsání zprávy dle PGP standardu.
Příkazová řádka
Možnost správy systému a práce s požadavky
Pozn.: Použití je zde konkrétně omezeno na správce systému a případné skripty.

4.3   Konfigurace systému

Základní potřebné informace pro instalaci systému lze získat nejlépe z dokumentu WebRT Manual - Installation.doc dostupného na WWW. Zde jsou uvedeny jen specifické konfigurační informace.

4.3.1   RT - úpravy Makefile

RT_PATH /opt/rt2
RT_LOG_PATH /tmp

DB_TYPE mysql
DB_HOME /usr
DB_DBA root
DB_DBA_PASSWORD :heslo správce mysql databáze:
DB_RT_HOST localhost
DB_DATABASE rt2
DB_PORT
DB_HOST localhost
DB_RT_USER rt_user
DB_RT_PASS :heslo uživatele rt_user:

WEB_USER www-data
WEB_GROUP www-data
Poznámka: Makefile je vhodné pečlivě uchovat nejen z důvodu, že obsahuje hesla správce MySQL a přístupové heslo do databáze RT, ale rovněž přijde vhod v případě rozzálohování či upgrade systému, kdy často dojde ke změně vlastnictví souborů a přístupových práv (nejčastěji zároveň suid bitů). Příkaz make fixperms pak dokáže během chvilky napravit zdánlivě nenapravitelné.

4.3.2   RT - úpravy config.pm

Jedná se o konfigurační soubor RT, kterým se nastavují základní parametry jeho chování. Zapsán je v jazyku Perl a interpretován při vyvoláním RT, tj. při každém startu WWW modulu pomocí mod_perl, při příchodu elektronické pošty do RT atp. Opět jsou zde uvedeny jen konkrétní úpravy oproti implicitním hodnotám.

$rtname ten.cz
Značka (tag) systému pro identifikaci příchozí elektronické pošty. Jakmile je systém jednou v provozu, není vhodné tuto hodnotu měnit, neboť by rozhraní elektronické pošty příchozí korespondenci k existujícím požadavkům považovalo za požadavky nové.
$Organization ten.cz
Formální značka systému v hlavičkách elektronické pošty.
$Timezone Europe/Prague
$OwnerEmail root
Adresa správce systému (nesmí být nasměrována do RT!) pro řešení případných problémů s elektronickou poštou.
$Charset iso-8859-2
Interní reprezentace národního kódování dat (místní úprava).
$CorrespondAddress rt-req@rt.cesnet.cz
Neudá-li správce fronty jinak, použije se tato adresa v odpovědích na požadavky.
$CommentAddress rt-com@rt.cesnet.cz
Neudá-li správce fronty jinak, použije se tato adresa v komentářích požadavků.
$PGPSignedOnly 0
Při nastavení na nenulovou hodnotu bude rozhraní elektronické pošty při interpretaci příchozí zprávy důvěřovat jen pokud úspěšně ověří PGP podpis jejího autora (místní úprava).
$MailCommand sendmail
Konstanta (nikterak nesouvisí s použitím postfix, exim atp.), která říká že výstupem je program v $SendmailPath.
$SendmailArguments -t
Argumenty (zde pro systém postfix)
$SendmailPath /usr/lib/sendmail
$UseFriendlyToLine 1
Formát položky odesílatel (From) v elektronické poště bude obsahovat skutečné jméno uživatele provádějícího danou operaci.
$WebPath /rt2
Relativní cesta ke kořenovému adresáři samotného WWW rozhraní RT.
$WebBaseURL https://rt.cesnet.cz
$MasonComponentRoot /opt/www/rt2
$MasonLocalComponent /opt/rt2/local/WebRT/html
Adresář obsahující místní úpravy html (Mason nadstavby) části WWW rozhraní RT.
$ShowPrivilegedUserRequests 1
V zobrazované historii požadavků WWW rozhraním RT se takto zobrazují i požadavky žadatelů, kteří jsou privilegovanými uživateli typu AdminCc: atp. (místní úprava).
$AlwaysSeeQueue 1
Umožní využít RT právo (ACL) SeeQueue k tomu, aby se uživateli daná fronta zobrazovala v přehledu front na úvodní pracovní obrazovce RT a jinak uživatel mohl vyhledávat ve všech frontách, má-li alespoň právo vidět obsah požadavků (místní úprava).
$ShowDeadTickets 1
Zruší standardní nedostupnost požadavků ve stavu Dead, při požadavku na jejich explicitní vyhledávání (místní úprava).
%WebOptions
    (
     QueueListingCols => 
      [
       { Header     => '#',
         TicketLink => 1,
         TicketAttribute => 'Id'
         },

      { Header     => 'Vec',
         TicketLink => 1,
         TicketAttribute => 'Subject'
         },
       { Header => 'Zadatel(e)',
         TicketAttribute => 'RequestorsAsString'
         },
       { Header => 'Stav',
         TicketAttribute => 'Status'
         },

       { Header => 'Fronta',
         TicketAttribute => 'QueueObj->Name'
         },

       { Header => 'Kontakt',
         TicketAttribute => 'ToldObj->AgeAsString'
         },

       { Header => 'Stari',
         TicketAttribute => 'CreatedObj->AgeAsString'
         },

       { Header => 'Uprava',
         TicketAttribute => 'LastUpdatedObj->AgeAsString'
         },

       { Header => 'Vlastnik',
         TicketAttribute => 'OwnerObj->Name'
       },
   
       { Header     => 'Vzit',
         TicketLink => 1,
         Constant   => 'Take',
         ExtraLinks => '&Action=Take'
         },

       { Header     => 'Oblast',
         Keyword    => 'Area',
         },

      ]
     );

Poněkud složitější datová struktura v jazyku Perl (momentálně hash s jednou hodnotou odkazující na pole s ukazateli na hashe), která však docela přehledně umožní definovat vzhled stránky s výstupem seznamu vyhledaných požadavků. Keyword je opět místní úprava umožňující zobrazit hodnotu daného klíčového slova (zde Area).

4.3.3   WWW - úpravy httpd.conf

MaxRequestsPerChild 50 # omezení potenciálního neuvolňování zdrojů

Listen 80 # čistě pro redirekci, při přístupu http  namísto https

LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime_ssl.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth_ssl.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
LoadModule perl_module /usr/lib/apache/1.3/mod_perl.so
LoadModule ssl_module /usr/lib/apache/1.3/mod_ssl.so
LoadModule auth_ldap_module /usr/lib/apache/1.3/auth_ldap.so

<IfDefine SSL>
Listen 443 # implicitní SSL port
</IfDefine>

User www-data # identita pod níž běží WWW rozhraní RT
Group www-data

ServerAdmin webmaster@rt.cesnet.cz # formální kontaktní osoba

DocumentRoot /var/www  # formální kořenový adresář dokumentů

<Directory /> # Vynucení autentizace při přístupu k serveru
    Options SymLinksIfOwnerMatch
    AllowOverride None
    SSLRequireSSL
    AuthType Basic
    AuthName CAAS
    AuthLDAPURL ldaps://tady.ten.cz tam.ten.cz/ou=People,o=ten.cz
    require valid-user
</Directory>

<Directory /var/www/>
    Options Indexes Includes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>

AddDefaultCharset iso-8859-2 # Znaková sada veškerých zobrazovaných dat

<IfModule mod_perl.c>  # Nutná inicializace mod_perl
  Alias /perl/ /var/www/perl/
  <Location /perl>
    SetHandler perl-script
    PerlHandler Apache::Registry
    Options +ExecCGI
  </Location>
</IfModule>

<VirtualHost 195.113.134.171:80> # Zajištění redirekce http na https
     ServerAdmin okrouhly@civ.zcu.cz
     DocumentRoot /opt/www/

     ServerName rt.cesnet.cz
     ErrorLog /var/log/apache/http_error_log
     TransferLog /var/log/apache/http_access_log
     Redirect / https://rt.cesnet.cz/
</VirtualHost>

<IfDefine SSL>
<VirtualHost _default_:443> # Samotný https přístup do systému

        DocumentRoot "/opt/www" # Kořenový adresář (úvodní informační stránky, dokumentace atp.)
        ServerName rt.cesnet.cz
        ServerAdmin root@rt.cesnet.cz
        ErrorLog /var/log/apache/rt2_error_log
        TransferLog /var/log/apache/rt2_access_log

 PerlModule Apache::DBI
 PerlFreshRestart On
 PerlRequire /opt/rt2/bin/webmux.pl # Vlastní inicializace obsluhy WWW požadavků


SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
SSLEngine on
SSLCertificateFile /etc/ten/ssl.crt/rt.cesnet.cz.crt
SSLCertificateKeyFile /etc/ten/ssl.key/rt.cesnet.cz.key
SSLCertificateChainFile /etc/ten/ssl.crt/TEN_CA_Bundle.crt
AuthLDAPCACertFile /etc/ten/ssl.crt/TEN_CA_Bundle.crt

<Location /rt2> # Navázání URL RT na Mason interpret
 SetHandler perl-script
 PerlHandler RT::Mason

SSLRequireSSL 
AuthType Basic 
AuthName CAAS 
AuthLDAPURL ldaps://tady.ten.cz tam.ten.cz/ou=People,o=ten.cz 
require valid-user
</Location>

<Directory /opt/www/>
    Options SymLinksIfOwnerMatch
    AllowOverride None
</Directory>

<Directory /opt/www/rt2/>
   Options SymLinksIfOwnerMatch
   AllowOverride None
</Directory>

# Přesměrování starších URL z RT verze 1 z kompatibilních důvodů
# (mohou se vyskytovat ještě ve staré elektronické poště)
Redirect /rtview.cgi http://rt.cesnet.cz:443/rt2/
Redirect /rt.cgi http://rt.cesnet.cz:443/rt2/
Redirect /rtadmin.cgi http://rt.cesnet.cz:443/rt2/
</VirtualHost>
</IfDefine>

4.3.4   Elektronická pošta - úpravy aliases

webmaster: root
postmaster: root
mailer-daemon: postmaster
www-data: root
root: okrouhly@civ.zcu.cz

#
# Request Tracker aliases
#
rt:             "|/opt/rt2/bin/enhanced-mailgate -queue rt -action action"
rt-req:         "|/opt/rt2/bin/enhanced-mailgate -queue rt -action correspond"
rt-com:         "|/opt/rt2/bin/enhanced-mailgate -queue rt -action comment"
operator:       "|/opt/rt2/bin/enhanced-mailgate -queue operator -action correspond"
operator-com:   "|/opt/rt2/bin/enhanced-mailgate -queue operator -action comment"
.
.
.

4.3.5   CRON - crontab

# RT2 sekce

# Zálohování RT systému
4 * * * 1-6  root /opt/rt2/save_rt.sh
#Čištění dočasných souborů od Mason resp. Apache::Session starších 3 dní
0 * * * * find /opt/rt2/WebRT/sessiondata -type f -amin +4320 -exec rm {} \;

# konec RT2 sekce

Záloha nejnutnějších dat - save_rt.sh

#!/bin/sh
LOCKFILE=/opt/rt2/save_rt.pid
LOGFILE=/opt/rt2/save_rt.log
TERM=linux; export TERM
        if [ -r ${LOCKFILE} ]; then
                echo save_rt.sh already running \(PID=`cat ${LOCKFILE}`\).
                kill -9 `cat ${LOCKFILE}` && \
                rm ${LOCKFILE} #|| exit 1
        fi
        echo $$>$LOCKFILE
        echo STARTING at `date` ------>>$LOGFILE
export PATH=/usr/bin:$PATH
mysqldump rt2>/tmp/rt.$$.sqldump &&  \
cd /opt&& tar czf /tmp/rt.$$.tgz rt2 &&  \
cd /&& tar czf /tmp/rt.$$.apache_confs.tgz etc/apache/httpd.conf \
 etc/init.d/apache etc/crontab etc/aliases \
 opt/inst.rt/rt.cesnet.cz/Makefile opt/inst.rt/rt.cesnet.cz/zal && \
cd /tmp && \
tar czf /tmp/rt_dump.tgz rt.$$.* &&  \
        echo BACKUP DATA COLLECTED at `date` ------>>$LOGFILE

rm /tmp/rt.$$*
rm $LOCKFILE

exit

5   Příručka do kapsy

Tato sekce obsahuje základní popis chování systému, tj. popis interakce s žadateli, privilegovanými uživateli (manipulátory) a správci front resp. administrátory.

5.1   Uživatelská stránka (žadatel)

V rámci CESNET,~z.~s.~p.~o. je žadatelům k dispozici pouze standardní rozhraní elektronické pošty. Lze sice na WWW serveru vytvořit veřejně přístupnou část s příslušnými formuláři, ale není k tomu žádný důvod. Příkladem řešení je formulář pro objednávky materiálu (umístěn na zcela jiném WWW serveru), který až po jeho korektním vyplnění předává data do RT elektronickou poštou.

5.1.1   Vznik požadavku

V závislosti na konfiguraci cílové fronty může žadateli RT automaticky odpovědět resp. potvrdit příjem jeho zprávy. Žadatel tak ví, že jeho zpráva byla doručena a navíc získává jedinečný identifikátor vzniklého požadavku, se kterým se na něj může kdykoli později odkazovat. Automatické odpovídání je u některých front naopak nežádoucí, například přichází-li požadavky strojově generované.

5.1.2   Zpracování požadavku

Vzniklý požadavek je v dané frontě ve stavu New. Některý z manipulátorů dané fronty se začne požadavkem zabývat (buď na základě zprávy, kterou zašle RT všem manipulátorům fronty, nebo na základě objevení se na WWW rohraní) tak, že se stane vlastníkem požadavku a odpoví žadateli (buď dotázáním se na další zatím neudané potřebné podrobnosti nebo popisem vyřešení požadavku). Žadatel tak dostane další zprávu, na niž může prostou odpovědí odeslat požadované upřesnění. RT přitom změní stav požadavku na Open (v případě jeho vyřešení může autorizovaný manipulátor samozřejmě změnit jeho stav při odpovědi rovnou na hodnotu resolved). Při této další korespondenci žadatele je důležité, aby zachoval v poli Věc (Subject) relevantní údaje jednoznačně identifikující požadavek (o tomto postupu bývá žadatel zpravidla informován právě výše zmiňovanou automatickou odpovědí). Rozhraní elektronické pošty RT tak automaticky může zatřídit zprávu k příslušnému požadavku (a případně ji opět rozeslat všem pozorovatelům).

5.1.3   Vyřešení požadavku

Implicitní nastavení RT neinformuje uživatele o vyřešení požadavku (předpokládá se, že byl informován o vyřešení předchozí korespondencí - viz např. předchozí odstavec), ale manipulátor má možnost při nastavování stavu resolved přidat k operaci textový komentář, jehož typ může změnit na odpověď. Pokud žadatel ještě odepíše, RT automaticky převede požadavek do stavu open, takže manipulátoři front o změně dozví i z WWW rozhraní a mohou náležitě reagovat.

5.2   Standardní manipulátor (privilegovaný uživatel)

Základní obecné znalosti získá privilegovaný uživatel nejlépe z on-line dokumentace na https://rt.cesnet.cz/navod.html nebo z dokumentu WebRT Manual - User Guide share.doc dostupného na WWW. Zde jsou uvedeny jen základní či nezbytné specifické informace.

5.2.1   Zpracování požadavků

Nejprve se manipulátor musí o požadavku, který má zpracovávat, dozvědět - možností je několik:

V případě práce přes rozhraní elektronické pošty často může rovnou odpovědět žadateli a zpráva se správně doručí a zároveň zaznamená k příslušnému požadavku v RT. Je zde ale hned několik úskalí: zaslání historie, či komentář od jiného manipulátora mají přednastavenu adresu pro odpověď na adresu určenou pro zasílání komentářů, takže pokud ji manipulátor příslušně neupraví, nedoručí se zpráva žadateli (toto velmi častá chyba). Rovněž není někdy politicky únosné, aby se v odpovědi žadateli objevil celý výpis historie požadavku (včetně potenciálně nejapných komentářů) a je třeba odesílanou zprávu pečlivě prohlédnout (opět relativně častá chyba). Největší úskalí spočívá v netriviálnosti provedení operací typu převzetí požadavku prostřednictvím elektronické pošty (minimálně je nutné znát speciální příkazy a správně je uvodit na začátek zprávy). Běžně se také manipulátor při práci prostřednictvím elektronické pošty nedoví, že požadavek si již někdo vzal za vlastní a zabývá se jím (není problém v implementaci zasílání informací o změně vlastnictví, ale v množství elektronických zpráv, které by takovýto manipulátor musel zpracovávat). Závěr je, že se doporučuje veškeré následné operace (poté, co se manipulátor doví o potřebě věnovat se požadavku) provádět prostřednictvím WWW rozhraní.

První nejdůležitější operací je tak vždy převzetí požadavku, pokud již není daným manipulátorem vlastněn. Je-li naopak vlastněn jiným manipulátorem a přesto jej musí řešit daný manipulátor, pak je k dispozici funkce Steal (tzv. ukradení požadavku). Je-li navíc požadavek v jiné frontě, kam nemá daný manipulátor přístup, pak musí o přesun požadavku požádat (třeba komentářem) někoho z příslušné fronty a nebo může založit požadavek nový (s příslušně vyplněnou položkou Requestor resp. žadatel) a odkázat v něm na již existující (toto je často velmi praktické řešení, protože RT tuto vazbu přehledně zobrazuje i u prvotního požadavku v druhé frontě).

Ostatní manipulátoři tak vidí, že požadavek je již vlastněn a někdo na něm pracuje. Jedná-li se o nový požadavek (stav New), pak je ještě správné převést jej do stavu Open (toto lze případně pomocí Scrips zautomatizovat). Nyní je teprve ten správný čas na korespondenci se žadatelem (případně na komentáře, které doplňují vnitroorganizačně potřebné informace). Odpověď žadateli rovněž převádí případně požadavek do stavu Open (totéž činí korespondence také v případě, že již byl ve stavu Resolved). Scrips se postarají o případné zaslání kopie komunikace i ostatním manipulátorům (doplněné o URL, aby si případně mohli přehledně prohlédnout celý vývoj požadavku na WWW rozhraní). Místní úprava umožňuje toto informování potlačit (zaškrtnutím Do not notify manipulators), pokud manipulátor usoudí, že by je daná aktuální korespondence zbytečně obtěžovala. Existuje také opačný případ, kdy je vhodné danou korespondenci zaslat třetí osobě. V tom případě se nabízí možnost zadat její elektronickou adresu do políček Cc: resp. Bcc:. Pokud má být tato osoba informována o celém dalším vývoji požadavku, je zde ještě možnost přiřadit ji prostřednictvím odkazu na pozorovatele požadavku (Ticket Watchers) do seznamu Cc: (zasílání korespondence s žadatelem) resp. AdminCc: (zasílání korespondence i komentářů atp.) daného požadavku.

Občas manipulátor potřebuje zaslat již existující zprávu v historii třetí osobě a nechce, aby její odpověď dorazila do systému RT (potažmo žadateli). Pro tento účel je zde ještě funkce Forward (místní úprava), která umožní zadat elektronickou adresu jak adresáta, tak i odesílatele (a tedy potenciálního příjemce odpovědi). S úspěchem lze tuto funkci také použít pro vytvoření nového požadavku v RT (či jakési kopie - viz výše uvedený případ řešení žádosti z požadavku v nedostupné frontě).

Tímto je popsána většina nejčastějších operací prováděných při zpracování požadavku a zbývá jen požadavek po vyřešení převést do stavu Resolved (pokud tak již nebylo učiněno při korespondenci, což systém umožňuje). Zde je opět nutné připomenout další častou chybu a to, že volba Resolve implicitně nabízí jako souběžnou operaci možnost zaslat komentář (a ne korespondenci, tj. odpověď žadateli). Předpokládá se totiž, že o vyřešení je informován předchozí korespondencí jen žadatel a teprve při změně stavu na Resolved se informují ostatní manipulátoři o způsobu vyřešení požadavku (či spíše problému).

5.2.2   Vyhledávání požadavků

Vyhledávání je druhou nejpodstatnější funkcí systému. Hodí se jak při zpětném dohledávání obsahu staršího požadavku (typicky při řešení požadavku resp. problému, který už pravděpodobně dříve nastal a byl řešen), tak při potřebě zobrazit přehledně obsah sledovaných front setříděn a vybrán dle volitelných kritérií. Popis použití je opět zpracován ve výše odkazovaných dokumentech. Nejčastěji se vyhledávají otevřené (či nové) požadavky v jedné konkrétní frontě. K tomu je v úvodní stránce (na WWW rozhraní RT označována jako Home) seznam sledovaných front (i s přehledem o počtu požadavků v daném stavu) a lze pouhým zvolením příslušné fronty zobrazit odpovídající výstup hledání. Cílem je, aby se počty nových (či otevřených) požadavků držely na nule, takže pokud manipulátor zpracovává nové požadavky z více front jen přes WWW, nejvíce mu pomůže sledování právě tohoto seznamu na stránce Home. Pokud chce sledovat dění ve více frontách, pak je lepší sestavit si příslušná kritéria výběru a sledovat jen výstup vyhledávací stránky (samozřejmě si musí také zvolit jeho pravidelné občerstvování).

5.2.3   Práce se záložkami

Často pracně sestrojený vyhledávací dotaz do databáze RT se hodí mít uložen v záložce (někdy označované jako bookmarks nebo oblíbené). Vyhledávací stránka (viz výše) umožňuje vytvořit pomocí funkce Bookmarkable URL for this search odkaz, kterým lze příště zinicializovat kritéria vyhledávání. K jejich použití je důležité poznamenat, že před použitím záložky je vhodné se autentizovat k WWW rozhraní. V opačném případě se sice také objeví výzva k autentizaci, ale po ní je třeba vyvolat záložku opětovně a teprve pak provést operaci aktualizace stránky (reload), což je zbytečná komplikace.

5.2.4   Vazby mezi požadavky

Vazby jsou velkým pomocníkem při prohlížení historie vývoje složitějších požadavků. Typicky těch, které požadují řešení nějakého problému, neboť zpětně lze odkázat na vzorové řešení nebo na další související problémy. Jejich jednoduché použití je opět popsáno ve výše uvedených dokumentacích.

5.3   Správce fronty

Základní obecné znalosti získá správce front nejlépe z dokumentu WebRT Manual - Administration.doc dostupného na WWW. Zde jsou uvedeny jen nezbytné specifické informace. Úlohy správců front dle důležitosti:

  1. Dohled na řešení požadavků
  2. Správa manipulátorů fronty
  3. Správa klíčových slov

5.3.1   Dohled na řešení požadavků

Tato úloha je jen nutným provozním opatřením a k jejímu řešení nepotřebuje správce žádná speciální přístupová práva jiná než má běžný manipulátor. Spočívá ve sledování množství požadavků dané fronty, které jsou ve stavu open nebo stalled, a zároveň zda u nich probíhá nějaký vývoj řešení(přinejmenším sledováním data/času poslední aktivity manipulátorů). Vždy se najdou nějaké sporadické požadavky (například žádost o nápravu něčeho, co se později ukáže momentálně neodstranitelnou vlastností - it is not a bug, it is a feature) a bez dohledu odpovědné osoby by se stal obsah fronty nepřehledným (což není cílem systému RT). Správce fronty tyto požadavky musí buď převést do stavu vyřešen nebo prostě vynutit si jejich zpracování manipulátory příslušné fronty.

5.3.2   Správa manipulátorů fronty

Prakticky se jedná o přiřazení práv k manipulaci s požadavky dané fronty prostřednictvím prostého zařazení nového manipulátora do skupiny uživatelů, jejíž jméno odpovídá názvu fronty. Práva k úpravám požadavků má pro zjednodušení celá skupina, takže není nutné složitě každému uživateli přidávat sadu jednotlivých práv. Stejným způsobem se opět jednoduše danému manipulátorovi mohou práva k úpravám požadavků dané fronty odebrat.

Příklad na WWW:
Configuration->Groups->skupina order->Members

Druhý úkon, který správce manipulátorů dané fronty (nejčastěji zároveň při přiřazení práv) provádí, je začlenění příslušného manipulátora do seznamu sledovatelů (AdminCc:) dané fronty. Administrativní korespondence (např. komentáře) se pak tomuto manipulátorovi začnou zasílat (samozřejmě jen tehdy, je-li to pro danou frontu správcem systému nakonfigurováno). Zrušení zasílání lze opět pouhým odebráním ze seznamu. Důležité je mít na paměti, že seznam AdminCc: není vázán na přístupová práva. To znamená, že dění v dané frontě mohou prostřednictvím elektronické pošty sledovat i uživatelé, kteří nemají jinak do fronty žádný přístup (forma pasivního dohledu).

Příklad na WWW:
Configuration->Queues->fronta order->Watchers

5.3.3   Správa klíčových slov

Klíčová slova jsou netriviální záležitostí (opět dobře popsanou v dokumentu WebRT Manual - Installation.doc dostupném na WWW). Každá fronta může mít přiřazeno několik výběrů klíčových slov (například Milníky vývoje, verze, oblast problému atp.) a klíčová slova jsou jejich jednotlivé hodnoty, které navíc mohou být stromově vnořené a nabývat i více hodnot (proto se vyplatí jejich konfiguraci ponechat na správci systému). Při vytváření hodnot klíčových slov je také třeba počítat s tím, že jednou vytvořené klíče se již nedají smazat (pouze blokovat jejich použití), neboť by se mohly smazat z již existujících požadavků. Ideální je tedy omezit jejich úpravy na minimum (tj. operace Edit pro blokování či změnu textu a nebo Add pro přidání nové hodnoty).

Příklad na WWW:
Configuration->Keywords->jméno fronty->jméno výběru klíčových slov->

5.4   Správce systému

Základní znalosti RT získá správce systému nejlépe z dokumentu WebRT Manual - Administration.doc dostupného na WWW. Zde jsou uvedeny jen nezbytné specifické informace.

5.4.1   Vytváření uživatelských kont

Uživatele není třeba v systému vytvářet, pouze je nutné nastavit jim odpovídající autorizační údaje (viz dále). Vytvářejí se automaticky při prvním příjmu jejich elektronické pošty (položka v záznamech o uživateli Comments about this user pak obsahuje hodnotu Autocreated on ticket submission) a při úspěšném ověření identity webovým autentizačním modulem (položka pak obsahuje hodnotu Autocreated by LDAP).

Autorizační údaje pak nastavuje již administrátor RT systému nebo příslušný pověřený uživatel podle jemu přidělených práv (konkrétně AdminQueue, AdminGroups či dokonce AdminUsers).

Nejdůležitější autorizační data jsou následující tři:

Technicky je autentizace vyřešena v apache modulu auth_ldap (a zabezpečena pomocí protokolu SSL) oproti centrálnímu LDAP serveru. Mason autohandler v RT adresáři local/WebRT/html/autohandler pak dle modulem nastavené proměnné prostředí REMOTE_USER zajistí případné založení uživatele, začlenění do skupiny auth_user i nastavení, že je to privilegovaný uživatel. Prostřednictvím externího programu ldap_search se navíc z LDAP získají další údaje o uživateli a nastaví se uživatelova elektronická poštovní adresa a jeho skutečné jméno (k případnému převodu obdržených hodnot do interní reprezentace národních znakových sad z LDAP užívaného MIME Base 64 kódování se mimo jiné používá opět volání externího programu recode).

5.4.2   Změny uživatelských kont

Úpravy autorizačních údajů mohou provádět tytéž osoby, které tyto hodnoty nastavují po založení uživatele viz předchozí odstavce. V praxi přijde vhod přidat skupině auth_user globální právo ModifySelf, které uživatelům umožní měnit si samostatně heslo a svoji signaturu.

5.4.3   Rušení uživatelských kont

Mazání uživatelů nelze rozumně zautomatizovat ani ponechat na případných správcích jednotlivých front, kteří mají jen omezená přístupová práva. Údaje o uživatelích navíc v systému pouze přibývají s každým novým žadatelem (elektronickou poštovní adresou) a v požadavcích se používá pouze odkazů na tyto údaje, takže například jen změna adresy se okamžitě projeví ve všech požadavcích atp. Vyplývá z toho, že uživateli lze tedy jen odebírat přístupová práva či jej pouze blokovat (zrušením nastavení položky uživatele Let this user access RT). Tuto operaci provádí pouze správce RT systému na základě autorizovaného požadavku (typicky od správce centrální autentizační autority).

Nejběžnější požadavek je zrušení přístupu uživatele, který již v organizaci nepracuje a ani nadále jako externista nebude spolupracovat. V tom případě je třeba projít Admin Cc: všech front (Watchers) a z nich jej odstranit (aby mu nechodila komunikace elektronickou poštou). Stejně tak je pro udržení pořádku vhodné odstranit jej ze všech skupin, jejichž je členem a následně nejdůležitější krok je zrušení nastavení položky Let this user be granted rights, případně i vymazání položky Email (což zamezí doručování odpovědí na případně existující jeho požadavky) a zrušení nastavení položky Let this user access RT.

5.4.4   Známá omezení uživatelských kont

Systém má pro každého uživatele přiřazenu jen jednu elektronickou poštovní adresu a tato je navíc klíčovou položkou, která musí být pro správnou funkci elektronického poštovního rozhraní unikátní, tj. nesmí se u více uživatelů s různým uživatelským jménem opakovat (systém zde nedělá silnou kontrolu!).

Pokud jeden uživatel hodlá se systémem pracovat pod stejnou identitou z více poštovních adres či domén, lze to vyřešit jedině naprogramováním převodu daných adres na jednu z nich pomocí funkce CanonicalizeAddress v konfiguračním souboru RT systému (v RT adresáři etc/config.pm). Nesprávné, ale částečně funkční řešení je vytvořit jinou, další, identitu uživatele s jeho další poštovní adresou a starat se dále o to, aby měla tato identita shodná práva jako původní identita s jediným rozdílem, že správci tuto nepřidají mezi pozorovatele front.

Pokud se již v systému objeví dvě různé elektronické adresy jednoho skutečného uživatele, neexistuje žádný způsob, jak vzniklé dvě identity v rámci RT spojit. Jediné řešení, je provést výše uvedenou transformaci a pokud je to nezbytné, pak u požadavků, vytvořených z nyní již transformací zastíněné adresy, změnit žadatele na výslednou jedinečnou identitu.

5.4.5   Přidání nové fronty

Při vytvoření nové fronty je ze základních údajů důležité vyplnit její označení resp. jméno, její krátký popis (Description) a je vhodné přidělit jí adresu, která se vkládá do odpovědí (Correspondence Address), a adresu pro komentáře (Comment Address). Dále je vhodné založit skupinu uživatelů se shodným jménem a této skupině dát pomocí Group Rights základní manipulační práva (typicky CommentOnTicket, CreateTicket, DeleteTicket, ModifyTicket, OwnTicket, ReplyToTicket, SeeQueue, ShowScrips, ShowTemplate, ShowTicket a ShowTicketComments ). Má-li smět kdokoli vytvářet požadavky v této frontě (jen výjimečně se požaduje omezení), pak je třeba přidat právo CreateTicket pseudoskupině Everyone. Pro akceptování další korespondence žadatele zde není nutné přidávat práva ReplyToTicket pseudoskupině Requestor, neboť toto je pro celý systém globálně nakonfigurováno. Pokud má fronta správce svých uživatelů, je třeba mu pomocí User Rights přidělit příslušná práva (typicky AdminQueue a ModifyQueueWatchers, případně AdminKeywordSelects) a má-li měnit klíčová slova, pak nezbývá než mu ještě dát globální právo AdminKeywords. Nepředpokládá se potřeba úprav vzorů zasílaných zpráv (Templates), neboť jsou definovány globálně. Důležitá je ale ještě konfigurace scrips pro danou frontu (což je téměř vždy potřeba), typickými scrips jsou

OnCorrespond NotifyAdminCcs with template AdminCorrespondence
OnCreate NotifyAdminCcs with template AdminCorrespondence
OnCorrespond NotifyRequestorsAndCcs with template Correspondence
OnComment NotifyAdminCcsAsComment with template AdminComment
, případně ještě
OnCreate AutoreplyToRequestors with template Autoreply
, pokud se má žadatel informovat o příjmu zprávy systémem. Ostatní scrips jsou definovány globálně, takže je zde není nutné vždy nastavovat (jedná se o
OnForward NotifyAdminCcsAsComment with template ForwardNotify 
OnForward Forward with template Forward 
OnQueueChange NotifyAdminCcsAsComment with template QueueChange 
OnOwnerChange NotifyOwner with template Give 
OnOwnerChange NotifyOldOwner with template Steal
). Než se začne fronta používat (a vůbec k ní budou přiřazeni manipulátoři a sledovatelé viz úkoly správce fronty) zbývá poslední krok a tím je přidání její poštovní adresy (byla-li jí udána viz výše) do konfigurace lokálního poštovního serveru (viz dřívější příklad konfigurace souboru /etc/aliases) a nezbytné provedení příkazu newaliases. Teprve nyní je fronta plně funkční (jelikož je jak vidno založení fronty netriviální záležitost, je vhodné toto ověřit) a lze případně zveřejnit její poštovní adresu.

5.4.6   Rušení nepoužívané fronty

Obdobně jako s uživateli, či klíčovými slovy, lze frontu libovolně upravovat (například měnit její jméno), ale nelze ji fyzicky smazat, přinejmenším proto, aby byly dostupné starší požadavky. Jediné korektní řešení je frontu zablokovat - na WWW rozhraní zrušením zaškrtnutí položky Enabled a případné přesměrování do ní příchozí pošty do jiné fronty či dle potřeby jinam (po úpravě souboru aliases opět nezapomenout vykonat příkaz newaliases).

5.4.7   Provádění úprav resp. upgrade

Před prováděním servisních zásahů je důležité zachovat správné pořadí zastavování jednotlivých komponent v tomto pořadí:

  1. WWW rozhraní (/etc/init.d/apache stop),
  2. poštovní rozhraní (/etc/init.d/postfix stop),
  3. vytvoření nejaktuálnější zálohy (nejlépe skriptem save_rt.sh uvedeným výše)
  4. a teprve naposled zastavení databázového stroje (/etc/init.d/mysql stop).
Důvod je jednoduchý - z WWW mohl ještě přijít na poslední chvíli požadavek a je třeba jej nechat případně dozpracovat, tj. i odeslat příslušně vytvořené zprávy. Stále ještě mohou přicházet požadavky elektronickou poštou a proto se databáze smí zastavit (totéž platí pro její případný reload) až po zastavení místního poštovního serveru. Po ukončení údržby je nutné systém startovat opět přesně v opačném pořadí, než byl zastavován. Základním předpokladem je zároveň rozumně nakonfigurovaný poštovní systém s více MX záznamy v DNS, takže během servisních zásahů se doručení elektronických zpráv pouze pozdrží.
Poznámka:
pouhé úpravy Mason komponent (nebo rozšíření o nové funkce založené čistě na Mason kódu) se projevují okamžitě, takže není potřeba zastavovat či restartovat žádný z uvedených subsystémů.

6   Budoucnost RT

Systém RT je již dlouhodobě v běžném provozním stavu, ale existuje mnoho rozšíření jeho funkcí, které donedávna nebylo možné resp. rozumné realizovat. Současně je výhledově třeba systém připravit na větší zatížení v důsledku kompletního zpracovávání současných trouble ticketů a zavedení dalších správních front s potřebou rychlé odezvy.

6.1   Fyzické oddělení databáze

V současnosti běží databáze (MySQL) na stejném stroji jako WWW server a poštovní server. Pro rozložení zátěže systému je vhodné databázi migrovat na samostatný stroj. Tento dále může zároveň sloužit jako zálohovací (a potenciálně i záložní) stroj.

6.2    Integrace s PGP, GPG obecně s PKI

Dnes se uživatelé, pracující s RT ověřují pouze ve chvíli, kdy potřebují pracovat pomocí WWW rozhraní (viz popisovaná součinnost s CAAS a LDAP).

Možné a do budoucna praktické se jeví vybavit RT systémem pro ověření identity pomocí systémů PGP nebo GnuPG. Privilegovaný uživatel, který bude komunikovat se systémem RT bude nucen svou korespondenci elektronicky podepsat a RT systém jeho požadavek přijme (bude-li tak nakonfigurována fronta) jen za předpokladu, že elektronický podpis je validní. Konkrétní řešení je zatím možné dvěma způsoby:

RT keyring
V systému RT bude uložen a spravován vlastní keyring, který bude obsahovat všechny veřejné klíče uživatelů, kteří budou RT používat. Přidávání nového uživatele bude zahrnovat proceduru výměny PGP (GnuPG) klíčů (chvalně známá z PGP autogramiád M. Sovy).
M. Sova podepisovací klíč
Namísto udržování všech klíčů se na systém RT umístí podepisovací klíč, kterým budou centrálně podepisovány klíče uživatelů využívajících RT systém. Nazvěme tuto metodu MSIE (M. Sova Interkey Exchange).

6.3   Migrace na RT 3.0

Připravovaná verze RT typu 3 má v sobě kompletně vyřešenu podporu vícejazyčných prostředí, takže v závislosti na nastavení uživatelských preferencí v jeho WWW prohlížeči může mít jeden WWW rozhraní tajvansky, druhý německy a další třeba česky. Veškerá interní reprezentace dat je v kódu UTF-8, do něhož se všechna jiná vstupní kódování převádí. UTF-8 je interně používáno jak interpretem jazyka Perl, tak i podporováno databázovým strojem a umožní tak např. korektní vyhledávaní a zobrazování údajů s diakritikou. Pro zdejší instalaci by to mělo znamenat pouhou úpravu migračního programu dat z RT2 do RT3, neboť v současné době jsou data uložena rovněž v jednotném národním kódování (iso-8859-2). RT3 nahrazuje systém klíčových slov systémem uživatelsky definovatelných položek (někdy také označováno jako metadata), takže na tomto poli bude třeba při migraci vyvinout jisté úsilí. Podobně tomu bude s místními úpravami a ve správě přístupových práv a scrips. Ta by však měla být zjednodušená takže jednorázová investice do přechodu se zúročí vzápětí (stačí si připomenout kolik operací je nutné provést při zakládání nové fronty).

6.4   Generování FAQ

RT systém může být nastaven tak, že vzorové řešení problémů se dá (například jen nastavením přepínače v odpovědi žadateli) předávat do generátoru FAQ (často kladené otázky). Řešení spočívá ve využití možnosti definovat nové typy transakcí (například popis problému - Description a řešení problému - Fix). FAQ lze pak dle potřeby jednoduše generovat jak off-line tak on-line.

7   Závěr

All stated above is indeed perfectly possible, though I am already in my pyjamas... jak řekl jeden nejmenovaný vědec, aneb realita je vždy alespoň o krůček napřed než vzniklé dokumenty, přesto se může velice hodit stávající dokumentace nazvaná RTFM na http://fsck.com/rtfm nebo WEBrt manuály v .DOC formátu na http://www.fsck.com/pub/rt/contrib/2.0/.
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz