"Too many open files" ?

[xNeTworKx]

Hi,
Ich würde gerne mal wissen, was im Errorlog diese Meldung bedeutet ?
[client xxx.xxx.xxx.xxx] (24)Too many open files: couldn't spawn child process: /home/pfad/zum/aufgeruften/script.

Jetzt wird es allmälich lästig, da dieser Fehler jetzt schon wöchentlich auftritt, und plötzlich keine Perl Scripts mehr funktionieren. Nur HTML wird angezeigt, und sobald ich ein Perl Script aufrufe : Internal Server Error.
 (Es kann nur mit der Schlampigkeit meines Providers zu tun haben, weil dieser Fehler tritt immer plötzlich von einer Sekunde auf die nächste auf.

[Fabian Transchel]

moin,
ich würde sagen das es ein fehler in diversen scripten sein muss, die am ende nach einem file-aufruf nicht das geöffnete file schließen, wie du sagtest, schlampige scripte.
der server hält die files halt offen und deswegen ist der arbeitsspeicher irgendwann schlichtweg _voll_
wan dieser fehler auftritt ist wie du sagtest rein zufällig, nämlich immer wenn mal wieder 'genug' files offen sind

Fabian

[xNeTworKx]

Hallo,
meine Scripte sind alle eigentlich sauber programmiert. Bei mir kommt es eigentlich nicht vor das ich ein File offen lasse. Kann es für diesen Fehler noch irgendwelche Ursachen geben ? Kann es sein, daß andere User( dieses Providers) schlampige Scripte haben, und somit diesen Fehler verursachen, oder geht dieses Problem nur meinen Webspace an ?
(Kann ich mir zwar nicht vorstellen, da doch viele User auf einem Server hosten, oder ?)

[Christoph Zurnieden]

Hallo,

Ich würde gerne mal wissen, was im Errorlog diese Meldung bedeutet ?
[client xxx.xxx.xxx.xxx] (24)Too many open files: couldn't spawn child process: /home/pfad/zum/aufgeruften/script.

Tja, irgendetwas forked da wie wild ;-)

Nein, Scherz beiseite:
Pro Prozess sind nur eine bestimmte Menge offener Dateien zugelassen. Da ich nur anhand der Pfadtrenner ganz grob auf Unix tippen kann, ist folgendes nur dafür und um genau zu sein, auch nur für Linux.

Bei älteren Kerneln ließ sich das (limits.h bzw fs.h) nur durch neukompilieren erhöhen, bei neueren (2.4) ist es das auch so möglich, falls das /proc Dateisystem mit eingebaut wurde.

To raise the maximum file handles and open-inodes the kernel will accept:

echo "32768" > /proc/sys/fs/file-max
echo "65536" > /proc/sys/fs/inode-max

somewhere in your startup.

inode-max sollte 2-3x so groß wie file-max sein.

Für die aktuellen Werte siehe 'ulimit -a' (Geht wahrscheinlich nur via Perls system() o.ä. falls kein Shellzugang vorhanden. Irgendjemand hat mal eine Art Telnet auf diese Weise zusammengbastelt, siehe Selfforums-Archiv)

Nein, stimmt nicht, das ändert ja nichts an der Grenze pro Prozess!

Also folgendes funktioniert unter 2.4

'ulimit -n $OPEN_MAX'

Wobei $OPEN_MAX eine Zahl 2^x sein sollte (z.B.: 2024)

Ich muß Dich aber enttäuschen, sowas geht normalerweise nur durch root.
Wenn auch für normale User: wechsel den Provider!

Jetzt wird es allmälich lästig, da dieser Fehler jetzt schon wöchentlich auftritt, und plötzlich keine Perl Scripts mehr funktionieren. Nur HTML wird angezeigt, und sobald ich ein Perl Script aufrufe : Internal Server Error.

(Es kann nur mit der Schlampigkeit meines Providers zu tun haben, weil dieser Fehler tritt immer plötzlich von einer Sekunde auf die nächste auf.

Ist wahrscheinlich kein Schlampigkeit, sondern Absicht. Irgendwie müssen die begrenzten Resourcen ja mehr oder weniger gerecht verteilt werden ;-)

Aber zumindest weißt Du jetzt, wo Du ansetzen mußt.

BTW: Die meisten mir bekannten Sysadmins trinken übrigens gerne sehr alten Whiskey ;-)

so short

Christoph Zurnieden

[xNeTworKx]

Hallo,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Ist wahrscheinlich kein Schlampigkeit, sondern Absicht. Irgendwie müssen die begrenzten Resourcen ja mehr oder weniger gerecht verteilt werden ;-)

Aber zumindest weißt Du jetzt, wo Du ansetzen mußt.

Ok danke, kann mir jetzt ein ziemlich gutes Bild davon machen, obwohl ich dieses Fachchinesisch nicht 100%ig verstanden habe :-)

[Christoph Zurnieden]

Hallo,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Wenn Du Dir wirklich sicher bist, das alle Deine Scripte i.O. sind, dann ist die Hardware Deines Providers wahrscheinlich wirklich überlastet und ich könnte die Empfehlung zum Wechsel wirklich nur wiederholen.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an Dir liegt!
Es sind einige Perlfreaks hier im Forum, bei Unsicherheiten werden diese evt weiterhelfen können. (Ich kann aber selbstverständlich nicht für sie sprechen)

Ist wahrscheinlich kein Schlampigkeit, sondern Absicht. Irgendwie müssen die begrenzten Resourcen ja mehr oder weniger gerecht verteilt werden ;-)

Aber zumindest weißt Du jetzt, wo Du ansetzen mußt.

Ok danke, kann mir jetzt ein ziemlich gutes Bild davon machen, obwohl ich dieses Fachchinesisch nicht 100%ig verstanden habe :-)

Solltest Du aber, wenn Du Dich mit dem Provider anlegst.
Kann einen Mangel darstellen, der zu beheben ist (oder Geld zurück). Bitte aber vorher genau die AGB lesen. Meist wird das dort ausgeschlossen.

so short

Christoph Zurnieden

[xNeTworKx]

Hi,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Wenn Du Dir wirklich sicher bist, das alle Deine Scripte i.O. sind, dann ist die Hardware Deines Providers wahrscheinlich wirklich überlastet und ich könnte die Empfehlung zum Wechsel wirklich nur wiederholen.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an Dir liegt!

Ich bin mir absolut sicher, daß es nicht an mir liegt, weil nämlich nach diesem Fehler die Systemzeit des Servers nicht mehr richtig funktioniert. Ausserdem passiert das jetzt schön wöchentlich und immer Ende der Woche für ca 1 Stunde, also Donnerstag, Freitag.
Andererseits, was kann man von nicht mal 100 Euro im Jahr erwarten.

Ok danke, kann mir jetzt ein ziemlich gutes Bild davon machen, obwohl ich dieses Fachchinesisch nicht 100%ig verstanden habe :-)

Solltest Du aber, wenn Du Dich mit dem Provider anlegst.
Kann einen Mangel darstellen, der zu beheben ist (oder Geld zurück). Bitte aber vorher genau die AGB lesen. Meist wird das dort ausgeschlossen.

Ich habe das mit dem kernell Dings usw gemeint. Ich verstehe leider nichts von Unix, ausserdem wie kann ich im vorhinein so etwas überhaupt abfragen ? Ich muss doch zuerst beim dem Provider hosten, damit ich das irgenwie abfragen kann, weil ich kann mir nicht vorstellen, daß dieser solche Systemdaten so einfach herausrückt, oder hab ich da jetzt etwas falsch verstanden ?

[Christoph Zurnieden]

Hallo,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Wenn Du Dir wirklich sicher bist, das alle Deine Scripte i.O. sind, dann ist die Hardware Deines Providers wahrscheinlich wirklich überlastet und ich könnte die Empfehlung zum Wechsel wirklich nur wiederholen.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an Dir liegt!

Ich bin mir absolut sicher, daß es nicht an mir liegt, weil nämlich nach diesem Fehler die Systemzeit des Servers nicht mehr richtig funktioniert.

Diese Begründung ist sehr merkwürdig ;-)

Aber davon ab: wenn die Systemzeit danach nicht mehr stimmt, riecht das ein wenig nach Reboot. Nicht sehr schön.

Ausserdem passiert das jetzt schön wöchentlich und immer Ende der Woche für ca 1 Stunde, also Donnerstag, Freitag.

Ende der Woche ist normalerweise auch immer ein höheres Aufkommen.
Könnten aber auch Wartungsarbeiten sein. IMHO ist bei Windows* ein regelmäßiger Reboot nötig.

Andererseits, was kann man von nicht mal 100 Euro im Jahr erwarten.

Kommt darauf an, was geboten wird.

Ok danke, kann mir jetzt ein ziemlich gutes Bild davon machen, obwohl ich dieses Fachchinesisch nicht 100%ig verstanden habe :-)

Solltest Du aber, wenn Du Dich mit dem Provider anlegst.
Kann einen Mangel darstellen, der zu beheben ist (oder Geld zurück). Bitte aber vorher genau die AGB lesen. Meist wird das dort ausgeschlossen.

Ich habe das mit dem kernell Dings usw gemeint. Ich verstehe leider nichts von Unix, ausserdem wie kann ich im vorhinein so etwas überhaupt abfragen ?

Es gibt diverse Tools dafür.

Ansonsten ganz billig ($HOST ist der Hostname z.B.: example.com):

telnet $HOST 80

-bischen-bla-bla-vom-Server-

HEAD  / HTTP/1.0 <ENTER>
Accept: text/html <ENTER><ENTER>

HTTP/1.1 200 OK
Date: Thu, 16 May 2002 16:57:40 GMT
Server: Apache/1.3.6 (Unix)
Last-Modified: Sat, 01 Sep 2001 17:50:03 GMT
ETag: "15602e-45c-3b911fcb"
Accept-Ranges: bytes
Content-Length: 1116
Connection: close
Content-Type: text/html

(Ausgabe ist von meinem lokalem Apachen. BTW: <ENTER> ist die ENTER-Taste, gelle? ;-)

Ich muss doch zuerst beim dem Provider hosten, damit ich das irgenwie abfragen kann, weil ich kann mir nicht vorstellen, daß dieser solche Systemdaten so einfach herausrückt, oder hab ich da jetzt etwas falsch verstanden ?

Diese Systemdaten (OPEN_MAX usw) wahrscheinlich nicht so einfach, da dafür andere Leute zuständig sind.
Aber fragen kost' normalerweise nix, oder? ;-)

so short

Christoph Zurnieden

[xNeTworKx]

Hallo,

