OpenBSD Journal

Developer blog: reyk: hoststated(8) preinspection

Contributed by dlg on from the schnell-schnell-schnell dept.

Some month ago I was looking for a solution to run OpenBSD as a fully-featured loadbalancer. It was bothering me for a long time that I had to run some systems coupled to the Alteons, F5s, Linux virtual servers, or even Cizzz-coeees of the world. So I was very happy when I found pyr's work. I helped to improve his daemon, imported it into OpenBSD as hoststated(8) and convinced Theo to get him into the project as a new developer. hoststated is amazing and I'm already using it in production, but one major thing was missing: Layer 7 Loadbalancing.

Loadbalancing in OpenBSD is not very new; you can do it for a long time now using the pf(4) redirection features, typically using layer 3 round-robin distribution to a table of internal hosts. Besides pf, it is also possible to handle a bigger load by using the layer 2 loadbalancing functionality which I implemented in the trunk(4) driver. You can also use the ARP balancing functionality of carp(4) but this requires to run OpenBSD on all the backend servers (this is nice but unfortunately not the typical case).

hoststated implements one missing link, the ability to do keep alive checks of the internal servers. If you run a simple pf redirection in front of a webserver pool, you would never know if all of the internal hosts are really available and the users would worry about failed connections. But the daemon will dynamically alter the redirection table of active hosts and is even able to check various protocols, like HTTP, for an expected reply.

So what about Layer 7 Loadbalancing? I was very happy that I could offer OpenBSD-based loadbalancers now, when I suddenly got asked: "Do you support SSL Acceleration?". Sure, we do, but there are many ways to achieve this functionality. And I did not really like the existing solutions. These "reverse-proxies" were either very complex, bloated, or non-free. And the preferred solutions like pound, squid or even OpenBSD's version of the Apache mod_proxy fall into the categories of beeing bloated and complex. And I did not like the licenses...

First of all, I was concerned about the security of the existing solutions. Security's worst enemy is complexity (thanks Bruce). I looked at pound, the most promising candidate, but stumbled over things like pthreads, regular expressions, and weird string functions like strcpy with dynamic input buffers. This doesn't necessarily mean that pound is insecure but it doesn't match our idea about software and the principle of proactive security. I don't like pthreads in networking daemons, because of potential risks in wrong use and the complexity of the API itself. You can implement high performance networking daemons using a single-threaded and non-forking event model with non-blocking I/O (this is how most of our networking daemons like bgpd(8), ospfd(8), or even hoststated work). Furthermore, the regular expressions are a powerful way to match input strings and to split the result into smaller pieces. Even though the regex(3) and regexp(3) APIs are very popular and probably the key feature of scripting languages like Perl, the implementation is very complex and a big enigma to us developers; it is a potential risk. And hence, I replaced the initial use of regex in the hoststated send/expect code with the very simple fnmatch(3) interface (fnmatch is also used for shell globbing, the advanced directory "wildcards").

So I decided to implement something on my own, something simple but powerful. I already had some code as part of my company's preinspection functionality to do generic TCP relaying with some additional protocol inspection. In fact, preinspection is meant to be an answer to the general UTM (Unified Threat Management) and deep inspection/intrusion prevention hype. I hate the idea of parsing the contents of every single packet payload, it is normally very slow, you have an incredible amount of false positives/negatives, and the protocol parsers are typically very buggy and a security nightmare on the firewall itself. So preinspection is more like behavior based blocking as we do in OpenBSD with pf overload tables, connection rates, max source connections, greylisting and greytrapping with spamd(8), and many other smart features.

Prevent an instrusion before looking into the packet details, leave the fancy UTM work to other systems behind the firewall. Who cares about the name of every single virus in the networks, as long as it's kept out of it!

The relay code was a good starting point for my planned SSL accelerator. In theory, such an SSL accelerator is nothing more than a TCP relay which listens for SSL connections on the one side and opens "plain" connections to the target system on the other side. In contrast to a protocol proxy, a basic TCP relay or SSL accelerator doesn't need to know any details about the transmitted layer 7 protocol, it just forwards any traffic between both sides. But you end up in one major problem if you use a relay as a SSL accelerator or reverse proxy: the target system doesn't know about the real client's IP address, it just sees incoming connections from the relay itself.

