Reading the server health page
The health page is a list of things that are either true about your server or not. This page explains what each state means, lists every check and what goes wrong if you leave it, sets up being told rather than having to look, and covers what ignoring a check does and does not do.
Step 1
Open it, and read the counts first.
In the panel, Server, then Health. The counts at the top are the part most people read and often the only part: how many checks pass, how many warn, how many are critical, and how many have never been set up. A readiness percentage is the passing checks as a share of the ones that actually ran.
Checks that could not run are deliberately left out of that figure. Counting a check that did not run as either a pass or a failure is how a dashboard starts lying.
The states
Five, and why not more.
| State | What it means | When to act |
|---|---|---|
| OK | This is true and nothing is needed. | Never. |
| Warning | It works, but something will break or is unprotected. | Soon. This is the state most server problems spend their life in before becoming outages. |
| Critical | Something is broken now and hosting is affected. | Now. |
| Not configured | A real feature that has never been set up. Kept separate from a warning because “you have not done this yet” and “this has stopped working” are different sentences to read at eight in the morning. | When you decide you want the feature. |
| Unknown | The check could not run, usually because the privileged agent did not answer. | Look at the agent itself. Nothing below it can be trusted while this is showing. |
A server with warnings is not reported as healthy. That is deliberate: the page exists to say what needs doing, and a green badge over an unresolved warning is the thing that makes a monitoring page worth ignoring.
Reading one check
What is true, what goes wrong, what to do.
Every check carries three sentences, in that order. The summary is what is true right now with the numbers in it, so “3 of 3 services running” rather than “services are fine”. The reason is what goes wrong if it stays as it is, written as a consequence rather than as advice. And where there is something to do, the action says what, with a button straight to the page it is done on.
Every check
Services and the machine.
| Check | What goes wrong if you leave it |
|---|---|
| Services | Nothing here knows whether the web server, the database or mail are up. |
| Programs this server needs | A missing program is a feature that fails when somebody uses it rather than when it went missing, which is usually during an upgrade nobody was watching. |
| File transfer | A stopped service is a customer who cannot work; a misconfigured one is a password crossing the network in clear text. |
| Disk space | A filesystem that fills up stops websites serving, stops backups and stops mail arriving. |
| Restart | A kernel or C library update is on disk but not in any running process. Until the server restarts it is still running the version that was replaced. |
| Operating system updates | Unapplied security updates are the ordinary way a hosting server is taken over: the fault is public, the fix is published, and the machine is still running the old one. |
Security.
| Check | What goes wrong if you leave it |
|---|---|
| SSH access | SSH is a root shell reachable from every address on the internet. A password is guessable and a key is not, and the port it answers on is knocked on constantly by people looking for one that is. |
| Firewall | With nothing enforcing, every port this server listens on is reachable from anywhere, including ones meant only for this machine. |
| Administrator second factor | An administrator’s password is the whole server. A second factor makes a stolen one not enough on its own. |
| Password and sign-in rules | The defaults are a working server rather than a broken one. They are still defaults, and a setting nobody knows about is a setting nobody has decided. |
| Website protection | Without it, a script uploaded into a website’s own upload directory runs, which is how almost every compromised site is actually used. |
| Password-protected directories | A password asked for over plain HTTP is sent in the clear with every request. The directory looks protected and the password is readable by anything in between. |
| Integration keys | A key works without a password or a second factor. One nobody remembers issuing is one nobody will notice being used. |
| Installation ownership | These directories hold code and configuration that run as root. Anything but root being able to write one of them is a way to replace what root runs. |
| Release signing | Without a key, an update is only as trustworthy as the channel that carried its checksum. |
| The server’s Redis | The spam filter keeps its statistics in Redis, and a Redis on a loopback port with no password is reachable by every website on this server, because a website’s PHP runs as an ordinary local account. |
| Certificate renewal | A certificate that stops renewing does not warn anybody. It works until the day it expires, and then every hosted website shows a security warning to every visitor. |
| … settings, one per configurable service | A service left on its installation defaults tells anybody scanning this server what it is running, and in several cases accepts connections it should refuse. |
Certificates, storage, hosting and the panel.
| Check | What goes wrong if you leave it |
|---|---|
| HTTPS coverage | A name served without a certificate that speaks for it is a browser warning on every visit, and visitors read that as the site being unsafe rather than as a configuration detail. |
| The panel’s own certificate | A panel served with a certificate browsers do not trust teaches everybody who signs in to click through a certificate warning, which is the habit that makes the warning worth nothing on the day it is real. |
| Website storage limits | Without kernel quotas a website’s storage limit is a number in the panel and nothing else. One website can fill the disk for every website on the server. |
| Where storage limits apply | A website on a different filesystem from the one carrying the quota has its limit recorded and never applied, and nothing else on the page would say so. |
| Website storage | A website at its limit stops accepting uploads and its application stops writing: sessions, caches and logs fail one at a time, which looks like the application breaking rather than like a disk that is full. |
| Website CPU and memory limits | Without the kernel’s control groups those limits are not applied, so one busy or broken site can take the server down for the others. |
| Off-site backups | Backups kept only on this server are on the same disk as the websites they protect. One failure destroys the data and its backups together. |
| Recent backups | A backup schedule that is not producing backups looks exactly like one that is, right up until somebody needs to restore. |
| Background work | Every website created, backup taken and certificate obtained happens on one queue. When it stops, nothing fails; it simply never happens. |
| Websites | A website left in error is one whose last operation did not finish. Until it is retried, its configuration on this server is not what the panel believes it is. |
| Records and reality | After the panel’s own state is restored, the machine is not restored with it. A website can be serving with no record of it here, or recorded here with nothing serving. |
| Notifications | Without somewhere to send mail nobody is told when a backup fails, a certificate stops renewing or the server runs out of disk, and nobody can be sent a password reset. |
| Licence | An installation at its ceiling keeps every website it has and is refused the next one, so this is otherwise discovered by somebody trying to create hosting rather than by looking here. |
| Release | A server left on an old release misses fixes, and finding out which ones means reading a changelog rather than being told. |
Step 2
Be told, rather than having to look.
Some of these checks raise a notification and an email when they go wrong, rather than waiting to be found. That needs somewhere to send mail, which is why Notifications is itself one of the checks: set up a relay under Server, then Mail, give it an address for alerts, and switch alerting on.
Until that is done the panel still records everything it would have told you about, so nothing is lost on a server in its first week. It just has no way to reach you. See outbound mail for getting the relay working.
Ignoring one
What it does, and what it does not.
A check you have decided about can be ignored, which stops it counting against the server and stops it being raised. Two rules are worth knowing before relying on it:
- Only a warning or a not-configured check can be ignored. Ignoring something and then having it turn critical brings it straight back, because a critical check is hosting being affected now and that is not somebody’s earlier decision to leave.
- Ignoring is a decision, not a fix. The condition is still true and still shown; it simply stops being counted. Off-site backups on a server you have deliberately decided not to back up off-site is a reasonable thing to ignore. A full disk is not.
Un-ignoring removes the record entirely, so the check goes back to behaving as it did before.
When everything reads Unknown
Start with the agent.
Roughly half of these checks are answered by the privileged part of Dashmox that runs as root. Whether kernel quotas are on, whether SSH is taking passwords, what the disk really holds: none of that can be answered by the panel alone. If that part is not answering, those checks report Unknown rather than guessing, and the honest reading of the page is that it does not currently know.
So a page full of Unknown is one problem rather than twenty. Fix that first and read the page again.
From the server itself
The same register, without a browser.
If the panel is the thing that is not working, dashmox doctor asks the root agent for the same register directly and checks a good deal besides: service states, file ownership on the directories that run as root, the programs the server needs, and the configuration of each service that is installed. It must be run as root.
sudo dashmox doctor
The output begins with the register, one line per check, and ends with a tally:
Health register:
OK Services: 7 of 7 running
WARNING SSH access: passwords are accepted
Turn off password authentication and use keys
SET UP Off-site backups: no destination configured
OK Disk space: 38% used of 80 GB
18 of 21 host checks passing.
The panel's own half is on its Health page.
The marks are OK, WARNING, CRITICAL, SET UP for something never configured, and UNKNOWN for a check that could not run. A check that is not passing prints its action underneath. The last line counts only the host’s half, which is why it says so: the panel’s own checks need the panel.
Logs for one service, when a check points at it:
sudo dashmox logs api sudo dashmox logs agent sudo dashmox logs nginx