haproxy | display DocumentRoot - (non)trivial?

[tn1rpi3]

HaProxy 1.7.11, pfsense 2.4.4-RELEASE-p3

I have a number of lxd vms waiting for deployment in the dmz.
pfsense has a working ACME certificate, haproxy front- and backends are in place.
Sites are organized in domain + subdomains (sub.main.TLD)
I can access all sites both locally and via WAN alright.

There is one little detail I can't figure out:
How can I get haproxy to serve the correct folder where the site is in?
I mean, in apache you'd simply set the DocumentRoot.
It sounds trivial, but instead of the site's content the browser shows the site's folder.

Now I did try a number of things, but nothing so far has worked out:
1.) I performed a "http-request set uri, fmt: /desired_folder"
--> result: error, too many redirects

2.) I tried a "reqirep ^([^\ :])\ /(.) \1\ /folder_name/\2" taken from this thread
--> result: the URL would then display correctly, but the page remains emtpty.

Question:
What's the best practice to have haproxy display the DocumentRoot instead of a folder?

Thanks for any hints.

[PiBa]

@tn1rpi3
Best practice.. probably to have the webserver serve the website using the same virtual path as the client thinks its browsing to.?

As for the 'to-many-redirects', thats probably coming from the web-application as well. You will have to 'teach' / configure that application that its external url is actually your sub.main.tld ..

Edit:
Um actually the 'to-many-redirects' is more likely because of the original request uri that is 'lost'.. Something like
"http-request set path fmt: /desired_folder%[path]"
might work though..

[tn1rpi3]

@PiBa said in haproxy | display DocumentRoot - (non)trivial?:

Best practice.. probably to have the webserver serve the website using the same virtual path as the client thinks its browsing to.?

Hey, thanks for your reply.
OK then, one step at a time.
The sites all display correctly when opened locally.
So if I hit 192.168.xxx.xxx it would automatically jump to typo3/install.php as desired.
The prob persists via WAN, though.

I went for your suggestion concerning "http-request set path fmt: /desired_folder%[path]"
It delivers inconsistent results:
nc.12bfree.com would display entirely, but stripped of any color.
lime.12bfree.com throws a 404.
moodle.12bfree.com same same.
With 12bfree.com it's even 503 "Service unavailable"

I'm behind Cloudflare CDN. I'm not sure if this is a factor.
It appears to be working flawlessly.

Just to make sure I haven't bungled this up:
hostname -f -->
12bfree.com
cat /etc/hosts -->
192.168.xxx.xxx 12bfree.com 12bfree
cat /etc/apache2/sites-available/12bfree.com.conf | grep DocumentRoot -->
DocumentRoot /var/www/html
ls -lrt /var/www/html/ -->
-rw-r----- 1 www-data www-data 0 Jan 25 14:17 FIRST_INSTALL
-rw-r----- 1 www-data www-data 6154 Jan 25 14:19 README.md
-rw-r----- 1 www-data www-data 18425 Jan 25 14:19 LICENSE.txt
-rw-r----- 1 www-data www-data 1434 Jan 25 14:19 INSTALL.md
-rw-r--r-- 1 www-data www-data 1026 Jan 25 14:19 CONTRIBUTING.md
drwxr-xr-x 1 www-data www-data 66 Jan 25 14:19 typo3
With the other sites it's basically the same, except that they're in a subfolder of /var/www/html

At this point I kinda feel like a shovetail louie..
I can't think of what I'm overlooking here.

[PiBa]

@tn1rpi3

For https://nc.12bfree.com/ the main page indeed loads.. If you look at the developer\network screen of your browser (F12) and refresh the page you see that it tries to load some css and js files that all return a 404 not found code . For example this one is requested by the browser:
https://nc.12bfree.com/nc/core/js/dist/main.js
However we have configure haproxy to rewrite the request path so effectively it will request: https://nc.12bfree.com/nc/nc/core/js/dist/main.js from the webserver.. Which does not exist..

There are several different options that could possibly lead to a solution.. I think the 3rd option could possibly have the best overall effect.. assuming it doesn't break the web-application completely...

1- What we could perhaps do instead of rewriting the path for all requests is to only do that for the first page? So create a 'acl' that will check if the 'path equals /' and then make the 'set-path' action check for that acl.
Something like this in haproxy.cfg (didnt check syntax..):

acl theRootWasRequested path -m str /
http-request set-path /nc%[path] if theRootWasRequested

2- Or perhaps you could use a redirect in haproxy, and not rewrite paths at all?

acl theRootWasRequested path -m str /
http-request redirect /nc if theRootWasRequested

3- Or perhaps change the webserver itself to have the DocumentRoot /var/www/html/nc to include the desired webpage path?

[PiBa]

@tn1rpi3
Probably the redirected path isnt the way to go for these:
lime.12bfree.com throws a 404.
moodle.12bfree.com same same.

With 12bfree.com it's even 503 "Service unavailable"
Check the status page of haproxy, i think it will show the server with a 'red' line as being 'down' ? Figure out why that is, the lastchk column in stats should tell a bit.. haproxy_troubleshooting

[tn1rpi3]

@PiBa
I've been testing as suggested, looking at nc.12bfree.com
Here are the results with/without http-request set path fmt:/nc%[path] set:

set ACL --> 404, path is auto-directed to a blank page, nc.12bfree.com/nc/index.php/login
remove ACL --> displays site folder, manually typing /nc in browser --> site displays correctly
set ACL --> 404, path is auto-directed to blank page, nc.12bfree.com/nc/index.php/login

Needless to say that I cleared cookies in between.
Results are somewhat inconsistent because initially I got a 503 instead of a 404.

Changing the path within the webserver config has no effect at all.
I can even reference a fictitious path, which will not change the results alternating as shown above..
(This goes for WAN access. Via LAN a fictitious path will produce an expected 'not found'.)

How can the webserver path display the site flawlessly when called from local, but play no role at all via WAN?
(⊙_☉)

I'm not sure if I followed option 2 correctly:
I set up a custom acl with "path -m str /"
and added an action "http-request redirect /nc", to no avail..

[PiBa]

@tn1rpi3
Do you have IRC, i'm on FreeNode #pfSense perhaps we can talk there?

[PiBa]

@tn1rpi3
Can try this configuration?:

[tn1rpi3]

@PiBa Thanks for the offer. Will do.
What's your timezone? Mine is Europe/VIENNA.

[PiBa]

@tn1rpi3 My timezone: CET - Europe/Netherlands/Amsterdam
Only online during evenings and weekends though..

[tn1rpi3]

@PiBa You using same user name over at FreeNode?

[PiBa]

@tn1rpi3 I'm using 'PiBa-NL' there. Currently online ;).