Ende der Woche ist normalerweise auch immer ein höheres Aufkommen.
Könnten aber auch Wartungsarbeiten sein. IMHO ist bei Windows* ein regelmäßiger Reboot nötig.

auf einem Windows Server würde ich schon gar nicht hosten :-)

[Der Linke Setzer]

Es gibt diverse Tools dafür.

http://aktuell.de.selfhtml.org/sonst/serverid.htm

[Christian Kruse]

Hoi Christoph,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Wenn Du Dir wirklich sicher bist, das alle Deine Scripte i.O. sind, dann
ist die Hardware Deines Providers wahrscheinlich wirklich überlastet und
ich könnte die Empfehlung zum Wechsel wirklich nur wiederholen.

Naja, der Apache schreibt doch 'Could not spawn child process' -- das heisst,
die Scripte wurden noch gar nicht gestartet. Nein, da ist eine Grenze
erreicht.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an Dir
liegt! Es sind einige Perlfreaks hier im Forum, bei Unsicherheiten werden
diese evt weiterhelfen können. (Ich kann aber selbstverständlich nicht für
sie sprechen)

unsauber geschriebene Scripte koennen es eigentlich nicht sein
(es sei denn, man benutzt mod_perl), denn der Garbage Collector von Perl
schliesst eigentlich alle geoeffneten Ressourcen beim beenden des Scriptes.
Da muesste schon jemand sowas machen wie

while(1) {
  local *DAT;
  open DAT,'<'.$file;
}

Sprich, sehr viele Dateien waehrend eines Durchlaufs oeffnen.

Gruesse,
 CK, auch unzufrieden mit seinem Provider

[Michael Schröpl]

Hi Christian,

Naja, der Apache schreibt doch 'Could not spawn child process'
-- das heisst, die Scripte wurden noch gar nicht gestartet.
Nein, da ist eine Grenze erreicht.

die Frage ist halt, wessen Grenze und warum. Ich tippe mal auf die
Grenze für diesen einen Apache-Teilprozeß. Wer es allerdings war,
der die vielen Filehandles belegt, das festzustellen dürfte nicht
so einfach sein - jedenfalls für einen Benutzer. Als Provider würde
ich mir das access_log aus der fraglichen Zeit ansehen und prüfen,
was die damals gestarteten CGI-Anwendungen so alles tun ... damit
kann man die Verdächtigen wenigstens einschränken, den Schuldigen
zu finden dürfte allerdings nicht einfach sein.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht
doch an Dir liegt!

Eben. Es kann auch das eigene Skript sein, das vorher ein paar
hundert mal gestartet wurde und irgendwelche Leichen hinterlassen
hat.
Gerade im Kontext von mod_perl etc. könnte ich mir solche Effekte
durchaus vorstellen, weil da mit CGI-Prozeßende ggf. nicht auto-
matisch alle Ressourcen freigegeben werden - da wäre eine unsaubere
Programmierung ggf. besonders schlimm.

Viele Grüße
      Michael
(der diesen Effekt vor zwei Wochen auf dem Server seiner Domain auch
 einmal hatte)

[xNeTworKx]

Hallo alle zusammen,
jetzt funktioniert SSI auf einmal nicht : [an error occurred while processing this directive], aber das kenn ich schon, das kommt immer nachdem dieser Fehler kommt, den ich vorher beschrieben habe (bis nächste Woche ist wenigstens Ruhe :) ) Übrigens wie ist das jetzt eigentlich, wenn ein User auf dem Server (wieviele User teilen sich eigentlich einen Server? ) ein fehlerhaftes Script hat, reisst er den ganzen Server mit, stimmt doch oder ?(oder gibt es da Sicherheitsvorkehrungen? )

[Christoph Zurnieden]

Hallo,

jetzt funktioniert SSI auf einmal nicht : [an error occurred while processing this directive], aber das kenn ich schon, das kommt immer nachdem dieser Fehler kommt, den ich vorher beschrieben habe (bis nächste Woche ist wenigstens Ruhe :) )

Einen gewissen Galgenhumor kann man Dir ja nicht absprechen ;-)

Übrigens wie ist das jetzt eigentlich, wenn ein User auf dem Server (wieviele User teilen sich eigentlich einen Server? )

So viele, wie draufpassen.
Nein, ist ernstgemeint.

ein fehlerhaftes Script hat, reisst er den ganzen Server mit, stimmt doch oder ?(oder gibt es da Sicherheitsvorkehrungen? )

Also:
Bei einem ordentlich geführtem Server (dies wird also eine rein theoretische Abhandlung ;-) sind alle verfügbaren Resourcen, als da wären: Speicherplatz (RAM und Platte) und Prozessorzeit, gleichmäßig auf alle User aufgeteilt (Oder auch je nach Geldbeutel ;-). Falls nun da einer der Prozesse eines oder mehrerer User Amok läuft, so geschieht das nur in den Grenzen de[sr] User[s]. Sollte sich dadurch ein User selber aussperren, so sind vorher (! ;-)  entsprechende Maßnahmen zu treffen, daß ausufernde Prozesse nach einer gewissen Zeit/Raumbeanspruchung automatisch abgeschossen werden. Bei Systemen mit einem Superuser kann dies auch noch eben jener von Hand tun.
Bei den meisten gängigen Systemen ist als letzter Notnagel eben jene Grenze der maximal offenen Dateien pro Prozess gesetzt, sodaß auch auf schlecht geführten Servern (Der Mehrheit also ;-) nichts Gravierendes passieren können dürfte.

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hallo,

Wenn auch für normale User: wechsel den Provider!

Das hab ich mehr als vor. Ich bin jetzt wirklich schon sehr verärgert.

Wenn Du Dir wirklich sicher bist, das alle Deine Scripte i.O. sind, dann
ist die Hardware Deines Providers wahrscheinlich wirklich überlastet und
ich könnte die Empfehlung zum Wechsel wirklich nur wiederholen.

Naja, der Apache schreibt doch 'Could not spawn child process' -- das heisst,
die Scripte wurden noch gar nicht gestartet.

Wie der Michael so schön bemerkte: er kann nur keine _weiteren_ mehr starten.
Wieviele schon offen sind geht daraus nicht hervor.

Nein, da ist eine Grenze
erreicht.

Die ist aber einstellbar und hängt, zumindest theoretisch, nur von der Hardware ab. Wenn die Hardware des Providers es also nicht mehr schafft, den Wochenendverkehr geregelt zu bekommen ...

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an Dir
liegt! Es sind einige Perlfreaks hier im Forum, bei Unsicherheiten werden
diese evt weiterhelfen können. (Ich kann aber selbstverständlich nicht für
sie sprechen)

unsauber geschriebene Scripte koennen es eigentlich nicht sein
(es sei denn, man benutzt mod_perl),

Das ist aber leider bei den meisten Providern Gang und Gäbe.
Zumindest die, die mir so unter die Finger gekommen sind.

denn der Garbage Collector von Perl
schliesst eigentlich alle geoeffneten Ressourcen beim beenden des Scriptes.
Da muesste schon jemand sowas machen wie

while(1) {
  local *DAT;
  open DAT,'<'.$file;
}

Sprich, sehr viele Dateien waehrend eines Durchlaufs oeffnen.

Das kann bei den Default(?)grenzen von 1024 aber schnell mal passieren. Irgendwo in einem Loop mal eine Tempdatei angelegt und nicht darauf geachtet, das durch den Loop die Datei mehrmals angelegt wird. Läßt sich schlecht feststellen, wenn die Datei nach Benutzung direkt gelöscht wird, dann such mal.

(Ja, hast' Recht, selber erlebt. Über die Einzelheiten breiten wir mal lieber den gnädigen Mantel des Schweigens ;-)

Gruesse,
CK, auch unzufrieden mit seinem Provider

Woran liegt's wer ist es? (Frage ignorieren, falls Billigpreis in Gefahr)

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Wie der Michael so schön bemerkte: er kann nur keine _weiteren_ mehr starten.
Wieviele schon offen sind geht daraus nicht hervor.

Ok, stimmt :-)

Nein, da ist eine Grenze
erreicht.

Die ist aber einstellbar und hängt, zumindest theoretisch, nur von der
Hardware ab.

Was anderes habe ich ja auch nicht gesagt :-)

Wenn die Hardware des Providers es also nicht mehr schafft, den
Wochenendverkehr geregelt zu bekommen ...

.... wirds Zeit fuer ein Update. Jau.

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an
Dir liegt! Es sind einige Perlfreaks hier im Forum, bei
Unsicherheiten werden diese evt weiterhelfen können. (Ich kann aber
selbstverständlich nicht für sie sprechen)

unsauber geschriebene Scripte koennen es eigentlich nicht sein
(es sei denn, man benutzt mod_perl),

Das ist aber leider bei den meisten Providern Gang und Gäbe.

Naja, so leider finde ich das gar nicht. Es erfordert halt einfach eine
Konsequent saubere Programmierung -- nichts anderes als Threadsafeness (geiles
Wort, leider bestimmt falsch ;-)

Zumindest die, die mir so unter die Finger gekommen sind.

Meiner leider nicht.

Das kann bei den Default(?)grenzen von 1024 aber schnell mal passieren.

Naja, also eigentlich ja nicht. Und IMHO liegen die Grenzen auch hoeher, aber
das ist natuerlich in hoechstem Masse systemabhaengig.

Gruesse,
CK, auch unzufrieden mit seinem Provider

Woran liegt's wer ist es? (Frage ignorieren, falls Billigpreis in Gefahr)

Ach, ich weiss auch nicht. Der ISP war anfangs recht gut, ich hatte sehr viele
Freiheiten. Aber jetzt... ich hab nichtmal mehr ein eigenes Errorlog. Und dann
bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der ISP ist
all- -- den Rest musst du dir selber suchen ;-))

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Wenn die Hardware des Providers es also nicht mehr schafft, den
Wochenendverkehr geregelt zu bekommen ...

.... wirds Zeit fuer ein Update. Jau.

Inklusive der Stromversorgung ;-)

Aber sei Dir vorher wirklich vollkommen sicher, daß es nicht doch an
Dir liegt! Es sind einige Perlfreaks hier im Forum, bei
Unsicherheiten werden diese evt weiterhelfen können. (Ich kann aber
selbstverständlich nicht für sie sprechen)

unsauber geschriebene Scripte koennen es eigentlich nicht sein
(es sei denn, man benutzt mod_perl),

Das ist aber leider bei den meisten Providern Gang und Gäbe.

Naja, so leider finde ich das gar nicht. Es erfordert halt einfach eine
Konsequent saubere Programmierung -- nichts anderes als Threadsafeness (geiles
Wort, leider bestimmt falsch ;-)

