ISP Config 3 Migration

Dieses Thema im Forum "Tipps - Tricks - Mods" wurde erstellt von Teris Cooper, 20. Nov. 2014.

  1. Teris Cooper

    Teris Cooper New Member

    Hier haben ich ein Shell-Script, weleches es ermöglicht, ISPConfig 3 inklusive aller Daten auf einen neuen Server zu migrieren.

    https://github.com/teris/Debian-ISPConfig3-migration

    Bitte beachtet, dass die User / Groups und UNIX-Kennwörter manuell eingefügt werden müssen.

    Es werden vom alten Server die Zugangsdaten gespeichert. Dies befindet sich unter dem Verzeichnis /root/old-server/.
    (passwd und group)
    Die Originale findet Ihr unter /etc/passwd und /etc/group. Diese einfach mit einem editor bearbeiten (vi oder nano)
    Beispiel:
    cat /root/old-server/passwd
    Ausgabe:
    replicator:x:1002:1002:,,,:/home/replicator:/bin/bash
    Dies einfach kopieren und in die originale einspeichern:
    nano /etc/passwd
    root:x:0:0:root:/root:/bin/bash
    replicator:x:1000:1000:,,,:/home/replicator:/bin/bash

    FERTIG!
     
    Till und florian030 gefällt das.
  2. florian030

    florian030 Member

    Warum exportierst Du nicht einfach nur die relevanten Daten (web*, ispconfig, ispapps)? Und wenn bspw. www-data auf dem neuen Server eine andere UID hat, müssen auch noch ein paar Rechte neu gesetzt werden. Sonst aber eine schöne Idee.
     
  3. Teris Cooper

    Teris Cooper New Member

    Grund dafür ist ja, dass man eben einfach nur den Server umziehen kann, aufgrund besserer Leistung oder so, jedoch nicht alle UID's erneuern muss und die Kunden, sofern man welche hat, nicht neue Passwörter vergeben muss. Darum habe ich das gebaut^^
     
  4. Till

    Till Administrator

    Es kann aber sein dass sich die UID's unterscheiden, z.B. wenn Du eine andere Installationsreihenfolge der Applikationen verwendet hast. Daher ist es wichtig das zumindest zu kontrollieren.
     
  5. Teris Cooper

    Teris Cooper New Member

    Es kann nicht nur sein, es wird sogar so sein. Aus diesem Grund, habe ich in dem Script das so eingebaut, dass die UIDs vom alten Server in /root/old-server/ gesaved wird. Grund dafür, wenn die Datein überschrieben werden, kommt man nicht mal mehr mit dem ROOT benutzer auf den Server und das wollen wir ja nicht.
     
  6. florian030

    florian030 Member

    Und deswegen ist es auch ausreichend, die oben genannten UIDs auf dem alten Server zu exportieren und auf dem neuen zu importieren. Die UID für root ändert sich übrigens nicht und mit dem alten Paßwort kannst Du dich dann problemlos anmelden.
     
  7. tom.1

    tom.1 New Member

    Zum Sichern und Rücksichern der von ISP Config angelegten Benutzer und Gruppen habe ich in meinem Backupskripten immer folgenden Code genutzt (Pfade anpassen, sonst geht's nicht):

    Backup:
    Code:
    echo "# Backup User Accounts"
    umask 007
    grep ^web /etc/passwd > $backupdir/passwd.ISPusers
    grep ^web /etc/shadow > $backupdir/shadow.ISPusers
    grep ^client /etc/group > $backupdir/group.ISPusers
    echo "Done"
    
    Restore:
    Code:
    cp /etc/passwd /tmp/passwd.bak
    umask 007
    grep -v ^web /etc/passwd > /tmp/pass.tmp
    grep ^web /path-to/passwd.ISPusers >> /tmp/pass.tmp
    mv /tmp/pass.tmp /etc/passwd
    
    cp /etc/shadow /tmp/shadow.bak
    grep -v ^web /etc/shadow > /tmp/shad.tmp
    grep ^web /path-to/shadow.ISPusers >> /tmp/shad.tmp
    mv /tmp/shad.tmp /etc/shadow
    chown shadow:root /etc/shadow
    
    cp /etc/group /tmp/group.bak
    grep -v ^client /etc/group > /tmp/grp.tmp
    grep ^client /path-to/group.ISPusers >> /tmp/grp.tmp
    mv /tmp/grp.tmp /etc/group
    
    Beim Backup werden mittels grep die Benutzer, deren Name mit "web" beginnt und die Gruppen, die mit "client" beginnen in Dateien gespeichert.
    Beim Restore werden die originalen Dateien passwd, shadow und group erst in /tmp/ gesichert. Dann werden noch einmal Kopien angelegt, aus welchen die "web..." und "client...-Einträge herausgefiltert werden - falls es schon ISP Config Benutzer auf dem neuen System gab. Der Umzug funktioniert ja nur, wenn man ISP Config 1:1 überträgt. Zusammenführen geht nicht, deshalb können/müssen diese Einträge soweit vorhanden auch weg. Die weiteren Kopien werden dann mit den gesicherten Daten zusammengeführt und nach /etc kopiert.

    Einen einzigen Fallstrick bei dieser Methode gibt es, wenn man einen regulären (nicht ISP Config-)Benutzer hat, dessen Benutzername mit web beginnt. Dieser wird beim Backup mitgenommen und beim Restore aus den Dateien des neuen Servers herausgefiltert. Letzteres kann ein Problem werden und muss deshalb manuell kontrolliert werden. Gleiches gilt für reguläre (nicht ISP Config-)Gruppen, die mit "client" beginnen.

    Die Code-Schnipsel stammen aus einem Backup-Skript von djTremors aus irgendeinem Forum (ist schon eine Weile her), aller Dank geht deshalb an ihn.
     
  8. Till

    Till Administrator

    Nur als Hinweis: Dieser grep Befehl lässt aber die shelluser aus, die Du in ISPConfig für die Webseiten angelegt hast. Hast Du keine Shelluser angelegt, geht es so.
     
  9. tom.1

    tom.1 New Member

    Das stimmt. Die Shell-User werden nach dem Muster [client_id]xyz angelegt.

    Für ein Backup gibt es leider keine einfache Standardlösung. Für passwd und group könnte man es an der UID/GID festmachen, die ist ja immer >5000. Dann sind im Backup aber auch die ISPConfig "Systembenutzer" dabei. Ist es richtig, dass sich deren Anzahl sich auch in Zukunft nicht ändert? Bei mir beginnen die web-User mit GID 5005 und UID 5004. D.h. man könnte für ein Backup theoretisch mit diesen Werten arbeiten. Bleibt noch shadow. An der Stelle fehlt mir eine einfache Idee - man könnte die auszulesenden Einträge mit den zuvor aus passwd und group ausgelesenen abgleichen. Fühlt sich aber nach einigem Programmieraufwand an. Da hab ich die paar Shell-User schneller per Hand exportiert. Bei mir sind es 0, das geht noch schneller :D

    Am sichersten wäre es wohl, diese Funktionalität in ISPConfig selbst zu integrieren. Das System sollte ja "wissen", welche Benutzer es selbst erstellt hat, d.h. welche für das Backup/den Umzug exportiert werden müssen.
     
  10. Till

    Till Administrator

    Das ist ein mögliches Schema. Das Schema ist aber frei konfigurierbar, daher können die Uernamen nahezu beliebig sein.

    Das Ganze ist an sich recht einfach zu lösen, denn wie ich oben geschrieben habe teilen sich diese shell user die UID (also die numerische ID) mit den web* Usern. Was ,an also machen muss ist folgendes:

    1) Alle web* user mit grep extrahieren in eine temporäre Datei.
    2) die Liste der user durchgehen und dann für jede enthaltene UID ein grep auf die passwd Datei machen.
     
  11. florian030

    florian030 Member

    Könnte man nicht web_domain um die GID und UID erweitern? Zumindest solange connect_userid_to_webid gesetzt ist?
     
  12. Till

    Till Administrator

    Könnte man generell machen, ich denke aber ads wäre einfach nur doppelte Datenhaltung denn man kann die UID des Users ja in php mittels posux Funktionen abfragen oder auch eifach mittels grep aus der passwd Datei abfragen.
     
  13. florian030

    florian030 Member

    Ich dachte dabei mehr an die Möglichkeit, bei einem Umzug die User dann per resync anlegen zu können.
     
  14. Till

    Till Administrator

    Ok, ja. dafür kann es Sinn machen. Das ist aber gerade bei multiuser systemen ein echtes Problem denn dazu müsste der slave ja die uid's von shell usern in der master DB ändern können, wenn dann mal ein slave gehacked wird dann kann man da sehr viel Schaden auf allen nodes anrichten. Und bei connect_userid_to_webid servern könnte dar rsync die ID's ja sowieso berechnen.
     
  15. florian030

    florian030 Member

    Bei einem connect user - web geht das. Ich hab bei mir keine Shell-User. Haben die dann immer die gleiche ID wie die dazugehörige Website? Dann dürfte es nicht so kompliziert sein, dass dem resync-tool dann auch noch beizubringen.
     
  16. Till

    Till Administrator

    Linux USERID = min userid + web ID

    Die min userid ist standard 1000 und unter System > server config > Start ID for userid/webid connect definiert.
     
  17. Till

    Till Administrator

    Ein Problem gäbe es an sich nur wenn jemand die min userid ändert nachdem das erste web angelegt wurde. Das führt aber immer zu Fehlern wenn jemand versuchen sollte sie zu verkleinern (vergrößern ist ok), sollten wir ggf. noch als fehlermeldung abfangen, falls jemand das versuchen sollte.
     
  18. florian030

    florian030 Member

    Stellt sich nur die Frage, wie man das anlegen der user bei einem resync realisiert - als eigenes plugin oder die vorhandenen plugins erweitern bzw. useradd dort anpassen und die uid mitgeben.
     
  19. Till

    Till Administrator

    An sich müsste das bereits jetzt schon so sein, denn wenn connect angeschaltet ist wird ja beim anleen der user die uid übergeben, sollte also auch beim resync gehen.
     
  20. florian030

    florian030 Member

    Dann kann man sich bei einem Umzug ja das Sichern von passwd und group sparen. Einfach nach der Installation (bei nur einem Server einen Dump von dbispconfig einspielen und) einen kompletten Resync laufen lassen.
     

Diese Seite empfehlen