OpenBSD Journal

hoststated is dead, long lives relayd!

Contributed by merdely on from the what's-in-a-name? dept.

In a recent post to misc@, Reyk Flöter (reyk@) announces hoststated's new name:

As you probably noticed, hoststated got renamed to relayd to reflect the enhanced scope of the daemon. I also used the chance to do significat changes to the configuration language. We may do a few more changes with the goal to get something that is extensible, nice, and consistent. This is the final name change for a tool that became very powerful and grew out of its roots, hopefully.

The rest of Reyk's message follows...

if you run the OpenBSD upgrade process, it will keep the old hoststated/hoststatectl binaries, which allows you to keep the old configuration while you're migrating from hoststated.conf to the new relayd.conf format. but i strongly advise to get rid of grumpy old hoststated!

to get an impression about the language changes, have a look at relayd.conf(5), see src/etc/relayd.conf, and view the differences in the OpenBSD CVS tree with:
        cvs diff -Nup -r1.10 -r1.11 src/etc/relayd.conf
(it will take some time to sync it to the anoncvs servers).

reyk

Below are the relevant commit messages Reyk quoted:

CVSROOT:	/cvs
Module name:	src
Changes by:	reyk@	2007/12/08 10:07:09

Modified files:
	etc            : relayd.conf 
	usr.sbin/relayd: parse.y relay.c relayd.8 relayd.c relayd.conf.5 
	                 relayd.h 
	usr.sbin/relayctl: relayctl.8 

Log message:
some changes to the relayd.conf configuration language and grammar.

