This is what I am getting from stunnel when it starts:
2005.06.09 16:14:36 LOG5[1409:1]: stunnel 4.08 on hppa2.0w-hp-hpux11.11 PTHREAD+POLL+IPv4 with OpenSSL 0.9.7e 25 Oct 2004 2005.06.09 16:14:37 LOG4[1409:1]: PRNG may not have been seeded with enough random bytes 2005.06.09 16:14:37 LOG5[1409:1]: 27 clients allowed 2005.06.09 16:14:37 LOG5[1410:2]: 5140 connected from 127.0.0.1:49153 2005.06.09 16:14:37 LOG3[1410:2]: SSL_connect: Peer suddenly disconnected 2005.06.09 16:14:47 LOG5[1410:3]: 5140 connected from 127.0.0.1:49156 2005.06.09 16:14:47 LOG3[1410:3]: SSL_connect: Peer suddenly disconnected
If I restart stunnel it establishes the connection fine, and does not receive the PRNG error. What can I do to generate enough random bytes to get this running properly, without starting stunnel later in the boot process?
-----Original Message----- From: Stephen Tanner Sent: Tuesday, June 07, 2005 8:36 AM To: 'Jan Meijer' Subject: RE: [stunnel-users] stunnel on HP-UX
Negative, the private key is not protected with a passphrase. If I use the startup script to start stunnel and syslog-ng manually, everything works. But on boot stunnel does not seem to properly establish a connection, and I must stop it and restart it to resolve the issue.
Stephen
-----Original Message----- From: Jan Meijer [mailto:jan.meijer@surfnet.nl] Sent: Tuesday, June 07, 2005 3:08 AM To: Stephen Tanner Cc: stunnel-users@mirt.net Subject: Re: [stunnel-users] stunnel on HP-UX
On Tue, 31 May 2005, Stephen Tanner wrote:
I'm running stunnel on a HP-UX 11.11 system so that I can securely transfer logs with syslog-ng. I have stunnel and syslog-ng both starting in rc2.d at S537. Every time I have rebooted the server I
get
a broken pipe as if stunnel is having an issue establishing a tunnel, and I am forced to restart stunnel and syslog-ng. Are there any specific daemons that need to be running before stunnel starts? I'm trying to avoid having this start too late, so that I don't miss logs
on
some daemons.
There are no specific daemons that need to run. Network is practical for DNS resolving if that's needed. To rule out the obvious: you would not have protected your stunnel private key with a passphrase would you?
Jan