Updates and support access

We do not come in on our own through either of these paths. The button moves the product to a new version; the checkbox opens a temporary way in for our engineer.

The SettingsLicense section, the “Install maintenance” block. The owner and administrators see it.

It works not through the product but through a separate supporthub-agent service on the server itself — the installer puts it there as its sixth step. The service exists precisely because the product restarts during an update: it cannot update itself, and it has nothing to show the progress with either. If the service is not answering, the buttons in the section do nothing, but support work is unaffected — messages are accepted and replies go out as usual.

The Update button appears when a version newer than the installed one is out for you. Next to it you see which one, and whether it changes the database schema. On a press the service takes five steps, in this order:

Settings, database, attachments and the setup code stay where they are. The database password does not change and operators are not signed out.

The page switches to showing the update's progress: the step the service is on and the time it started. It takes that not from the product — the product is restarting — but from a separate address served by the host nginx out of a file. That is why the page keeps answering even when everything else is down.

You can close this page. The update runs on the server and does not wait for a browser: a closed tab, a reloaded page and a dropped internet connection do not affect it. When you come back you see the step the service is on.

Sometimes the progress is not visible — the status page is not answering. The update itself is still running; come back in a few minutes.

The service puts the previous version back by itself, with no involvement from you, and says so on the same page: “The update did not go through, the previous version is back”. The product keeps working on what was working.

The database is deliberately not restored from the backup in that case. The previous version usually works on the new schema too, and a restore would wipe everything your customers wrote while the update ran. The backup simply stays where it is.

If putting the previous version back did not help either, the service restores the database from the backup taken in the first step. That is a last resort, and it is worth writing to us about: a record of every step stays in the service journal (/var/lib/supporthub-agent/journal.jsonl), and working it out from there takes minutes.

The previous version can also be put back by hand, without the cabinet:

The update term is written into your license separately from the term it works for. When it runs out the product keeps working and new versions stop being offered, and the section shows the date they were available until. Extending it goes through us.

A supporthub command is installed on the server next to the service — the same thing for those who prefer a terminal:

It does exactly what the buttons do: both roads lead to the same service, and they share one journal.

The “Grant support access” checkbox is your permission for us to come onto the server. While it is not ticked there is no account for us on the server, no key and no sudo rule: there is nothing to revoke and nothing to forget to revoke.

When you tick it, the service starts asking our server once a minute whether a support session is open for you. If one is, it creates the supporthub-support account and puts our key in it, issued for that session and only that session. If there are no sessions, nothing happens: the checkbox is a permission, not a sign-in.

About addresses: if we gave you the list of ours, sign-in is allowed only from them, and they are visible in the section. While the list is empty the section honestly says “no address restriction” — meaning sign-in is possible from any address, and the only limits left are your permission, the key and the term.

Untick the checkbox. The service removes the key, deletes the sudo rule, locks the account and cuts open sessions — in that order, so no gap is left to come back in through. An engineer who was working at that moment is dropped out of the terminal.

The account is locked rather than deleted: deleting it would take its home directory with it, and that is the record of what was done on the server. A locked account cannot be signed in to.

If you do not untick it, the access closes by itself once the term passes.

Under the checkbox there is a journal: when the access was granted, which engineer signed in and out and when, when the term expired and when you revoked it. Journal entries appear by themselves and are not editable, neither by us nor from the cabinet.

• We do not update you ourselves. There is no automatic updating: until you press the button, the version stays the one that is installed.
• We do not come onto the server without the checkbox. We can open a session on our side, but it never reaches the server: it is the service on your host that asks us, and it only asks while you allow it.
• We do not see the contents of conversations. What goes out is the license id, the server fingerprint, the version and a timestamp — the same as during a license check. Conversations and personal data stay on your server.