Denne siden er arkivert, og kan inneholde utdatert, gammel eller feil informasjon.

Request Tracker

Se RequestTracker for mer generell informasjon.

Teknisk implementasjon

Mesteparten av endringene som er gjort er gjort innenfor RT selv, ved å endre på de medfølgende templatene slik at de passer våre behov bedre og får systemet til å ligne med på en mailingliste. Når det gjelder mailinterfacet, er itk@ og itk-comment@ satt opp via RTs eget script "rt-mailgate" på vanlig måte i /etc/aliases på cassarossa.

Merk at all mail til itk@ og itk-comment@ delayes fem sekunder for at evt. Bcc'er til itk-take@ og itk-resolve@ skal komme først – dette for at statusinformasjonen nederst på mailene som sendes ut skal være så riktig som mulig. (Denne delayen gjøres også i /etc/aliases.) På samme måte vil mail til itk-resolve delayes to sekunder for at ikke en evt. kopi til take@ skal gjenåpne saken etterpå (litt stygt hack, itk-take@ burde strengt tatt sjekke status først).

itk-take@ og itk-resolve@ sendes (igjen via /etc/aliases) til vårt eget Perl-script kalt "rt-itk" (som ligger sammen med rt-mailgate i /usr/share/request-tracker/bin). Dette bruker RTs egne moduler til å gjøre de nødvendige endringene i databasen, og er "stille", dvs. at den aldri sender ut svar (se TODO :-) ).

Lokale endringer i RT

Pga. en del endringer er RT-pakken satt som "hold" i dpkg på cassarossa – ideellt sett burde man fått sendt lignende endringer eller tilsvarende funksjonalitet til RT upstream. Alle endringer og lokale hacks er tydelig merket som sådan i Perl-koden. Alle filnavn det refereres til her er under /usr/share/request-tracker/lib/RT/, hvis ikke annet er spesifisert.

Endringer for å bevare fungerende tråding

Ticket.pm (rundt linje 1690, og rundt linje 1750): In-Reply-To-headeret kopieres fra innkommende mail på correspond (itk@) og comment (itk-comment@) inn i ticket, dersom headeret finnes.

Attachment.pm (rundt linje 320): In-Reply-To kopieres ut sammen med de andre headerne (det er uvisst om dette virkelig er nødvendig for riktig threading eller ikke, men det ser ikke ut til å brekke noe viktig ;-) ).

Action/SendEmail.pm (rundt linje 230): I stedet for å generere et nytt (ubrukelig) In-Reply-To-header, kopieres det ut fra ticketen hvis det eksisterer.

Andre endringer

Ticket.pm (rundt linje 1770): En sak som er resolved vil ikke gjenåpnes automatisk av en mail fra brukeren som eier saken (se over i beskrivelsen av itk-resolve@ for begrunnelse).

Action/Notify.pm (rundt linje 90): La folk få kopier av også de mailene som de selv har sendt.

Action/SendEmail.pm (rundt linje 470): Flyttet "samfundet #123"-taggen sist for å gjøre subject mer leselig.

/usr/share/request-tracker/bin/rt-mailgate (rundt linje 130): Bruk In-Reply-To-headeret for å finne ticketnummer hvis man ikke fant noe i subject (både ved å prøve å lese ticketnummeret rett ut av headeret, og deretter ved å matche mot tidligere meldinger i ticket'en hvis dette feiler).

MERK: Dette gjelder ikke endringene som skulle til for å integrere ting med ITKACL! Se under og bruk ellers grep etter "sesse/itk", de fleste stedene burde være merket.

Integrasjon mot ITKACL

Ettersom RT er et system vi bruker en del, må man selvfølgelig kunne autentisere mot det med ITKACL :-) RT er imidlertid aldri helt laget for dette, og den eneste egentlig gode måten vi har å integrere ITKACL (dvs. Kerberos-delen) mot web på er via mod_auth_itkacl (se ITKACLBruk), som man kan sette i .htaccess eller i httpd.conf et eller annet sted, men naturlig nok ikke bruke fra Perl. RTs "web external authentication"-system ville vært fint, bortsett fra at vi ønsker å beholde vanlig innlogging (mer brukervennlig login-skjerm, f.eks. ;-) ) inntil videre, så man kan ikke bruke bare det. Derfor skjer følgende når man prøver å aksessere en RT-side

