DB-유

Synology Web Station: Hosting a PHP Site

· synology, php, webserver

I wanted an internal wiki and didn't want yet another machine to patch, so I put it on the NAS. Web Station fronts Apache or nginx, plugs in PHP, and runs several sites side by side as virtual hosts. For a wiki, a photo gallery or a staging copy of a small site it's plenty.

This is how I set up a PHP site on DSM 6.1 with its own virtual host, its own PHP profile, and HTTPS. Before you start, have a DNS name that resolves to the NAS (wiki.example.com on internal DNS, or a hosts-file entry for testing) and a certificate for it imported under Control Panel → Security → Certificate.

Packages

Package Center → search for and install:

  • Web Station
  • PHP 7.0 (listed as a separate package)
  • Apache HTTP Server 2.4, optional; Web Station can use nginx without it.

Installing Web Station creates the shared folder web at /volume1/web, which is the document root of the default site. Leave the default site alone and build the real site as a virtual host in its own folder.

Site folder and code

sudo mkdir -p /volume1/web/wiki
sudo chown -R http:http /volume1/web/wiki

Web Station runs PHP as the http user. Anything the application needs to write, such as an uploads or cache directory, must be writable by that user. Copy the application files in with File Station or over SMB into \\nas\web\wiki. A minimal test file for now:

echo '<?php phpinfo();' | sudo tee /volume1/web/wiki/index.php

A PHP profile per site

Web Station → PHP Settings → Create. I never touch the default profile. A per-site profile means I enable only what that site needs.

  • Profile name: wiki-php70
  • PHP version: PHP 7.0
  • Tick "Enable PHP cache" (opcache) and "Customize PHP open_basedir" leaving the default /tmp:/var/services/tmp:/var/services/web:/var/services/homes.
  • Extensions tab: enable mysqli, pdo_mysql, gd, mbstring, curl, zip, openssl and intl. Almost every PHP application wants this set.
  • Core tab: raise memory_limit to 256M, upload_max_filesize and post_max_size to 64M if the application handles files.

The profile becomes a php-fpm pool with its own configuration under /usr/local/etc/php70/, so a bad setting in one site cannot take the others down.

Virtual host

Web Station → Virtual Host → Create:

Name-based:      wiki.example.com
Port:            80 / 443 (HTTPS)
Document root:   web/wiki
HTTP back end:   Nginx
PHP:             wiki-php70

Name-based hosts share ports 80 and 443 with the default site and are selected by the Host: header, which is what you want for anything with a proper DNS name. Port-based hosts are useful when you only have an IP address.

Web Station writes an nginx server block for this into /usr/local/etc/nginx/sites-enabled/ and reloads nginx. If you need to look at what it generated:

sudo cat /usr/local/etc/nginx/sites-enabled/*wiki*
sudo nginx -t

Do not edit these files; Web Station regenerates them.

Certificate

Control Panel → Security → Certificate → Configure. The new virtual host appears as its own service entry. Set it to the certificate for wiki.example.com and apply. Without this, the site is served with the DSM default certificate and browsers complain about the name mismatch.

Pretty URLs

Applications such as MediaWiki, DokuWiki or WordPress rely on rewrite rules. Under the Apache back end, Web Station honours .htaccess files in the document root, so the application's own file works as is. Under nginx there is no .htaccess; instead, put rules in a user-editable include that Web Station picks up. The path is created when the virtual host is:

ls /usr/local/etc/nginx/conf.d/

Look for a directory named after the host and add a user.conf there, for example for a front controller:

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

Then sudo nginx -s reload. If clean URLs are a hard requirement and the rules are complex, I just use the Apache back end. It's less work.

Does it load?

Browse to https://wiki.example.com/. The phpinfo() page should report PHP 7.0.x, Server API as FPM/FastCGI, and under Loaded Configuration File a path inside /usr/local/etc/php70/. Check that the extensions you enabled are listed. Then remove the test file; phpinfo() leaks paths and versions and should never stay on a reachable site.

If something's off

  • The browser shows the DSM login page or the default Web Station page instead of your site. The Host: header did not match a virtual host. Confirm the DNS name resolves to the NAS and that you typed it identically in the virtual host; wiki.example.com and wiki.example.com. are not the same to nginx.
  • "403 Forbidden" on every page: the document root or files are not readable by http. Rerun sudo chown -R http:http /volume1/web/wiki and sudo chmod -R u+rwX,go+rX /volume1/web/wiki.
  • PHP error "open_basedir restriction in effect. File(/volume1/data/...) is not within the allowed path(s)". The application reads a file outside /var/services/web. Add the path to the profile's open_basedir in the PHP Settings, separated by a colon.
  • Uploads fail silently at a certain size while upload_max_filesize is large. nginx's client_max_body_size defaults to 1 MB or so per Web Station; set it in the user.conf for the host with client_max_body_size 64m;.

It won't replace a real web server if you need fine control, but for a handful of PHP sites on a box that's already running, it's fine.