Quoth Jordan Geoghegan <[email protected]>: > > > On 11/5/25 11:17, Marc Chantreux wrote: > > On Wed, Nov 05, 2025 at 01:43:30PM -0000, Stuart Henderson wrote: > >> On 2025-11-05, Christoph Liebender <[email protected]> wrote: > >>> I'm currently trying to migrate my nginx setup to relayd > >> why? > >> if you want to avoid nginx, I suggest looking at haproxy. > > why? This is not a rethorical question: maybe I chose it for bad > > reasons? > > > > I'm an openBSD almost newbie and chose relayd because relayd is > > default and I had the intuition that relayd, httpd and pf are designed > > to work together in a modular way so it was the idiomatic choice. > > > > I have to admit It wasn't as easy as I expected to dive in but I blamed > > my complete openBSD inexperience (no previous pf usage). I think I > > now have a better understanding about how it works and my next step is > > to setup SSL (if I correctly understand it, what I want is relayd to > > deal with the encrypted trafic from/to internet and the local traffic is > > plain). > > > > I have to admit a more didactic documentation is missing but my real > > question is: is there a problem with relayd itself ? is it unmaintained? > > suffer a bad design? have performance or consumption problem? > > If so, why is it still default? > > > > Regards, > > > relayd certainly has it's shortcomings, and some big names here in the > community can be rather vocal about their distaste for it, but I thought > I'd chime in with my two cents. > > I've used relayd fairly extensively for a number of years now. relayd is > meant for simple use cases. My needs are relatively simple, so it fits > nice. > > I use relayd for health checking, carp demotion, manipulating headers, > tcp proxying and basic WAF things. As Stuart mentioned, for simple TCP > proxying leveraging the "socket splicing" feature, it can be blazing > fast - I would know, I've abused relayd in this capacity. > > I also appreciate how simple it is to implement tag based policies in > relayd. It may be idiosyncratic to some, but for my brain, it flows nice > and is similar to implementing pf tag based policies (which I also make > heavy use of). > > For example, on a Roundcube install I manage I needed to block certain > sensitive paths and wanted to cut down on the spew from the LLM bot > tidal wave. With just a handful of lines I've got some nice basic WAF > functionality: > > match request header "User-Agent" value "*Mozilla*" tag AGENT > match request path file "/etc/relayd/roundcube.blocklist" tag BADPATH > match request header "User-Agent" file "/etc/relayd/useragent.blocklist" > tag BADBOT > match request header "Host" value "webmail.example.com" tagged AGENT tag > ALLOWED > pass tagged ALLOWED > > $ cat /etc/relayd/useragent.blocklist /etc/relayd/roundcube.blocklist > *Bot* > *bot* > *Monit* > *Seekport* > ... > $ cat /etc/relayd/useragent.blocklist /etc/relayd/roundcube.blocklist > /INSTALL > /SQL/* > /vendor/* > ... > > httpd+relayd has a fraction of the lines of code and buttons to push > and knobs to turn that nginx, caddy or HA Proxy have. It's just a > seemingly bulletproof static or simple FastCGI hosting solution. > > In short, I just really really like OpenBSD style config files and > syntax, and I simply far prefer managing software that is configured in > that style. I'm very grateful that relayd + httpd exist. I hope they get > the love they deserve and a new maintainer and ideally some more > informative documentation (why no mention of relayd SNI support anywhere > in man pages?!). >
oh it's there in relayd.conf(5) under Protocols > tls option > keypair name. it's titled "TLS Server Name Indication" in there. we should add " (SNI)" afterwards tbh so it's easier to grep for. > But of course you have to be realistic, if relayd is missing a button or > knob you need to get the job done, then go use what works for your use > case. > > Regards, > > Jordan -- noodle
