nicht angemeldet
Struppi
Struppi
Patrick Andrieu
Patrick Andrieu
Patrick Andrieu
Patrick Andrieu
Patrick Andrieu
Hallo,
gibt es eine Möglichkeit, ein Perl-Programm (cgi) anzuhalten, wenn eine bestimmte Variable geändert wird oder aber in einem log anzuzeigen, wo sie geändert wurde?
Danke
Gisele
gibt es eine Möglichkeit, ein Perl-Programm (cgi) anzuhalten, wenn eine bestimmte Variable geändert wird oder aber in einem log anzuzeigen, wo sie geändert wurde?
Geht's vielleicht ein bischen konkreter?
So wie du es beschreibst fällt mir nur der Debugger der ActiveState IDE ein
Struppi.
gibt es eine Möglichkeit, ein Perl-Programm (cgi) anzuhalten, wenn eine bestimmte Variable geändert wird oder aber in einem log anzuzeigen, wo sie geändert wurde?
Geht's vielleicht ein bischen konkreter?
Weiss nicht, wie ich es konkreter formulieren soll?
Eine Variable kann an zig Stellen geändert werden. Ich könnte dann allen Stellen den aktuellen Wert ausgeben oder halt schlauer: Das System gibt nur an der Stelle den Wert (und Programm-Zeile) aus, an der er geändert wurde.
Geht's vielleicht ein bischen konkreter?
Weiss nicht, wie ich es konkreter formulieren soll?
Eine Variable kann an zig Stellen geändert werden. Ich könnte dann allen Stellen den aktuellen Wert ausgeben oder halt schlauer: Das System gibt nur an der Stelle den Wert (und Programm-Zeile) aus, an der er geändert wurde.
An sich ist sowas nicht vorhesehen, die Frage ist, warum brauchst du sowas?
Der einzige Weg der dir bliebe ist, wie Alexander schon sagte, mit tie, damit kannst du Werte beobachten, aber soweit ich weiß nicht, wo die Änderung erfolgt.
Struppi.
An sich ist sowas nicht vorhesehen, die Frage ist, warum brauchst du sowas?
Der einzige Weg der dir bliebe ist, wie Alexander schon sagte, mit tie,
TIMTOWTDI: Hook::WrapSub kann sich vor und hinter Funktionsaufrufe einklinken, man kann eine gefakte CGI-Umgebung aufbauen (QUERY_STRING und ein paar andere Variablen im Environment setzen) und den Debugger benutzen, TCP-Connection zu einem primitiven Chat-Server aufmachen und debug-Statements in die TCP-Connection schreiben, ....
damit kannst du Werte beobachten, aber soweit ich weiß nicht, wo die Änderung erfolgt.
caller() innerhalb von STORE() aufrufen.
Ich habe den Verdacht, dass ein CGI-Script ohne -T, ohne -w, ohne use strict, ohne use CGI debuggt werden soll.
Erste Regel bei Perl-Problemen: use strict und -w einschalten. Diagnose-Ausgaben lesen, bei CGIs typischerweise im Error-Log des Webservers. Alle von strict gemeldeten Probleme beheben, erst dann nach dem eigentlichen Fehler suchen, wenn das Ausmisten nach use strict ihn nicht schon beseitigt hat.
CGIs ohne -T laufen zu lassen ist hart am Rand der Behilfe zur Datensabotage. Wer dann auch noch versucht, die CGI-Spec selbst zu implementieren (typisches Symptom: Zugriff auf $ENV{'QUERY_STRING'} im Programmtext), statt die bewährte und getestete CGI-Library zu benutzen, gehört geteert und gefedert.
Alexander
An sich ist sowas nicht vorhesehen, die Frage ist, warum brauchst du sowas?
Wenn man Luxus gewöhnt ist, möchte man halt ungerne darauf verzichten.
Auch das SAS-System (Host und PC) cietet da komfortable Hilfen
Ich habe den Verdacht, dass ein CGI-Script ohne -T, ohne -w, ohne use strict, ohne use CGI debuggt werden soll.
Falsch geraten, alles aktiviert.
Erste Regel bei Perl-Problemen: use strict und -w einschalten. Diagnose-Ausgaben lesen, bei CGIs typischerweise im Error-Log des Webservers. Alle von strict gemeldeten Probleme beheben, erst dann nach dem eigentlichen Fehler suchen, wenn das Ausmisten nach use strict ihn nicht schon beseitigt hat.
Fehler sind ja keine vorhanden, also nützt das log überhaupt nichts.
CGIs ohne -T laufen zu lassen ist hart am Rand der Behilfe zur Datensabotage.
siehe oben.
Hallo Alexander!
CGIs ohne -T laufen zu lassen ist hart am Rand der Beihilfe zur Datensabotage.
Wenn sie "mit" erstmal "laufen" würden...
---------------------------------------------
#!/usr/bin/perl -T
use CGI::Carp qw(fatalsToBrowser);
use strict;
use warnings;
use CGI qw(header);
my $str = "Tainted love!";
print header(-type => 'text/html');
print "$str\n";
---------------------------------------------
Viele Grüße aus Frankfurt/Main,
Patrick
CGIs ohne -T laufen zu lassen ist hart am Rand der Beihilfe zur Datensabotage.
Wenn sie "mit" erstmal "laufen" würden...
Am Script selbst gibt es eigentlich nichts auszusetzen, offensichtlich bringt die Kombination mit der installierten Perl-Version und der Webserver-Umgebung Perls Paranoia zum Ausbruch. Was steht im Error-Log? mod_perl aktiv? Ausgabe von perl -V?
Alexander
Hallo Alexander!
Am Script selbst gibt es eigentlich nichts auszusetzen, offensichtlich bringt die Kombination mit der installierten Perl-Version
Perl-Version: 5.006001
und der Webserver-Umgebung
Apache/1.3.33 (Unix) auf Debian-Linux.
Was steht im Error-Log?
Schön wär's, wenn ich Zugang zu einer solchen hätte. Anscheinend hält sie 1und1 für seine Kunden schön versteckt, denn ich habe zwar ein Verzeichnis /logs mit den in -sach ich mal- wöchentlichen .gz-Files zusammengefassten täglichen access_log-Dateien, sogar mail.log-Dateien über die "Arbeiten" von sendmail, ftp-log-Dateien - aber keinerlei Error-Log! Und das in einem "Business _Pro_" genannten Paket...
mod_perl aktiv?
Wie kann ich das überprüfen?
Ausgabe von perl -V?
?
Sobald ich das -T aus der Shebang wegnehme, bekomme ich die Ausgabe aus print. Mit -T greift noch nicht mal fatalsToBrowser, so dass ich nicht sehen kann, was Perl nicht passt.
Viele Grüße aus Frankfurt/Main,
Patrick
Perl-Version: 5.006001
Ui! Mottenkiste! Das wurde am 8. April 2001 (zweitausendundeins) released.
und der Webserver-Umgebung
Apache/1.3.33 (Unix) auf Debian-Linux.
"Da sprach der alte Häuptling der Indianer ..." ;-)
Was steht im Error-Log?
Schön wär's, wenn ich Zugang zu einer solchen hätte. Anscheinend hält sie 1und1 für seine Kunden schön versteckt, denn ich habe zwar ein Verzeichnis /logs mit den in -sach ich mal- wöchentlichen .gz-Files zusammengefassten täglichen access_log-Dateien, sogar mail.log-Dateien über die "Arbeiten" von sendmail, ftp-log-Dateien - aber keinerlei Error-Log! Und das in einem "Business _Pro_" genannten Paket...
Im 1&1-Controlcenter gibt es zwei Utilities "Perl-Syntax-Checker" und "CGI-Ausgabe-Monitor", vielleicht helfen die Dir weiter. Letzterer sieht vielversprechend aus, ich will jetzt aber nicht auf dem Firmenwebseiten meines Arbeitgebers rumtesten.
mod_perl aktiv?
Wie kann ich das überprüfen?
$ENV{'MOD_PERL'} existiert, für mod_perl2 wäre $ENV{'MOD_PERL_API_VERSION'} auf 2 gesetzt (aber der alte Indianer kann nur MOD_PERL 1.x)
Ausgabe von perl -V?
?
Im 1&1 CC einen ssh-Zugang aktivieren und perl -V ausführen.
Sobald ich das -T aus der Shebang wegnehme, bekomme ich die Ausgabe aus print. Mit -T greift noch nicht mal fatalsToBrowser, so dass ich nicht sehen kann, was Perl nicht passt.
Was 1&1 da bloß gebastelt hat...
Irgendwelche bösen Spielchen mit redirect finden bei CGI-Aufrufen übrigens auch noch statt. Data::Dumper->Dump(%ENV) ist sehr aufschlußreich, treibt einem allerdings auch die Tränen der Verzweiflung in die Augen, wenn man es mit der Ausgabe auf einem nicht vergewaltigten Apachen vergleicht.
Alexander
Hallo Alexander!
Perl-Version: 5.006001
Ui! Mottenkiste! Das wurde am 8. April 2001 (zweitausendundeins) released.
Jepp. Zu Hause habe ich 5.8.7 (Active State, da Windows-PC)...
Aber im Vergleich zum vorigen Hoster ist es schon ein Fortschritt. Dort (war: Communitech.net, Kansas, USA) war noch 5.5 wenn nicht älter. Außerdem ist der Rechner bei 1&1 schneller, die Speicherzuweisung anscheinend höher: Vieles »flutscht« nur noch, was beim alten Hoster manchmal richtig Zeit in Anspruch nahm.
[Klammer auf: Übrigens habt Ihr (Du, Struppi und Siechfred) mir den Ansporn geliefert, dass ich meine Kenntnisse nun vertiefe. Allerdings scheinen in »Programmieren mit Perl« einige Sachen veraltet zu sein, dort wird z.B. den Einsatz von Pseudohashes gelobt, was mir beim Testen eine Warnung brachte, dass diese nun »deprecated« seien... Außerdem gibt es Vieles, was ich nicht verstehe, aber das hat weniger mit Perl an sich zu tun als vielmehr damit, dass mir die Grundlagen fehlen, was die Vorgänge innerhalb des Computers angeht usw. Aber egal, schon viel gelernt, viele Ideen, was ich anders machen kann - und die Kapitel, die meinen Kopf zu rauchen bringen, kann ich später noch einmal lesen ;) :Klammer zu]
Apache/1.3.33 (Unix) auf Debian-Linux.
"Da sprach der alte Häuptling der Indianer ..." ;-)
Ja, allerdings scheint der alte Häuptling bei Webhostern noch weit verbreitet zu sein ;)
Für die lokale Umgebung arbeite ich noch mit dem Xitami (nicht lachen, der reicht mir noch vollkommen aus und man lernt, Umgebungsvariablen zu kennen!).
Im 1&1-Controlcenter gibt es zwei Utilities "Perl-Syntax-Checker"
Danke, sehr guter Tipp. Hier das Ergebnis von »tainted_test.pl" ohne -T:
Ergebnis:+ Check succeeded
/../../../../../tainted_test.pl syntax OK
STDOUT OK STDERR OK
und hier mit -T:
Ergebnis:- cgi: File has no correct script header
(should be #! /usr/bin/perl)
(no output)
Das würde bedeuten, dass es mir bei 1&1 nicht möglich ist, Taintchecks vorzunehmen und also doppelte Vorsicht bei Scripts walten lassen muss, die Eingaben von außen bearbeiten? Auf dem Xitami läuft das Script in beiden Varianten, ich könnte solche Programme also zunächst lokal testen. Außerdem läuft es auch auf der Konsole: perl -T tainted_test.pl
und "CGI-Ausgabe-Monitor", vielleicht helfen die Dir weiter. Letzterer sieht vielversprechend aus,
Hm, hier wird keine Variante bemägelt, beide gehen durch. Ich nehme an, dass das Feld "Parameter" für die Angabe eines Query Strings gedacht ist? Jedenfalls brachte hier ein -T auch keine Änderung an den Ergebnissen:
Ergebnis:+ CGI Check succeeded
Content-Type: text/html; charset=ISO-8859-1
Tainted love!
STDOUT OK STDERR OK
ich will jetzt aber nicht auf dem Firmenwebseiten meines Arbeitgebers rumtesten.
Sind dessen Seiten bei 1&1?
mod_perl aktiv?
Wie kann ich das überprüfen?
$ENV{'MOD_PERL'} existiert,
Ausgabe ist leer.
Im 1&1 CC einen ssh-Zugang aktivieren und perl -V ausführen.
Das überprüfe ich später im Laufe des Tages.
Was 1&1 da bloß gebastelt hat...
Irgendwelche bösen Spielchen mit redirect finden bei CGI-Aufrufen übrigens auch noch statt.
Hm ja... Zu Beginn (ich bin erst seit März dort gehostet) konnte ich keine eigene 500er-Seite generiereren lassen, trotz entsprechender Angabe in der .htaccess. Erst ein mehrmaliges Schriftwechsel mit dem Support, mehrmalig deswegen, weil der den Ticket-bearbeitende Mitarbeiter am Ende seines Wissens war und »höher« nachfragen musste, erhielt ich den Tipp, dass ich im jeweiligen Heimverzeichnis meiner Domains je eine error500.html genannte Datei ablegen musste (dann geht es auch ohne Eintrag in der .htaccess, sehr seltsam). Koscher ist die Sache immer noch nicht, denn ich sehe _nie_ den Status 500 in den Logs! Jedes kaputte Script, das die Ausgabe eines 500er Errors verursacht (die Error-Seite wird ausgeliefert), erscheint in den Logs mit einem schönen 200er. Also wird sehr wohl intern da herumgefriemelt, denke ich mal.
Viele Grüße aus Frankfurt/Main,
Patrick
Nachtrag:
und hier mit -T:
Ergebnis:- cgi: File has no correct script header
(should be #! /usr/bin/perl)
(no output)
Diese Meldung kommt auch mit einem simplen -w-Switch in der Shebang - obwohl die Scripts ansonsten problemlos durchlaufen. Daher sagt obiges leider nicht viel aus...
Viele Grüße aus Frankfurt/Main,
Patrick
perl -V
Im 1&1 CC einen ssh-Zugang aktivieren und perl -V ausführen.
Das überprüfe ich später im Laufe des Tages.
Habe die Ausgabe jetzt in einer Textdatei gespeichert. Welche Infos sind denn relevant?
Viele Grüße aus Frankfurt/Main,
Patrick
perl -V
Im 1&1 CC einen ssh-Zugang aktivieren und perl -V ausführen.
Das überprüfe ich später im Laufe des Tages.Habe die Ausgabe jetzt in einer Textdatei gespeichert. Welche Infos sind denn relevant?
Alle ;-)
Alexander
Hallo Alexander!
[...] Ausgabe perl -V
Alle ;-)
Hm, soll ich wirklich die ganzen Interna hier posten? Ich meine, ich habe keine Probleme, nackt herum zu laufen - aber nur in den eigenen vier Wänden[1] ;)
[1] manchmal auch in meiner Heimat am Strand, aber dieses Jahr fahre ich nicht hin ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Jepp. Zu Hause habe ich 5.8.7 (Active State, da Windows-PC)...
Auch nicht das neueste, aber schonmal ganz gut.
»Programmieren mit Perl« ... veraltet
Im Zweifel gilt das, was Perl an Doku mitbringt, und wenn die Übersicht ganz weg ist, helfen gerne auch mal die Perlmonks weiter.
Apache/1.3.33 (Unix) auf Debian-Linux.
"Da sprach der alte Häuptling der Indianer ..." ;-)Ja, allerdings scheint der alte Häuptling bei Webhostern noch weit verbreitet zu sein ;)
Nicht nur bei denen. Die 1.3er-Serie ist einfach saustabil und bewährt. Wobei bei Debian dazu kommt, dass Debian jede Menge Bugfixes backportet, ohne die Versionsnummer zu erhöhen.
Im 1&1-Controlcenter gibt es zwei Utilities "Perl-Syntax-Checker"
Danke, sehr guter Tipp. Hier das Ergebnis von »tainted_test.pl" ohne -T:
Ergebnis:+ Check succeeded
/../../../../../tainted_test.pl syntax OK
STDOUT OK STDERR OKund hier mit -T:
Ergebnis:- cgi: File has no correct script header
(should be #! /usr/bin/perl)
(no output)Das würde bedeuten, dass es mir bei 1&1 nicht möglich ist, Taintchecks vorzunehmen und also doppelte Vorsicht bei Scripts walten lassen muss, die Eingaben von außen bearbeiten?
Das bedeutet, dass man die guten Sicherheitsstiefel mit den Stahlkappen anzieht und sich bei 1&1 a***tretend die Support-Hierarchie hochkämpft. :-(
und "CGI-Ausgabe-Monitor", vielleicht helfen die Dir weiter. Letzterer sieht vielversprechend aus,
Hm, hier wird keine Variante bemägelt, beide gehen durch. Ich nehme an, dass das Feld "Parameter" für die Angabe eines Query Strings gedacht ist?
Keine Ahnung, ich hab die Tools noch nie benutzt.
Jedenfalls brachte hier ein -T auch keine Änderung an den Ergebnissen:
Ergebnis:+ CGI Check succeeded
Content-Type: text/html; charset=ISO-8859-1Tainted love!
STDOUT OK STDERR OKich will jetzt aber nicht auf dem Firmenwebseiten meines Arbeitgebers rumtesten.
Sind dessen Seiten bei 1&1?
Ja, mit genau dem gleichen Paket.
mod_perl aktiv?
Wie kann ich das überprüfen?
$ENV{'MOD_PERL'} existiert,Ausgabe ist leer.
Leer, undefiniert oder nicht vorhanden?
(!length, !defined, !exists)
Was 1&1 da bloß gebastelt hat...
Irgendwelche bösen Spielchen mit redirect finden bei CGI-Aufrufen übrigens auch noch statt.Hm ja... Zu Beginn (ich bin erst seit März dort gehostet) konnte ich keine eigene 500er-Seite generiereren lassen, trotz entsprechender Angabe in der .htaccess. Erst ein mehrmaliges Schriftwechsel mit dem Support, [...] Also wird sehr wohl intern da herumgefriemelt, denke ich mal.
Ja, jede Menge. Ich gehe mal davon aus, dass massiv an dem Apachen verändert wurde, um statische Dateien möglichst schnell und resourcenschonend auszuliefern und CGIs möglichst ohne Last und Support-Calls laufen zu lassen. Sehr wahrscheinlich gibt es eine Begrenzung für Zeit und Speicher, und vermutlich wird die CGI-Umgebung erst einmal von einem anderen Prozess vorbereitet.
Installiere Dir mal den Windows-Apachen in 1.3.x (gibts direkt als Binary bei apache.org) und vergleiche die Environments, insbesondere die REDIRECT-Variablen.
Alexander
Hallo Alexander!
5.8.7 (Active State, da Windows-PC)...
Auch nicht das neueste, aber schonmal ganz gut.
Installation Nov 2005. Da gab's hier einen neuen Rechner ;)
»Programmieren mit Perl« ... veraltet
Im Zweifel gilt das, was Perl an Doku mitbringt
Sieht so aus, als wäre alles in der Doku, was vom Tom Christiansen ist, auch im Buch wieder zu finden - teilweise haargenau die gleichen Beispiele... Ich kenne Fred Feuerstein jetzt besser, denn als es damals im Fernsehen lief ;)
Das bedeutet, dass man die guten Sicherheitsstiefel mit den Stahlkappen anzieht und sich bei 1&1 a***tretend die Support-Hierarchie hochkämpft. :-(
Hm... dann versuche ich, lieber selber für eine unbefleckte Empfängnis von außen kommender Daten zu sorgen ;)
Ja, mit genau dem gleichen Paket.
Sieh einer an. Nun ja, der Vertrag läuft 2 Jahre. Wird wahrscheinlich auch dabei bleiben... Mal sehen, was es in 1 3/4 Jahr für Angebote (wahrscheinlich woanders) gibt ;)
Sehr wahrscheinlich gibt es eine Begrenzung für Zeit und Speicher, und vermutlich wird die CGI-Umgebung erst einmal von einem anderen Prozess vorbereitet.
Als ich zu Beginn des Hostings den Verdacht hatte, dass irgendeine Prozesse mir den Speicher fressen (dabei war eine Sub in einem meiner Scripts buggy, der Fehler war jedoch nur hin und wieder reproduzierbar), sagte der Ticket-Mitarbeiter irgendwas von 32MB Speicherbegrenzung, die würde ich im Normalfall nie brauchen.
Installiere Dir mal den Windows-Apachen in 1.3.x (gibts direkt als Binary bei apache.org) und vergleiche die Environments, insbesondere die REDIRECT-Variablen.
Ja, ist überfällig. Habe nur bisher um Apache einen großen Bogen gemacht, und lieber meine uralte Xitami-Installation beigebracht, SSI zu implementieren ;)
Aber ich sehe ein, der Schritt wird irgendwann nötig sein ;)
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Alexander!
5.8.7 (Active State, da Windows-PC)...
Auch nicht das neueste, aber schonmal ganz gut.Installation Nov 2005. Da gab's hier einen neuen Rechner ;)
»Programmieren mit Perl« ... veraltet
Im Zweifel gilt das, was Perl an Doku mitbringtSieht so aus, als wäre alles in der Doku, was vom Tom Christiansen ist, auch im Buch wieder zu finden - teilweise haargenau die gleichen Beispiele...
Wen wundert's ...
Der absolute Hammer ist "Perl in a Nutshell", was bis auf geringfügige Überarbeitung die gedruckte und gebundene Version der Perl-Doku ist. Wenigstens kann man das auch als Buch mit CD kaufen, auf der noch ein paar andere, bessere Perl-Bücher als HTML mit drauf sind.
Als ich zu Beginn des Hostings den Verdacht hatte, dass irgendeine Prozesse mir den Speicher fressen (dabei war eine Sub in einem meiner Scripts buggy, der Fehler war jedoch nur hin und wieder reproduzierbar), sagte der Ticket-Mitarbeiter irgendwas von 32MB Speicherbegrenzung, die würde ich im Normalfall nie brauchen.
Eine sehr optimistische Aussage. Das Projektmanagement-Tool, das ich für meinen vorherigen Arbeitgeber geschrieben habe, verbrennt auch locker mal 100 bis 200 MB RAM, wenn es größere Arbeiten zu erledigen hat. Das wird aber auch nicht bei 1&1 gehostet, sondern auf dedizierten Servern beim Kunden.
Installiere Dir mal den Windows-Apachen in 1.3.x (gibts direkt als Binary bei apache.org) und vergleiche die Environments, insbesondere die REDIRECT-Variablen.
Ja, ist überfällig. Habe nur bisher um Apache einen großen Bogen gemacht, und lieber meine uralte Xitami-Installation beigebracht, SSI zu implementieren ;)
Aber ich sehe ein, der Schritt wird irgendwann nötig sein ;)
Dann aber vielleicht besser den 2.0, der bringt auch SSL mit. Den 1.3er nur als Vergleich zu 1&1, SSL gibt's dafür nur als 3rd Party und macht immer reichlich Arbeit, entweder für den Compiler oder für die Suchmaschine auf der Jagd nach fertigen, zueinander passenden Compilaten.
Alexander
Hallo Alexander!
Dann aber vielleicht besser den 2.0, der bringt auch SSL mit. Den 1.3er nur als Vergleich zu 1&1, SSL gibt's dafür nur als 3rd Party und macht immer reichlich Arbeit, entweder für den Compiler oder für die Suchmaschine auf der Jagd nach fertigen, zueinander passenden Compilaten.
Danke für die Tipps, ich werde die Indianer installieren, wenn ich einen neuen Laptop habe (mein alter ist 5 Jahre alt und kränkt sehr und wird bald ersetzt. Da kommt sicher auch eine Linux-Partition drauf, wird also viel Neues für mich sein dabei...)
Bez. den Ausdruck aus "perl -V". Wie unten erwähnt, würde ich ungerne alles posten, was brauchst Du konkret für Infos daraus?
Viele Grüße aus Frankfurt/Main,
Patrick
tie() + entsprechende Klassen
Nur: Wozu soll das gut sein?
Alexander