Corin Langosch wrote:[...]

There are some cases when pound should return 503, but there are some 
cases when it shouldn't.
Consider situation that You are working for bank, and You install pound 
as a LB. Pound get request and it try to connect to the first backand, 
but it get error(fe. internal server error), and then connect to the 
second backand and so on. In that case one operation(fe. payement) could 
be done multiple times(fe. when You get internal server error), and it 
isn't good.
In another case, where pound get connection refused it could try to 
connect to another backand(but pound doesn't do it).
So it isn't so simple as it could look.

If You have problems with pound I suggest You to switch to haproxy - 
http://haproxy.1wt.eu/. Haproxy have much
more features than pound, 
drawback is that it uses more cpu.

Best Regards
Maciej Bogucki
[...]

First place to look is your  /var/log/syslog

You could post here from when you start pound to when the timeout first
occurs.

/David


On 08/10/06, Matt Murphy <mmmurf(at)gmail.com> wrote:[...]

[...]

David --

A grep of recent syslog lines containing pound and error:

Oct  8 09:59:33 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 09:59:36 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 09:59:39 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:00:25 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:01:27 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:02:11 loadbalancer001 pound: error copy chunk cont: Connection
timed out
Oct  8 10:03:29 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:04:43 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:04:57 loadbalancer001 pound: error copy chunk cont: Connection
timed out
Oct  8 10:04:57 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:05:11 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:06:05 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:06:15 loadbalancer001 pound: error flush headers to 218.52.100.59:
Connection reset by peer
Oct  8 10:06:24 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:06:27 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:07:10 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:07:32 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:08:30 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:09:09 loadbalancer001 pound: error flush headers to 81.77.108.238:
Connection reset by peer
Oct  8 10:09:41 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:09:55 loadbalancer001 pound: error copy response body: Connection
timed out
Oct  8 10:10:21 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:11:20 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:11:24 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:11:43 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:13:00 loadbalancer001 pound: error copy chunk cont: Connection
timed out
Oct  8 10:14:40 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:14:41 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:14:47 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:15:11 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:15:12 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:15:29 loadbalancer001 pound: error copy server cont: Connection
timed out
Oct  8 10:15:31 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:15:32 loadbalancer001 pound: error copy chunk cont: Connection
reset by peer
Oct  8 10:15:34 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:15:58 loadbalancer001 pound: error copy chunk cont: Connection
timed out
Oct  8 10:15:58 loadbalancer001 pound: error copy chunk cont: Connection
timed out


and below is a segment of the log with some errors interspersed:

Oct  8 10:19:36 loadbalancer001 pound: 205.188.116.133 GET
/css/penguinmagic.css HTTP/1.1 - HTTP/1.1 304 Not Modified
Oct  8 10:19:37 loadbalancer001 pound: 24.251.227.11 GET
/discuss/viewtopic.php?t=115345 HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:38 loadbalancer001 pound: 207.200.116.12 GET
/product.php?ID=891 HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:38 loadbalancer001 pound: 24.251.227.11 GET
/discuss/templates/subSilver/images/ HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:38 loadbalancer001 pound: 64.91.26.194 GET
/browse.php?page=7&perpage=10&category=street&searchString=&tr=206
HTTP/1.1
- HTTP/1.1 200 OK
Oct  8 10:19:38 loadbalancer001 pound: 66.177.212.54 GET /blog/atom.xml
HTTP/1.1 - HTTP/1.1 304 Not Modified
Oct  8 10:19:39 loadbalancer001 pound: 64.60.208.10 HEAD / HTTP/1.0 -
HTTP/1.1 200 OK
Oct  8 10:19:39 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:19:39 loadbalancer001 pound: 205.188.116.203 GET /images/fill.gif
HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:39 loadbalancer001 pound: 66.249.66.204 GET
/discuss/profile.php?mode=viewprofile&u=124252&sid=75dbb1a5bfab28fb41101a8930aac94c
HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:40 loadbalancer001 pound: error copy server cont: Connection
reset by peer
Oct  8 10:19:40 loadbalancer001 pound: 68.142.230.186 GET
/discuss/posting.php?mode=quote&p=767742 HTTP/1.0 - HTTP/1.1 302 Found
Oct  8 10:19:41 loadbalancer001 pound: 205.188.116.201 GET
/product.php?ID=1365 HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:41 loadbalancer001 pound: 69.81.198.114 POST
/specialordercatalog.php HTTP/1.1 - HTTP/1.1 200 OK
Oct  8 10:19:41 loadbalancer001 pound: 24.15.126.99 GET
/discuss/viewforum.php?f=10008 HTTP/1.1 - HTTP/1.1 200 OK


-Matt

On 10/8/06, david walters <dwalters1(at)gmail.com> wrote:[...]

Try disabling KeepAlive in apache (KeepAlive 0)

- if that works I would search through the mailing list archives to see if
there was any other resolution/fix for this problem

http://www.apsis.ch/pound/pound_list

/David

On 08/10/06, Matt Murphy <mmmurf(at)gmail.com> wrote:[...]

[...]

Hello,

Stefan Lambrev wrote:[...][...]
>>> On Wed, 2006-10-04 at 19:19 +0300, Stefan Lambrev wrote:
>>>  
>>>> Is there any reason this configuration file to not work with
pound 
>>>> 2.1.3 and FreeBSD ?
>>>>
>>>> ListenHTTP
>>>>   Address 0.0.0.0
>>>>   Port    80
>>>> End
>>>>
>>>> Service
>>>>     BackEnd
>>>>         Address 192.168.13.4
>>>>         Port    9080
>>>>         TimeOut 300
>>>>     End
>>>> End
>>>> Alive 4
>>>> LogLevel 4
>>>>
>>>> Backend is apache 1.3.XX
>>>> but on all browsers that I check my request http://url/ is always 
>>>> rewritten to http://url:9080/
>>>> I tried all possible combinations of :
>>>>   RewriteLocation 0|1|2
>>>>   RewriteDestination 0|1
>>>> w/o any success. I'll test on linux tomorrow.
>>>> Am I missing something ?
>>>>     
>>>
>>> This is probably a result of your application doing something
funny
>>> (such as embedding absolute URLs in the web pages). It's unlikely
it 
>>> has
>>> anything to do with Pound.
>>>   [...][...]
Robert I think it's a normal behaviour mod_rewrite in apache to  "add" 
this port, because
the apache web server do not know about the balancer.
So if I have apache server running on port 9090 and then I use 
mod_rewrite it is 100%
acceptable http:/url:9090/ to be rewritten to http:/url:9090/blabla/, so 
adding additional
rewrite rule to delete this port will make web server to be unable to 
work without a balancer.
Also have in mind that when I make request to pound it is just 
http://url/ then pound
send http://url:9090/ to the backend, with
Header Location url, but the 
response from backend
is Location http://url:9090/blabla/ - so
I'm pretty sure that this 
header have to be rewritten when is passed
through balancer and pound 1.9 do this very well.

>>> In any case you should NEVER use 0.0.0.0 as a listener or a 
>>> back-end, as
>>> it completely defeats the rewriting mechanism (see the man page
for
>>> details as to the conditions for rewriting)!
>>>   [...]
[...]

On Mon, 2006-10-09 at 14:25 +0300, Stefan Lambrev wrote:[...]

That is not what happens.

A request is issued to http://xyz/abc. What this
really means in HTTP
terms:

Get /abc HTTP/1.1
...
Host: http://xyz
...

This request is sent by Pound to the back-end (on whatever port it
happens to run):

Get /abc HTTP/1.1
...
Host: http://xyz
...

Thus the URL http://xyz:9090/abc is never
created - unless you create it
yourself via the rewrite rules or inside your application.

As to the Location header: this is created by the Apache server, and
will usually include the port:

HTTP/1.1 200 /abc OK
...
Host: http://xyz
...
Location: http://qwe:9090
...

Make sure you use RewriteLocation and it will be rewritten correctly by
Pound to what it should be:

HTTP/1.1 200 /abc OK
...
Host: http://xyz
...
Location: http://xyz
...

I suggest you use a sniffer to look at the traffic between Pound and
Apache to see exactly what happens on the wire and we'll take it from
there if needed be. At the very least you should check that the
conditions for rewriting were fulfilled (especially that your Apache
address can be resolved) and that no rewriting took place.[...]

On Thu, 2006-10-05 at 09:59 +0100, Michael Parkin wrote:[...]

I admit I am very confused by what certificates you have where. Perhaps
you could try explaining it again? WHat exactly do you mean by "root"
certificate as opposed to "CA" certificate?[...]

Hi Robert,

Thanks for your email.

On 10/10/06,  Robert Segall <roseg(at)apsis.ch> wrote:[...]

Hopefully I can explain things a bit better this time for you... And I
have also found the answer...

I have two certificates, one for the client and one for server.

1) The client and server certificate are issued by the same CA.  The
CA is the only root of trust.  It is a self signed certificate and is
installed into a PEM formatted file available to both the client and
the server. Assuming OpenSSL verification indices the chain depth is
1: certificate 0 is the peer's certificate, 1 is the trusted CA.

2) I have set the CAlist parameter to point to this self-signed CA
certificate to request that the client send their certificate signed
by this CA.

3) I am not using CRLs at the moment, so the VerifyList parameter also
points to the same self-signed CA certificate -- as this is the CA I'd
like Pound to verify the client certificate against.

4) When Pound is configured like this I use 'openssl s_client' to
check what is being sent to/from the server. I have found that the
server is telling me that the client certificate is 'bad' (failing
with 'SSL Alert Number 42' as in [1]).

This configuration puzzled me and a colleague for a long time (as it's
correct) until we decided to add the CRL to the VerifyList file.
Success! The openssl s_client test worked (we also checked with curl
and telnet).

This is odd because within the client, server and CA certificates the
checking of CRLs is marked as 'not critical' - i.e. verification
should work with or without the presence of the CRL. (Indeed on Apache
the CRL is not required to perform mutual SSL authentication).

Is the presence of the CRL something that Pound mandates but is not documented?

Please can you confirm this as I'm sure this has given others a headache too!

Michael.

[1] http://support.intel.com/support/netstructure/sb/cs-009585.htm

Site: www.xscores.com (live sports scores)
Pound in production: 12 months
Errors/Issues: none
Version: 1.9 (I think... how can I tell for sure?)

Install Method: apt-get install pound

