CustomBuild Nginx edition

Well from the looks of all this, I say it definitely should be added to custombuild as an option. I am sure a lot of people like me who dont know the ins and outs of setting it up properly would love to use it, but dont because its not in custombuild.
 
most cms' and scripts indeed are just build for apache. Maybe it will change over time if it turns out nginx is really better.

Yes, that's right. And this determines the things why Apache is still so popular. And from another point of view, PHP programmers write their code for Apache, because it's widely used on shared hosting servers. Note since .htaccess is not supported by nginx, I would not like to give customers a way to edit a raw config file for adding rewriting rules, since that there should be some kind of an interface which would allow to add rewriting rules into nginx config for a virtual host and protect the configs against typos and other errors which could break nginx. For now I personally don't know a way how to do it... that is mostly caused by the fact I did not need anything of this kind. Maybe anybody else here have ideas about how to organize a web interface for managing rewriting rules for NGINX, error pages handling, index file changing, etc...
 
That does sound like a deal breaker. Maybe at one point they are willing to add support for shared hosting, so things can be configured like htaccess.

Though in theory it should be possible to create a web ui to modify/add things, with very strict checks.
 
Like I said. nginx supports so called 'configtests' which tests if a config-edit works or not. Customers should be given their own interface per domainname and before applying a restart, simply do a configtest. If it fails, just revert to the original config.
 
Well by design I would then write the user config to a tmp one, and make nginx test that (or copy the main one along with it). But is every config caged from one another? I wouldn't think that it would be a good idea that every customer could put everything in a nginx config, even if the syntax is correct. Or I'm missing how nginx works..
 
Well by design I would then write the user config to a tmp one, and make nginx test that (or copy the main one along with it). But is every config caged from one another? I wouldn't think that it would be a good idea that every customer could put everything in a nginx config, even if the syntax is correct. Or I'm missing how nginx works..
No you're quite right. It's still a potential security/config-modify risk. But I can think you can easily 'fix' that by using an own config maker/generator & parser. After-all that's what DirectAdmin is about (DA writes the generated configs etc.)
 
Not really. It's pretty much what DirectAdmin already does and is made for (generating Apache (and other services) configs etc.).

I'd like to see a picture or a html template of a config maker for a virtual host, so an end-user could do the following (for a domain, and for every enclosed directory):

1. Change index page settings and autoindexing settings (for a domain, and for every enclosed directory).
2. Change error pages settings (3xx-5xx error codes redirection) for a domain, and for every enclosed directory
3. Set/modify rewriting rules for a directory, for virtual host (The rewrite module: URI changing using regular expressions).
4. SSL settings (not sure if we need it here, as it can be done automatically)
5. HTTP Basic authentication (not sure if we need it here, as it can be done automatically)
6. Access control based on client IP address

what else? You can find it here: http://nginx.org/en/

Note, without a separate interface, an end user won't be able even to change index page settings.
Apache mod_rewrite is very difficult for the most of the users, and what to say about regular expressions in NGINX?

See

Code:
if ($http_user_agent ~ MSIE) {
    rewrite ^(.*)$ /msie/$1 break;
}

if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
    set $id $1;
}

if ($request_method = POST) {
    return 405;
}

if ($slow) {
    limit_rate 10k;
}

if ($invalid_referer) {
    return 403;
}

Of course it gives more functionality, but I'd rather say it's more complicated.
 
On my non-DirectAdmin boxes I'm fine with manual configuration. And I don't have the time to make such interface. This is something the DirectAdmin could/should look into.

And I'm not sure if you've looked at the .htaccess file from projects like HTML5 Boilerplate. It's quite complicated to maintain too, and the nginx syntax is more useful in that case. And the examples you gave aren't really "standard" configuration things.

This is how a nginx virtual-site configuration looks like, with support for Drupal (CMS). It includes a whitelist.

Code:
server {
	#Listen to port
	listen 80;

	#Specify hostnames to listen to
	server_name www.mywebsite.lol mywebsite.lol;

	#Document root
	root /home/mywebsite/public_html;

	#Only allow 2 IPs. Others are denied.
	allow 133.7.133.7;
	allow 133.7.133.7;
	deny all;

	#Rewrite everything that is passed to @rewrite
	location @rewrite {
		rewrite ^/(.*)$ /index.php?q=$1;
	}

	#Specific rules for styles
	location ~ ^/sites/*/files/styles/ {
		#Pass to @rewrite if doesn't exist
		try_files $uri @rewrite;

		#Never expire files (max caching @ client)
		expires max;
	}

	#Some security measures
	location ~ \..*/.*\.php$ {
		return 403;
	}

	#Default location. If doesn't exist pass to @rewrite
	location / {
		try_files $uri @rewrite;
	}

	#Pass PHP files to PHP-FPM. These lines can be easily brought back to only 2 lines
	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_index index.php;
		fastcgi_pass php;
		include /etc/nginx/fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_intercept_errors on;
		fastcgi_param SCRIPT_NAME $fastcgi_script_name;
	}

	#Disable hidden files/folders (security)
	location ~ /\. {
		#Don't log
		access_log off;
		log_not_found off; 

		#Deny
		deny all;
	}

	#Disable .ht files (such as .htaccess and .htpasswd) (security)
	location ~ /\.ht {
		#Don't log
		access_log off;
		log_not_found off; 

		#Deny
		deny  all;
	}
}

It's simply a somewhat different approach. Not, per definition, more complex or whatever.
 
It probably is, right now htaccess and apache take care of that part. You would need to make a parser from user input to check everything if it's correct and allowed. Right now that's not the case.

I could imagine that the nginx config syntax would need to be studied, and parses for each allowed entry should me made. A page dedicated for rewrite rules, another for allowed ips etc.
 
It can be if you are the only user on the server. But it won't give your customers all flexibility of the Apache for which the most popular software is designed.
 
Does this organization look like they will be around in 5 years?
It would be a shame to have your servers using a product that does not upgrade...
 
If the company may not be around or have enough interest behind it, why the hell would I even want to discuss features?
I have apache running on my servers and I am pretty sure that in 10 years it will still be supported. I have customers that rely on my decisions when it comes to technical issues, The last thing I want to do is lose a business that took years to build because all my servers run nginx and it is no longer being updated timely... So my question is probably way more important to get out of the way than any suggestion posted so far!
 
I understand the "history of apache"
am using it fo long time also, but we need to move on with the new technologies.
1. we not meaning to "drop" apache, just add another option
2. personally, I do not believe that nginx will leave us so fast
3. nginx work Much faster then apache, it will be better also for your customers In certain situations

Best Regards,
Star Network.
 
If the company may not be around or have enough interest behind it, why the hell would I even want to discuss features?
I have apache running on my servers and I am pretty sure that in 10 years it will still be supported. I have customers that rely on my decisions when it comes to technical issues, The last thing I want to do is lose a business that took years to build because all my servers run nginx and it is no longer being updated timely... So my question is probably way more important to get out of the way than any suggestion posted so far!
nginx has been around for over 7 years and is used by many corporate websites. nginx has a (growing) market share of 11% on all domains (source). And on top of that it's open-source. So if the company behind it stops, there's still a community that can pick it up. :)
 
I will consider nginx for the next release of CB (not 2.0.0, which is completed) :) I would not like to promise anything now, but it might be possible to bring alpha/beta release this year.
 
Back
Top