DRINGENDE Anfrage: Server-Umzug bei unterschiedlichen Debian-Versionen

speedy8

Member
Hallo Leute,
ich habe ein ganz dringendes Problem und hoffe, dass mir hier jemand weiterhelfen kann. Und zwar folgendes ...
Ich habe bislang einen Debian6-Server mit ISPConfig und Courier etc. betrieben, wie er hier im Forum auch beschrieben ist.
Ich wollte schon vor einer ganzen Weile meinen Server auf die nächste Debian-Version hiefen, doch leider lief auf meinem vServer eine alte Kernel-Version, weshalb das leider nicht ging.
Da nun auch für die Debian6-LTS-Version keine Sicherheits-Updates mehr zur Verfügung stehen, habe ich meinem Hoster nun gedrängt, wann denn endlich der neue Kernel eingspielt wird. Leider wird das nicht erfolgen ... sondern ich kann einen anderen vServer mit neuen Spezifikationen nehmen.

Das habe ich nun kurzerhand auch getan, nur leider kann ich auf diesem Server kein Debian6 installieren, um ein identisches System zu haben, in welches ich meine Daten überspiele.

Also habe ich jetzt auf dem neuen Server ein Debian7-64Bit installiert und alle weiteren Programme entsprechend der HowToForge-Anleitung installiert.

Der neue Server alleine läuft nun auch prima, auch ISPConfig und Roundcube.

Doch jetzt kommt das Problem, dass ich ja vom alten Verzeichnis alle Internetseiten und Datenbanken und Email-Postfächer transferieren muss.

Dazu habe ich folgendes getan:
1. auf dem alten und dem neuen Server jeweils ein "/etc/init.d/postfix stop" ausgeführt.
2. jetzt habe ich auf dem alten Server ein "rsync -az /var/vmail/ root@<meineNeueServerIP>:/var/vmail/" ausgeführt.
3. Danach habe ich auf dem alten Server ein "rsync -az /var/www/ root@<meineNeueServerIP>:/var/www/" ausgeführt.
4. Danach habe ich mit obigem rsync-Befehl noch die Dateien /etc/group, /etc/group-, /etc/passwd, /etc/passwd- sowie /etc/cron.d auf den neuen Server gespielt.
5. Jetzt musste noch die Datenbank kopiert werden. Dazu habe ich auf dem alten Server ein "mysqldump -u root -p --all-databases > mysql-2016-03-11.sql" ausgeführt. Gleich zu Beginn der Erstellung des Dump erhielt ich noch die Meldung "-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly."
Den Dump habe ich dann wie oben mittels rsync auf den neuen Server transferriert.
6. Den Datenbank-Dump habe danach auf dem neuen Server wieder eingespielt mittels "mysql -p < mysql.sql"

So, das hat er auch übernommen. Natürlich sind die von der Neuinstallation von ISPConfig vorhandenen Daten mit den Daten aus dem Dump überschrieben. Nagut. Aber ein Einloggen in RoundCube war leider nicht so richtig möglich, vielmehr erhielt ich nach dem Login nur eine weiße Seite!

Als ich dann noch den neuen Server neu gebootet habe, startete MySQL schon nicht mehr. Eine Fehlermeldung konnte ich in der mysql.error nicht finden.

Ich habe eben noch einmal geschaut, und auf dem alten Server läuft (Debian 6.0.10, MySQL 5.1.73) und auf dem neuen Server läuft (Debian 7.9, MySQL 5.5.47)
KANN MIR HIER JEMAND WEITERHELFEN???????

Schon einmal vielen Dank!
 
Zuletzt bearbeitet:

Till

Administrator
Was steht denn im syslog, wenn Du versuchst mysql zu starten?

4. Danach habe ich mit obigem rsync-Befehl noch die Dateien /etc/group, /etc/group-, /etc/passwd, /etc/passwd- sowie /etc/cron.d auf den neuen Server gespielt.

Das ist vermutlich ein größeres Problem, hast Du Backup's der Dateien des neuen Systems? Man sollte die Dateien nie komplett rüber kopieren da die UID's von Systemdiensten meist abweichen und daher Dienste dann falsche Rechte bekommen.
 

speedy8

Member
Hallo,

ich habe auf dem neuen Server zunächst einmal das Backup der korrekten neuen Server-Installation angefertigt habe, eingespielt.
Was ich merkwürdig finde ist, dass der Speicher mächtig voll ist. Ich hatte auf meinem Debian-Server den Apache und MySQL so eingestellt, dass wirklich nur wenig Speicher genutzt wurde.

Wenn ich auf dem Debian6-Server ein "free -m" ausführe, dann erhalte ich

Code:
             total       used       free     shared    buffers     cached
Mem:          4096        813       3282          0          0          0
-/+ buffers/cache:        813       3282
Swap:            0          0          0

Wenn ich das ganze auf dem neuen Debian7-Server starte (nach dem Neustart), dann erhalte ich dort folgende Werte
Code:
             total       used       free     shared    buffers     cached
