# DRINGENDE Anfrage: Server-Umzug bei unterschiedlichen Debian-Versionen



## speedy8 (10. März 2016)

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!


----------



## Till (10. März 2016)

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 (11. März 2016)

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 


```
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

```
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:


```
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 (11. März 2016)

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

Dort wird mir jetzt folgendes ausgegeben.


```
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


```
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


```
[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 


```
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 (11. März 2016)

Kopiere mal die /etc/mysql/debian.cnf Datei vom alten auf den neuen Sever und starte mysql neu.


----------



## Till (11. März 2016)

Zitat von speedy8:


> 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 (13. März 2016)

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:

```
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:


```
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 (13. März 2016)

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:


```
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

```
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 (13. März 2016)

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 (13. März 2016)

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:


```
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?!?!?!


----------



## robotto7831a (13. März 2016)

Was ist an Access denied nicht zu verstehen?


----------



## speedy8 (13. März 2016)

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:


```
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

```
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 (13. März 2016)

nun, habs doch noch selbst gefunden. Und zwar

```
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 (14. März 2016)

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 (14. März 2016)

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 (14. März 2016)

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 (15. März 2016)

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 (15. März 2016)

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

```
apt-get autoremove courier-authdaemon courier-authlib-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl courier-maildrop
```
und danach ein


```
apt-get install openssl dovecot-imapd dovecot-pop3d dovecot-mysql dovecot-sieve sudo
```
sowie die Anpassung der Skripte/config-Files von fail2ban ?


----------



## speedy8 (15. März 2016)

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  ??


----------



## speedy8 (15. März 2016)

ok ... für die Migration von courier zu dovecot gibt es wohl ein Migrations-Tool, nämlich hier http://wiki.dovecot.org/Migration/Courier


----------



## robotto7831a (15. März 2016)

Du installierst einen Wheezy Server nach der Anleitung für Squeeze?

Für die Courier Migration gibt es ein Skript.
https://www.howtoforge.de/forum/threads/ispconfig-2-courier-durch-dovecot-ersetzen.5916/#post-30671


----------



## speedy8 (15. März 2016)

Zitat von robotto7831a:


> Du installierst einen Wheezy Server nach der Anleitung für Squeeze?


Ja, das hatte ich eingangs ja auch geschrieben. Hintergrund war, dass ich der Meinung war, dass die Server-Konfiguration des neu aufgesetzten Servers ziemlich identisch mit der alten Konfiguration sein sollte. Und der alte Server war halt nach der Squeeze-Anleitung mit den dort benannten Paketen erfolgt. Die Debian-Sourcen selbst waren natürlich von Wheezy, da es die Squeeze-Sourcen nicht mehr gab.

Werde gleich noch die Courier-DoveCot-Migration durchführen. Aber sollte das der Hintergrund sein, dass Roundcube sich offensichtlich nicht richtig authorisiert und in einer blanken weißen Seite landet?


----------



## speedy8 (16. März 2016)

ok, habe die in der im ZIP.File enthaltenen Readme alle Schritte ausgeführt, obwohl ich ja courier bereits deinstalliert hatte und dovecot installiert hatte.

Wenn ich jetzt in dem Skipt die Daten des entfernten ISPConfig-Benutzers eintrage, dann verbindet der neue Server sich wohl ordnungsgemäß, offensichtlich werden auch die Postfach-Daten von Courier gewandelt (neue Daten liegen dann unter /var/vmail/POSTFACHNAME/mail/Maildir

ABER ... wenn ich mich via Mail-Client von zu Hause einlogge, dann erhalte ich folgende Meldung


```
Mar 16 01:26:12 galaxy dovecot: imap(POSTFACH-Email): Error: stat(/var/vmail/POSTFACHNAME/mail/Maildir/.quotausage/tmp) failed: Not a directory
Mar 16 01:26:12 galaxy dovecot: imap(POSTFACH-Email): Error: stat(/var/vmail/POSTFACHNAME/mail/Maildir/.quotausage/tmp) failed: Not a directory
```
Was läuft hier noch schief?

Zudem läuft roundcube noch immer nicht, obwohl ich in der Config schon die für den "Entfernten Benutzer dovecot" relevanten Daten eingegeben habe.

Vielen Dank für eure weitere Unterstützung.
Tut mir leid, wenn ich vielleicht nerve!


----------



## Till (16. März 2016)

Zitat von speedy8:


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


Klar funktioniert das auch auch Debian 7 und 8, exakt genauso wie auf Debian 5 und 6. Wir schreiben nur keine neuen Courier tutorials da das Setup mit dovecot meines Erachtens besser ist und Dovecot mehr Zukunftspotential hat.


----------



## speedy8 (16. März 2016)

So,
ich glaube, jetzt funktioniert alles. Ich hätte sicherlich vor alledem hier im Forum die Beiträge zur "Server Migration" lesen sollen.

Zusammenfassend möchte ich noch mitteilen, was ich im einzelnen gemacht habe, um diesen Beitrag abzuschließen (ich hoffe, dass nach der DNS-Änderung meiner Domains auch weiterhin alles ordentlich läuft!)

1. Installation des neuen Debian-7-Servers nach dieser Anleitung. (außer squirrelMail, da ich RoundCube nutzen will)
2. auf dem alten Server anhalten der Mail-Dienste und des Web-Servers.
3. auf dem alten Server erstellen von Backups des Ordners /var/vmail und /var/www
Ein direktes rSync der Ordner vom alten auf den neuen Server hatte bei mir irgendwie die Rechte nicht 100%ig gesetzt. Daher mit folgenden Befehlen erst Tar-Archive erstellen, die ich dann mittels rSync auf den neuen Server geschoben habe


```
mkdir /root/backup
cd /root/backup
tar cfvpz var-vmail.tar.gz /var/vmail/
tar --exclude="/var/www/cache/*" -cpvz - /var/www/ | split -b 1000M - var-www.tar.
```
Mit letzterem Befehl werden 1GB-große Dateien erstellt.
4. Erstellen eines Datenbank-Dumps der dbispconfig sowie aller Nutzer-Datenbanken. 

```
mysqldump -u root -p --databases dbispconfig roundcube usr_DB_1 usr_DB_2 usr_DB_3 usr_DB_4 usr_DB_5 usr_DB_6 usr_DB_7 > /root/backup/mysql-datenbanken-2016-03-14.sql
```
Anstelle von usr_DB_x war natürlich der tatsächliche Datenbankname einzugeben.
5. Nun waren alle Backup-Daten vom alten Server auf den neuen Server zu überspielen

```
rsync -avz /root/backup/* root@IpNeuerServer:/root/backup/
```
6. Auf dem neuen Server habe ich nun als erstes das Datenbank-Backup eingespielt. 

```
/root/backup/mysql-datenbanken-2016-03-14.sql
```
7. Nun habe ich mich im ISPConfig-Backend eingeloggt, die ServerIP aktualisiert und die ServerEinstellungen zum E-Mail-System. Diese waren jetzt auf *DoveCot *und *Sieve* zu stellen.
8. Jetzt habe ich gleich noch vorsorglich einen RemoteUser für DoveCot angelegt. BenutzerName und Passwort merken!
9. Jetzt habe ich das Mail-System sowie den Apache-Server angehalten

```
/etc/init.d/postfix stop
/etc/init.d/dovecot stop
/etc/init.d/apache2 stop
```
10. Nun waren die Backup-Dateien von /var/vmail und /var/www zu entpacken.

```
cd /
tar xfvpz /root/backup/var-vmail.tar.gz
cat /root/backup/var-www.tar.* | tar xfvzp -
```
11. Da ich auf meinem alten Server courier statt das jetzt installierte DoveCot installiert hatte, mussten noch die Email-Verzeichnisse konvertiert werden. Das habe ich mit dem Skript aus diesem Artikel gemacht (wie bereits oben von 
*robotto7831a* mitgeteilt). Entsprechend der Readme habe ich dazu zunächst noch einige Programmpakete nachinstalliert und dann das Skript angepasst bzgl. der Daten des vorhin angelegten RemoteUsers für DoveCot.

```
apt-get install dovecot-imapd dovecot-pop3d dovecot-common
php courier_to_dovecot.php
```
12. Jetzt habe ich noch ein ISPConfig-Update laufen lassen

```
cd /tmp
wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xfz ISPConfig-3-stable.tar.gz
cd ispconfig3_install/install/

php -q update.php
```
Auf die Frage, ob die Dienste neu konfiguriert werden sollen, ist mit YES zu antworten (Standard ist NO).

13. Jetzt habe ich noch den WebMailer Roundcube installiert und konfiguriert (vom alten Server habe ich im ISPConfig ja bereits einen RemoteUser für RoundCube. Also musste ich diesen nicht neu anlegen!)

```
apt-get install roundcube roundcube-plugins roundcube-plugins-extra

nano /etc/apache2/conf.d/roundcube

nano /etc/roundcube/main.inc.php

/etc/init.d/apache2 restart

apt-get install git
cd /tmp
git clone https://github.com/w2c/ispconfig3_roundcube.git
cd /tmp/ispconfig3_roundcube/
mv ispconfig3_* /var/lib/roundcube/plugins
cd /var/lib/roundcube/plugins
mv ispconfig3_account/config/config.inc.php.dist ispconfig3_account/config/config.inc.php

nano ispconfig3_account/config/config.inc.php
```
Für die Eintragungen in die einzelnen Config-Dateien habe ich mich an dieser Anleitung langgehangelt.

Jetzt kann ich mich unter http://MeineNeueServerIP/webmail in RoundCube anmelden, und die Emails im IMAP-Postfach werden korrekt angezeigt.

Warum das entsprechend der bisherigen Einträge in diesem Threat nicht funktioniert hat weiß ich nicht.

Ich werde auf meinem alten Server über Nacht nun den Mail-Server und den Apache-Server ausschalten ... und morgen früh, wenn alle DNS-Server im Netz meine neue SERVER-IP übernommen haben, dürften die E-Mail-Zustellungsversuche auf meinen neuen Server umgelenkt werden ... und die Webanfragen werden dann wohl auch wieder entsprechend umgeleitet.

Hoffentlich klappt das auch alles schön!

Vielen dank noch einmal allen hier im Forum für die Unterstützung ... und vor allem auch Till für die tolle Arbeit.

mfg


----------



## robotto7831a (16. März 2016)

Bleibt nur noch die Frage, warum Du nicht auf die aktuellste Debian Version gegangen bist. Immerhin läuft Wheezy aus dem normalen Support raus.


----------



## speedy8 (16. März 2016)

Zitat von robotto7831a:


> Bleibt nur noch die Frage, warum Du nicht auf die aktuellste Debian Version gegangen bist. Immerhin läuft Wheezy aus dem normalen Support raus.


Nun, ein Upgrade ist ja im Bedarfsfall unproblematisch möglich. Wann läuft denn Wheezy tatsächlich aus dem Support raus?

Ok, habe eben mal im Wikipedia geschaut, und der Support für das normale Debian 7 läuft wohl in 02/2016 aus, das LTS dann erst in 2018.

Vielleicht werde ich mich demnächst doch noch mit dem Upgrade beschäftigen, da der neu aufgesetzte Server jetzt läuft und alle Umstellungsdinge bereits vorgenommen sind.

Danke.


----------



## speedy8 (23. März 2016)

Hallo,

eine letzte Frage tauchte bei mir jetzt noch auf: Und zwar möchte ich roundcube, welches ich via "apt-get install roundcube" installiert habe und welches unter /var/lub/roundcube abgelegt ist, für alle vorhandenen Domains unter http://mail.domain.de verfügbar machen.

Ich dachte, dass es hier ausreichend wäre, einfach eine neue Datei unter /etc/apache2/sites-available/roundcube.vhost anzulegen mit nachfolgendem Inhalt:

```
<VirtualHost *:80>
    ServerAdmin webmaster@meineDomain.de
    ServerAlias mail.*

    DocumentRoot /var/lib/roundcube/
    <Directory />
            Options FollowSymLinks
            AllowOverride None
    </Directory>
    <Directory /var/lib/roundcube>
            Options Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

    ErrorLog /var/log/apache2/mail.error.log
    LogLevel warn

    CustomLog /var/log/apache2/mail.access.log combined
</VirtualHost>
```
Aber irgendwie will das nicht funktionieren.

Gibts hier noch eine einfachere Variante, meinen Wunsch zu realisieren?

Mfg


----------

