Moin Till,
ich bin hier über ein Problem mit AWStats und logrotate gestolpert und bin mir nicht ganz sicher, ob die Ursache bei ISPConfig oder beim Debian-AWStats-Paket liegt. Vielleicht kannst du das besser einordnen.
logrotate.service läuft bei mir auf einen Fehler:
Error while processing /etc/awstats/awstats.conf
Error: SiteDomain parameter not defined in your config/domain file.
You must edit it for using this version of AWStats.
logrotate.service: Main process exited, code=exited, status=1/FAILURE
logrotate.service: Failed with result 'exit-code'.
Ich habe mir das etwas genauer angesehen.
In der allgemeinen
/etc/awstats/awstats.conf
steht unter anderem:
LogFile="/var/log/apache2/access.log"
SiteDomain=""
HostAliases="localhost 127.0.0.1"
Daneben gibt es die von ISPConfig verwendeten Domain-Konfigurationen, z. B.:
/etc/awstats/awstats.domainname1.conf
/etc/awstats/awstats.domainname2.conf
/etc/awstats/awstats.domainname3.conf
Diese sehen beispielsweise so aus:
Include "/etc/awstats/awstats.conf"
LogFile="/var/log/ispconfig/httpd/domainname1/yesterday-access.log"
SiteDomain="domainname1"
HostAliases="www.domainname1 localhost 127.0.0.1"
Die Domain-Konfigurationen selbst sehen für mich also korrekt aus. Die allgemeine awstats.conf scheint hier als Basiskonfiguration zu dienen und wird von den einzelnen Domain-Konfigurationen eingebunden.
Beim Logrotate wird aber über
/etc/logrotate.d/httpd-prerotate/awstats
das Skript
/usr/share/awstats/tools/update.sh
aufgerufen.
Darin steht:
for c in `/bin/ls -1 awstats.*.conf 2>/dev/null | \
/bin/sed 's/^awstats\.\(.*\)\.conf/\1/'` \
`[ -f /etc/awstats/awstats.conf ] && echo awstats`
Damit werden einerseits korrekt die einzelnen
awstats.<domain>.conf
verarbeitet.
Durch
[ -f /etc/awstats/awstats.conf ] && echo awstats
wird aber zusätzlich die allgemeine awstats.conf als eigenständige Konfiguration verarbeitet, also praktisch:
awstats.pl -config=awstats -update
Und genau dieser Aufruf schlägt fehl, weil in der Basiskonfiguration:
SiteDomain=""
steht.
Das eigentliche AWStats-Update der einzelnen Domains scheint dagegen korrekt zu funktionieren.
Das Problem ist daher weniger AWStats selbst, sondern dass dadurch der komplette
logrotate.service
mit status=1/FAILURE endet.
Ich habe lokal einen Workaround gebaut, wollte den hier kurz teilen und besprechen, weil vermutlich auch andere ISPConfig-Installationen mit der Kombination betroffen sein könnten und ob ich damit richtig liege.
Ist die Verwendung von /etc/awstats/awstats.conf als gemeinsame Basiskonfiguration bei ISPConfig so vorgesehen?
Falls ja, wäre die Frage, ob das eher auf ISPConfig-Seite angepasst werden sollte oder ob das Verhalten des Debian-AWStats-update.sh, eine vorhandene awstats.conf grundsätzlich zusätzlich als eigene Site zu verarbeiten, hier das eigentliche Problem ist.
ich würde sonst: /etc/logrotate.d/httpd-prerotate/awstats so abändern:
ich bin hier über ein Problem mit AWStats und logrotate gestolpert und bin mir nicht ganz sicher, ob die Ursache bei ISPConfig oder beim Debian-AWStats-Paket liegt. Vielleicht kannst du das besser einordnen.
logrotate.service läuft bei mir auf einen Fehler:
Error while processing /etc/awstats/awstats.conf
Error: SiteDomain parameter not defined in your config/domain file.
You must edit it for using this version of AWStats.
logrotate.service: Main process exited, code=exited, status=1/FAILURE
logrotate.service: Failed with result 'exit-code'.
Ich habe mir das etwas genauer angesehen.
In der allgemeinen
/etc/awstats/awstats.conf
steht unter anderem:
LogFile="/var/log/apache2/access.log"
SiteDomain=""
HostAliases="localhost 127.0.0.1"
Daneben gibt es die von ISPConfig verwendeten Domain-Konfigurationen, z. B.:
/etc/awstats/awstats.domainname1.conf
/etc/awstats/awstats.domainname2.conf
/etc/awstats/awstats.domainname3.conf
Diese sehen beispielsweise so aus:
Include "/etc/awstats/awstats.conf"
LogFile="/var/log/ispconfig/httpd/domainname1/yesterday-access.log"
SiteDomain="domainname1"
HostAliases="www.domainname1 localhost 127.0.0.1"
Die Domain-Konfigurationen selbst sehen für mich also korrekt aus. Die allgemeine awstats.conf scheint hier als Basiskonfiguration zu dienen und wird von den einzelnen Domain-Konfigurationen eingebunden.
Beim Logrotate wird aber über
/etc/logrotate.d/httpd-prerotate/awstats
das Skript
/usr/share/awstats/tools/update.sh
aufgerufen.
Darin steht:
for c in `/bin/ls -1 awstats.*.conf 2>/dev/null | \
/bin/sed 's/^awstats\.\(.*\)\.conf/\1/'` \
`[ -f /etc/awstats/awstats.conf ] && echo awstats`
Damit werden einerseits korrekt die einzelnen
awstats.<domain>.conf
verarbeitet.
Durch
[ -f /etc/awstats/awstats.conf ] && echo awstats
wird aber zusätzlich die allgemeine awstats.conf als eigenständige Konfiguration verarbeitet, also praktisch:
awstats.pl -config=awstats -update
Und genau dieser Aufruf schlägt fehl, weil in der Basiskonfiguration:
SiteDomain=""
steht.
Das eigentliche AWStats-Update der einzelnen Domains scheint dagegen korrekt zu funktionieren.
Das Problem ist daher weniger AWStats selbst, sondern dass dadurch der komplette
logrotate.service
mit status=1/FAILURE endet.
Ich habe lokal einen Workaround gebaut, wollte den hier kurz teilen und besprechen, weil vermutlich auch andere ISPConfig-Installationen mit der Kombination betroffen sein könnten und ob ich damit richtig liege.
Ist die Verwendung von /etc/awstats/awstats.conf als gemeinsame Basiskonfiguration bei ISPConfig so vorgesehen?
Falls ja, wäre die Frage, ob das eher auf ISPConfig-Seite angepasst werden sollte oder ob das Verhalten des Debian-AWStats-update.sh, eine vorhandene awstats.conf grundsätzlich zusätzlich als eigene Site zu verarbeiten, hier das eigentliche Problem ist.
ich würde sonst: /etc/logrotate.d/httpd-prerotate/awstats so abändern:
Code:
#!/bin/sh
AWSTATS=/usr/lib/cgi-bin/awstats.pl
[ -x "$AWSTATS" ] || exit 0
for CONF in /etc/awstats/awstats.*.conf
do
[ -f "$CONF" ] || continue
CONFIG=$(basename "$CONF" .conf)
CONFIG=${CONFIG#awstats.}
su -s /bin/sh -l -c \
"nice -n 10 $AWSTATS -config='$CONFIG' -update" \
www-data
done
exit 0