Jurian Sluiman's questions

My Synology NAS is capable of running the web interface via HTTPS. By default, you access the NAS via its name (say, mynas) so http(s)://myname:5001 or http(s)://myname.local. It defaults to an SSL certificate for synology.com.

You can create a new cert using Let's Encrypt; you forward the required ports from your router to your NAS, I created a sub domain from a domain I own and updated the DNS to point towards my home ip. (e.g. home.my-domain-i-own.com)

I was hoping I could enter myname;myname.local as subject alternative names, so I can browse my NAS internally via HTTPS without warning. However, Let's Encrypt doesn't accept domain names it can't validate, apparently.

My question: how to solve the issue I can use a Let's Encrypt cert with my domain mynas.local without any warnings?

For a couple of years I have SSL on my personal domain: https://juriansluiman.nl. Now I was using subdomains to access my Google Apps: mail, calendar etc. All these subdomains are configured using Google's recommended approach with CNAMEs. This worked for ages, before and after I started using HTTPS.

A few months ago I started to add a HSTS header on my domain. Somewhat during that time, I also started noticing I couldn't access my Google pages using the subdomains any more.

Example: http://mail.juriansluiman.nl or https://mail.juriansluiman.nl

All my browsers give me a connection error. Tools like web-sniffer.net return me the message "Error while fetching URL". Does anyone know what the specific problem might be?

Just as an experiment, I was trying to remove my index.php from the webroot in nginx and directly point to app.php, as the only thing the index file does is this:

<?php

chdir(dirname(__DIR__));
include 'app.php';

My nginx setup is pretty easy:

server {
    listen      80;
    server_name localhost;
    root        /vagrant/public;

    location / {
        try_files $uri /index.php?$query_string;
    }

    # some includes here
}

And simply pointing out of the web root does not work:

server {
    listen      80;
    server_name localhost;
    root        /vagrant/public;

    location / {
        try_files $uri /../app.php?$query_string;
    }

    # some includes here
}

It is for me a bit hard to search for this case, as there are many problems popping up based on the used key words, but all related to another problem.

There is no real need for this, but with nginx such a powerful tool I can't imagine this is not possible. So, it it?

For a website just-to-be-put live, we often have a static index.html in our web root. The file contains all styles and images inline, so there is no other request required to load that page.

For now, I use this config:

# Temporary placeholder
server {
        server_name .domain.com;
        root        /var/www/domain/production/public;

        index index.html;
        charset UTF-8;
}

# Production
server {
        server_name test.domain.com;
        root        /var/www/domain/production/public;

        charset UTF-8;
        gzip_types text/plain application/xml text/css text/js image/svg+xml text/xml application/x-javascript text/javascript application/json application/xml+rss;
        location /assets/images {
           default_type image/jpeg;
           expires max;
           add_header Pragma public;
           add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        }
        location /styles/fonts {
           expires max;
           add_header Pragma public;
           add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        }

        include conf.d/common.conf.inc;
}

This works great "enough" but ppl are able to request resources which should not be served (e.g. domain.com/foo/bar/file.ext) as only the "index" directive is set.

Question: how can I point all requests to the index.html in the first server block? I tried using a location with try_files but nginx cannot handle a single item in that list:

location / {
    try_files index.html;
}

