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-operates-correctly-to15646508.html > > > > 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-By" > > 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