Nginx+Apache2

[toukie]

I did the Nginx-as-reverse-proxy-to-Apache thing and got some curious problems.
I can get up my own stuff from B3 only by https.

Http gives a blank page with this message: "It works! This is the default web page for this server. The web server software is running but no content has been added, yet."

Everything else works normally.

What could it be?

[Gordon]

Check your /etc/apache2/sites-enabled folder.

Apache loads the files in there by ASCII order and you'll most likely have an file that lists before `bubba` and defines the defaulthost at location /var/www

[toukie]

Http goes to nginx and gives 403 Forbidden error all the time. Https goes to Apache and it works. That's how it goes.

[Gordon]

My bad...

The page you mentioned is the Apache default page, so apparently you configured nginx to use /var/www as the webroot to serve pages from. It's hard to say at this point where the 403 error originates. The issue could be that nginx cannot find the index file for a directory that you requested or that it has insufficient rights to access that file. In case you're trying to access /admin, do note that this folder does in fact not exist inside the B3 webroot at /home/web. A possible fix in this case might be to actually create that directory and place an empty index.php file inside it for nginx to find and pass the request on to Apache.

[toukie]

My server seen from the web is nginx/0.7.67 and now I see the "default web page for this server"
It was a blank page before with the "It works"-message.

I have root as /home/web/; in /etc/nginx/sites-available/default should it be /var/www ??

From the default page of the server I don't get to the blog, the error is now "Not Found" 404.

I have two WP-blogs on /home/web plus several other folders. Permissions are standard and should work with nginx.

I want to be able to connect as usual locally by b3.local. By https I get to the b3.local/admin page but for some reason not without it. It says "Load failed, Reason: Could not connect to the server.

[Gordon]

I have root as /home/web/; in /etc/nginx/sites-available/default should it be /var/www ??

/home/web is correct. /var/www is the location of the "It Works!" page.

I want to be able to connect as usual locally by b3.local. By https I get to the b3.local/admin page but for some reason not without it. It says "Load failed, Reason: Could not connect to the server.

Sounds like your proxy is configured incorrectly. I recommend that you do not follow any guidelines that instruct you to let Apache listen at 127.0.0.1:80 and configure Nginx to listen at port 80 on every other registered IP address. Change the listen port of Apache instead (8080 is fairly common to use) so you can verify that Apache is running correctly by accessing http://b3.local:8080/

[toukie]

Still not clear with the configuration.

I have:

1) Easyfind address that picks up the default page from which there is a link to one WordPress instance. Now it does so only with https.

2) A new domain address which is supposed to pick up another WordPress instance.

Under the easyfind address the two blogs worked fine plus all the rest in /home/web. Maybe I don't write the root right in nginx sites-enabled or whatever. The new domain address picks up the default page, not the WordPress folder I am trying to point to, but that happens only with https. With http I get 503 error and nothing else.

Nginx and Apache2 have OK syntax when checked.

With https, when using easyfind address I get to all the folders in /home/web including WordPress x2.

[Gordon]

503 error means that the upstream server (Apache) is down or otherwise unreachable. Did you verify that you can still access the pages if you go directly to Apache's non-SSL listen port?

[Gordon]

Well, I figured I give this a try myself and see if nginx really delivers. Actually managed to get the 503 error myself after fondling around in the shell and killing the fastCGI processes thinking they were stuck processes from earlier messing around. Obviously I had the same error in https, but still...

Other than this I found no real problems setting Nginx up with Apache to serve as a backend. I've created something of a cookbook if you like to try:

Get Nginx from the repository:

Code: Select all

apt-get install nginx

Go to /etc/nginx/sites-available and create a new file - I'll name this `www.example.com`

Code: Select all

server {
        listen 8080; 

        root /home/web/www.example.com; 
        index index.php index.html index.htm;

        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;

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

        location @rewrites {
                # Can put some of your own rewrite rules in here
                # for example: rewrite ^/~(.*)/(.*)/? /users/$1/$2 last;

                # When trying /index.php we want to pass the original url to Apache,
                # so don't do this: rewrite ^ /index.php last;

                # If you have no active rules here, then remove @rewrites in the
                # try_files line in the `location /` section
        }

        # 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;
        }
}

Wherever it says `www.example.com` change that to the location/name you desire. If you have multiple vhosts defined in Apache and want to serve those here as well, then do the same for each of these vhosts.

Note that in this file I've set a listen port of 8080. This is because the Apache configuration is actively maintained by Excito and that will cause a conflict if they push an update of bubba-frontend towards your server. Next change to /etc/nginx/sites-enabled and remove the symbolic link `default` you'll find there. Create new links for the sites you want to enable and a neat trick here is to prepend priority numbering to the link names (kind of like they do in InitV):

Code: Select all

ln -s ../sites-available/defaulthost 01-defaulthost
ln -s ../sites-available/intranet 02-intranet
ln -s ../sites-available/www.example.com 10-www.example.com