Ich kenne auch nichts anderes als "threadsafe" (Man könnte es auch übersetzen, aber "einfädelsicher"? ;-)

Aber (für's Archiv) was genau heißt den Threadsafe in Perl?
Was gibt es da zu beachten?
In C weiß ich es, aber in Perl?

Zumindest die, die mir so unter die Finger gekommen sind.

Meiner leider nicht.

Wie sieht es denn da aus?

Das kann bei den Default(?)grenzen von 1024 aber schnell mal passieren.

Naja, also eigentlich ja nicht. Und IMHO liegen die Grenzen auch hoeher, aber
das ist natuerlich in hoechstem Masse systemabhaengig.

Nein, gottseidank nicht, sie sind einstellungsabhängig.
(Aber ich meine 1024 gelesen zu haben. Muß aber auch zugeben, jetzt zu faul zum Nachschauen zu sein ;-)

Obergrenze ist IMHO sizeof(int). Also zumindest das ist damit systemabhängig ;-)

Gruesse,
CK, auch unzufrieden mit seinem Provider

Woran liegt's wer ist es? (Frage ignorieren, falls Billigpreis in Gefahr)

Ach, ich weiss auch nicht. Der ISP war anfangs recht gut, ich hatte sehr viele
Freiheiten. Aber jetzt... ich hab nichtmal mehr ein eigenes Errorlog. Und dann

Noch nicht einmal einen Errorlog?
Na, _das_ ist aber ziemlich hart!

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der ISP ist
all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

Wenn's nur nicht immer so ein Aufwand wäre, nicht? KK stellen, neuen Hoster suchen, da alles finden und wahrscheinlich auch noch dies und das portieren usw.
Tja, ich befürchte, die wissen darum und nehmen sich entsprechend alles raus.

so short

Christoph Zurnieden

[Christian Kruse]

Moin!

Naja, so leider finde ich das gar nicht. Es erfordert halt einfach eine Konsequent saubere Programmierung -- nichts anderes als Threadsafeness (geiles Wort, leider bestimmt falsch ;-)

Ich kenne auch nichts anderes als "threadsafe" (Man könnte es auch übersetzen, aber "einfädelsicher"? ;-)

Naja, aber threadsafeness? Ich bin fast sicher, es muss threadsafety heissen ;-)

Aber (für's Archiv) was genau heißt den Threadsafe in Perl? Was gibt es da zu beachten?

Naja. Das ist bei mod_perl etwas komplizierter. Generell kann man IMHO sagen:

• globale Variablen immer initialisieren! Man kann nie wissen, was   da nicht schon drin steht.

• Niemals Konstrukte wie

use strict;

my $counter = 0;

addone();     addone();

sub addone {       $counter++;     }

Benutzen. In 'sub addone' ist bei mod_perl nicht die lexikalisierte   Variable '$counter' gemeint, sondern die globale Variable   '$counter'. Das haengt damit zusammen, wie mod_perl ein Script   sieht. Denn bevor der Code ausgefuehrt wird, macht mod_perl daraus

package Apache::ROOT::verzeichnis::zum::script;    use Apache qw(exit);    sub handler {       use strict;

my $counter = 0;

addone();       addone();

sub addone {         $counter++;       }    }

Aus jedem Script wird ein Modul mit nur einer Sub (handler).   Daraus folgt, dass man an Subroutinen grundsaetzlich alles   uebergeben sollte, als Funktionsargumente. Ausserdem muss man   natuerlich grundsaetzlich alle Variablen initialisieren!

• Dann gilt: Scripte, die auf mod_perl laufen sollen, grundsaetzlich   sehr gut durchtesten. Es kann sehr gut sein, dass ein   Fehlerverhalten erst nach einer gewissen Zeit auftritt. Das liegt   daran, dass der Apache forked: in jedem Apache-Prozess wird das   Script neu geladen. Und weil der Apache den Child, der den Request   bearbeiten soll, nach dem Round-Robin-Verfahren aussucht, kann es   durchaus sein, dass ein Fehlverhalten erst nach 40 oder 50   Testlaeufen zum Vorschein kommt. Ich wuerde empfehlen, bei dem   eigenen Testserver die Anzahl der Childs auf nur sehr wenige   einzuschraenken. Die Alternative ist natuerlich, dem Apachen   komplett zu verbieten zu forken. Das erreicht man, indem man ihn   mit 'httpd -x' aufruft.

• Man sollte niemals $^W abschalten. mod_perl schreibt alle Warnings   ins Errorlog, ein unersetzbares Werkzeug.

• Man sollte aufpassen mit exit()-Aufrufen. Das kann ins Auge gehen   und dazu fuehren, dass der Apache-Prozess beendet wird. Lieber   Apache::exit() benutzen.

• Ich kann es nie oft genug wiederholen: vorsicht mit globalen   Variablen! Globale Variablen erhalten ihren Wert fuer die gesamte   Lebensdauer des Apache-Kind-Prozesses! Eine typische Falle waere   beispielsweise

use strict;     use vars qw($user);

use CGI;     my $cgi = new CGI;

$user = 1 if $cgi->param('username') eq 'admin' and $cgi->param('password') eq 'strenggeheim';

Wenn hier die Authentifizierung fehl schlaegt, ist $user trotzdem   noch 1! Ein moeglicher Loesungsansatz waere:

$user = $cgi->param('username') eq 'admin' && $cgi->param('password') eq 'strenggeheim' ? 1 : 0;

• Vorsicht mit precompiled regular expressions! Wenn man z. B.

$pattern = '^blub$'; # $pattern wird normal dynamisch gefuellt     foreach(@list) {       print if /$pattern/o;     }

benutzt, dann ist das zwar uU ein ziemlicher Performance-Gewinn,   aber das heisst auch, dass die Pattern sich nicht aendert, bis der   Apache-Child beendet wird. Das kann natuerlich zu ziemlich   fiddeligen Bugs fuehren... Eine moegliche Loesung ist das folgende   Code-Stueck:

$pattern = '^blub$';     eval q{       foreach(@list) {         print if /$pattern/o;       }     };

Allerdings muss man schon die ganze Schleife in das eval q{}   schreiben -- sonst kann man das 'o' bei /o genau so gut   weglassen ;-) Denn dann wuerde die RegEx trotzdem jedesmal neu   kompiliert. Wem eval() nicht zusagt, der kann sich zunutze machen,   dass Perl Regexe cached. Die folgende Loesung wuerde genau so   laufen:

$pat = '^blub$';     'blub' =~ /$pat/; #1     foreach(@list) {       print if //;     }

Bei dieser Loesung ist wichtig, dass der mit '#1' titulierte RegEx   in jedem Fall matcht! Sonst wird die RegEx nicht gecached. Das   kann man btw. auf mehrere Arten erreichen: wenn man sicherstellen   kann, dass $pat keine Meta-Zeichen enthaelt (wie z. B. '.+' oder   '*' oder so), dann wird das hier immer wahr sein:

$pat =~ /\Q$path\E/;

Ansonsten muss man tricksen:

"\380" =~ /$pat|^\380/;

• Wichtig ist auch, daran zu denken, dass Scripte nicht im Namespace   'main' laufen, sondern in einem eigenen Namespace. Das haengt, wie   weiter oben schon erwaehnt, damit zusammen, dass mod_perl aus   Scripten ein Modul macht.

• Man kann @INC zur Laufzeit nicht mehr aendern! mod_perl ist ein   laufender Apache-Prozess, da kann man @INC nicht mehr veraendern.   Um @INC zu beeinflussen, muss man das vorher machen. Z. B. ueber   die Konfigurations-Direktive

PerlSetEnv PERL5LIB /home/httpd/perl

• Module werde nicht neu geladen. Das heisst, wenn das Script das   erste mal laeuft, wird das Modul frisch geladen. Beim zweiten mal   nicht mehr. Um das zu erreichen, muss man...

- den Server neu starten.   - Apache::StatINC benutzen. Gilt nur fuer den Developement-Prozess!     Danach sollte man das lassen, um Performance zu sparen.     Apache::StatINC benutzt man so:

PerlModule Apache::StatINC        PerlInitHandler Apache::StatINC

- Apache::Reload benutzen. AFAIK ist das eine Weiterentwicklung     von Apache::StatINC und wird so benutzt:

PerlInitHandler Apache::Reload

Jetzt gibt es zwei Moeglichkeiten. Die erste ist das implizite     registrieren von Modulen. Das erfordert eine weitere     Konfigurations-Direktive:

PerlSetVar ReloadAll Off

und in jedem Modul, dass neu geladen werden soll, ein

use Apache::Reload;

Die zweite Moeglichkeit waere ein explizites registrieren von     Modulen, die neu geladen werden sollen. Das geht nur ueber     Konfigurations-Direktiven:

PerlInitHandler Apache::Reload       PerlSetVar ReloadModules "My::Foo My::Bar Foo::Bar::Test::*"

Richtig, hier sind auch Wildcards erlaubt :-)

- Eine Touch-Datei definieren. Man kann mit mod_perl eine Datei     definieren, auf die ein stat() gemacht wird. Wenn die Access-Time     sich geaendert hat, dann werden die Module neu geladen. Das geht     auch mit einer Konfigurations-Direktive:

PerlSetVar ReloadTouchFile /tmp/reload_modules

• Man sollte mit den Modulen aufpassen. Das beste Beispiel ist hier   CGI.pm: oft benutzt man (ich selber auch) etwas wie

use CGI qw/param/;

Das ist bei mod_perl ziemlich boese. CGI.pm erstellt intern ein   eigenes Objekt, um die CGI-Paramter zu speichern. Das wuerde bei   der Benutzung von param() jetzt natuerlich boese auf uns zurueck   fallen: wir haetten die alten Parameter. Deshalb, bei   mod_perl-Scripten immer ein neues Objekt erstellen. Oder auch   Konfig-Module: ich hab schon relativ haeufig etwas wie

package MyConfig;

use strict;     use vars qw(%conf @EXPORT_OK @INC);

@INC = qw(Exporter);     @EXPORT_OK = qw(%conf);

%conf = (       Config => {         containing => 'many',         entries => 'sic!'       }     );

Das geht hier natuerlich so nicht, aus bekannten Gruenden. Loesung   waere dafuer vielleicht sowas wie

PerlHandler "sub { do 'MyConfig.pm'; }"

• mod_perl-Scripte koennen keine END und DATA Sektionen   enthalten, weil das Script in ein Modul umgewandelt wird.

