Configuring the services

Under Server, the Service settings group has a page for each of the five: Nginx, PHP, Postfix, Dovecot and MariaDB. Each shows what that service is currently using, not what a file somewhere says it should be using.

That distinction matters more than it sounds. A setting can be written correctly into a configuration file and ignored by the service that reads it, and the page tells you which of those you are looking at.

Some of these settings are ordinary tuning and some of them are the difference between a compromised website and a compromised server. The ones in the second group carry a warning and say what goes wrong, in a sentence rather than a category:

• Reading files from the client in MariaDB. A website with a SQL injection hole can be made to read files off the machine it runs on through this.
• Following symbolic links in MariaDB. With links followed, one customer's database file can be made to point at another's data.
• Announcing the version in nginx and PHP. Knowing which release a server runs turns a published vulnerability into a targeted one.
• Allowing programs to run from PHP. A website that can start processes is a website that can be turned into one.

The health page counts them, so a server nobody has looked at in a month still says how it is configured.

Rather than reading each warning and setting each switch, Set these safely puts every flagged setting on the service to its safe value at once. Each service is done on its own, so accepting MariaDB's recommendations does not quietly change nginx as well.

Some of them need the service restarted, and the page says which before you press anything. MariaDB is the one to know about: it has no way to reload, so its changes mean a restart, and a restart means every website's database is briefly unavailable.

A configuration file that a service refuses is a service that does not come back. So nothing is applied on trust: the file is written, the service is asked to read it, and only a configuration it accepts is kept. A refusal puts the old file back and says what the service complained about, in its own words.

Since 0.97.17 there is a further check, and it is the one that matters. Writing a file, having the service accept it, and having the service restart are three things that can all succeed while nothing has changed, because a service that cannot read a file ignores it without saying so. The panel now reads the settings back afterwards and tells you about any that did not take, rather than reporting a save that had no effect.

Dashmox writes its settings into a file of its own for each service, alongside whatever the distribution shipped and whatever you have added. It does not rewrite the main configuration, and it does not remove anything you put there.

The one exception is nginx, and it is explained where it happens: Ubuntu's own nginx.conf sets several of the same directives Dashmox offers, and nginx refuses a configuration that sets one twice. Where that collides, the duplicate in the distribution's file is commented out rather than deleted, marked so that anybody reading the file over SSH can see what happened and put it back.

Editing the file Dashmox writes is temporary: the next save from the panel replaces it. Editing your own files is permanent, and the page will show you the result, because it reports what the service is using rather than what the panel last wrote.