Zum Inhalt

Enterprise-Installationsanleitung für Administratoren

Diese Anleitung beschreibt die Installation von FLEET Mira Enterprise 1.1.0-beta6 in zwei unterstützten Topologien. Enterprise verwendet PostgreSQL und darf auf Windows Server sowie in RDP-, Citrix- und vergleichbaren Mehrbenutzerumgebungen ausgeführt werden. Für Server und Terminalserver darf ausschließlich das Enterprise-Setup verwendet werden; das Basic/Pro-Setup sperrt diese Umgebungen.

Installationsdateien

Betastatus und Worker-Betrieb

Die Setups sind noch nicht codesigniert. Prüfen Sie deshalb vor der Installation die SHA-256-Prüfsummen. Zentrale Hintergrundaufgaben laufen ausschließlich im Windows-Dienst FleetMiraWorker; Enterprise-Clients starten keinen integrierten Worker. Ein All-in-One-Server installiert Client und Worker gemeinsam, verwendet aber keinen besonderen Kombiniert-Modus.

Gemeinsame Planung

Planen Sie vor der Installation:

  1. einen stabilen DNS-Namen für den PostgreSQL-Server;
  2. jeweils ein mindestens zwölf Zeichen langes Kennwort für mira_app, mira_backup, mira_restore und den PostgreSQL-Administrator;
  3. die Berechtigungen des virtuellen Dienstkontos NT SERVICE\FleetMiraWorker beziehungsweise eines vorgesehenen gMSA;
  4. lokale NTFS-Speicherorte für die PostgreSQL-Daten und zentrale Speicherorte für Tachodaten- und Belegarchive;
  5. eine Sicherung für PostgreSQL und eine getrennte Sicherung der Dateiarchive;
  6. Wartungsfenster, Firewallregeln und – für Verbindungen über das Netzwerk – ein vertrauenswürdiges TLS-Serverzertifikat.

PostgreSQL-Daten müssen auf einem lokalen, festen Datenträger des Datenbankservers liegen. Tachodateien und Originalbelege werden nicht vollständig in PostgreSQL gespeichert. In einer Client/Server-Installation müssen deshalb alle Clients und der Worker dieselben kanonischen UNC-Pfade verwenden und mit den erforderlichen NTFS- und Freigaberechten ausgestattet sein.

Szenario 1: Client/Server mit serverseitigem Worker

Zielbild

flowchart LR
    C1["Enterprise-Client 1"] -->|TLS / TCP 5432| DB[("PostgreSQL: mira")]
    C2["Enterprise-Client n"] -->|TLS / TCP 5432| DB
    W["FleetMiraWorker-Dienst"] -->|TLS / TCP 5432| DB
    W --> A["Gemeinsames Dateiarchiv (UNC)"]
    C1 --> A
    C2 --> A

Der Windows Server hostet PostgreSQL und den eigenständigen Worker-Dienst. Die Benutzer arbeiten mit Enterprise-Clients auf Windows-10/11-Arbeitsplätzen oder zugelassenen Server-Sitzungen.

Server installieren

  1. Melden Sie sich am Windows Server mit lokalen Administratorrechten an.
  2. Kopieren Sie beide Setups lokal auf den Server und vergleichen Sie deren SHA-256-Werte mit SHA256SUMS-Enterprise.txt.
  3. Starten Sie FLEET-Mira-PostgreSQL-Server-1.1.0-beta6-Setup-x64.exe als Administrator.
  4. Erfassen Sie Port sowie die Kennwörter für PostgreSQL-Administrator, mira_app, mira_backup und mira_restore. Das Setup installiert PostgreSQL, legt Dienst, Datenbank und Rollen an und importiert anschließend das vollständige, fachlich leere Mira-Anwendungsschema.
  5. Konfigurieren Sie listen_addresses, pg_hba.conf, DNS und TLS nach Ihrer Sicherheitsrichtlinie. Öffnen Sie TCP 5432 in der Windows-Firewall ausschließlich für die vorgesehenen Client- und Worker-Netze.
  6. Starten Sie das Enterprise-Setup als Administrator und wählen Sie die Komponente Fleet Mira Worker. /COMPONENTS=worker ist die unbeaufsichtigte Entsprechung.
  7. Tragen Sie in einer administrativen Enterprise-Clientinstallation DNS-Name, Port, Datenbank mira, Benutzer mira_app, Kennwort und SSL-Modus ein. Für Produktivnetze wird verify-full empfohlen.
  8. Testen Sie die Verbindung. Eine nachträgliche Schemainitialisierung ist nicht erforderlich; das Server-Setup prüft vor seiner Erfolgsmeldung das Anwendungs-, Worker- und Enterprise-Backup-Schema. mira_app benötigt und erhält dafür kein DDL- beziehungsweise CREATE-Recht auf dem Schema public.
  9. Prüfen Sie den Dienst FleetMiraWorker, seinen Heartbeat und %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log.
  10. Konfigurieren Sie gemeinsame Archiv-, Import- und Belegpfade. Gewähren Sie dem Dienstkonto die benötigten UNC- und NTFS-Rechte.

Clients installieren

  1. Starten Sie auf jedem Client ausschließlich das Enterprise-Applikationssetup als Administrator.
  2. Öffnen Sie FLEET Mira und verbinden Sie die Anwendung über den Assistenten mit derselben Datenbank mira.
  3. Prüfen Sie den Zugriff auf alle gemeinsamen Archive mit dem jeweiligen Benutzerkonto.
  4. Der Client übergibt manuell ausgelöste zentrale Aufgaben automatisch an die PostgreSQL-Queue; ein lokaler Scheduler wird nicht gestartet.

Worker betreiben

  • Verwenden Sie standardmäßig NT SERVICE\FleetMiraWorker; für UNC kann dem Computerkonto Zugriff gegeben oder auf gMSA/Domänenkonto umgestellt werden.
  • Überwachen Sie Dienststatus, PostgreSQL-Heartbeat, Queue, Leases und fehlgeschlagene Jobs.
  • Mehrere Worker sind technisch zulässig; Advisory Locks und Leases verhindern doppelte Verarbeitung.
  • Überwachen Sie %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log sowie die PostgreSQL- und Windows-Ereignisprotokolle.
  • Der Dienst startet nach einem Serverneustart verzögert automatisch und besitzt konfigurierte Recovery-Aktionen.

Szenario 2: Terminalserver mit allen Komponenten

Zielbild

flowchart TB
    U1["RDP-/Citrix-Benutzersitzung 1"] --> DB[("Lokales PostgreSQL: mira")]
    U2["RDP-/Citrix-Benutzersitzung n"] --> DB
    W["FleetMiraWorker-Dienst"] --> DB
    U1 --> A["Zentrales Dateiarchiv auf lokalem NTFS-Datenträger"]
    U2 --> A
    W --> A

PostgreSQL, Enterprise-Anwendung, Benutzer-Sitzungen und Worker-Dienst befinden sich auf demselben Windows Server.

Installation

  1. Legen Sie lokale NTFS-Verzeichnisse für PostgreSQL-Daten und die Dateiarchive an. Verwenden Sie weder Benutzerprofile noch UNC- oder Netzlaufwerke für das PostgreSQL-Datenverzeichnis.
  2. Installieren Sie zuerst das PostgreSQL-Server-Setup als Administrator. Es legt mira, das vollständige Anwendungsschema und die Rollen mira_owner, mira_app, mira_backup und mira_restore an.
  3. Installieren Sie danach das Enterprise-Applikationssetup einmal systemweit als Administrator.
  4. Starten Sie FLEET Mira in einer administrativen Einrichtungs-Sitzung und verbinden Sie es mit localhost, dem gewählten Port und der Datenbank mira.
  5. Testen Sie die bereits initialisierte Datenbank. Die Verbindungskonfiguration wird maschinenweit unter %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise gespeichert und das Kennwort mit Windows DPAPI geschützt.
  6. Konfigurieren Sie die Dateiarchive auf einem für alle vorgesehenen Sitzungen erreichbaren lokalen NTFS-Pfad, beispielsweise D:\FLEET-Mira-Data.
  7. Melden Sie eine normale Benutzersitzung an und prüfen Sie Anmeldung, Lese-/Schreibrechte, Berichtsausgabe und Archivzugriff.
  8. Installieren Sie Client und Dienst gemeinsam über /COMPONENTS=client,worker und prüfen Sie, dass nur der Dienst Hintergrundaufgaben ausführt.

Die gemeinsame Installation erzeugt keinen eigenen Kombiniert-Modus. Jede Terminalserversitzung bleibt ein Client; Scheduler, Benachrichtigungen und zentrale Importe laufen ausschließlich im Dienst.

Anmeldung diagnostizieren

  • Prüfen Sie zuerst %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log.
  • POSTGRESQL_SCHEMA verified bestätigt Verbindung und vollständige Startprüfung, aber noch nicht den eigentlichen Benutzerlogin.
  • Suchen Sie nach dem ersten CRITICAL-Eintrag unmittelbar nach dem Klick auf Anmelden. Der zugehörige Traceback nennt Repository, SQL-Anweisung und PostgreSQL-Fehlerklasse.
  • Der Client zeigt unerwartete Datenbankfehler zusätzlich direkt im Anmeldedialog an. Kennwörter werden weder dort noch im Log ausgegeben.
  • Ein permission denied for schema public darf mit einem aktuellen Setup nicht auftreten: mira_app schreibt Anwendungsdaten, führt aber keine DDL-Anweisungen aus.

