ISPConfig3 Update von 3.0.4.6 auf 3.0.5.1 - HCP leere Seite

Brainfood · 20. März 2013

Heho,

ich hab gerade eben die Produktivserver aktualisiert.
Serverschema:
- 1x Config (Main HCP)
- 2x Web (Main + Backup Slave)
- 2x DB (Main + Backup Slave)
- 2x Mail (Main + Backup Slave)
- 2x DNS (Main + Backup Slave)

Auf jeder Kiste wurde ISPConfig CP (8080 + SSL) installiert, verwaltet werden sie aber nur durch den Config HCP

Backup von den laufenden ISPConfig 3.0.4.1 erstellt -> ISPConfig Update zuerst auf dem Config HCP -> dann auf allen Client-Servern durchgeführt, mit dem Ergebnis:

Config (8080) = leere Seite
DB1 = leere Seite
DB2 = leere Seite
Mail1 = leere Seite
Mail2 = leere Seite
DNS1 = leere Seite
DNS2 = leere Seite
Web1 = CP funktioniert
Web2 = CP funktioniert

Im Apache Error-Log stand:

Code:

[Wed Mar 20 11:21:33 2013] [error] [client 80.XXX.XXX.XXX] PHP Warning:  require_once(/usr/local/ispconfig/interface/lib/config.inc.php): failed to open stream: Permission denied in /usr/local/ispconfig/interface/web/index.php on line 31
[Wed Mar 20 11:21:33 2013] [error] [client 80.XXX.XXX.XXX] PHP Fatal error:  require_once(): Failed opening required '../lib/config.inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/local/ispconfig/interface/web/index.php on line 31
[Wed Mar 20 11:21:43 2013] [error] [client 2001::XXX] PHP Warning:  require_once(/usr/local/ispconfig/interface/lib/config.inc.php): failed to open stream: Permission denied in /usr/local/ispconfig/interface/web/index.php on line 31
[Wed Mar 20 11:21:43 2013] [error] [client 2001::XXX] PHP Fatal error:  require_once(): Failed opening required '../lib/config.inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/local/ispconfig/interface/web/index.php on line 31

Auf den funktionierenden Web1/2 stand zusätzlich:

/var/log/apache2/suexec.log

Code:

[2013-03-20 12:06:51]: uid: (5003/ispconfig) gid: (5004/ispconfig) cmd: .php-fcgi-starter
[2013-03-20 12:06:52]: uid: (5003/ispconfig) gid: (5004/ispconfig) cmd: .php-fcgi-starter
[2013-03-20 12:06:52]: uid: (5003/ispconfig) gid: (5004/ispconfig) cmd: .php-fcgi-starter

###

Da ich noch andere nicht aktualisierte Produktivserver laufen habe, hab ich mich dort eingeloggt und habe sehr ausführlich alle Permissions / Config-Inhalte zwischen den aktualisierten 3.0.5.1er und funktionsfähigen 3.0.4.6 Dosen verglichen.

Sprich ... die Rechte unter /usr/local/ispconfig sowie die Configs aus /etc/apache2 …

Die einzigen Unterschiede, die ich beobachten konnte, wären:

/etc/apache2/sites-available/apps.vhost

Code:

3.0.4.6

  <IfModule mod_fcgid.c>
    DocumentRoot /var/www/apps
    SuexecUserGroup ispapps ispapps
    <Directory /var/www/apps>
      Options Indexes FollowSymLinks MultiViews +ExecCGI
      AllowOverride AuthConfig Indexes Limit Options FileInfo
      AddHandler fcgid-script .php
      FCGIWrapper /var/www/php-fcgi-scripts/apps/.php-fcgi-starter .php
      Order allow,deny
      Allow from all
    </Directory>
  </IfModule>

  <IfModule mod_php5.c>
    DocumentRoot /var/www/apps
    AddType application/x-httpd-php .php
    <Directory /var/www/apps>
      Options FollowSymLinks
      AllowOverride None
      Order allow,deny
      Allow from all
    </Directory>
  </IfModule>

Code:

3.0.5.1

  <IfModule mod_php5.c>
    DocumentRoot /var/www/apps
    AddType application/x-httpd-php .php
    <Directory /var/www/apps>
      # php_admin_value open_basedir "/var/www/apps:/usr/share:/tmp"
      Options FollowSymLinks
      AllowOverride None
      Order allow,deny
      Allow from all
    </Directory>
  </IfModule>

  <IfModule mod_fcgid.c>
    DocumentRoot /var/www/apps
    SuexecUserGroup ispapps ispapps
    <Directory /var/www/apps>
      Options Indexes FollowSymLinks MultiViews +ExecCGI
      AllowOverride AuthConfig Indexes Limit Options FileInfo
      AddHandler fcgid-script .php
      FCGIWrapper /var/www/php-fcgi-scripts/apps/.php-fcgi-starter .php
      Order allow,deny
      Allow from all
    </Directory>
  </IfModule>