Unique IPs monthly: 800,000
Max. concurrent sessions: 16,000  (we know this from 60 second Ajax client
poll)
Backends: 5
Backend App: Tomcat
Protocols: HTTP

/proc/version
Linux version 2.6.8-3-686-smp (root(at)lart) (gcc version 3.3.5 (Debian 1:
3.3.5-13)) #1 SMP Sat Jul 15 08:52:57 UTC 2006
Hardware: Dell Poweredge, dual Xeon 3Ghz, 1Gb RAM
Max Peak Load: 1.0 - 2.0
Average Load: 0.1 - 0.5

*** Necessary System Tweaks ***
--------------------------------------------------
1. ulimit -n 16000
2. echo 65000 > /proc/sys/net/ipv4/ip_conntrack_max

David

On 11/10/06, K Kopper <karl_kopper(at)yahoo.com> wrote:[...]

Warning: This message has had one or more attachments removed
Warning: (poundstatlogger).
Warning: Please read the "Newcastle-Attachment-Warning.txt" attachment(s) for
more information.

We use it extensively here in the Medical Faculty at the University of
Newcastle.

We've got quite a few SSL hosted sites and I've settled on a separate Pound
process for each SSL/non-SSL host... eg.

loadbal  27003  0.0  0.0 15596 2964 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl6 -f /usr/local/etc/pound.ssl6.cfg
loadbal  27004  0.3  0.0 18204 3336 ?        S    Oct11   1:38
/usr/local/sbin/pound-ssl6 -f /usr/local/etc/pound.ssl6.cfg
loadbal  27007  0.0  0.0 15624 3012 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl2 -f /usr/local/etc/pound.ssl2.cfg
loadbal  27008  0.0  0.0 15624 3004 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl4 -f /usr/local/etc/pound.ssl4.cfg
loadbal  27009  0.3  0.0 21324 3676 ?        S    Oct11   1:39
/usr/local/sbin/pound-ssl2 -f /usr/local/etc/pound.ssl2.cfg
loadbal  27010  0.3  0.0 19256 3416 ?        S    Oct11   1:38
/usr/local/sbin/pound-ssl4 -f /usr/local/etc/pound.ssl4.cfg
loadbal  27015  0.0  0.0 15756 3080 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl3 -f /usr/local/etc/pound.ssl3.cfg
loadbal  27016  0.3  0.0 21436 3688 ?        S    Oct11   1:37
/usr/local/sbin/pound-ssl3 -f /usr/local/etc/pound.ssl3.cfg
loadbal  27019  0.0  0.0 15756 3076 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl1 -f /usr/local/etc/pound.ssl1.cfg
loadbal  27020  0.3  0.1 24964 4728 ?        S    Oct11   1:39
/usr/local/sbin/pound-ssl1 -f /usr/local/etc/pound.ssl1.cfg
loadbal  27023  0.0  0.0 15620 2988 ?        Ss   Oct11   0:00
/usr/local/sbin/pound-ssl5 -f /usr/local/etc/pound.ssl5.cfg
loadbal  27024  0.3  0.0 17460 3208 ?        S    Oct11   1:37
/usr/local/sbin/pound-ssl5 -f /usr/local/etc/pound.ssl5.cfg
loadbal  24985  0.3  0.8 60476 35436 ?       S    Oct10   6:15
/usr/local/sbin/pound -f /usr/local/etc/pound.cfg

