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
adead
. 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
- 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)
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_PATHPoznámka:/opt/rt2
RT_LOG_PATH/tmp
DB_TYPEmysql
DB_HOME/usr
DB_DBAroot
DB_DBA_PASSWORD :heslo správce mysql databáze: DB_RT_HOSTlocalhost
DB_DATABASErt2
DB_PORT DB_HOSTlocalhost
DB_RT_USERrt_user
DB_RT_PASS :heslo uživatele rt_user: WEB_USERwww-data
WEB_GROUPwww-data
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:
- sledování jím obsluhovaných front na WWW (popsáno v dalších odstavcích)
- obdržení elektronické zprávy s korespondencí od uživatele
- obdržení elektronické zprávy s informací, že mu byl daný požadavek přidělen
- obdržení elektronické zprávy s historií vývoje požadavku, pokud byl daný požadavek přesunut z jiné do jím obsluhované fronty
- ostatní formy jsou již individuální jako třeba obdržení komentáře od jiného manipulátora, ústní nařízení vedoucím pracovníkem atp.
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:
- Dohled na řešení požadavků
- Správa manipulátorů fronty
- 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:
- nastavení položky Let this user be granted rights v záznamech o uživateli (někdy se takový uživatel označuje jako privilegovaný)
- začlenění do seznamu resp. seznamů Administrative Cc: dané fronty resp. daných front (pozn. nepřesné, ale používané označení těchto seznamů je Queues Watchers)
- začlenění uživatele do skupiny názvem odpovídající názvu front, v nichž má
mít práva odpovídající uživatelům typu Admin Cc: (dříve označováno
Manipulators); má-li mít uživatel automaticky přístup ke všem
požadavkům (Nerovná se mít Admin Cc: práva!), pak rovněž musí
být členem formální skupiny
auth_user
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í:
- WWW rozhraní (/etc/init.d/apache stop),
- poštovní rozhraní (/etc/init.d/postfix stop),
- vytvoření nejaktuálnější zálohy (nejlépe skriptem save_rt.sh uvedeným výše)
- a teprve naposled zastavení databázového stroje (/etc/init.d/mysql stop).
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.