Questions about installation from source

John F. Morse inn at
Fri Jun 29 15:55:38 UTC 2012

Matija Nalis wrote:
> 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?

I do not know. Russ said so, then when I tried to connect to port 563 on a 
stock Debian server, I was refused.

There are references in the installation procedures which state compiling with 
SSL/TLS is required, and that is what I did for this reader server.

Additional discussion in n.s.nntp also indicates this compiling requirement.

>> 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
> related).
> For example, if your client IP is and it does NOT resolve
> back to name (check on your server side with 'host' or
> 'dig -x' -- using whatever your client IP is, of course).

No problems found in DNS here, including reverse DNS. I do run my own Bind9 

I do have some reverse lookups failing with one or two users who use AT&T or 
one of their associated FQDNs (all are DSL/ADSL). That is a problem with Ma 
Bell, and nobody on Earth is powerful enough to get them to correct their errors.

It might be one of them who is establishing a connection at the same time I am 
connecting, and causing me to wait.

I'll have to study it in detail. It is not a big problem needing immediate 

> 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.)

This occasional delay is rarely experienced when I haven't been trying to 
connect for many hours, like following a period of sleep. IOW, the connection 
is fast, but the delay can come during an active time of my usage.

The minor problem has no real reliability of repetition, therefore it is 
difficult to isolate.

Another problem is the occasional failure of Thunderbird to accept a 
self-signed certificate. There is a possibility that Thunderbird is the 
problem, and I do not remember the delay occurring with other newsreaders, or 
connections through Stunnel.

> 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).

I certainly could do that, but I prefer the FQDN in the log and Daily Report.

Besides, I do not know it the problem is really affecting other users, or just 
me, possibly due to Thunderbird and the occasional self-signed CA nag.

I have one non-technical user who has given up because their SeaMonkey client 
seems impossible to configure to accept self-signed certificates.

> 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
> domain)

I suppose I could hard-code the client IP into the server's /etc/hosts and see 
if that does anything. I doubt that DNS is my problem though, but do know that 
Mozilla has gone downhill with their SSL/TLS certificate support, amongst 
other things.

Thanks for your ideas, Matija, and have a nice weekend.


More information about the inn-workers mailing list