Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
On Wed, Aug 06, 2014 at 09:44:40PM +, Richards, Matthew E ERDC-RDE-CERL-IL wrote: If you're going to the localhost, I'm not actually sure why you're involving SSL, but that's a separate issue. Actually, that was the issue. You're right, there's no need to use SSL with localhost. We have a rewrite from 80 to 443 for all interfaces and it always forces us to use https. I guess we could have created a non-SSL site just for localhost. The DoD has its own root CA that we added in a ca_file, but I think it's very slow and was causing the timeouts. I changed the rt-mailgate get_useragent to $ua- ssl_opts(SSL_verify_mode = 'SSL_VERIFY_NONE'); and that solved the issue. It's a temporary fix until we create a locahost:80 binding. I don't like maintaining custom source. Thanks for all the help. If you don't want to verify, why not just use the flag? $ ./bin/rt-mailgate --help | grep verify --ca-file or --no-verify-ssl, below. authority that should be used to verify the website's SSL certificate. preferentially use this option over --no-verify-ssl, as it will --no-verify-ssl -kevin pgpEGC686EGKR.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
On Mon, Aug 04, 2014 at 08:29:02PM +, Richards, Matthew E ERDC-RDE-CERL-IL wrote: 443 is listening on localhost. As you suggested, we tried curl from the localhost with both the FQDN and localhost URLs. We had limited success (without any message content), but it still fails with rt- mailgate. I suspect we need some content to test it further with curl. Do you have a sample curl command line with post params for testing? Just run rt-mailgate by hand, handing it a correctly formatted message and the --debug setting. If it works sporadically, you have some serious problem with your webserver config. If you're going to the localhost, I'm not actually sure why you're involving SSL, but that's a separate issue. -kevin pgpY5fR35cHTa.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
If you're going to the localhost, I'm not actually sure why you're involving SSL, but that's a separate issue. Actually, that was the issue. You're right, there's no need to use SSL with localhost. We have a rewrite from 80 to 443 for all interfaces and it always forces us to use https. I guess we could have created a non-SSL site just for localhost. The DoD has its own root CA that we added in a ca_file, but I think it's very slow and was causing the timeouts. I changed the rt-mailgate get_useragent to $ua-ssl_opts(SSL_verify_mode = 'SSL_VERIFY_NONE'); and that solved the issue. It's a temporary fix until we create a locahost:80 binding. I don't like maintaining custom source. Thanks for all the help. Matt -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
On Thu, Jul 31, 2014 at 09:03:16PM +, Richards, Matthew E ERDC-RDE-CERL-IL wrote: I increased the timeout from 180 to 750 added extra debugging to the code to get more information. I replaced our URL with localhost for security: Are you actually listening with SSL on localhost? Is your webserver configured to listen and allow that through to RT? see an entry in the access.log. Fiddler gives us the same error (504 - Gateway Timeout Error). If I execute consecutive posts very quickly in Fiddler, after about seven 504 errors, I finally get a string of 200 (success) responses and some entries in the rt.log file to indicate it couldn’t find a valid user (because I didn’t supply one). If I let it set for a minute, I get the 504 errors again. Is fiddler running on the machine connecting to localhost or somewhere else? It's a much more relevant test to use something like curl to connect to localhost with the same arguments as rt-mailgate. rt-mailgate isn't doing anything complicated, and if RT isn't logging anything in debug mode, then normally this means your webserver is bound only to the external hostname. -kevin pgpSxy8xFKVHk.pgp Description: PGP signature -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] RT-Mailgate timeout error after upgrade to 4.2.6
Hi Kevin, Thank you for the reply. Are you actually listening with SSL on localhost? Is your webserver configured to listen and allow that through to RT? 443 is listening on localhost. As you suggested, we tried curl from the localhost with both the FQDN and localhost URLs. We had limited success (without any message content), but it still fails with rt-mailgate. I suspect we need some content to test it further with curl. Do you have a sample curl command line with post params for testing? user@rt:~$ curl -I https://rt.fully.qualified.domain.name/REST/1.0/NoAuth/mail-gateway HTTP/1.1 200 OK Date: Mon, 04 Aug 2014 17:09:29 GMT Server: Apache/2.4.7 (Ubuntu) X-Frame-Options: DENY Vary: Accept-Encoding Content-Type: text/plain; charset=utf-8 user@rt:~$ curl -I https://localhost/REST/1.0/NoAuth/mail-gateway HTTP/1.1 200 OK Date: Mon, 04 Aug 2014 17:10:29 GMT Server: Apache/2.4.7 (Ubuntu) X-Frame-Options: DENY Vary: Accept-Encoding Content-Type: text/plain; charset=utf-8 Running rt-mailgate with fetchmail: 2 messages for RTUSER at hostmaster.fully.qualified.domain.name (36925 octets). fetchmail: POP3 LIST 1 fetchmail: POP3 +OK 1 34826 fetchmail: POP3 TOP 1 fetchmail: POP3 +OK reading message rtu...@hostmaster.fully.qualified.domain.name:1 of 2 (34826 octets) #**.***..*.*.*.*.*.*.*.**.*.*.*.*.*.*.*.**.*.*.*.*.*.*.*.**.*.*.*.*.*.*.**.*.*.*.*.*/opt/rt4/bin/rt-mailgate: temp file is '/tmp/63WuokOupY/OIpKtEaLCc' /opt/rt4/bin/rt-mailgate: connecting to https://rt.fully.qualified.domain.name /REST/1.0/NoAuth/mail-gateway HTTP request failed: 500 Can't connect to rt.fully.qualified.domain.name:443. Your webserver logs may have more information or there may be a network problem. /opt/rt4/bin/rt-mailgate: undefined server error fetchmail: MDA returned nonzero status 75 not flushed fetchmail: POP3 LIST 2 fetchmail: POP3 +OK 2 2099 fetchmail: POP3 TOP 2 fetchmail: POP3 +OK Again, when we added some additional debugging messages and the actual error is: LWP::Protocol::https::Socket: Timeout at /usr/share/perl5/LWP/Protocol/http.pm line 41. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
