ISPConfig3 Update von 3.0.4.6 auf 3.0.5.1 - HCP leere Seite

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von Brainfood, 20. März 2013.

  1. Brainfood

    Brainfood Member

    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')
     
    Zuletzt bearbeitet: 20. März 2013
  2. Till

    Till Administrator

    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.

    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

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

    Brainfood Member

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

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

    Kipperlenny New Member

    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
     
  5. PatrickR

    PatrickR Member

    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
     
  6. PatrickR

    PatrickR Member

    Toll....... :confused: :( :mad: 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!!!
     
  7. Till

    Till Administrator

    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.
     
  8. PatrickR

    PatrickR Member

    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
     
  9. Till

    Till Administrator

    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.
     
  10. Till

    Till Administrator

    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
     
  11. PatrickR

    PatrickR Member

    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
     

Diese Seite empfehlen