Mem:          7372        353       7019          0          0        174
-/+ buffers/cache:        179       7193
Swap:        35999          0      35999

Aber wenn der Server - wie bei mir - ca. 1 Tag gelaufen ist, dann waren nur noch 300 MB an Speicher frei, und ein Teil des Swap-Seicher war auch schon genutzt. Ist das in Debian 7 neu??? Denn beim alten Debian6-Server haben sich die Werte über lange Zeit kaum geändert.
Ist dieser Zustand vielleicht ein Problem?


Also, wenn ich jetzt auf dem frisch installierten Server die MySQL-Datenbank stoppe und wieder starte, dann sieht das im Syslog wie folgt aus:

Code:
Mar 10 23:32:25 galaxy mysqld: 160310 23:32:25 [Note] /usr/sbin/mysqld: Normal shutdown
Mar 10 23:32:25 galaxy mysqld:
Mar 10 23:32:25 galaxy mysqld: 160310 23:32:25 [Note] Event Scheduler: Purging the queue. 0 events
Mar 10 23:32:25 galaxy mysqld: 160310 23:32:25  InnoDB: Starting shutdown...
Mar 10 23:32:26 galaxy mysqld: 160310 23:32:26  InnoDB: Shutdown completed; log sequence number 1660802
Mar 10 23:32:26 galaxy mysqld: 160310 23:32:26 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 10 23:32:26 galaxy mysqld:
Mar 10 23:32:26 galaxy mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mar 10 23:32:27 galaxy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 [Note] /usr/sbin/mysqld (mysqld 5.5.47-0+deb7u1) starting as process 4146 ...
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 [Note] Plugin 'FEDERATED' is disabled.
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: The InnoDB memory heap is disabled
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: Compressed tables use zlib 1.2.7
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: Using Linux native AIO
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: Initializing buffer pool, size = 128.0M
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: Completed initialization of buffer pool
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27 InnoDB: highest supported file format is Barracuda.
Mar 10 23:32:27 galaxy mysqld: 160310 23:32:27  InnoDB: Waiting for the background threads to start
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 InnoDB: 5.5.47 started; log sequence number 1660802
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 [Note] Server socket created on IP: '0.0.0.0'.
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 [Note] Event Scheduler: Loaded 0 events
Mar 10 23:32:28 galaxy mysqld: 160310 23:32:28 [Note] /usr/sbin/mysqld: ready for connections.
Mar 10 23:32:28 galaxy mysqld: Version: '5.5.47-0+deb7u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4222]: Upgrading MySQL tables if necessary.
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4226]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4226]: Looking for 'mysql' as: /usr/bin/mysql
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4226]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4226]: This installation of MySQL is already upgraded to 5.5.47, use --force if you still need to run mysql_upgrade
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4240]: Checking for insecure root accounts.
Mar 10 23:32:29 galaxy /etc/mysql/debian-start[4245]: Triggering myisam-recover for all MyISAM tables

Den SQL-Dump habe ich danach mit "mysql -p < /root/mysql.sql " eingespielt.
...
 

speedy8

Member
...
Danach habe ich noch einmal den MySQL-Server neu gestartet ... und im Syslog geschaut.

Dort wird mir jetzt folgendes ausgegeben.

Code:
Mar 10 23:44:13 galaxy mysqld: 160310 23:44:13 [Note] /usr/sbin/mysqld: Normal shutdown
Mar 10 23:44:13 galaxy mysqld:
Mar 10 23:44:13 galaxy mysqld: 160310 23:44:13 [Note] Event Scheduler: Purging the queue. 0 events
Mar 10 23:44:14 galaxy pure-ftpd: (?@88.80.221.107) [INFO] New connection from 88.80.221.107
Mar 10 23:44:14 galaxy pure-ftpd: (?@88.80.221.107) [INFO] Logout.
Mar 10 23:44:14 galaxy postfix/anvil[3503]: statistics: max connection rate 1/60s for (smtp:88.80.221.107) at Mar 10 23:36:14
Mar 10 23:44:14 galaxy postfix/anvil[3503]: statistics: max connection count 1 for (smtp:88.80.221.107) at Mar 10 23:36:14
Mar 10 23:44:14 galaxy postfix/anvil[3503]: statistics: max cache size 2 at Mar 10 23:42:14
Mar 10 23:44:15 galaxy mysqld: 160310 23:44:15 [Warning] /usr/sbin/mysqld: Forcing close of thread 128  user: 'ispconfig'
Mar 10 23:44:15 galaxy mysqld:
Mar 10 23:44:15 galaxy mysqld: 160310 23:44:15  InnoDB: Starting shutdown...
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17  InnoDB: Shutdown completed; log sequence number 1078483574
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 10 23:44:17 galaxy mysqld:
Mar 10 23:44:17 galaxy mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mar 10 23:44:17 galaxy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 [Note] /usr/sbin/mysqld (mysqld 5.5.47-0+deb7u1) starting as process 5245 ...
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 [Note] Plugin 'FEDERATED' is disabled.
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: The InnoDB memory heap is disabled
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: Compressed tables use zlib 1.2.7
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: Using Linux native AIO
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: Initializing buffer pool, size = 128.0M
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: Completed initialization of buffer pool
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17 InnoDB: highest supported file format is Barracuda.
Mar 10 23:44:17 galaxy mysqld: 160310 23:44:17  InnoDB: Waiting for the background threads to start
Mar 10 23:44:18 galaxy postfix/smtpd[4654]: timeout after END-OF-MESSAGE from localhost[127.0.0.1]
Mar 10 23:44:18 galaxy postfix/smtpd[4654]: disconnect from localhost[127.0.0.1]
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 InnoDB: 5.5.47 started; log sequence number 1078483574
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [Note] Server socket created on IP: '0.0.0.0'.
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [Note] Event Scheduler: Loaded 0 events
Mar 10 23:44:18 galaxy mysqld: 160310 23:44:18 [Note] /usr/sbin/mysqld: ready for connections.
Mar 10 23:44:18 galaxy mysqld: Version: '5.5.47-0+deb7u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5321]: Upgrading MySQL tables if necessary.
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5325]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5325]: Looking for 'mysql' as: /usr/bin/mysql
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5325]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5325]: Error: Failed while fetching Server version! Could be due to unauthorized access.
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5325]: FATAL ERROR: Upgrade failed
Mar 10 23:44:19 galaxy /etc/mysql/debian-start[5342]: Checking for insecure root accounts.