I needed to extend the relay to do a little bit of HTTP processing. The trick was to add an additional HTTP header to forwarded requests, the "X-Forwarded-For" header as used by some other HTTP proxies and non-free loadbalancers. But instead of hardcoding the X-Forwarded-For header, I implemented a generic way to add, remove, change, expect or filter HTTP headers. It is also possible to append values to existing headers, because it's very common to append the client's IP address to a comma-separated list in the existing header (a HTTP request may pass several proxies on its way to the target host).

protocol myhttp {
        protocol http
        append "$REMOTE_ADDR" to "X-Forwarded-For"
        append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
        change "Connection" to "close"
        remove "Keep-Alive"

        # Various TCP performance options                                       
        tcp { nodelay, socket buffer 65536 }
}                                                                               

A perfect place to add the relay code was the existing hoststated. The existing framework of the daemon and the multi-process privsep model allowed to add independent processes handling the relay functionality while using the state information provided by the existing host check engine. And while I was already working with pyr on improving the hoststated for the upcoming 4.1 OpenBSD release, I was able to extend my TCP relay and SSL accelerator to become a real layer 7 loadbalancer. I simply had to implement some loadbalancing protocols like roundrobin, loadbalance, and hash (indeed, roundrobin and loadbalance got inspired from my existing work in trunk(4)) to be used independently from the pf redirection. The loadbalance protocol uses a hash over the source and destination IP addresses to select the target host and hash allows to feed specified HTTP header values into the hash instead.

table web {
        real port 80
        check http '/' code 200
        host $webserver1
        host $webserver2
}                                                                               

relay sslaccel {
        listen on www.myhost.com port 443 ssl

        # Relay protocol definition, see above                                  
        protocol myhttp

        # Layer 7 loadbalancing using src/dst hashing                           
        table web loadbalance
}                                                                               

And I went further than I expected... Some web applications use session IDs in the URL to track the users. For example, you may have a session ID like http://www.myhost.com/shop.php?page=foo&sessid=387874683268264826482&shop=bar I extended my relay code to be able to parse the variables in an URL, the GET-Vars, and to feed specified values into the hash. It allows to grab the sessid variable and to feed it into the computed hash for the loadbalance and hash protocols. This allows to do session-aware loadbalancing to a pool of HTTP servers, if your web application doesn't support any kind of internal clustering. And of course, you can also use the filter or expect rules on the GET-Vars.

The relay has been tested to be very efficient and I initially installed it as a SSL accelerator in front of a high volume web shop. Our systems are running on dual core Opteron servers with PCI express em(4) gigabit NICs, high end crypto accelerators, and using OpenBSD's amd64 multiprocessor kernel. We tested the SSL accelerator with up to 110.000 pf states, about 5.000 new SSL connections per minute using layer 7 loadbalancing and HTTP header rewriting, and nearly the same volume of concurrent HTTP connections using layer 3 pf redirection. After about six hours of testing we decided that the implementation is good enough for production use ;-)... We had to stop the test when we reached the limits of the backend webservers (pf's state and source connection limits will protected the servers in production). Amazingly, the loadbalancer was only up to 20% to 40% busy with a peak load of 4.0 and below 40MB user memory usage (SSL session cache disabled). While the relay code is designed to be non-blocking and single-process based as mentioned before, I use a configurable count of preforked relay processes to prevent any delays that can happen in the SSL handshake.

A drawback of layer 7 TCP relays is that you cannot provide stateful failover like we do with carp and pfsync(4). To improve the situation, I implemented support for the carp demotion counters as used by bgpd to force a quicker failover on error conditions. You can enable carp demotion of a specified interface group, typically the group called carp, to increase the demotion counter if all hosts in a table are down. An increased carp demotion counter will force the local system into BACKUP state to allow a graceful failover to a backup loadbalancer. Furthermore, a global carp demotion option allows to force the system into BACKUP state if hoststated exits or is beeing killed to reload the configuration. It will clear the specified group's demotion counter on startup and set it to 128 on exit.

A different thing, but a very good addition to the high performance loadbalancers, is mpf's implementation of IP-based loadsharing for CARP. Instead of running in the typical BACKUP/MASTER configuration, the redundant OpenBSD systems will compute a source/destination hash on the IP addresses to decide if they accept the incoming connections. Both systems will run in BACKUP and MASTER state at the same time and the load will be equally shared. I considered it as an option for the SSL accelerators, and tested the functionality with positive results, but the good performance of the primary relay didn't require to run a CARP "cluster" (But I hope that this new carp mode will be available after the 4.1 release).

