Website Configuration Reference

This page is a detailed breakdown of all the configuration options and files available when configuring website hosting on Sympl.

As with all the other documentation here, the site example.com will used, and you should substitute this for your domain.

All configuration for this domain will be in the /srv/example.com/ directory.

Sympl uses the Apache web server, along with the relevant version of PHP for your version of Debian, along with the typical PHP extensions.

• PHP 7.0 for Debian Stretch (Sympl 9.x)
• PHP 7.3 for Debian Buster (Sympl 10.x)

Getting Started

The files for example.com are in the /srv/example.com/public/htdocs directory which is the site root.

• If this directory doesn't exist, is empty, or has no index.php or index.html, the default page will be served, mentioning there is no content on the site.
• The content in the directory will be served for both www.example.com and example.com, so theres no need to prefix the domain with www.
• If you want to serve different content for www.example.com and example.com, you can create /srv/www.example.com as a separate directory.
• Within an hour of the directory creation, a new configuration will automatically be created for Apache.

More detailed information about how Sympl serves content can be found at How Web Hosting Works on Sympl.

Testing Your Sites

New sites can be tested before they are made live using the 'testing' domains. If your hosting provider provides a wildcard DNS entry on your server pointing to its hostname (and the default site is set to match), then sites can be accessed via this method.

You can confirm if this is the case using dig or a similar tool - if your server is named server.example.host, if you run dig +short randomname.server.example.host and get a response with the server's IP address, then this is the case.

If so, you can access any of the sites via this method in the format <domain_directory>.testing.<server_hostname>, for example example.com.testing.server.example.host. Note that the www. should not be included in this case.

Note that this only applies to websites (not email, FTP and similar), and will not work fully in all instances, as some sites will redirect to their expected hostname or similar. If this is the case, you can test by editing your hosts file on your local computer.

Serving the Same Content on Multiple Domains.

In some cases you may want to accept traffic for and serve the same content for multiple domains, such as WordPress multi-site configurations.

Both of these assume you have the main site already configured and working.

Aliasing the Whole Domain

The most simple option is to alias the whole domain. This will result in the whole configuration including other services such as email, SSL certificates, and FTP sites all sharing the same domain.

To do this, you only need to create a symbolic link to the directory of the site you want to alias. Aliasing example.org (new domain) to example.com (existing domain) you would use

ln -s /srv/example.com /srv/example.org

Aliasing the Web Content Only

Slightly more complicated, but more flexible is to alias only the public/ or public/htdocs/ directory. This allows separate email, SSL certificates and individual, which don't reference the main domain. Some sites access content at the directory above htdocs/, in which case you should link at the public/ point, otherwise public/htdocs/ is usually preferable as it provides separate logging and allows individual FTP access.

In the examples below, example.com is the site which already exists, and example.org is the new domain.

Aliasing public/htdocs/ Only

mkdir -p /srv/example.org/public
ln -s /srv/example.com/public/htdocs /srv/example.org/public/htdocs

Aliassing public/ and Subdirectories

mkdir -p /srv/example.org
ln -s /srv/example.com/public /srv/example.org/public

Redirecting to a Preferred Domain

In the event you want to force all traffic to the same domain name, this can be done with an Apache rewrite. This this example, we want to ensure the domain being used is always www.example.com, preventing anyone from using example.com without the www..

To do this, you would create a file named .htaccess in the htdocs/ directory with this content:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www.*$ [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=302,L]

What this set of rules do is:

1. Enable the rewriting of content.
2. If the hostname being used does not start with 'www.' (case insensitive)
3. Temporarily redirect the request to the same hostname but with 'www.' added and don't process any rules.

Once this is working as expected, you can change the R=302 to R=301 to swap the temporary redirect to a permanent one which will be cached by the browser.

More information is available at Apache Rewrites.

Logging

By default, the Apache logs are written to /srv/example.com/public/logs, named as either access.log and error.log for HTTP requests, and ssl_access.log and ssl_error.log for HTTPS.

These are automatically rotated daily, and compressed after two days.

For any sites being served with mass hosting, the logs can be found at /var/log/apache2/zz-mass-hosting.access.log and /var/log/apache2/zz-mass-hosting.error.log .

Logging for any other traffic is written to /var/log/apache2/other_vhosts_access.log, with any errors for Apache itself at /var/log/apache2/error.log.

Modifying the Apache Configuration

The majority of typical changes to the Apache configuration can be made via relevant .htaccess files.

In the event you need to modify the Apache configuration for an individual site, configuration files can be found in /etc/apache/sites-enabled. Note that if you make any changes, the configuration will no longer be managed by Sympl and it won't make any changes if the templates are updated. If you want to revert to a Sympl generated configuration for a specific domain, you can do this with sudo sympl-web-configure --verbose example.com

If you want to update the configuration of all sites, then you can edit the templates used to generate the Apache configurations, but you should take care when making any changes to ensure the result is valid. These can be found in /etc/sympl/apache.d, and the existing templated configurations can be regenerated with sudo sympl-web-configure --verbose.

Finally, if you want to create your own Apache configurations not managed by Sympl you can do, as it will not make any changes to them.