• die() verhaelt sich nicht wie gewohnt. mod_perl setzt einen   Signal-Handler auf SIG__DIE__, also bitte kein use CGI::Carp   qw/fatalsToBrowser/ benutzen!

• print() und printf() verhalten sich nicht wie gewohnt. Man muss   CGI::print benutzen, also

my $rq = new CGI;     $rq->print 'text';

• END{} und BEGIN{} Bloecke verhalten sich nicht normal.

• Die SheBang-Zeile hat keinen Einfluss mehr. Wenn man command line   switches setzen will, dann muss man das entweder mit den   aequivalenten Perl-Variablen (z. B. $^W fuer '-w') oder mit einer   Konfigurations-Option (z. B. PerlWarn On).

Puh. Mehr faellt mir jetzt nicht ein, aber ich bin sicher, da gibt es noch mehr zu beachten.

Zumindest die, die mir so unter die Finger gekommen sind.

Meiner leider nicht.

Wie sieht es denn da aus?

Da wird Perl ganz normal als CGI-Prozess benutzt :-)

Das kann bei den Default(?)grenzen von 1024 aber schnell mal passieren.

Naja, also eigentlich ja nicht. Und IMHO liegen die Grenzen auch hoeher, aber das ist natuerlich in hoechstem Masse systemabhaengig.

Nein, gottseidank nicht, sie sind einstellungsabhängig.

Na, das ist in diesem Fall doch dasselbe :-)

Ach, ich weiss auch nicht. Der ISP war anfangs recht gut, ich hatte sehr viele Freiheiten. Aber jetzt... ich hab nichtmal mehr ein eigenes Errorlog. Und dann

Noch nicht einmal einen Errorlog? Na, das ist aber ziemlich hart!

Ja. Sagte ich ja. Und vom Support-Team kommen nur dumme Kommentare wie 'Leider koennen wir Ihnen kein Errorlog zur Verfuegung stellen'. Naja, wird Zeit, dass ich (wieder mal) umziehe :-)

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der ISP ist all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

hehe fast ;-))

Wenn's nur nicht immer so ein Aufwand wäre, nicht? KK stellen, neuen Hoster suchen, da alles finden und wahrscheinlich auch noch dies und das portieren usw.

Jo... Das anpassen der Scripte ist das muehsamste. Ueberall Pfadangaben aendern.

Gruesse,  CK

[xNeTworKx]

Hallo,
puh, da habe ich ja recht aufschlußreichen Lesestoff =), übrigens, CGI Scripts funktionieren heute schon wieder nicht bei meinem Provider.

[Christoph Zurnieden]

Hallo,

Eigentlich sollte ich das so stehen lassen, aber ein paar Fragen/Kommentare hätte ich doch noch.

Naja, so leider finde ich das gar nicht. Es erfordert halt
einfach eine Konsequent saubere Programmierung -- nichts
anderes als Threadsafeness (geiles Wort, leider bestimmt
falsch ;-)

Ich kenne auch nichts anderes als "threadsafe" (Man könnte es
auch übersetzen, aber "einfädelsicher"? ;-)

Naja, aber threadsafeness? Ich bin fast sicher, es muss threadsafety
heissen ;-)

Das erste ist mehr "Zuverlässigkeit" das zweite mehr dem deutschem "Sicherheit" zuzuordnen.
Mmh...
Ach, nimm "reentrant" ;-)

Aber (für's Archiv) was genau heißt den Threadsafe in Perl?
Was gibt es da zu beachten?

Naja. Das ist bei mod_perl etwas komplizierter. Generell kann man
IMHO sagen:

• globale Variablen *immer* initialisieren! Man kann nie wissen, was
    da nicht schon drin steht.

• Niemals Konstrukte wie

use strict;

my $counter = 0;

addone();
    addone();

sub addone {
      $counter++;
    }

Benutzen. In 'sub addone' ist bei mod_perl nicht die lexikalisierte
  Variable '$counter' gemeint, sondern die globale Variable
  '$counter'. Das haengt damit zusammen, wie mod_perl ein Script
  sieht. Denn bevor der Code ausgefuehrt wird, macht mod_perl daraus

package Apache::ROOT::verzeichnis::zum::script;
   use Apache qw(exit);
   sub handler {
      use strict;

my $counter = 0;

addone();
      addone();

sub addone {
        $counter++;
      }
   }

Aus jedem Script wird ein Modul mit nur einer Sub (handler).
  Daraus folgt, dass man an Subroutinen grundsaetzlich *alles*
  uebergeben sollte, als Funktionsargumente. Ausserdem muss man
  natuerlich grundsaetzlich alle Variablen initialisieren!

Auf die Gefahr hin, Dich zu wiederholen: man sollte _immer_ und _überall_ _alle_ Variablen initialisieren. Ausnahmen nur für Experten und auch nicht in jeder Sprache.

• Dann gilt: Scripte, die auf mod_perl laufen sollen, grundsaetzlich
    *sehr* gut durchtesten. Es kann sehr gut sein, dass ein
    Fehlerverhalten erst nach einer gewissen Zeit auftritt. Das liegt
    daran, dass der Apache forked: in jedem Apache-Prozess wird das
    Script neu geladen. Und weil der Apache den Child, der den Request
    bearbeiten soll, nach dem Round-Robin-Verfahren

Round-Robin:
http://choices.cs.uiuc.edu/f-kon/RoundRobin/node1.html

aussucht, kann es
  durchaus sein, dass ein Fehlverhalten erst nach 40 oder 50
  Testlaeufen zum Vorschein kommt. Ich wuerde empfehlen, bei dem
  eigenen Testserver die Anzahl der Childs auf nur sehr wenige
  einzuschraenken. Die Alternative ist natuerlich, dem Apachen
  komplett zu verbieten zu forken. Das erreicht man, indem man ihn
  mit 'httpd -x' aufruft.

Das ist aber wenig zu empfehlen bei "gleichzeitigen" Lese/Schreibzugriffen auf gemeinsame Dateien. (Datenbank etc)
Also Vorsicht bei scheinbar simplen Lösungen ;-)

• Man sollte niemals $^W abschalten. mod_perl schreibt alle Warnings
    ins Errorlog, ein unersetzbares Werkzeug.

So man denn eins hat >;->
Nein, der war zu fies, denn ziehe ich, wenn auch nur halbherzig, zurück ;-)

• Ich kann es nie oft genug wiederholen: vorsicht mit globalen
    Variablen! Globale Variablen erhalten ihren Wert fuer die gesamte
    Lebensdauer des Apache-Kind-Prozesses!

Globale Variablen sind selten threadsafe. Das gilt für alle Sprachen.

(In Pseudo-Perl)

$pi = 3.1415;

geht,

$name = "Heinz";

sub foo(){
 if($name == "Heinz")
 code-for-Heinz
 else
 code-for-otto
}
sub bar(){
 $name ="Otto";
}

gibt Probleme, die hier eindeutig sind. Das kann sich aber auch ganz unangenehm verstecken, wie im folgendem Beispiel:

Eine typische Falle waere
  beispielsweise

use strict;
    use vars qw($user);

use CGI;
    my $cgi = new CGI;

$user = 1 if $cgi->param('username') eq 'admin' and $cgi->param('password') eq 'strenggeheim';

Wenn hier die Authentifizierung fehl schlaegt, ist $user trotzdem
  noch 1! Ein moeglicher Loesungsansatz waere:

$user = $cgi->param('username') eq 'admin' && $cgi->param('password') eq 'strenggeheim' ? 1 : 0;

• Wichtig ist auch, daran zu denken, dass Scripte nicht im Namespace
    'main' laufen, sondern in einem eigenen Namespace. Das haengt, wie
    weiter oben schon erwaehnt, damit zusammen, dass mod_perl aus
    Scripten ein Modul macht.

Sollte aber nicht zu sehr verführen! ;-)

• Man kann @INC zur Laufzeit nicht mehr aendern! mod_perl ist ein
    laufender Apache-Prozess, da kann man @INC nicht mehr veraendern.

Sollte eigentlich in mod_perl eingebaut werden können. Was habe ich hier? mod_perl-1.26, dann schau ich mal.
Aber nur gucken! ;-)

• Module werde nicht neu geladen. Das heisst, wenn das Script das
    erste mal laeuft, wird das Modul frisch geladen. Beim zweiten mal
    nicht mehr. Um das zu erreichen, muss man...

- den Server neu starten.

Naja ;-)

- Apache::Reload benutzen. AFAIK ist das eine Weiterentwicklung
    von Apache::StatINC und wird so benutzt:

PerlInitHandler Apache::Reload

Jetzt gibt es zwei Moeglichkeiten. Die erste ist das implizite
    registrieren von Modulen. Das erfordert eine weitere
    Konfigurations-Direktive:

PerlSetVar ReloadAll Off

und in jedem Modul, dass neu geladen werden soll, ein

use Apache::Reload;

Das scheint mir wohl die beste Möglichkeit. Erfordert allerdings auch Schreibzugriff auf die Conf, das nicht jeder hat

- Eine Touch-Datei definieren. Man kann mit mod_perl eine Datei
    definieren, auf die ein stat() gemacht wird. Wenn die Access-Time
    sich geaendert hat, dann werden die Module neu geladen. Das geht
    auch mit einer Konfigurations-Direktive:

PerlSetVar ReloadTouchFile /tmp/reload_modules

(In /tmp würde ich nie etwas lagern. Man muß immer damit rechnen, daß der liebe Sysadmin jederzeit ein 'rm -rf /tmp/*' ausführen kann)

• Man sollte mit den Modulen aufpassen.

Gibt es da noch keine Unterscheidung bezüglich reentrance?

• Die SheBang-Zeile hat keinen Einfluss mehr.

Erklärung(?):
Da alles in ein sub{} gesetzt wird, steht diese Zeile nicht mehr am Anfang und ist somit ein simpler Kommentar.

Puh. Mehr faellt mir jetzt nicht ein, aber ich bin sicher, da gibt
es noch mehr zu beachten.

Noch ist dieser Thread verlängerbar ;-)

Zumindest die, die mir so unter die Finger gekommen sind.

Meiner leider nicht.

Wie sieht es denn da aus?

Da wird Perl ganz normal als CGI-Prozess benutzt :-)

Und da wundern sich die Leute, wenn ich CGI als zweifelhaften Workaround ansehe ;-)
Ist doch wirklich nicht so schwer ein Modul zu bauen, geschweige denn an den Apachen anzuhängen, oder?

Das kann bei den Default(?)grenzen von 1024 aber schnell
mal passieren.

Naja, also eigentlich ja nicht. Und IMHO liegen die Grenzen
auch hoeher, aber das ist natuerlich in hoechstem Masse
systemabhaengig.

