Nginx support

[Me.B]

**** The purpose of this thread to get your opinion and exchange over Nginx implementation  ****

**** It's still not on the roadmap ( short term)                                                                     ****


A lot of people are asking for Nginx or thinking about it would be better to support it.

So the question is how we support it? Does it make sense?

1. Nginx don't support .htaccess.
2. Nginx don't support .htpasswords.
3. Nginx rules are more complex and some popular software like WP will require custom rules. We can't allow users to manipulate webserver rules ! As it would not be secure.

I saw other panels using nginx as reverse proxy while apache sits behind. So you are still using apache and trying to get some performance improvement using nginx, but does this sound ok? Require more memory for micro instance.

So how to implement it?

We can set list of templates that user could apply per website, those rules are configured. Nginx only? No apache behind?

So hope the community help answering those question or explain more how it could be used.

M B

[bbspike]

I think we should not replace apache for nginx but more to use it for static serve.

[Me.B]

How as static server. That would mean having NGINX sitting in front of apache and forwarding all requests. That would mean that .htaccess restrictions could be cut short over static content too...

Aside on another IP?

[Castey]

Nginx uses one config file per domain and rewriting in one domain won't affect other domains but still, impropriety rules still can kill whole web server. Maybe we can develop module for creating rules? Module will check syntax before allow to save them to domain config file and prevent from errors (in this case we can excluede several options from rules for users to make it more secure). Rules will be activated with next deamon run like new subdomain etc.

[Me.B]

Nginx uses one config file per domain and rewriting in one domain won't affect other domains but still, impropriety rules still can kill whole web server. Maybe we can develop module for creating rules? Module will check syntax before allow to save them to domain config file and prevent from errors (in this case we can excluede several options from rules for users to make it more secure). Rules will be activated with next deamon run like new subdomain etc.

Building a rule interface...hmmm.. How to validate the config? Would you allow end user do that?
Nginx have a lot of rules. A lot of syntax and beside that what if user change the root to / instead of his own directory.

We should then validate the syntax is OK and the input won't go outside of current authorised user directories?

Only serious way of validating rules is using nginx it self:
https://wincent.com/wiki/Checking_nginx_...ile_syntax

But that only validate the syntax. Doesn't garantee that the new config is SECURE.

[bbspike]

a qeustion not so related to nginx. Whats the future for apache in Snetora? Using the handler or going to factcgi and FPM?

[Me.B]

Future would be with SuEXEC & fastCGI. I have an idea how to get that. We need SuEXEC too later if we plan to get CGI back or more languages.

I see that beta in 1.0.5 target may be earlier but the biggest issue is already solved and will apply to SSL implementation.

M B

[apinto]

NGinx is no magical bullet. This is my premisse.

I use Sentora with Apache and I've added a Varnish on the front.
It works differently than NGinx however the performance is very similar or even better (when not using Varnish Cache, only as a Reverse Proxy).
As a reverse Proxy it has a LOT less features than NGinx, however it is lighter, easier to manage and allows a extra caching service that is amazingly fast.

Also, as a Bonus, Varnish is a great Load Balancer for multi server setups.

In the end I do not think NGix will be a good choice, too complex without any need for that.

[apinto]

I believe Sentora must simplify everything it uses. Both for maintenance and for ease of use.

[Me.B]

varnish don't support ssl nginx yes and it can replace apache.