Re: relayd fails on POST 2GB

2012-01-10 Thread Gordon McAllister
2012/1/9 iLXQ {IPICIN chipits...@gmail.com:
 Hello! Can you provide relays configuration as well as haproxy
 configuration?

Here's our relayd and haproxy configs as well as a dmesg, maybe this
will be helpful.

Regards,

---Gordon

# relayd.conf
#
# Macros
#
ext_ssl_listener=127.0.0.1
int_ssl_listener=127.0.0.2
haproxy_listener=127.0.0.1
web1=10.210.0.11
web2=10.210.0.12
web3=10.210.0.13
web4=10.210.0.14
app1=10.211.0.11
app2=10.211.0.12
app3=10.211.0.13
app4=10.211.0.14

#
# Global Options
#
interval 3
prefork 10

# No lower, this needs to cover a complete SSL handshake over high-latency
# connections (several hundred ms best case).
timeout 2000

#
# Each table will be mapped to a pf table.
#
table haproxy { $haproxy_listener }
table webhosts { $web1 $web2 $web3 $web4 }
table apphosts { $app1 $app2 $app3 $app4}

#
# Protocol and relays for SSL acceleration. Decrypted traffic is forwarded
# to haproxy listening on a loopback IP.
#
http protocol http_ssl {
# Rewrite headers. 'X-Forwarded-For' is critical, any client-provided
# value must be overwritten.
header change X-Forwarded-For to $REMOTE_ADDR
header change X-Forwarded-By to $SERVER_ADDR:$SERVER_PORT
header change Connection to close
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
ssl session cache disable
}

relay ext_ssl {
listen on $ext_ssl_listener port 443 ssl
protocol http_ssl
# Long timeout (30 min) required for large file uploads
session timeout 1800
forward to haproxy port 8080 check script
/usr/local/bin/check_haproxy_ext.sh
# If haproxy is dead, carry on by sending traffic directly
forward to webhosts port 8080 mode roundrobin interval 6 \
check http /check.html code 200
}

relay int_ssl {
listen on $int_ssl_listener port 443 ssl
protocol http_ssl
# Long timeout (30 min) required for large file uploads
session timeout 1800
forward to haproxy port 8081 check script
/usr/local/bin/check_haproxy_int.sh
# If haproxy is dead, carry on by sending traffic directly
forward to apphosts port 8080 mode roundrobin interval 6 \
check http /check.html code 200


# haproxy.cfg

global
log /dev/log daemon
maxconn 10240
chroot /var/haproxy
uid 604
gid 604
daemon
#spread-checks 3
pidfile /var/run/haproxy.pid
stats socket /var/run/haproxy.sock group _relayd mode 664 level admin

defaults
log global
modehttp
option  httplog
option  dontlognull
option  redispatch
retries 3
#maxconn 2000
timeout connect 5s
timeout client  50s
timeout server  180s
stats enable
stats hide-version
stats auth admin:passwd
stats refresh 10

frontend external_ssl
bind 127.0.0.1:8080
acl root_url url_reg ^/$
redirect location /index.html if root_url
capture request header X-Forwarded-For len 15
capture request header Content-Length len 12
capture response header Content-Length len 12
capture response header Cache-Control len 8

default_backend web

frontend internal_ssl
bind 127.0.0.1:8081
acl root_url url_reg ^/$
redirect location /admin.html if root_url
capture request header X-Forwarded-For len 15
capture request header Content-Length len 12
capture response header Content-Length len 12
capture response header Cache-Control len 8

default_backend app

frontend external_clear
bind 10.200.0.1:80
reqidel ^X-Forwarded-For:.*
acl clear dst_port 80
redirect location https://www.example.com/ if clear
default_backend web

backend web
# Backend to service 'external' traffic
id 254
source 10.210.0.1
# Add 'X-Forwarded-For' header for all connections except those from
relayd
option forwardfor except 127.0.0.0/8
option httpclose
option httpchk /check.html
balance roundrobin
server web01 10.210.0.11:8080 check inter 2s rise 1 fall 2
server web02 10.210.0.12:8080 check inter 2s rise 1 fall 2
server web03 10.210.0.13:8080 check inter 2s rise 1 fall 2
server web04 10.210.0.14:8080 check inter 2s rise 1 fall 2

backend app
# Backend to service 'internal' traffic
id 255
source 10.211.0.1
# Add 'X-Forwarded-For' header for all connections except those from
relayd
option forwardfor except 127.0.0.0/8
option httpclose
option httpchk /check.html
balance roundrobin
server app01 10.211.0.11:8080 check inter 2s rise 1 fall 2
server app02 10.211.0.12:8080 check inter 2s rise 1 fall 2
server app03 10.211.0.13:8080 check inter 2s rise 1 fall 2
server app04 10.211.0.14:8080 check inter 2s rise 1 fall 2

# dmesg

OpenBSD 4.9 (GENERIC.MP) #819: Wed Mar  2 06:57:49 MST 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3748134912 (3574MB)
avail mem = 3634339840 (3465MB)
mainbus0 at root
bios0 at 

Re: relayd fails on POST 2GB

2012-01-08 Thread Rafal Bisingier
Hi,

On friday, 06 Jan 2012 at 13:22 CET
Gordon McAllister gordon.mcallis...@gmail.com wrote:

 Is there a knob to tweak to allow POSTs greater than 2GB or is this
 limit somehow hardcoded?

A wild guess (since you didn't provide dmesg): do you use i386 arch?

-- 
Greetings
Rafal Bisingier



Re: relayd fails on POST 2GB

2012-01-08 Thread Stuart Henderson
On 2012-01-08, Rafal Bisingier ra...@man.poznan.pl wrote:
 A wild guess (since you didn't provide dmesg): do you use i386 arch?

No, amd64, see the original message.


On 2012-01-06, Gordon McAllister gordon.mcallis...@gmail.com wrote:
 Hello all,

 I have a relayd setup on 4.9 (amd64), terminating SSL in front of an
   ^^^
 application that requires large-ish file uploads. All is well until a
 file upload greater than 2GB is attempted. The request fails
 immediately, here's an example log message:

 relay ext_ssl, session 33753 (1 active), 0, 10.6.66.76 -
 127.0.0.1:8080, too large

Is this the exact text of the log entry? I don't see this too large
string in relayd source code implying it comes from elsewhere.
Does the backend server even accept 2GB POSTs in the first place?
If unsure, take relayd out of the equation and connect directly.



Re: relayd fails on POST 2GB

2012-01-08 Thread Gordon McAllister
On Sun, Jan 8, 2012 at 4:35 AM, Stuart Henderson s...@spacehopper.org wrote:
 Is this the exact text of the log entry? I don't see this too large
 string in relayd source code implying it comes from elsewhere.
 Does the backend server even accept 2GB POSTs in the first place?
 If unsure, take relayd out of the equation and connect directly.

Thanks for the reply, yes this is the exact text.Our config has relayd
handing decrypted traffic off to HAProxy, which forwards to app
servers running Tomcat on the backend. In debugging this I ran tcpdump
on the loopback interface HAProxy listens on, in the large-POST case
nothing ever reaches HAProxy so I'm not sure it's to blame here. I can
send large (2GB) POSTs to Tomcat directly through the same OpenBSD
box.

If anyone would like to see our relayd config, dmesg, whatever, please
let me know and I can provide the info.

Regards,

---Gordon