AwStats plugin for DA [Still in BETA]

[fusionictnl]

NOTE: This plugin appears to be unsupported; the author hasn't posted on the DirectAdmin forums for over 15 months.

This Plugin will update all awstats.pl to the current awstats version

AwStats DA Plugin (http://www.fusion-ict.nl/da_plugin/awstats.tar.gz) : v.2.1.9 09-Jan-2006 (GMT+1)
Awstats Version: (Auto-Update)

Click this link if you want to donate (https://www.paypal.com/xclick/business=paypal%40fusion-ict.nl&item_name=Awstats+Plugin+for+DirectAdmin&item_number=AWDA01&no_shipping=0&no_note=1&tax=0&currency_code=EUR) and maybe it will get better :p it's STILL free :)

ALWAYS USE LATEST DA RELEASE - EXTRA FEATURES AREN'T ADDED ANYMORE, SO DON'T REQUEST

Use the above url in your DA Plugin Management to install (Admin-Level).

On user-level users, can activate awstats on their domain through the control panel.
It creates a /awstats for the specified domain. So you can browse to: http://www.yourdomain.com/awstats
and see the statistics.

Admin-level, choose wich users can access awstats plugin.

It features password protection and all other awstats functions.

Let me know if it works or if there are any problems ;)

If you want to install awstats to all domains, login as root on your machine and run: /usr/local/directadmin/plugins/awstats/hooks/alldomains.php

For use in a Cron
Add to cron: /usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats_updateall.pl now -awstatsprog=/usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats.pl

*OR*


Replace:-

10 0 * * * root echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue

With:-

10 0 * * * root /usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats_updateall.pl now -awstatsprog=/usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats.pl && echo 'action=tally&value=all' >> /usr/local/directadmin/data/task.queue



I Have added an option (ver > 1.4) to the awstats_updateall.pl: -rotated=[size]

This size is in MB's and this will let the update only update the log's bigger as this SIZE ;) So : -rotated 99 will only update logs bigger as 99 MB. (For example da logrotate size)


I don't recommend upgrading the awstats.pl yourselfs as the original has a minor bug/feature in it, that would let you read any stats for any apache log file. (This is a customized version of AwStats and a customized version of the awstats_updateall.pl with some extra's in it).

As of 2.0.5 there is an other tool added in the hooks: awstatsinstall.php (heavily documented). This can be used to install/update/check the awstats installations of the plugin! Thx to: Cal Evans


Automaticaly give access to stats to new users

# cd /usr/local/directadmin/scripts/custom
# vi user_create_post.sh

Add the following to the new file or add the line if exists:




#!/bin/sh
echo $username >> /usr/local/directadmin/plugins/awstats/hooks/permissions.txt



# save the file VI command ( 'ESC' then ':' then 'wq!' )
# chmod a+x user_create_post.sh

This should now automaticaly add new users to the permissions file!


Use /usr/local/directadmin/plugins/awstats/update/update.sh to update your awstats, to the latest version!!

Some people asked if they could donate something to the good of me :) I created the plugin for myself and are sharing it among others of the DA community. So please don't feel like you'll have to donate. This is just for the people that want to thank me for it! And offcourse I appreciate it, as well as you don't.


Good luck!

[fusionictnl]

Updated v0.2:

*- History files will be written to /etc/awstats (faster reporting)
*- Seperate AwStats config files will be generated to /etc/awstats for futere settings (per user).

[fusionictnl]

Updated v0.3:

*- Users with multiple domains can choose wich domain to show.

[fusionictnl]

Updated v0.4:

*- Plugin name is correct.
*- Admin/Resellers can view his/her own domains on User Level
*- Multiple domain bug (users could access every domain stats) fixed.
*- Script name is changed to awstats.tar.gz, old update doesn't work

Let me know if there are things that don't work or should be added!

[jmstacey]

Stats for domains under admin user are not working. here is the error message.
----- awstats 6.2 (build 1.761) (c) 2000-2004 Laurent Destailleur ----- awstats is a free web server logfile analyzer to show you advanced web statistics. awstats comes with ABSOLUTELY NO WARRANTY. It's a free software distributed with a GNU General Public License (See LICENSE file for details). Syntax: awstats.pl -config=virtualhostname [options] This runs awstats in command line to update statistics of a web site, from the log file defined in AWStats config file (with -update option), or build a HTML report (with -output option). First, awstats tries to read awstats.virtualhostname.conf as the config file. If not found, awstats tries to read awstats.conf Note 1: Config files (awstats.virtualhostname.conf or awstats.conf) must be in /etc/awstats, /usr/local/etc/awstats, /etc or same directory than awstats.pl script file. Note 2: If AWSTATS_FORCE_CONFIG environment variable is .......... and it just goes on a page or so more.
So it appears it is not executing just reading the file.

also, something wrong with the code used in the plugin link that displayed on the user levels etc when DA is secured. The error message is about a part of the page is not secure, only change was this plugin

Hope this helps a little.

[flumps]

would just like to say ive installed this on my box and it works a treat, nice work dude :D

[thuskey]

Does awstats need to be preinstalled on the server? I do not have awstats preinstalled. After running the install, the link appeared, I clicked it, and it went to a standard enhanced template page which was blank in the content area. I've gone as far as adding an echo "AwStats"; at the top of the index.html file, which now is the only thing that appears in the content area.

I'm also playing with a plugin of my own which now has a bolded link, caused by your <B>AwStats Statistics<B> syntax in the user_txt.html file which should read <B>AwStats Statistics</B> enstead.

[thuskey]

I answered my own question. No you do not have to have awstats preinstalled.

I did however make the following changes.

1)in file user_txt.html added closing slash in bold tags.

<B>AwStats Statistics</B>

2)in file index.html

#$dir=$_ENV["DOCUMENT_ROOT"]."/../hooks";
$dir="/usr/local/directadmin/plugins/awstats/hooks";

when echoing $dir on my server, I found the value for $_ENV["DOCUMENT_ROOT"] is always null. Maybe it is different on other servers.

all in all, cool plugin, I hope this sparks others to start developing a few more plugins of their own :)

[fusionictnl]

...... also, something wrong with the code used in the plugin link that displayed on the user levels etc when DA is secured. The error message is about a part of the page is not secure, only change was this plugin

Link changed ;)

Look at your URL when you open op the plugin. Does it say something like ?domain=... ?

Did you first delete your plugin completely (because you already had one installed?) If not do so and check /usr/local/directadmin/plugins if there isn't any trash in it ;) (probaly not). And then re-install it. (maybe the last update fixed some things for you, I hope).



1)in file user_txt.html added closing slash in bold tags.

Changed


$dir="/usr/local/directadmin/plugins/awstats/hooks";

Changed, probaly less problems, but I don't know if everybody has da in /usr/local/directadmin ;)

You can just Update your plugin. It should then be version 0.5 ;)

[jmstacey]

Whenever I try accessing the user level I get a warning message still.
"This page contains both secure and nonsecure content...."
It is because of the small image you have in it since its not on a secure server ;)

I did uninstall and delete the old version before installing the new one but stats are not working on any accounts. Still displaying the same message.
All user urls are CMD_PLUGINS/awstats
thats it, so it looks like its not putting in the domain correctly, or displaying the list to select multiple domains from depending on how you did it.

[fusionictnl]

You're running Da on HTTPS :)

You can fix it by changing the user....txt file in /usr/local/directadmin/plugins/awstats/hooks/

Removing the <img src......>

[thuskey]

Originally posted by fusionictnl

Changed, probaly less problems, but I don't know if everybody has da in /usr/local/directadmin ;)


I found a more proper fix for my DOCUMENT_ROOT problem. I changed the line back to the way you had it and modified the association line at the top of the index.html file to look like this.

#!/usr/local/bin/php -c /usr/local/lib/php.ini
.
.
$dir=$_ENV["DOCUMENT_ROOT"]."/../hooks";

[fusionictnl]

Thx will be added next release ;)

Some points I'm going to add:

-- Let users choose if they want to have a cron job and export it to a defined path for ex. http://www.xxx.xxx/awstats
This way all links will work and frames (Standard) can be used.
The stats in the CP will then be removed, it will only be for the statistics options.

-- Users can modify it's config, for example the plugins DNS Lookups etc.

-- Resellers could choose wich users can change the options or add cronjobs. (No cronjobs will disable it for the user)

-- Resellers can create a default configuration file, wich will be used for their users.
This way if some AwStats plugins are to heavy load for the server, the reseller can define a standard configuration file and deny users from modifying it's own configuration file.

Fixes:

- ENV: Document root (prev. topic).
- HTTPS problem, fixing by using the local picture's instead of http://www.awstats.org

If you have any comments on above features or how it should be implemented on a better way, please tell me ;)

[hostpc.com]

Dude, THANK YOU!

Tho this only reports for the current log cycle, it's gonna be a blessing for some of my customers that can't stand webalizer. Awstats rocks (as far as free stats goes).

There are some issues however. I tried to click on
Referers: Refering sites and got this error:


Unable to execute your request

Details

That plugin does not exit for the specified User Level


Does not exit? Exist maybe? Is that a seperate plugin? The item links to: http://hostpc.com:2222/CMD_PLUGINS/awstats.hostpc.com.refererpages.html

Any thoughts?

Thanks again!

Joe

[fusionictnl]

There is a problem with the links, because these require some static page's or the awstats.pl I'm working on it.

I'm testing 2 things:

- Static page's generated by a cron
- Put the awstats.pl in each users ./cgi-bin/ dir.

Probaly for the next release I will take the second way ;) Always the easiest way, so you guys and my customers can use AwStats to the fullest a.s.a.p.

Scripts from AwStats that generate the static pages, doesn't have enough configuration options. So that's why I'll use the awstats.pl instead of static reports. This way The plugin doesn't have to change to much on the system ;)

[hostpc.com]

tried copying off awstats.pl to a users cgi-bin.... wasn't that easy, but maybe I missed a step.

Just FYI.

[fusionictnl]

This will be automaticaly in the next release ;)

You don't have to do anything right now ;)

[hostpc.com]