Nein, gottseidank nicht, sie sind einstellungsabhängig.

Na, das ist in diesem Fall doch dasselbe :-)

Aha, dann Mißverständnis, ich ziehe die Grenze zum System sehr hart an Hardware/Objektcodierung. Alles, was sich irgendwie (ohne Reboot ;-) einstellen läßt, fällt da nicht drunter. (sozusagen: System = 'uname -a')

Ach, ich weiss auch nicht. Der ISP war anfangs recht gut, ich
hatte sehr viele Freiheiten. Aber jetzt... ich hab nichtmal
mehr ein eigenes Errorlog. Und dann

Noch nicht einmal einen Errorlog?
Na, _das_ ist aber ziemlich hart!

Ja. Sagte ich ja. Und vom Support-Team kommen nur dumme Kommentare
wie 'Leider koennen wir Ihnen kein Errorlog zur Verfuegung stellen'.
Naja, wird Zeit, dass ich (wieder mal) umziehe :-)

Dann ist's wirklich dringend.
Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der
ISP ist all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

*hehe* fast ;-))

Kenne mich da nicht aus. (Und zu faul Google zu bemühen ;-)

Kannst es mir ja heimlich stecken.

Kleine Schwester war so nett, meinte: "Tonline wird nix geschenkt!" ;-)

Wenn's nur nicht immer so ein Aufwand wäre, nicht? KK stellen,
neuen Hoster suchen, da alles finden und wahrscheinlich auch noch
dies und das portieren usw.

Jo... Das anpassen der Scripte ist das muehsamste. Ueberall
Pfadangaben aendern.

'man m4' ?

Au, au, au, nich' hauen!

;-)))

so short

Christoph Zurnieden

[Christian Kruse]

Hoi Christoph,

Naja, so leider finde ich das gar nicht. Es erfordert halt
einfach eine Konsequent saubere Programmierung -- nichts
anderes als Threadsafeness (geiles Wort, leider bestimmt
falsch ;-)

Ich kenne auch nichts anderes als "threadsafe" (Man könnte es
auch übersetzen, aber "einfädelsicher"? ;-)

Naja, aber threadsafeness? Ich bin fast sicher, es muss threadsafety
heissen ;-)

Das erste ist mehr "Zuverlässigkeit" das zweite mehr dem deutschem
"Sicherheit" zuzuordnen.
Mmh...
Ach, nimm "reentrant" ;-)

Ok ;-) Wobei ich Threadsafety als richtig empfinde ;-)

• Dann gilt: Scripte, die auf mod_perl laufen sollen, grundsaetzlich
    *sehr* gut durchtesten. Es kann sehr gut sein, dass ein
    Fehlerverhalten erst nach einer gewissen Zeit auftritt. Das liegt
    daran, dass der Apache forked: in jedem Apache-Prozess wird das
    Script neu geladen. Und weil der Apache den Child, der den Request
    bearbeiten soll, nach dem Round-Robin-Verfahren

Round-Robin:
http://choices.cs.uiuc.edu/f-kon/RoundRobin/node1.html

Netter Link ;-)

aussucht, kann es
  durchaus sein, dass ein Fehlverhalten erst nach 40 oder 50
  Testlaeufen zum Vorschein kommt. Ich wuerde empfehlen, bei dem
  eigenen Testserver die Anzahl der Childs auf nur sehr wenige
  einzuschraenken. Die Alternative ist natuerlich, dem Apachen
  komplett zu verbieten zu forken. Das erreicht man, indem man ihn
  mit 'httpd -x' aufruft.

Das ist aber wenig zu empfehlen bei "gleichzeitigen" Lese/Schreibzugriffen
auf gemeinsame Dateien. (Datenbank etc)
Also Vorsicht bei scheinbar simplen Lösungen ;-)

Diese 'Loesung' war nur fuer den Developement-Prozess gedacht ;-)

• Ich kann es nie oft genug wiederholen: vorsicht mit globalen
    Variablen! Globale Variablen erhalten ihren Wert fuer die gesamte
    Lebensdauer des Apache-Kind-Prozesses!

Globale Variablen sind selten threadsafe. Das gilt für alle Sprachen.

Stimmt ;-) Dafuer muss man Mutexes oder aehnliche Locking-Mechanismen
einrichten.

• Module werde nicht neu geladen. Das heisst, wenn das Script das
    erste mal laeuft, wird das Modul frisch geladen. Beim zweiten mal
    nicht mehr. Um das zu erreichen, muss man...

- den Server neu starten.

Naja ;-)

Eine simple Loesung ist auch eine Loesung ;-)

• Man sollte mit den Modulen aufpassen.

Gibt es da noch keine Unterscheidung bezüglich reentrance?

Was meinst du?

• Die SheBang-Zeile hat keinen Einfluss mehr.

Erklärung(?):
Da alles in ein sub{} gesetzt wird, steht diese Zeile nicht mehr am Anfang
und ist somit ein simpler Kommentar.

Nein :-)
Die SheBang wird nicht von Perl benutzt, sondern von der Shell. Mal ganz
abgesehen davon, dass Perl zu dem Zeitpunkt schon laeuft, wo das Script ausgefuehrt wird...

Und da wundern sich die Leute, wenn ich CGI als zweifelhaften Workaround
ansehe ;-)
Ist doch wirklich nicht so schwer ein Modul zu bauen, geschweige denn an
den Apachen anzuhängen, oder?

Nein, das sicher nicht. Probleme macht mod_perl nur mit der
Speicherverwaltung... so 80MB-Apache-Prozesse sind nicht so das dollste ;-)

Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

Hehe ;-)
Nene. Ich hab mir vorgenommen, jetzt mache ich das richtig. Ich spare auf das
noch fehlende 19"-Gehaeuse und stelle mir dann meinen eigenen Server auf. Mir
geht das dauernde Provider-wechseln einfach nur auf den Geist.

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der
ISP ist all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

*hehe* fast ;-))

Kenne mich da nicht aus. (Und zu faul Google zu bemühen ;-)

Kannst es mir ja heimlich stecken.

Tausch mal das 'ex' gegen 'in' und setz ein '.com' dahinter *g*

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

• Dann gilt: Scripte, die auf mod_perl laufen sollen, grundsaetzlich
    *sehr* gut durchtesten. Es kann sehr gut sein, dass ein
    Fehlerverhalten erst nach einer gewissen Zeit auftritt. Das liegt
    daran, dass der Apache forked: in jedem Apache-Prozess wird das
    Script neu geladen. Und weil der Apache den Child, der den Request
    bearbeiten soll, nach dem Round-Robin-Verfahren

Round-Robin:
http://choices.cs.uiuc.edu/f-kon/RoundRobin/node1.html

Netter Link ;-)

Ja, nicht? Ist so eine schöne einfache Erklärung, da verweise ich immer drauf ;-)
(Falls der nach einer gewissen Zeit nicht mehr leben sollte, lieber Archivbesucher: der ist vielfach gespiegelt, einfach mal eine Suchmaschine Deiner Wahl bemühen)

aussucht, kann es
  durchaus sein, dass ein Fehlverhalten erst nach 40 oder 50
  Testlaeufen zum Vorschein kommt. Ich wuerde empfehlen, bei dem
  eigenen Testserver die Anzahl der Childs auf nur sehr wenige
  einzuschraenken. Die Alternative ist natuerlich, dem Apachen
  komplett zu verbieten zu forken. Das erreicht man, indem man ihn
  mit 'httpd -x' aufruft.

Das ist aber wenig zu empfehlen bei "gleichzeitigen" Lese/Schreibzugriffen
auf gemeinsame Dateien. (Datenbank etc)
Also Vorsicht bei scheinbar simplen Lösungen ;-)

Diese 'Loesung' war nur fuer den Developement-Prozess gedacht ;-)

Nützt nichts, wenn man genau das prüfen sollte.

Aber gut, zugegeben: wer sich da (konkurierende Zugriffe) dran traut, sollte wohl gut genug sein, da auch selber drauf zu kommen, nicht? ;-)

• Ich kann es nie oft genug wiederholen: vorsicht mit globalen
    Variablen! Globale Variablen erhalten ihren Wert fuer die gesamte
    Lebensdauer des Apache-Kind-Prozesses!

Globale Variablen sind selten threadsafe. Das gilt für alle Sprachen.

Stimmt ;-) Dafuer muss man Mutexes oder aehnliche Locking-Mechanismen
einrichten.

Geht das eigentlich auch in Perl?

Aha 'man perlthrtut' ;-)

Oho, da kann man ja richtig schöne Gemeinheiten mit anstellen!
Das ist was für Vaters Sohn! ;-)))

'perl -e 'use Thread;'

Schade, nicht auf der Platte :-(

perl -MCPAN -e 'install Thread;' ;-)

• Module werde nicht neu geladen. Das heisst, wenn das Script das
    erste mal laeuft, wird das Modul frisch geladen. Beim zweiten mal
    nicht mehr. Um das zu erreichen, muss man...

- den Server neu starten.

Naja ;-)

Eine simple Loesung ist auch eine Loesung ;-)

Neustart ist keine Lösung!
Hamm' doch kein Windows!
'dammtnochmal!
;-)))

• Man sollte mit den Modulen aufpassen.

Gibt es da noch keine Unterscheidung bezüglich reentrance?

Was meinst du?

Nun, in den LibCs gibt für die verschiedensten Funktionen auch reentrante Versionen, haben z.B. ein _r hinten angehangen in der GlibC.
Und genau so etwas meine ich, irgendein äußerliches Zeichen, das normale Funktionen von reentranten Funktionen unterscheidet, falls so eine Unterscheidung überhaupt nötig sein sollte.

• Die SheBang-Zeile hat keinen Einfluss mehr.

Erklärung(?):
Da alles in ein sub{} gesetzt wird, steht diese Zeile nicht mehr am Anfang
und ist somit ein simpler Kommentar.

Nein :-)
Die SheBang wird nicht von Perl benutzt, sondern von der Shell.

Hupsalla, stimmt. My Fault. ;-)

Und da wundern sich die Leute, wenn ich CGI als zweifelhaften Workaround
ansehe ;-)
Ist doch wirklich nicht so schwer ein Modul zu bauen, geschweige denn an
den Apachen anzuhängen, oder?

Nein, das sicher nicht. Probleme macht mod_perl nur mit der
Speicherverwaltung... so 80MB-Apache-Prozesse sind nicht so das dollste ;-)

Na, bei _den_ Speicherpreisen ;-)

Aber darf eigentlich nicht passieren. Leck in mod_perl?

Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

