0

I am running a Redmine instance which uses nginx for SSL and apache for serving content.

I'm upgrading this by installing the latest version on a new machine and I will copy the files and database once this is all working.

I've copied the config for both apache and nginx from the existing machine to the new one and yet the results are different on the two machines and I can't figure out why.

On the current production instance, Redmine is being run on port 18804 (as decreed by my boss). Currently, when someone uses a browser to access redmine.mydomain.com, they are automatically redirected to Redmine using HTTPS. This happens whether :18804 is appended on the end or not which is how I would like this to operate.

However on the new machine, if in a browser I enter newredmine.mydomain.com, I am redirected to the nginx test page. However, if I enter either newredmine.mydomain.com:18804, or https://newredmine.mydomain.com, then I am routed to the application using HTTP.

I need this to happen simply by entering the logical URL. Clearly the redirection to HTTPS isn't working but as the config is an exact copy I don't understand why.

The current server is running Amazon Linux, Apache 2.2.31 and nginx 1.10.2. The new one is running Centos 7, Apache 2.4.6 and nginx 1.10.2.

This is my config nginx for my application:

upstream redmine {

        server 127.0.0.1:18805;

}


server {

        listen 18804;

        location / {

                return 301 https://$host$request_uri;

        }

}




server {

        listen 80;

        location / {

                return 301 https://$host$request_uri;

        }

}



server {

        listen 443 ssl;

        server_name application.mydomain.com;



        access_log /var/log/nginx/redmine.access.log;

        error_log /var/log/nginx/redmine-errors.log;



        ssl on;

        ssl_certificate_key /etc/ssl/private/key;

        ssl_certificate /etc/ssl/certs/crt;

        ssl_ciphers RC4:HIGH:!aNULL:!MD5;

        ssl_prefer_server_ciphers on;





        client_max_body_size 0;



        location / {

                proxy_set_header Host $host;

                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_pass http://redmine;

        }

}

And my server block from Apache in case that is required:

# Redmine 3.3.3

<VirtualHost *:18805>
  DocumentRoot /var/www/html/redmine/public
  ServerName newredmine.mydomain.com
  ServerAlias 127.0.0.1
  ErrorDocument 503 /maintenance.html
  RewriteEngine on
  RewriteCond %{DOCUMENT_ROOT}/../tmp/stop.txt -f
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ /$1 [R=503,L]

<Directory /var/www/html/redmine/public/>
  AllowOverride all
  # MultiViews must be turned off.
  Options -MultiViews
</Directory>

  ErrorLog logs/redmine_3.3.3_log

As I said the really confusing part is that the two instances are behaving differently despite there being identical config on both. The only differences are ones you would expect, for example the location of the Redmine public folder.

Can anyone see what I am missing here?

3

You are missing server_name on your redirect server blocks. Therefore the actual virtual host selection on nginx is not that clear.

First, you need to make sure that you have a server block which has the default_server attribute on the listen directive. On this block you define what the server does when it receives a request for a host which is not explicitly configured.

Then, you need to have server blocks like these for redirection:

server {
    listen 18804;
    server_name redmine.mydomain.com;

    return 301 https://redmine.mydomain.com$uri;
}

server {
    listen 80;
    server_name redmine.mydomain.com;

    return 301 https://redmine.mydomain.com$uri;
}

It is better to use explicit domain name in the return directive, since the $host variable might contain non-desired values at some point.

The SSL block can be left like it is now.

  • Thanks again - this was the problem and now it's working as expected. A pretty embarrassing oversight, cheers for picking it up. – shaneoh Jun 13 '17 at 7:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.