Ich habe die ICS_AWStats Erweiterung Konfiguriert wie eine zweite Installation auf dem selben Server für eine andere Website. Die funktioniert einwandfrei. Allerdings habe ich dort 0.2.5 am start. In der neuen Umgebung möchte ich ICS_AWSTATS 0.2.7 verwenden (Security Issue).
Die Webserver Log Datei wird sauber im Apache Format geschrieben. Die AWSTATS Konfiguratinsdatei sollte die Paramater ja durch die Typo3 Systemkonfiguration vornehmen (oder?). Es sollte also nicht nötig sein die Parameter in der AWStats Konfigurationsdatei festzulegen...
SiteDomain="__AWS_DOMAIN__"
HostAliases="__AWS_DOMAINS__ localhost 127.0.0.1"
DNSLookup=__AWS_DNSLOOKUP__
DirData="__AWS_CACHE_DIR__"
DirCgi="/cgi-bin"
DirIcons="__AWS_ICON_DIR__"
AllowToUpdateStatsFromBrowser=__AWS_ALLOW_UPDATE__
PurgeLogFile=__AWS_PURGELOGFILE__
ArchiveLogRecords=__AWS_ARCHIVELOGRECORDS__
WrapperScript="__AWS_WRAPPER__"
Lang="__AWS_LANG__"
DirLang="__AWS_LANG_DIR__"
Dennoch started AW Stats im Typo3 Backend mit folgender Fehlermeldung im Debug Modus:
Error: Could not open include file: F:/Inetpub/xxxxxxxxx/typo3conf/ext/ics_awstats/awstats/F:/Inetpub/tp_itbetrieb/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
Setup ('F:/Inetpub/xxxxxxxxx/typo3conf/ext/ics_awstats/awstats/awstats.xxxxxxxxx.xxx.conf' file, web server or permissions) may be wrong.
Die Berechtigungen sind geprüft und i.O. Es deutet alles darauf hin, dass etwas mit der Konfiguration nicht stimmt. Es ist mir klar, dass die dummy.inc.conf unter dem angegebenen Pfad nicht gefunden werden kann (Pfad + Pfad + Datei). Da der Pfad zur Konfigurationsdatei im Setup aber korrekt angegeben ist bin ich verwirrt.
Hat jemand die Lösung oder einen Lösungsweg?
Meine Forensiche Analyse:
AWStats Logfile Analyse
Wählen Sie ein Logfile für die Analyse aus:
subdomainname.log
Konfigurierte Domains (in Reihenfolge): domain.de,subdomain.domain.de
Shift + Click -> AW Stats in neuem Fenster mit URL:
http://subdomain.domain.de/typo3conf/ext/ics_awstats/mod1/index.php?t3log=subdomain.log&debug=1
Wenn ich den Querystring Parameter t3log=subdomain.log in t3log=fileadmin/log/subdomain.log ändere (also den relativen Pfad mitgebe) ändert sich die Fehlermeldung:
AWStats Logfile Analyse
-> Die angeforderte Logdatei ist noch nicht konfiguriert!
Nun sind die Fragen:
2. der relative Pfad zur Logdatei sollte sich doch aus der Konfiguration ergeben !? In der localconf.php habe ich diesen Parameter doch klar deklariert:
$TYPO3_CONF_VARS['FE']['logfile_dir'] = 'fileadmin/log/';
Zieht sich ics_awstats die Konfiguration etwa nicht aus der localconf an? Muß der Pfad in der AW Stats Konfiguration mitgegeben werden oder wo ist der Pfad ganau zu hinterlegen? Laut Doku ist zur Konfiguration des Logfiles selbst nötig in der config sektion für die Website nur den Namen der Logdatei zu hinterlegen:
config {
stat = 1
stat_apache = 1
stat_apache_logfile =subdomain.log
stat_mysql = 1
}
...habe auch hier den relativen Pfad ergänzt, das sieht jetzt so aus
stat_apache_logfile = fileadmin/log/subdomain.log
Leider ändert das nichts daran, dass AW Stats im QS Parameter unbedingt die log Datei ohne den realtiven Pfad aufrufen möchte 😢
2. benötigt ics_awstats im QS Parameter den Pfad zur Konfigurationsdatei für die Log Datei?
...
Ich habe die Konfigurationsdatei awstats.conf (bzw. in meinem fall awstats.domain.de.conf) nicht weiter modifiziert da ich davon ausgehe, dass die Parameter von der Typo3 Systemumgebung zur verfügung gestellt werden sollten...
Es erscheint mir zwar unsinnig, weil AWStats ja immer auf die awstats.conf zurückfällt wenn keine konkrete AWStats Konfigurationsdatei vorhanden ist, ich habe aber trotzdem alle möglichen, sinnvollen Varianten der awstats.conf durch kopieren erzeugt, was das Problem erwartungsgemäß nicht gelöst hat:
awstats.domain.de.conf
awstats.subdomain.domain.de.conf
awstats.subdomain.conf
awstats.subdomain.de.conf (<- unsinnige Variante, trotzdem ausprobiert o.O )
...
...nun drehe ich das ganze um:
localconf.php Pfat zur Logdatei auskommentiert:
// $TYPO3_CONF_VARS['FE']['logfile_dir'] = 'fileadmin/log/';
Log Datei ins Root Verzeichnis kopiert und in domain.log umbenannt
ICS_AWStats gestartet, Neue Konfiguration notwendig! Angezeigt war nun die domain.log aus dem Root Verzeichnis. Domians domain.de,subdomain.domain.de eingegeben.
Ergebnis: neues Verzeichnis .awstats-data mit awstats-module.conf
Das alte Verzeichnis fileadmin/log/ samt Inhalten gelöscht.
Shift + Click um domain.log zu analysieren...
http://subdomian.domain.de/typo3conf/ext/ics_awstats/mod1/index.php?t3log=teraport.log
Fehler wie gehabt:
Error: Could not open include file: F:/Inetpub/xxxxxxxxx/typo3conf/ext/ics_awstats/awstats/F:/Inetpub/tp_itbetrieb/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
Setup ('F:/Inetpub/xxxxxxxxx/typo3conf/ext/ics_awstats/awstats/awstats.xxxxxxxxx.xxx.conf' file, web server or permissions) may be wrong.
QS t3log=domain.log esretzt durch t3log=/domain.log
Fehler (wie auch schon gehabt):
AWStats Logfile Analyse
Die angeforderte Logdatei ist noch nicht konfiguriert!
In localconf.php eingegeben:
$TYPO3_CONF_VARS['FE']['logfile_dir'] = '/';
Fehler:
Die Logfiles müssen auf folgendes Muster passen: *.log oder *log*.txt
Beispiele: my-domain.log logfile.txt website-log.txt
...dann findet awstats gar nichts mehr...
Latein = Ende #angry#
Von Blindheit geschlagen!!!
Der Windows Pfad F:/Inetpub/tp_itbetrieb/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
#angry# ist kein Windows Pad!!!
Jetzt kann ich meine Frage wenigstens genauer spezifizieren: wo kann ich in der Konfiguration der Erweiterung ICS_AWSTATS 0.2.7 angeben, dass absolute Pfade im "Windows Format" zurückzugeben sind?
Für eine hilfreiche Antwort wäre ich euch ja soooooooo verbunden.
Nein, das kann auch nicht das Problem gewesen sein, denn der Debug Output des Systems, wo ics_awstat funktioniert versteht diese vermeintlich falschen Windows Pfade auch... 😢
Also muß es damit zu tunn haben, dass der Programmierer zwecks schliessen der Sicherheitslücken Pfade eingebaut hat, die nicht über Perl geprüft werden sondern per php... und php scheint mit diesen Pfaden nicht klarzukommen:
AWS_INCL_DECODEUTFKEYS F:/Inetpub/xxxxxxxxxx/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
AWS_INCL_GEOIP F:/Inetpub/xxxxxxxxxxx/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
AWS_PATH_TO_GEOIP
Mir bleibt also scheinbar nichts anderes übrig als die ics_awstats Klassen in die Mangel zu nehmen. Es sei denn es meldet sich noch jemand zu Wort bevor ich mir das System vergeige.
Hi Valentin Schmid,
I have ics_awstats 0.2.5 running fine in a windows environment. I installed 0.2.7 because of the security issue in the same environment for a new website. Obviously the built in checks cause problems when call_awstats is processed. The reason is obviously something with the configuration. I am not exactly fit with typo3 classes and I do not know where the configuration comes from when "$this->conf['awstatsFullUrl']" is used.
Apparently there is a difference when the Debug Mode does the getenv('AWS_INCL_DECODEUTFKEYS'); the correct path to F:/Inetpub/xxxxxxxxx/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf is displayed in the debug table.
But when I click the domain.log in the BE User Ineterface I get an error message from typo3 (at least the error message is not defined in /mod1/locallang.xml), note that the path is repeated:
Error: Could not open include file: F:/Inetpub/tp_itbetrieb/typo3conf/ext/ics_awstats/awstats/F:/Inetpub/tp_itbetrieb/typo3conf/ext/ics_awstats/awstats/dummy.inc.conf
After this message there is the iws_awstats error message "Der AWStats System-Aufruf ist fehlgeschlagen! Benutze den Debug-Mode um den Grund zu finden." (returned from CASE: ERR_AWSTATS_CALL_FAILED in moduleContent())
I avoid the error messages when I replace:
//putenv ('AWS_INCL_DECODEUTFKEYS='. $this->conf['awstatsFullDir'].'dummy.inc.conf');
putenv ('AWS_INCL_DECODEUTFKEYS=dummy.inc.conf');
//putenv ('AWS_INCL_GEOIP='. $this->conf['awstatsFullDir'].'dummy.inc.conf');
putenv ('AWS_INCL_GEOIP=dummy.inc.conf');
Now at least the script goes on to GeoIP Sections, but I haven´t configured GeoIP yet so it stops with an error message. But this is my next step. In any case it might be important for you to know of the problem.
Best regards
Andreas
Hallo Valli,
>> Sicherlich! Vielen Dank fuer die Rueckmeldung. Ich werde mich diesem Problem annehmen!
>> Moeglicherweise koennte es sich auch um einen awstats BUG handeln.
deine Vermutung war richtig. Ich konnte die Ursache in der awstats.pl isolieren, darin ist ab Zeile 1223 oder 1228 (durch Debugging Code nicht mehr ganz klar… entschuldige das eventuell stümperhafte debugging, Perl war bisher noch nicht mein Spielfeld ;o) ) eine Prozedur eingebaut die mit # Check Includes umschrieben ist. Ich hoffe du empfängst diese Mail im HTML Format damit du meinen Code (in rot) vom Original Code unterscheiden kannst. Spricht etwas dagegen diese Zeile zu ersetzen – vorausgesetzt es kommt ausschließlich ics_awstats zum Einsatz?
Nach Änderung der Zeile im Code bleibt mein ics_awstats im Perl Debugger zwar nochmal hängen, die Hinweise sind aber klar. Ich hoffe ich bekomme beide Dateien bei Maxmind:
Can't locate Geo/IP.pm in @INC
Can't locate Geo/IP/PurePerl.pm in @INC
Achtung für alle mitleser: der Code ist PERL, nicht PHP. Gibt hier aber leider kein en Auszeichner dafür. Im Code wird $1 ohne Punkte vom Forum geschluckt drum habe ich .$.1. verwendet:
# Check includes
if ($_ =~ /^Include "([^\"]+)"/ || $_ =~ /^#include "([^\"]+)"/) { ##include kept for backward compatibility
my $includeFile = $1;
# Expand __var__ by values
if ($Debug) { debug(" MOA includeFile in awstats.pl, ln 1227: $includeFile"); } ##
while ($includeFile =~ /__([^\s_]+(?:_[^\s_]+)*)__/) {
my $var=$1; $includeFile =~ s/__${var}__/$ENV{$var}/g;
if ($Debug) { debug(" MOA includeFile in awstats.pl, ln 1230: $includeFile"); } ##
}
if ($Debug) { debug(" MOA includeFile in awstats.pl, ln 1232: $includeFile"); } ##
if ($Debug) { debug("Found an include : $includeFile",2); }
if ($Debug) { debug(" MOA includeFile in awstats.pl, ln 1234: $includeFile"); } ##
if ( $includeFile !~ /^[\\\/]/ ) {
# Correct relative include files
# if ($FileConfig =~ /^(.*[\\\/])[^\\\/]*$/) { $includeFile = ".$.1.$includeFile"; } ########### <- .$.1. verursacht doppelten Pfad
if ($FileConfig =~ /^(.*[\\\/])[^\\\/]*$/) { $includeFile = "$includeFile"; }
}
if ($Debug) { debug(" MOA includeFile in awstats.pl, ln 1239: $includeFile"); } ##
if ($level > 1) {
warning("Warning: Perl versions before 5.6 cannot handle nested includes");
next;
}
if ( open( CONFIG_INCLUDE, $includeFile ) ) {
&Parse_Config( *CONFIG_INCLUDE , $level+1, $includeFile);
close( CONFIG_INCLUDE );
}
else {
error("Could not open include file: $includeFile" );
}
next;
}
Schöne Grüße nochmals in die Schweiz
Andi ;o)
Der Autor hat geantwortet, die Lösung des Problems betrifft Winwows Umgebungen. Ich habe es getestet und es funktioniert.
Hallo Andreas,
Das '$1' darfst du nicht einfach so loeschen. Das brauchts da!
Das problem liegt in folgender Zeile:
(Hier wird ueberprueft, ob $includeFile ein absoluter oder relativer Pfad ist.
Dabei entging dem Autor, dass absolute Pfade bei Windows mit dem Laufwerksbuchstaben
anfangen.)
...
if ( $includeFile !~ /^[\\\/]/ ) {
...
Diese muesste so lauten:
...
if ( $includeFile !~ /^([a-zA-Z]🙂?[\\\/]/ ) {...
Kannst du dies mal bei dir testen.
Falls es klappt, werde ich (oder du?) dies in das Awstats Bugreporting Tool
aufnehmen. Mit Glueck wird dies noch in AWStats 6.9 gefixt.
Gruss valli
Kann mir jemand sagen wo ich die purepearl.pm herkriege ohne sie selbst kompilieren zu müssen?