Jump to content

olf-peter

Members
  • Content Count

    19
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral
  1. Hi Powie, aktuell wird auf Heise.de dringend dazu geraten in der php.ini den Schlüssel allow_url_fopen auf "Off" zu setzen. Leider verwendet wohl sshcheck die Funktion fopen in Verbindung mit einer externen URL. PCheck meldet seither alle überwachten Server "NOTOK". Sobald in der php.ini der Wert auf "On" gesetzt wird sind wieder alle Server "OK". Siehst du eine Alternative oder einen Workaround?
  2. Argl, Thomas - sorry, das ich deine Zeit beansprucht habe. Manchmal sieht man den Wald vor lauter Bäumen nicht. Bei der Neuinstallation hab ich doch tatsächlich vergessen die Referenzserver in der config.inc.php einzutragen Peinlich, peinlich. Sorry. Es funktioniert jetzt wundenbar.
  3. Hab ich gemacht - gleiches Ergebnis. Weiterer Test: Alle Checker gelöscht - gleiches Ergebnis. Ratlos....
  4. Moin Thomas, auf einem meiner Server läuft PScript einwandfrei: Content-type: text/html X-Powered-By: PHP/4.3.1 PCHECK Prüfung startet Prüfe Referenzserver 1 Prüfe Referenzserver 2 Referenzserver OK - Testbeginn Zu prüfende Services: 1 Prüfe s2.nbg12.de - OK auf einem neu eingerichteten Server meldet sshcheck das der Referenzserver 1 offline ist: Content-type: text/html X-Powered-By: PHP/4.3.3 Set-Cookie: PHPSESSID=08fefea849852e35c9a3e9c103898749; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check
  5. Du musst sshcheck von php ausführen lassen, z.B. /usr/bin/php /usr/bin/sshcheck
  6. Ist seit einigen tagen drin und scheint keine Probleme zu machen. Ich teste mal weiter. Danke
  7. Hallo Thomas, konntest du etwas entdecken? Gruß Olf
  8. Kann ich noch nicht so ganz nachvollziehen. Die Zeiten sind sogar auf dem gleichen Server unterschiedlich: Server: s1 (von pscript.de überwacht - public) 01.03.2004, 00:30:02 OK 01.03.2004, 00:18:11 NOTOK 25.02.2004, 06:15:06 OK 25.02.2004, 06:03:16 NOTOK Server: s1 (von pscript.de überwacht - private) 01.03.2004, 22:45:02 OK 01.03.2004, 22:33:11 NOTOK 24.02.2004, 14:15:08 OK Server s1 (von s2 überwacht) 03.03.2004, 10:20:08 OK 03.03.2004, 10:13:18 NOTOK 29.02.2004, 18:40:12 OK 29.02.2004, 18:33:26 NOTOK 26.02.2004, 18:05:56 OK
  9. PCheck (sshcheck) läuft bei mir alle 10 Minuten durch Aufruf via Cron. Ab und an kommt es zu einem falschen Alarm (NOTOK) obwohl der überwachte Server und Dienst definitiv erreichbar war. Getestet wurde der http-Aufruf (File mit \"Success\") und Ping. Beide Testarten bringend as gleiche Problem. Auffällig dabei ist, dass PCheck bzw. sshcheck bei den \"Fehlalarmen\" erstaunlich lange Laufzeit zu haben scheint (> 3 Minuten). Ich vermute daher irgendeinen Timeout-Fehler oder ähnliches. Beispiel: Das Script läuft um: 10:00 Uhr 10:10 Uhr 10:20 Uhr 10:30 Uhr 10:40 Uhr 10:50 U
  10. Ich hatte sshcheck in ein anderes Verzeichnis verschoben. Als ich es danach wie oben beschrieben aufgerufen habe lief es einwandfrei.
  11. Komisch - der qualifizierte Aufruf /usr/bin/php /pfad/zum/Script/sshcheck läuft einwandfrei. [Ratlos] php sshcheck bringt den Fehler. @Powie besten Dank!
  12. Powie, das wäre klasse. Wie kann ich das wieder gutmachen?
  13. Das wäre natürlich klasse. Ich meine derzeit ist 4.3.1 auf dem Rechner. Meinst du das funktioniert dann?
  14. Das sieht fast so aus Das Problem ist, dass ich PHP nicht selbst compiliert habe sondern als Binary-RPM von der SuSE CD installiert habe. Ich ahb mir auch schon die Finger wund gesucht bei rpmseek.com ob es ein RPM für SuSE gibt welches auch in der Shell auszuführen ist. Bislang nichts. Im Compilieren bin ich leider nicht der Meister
  15. Ja, ich denke auch, dass es nicht an sshcheck liegt sondern daran, dass PHP nicht direkt aufgerufen werden kann. Das ganze allerdings auf zwei Rechnern in Standardinstallation PHP (als Modul für Apache) in SuSE 8.2. Somit denke ich, dass noch mehr User das Problem bekommen werden. Aus meiner Sicht ist die Kernaussage der Meldung: Security Alert! The PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directiv
×
×
  • Create New...