On Thu, Mar 06, 2008 at 08:58:01PM +0100, Sebastian Reitenbach wrote: > Reyk Floeter <[EMAIL PROTECTED]> wrote: > > btw., did you test it with the latest code from -current? > > the sparch64 was installed from a snapshot not very long ago: > OpenBSD 4.2-current (GENERIC.MP) #113: Wed Feb 13 20:47:18 MST 2008 > [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC.MP > the system is from the same download. > > Sebastian >
Feb 13 and 4.2-current is long ago ;) Some things have been changed in March... please try the latest snapshot or even -current. > > > > On Mon, Mar 03, 2008 at 07:37:53PM +0100, Sebastian Reitenbach wrote: > > > Reyk Floeter <[EMAIL PROTECTED]> wrote: > > > > hi! > > > > > > > > it tested your config and it works fine without problems, there is no > > > > bug in relayd here... > > > > > > > > ...you seem to make a common mistake: > > > > > > > > > forward to <ogohosts> port http mode hash \ > > > > > check http "/" code 200 > > > > > > > > you expect that the webservers always return the HTTP error code 200 > > > > OK. this is not how HTTP works. your webserver may return another > > > > error based on the site, state, or configuration (moved, not allowed, > > > > not found, server error, ...). > > > > > > > > please test the following: > > > > > > > > $ lynx -head http://10.0.0.121/ > > > This was done on the host running relayd: > > > HTTP/1.1 200 OK > > > Date: Mon, 03 Mar 2008 18:22:37 GMT > > > Server: Apache > > > Last-Modified: Tue, 28 Aug 2007 16:00:16 GMT > > > ETag: "fccbb0109d4b4b44b551e2fe7cc156404b93a785" > > > Accept-Ranges: bytes > > > Content-Length: 2216 > > > Connection: close > > > Content-Type: text/html > > > > > > On the 4.2 host, this check works also well with hoststated, there its > > > embedded in the table definition, see last configuration snippet. But > with > > > hoststated, I have the other problem mentioned below. > > > The / on the apache instances is just serving the apache index page. > > > The application itself sits behind a location, but I think checking just > the > > > apache availability, and then assuming the application is there too, is > fine > > > for testing. > > > > > > > > > > > and you will see the HTTP header. for example, the following header > > > > would require you to change your check to 'check http "/" code 302' > > > > (or even 'check http "/oxid/" code 200'): > > > > > > > > HTTP/1.1 302 Found > > > > Date: Mon, 03 Mar 2008 17:24:10 GMT > > > > Server: Apache > > > > Location: /oxid/ > > > > Connection: close > > > > Content-Type: text/html > > > > > > > > i normally use a special monitor script to check the state on the > > > > webservers, for example the Zend platform provides the following > > > > self-test: > > > > > > > > check http '/ZendPlatform/client/getPing.php' code 200 > > > > > > there is unfortunately no such thing in the app I want to use, at least > not > > > that I am aware of, but I think the ordinary http check is ok for now. > > > > > > Sebastian > > > > > > > > > > > reyk > > > > > > > > On Mon, Mar 03, 2008 at 07:45:00AM +0100, Sebastian Reitenbach wrote: > > > > > Hi, > > > > > > > > > > this is the first time I play around with hoststated/relayd. > > > > > I have a stateful web application, and try to use hoststated/relayd > in > > > front > > > > > of it. Because the application is stateful, the client has to be > > > redirected > > > > > to the same instance for the session lifetime. The session id is > encoded > > > as > > > > > GET parameter "wosid". Further I have the problem that many of the > users > > > are > > > > > either sitting behind a proxy or a NAT'ed IP address, so these > should > > > not be > > > > > redirected to the same application instance. > > > > > I tried with hoststated on OpenBSD 4.2 i386 and with relayd on > > > > > OpenBSD -snapshot sparc64 from beginning of February 08. > > > > > > > > > > I'm not sure, whether I see the same problems, as described here in > that > > > > > thread: > > > > > > > > http://www.nabble.com/relayd-http-check-connection-failures--hoststated- > > > > > > > > > > > > > Well, I do not fiddle around with carp interfaces, and I also tried > the > > > > > patch with the timeout, that did not fixed my problem. > > > > > > > > > > First I tried to use relayd, until I came across above mentioned > thread, > > > > > however, first I tried to setup a ssl accelerator as in the example: > > > > > > > > > > ext_addr="10.0.0.24" > > > > > ogo1="10.0.0.121" > > > > > ogo2="10.0.0.122" > > > > > ogo3="10.0.0.123" > > > > > ogo4="10.0.0.124" > > > > > ogo5="10.0.0.125" > > > > > > > > > > timeout 9999 > > > > > > > > > > table <ogohosts> { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 } > > > > > > > > > > http protocol httpssl { > > > > > header append "$REMOTE_ADDR" to "X-Forwarded-For" > > > > > header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded- > > > > > header change "Connection" to "close" > > > > > cookie hash "wosid" > > > > > url hash "wosid" > > > > > url log "wosid" > > > > > > > > > > # Various TCP performance options > > > > > # tcp { nodelay, sack, socket buffer 65536, backlog 128 } > > > > > > > > > > # ssl { no sslv2, sslv3, tlsv1, ciphers HIGH } > > > > > # ssl session cache disable > > > > > } > > > > > > > > > > relay wwwssl { > > > > > # Run as a SSL accelerator > > > > > listen on $ext_addr port 443 ssl > > > > > protocol httpssl > > > > > > > > > > # Forward to hosts in the webhosts table using a src/dst > hash > > > > > forward to <ogohosts> port http mode hash \ > > > > > check http "/" code 200 > > > > > } > > > > > > > > > > # relayd -d -vv -f /etc/relayd.conf > > > > > startup > > > > > init_filter: filter init done > > > > > init_tables: created 0 tables > > > > > relay_privinit: adding relay wwwssl > > > > > protocol 0: name httpssl > > > > > flags: 0x0004 > > > > > type: http > > > > > request change "Connection" to "close" > > > > > request cookie hash "wosid" > > > > > request url hash "wosid" > > > > > request url log "wosid" > > > > > request append "$SERVER_ADDR:$SERVER_PORT" > > > > > to "X-Forwarded-By" > > > > > request append "$REMOTE_ADDR" to "X-Forwarded-For" > > > > > hce_notify_done: 10.0.0.121 (tcp_send_req: timeout) > > > > > relay_init: max open files 1024 > > > > > relay_init: max open files 1024 > > > > > host 10.0.0.121, check http code (9ms), state unknown -> down, > > > availability > > > > > 0.00% > > > > > hce_notify_done: 10.0.0.122 (tcp_send_req: timeout) > > > > > host 10.0.0.122, check http code (51ms), state unknown -> down, > > > availability > > > > > 0.00% > > > > > hce_notify_done: 10.0.0.123 (tcp_send_req: timeout) > > > > > host 10.0.0.123, check http code (52ms), state unknown -> down, > > > availability > > > > > 0.00% > > > > > hce_notify_done: 10.0.0.124 (tcp_send_req: timeout) > > > > > host 10.0.0.124, check http code (53ms), state unknown -> down, > > > availability > > > > > 0.00% > > > > > hce_notify_done: 10.0.0.125 (tcp_send_req: timeout) > > > > > host 10.0.0.125, check http code (53ms), state unknown -> down, > > > availability > > > > > 0.00% > > > > > pfe_dispatch_imsg: state -1 for host 9 10.0.0.121 > > > > > pfe_dispatch_imsg: state -1 for host 8 10.0.0.122 > > > > > pfe_dispatch_imsg: state -1 for host 7 10.0.0.123 > > > > > pfe_dispatch_imsg: state -1 for host 6 10.0.0.124 > > > > > pfe_dispatch_imsg: state -1 for host 5 10.0.0.125 > > > > > relay_ssl_ctx_create: loading certificate > > > > > relay_init: max open files 1024 > > > > > relay_ssl_ctx_create: loading certificate > > > > > relay_ssl_ctx_create: loading certificate > > > > > relay_ssl_ctx_create: loading private key > > > > > relay_init: max open files 1024 > > > > > adding 5 hosts from table ogohosts:80 > > > > > relay_init: max open files 1024 > > > > > relay_launch: running relay wwwssl > > > > > relay_ssl_ctx_create: loading private key > > > > > adding 5 hosts from table ogohosts:80 > > > > > relay_ssl_ctx_create: loading private key > > > > > relay_launch: running relay wwwssl > > > > > adding 5 hosts from table ogohosts:80 > > > > > relay_ssl_ctx_create: loading certificate > > > > > relay_launch: running relay wwwssl > > > > > relay_ssl_ctx_create: loading certificate > > > > > relay_ssl_ctx_create: loading private key > > > > > adding 5 hosts from table ogohosts:80 > > > > > relay_ssl_ctx_create: loading private key > > > > > relay_launch: running relay wwwssl > > > > > adding 5 hosts from table ogohosts:80 > > > > > relay_launch: running relay wwwssl > > > > > relay wwwssl, session 1 established (1 active) > > > > > relay_from_table: no active hosts > > > > > relay wwwssl, session 1 (1 active), 0, 10.0.0.9 -> :80, session > failed > > > > > relay wwwssl, session 2 established (1 active) > > > > > relay_from_table: no active hosts > > > > > relay wwwssl, session 2 (1 active), 0, 10.0.0.9 -> :80, session > failed > > > > > tcp_write: connect timed out > > > > > hce_notify_done: 10.0.0.124 (tcp_write: connect failed) > > > > > tcp_write: connect timed out > > > > > hce_notify_done: 10.0.0.125 (tcp_write: connect failed) > > > > > hce_notify_done: 10.0.0.121 (tcp_send_req: timeout) > > > > > hce_notify_done: 10.0.0.122 (tcp_send_req: timeout) > > > > > hce_notify_done: 10.0.0.123 (tcp_send_req: timeout) > > > > > > > > > > > > > > ============================================================================ > > > > > > > > > > > > > Also a http redirect did not work. I get a timeout in the browser. > With > > > > > tcpdump I see incoming SYN packets to port 80, but they are not > > > answered: > > > > > > > > > > ext_addr="10.0.0.24" > > > > > ogo1="10.0.0.121" > > > > > ogo2="10.0.0.122" > > > > > ogo3="10.0.0.123" > > > > > ogo4="10.0.0.124" > > > > > ogo5="10.0.0.125" > > > > > > > > > > timeout 9999 > > > > > > > > > > table <ogohosts> { $ogo1 $ogo2 $ogo3 $ogo4 $ogo5 } > > > > > > > > > > redirect "www" { > > > > > listen on $ext_addr port 80 > > > > > listen on biggame.ds9 port 80 > > > > > sticky-address > > > > > forward to <ogohosts> port http timeout 3000 \ > > > > > check http "/" code 200 > > > > > } > > > > > > > > > > > > > > > # relayd -d -vv -f /etc/relayd.conf > > > > > startup > > > > > init_filter: filter init done > > > > > hce_notify_done: 10.0.0.125 (tcp_read_buf: check succeeded) > > > > > init_tables: created 1 tables > > > > > host 10.0.0.125, check http code (9ms), state unknown -> up, > > > availability > > > > > 100.00% > > > > > hce_notify_done: 10.0.0.122 (tcp_read_buf: check succeeded) > > > > > host 10.0.0.122, check http code (146ms), state unknown -> up, > > > availability > > > > > 100.00% > > > > > hce_notify_done: 10.0.0.124 (tcp_read_buf: check succeeded) > > > > > host 10.0.0.124, check http code (148ms), state unknown -> up, > > > availability > > > > > 100.00% > > > > > hce_notify_done: 10.0.0.123 (tcp_read_buf: check succeeded) > > > > > host 10.0.0.123, check http code (149ms), state unknown -> up, > > > availability > > > > > 100.00% > > > > > hce_notify_done: 10.0.0.121 (tcp_read_buf: check succeeded) > > > > > host 10.0.0.121, check http code (150ms), state unknown -> up, > > > availability > > > > > 100.00% > > > > > pfe_dispatch_imsg: state 1 for host 5 10.0.0.125 > > > > > pfe_dispatch_imsg: state 1 for host 8 10.0.0.122 > > > > > pfe_dispatch_imsg: state 1 for host 6 10.0.0.124 > > > > > pfe_dispatch_imsg: state 1 for host 7 10.0.0.123 > > > > > pfe_dispatch_imsg: state 1 for host 9 10.0.0.121 > > > > > sync_table: table www: 5 added, 0 deleted, 0 changed > > > > > pfe_sync: enabling ruleset > > > > > sync_ruleset: rule added > > > > > sync_ruleset: rule added > > > > > sync_ruleset: rule added > > > > > hce_notify_done: 10.0.0.124 (tcp_read_buf: check succeeded) > > > > > hce_notify_done: 10.0.0.121 (tcp_read_buf: check succeeded) > > > > > hce_notify_done: 10.0.0.123 (tcp_read_buf: check succeeded) > > > > > hce_notify_done: 10.0.0.122 (tcp_read_buf: check succeeded) > > > > > hce_notify_done: 10.0.0.125 (tcp_read_buf: check succeeded) > > > > > > > > > > > > > > ============================================================================ > > > > > > > > > > > > > Using hoststated on OpenBSD 4.2, there it generally works, www > > > > > loadbalancing, and https acceleration. > > > > > But here I have another little problem. When I change the "sessid" > > > > > to "wosid", in the protocol definition, then hoststated refuses to > > > start, > > > > > below below shown reason. > > > > > > > > > > ext_addr="10.0.0.21" > > > > > ogo1="10.0.0.121" > > > > > ogo2="10.0.0.122" > > > > > ogo3="10.0.0.123" > > > > > ogo4="10.0.0.124" > > > > > ogo5="10.0.0.125" > > > > > > > > > > timeout 9999 > > > > > log all > > > > > > > > > > table webhosts { > > > > > check http "/" code 200 > > > > > real port 80 > > > > > host $ogo1 > > > > > host $ogo2 > > > > > host $ogo3 > > > > > host $ogo4 > > > > > host $ogo5 > > > > > } > > > > > > > > > > protocol http_ssl { > > > > > protocol http > > > > > header append "$REMOTE_ADDR" to "X-Forwarded-For" > > > > > header append "$SERVER_ADDR:$SERVER_PORT" > > > > > to "X-Forwarded-By" > > > > > header change "Keep-Alive" to "$TIMEOUT" > > > > > # cookie hash ogo-webui-1.1 > > > > > # query hash "wosid" > > > > > # url log "sessid" > > > > > url hash "sessid" > > > > > } > > > > > > > > > > relay sslaccel { > > > > > listen on $ext_addr port 443 ssl > > > > > protocol http_ssl > > > > > table webhosts hash > > > > > } > > > > > > > > > > service www { > > > > > virtual host $ext_addr port 80 > > > > > sticky-address > > > > > table webhosts > > > > > } > > > > > > > > > > The construct seems to work well with the service www. The sessions > are > > > > > stuck to the same instance because of the sticky-address. However, > in my > > > > > testsetup it seems, that all clients from the same host are > redirected > > > to > > > > > the same instance. My testsetup were only two different browsers on > the > > > same > > > > > host, so I might have the wrong conclusion. Therefore I thought, I > could > > > > > make the protocol definition used for the relay sslacces consider > the > > > value > > > > > of wosid to calculate the host to which it gets redirected. As it > seems, > > > I > > > > > can change the value of cookie hash to anything I want, without > getting > > > an > > > > > error, but I do not want to use cookies. So I changed the url > > > hash "sessid" > > > > > to url hash "wosid", but then the following error occurs on > hoststated > > > > > startup: > > > > > > > > > > hoststated -d -v -f /etc/hoststated.conf > > > > > /etc/hoststated.conf:41: protocol node wosid defined twice > > > > > /etc/hoststated.conf:44: syntax error > > > > > /etc/hoststated.conf:48: no such protocol: http_ssl > > > > > /etc/hoststated.conf:49: table webhosts defined twice > > > > > > > > > > Also, I cannot specify both url log "sessid", and url hash "sessid", > > > then > > > > > the same error as above shows up. With relayd, I can specify both, > and > > > also > > > > > name the value wosid, without getting this error, but there I run > into > > > the > > > > > problem mentioned in the beginning of the mail. > > > > > > > > > > So, long story, some shorter questions: > > > > > > > > > > Is the problem I see with relayd, the same as in the thread I > mentioned > > > > > above, or have I done sth. else wrong? > > > > > How can I make hoststated protocol consider the value of wosid to > > > calculate > > > > > the host to redirect to? > > > > > > > > > > cheers > > > > > Sebastian
