AwStats plugin for DA [Still in BETA]

Cool! I've put the cron into the root now and ran it manually for once and it works now.

By the way, when this cron is used, it will also leave the webalizer run too right?

What does this do anyway??? Is this for direct admin stuff?

echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue
 
Can we get the plugin to work with subdomains in DA (install the script on a subdomain and view the stats for that sub-domain)?

If so how do I get it to work as only the main ddomains are listed.

Regards,
Onno
 
log rolling

I've got some domains that aren't having their historical logs processed correctly.. after their logs get rolled into /home/username/domains/logs, those logs are no longer accounted for in awstats. Any way around that currently?
 
Just updated but the installer overwrited all the configs in /etc/awstats the problem is these all had my custom changes in as I do no want to allow manual stat refreshing, is there a way to mass spread my own config again to existing domains? Also can future versions be made not to do this.
 
Hi fusionictnl and all.

First let me thank and congratulate fusionictnl on all his hard work for the community. Much love, fusionictnl.

Amazingly enough, I've spent the last hour reading through all the posts. Lots of good information in here, probably needs to get compiled someday into a mini-howto. :D

I'm running a clean install of Fedora and DA with PHP v4.3.10.

My questions:

1) When I download the AWSTATS plug-in via DA ( Install after upload is checked off ) I get the following error message:

Error unpacking /usr/local/directadmin/plugins/awstats/plugin.tar.gz : Error restoring file /usr/local/directadmin/plugins/awstats/plugin.tar.gz

I saw this question already asked previously and the response was to remove and install. Well, I've done it 4 times to no avail. I even tried downloading with install option turned on and still get the same message.

What does this error message mean and how can I make it not appear? How can I be sure it's not a problem. The download seems to work and unpack as I see the /usr/local/directadmin/plugins awstats folder with all its files and I can install and activate the plug-in.

2) After installing the AWSTATS plugin I noticed that webalizer appeared in the user directories.... (Maybe the existed before and I didn't notice?)

/home/<user>/domains/logs
/home/<user>/domains/stats

Are these part of AWSTATS? Or was webalizer installed with DA? Does AWSTATS or the AWSTATS plugin need webalizer?

3) Are these the correct steps to fully remove the awstats plug-in?

a. As DA admin, Deactivate and Uninstall the awstats plug-in.

b. rm -rf all of the following directories for each user and domain:
/home/<user>/domains/<domain_name>/public_html/awstats

c. rm -rf /etc/awstats

Are there any more steps to take besides those 3 above?


4) Looking at the install script I can see that /awstats is created for each domain upon initial install of the awstats plug-in. Please clarify if this is intended behavior. From reading the posts is sounded like this was only suppose to happen if you execute alldomains.php.

5) Is there a config setting so all new users added after the AWSTATS plugin is already installed are defaulted to having access the awstats plug-in?

Answer: This thread explains a method.

6) In the alldomains.php you try to issue a command:

chmod -L 755

This gives and error with my chmod... are you just trying to be compatible with other versions of Linux?

Thank you for your help.
 
Last edited:
m...
I have made a copy of the old .txt files and I am proceding to force an update of the stats, to see if the results improve..


fusionictnl said:
albatroz I definitly see a big difference, but can't think of anything else than that the logs are wrongly written by apache, or the history files are somehow corrupted in the /etc/awstats/ (the .txt files)
Click to expand...
 
Sorry for the late response, but as explained earlier I have emailed DA with the intention to help them implement this plugin and like always they don't respond to it. So I'm not sure if they will ever implement it. But I'm not further developing it, only security fixes that affect the plugin/system stability.

resolveit: Only if you create them as a domain. Awstats doesn't handle them seperatly as far as I know.

hardlines: If they get rotated they will no longer be processed and there's no need for it as Awstats keeps historic files in the /etc/awstats/[domain].txt

Chrysalis: In the /usr/local/directadmin/plugins/awstats/hooks there should be a default awstats conf file that will be used for it. Change this and backup it when upgrading to a new version. I can't really keep the old one as new changes in the log files (newer versions and improvements) aren't changed.

srelliott:

1.Did you remove the complete awstats dir in the plugins before re-installing ? Normally there shouldn't get any errors.

2./public_html/awstats (is the only user Awstats dir) the other ones are Webalizer stats files. You can't JUST remove these files as Webalizer is part of DA

3.Uninstalling: rm -Rf /usr/local/directadmin/plugins/awstats (double check the syntax ;))

4. That's normally as that file is the webpage that shows the statistics ;)

