Migrating nginx config to OpenBSD's httpd

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating nginx config to OpenBSD's httpd

Carlos López
Hi all,

 I am trying to migrate nginx configuration to OpenBSD's httpd. All it is
working ok, except for some proxy reverse config that I use with nginx's
config, like for example:

server {
    listen 80;
    server_name internal.w01.domain.org;

    location / {
        proxy_pass http://192.168.30.4;
    }
}

 I don't see what is the option to use with httpd.conf or is it best
option to use relayd.conf for this type of configs?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Pavel Korovin
Hi Carlos,

There's no analog of proxy_pass in httpd(8). relayd(8) is your friend.

On 04/13, C. L. Martinez wrote:

>  I am trying to migrate nginx configuration to OpenBSD's httpd. All it is
> working ok, except for some proxy reverse config that I use with nginx's
> config, like for example:
>
> server {
>     listen 80;
>     server_name internal.w01.domain.org;
>
>     location / {
>         proxy_pass http://192.168.30.4;
>     }
> }
>
>  I don't see what is the option to use with httpd.conf or is it best
> option to use relayd.conf for this type of configs?

--
With best regards,
Pavel Korovin

Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Bogdan Kulbida
Hi Carlos,

HAproxy project exists and serves much better as load balancer and reverse
proxy server. It is more efficient than engine X. Any concerns using it?

- Bogdan

On Fri, Apr 13, 2018 at 04:47 Pavel Korovin <[hidden email]> wrote:

> Hi Carlos,
>
> There's no analog of proxy_pass in httpd(8). relayd(8) is your friend.
>
> On 04/13, C. L. Martinez wrote:
> >  I am trying to migrate nginx configuration to OpenBSD's httpd. All it is
> > working ok, except for some proxy reverse config that I use with nginx's
> > config, like for example:
> >
> > server {
> >     listen 80;
> >     server_name internal.w01.domain.org;
> >
> >     location / {
> >         proxy_pass http://192.168.30.4;
> >     }
> > }
> >
> >  I don't see what is the option to use with httpd.conf or is it best
> > option to use relayd.conf for this type of configs?
>
> --
> With best regards,
> Pavel Korovin
>
> --

---
Best regards,
Bogdan Kulbida
CEO/CTO, Konstankino LLC <http://konstankino.com>
+1.802.793.8295
Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Henrik Friedrichsen
In reply to this post by Pavel Korovin
On Fri, Apr 13, 2018 at 02:30:18PM +0300, Pavel Korovin wrote:
> Hi Carlos,
>
> There's no analog of proxy_pass in httpd(8). relayd(8) is your friend.

So far I have not been able to emulate proxy_pass with relayd.

I came across two issues:
- relayed HTTP requests resulted in cut off responses, similar to this
  issue: https://github.com/reyk/relayd/issues/12
- I have not been able to come up with a configuration/filter setting
  that will only match for a specific subdomain and will pass the
  non-matching requests to the regular httpd listening on port 80

Did anyone have success in setting this up?


Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Pavel Korovin
Henrik,

Regarding cut off responses, I didn't have such problems, maybe it was fixed
since 2016.

Regarding multi-site setup, I have something like this:

--- httpd.conf ---
### default site behind relayd
server "waste.tristero.se" {
    alias "tristero.se"
    listen on 127.0.0.1 port 80
    listen on ::1 port 80
    root "/htdocs/waste.tristero.se"
}

server "openbsd.tristero.se" {
    listen on 127.0.0.1 port 80
    listen on ::1 port 80
    root "/htdocs/openbsd.tristero.se"
}

### this one is not behind relayd, used for http to https redirection
server "waste.tristero.se" {
    alias "openbsd.tristero.se"
    alias "tristero.se"
    listen on 188.244.46.111 port 80
    listen on 2001:470:1f15:1492::2 port 80
    root "/htdocs/waste.tristero.se"
    block return 301 "https://$HTTP_HOST/$DOCUMENT_URI"
}

--- relayd.conf ---

ext4="188.244.46.111"
ext6="2001:470:1f15:1492::2"
localhost4="127.0.0.1"
localhost6="::1"

table <openbsd4> { $localhost4 }
table <openbsd6> { $localhost6 }
table <waste4> { $localhost4 }
table <waste6> { $localhost6 }

http protocol "https4" {
    match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
    match request header set "X-Forwarded-By" value "[$SERVER_ADDR]:$SERVER_PORT"
    match request header "Host" value "tristero.se" forward to <waste4>
    match request header "Host" value "waste.tristero.se" forward to <waste4>
    match request header "Host" value "openbsd.tristero.se" forward to <openbsd4>
    tls { no tlsv1.0, ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+SHA256:EECDH+SHA384:ECDHE+SHA256 }
}

