AwStats plugin for DA [Still in BETA]

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 :(
 
Getting a blank page

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?
 
Last edited:
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 ;)
 
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
 
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.
 
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
 
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.
 
Awstats

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
 
Last edited:
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
 
fusionictnl said:
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:
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.
 
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
 
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.
 
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.
 
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!
 
Back
Top