Migration auf neuen Server - MySQL Passwort

[AceLine]

Hallo Leute,
Hallo ISPC-Team,

ich brauche dringend Eure Hilfe:

Ich habe eine ISPC-3 Installation von einem Server auf einen anderen kopiert und soweit alles ganz gut hinbekommen. Alle DBs erreichbar, alle Domains und andere Datensätze sind da, ich kann mich am Panel einloggen, etc.

Ich kann allerdings nicht per FTP auf den Pure-FDPd zugreifen obwohl scheinbar alles ok ist.

Meine Vermutung ist nun, dass ich noch irgendwo eine Stelle übersehen habe, an der ich das Passwort des ISPConfig-mySQLusers des alten Servers umzuändern gehabt hätte...

Ich kann jetzt schwer aus dem Stehgreif heraus sagen, wo ich das Passwort überall gefunden und geändert habe, daher jetzt meine Frage:

Könnt Ihr hier möglicherweise kurz aufzählen, wo überall das mySQL-Passwort des ISPConfig-Users steckt?


Falls Ihr sonst noch eine Idee habt, was ich bei einer eins zu eins Migration noch beachten könnte, wäre ich Euch sehr dankbar.


Liebe Grüße,

AceLine

[AceLine]

ich finde in der syslog immer wieder:

Access denied for user 'ispconfig'@'localhost'

weiß aber nicht, wo ich für postfix und co. das passwort für den ispconfig user ändern kann.


ich weiß, die angaben sind etwas schwammig aber genau so fühlt sich mein hirn nach neun stunden fehlersuche an... .

Danke im Voraus,

Lg. AceLine

[Till]

Ich vermute Du bist bei der Migration falsch vorgegangen

Du musst als erstes ISPConfig auf dem neuen Server installieren, da man es nicht eben mal rüberkopieren kann. Es muss unbedingt auf dem neuen Server installiert werden, damit der Installer das System korrekt aufsetzt. Dann stimmen auch alle Passworte des ispconfig users. Du musst aufpassen dass Du den ispconfig mysql User in der mysql.user Tabelle nicht überschreibst und dass Du auch keine der Configdateien von postfix, pure-ftpd in /etc/ überschreibst.

Nachdem ISPConfig auf dem neuen Server installiert ist, ist die Migration sehr einfach:

/var/www und /var/vmail und den Inhalt der ispconfig DB rüber kopieren.
Die web[ID] Zeilen in /etc/passwd und /etc/shadow rüber kopieren.
Die client[ID] Zeilen in /etc/group und /etc/gshadow rüber kopieren.
Den Inhalt der sites-enabled und sites-available Verzeichnisse kopierem
Die mysql user (außer root, debian-sys-maint und ispconfig user) auf den neuen Server kopieren und dann die mysql DB's.

[AceLine]

Lieber Till!

Vielen, vielen Dank für die ausführliche Antwort. Ich werde mal versuchen genau nach Deiner Anweisung vorzugehen.

Falls Probleme auftauchen sollten und ich dem ganzen nicht gewachsen bin () wäre es interessant, ob Du bzw. Falco gegen Entgelt eine solche Migration durchführen könntet.

Wenn ja, wie könnte man sich diesbezüglich kurzschließen? Bin in Wien, hab ´n Mobile, hab Mail, etc.

Gib mir bitte kurz Bescheid.

Danke und cu.

Lg. AceLine

[Till]

Falls Probleme auftauchen sollten und ich dem ganzen nicht gewachsen bin () wäre es interessant, ob Du bzw. Falco gegen Entgelt eine solche Migration durchführen könntet.

Wenn ja, wie könnte man sich diesbezüglich kurzschließen? Bin in Wien, hab ´n Mobile, hab Mail, etc.

Ja, ISPConfig Migrationen bieten wir neben Installations- und Update Support auch an. DEr Preis richtet sich da aber nach der für den Support notwendigen Zeit, da sich ein setup mit 10 Websites halt viel schneller migrieren lässt als eines mit mehreren hunder Seiten. Bei Interesse schreib uns einfach eine Email an support [at] projektfarm [dot] com

