Bugzilla und email_in.pl
Diesen Beitrag schrieb ich 18 Jahre und 11 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Und hier mal im Schweinsgalopp eine Anleitung, wie man den dämlichen fantastischen Bugzilla dazu bringt, Tickets per Mail anzunehmen.
- Die Installation liegt in
/usr/share/bugzillaund funktioniert über Webinterface. - Der verwendete Mailserver ist ein
sendmail.
Zuständig ist ein Perl-Script: /usr/share/bugzilla/email_in.pl. Als ersten Schritt prüfen wir, ob das Teil per Konsole funktioniert. Dazu legen wir eine Datei /tmp/blamail an mit einem Inhalt, der folgendem ähnlich ist – natürlich in Abhängigkeit von eurer Konfiguration:
From: EinRegistrierterBugzillaUser@domain.tld
Subject: Ein aussagekräftiges Subject
@product = DieProduktgruppe
@component = Testqueue
@version = 1.0
@op_sys = WasWeissIch
@rep_platform = KeineAhnungLasstEuchWasEinfallen
Wer andern eine Grube gräbt
hat meist ein Gruben-Grab-Gerät!
--
Die Signatur wird durch diese zwei Striche abgetrennt und erscheint nicht im Ticket
Dieses Muster-Ticket füttern wir nun dem Script ein:
$ cd /usr/share/bugzilla
$ perl email_in.pl -vvv < /tmp/blamail
Funktioniert? Okay – dann weiter. Damit das im sendmail auch tut, muss ein Symlink nach /etc/smrsh (und natürlich muss der sendmail smrsh überhaupt kennen! (FEATURE(smrsh’, /usr/sbin/smrsh')dnl)); also jetzt so:
$ cd /etc/smrsh
$ ln -s /usr/share/bugzilla/email_in.pl
$ perl email_in.pl -vvv < /tmp/blamail
Der Ordner, in den der Link gehört, ist abhängig vom verwendeten System, vom verwendeten Paket etc. – um herauszufinden, wohin der Link gehört, ruft ihr das hier auf:
$ strings /path/to/smrsh | grep ^/
Bei mir liegt das Binary in /usr/sbin. Kann gut sein, dass ihr nun erst einmal mit Fehlermeldungen zugebombt werdet, irgendwas in dieser Art hier:
Can't locate Bugzilla.pm in @INC (@INC contains: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.7/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /etc/smrsh/email_in.pl line 40.
BEGIN failed--compilation aborted at /etc/smrsh/email_in.pl line 40.
Das kommt daher, dass das Ding eigentlich nur aus seinem eigenen Ordner heraus aufgerufen werden will. Wenn man das Script ein wenig stutzt, ist das aber zu schaffen: einfach eine Zeile einfügen (nach dem use strict):
use lib "/usr/share/bugzilla";
Wenn ihr den Aufruf perl /etc/smrsh/email\_in.pl -vvv < /tmp/blamail nun erneut versucht – funktioniert es nun? Okay – dann weiter. In den aliases muss nun eine E-Mail-Adresse hinzugefügt werden, ungefähr sowas hier:
bugzilla: "|/etc/smrsh/email_in.pl -vvv"
Anschließend das newaliases nicht vergessen! Nun könnt ihr mal versuchen, eine Mail an bugzilla@domain.tld zu schicken. Geht alles gut: prima, dann sind wir fertig!
Blöd allerdings, wenn Ihr eine ähnliche Meldung wie diese bekommt:
The original message was received at Thu, 22 Nov 2007 10:23:40 GMT
from blabla [192.168.0.1]
----- The following addresses had permanent fatal errors -----
"|/etc/smrsh/email_in.pl -vvv"
(reason: Service unavailable)
(expanded from: <bugzilla@domain.tld>)
----- Transcript of session follows -----
smrsh: "email_in.pl" not available for sendmail programs (stat failed)
554 5.0.0 Service unavailable
Abhilfe geschafft hat hier ein chmod +s /usr/share/bugzilla/email\_in.pl; danach lautete die Fehlermeldung folgendermaßen:
The original message was received at Thu, 22 Nov 2007 10:41:58 GMT
from blabla [192.168.0.1]
----- The following addresses had permanent fatal errors -----
"|/etc/smrsh/email_in.pl -vvv"
(reason: 255)
(expanded from: <bugzilla@domain.tld>)
----- Transcript of session follows -----
Insecure dependency in chdir while running setuid at /etc/smrsh/email_in.pl line 30.
BEGIN failed--compilation aborted at /etc/smrsh/email_in.pl line 31.
554 5.3.0 unknown mailer error 255
Er versucht, in das Bugzilla-Verzeichnis zu wechseln, und aus Sicherheitsgründen wird das geblockt; ist auch unnötig, da wir ihm ja vorhin anhand des use lib-Statements gesagt haben, wo er seinen Kram findet! Abhilfe schafft es, diese Zeile 30 einfach auszukommentieren – klingt brachial, ist aber extrem wirkungsvoll.
Wenn es dumm läuft kann es sein, dass eure Tickets nun mit dieser Meldung nicht akzeptiert werden: A legal OS/Version was not set.. Soweit bin ich gerade und komme auch nicht weiter. In meiner blamail wird der Parameter ja sogar als @op_sys = Windows definiert, per Konsole tut auch alles wunderbar – bloß per Mail schafft er es angeblich nicht, das auszuwerten.
Fazit: unübersichtlich, buggy, macht keinen Spaß; ziemlich unbenutzbar für die User, da die diese ganzen ‘@’-Parameter angeben müssen. Das Frontend des Bugzilla kann man sowieso vergessen; mich verwundert der Grad der Verbreitung dieser Sache…
Update: Mein Kollege kann Tickets per Mail einstellen, bloß ich kann es nicht; kann ggf. daran liegen, dass er Windows nutzt, ich hingegen MacOS X, und dass bei ihm @op_sys automatisch richtig ausgewertet wird – als Parameter hat er es nämlich nicht angegeben – und dass es bei mir überhaupt nicht ausgewertet wird, auch nicht, wenn ich es explizit angebe. Mpf.
Hinterlasse einen Kommentar
Ich freue mich über jeden Kommentar, es sei denn, er ist blöd.
Deshalb sind die Kommentare auf dieser Seite auch generell moderiert.