nicht angemeldet
Hi Thomas,
wie sicher bzw. stabil ist die Version 1.05?
sie läuft auf www.schroepl.net produktiv:
, ohne irgendwelche Einträge im error_log zu
verursachen.
Das galt übrigens auch für alle vorherigen Versionen.
Schon die 1.00 (2002-05-12) habe ich dort verwendet
- damals noch mit temporärer Kopie der Original-Datei
_vor_ dem Komprimieren per system("cp") und mit der
Erzeugung von Cache-Pfaden mit system("mkdir -p") ...
Christian hat in meinem Code kräftig aufgeräumt.
Ich lade nur Versionen von gzip_cnc hoch, die zuvor
- sowohl auf meinem Win98-PC (dort mit Compress::Zlib)
- als auch für schroepl.net (dort mit /bin/gzip)
erfolgreich getestet wurden und die ich auch selbst
produktiv einsetze.
ich habe sie mir nämlich an meinem server
installiert und nun würde ich gerne wissen,
ob ich mit probleme rechnen sollte ode nicht.
Mit Problemen sollte man immer rechnen. ;-)
Aber wenn Du meine Homepage erreichen kannst, dann
sollte Deine ebenfalls eine gute Chance haben.
Im Übrigen gilt natürlich
http://www.schroepl.net/projekte/gzip_cnc/install.htm#test
- ein Fingerfehler während der Installation ist schnell
gemacht ... das passiert mir durchaus auch selbst.
ich hatte eine ganze weile gebraucht bis ich
verstanden haben was ich unter "Festlegung des
Wurzelverzeichnisses für den Cache-Baum" mit
"innerhalb des URL-Baums" und "außerhalb des URL-
Baums" meint.
das ist deshalb verwirrend weil ihr mal über
document-root spricht, aber fast immer der domain-
root gefragt ist und ein URL-Baum als begriff
ziemlich wenig eindeutig ist.
In der Apache-Terminologie gibt es keine "Domain-Root".
Auch ein Virtual Host hat eine DocumentRoot:
http://httpd.apache.org/docs/mod/core.html#documentroot
gzip_cnc ist es aber egal, ob es für einen Virtual Host
läuft oder für einen ganzen Server - der kennt diese
Begriffe nicht.
Die DOCUMENT_ROOT ist halt die einzige Environment-
Variable der CGI-Schnittstelle, die mir einen halbwegs
sinnvollen Defaultwert für die Pfade gibt - ich hatte
die Hoffnung, daß gzip_cnc selbst ohne jede Änderung
im Quelltext irgendwie funktionieren kann.
Besser ist es in jedem Fall, die beschriebenen Stellen
so anzupassen, daß man mit den Ergebnissen glücklich
wird - gzip_cnc braucht keine Protokolldatei, aber der
Benutzer wird eine haben wollen, um zu verstehen, was
passiert.
Und Du kannst sowohl den Cache-Baum als auch die Pro-
tokolldatei hinlegen, wo immer Du willst - Hauptsache,
die Benutzerkennung, unter der gzip_cnc läuft, hat dort
Schreibrecht. Das ist wie bei jedem anderen CGI-Skript.
Du _kannst_ beides auch in den URL-Raum legen - ich
halte das bloß nicht für übersichtlich, statische und
dynamische Dateien miteinander zu mischen.
das zweite problem hatte ich beim "Festlegung der
gzip_cnc-eigenen Protokolldatei" es steht nirgednwo
dass der pfad vom domain-root ausgehen angegeben
werden muss
Muß er auch gar nicht.
gzip_cnc arbeitet nur mit absoluten Pfaden.
Die Funktion "terminate" macht die Log-Datei mit
if (open (LOG, ">>$logfile_path"))
auf - da ist nichts mit "relativ zu irgendwas".
und es wird auch nicht gesagt, dass man die
protokolldatei erst selbst tatsächlich anlegen
soll
"soll" und muß man auch nicht.
">>" legt die Datei an, falls sie nicht existiert.
(zumindest wurde sie bei mir nicht automatisch
erstellt)
Wo hast Du sie erzeugen wollen?
Hast Du dort Schreibrecht?
Steht in Deinem error_log irgendwas von
"failed to open log file" und
"fopen: Permission denied" ?
Wenn Du irrtümlich einen relativen Pfad verwendest,
wo ein absoluter Pfad notwendig ist (nämlich überall),
dann kann es gut sein, daß dieser Pfad so gar nicht
existiert.
gzip_cnc versucht beispielsweise nicht, auf dem Weg
zum Logfile-Pfad fehlende Verzeichnisse anzulegen -
es könnte dies tun, aber falls es notwendig wäre,
würde das mit hoher Wahrscheinlichkeit an einem Miß-
verständnis liegen und dann der angegebene Pfad wegen
fehlender Berechtigungen (ab UNIX-Filesystem-Root)
ohnehin unbrauchbar sein.
Und in diesem Fall kann gzip_cnc nichts tun:
(if we can't open the file, where should we write the message to?)
Ich würde Dir ja gerne eine Fehlermeldung ausgeben -
ich weiß nur nicht, wohin. In das ausgegebene Dokument
im Browser kann ich sie ja schlecht schreiben - denn
das sollte ja i.d.R. komprimiert sein ... und wenn es
tatsächlich einen Perl-Laufzeitfehler gibt, dann
steht er ohnehin im error_log (bei mir wäre das der
Fall).
vielleicht könntet ihr beispiele in den erklärungen
geben.
Wie soll ich das tun, ohne die Verzeichnisstruktur
Deines Servers zu kennen?
Wüßte ich, daß jeder Benutzer seine CGI-Skripte unter
einer eigenen Benutzerkennung ausgeführt bekommt,
dann könnte ich versuchen, das Heimatverzeichnis
dieser Benutzerkennung zu verwenden - dies aber ist
auch wieder nur dann der Fall, wenn der Provider
suexec oder etwas Ähnliches einsetzt ...
Pfade sind immer etwas sehr Individuelles bei einer
Installation - ich will eben gerade _nicht_ irgend-
welche Werte wie /tmp vorgeben, die dann von den Be-
nutzern blind abgeschrieben werden und genau _nicht_
funktionieren, wenn zwei Benutzer gzip_cnc auf dem-
selben Server einsetzen.
Auf meinem Webspace liegen die Dateien von URL-Raum
und sonstigen Kram beispielsweise ziemlich weit von-
einander entfernt:
- URL-Räume liegen in /www/<domainname>,
- sonstiges Zeug liegt in /home/<domainname>.
Folglich liegen bei mir auch der Cachebaum und alle
Log-Dateien in /home/<domainname> - also eben gerade
_nicht_ relativ zu DOCUMENT_ROOT.
Das wird aber bei den meisten Anwendern wieder völlig
anders sein - oft ist der URL-Raum ein Unterverzeichnis
des FTP-Einwahlpunktes oder was auch immer.
Und manchmal haben die Webspaces überhaupt keinen
Bereich außerhalb des URL-Raums ...
ansonsten war alles klar.
Fein. Ich bin gespannt auf die Komprimierungswirkung ...
(Auswertung 'meiner' Zugriffe seit 6. Juni, der letzten
Logfile-Format-Änderung:
http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc_log_eval/)
ps:was meinst du mit "allen browser" ??
was ich in meinem CSS verkehrt mache ... die
Navigation sollte eigentlich in allen Browsern
so aussehen wie im M$IE, also mit gleich
breiten hover-Balken ...
Zu dem Zeitpunkt, als ich das gepostet hatte, war noch
kein "display:block" drin, wenn ich das richtig in Er-
innerung habe - der M$IE wertet wohl allein schon die
width-Angabe von dem, was in der damaligen Version um
die Links herum existierte (<p>?), so aus, wie Mozilla
und Opera das, was Du jetzt im Quelltext vorfindest.
Das ist inzwischen behoben worden.
Viel Erfolg beim Ausliefern komprimierter Seiten
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael