Alexander wrote: ↑Fri 18. Aug 2023, 13:25
Einmal in die Repository Verwaltung gehen -> Das entsprechende Repository zum Bearbeiten öffnen -> Speichern klicken.
Das triggert den Job "Integritätsprüfung / Statistiken aktualisieren" - wenn der durchlaufen wurde, taucht der Eintrag auch wieder in der Liste auf.
Ich bin nun erstmalig mit dem Server umgezogen (neuer Hostname+IP), hatte vorher auch nie wirklich Backups gemacht, da die Daten auch offline noch vorhanden sind.
Hostname + IP sind in der Datenbank in den settings bereits angepasst.
Habe am Ende meine Lets Encrypt-Zertifikate wie in der Anleitung wiederhergestellt und leider das Original von der keyhelp-Administrationsseite gelöscht. Bin auf den Fehler erst danach draufgekommen.
Ich habe zwischendurch ein Snapshot gemacht, müsste also nicht alles nochmal machen, jedoch aus Interesse würde ich gerne wissen wie ich diese Neu erstellen lassen kann?
Über Wartungsintervalle -> Wartung von SSL/TLS-Zertifikaten wird das Zertifikat nicht als Fehlerhaft erkannt und als gültig abgetan.
Ich nehme mal an ich habe das Zertifikat vom alten Server eingespielt, es ist "aktiv" und dieses ist natürlich nicht passend zum nun neuen Hostname.
Welche Zertifikatsteile muss ich löschen damit keyhelp dieses neu erstellt?
Ich habe gestern aus dem Snapshot (vor Schritt 4) den /etc/ssl/keyhelp Ordner mal gesichert.
Vor dem Schritt 4 und 5 konnte ich das keyhelp-webinterface problemlos aufrufen.
Nach Schritt 4&5 erhalte ich Zertifikatsfehler.
Nach mehreren hin und her schieben der Zertifikate und löschen von veralteten, war die Seite wieder "sicher" aufrufbar,... welcher Schritt davon genau zum Ziel geführt hat, habe ich noch nicht verstanden.
Ich weiß nicht welche Zertifikatsteile für das Webinterface zuständig sind.
Gibt es irgendwo eine Anleitung wie man bei hostname+ip-wechsel richtig vor geht?
EDIT:
Ich habe nun alle Files in dem Ordner /etc/ssl/keyhelp mit den Files der neu installierten Instanz belassen und nur den /etc/ssl/keyhelp/letsencrypt-Ordner (ausgenommen dem darin enthaltenen keyhelp-Ordner) aus dem Backup wiederhergestellt, damit scheint nun alles zu gehen...
Auf einem Debian 10 System gibt es seit dem 03. Februar diesen Jahres auch noch folgende Dateien in denen die KeyHelp User stehen.
Wie muss man mit diesen Dateien verfahren?
/etc/subgid
/etc/subgid-
/etc/subuid-
/etc/subuid
Korrektur: Es ist ein Debian 10 System
Gruß,
Tobi
----------------------------- wewoco.de Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
"SubUID/GIDs are a range subordinate user/group IDs that a user is allowed to use. These are commonly used by containerization software, such as LXD and Podman, for creating privilege separated containers."
Da Container nicht Bestandteil von Keyhelp sind, messe ich diesen Dateien erstmal keine weitere Bedeutung ein.
Mit freundlichen Grüßen / Best regards
Florian Cheno
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
Florian wrote: ↑Fri 1. Mar 2024, 12:29
ich habe die Anleitung bezüglich der Anpassung von group und gshadow nochmal überarbeitet.
Und ich das gesamte Dateihandling und Datenbankrumgefummle.
Geht jetzt alles automatisch mit meinem brandneuen Skript welches ich im ersten Beitrag hinzugefügt habe.
Viel Erfolg bei der Wiederherstellung
Gruß,
Tobi
----------------------------- wewoco.de Das Forum für Reseller, Digital-Agenturen, Bildschirmarbeiter und Mäuseschubser
