AwStats plugin for DA [Still in BETA]

OK, I tried to unistall and then delete this plugin and install it again....and i am still getting

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Does it work in new DA at all?
 
It is working properly for me on 1.22.6

Did you follow fusionictl's instructions completely? Not only removing the plugin from DirectAdmin?
 
New Feature request:

Create a page for the admin level with the options to install or uninstall integration with the Site Summary / Statistics / Logs page integrate with webalizer.

The implementation idea I came up with migh do the following when the install button is pressed by the administrator.

a. Remove the normal AwStats link that is used now
b. Create a backup of the Site Summary / Statistics / Logs
skin file
c. Open up the the Site Summary / Statistics / Logs skin file and search for a specific/unique line regarding the webalizer table which it would then replace with new code.

The new look might be something like this:
a. The word webalizer would be removed so it just said 'Domain Stats'
b.The domain names would not be links anymore, instead to the direct right would be a webalizer | awstats links for whichever. When awstats is selected it would run a check and if it wasn't already installed it would install it, otherwise it would load the normal awstats page.

(maybe an option to replace the webalizer link altogether, it would work the same way it does now only awstats would be in webalizers place. How does DA parse its bandwidth usage? If it doesn't do it with webalizer why not a script to totally remove it, hehe)

Tell me what you think, good/bad, needs a little change whatever.
Since it appears DA is not going to replace or add awstats as a normal integrated solution I think this is the best way to go.

Although option two just came to mind as I'm typing this:
Do something like Cpanel did where you have an option page to chose which program you want to view the stats with. This would leave room for easier integration or the possibility of expanding (such as instead of the awstats plugin, a general stats plugin which might also include analog :p )
 
You can't totaly remove webalizer, as DA shows the bandwith usage by webalizer in the CP. So removing it would run into some problems.

It is damn easy for DA to implement Awstats in the panel, as it is only one simple perl with a config file. The way I have to do it with the plugin is very complicated, as I only have access on 1 run (Install.sh) when you install the plugin.


kamsel

The new DA doens't change anything for the plugin. Did you move /etc/awstats to something like /etc/awstats_old?

Then reinstalled the plugin ? As the problem you have is definitly a problem with the rights on /etc/awstats

;)
 
fusionictnl said:
It is damn easy for DA to implement Awstats in the panel, as it is only one simple perl with a config file. The way I have to do it with the plugin is very complicated, as I only have access on 1 run (Install.sh) when you install the plugin.
Click to expand...

I know, maybe we should have another request drive and poll for it :)

But in the mean time just thinking of other workarounds.
Since everything is executed as admin it would make more sense to use the php 'exec' command to run commands on the system itself. It would basically have the same functionality as admin would while logged in ssh.
 
Still it wouldn't have the rights of root. But as far as the workaround goes it shouldn't be any problemen. As install.sh is ran by root and sometimes like the problem above the directories aren't set to full acces to everyone :s (chmod :()
 
I'll have some spare time next week if you'd like me to fiddle around with it. Business has been kind of slow lately....

Maybe we should bring that AwStats feature request thread back from the dead.
 
Last edited:
This could be a better alternative than working with this workaround. DA could build this feauture in the panel pretty quick, probaly 2 hours work :) As it is quite simple.

If the feature is in it. I could make the plugin to only alter the config file and make some limitation option on admin/reseller levels. And settings (more advance than now) on user level.

You can think of custom logo's per/reseller etc.
 
fusionictnl, yes I have tried to reinstall this script again [ moved /etc/awstats to /etc/awstatswhatever ]....no luck

what chmod should I give for this directory?
 
Hi,

How do I COMPLETELY remove every file, anything that this plugin has installed/putted/changed in DA, because no matter what I try I am getting error 500 ?
I tried to deactivate/unistall/remove change file premissions and so on...didn't help.

kamsel
 
Make sure the plugin has been removed from /usr/local/directadmin/plugins/

