Umzug einzelner Kunden ohne Kenntnis von deren Passwörtern

    Hallo,

    es wird ja hier sehr oft und ausführlich der Umzug kompletter Server diskutiert, aber ich habe nur einen anderen Beitrag zu meinem Problem gefunden, der auch nicht wirklich weiterhilft.

    Natürlich ist es super einfach, eine Webseite umzuziehen und auch die E-Mail Postfächer sind kein Problem. Aber wenn der Kunde sein Passwort geändert hat, dann kann ich nur ein neues vergeben und ihn bitten, dies wieder zu ändern.

    Gibt es keine Möglichkeit, alle Datenbankeinträge des Kunden umzuziehen? Das große Problem sehe ich bei der ID, aber wenn ich den Kunden am Ziel nur "notdürftig" anlege, müßte ich doch eine neue ID haben. Kann ich nun nicht alle DB-Einträge von ID-ALT in ID-NEU kopieren?

    Dieses Problem hatte doch sicherlich schon jemand und teilt liebenswürdigerweise sein SQL-Skript mit mir - oder?

    Vielleicht gibt es ja auch noch eine andere Lösung, denn so selten sollte diese Aufgabe ja nicht sein.

    Danke

    Michael

    Wenn es von einem i-MSCP Server zu einem anderen i-MSCP server geht, kannst die Kennwörter in verschlüsselter Form direkt aus der einen Datenbank in die andere kopieren.

    Kunde auf dem neuen Server anlegen mit temporären Kennwörtern, Daten migrieren, Kennwörter 1:1 kopieren, sollte alles laufen und der Kunde merkt nichts.

    Wäre aber ein tolles AddOn: Im alten Server kompletten User exportieren, das AddOn legt dann DB-Script und Archiv mai Mail und Web an, das kann man dann per scp auf die neue Kiste ziehen und dort importieren.


    Sollte nicht so schwierig sein, wenn man sich mit den Interna von iMSCP besser auskennt.


    DB Export stelle ich mir easy vor, Archive packen auch.


    Aber, wie den neuen User per Script anlegen? Wie bekommt er eine ID?

    Was muss dann alles auf to_change gestellt werden, und mit welchem Befehl lässt man dann die Configs neu generieren?

    Ein Dreh- und Angelpunkt dünkt mich dabei die Eindeutigkeit der User-IDs über alle Server hinweg - damit derselbe Kunde auch auf einem anderen Server dieselbe ID nutzen kann. Solange das nicht geht, wird alles recht kompliziert (ID ändert -> DB-Name wegen prefix ändert -> viel Aufwand, ausserdem ist ein Umzug der Mailkonti bei bleibender ID einfacher).


    Ich hab meine Installation etwas angepasst, dass ich die ID bei neuien Kunden manuell eingeben kann - so kann ich den Umzug wenn auch manuell, recht einfach machen.


    Sobald wir eindeutige UserIDs über mehrere Server haben und ein Umzug eines Kunden von einem auf einen anderen server, wird das M in i-MSCP endlich Realität... im Prinzip sollte das mit einem zusätzlichen DB-Feld in verschiedenen Tabellen machbar sein: auf welchem server sind Webdaten, DB-Daten, Maildaten (usw).

    Die Mails der Kunden separat vom Web zu verwalten (zB. alle Mailkonti auf einem Server) hätte den Vorteil, dass der Kunde bei einem Umzug nicht seine Mail-Einstellungen ändern muss. Seit SSL im Mail geht ja mail.kunde.tld nur noch beschränkt bzw. nicht, also kommen Hostnamen des Providers zum Einsatz.

    Eine andere Variante zur Beibehaltung des MAil-Hostnamens wäre: einen POP/IMAP/SMTP-Proxy einsetzen (Dovecot kann mindestens POP+IMAP) - alle sprechen den Proxy an und der leitet die Anfragen inten an den jeweiligen Server weiter, je nach Kunde.


    Sowas geistert mir seit Monaten durch den Kopf... und hier sehe ich zurzeit eien Mangel an Entwicklung.


    /Jo

    Quote from joximu

    Ein Dreh- und Angelpunkt dünkt mich dabei die Eindeutigkeit der User-IDs über alle Server hinweg - damit derselbe Kunde auch auf einem anderen Server dieselbe ID nutzen kann. Solange das nicht geht, wird alles recht kompliziert (ID ändert -> DB-Name wegen prefix ändert -> viel Aufwand, ausserdem ist ein Umzug der Mailkonti bei bleibender ID einfacher).

    Man könnte ja einfach prüfen, ob die alte ID schon vorhanden ist. Wenn nicht, manuell eine eingeben.


    Quote from joximu

    Ich hab meine Installation etwas angepasst, dass ich die ID bei neuien Kunden manuell eingeben kann - so kann ich den Umzug wenn auch manuell, recht einfach machen.

    Ja, als Fallback sicher gut.


    Ich sehe bei meinem Setup das Problem mit den IDs nicht als so gravierend an, wenn, dann würde ich eh große Kunden auf einen Dedi auslagern, also in eine frische Installation einspielen. Ja, das geht jetzt auch, aber ist halt noch viel Handarbeit.


    Quote from joximu

    Sobald wir eindeutige UserIDs über mehrere Server haben und ein Umzug eines Kunden von einem auf einen anderen server, wird das M in i-MSCP endlich Realität... im Prinzip sollte das mit einem zusätzlichen DB-Feld in verschiedenen Tabellen machbar sein: auf welchem server sind Webdaten, DB-Daten, Maildaten (usw).

    Ja, das wäre toll, ich bin mal gespannt, ob/was diesen Monat mit i-HMS wird …


    Quote from joximu

    Die Mails der Kunden separat vom Web zu verwalten (zB. alle Mailkonti auf einem Server) hätte den Vorteil, dass der Kunde bei einem Umzug nicht seine Mail-Einstellungen ändern muss. Seit SSL im Mail geht ja mail.kunde.tld nur noch beschränkt bzw. nicht, also kommen Hostnamen des Providers zum Einsatz.

    Wieso das?

    Du kannst doch bis zu 100 Aliase in eine LE-Cert packen.

    Klar, wäre natürlich schön, wenn das automatisch passieren würde.


    Evtl. auch nur als Option, ich brauche nicht für jede meiner Domains einen eigenen MailserverName, die laufen alle über einen Zentralen.

    Quote from joximu

    Eine andere Variante zur Beibehaltung des MAil-Hostnamens wäre: einen POP/IMAP/SMTP-Proxy einsetzen (Dovecot kann mindestens POP+IMAP) - alle sprechen den Proxy an und der leitet die Anfragen inten an den jeweiligen Server weiter, je nach Kunde.

    Ist aber auch viel Aufwand :(



    Quote from joximu

    Sowas geistert mir seit Monaten durch den Kopf... und hier sehe ich zurzeit eien Mangel an Entwicklung.

    Machen könnte man viel.

    Nur: Es kann im Prinzip nicht mehr als ein Hobby sein, selbst wenn man das als kostenpflichtiges PlugIn macht müssen sich viele Abnehmer finden, damit sich das lohnt.

    Hoi tracer


    Alle Domains ins LE-Zertifikat packen (für Mailserver):

    Da man dieses Zertifikat ansehen kann, finde ich es aus Datenschutzgründen nicht so toll, wenn jemand gleich eine Liste hat, welche Domains alles auf dem Server laufen. Wenn jemand eine bestimmte Domain kennt, kann er das rausfinden - aber er braucht keine Liste der Kunden... finde ich.


    Der Mailproxy ist sicher am Anfang viel Aufwand (und ich hab noch kein SMTP-Proxy - aber das solls auch geben). War für mich ne Überlegung mindestens als Übergang.

    Sobald ich alle Mailkonti getrennt von den Webs auf einen Server packen kann, brauchts den Mailproxy natürlich nicht (mehr...).


    Es ist halt so... man kommt an ein Problem und sucht eine Lösung... das M würde oft etwas vereinfachen... :-) Es wurde schon lange versprochen (mit dem Start von i-MSCP) aber ich sehe nirgends eine Ansatz, wie es gelöst werden soll - und als Plugin sollte das M auch nicht verwirklicht werden...

    Ob nun ein neuen Javascript Framework die Lösung dafür ist... ich weiss nicht.


    Es ist mir bewusst, dass es viel Arbeit ist - es ist halt schade, dass es immer wieder Schwierigkeiten gibt, die die Entwickler dann in Stret ausbrechen lassen...


    Gruss Jo

    Quote from joximu

    Alle Domains ins LE-Zertifikat packen (für Mailserver):

    Da man dieses Zertifikat ansehen kann, finde ich es aus Datenschutzgründen nicht so toll, wenn jemand gleich eine Liste hat, welche Domains alles auf dem Server laufen. Wenn jemand eine bestimmte Domain kennt, kann er das rausfinden - aber er braucht keine Liste der Kunden... finde ich.

    Hmm, sehe ich aber nicht als so kritisch an.

    Wer sich eine Domain kauft will sie ja nutzen. Und nur der Domainname sagt ja nicht viel aus, dank DSGVO-Schwachsinn funktionieren beim DeNIC ja nicht mal mehr WHOIS-Abfragen.



    Quote from joximu

    Ob nun ein neuen Javascript Framework die Lösung dafür ist... ich weiss nicht.

    Auch?

    Ich hatte gelesen, dass er neu schreiben will, in Laravel, das ist Backend.

    Das hier gefunden: "Full rewrite of the i-MSCP software using the Laravel framework. Provided through Docker images."


    Wenn er das Docker-only macht bin ich eh raus, so einen Müll haue ich mir nicht auf den Rechner.

    LE-Zert/Domains:

    Ich will ja nicht übertreiben mit Datenschutz - aber ein "Hallo Besucher - schön, du hast einen Server kontaktiert, hier werden übrigens die Mails für folgende Domains gehostet: ...." das muss nicht sein.


    Rewrite:

    Ja, Backend hat er auch erwähnt... ich meinte auch etwas fürs Frontend - lassen wir uns überraschen.


    /J

    Quote from joximu

    Ja, Backend hat er auch erwähnt... ich meinte auch etwas fürs Frontend - lassen wir uns überraschen.

    Ich glaube, in dem langem Thread war was dazu, react? Hmm, wie auch immer auf Frameworks zu setzen schadet nicht. Mein aktuelles Projekt mache ich mit symfony und Vue, ist am Anfang eine steile Lernkurve, aber mittelfristig eine Erleichterung, und hilft Sicherheitslücken zu vermeiden, weil viel mehr Leute auf den Code gucken.


    Quote from joximu

    LE-Zert/Domains:

    Ich will ja nicht übertreiben mit Datenschutz - aber ein "Hallo Besucher - schön, du hast einen Server kontaktiert, hier werden übrigens die Mails für folgende Domains gehostet: ...." das muss nicht sein.

    Schön ist es nicht. Es wäre definitiv cooler, wenn der Mailserver nur einen Namen ausspuckt.

    Aber geht mit SMTP wohl nicht anders. Bei http wurde das ja mit SNI gelöst.

    Nach langer Zeit nochmal ein Hallo,


    der erste Ansatz hat gut funktioniert, vielen Dank.


    ich finde es persönlich sehr schön, daß sich noch so viele für einen Fortbestand dieses Projektes engagieren. Wir haben i-mscp seit 12 Jahren im Einsatz und waren immer sehr zufrieden. Bei einem Servercrash vor einigen Jahren, an dem wir nicht ganz unschuldig waren, hat Nuxwin sofort geholfen. Leider hat sich sich dies seit 2018 grundlegend geändert und ein neuer Server wird wohl ISPConfig bekommen. Streiterei im Team kann das beste Projekt zerstören und genau das ist hier passiert. Wir sehen leider keine Zukunft mehr. Das ist sehr schade.


    Wir sind sehr traurig und werden das Projekt weiterhin verfolgen


    Michael