Migration von i-MSCP zu KeyHelp

[xister]

Du kannst auch 100 Server zu einem zusammenführen. Das Skript macht es möglich. Wir haben auch mehrere uralte Systeme auf neue Hardware zusammengeführt. Lief alles einwandfrei!

[theqkash]

Du willst tatsächlich 44 Einzelserver in einem einzigen zusammenführen?

Welche Hardware haben die Quellserver?
Welche Hardware hat der Zielserver?

Bislang handelte es sich bei diesen 44 Maschinen um virtuelle Server. Aus verschiedenen Gründen wurden sie einfach auf getrennten Virtualitäten platziert. Es war, sagen wir mal, die alte Verkehrsverteilungslogik, bei der der Kunde, bei dem der i-MSCP stand, in VPS investiert hat, um den Verkehr zu verteilen, und nicht in die Dedicates, auf denen jetzt alles sitzt. Aus Sicht des Verkehrs und der Belastung wird also alles passen. Ich frage mich nur, ob der Migrator dies strukturell bewältigen kann.

Du kannst auch 100 Server zu einem zusammenführen. Das Skript macht es möglich. Wir haben auch mehrere uralte Systeme auf neue Hardware zusammengeführt. Lief alles einwandfrei!

Danke! Sie haben mich beruhigt!


Lukas

[Zeitkind]

Moin!

Mal eine Frage... wie gut wird eine Migration eines Servers funktionieren, der schon eine Migration von vhcs2 -> ispCP -> i-mscp hinter sich hat?

In der Datenbank sieht es.. gewachsen aus, laut imscp.conf wird

DATABASE_NAME = ispcp

verwendet.

Code: Select all

MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| ********_biz       |
| information_schema |
| ispcp              |
| ispcp_pma          |
| ispcp_rainloop     |
| ispcp_roundcube    |
| mysql              |
| performance_schema |
| *********_forum    |
| *********_web      |
| ser                |
| smf                |
| teamspeak3         |
| vhcs               |
+--------------------+
14 rows in set (0.02 sec)

MariaDB [(none)]> USE ispcp;

Database changed
MariaDB [ispcp]> SHOW TABLES;
+----------------------+
| Tables_in_ispcp      |
+----------------------+
| admin                |
| autoreplies_log      |
| config               |
| custom_menus         |
| domain               |
| domain_aliasses      |
| domain_dns           |
| domain_traffic       |
| email_tpls           |
| error_pages          |
| ftp_group            |
| ftp_users            |
| hosting_plans        |
| htaccess             |
| htaccess_groups      |
| htaccess_users       |
| httpd_vlogger        |
| log                  |
| login                |
| mail_users           |
| php_ini              |
| plugin               |
| quotalimits          |
| quotatallies         |
| reseller_props       |
| server_ips           |
| server_traffic       |
| sql_database         |
| sql_user             |
| ssl_certs            |
| subdomain            |
| subdomain_alias      |
| tickets              |
| user_gui_props       |
| web_software         |
| web_software_depot   |
| web_software_inst    |
| web_software_options |
+----------------------+
38 rows in set (0.00 sec)


USE ispcp; SELECT * FROM admin;


MariaDB [ispcp]> USE ispcp; SELECT * FROM admin;
Database changed
+----------+--------------+----+------------+----------------+ [...]
| admin_id | admin_name   |(PW)| admin_type | admin_sys_name | [...]
+----------+--------------+----+------------------------------ [...]
|        1 | admin        |****| admin      | vu2000         | [...]

Auf Unixebene sind die Usernamen auch alle noch schön im vhcs-Stil, in /etc/passwd

Code: Select all

vu2000:x:2044:2044:i-MSCP Control Panel Web User:/var/www/imscp/gui:/bin/false
vu2006:x:2045:2045:i-MSCP Web User:/var/www/virtual/derserver.tld:/bin/false