(I always create a `defaulthost` dummy site with no content, where people stumbling on my IP address can't do any harm).

Next start Nginx and verify that you can access all your pages when visiting http://www.example.com:8080 http://b3.local:8080 etcetera.

Got that? Last step is to reroute people accessing port 80 (which is bound to Apache) on your machine to port 8080 where Nginx is. To do this we'll add some firewall rules:

Code: Select all

# Allow access to port 8080
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -j ACCEPT

# Read the WAN address and interface name in variables...
wan_IF=$(bubba-networkmanager-cli getwanif)
wan_IP=$(ifconfig $wan_IF | grep "inet addr" | sed -r "s/^.*inet addr:([^\s]*)\s.*$/\\1/")

# ... and use these to reroute incoming traffic for port 80 to port 8080
iptables -t nat -A PREROUTING -d $wan_IP/32 -i $wan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080

# Do the same for the LAN interface
lan_IF=$(bubba-networkmanager-cli getlanif)
lan_IP=$(ifconfig $lan_IF | grep "inet addr" | sed -r "s/^.*inet addr:([^\s]*)\s.*$/\\1/")
iptables -t nat -A PREROUTING -d $lan_IP/32 -i $lan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $lan_IP:8080

If you're behind another router like me, then you'll like this additional rule as well

Code: Select all

# get the public address by doing a host lookup on our domain
public_address=$(host -tA www.example.com | awk '{print $4}')

# Make this a priority rule
iptables -t nat -I PREROUTING 1 -d $public_address/32 -i $lan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080

[toukie]

I'll check out what the above intructions can do in my case. I had already nginx 1.2.1 installed.

I have nginx listening on port 80. Is there the same conflict with updates from Excito if I do them from the command line?

I still have something wrong. I get "page isn't redirecting properly"-error. I don't know if it is the browser or the server. I get my_IP_number:80 as Remote IP, maybe that isn't correct?

[Gordon]

Only place where I have 127.0.0.1:8118 is in Privoxy in my browser. Without it I get remote IP: my_IP_number:80 not 127.0.0.1:8080. Still something wrong, the "page isn't redirecting properly.

That may in fact be a totally different issue. My guess is that this is caused by definitions coded inside the admin page. Reason that I'm not getting the same may be a difference in configuration (see the "don't" I mentioned in the nginx site conf file), but it may also be the result of the fact that I made some changes to the admin page (see the "make /admin variable" topic). In any case it would seem that the script controlling the admin page is replicating the 127.0.0.1:8080 address from the proxy call as the base url for include files and links.

I have nginx listening on port 80. Is there the same conflict with updates from Excito if I do them from the command line?

Obviously yes. Excito will overwrite the bubba.conf file in /etc/apache2/sites/available as they see fit and probably some other files in /etc/apache2 as well. So any update will most likely break the admin page and possibly cause apache not to start at all on account of port 80 being allocated by another application. And while you may remember tomorrow that you need to redo some changes you made, chances are that when a few months have passed you'll be climbing up the walls because you can't figure out why it isn't working anymore.

[toukie]

The code didn't work for me, it returned "Bad arguments"

1) iptables -t nat -A PREROUTING -d $wan_IP/32 -i $wan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080
Bad argument `/32'
Try `iptables -h' or 'iptables --help' for more information.

2) iptables -t nat -I PREROUTING 1 -d $public_address/32 -i $lan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080
Bad argument `tcp'

Maybe switching off nginx before doing updates from Excito will be as safe?

If it is the admin page that causes the redirect problem with 127.0.0.1:8080 could it be solved by choosing an other port?

[Gordon]

The code didn't work for me, it returned "Bad arguments"

1) iptables -t nat -A PREROUTING -d $wan_IP/32 -i $wan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080
Bad argument `/32'
Try `iptables -h' or 'iptables --help' for more information.

2) iptables -t nat -I PREROUTING 1 -d $public_address/32 -i $lan_IF -p tcp -m tcp --dport 80 -j DNAT --to-destination $wan_IP:8080
Bad argument `tcp'

Dunno... If you executed all lines in order than $lan_IF, $lan_IP, $wan_IF and $wan_IP should have valid contents.

what does this line return?

Code: Select all

bubba-networkmanager-cli getwanif

Obviously you can also manually edit the correct values in the iptables commands. Bare in mind that the firewall configuration is the last step - there's no point in doing this if you don't have the proxy configured correctly and accessible through port 8080. Also note that if you're behind your ISP router, you can also do the portforwarding directly on that router rather than first forwarding traffic to port 80 on the B3.

Maybe switching off nginx before doing updates from Excito will be as safe?

If it is the admin page that causes the redirect problem with 127.0.0.1:8080 could it be solved by choosing an other port?

The whole issue is that Excito is choosing port 80 to allow owners to administer their B3. Therefore, if you configure nginx to listen at port 80 and Excito does the same with apache when updating bubba-frontend, one of these services is bound to fail.

[toukie]

bubba-networkmanager-cli getwanif returns: eth0

I had my site for a while but lost it again when trying to move there Word Press, it went back to the redirect problem.

The system is somehow mixed up. I don't get to the B3 admin page without https. Nginx and Apache can show syntax OK but that doesn't help.

I need two virtual hosts, one with the easyfind address from Excito the other is a new domain.

[Gordon]

I don't know what you did then. If you execute the whole code block then the iptables command should work correctly.

Oh and I guess I may have misunderstood the 127.0.0.1:8080 comment you made. The problem is with some basic definitions in the code of the admin page. Essentially what they do is grab the full uri that you're calling and prepend everything upto and including /admin/ to the links in the page you're viewing (which includes the location of stylesheets, images and javascript documents that make up the page itself). You should be able to verify this when looking at the page source in Firefox (Ctrl-U).

In any case I can not confirm this myself since I hacked these definitions. Looking at the page source all my links start with '/admin/' and not 'http://b3.local/admin/'.