Problem Awstats

[santerref]

Hello Everything work find for me on my server with ispCP, but awstats doesn't "work".

When someone register a domaine, the email says that the stats are there :

Code:

www.domaine.com/stats/

And it says that the username is domaine.com and the password 12983. When i try to see the stats it doesn't work. The password don't work.

I go see in MySQL and in the table htaccess_users i can see that there is the hash but not the uname. Uname = NULL.

So i think that the panel don't create the good htaccess so we cannot have access the our statistique.

When i setup the panel i choose the default option for awstats (i think it was dynamic...).

Santerref
Sorry for my english...I'm better in french

[pgentoo]

It seems like awstats should be validating against this table, but the template says otherwise...

Code:

ispcp debian # cat apache/parts/dmn_awstats_dynamic_entry.tpl
   ProxyRequests Off

   <Proxy *>
      Order deny,allow
      Allow from all
   </Proxy>

   ProxyPass                    /stats  http://localhost/stats/{DMN_NAME}
   ProxyPassReverse             /stats  http://localhost/stats/{DMN_NAME}

    <Location /stats>
        AuthType Basic
        AuthName "Statistics for domain {DMN_NAME}"
        AuthUserFile {WWW_DIR}/{DMN_NAME}/{HTACCESS_USERS_FILE_NAME}
        AuthGroupFile {WWW_DIR}/{DMN_NAME}/{HTACCESS_GROUPS_FILE_NAME}
        Require group {AWSTATS_GROUP_AUTH}
    </Location>

I actually have the same problem, it seems that the password set there is the original password that the domain is added with (maybe?), and after updating the users password, the .htpasswd doesn't get updated and login fails with the current password.

It would be nice to get this going with mod_auth_mysql, or similar. Until that happens, or this gets fixed, you might want to just use "htpasswd" tool to update the password in the .htpasswd file in question.

Hope that helps,
pGentoo

[santerref]

Is it possible to desactivate the password request when we want to see the stats during the time the this gets fixed?

[pgentoo]

Just manually reset the password to something that you know:

Code:

htpasswd /var/www/virtual/domain.com/.htpasswd domain.com

[santerref]

But i'm making a webhosting association and if i have 30 clients in the same day it will be longue... I think i will make a little message on my site to explain the situation it will be better

[sci2tech]

When a new domain is created a default user is added identical with user used for login, with same password. Later this user can be removed, or password changed using Webtools -> Group / User management. There you have a group named statistics than can not be edited. Any user that is in this group can access awstats data. No user -> no statistics. Altering user password used for login in control panel do not change password for awstats. This password can be changed only from Webtools -> Group / User management.

[pgentoo]

(01-08-2009 01:46 AM)sci2tech Wrote:  When a new domain is created a default user is added identical with user used for login, with same password. Later this user can be removed, or password changed using Webtools -> Group / User management. There you have a group named statistics than can not be edited. Any user that is in this group can access awstats data. No user -> no statistics. Altering user password used for login in control panel do not change password for awstats. This password can be changed only from Webtools -> Group / User management.

Sci2tech,

Thanks for that clarification. I looked in "Protected Areas", but I saw right away that "You do not have protected areas", so I didn't think it was managed like that.

Doesn't it make sense to tie this password to the account password though? We request that the user changes their password upon first login, but then they will have to go change this seperately so they don't forget it.

I just thought it would work a little cleaner if they were tied together... Thoughts?

Would it make more sense to manage the passwords for stats entirely through their "Protected Areas" interface, instead of in the actual VirtualHost? That way they would see right away that they have a protected area called "Statistics", and they could even remove the user/password if they wanted to.

Just some ideas...

-
pGentoo

[sci2tech]

(01-08-2009 04:23 AM)pgentoo Wrote:  Doesn't it make sense to tie this password to the account password though?

There are not tie together and should not be. This user (I speak about protected areas) can be removed, or password can be changed. I guess that is better not to add a default user, and better just tell in account creation email that they can add users to this area using Webtools -> Group / User management. The idea was that everybody can add as many users as they need for this area (and users to be named freely not using a pattern like user@domain.tld).

(01-08-2009 04:23 AM)pgentoo Wrote:  Would it make more sense to manage the passwords for stats entirely through their "Protected Areas" interface, instead of in the actual VirtualHost? That way they would see right away that they have a protected area called "Statistics", and they could even remove the user/password if they wanted to.

I did not wanted to use "Protected Areas" interface mainly because no .htaccess file is generated. Things were more complicated to tunnel authenticate date trough proxy and keep synchronization between user folder htaccess and awstats directory. But I guess we can add a form that permit to edit user belonging to statistics group in "Protected Areas" just to make things simpler for users. It a first implementation, and always can be improved. Any suggestion is welcomed.
Daniel Andreca aka sci2tech