More deployment choices (e. g. Nginx, FirewallD) #14

CL-Jeremy commented 2025年06月19日 23:51:59 +02:00

Fedora Server user here. Thanks for the effort of supporting Fedora/EL especially regarding. Just spent about a whole day working on deploying this on our existing setting (nginx-based) and the result was great, though I did have to wrap my head around the various differences between reverse proxy programs. (I'm attaching a minimal configuration file without the SSL certificate part for reference – I symlinked the /web asset folder into /var/www/vpn-user-portal to simplify this, otherwise an alias directive would be necessary).

On the other hand, I still haven't figured out the exact commands for firewall-cmd (partly because we don't use OpenVPN and bare WireGuard, so I didn't bother), so I ditched all the rules from firewalld and just used the nftables (included into the main config as a rule set stored in /etc). From a (corporate) system admin stand point, a guide/deployment path with firewall-cmd would be much appreciated, especially since openSUSE/SLES 15 have also moved to firewalld.

Granted, this issue/enhancement proposal could be raised in the docs repo, but I do think it's worth talking about in the context of deploy scripts and/or packaging (e. g. the multiple instances of apache user in RPM releases would need to be changed to also accept nginx, probably based on dependency matches). Hopefully I could find time to contribute to this if there is more interest.

Fedora Server user here. Thanks for the effort of supporting Fedora/EL especially regarding. Just spent about a whole day working on deploying this on our existing setting (nginx-based) and the result was great, though I did have to wrap my head around the various differences between reverse proxy programs. (I'm attaching a minimal configuration file without the SSL certificate part for reference – I symlinked the `/web` asset folder into `/var/www/vpn-user-portal` to simplify this, otherwise an `alias` directive would be necessary). On the other hand, I still haven't figured out the exact commands for `firewall-cmd` (partly because we don't use OpenVPN and bare WireGuard, so I didn't bother), so I ditched all the rules from `firewalld` and just used the `nftables` (included into the main config as a rule set stored in `/etc`). From a (corporate) system admin stand point, a guide/deployment path with `firewall-cmd` would be much appreciated, especially since openSUSE/SLES 15 have also moved to `firewalld`. Granted, this issue/enhancement proposal could be raised in the docs repo, but I do think it's worth talking about in the context of deploy scripts and/or packaging (e. g. the multiple instances of `apache` user in RPM releases would need to be changed to also accept `nginx`, probably based on dependency matches). Hopefully I could find time to contribute to this if there is more interest.

fkooman commented 2025年06月20日 10:01:02 +02:00

Hi,

Thank you for writing! It is nice to hear there are other Fedora users! It is mostly my testing and development platform! 😃

First firewalld:

When investigating firewall replacements for the old iptables and ended up with nftables, I looked into firewalld and really wanted to use it, but it is just too complex for the simple scenario. Two things I didn't manage to get working:

1. Using IPv6+NAT which is something I'd like to have out of the box
2. It was not easy to restrict e.g. SSH to only allowing connections from a certain IP prefixes

If those two things would have worked in a simple way, I'd have used that! Of course, that is assuming it also works on Debian/Ubuntu, which was another requirement, and I guess it was supported otherwise I'd never have looked into firewalld.

Perhaps things have changed! And those things are easy now? Then in time for the eduVPN 4.x server we can reconsider this and replace nftables with firewalld.

The other approach is indeed write documentation on how to switch to firewalld coming from the default nftables, I think that is actually a nice idea, and probably a first step anyway.

Regarding nginx:

Wow! That seems indeed like a lot of work to get that all working! Great! Regarding nginx a bit the same applies as with firewalld. Apache is terrible regarding configuration, but nginx is not substantially better, so I never really bothered to look into it in detail. If we could switch to something like OpenBSD's httpd, now that would be a big improvement I could get on board with 😉 But this has its own problems still.

That being said, I think many Fedora/EL packages have a sub package that includes either the Apache or the nginx configuration snippets that are then put in the right place. Is this an approach that could work? I see your snippet also contains (server wide) configuration options, that is not something that can fly when putting it in a sub package? Is it possible to limit the "scope" of those snippets to just vpn-user-portal like is done in the Apache snippet, see this?

From my perspective, and also from the project, it does not really make sense to support two web servers, especially because Apache supports authentication modules for SAML and OpenID Connect, which is something that is used (a lot) in the field. Not sure this is (easily) possible with nginx either, so we can't drop Apache from what I can see.

To summarize: it would be great to be able to support firewalld and nginx, but they lack features currently used by many deployments, or are/were? too complex to get working. If you are really interested in this, a first step would be (I guess) to create a script for switching to firewalld and a script to switch to nginx after the default deploy. We have an "acme" script already for deploying a TLS cert, so something along those lines would be a good indicator of how complex it is to switch, and whether or not it is possible to support this officially.

What do you think?

Hi, Thank you for writing! It is nice to hear there are other Fedora users! It is mostly my testing and development platform! 😃 First `firewalld`: When investigating firewall replacements for the old `iptables` and ended up with `nftables`, I looked into `firewalld` and really wanted to use it, but it is just too complex for the simple scenario. Two things I didn't manage to get working: 1. Using IPv6+NAT which is something I'd like to have out of the box 2. It was not easy to restrict e.g. SSH to only allowing connections from a certain IP prefixes If those two things would have worked in a simple way, I'd have used that! Of course, that is assuming it also works on Debian/Ubuntu, which was another requirement, and I guess it was supported otherwise I'd never have looked into `firewalld`. Perhaps things have changed! And those things *are* easy now? Then in time for the eduVPN 4.x server we can reconsider this and replace `nftables` with `firewalld`. The other approach is indeed write documentation on _how_ to switch to `firewalld` coming from the default `nftables`, I think that is actually a nice idea, and probably a first step anyway. Regarding `nginx`: Wow! That seems indeed like a lot of work to get that all working! Great! Regarding `nginx` a bit the same applies as with `firewalld`. Apache is terrible regarding configuration, but `nginx` is not substantially better, so I never really bothered to look into it in detail. If we could switch to something like OpenBSD's `httpd`, now that would be a big improvement I could get on board with 😉 But this has its own problems still. That being said, I think many Fedora/EL packages have a sub package that includes either the Apache or the nginx configuration snippets that are then put in the right place. Is this an approach that could work? I see your snippet also contains (server wide) configuration options, that is not something that can fly when putting it in a sub package? Is it possible to limit the "scope" of those snippets to just `vpn-user-portal` like is done in the Apache snippet, see [this](https://codeberg.org/eduVPN/vpn-user-portal.rpm/src/branch/v3/SOURCES/vpn-user-portal-httpd.conf)? From my perspective, and also from the project, it does not really make sense to support two web servers, especially because Apache supports authentication modules for SAML and OpenID Connect, which is something that is used (a lot) in the field. Not sure this is (easily) possible with nginx either, so we can't drop Apache from what I can see. To summarize: it would be great to be able to support `firewalld` and `nginx`, but they lack features currently used by many deployments, or are/were? too complex to get working. If you are really interested in this, a first step would be (I guess) to create a script for switching to `firewalld` and a script to switch to `nginx` after the default deploy. We have an "acme" script already for deploying a TLS cert, so something along those lines would be a good indicator of how complex it is to switch, and whether or not it is possible to support this officially. What do you think?

CL-Jeremy commented 2025年06月20日 13:36:30 +02:00

Thanks for the very quick and detailed reply! I do agree with most of these points. Just to clarify: I'm not by any means a professional server admin (started off doing this at the university faculty, and have been investigating eduVPN primarily for their sake, even though I'm not working there anymore). In fact I got exposed to Fedora in work environment because our computer pools and servers had it. To sum up: it's indeed my lacking the expertise that made me spend too long for this deployment. By opening this issue I just want to start an open discussion on these alternative options as I'm probably not alone on this, and this could potentially increase the adoption of ProxyGuard/eduVPN.

Also I'd like to make it clear I'm not asking about dropping Apache. It's just an idea from a packaging standpoint, with my own config as a starting point for potential work in the future. I'm fine either way with the outcome at this stage: it makes sense not to work on this for v3 - I very much understand the extra work related to maintaining this, and Nginx surely isn't without its own problems. However, I do believe that for those well versed in using nginx and firewalld, they can achieve feature and modularity parity with Apache.

Anyway, hoping for the best for this project! It solves real problems and is backed/blessed by the key public sector organisations ensuring its publicity. Really hope for more adoption in the future.

Thanks for the very quick and detailed reply! I do agree with most of these points. Just to clarify: I'm not by any means a professional server admin (started off doing this at the university faculty, and have been investigating eduVPN primarily for their sake, even though I'm not working there anymore). In fact I got exposed to Fedora in work environment because our computer pools and servers had it. To sum up: it's indeed my lacking the expertise that made me spend too long for this deployment. By opening this issue I just want to start an open discussion on these alternative options as I'm probably not alone on this, and this could potentially increase the adoption of ProxyGuard/eduVPN. Also I'd like to make it clear I'm not asking about *dropping* Apache. It's just an idea from a packaging standpoint, with my own config as a starting point for potential work in the future. I'm fine either way with the outcome at this stage: it makes sense not to work on this for v3 - I very much understand the extra work related to maintaining this, and Nginx surely isn't without its own problems. However, I do believe that for those well versed in using `nginx` and `firewalld`, they can achieve feature and modularity parity with Apache. Anyway, hoping for the best for this project! It solves real problems and is backed/blessed by the key public sector organisations ensuring its publicity. Really hope for more adoption in the future.

CL-Jeremy commented 2025年06月20日 13:51:30 +02:00

Also back to Fedora packaging: yes, separate packages for Apache and Nginx would be required to achieve my proposal of dependency-based selection. In fact, I only recently got to know about this solution with the lemonldap-ng package from the official Fedora repo. (LemonLDAP::NG is a Perl package to be used either with Apache or Nginx to provide modular web-based SSO. I was looking at it because I don't want to add Keycloak into the stack, but thankfully PHP has perfect LDAP integration already.) Again, this is just an idea for the community to consider.

Also back to Fedora packaging: yes, separate packages for Apache and Nginx would be required to achieve my proposal of dependency-based selection. In fact, I only recently got to know about this solution with the `lemonldap-ng` package from the official Fedora repo. (LemonLDAP::NG is a Perl package to be used either with Apache or Nginx to provide modular web-based SSO. I was looking at it because I don't want to add Keycloak into the stack, but thankfully PHP has perfect LDAP integration already.) Again, this is just an idea for the community to consider.

fkooman commented 2025年11月06日 10:35:27 +01:00

I'm closing this until someone 1) does the work, and 2) does not increase the overall complexity.

I'm closing this until someone 1) does the work, and 2) does not increase the overall complexity.