my users are giddy with anticipation ;)

[fusionictnl]

It's almost finished the second release ;) This will generate static pages for your domain: http://www.domain.xxx/awstats/

this way all links work ;)

[rldev]

Why not set it up so that it runs in a server wide cgi-bin. This makes it very easy to update and should operate with much lower overhead.

[fusionictnl]

This way some httpd setting have to be changed and I don't know if there is already one :s Otherwise DA would probaly change the setting every time.

But I will look in to it today ;) and hopefully this could be done the way you say ;) It will indeed cost less overhead ;)

[lnguyen]

let me say, I'm very greatful for your work! AWStats is something I like, but DA was missing... I haven't had a chance to give it a try yet, but glad to see it's going good.

Has there been any major problems yet?

Linh

[fusionictnl]

Not really at the moment, tomorrow GMT+1 (Netherlands) I will try to release the next version, wich will use the server wide CGI, if it works ;) Have to test to see if DA doesn't delete the parameters I'm adding to the httpd conf.

I'm working on it and it looks like it should be up and running tomorrow ;)

[fusionictnl]

Ok I've found the first problem I ran into, when using a GLOBAL awstats cgi. SuExec doesn't allow this, because the owner of the file must be of the owner of the domain :s So I will have to take a look if it's possible to do it another way, otherwise I will have the script copy the files needed to the user dirs.

[thuskey]

is there a CgiDir variable or something like that in the perl file that will allow you to define the root cgi directory as CMD_PLUGINS/awstats/hooks/cgi-bin/ or maybe you could somehow force a base url tag in the header section. I guess that would be really difficult since DA serves up the footer and the header for all pages.

[fusionictnl]

Well I'm now looking at generating static pages, but still there are some difficulties for it. I could make a workaround, but this will change a lot of thing within DA and could cause problems on other Distro's, so I'm not doing that. I want to keep the plugin as limited as possible in changing the server preferences.

[fusionictnl]

Updated v0.7:

A lot of things are added and fixed!!

The users can access AwStats by going to the AwStats link in the CP, this will automaticaly if they have 1 domain, install AwStats in their public HTML folder /awstats . There are some other things that will be setup, but you can see this at the user page.

If they have multiple domains they will have the option to select the domain to activate awstats for ;)

Please try it and let me know it there are any BUGS in it. It works fine on my server, so let me know if it works on yours ;)

[hostpc.com]

Works GREAT on individual sites, but I'm running into errors on reseller accts, or accts with multiple domains.

I'll get a list together and post here later.

[Protollix]

Hello,
I installed this plugin just fine (v0.7).

When I login with a user account and click the AWstats link in the control panel it seems to set everything up ok. Next, I click on the link provided ( http://www.protollix.com/awstats/)

Notice the 403 error.

Any idea *why* this would be occuring. I just rebuilt Apache with the DA script to ensure I didn't miss anything. There are addhandler lines in httpd.conf to add .pl to cgi-script.

Permissions *look* right. Ideas?

[hostpc.com]

Found the issue with the reseller... custom 404's were messing it up, nothing to do with the scripting.

So far, 100% fine for our test, gonna deploy on a couple more servers and make it "known"... will let you know.

[hostpc.com]

I like to keep my directory password protected to keep snoopers out

However, be warned if you password protect it through the control panel it will overwrite the .hatccess redirect file that the installation makes and cause you to get forbidden errors

I removed the password protection but it didnt remove the .htaccess file .. manually removed the .htaccess file and of course still got forbidden errors

tried to manually put the redirect back in
long story short .. i ended up having to just go through the installation again for it to work properly

Thanks,
HostPC Staff

[Protollix]

I fixed the problem:

in the generated .htaccess problem the following line is present:


Options ExecCGI

However, it should be (at least for my installation):

Options +ExecCGI

(it needs the "+")

So I edited the .htaccess and it works fine. It's just that I have to do this for each domain that awstats is on now =|

[fusionictnl]

I'll add the +ExecCGI on it ;) Furthermore, in the options I'm building the password security, this can be done directly in the awstats configuration. Thx for your efforts ;)

[fusionictnl]

Updated v0.8:

*- HTTPS bug fixed (again :s)
*- (+) added to ExecCGI ;)
*- Section splitted (Install Awstats on Domain, Tune Awstats)
*- Password protection available under Tune AwStats

Let me know how it goes and if you know any features to add (if it's needed) ;)

[thuskey]

the password thingy didn't password protect it.

Here is the content of the .htaccess file after running the password protect thingy.

Options +ExecCGI
DirectoryIndex awstats.pl

[fusionictnl]

Make sure you don't use/click "Install AwStats on this domain*" after setting up the password protection, otherwise it will be resetted ;)

[thuskey]

How about a link below "Tune Awstats" and "Install AwStats" that says "View AwStats", just in case we forget the url and don't want to click the Install link and loose the current password stuff.

[fusionictnl]

Well, I could do that :p

[thuskey]

Originally posted by fusionictnl
Make sure you don't use/click "Install AwStats on this domain*" after setting up the password protection, otherwise it will be resetted ;)

I'm going in and entering a username and password, and the .htaccess timestamp never even changes, so I deleted the file and added a password again and no new file was written.

[fusionictnl]

Does the script give any errors when protecting awstats?

What's the full path of the awstats plugin on your machine ? (normaly /usr/local/directadmin/plugins/awstats/hooks /user /...)

Did you first Delete the Old plugin version and then installed the new one ?

Where is the awstats for the virtual host located ? (normale /home/[username]/domains/[domainname]/public_html/awstats)

Thx

[thuskey]

I'll uninstall and reinstall and try again just to verify. Well, as soon as http://www.fusion-ict.nl/da_plugin/awstats.tar.gz is available again.

[fusionictnl]

It's available ;) Backup crashed last night :( Not using that tool anymore ;)

[jmstacey]

Its not detecting domains for me. During install when it says Install awstats on this domain, no domain is displayed and when I attempt to run it, this is reported when it tries to create the awsats directory.
Warning: mkdir(/home/username/domains//public_html/awstats): No such file or directory

Its not detecting the domains for me. This causes a cascading affect of course on the rest of the install procedure.
This is the link it displays when I try installing:
https://mydomain:2222/CMD_PLUGINS/awstats?config=1&domain=
I tried putting my domain in manually but still same results, it didn't insert it into the install script.
This is for all accounts, not just the admin.

Any ideas?

[fusionictnl]

Users with more than one domain (as owner) do they first see a list of domains ??? it uses (CMD_API_SHOW_DOMAINS) to get the list of owned domains.

I can't really understand why it shouldn't know wich domain the logged in user has, as this is being fetched from DirectAdmin.

Did you reinstall the plugin or did you "update" it ?
Did you try logging in as a domain user (wich has only one domain) ?
Are you running DA in HTTPS ? (maybe this is why it couldn't fetch the domains)

[Icheb]

This plugin doesn't function with safe-mode enabled, does it ?

I get the following after trying to access it with a user after installing:


Warning: main(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /usr/local/directadmin/plugins/awstats/hooks/da.php owned by uid 0 in /usr/local/directadmin/plugins/awstats/user/index.html on line 8 Warning: main(/usr/local/directadmin/plugins/awstats/hooks/da.php): failed to open stream: Success in /usr/local/directadmin/plugins/awstats/user/index.html on line 8 Warning: main(): Failed opening '/usr/local/directadmin/plugins/awstats/hooks/da.php' for inclusion (include_path='.:/usr/local/lib/php') in /usr/local/directadmin/plugins/awstats/user/index.html on line 8 Fatal error: Cannot instantiate non-existent class: httpsocket in /usr/local/directadmin/plugins/awstats/user/index.html on line 10
Since the script uid keeps popping up as 101, i'll try a permissionchange from uid 0 to 101 for the script....

OK, that worked, now getting another problem:



Checking if there is already something installed..
Creating AwStats dir on domain
Warning: mkdir(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 39 Checking if awstats files are available Warning: symlink(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 45 + Warning: symlink(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 47 + Warning: symlink(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 49 +
Checking for AwStats itself
Warning: copy(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 54 Warning: copy(/home/testdomain/domains/testdomain.nl/public_html/awstats/awstats.pl): failed to open stream: No such file or directory in /usr/local/directadmin/plugins/awstats/user/index.html on line 54 Installed awstats.
(Re-)Activating CGI for dir
Warning: copy(): SAFE MODE Restriction in effect. The script whose uid is 101 is not allowed to access /home/testdomain/domains/testdomain.nl/public_html owned by uid 512 in /usr/local/directadmin/plugins/awstats/user/index.html on line 57 Warning: copy(/home/testdomain/domains/testdomain.nl/public_html/awstats/.htaccess): failed to open stream: No such file or directory in /usr/local/directadmin/plugins/awstats/user/index.html on line 57 (Re-)Setting permissions
Warning: chmod(): Unable to access /home/testdomain/domains/testdomain.nl/public_html/awstats/awstats.pl in /usr/local/directadmin/plugins/awstats/user/index.html on line 59 Warning: chmod(): No such file or directory in /usr/local/directadmin/plugins/awstats/user/index.html on line 59 Warning: chown(): Unable to access /home/testdomain/domains/testdomain.nl/public_html/awstats/awstats.pl in /usr/local/directadmin/plugins/awstats/user/index.html on line 60 Warning: chown(): No such file or directory in /usr/local/directadmin/plugins/awstats/user/index.html on line 60 Now (re-)creating your configuration file.
Config file has been created and your statistics are now setup!

You can now view the statistics for your domain at: www.testdomain.nl/awstats/

But heh, I'm making progress....

[fusionictnl]

jmstacey I've just setup a new version wich support HTTPS (i hope, can't test). If you want to enable HTTPS, install v. 0.8.1 and from console use the following: "touch /usr/local/directadmin/plugins/awstats/hooks/ssl.use"

Let me know if it works, so i can implement it ;)

Icheb With safe_mode restriction on it will not work, even awstats does use files outside the users dir.

The script(s) change a lot outside the permitted directory in safe_mode.

[jmstacey]

This still didn't work. Same problem. I also disabled ssl for directadmin and tried it but still not luck. Is it my OS combination thats the problem. Your developing it on RedHat aren't you?

[fusionictnl]

Yes, I don't know wich path's or that the API is different somehow. :s

Or that the way the enviroment variables should be passed to php differs ? Put in the top of the index.html the following (after the php tag):

echo "User: ".$_SERVER["USER"]."<BR>"; (Must be capital).

if this doesn't work you can check for me:

$_ENV["USER"]
$_ENV["USERNAME"]
$_SERVER["USERNAME"]

These all contain the same variable on redhat, so we just need to find out if any of these contains the user on your system ;)

Thx

[jmstacey]

Tell me what to look for and I'll find it! :D

[fusionictnl]

I edited my post!

[Icheb]

Originally posted by fusionictnl
Icheb With safe_mode restriction on it will not work, even awstats does use files outside the users dir.

The script(s) change a lot outside the permitted directory in safe_mode.

Figured that out already :D
I disabled safe mode everywhere, my php.ini, the httpd.conf etc, but DA is still giving me the same problems.
Where does the php version of DA get it's safe mode config from, and why isn't it listening to safe_mode=OFF in php.ini...

Not that awstats are vital to the server, but I'd like to offer it to my clients.

Oh, btw: nice job with the uninstall.sh. Uninstallation doesn't seem possible, does it ? :D

[fusionictnl]

DA removes the plugin dir ;) /etc/awstats and the user's public_html/awstats have to be deleted manualy.

If you have another awstats or something it would be deleted, nobody likes that ;) or if something goes wrong with deleting the awstats dir and the users public_html is gone, they wouldn't be happy ;)

If you just turn off safe_mode in the panel, as it is standard, it should work ;)

By the way, HTTPS isn't working correctly, so if you're running https it probaly won't work. (working on it ;))

[UltimeWWW]

Works great!

Had to translate and comment a cupple of things I didn't liked, but now it works very good!

Thanks a lot.

[Icheb]

Originally posted by fusionictnl
DA removes the plugin dir ;) /etc/awstats and the user's public_html/awstats have to be deleted manualy.

If you have another awstats or something it would be deleted, nobody likes that ;) or if something goes wrong with deleting the awstats dir and the users public_html is gone, they wouldn't be happy ;)

If you just turn off safe_mode in the panel, as it is standard, it should work ;)