Beim ersten RESTART scheint der Server aber hochgefahren zu sein. In der Shell hat er aber noch ausgegeben

Code:
root@galaxy:~/backup# ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)
Ein weiterer MySQL-Restart bringt nun aber folgende Ausgabe

Code:
[FAIL] Stopping MySQL database server: mysqld failed!
[ ok ] Starting MySQL database server: mysqld already running.

Und tatsächlich kann auf die Datenbank nicht zugegriffen werden durch ISPConfig.
Also habe ich noch einmal mittels "ps -x | grep mysql" geschaut, ob MySQL doch noch läuft. Und als Ausgabe erhielt ich

Code:
4929 pts/0  S  0:00 /bin/sh /usr/bin/mysqld_safe
5246 pts/0  S  0:00 logger -t mysqld -p daemon.error

Also auf gut Deutsch ... MySQL läuft ... und eigentlich müsste ich darauf zugreifen können? Im ISPConfig-Backend bekomme ich aber keine Verbindung.

Ist denn mein Ansatz aber grundsätzlich nachvollziehbar und korrekt, wie ich den Server transferieren will?
1. Datenbank (eventuell jd. Datenbank einzeln, und bei der ISPConfig-Datenbankn ggf. nur einzelne Tabellen?)
2. Verzeichnis /var/www (hier sind alle Homepages drin. Sind auch zwingend die Verzeichnisse unter /var/www/php-fcgi-Skripts mit zu kopieren?)
3. Verzeichnis /var/vmail (hier sind ja alle Email-Konten drin)
4. einzelne Konfigurations-Dateien (insbesondere sind die Dateien /etc/passwd und /etc/group m.E. erforderlich, dass die Verzeichnisrechte auch tatsächlich auf die ISPConfig-User verweisen)

Bei letzteren Dateien will gleich noch einmal schauen, ob dort die UIDs der Standard-System-User identisch sind mit dem neuen Server ...
Ha, in der Passwd habe ich Unterschiede entdeckt, so dass ich einfach alles, was von ISPConfig hinsichtlich der dortigen Benutzer hinzugefügt wurde, händisch eintrage (dürfte alles >5000 sein?). Aber sind die UIDs denn zusätzlich auch noch in der ISPConfig-Datenbank hinterlegt? Dann müsste das ja dort auch noch geändert werden ... ??? Ich würde in den vom neuen System systemseitig vergebenen UIDs natürlich keine Änderung vornehmen gegenüber dem alten System.

So, werde mich dann morgen mal daran machen, die Werte aus den /etc/passwd und die /etc/group händisch zu übertragen.

Wegen der MySQL-Datenbanken wäre es aber schon einmal schön zu erfahren, was ich dort im Detail machen soll.

Danke!
 

Till

Administrator
Bei letzteren Dateien will gleich noch einmal schauen, ob dort die UIDs der Standard-System-User identisch sind mit dem neuen Server ...
Ha, in der Passwd habe ich Unterschiede entdeckt, so dass ich einfach alles, was von ISPConfig hinsichtlich der dortigen Benutzer hinzugefügt wurde, händisch eintrage (dürfte alles >5000 sein?). Aber sind die UIDs denn zusätzlich auch noch in der ISPConfig-Datenbank hinterlegt? Dann müsste das ja dort auch noch geändert werden ... ??? Ich würde in den vom neuen System systemseitig vergebenen UIDs natürlich keine Änderung vornehmen gegenüber dem alten System.

