PHP-Fehler bei Installation von CRM auf Shared-Webserver

[Karl Heinz]

Guten Abend,

hab eine Frage zum CRM-System vTiger. Wollte mir das kostenfreie CRM auf meinem Webspace installieren. Während der Installation auf meinem "shared Server" tritt folgende Warnung auf:

Recommended PHP Settings:

Directive Recommended PHP.ini value
max_execution_time 600 30
error_reporting E_WARNING & ~E_NOTICE NOT RECOMMENDED

Da ich mir nicht zu helfen wußte (kenne mich mit PHP nicht aus) hab ich meinen Hoster (allinkl.com) angerufen und gefragt ob ich diese Warnungen ignorieren kann. Der meine folgendes:

• Ein umstellen von max_execution_time von 30 auf 600 sei nicht möglich, da ich nur einen "Shared Server" habe, sie könnten diesen Wert nur dann auf 600 hochstellen, wenn ich mir einen kompletten Server miete, was ich mir nicht leisten kann. Er konnte mir nicht sagen, ob der zu geringe Wert 30 zu Problemen bei der Installation führt, ich sollte es einfach ausprobieren

• bezüglch error_reporting sagt der Hoster es würde nix ausmachen und ich sollte die Einstellung so lassen

Nach dem Anruf beim Hoster habe ich die Installation trotz Warnungen einfach mal durchgeführt. Die Installatoin bricht nach einigen Minuten mit dieser Meldung ab:

Gateway Time-out
The gateway did not receive a timely response from the upstream server or application.

Rufe ich dann erneut die URL auf gelange ich zum Loginbildschirm von vTiger. Nach einem Login scheint alles zu funktionieren. Sicherheitshalber hab ich nun dennoch beim Support von vTiger angerufen und nachgefragt, die meinten mit einem Shared-Server würde das nicht gehen und ich solle entweder die Clowd-Variante nutzen (25 Euro im Monat) oder aber den Kram auf einem eigenen Server z.B. bei mir in der Firma installieren, wo ich dann den PHP-Wert max_execution_time auf 600 setzen kann.

Das kommt mir irgendwie seltsam vor, verstehe nicht warum der Kram nicht auf meinem Shared-Server laufen sollte. Scheinbar funktioniert es ja auch, wir nur nicht das Risiko eingehen, dass eine max_execution_time von 30, die ja eigentlich 600 sein sollte auf Dauer im Betrieb zu größeren Problemen führt.

Wäre toll wenn mir die PHP Experten von euch einen Ratschlag geben könnten. Soll ich jetzt einfach das Tool nutzen ohne mir weitere Gedanken zu machen oder kann es auf Dauer Probleme machen, weil max_execution_time ja nur auf 30 steht.

PS:
Sonderbar ist ja auch das die Installation mit einer Fehlermeldung abgegrochen hat wie oben bereits erwähnt:

Gateway Time-out
The gateway did not receive a timely response from the upstream server or application.

Bin mir unsicher ob der Kram nun richtig installiert ist oder nicht.

Vielen Dank für eure Hilfe.

[dedlfix]

Hi!

Das kommt mir irgendwie seltsam vor, verstehe nicht warum der Kram nicht auf meinem Shared-Server laufen sollte. Scheinbar funktioniert es ja auch, wir nur nicht das Risiko eingehen, dass eine max_execution_time von 30, die ja eigentlich 600 sein sollte auf Dauer im Betrieb zu größeren Problemen führt.

Es kann sein, dass das Installationsscript eine zeitaufwendige Arbeit verrichtet, wie das Einrichten der Datenbank. Das kann es vielleicht nicht (vollständig) tun und hinterlässt eine unvollständige Installation. Beim kurzen Testen fällt dir möglicherweise der fehlende Teil nicht auf.

Wäre toll wenn mir die PHP Experten von euch einen Ratschlag geben könnten.

Raten, mehr können wirᵀᴹ nicht, es sei denn, jemand kennt die Arbeitsweise des Installationsscripts näher.

Soll ich jetzt einfach das Tool nutzen ohne mir weitere Gedanken zu machen oder kann es auf Dauer Probleme machen, weil max_execution_time ja nur auf 30 steht.