[AceLine]

Danke Till, ich muss es zwar erst ausgibigst testen, es sollte aber soweit hingehaut haben...

Zwei Anmerkungen für alle, die auf diesen Thread stoßen:

1.) Wenn man SSL-Zertifikate zur Verwendung eines https-Aufrufs des ISPConfig Panels konfiguriert hat, sollte man diese unbedingt wieder einrichten und dabei darauf achten, dass im Ordner /etc/apache2/ssl/ auch die apache.pem liegt

2.) Um den apache an dieser Stelle überhaupt wieder zum Laufen zu bekommen muss mann den Inhalt der /var/log/ispconfig/httpd/ ebenfalls an die selbe Stelle am neuen Server kopieren.


Sollten sich noch irgendwelche Fragen, Anregungen oder Erkenntnisse ergeben, werde ich mich nochmals melden.

Liebe Grüße,

AceLine

[AceLine]

Hi Till,
Hi All,

tja, grundsätzlich alles ganz sauber, außer...

BIND...?!

Augenscheinlich ist der BIND am Laufen, tut auch was er soll aber er hat in der /etc/bind/ keine Zone-Files aus der Migration übernommen.

Till, soll ich die Zone-Files einfach eins zu eins rüber kopieren oder kriege ich den Kübel irgendwie einfacher dazu die Zonen aus der ISPC-DB zu übernehmen?
Wäre natürlich schon wünschenswert, wenn der BIND die Daten aus ISPC übernehmen könnte, da ich im Zuge der Migration in der Table dns_rr alle IPs händisch auf den neuen Server angepasst habe.

Danke für Deine Hilfe!

Cu. AceLine

PS: Habe übrigens gerade im Panel die Domain test.com mit dem Wizzard angelegt, die er im /etc/bind/ auch anlegt. In der named.conf.local liegen jetzt alle Zonen drinnen, diese verweisen jetzt jedoch auf die ganzen nicht vorhandenen pri.xxxx.xxx Zone-Files...

[AceLine]

So, jetzt funktioniert alles...

Für alle, die diesen Thread als kleines How-To sehen und vor den selben Problemen stehen:

1.) Das DNS-Porblem mit den fehlenden Zone-Files:

Es waren bei mir nur etwa 30 Zonen, somit also kein Riesenaufwand. Ich habe die Zone-Files einfach per Hand leer erstellt und dann im ISPC-Panel jede Zone einmal geöffnet - inklusive einem Eintrag, jedoch ohne was zu ändern -, sowie wieder gespeichert. Danach befüllt ISPC ganz brav die Zone-Files.

Wie man das bei hunderten Zone-Files macht,.... Keine Ahnung. Ich hoffe, dass ich das Problem so schnell nicht habe oder bis dort hin eine Lösung gefunden hab.


2.) IPs in den .vhost Files:

Ebenfalls händisch habe ich jedes .vhost File im Ordner /etc/apache2/sites-available/ geöffnet und die IP sowohl für den 80er Virtual Host als auch für den 443er angepasst.

3.) DB-Berechtigungen:

Wenn man diesem Thread folgt, sieht man zwar an dieser Stelle bereits all die schönen sachen, die man migriert hat (sites), diese wollen aber partout keine Daten von der DB abholen...

Da gehört noch die komplette Table mit den Userberechtigungen auf den neuen Server kopiert (mysql/db) aber: "Ohne den beiden test usern und v.A. ohne dem ispconfig-user"
Könnte zwar trotzdem problemlos laufen, ich wollte es aber nicht austesten.


Jetzt sollte alles laufen, tut es auch... aber sollten sich beim produktiv gehen noch Probleme oder Fragen herausstellen, werde ich mich hier nochmals melden.

Ansonsten, thnx. Till und liebe Grüße!

