ISP Config 3 Migration

#1
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!
 
#3
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^^
 

Till

Administrator
#4
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
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
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
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.
 
#9
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.
 

Till

Administrator
#10
Das stimmt. Die Shell-User werden nach dem Muster [client_id]xyz angelegt.
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.
 

Till

Administrator
#12
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.
 

Till

Administrator
#14
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
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.
 

Till

Administrator
#17
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
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.
 

Till

Administrator
#19
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
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.
 

Werbung