Wenn ein Script beim normalen Arbeiten 30 Sekunden CPU-Zeit verbraucht, ist sowieso kein ordentliches (= einigermaßen zügiges) Arbeiten möglich. Die reale Wartezeit kann nochmal deutlich länger sein, weil nur die selbst verbrauchte Zeit zählt und nicht das Warten auf andere Prozesse. Mit einer anzunehmenden fehlerhaften Installation werden bestimmt an irgendeiner Stelle ebenfalls Probleme zu erwarten sein.

Lo!

[Karl Heinz]

Wenn ein Script beim normalen Arbeiten 30 Sekunden CPU-Zeit verbraucht, ist sowieso kein ordentliches (= einigermaßen zügiges) Arbeiten möglich.

Woher weißt Du denn, dass das Script 30 Sekunden verbraucht und in welchem Zusammenhang meinst Du das, verstehe nur Bahnhof.

Warum ist dann kein ordentliches Arbeiten möglich? Es braucht doch nur einmal bei der Installation 30 Sekunden Zeit, danach ist da doch erledigt und ich kann ohne Probleme arbeiten... oder?

Die reale Wartezeit kann nochmal deutlich länger sein, weil nur die selbst verbrauchte Zeit zählt und nicht das Warten auf andere Prozesse. Mit einer anzunehmenden fehlerhaften Installation werden bestimmt an irgendeiner Stelle ebenfalls Probleme zu erwarten sein.

Ich zieh mal ein Fazit hoffe ich hab's richtig verstanden, bitte berichtigen :-)

• weil das Script mehr als 30 Sekunden zur Installation braucht und mein Hoster mir nicht die Möglichkeit gibt, dass ein Script mehr als 30 Sekunden laufen darf, fällt die Installation auf einem Shared-Server flach. Ist das richtig so?

• Als Alternative bleibt mir also nur entweder einen ganzen Server zu mieten (bei einem Hoster) oder eben in meiner Firma einen Server zu nutzen auf dem ich dann einen Apache, PHP, MySQL usw. installiere.

Zur welcher Variante würdest Du mir denn raten?

PS:

Gibt es nicht vielleicht doch irgendeine Möglichkeit den Kram auf einem Shared Server zu nutzen?

[dedlfix]

Hi!

Wenn ein Script beim normalen Arbeiten 30 Sekunden CPU-Zeit verbraucht, ist sowieso kein ordentliches (= einigermaßen zügiges) Arbeiten möglich.
Woher weißt Du denn, dass das Script 30 Sekunden verbraucht und in welchem Zusammenhang meinst Du das, verstehe nur Bahnhof.

Ich sprach von der Möglichkeit, dass es dies tun könnte. Ansonsten braucht man zur Laufzeit ja keine max_execution_time-Erhöhung. In dem Fall wäre das ein einmaliger Akt beim Installieren. Man könnte dann versuchen, das System auf einem unbeschränkten Rechner zu installieren und einen Datenbank-Dump nebst Dateienkopieren auf den Hoster-Server laden. Datenbank-Dumps spielen sich üblicherweise recht schnell ein, oder man separiert das auf handliche Häppchen.

Warum ist dann kein ordentliches Arbeiten möglich? Es braucht doch nur einmal bei der Installation 30 Sekunden Zeit, danach ist da doch erledigt und ich kann ohne Probleme arbeiten... oder?

Das ist die Vermutung, dass es nur bei der Installation so lange braucht und nicht ständig Gedenkminuten beim Arbeiten einfordert.

Ich zieh mal ein Fazit hoffe ich hab's richtig verstanden, bitte berichtigen :-)

• weil das Script mehr als 30 Sekunden zur Installation braucht und mein Hoster mir nicht die Möglichkeit gibt, dass ein Script mehr als 30 Sekunden laufen darf, fällt die Installation auf einem Shared-Server flach. Ist das richtig so?

Ja, aber eine Kopie einer anderswo installierten Version zu übertragen kann einen Versuch wert sein. Dazu muss man aber genau beobachten, wie sich das System installiert hat. Unter anderem sollte man die Dateibesitzverhältnisse und -berechtigungen anschauen und adäquat auf dem Hoster-Server einrichten.

• Als Alternative bleibt mir also nur entweder einen ganzen Server zu mieten (bei einem Hoster) oder eben in meiner Firma einen Server zu nutzen auf dem ich dann einen Apache, PHP, MySQL usw. installiere.
  Zur welcher Variante würdest Du mir denn raten?

Das musst du schon selbst entscheiden. Einen eigenen Server zu mieten/betreiben zieht wieder dessen Wartung nach sich. Die Installation-Anderswo-plus-Kopieren-Variante kann aufwendig sein, ist aber ein einmaliger Akt, wenn man alles richtig macht.