http protocol "https6" {
    match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
    match request header set "X-Forwarded-By" value "[$SERVER_ADDR]:$SERVER_PORT"
    match request header "Host" value "tristero.se" forward to <waste6>
    match request header "Host" value "waste.tristero.se" forward to <waste6>
    match request header "Host" value "openbsd.tristero.se" forward to <openbsd6>
    tls { no tlsv1.0, ciphers EECDH+AESGCM:EECDH+CHACHA20:EECDH+SHA256:EECDH+SHA384:ECDHE+SHA256 }
}

relay "https4" {
    listen on $ext4 port 443 tls
    protocol "https4"
    forward to <openbsd4> port 80
    forward to <waste4> port 80
}

relay "https6" {
    listen on $ext6 port 443 tls
    protocol "https6"
    forward to <openbsd6> port 80
    forward to <waste6> port 80
}

--- end cut ---

The only problem I have was configuring specific security headers for
specific hosts, i.e. I cannot have specific http protocol sections with
different responses for specific hosts, like:

http protocol "https4-flex" {
    match request header "Host" value "not-secure.domain" forward to <backend-site1>
    match response header set "Content-Security-Policy" value "<flex-policy-rules-follow>"
}
http protocol "https4-strict" {
    match request header "Host" value "secure.domain" forward to <backend-site2>
    match response header set "Content-Security-Policy" value "<strict-policy-rules-follow>"
}

--
With best regards,
Pavel Korovin

On 04/16, Henrik Friedrichsen wrote:

>
> So far I have not been able to emulate proxy_pass with relayd.
>
> I came across two issues:
> - relayed HTTP requests resulted in cut off responses, similar to this
>   issue: https://github.com/reyk/relayd/issues/12
> - I have not been able to come up with a configuration/filter setting
>   that will only match for a specific subdomain and will pass the
>   non-matching requests to the regular httpd listening on port 80
>
> Did anyone have success in setting this up?

Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Henrik Friedrichsen
Hey Pavel,

thanks for your response. I have adapted my configuration and came up
with this:

<SNIP>
ext4="51.15.10.194"
ext6="2001:bc8:2d08::1"

table <monit> { "127.0.0.1" }
table <httpd> { "127.0.0.1" }

http protocol "monit" {
    match request header "Host" value "status.affekt.org" forward to <monit>
    match request header "Host" value "affekt.org" forward to <httpd>
}

relay "proxy" {
    listen on $ext4 port 80
    protocol "monit"
    forward to <monit> port 2812
    forward to <httpd> port 80
}
</SNIP>

I have a local monit instance listening on 127.0.0.1:2812

This configuration works, sort of:
- Is there a way to match all hosts that are not "status.affekt.org"?
  That way I don't have to write a filter rule for every subdomain
- Relayed HTTP output is cut off. As you can see below the HTTP DOM is not
  closed and most of the HTTP response headers are missing (status code,
  content-length, etc.)

Any idea what I'm doing wrong?

Thanks!

hera ~ % curl -v "http://status.affekt.org/"
*   Trying 51.15.10.194...
* TCP_NODELAY set
* Connected to status.affekt.org (51.15.10.194) port 80 (#0)
> GET / HTTP/1.1
> Host: status.affekt.org
> User-Agent: curl/7.58.0
> Accept: */*
>
Connection: close
Content-Type: text/html
WWW-Authenticate: Basic realm="monit"

* Connection #0 to host status.affekt.org left intact
<html><head><title>401 Unauthorized</title></head><body
bgcolor=#FFFFFF><h2>Unauthorized</h2>You are not authorized to access
monit. Either you supplied the wrong credentials (e.g. bad password), or
your browser doesn't understand how to supply the credentials required


Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Pavel Korovin
On 04/16, Henrik Friedrichsen wrote:
> - Is there a way to match all hosts that are not "status.affekt.org"?
>   That way I don't have to write a filter rule for every subdomain

Didn't test, just the idea:

1. You put your default host (i.e. one that will respond to all http
requests which do not fall into specific configurations) first in
httpd.conf.

2. In relayd configure http protocol like this:
http protocol "monit" {
     match request header "Host" value "status.affekt.org" forward to <monit>
     forward to <httpd> port 80
}

So the requests that match Host header will go to monit, all other
requests will go to httpd, where default site will respond.

> - Relayed HTTP output is cut off. As you can see below the HTTP DOM is not
>   closed and most of the HTTP response headers are missing (status code,
>   content-length, etc.)
>
> Any idea what I'm doing wrong?
 
I guess something is wrong on monit side.. I set up relayd with varous stuff
in the backend, but have seen anything like this.
 
--
With best regards,
Pavel Korovin

Reply | Threaded
Open this post in threaded view
|

Re: Migrating nginx config to OpenBSD's httpd

Henrik Friedrichsen
Thanks again.

This worked in case anyone is looking for it:

http protocol "monit" {
    match request forward to <httpd>
    match request header "Host" value "status.affekt.org" forward to <monit>
}

The order is important, if put in reversed the "status.affekt.org"
forward will be overwritten.

Now all I need to investigate is why HTTP responses are erroneous,
though you might be right that it could be a Monit problem.