AceLine

[Till]

zu 1) Es gibt auch ein Plugin mit dem man die Zonefiles automatisch neu erzeugen lassen kann:

http://www.howtoforge.com/forums/sho...16&postcount=2

zu 2) Niemals die Datein direkt editieren, denn ISPConfig bereinigt solche manuellen Änderungen und schreibt die alte IP zurück. Stattdessen einfach die neue IP in ISPConfig in den Web Einstellungen auswählen und auf speichern klicken.

[AceLine]

Stimmt, ich habe aber eh auch in der default die IPs angepasst. Somit war zumindest der Eingriff in die einzelnen .vhost Files umsonst. Aber ich konnte ja nicht wissen, dass es nach der Anpassung in der default automatisch übernehmen würde. (In der default standen hinter 80 und 443 noch die alten IPs drinnen)

Ich brauche nochmals Deine Hilfe:

Problem:

Das Mail-Senden funktioniert einwandfrei, ankommen tun aber keine... in der Mail Err-Log kommt folgendes

Mar 11 16:49:29 ns3 amavis[2167]: (02167-05) (!!)ClamAV-clamd av-scanner  FAILED: run_av error: Too many retries to talk to  /var/run/clamav/clamd.ctl (Can't connect to UNIX socket  /var/run/clamav/clamd.ctl: Permission denied) at (eval 88) line 309.
Mar 11 16:49:29 ns3 amavis[2167]: (02167-05) (!!)WARN: all primary virus scanners failed, considering backups
Mar 11 16:49:29 ns3 amavis[2167]: (02167-05) (!!)ClamAV-clamscan  av-scanner FAILED: /usr/bin/clamscan DIED on signal 11 (000b) at (eval  88) line 527.
Mar 11 16:49:29 ns3 amavis[2167]: (02167-05) (!!)TROUBLE in check_mail:  virus_scan FAILED: virus_scan: ALL VIRUS SCANNERS FAILED: ClamAV-clamd  av-scanner FAILED: run_av error: Too many retries to talk to  /var/run/clamav/clamd.ctl (Can't connect to UNIX socket  /var/run/clamav/clamd.ctl: Permission denied) at (eval 88) line 309.;  ClamAV-clamscan av-scanner FAILED: /usr/bin/clamscan DIED on signal 11  (000b) at (eval 88) line 527.

Hab schon einen Uralt-Thread zu einem ähnlichen Thema ausgegraben (wegen fehlendem Pfad zu /var/lib/amavis/tmp), hab auch schon versucht mit

apt-get install --reinstall clamav-daemon clamav-base clamav

den Clamav neu zu installieren, er sagt jedoch direkt nach der Reinstallation und auch beim manuellen Starten:

Starting ClamAV daemon: clamd LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
/lib/lsb/init-functions: line 30:  7745 Segmentation fault      /sbin/start-stop-daemon --start --nicelevel $nice --quiet --exec $exec --oknodo --pidfile "$pidfile" -- "$@"
 failed!

Fällt Dir - bzw. Euch - irgendwas dazu ein?

Die /var/run/clamav/clamd.ctl hat es nicht gegeben, die hab ich leer - wie am alten Server - hinzugefügt und chmoded auf clamav:clamav.
Die /var/run/clamav/clamd.pid gab es ebenfalls nicht, die habe ich in meiner Verzweiflung auch händisch erstellt, chmoded und die selbe pid eingefügt, wie am alten server... die .pid hat er allerdings nach dem nächsten Startversuch einfach wieder gelöscht. Klar... Hmmm...

Danke im Voraus,

Lg. AceLine

PS: @Till: Ich weiß, Deine Zeit ist Gold wert; Und als solches werte ich Deine Hilfe auch. Ich habe schon vor längerer Zeit die erste Version der Doku und später dann das erste Update gekauft - bzw. gegen kleinen Betrag erworben. Ich werde dies sicher wieder tun. Thnx.