Laufen tut der Server mit i-mscp v1.5.3 auf 'nem Debian v9.13, und jetzt soll endlich mal umgestellt werden. In Frage käme halt Froxlor & SOGo und ähnliches, bin heute erst auf keyhelp gestoßen, kannte ich noch gar nicht. Der Server läuft z.Z. in einer proxmox-VM, der Nachfolger wird ebenfalls eine VM werden. An sich hatten wir uns schon damit abgefunden alles neu hochzuziehen, da liegt nicht wirklich lebenswichtiges, fast alles mehr oder weniger private Webseiten, Foren und Email. Aber auch das würde halt schon genug Arbeit machen. Der Omma einfach neues Kennwort per WhatsApp schicken wird nix, also wäre uns natürlich recht, wenn möglichst viel erhalten bliebe..

[space2place]

Ich kann Dich beruhigen. Auch diese Migration sollte durchlaufen. WIr hatten auch ein paar Server aus alten Zeiten, wo die Datenbank "ispcp" hieß.
Das Script schaut nach wie die Datenbank heisst, die von i-MSCP genutzt wird.

[Zeitkind]

Hmm.. naja, halt immer nur Updates gefahren, mit Linux geht so was ja recht problemlos.. ^^

Gut, dann werden wir das wohl mal probieren, erst mal in eine lokale VM, der alte Server muss dazu ja "nur" angehalten werden. Bin noch am überlegen, wie wir dann den neuen testen können, da die IPs etc. überall drin stecken. Hmmm.. Eventuell die VM runterladen und in ein Test-Netzwerk rein, wo wir die "echten" IPs simulieren können. Mal schauen, aber KeyHelp is damit wohl ein Kandidat geworden, muss mir das System eh erst noch mal genauer anschauen, danke soweit.

[Ralph]

Allow remote access = enable

Wenn ich hier eine etwas langwierige Situation habe ist mysql remote dann auch als Absicherung via iptables an die externe IP Adresse möglich oder verwendet das Migrationsscript noch andere Ports bzgl. Mysql?
Also anstatt Fail2ban sollte es doch auch damit klappen .... z.b. als cron job @reboot das script laden, damit gebe ich dann nur der Import IP Adresse Zugriff auf Mysql von extern:

Code: Select all

iptables -A INPUT -p tcp -s 111.111.11.111 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -s 111.111.11.111 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP
ip6tables -A INPUT -p tcp --dport 3306 -j DROP

[Ralph]

Bei einigen Anwendungen gibt es oft Probleme wg. dem abweichenden DocRoot und alles von Hand abändern (einige Pfade auch in der DB) ist nicht ohne ...
Wäre das nicht mit Symlinks machbar, die Originalpfade nachzustellen?
z.b.
mkdir /var/www/virtual
die Kunden /home/users/username dann verlinken nach /var/www/virtual/firstdomainname.tld
und in den /home/users/username ggf. noch Symlinks setzen /aliasdomain.tld/htdocs und subname/htdocs

Würde das funktionieren - und wäre es Updatesicher, also die Links im Userfolder?

[24unix]

Würde das funktionieren - und wäre es Updatesicher, also die Links im Userfolder?

Ich habe hier einige Frankensteins (z.B. Upgrade von Ubuntu auf Debian auf einer dev-Kiste ohne KH), aber bei einem Produktivsystem würde ich mich damit nicht wohlfühlen.
Um wie viele Domains geht's denn?

[Ralph]

Würde das funktionieren - und wäre es Updatesicher, also die Links im Userfolder?

Ich habe hier einige Frankensteins (z.B. Upgrade von Ubuntu auf Debian auf einer dev-Kiste ohne KH), aber bei einem Produktivsystem würde ich mich damit nicht wohlfühlen.
Um wie viele Domains geht's denn?

das sind mal gut 60 Webs wo der Pfad Probleme macht ...
Für die Symlinks müsste man halt noch ein script basteln um die Links zu unlinken wenn eine Domain gelöscht wird ...
erweiterte Berechtigungen gibt es damit keine, bleibt ja beim User Folder

[Jolinar]

Für die Symlinks müsste man halt noch ein script basteln um die Links zu unlinken wenn eine Domain gelöscht wird ...

Wäre es da nicht sinnvoller, ein Script zu basteln, was die Pfade direkt anpaßt anstatt so ein Gefrickel mit Symlinks...?

[24unix]

Für die Symlinks müsste man halt noch ein script basteln um die Links zu unlinken wenn eine Domain gelöscht wird ...