Hehe ;-)
Nene. Ich hab mir vorgenommen, jetzt mache ich das richtig. Ich spare auf das
noch fehlende 19"-Gehaeuse und stelle mir dann meinen eigenen Server auf. Mir
geht das dauernde Provider-wechseln einfach nur auf den Geist.

Au, das wird teuer.
Wäre es nicht billiger, sich einfach einen anzumieten?

bezahle ich auch noch einen ziemlich teuren Preis dafuer. Der
ISP ist all- -- den Rest musst du dir selber suchen ;-))

"all-exclusive" ? >;->

*hehe* fast ;-))

Kenne mich da nicht aus. (Und zu faul Google zu bemühen ;-)

Kannst es mir ja heimlich stecken.

Tausch mal das 'ex' gegen 'in' und setz ein '.com' dahinter *g*

Wie belieben?
Achso.
Nein, auch nicht.

Ich gestatte mir mal meine abschließende Frage in hiesigem Idiom zu formulieren:

Hä?

so short

Christoph Zurnieden

[Christian Kruse]

Moin,

Neustart ist keine Lösung!
Hamm' doch kein Windows!
'dammtnochmal!
;-)))

*duck* ;-)

• Man sollte mit den Modulen aufpassen.

Gibt es da noch keine Unterscheidung bezüglich reentrance?

Was meinst du?

Nun, in den LibCs gibt für die verschiedensten Funktionen auch reentrante
Versionen, haben z.B. ein _r hinten angehangen in der GlibC.
Und genau so etwas meine ich, irgendein äußerliches Zeichen, das normale
Funktionen von reentranten Funktionen unterscheidet, falls so eine
Unterscheidung überhaupt nötig sein sollte.

Ach so. Das meinst du. Nunja, generell ist das eigentlich nicht noetig -- es
sei denn, die Module benutzen Modul-Interne Variablen. Und nein, IMHO gibt es
das nicht (diese Unterscheidungen) ;-)

Aber darf eigentlich nicht passieren. Leck in mod_perl?

Keine Ahnung. Mal genauer austesten.

Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

Hehe ;-)
Nene. Ich hab mir vorgenommen, jetzt mache ich das richtig. Ich spare auf das
noch fehlende 19"-Gehaeuse und stelle mir dann meinen eigenen Server auf. Mir
geht das dauernde Provider-wechseln einfach nur auf den Geist.

Au, das wird teuer.
Wäre es nicht billiger, sich einfach einen anzumieten?

Klar -- aber dann haette ich wieder so einen komischen SuSE Server.

Tausch mal das 'ex' gegen 'in' und setz ein '.com' dahinter *g*

Wie belieben?
Achso.
Nein, auch nicht.

Ich gestatte mir mal meine abschließende Frage in hiesigem Idiom zu
formulieren:

Hä?

Na, 'all-exclusive' =~ s/ex/in/ -- jetzt kapiert? ;-) So heisst der ISP

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Nun, in den LibCs gibt für die verschiedensten Funktionen auch reentrante
Versionen, haben z.B. ein _r hinten angehangen in der GlibC.
Und genau so etwas meine ich, irgendein äußerliches Zeichen, das normale
Funktionen von reentranten Funktionen unterscheidet, falls so eine
Unterscheidung überhaupt nötig sein sollte.

Ach so. Das meinst du. Nunja, generell ist das eigentlich nicht noetig -- es
sei denn, die Module benutzen Modul-Interne Variablen.

Aus dieser "Radio Eriwan Antwort" ersehe ich, das im Zweifelsfalle Quellcodekontrolle unabdingbar ist, ja?
"See the source, Luke!" ;-)

Aber darf eigentlich nicht passieren. Leck in mod_perl?

Keine Ahnung. Mal genauer austesten.

Es gibt im mod_perl ein Leak Module ($mod_perl/Leak/Leak.*), vielleicht hilft das?
Auf die Schnelle habe ich nur ein unsauberes sprintf() in $mod_perl/src/modules/perl/perl_config.c gefunden (schreibt in line[8192], die Zahl habe ich aber nur von 'gcc -E', weiß nicht woher die kommt, ist das Makro MAX_STRING_LEN) Da nicht auf Länge des Inputs getestet wird, kann das in's Auge gehen (Buffer Overflow). Exploitability (auch ein schönes Wort ;-) habe ich nicht getestet, dürfte aber nicht vorhanden sein.

Hatte nicht letzte Tage hier mal jemand Teilhaber gesucht? ;-)))

Hehe ;-)
Nene. Ich hab mir vorgenommen, jetzt mache ich das richtig. Ich spare auf das
noch fehlende 19"-Gehaeuse und stelle mir dann meinen eigenen Server auf. Mir
geht das dauernde Provider-wechseln einfach nur auf den Geist.

Au, das wird teuer.
Wäre es nicht billiger, sich einfach einen anzumieten?

Klar -- aber dann haette ich wieder so einen komischen SuSE Server.

Nein, mittlerweile gibt es die vermehrt auch mit *BSD. ,-)

Allerdings meinte ich mit anmieten auch "bare metal" und die OS-Installation dann nach Wunsch. Das ist aber wie gesagt recht teuer.

Tausch mal das 'ex' gegen 'in' und setz ein '.com' dahinter *g*

Wie belieben?
Achso.
Nein, auch nicht.

Ich gestatte mir mal meine abschließende Frage in hiesigem Idiom zu
formulieren:

Hä?

Na, 'all-exclusive' =~ s/ex/in/ -- jetzt kapiert? ;-) So heisst der ISP

Na, soweit war ich auch schon ;-)
Aber whois sagte mir was von Reisebüro? IP-Bereich wird von UU-Net verwaltet, da kommt man schlecht ran, ist also auch nicht sehr hilfreich.

Aufgrund dessen halt meine Frage: Hä?

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Aus dieser "Radio Eriwan Antwort" ersehe ich, das im Zweifelsfalle
Quellcodekontrolle unabdingbar ist, ja?

Genau ;-)

Klar -- aber dann haette ich wieder so einen komischen SuSE Server.

Nein, mittlerweile gibt es die vermehrt auch mit *BSD. ,-)

Ah -- die Menschen werden vernuenftiger ;-)

Allerdings meinte ich mit anmieten auch "bare metal" und die OS-Installation
dann nach Wunsch. Das ist aber wie gesagt recht teuer.

Nunja, mal sehen, was ich so an Angeboten finde.

Na, 'all-exclusive' =~ s/ex/in/ -- jetzt kapiert? ;-) So heisst der ISP

Na, soweit war ich auch schon ;-)
Aber whois sagte mir was von Reisebüro? IP-Bereich wird von UU-Net
verwaltet, da kommt man schlecht ran, ist also auch nicht sehr hilfreich.

Aufgrund dessen halt meine Frage: Hä?

Nun ja. Sie benutzen eine Abkuerzung. Ich sage nur:

s^^^<DATA>^e;s((\d{3}|(\D+))){$i++%2?chr($1-1)^chr($i):
$1^chr($i%3)}exg;y/\010/;/;s..*.$_.ee;
__END__
q113i107v039#097t127r055.034w104u061`121l060k119j119.128m116.125n001

;-)))

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Klar -- aber dann haette ich wieder so einen komischen SuSE Server.

Nein, mittlerweile gibt es die vermehrt auch mit *BSD. ,-)

Ah -- die Menschen werden vernuenftiger ;-)

Obwohl: für so kleine Dinger wie sie angeboten werden (im Höchstfall mal ein Dual Athlon o.ä.) reicht auch Linux (aber dann selbstgebaut!) wenn sie nicht gerade stets am Limit operiert, wie die arme Kiste, die hier das Forum benebst Archiv+Suche betreibt ;-)

Na, 'all-exclusive' =~ s/ex/in/ -- jetzt kapiert? ;-) So heisst der ISP

Na, soweit war ich auch schon ;-)
Aber whois sagte mir was von Reisebüro? IP-Bereich wird von UU-Net
verwaltet, da kommt man schlecht ran, ist also auch nicht sehr hilfreich.

Aufgrund dessen halt meine Frage: Hä?

Nun ja. Sie benutzen eine Abkuerzung. Ich sage nur:

s^^^<DATA>^e;s((\d{3}|(\D+))){$i++%2?chr($1-1)^chr($i):
$1^chr($i%3)}exg;y/\010/;/;s..*.$_.ee;
__END__
q113i107v039#097t127r055.034w104u061`121l060k119j119.128m116.125n001

;-)))

"Security thru obscurity does not work!" ;-)

Kommt mir irgendwie bekannt vor. War so etwas ähnliches nicht mal im Obfuscated Perl Contest?
Oder war der etwa von Dir? ;-)
(Jetzt weiß ich auch endlich, wofür ich den Jail gebastelt habe, worin bis jetzt immer nur einsam und verlassen der Netscape dümpelte ;-)

Na, dann schauen wir mal.
Nunja, garantieren mal gerade 99% Uptime, das sind dann über dreieinhalb Tage Downtime per Anno!
Selbst MS garantiert ja schon 99.5%! ;-)

Bei der Hardware steht oben "Intel Prozessor".
Irgendwo habe ich noch einen P90, ist auch ein Intelprozessor, oder? ;->

Die AGB ist das übliche "Wir haben mit nix etwas zu tun, hauptsache ihr zahlt", allerdings wiedersprechen sich der erste und der letzte Absatz, deshalb gilt für Änderungen am Vertrag (also auch Preiserhöhungen) automatisch BGB. (Oder bist Du Vollkaufman?)

Insgesamt kann ich Deinen Entschluß die Koffer zu packen, nur allzugut verstehen.

So, jetzt aber Schluß hier, sonst bekomme ich wieder http://forum.de.selfhtml.org/?m=67918&t=12241 einen auf den Sack wg OT ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Klar -- aber dann haette ich wieder so einen komischen SuSE Server.

Nein, mittlerweile gibt es die vermehrt auch mit *BSD. ,-)

Ah -- die Menschen werden vernuenftiger ;-)

Obwohl: für so kleine Dinger wie sie angeboten werden (im Höchstfall mal
ein Dual Athlon o.ä.) reicht auch Linux (aber dann selbstgebaut!) wenn sie
nicht gerade stets am Limit operiert, wie die arme Kiste, die hier das
Forum benebst Archiv+Suche betreibt ;-)

Och, das ist nicht alles, was er betreibt. Aber du siehst ja bestens an der
Archiv-Suche, was das Betriebssystem ausmacht ;-)) Vorher war ein Linux
drauf, da hat ein Such-Vorgang hart am CGI-Timeout 'rumgeduempelt ;-)