the tables will look more like pf tables, it is easier to re-use
tables with different options, "services" will become "redirections"
(they refer to rdr pf rules), sync configuration directives of
redirect (l3, ex-service) relay (l7) sections (for example "virtual
host" will become "listen on"), all target definitions will start with
"forward to", etc. pp. (see relay.conf(5) and etc/relayd.conf)

discussed with pyr and deraadt
ok pyr@

CVSROOT:        /cvs
Module name:    src
Changes by:     deraadt@ 2007/12/07 10:27:07

Removed files:
        usr.sbin/hoststatectl: Makefile hoststatectl.8 hoststatectl.c
                               parser.c parser.h
        usr.sbin/hoststated: Makefile buffer.c carp.c check_icmp.c
                             check_script.c check_tcp.c control.c hce.c
                             hoststated.8 hoststated.c hoststated.conf.5
                             hoststated.h imsg.c log.c name2id.c parse.y
                             pfe.c pfe_filter.c relay.c relay_udp.c
                             ssl.c ssl_privsep.c

Log message:
hoststated/hoststatectl get repository copied (and de-tagged) into
relayd/relayctl.  This is a more suitable place for a daemon that has
grown out of it's initial roots of "monitoring and redirecting services
at various layers", into one that is "a full featured proxy, which
happens to know what is up/down"

(Comments are closed)


Comments
  1. By Matthew Dempsky (69.232.192.140) matthew@dempsky.org on

    relayd looks really slick. Right now we use nginx for our HTTP relaying, and we heavily rely on its ability to relay HTTP requests to different ip:port's depending on the request path. Does relayd support this too? I've looked over the relayd.conf(5) man page for the past few minutes, and I get the impression that currently it does not, but hopefully someone will correct me. :-)

    Comments
    1. By Darrin Chandler (dwc) on http://www.stilyagin.com/darrin/

      > relayd looks really slick. Right now we use nginx for our HTTP relaying, and we heavily rely on its ability to relay HTTP requests to different ip:port's depending on the request path. Does relayd support this too? I've looked over the relayd.conf(5) man page for the past few minutes, and I get the impression that currently it does not, but hopefully someone will correct me. :-)

      Right now nginx does some things that hostst^Wrelayd doesn't, and vice versa. Remember that relayd is still pretty new, and under *very* active development. I'd expect to see some more of what nginx can do make it into relayd some time in the future.

      That said, relayd and nginx are not aimed at quite the same goals, so there will probably always be times to pick one over the other. Relayd is the more general tool, and I expect to use it more in the long run.

    2. By Reyk Floeter (212.202.20.73) reyk@openbsd.org on http://team.vantronix.net/~reyk/

      > relayd looks really slick. Right now we use nginx for our HTTP relaying, and we heavily rely on its ability to relay HTTP requests to different ip:port's depending on the request path. Does relayd support this too? I've looked over the relayd.conf(5) man page for the past few minutes, and I get the impression that currently it does not, but hopefully someone will correct me. :-)

      it is on our list... :)

      - there is a "mark" action in relayd to match specific content (like a request path). i'm working on using this "mark" to select an alternative target table; for example you're able to match mostly anything in the HTTP request (like the virtual host in the "Host:" header), mark it, and it will be possible to forward sessions to a target pool of hosts based on its mark. most of the code is already done.

      - all hosts in a table currently have to share the same port. but i'm aware that some web services like ruby-on-rails use a number of ports on a single host. this would need some changes in the pf table code and is a little bit complicated to do.

      Comments
      1. By Matthew Dempsky (69.232.198.66) matthew@dempsky.org on

        > > relayd looks really slick. Right now we use nginx for our HTTP relaying, and we heavily rely on its ability to relay HTTP requests to different ip:port's depending on the request path. Does relayd support this too? I've looked over the relayd.conf(5) man page for the past few minutes, and I get the impression that currently it does not, but hopefully someone will correct me. :-)
        >
        > it is on our list... :)
        >
        > - there is a "mark" action in relayd to match specific content (like a request path). i'm working on using this "mark" to select an alternative target table; for example you're able to match mostly anything in the HTTP request (like the virtual host in the "Host:" header), mark it, and it will be possible to forward sessions to a target pool of hosts based on its mark. most of the code is already done.
        >
        > - all hosts in a table currently have to share the same port. but i'm aware that some web services like ruby-on-rails use a number of ports on a single host. this would need some changes in the pf table code and is a little bit complicated to do.
        >

      2. By Matthew Dempsky (69.232.198.66) matthew@dempsky.org on

        (Ugh, I had a problem with the captcha timing out, and didn't notice my message was reset when I reloaded the page. Sorry about that stupid mispost. :-()

        > it is on our list... :)

        Awesome.

        > - all hosts in a table currently have to share the same port. but i'm aware that some web services like ruby-on-rails use a number of ports on a single host. this would need some changes in the pf table code and is a little bit complicated to do.

        For what it's worth, all of our backend servers for a particular path listen on the same port number, so it'd suffice to just be able to say ``forward requests for /foo/bar to <blah> port 8000; forward requests for /quux to <frobnitz> port 8001''. (Just remembering which groups of hostnames manage which URLs is hard enough without needing to also remember unique ports for each of them. :P)

        Looking over our nginx.conf, the only other ngingx features we use that stand out are serving static files, adding HTTP authentication, fastcgi, and URL-rewrite/HTTP-redirecting. Of course, as long as we had path-dependent redirects, we could handle these on the backend servers still using nginx or something. (I only mention them in case you're looking for other potential features to add.)

        Thanks!

        Comments
        1. By Reyk Floeter (212.202.20.73) reyk@openbsd.org on http://team.vantronix.net/~reyk/

          > For what it's worth, all of our backend servers for a particular path listen on the same port number, so it'd suffice to just be able to say ``forward requests for /foo/bar to <blah> port 8000; forward requests for /quux to <frobnitz> port 8001''. (Just remembering which groups of hostnames manage which URLs is hard enough without needing to also remember unique ports for each of them. :P)
          >

          yes, this will be possible with something like

          request path mark "/foo/bar" with 1
          request path mark "/quux" with 2
          ...
          forward to <blah> port 8000 marked 1
          forward to <frobnits> port 8001 marked 1

          (i may allow symbolic names for marks, just like pf tags)

          > Looking over our nginx.conf, the only other ngingx features we use that stand out are serving static files, adding HTTP authentication, fastcgi, and URL-rewrite/HTTP-redirecting. Of course, as long as we had path-dependent redirects, we could handle these on the backend servers still using nginx or something. (I only mention them in case you're looking for other potential features to add.)
          >

          i do not want to turn relayd into a webserver.

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


            > > Looking over our nginx.conf, the only other ngingx features we use that stand out are serving static files, adding HTTP authentication,

            I'm currently working on on the fly HTTP authentication.
            As reyk said the other features are more in the scope of a web server.

  2. By Anonymous Coward (24.37.242.64) on

    This is great! I love this and ifstated too, very, very useful things! I have to see more of the new changes...

    According to the post, there should be a relay.conf(5) but I only see relayd.conf(5) on openbsd.org, is it just a matter of time to sync it there? I'm curious to read both man pages.

    Thanks for the GREAT work, worth every dollar I can afford to donate!

    Comments
    1. By Anonymous Coward (76.123.120.40) on

      > According to the post, there should be a relay.conf(5) but I only see relayd.conf(5) on openbsd.org, is it just a matter of time to sync it there? I'm curious to read both man pages.
      Looks like a typo. There are relayd.conf(5) relayd(8) and relayctl(8).

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.]