5. echo $domainname >> /usr/local/...../hooks/permissions.txt (don't know the exact syntax, but that should be axplained in the topic). After that the user can manually install the plugin in it's userpanel.

6. Alldomains.php does have a hence of settings to set the correct permissions as every distro respond differently to php set mods and system chmod and sometimes just ignores them. So that's why there are a lot of different ways implemented. Not to worry ;)

albatroz: If the results doesn't improve, check your log files and compare them with the LogFileFormat in the /etc/awstats/somedomain.conf

malachor: This plugin isn't under construction anymore. As posted a while ago support has been stopped for implementing new features. Reason is explained there. But thanks for the offer.
 
Last edited:
fusionictnl,

1) Yes, completely removed before installing, including the /etc/awstats dir. The plug-in upon uninstall kills off the /usr/local/directadmin/plugins/awstats directory.

I watch the plugin-in create the ./plugings/awstats dir, download the .gz and unpack it. It just makes me wonder why I'm getting the unpack and restore errors.

Maybe an incompatibility with the Fedora version we're runinng.... do you know what the command line commands are that are being issued? I could try them manually and see if I get an error on the command line. Bottom line, is that it installs and seems to work just fine.

2) Thank you.

3) If syntax refers to the captial 'R' instead of lowercase 'r' in rm -Rf, in my version of fedora, they're both the same. If you're referring to /etc/awstats, I'm deleteing that directory as well as making sure the /usr/local/directadmin/plugins/awstats directory is deleted too. Thank you.

4) Ok, so working as intended. All existing users get created an awstats folder upon installation. Thank you.


5) The way easiest way I found was to create a domain_create_post.sh in the ./scripts/custom directory with this command:

/usr/local/directadmin/plugins/awstats/hooks/awstatsinstall.php -id ${domain}

Thank you.


6) Got it, just making sure. Removed the offending lines for my particular distro. Thank you.

--
Shannon
 
Ok thanks for reply, since you wont be developing it I guess I will need to make a script that can mass distribute the backup to the domains in the /etc/awstats dir after each upgrade. I do currently backup my config but have know easy way of applying it again to all the domains.
 
The problem (and I'm sure anyone who has been working with awstats for any length of time knows this) is that occasionally, they add new things to the conf file. So simply replacing the conf file with a backup may not be the best plan.

I'm not sure what the best plan is, I can tell you that with my setup, I have several statements in a separate file. These are generic across all my domains. I have a perl -p -i -e statement that that adds an include statement into each of my conf files. I run it after every plugin update. This way my changes always get applied back to the conf files.

I'm sure there are other (and possibly better) ways to accomplish this. I'm just sharing how I fix the problem.

=C=
 
heh thats what I need, I am somewhat poor at bash/perl scripting, I need to run a script that makes the changes to a mass number of files in one go :) so for example. to all files in /etc/awstats awstats.*.conf.

The following changes.

AllowToUpdateStatsFromBrowser=0
old value - AllowToUpdateStatsFromBrowser=1
EnableLockForUpdate=0
old value - EnableLockForUpdate=1
DebugMessages=0
old value - DebugMessages=1
LevelForWormsDetection=1
old value - LevelForWormsDetection=0
ShowWormsStats=1
old value - ShowWormsStats=0
LoadPlugin="tooltips"
old - value - #LoadPlugin="tooltips"
LoadPlugin="hashfiles"
old value - #LoadPlugin="hashfiles"

old value been what the default is.
 
Well, no promises because I'm no perl monger myself but I would put all of those in a separate file, call it mySettings.inc

Then in your /etc/awstats directory do something like:

perl -p -i -e "s/\#Include \"\"/Include \"\/etc\/awstats\/mySettings.inc\"/g" *.conf

That should add it in at the very bottom of your file.

Does that help?

=C=
 
thanks will try this, but I am curious what will happen because some settings will be duplicated eg. I will have 'EnableLockForUpdate=0' i nmy include file and then it will be repeated again as 'EnableLockForUpdate=1' in the main file.
 
Chrysalis said:
Done it and seems to have worked, wow nice stuff thanks.
Click to expand...

exactly what does not work?

oh, 500 error. Deeper problems. Check your apache logs and see what it's telling you. This isn't necessarily an awstats issue. My guess is it's a perl issue.

=C=
 
i though it was a perl issue also, but perl seems to be working just fine via ssh, but output isnt.

i checked permissions and everything and i cant find anything wrong
 
You must log in or register to reply here.
Back
Top