Nun ja. Sie benutzen eine Abkuerzung. Ich sage nur:

s^^^<DATA>^e;s((\d{3}|(\D+))){$i++%2?chr($1-1)^chr($i):
$1^chr($i%3)}exg;y/\010/;/;s..*.$_.ee;
__END__
q113i107v039#097t127r055.034w104u061`121l060k119j119.128m116.125n001

;-)))

"Security thru obscurity does not work!" ;-)

*lol*

Kommt mir irgendwie bekannt vor. War so etwas ähnliches nicht mal im
Obfuscated Perl Contest?

Oehm, keine Ahnung

Oder war der etwa von Dir? ;-)

Ja ;-)

(Jetzt weiß ich auch endlich, wofür ich den Jail gebastelt habe, worin bis
jetzt immer nur einsam und verlassen der Netscape dümpelte ;-)

Hehehe. Du glaubst doch nicht etwa, dass ich irgendwas boeses hier poste? ;-)

[...]
Insgesamt kann ich Deinen Entschluß die Koffer zu packen, nur allzugut
verstehen.

*sniff* danke schoen -- jetzt fuehle ich mich gleich besser ;-))

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

» »» Obwohl: für so kleine Dinger wie sie angeboten werden (im Höchstfall mal

ein Dual Athlon o.ä.) reicht auch Linux (aber dann selbstgebaut!) wenn sie
nicht gerade stets am Limit operiert, wie die arme Kiste, die hier das
Forum benebst Archiv+Suche betreibt ;-)

Och, das ist nicht alles, was er betreibt. Aber du siehst ja bestens an der
Archiv-Suche, was das Betriebssystem ausmacht ;-)) Vorher war ein Linux
drauf, da hat ein Such-Vorgang hart am CGI-Timeout 'rumgeduempelt ;-)

Damit ist es dann ja wieder OT, ja? ;-)

Was läuft da eigentlich, OpenBSD? Die derzeitige FreeBSD Version hat noch Schwierigkeiten im SMP Betrieb, entspricht in der Qualität etwa Linux 2.2. (2.4 hat ein komplett anderes Locking, dafür aber auch eine komplett andere VM-Verwaltung, die leider etwas lahmer ist). Ist das bei OpenBSD anders/besser?

Nun ja. Sie benutzen eine Abkuerzung. Ich sage nur:

s^^^<DATA>^e;s((\d{3}|(\D+))){$i++%2?chr($1-1)^chr($i):
$1^chr($i%3)}exg;y/\010/;/;s..*.$_.ee;
__END__
q113i107v039#097t127r055.034w104u061`121l060k119j119.128m116.125n001

;-)))

"Security thru obscurity does not work!" ;-)

*lol*

Du lachst, aber es wird immer noch Closed Source Verschlüsselungssoftware verkauft!
BTW: hatte neulich auf einer Messe ein kurzes Gespräch mit einem Entwickler eines Fingerabdruckscanners:
"Und welchen Algorithmus benutzt das Dingen?"
"Sie sind sich doch im Klaren darüber, das ich darüber keine Auskunft geben kann, oder?"

Da mir also keiner sagt, _wie_ das funktioniert, muß ich im Zweifelsfall davon ausgehen, das es _nicht_ funktioniert, also: Schrott -> Tonne.

Kommt mir irgendwie bekannt vor. War so etwas ähnliches nicht mal im
Obfuscated Perl Contest?

Oehm, keine Ahnung

Oder war der etwa von Dir? ;-)

Ja ;-)

Das glaube ich Dir gerne, so gut kenne ich Dich mittlerweile ;-)
Ich meinte jetzt aber den Beitrag beim Obfuscated Perl Contest.

Sowas wie z.B.:

@_=qw(ack ub c e f sh i (1..$,) n p r s t u _);push@_," ";($_=<DATA>)=~s&(\d|\w)&$_[hex $1]&g;eval;$,=84;_(20,__END__
b1f1{9a68c4f90'2',564c}b1f2{1++$#e;a3cda8$#e}b1fe{27;$,+=564c;@e?e(@e):27}

Obwohl: die Decodierung selber ist doch etwas anders aufgebaut

(Jetzt weiß ich auch endlich, wofür ich den Jail gebastelt habe, worin bis
jetzt immer nur einsam und verlassen der Netscape dümpelte ;-)

Hehehe. Du glaubst doch nicht etwa, dass ich irgendwas boeses hier poste? ;-)

Wäre nicht böse, da ja im Code vorhanden. Wer sowas unbesehen ausführt ist doch selber schuld, oder? ;-)

Aber zugegeben, war auch ein gutes Stück Faulheit dabei. Um hinter Deinen Code zu steigen (soweit, daß ich mir auch selber so etwas basteln könnte) bräuchte ich bestimmt so 1-2 Stunden ;-)

[...]
Insgesamt kann ich Deinen Entschluß die Koffer zu packen, nur allzugut
verstehen.

*sniff* danke schoen -- jetzt fuehle ich mich gleich besser ;-))

Oh, das tut mir jetzt leid, lag überhaupt nicht in meiner Absicht! ;-)

so short

Christoph Zurnieden

[Christian Kruse]

Moin!

Obwohl: für so kleine Dinger wie sie angeboten werden (im
Höchstfall mal ein Dual Athlon o.ä.) reicht auch Linux
(aber dann selbstgebaut!) wenn sie nicht gerade stets am
Limit operiert, wie die arme Kiste, die hier das Forum
benebst Archiv+Suche betreibt ;-)

Och, das ist nicht alles, was er betreibt. Aber du siehst ja
bestens an der Archiv-Suche, was das Betriebssystem ausmacht
;-)) Vorher war ein Linux drauf, da hat ein Such-Vorgang hart
am CGI-Timeout 'rumgeduempelt ;-)

Damit ist es dann ja wieder OT, ja? ;-)

Ja, geschickt, nicht wahr? ;-)

Was läuft da eigentlich, OpenBSD?

Nee, FreeBSD.

Die derzeitige FreeBSD Version hat noch Schwierigkeiten im SMP
Betrieb,

Ja, leider :(

entspricht in der Qualität etwa Linux 2.2. (2.4 hat ein komplett
anderes Locking, dafür aber auch eine komplett andere
VM-Verwaltung, die leider etwas lahmer ist). Ist das bei OpenBSD
anders/besser?

Keine Ahnung ;-) Mit OpenBSD habe ich mich noch nicht beschaeftigt.
Die Probleme bei FreeBSD dagegen kann ich nur bestaetigen.

Du lachst, aber es wird immer noch Closed Source
Verschlüsselungssoftware verkauft!

Natuerlich. Und das wird sich auch nie aendern.

BTW: hatte neulich auf einer Messe ein kurzes Gespräch mit einem
Entwickler eines Fingerabdruckscanners:
"Und welchen Algorithmus benutzt das Dingen?"
"Sie sind sich doch im Klaren darüber, das ich darüber keine
Auskunft geben kann, oder?"

Da haett ich glatt gefragt: 'warum nicht?'

Da mir also keiner sagt, _wie_ das funktioniert, muß ich im
Zweifelsfall davon ausgehen, das es _nicht_ funktioniert, also:
Schrott -> Tonne.

Oder man vertraut der Firma. So wird es bei uns gehandhabt ;-) (IMHO
nicht immer der gute Weg -- Lotus oder IBM ist nicht immer
Vertrauenswuerdig, ganz im Gegenteil)

Das glaube ich Dir gerne, so gut kenne ich Dich mittlerweile ;-)
Ich meinte jetzt aber den Beitrag beim Obfuscated Perl Contest.

Ach so. Nein, das war ich natuerlich nicht ;-)

Sowas wie z.B.:

@_=qw(ack ub c e f sh i (1..$,) n p r s t u _);push@_," ";($_=<DATA>)=~s&(\d|\w)&$_[hex $1]&g;eval;$,=84;_(20,__END__
b1f1{9a68c4f90'2',564c}b1f2{1++$#e;a3cda8$#e}b1fe{27;$,+=564c;@e?e(@e):27}

Obwohl: die Decodierung selber ist doch etwas anders aufgebaut

syntax error at test.pl line 1, at EOF
Execution of obsf.pl aborted due to compilation errors.

C:>perl -v

This is perl, v5.6.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2000, Larry Wall

Binary build 620 provided by ActiveState Tool Corp. http://www.ActiveState.com
Built 18:31:05 Oct 31 2000

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using man perl' or perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

C:>

Wäre nicht böse, da ja im Code vorhanden. Wer sowas unbesehen
ausführt ist doch selber schuld, oder? ;-)

Ja -- aber ich wuerde hier nichts zerstoererisches posten -- ich
weiss schliesslich sehr genau, dass hier viele Leute das gedankenlos
ausfuehren wuerden ;-)

Aber zugegeben, war auch ein gutes Stück Faulheit dabei. Um
hinter Deinen Code zu steigen (soweit, daß ich mir auch selber so
etwas basteln könnte) bräuchte ich bestimmt so 1-2 Stunden ;-)

Hehe ;-) Faulheit ist die Wurzel allen Vortschritts

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Damit ist es dann ja wieder OT, ja? ;-)

Ja, geschickt, nicht wahr? ;-)

Und den Schwanzabschneider auch noch überlistet.
Ach nein, UID = 0, oder? ;-)

Die derzeitige FreeBSD Version hat noch Schwierigkeiten im SMP
Betrieb,

Ja, leider :(

Es wurde aber für die nächste Version (5.0) versprochen. Soll angeblich auch nicht mehr lange auf sich warten lassen.

Du lachst, aber es wird immer noch Closed Source
Verschlüsselungssoftware verkauft!

Natuerlich. Und das wird sich auch nie aendern.

"Die Hoffnung stirbt nie!" ;-)

Zumindest basiert der Serverbereich des Bundestages jetzt auf Open Source.

Wundert mich eigentlich bei deren IT-Spezialisten, die für simples Wahldatensammeln ein hochkompliziertes System aufbauen mußten, das jeder vernünftige Mensch mit signierter und verschlüsselter Mail und ein paar Shellscripten erledigt hätte.

BTW: hatte neulich auf einer Messe ein kurzes Gespräch mit einem
Entwickler eines Fingerabdruckscanners:
"Und welchen Algorithmus benutzt das Dingen?"
"Sie sind sich doch im Klaren darüber, das ich darüber keine
Auskunft geben kann, oder?"

Da haett ich glatt gefragt: 'warum nicht?'

Ob derartiger Arroganz?

Da mir also keiner sagt, _wie_ das funktioniert, muß ich im
Zweifelsfall davon ausgehen, das es _nicht_ funktioniert, also:
Schrott -> Tonne.

