Debian 7 + EASYSCP 1.1.x auf Debian 9 EASYSCP 2.1.x?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Debian 7 + EASYSCP 1.1.x auf Debian 9 EASYSCP 2.1.x?

      Ich habe ja schon eine Weile eine Installation auf Debian 7 mit der EASYSCP 1.1.x erfolgreich am Laufen. Nach dem Motto "never change a running system" habe ich mich bisher nicht dazu durch ringen können, an am Debian oder am EASYSCP etwas upzugraden. Speziell das Risiko, dass meine User im Problemfall ihre Mails nicht mehr bekommen oder senden könnten, treibt mir den Angstschweiß auf die Stirn.

      Nun habe ich vor einigen Tagen einen neuen physischen Server bezogen und die VMs erfolgreich übersiedelt (neue IPs). Dazu habe ich die server_ips Tabelle manuell angepasst, denn einmal eingestellt kann man die IP Adresse scheinbar nirgends mehr regulär warten.

      Weil aber gerade alle Komponenten neue Versionen bereit stellen, würde ich gerne einen Versuch wagen, das ev. auf Debian 9 + EASYSCP 2.1 neu hoch zu ziehen - aber die Konten zu übernehmen. Meine Hoffnung ist, dass ich dann wieder eine Weile Ruhe habe.

      Gibt's dafür eine empfohlene Vorgehensweise?

      Debian 9 minimal aufsetzen + EASYSCP + Daten kopieren, oder eher VM kopieren, dist-upgrade + EASYSCP upgrade, oder erst EASYSCP Upgrade am Debian 7 und anschließend Dist-upgrade auf Debian 9?
      Oder alles umgekehrt?

      Das Dist-Upgrade schraubt ziemlich am System herum, beispielsweise am DNS Server, der jetzt auch eine SQL Datenbank braucht. MySQL ist gegen MariaSQL getauscht worden, Apache wird zwar zunehmend gegen NGINX ersetzt, aber wenn Apache stabil läuft, werde ich kaum umstellen.
    • ShadowJumper wrote:

      Hast du die Möglichkeit das ganze System als Snapshot zu speichern oder ein Spiegelsystem zu betreiben?
      Einen Snapshot kann ich nicht machen. Ich virtualisiere mir QEMU/KVM/Cloudmin. Ich kann die VM runterfahren und kopieren. Dann geht 2 Stunden der Server nicht, wäre aber machbar. Ich muss das allerdings auf eine neue IP Adresse konfigurieren, ehe ich die Kopie wieder hoch fahren kann. Eine habe ich dafür in Reserve.

      Das Testen ist allerdings eine Quälerei, weil natürlich ALLES entweder auf die IP bezogen ist, oder auf die Domain. Die zeigt aber auf den originalen Server. Sowohl innerhalb als auch außerhalb.

      Deshalb war meine erste Idee, überhaupt leer zu installieren und nur die Nutzdaten zu migrieren. Das kann ich mit kurzen Ausfallszeiten machen. Die großen Datenmengen kann ich live kopieren. Das Testen wird trotzdem kompliziert, vor Allem was E-Mail angeht. Deshalb war meine zweite Idee, das In-Place zu aktualisieren - natürlich mit Backup.

      Warum muss die Konfiguration bloß so kompliziert sein? Alles hängt von allem ab und alles wichtige ist in einer Datenbank verschlüsselt...
    • Hi,

      die verschlüsselten Daten in der Datenbank sind ja zum Schutz, falls jemand in die DB Einbricht. Somit könnte derjenige nichts mit den Daten anfangen.

      Das Spiegelsystem wäre ja nur dazu da, um die Datenbank auf 2.0 bzw. 2.1 Schema zu bringen. Dann läuft man nicht Gefahr was kaputt zu machen.

      Damit ist der Umzug dann relativ einfach:
      1. Neues System aufsetzen, dabei darauf achten das KEY/IV vom alten System übernommen wurden (vor dem starten des Setups in der XML eintragen)
      2. Normal installieren
      3. DB durch die zuvor gesicherte DB ersetzen
      4. Domains etc. auf "add" setzen und über den Debbuger die dann offenen Requests anstoßen.
      5. Daten vom alten System kopieren (Web und Mails).


      Ohne Spiegelsystem müsste man ansonsten die DB im laufenden Betrieb hochziehen, was auch geht aber Probleme bereiten könnte, wenn mehrere Leute auf das Panel zugreifen. Zumal ein Dist-Upgrade auch nicht wirklich zu empfehlen ist, da dabei zu viele Leichen übrigbleiben. Diese können dann später zu Problemen führen.
      Gruss
      Shadow
    • ShadowJumper wrote:

      Neues System aufsetzen, dabei darauf achten das KEY/IV vom alten System übernommen wurden (vor dem starten des Setups in der XML eintragen)

      Normal installieren

      DB durch die zuvor gesicherte DB ersetzen

      Domains etc. auf "add" setzen und über den Debbuger die dann offenen Requests anstoßen.

      Daten vom alten System kopieren (Web und Mails).
      Sorry, wenn ich mich grad wieder blöd anstelle. Ich möchte die Tage zwischen den Feiertagen nützen, das leidige Problem endlich zu lösen. Die obige Aufgabenliste verstehe ich so:

      1. Debian 9 LAMP neu aufsetzen,
      2. EasySCP Install Archiv laden, entpacken
      3. Keys richtig eingetragen
      4. EasySCP 2.02 "normal installieren"


      Nach der Operation habe ich zwar ein super Schema aber keine User, keine E-Mails, keine Datenbanken, keine FTP Accounts, kein garnichts. Eine schöne leere Installation. Mein Verständnis Problem beginnt da, wo ich eigentlich "alle Benutezrdaten" übernehmen will:

      • "DB durch die zuvor gesicherte DB ersetzen
      Ich mache also von der EasySCP Datenbank am alten Server eine MySQL Sicherung, kopiere die auf den neuen Server und mache ein Restore?? Dann habe ich ja wieder das alte Schema drin. Die alten Daten kann man ja wegen der unterschiedlichen Spalten nicht in das neue Schema importieren und wenn die Tabellen gedropt werden habe ich erst wieder das alte Schema.

      Angenommen ich kriege die User und Domains da irgendwie rein, dann wird "Domains etc. auf "add" setzen" mir doch weder die Datenbanken noch die FTP Accounts und auch die E-Mail Konten nicht wieder (leer) anlegen, oder übersehe ich da was offensichtliches?

      Von 2.02 auf 2.1.0 wird das dann wieder die gleiche Prozedur?
    • Hi,

      deswegen habe ich ja oben extra was von Spiegelsystem geschrieben um die DB hochzuziehen auf das aktuelle DB Schema. Das geht auch auf dem "alten" System, aber danach kannst du das alte System nicht mehr benutzen (da die DB dann auf Stand 2.x ist). Ohne Angepasste DB bzw. aktuelles Schema geht das ganze nicht bei einem Server Umzug, das wurde aber an diversen Stellen mehrfach geschrieben.

      Von 2.0 auf 2.1 hast du das Problem nicht, da du dort ja lediglich die neue Version entpackst und das Update den Rest erledigt. Würdest du dort aber von einem z.b. 2.0 Server mit Debian 8 auf ein 2.1 mit Debian 9 wechseln (als Beispiel) hättest du auch dort das gleiche Problem bezgl. dem Datenbank Schema.

      Das hat aber nichts mit 2.0 bzw. 2.1 zu tun, sondern das du unterschiedliche Datenbank Strukturen hast. Deswegen ja immer der Hinweis die alte DB hochzuziehen, und diese dann auf dem neuen System zu importieren (deswegen der Hinweis mit dem alten KEY/IV wegen der Verschlüsselung in der DB). Dann läuft das ganze völlig Problemlos bei einem Server Umzug.

      Bei dir ist jetzt halt die Konstellation gegeben, altes System auf altem OS, was du auf neues System mit neuem OS bringen willst. Das ist nicht ganz so trivial. Hättest du z.b. auf dem alten System schon eine 2.0 drauf, wäre die Empfehlung auf Debian 9 die 2.0 zu installieren und danach erst das Update auf die 2.1 zu machen, weil dann der Daemon alle nötigen Anpassungen automatisch macht.
      Gruss
      Shadow
    • ShadowJumper wrote:

      deswegen habe ich ja oben extra was von Spiegelsystem geschrieben um die DB hochzuziehen auf das aktuelle DB Schema
      Ok. Ich seh's ein. Ich bin doof. Normalerweise stell ich mich nicht so an, grad am Computer nicht.

      Das "Spiegelsystem" ist also ein drittes, nicht das neue, das vom alten gespiegelt wurde.
      Das "Hochziehen" der DB auf das aktuelle Schema ist eine Sache die ein normaler Mensch mit Erfahrung am Computer nach dem Lesen der Upgrade Anleitung selbständig zuwege bringt - steht alles in der Doku? Oder ist das so eine Kiste, die man "natürlich weiß", wenn man schon in der Krabbelstube Linux Kisten gehackt und natürlich internes Wissen über die ganze Programmierung des EasySCP hat?

      Ich installiere mir also ein neue, leeres Debian 9, installiere mir da die 2.0.2 (mir ist eine stabile Version lieber als eine, bei der dies und das "noch nicht" richtig funktioniert - wobei laut Change List die Debian 9 Unterstützung ja eigentlich erst mit der 2.1 gewährleistet ist. "noch nicht" kann ja durchaus auch ein Jahr oder länger dauern, weil die Leute hier in ihrer Freizeit arbeiten und nicht Vollzeit. Danke dafür). Dann kopiere ich die alte Installation auf eine dritte VM, vergleiche die Datenbanken und passe alle Felder und Tabellen manuell(?) so an, dass sie der neuen DB entsprechen. Von dieser "hochgezogenen" DB mache ich eine Kopie, die ich in der leeren Installation importiere.

      Ein geregeltes Upgrade einer 1.x Version auf 2.x scheint es ja nicht direkt zu geben, sonst würde ich am neuen Server ja zuerst die 1.1.15 installieren, die Datenbank kopieren und "einfach ein Update auf 2.x" machen lassen?

      Aber

      ShadowJumper wrote:

      das wurde aber an diversen Stellen mehrfach geschrieben

      Das Update von 2.0.2 auf 2.1.0 geht jetzt? Da finde ich nur die Ankündigung von Juli, dass es derzeit nur für Neuinstallationen funktioniert aber "bald" ein Update kommen wird. Ich habe die im Paket enthaltene Doku gelesen und da steht in 'easyscp-2.1.0/docs/Debian/UPDATE':

      EasySCP Version: 1.1.0
      UPDATE Script: 1.00

      ...
      NOTE: EasySCP can only be updated from post 1.1.0. If you have a
      version prior 1.1.0 (final release) installed, migrate to EasySCP 1.1.0 first.


      Da gehe ich jetzt vorsichtshalber davon aus, dass das ein altes File ist, denn im INSTALL file steht schon was von Version 2.1.0. Bevor ich mir aber den Zorn meiner User zu ziehe, weil sie keine E-Mails mehr bekommen, nur weil ich leichtsinnigerweise darauf baue, dass das Update das schon alles irgendwie richtig machen wird, deklariere ich mich hier lieber als DAU.

      Oder ist das "Setup" gleichzeitig auch das Update und die Anweisungen in der Update Datei sind hinfällig?

      Ich bin sonst eher Risiko freudig, beim Ausprobieren und wenn was mal nicht geht, dann geht's halt nicht. Aber ich habe User am Server die sich darauf verlassen, dass ich nicht fröhlich so lange herum experimentiere, bis es dann doch irgendwann wieder geht. Deshalb wäre mir eine(!) Anleitung hilfreich, die das Procedere nachvollziehbar beschreibt.

      Sei bitte nicht genervt, ich krieg das schon irgendwie hin. Und dann lass ich Euch wieder 5 Jahre in Ruhe.
    • Hi,

      dann nochmal Schritt für Schritt die wichtigen Punkte.

      Zum hochziehen der Datenbank brauchst du die Datei "gui/include/EasySCP/Update/Database.php" aus der Version, welche du auf dem neuen Server installieren willst. Diese kopierst du auf das alte bzw. Spiegelsystem und überschreibst die vorhandene Datei, je nachdem welchen Weg du gehen willst. Wenn du dich dann als Administrator einloggst, teilt dir das System mit, das ein Update für die Datenbank vorliegen würde. Das führst du dann aus. Achtung !!! Ab dann ist die alte Version nicht mehr Lauffähig !!!


      Jetzt hast du ein Schema, das 1:1 zur neuen Version passt. Dieses kannst du dann mittels PMA exportieren, und auf dem neuen System importieren um deine Daten zu übernehmen.

      Bzgl. Debian 9: Da musst du auf die neue 2.1 gehen. Die 2.0.2 unterstützt Debian 9 nicht. Das ist aber auch kein Problem, die 2.1.0 läuft absolut stabil. Sieh es als Vorteil, du hast dann gleich das aktuellste System, welches sich leichter updaten lässt.

      Alle anderen "Hürden" bei einem Upgrade die du evtl. gelesen hast kannst du vollständig ignorieren, da diese bei einer Neuinstallation keine Rolle spielen. Hier ist nur das Datenbank Schema wichtig, und das du VOR der Installation den KEY/IV in der "setup/config.xml" eingetragen hast. Der Rest ist für dich unwichtig, da du ja sowieso dann ein sauberes leeres System hast.

      Bei deiner Konstellation ist es also wesentlich einfacher direkt auf das neueste System zu gehen, da du dir dann viel Arbeit ersparst. Einzige aktuelle Hürde ist noch die Änderung der Zugriffsrechte auf die Datenbank ab Debian 9. Am einfachsten ist es da einen separaten User für EasySCP anzulegen auf der Konsole mittels


      Source Code

      1. mysql -u root
      2. grant all on *.* to easyscp@localhost identified by 'dein Passwort' with grant option;
      3. exit
      und diesen dann beim Setup anzugeben.

      Kurz zusammengefasst also wie folgt:

      • KEY/IV vom alten System in der "setup/config.xml" eintragen.
      • EasySCP 2.1.0 auf dem neuen System mit Debian 9 installieren.
      • "gui/include/EasySCP/Update/Database.php" vom neuen System auf das alte kopieren, und Datenbank Schema aktualisieren
      • Datenbank auf dem alten System exportieren
      • Datenbank auf dem neuen System exportieren (für alle fälle), danach leeren und den Dump vom alten System einspielen
      • "Add" Einträge wie mehrfach beschrieben setzen
      • Ins Panel als Admin einloggen und über den Debugger alle offenen Requests ausführen lassen
      Danach hast du ein 1:1 System mit allen Usern, Mailkonten etc. Das einzige was in der aktuellen Version (noch nicht) automatisch erzeugt wird sind die SQL Datenbanken für die einzelnen Domains. Ich arbeite gerade daran das auch noch einzubauen. Falls du viele Datenbanken hast sag Bescheid, ich habe eine Lösung auf der Kommandozeile dafür um das zu erledigen.
      Gruss
      Shadow
    • Vielen dank für die nochmalige Auflistung was genau zu tun ist.

      Ich bin schon fast am Ziel. Neuer Server läuft, V2.1.0 ist drauf, alle Konten wurden übernommen, die Datenbanken hab ich selber hin bekommen. Eigentlich schaut es recht gut aus. Mail Logins funktionieren, FTP Logins funktionieren, ich habe auch für alle Kanäle wieder die SSL zertifikate laufen. Mail Verzeichnisse kopieren noch.

      ... aber nach dem Wiederherstellen der Webs verweigert mit Apache das Ausführen der PHP Scripts. Ich bekomme "403 Zugriff verweigert", aber nicht bei jedem Web.

      Die phpinfo() habe ich probehalber bei einem Web zugelassen, das den Fehler nicht bringt und da bekomme ich auch eine Liste. Bei Einem Web das den 403 Fehler bringt, bekomme ich den auch bei dieser Minimal PHP.

      Ich vermute, dass der SUEXEC nicht richtig funktioniert, obwohl die UserID im Web Konfig korrekt eingetragen ist. Im SUEXEC.log sehe ich jedenfalls nicht, dass auf den betreffenden User gewechselt wurde, wenn ich ein Web aufrufe, das den 403er Fehler bringt. Dort wo das phpinfo() geht, sehe ich auch einen Eintrag in der SUEXEC.log.

      Ich finde aber auch sonst keinen wirklichen Hinweis auf die Ursache.

      Mistding....

      Ok, Problem abliegen lassen und gefunden. Aus irgend einem Grund war in den betroffenen Domains nach der Übersiedlung "PHP: nein" eingestellt. Warum auch immer. Die Domains funktionieren seit Jahren ausschließlich mit PHP. Wieder aktiviert und der 403 Fehler ist weg, dafür kommt die phpinfo() wideder :)

      Die IMAP Clients mussten nach der Übersiedlung neu eingerichtet werden, weil DOVECOT und COURIER unterschiedliche Verzeichnis Strukturen für Unterordner haben. Aber alle Mails wurden wieder gefunden :-))

      Wenn ich jetzt noch den Roundcube zum Laufen bringe, bin ich durch. Der zeigt nach dem Login nur eine weiße Seite. vermutlich irgend ein PHP Problem. Sobald ich das zugehörige Log gefunden habe, wird das wohl auch lösbar sein...

      ---
      OK, das mitgelieferte Roundcube 1.1 geht nicht mehr mit PHP7. Ein Update auf 1.3 hat das Problem auch behoben.

      Schaut aus, als ob es wieder rund läuft.

      VIELEN DANK!

      The post was edited 2 times, last by smallfreak ().

    • Danke für die viele Arbeit die Du da rein steckst.

      Ich hab glaub ich einen Bug gefunden: Die E-Mail Umleitungen (Aliase) werden nicht richtig verarbeitet, oder migriert. Viele haben ganz gefehlt und wenn ich eines änern will, ist hinterher im "source" Feld in der DB nichts drin. Es verliert beim Update also die Quell Adresse.

      Neu anlegen funktioniert, nur nicht ändern.
    • Source Code

      1. date.timezone = "UTC+2"


      smallfreak wrote:
      OK, das mitgelieferte Roundcube 1.1 geht nicht mehr mit PHP7. Ein Update auf 1.3 hat das Problem auch behoben.

      Schaut aus, als ob es wieder rund läuft.
      [/quote]

      ShadowJumper wrote:

      Hi,

      freut mich das alles geklappt hat.

      Und stimmt, RoundCube habe ich völlig vergessen, ich muss das die Tage dringend austauschen. ;(


      Moin.

      Gleich zum RoundCube 1.3:
      ggf. wird bei den Mails das Datum nicht angezeigt - bei mir war die Einstellung der PHP.INI falsch.


      Source Code: /var/www/fcgi/master/php/php.ini

      1. date.timezone = UTC+2
      Stimmt NICHT! Laut PHP 7.x Handbuch muß es 1. ein String sein, also wenn schon, dann

      Source Code

      1. date.timezone = "UTC+2"


      aber auch das hat nicht geholfen, geholfen hat:

      Source Code

      1. // date.timezone = "UTC+2"

      Gruß, Kuerbis
    • Weshalb ich heute egtl . mal reingeschaut habe:


      EasySCP Exception Message


      An error occured! Please, contact your administrator!

      Leider finde ich in den LOGs nichts. Alles andere scheint auch zu funzen (webmail, pma, etc).
      Irgendeine Idee wo ich das prüfen kann?
      Ich bin der Meinung vor 3 Tagen ging alles noch.

      Ich habe ja eine VM und damit eine Sicherung.... wenn ich eine neue VM damit erstelle (mit anderer IP), dann erhalte ich bei direktem Zugriff auf die IP die Apache-Default-Seite und bei

      htpps//:ip.ip.ip.ip
      Kommt: Ein Fehler ist während einer Verbindung mit ip.ip.ip.ip aufgetreten. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat. Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG


      Ich verstehe es nicht mehr.


      Ideen? Danke, Gruß, Kuerbis
    • kuerbis42 wrote:

      Kommt: Ein Fehler ist während einer Verbindung mit ip.ip.ip.ip aufgetreten. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat. Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG
      Das kam bei mir, wenn SSL am Host nicht aktiv war. Mal im Apache nachsehen, ob für Port 443 wirklich ein Web konfiguriert ist. Die 2.1 macht das eigentlich selbständig, wenn man (erst mal ohne SSL) anmeldet und Zertifikatsdaten hinterlegt. Ohne Zertifikat kein SSL. Ohne SSL die obige Meldung.

      Ich mühe mich gerade mit "letsencrypt" ab, so dass ich für meine Webs bei Bedarf ein Zertifikat anfordern kann und sich das auch automatisch refresht. Geht, aber benötigt noch Handarbeit. Das könnte man vielleicht mal fix einbauen:

      Einen Button "LetsEncrypt Zertifikat anfordern" in den SSL Dialog, den Refresh dazu gleich in den Scheduler einbauen.

      Wunsch für Version 2.2 :)
    • @smallfreak: Danke für den Vorschlag, aber mir viel gestern Abend im Bett ein, was ich ja geändert habe (wg. RoundCube):

      Lösung:

      Sowohl für das Datum-Problem mit RoundCube 1.3 und EasySCP


      Falsch, aber default:

      Source Code: /var/www/fcgi/master/php/php.ini

      1. date.timezone = UTC+2
      Richtig:

      Source Code: /var/www/fcgi/master/php/php.ini

      1. date.timezone = "Europe/Berlin"

      :)
    • sorry, dass ich den threat nochmal anstosse, aber ich hab folgende Fragen:

      1.) wenn von "KEY/IV vom alten System" gesprochen wird, handelt es sich um das file "/etc/easyscp/easyscp-keys.conf"?
      2.) zu welchem Zeitpunkt in "setup/config.xml" eintragen? Vor oder nach EasySCP WebGUI Setup?

      danke & greets
    • Hi,

      genau, die Daten stehen auch in der "EasySCP_Config_DB.php" im gleichen Pfad. Im zweifel würde ich immer die aus der "EasySCP_Config_DB.php" bevorzugen, da diese definitiv in verwenden sind. Die "easyscp-keys.conf" ist nur noch aus kompatibilitäts- gründen mit dabei.


      Bzgl. Zeitpunkt: VOR dem Start des WebGUI Setup. Ich arbeite daran diese Abfrage noch ins Setup mit aufzunehmen, quasi eine Art "erweiterte" Installation, wo man das dann direkt in der WebGUI eingeben könnte.
      Gruss
      Shadow