Ho installato Request Tracker (RT) nel mio ufficio e funzionava bene fino ad oggi. Improvvisamente, ha smesso di accettare richieste di biglietti tramite Mail e non si è verificato alcun messaggio di rimbalzo o un errore mostrato all'utente/richiedente. Ecco come ho debugizzato il problema:la prima cosa che ho fatto è stata verificare se la richiesta di posta stava raggiungendo la macchina RT (dal server di posta) e funzionava davvero bene. Ma poi, il ticket semplicemente non veniva creato e fortunatamente il /var/log/maillog aveva il seguente messaggio di errore ed è stato acquisito durante la creazione del ticket con rt-mailgate perl script.
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
Per ottenere un errore dettagliato, ho usato –debug opzione per rt-mailgate script come mostrato di seguito:
/opt/rt3/bin/rt-mailgate --queue default --action correspond --url https://rt.techglimpse.com:443/ --debug < test
Nota:"test" è un file di esempio con un testo/messaggio di esempio.
ed ecco l'errore ottenuto :
500 Can't connect to rt.techglimpse.com:443 (certificate verify failed) /opt/rt3/bin/rt-mailgate: undefined server error
Con questo messaggio di errore, si deduce che il certificato SSL utilizzato per l'istanza RT ha attivato questo errore. Ci sono due cose da verificare riguardo al certificato SSL.
openssl verify /etc/httpd/conf/ssl.crt/rt.techglimpse.com.crt
Il comando precedente ha restituito lo stato "OK". Sorprendentemente, quando RT è accessibile tramite https tramite browser web, non ha avuto alcun problema (ma non ha funzionato nella riga di comando). Per chiarire che le funzioni di alcuni moduli perl non sono interrotte, ho appena aggiornato i moduli perl sotto tramite cpan:
LWP::UserAgent, Crypt::SSLeay, LWP::Protocol::https HTTP::Cookies
Ma ancora il problema originale non è stato ancora risolto. Dopo aver cercato su Google per un'ora, ho trovato una patch per rt-mailgate, per correggere la verifica SSL su POSIX, o impostando la variabile di ambiente PERL_LWP_SSL_VERIFY_HOSTNAMES oppure chiedi allo user-agent di ignorare la verifica dei nomi host e dell'SSL utilizzando le opzioni come mostrato di seguito. Per farlo, cerca la riga sottostante in /opt/rt3/bin/rt-mailgate
my $ua = new LWP::UserAgent;
Aggiungi la riga sottostante che informa lo user-agent del percorso della CA ROOT:
$ua->ssl_opts( verify_hostnames => 0 );
Avviso : Prendi nota qui, poiché la procedura di cui sopra aprirà una vulnerabilità. Funzionerà, poiché l'utilizzo del certificato viene ignorato, ma il server potrebbe essere vulnerabile all'attacco MITM.
Nel mio caso, ho utilizzato un certificato autofirmato e (non avevo creato alcun certificato CA ROOT o potrei non essere in grado di rintracciarne uno) che non era attendibile! Se desideri comunque utilizzare i certificati autofirmati, puoi seguire Creazione della tua autorità di certificazione SSL (e Dumping di certificati autofirmati) per creare CA ROOT e certificati autofirmati. Copia la CA ROOT nella posizione /etc/pki/CA/certs . Se questa posizione non è presente, devi installare ca-certificates-2010.63-3.el6_1.5.noarch Pacchetto RPM.
Alla fine, sono stato in grado di eseguire rt-mailgate con successo. Se la tua CA ROOT non si trova nella posizione standard, puoi specificarla in rt-mailgate come suggerito dal post sul blog di Brain. Trova la riga seguente in /opt/rt3/bin/rt-mailgate
my $ua = new LWP::UserAgent;
Aggiungi la riga sottostante che informa lo user-agent del percorso della CA ROOT.
$ua->ssl_opts( SSL_ca_file => '/path/to/root.crt' );
Nota: Ricordarsi di impostare il percorso corretto della CA ROOT nella riga sopra.
Questo è tutto! Spero che la mia esperienza possa aiutare qualcuno là fuori.