Ich würde es andersrum machen:

KH-Struktur behalten, und via Script die hosts anpassen.

Sonst ist das doch ne ewige Bastelbude.

Edit: Jolinar war schneller, aber sollte phpBB mir vor dem Senden nicht anzeigen, dass es schon neue Beiträge gibt?

[Ralph]

Danke Euch!
die Host Pfade anpassen wird schwierig, da hängt zu vieles mit dran open_basedir, tmp usw. logfiles und cronjobs ...
Pfade in den Anwendungen ändern wäre auch noch OK, aber in den Datenbanken ...
Die Symlinks an sich machen eigentlich keine Probleme solange die Quelle intakt bleibt ... hm, aber es ist wohl alles nicht so prickelnd

[24unix]

Danke Euch!
die Host Pfade anpassen wird schwierig, da hängt zu vieles mit dran open_basedir, tmp usw. logfiles und cronjobs ...
Pfade in den Anwendungen ändern wäre auch noch OK, aber in den Datenbanken ...

Absolute Pfade in der DB?

Nicht, dass ich das nicht kenne (10 Jahre legacy Projekt …), aber das wär ein guter Zeit zum refactoring

Die Symlinks an sich machen eigentlich keine Probleme solange die Quelle intakt bleibt ... hm, aber es ist wohl alles nicht so prickelnd
[/quote]

Einen Tod muss man sterben … Ich persönlich würde immer versuchen, alles an die Infra, in dem Fall KH anzupassen, nicht umgekehrt.

Ein Update, irgendwas ungeplantes geht schief und 60 Seiten offline ist auch keine tolle Vorstellung.

[Ralph]

@space2place

habe hier zwei Probleme beim migrieren von imscp:

Die FTP Passwörter werden nicht übernommen - werden ohne Hash in die KH ftpuser table gesetzt
aus:
$6$rounds=5000$rS8BY7V7V7X ......
wird:
TCG8vUZ>

Ist es machbar die Original Datenbanknamen und User beim API Import zu übernehmen, also ohne eine Prefix anzuhängen?
Bei Wordpress oder Joomla ist das nicht problematisch aber bei einigen anderen Anwendungen und vor allem eigenen PHP Anwendungen wird es ein riesiger Zeitaufwand.
Ich habe einige User mit eigenen PHP Anwendungen und 20+ Datenbanken, mit DB Namen die in zu vielen Scripten im Text vorkommen, es dauert Stunden um diese zu finden wenn überhaupt möglich ...

Code: Select all

find /home/users/username/www -type f -name "*.php" -exec grep 'dev' {} +

### edit ###
das mit den FTP Passwörtern würde ich gerne noch anpassen, mit den Datenbank und User Namen ist wohl ziemlich aufwendig die Prefix wieder raus-zu-fummeln oder eine weitere condition einzubauen und fraglich ob der Import dann noch funktioniert, also belasse ich es dabei

[space2place]

Hi Ralph,
Das mit den Datenbanken war schon mal Thema. Nein - Das werde ich nicht umprogrammieren.
Aus einem ganz einfachen Grund. i-MSCP kann Prefixe (1_, 2_ usw davor setzen). Bei KeyHelp war das damals nicht erlaubt. Deswegen ist das so gebaut worden.
Wenn Du das ändern willst und auch eigene Kappe nimmst, stenht es Dir frei das Git zu klonen und die Anpassungen selnbst durchzuführen.

Code: Select all

Die FTP Passwörter werden nicht übernommen - werden ohne Hash in die KH ftpuser table gesetzt
aus:
$6$rounds=5000$rS8BY7V7V7X ......
wird:
TCG8vUZ>

Das ist mir was ganz Neues. Du bist der erste nach so langer Zeit der das meldet.
Und

Code: Select all

$6$rounds=5000$

kenne ich nur von den Email Konten. Das hat nicht mit den FTP Konten zu tun. Das kommt von der Passwortverschlüsselung die i-MSCP nutzt.
Wenn Deine Passwörter der FTP Konten so gepseichert wurden, dann hast Du selbst was an i-MSCP gedreht. Das kenne ich von keinem i-MSCP Server die ich betrieben habe.