Lo!

[Karl Heinz]

Hab nun ein weiteres mal bei meinem Hoster angerufen, hatte jetzt einen anderen Anprechpartner am Telefon. Dieser hat mir nun gesagt, dass es eben doch möglich ist "max_execution_time" auch bei einem Shared Server auf 600 umzustellen. Unter seiner Anleitung habe ich dies getan. Habe folgendes in die .htaccess Datei gepackt:

php_value max_execution_time 600

Anschließend folgende Adresse zur Kontrolle aufgerufen:

http://www.<meine URL>/infophp.php

dort wird dann auch bestätigt, das der Wert von "max_execution_time" wirklich auf 600 steht.

Anschließend hab ich die Installation gestartet. Diese bricht nach eininger Zeit mit folgender Fehlermeldung ab:

Gateway Time-out
The gateway did not receice a timely response from the upstream server or applicaton

Was hat das denn nun wieder zu bedeuten und was kann ich tun um dieses Problem zu lösen?

[dedlfix]

Hi!

Anschließend hab ich die Installation gestartet. Diese bricht nach eininger Zeit mit folgender Fehlermeldung ab:
Gateway Time-out
The gateway did not receice a timely response from the upstream server or applicaton

Das ist sicher keine Ausgabe des Installationsscripts sondern eher eine Meldung des Browsers oder eines Proxys, weil denen was zu lange dauert. Wenn du schon in der .htaccess Konfigurationen ändern kannst, stell die Angaben zum Error-Logging so ein, dass in eine Datei geschrieben wird, dann siehst du vielleicht mehr.

Lo!

[Karl Heinz]

Wenn du schon in der .htaccess Konfigurationen ändern kannst, stell die Angaben zum Error-Logging so ein, dass in eine Datei geschrieben wird, dann siehst du vielleicht mehr.

hab jetzt folgendes in die .htaccess gepackt:

php_value max_execution_time 600
php_value error_log error.log

Ist das so richtig?

[dedlfix]

Hi!

[...]stell die Angaben zum Error-Logging so ein, dass in eine Datei geschrieben wird, dann siehst du vielleicht mehr.
hab jetzt folgendes in die .htaccess gepackt:
php_value error_log error.log

log_errors einzuschalten empfiehlt sich auch noch. Da das ein Flag ist, ist das mit php_flag log_errors on einzuschalten.

Lo!

[Karl Heinz]

log_errors einzuschalten empfiehlt sich auch noch. Da das ein Flag ist, ist das mit php_flag log_errors on einzuschalten.

Hab das jetzt auch so in die .htaccess Datei gepackt, wie Du es gesagt hast. Nun tritt wieder ein ganz anderer Fehler auf:

Fatal error: Uncaught exception 'Exception' with message 'result is not an object' in /www/htdocs/w00a53e4/vtigercrm/include/database/PearDatabase.php:789 Stack trace: #0 /www/htdocs/w00a53e4/vtigercrm/index.php(120): PearDatabase->query_result(false, 0, 'current_version') #1 {main} thrown in /www/htdocs/w00a53e4/vtigercrm/include/database/PearDatabase.php on line 789

Ich blick da echt nichtmehr durch :-(, verusch jetzt schon seit ein paar Tagen das CRM zu installieren.

Was hat denn diesr Fehler nun wieder zu sagen?

[dedlfix]

Hi!

Fatal error: Uncaught exception 'Exception' with message 'result is not an object' in /www/htdocs/w00a53e4/vtigercrm/include/database/PearDatabase.php:789 Stack trace: #0 /www/htdocs/w00a53e4/vtigercrm/index.php(120): PearDatabase->query_result(false, 0, 'current_version') #1 {main} thrown in /www/htdocs/w00a53e4/vtigercrm/include/database/PearDatabase.php on line 789
Was hat denn diesr Fehler nun wieder zu sagen?

Nun, da scheint eine Datenbankabfrage fehlgeschlagen zu sein. Das Programm erwartet anscheinend ein Result-Objekt, bekommt aber keins. Typischerweise ist das Ergebnis im Fehlerfall false, und das ist ja kein Objekt. Das Script fängt diesen Fall nicht ab. Wenn du nicht weißt, wie man da Debugging betreibt, wende dich an den Hersteller.

Lo!