No modifications, pound is compiled with OpenSSL and without DAV and syslog
support. One thing we do however is perform a scheduled restart of the pound
processes in the wee hours of the morning.

I use a couple of little shell scripts to start and stop individual pound
instances, redirect the log messages and do overnight processing of all our
pound log files into a central awstats system, sorted by hostname:

---------------------< poundstart-ssl1 >----------------
#!/bin/bash

/usr/local/sbin/pound-ssl1 \
        -f /usr/local/etc/pound-ssl1.cfg >>/var/log/pound-ssl1.log
2>>/var/log/pound-ssl1.error.log &
sleep 5
ps aux | grep pound-ssl1 | grep -v grep | awk '{print $2}' >
/var/tmp/pound-ssl1.PID
---------------------------------------------------------

---------------------< poundstop-ssl1 >------------------
#!/bin/bash

cat /var/tmp/pound-ssl1.PID | while read PID
do
        kill -9 $PID
done
---------------------------------------------------------


---------------------< poundlogzip >------------------
#!/bin/bash
#
# Simple script to tidy up pound logfiles
#

# Where stuff is....
PSTOP=/sbin/poundstop
PSTART=/sbin/poundstart
PERLOG=/var/log/pound.error.log
PLOG=/var/log/pound.log
PLOGDIR=/var/log/pound

DATE=`date +%d%m%y`

cd /var/log
for LOG in pound pound-ssl1 pound-ssl2 pound-ssl3 pound-ssl4 pound-ssl5
pound-ssl6
do
        # Move and recreate main logfile
        mv $LOG.log $PLOGDIR/$LOG.log.tmp
        touch /var/log/$LOG.log
        chown loadbal:loadbal /var/log/$LOG.log

        # Move and recreate error logfile
        mv $LOG.error.log $PLOGDIR/$LOG.error.log.tmp
        touch /var/log/$LOG.error.log
        chown loadbal:loadbal /var/log/$LOG.error.log
