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

[Sergey B Kirpichev]

Hello.

Hope, this post will clarify my point.

>Here's a summary of how I understand your proposal (added leading
> interface and paranthesis around routines breaking the chain from
> working out-of-the-box):

> cron:   logrotate[root] < httpd > logs[root:adm]
> admin: (edit logrotate to output logs to root:awstats)

Or just add awstats to group adm.

> cron:   awstats[awstats] < logs[:awstats] > stats[awstats:awstats]

Yes.  Put raw statistics in /var/lib/awstats.  Permissions:
awstats:awstats, 0750 (now: www-data:www-data).

> admin: (edit cron to output stats to awstats:www-data)
> cgi:    awstats[www-data] < stats[:www-data] > httpd

No.  We just generate static html statistics (/var/cache/awstats) with
buildstatic.sh in crontab.  Permissions on directory should be:
awstats:awstats, 0750 (now: www-data:www-data).

We can guide user (via debconf or README.Debian) how to make html
accessible via web server.

> In other words, you propose to have neither stats nor CGI usable without
> admin customization.  Or did I miss something?

No.  Only CGI.

Yes, my proposal looks like above.  Just to clarify local admin's steps:

1. install awstats package
2. configure /etc/awstats/awstats.conf (by hand or via debconf
questions), optionally add other virtial hosts like
/etc/awstats/awstats._site_name_.conf
3. chgrp to awstats on log files (via logrotate) or add awstats to
group adm (this can be automated via postinst)
4. enable cron jobs (commented out by default) for parsing and
building of the static reports

Optionally, enable web-access stuff.  For example:
5. chgrp www-data /var/lib/awstats

We can simplify things to local admin as possible, document preferred
workflow(s) in README.Debian.  No more.

Steps 2-4 sould be automated.  First: 3 (alternative in debconf:
awstats to group adm or manual setup with README.Debian).  Second: 2
and 4 (via debconf).

> Here's an improved draft of my proposal:
>
> cron:   logrotate[root] < httpd > logs[root:adm]
> cron:   cp[awstats-adm] < logs[:adm] > logs[awstats-adm:awstats]
> cron:   awstats < logs[:awstats] > stats[awstats:awstats]
> cron:   cp[awstats-adm] < stats[:awstats] > stats[awstats-adm:adm]
> admin: (edit /etc/default/awstats to cp > stats[awstats-adm:www-data]
> web:    awstats[www-data] < stats[:www-data] > httpd
>
> Provides stats out-of-the-box (but readable only my admins).
>
> Can later be enhanced:
>
>   * admin task can be implemented as debconf question in postinst
>   * cp can be replaced with smarter wrapper (gzip, ip resolving, etc.)
>   * tiny piping tool can be provided, by default useless but optionally
>     (through debconf) suid awstatsadm, for safer-than-direct realtime
>     access to logfiles

> I agree that it requires more disk space.  And that it restricts ability
> to use fancy features of AWStats.  But I cannot see how it is more
> risky. But how is "cp" more error-prone than allow AWStats access to the
> file (and everything else with same access rights!)?

It's not uncommon to have daily log files ~ several Gb.  Do you really
want to copy (rsync) them every 10 minutes?  Between diffrerent disks
(e.g., /var/log/
and /var/)...

Second, you can't seek on pipe, so "tiny piping tool" force AWStats to
scan over all log file (jet, may be we can use logtail...).

So, "cp" solution is just horrible.  "Tiny piping tool" solution -
better, but still very complex, compared with "insecure" "awstats to
group adm" solution.

Just to note: webalizer package has the same problem.  It's shipped
with easy (but "insecure") solution: parse log files as root.  Another
example is logcheck package (logcheck user belongs to group adm).