Make sure /etc/awstats/ was removed
As well as the awstats directory in each users home directory which may have installed them. (/home/username/domains/*/public_html/awstats)

You may also want to check all cgi-bins in the public_html directory that they are chmodded correctly and belong to username:username

I believe that is everything.
 
The cgi-bin files are sym-links, these have permissions set to all.

The user dir files can be removed /home/user/domains/domainname/public_html/awstats


If you're getting errors, look at previous problems:

- Check /var/log/httpd/suexec_log
- Check /var/log/httpd/domains/domain_error_log

In these logs you probaly find out:

suexec is giving some permission problem: User/Group aren't the same as the user: Rights on the /awstats dir in users public_html is incorrect.

apache giving some strange error: the awstats.pl file in the public_html /awstats dir is not set to be executable.

Last problem could be that the .htaccess file isn't in the users public_html /awstats dir.

And offcourse there should be at least in the /awstats dir, the following files:

awstats.pl and .htaccess.


If all of these are correct than awstats should run. It's dead simply a perl cgi-bin script, nothing more. Any errors relative to the /etc/awstats dir should be viewed in the browser by awstats.
 
Hello,

Here is what I am getting in /var/log/httpd/suexec_log after I access to domain.com/awstats

[2004-09-29 12:42:08]: Jailing kamsel to |HOME|
[2004-09-29 12:42:08]: error: unable to chroot to jail_dir: |HOME| : No such file or directory

I do not understand what does jailing have to do with awstats plugin, but also: I did not set up jailing for this user.

In error_ log however, I see:

[Wed Sep 29 12:42:10 2004] [error] [client X.X.X.X] Premature end of script headers: /home/kamsel/domains/domain.com/public_html/awstats/awstats.pl

Also, before installing the plugin I checked out if plugin was removed from DA [ in DA panel and in shell ], I also completely removed /etc/awstats dir and all files that were places in cgi-bin [ if that matters...I tried everything ]

And yes, awstats.pl and .htaccess do exist after installing awstats on domain.

Very weird problem.
 
---------
[2004-09-29 12:42:08]: Jailing kamsel to |HOME|
[2004-09-29 12:42:08]: error: unable to chroot to jail_dir: |HOME| : No such file or directory
----------

You have some sort of jailing running on this domain. The files in the user dirs also use symlinks out of the users home, so with jailing you will run in some problems.

Further more:

At the same time in the error_log (premature end of script headers) the line shows up, giving you information that there is something wrong. The times match up "error_log" and "suexec_log" so the message about jailing is the problem.

Do you use any jailing on you're server? This is definitly the problem.
Wich jailing do you use? The one specified in another topic on this forum about jailing ? Make another thread in an other topic, so someone else could try to help you. As my information about jailing is limited and I don't use any jailing at the moment. And it is limited to none supported by DA.
 
Hello,

Thanks fusionictnl, yes indeed it happened because of "jail".
Now plugin works just fine.
Agh

thanks again and sorry for late answer but I didn't have time this week,

kamsel
 
The only real problem I have with this plugin is that users will have two stats programs running on a daily basis Having both webalizer and awstats both run for each and every domain does not sound good in terms of server load. And since I have Urchin licenses, this will really test a servers will :) Of course this is not the fault of this great plugin. Good work. I just wonder hw people plan to deal with this.
 
rldev said:
The only real problem I have with this plugin is that users will have two stats programs running on a daily basis Having both webalizer and awstats both run for each and every domain does not sound good in terms of server load. And since I have Urchin licenses, this will really test a servers will :) Of course this is not the fault of this great plugin. Good work. I just wonder hw people plan to deal with this.
Click to expand...

It isn't run on a daily basis, unless you set it up that way.
The default install will only update a users statistics after he installs awstats on that domain and then will only update when the user clicks on the update button within awstats. At least thats how it works for my clients.
 
So what happens if a user doesn't update his/her stats until after the log is rotated? Then they will not have the stats in AW Stats, correct?
 
If the log were to rotate then the user would lose all stats between the time he last updated and the time since the new log began. Thankfully DircctAdmin does not rotate logs based on time but by size (I believe the default is 100mb)

So this could be a problem. Best solution I can think of right now (other than having it run nightly on all domains) is to have a small script run right before DA does its tally as well as logrotate checks in the crontab.

That script would:
1. Check all domain.com.log file sizes
2. Determine if they are going to be rotated by DA (size > rotate size setting)
3. If so, run a check of all logs to be rotated and compare to domains in /etc/awstats
4. If match(es) are found it would commence the update of stats for that domain.

This method would at least stagger the updates since users would reach the rotate filesize at different points in time and you wouldn't have it run on all domains at the same time awstats is.
 
You must log in or register to reply here.
Back
Top