Instalé Request Tracker (RT) en mi oficina y funcionaba bien hasta hoy. De repente, dejó de aceptar solicitudes de tickets por correo y no se mostró ningún correo devuelto ni un error al usuario/solicitante. Así es como depuré el problema:lo primero que hice fue verificar si la solicitud de correo estaba llegando a la máquina RT (desde el servidor de correo) y, de hecho, funcionaba bien. Pero luego, el ticket simplemente no se creó y, afortunadamente, el /var/log/maillog tenía el siguiente mensaje de error y se capturó al crear el ticket con rt-mailgate secuencia de comandos perl.
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
Para obtener un error detallado, utilicé –debug opción para rt-mailgate secuencia de comandos como se muestra a continuación:
/opt/rt3/bin/rt-mailgate --queue default --action correspond --url https://rt.techglimpse.com:443/ --debug < test
Nota:"prueba" es un archivo de muestra con un texto/mensaje de muestra.
y aquí está el error obtenido:
500 Can't connect to rt.techglimpse.com:443 (certificate verify failed) /opt/rt3/bin/rt-mailgate: undefined server error
Con este mensaje de error, la inferencia es que el certificado SSL utilizado para la instancia RT ha activado este error. Hay dos cosas que verificar con respecto al certificado SSL.
openssl verify /etc/httpd/conf/ssl.crt/rt.techglimpse.com.crt
El comando anterior devolvió el estado "OK". Sorprendentemente, cuando se accede a RT a través de https a través del navegador web, no tuvo ningún problema (pero no funcionó en la línea de comando). Para dejar claro que las funciones de algunos módulos de Perl no están rotas, solo actualicé los siguientes módulos de Perl a través de cpan:
LWP::UserAgent, Crypt::SSLeay, LWP::Protocol::https HTTP::Cookies
Pero aún así, el problema original aún no se resolvió. Después de buscar en Google durante una hora, encontré un parche para rt-mailgate, para corregir la verificación SSL en POSIX, ya sea configurando la variable de entorno PERL_LWP_SSL_VERIFY_HOSTNAMES o dígale al agente de usuario que ignore la verificación de los nombres de host y las opciones de uso de SSL como se muestra a continuación. Para hacer eso, simplemente busque la línea a continuación en /opt/rt3/bin/rt-mailgate
my $ua = new LWP::UserAgent;
Agregue la siguiente línea que le informa al agente de usuario sobre su ruta de CA ROOT:
$ua->ssl_opts( verify_hostnames => 0 );
Advertencia: Solo tome nota aquí, ya que el procedimiento anterior abrirá una vulnerabilidad. Funcionará, ya que se ignora el uso del certificado, pero el servidor podría ser vulnerable a un ataque MITM.
En mi caso, usé un certificado autofirmado y (no había creado ningún certificado ROOT CA o puede que no pueda rastrear uno) ¡no era de confianza! Si aún desea usar certificados autofirmados, puede seguir Creación de su propia autoridad de certificación SSL (y volcado de certificados autofirmados) para crear certificados autofirmados y CA ROOT. Copie la CA RAÍZ en la ubicación /etc/pki/CA/certs . Si esta ubicación no está presente, debe instalar ca-certificates-2010.63-3.el6_1.5.noarch Paquete RPM.
Finalmente, pude ejecutar rt-mailgate exitosamente. Si su CA RAÍZ no está en la ubicación estándar, puede especificarla en rt-mailgate como lo sugiere la publicación del blog de Brain. Busque la siguiente línea en /opt/rt3/bin/rt-mailgate
my $ua = new LWP::UserAgent;
Agregue la siguiente línea que le informa al agente de usuario sobre su ruta de CA ROOT.
$ua->ssl_opts( SSL_ca_file => '/path/to/root.crt' );
¡Eso es todo! Espero que mi experiencia pueda ayudar a alguien.