btw., did you test it with the latest code from -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-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

Reply via email to