Every installation shows who looks after it: the partner through whom the customer obtained AegisGrid, otherwise AegisGrid itself. Only we maintain the details, on the license server; partners and customers do not change them. Built in are the details of AegisGrid (AegisGrid – MSD Computersysteme GmbH, Grunerstraße 41, 40239 Düsseldorf, Germany, phone +49 211 21099-0, info@msdnet.invalid.de, https://aegisgrid.de).
21.1 Where it can be seen#
| Place | What appears |
|---|---|
| Setup (Windows) | a banner on every page: before activation the AegisGrid shield, after it the partner's logo with AegisGrid small next to it; the finish page names the contact |
| Setup (text, --silent) | the block “Your contact” after activation and at the end of the report |
| Management console, target console | “Help → About …” with logos and contact; “Help → Support...” with email and web link, for the chosen server its contact |
| Messages | notes on license and subscription name the contact with phone and email |
| Mails of the job scheduler | a footer “Your contact: …” below every mail |
| Command line | --version and --help end with “AegisGrid” and “Support: …” |
21.2 How it gets onto the machines#
The signed license names the hash of the branding. At activation and at every daily renewal (bkp_license renew) the installation fetches it if the hash has changed, and only accepts it if it matches the hash. A change of partner or a transfer of the account changes the hash by itself. It is stored in %ProgramData%\AegisGrid\branding (readable for all users) or /var/lib/bkp_branding; uninstalling removes it.
21.3 Moving to the new names#
Older installations were called “cybackup”. The updater converts them at the first run after the update: on Windows %ProgramFiles%\AegisGrid, %ProgramData%\AegisGrid, service aegisgrid-sched (“AegisGrid Scheduler”), tasks “AegisGrid updater” and “AegisGrid resume”, start menu, “Installed apps” and firewall rule; on Linux /opt/aegisgrid and the accounts aegisgrid and aegisgrid-api (same user number, the stores keep their owner). Links stay at the old places for scripts of your own. If a job or a backup is running right now, the move waits for the next run; if a step fails, everything is taken back, the job scheduler sends a mail with the cause, and the next run tries again. bkp_updater --migrate-names triggers it at once.
Note: After the move it is no longer possible to go back to a version before the renaming (--rollback, --update --to); it does not know the new names. The program names bkp_*, the formats of the backups and all keys stay.