Bestehende SQLite-Daten migrieren

  1. Erstellen und prüfen Sie vorab eine unveränderte Sicherung der SQLite-Datei sowie der zugehörigen Dateiarchive.
  2. Beenden Sie alle anderen FLEET-Mira-Instanzen und stoppen Sie den Dienst FleetMiraWorker auf allen Worker-Hosts.
  3. Öffnen Sie in Enterprise Enterprise → SQLite-Datenbank migrieren.
  4. Wählen Sie die SQLite-Quelle. Der Assistent öffnet sie schreibgeschützt, führt PRAGMA quick_check aus und zeigt Tabellen- und Datensatzanzahlen.
  5. Die verpflichtende Option DDD-, Dokument- und Finanzarchive in das FLEET-Mira-ProgramData-Verzeichnis kopieren übernimmt die zugehörigen Dateien atomar nach %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\state. Der Assistent prüft vorhandene Zieldateien anhand der bestehenden SHA-256-Werte und bricht bei fehlenden oder veränderten Referenzen ab. Erst danach werden alle DDD-, Dokument-, Manifest- und Finanzarchivpfade innerhalb derselben PostgreSQL-Transaktion auf portable state/...-Pfade normalisiert. Es werden keine neuen fachlichen Hashwerte oder Signaturen erzeugt.
  6. Geben Sie Benutzer mira_restore und das beim PostgreSQL-Setup festgelegte Restore-Kennwort ein. Diese Zugangsdaten werden ausschließlich für die aktuelle Migration verwendet und nicht gespeichert.
  7. Bestätigen Sie das Ersetzen des leeren beziehungsweise vorgesehenen Mira-Schemas. Die Übertragung erfolgt als mira_owner in einer PostgreSQL-Transaktion; Fehler führen zum Rollback. Danach werden Enterprise-Worker-/Backupobjekte und die Rechte für mira_app und mira_backup wiederhergestellt.
  8. Starten Sie Enterprise neu und vergleichen Sie Benutzer, Fahrzeuge, Tachodaten, Belege und Stichprobenberichte mit dem Altsystem.
  9. Aktivieren Sie den Worker erst nach schriftlicher Abnahme der Migration.

Sicherung, Update und Rückfall

  • Unter Administration → Sicherungen → Quick Backup kann ein berechtigter Administrator unabhängig vom konfigurierten Sicherungsziel einen PostgreSQL-Custom-Dump als ZIP-Datei in ein ausgewähltes lokales Verzeichnis exportieren. Die ZIP-Datei enthält mira.dump und ein Prüfsummenmanifest. Dafür werden Benutzer mira_backup und dessen Kennwort abgefragt; das Kennwort wird nicht gespeichert. Diese Diagnosesicherung enthält ausschließlich die Datenbank und ersetzt keine vollständige Enterprise-Sicherung der Dateiarchive.
  • Die Zielkonfiguration blendet abhängig vom Provider nur die jeweils benötigten Felder ein. Für Dateisystem/UNC steht eine Verzeichnisauswahl, für die Google-OAuth-Konfiguration eine JSON-Dateiauswahl zur Verfügung.
  • Sichern Sie PostgreSQL regelmäßig mit pg_dump oder einem zentral überwachten PostgreSQL-Sicherungssystem und testen Sie pg_restore.
  • Sichern Sie Tachodaten-, Finanzbeleg- und weitere Dateiarchive getrennt und konsistent.
  • Erstellen Sie vor jedem Update ein PostgreSQL-Dump und eine Archiv-Sicherung; beenden Sie dabei alle Clients und den Worker.
  • Die SQLite-Snapshot-/Restore-Funktion von Basic/Pro ist in Enterprise deaktiviert.
  • Bewahren Sie die ursprüngliche SQLite-Datenbank bis zum Ende der vereinbarten Rückfallfrist unverändert und offline auf.

Abnahmecheckliste

  • [ ] Setups und Prüfsummen stimmen überein.
  • [ ] PostgreSQL-Daten liegen auf einem lokalen festen NTFS-Datenträger.
  • [ ] mira_app kann nur aus den vorgesehenen Netzen beziehungsweise lokal zugreifen.
  • [ ] TLS, Firewall, pg_hba.conf und DNS sind dokumentiert und getestet.
  • [ ] Jeder Client verwendet dieselbe PostgreSQL-Datenbank und dieselben kanonischen Archivpfade.
  • [ ] Der Dienst FleetMiraWorker läuft und Enterprise-Clients starten keinen integrierten Worker.
  • [ ] Mehrere Benutzer können gleichzeitig lesen und schreiben.
  • [ ] PostgreSQL- und Dateiarchiv-Sicherung sowie Rücksicherung wurden getestet.
  • [ ] Migration und fachliche Stichproben wurden protokolliert.
  • [ ] Notfallzugang, Kennwortablage, Monitoring und Neustartverfahren sind dokumentiert.

Die bekannten Einschränkungen und noch erforderlichen Produktionsarbeiten stehen unter Offene Enterprise-Punkte.