forum.excito.org

Posted: **25 Jul 2013, 10:34**

While I am a big fan of Apache webserver, I have been running Nginx for a while now as a front end proxy and it does appear to take quite a load off of the B3. Noting that the admin pages are in fact served by PHP running in user space rather than being served by Apache it seemed like a waste of effort to have Nginx forward the request to Apache which then forwards it to the user space CGI.

So let's start with a default Nginx as a front end proxy for Apache configuration:

Code: Select all

server {
	listen   8080; 

	server_name www.example.com;

        access_log /var/log/nginx/www.example.com-access.log;
        error_log /var/log/nginx/www.example.com-error.log;

	root /home/web; 
	index index.php index.html index.htm;

	# Attempt to serve pages
	location / {
		try_files $uri $uri/ /index.php;
	}

	# Pass php pages on to Apache
	location ~ \.php$ {
		proxy_set_header X-Real-IP  $remote_addr;
		proxy_set_header X-Forwarded-For $remote_addr;
		proxy_set_header Host $host;
		proxy_pass http://127.0.0.1:80;
	}

	# Deny acces to Apache's .htaccess files
	location ~ /\.ht {
		deny all;
	}
}

Well, not completely default... This puts Nginx at the alternate port 8080 and leaves Apache at its original port 80. You can use this for testing - I actually have this as the active configuration and use the firewall to redirect incoming traffic for port 80 to 8080. IMO that's the safe way to not cause possible conflicts on B3 software updates.

The above config will let Nginx serve all the static files under /home/web and pass everything else on to Apache, including requests for files that don't exist as far as Nginx is concerned. This means that because /admin is not in /home/web, Apache will be serving the static files in this location and the CGI is doing the PHP files. Inserting the next bit to the Nginx config file fixes this:

Code: Select all

	# Serve static files from web-admin, rewrite virtual files for processing by CGI
	location /admin/ {
		root /usr/share/web-admin;
		try_files $uri /admin/index.php?/$uri;
	}

	# Pass dynamic pages from web-admin on to the CGI
	location ^~ /admin/index.php {
		root /usr/share/web-admin;
		fastcgi_split_path_info ^(.+?\.php)(/.*)$;
		fastcgi_pass unix:/var/lib/apache2/fastcgi/fcgi;
                include fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	}

Note the indentation which should match that of the original default config.

That's it. You can now stop Apache and verify that you can still access the admin pages. Alternatively you can monitor the logs with `tail -f` to verify that no requests for /admin are passed on to Apache.

Posted: **08 Aug 2013, 07:32**

Found a bit of an issue here, which may or may not be an actual problem.

As it turns out Nginx limits the amount of data that a client can upload to the server to 1Mb, causing the upload function in Bubba File Manager to fail with larger files. This limit can be raised by adding the following lines to the server block in the Nginx config file:

Code: Select all

client_max_body_size 4M;
client_body_buffer_size 128k;

Although it may be tempting to raise this value to the supported 2Gb from the upload routine you need to expect different behaviour here then when using Apache. This is because Nginx will first buffer the full upload before handing it over to the Apache backend (calling FTD), so there will be no progress indication during the upload and the uploader will have no clue how long the upload will take or whether it is even working at all.

Not an issue for me, as I only publicly expose the Bubba admin over HTTPS which is served directly by Apache, but something that others might want to consider.

forum.excito.org

Use Nginx for admin pages

Use Nginx for admin pages

Re: Use Nginx for admin pages