Du musst aus passwd und shadow alle web* user und aus group und gshadow alle client* gruppen zelen in die Dateien auf dem neuen server übernehmen, wie in diversen server mig threads hier und im EN Forum beschrieben.
 

speedy8

Member
Hallo Till,

also ich habe noch einmal den Stand hergestellt, welchen ich unmittelbar nach dem Installieren des "Perfekten Debian Webservers" hatte.
Danach habe ich den MySQL-Datenbank-Dump eingespielt ... und aus den obigen Dateien alle "web*" - und "client*"-Einträge in die aktuell im System enthaltenen Dateien übernommen. Und danach habe ich noch die Verzeichnisse /var/www (nur alles was die Benutzerverzeichnisse waren) und dann noch /var/vmail/.

Dann habe ich, wie von Dir oben beschrieben, vom alten Debian-6-Server die /etc/mysql/my.cnf im neuen Debian-7-Server eingespielt.

Ein Restart des MYSQLD ergab dann folgende Meldung:
Code:
Mar 13 12:23:22 galaxy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [Note] /usr/sbin/mysqld (mysqld 5.5.47-0+deb7u1) starting as process 4209 ...
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [ERROR] An old style --language value with language specific part detected: /usr/share/mysql/english/
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [ERROR] Use --lc-messages-dir without language specific part instead.
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 [Note] Plugin 'FEDERATED' is disabled.
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: The InnoDB memory heap is disabled
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: Compressed tables use zlib 1.2.7
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: Using Linux native AIO
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: Initializing buffer pool, size = 128.0M
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: Completed initialization of buffer pool
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22 InnoDB: highest supported file format is Barracuda.
Mar 13 12:23:22 galaxy mysqld: 160313 12:23:22  InnoDB: Waiting for the background threads to start
Mar 13 12:23:23 galaxy mysqld: 160313 12:23:23 InnoDB: 5.5.47 started; log sequence number 1198233692
Mar 13 12:23:23 galaxy mysqld: 160313 12:23:23 [ERROR] /usr/sbin/mysqld: unknown variable 'default-character-set=utf8'
Mar 13 12:23:23 galaxy mysqld: 160313 12:23:23 [ERROR] Aborting
Mar 13 12:23:23 galaxy mysqld:
Mar 13 12:23:23 galaxy mysqld: 160313 12:23:23  InnoDB: Starting shutdown...
Mar 13 12:23:24 galaxy mysqld: 160313 12:23:24  InnoDB: Shutdown completed; log sequence number 1198233692
Mar 13 12:23:24 galaxy mysqld: 160313 12:23:24 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 13 12:23:24 galaxy mysqld:
Mar 13 12:23:24 galaxy mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mar 13 12:23:36 galaxy /etc/init.d/mysql[4418]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Mar 13 12:23:36 galaxy /etc/init.d/mysql[4418]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Mar 13 12:23:36 galaxy /etc/init.d/mysql[4418]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Mar 13 12:23:36 galaxy /etc/init.d/mysql[4418]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Mar 13 12:23:36 galaxy /etc/init.d/mysql[4418]:
Da die Variable "default-character-set=utf8" wohl nicht passt, habe ich die einfach einmal auskommentiert.

Aber auch das scheint irgendwie nicht richtig zu funktionieren. Denn MYSQL startet noch immer nicht richtig neu. Er quittiert in der SYSLOG folgendes:

Code:
Mar 13 12:28:46 galaxy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [Note] /usr/sbin/mysqld (mysqld 5.5.47-0+deb7u1) starting as process 5582 ...
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [ERROR] An old style --language value with language specific part detected: /usr/share/mysql/english/
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [ERROR] Use --lc-messages-dir without language specific part instead.
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 [Note] Plugin 'FEDERATED' is disabled.
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: The InnoDB memory heap is disabled
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: Compressed tables use zlib 1.2.7
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: Using Linux native AIO
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: Initializing buffer pool, size = 128.0M
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: Completed initialization of buffer pool
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46 InnoDB: highest supported file format is Barracuda.
Mar 13 12:28:46 galaxy mysqld: 160313 12:28:46  InnoDB: Waiting for the background threads to start
Mar 13 12:28:47 galaxy mysqld: 160313 12:28:47 InnoDB: 5.5.47 started; log sequence number 1198233692
Mar 13 12:28:47 galaxy mysqld: 160313 12:28:47 [ERROR] /usr/sbin/mysqld: unknown variable 'default-character-set=utf8'
Mar 13 12:28:47 galaxy mysqld: 160313 12:28:47 [ERROR] Aborting
Mar 13 12:28:47 galaxy mysqld:
Mar 13 12:28:47 galaxy mysqld: 160313 12:28:47  InnoDB: Starting shutdown...
Mar 13 12:28:48 galaxy mysqld: 160313 12:28:48  InnoDB: Shutdown completed; log sequence number 1198233692
Mar 13 12:28:48 galaxy mysqld: 160313 12:28:48 [Note] /usr/sbin/mysqld: Shutdown complete
Mar 13 12:28:48 galaxy mysqld:
Mar 13 12:28:48 galaxy mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
Mar 13 12:28:55 galaxy postfix/smtpd[5699]: connect from monitoring.vipanel.de[88.80.221.107]
Mar 13 12:28:55 galaxy postfix/smtpd[5699]: disconnect from monitoring.vipanel.de[88.80.221.107]
Mar 13 12:29:00 galaxy /etc/init.d/mysql[5783]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
Mar 13 12:29:00 galaxy /etc/init.d/mysql[5783]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed
Mar 13 12:29:00 galaxy /etc/init.d/mysql[5783]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)'
Mar 13 12:29:00 galaxy /etc/init.d/mysql[5783]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
Mar 13 12:29:00 galaxy /etc/init.d/mysql[5783]:
 