By the way, HTTPS isn't working correctly, so if you're running https it probaly won't work. (working on it ;))

Ok, it's true that users wouldn't like their public_html dir removed...

I got it running, my php was compiled with the enable safe mode command. So it kept the system in safe mode while safe mode is supposed to be off. (I work with open basedir restrictions and some disabled commands.)

It looks good :)

Although a 'go back to panel mainpage' button might be usefull, and perhaps a button while in the panel awstats menu to directly go to the <domain>/awstats/. But that's only if you would have the time for it, and want to make it :D

[fusionictnl]

I will implement it. But for now I'm going on a vacation for a week.

;)

[Icheb]

Originally posted by fusionictnl
I will implement it. But for now I'm going on a vacation for a week.

;)
Have a nice vacation :D

[Protollix]

You probably should change this line

if ($awuser && $awpass && $domain) {

to something like

if ($awuser && $awpass && isset($domain)) {

the problem is, if they are trying to set the password on the first domain (item 0 in the array) the if statement will ALWAYS evaluate to false.

[sander815]

anyone have a backup url? the 1 provided doesn't work forme

[sander815]

everything is 0 in a domain i tried awstats plugin on, is that ok?

[jmstacey]

Still on Vacation! :p

Secure connections are finally fixed.
- Update the socket communication class to v2.3 (da.php)
forget about any changes you've made to it
- in the index.html file where this line is
$Socket->connect('127.0.0.1',2222);
REPLACE it with this

if (file_exists("/usr/local/directadmin/plugins/awstats/hooks/ssl.use"))
$Socket->connect('ssl://127.0.0.1',2222);
else
$Socket->connect('127.0.0.1',2222);

Not the prettiest but it works. Do this to ALL files that require a connection to DA like options.php for example.
Once its actually connecting to DA there shouldn't be any more domains not showing issues so you can probably remove the echo debug command that displays the domains array before its parsed.


One BIG Problem
It just doesn't work for me, lol. when I try going to my awstats directory I get a 500 error. If I try running it through the command line its because it needs a -config=virtualhostname after the command which is probably the reason for the server error, not sure how to fix this since I don't have much experience with awstats. I'm not sure what your trying to do but my suggestion is don't even bother with putting stuff other that the stats in the users directory.

What I suggest is you make an admin page with a cron tool scripts that will add a cron to generate stats for all users 30 to 60min before webalizer does. Then when I user goes and "Installs" webalizer on their domain config file is created and is added to the awstats/hooks/domains.conf then when generate.sh or a script like it runs through and updates stats for all users it will put all stats in the users awstats directory.
Doing it this way will elliminate all of the permissions problems and overhead (I think), and will help against users updating stats more often than they need to be.

I'd say once you got that base working so something at least works then more options can be added. For example:
+ admin option to set cron at different intervals
+ admin option to allow users to set the interval time that stats are generated for them
+ user option to select generation interval.

Something like how Directadmin does its crons could be used to keep away from editing the main crontab. Like one entry in the main crontab to check the awstats crontab every minute, or however DA does its thing.

[fusionictnl]

Updated v0.9:

DEBUG info domain array removed.

Direct link to statistics

Replaced the HTTPS setting (jmstacey) so it will hopefully work with https ;)



The -config= isn't needed because the .pl is user through CGI. This way it will use the domainname it's called by. Ex:

http://www.test.nl/awstats will use awstats.www.test.nl.conf

Further a 500 Error looks more like a cgi-bin permission error :s Probaly the rights on the file aren't setted correctly.

check the following files:

/var/log/httpd/suexec_log and /var/log/httpd/domains/[domain].error.log

It should prompt there what the real problem is.

For using a cron script for generating the statistics is way to complicated :P First there should be an output dir for each domain /home/domain/httpdocs/awstats

The scripts used for generating the statistics for all domains is very cpu/time consuming (they are too simple setupped)

The CGI only generates the statistics when needed and is way faster :) For my feeling :P

[jmstacey]

I'll look into the permissions settings. Personally the cron sounds a little less complicated that each user having a awstats.pl which has file linked to here which has files linked to there and everywhere :p

[fusionictnl]

Or every user has a bunch of statistics files ;)

Keep me updated on the 500 error ;)

Thx

[jmstacey]

Problem fixed finally! Does require your installation script to be modified somewhat though. The awstats directory that your plugin creates belongs to username:apache where it should be username:username. once I fixed that its working like it should.
I highly suggest you add this to the installation script as it does not work for any of my domains without this step.

Heres the fix :D
In the index.html page find the following

echo "Checking if there is already something installed..<BR>";
if (file_exists($location)) echo "AwStats Directory already exists on domain<BR>";
else {
echo "Creating AwStats dir on domain<BR>";
mkdir($location);
}


and replace it with this

if (file_exists($location))
{
echo "AwStats Directory already exists on domain<BR>";
echo "Setting Directory Permissions";
chgrp($location,$_SERVER['USER']);
}
else {
echo "Creating AwStats dir on domain<BR>";
mkdir($location);
echo "Setting Directory Permissions";
chgrp($location,$_SERVER['USER']);
}

Also you can get the latest version thing working to show in the plugins page by modifying the plugin.conf and changing

version_url=http://awstats.sf.net
to

version_url=http://www.yourdomain.com/version
then on your server create a file named "version" that contains the version information such as "1.0"

:cool:

[jmstacey]

Some things that need working on.

+ Only the current days stats are processed but then are lost when DA cleans it out every 24 hours. This needs to be fixed since I would like history and not just todays stats ;)

+ If static pages were used it would save a lot of processing time from having to generate all of your records each time you viewed the page. Although I'm not sure how you can do this easily without heading the cron way. This would also fix the problem where you can't access the stats without the www

+ Short term solution to the www problem is adding a link in /etc/awstats of awstats.domain.net.conf to awstats.www.domain.net.conf

[fusionictnl]

Updated v0.9.1

- jmstacey fix for permissions and latest version info

In reply:

History is being written to /etc/awstats/awstats[date].www.[domain].txt

My statistics go back to beginning of the year ;)

For using without the www, awstats will write another history file. This way all history files will be doubbled for every domain.

[UltimeWWW]

I suggest enhancing the text. It's really ugly!

[jmstacey]

Originally posted by fusionictnl
Updated v0.9.1
History is being written to /etc/awstats/awstats[date].www.[domain].txt

My statistics go back to beginning of the year ;)

For using without the www, awstats will write another history file. This way all history files will be doubbled for every domain.

But there is still the two major problems
1. All of the stats must be generated everytime a new session is started. Rather time consuming but not really a problem unless there are lots of stats to generate over a lengthy period of time.

2. Statistics are not complete if you don't run them right before DA rotates the usage log.
For example, I ran it at the end of the 12th and today (14th) and did not run it on the 13th. As such there are no statistics for the 13th.

Perhaps at least a script that will generate stats right before webalizer does and when DA rotates the logs. That way there will at least be stats for that day whether or not the user updated his stats. See what I'm saying?

[rldev]

"All of the stats must be generated everytime a new session is started."
What does this mean?

Aren't stats incremental?

[jmstacey]

Yes they are incremental, but you must rebuild the nice graphics and such everytime you start a new session viewing stats because it must reparse the incremental log data.

[rldev]

That would make sense since it is dynamic but seems like a load to deal with if you have a busy server
.
They give you the choice to run static pages, but it doesn't look very good.

[fusionictnl]

1.All of the stats must be generated everytime a new session is started. Rather time consuming but not really a problem unless there are lots of stats to generate over a lengthy period of time.

Check the permissions and look for the files I earlier described before. All of the stats aren't regenerated everytime (There must be some permission issue). "/etc/awstats/*.txt" are the history files and processed info.