Oder man vertraut der Firma. So wird es bei uns gehandhabt ;-) (IMHO
nicht immer der gute Weg -- Lotus oder IBM ist nicht immer
Vertrauenswuerdig, ganz im Gegenteil)

Sicherheit die auf Vertrauen basiert ist unzureichend.
"Unzureichende Sicherheit" ist ein Oxymoron, entweder ist es sicher oder nicht, "ein bischen schwanger" gibt es nicht.

Das glaube ich Dir gerne, so gut kenne ich Dich mittlerweile ;-)
Ich meinte jetzt aber den Beitrag beim Obfuscated Perl Contest.

Ach so. Nein, das war ich natuerlich nicht ;-)

Dann mach doch mal mit! ;-)

Sowas wie z.B.:

@_=qw(ack ub c e f sh i (1..$,) n p r s t u _);push@_," ";($_=<DATA>)=~s&(\d|\w)&$_[hex $1]&g;eval;$,=84;_(20,__END__
b1f1{9a68c4f90'2',564c}b1f2{1++$#e;a3cda8$#e}b1fe{27;$,+=564c;@e?e(@e):27}

Obwohl: die Decodierung selber ist doch etwas anders aufgebaut

syntax error at test.pl line 1, at EOF
Execution of obsf.pl aborted due to compilation errors.

Ja, den hatte ich auch, funktioniert nur mit älterem Perl.
Aber jetzt frag mich bloß nicht warum ;-)

C:>perl -v

This is perl, v5.6.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Iih, Windows! ;-)

Wäre nicht böse, da ja im Code vorhanden. Wer sowas unbesehen
ausführt ist doch selber schuld, oder? ;-)

Ja -- aber ich wuerde hier nichts zerstoererisches posten -- ich
weiss schliesslich sehr genau, dass hier viele Leute das gedankenlos
ausfuehren wuerden ;-)

Da verkneif ich mir meinen Kommentar lieber mal ;-)

Aber zugegeben, war auch ein gutes Stück Faulheit dabei. Um
hinter Deinen Code zu steigen (soweit, daß ich mir auch selber so
etwas basteln könnte) bräuchte ich bestimmt so 1-2 Stunden ;-)

Hehe ;-) Faulheit ist die Wurzel allen Vortschritts

Wenn es Windows nicht gäbe, könnte ich das doch glatt unterschreiben >;->

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Und den Schwanzabschneider auch noch überlistet.
Ach nein, UID = 0, oder? ;-)

Na, was sonst? ;-)
Nein, aber den Schwanzabschneider kann man hier nur schwer
beeinflussen.

Es wurde aber für die nächste Version (5.0) versprochen.

Jepp.

Soll angeblich auch nicht mehr lange auf sich warten lassen.

Ende des Jahres ;-)

"Die Hoffnung stirbt nie!" ;-)

Das hat nix mit Hoffnung zu tun. Aus irgendwelchen unerfindlichen
Gruenden ist in gewissen Branchen in Deutschland das Motto 'Was nix
kostet is auch nix' vorherrschend.

Da haett ich glatt gefragt: 'warum nicht?'

Ob derartiger Arroganz?

Gerade deshalb ;-)

Sicherheit die auf Vertrauen basiert ist unzureichend.

Aber nicht immer umgaenglich -- oder verstehst du alle Sourcen, die
du einblickst? ;-)

"Unzureichende Sicherheit" ist ein Oxymoron, entweder ist es
sicher oder nicht, "ein bischen schwanger" gibt es nicht.

Und was ist mit einer Bauchschwangerschaft? ;-))

Dann mach doch mal mit! ;-)

Das wuerd nichts bringen. Da wuerde ich so oder so verlieren.

syntax error at test.pl line 1, at EOF
Execution of obsf.pl aborted due to compilation errors.

Ja, den hatte ich auch, funktioniert nur mit älterem Perl.
Aber jetzt frag mich bloß nicht warum ;-)

Ich denke, wegen dieses Teils:

_(20,__END__

Das *muss* ja schon fast einen Syntax-Fehler geben ;-)

C:>perl -v

This is perl, v5.6.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Iih, Windows! ;-)

Tja, nicht jeder hat die Wahl auf der Arbeit.

Hehe ;-) Faulheit ist die Wurzel allen Vortschritts

Wenn es Windows nicht gäbe, könnte ich das doch glatt
unterschreiben >;->

Seit wann steht Windows fuer Faulheit? Ich dachte, das stuende fuer
Umstaendlichkeit? ;-)

Gruesse,
 CK

[Christoph Zurnieden]

Hallo,

Und den Schwanzabschneider auch noch überlistet.
Ach nein, UID = 0, oder? ;-)

Na, was sonst? ;-)
Nein, aber den Schwanzabschneider kann man hier nur schwer
beeinflussen.

Nunja, regelmäßig posten hilft schon. ;-)
Aber die mangelnde Möglichkeit der Einflußnahme ist auch ganz gut so.

Es wurde aber für die nächste Version (5.0) versprochen.
Jepp.
Soll angeblich auch nicht mehr lange auf sich warten lassen.

Ende des Jahres ;-)

Ah, doch noch so lange?
Verdammt, dann muß ich mir etwas anderes einfallen lassen, muß wohl doch Linux 2.4 nehmen.

"Die Hoffnung stirbt nie!" ;-)

Das hat nix mit Hoffnung zu tun. Aus irgendwelchen unerfindlichen
Gruenden ist in gewissen Branchen in Deutschland das Motto 'Was nix
kostet is auch nix' vorherrschend.

Das sind übrigens meistens diejenigen, die auch Open Source mit der Begründung ablehnen, das die Umschulung zu teuer wäre >;->

Da haett ich glatt gefragt: 'warum nicht?'

Ob derartiger Arroganz?

Gerade deshalb ;-)

Er will mir etwas verkaufen, nicht umgekehrt. Wenn mir also sein Verhalten nicht passt, geh ich zur Konkurenz.
Dumm nur, wenn es keine gibt ;-)

Sicherheit die auf Vertrauen basiert ist unzureichend.

Aber nicht immer umgaenglich -- oder verstehst du alle Sourcen, die
du einblickst? ;-)

Die Sicherheitsrelevanten: ja.
Wenn nicht, nehme ich sie nicht.

Aber das Argument ist auch etwas schwach. Deines, wie auch meines. Nicht jeder macht sich die Mühe, kann es meist auch gar nicht, die Quellen zu verstehen. Aber irgendjemanden gibt es immer. Deshalb sollte man in solchen Bereichen auch nie die "last stable" nehmen, sondern, nach durchackern der Buglist, stets die Vorletzte.

Ja, Sicherheit ist nicht billig.

"Unzureichende Sicherheit" ist ein Oxymoron, entweder ist es
sicher oder nicht, "ein bischen schwanger" gibt es nicht.

Und was ist mit einer Bauchschwangerschaft? ;-))

Wo die "Programme" liegen ist egal ;-)

Dann mach doch mal mit! ;-)

Das wuerd nichts bringen. Da wuerde ich so oder so verlieren.

Bin da mal durchgegangen. Glaube ich eigentlich nicht, hättest normale Chancen.

syntax error at test.pl line 1, at EOF
Execution of obsf.pl aborted due to compilation errors.

Ja, den hatte ich auch, funktioniert nur mit älterem Perl.
Aber jetzt frag mich bloß nicht warum ;-)

Ich denke, wegen dieses Teils:

_(20,__END__

Das *muss* ja schon fast einen Syntax-Fehler geben ;-)

Ah, doch, jetzt wo Du es sagst ;-)

C:>perl -v

This is perl, v5.6.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Iih, Windows! ;-)

Tja, nicht jeder hat die Wahl auf der Arbeit.

Aber die Wahl der Arbeit!

Na gut, der war jetzt an Zynismus kaum zu überbieten, entschuldige mich hiermit bei allen unfreiwillig Arbeitslosen.

Hehe ;-) Faulheit ist die Wurzel allen Vortschritts

Wenn es Windows nicht gäbe, könnte ich das doch glatt
unterschreiben >;->

Seit wann steht Windows fuer Faulheit? Ich dachte, das stuende fuer
Umstaendlichkeit? ;-)

Windows kam zu einer Zeit raus, da war hieß die Alternative Unix.
(eigentlich MacOS, aber die Geschichte, warum es Apple nicht geschafft hat, darf ich wohl als bekannt vorraussetzen)

Aber Scherz beiseite: Windows ist nunmal auf allen PC-Rechnern vorinstalliert. Das zu ändern kostet Arbeit.

so short

Christoph Zurnieden

[Christian Kruse]

Hoi,

Nunja, regelmäßig posten hilft schon. ;-)

*g* das beweist dieser Thread

Aber die mangelnde Möglichkeit der Einflußnahme ist auch ganz gut so.

Stimmt.

Ende des Jahres ;-)

Ah, doch noch so lange?

AFAIK schon. Aber natuerlich kann ich mich irren.

"Die Hoffnung stirbt nie!" ;-)

Das hat nix mit Hoffnung zu tun. Aus irgendwelchen unerfindlichen
Gruenden ist in gewissen Branchen in Deutschland das Motto 'Was nix
kostet is auch nix' vorherrschend.

Das sind übrigens meistens diejenigen, die auch Open Source mit der
Begründung ablehnen, das die Umschulung zu teuer wäre >;->

Stimmt ;-) Mit Vorzug Rechtsanwaelte, Steuerpruefer, Wirtschaftspruefer, etc.
Ich hab taeglich mit denen zu tun ;-)

Er will mir etwas verkaufen, nicht umgekehrt. Wenn mir also sein Verhalten
nicht passt, geh ich zur Konkurenz.

Darum gehts ja gar nicht ;-) Ich wuerde ihn allein aus Prinzip schon fragen.

Dumm nur, wenn es keine gibt ;-)

Jo...

Aber das Argument ist auch etwas schwach. Deines, wie auch meines. Nicht
jeder macht sich die Mühe, kann es meist auch gar nicht, die Quellen zu
verstehen.

Richtig.

Aber irgendjemanden gibt es immer.

Genau auf dieses Argument habe ich gewartet ;-))

Ja, Sicherheit ist nicht billig.

Stimmt.

Aber die Wahl der Arbeit!

Schoen waers ;-) Bis Dezember bin ich gebunden.

Aber Scherz beiseite: Windows ist nunmal auf allen PC-Rechnern
vorinstalliert. Das zu ändern kostet Arbeit.

Stimmt. Aber bequem ist Windows deshalb trotzdem nicht.

Gruesse,
 CK