This HOWTO was inspired by a need to figure out a way to automatically create .htaccess and associated .htpasswd files for specified directories without having a separate userid and password to have to maintain.

I have come up with a solution to this problem and have created a perl script that handles exactly this. This script is unique in the regard that it uses either site admins information or both site admins and users (name and password) to generate a .htaccess and .htpasswd file. Syncronization of this information occurs when running this script as a cron job.

It is particularly important to having protection for directores such as /awstats, where sensitive site stats information is left open by default. With recent exploits found (although fixed with the latest awstats), this is a must have for protecting these locations from unwanted visitors.

Please read the information in the comment section of the script prior to running. Although I have a high confidence level with this script, I must state to use at your own risk and understand what this script is doing. Running this script in debug mode and using it with one domain (specified as a command line option) is strongly suggested before implementing for all domains.

V1.1 - REVISION 02/23/05:
====================
I have revised the original script to now handle either site admin or both site admin and users associated with a virtual domain. You may choose either method for any directory listed in @protected_dirs.

V1.2 - REVISION 03/24/05:
====================
There was an issue in the previous version (1.1) when using "all" as the parameter in @protected_dirs which essentially allowed all users from each domain being processed to be added to the next domain -- not a good thing.

The new version fixes this issue, plus provides the option to force delete all domains htpasswd file before re-creating it. If you have been using v1.1 or previous you will want to enable this option for the first run through the application by setting the variable $force_delete_htpasswd to 1. Then set this back to the default value of 0 when done.

The sitelookup application is now a variable. The default is Ensim's sitelookup, however, you may use Doobla's dsitelookup as a replacement.

COMMENT 02/23/05:
===============
Doobla has created an application called dsitelookup which provides the same functionality as Ensim's sitelookup, except with much better performance. Due to the frequency that the autoprotect script should be executed in cron, I highly suggest replacing sitelookup with dsitelookup.

Download sitelookup here:

http://www.doobla.com/ensim/dsitelookup
-------------------------------------------------------------------------------------

The autoprotect script can be downloaded here:

http://www.cacheweb.com/ensim/autoprotect_...t_ensim_dirs.pl

I had to remove the code in this thread due to exceeding the length of the post.

Just wanted to point out that if you use dsitelookup instead of sitelookup you will see a dramatic increase in speed when running the script. dsitelookup is completely compatible with ensim's sitelookup utility (to the best of my knowledge) with added functionality and increased speed.

You can get it at http://www.doobla.com/ensim/dsitelookup

Many thanks for your implementation. I think I'll put it to good use.

Hope my contribution helps (especially considering the frequency that the script needs to run).

God Bless,

Jon

Doobla,

Your dsitelookup application works great! I would highly recommend everyone using this as a replacement for sitelookup in my autoprotect script. There is indeed considerable improvement in performance, plus will allow more frequent execution using less system resources.

The original howto has been modified to add dsitelookup as a suggested replacement in the script.

Thanks again,
Frank

hehe, thanks. I think I might contact you for a testimonial when I get the project page up My goal is to make it as compatible as possible (i.e. 100%) with ensim's so as to be a complete replacement in /usr/local/bin. In fact, I rename sitelookup on my own system and hardlink dsitelookup to sitelookup and scripts such as EditVirtDomain and AddVirtDomain, etc work much faster as a result.

Glad ya liked it,

Jon

WTG Frank & Jon! I look forward to implimenting this.

I'm revising the autoprotect script to include support for multiple users on a domain. For example, it may not be reasonable to only allow the site admin to have access to the /awstats directory. This would also alleviate forcing the site admin to provide the admin information to standard users.

I have revised the original script to now handle either site admin or both site admin and users associated with a virtual domain. You may choose either method for any directory listed in @protected_dirs.

You can download the latest version here:
http://www.cacheweb.com/ensim/autoprotect_...t_ensim_dirs.pl

I have modified this application to version 1.2. There was an issue in the previous version (1.1) when using "all" as the parameter in @protected_dirs which essentially allowed all users from each domain being processed to be added to the next domain -- not a good thing.

The new version fixes this issue, plus provides the option to force delete all domains htpasswd file before re-creating it. If you have been using v1.1 or previous you will want to enable this option for the first run through the application by setting the variable $force_delete_htpasswd to 1. Then set this back to the default value of 0 when done.

The sitelookup application is now a variable. The default is Ensim's sitelookup, however, you may use Doobla's dsitelookup as described earlier in this thread.

You can download the latest version here:
http://www.cacheweb.com/ensim/autoprotect_...t_ensim_dirs.pl

Sorry for asking what might be the obvious question. In order to use dsitelookup, I just replace the dsitelookup file with sitelookup located in /usr/bin/sitelookup?

Just that right? No need to make any configurations changes?

Thanks in advance.

In the script, replace his reference to sitelookup with the path to your copy of dsitelookup and save. That is it.

I actually just backup ensim's sitelookup utility and replace it on the system with my own, but since this is just my pet project you may or may not feel like going that far. If you do then you'll see speed increases in other ensim scripts, however.

Jon

But I don't know who is using sitelookup because i sometimes see sitelookup process running and it takes up a lot of resources. I personally don't use sitelookup as i am not even sure what it's used for.

I think i'll replace dsitelookup with ensim's sitelookup. Hopefully nothing breaks.

Can this script be used so ONLY **SERVER** admin can protect all AWSTATS folders in each site's tree with a single login/password or must it be individually created?

Not yet, although I'll see what I can do to integrate this functionality into the program.

Anyone know where the encrypted Ensim admin password is stored? It would be nice to be able to rip that out and use it for authentication in the generated .htaccess files for each site.

Frank

This all worked very well, thank you for both of these scripts.

However, there is one thing to mention.

I tried adding the cron job as per the intructions in the file and it ran but did nothing. Turns out the "-q" flag should not be there... took it out and it worked fine.

AFAIK the fact that the output goes to /dev/null would negate the need for a "quiet" mode anyway.

Please excuse me if I am wrong, just thought you should know

Does all of this still work for Ensim X?

-Strider

Yes, the script is working fine on Ensim X!

Thanks cweb by the way

I think we just had a problem with the cron job example and had to remove the "-q" option there. Works like a charm now.