done

cd $PLOGDIR
/bin/ls pound*.log.tmp | grep -v error | while read LOG
do
        cat $LOG >> $PLOGDIR/pound.log.$DATE
done

cd $PLOGDIR
/bin/ls pound*error.log.tmp | while read LOG
do
        cat $LOG >> $PLOGDIR/pound.error.log.$DATE
done

# Compress the old logfiles
nice -n 19 gzip $PLOGDIR/pound.log.$DATE
nice -n 19 gzip $PLOGDIR/pound.error.log.$DATE

rm $PLOGDIR/*.log.tmp
-----------------------------------------------------------

I've also attached my pound log processing script (you'll find it in the
archives)... it should be pretty easy to figure out. It's obviously custom for
our setup, so YMMV!

Uname: Linux version 2.6.5-7.201-smp (geeko(at)buildhost) (gcc version 3.3.3
(SuSE Linux)) #1 SMP Thu Aug 25 06:20:45 UTC 2005
Hardware: Sun Microsystems Fire V20z - Dual Opteron 250's, 4Gb Ram, 2x73Gb
10krpm disks in RAID1

As of this mornings log processing, we have 101 hosts handled by 7 pound
processes (the main pound -f pound.cfg process runs most of the plain http://
sites). Most of our systems are based on Zope (all of those being ZEO hosted),
with a total of 10 dual homed backend servers on a private network; in the case
of our largest systems, we run over all 10 of them (thus 2x10 network
interfaces). We try not to use session affinity in Pound whenever possible;
preferring to use a ZEO mounted session.fs if practical. Where this is not
practical, we just stick to IP based sessions and find it a good compromise.

We still have a good smattering of Apache/PHP/Perl systems running, and all of
those requests get passed on by Pound to a dedicated Apache box on the private
network; a lot of the Zope services defined in Pound have URL's for static file
services also sent to Apache.

In terms of traffic of our largest systems; 3 medical-based virtual learning
environments, though there is obviously only a limited set of users (i.e
registered staff and students) we average around 40-50Gb per system, per month
- at around exam times (May-June) each of those bigger systems can easily
consume 100Gb+ of bandwidth each. The rest of our sites vary from 10's of
megabytes and a few dozen users to tens of thousands of users and anywhere up
to the kind of bandwidth that our learning environments use.

For us Pound works really well. As I'm pretty much the only guy looking after
30-40 of our servers I find the config much easier to get started with than the
older 1.x series - splitting out the different SSL hosts makes it a lot easier
to perform maintenance on the development systems or move machines/systems
around from host to host, without impacting on other hosted services. Ideally
I'd love a few Zeus Traffic Manager appliances; but that isn't going to happen
- so Pound is probably with us for the long term :-)

In the coming months we're going to start looking at a paired Linux LVS setup,
so it will be interesting to see how well our pretty complex setup transfers to
that sort of arrangement.

 John Snowdon - IT Support Specialist
-==========================================-
 School of Medical Education Development 
 Faculty of Medical Sciences Computing
 University of Newcastle

 Email : j.p.snowdon(at)ncl.ac.uk

[...]

Thanks for your detailed replies! 
   
  Regarding LVS--if you build an LVS-DR cluster you can run both Pound and LVS
alongside each other on the same box. LVS doesn't do layer 7 load balancing so
it won't be able to distribute traffic based on session information (HTTP
header info). For large file transfers like you describe, however, LVS-DR would
be a good choice so you can route the packets directly back to the client
computer (not through the load balancer) which is what LVS-DR is all about. 
   
  The LVS HOWTO is an excellent resource, <begin plug> you may also want
to check out my book on the subject called, "The Linux Enterprise Cluster"
<end plug>.
   
  Hoping to hear from more Pound users out there . . .
   
  --Karl 


 		
---------------------------------
Do you Yahoo!?
 Get on board. You're invited to try the new Yahoo! Mail.

On Wed, 2006-10-11 at 15:43 +0100, Michael Parkin wrote:[...]

No, it certainly is not. I see two possibilities:

1. We have misunderstood the OpenSSL documentation (which tends to vary
between confusing and non-existent) and have done something wrong in our
code.

2. There is a bug in OpenSSL.

We'll look into this some more and announce it here once we find out
what is going on. In any case many thanks for your efforts in diagnosing
the problem.[...]

On Wed, 2006-10-11 at 15:43 +0100, Michael Parkin wrote:[...]

No, and hopefully the new 2.1.4 solves the problem - please let me know
if it doesn't.[...]

Hello,

It will be very useful if someone write/publish brief "howto".
Unfortunately I'm stuck on this problem too :)

Michael Parkin wrote:[...]
[...]

Hi Stefan,

What (exactly) are you stuck on? Post some details and maybe I can
help (having been through all this...).

Michael.

On 10/17/06, Stefan Lambrev <stefan.lambrev(at)sun-fish.com> wrote:[...]

Client Cert Verification with pound 1.9 :)

A have no idea why with works so beautiful with pound 2.1.4 and failed 
to work with pound 1.9 :)

So in brief what I made is following your steps and the howto from 
http://dsd.lbl.gov/~boverhof/openssl_certs.html

1)    openssl req -out ca.pem -new -x509
As I do have server key from thawte I skipped steps from 2 to 4
2)  openssl genrsa -out client.key 1024
3) openssl req -key client.key -new -out client.req
4) openssl x509 -req -in client.req -CA ca.pem -CAkey privkey.pem 
-CAserial file.srl -out client.pem
I done also :
5) cat client.key client.pem > client-key.pem

 From my pound-2.1.4.conf file:

ListenHTTPS
  Address 0.0.0.0
  Port    443
  Cert    "/path/to/server.pem"
  Ciphers "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:-SSLv2"
  ClientCert 2 3
  VerifyList "/path/to/keys/ca.pem"
End

where server.pem is provided by thawte.

And this works as expected.

On pound 1.9 with same keys I have:

ListenHTTPS *,7443 /path/to/key/server.pem 
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:-SSLv2
VerifyList /path/to/keys/ca.pem 3
HTTPSHeaders 2

and every time when I try to connect with stunnel I got this:

2006.10.17 14:06:25 LOG7[5847:5527552]: SSL alert (read): fatal: bad 
certificate
2006.10.17 14:06:25 LOG3[5847:5527552]: SSL_connect: 14094412: 
error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
2006.10.17 14:06:25 LOG5[5847:5527552]: Connection reset: 0 bytes sent 
to SSL, 0 bytes sent to socket

Upgrade to pound 2.1.4 is planned already here, but I still want to test 
it little more before I actually upgrade,
and I'm trying to make pound 1.9 work with client certs.

Michael Parkin wrote:[...][...][...][...]

Hello,

I just want to confirm that this issue is fixed with pound 2.1.4 :)

Thanks Robert!

Robert Segall wrote:[...][...][...]
[...]

please send you pound logfile, config file and check the error line. The 
correct line has to be
"GET /member/common/member.jsp HTTP/1.1". Maybe malformated request?

Malte[...]

Hello

On 26.10.2006 (20:15:08) you wrote:
[...]
[...]

[...]

Haproxy also doesn't support reloading configuration file without
restarting process.

I think that it is possible to modify pound to allow
configuration reload. Could anybody make suggestions, how to do this ?




[...]

But what HAProxy does is allow the process to be restarted without a long
down-time.  The old process stops listening so the new process can start
listening.  The old process will also start listening again if the new
process fails to start normally.  There is also some provision for moving
session state to the new process.  This means that the interruption caused
by a process bounce is very, very short.

Pound could definitely support this style of transfer, but the developer(s)
are very intent on maintaining a very simple and clean implementation for
security purposes.


On 10/26/06 11:41 AM, "ForAll.pl - Firma" <firma(at)forall.pl> wrote:
[...][...][...][...][...][...][...]