2. Statistics are not complete if you don't run them right before DA rotates the usage log.
For example, I ran it at the end of the 12th and today (14th) and did not run it on the 13th. As such there are no statistics for the 13th.


Don't know when DA rotates it's logs ?? On my server I have no problems with incomplete awstats statistics even if it isn't ran for 1,5 month (just checked it).

[Auraka]

Thanks for this awesome plugin :-)

[vincenzobar]

link is not working!!!!!

[jmstacey]

Ok, yeah file permissions was messed up but it appears that it was only for that file as it is working for other domains I try installing it on. I probably messed it some time down the road.'

OK! That fixed all the problems :p

[hostpc.com]

[root@joelinux root]# dig fusion-ict.nl

; <<>> DiG 9.2.3 <<>> fusion-ict.nl
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@joelinux root]#


???:confused:

[fusionictnl]

This machine where the site is hosted is running in test fase with DA. It's a new server, but it's randomly crashing a lot. about 1 or 2 weeks between.

So it could be that it sometimes wouldn't respond.

Sorry for the incovenience. Hope we'll get it fixed soon. New hardware is being changed to test where the problem is.

;) You can "dig" again ;)

[vincenzobar]

i accidently un-tarred in a public_html directory and now i cannot remove it. it says access denied and when i try to reinstall i get a 404 error or something. how in the hell do i delete the directory so i can start the install on that site again from scratch. also it is in my FTP area becuase i was looking for a readme. which wasn't there!!!!



HELP

Works great everywhere else but in my one site!!!!

[jmstacey]

ehemmm.
First Login as root then you can remove the directory. Secondly, this is a DirectAdmin Plugin. You must have admin access to the control panel, once there head to the Plugins page. The link is on the main admin page, you install the "Plugin" from there ;)

[vincenzobar]

come on im not that stupid!!!!!

I SSH as root and i still can't remove the dr i tried rm -d -f and rmdir (im not great with Command line yet) any thing else i could use.

I got it installed and running on every other site other than one with this problem

anyother suggestions

[jmstacey]

Well, just giving you ideas. Most times its just a simple thing that you overlooked. Did you try the rm -rf command to try force the removal of it? As root you should be able to get rid of everything you want to no matter who the owner is.

[vincenzobar]

Had to do a rm -d -R awstats

and Y to every file!!!!!

Thanks for trying!!!!! seriously!!!!! no sarcasm i swear!!! text can come off wrong sometimes!

[l0rdphi1]

http://www.pvv.ntnu.no/~steinl/vitser/rm.html
-R Raw eggs option. For every file deleted, print the
string "Ada sucks raw eggs" to the system console.And -D isn't listed.


A simple rm -fr awstats should have removed your awstats directory in one sweep.

Phi1.

[vincenzobar]

That did the trick too... used it in my ftp directory!!!

thanks i will have to remember that one!!!! its alot quicker then the way i did it as seen above!

[l0rdphi1]

Indeed that is a lot easier :D

Good luck!

Phi1.

[vincenzobar]

last question!!!


I can't protect the link through tuning?!?!?!!?

one of my users noticveed that for me and is a little concerned. I guess i could protect the directory through file manager but thats a extra step that he will not like so much. I read the entire post, what did i look over or miss?

[fusionictnl]

Could you look in the public_html/awstats dir from a site you try to protect for a file named .htaccess ?

with a ls -la you can list the dir for . (hidden) files. (ssh offcourse ;))

and check if the location of the password file is correct ?

[vincenzobar]

this is what i got

-rw-r--r-- 1 freddyv freddyv 43 Aug 17 22:34 .htaccess

in root of awstats

where should it be?

[nobaloney]

If you insist on belittling people who try to help you, you'll soon find no one will help you.

If you want to remove a directory, and you don't care what's in it, as root...

First navigate to the directory that contains the directory you want to delete.

Then do this:

# rm -Rf directoryname

where directoryname is the name of the directory you want to delete.

If that doesn't work, then do:

ls -ald directoryname

and post the output.

Jeff

[vincenzobar]

Originally posted by jlasman
If you insist on belittling people who try to help you, you'll soon find no one will help you.

If you want to remove a directory, and you don't care what's in it, as root...

First navigate to the directory that contains the directory you want to delete.

Then do this:

# rm -Rf directoryname

where directoryname is the name of the directory you want to delete.

If that doesn't work, then do:

ls -ald directoryname

and post the output.

Jeff

im going to let that slide!!!! i never belittled anyone!

thanks for the info!!

peace

[fusionictnl]

Originally posted by vincenzobar
this is what i got

-rw-r--r-- 1 freddyv freddyv 43 Aug 17 22:34 .htaccess

in root of awstats

where should it be?

Open up the file and look to the .passwd path and check if this file exists. Normaly you should already get a popup for this domain, even if the .passwd isn't found I thought

[vincenzobar]

this is all thats in my .htaccess file

Options +ExecCGI
DirectoryIndex awstats.pl


nothing else

[fusionictnl]

Updated v0.9.2

- fixed password protection problems (tune awstats)



In reply:

The password couldn't be altered/set due to a fault in converting the password to .htpasswd password format.

The problem is now fixed.



Thx for your support ;)

[vincenzobar]

Thank you for yours!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Now.. how do i update???

Result While Updating Plugin(s)

Details

Error Downloading http://www.fusion-ict.nl/da_plugin/awstats.tar.gz : Unable to open /usr/local/directadmin/plugins/awstats/plugin.tar.gz for writing

do i do a reinstall from scratch or what!

[fusionictnl]

Just delete the old one then install the new one.

[kamsel]

Hey,

Script works great, but I am having problem ONLY with one domain. Here is what I am getting:




Checking if there is already something installed..
AwStats Directory already exists on domain
Checking if awstats files are available...
Checking for AwStats itself
Awstats already exists.
(Re-)Activating CGI for dir
(Re-)Setting permissions
Now (re-)creating your configuration file.
Warning: symlink(): File exists in /usr/local/directadmin/plugins/awstats/user/index.html on line 77 Config file has been created and your statistics are now setup!

You can now view the statistics for your domain at: www.my_domain.com/awstats/



Is it because I have two domains on one account?
Also, other domain's stats are working fine.


______________________________
also, I forgot to mention that when i go to my_domain.com/awstats/ I am getting Internal Server Error



Thanks,
Kamsel

[jmstacey]

Make sure the awstats permisions are set to username:username and not username:apache

I ran into this problem because of that. The installation script does not change the file permissions if the directory already exists.

It may be a good idea to have it do it anyway fusionictnl in case of a similar problem. Or a check that will make sure its set correctly.

[vincenzobar]

Originally posted by fusionictnl
Just delete the old one then install the new one.

I just un- tarred right over it and it worked perfect!!!! Thanks, you are THE MAN!!!!!!!!!!!

[kamsel]

Hi,


Fixed. Thanks


kamsel

[UltimeWWW]

Hum, weird.

On one server I got a message saying that my log-format isn't OK but on the other one it's perfect.

:confused:

[fusionictnl]

jmstacey:

The permissions are being (re-)set for the dir, even if it exists. You delivered me the changes to set it to user:user.

UltimeWWW:

Where do you get this error, what does this error say ?

If it is that the log format isn't correct, check if the logs exists for the user.

kamsel:

It is fixed ? How ???

[kamsel]

Fusionictnl, I figured out that it creates directory in /public_htmll/ just after jmstacey responded to my question [ shema on me ]. So I basically deleted this directory and tried to install it again...it worked.

[fusionictnl]

K thx ;)

[UltimeWWW]

Originally posted by fusionictnl
jmstacey:

The permissions are being (re-)set for the dir, even if it exists. You delivered me the changes to set it to user:user.

UltimeWWW:

Where do you get this error, what does this error say ?

If it is that the log format isn't correct, check if the logs exists for the user.

kamsel:

It is fixed ? How ???

Well it's a basic DA server. Gonna check this out more carefully.

[Icheb]