speedy8

Member
Mmmh, und nun? Auch nach einem Server-Restart ändert sich nichts daran, dass MySQL nicht startet.
Habe dann wieder die während der Debian-7-Installation erzeugte my.cnf eingespielt und Debian neu gestartet. Jetzt gings, in der Syslog steht folgendes:

Code:
Mar 13 12:37:55 galaxy mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 [Note] /usr/sbin/mysqld (mysqld 5.5.47-0+deb7u1) starting as process 4711 ...
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 [Note] Plugin 'FEDERATED' is disabled.
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: The InnoDB memory heap is disabled
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: Compressed tables use zlib 1.2.7
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: Using Linux native AIO
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: Initializing buffer pool, size = 128.0M
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: Completed initialization of buffer pool
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55 InnoDB: highest supported file format is Barracuda.
Mar 13 12:37:55 galaxy mysqld: 160313 12:37:55  InnoDB: Waiting for the background threads to start
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 InnoDB: 5.5.47 started; log sequence number 1198233692
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 [Note] Server socket created on IP: '0.0.0.0'.
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 [Note] Event Scheduler: Loaded 0 events
Mar 13 12:37:56 galaxy mysqld: 160313 12:37:56 [Note] /usr/sbin/mysqld: ready for connections.
Mar 13 12:37:56 galaxy mysqld: Version: '5.5.47-0+deb7u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4786]: Upgrading MySQL tables if necessary.
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4790]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4790]: Looking for 'mysql' as: /usr/bin/mysql
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4790]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4790]: Error: Failed while fetching Server version! Could be due to unauthorized access.
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4790]: FATAL ERROR: Upgrade failed
Mar 13 12:37:57 galaxy /etc/mysql/debian-start[4808]: Checking for insecure root accounts.

In der Shell wurde mir nach dem Restart angezeigt
Code:
root@galaxy:~# ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

Also MySQL läuft jetzt, und ich kann mich mit phpMyAdmin in die Datenbanken hineinschauen.

Komischerweise kann ich mich aber jetzt noch nicht im ISPCONFIG-Backend einloggen. Trotz laufendem MYSQL sagt er mir
"Error Benutzername oder Passwort ist leer."
Das ist aber ja gar nicht so.

Und wenn ich in phpMyAdmin schaue sind dort auch alle Datenbanken vorhanden.

Langsam bin ich wirklich am Verzweifeln, da für den Server-Wechsel eine DeadLine steht ... und es will einfach nicht klappen!!!

Hast Du noch eine Idee?
 

speedy8

Member
ok ... Login-Problem in ISPConfig habe ich geklärt. Ich habe ja die ISPConfig-Datenbank vom alten Server mit dem Dump eingespielt, jedoch auf dem neuen Server die dazugehörigen MySQL-Login-Daten zur Datenbank noch nicht geändert.

Mit einem "nano /usr/local/ispconfig/interface/lib/config.inc.php" habe ich auf dem neuen Server die Datei geöfffnet und vom alten Server entsprechend das MySQL-Passwort zur ISPConfig-Datenbank eingetragen. Also ISPConfig-LOGIN klappt jetzt wenigstens.
 

speedy8

Member
so, jetzt muss ich noch die Sache mit den E-Mails zum Laufen bekommen. Ich hatte auf meinem alten Server das RoundCube händisch installiert, also via php-Installer. Auf dem neuen Debian-7-Server habe ich das jetzt mittels der Anleitung hier im Forum getan.

Den Login-Screen von RoundCube erhalte ich unter der Domain http://galaxy.meinServer.de/webmail

Doch leider funktioniert das Login nicht. Egal ob ich einen User mit richtigem oder falschem Passwort eingebe - nach Bestätigung des Login-Buttons erhalte ich eine weiße Seite und fertig.

Dann habe ich gedacht, ich versuche einmal ein Mail-Abruf mit einem lokalen Mail-Client auf meinem Rechner. Und siehe da ... der nimmt das Passwort nicht ... und da das Passwort eigentlich korrekt ist, kann ich nur vermuten, dass die Email-Postfach-Daten von Courier nicht korrekt abgerufen werden können.

