[Pkg-awstats-devel] RFC - cron-related stuff

Sergey B Kirpichev skirpichev at gmail.com
Thu Apr 16 10:18:13 UTC 2009


On Mon, Apr 13, 2009 at 12:25:54PM +0200, Jonas Smedegaard wrote:
> This is your approach (please correct me if I am wrong:
> 
> logrotate[root] < httpd > logs[root:awstats]
> awstats[awstats] < logs[:awstats] > stats[awstats:www-data]
> awstats[www-data] < stats[:www-data] > httpd
> 
> It won't work out of the box: It requires changes to a logrotate script 
> not owned by our package, so cannot even optionally be automated by us.

Yes.  But it's easy to customize by local admin (one line changes in
logrotate.d/* configs).

But, after our discussion, the second line is:
awstats[awstats] < logs[:awstats] > stats[awstats:awstats]
No web access.

> When working, raw logfiles are only usable by awstats - other packages 
> (e.g. alternative log analyzers, perhaps even security surveillance) 
> cannot concurrently access them without even more custom changes.

Yet simple...  Just add them to awstats group (no security issues).

> This is my approach, improved to not use root access but another user 
> member of both adm and awstats groups ([:awstats] means read-only by 
> members of awstats group, writable only by same user):
> 
> logrotate[root] < httpd > logs[root:adm]
> awstats-adm[awstats-adm] < logs[:adm] > logs[awstats-adm:awstats]
> awstats < logs[:awstats] > stats[awstats:awstats]
> awstats[www-data] < stats[:www-data] > httpd
> 
> It won't work out of the box: Stats are generated but accessible to 
> noone by default.  Changes needed are possible to automate, however, as 
> they involve only groups memberships and/or our own config files.
> 
> When working, raw logfiles are untouched, so usable by other packages 
> too.

Personally, I'm dislike this copying stuff (as more error prone).

> Yes, we can throw all sorts of files in as examples.  Examples are 
> unreliable, it is something that we do not support.
> 
> With my proposal we can extend our *supported* routines to support 
> several approaches to virtual hosting.  And we can extend our 
> *supported* routines to automatically enable fully working, 
> web-accessible stats (yes, I _do_ want that to be possible, I just don't 
> want it to be the default).

> With my approach we need the location, possibly in multiple scripts, so 
> it makes sense instead to save the location in /etc/default/awstats.

If user want's piped logs?  Or gzip'ed?  Now it all can be handled in just
one place (/etc/awstats/awstats.example.com.conf).

> Yet another thing the local admin needs to do manually which we cannot 
> later automate :-(

If we have a working setup for parsing stuff (as package is installed),
then we would enable crontab entry.
Right now (and before), default awstats setup doesn't work from
begining.

So, my suggestion is to merge first static pages stuff (and use
separate awstats:awstats user/group for /var/lib/awstats).  I will do
this at weekend or on the next week.

And then we can try to tune crontab entries (include some wrapper to access logs in
adm group).

> It is better to provide master config below /etc/default than requiring 
> the admin to edit multiple configfiles in different formats.
> 
> Also, files below /etc/default must use a specific format that we can 
> later automate and provide a debconf interface for.
> 
> Would be _very_ nice if we some day could make it possible to preseed 
> awstats for use out-of-the-box at various security levels.

Then, anyway, we _must_ automate also /etc/awstats/awstats._site_.conf
stuff (virtual host names etc).  Doesn't look nice.

M.b. we can instead use just some sed/awk/grep stuff in /etc/cron.d/awstats to
receive LogFile info?



More information about the Pkg-awstats-devel mailing list