Es ist vollbracht!
Ja, es ist vollbracht: Endlich LÄUFT der neue Server, jegliche Dienste sind umgezogen UND es gibt erstmal keine offensichtlichen Fehler mehr …
Die eigentliche Umzugsarbeit war nach nicht mal einer Stunde erledigt und auch das Umziehen der über 20 Domains war in etwa 15 Minuten getant (das Aktualisieren des DNS-Caches dürfte nicht mal ins Gewicht gefallen sein, da jegliche Domains eh nur 10 Minuten gecacht werden sollen).
Aber gut: Warum melde ich mich dann erst ~2 Stunden später? Kurz gesagt: Weil FCGID der Meinung war, Scripte mit kuriosesten Berechtigungsproblemen nicht ausführen zu wollen. Die Ursache, dass es an den Rechten liegt, ist bei Fehlermeldungen wie
[Sat Nov 14 00:25:59 2009] [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [Sat Nov 14 00:25:59 2009] [error] [client 65.55.207.101] Premature end of script headers: index.php |
den von Aussagekraft strotzenden Log-Einträgen von suexec (apache2-suexec-custom) a la
[2009-11-13 23:46:32]: uid: (2059/vu2059) gid: (2059/vu2059) cmd: php5-fcgi-starter [2009-11-13 23:46:32]: target uid/gid (2059/2059) mismatch with directory (2018/2018) or program (2018/2018) |
ja wohl jedem Blinden ersichtlich sein. Oder täusche ich mich da. Na gut: Es gab da nun dieses HauZu, was die nötigen Schritte auch soweit recht gut beschrieben hatte, jedoch genau beim wichtigsten Schritt EXTREM patzte: Setzen der BErechtigungen für FastCGI.
Korrigiert müsste das Script lauten:
#!/bin/bash # # PROCESS DIRECTORY RIGHTS (OWNERSHIP & CHMOD) # # !!!! Edit path to mysql.cnf file !!!! mycnf=/root/mysql.cnf # sample mysql.cnf looks like this: # [client] # user=user_for_ispcp_database_usualy_root # password=password_of_user for domain_id in `echo "SELECT domain_id FROM ispcp.domain" | mysql --defaults-file=$mycnf -s`; do uid=`echo "SELECT domain_uid FROM ispcp.domain WHERE domain_id='$domain_id'" | mysql --defaults-file=$mycnf -s`; gid=`echo "SELECT domain_gid FROM ispcp.domain WHERE domain_id='$domain_id'" | mysql --defaults-file=$mycnf -s`; dmn=`echo "SELECT domain_name FROM ispcp.domain WHERE domain_id='$domain_id'" | mysql --defaults-file=$mycnf -s`; echo "==========================================================="; echo " $dmn"; echo "==========================================================="; # process ftp echo "UPDATE \`ispcp\`.\`ftp_group\` SET \`gid\`='$gid' WHERE \`groupname\`='$dmn'" | mysql --defaults-file=/root/mysql.cnf -s echo "UPDATE \`ispcp\`.\`ftp_users\` SET \`uid\`=$uid, \`gid\`='$gid' WHERE \`userid\` like '%@$dmn'" | mysql --defaults-file=/root/mysql.cnf -s chown -R vu$uid:vu$gid /var/www/virtual/$dmn chmod 770 /var/www/virtual/$dmn chown vu$uid:www-data /var/www/virtual/$dmn chown -R vu$uid:www-data /var/www/virtual/$dmn/backups chmod 770 /var/www/virtual/$dmn/backups chown -R vu$uid:vu$gid /var/www/virtual/$dmn/cgi-bin chmod 755 /var/www/virtual/$dmn/phptmp chown -R vu$uid:vu$gid /var/www/virtual/$dmn/errors chmod 775 /var/www/virtual/$dmn/errors chown -R vu$uid:vu$gid /var/www/virtual/$dmn/htdocs find /var/www/virtual/$dmn/htdocs -type d -exec chmod 775 {} \; chown vu$uid:www-data /var/www/virtual/$dmn/.ht* chown vu$uid:www-data /var/www/virtual/$dmn/.svn* chmod 640 /var/www/virtual/$dmn/.ht* chown -R vu$uid:www-data /var/www/virtual/$dmn/logs chmod 770 /var/www/virtual/$dmn/logs chown -R vu$uid:www-data /var/www/virtual/$dmn/phptmp chmod 770 /var/www/virtual/$dmn/phptmp chown -R vu$uid:vu$gid /var/www/fcgi/$dmn chmod 755 /var/www/fcgi/$dmn chmod 755 /var/www/fcgi/$dmn/php5-fcgi-starter chown -R vmail:mail /var/mail/virtual/* sleep 1 done |
Danach noch etwas zwecks enabledten Mods spielen, Stoßgebet gen Himmel und einen Restart des Apachen … Mit etwas Glück funktioniert es danach … Alternativ aus dem engine/setup-Verzeichnis das ispcp-update-Script ausführen (Im Falle, dass er Module nicht findet, in das setup-Verzeichnis vorher wechseln). Dort Punkt 9 auswählen, dann baut er jegliche Nutzer neu auf. Danach dann dieses Permission-Update-Script starten.
Da hatte ich mit Postfix, MySQL, und den zahlreichen anderen Diensten wirklich weniger Probleme.
Naja. Wird Zeit, dass die bei ispCP endlich die Server-Migration als Default-Feature upstream einpflegen!
Glückwunsch zum erfolgreichen Serverumzug – scheint nahezu reibungslos verlaufen zu sein, was nicht immer so der Fall ist… aber gute Vorbereitung ist die halbe Miete 😉 Sehr positiv anzumerken ist vor allem der massive Performancezuwachs. Na dann – absturzfreies Arbeiten. 😛
Kommentar von Peter Großöhme — 15.11.2009 @ 15:20:52