Maybe this is the time to update the awstats version itsself as well (if that hasn't already been done) due to : http://www.securityfocus.com/bid/10950
Just in case someone missed it :D

[jmstacey]

Originally posted by fusionictnl
jmstacey:

The permissions are being (re-)set for the dir, even if it exists. You delivered me the changes to set it to user:user.



I looked at the index.php file where it does its check for the awstats directory, if it exists it echos its (re-)seting the permissions but there is no code after that to do do the actual setting of permissions, it just moves on to the next step. I'll take a close look when I get home, I probably missed something again. :)

[jep]

Hey Guys,

I'm sorry for bugging you, but I cannot find something.

I've installed the plugin and now I thought I should have /awstats stats on the domains. The only thing I have is a .conf file in /home/username/awstats/.

Is there anything I forgot to do?

Thanks!

[root@reseller scripts]# ./uninstall.sh
Plugin Un-Installed!
[root@reseller scripts]# ./install.sh
Plugin Installed!
./install.sh: line 5: //this: No such file or directory
chmod: failed to get attributes of `user/*': No such file or directory
chown: failed to get attributes of `user/*': No such file or directory
chmod: failed to get attributes of `reseller/*': No such file or directory
chown: failed to get attributes of `reseller/*': No such file or directory
chmod: failed to get attributes of `admin/*': No such file or directory
chown: failed to get attributes of `admin/*': No such file or directory
mkdir: cannot create directory `/etc/awstats': File exists

[jep]

Oh. I couldn't find the link to the CMD_PLUGINS dir. Is it in the skin or not? Otherwise I have to tell my clients.

By the way, I want to install awstats on one server on all domains. Is there an script for that?

[fusionictnl]

Hey,

You must install the plugin through the CP. This shouldn't have anything to do with the Skins. The plugin is available to all domains (users-level) and they can choose to activate it or not.
I will try to get it on the admin page to install it on all domains.

Icheb

All versions of DA are vunarable for the Logfile Input check. They probaly don't think this is something big :P It is the latest version, so I don't know if in the latest build this is solved.

[jep]

That would be great!

But where do I find the awstats/plugin section on a user-login? I cannot find it.

[fusionictnl]

First remove the plugin from the plugin Manager in the Admin section. Then install it again and you should see it at the user level from any domain.

[jep]

I did that, but when I login as a user, I still don't see any buttons that has to do with plugins or awstats :(

[fusionictnl]

Jep

Do you removed the dir in /usr/local/directadmin/plugins/awstats (completly?)

Otherwise If you have MSN you can PB me with your adres, so we can walk things through and not flooding this topic too much with one problem ;)

Thx!

[Icheb]

Originally posted by jep
I did that, but when I login as a user, I still don't see any buttons that has to do with plugins or awstats :(

As a user or as a demo user ?
Demo users/resellers don't have the plugins visable/usable...

[fusionictnl]

It is already fixed. Used skin doesn't show Plugins

[fusionictnl]

Updated v1.0:

*- Added alldomains.php to the hooks dir! (installs awstats on all domains)
*- Updated alldomains.php to reset all permissions even if the files exists.

alldomains.php is very simple and could do some wrong things to your machine, be carefull when running it! I tested it on 3 machines FreeBSD,RedHat and Fedora. They all worked fine!

Keep me updated if it works!

[decafranky]

Hi,

Thanks guys, awstats is working great.

But I have 2 questions:

1. I see the stats aren't accepting any country informaties (there are all unknow).

2. Stats are working fine via http://www.domain.com/awstats/domain.com.html, but howto create automaticaly subs to each domain name and forward that index to the stats of that domain?

Keep on doing that great work!

Regards,

Franky

[jep]

Originally posted by decafranky
Hi,

Thanks guys, awstats is working great.

But I have 2 questions:

1. I see the stats aren't accepting any country informaties (there are all unknow).

Make sure that your apache resolves hostnames.


2. Stats are working fine via http://www.domain.com/awstats/domain.com.html, but howto create automaticaly subs to each domain name and forward that index to the stats of that domain?

Keep on doing that great work!

Regards,

Franky
That's one thing I also want to know. ;)

[fusionictnl]

Updated v1.1

DNSLookups are working now (Country lookup).
You will need to remove all old .txt files of the domains (otherwise only new data will be lookuped) and reactivatie awstats on the domain(s) (Otherwise the configuration files aren't corrected).

If it already workes, you can Tweak awstats yourself by changing the template config: /usr/local/directadmin/plugins/awstats/hooks/cgi-bin/none.awstats.conf

and setting DNSLookups to 0

If it still doesn't work you can check www.awstats.org and search for the GeoIP(free) plugin and implement this one to awstats.



2. Stats are working fine via http://www.domain.com/awstats/domain.com.html, but howto create automaticaly subs to each domain name and forward that index to the stats of that domain?

Keep on doing that great work!

Regards,

Franky

Could you explain how http://www.domain.com/awstats/domain.com.html works ?? there is normaly only a awstats.pl in that dir with some links ?

And how do you mean automaticaly forward ? Does awstats do logging of subdomains ? I thought it counts it to it's main domain ?

I should be wrong about this, so please explain some more, so I could maybe add this feature :)

Thx!

[decafranky]

Hi,

I have searched in the httpd.conf file, but can't find anything what is pointing to resolving hostnames...

Even via webmin, the apache server, can't find it.

Where should i activa hostname lookup (resolving)?

Regards,


Franky

[fusionictnl]

If you enable lookups in apache, awstats lookups should be turned off, as of now awstats lookups are turned on, so this doesn't need to be done by apache.

To fix it read the above and update to the latest!

Let me know how it goes!!

[fusionictnl]

Update v1.1

- Added extra options to the "Tune Awstats" page.
- Locks multiple updates. (DoS attacks on awstats.pl).

Now users can turn DNS Lookups on/off, Frames, New Windows or First Day Of the Week.

[decafranky]

Hi,

V1.1 works great, thanks !

Just found one bug, on the cron job it should be
php /etc/awstats/domainlist.php
instead of /etc/awstats/php domainlist.php

Regards,

Franky

[decafranky]

Oops, my mistake.

Sorry!

Franky

[fusionictnl]

I don't think this has anything to do with the plugin ;)

But thx anyway ;)

[decafranky]

Hi,

I am searching how to update the stats for all domains one a day via cron job.

But i can't figure out what command for awstats is needed to run update the stats for all domains.

I tried /usr/local/directadmin/plugins/awstats/hooks/alldomains.php and /etc/awstats/alldomains.php , but both of them seems not to update the stats ...

Regards,

Franky

[jep]

I'm looking for that too :D

And, are new domains automaticaly installed with awstats? :P

[decafranky]

I suppose Awstats is now updating once a week for all domains?

Franky

[fusionictnl]

Update v1.3

- Added awstats_updateall.pl


In reply:

Alldomains.php just configures all domain, not new ones automaticaly, as this script is pretty fast you can run it on new domain creation or something.

To update all domains:

Update to the latest version, I've added the awstats_updateall.pl file to the hooks dir!

This is documented by awstats:

awstats_updateall launches update process for all AWStats config files (except
awstats.model.conf) found in a particular directory, so you can easily setup a
cron/scheduler job. The scanned directory is by default /etc/awstats.

Usage: awstats_updateall.pl now [options]

Where options are:
-awstatsprog=pathtoawstatspl
-configdir=confdirtoscan


At the moment I don't have time to find out how it works, when I have time, maybe tonight I'll take a look at it. Probaly isn't very hard. :)

Good luck!

[decafranky]

Hi,

Wpdatescripts works great! Thanks.

Just a final question:

Don't know why, i think it's because i have run alldomains.php, in the DA control panel, i get in the AwStats config permission error when i chance something (day of week, password protecting, etc).

example:


Warning: fopen(/etc/awstats/awstats.www.zeevisandre.be.conf): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/user/save.php on line 38 Warning: fwrite(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/save.php on line 39 Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/save.php on line 40

And that error exists for every domain, any idea?

Regards,

Franky

[decafranky]

When i use or try to configure awstats in da control panel, i get the following error:

Checking if there is already something installed..
AwStats Directory already exists on domain
Checking if awstats files are available...
Checking for AwStats itself
Awstats already exists.
(Re-)Activating CGI for dir
Warning: copy(/home/admin/domains/decaserver2.be/public_html/awstats/.htaccess): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/user/index.html on line 62 (Re-)Setting permissions
Now (re-)creating your configuration file.
Warning: fopen(/etc/awstats/awstats.www.decaserver2.be.conf): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/user/index.html on line 70 Warning: fwrite(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 75 Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 76 Warning: symlink(): File exists in /usr/local/directadmin/plugins/awstats/user/index.html on line 77 Config file has been created and your statistics are now setup!



Regards,

Franky

[UltimeWWW]

I still got a problem on only one server saying the LogFormat isn't OK. That's weird, those DA servers are identical!

[fusionictnl]

decafranky

Could you give me some more info about the permissions of the files/dirs: /etc/awstats and the /home/.../public_html/awstats

Thx!

UltimeWWW

The logs should be identical as you say, but could you check if:

/var/log/httpd/domains/*.log exists and there are logs with data in it!

Further more can you check the specific configuration file of that domain in /etc/awstats/awstats.www.[domain].conf and look if the parameter: LogFile="/var/log/httpd/domains/[domain].log" is correctly set and that the file exists!

Thx

[jmstacey]

Minor feature suggestion. Create some kind of detection to tell if DA is using ssl or not. Since its only yes or no it should be pretty simple and then have it automaticlly adjust to the environment it is running under, that way for those running ssl it is a plugin that doesn't require tweaking through ssh (touching the ssl.use file)

And if you get bored a little user interface work like saying succesful or forwarding back to the domain index page after saving the settings in the tune awstats page instead of just displaying the page again. It might confuse users as to whether the settings actually saved or not.

:p

[fusionictnl]

Thx for your input jmstacey! Will be implemented ;) a.s.a.p. !

[jumonjii]

I get this in the DA Plug in Manager

Unable to execute your request



Details

The password provided is not correct. The password is required due to the high risk factor of plugins

[fusionictnl]

I sended you a private message about this before. You must use the admin-account password in the field next to the button.
The one you used to login to DirectAdmin.

I attached an image !

;)

[GillroY]

Is your site offline? I can't seem to get to it, so I can't download the plugin at the moment. :(

[fusionictnl]

Server has crashed last night during a mondo backup, it was down for approx. 30 min.

;)

[GillroY]

Yeah, great it's working again. I probably tried to download it several times right when it was down :)

Anyway, great work, this plugin!

[GillroY]

Tried to install the plugin, which went fine, but now the plugin doesn't see my users' domains...

I'm running in ssl, but I created a ssl.use file, so that shouldn't be the problem. When I echo "sizeof($domains)", it gives me 0. But I'm sure the user has at least one domain (tried this with users with 1 and with multiple domains).

Any idea what is causing this? I couldn't find the answer/solution in this thread :(

[fusionictnl]

Private Message send.

http://www.directadmin.com/forum/private.php

[Seth]

I get a blank page in DA.

[Acid-Duck]

Hi all,

I just tried installaing the awstats pluggin. I did an installation for awstats while specifying "NONE" for the webserver configuration for awstats, since I figured the pluggin would do this. The appropriate directories were created... when I run ./alldomains.php I don't get an error message and everything seems to have worked, but when I click on awstats in DirectAdmin all I get is a blank page. Please help,

Thanks.


Erik


PS: The version of awstats I installed is the generic one, from another thread I've noticed there's awstats-md. Is that what I should be installing instead? Or perhaps was I supposed to let awstats modify the httpd config files?

[fusionictnl]

In this plugin is awstats build in. You should move all the files in your /etc/awstats to something like /etc/awstats_old and delete and reinstall the plugin.

The domains shouldn't have an /awstats in their public_html because it uses this dir. to install awstats for the users.

If it still shows a blank page, you should check the /var/log/httpd/domains/[domain]_error.log or the suexec.log in /var/log/httpd

Keep me updated on how it goes ;)

[Acid-Duck]

Hi,

Thanks for your reply. Originally I installed AWSTATS by myself as I indicated in my previous post. I tried correcting this by moving /etc/awstats to /etc/awstats_old and I went in each user's homedirectories deleting the ~USER/public_html/awstats dir. I then proceeded by installing the plugin from the plugin manager but still no results. I still get the same blank page.. suexec log shows:

[2004-09-05 05:02:06]: info: (target/actual) uid: (manacan/manacan) gid: (manacan/manacan) cmd: awstats.pl


and the error file shows nothing it seems. I did a tail -f file and nothing was written to the error file for that domain.



Erik

[Seth]

fusionictnl do you have an install service? :-)

[fusionictnl]

Acid-Duck

The suexec entry is completely OK ;) and if the httpd doesn't write any line in the error_log than there's nothing wrong.

You could check if an .htaccess exists in it and that the rights on this file are correct. (Same as the other files ;))

If it isn't a production server, I could take a look in it and try to create a fix for it.

Seth

You can email me or Private Message me with the login for the specific server. As long as it isn't a production server I will try to take a look for you ;)

Probaly is your problem the same as the one Acid-Duck has.

[Acid-Duck]

I'm resuming my discussion here from the other thread since it doesn't seem to be an issue with perl anymore...


I tried un-installing/deleting the plugin and re-installing it. After doing so, I tried loading the awstats section from my control panel but still no luck. Although I was able to go in my user's dir and run awstats.pl -config=VIRTUALHOST and the states were succesfully generated/displayed at virtualhost/awstats. Any oter suggestions?




Erik

[fusionictnl]

In your other thread you're saying perl doesn't output anything ? Awstats uses perl, so if it is still broken. This would be the problem.

[Acid-Duck]

Hi,


After talking to diffrent people, I figured out what happens is that I'm not using a standard bash shell (I'm using what we call bash-bofh to monitor user inter-action on the box if ever needed for whatever reason). BASH-BOFH, from what I can say, doesn't output perl commands properly. If I do perl -le 'print "hello world"' I'll get something printed on my screen.. if I wouldn't have used the "l" switch it wouldn't work. This is what someone answered me the other night when I was asking about how to fix it:


[08:44PM]<@woggle> So always output with a newline at the end.
[08:44PM]<@woggle> Or similar.
[08:44PM]<@woggle> If you leave an incomplete line your shell will overwrite it.
[08:44PM]<@woggle> You can see this pretty clearly with perl -e 'print "0123456789"x10'
[08:45PM]<@woggle> Perhaps. Your applications should be well behaved anyways...
[08:45PM]<@woggle> that is, well-behaved enough to end output in a newline.
[08:45PM]<@woggle> Any breakage of your perl apps is entirely unrelated, unless it is about not seeing the last line of
output.


So in other words any perl scripts which are well coded should end the output in a new line (a carriage return). I installed your pluggin and I manually ran phpalldomains and stats were generated for all domains. I visited each www.domain.com/awstats and I was able to click on update and get the stats. What I'm getting to, is that the only thing that doesn't work so far is the actual user interface in directadmin to change the settings of the plugin. Thanks in advance,



Erik

[fusionictnl]

Problem is corrected.

If you're using DA through SSL: https://www.domain.com:2222/ than execute the following command: touch /usr/local/directadmin/plugins/awstats/hooks/ssl.use

[Acid-Duck]

Hi,

Ok well Fusion-ICT beat me to the post but yes that was the problem. He was very helpful in trying to find out what was the problem, we spoke for a good 25-30 minutes. Thanks again!!

Erik

[l0rdphi1]

Originally posted by fusionictnl
Problem is corrected.

If you're using DA through SSL: https://www.domain.com:2222/ than execute the following command: touch /usr/local/directadmin/plugins/awstats/hooks/ssl.use
Maybe I don't know how you're using this, but perhaps this code will detect HTTPS for you:

PHP:
if ( $_SERVER['SSL'] == 1 )
{
// check for extension
if (!extension_loaded('openssl')) die("PHP not compiled with OpenSSL extension. Please recompile PHP.");

$Socket->connect("ssl://127.0.0.1",$_SERVER['SERVER_PORT']);

}
else
{
$Socket->connect('127.0.0.1',$_SERVER['SERVER_PORT']);
}(this assumes $Socket is already an instance of HTTPSocket and you're using PHP. I use this in Installatron.)

Cheers, Phi1.

[fusionictnl]

This will check if you have SSL support compiled (or not?). What if I have SSL support compiled in PHP , but running DA not with SSL :)

I will let the install script check the directadmin.conf and look if HTTPS=1 or something what the directive was :P

[l0rdphi1]

I had asked John a while back to set the ENV SSL equal to 1 when DA is set to run over HTTPS in directadmin.conf. :)

Otherwise, there is no way to check this "on the fly."

Phi1.

[fusionictnl]

You can solve this on the fly simply by checking what url is typed in. if it is https://domain:2222 or http://domain:2222

;)

[l0rdphi1]

Perhaps that's a newer addition to what DA populates. I don't know.

I don't think we would have added the SSL ENV if it wasn't needed. :)

Phi1.

[GillroY]

Yeah! I fixed my problem. Turned out that for some reasen openssl wasn't compiled into php, so a secure connection could not be made. Everythings working now!

[fusionictnl]

I'm glad :) it works!

[GillroY]

Just found a small bug when using the plugin with users with multiple domains and certain skins. (But i've got a fix ready :-))

When users have got more than 1 domain, your code in "index.html" overwrites the $domain variable. So when you click back in (for example) the hermes skin, the domain variable is set to 1, which leads to an error from DA. This can easily be fixed by renaming the domain variable to awdomain everywhere in the file. This is probably not very clear, so here's an example line:

echo "<BLOCKQUOTE><B><BR><A HREF='?config=1&domain=$domain'>Install AwStats on this domain*</A></B><BR>";

becomes

echo "<BLOCKQUOTE><B><BR><A HREF='?config=1&awdomain=$awdomain'>Install AwStats on this domain*</A></B><BR>";

This fix is only needed with certain skins, but I thought I just let all of you know. :)

Oh, and I've got a little question too. I'm trying to improve functionality with multiple domains (I'll show it when it works), but I can't figure this out: How can I use php in the "user_txt.html" file? Any help would be apreciated!

[fusionictnl]

Just found a small bug when using the plugin with users with multiple domains and certain skins. (But i've got a fix ready :-))

When users have got more than 1 domain, your code in "index.html" overwrites the $domain variable. So when you click back in (for example) the hermes skin, the domain variable is set to 1, which leads to an error from DA. This can easily be fixed by renaming the domain variable to awdomain everywhere in the file. This is probably not very clear, so here's an example line:

echo "<BLOCKQUOTE><B><BR><A HREF='?config=1&domain=$domain'>Install AwStats on this domain*</A></B><BR>";

becomes

echo "<BLOCKQUOTE><B><BR><A HREF='?config=1&awdomain=$awdomain'>Install AwStats on this domain*</A></B><BR>";

It's added for the next release ;) thx !


Oh, and I've got a little question too. I'm trying to improve functionality with multiple domains (I'll show it when it works), but I can't figure this out: How can I use php in the "user_txt.html" file? Any help would be apreciated!


We'll I think there's not really any php functionality in the user_txt.html. DA will just add this section to it's output of html.

I think ;)

[jmstacey]

I don't know what you would put php there for, but I assume the same way you do the other pages.
Haven't actually tried it though.


#!/usr/local/bin/php -c /usr/local/lib/php.ini

<?php

?>

[GillroY]

Well, I'm trying to send the "domain" variable in CMD_SHOW_DOMAIN?domain=www.xxx.com to the plugin, so that I don't have to choose the domain from a list again. I allready tried that code, and it didn't work...

[fusionictnl]

The plugin doesn't accept domains as names. It uses an ID to specify the domain. 1 = first, 2 = second etc.

This to prevent giving any random domainname to the script and so having access to someone elses domain ;)

[GillroY]

I know that, but I've written some code that converts the domainname to the right number. And giving a domainname that doesn't belong to the logged in user gives an error. So no harm done by that.

Also passing around the domainname makes sure that the user doesn't have to choose a domain again when it wants to go back to the main menu.

I fixed it temporary by adding a link hard coded into the skin.

By the way, if you're interested in the code, let me know and I'll send it to you!

[fusionictnl]

My script does the converting to numbers. DA will accept only domainnames.

The script does the following:

It reads the domainnames from the users and puts them in an array.

So 0 = the first domain etc. (mistake in my previous post)

But if you add the domain=[number] to the CMD_PLUGIN/awstats/?domain=x it should work.

Domain will be replaced with awdomain in the next release.

[GillroY]

I think you don't understand why I did this. I was getting irritated by having to choose which domain I wanted to config awstats on, while I allready chose a domain when logging in as the user. So now when I click the awstats link, I automatically go to the domain I chose at the login.
Also when I return to the main menu, I won't get a list where I have to choose again. This used to be the case with the unedited plugin. But with my adjustments, I now only have to choose a domain right after login.

[fusionictnl]

Sorry,

I thought you had hardcoded it, not dynamicaly. But if it is dynamicaly I'm very interested in the code ;)

Thx!

[GillroY]

Allright, here's the code.

I replaced this loop:


if ((sizeof($domains)>1)&&(is_null($awdomain))) {
echo "<BLOCKQUOTE><BR><B>Select Domain to Activate</B><BR><BR>";

for ($x=0;$x<sizeof($domains);$x++) echo "<A HREF='?awdomain=$x'>$domains[$x]</A><BR>";

die();
} elseif (sizeof($domains)==1) $awdomain=0;

with


if ((sizeof($domains)>1)&&(is_null($awdomain))) {
$x=0;
while (($x<sizeof($domains)) && ($domains[$x]<>$domain)) {
$x++;
}
if ($x==sizeof($domains)) {
echo 'Error: Domain not found';
die();
} else {
$awdomain = $x;
}
} elseif (sizeof($domains)==1) $awdomain=0;

This means that a variable $domain has to be set with the name of the allready selected domain. Also, this script will give an error if the variable is not set (which can off course be easily fixed, but wasn't nessecery for my purpose).
Because your script connects to DA as the logged in user, setting the $domain variable with a domain that doesn't belong to the user just gives an error because it won't be found in the $domains array.

[GSMedia]

hello,

i've created a domain ictopus.gsmedia.nl, but i can't get stats on it !

well, actually i can, but only by going to www.ictopus.gsmedia.nl/awstats, not ictopus.gsmedia.nl/awstats

for all my other domains it works like a charm! keep up the good work ;)

grtz

[fusionictnl]

As I could remember I already had this question answered.

But you can create a symbolic link in the /etc/awstats dir.

Link for awstats.domain.ext.conf to the file awstats.www.domain.ext.conf

;)

[GSMedia]

hmm .. did you happen to have already fixed that in the current version?

i justed wanted to create a symbolic link, but i got a file exists error, so i checked it out and indeed the symbolic link was already there !! and i´m absolutely sure i didn´t create it!

grtz

[fusionictnl]

When I executed the following command:

ln -s awstats.www.fusion-ict.nl.conf awstats.fusion-ict.nl.conf

the stats works perfectly.

Edit: Looks like you already fixed it! ictopus.gsmedia.nl/awstats works perfectly.

you must look wich config you have to create by looking at the error message that awstats shows. and create the symbolic link for it in /etc/awstats


Ready for next release:

- Automatic check if SSL is in use
- Symbolic link creation
- Minor fixes

Todo for next release:

- Implementing above script to prevent second time domain selection.
- Some small fixes

[GSMedia]

yeah, sorry i didn't told you, but indeed, the awstats worked already !

grtz

[noose]

Hello ;]
When I installed a Awstats I was happy, for first run of stats :( there was a 403 error :( what is going on ?? :( how to repair this ??


errors when I installed awstats for my domain:
Checking if there is already something installed..
AwStats Directory already exists on domain
Checking if awstats files are available...
Checking for AwStats itself
Awstats already exists.
(Re-)Activating CGI for dir
(Re-)Setting permissions
Now (re-)creating your configuration file.
Warning: fopen(/etc/awstats/awstats.www.thc.net.pl.conf): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/user/index.html on line 70 Warning: fwrite(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 75 Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 76 Warning: symlink(): File exists in /usr/local/directadmin/plugins/awstats/user/index.html on line 77 Config file has been created and your statistics are now setup!

[Icheb]

Noose: don't think your permissions in /etc/awstats are correct...

It should be available to the user under which DA runs (correct me if wrong).

[kamsel]

Hello,

After today's DA upgrade awstats for all users stopped working, Error 403.

Very weird.

kamsel

[noose]

Originally posted by Icheb
Noose: don't think your permissions in /etc/awstats are correct...

It should be available to the user under which DA runs (correct me if wrong).
no :( user's don't have stats too :(

[fusionictnl]

Sorry for the late reply


Warning: fopen(/etc/awstats/awstats.www.thc.net.pl.conf): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/user/index.html on line 70 Warning: fwrite(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 75 Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/user/index.html on line 76 Warning: symlink(): File exists in /usr/local/directadmin/plugins/awstats/user/index.html on line 77 Config file has been created and your statistics are now setup!


Remove your /etc/awstats dir completely. It has problems with the permission on this dir. Copy the .txt files into another dir. Just in case it can't get the old statistics back when doing a "update" on the domain.

Remove the plugin from within the control panel.

After that install the plugin again within the control panel.

Try to re-run the process. It should work correctly.

Let me know how it goes ;)

[kamsel]

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?

[jmstacey]

It is working properly for me on 1.22.6

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

[jmstacey]

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 )

[fusionictnl]

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

;)

[jmstacey]

Originally posted by fusionictnl
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.


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.

[fusionictnl]

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 :()

[jmstacey]

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.

[fusionictnl]

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.

[kamsel]

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?

[fusionictnl]

chmod 777 /etc/awstats -R

As this dir has to be read/writable by everyone for configuration options in the user pages

[kamsel]

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

[jmstacey]

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.

[fusionictnl]

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.

[kamsel]

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.

[fusionictnl]

---------
[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.

[kamsel]

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

[rldev]

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.

[jmstacey]

Originally posted by rldev
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.

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.

[rldev]

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?

[jmstacey]

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.

[rldev]

That is a very good idea. It solves the issue. Now if we can get someone to write this script :) It could even be implemented in the plugin.

[fusionictnl]

Updated v1.4:

*- "-rotated=[size]" option added to awstats_updateall.pl (See first MAIN post).

[rldev]

You are fast :) Thank you.

[fusionictnl]

Updated v1.5:

*- Fixed BUG with awdomain not being set, so user level pages don't work.
*- Auto detection of SSL on installation of plugin. No need to manualy touch the ssl.use file
*- Fixed some problems with permissions that weren't set correctly.
*- Hopefully the symbolic links now work with the conf files in /etc/awstats for domain.com/awstats instead of using www

Problems :confused: Let me know :p

[rldev]

I'm not having any luck with the plugin. I followed instructions to add plugin to the server and it does do this, But I can not install it on my domain. I get a blank DA page when I try to install it. It hangs for a while and just displays a blank page. Some observations:

1. It does not create a awstats dir or link in /home/user/*html

2. I see nothing in the /etc/awstats folder, just blank

3. The plugin Manager reports it is version 1.3 and 1.5 is available. But I downloaded the lastedt one. When I try to update, it says update successsful but reports the same version, 1.3

4. I access DA through https

5. I have php safe mode turned off for the domain I am trying to install this on,

6. The domain I am trying to install this on is the primary reseller domain on my system.

Any ideas on how I can troubleshoot this? I see others had the same thing happen to them, but they never posted what they did to resolve the problems.

[fusionictnl]

I access DA through https


If you're using DA through SSL, SSL should be compiled with PHP


So I presume you don't have SSL compiled in PHP. (This is not done standardly in DA)



The plugin Manager reports it is version 1.3 and 1.5 is available. But I downloaded the lastedt one. When I try to update, it says update successsful but reports the same version, 1.3


Fixed, forgotten to increase the version no. in the plugin itself ;) shouldn't make any difference.

[albatroz]

I wonder if you would release someday a version that would include the integration
with Maxmind Geoip location module
http://www.maxmind.com/app/weblogs

[fusionictnl]

Originally posted by albatroz
I wonder if you would release someday a version that would include the integration
with Maxmind Geoip location module
http://www.maxmind.com/app/weblogs

Maxmind as this is a payable solution and awstats has a free solution: "GeoIPfree plugin"

http://awstats.sourceforge.net/awstats_contrib.html#PLUGINS

there's info on how to install it on your machine. Edit the /usr/local/directadmin/plugins/awstats/hooks/awstats.conf

[rldev]

Ok I enabled ssl and the plugin installs. However, everytime I try to update my stats I get the following error:

Error: An AWStats update process seems to be already running for this config file. Try later. If this is not true, remove manually lock file '/tmp/awstats.www.rocksolidnet.com.lock'.

I have removed this lock several times, but I still get the error. Maybe I am missing something.

[fusionictnl]

Check the main config /usr/local/directadmin/plugins/awstats/hooks/cgi-bin

and there should be some file named: awstats.none.conf

Edit this, and look for a row that says:

EnableLockForUpdate=1

Set this to Zero.

remove all .conf files in the /etc/awstats dir and reinstall on all domains.

Good Luck

[rldev]

no luck. stats did not update, but I didn't get any errors either.

It just says Never updated (See 'Build/Update' on awstats_setup.html page) Update now

and shows zeros for everything.

[rldev]

10 minutes later, the stats are mysteriously there. Perhaps I do not understand how they run.

On a different not what do most of you have AllowFullYearView set to?

Seems wrong that a client can not have a yearly view of their stats. But if it will kill server load what can you do.

[SeLLeRoNe]

I tryed to install that upgrade.. i've already a lot of domain.. when i install its all ok.. but if i go on my domains and activate this upgrade doesent work... and if i login like a user i dont find anything to install awstats to user account.. help.. and sorry for my english :P

[davidb]

Ok.. I am tired.. it's late.. and I have been stuggling to figure out what is going on for the last 3 hours..

I have the plugin installed.
Figured out that the default skin doesn't display plugins.
installed it on 1 domain, which appeared to be ok.

try to check the stats and here is the error that shows up in the domain error log..
[Sun Oct 10 00:28:06 2004] [error] [client 65.69.126.252] script not found or unable to stat: /usr/local/awstats

say what???? please help.. I am afraid that my brain just can't take it anymore..

[BritishEnigma]

I need some help please, I an going mad trying to work out how to update all my AWSTATS hourly via a cron job. I have never worked with cron job before. I have tried creating a file called awstats.sh in the cron.hourly folder and in that file I put the same command I use to manualy update all domains. However nothing happens.

Any really easy 123 step guides would be very helpful.

Thanks

[jmstacey]

You should put the cron in the /etc/crontab file.

Something like:

* */1 * * * your_commands

[fusionictnl]

10 minutes later, the stats are mysteriously there. Perhaps I do not understand how they run.

On a different not what do most of you have AllowFullYearView set to?

Seems wrong that a client can not have a yearly view of their stats. But if it will kill server load what can you do.


If you enable full year view, the a client can view the whole year statistics, so this will give some extra load. Not sure how much, because the .txt (history) aren't that big.



I tryed to install that upgrade.. i've already a lot of domain.. when i install its all ok.. but if i go on my domains and activate this upgrade doesent work... and if i login like a user i dont find anything to install awstats to user account.. help.. and sorry for my english :P

This could be an issue with SSL. :s You could check if the ssl.use exists in the /usr/local/directadmin/plugins/awstats/hooks dir.

At install/upgrade time of your plugin it checks the /usr/local/directadmin/conf/directadmin.conf, to see if the SSL=0 or 1. But if there's an extra whitespace behind it. It will give a false result and disable's SSL in the plugin.



Ok.. I am tired.. it's late.. and I have been stuggling to figure out what is going on for the last 3 hours..

I have the plugin installed.
Figured out that the default skin doesn't display plugins.
installed it on 1 domain, which appeared to be ok.

try to check the stats and here is the error that shows up in the domain error log..
[Sun Oct 10 00:28:06 2004] [error] [client 65.69.126.252] script not found or unable to stat: /usr/local/awstats

say what???? please help.. I am afraid that my brain just can't take it anymore..


[Sun Oct 10 00:28:06 2004] [error] [client 65.69.126.252] script not found or unable to stat: /usr/local/awstats

This error shouldn't be displaying /usr/local/awstats. What this could be is that it isn't finding it's lib files in the users public_html/awstats

The directory should have the following files:

awstats.pl (awstats script), lang (symlink), lib (symlink), plugins (symlink), and .htaccess (enabling CGI and awstats as index file).

If any of these "symlinks" are missing it could be that the script will check the default dirs like /usr/local/awstats.

Try reinstalling the plugin on the domain (user-level with enhanced skin) or use "/usr/local/directadmin/plugins/awstats/hooks/alldomains.php" to install it on all domains.

And offcourse check if you're using SSL that there IS a file in the hooks dir ssl.use! (Not needed for alldomains.php script)


Please let me know if it works and how you changed it, so I can implement some extra checks/steps etc. in the plugin

[davidb]

it runs OK from the command line.. all of the appropriate symlinks are in place. Other thoughts? still no go from the browser..

[fusionictnl]

Check the rights on the DIR and the other files in the public_html/awstats. For example check the apache error log and the suexec log in the /var/log/httpd/domains/

If it runs OK from commandline it should work OK from the browser as CGI.

You could check the contents of the .htaccess file in the dir.

[davidb]

ok..

1. I can't find the suexec logs
2. what permissions am I looking for? I can su to apache (after chaning the shell) and run it

[fusionictnl]

Check your PM's (Private message) ;)

[BritishEnigma]

Currently my crontab file looks like this,

-----------------------------------------------------
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
-----------------------------------------------------

I need to find a method of putting the update stats command current run manually in to run every hour.

I understand the command is "/usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats_updateall.pl now -awstatsprog=/usr/local/directadmin/plugins/awstats/hooks/cgi-bin/awstats.pl"

But every time I try then wait for a few hours, nothing happens all stats just remain unchanged.

I am sure there are other people with this problem as well.

PLEASE help ...thanks

Stephen

[fusionictnl]

Try putting perl in front of it. And check you're servers email. Errors will be witten in an email to root@[hostname]

[Chrysalis]

I installed and got this when trying to view the user's stats page.

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

Do I need to wait for a cron to run first?

[Chrysalis]

from error log

[14:16] <!Chrysalis> [Sun Oct 17 12:08:18 2004] [error] [client 82.3.32.75] Premature end of script headers: /home/admin/domains/XXXXXXX/public_html/awstats/awstats.pl

[Haayer]

I installed the plugin 1.5 and there were no errors, but the stats are not counting.

There are also no errors in the error log.

I also waited 24 hours just to be sure and watched againg. I installed it on a user with 1 domain and on a user with multiple domains, both the stats keep empty.

[fusionictnl]

Originally posted by Chrysalis
from error log

[14:16] <!Chrysalis> [Sun Oct 17 12:08:18 2004] [error] [client 82.3.32.75] Premature end of script headers: /home/admin/domains/XXXXXXX/public_html/awstats/awstats.pl

This is a rights problem. Could you check the permissions on

/home/admin/domains/XXXXXXX/public_html/awstats/awstats.pl

and be sure it is Executable.



installed the plugin 1.5 and there were no errors, but the stats are not counting.

There are also no errors in the error log.

I also waited 24 hours just to be sure and watched againg. I installed it on a user with 1 domain and on a user with multiple domains, both the stats keep empty.


Do you get the normal awstats page ? If so check the log file of the user /var/log/httpd/domains/domainname.log

If it has entry's in it check the /etc/awstats/awstats.domainname.conf and check the LogFile=[file]

It should be pointing to the users log files of httpd (apache).

[Chrysalis]

its already 755 so executable permissions are set.

[fusionictnl]

Originally posted by Chrysalis
its already 755 so executable permissions are set.

Owner is the user of that domain ?

Check the /var/log/httpd/suexec log file ;)

