ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Security and Passwords
|
Contents Monitoring Apache Log Monitoring Log Management Configuration Management Security and Passwords Keeping Apache Up to Date Other Systems and Extensions Scheduling Maintenance |
User life cycle management may not be one of your first thoughts during the lifetime of your Web server, but it’s a critical part to keeping the system running and ensuring the security of the environment. It doesn’t matter whether you are using
standard HTTP authentication, an authentication system mapped to a MySQL or other database, or your own internal system; you need to keep a track of those people to whom you have granted access.
The key part of user life cycle management is to ensure their ID and access is granted only while they are actually allowed to access the system. This means regularly checking your user list and HTTP authentication systems to ensure only those users who should have access to your servers do.
One way to do this is to keep a separate log of the users added to the system and when (both manually and automatically). The moment a user leaves, remove him or her from the authentication system. Periodically, you should also go through Web site access logs to check who has been using the system recently.
There are two reasons for this. First it highlights any errors. Second, it enables the removal of users from the authentication system if they’ve been inactive for a reasonable period. On secure sites, such as an intranet, checks should be performed
every month; on unsecured sites, checks should be run every three months. Remove anyone who hasn’t used the system in that time period. They can always be granted access at a later stage if need be.
Keeping Apache Up to Date
The final component of server maintenance is monitoring the process of updating your Apache installation to the latest version. We can’t emphasize enough: Never install a version of Apache on a production or live system without first testing it. To test, we keep a copy of the latest site, configuration, and other information on a VMware or VirtualPC machine; install a copy of Apache; and test the effects.
For these machines, as well as developmental and other non-critical machines, we use a directory structure to hold Apache sources during building. We keep a separate directory for each instance of an Apache server — not just each version. For machines running multiple Apache instances, it’s vital to have a separate installation directory and source structure for each one.
Here, is a sample structure from a main Web server that holds three instances for development, staging, and production Web sites:
production/httpd-2.0.46/ devel/httpd-2.0.46/ devel/httpd-2.0.49/ staging/httpd-2.0.46/ staging/httpd-2.0.49/ |
There is a separate build directory for each version of Apache within each instance. One of the issues with Apache is that you must configure and then build the system using the correct options — not specifying a dynamic structure or the additional modules you want can cause problems. So, within each instance directory sits a script that holds the configuration command line used to configure the Apache server instance.
For example, the script might contain:
./configure --prefix=/export/http/staging-apache --enable-shared=dav |
This works with any version of Apache to configure the sources for the correct instance. If a new version comes out, just re-run the script in the new source directory. Whatever configuration options were active with the current version will then apply to the new one, no need to remember the configuration and command line options used months ago when the previous edition came out.
