Manual · Chapter 16

Web interface

Go to the contents

The job scheduler and the backup server can also be operated in a browser, without Windows and without additional software. The web interface is built into bkp_sched and bkp_target and works through the same HTTPS API as the management console and the target console. It is especially suited to pure Linux, Proxmox and Xen environments.

ServiceAddressWhat can be operated there
Job scheduler (bkp_sched)https://<computer>:8447/Overview, jobs with wizard and schedule, runs with log, destinations, profiles, restore (files, image, VM, M365), email, license, settings
Backup server (bkp_target)https://<computer>:9991/Overview, sessions, storage with stores and runs, accesses and customers, holding backups, target scheduler, email, log, settings

The API must be switched on (Chapter 14, Chapter 15); the setup does this on request. The web interface itself is then on by default. If you do not want it, switch it off in bkp_sched.cfg or bkp_target.cfg; the API for the consoles is not affected:

[api]
web=no

Open the port in the firewall only for the computers from which the server is managed. The interface follows the language of the browser (German, English, Spanish, French, Croatian) and can be switched at the top right; it adapts to light and dark settings and to narrow screens.

16.1 The first visit: browser warning and fingerprint#

By default the API uses a self-signed certificate. On the first visit the browser therefore warns once that the connection is not private. This is expected and not an error. Before you confirm the warning, compare the certificate's fingerprint (SHA-256) with the one the computer itself reports:

bkp_sched api-info          # job scheduler
bkp_target --api-info       # backup server

The browser shows the fingerprint in the details of the warning or through the lock or warning symbol next to the address (“view certificate”). If both match, the page belongs to your computer and you can continue. The sign-in page explains this once more. To avoid the warning, use a certificate of your own (section “Own certificate”).

16.2 Signing in#

You sign in with the name and password of a web user. The browser derives a key from the password and signs every request with it; the password itself never leaves the browser, and the server knows only a value derived from it. After ten failed attempts the server locks the browser's address out for a minute.

  • The sign-in is valid for the browser tab: reloading keeps it, closing ends it.
  • After 30 minutes without input the interface signs out; a warning appears two minutes before, and any input extends the session.
  • You change your own password at the top right under your name (“Change password…”); you also sign out there.
RoleWhat the web user can do
Administrator (admin)See and change everything: start and create jobs, restore, settings, web users, certificate, activation.
Read only (read)See everything. Elements for changes are greyed out; their hint gives the reason.

What the server allows only on the command line anyway (actions locked in [api], such as deleting stores without allow-delete) is not possible in the browser either. The interface shows errors with text and next step; ? and F1 open the matching section of this manual.

16.3 Web users#

Web users are the people who sign in to the web interface. Every job scheduler and every backup server has its own. Names consist of letters, digits, “-” and “_” (at most 64 characters, not beginning with lic-, which is reserved for the license server); passwords have at least 10 characters. There are four ways to add and maintain them:

  • Setup: On Linux the setup asks for the first user at the end (default admin, role administrator) and then shows address and fingerprint. The Windows setup offers the same on the page “Web interface”. Without windows: --web-user <name> with --web-password-file <file>.
  • Web interface: page “Settings”, card “Web users” (administrators only).
  • Consoles: in the management console menu “Scheduler” › “Web users…”, in the target console menu “Server” › “Web users…”. The console needs an admin token for this. Here too the key is derived on the Windows computer.
  • Command line on the computer itself (the password is asked twice without echo; --password-stdin reads it from the first line for scripts):
bkp_sched web-user add eva --role admin
bkp_sched web-user add reader --role read
bkp_sched web-user passwd eva
bkp_sched web-user list
bkp_sched web-user remove reader

bkp_target --web-user-add eva --role admin
bkp_target --web-user-passwd eva
bkp_target --web-user-list
bkp_target --web-user-remove eva

An administrator can neither remove nor change themselves through the user management. Therefore add a second administrator, so that someone can still sign in if a password is forgotten; otherwise web-user passwd on the command line helps. Pass passwords on in person or by phone, not by email.

16.4 Own certificate#

With a certificate of your own certification authority (or a public one) the browser warning disappears. Upload it on the page “Settings”, card “Certificate of the web interface”, with “Use own certificate…” (administrators only):

  • Certificate: the server certificate in PEM format, followed by the intermediate certificates of its chain.
  • Private key: in PEM format, without passphrase. It is stored readable for administrators only.

The server checks that key and certificate belong together and that the certificate is valid. If none of the names in the certificate matches the address in the browser, a warning lists the names under which you should open the interface. After saving, the server uses the certificate within a few seconds and the page reloads. The same certificate also applies to the consoles: they report the new fingerprint at the next connection, which is taken over under “Edit scheduler...” or “Edit server...”.

The card shows issuer, names, expiry date and fingerprint. Replace a certificate in good time before it expires; browsers refuse an expired one. Going back to the self-signed certificate is done on the command line:

bkp_sched api-init --force          # job scheduler
bkp_target --api-init --force       # backup server

16.5 Activation#

In the job scheduler the page “License” shows the state of the license or trial period with the notices before its end, in the backup server the card “Activation” on the page “Settings”. With “Enter activation code…” administrators activate the installation; this is the same as bkp_license activate on the command line. Upper and lower case and spaces in the code do not matter. The computer asks the license server, which usually takes a few seconds; the result then appears on the page.

16.6 When it does not work#

Message or observationCause and next step
The page does not loadAPI off, service stopped or port blocked in the firewall. On the computer check bkp_sched api-info or bkp_target --api-info (enabled?) and ss -ltn | grep -E '8447|9991'.
“Not found” instead of the sign-in pageThe configuration contains [api] web=no. Set it to yes and reload the service.
Name or password wrongMind upper and lower case. An administrator sets a new password, or web-user passwd on the computer.
Too many failed sign-insThe server locks the address out for a minute; then sign in again.
The clock differsRequests are signed; the two clocks may differ by at most 5 minutes. Set the clocks of server and workstation by NTP.
No connection after uploading the certificateOpen the interface under one of the names in the certificate. If need be, run api-init --force on the computer and switch the consoles to the new fingerprint.