[davidb]

Thought I would check and see if you had figured out how to remedy the issue found on my setup..

Thanks for the work!

[fusionictnl]

So it is solved ? :confused: :D

[Haayer]

Originally posted by fusionictnl
Do you get the normal awstats page ? If so check the log file of the user /var/log/httpd/domains/domainname.log

If it has entry's in it check the /etc/awstats/awstats.domainname.conf and check the LogFile=[file]

It should be pointing to the users log files of httpd (apache).

The log file in /var/log/httpd/domains/domain.nl.log is correct checked it with tail -f domain.nl.log
Also checked in /etc/awstats/awstats.www.domain.nl.conf the LogFile= option is pointing to /var/log/httpd/domains/domain.nl.log

But the stats are staying empty:confused:

[fusionictnl]

Does the error.log show anything of that specific domain ? (Or are it all domains?) Does the suexec_log show anything ?? (/var/log/httpd/suexec) ?

[Chrysalis]

Originally posted by fusionictnl
Owner is the user of that domain ?

Check the /var/log/httpd/suexec log file ;)

[2004-10-19 13:36:23]: info: (target/actual) uid: (admin/admin) gid: (admin/admin) cmd: awstats.pl
[2004-10-19 13:36:23]: error: target uid/gid (1001/1005) mismatch with directory (1001/1004) or program (1001/1004)