Wo müsste ich dazu Fehlermeldungen finden? Ahh ... in der /var/log/syslog finde ich folgendes:

Code:
Mar 13 18:44:38 galaxy postfix/smtpd[25191]: disconnect from unknown[120.27.94.124]
Mar 13 18:44:49 galaxy postfix/smtpd[25191]: connect from unknown[120.27.94.124]
Mar 13 18:44:53 galaxy postfix/smtpd[25191]: warning: unknown[120.27.94.124]: SASL LOGIN authentication failed: generic failure
Mar 13 18:44:59 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:44:59 galaxy postfix/smtpd[25264]: connect from ip-109-47-192-138.web.vodafone.de[109.47.192.138]
Mar 13 18:44:59 galaxy imapd: LOGOUT, ip=[::ffff:109.47.192.138], rcvd=24, sent=464
Mar 13 18:44:59 galaxy postfix/smtpd[25264]: disconnect from ip-109-47-192-138.web.vodafone.de[109.47.192.138]
Mar 13 18:45:01 galaxy /USR/SBIN/CRON[25267]: (getmail) CMD (/usr/local/bin/run-getmail.sh > /dev/null 2>> /dev/null)
Mar 13 18:45:01 galaxy /USR/SBIN/CRON[25268]: (root) CMD (/usr/local/ispconfig/server/server.sh 2>&1 > /dev/null | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done)
Mar 13 18:45:04 galaxy postfix/smtpd[25264]: connect from unknown[120.27.94.124]
Mar 13 18:45:05 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:05 galaxy imapd: couriertls: read: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Mar 13 18:45:05 galaxy imapd: Disconnected, ip=[::ffff:109.47.192.138], time=0, starttls=1
Mar 13 18:45:07 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:08 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:08 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:08 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:08 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:08 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:08 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:08 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:11 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:11 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:11 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:11 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:12 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:12 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:12 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:12 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:14 galaxy postfix/smtpd[25191]: lost connection after AUTH from unknown[120.27.94.124]
Mar 13 18:45:14 galaxy postfix/smtpd[25191]: disconnect from unknown[120.27.94.124]
Mar 13 18:45:22 galaxy postfix/smtpd[25191]: connect from ip-109-47-192-138.web.vodafone.de[109.47.192.138]
Mar 13 18:45:22 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:22 galaxy postfix/smtpd[25191]: improper command pipelining after EHLO from ip-109-47-192-138.web.vodafone.de[109.47.192.138]: QUIT\r\n
Mar 13 18:45:22 galaxy imapd: LOGOUT, ip=[::ffff:109.47.192.138], rcvd=24, sent=464
Mar 13 18:45:22 galaxy postfix/smtpd[25191]: disconnect from ip-109-47-192-138.web.vodafone.de[109.47.192.138]
Mar 13 18:45:28 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:29 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:29 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:29 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:29 galaxy imapd: Connection, ip=[::ffff:109.47.192.138]
Mar 13 18:45:30 galaxy authdaemond: failed to connect to mysql server (server=localhost, userid=ispconfig): Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:30 galaxy imapd: LOGIN FAILED, method=PLAIN, ip=[::ffff:109.47.192.138]
Mar 13 18:45:30 galaxy imapd: authentication error: Input/output error
Mar 13 18:45:38 galaxy postfix/qmgr[3205]: 716642CC0028: from=<root@galaxy.meinServer.de>, size=949, nrcpt=1 (queue active)
Mar 13 18:45:38 galaxy postfix/qmgr[3205]: 84C042CC0029: from=<root@galaxy.meinServer.de>, size=949, nrcpt=1 (queue active)
Mar 13 18:45:38 galaxy postfix/qmgr[3205]: 5B4F12CC0022: from=<root@galaxy.meinServer.de>, size=949, nrcpt=1 (queue active)
Mar 13 18:45:38 galaxy amavis[24109]: (24109-01) (!)connect_to_sql: unable to connect to DSN 'DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306': Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:38 galaxy amavis[24109]: (24109-01) (!!)TROUBLE in process_request: connect_to_sql: unable to connect to any dataset at (eval 111) line 247.
Mar 13 18:45:38 galaxy amavis[24109]: (24109-01) (!)Requesting process rundown after fatal error
Mar 13 18:45:38 galaxy amavis[24466]: (24466-01) (!)connect_to_sql: unable to connect to DSN 'DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306': Access denied for user 'ispconfig'@'localhost' (using password: YES)
Mar 13 18:45:38 galaxy amavis[24466]: (24466-01) (!!)TROUBLE in process_request: connect_to_sql: unable to connect to any dataset at (eval 111) line 247.
Mar 13 18:45:38 galaxy amavis[24466]: (24466-01) (!)Requesting process rundown after fatal error

Mmh, muss ich das ISPConfig-Passwort noch an einer anderen Stelle ändern als in den ISPConfig-Files selbst?!?!?!
 

speedy8

Member
ja ... danke ... eben!

Ich habe gerade noch einmal in den Postfix-Files geschaut, was dort für ein ispconfig-Mysql-Kennwort hinterlegt ist. Und hier scheint genau der Fehler zu liegen! In der MySQL-Datenbank ist das Kennwort aus dem Dump enthalten, also vom alten Server, und in den Konfig-Files ist das ISPConfig-Kennwort enthalten, was bei der Server-Installation angelegt wurde.

Ehe ich jetzt alle Konfig-Files abändere würde ich der Einfachheit halber in der MySQL-Datenbank für den Benutzer "ispconfig" das Kennwort ändern. Bislang müsste ich auch nur in den ISPConfig-Files etwas ändern.

Im Netz habe ich gefunden, dass man das auf der Konsole wie folgt macht:

Code:
mysql -u root -p

mysql> GRANT ALL PRIVILEGES ON *.* TO ‘ispconfig’@'localhost’ IDENTIFIED BY ‘HierMysqlKennwortEingeben’ WITH GRANT OPTION;
Wenn ich das aber versuche, dann erhalte ich die Fehlermeldung
Code:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Kann ich denn als "root" nicht alle MySQL-Daten ändern?

Jemand eine andere Idee?
 

speedy8

Member
nun, habs doch noch selbst gefunden. Und zwar
Code:
mysql -u root -p                    
[bei der Abfrage das mysql-root-Kennwort eingeben]

use mysql;

update user set password=PASSWORD('HierNeuesIspconfigMysqlKennwortEingeben') where user='ispconfig';

flush privileges;

quit

So, also in mysql konnte ich jetzt das Kennwort ändern. Es stimmt jetzt mit allen Config-Files überein.

Ich wollte jetzt in der ispconfig-Files das mysql-Kennwort auch ändern ... und da steht unter /usr/local/ispconfig/server/lib/config.inc.php schon genau dieses Kennwort drin. Und was soll ich sagen, ich kann mich nun, nachdem ich in mysql das Kennwort geändert habe, mich natürlich auch nicht mehr m ISPConfig-Backend anmelden. Und ich könnte wetten, wenn ich jetzt in mysql das Kennwort für den ispconfig-Nutzer wieder zurückstelle, dass dann das Login wieder funktioniert.

Kann mir jemand sagen, ob die MySQL-Daten für ispconfig in einem anderen Config-File abgelegt werden als oben dargestellt?
 

robotto7831a

Well-Known Member
Ja, in /usr/local/ispconfig/server/lib/config.inc.php steht das MySQL Passwort.

Wenn Du einfach damit aufhörst wild irgendwelche Konfigfiles und Dumps hin und her zu kopieren, dann hättest Du viel weniger Probleme. Und von einer anderen DB Version die mysql Datenbank in einer höheren DB Version zu verwenden ist übrigens eine schlechte Idee. MySQL ändert auch schon mal etwas an seinen Tabellenstrukturen.
 

speedy8

Member
ja, danke für die Antwort. Ich denke, jetzt müsste alles laufen bis auf roundcube.
Aber mit der anderen Datenbank-Version auf dem neuen Server hatte ich ja schon erklärt. Mir wäre es auch lieber gewesen, auf dem neuen Server ein identisches Debian installiert zu haben mit identischen Versions-Nummern. Aber leider sind diese Voraussetzungen nicht gegeben.

Ich habe noch einmal im Forum gesucht und einige Anleitungen zur Server-Migration gefunden. Wenn ich es richtig verstanden habe, dürfte eigentlich alles ganz easy sein!

1. Backup der Verzeichnisse /var/vmail und /var/www inklusive aller Berechtigungen, also entweder ein" tar cfvzp" über die Verzeichnisse oder aber ein rsync -az vom alten auf den neuen Server (letzteres habe ich gemacht).
2. Backup der Dateien /etc/passwd ; /etc/group , /etc/shadow ; /etc/gshadow, um aus diesen Dateien dann händisch die web* und client* - Nutzer auf dem neuen Server einzutragen.
3. ein Datenbank-Backup erstellen. Hier hatte ich in meinem ursprünglichen Dump ein Backup über alle vorhandenen Datenbanken gemacht und auf dem neuen Server wieder eingestellt. Das war aber wohl falsch. Daher habe ich noch einmal einen neuen DUMP erstellt mittels
mysqldump -u root -p --databases dbispconfig roundcube userdatenbank1 userdatenbank2 userdatenbank3 > /root/backup/mysql-datenbanken-2016-03-14.sql
Anstelle der "userdatenbank1" etc. war natürlich der korrekte Datenbank-Name einzugeben. Da ich das falsch gemacht hatte, habe ich den Migrations-Vorgang noch einmal komplett neu gestartet, Neuen Server noch einmal entsprechend der "Perfekter Server"-Anleitung installiert.
4. Als nächstes habe ich den Datenbank-Dump auf den neuen Server kopiert und dort mittels
mysql -p < /root/backup/mysql-datenbanken-2016-03-14.sql
auf dem neuen Server eingespielt.
5. Nun habe ich mich auf dem neuen Server im ISPConfig-Backend eingeloggt, die IP-Adresse des neuen Servers eingegeben und dann unter EINSTELLUNGEN -->Resync einen Resync bzgl. aller Dienste durchgeführt.
6. Danach habe ich dann die Verzeichnisse /var/www und /var/vmail auf dem neuen Server überspielt mittels
rsync -az /var/vmail root@NeueIP-Adresse:/var/vmail/
rsync -az /var/www root@NeueIP-Adresse:/var/www/

Wenn ich jetzt in die Logs schaue, bin ich der Meinung, dass alle Dienste korrekt laufen.

Das Einzige Problem, welches ich jetzt noch habe, ist Roundcube. Ich erhalte das Login-Fenster, jedoch kann ich eingeben, was ich will, nach der Bestätigung des Logins erhalte ich eine weiße leere Seite. Ich habe die Passworte überprüft sowohl in der /etc/roundcube/debian-db.php (hier wird der Mysql-User und DB für Roundcube eingegeben) als auch unter /var/lib/roundcube/plugins/ispconfig3_account/config/config.inc.php (hier wird der in ISPConfig eingegebene RemoteUser eingegeben).

Wie gesagt, die Login-Daten stimmen, aber leider startet es nicht richtig. Ich werde jetzt auf dem neuen Server noch einmal RoundCube Deinstallieren und danach neu installieren. Mal schauen, obs dann richtig läufigt.

Oder hat noch jemand eine Idee, wie ich hier noch schlauer werden kann?
 

speedy8

Member
Habe eben noch einmal das RoundCube installiert, Datenbank noch einmal erstellt, noch einmal ein resync der Email-Konten erstellt ... aber noch selbe Systematik. Nach Bestätigung der Login-Eingaben bleibt Seite weiß und in der /var/log/syslog sind keine Fehlermeldungen erkennbar.

Kann mir noch jemand sagen, wo ich hier Infos erhalte, warum RoundCube nicht durchstartet?

Vielen Dank.
 

florian030

Well-Known Member
Nutzt Du weiterhin Courier oder jetzt Dovecot? Wenn Du bei Courier geblieben bist, passt SASL nicht mehr. Das Unterscheidet sich zwischen Debian 6 und 7.
 

speedy8

Member
Hallo, habe aktuell sämtliche Software so installiert wie unter https://www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-courier-ispconfig-3-p3
beschrieben, also auch courier. Was hat sich denn mit courier und sasl geändert? Funktioniert das gar nicht mehr oder muss hier was angepasst werden? Oder sollte ich doch besser dovecot verwenden und den neuen Server nach der Anleitung https://www.howtoforge.com/perfect-server-debian-wheezy-apache2-bind-dovecot-ispconfig-3-p3 aufsetzen?

Oder reicht jetzt einfach ein
Code:
apt-get autoremove courier-authdaemon courier-authlib-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl courier-maildrop

und danach ein

Code:
apt-get install openssl dovecot-imapd dovecot-pop3d dovecot-mysql dovecot-sieve sudo

sowie die Anpassung der Skripte/config-Files von fail2ban ?
 
Zuletzt bearbeitet:

speedy8

Member
Habe das jetzt eben einmal durchgeführt ... und danach mit ispconfig die Dienste neu Starten lassen. Also DOVECOT läuft jetzt.

ABER ... das RoundCube-Login führt noch immer nicht zur entsprechenden Web-Mailer-Oberfläche. Der Login-Screen erscheint tadellos, aber nach dem Login (auch mit falschem Passwort) führt nicht zu einer Fehlermeldung, sondern zu einem weißen Bildschirm. Wenn ich mir die Sourcen dieser HTML-Seite anzeigen lasse, dann ist das im großen und ganzen leer bis auf die <html>, <head> und <body> Marker.

Zudem ... wenn ich mich mit meinem Email-Client (Thunderbird) von zu Hause ins Email-Postfach einlogge, dann macht der das korrekt ... aber er zeigt mir keine E-Mails an (hat er im Übrigen bei der Verwendung von Courier auch nicht!!!).

Wenn ich in meine /var/vmail - Verzeichnisse reinschaue, da sehe ich natürlich dann Ordner wie "courierimaphieracl" oder "courierimapuiddb". Ich gehe einmal davon aus, dass mit dieser Ordner-Struktur die bisherigen Mails nicht zu lesen sind. Gäbe es hier ein Migrations-Skript???

Wie würdet ihr denn hier an meiner Stelle vorgehen?! Funktioniert denn Courier überhaupt nicht mehr sinnvoll mit ISPConfig3 auf Debian 7.x ??
 

Werbung

Top