agreed, but the proxypass UI is not maybe the good tool, a rpm with the vhost reverse configuration could be done.
No, on the contrary, there should be NO seperate RPM which magically creates some hidden configrations which intereferes with your manually created other reverse proxy entries. This leads to endles debugging sessions, which I had until I found hidden configuration files left over after package deinstalls.
The ONLY correct way is to enable to reverse proxy UI to reverse proxy all services of a to NS to a backend NS. Possible limitations (like âtarget must use httpsâ which is actualy a bug in my opinion) and caveats (like "ensure correct public webtop URL in the backend server) should be documented in the documenation.
It is not neccessary to describe the general concecpt of how to reverse proxy at all, but would be a good option to give examples for webtop, nextcloud and matterhost. This includes the URs are mapped correctly (e.g. not webtop/webtop), or that the certificates have to be created in the frontend not in the backend.
1 Like
to recap
- the reverse proxy to a local websocket works (tested mattermost, webtop)
- the reverse proxy to a remote websocket works for webtop if you add the proxied domain to PublicUrl and DavServerUrl
- I cannot make it workable for mattermost, I think it is something internal because I got a 403 error
I tend to think the configuration is valid but some apps cannot works like this, so at this point my mind is split.
- close the PR because it cannot work in most of 99.9999999999% of cases (I am kidding)
- Use the SME Server way, make it workable only by a hidden esmith property, at least until we could be sure it is fully workable
Currently there is not a single hint that the option is not working. All problem disussed u ntil now came from wrong configurations or the fact that the NS application are not too easy to reverse proxy at all. This is however another issue which should be solved in the way I outlined before. Currently it work for be with webtop and nextcloud, and it will also work with other applications. So leave the option visible, close the issue.
The other issue that reverse proxing NS applications is not to easy in general should be a seperate task.
We reached an agreement, this feature will be released inside the proxypass UI, maybe we have to test it a bit more
4 Likes
We have a working implementation thanks to @stephdl work!
Probably, the feature will be marked as experimental, but before taking the final decision we need your feedback!
So, please try the packages from the PR:
yum install -y http://packages.nethserver.org/nethserver/7.8.2003/autobuild/x86_64/Packages/nethserver-httpd-3.10.11-1.16.pr82.g70ba85e.ns7.noarch.rpm http://packages.nethserver.org/nethserver/7.8.2003/autobuild/x86_64/Packages/nethserver-httpd-proxypass-3.10.11-1.16.pr82.g70ba85e.ns7.noarch.rpm http://packages.nethserver.org/nethserver/7.8.2003/autobuild/x86_64/Packages/nethserver-httpd-virtualhosts-3.10.11-1.16.pr82.g70ba85e.ns7.noarch.rpm
To revert the changes:
yum downgrade nethserver-httpd nethserver-httpd-proxypass nethserver-virtualhosts
Please @carsten @royceb @djx test it and report your feedback!
2 Likes
oO that really came just about the time I needed. Thanks all.
Just a question. If websocket listens to more than 1 path (e.g /wss and /websock) is there any way to include them all in the path rule?
Also the yum downgrade seems not to work
yum downgrade nethserver-httpd nethserver-httpd-proxypass nethserver-virtualhosts
Loaded plugins: changelog, fastestmirror, nethserver_events
No Match for available package: nethserver-virtualhosts-1.0.6-1.ns7.noarch
Resolving Dependencies
â Running transaction check
â> Package nethserver-httpd.noarch 0:3.10.11-1.ns7 will be a downgrade
â> Package nethserver-httpd.noarch 0:3.10.11-1.16.pr82.g70ba85e.ns7 will be erased
â> Package nethserver-httpd-proxypass.noarch 0:3.10.11-1.ns7 will be a downgrade
â> Package nethserver-httpd-proxypass.noarch 0:3.10.11-1.16.pr82.g70ba85e.ns7 will be erased
â Finished Dependency Resolution
Error: Package: nethserver-httpd-virtualhosts-3.10.11-1.16.pr82.g70ba85e.ns7.noarch (@/nethserver-httpd-virtualhosts-3.10.11-1.16.pr82.g70ba85e.ns7.noarch)
Requires: nethserver-httpd >= 3.10.11-1.16.pr82.g70ba85e.ns7
Removing: nethserver-httpd-3.10.11-1.16.pr82.g70ba85e.ns7.noarch (@/nethserver-httpd-3.10.11-1.16.pr82.g70ba85e.ns7.noarch)
nethserver-httpd = 3.10.11-1.16.pr82.g70ba85e.ns7
Downgraded By: nethserver-httpd-3.10.11-1.ns7.noarch (nethserver-updates)
nethserver-httpd = 3.10.11-1.ns7
Available: nethserver-httpd-3.9.0-1.ns7.noarch (nethserver-base)
nethserver-httpd = 3.9.0-1.ns7
Available: nethserver-httpd-3.10.0-1.ns7.noarch (nethserver-updates)
nethserver-httpd = 3.10.0-1.ns7
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Btw reverted back by doing the below
yum install -y http://packages.nethserver.org/nethserver/7.8.2003/base/x86_64/Packages/nethserver-httpd-3.9.0-1.ns7.noarch.rpm http://packages.nethserver.org/nethserver/7.8.2003/base/x86_64/Packages/nethserver-httpd-proxypass-3.9.0-1.ns7.noarch.rpm http://packages.nethserver.org/nethserver/7.8.2003/base/x86_64/Packages/nethserver-httpd-virtualhosts-3.9.0-1.ns7.noarch.rpm
yum update
Welcome to NethServer community 
Not from the UI, but if you do not specify the path, the rewrite rule could already do some magic for you.
Just try it and see how it goes 
1 Like
Nobody wants to test this new feature?
I hope that someone would spend few minutes on it during the weekend! 
i would love to test, but i am not sure what i would be testing exactly in this case. So ill let those with more experience
1 Like
This is to test to see if the reverse proxy functions with web-services that utilize web sockets (FreeNas/Xen Orchestra are two off the top of my head that Iâve experienced).
Give me some time today @giacomo and Iâll test it out via ns droplets. All my server hardware right now is waiting for their new fiber line to be hooked up by the end of July 
2 Likes
Hi Giacomo
Was the whole week in Germany not far from Frankfurt and had today a big Demo with Proxmox, NethServer and OPNsense. The client group were VERY Happy with the whole thing!
@alefattorini
They liked the whole show that much I might be able to convince them to become Partners of Nethesis, time will show⊠They are much bigger than me and my clients - and it could be a real win win for both!
Iâm headed home tomorrow, but itâs still a 6 hour trip. But Sunday I can test this!
My 2 cents
Andy
1 Like
Worked as expected with the upgrade instructions; before vs after. Excellent work and super easy to configure and deploy. Thank you for all of the hard work you all put into NethServer.
3 Likes
Thank you @royceb for testing!
Since this was a scenario to cover, Iâd proceed with the merge and move the package toward the release! 
Thanks to work of the community, everything is in testing!
I think we can release thanks to Rocye testing, but @carsten would you like to give it the last try?
Youâre the one who was proposing the feature
1 Like
Yes, it works fine, well done. However the extra option for the websocket path does not make any sense and leads to confusion of users and potentional misbehaviour of the proxy. The rewrite rule parser is used to determinate whether a websocket upgrade has been requested and determines the path automatically. There is NO possiblility for the path to ever make sense. It either contains the correct value which the rewrite rule already determined or does not work. So I would suggest removing this option, because it makes no sense.
In theory the rewrite is somewhat slower than ProxyPass, so IF you want to use the path (but keep in mind, that there could be multiple websocket paths, so the single path cannot work here either), then do use Proxypass instead of the rewrite and do no parsing with the rewrite module at all.
So I strongly suggest removing this option!
Another option is missing however to proxy widespread applications: flushpackets=on
It is needed for Guacamole for example as an option to the proxypass statement. So either make another check box or have a âcustom proxypass optionsâ field where one can enter the proxypass options completely yourself.
Currently âmax=3 retry=30â is added automatically for every reverse proxy without the possiblilty to change it. Having an âcustom proxypass optionâ could add other fields like âflushpackets=onâ and also remove or change the default of max and retry (which should also be not set for guacamole).
If âcustom proxypass optionâ is empty, just add the default like now, but when it is not empty append the option to the proxypass statement. With this change,also guacamole could be reversed proxied with the Nethserver GUI. So maybe you change/rename the superflues option to this new one.
Guacamole is currently the only application where I have to use a custom template.
Currently nethserver generates:
ProxyPass /guacamole http://192.168.42.16:8080/guacamole max=3 retry=30
But Guacamole needs:
ProxyPass /guacamole http://192.168.42.16:8080/guacamole flushpackets=on
2 Likes
I simplified the template 30ProxyPass, corrected the order of rewrite and proxypass statements and extended it with the feature âcustom proxy pass optionsâ, by misusing the variable, which shoud be renamed. Now all my reverse proxy entries including guacmole with with the UI. For guacamole I have to put âflushpackets=onâ on the option âcustom-proxypass-opionâ (now named WebSocketsPath).
{
my $proxypassoptions=$WebSocketsPath;
if (proxypassoptions eq '') { $proxypassoptions='max=3 retry=30'; }
if ($WebSockets eq 'enabled' ) {
my $ws = $Target =~ s/^http/ws/r;
$OUT .= " # Websockets proxypass\n";
$OUT .= " RewriteCond \%\{HTTP:Upgrade\} websocket [NC]\n";
$OUT .= " RewriteCond \%\{HTTP:Connection\} upgrade [NC]\n";
$OUT .= " RewriteRule .* ${ws}\%\{REQUEST_URI\} [P,L]\n\n";
}
my $target = $Target =~ s|/*$|/|r;
$OUT .= " # Reverse Proxy (with exclusion of local Letsencrypt challenge path)\n";
$OUT .= " ProxyPassMatch ^/.well-known/acme-challenge/ !\n";
$OUT .= " ProxyPass / $target $proxypassoptions\n";
$OUT .= " ProxyPassReverse / $target\n";
}The feature has been released! 
Adding an extra option could be cool, but watch out for validation.
When you have something that could do the job, please open a PR!
Sorry for the late reply, but the option WebProxyPath should be removed. It is totally useless. We are still in testing, so corrections should be possible before this code hits the public.