so I do a chown admin:admin then?

[Chrysalis]

ahh looked at the error and fixed it, seems . owner:group has to match that of awstats.pl.

is there a way to remove this requirement?

[fusionictnl]

Depends on who's files these are.

For /home/user1/public_html/awstats

The files are user1:user1 (Owner user1)

For /home/admin/public_html....

The files are admin:admin (Owner admin)

The permissions should be set correctly to the user of wich the domain/folder is

[Chrysalis]

my admin is in wheel group so has admin:wheel

directadmin is trying to use it as admin:admin (linux system), which is what caused the problem.

I have a duff admin group which I made to satisfy apache, so just set the ownership of the dir to admin:admin which shouldnt break anything as the admin user is still the owner, but this is another freebsd incompatibility with directadmin.

[davidb]

I was exploring around and found some information from a past awstats install in the httpd.conf file. What should be in the httpd.conf file in regards to awstats?

[fusionictnl]

Originally posted by davidb
I was exploring around and found some information from a past awstats install in the httpd.conf file. What should be in the httpd.conf file in regards to awstats?

We'll my plugin doesn't change the httpd.conf, so I don't know if you did it ;)

For awstats there doesn't have to be any entry!

[Chrysalis]

Ok I got another problem now, it is working great on my admin user but any other user's made on directadmin dont have any button for awstats. Is there something I need to do to enable it for all users?

