HAProxy path problem (truenas ui + webdav port)
-
Hi. This looks like a simple problem to solve but no clear method written up for a newbie. SSL offloading is configured firstly.
Two use cases: truenas web ui PLUS a webdav directory listing ("/a") like so...
(1) truenas.domain.com -> nas.domain.com:443
(2) truenas.domain.com/a -> nas.domain.com:8081/aNow (1) works as expected, in that the browser eventually sees truenas.domain.com/ui/sessions/signin (ie. the sign in page if you're not signed in, and if you are signed in, the main landing page). There is an underlying rewrite but truenas does it.
(2) gives me "503 service unavailable". This is the PROBLEM.
What I have is as follows:
two backends:
name: truenas
address: nas.domain.com
port: 443
enc: yesname: truenas_webdav
address: nas.domain.com
port: 8081
enc: yesno ACLs or actions defined in backends.
Next, frontend:
ACLs
name: truenas
exp: host matches
not: no
value: truenas.domain.comname: truenas_a_1
exp: path matches
not: no
value: /aname: truenas_a_2
exp: path starts with
not: no
value: /a/name: truenas_a_1_neg
exp: path matches
not: yes
value: /aname: truenas_a_1_neg
exp: path starts with
not: yes
value: /a/then, actions (frontend)
use backend truenas
cond: truenas truenas_a_1_neg truenas_a_2_neguse backend truenas_webdav
cond: truenas_webdav truenas_a_1 truenas_a_2So I thought these conditions would be explicit enough (if I translate all the above to logic). I was wrong.
I read posts where they talk about putting the negative rules, setting or replacing paths, playing around with rules in front as well as back, using custom rules, regexes, etc. To no avail.
What is missing from the config? The real end points do work independently, albeit with the expected cert warning.
Could the automatic /ui/ redirect be interfering?Learning from these refs:
- https://www.haproxy.com/blog/path-based-routing-with-haproxy
- https://forum.netgate.com/topic/178410/how-to-make-haproxy-path-use-backend-including-links-scripts/4
- https://forum.netgate.com/topic/185542/haproxy-add-folder-path-to-backend-ip-address/2
- https://forum.netgate.com/topic/185741/configure-haproxy-backend-to-a-url-with-a-subdirectory
- https://serverfault.com/questions/982324/how-to-use-http-request-redirect-or-http-request-set-path-in-haproxy
-
@gurpal2000
Why don't you just use different host names instead of fighting with the path ACL. So you would as well have a friendly URL for both backends.But yes, it can also be done with the path if you want that.
However, I don't get your settings.
Can you post the whole config (from the bottom of the general page)?And also not clear, if the backend needs to see the path as well. This would suggest that it needs it:
(2) truenas.domain.com/a -> nas.domain.com:8081/a
-
@viragomann Yes using a different host name would work of course, and will most likely go down that path. (For example i might have a "files" host name and then any subdirectory will work fine if I have multiple shares.)
Sorry i don't know what you mean by "general page". But here are some screens. You can see the real/true hostnames now.
Yes I am not putting any rules on the backend. I wouldn't know why I would need to. I stopped playing around with set-path/replace-path/sub-this, sub-that. The below is the current state.
many thanks
-
@gurpal2000 said in HAProxy path problem (truenas ui + webdav port):
Sorry i don't know what you mean by "general page"
At the bottom of the "Settings" page you can see a "Show" button, which can be used to display the HAproxy settings.
I stopped playing around with set-path/replace-path/sub-this, sub-that. The below is the current state.
So does it work as expected now?
Consider that HAproxy will pass-through the paths you entered in the browser to the backends by default.
Therefor I asked if the backend device is expecting these paths.
If not you would have to remove them in HAproxy. -
@viragomann said in HAProxy path problem (truenas ui + webdav port):
the bottom of the "Settings" page you can see a "Show" button, which can be used to display the HAproxy settings.
No it is the current state as of the post. i get a 503 for use case (2). The way I understand the "rules" (acl) is that this is binary. If you put just the domain name you get (1). If you put /android on the end you get (2). The android directory will contain more files by the way (/android/**/*).
The backend device is expecting the path yes "/android" as that is the share name. let's assume there's only ever going to be one share by the way being served by port 8081.
The device only exposes port 443 and 8081 both https already.
config (obfuscated somewhat)
frontend frontend_domain_com bind 192.168.10.1:443 name 192.168.10.1:443 ssl crt-list /var/etc/haproxy/frontend_domain_com.crt_list mode http log global option http-keep-alive timeout client 30000 acl truenas var(txn.txnhost) -m str -i truenas.domain.com acl truenas_a_1 var(txn.txnpath) -m str -i /android acl truenas_a_2 var(txn.txnpath) -m beg -i /android/ acl truenas_a_1_neg var(txn.txnpath) -m str -i /android acl truenas_a_2_neg var(txn.txnpath) -m beg -i /android/ acl aclcrt_frontend_domain_com var(txn.txnhost) -m reg -i ^([^\.]*)\.domain\.com(:([0-9]){1,5})?$ http-request set-var(txn.txnhost) hdr(host) http-request set-var(txn.txnpath) path use_backend truenas_ipvANY if truenas !truenas_a_1_neg !truenas_a_2_neg aclcrt_frontend_domain_com use_backend truenas_webdav_ipvANY if truenas truenas_a_1 truenas_a_2 aclcrt_frontend_domain_com backend truenas_ipvANY mode http id 100 log global timeout connect 30000 timeout server 30000 retries 3 load-server-state-from-file global server truenas 192.168.10.9:443 id 101 ssl check inter 1000 verify none backend truenas_webdav_ipvANY mode http id 115 log global timeout connect 30000 timeout server 30000 retries 3 load-server-state-from-file global http-request replace-path /android\/?(.*) \/\1 server truenas_webdav 192.168.10.9:8081 id 101 ssl check inter 1000 verify none
thx
-
@gurpal2000 said in HAProxy path problem (truenas ui + webdav port):
No it is the current state as of the post. i get a 503 for use case (2).
So first off ensure that the frontend is shown up as 'online' on the StatsFS page.
You don't need necessarily an ACL for the host name. If the packets hit the frontend due to it's IP and port it is used.
The only one ACL you would need is "Path starts with", value = "/android".
Then at action add an action for this ACL to use the second backend.
The first backend can be set as default then.
-
@viragomann "first backend can be set as default then"
Using the "Default Backend" field?
I have only 1 catch-all frontend with a wildcard cert (*.domain.com). I don't think i can have more than one. -
@gurpal2000
We are talking about backends.There is a "Default Backend" setting in the frontend. This is used if no rule matches a traffic.
Howerver, you can as well add an action for the primary backend and negate the existing ACL.