Questions about installation from source
mnalis-ml at voyager.hr
Fri Jun 29 09:01:41 UTC 2012
On Sat, Jun 16, 2012 at 02:36:22PM -0500, John F. Morse wrote:
> My INN 2.5.2 reader server on Debian Squeeze was compiled for SSL/TLS support.
> Is that still a requirement (because the Debian APT package does not support TLS)?
AFAICT, standard Debian Squeeze inn2 package normally supports TLS?
> In use, I find an occasional delay when connecting, sometimes as
> long as five seconds. Once the initial connection is made, later
> connections are immediate. I see nothing in the log other than what
> I would expect. It is just slow if I haven't connected in some time.
This sound suspiociosly like reverse DNS problem (and not TLS
For example, if your client IP is 192.0.2.42 and it does NOT resolve
back to name (check on your server side with 'host 192.0.2.42' or
'dig -x 192.0.2.42' -- using whatever your client IP is, of course).
It will create exactly such delay on first access (unless it is
cached already, of course!) until it fails to get a response, and
then the negative DNS reply will be cached for some time, resulting
is subseqent accesses to be fast. (the same issue arises if your DNS
reverse resolving works, but is slow for some reason, like some of
DNS servers being down, or big chain of DNS CNAME linking etc.)
On my servers I'm running nnrpd(8) separetely from innd(8), and have
solved such problems by running nnrpd with "-n" option (to turn off
resolution of IP addresses to names).
Note: side effect of that fix is different innreport look
(domain-name based part of report couldn't group hosts by domain, as
it doesn't know the domain anymore). On the positive side, it fixes
all such DNS-based problems.
Or you could fix reverse DNS for your client that it resolves (faster
or at all), and/or increase DNS cache buffers and/or DNS TTL so it
remains cached longer... (but that would fix it only for that one
Opinions above are GNU-copylefted.
More information about the inn-workers