[fusionictnl]

If it is there for the user admin on "User-Level", it should be there for the users on their "User-Level".

This is how the plugin system works.

[sde]

when i am at a user level and try to install awstats on a domain, it does not seem to pick up the domain name:

for example, one error when i try to install from the user level is: Warning: mkdir(/home/someuser/domains//public_html/awstats):

the /etc/awstats/ directory would support this as the log file it creates there is: awstats..conf

what could i be doing wrong?

[sde]

port 2222 is hard coded on the socket connect functions for the /user files.

i run da on port 8080

to fix this, i changed the port to 8080 in the $Socket->connect() function of the /user files.

could this possibly be a configuration variable somewhere in future updates?

excellent plugin btw, .. thanks a lot!

[Haayer]

Originally posted by fusionictnl
Does the error.log show anything of that specific domain ? (Or are it all domains?) Does the suexec_log show anything ?? (/var/log/httpd/suexec) ?
It's a problem with all domains. And the error.log shows
nothing strange. No errors about awstats.
Suexec_log shows :

[2004-10-20 20:33:36]: info: (target/actual) uid: (jhon/jhon) gid: (jhon/jhon) cmd: awstats.pl
[2004-10-20 20:33:38]: info: (target/actual) uid: (jhon/jhon) gid: (jhon/john) cmd: awstats.pl
[2004-10-20 20:33:38]: info: (target/actual) uid: (jhon/jhon) gid: (jhon/jhon) cmd: awstats.pl

that 's for the user jhon when i try to open www.domain.com/awstats

[davidb]

Ok.. I found some more info on the issue that I was having where the stats won't run.. Your script doesn't work for webs that have been extended with Microsoft FrontPage Extensions. I haven't had time to try and figure it out below that, but perhaps you can chase it down further..

[fusionictnl]

Originally posted by davidb
Ok.. I found some more info on the issue that I was having where the stats won't run.. Your script doesn't work for webs that have been extended with Microsoft FrontPage Extensions. I haven't had time to try and figure it out below that, but perhaps you can chase it down further..

The directory structure isn't affected when installing FP Extensions. So it should work correctly. (Tested it!)

Could you check if the: /home/[user]/domains/.../public_html/awstats exists ? If it does, you can try using the all_domains.php in the hooks dir, to check if it works after that ? this will install it on all domains, using another approach.

Haayer

Same as above:

Could you check if the: /home/[user]/domains/.../public_html/awstats exists ? If it does, you can try using the all_domains.php in the hooks dir, to check if it works after that ? this will install it on all domains, using another approach.


sde

You can edit the /hooks/da.php and alter:


function connect($host, $port = '' )
{
if (!is_numeric($port))
{
$port = 80;
}

$this->remote_host = $host;
$this->remote_port = $port;
}

To:


function connect($host, $port = '' )
{
if (!is_numeric($port))
{
$port = 80;
}

$this->remote_host = $host;
$this->remote_port = 8080;
}


:D

[sde]

thanks fusionictnl.

[davidb]

ok.. after updating apache with the directadmin build commands it runs if specified /awstats/awstats.pl.. I haven't been able to get it to run as a directory index file yet.. perhaps tonight I will get this one hammered out.. In the meantime, a re-direct index.html page to the .pl script would be nice..

[fusionictnl]

The .htaccess in the /awstats dir should do this for you! Check it's permission ;)

[davidb]

nope.. definitely something with fp server extensions screwing up the ability of the htaccess to work correctly..