Anyway, relay is more than just a loadbalancer! It also supports transparent proxying using NAT lookups, generic TCP redirection, and we're thinking about many other smart features in the future. A very simple patch to add URL white/blacklisting is on the way and you can do some nice tricks with TCP-based connections. And here we end up in a new trap - hoststated is a host state monitoring daemon, partially a loadbalancer but now it's getting a general-purpose preinspection thing? Should we change the name again? Probably not.

Nevertheless, the relay functionality and hoststated will be available in OpenBSD 4.1. It is still considered to be experimental, and I have some work on my TODO list, including additional cleanup, code review and improvement. The latest discussions on our mailing lists about possible reverse proxy solutions showed me that it was the right time to release something new, to carefully enter layer 7 in OpenBSD.

More to follow...

(Comments are closed)


  1. By marklar (203.11.81.235) marklar_@hotmail.com on

    This is insane, you're about to put F5 out of business if you keep this up... good job!!
    Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.

    1. By Nate (Nate) on

      > Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.

      Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

      1. By Anonymous Coward (122.49.141.5) on

        > Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

        I've always found the FAQ to be more howto-ish than FAQ-ish. Meh.
        As long as there's something to tell me what man page I need to look at in order to work with feature X (and the FAQ generally does this), I'm happy.

      2. By reyk (81.3.3.148) on http://team.vantronix.net/~reyk/

        > > Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.
        >
        > Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

        The manpage is called hoststated.conf(5).

        I'm working on improving the manpage together with jmc@ and pyr@.

    2. By Pierre-Yves Ritschard (pyr) on http://spootnik.org

      > This is insane, you're about to put F5 out of business if you keep this up... good job!!

      Who wouldn't want to get rid of their F5's ;)

  2. By Jeremy Huiskamp (kamper) on

    Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

    1. By christian (84.75.130.36) llx@swissonline.ch on

      > Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

      the prefered way to track a user session in an SSO environment is
      ssl-based. it is far more complex to steal ssl-credentials then cookies. to protect you from insane configurations it is even
      better to combine ssl-traking with one or more other session
      tracking mechanism. but this is somewhat off-topic here.

      may containers use poor random values for there sessionID thus a
      nice openbsd-like feature would be to replace the sessionID with a strong randomized value.

    2. By Anonymous Coward (74.115.21.120) on

      > Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

      Yes, and its not any harder to parse the cookies than it is to parse the query string, so it shouldn't be hard to add. You should never have session IDs in the url, as then they get passed in referrer headers and other malicious sites can steal your users valid session IDs without even needing to get in between them and your server to sniff.

  3. By Henrik Kramshøj (90.184.69.92) hlk@kramse.dk on www.kramse.dk

    Nice article!

    I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.

    The project is not very old, and some of the readers that needs
    these technologies might not know about it.
    http://varnish.projects.linpro.no/

    Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

    1. By Anonymous Coward (203.217.30.85) on

      > Nice article!
      >
      > I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.
      >
      > The project is not very old, and some of the readers that needs
      > these technologies might not know about it.
      > http://varnish.projects.linpro.no/
      >
      > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

      Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

      1. By Henrik Kramshøj (90.184.69.92) on

        > > Nice article!
        > >
        > > I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.
        > >
        > > The project is not very old, and some of the readers that needs
        > > these technologies might not know about it.
        > > http://varnish.projects.linpro.no/
        > >
        > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
        >
        > Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

        Yes, he is your run of the mill old grumpy UNIX guy ...
        I regularly run into him at various places in DK, and he is nice and knowledgeable. Varnish is way cool and being deployed at quite big sites with great success. Would be sad if we couldn't make it work on OpenBSD someday.

        I guess that terrorist, FUDDING etc is something about wireless and especially Atheros drivers/blobs?

        If so I think a lot of people get the whole point wrong.

        The way I see it FreeBSD wanted the cards supported and decided to "take on for the team" by bending over - their choice.
        While OpenBSD opted for the harder way, make a free driver - which is GREAT - I love the ath driver and even replaced an unsupported Cisco 802.11b in my Thinkpad X31 with an atheros 802.11g. Thanks Reyk!

        The goals were different and both succeeded with their goals
        - the real problem is how it affects the whole driver, vendor system vs
        open source, and here I can only say that I agree fully with the OpenBSD way!

        Enough of that, I need to show these cool OpenBSD things on Linuxforum 2007!

      2. By Anonymous Coward (128.171.90.200) on

        > Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

        What the ..

    2. By sthen (85.158.44.149) on

      > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

      OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.

      1. By Anonymous Coward (82.195.149.9) on

        > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
        >
        > OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.

        Also Varnish does not support load balancing to back-end servers.

        1. By uspoerlein (85.180.130.120) on

          > > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
          > >
          > > OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.
          >
          > Also Varnish does not support load balancing to back-end servers.

          Yes it does, with their own "programming language" you can decide to fire off requests to different backend servers. You can also do this session-based, if the session is transmitted via &sid=foo-URL. I don't know if you can inspect the Cookies of the HTTP request, but I would be surprised if you couldn't.

          Please check out the interview with phk on bsdtalk, he give's a really nice overview of Varnish.

          1. By Anonymous Coward (82.195.149.9) on

            > > > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
            > > >
            > > > OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.
            > >
            > > Also Varnish does not support load balancing to back-end servers.
            >
            > Yes it does, with their own "programming language" you can decide to fire off requests to different backend servers. You can also do this session-based, if the session is transmitted via &sid=foo-URL. I don't know if you can inspect the Cookies of the HTTP request, but I would be surprised if you couldn't.

            Thats not the same as load balancing, at all.

            >
            > Please check out the interview with phk on bsdtalk, he give's a really nice overview of Varnish.

            I've read the source, thanks very much.

            >
            >

  4. By Pete (80.203.236.21) on

    hi reyk,

    nice work :-) I'm a long time pound user, but this new stuff looks very promising

    is it possible to make sessions sticky based on cookie contents ? e.g. a pretty common cookie is JSESSIONID, based upon which I'd love to be able to tie to a particular backend.

    also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?

    thanks

    /pete

    1. By reyk (212.202.20.246) on http://team.vantronix.net/~reyk/

      > hi reyk,
      >
      > nice work :-) I'm a long time pound user, but this new stuff looks very promising
      >
      > is it possible to make sessions sticky based on cookie contents ? e.g. a pretty common cookie is JSESSIONID, based upon which I'd love to be able to tie to a particular backend.
      >

      I do support hashing of the complete Cookie header, splitting the Cookie into values is on my TODO list. This will allow to use the cookie value like any other HTTP header or GET-Var.

      > also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?
      >

      The relay will use the host states from the hoststated check engine to determine if a target host is up or down. If the determined host is down, the relay will try the next available host for this connection, if using the table loadbalance, roundrobin, or hash protocols.

      I'm thinking about adding an additional fallback if the inbound connection to a host that was marked as up failed.

      If all hosts in the table are down, hoststated can use the carp demotion option to enter carp BACKUP state.

      > thanks
      >
      > /pete

      1. By sthen (85.158.44.149) on

        Nice work...

        > I'm thinking about adding an additional fallback if the inbound connection to a host that was marked as up failed.

        That may be worth doing, at least for the obviously broken "SYN -> no response" or "SYN -> RST", you could mark the backend as being down straight away rather than waiting for the next scheduled check, and ideally cut the client's connection across to another backend.

        "request sent but no response from backend within timeout" and "request sent but error response from backend" probably need more consideration, the unwary user may get bitten with duplicate form submissions etc.

    2. By David Gwynne (dlg) on

      > also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?

      it depends on how the group of servers store their information about a clients session.

      for example, the default session store for php driven stuff is a file in /tmp. obviously if that server with the session info dies then the session dies too, and the client will have to create a new session on another server in the pool.

      however, you can modify it so the session store is something like a database. if all servers in the pool are using the one database to store session info then a server can die without the client noticing. another server in the pool can get the session info and pick up where the other left off just fine.

      1. By Anonymous Coward (81.57.42.108) on

        Alternativly, some web languages allows to store session in a memcached pool shared among servers.

        On a side note, did you looked at HA Proxy ?
        It's a similar (event driven, w/ servers health checks, http layer7 facilities, ... but lacks SSL support) load balancer, written by a Linux kernel dev. Run fine on OpenBSD.

        There's bright ideas to poke here, related to high performance and even security (eg. connection tarpitting is nice !).

  5. By Matt Van Mater (69.255.1.181) on

    This is great, I have been looking for a non-Apache, non-Pound, non-squid way of doing this natively on openbsd for some time now. Keep up the good work, i appreciate it.

  6. By Anonymous Coward (128.171.90.200) on

    "Should we change the name again? Probably not."

    oh go on ...

    1. By Anonymous Coward (149.169.23.92) on

      > "Should we change the name again? Probably not."

      Please do this before it gets put into an official release if it's going to happen. I preferred the idea of eating hosts with the previous name anyway.

      1. By Anonymous Coward (128.171.90.200) on

        > Please do this before it gets put into an official release if it's going to happen.

        seems doubtful, but my vote is for Anemone ;)

        > I preferred the idea of eating hosts with the previous name anyway.

        eating hosts ?

        1. By Anonymous Coward (70.162.93.223) on

          > > I preferred the idea of eating hosts with the previous name anyway.
          >
          > eating hosts ?

          The first iteration of the little magic bot was hostated

          which you could split up as:

          ho state daemon

          - OpenBSD branches into big pimpin'

          or host ate daemon

          - The reverse memory leak, perhaps?

          The renaming to hoststated removed that amusement.

          1. By Pierre-Yves Ritschard (pyr) on http://spootnik.org

            > > > I preferred the idea of eating hosts with the previous name anyway.
            > >
            > > eating hosts ?
            >
            > The first iteration of the little magic bot was hostated
            >
            > which you could split up as:
            >
            > ho state daemon
            >
            > - OpenBSD branches into big pimpin'
            >
            > or host ate daemon
            >
            > - The reverse memory leak, perhaps?
            >
            > The renaming to hoststated removed that amusement.

            Well the first iteration was actually called slbd.
            I didn't see there was an eponym at the time.

  7. By Curis (199.6.38.58) on

    This is a great feature but looking into the hoststated.conf(5), hoststated(8) and hoststatedctl(8) man pages I didn't see a way to test multiple ports on one host.

    I'm thinking of my Rails project where I run a Mongrel cluster on ports 8000-8005 and would like to be able to check that they are still alive and also loadbalance between those 5 (as well as another machine that also runs the same setup).

    Is this capable, or on the TODO list? Either way this is looking great and I can always just keep the two front facing Apache servers on port 80 I have now with proxy balancing between the Mongrel clusters.

    1. By Frank DENIS (212.129.63.1) on

      > This is a great feature but looking into the hoststated.conf(5), hoststated(8) and hoststatedctl(8) man pages I didn't see a way to test multiple ports on one host.
      >
      > I'm thinking of my Rails project where I run a Mongrel cluster on ports 8000-8005 and would like to be able to check that they are still alive and also loadbalance between those 5 (as well as another machine that also runs the same setup).

      Sorry, but I don't see the point of using hostated in that case, in place of Apache2, Lighttpd-current or Nginx.
      Mongrel is great, but for static content, it sucks. So let a front-end web server handle the static content, and have mongrel only handle the Rails part.

  8. By Anonymous Coward (68.104.220.48) on

    Brilliant! What a development. Frankly I've been impressed with the load balancing capabilities of a simple rdr server pool but this L7 stuff is cool, especially at the performance level. Another ++ for the solid OpenBSD architecture and adherence to doing things the best way possible.

    I hadn't realized that this was the case:

    > You can also use the ARP balancing functionality of carp(4) but this requires to run OpenBSD on all the backend servers (this is nice but unfortunately not the typical case).

    What's with the dependency on the arpbalance on the backend OS?

    And what is the required way of enabling the hardware load balancer for use in the SSL acceleration? I have a "Hifn 7955/7954" and haven't been clear on how to use it for acceleration.

    1. By Lennie (82.75.21.80) on

      > Brilliant! What a development. Frankly I've been impressed with the load balancing capabilities of a simple rdr server pool but this L7 stuff is cool, especially at the performance level. Another ++ for the solid OpenBSD architecture and adherence to doing things the best way possible.
      >
      > I hadn't realized that this was the case:
      >
      > > You can also use the ARP balancing functionality of carp(4) but this requires to run OpenBSD on all the backend servers (this is nice but unfortunately not the typical case).
      >
      > What's with the dependency on the arpbalance on the backend OS?
      >
      > And what is the required way of enabling the hardware load balancer for use in the SSL acceleration? I have a "Hifn 7955/7954" and haven't been clear on how to use it for acceleration.
      >

      I can only answer your first question.

      ( in case you do not know what arp is, arp is the methode of finding out which network-card 'houses' an IP-address. So if you want to send some packets to an other host on your local network, an ARP-request will be send out to ask what network-card these packets need to be send to, for them to arrive (the 'owner' then responds with it's MAC- or Ethernet-address) )

      arpbalance an advanced feature of CARP in OpenBSD (maybe even other BSD's), it allows you to devide a network into equal parts per server (or firewall ofcourse). One host will respond to ARP-requests for certain machines on the network, an other machine in the 'cluster' responds to others. Thus creating a loadbalancing system.

      About the hardware take a look here:
      http://www.openbsd.org/cgi-bin/man.cgi?query=hifn&arch=i386&sektion=4

      If I've understood it right, supported hardware should automagically get used by OpenBSD for the encryption-methodes supported by the hardware.

      As I've never seen such a card up close, I'm guessing it should show up in dmesg and tell you what is supported.

  9. By Ed White (151.41.8.53) on

    I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".

    1. By Anonymous Coward (24.37.236.100) on

      > I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".
      >
      >

      stuffd(8), then hostated(8) would have ate too many d's. Good thing it was renamed... ;-)

    2. By sthen (85.158.44.149) on

      > I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".

      a load-balancer needs to know the state of the hosts; combining them reduces overhead (machine resources, mostly-duplicated configuration) ... it does make sense.

  10. By reyk (212.202.20.246) on http://team.vantronix.net/~reyk/

    Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...

            ssl { no sslv2, ciphers "HIGH" }
    

    I also tweaked some other options, added the log action to track header/url values, and implemented a configurable listen backlog option for an improved performance with many concurrent connections.

    1. By David Gwynne (dlg) on

      > Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...

      does complying mean anything, or is this just a gold sticker for good behaviour?

      if it is better with the compliant behaviour, perhaps it would make sense to make that the default?

      1. By reyk (212.202.20.246) on http://team.vantronix.net/~reyk/

        > > Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...
        >
        > does complying mean anything, or is this just a gold sticker for good behaviour?
        >

        it is a requirement to connect your e-commerce platform to various payment gateways for things like VISA.

        > if it is better with the compliant behaviour, perhaps it would make sense to make that the default?

        yes, i changed it to disable SSLv2 and to use the "HIGH" crypto ciphers by default. you have to enable it now if you need any kind of MEDIUM or LOW
        crypto or if you need to use SSLv2.




  11. By David Steinberg (71.232.117.76) dave@redterror.net on http://www.geekisp.com/

    Awesome work! I was curious if there was any feature planned to enable actions to be conditional based on certain headers? Specifically with Pound I often do special backend routing based on the Host header - for instance with the following (rough) pound.conf snippit:
    Service "railstest"
         HeadRequire "Host: railstest"
         Backend
            Address int01
            Port 8080
         End
    End
    
    Service "default"
         Backend
            Address int01
            Port 80
         End
    End
    
    The first chunk would pick up a request for http://railstest/ and the latter would serve everything else. I use this on a single IP, which lets me avoid DNS changes for backend handling changes. I didn't see anything in the man page about this, so please do apply the clue stick if I'm missed it. Again, great work, I'd dump pound in a moment if I could use hoststated (not that pound is bad, just OpenBSD rules)!

  12. By Motley Fool (MotleyFool) motleyfool@dieselrepower.org on

    Do you have any thoughts towards manipulating HTML on the fly? I have a video streaming server I'd like to provide controlled access to the outside world. It's web server only talks http. I initially setup squid reverse proxy to get to it, unfortunately the embedded server hard codes the server IP address using hidden values, so the ActiveX control can access the video stream. Rewriting HTML content on the fly could replace the internal IP address with the OpenBSD system running hoststated.

    g.day

    1. By Anonymous Coward (167.88.178.70) on

      So guys, assuming we have 2 or more firewalls that are load balanced using CARP+pfsync, do we also need to setup hostated on all firewalls?

      I can't wait to try it! Awesome article!!!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]