RT (mer presist, autohandler) ser at brukeren ikke er logget inn (mangler sesjon). Det første som skjer er at autohandler sender tilbake en loginform (WebRT/html/Elements/Login); forskjellen fra vanlig RT er at denne har statuskode 401 (Authorization Required) og "WWW-Authenticate: Negotiate".
En browser som ikke skjønner negotiate-autentisering (altså Kerberos/ITKACL) vil tolke dette som en feil, gi opp autentiseringen (da den ikke har noen autentiseringsmetoder som serveren vil godta) og vise loginformen som en feilside, hvorpå man kan logge inn som vanlig. Ingen endring fra normal oppførsel.
En browser som derimot skjønner negotiate-autentisering (eller i det minste tror den skjønner...) vil gjenta forespørselen mot samme side, men nå med et "Authorization"-header som inneholder GSS-parametre (dvs. i praksis en Kerberos-ticket, såvidt jeg har skjønt).
autohandler ser fremdeles at brukeren ikke er logget inn, men den ser også Authorization-headeren. Derfor sender den en 302 (redirect) til /kerberosauth.html, med en URL-parameter som sier hvor den kom fra (her kunne man kanskje brukt Referer i stedet, menmen...).
kerberosauth.html er en URL som er markert spesiell for Apache – den er satt med "AuthType ITKACL" mot området /web/rt. Her skjer "vanlig" ITKACL-autentisering, med Kerberos og det hele. (Hva som skjer om autentiseringen mislykkes er beskrevet under – vi antar at autentiseringen var vellykket.)
autohandler (som kjører før kerberosauth.html, da kerberosauth.html egentlig er et HTML::Mason-fragment, som resten av RT) logger brukeren inn i RT med brukernavnet fra ITKACL (som den får fra variabelen $ENV{'REMOTE_USER'}). kerberosauth.html sender så klienten tilbake (via en ny 302-header) til siden den kom fra, og som den i utgangspunktet prøvde å aksessere.
Klienten går inn på den første siden igjen og får nå tilgang, ettersom den er logget inn.

Skjær i sjøen – hva skjer hvis autentiseringen feilet?

I prinsippet burde ikke autentiseringen feile – folk som faktisk har en Kerberos-ticket på Samfundet og prøver å bruke RT burde i utgangspunktet også ha tilgang til RT. Imidlertid er det ikke så lett; IE6 prøver f.eks. villig vekk å autentisere folk uten noen tickets, og det går ikke alltid like bra (se "pitfalls" under Kerberos).

I utgangspunktet burde dette være greit; man har et ErrorDocument 401 som har en Refresh (kan ikke bruke Location, ettersom den bare skal trigges dersom dokumentet faktisk ble vist, dvs. klienten har gitt opp autentiseringen). Imidlertid blir vi her bitt i leggen av en relativt obskur bug i IE6 – dersom den tror den kan autentisere seg med negotiate-autentisering (hvilket den fortsatt tror, selv om den fikk 401) klarer den ikke å sende en eneste liten byte i POST-formen til RT, og får derfor heller ikke logget seg inn på den måten. Derfor sender vi ingen Refresh, men heller en forklarende webside (/nokerberosauth.html) som forklarer hva som må gjøres for å skru av Kerberos i IE6 dersom den ikke fungerer. Hurra for Microsoft... ;-)

TODO – følgende er ting man burde få sett på:

Få itk-take@ og itk-resolve@ til å sende mail tilbake til brukeren ved feil. (Noe av problemet er at RT ikke ser ut til å ha en enkel funksjon for å finne ut hva slags returstrenger som angir feil og hvilke som angir suksess, men man kan alltids f.eks. regexp-matche på dette.)
Av ukjent grunn vises "In-Reply-To" dobbelt på web. Det funker på mail som sendes ut, så det er ukjent om det faktisk er slik i databasen eller om det er en kosmetisk frontend-feil. :-)
Attachments sendt på mail vil ikke gå videre ut. Man burde evt. implementere dette og samtidig filtrere ut text/html-attachments, evt. blokkere mail som kun har text/html-del. (Oppdatering: Man får i hvert fall med en saklig URL på attachments til mail nå... :-) )
Webinterfacet lager ikke In-Reply-To-headere. Man har ikke undersøkt hvor mye arbeid det evt. ville bli å implementere dette.

Lenker: Start, gammel dokumentasjon