Ich habe Request Tracker (RT) in meinem Büro installiert und es hat bis heute gut funktioniert. Plötzlich akzeptierte es keine Ticketanfragen mehr per E-Mail und es gab keine unzustellbare E-Mail oder einen Fehler, der dem Benutzer/Anforderer angezeigt wurde. So habe ich das Problem behoben:Als Erstes habe ich überprüft, ob die E-Mail-Anfrage den RT-Rechner (vom Mailserver) erreicht hat und tatsächlich einwandfrei funktionierte. Aber dann wurde das Ticket einfach nicht erstellt und glücklicherweise die /var/log/maillog hatte die folgende Fehlermeldung und sie wurde beim Erstellen des Tickets mit rt-mailgate erfasst Perl-Skript.
Jun 10 17:03:50 support sendmail[1953]: t5ABXovT001952: to="|/opt/rt3/bin/rt-mailgate --queue default --action correspond --url http://rt.techglimpse.com/", ctladdr=<[email protected]> (8/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=34931, dsn=4.0.0, stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL
Um einen detaillierten Fehler zu erhalten, habe ich –debug verwendet Option für rt-mailgate Skript wie unten gezeigt:
/opt/rt3/bin/rt-mailgate --queue default --action correspond --url https://rt.techglimpse.com:443/ --debug < test
Hinweis:„test“ ist eine Beispieldatei mit einem Beispieltext/einer Beispielnachricht.
und hier ist der erhaltene Fehler:
500 Can't connect to rt.techglimpse.com:443 (certificate verify failed) /opt/rt3/bin/rt-mailgate: undefined server error
Aus dieser Fehlermeldung lässt sich schließen, dass das für die RT-Instanz verwendete SSL-Zertifikat diesen Fehler ausgelöst hat. In Bezug auf das SSL-Zertifikat müssen zwei Dinge überprüft werden.
1. Bestätigen Sie das von der RT-Instanz verwendete SSL-Zertifikat:
openssl verify /etc/httpd/conf/ssl.crt/rt.techglimpse.com.crt
Der obige Befehl hat den Status „OK“ zurückgegeben. Überraschenderweise gab es beim Zugriff auf RT über https über einen Webbrowser keine Probleme (aber es funktionierte nicht in der Befehlszeile). Um mir klar zu machen, dass die Funktionen einiger Perl-Module nicht kaputt sind, habe ich einfach die folgenden Perl-Module über cpan aktualisiert:
LWP::UserAgent, Crypt::SSLeay, LWP::Protocol::https HTTP::Cookies
Aber immer noch war das ursprüngliche Problem noch nicht gelöst. Nachdem ich eine Stunde gegoogelt habe, bin ich auf einen Patch für rt-mailgate gestoßen, um die SSL-Verifizierung auf POSIX zu korrigieren – entweder durch Setzen der Umgebungsvariable PERL_LWP_SSL_VERIFY_HOSTNAMES oder weisen Sie den User-Agent an, die Überprüfung von Hostnamen und SSL zu ignorieren, indem Sie Optionen wie unten gezeigt verwenden. Suchen Sie dazu einfach in /opt/rt3/bin/rt-mailgate nach der folgenden Zeile
my $ua = new LWP::UserAgent;
Fügen Sie die folgende Zeile hinzu, die dem User-Agent Ihren ROOT-CA-Pfad mitteilt:
$ua->ssl_opts( verify_hostnames => 0 );
Warnung: Beachten Sie hier einfach, dass das obige Verfahren eine Schwachstelle öffnet. Es funktioniert, da die Verwendung des Zertifikats ignoriert wird, aber der Server ist möglicherweise anfällig für MITM-Angriffe.
2. SSL-Zertifikatsvertrauen bestätigen, das die RT-Instanz verwendet?
In meinem Fall habe ich ein selbstsigniertes Zertifikat verwendet und (ich hatte kein ROOT-CA-Zertifikat erstellt oder kann möglicherweise keins nachverfolgen), dem nicht vertraut wurde! Wenn Sie dennoch selbstsignierte Zertifikate verwenden möchten, können Sie unter Erstellen Ihrer eigenen SSL-Zertifizierungsstelle (und Dumping von selbstsignierten Zertifikaten) befolgen, um ROOT-CA- und selbstsignierte Zertifikate zu erstellen. Kopieren Sie ROOT CA an den Speicherort /etc/pki/CA/certs . Wenn dieser Speicherort nicht vorhanden ist, müssen Sie ca-certificates-2010.63-3.el6_1.5.noarch installieren RPM-Paket.
Schließlich konnte ich rt-mailgate ausführen erfolgreich. Wenn sich Ihre ROOT-CA nicht am Standardort befindet, können Sie sie in rt-mailgate angeben wie im Blogbeitrag von brain vorgeschlagen. Suchen Sie die folgende Zeile in /opt/rt3/bin/rt-mailgate
my $ua = new LWP::UserAgent;
Fügen Sie die folgende Zeile hinzu, die dem User-Agent Ihren ROOT-CA-Pfad mitteilt.
$ua->ssl_opts( SSL_ca_file => '/path/to/root.crt' );
Hinweis: Denken Sie daran, in der obigen Zeile den korrekten Pfad der ROOT-CA anzugeben.
Das ist es! Ich hoffe, meine Erfahrung könnte jemandem da draußen helfen.