Filippo Carletti wrote: >I was going to rebuild the sarg contrib on SME5 and I thought about a couple >of little cosmetic changes. > I'm asking your advice. > > - Is e-smith.domain.com/squid-reports a good choice for the URL to access >the reports ? Better suggestions ?
I'm configuring a SARG/log environment on my system, and I think that the i-bay way is not the better choice for it, because there's no need for FTP or SMB access to SARG/log report directory. One of the main strenghts of SARG is its ability to manage historical summaries, beside the simple log analisys "on the fly". To cache in this value, one must work on the squid log management, too: logrotate put away squid logs every week, and keeps only the last five weeks older logs. If one wants to present log on a periodical basis, let's say collect monthly summaries, there's the need to save squid logs in a global file in some standard location, keeping an eye on it not to let it grow too big and syncronizing SARG runs to produce monthly reports only. Besides, while the squid log management must be done by admin, the log analysis could be left to some other person that does not need admin privileges. On my free time scraps :), I'm following this way. I grabbed sarg-esmith-40.tgz by Hugues Michel <[EMAIL PROTECTED]>, extracted sarg-1.1.1 binaries, ignored everything else, analyzed the install script and copied the sarg binaries and needed support files in the right directories - the /usr/local/sarg tree. To store SARG reports, I made a ./log/sarg directory under /home/e-smith/files/primary, then created a httpd.conf custom fragment to define a /log alias and a /log directory protected by a .htaccess file and internally accessible only. Then I configured SARG to create reports in the .../log/sarg directory, starting from an access.log that resides in a different location than /var/log/squid. In this directory, there is a global file that accumulates the squid access.log files: periodically I run a script that appends the gzipped access logs and deletes them. After the first new month log rotation and log accumulation, I run another script that "slices" away from the global file the entries related to the last month. Finally, I copy this last file as access.log.<month> and as access.log, and run SARG, so it creates the reports I want where I want it to do it. These report are now available for review by another person that has a normal account on the ESSG system. Only that person can view the logs because his account is the only one specified in the .htaccess file. My final target consists in having all the log summaries I need in their subdirectories of choice, starting from the main /log url, and available only to authorized personnel on directory basis - let's say, by example, that the system summaries made by Calamaris are interesting only for admin and system operators, while SARG summaries, being more descriptive of personnel behaviour, should be considered reserved and accessible to some persons only. I'm moving my first steps here: while the SARG part is simple to implement, the log management is still rudimental. I'm still thinking about how to automate this process dependably. On a side note, it would be fine to let authorized personnel generate reports based on the live access logs on the fly... this would require some scripting on the server, though, something like the cgi scripts in the sarg-esmith-40.tgz... My personal point of view, of course. -- Pierluigi Miranda -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