... die Reihenfolge ...

sowie in /etc/apache2/sites-available/ispconfig.vhost

Code:

3.0.4.6

  <IfModule mod_php5.c>
    DocumentRoot /usr/local/ispconfig/interface/web/
    AddType application/x-httpd-php .php
    <Directory /usr/local/ispconfig/interface/web>
      # php_admin_value open_basedir "/usr/local/ispconfig/interface:/usr/share:/tmp"
      Options FollowSymLinks
      AllowOverride None
      Order allow,deny
      Allow from all
         php_value magic_quotes_gpc        0
    </Directory>
  </IfModule>

Code:

3.0.5.1

#  <IfModule mod_php5.c>
#    DocumentRoot /usr/local/ispconfig/interface/web/
#    AddType application/x-httpd-php .php
#    <Directory /usr/local/ispconfig/interface/web>
#      # php_admin_value open_basedir "/usr/local/ispconfig/interface:/usr/share:/tmp"
#      Options FollowSymLinks
#      AllowOverride None
#      Order allow,deny
#      Allow from all
#         php_value magic_quotes_gpc        0
#    </Directory>
#  </IfModule>

In 3.0.5.1 is der komplette <IfModule mod_php5.c> auskommentiert.

Nach einem:

Code:

apachectl configtest
Syntax OK

Hab ich einfach mal folgende Befehle ausgeführt:

Code:

chown -R ispconfig:ispconfig /usr/local/ispconfig
grpck
pwconv
grpconv
pwck
service apache2 stop
service apache2 start

JETZT ging der Zugriff aufs Hosting-Control-Panel wieder

es scheint als "verschluckt" sich Apache etwas bei dem Services Neustart durch die ispconfig_update.php

Interessant ist auch an dieser Stelle:

Ist man im Control-Panel eingeloggt und bootet komplett den Server neu, erscheint im syslog:

Code:

Mar 20 13:23:33 sys1 suhosin[2098]: ALERT - configured GET variable limit exceeded - dropped variable 'refresh' (attacker '192.168.250.202', file '/var/www/ispconfig/monitor/show_sys_state.php')
Mar 20 13:23:38 sys1 suhosin[2098]: ALERT - configured GET variable limit exceeded - dropped variable 'refresh' (attacker '192.168.250.202', file '/var/www/ispconfig/monitor/show_sys_state.php')
Mar 20 13:23:43 sys1 suhosin[2098]: ALERT - configured GET variable limit exceeded - dropped variable 'refresh' (attacker '192.168.250.202', file '/var/www/ispconfig/monitor/show_sys_state.php')
Mar 20 13:23:48 sys1 suhosin[2098]: ALERT - configured GET variable limit exceeded - dropped variable 'refresh' (attacker '192.168.250.202', file '/var/www/ispconfig/monitor/show_sys_state.php')

Till · 20. März 2013

In einem multiserver setup darf nur auf dem controlpanel server das ispconfig interface installierts ein, das war schon immer so. Es ist also richtig wenn es auf allen anderen Servern nicht mehr geht.

In 3.0.5.1 is der komplette <IfModule mod_php5.c> auskommentiert.

Richtig, das muss auch so sein denn ab 3.0.5.1 wird fastcgi für das controlpanel genutzt. Auf keinen Fall den mod_php Teil wieder einsetzen oder permissions in /usr/local/ispconfig ändern wenn Du ein sicheres setup behalten möchtest.

wenn es auf Deinem cp server nicht erreichbar war dann fehlte entweder mod_fcgi bzw. es war nicht aktiv oder es war kein php5-cgi installiert

Ist man im Control-Panel eingeloggt und bootet komplett den Server neu, erscheint im syslog:

Scheinbah hast Du suhosin installiert und das get limit von suhosin zu niedrig gesetzt.

Brainfood · 20. März 2013

@Till

Geupdatet wurden die Kisten nach folgender Reihenfolge:

Sys1 (Main HCP) -> DB1 -> DB2 -> Mail1 -> Mail2 -> DNS1 -> DNS2 -> Web1 -> Web2

Das der ISPConfig Updater in einem Multiserver-Setup alle HCPs auf den "Slaves" deaktiviert um nur das Management vom Haupt HCP zu gestatten, wäre ja in Ordnung gewesen ... wenn es auch funktioniert hätte ...

im ispconfig_3_manual_1.4.pdf steht ja explizit:

If you use the command line update to update multiple servers, it is strongly recommended to run the update on the master first and afterwards on the slave(s)!

Jetzt funktioniert es wieder auf allen Kisten, wichtig ist sowieso nur der Zugriff aufs Main HCP

Kipperlenny · 28. März 2013

Jo bei mir das gleiche Problem (und ich habe schon immer nur ein CP auf dem Master Server installiert).

geholfen hat:

chown -R ispconfig:ispconfig /usr/local/ispconfig
grpck
/etc/init.d/apache2 restart

PatrickR · 16. Apr. 2013

Hallo,

bei mir auch der gleiche fehler nur hilft bei mir kein "Chown"

die ControlPanel seite bleibt weiß

erbitte schnelle hilfe

Code:

[Tue Apr 16 07:55:56 2013] [error] [client 188.246.9.36] PHP Warning:  require_once(/usr/local/ispconfig/interface/lib/config.inc.php): failed to open stream: Permission denied in /usr/local/ispconfig/interface/web/index.php on line 31

Danke / Gruß
Patrick

PatrickR · 16. Apr. 2013

Toll.......

grrrrrr

SQL Backup kann auch nicht eingespielt werden...

Code:

root@login2:/# mysql -uroot -p dbispconfig < ispconfig_db_backup.sql
Enter password:

ERROR 1062 (23000) at line 33: Duplicate entry '107' for key 'PRIMARY'
root@login2:/# ERROR 1062 (23000) at line 33: Duplicate entry '107' for key 'PRIMARY'

HILFE!!!

Till · 16. Apr. 2013

Zitat von PatrickR:
Toll....... grrrrrr

SQL Backup kann auch nicht eingespielt werden...

Code:

root@login2:/# mysql -uroot -p dbispconfig < ispconfig_db_backup.sql Enter password: ERROR 1062 (23000) at line 33: Duplicate entry '107' for key 'PRIMARY' root@login2:/# ERROR 1062 (23000) at line 33: Duplicate entry '107' for key 'PRIMARY'

HILFE!!!

Nicht das backup zurückspielen!

Wenn die Seite weiß bleibt dann liegt ein PHP Problem vor. Da die neue Version ja bereits auf einige zehntausend Servern erfolgreich installiert wurde ist ja klar dass es kein Problem in der Software sondern in der Konfiguration des Servers ist.

Wahrscheinlich fehlt das php fcgi binary oder das fastcgi apache Modul oder es wurde etwas gegenüber dem standards etup geändert.

PatrickR · 16. Apr. 2013

Hallo Till,

die module sind alle installiert. alles was in den postings weiter oben steht habe ich ausprobiert. alles ohne erfolg.

also muss ich notgedrungen die backups einspielen um die sachen wieder ans laufen zu kriegen.
zum glück ist dies nun ein kleines neben system auf dem nicht viele kunden drauf sind.

es ist ein standart setup nach dem HowTo. Multiserver Setup debian 6.0
(ein CP Server, ein webserver (mail, ftp, apache, mysql)

Ich habe allerding auch schon mehrmals probiert auf einem simulierten system auf unseren Vserver das update aufzuspielen... auch ohne erfolg.

Danke, viele grüße
Patrick

Till · 16. Apr. 2013

Dann kann ich Dir auch nicht sagen was auf Deinen Servern falsch bzw. anders ist, Habe hete mehrer Server von unseren Kunden aktualisiert, eifach ispconfig_update.sh aufgerufen und alle laufen einwandfrei. Es handelt sich bei allen Dieden Systemen um perfects setups die ich selbst installiert habe, ich weiß also dass sie exakt der Anleitung entsprechen.

Till · 16. Apr. 2013

Ich kann mir das auf Deinem Server natürlich gerne mal ansehen, aber das fällt aber unter den kostenpflichtigen Support. Du erreichst ihn über unser Ticketsystem:

projektfarm :: Support Ticket System

PatrickR · 16. Apr. 2013

Hallo Till,

für das System wäre es uninteressant, dass du dir das anschaust, da es wie gesagt nur ein ganz kleines system mit 4 kunden ist. habe es nun auch schon wieder auf den alten stand gebracht.

Aber für unser eigentliches Produktivsystem wäre es interessant, habe dir dazu aber schon eine PM geschickt.

Danke und viele Grüße
Patrick

ISPConfig3 Update von 3.0.4.6 auf 3.0.5.1 - HCP leere Seite

Brainfood

Member

Till

Administrator

Brainfood

Member

Kipperlenny

New Member

PatrickR

Member

PatrickR

Member

Till

Administrator

PatrickR

Member

Till

Administrator

Till

Administrator

PatrickR

Member

Werbung

Wir schützen deine Privatsphäre