How can I achieve this? (I know you can work with redirects, but for now I don't prefer that solution. domain.com/foo/bar/baz should just serve index.html).

We run web servers where we have the following situation:

1. The www-data user runs the web server and must have read+write access to the files
2. The deploy user deploys all the code
3. The bob and alice users might login via ssh and change configurations locally

All users must have read+write access on /var/www/mysite. We currently accomplish this by owning the group of /var/www/site to www-data. Then we set the write + setgid bit on the group to make sure all subdirectories are having the same rights.

Now, this is all running fine for some time, but we have issues with the following scenarios:

1. We use bower to install packages with bower install. The user who ran bower install the first time owns the public/bower_components directory and no setgid bit is set
2. We use gulp to minify javascripts from public/scripts/src to public/scripts/dist and the first user who ran gulp build owns the files

In both situations, a find path/to/dir -type d -exec chmod g+ws {} \; does mitigate the problem, but is it possible to fix this issue in the first place? We have set the setgid bit on the /var/www/mysite directory, so why does bower install not follow this permission set?

If not, is there a better way to fix this problem? We have thought to set the bits in the deployment automation process, but if a user forgets the setgid bit we think the automated deployment could get stuck as well.

For a web service we have two certificates: myservice.com and api.myservice.com. Both have the same application (document root) but are serverd over HTTPS with different certificates. Unfortunately, we don't have a two-domain certificate at this moment.

Currently, I have to define two server blocks, one for each pointing to the same root. The only difference is the ssl_certificate directive, but that one can be declared only on http or server level.

Nevertheless, is there a way to avoid the copy/paste in the server blocks? This is an example code:

server {
    listen      443;
    server_name .myservice.com;
    root        /var/www/myservice.com/public;

    include conf.d/common.conf.inc;

    ssl                 on;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
    ssl_session_cache   shared:SSL:5m;
    ssl_session_timeout 10m;
    ssl_certificate     /path/to/myservice.com.bundle.crt;
    ssl_certificate_key /path/to//myservice.com.key;

    ssl_prefer_server_ciphers on;
}

server {
    listen      443;
    server_name api.myservice.com;
    root        /var/www/myservice.com/public;

    include conf.d/common.conf.inc;

    ssl                 on;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
    ssl_session_cache   shared:SSL:5m;
    ssl_session_timeout 10m;
    ssl_certificate     /path/to/api.myservice.com.bundle.crt;
    ssl_certificate_key /path/to//myservice.com.key;

    ssl_prefer_server_ciphers on;
}

/edit: As requested, here the output of nginx -V:

nginx version: nginx/1.2.7

TLS SNI support enabled configure

arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.2.7/debian/modules/chunkin-nginx-module --add-module=/build/buildd/nginx-1.2.7/debian/modules/headers-more-nginx-module --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-development-kit --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-http-push --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-lua --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-upload-module --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-upload-progress --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.2.7/debian/modules/nginx-dav-ext-module

I am looking for a solution for this problem. I understand the reasoning why the setup in that question does not work, but I try to get to a solution where I can get it working.

The idea is to allow large file uploads only on certain urls. I can use a location block for this, but the problem is: I have a php frontcontroller pattern:

location ~ \.php {
    # ...
    fastcgi_pass unix:/tmp/php5-fpm.sock;
}

My total config looks like:

# ...

http {
    # ...

    client_max_body_size 512K;

    server {
        server_name example.com;
        root        /var/www/example.com/public;

        location / { 
            try_files $uri /index.php?$query_string;
        }

        location /admin/upload {
            client_max_body_size 256M;
        }

        location ~ \.php {
            # ...

            fastcgi_pass unix:/tmp/php5-fpm.sock;
        }
    }
}

As I understand, only one location block will be applied. So if I have a default request size of 512K, the 256M will never be applied since all requests are matched through the frontcontroller pattern ~ \.php.

Am I right in this case and if so, what can be configured such that visitors cannot upload anything except when they upload to admin/upload?

For all our sites we have an include file which contains several things, amongst this line:

location / { 
    try_files $uri /index.php?$query_string;
}

For a single site, we do want to redirect all requests from mysite.com/ to mysite.com/blog, as a temporary "fix". The block looks like this:

server {
    server_name mysite.com;
    root        /var/www/mysite;
    include     conf.d/common.conf.inc;

    # Redirect blog
    location / {
        rewrite / /blog redirect;
    }
}

This fails however, with the following error:

Testing nginx configuration: nginx: [emerg] duplicate location "/" in /etc/nginx/sites-enabled/mysite:7

The question

How can we have a server block with location / {} for the try_files and redirect all requests from / to /blog?

We run an Ubuntu 12.04 server where php 5.3.10 is installed by default. I thought Ubuntu did only apply bugfixes in their updates, so micros like 5.3.x should pass through.

Apparently, our version isn't updated, but we are stuck with a critical bug in php which is solved in 5.3.15. Should I wait longer for this release to bubble up? Or are there safe repositories to use for Ubuntu to continuously update php and php related packages?

We are a software company and offer hosting to our clients. We have a VPS at a large Dutch datacenter. For some of the applications, we need an SSL certificate which we'd like to encrypt with a password protected keyfile.

Our VPS reboots now and then because of updates whatsoever, but that means our apache doesn't start right away because the passwords are needed. This results in downtime and is of course a real big problem.

We can give the passwords to our VPS datacenter, or create certificates based on keyfiles without passwords. Both solutions seem not the best one, because they compromise the security of our certificates. What's the best solution for this issue?