welcome hpws docs hp-ux webservers home contact hp support
hp logo - invent  hp-ux web server suite

User Guide for HP-UX Web Server Utilities


Overview Cache_util.pl Chroot_os_cp.sh Mkcert.sh Test_certmig.sh Legal Notices


These utilities provide functions that are unique to the HP-UX Web Server Suite. They are located in /opt/hpws/apache/util.


Cache utility. This interactive utility helps in the creation of a cache.conf file for use with mod_file_cache. Performance of HP-UX Apache-based Web Server can be improved for serving of static content by using mod_file_cache. Frequently accessed static files can be pre-loaded into memory and served directly in order to avoid frequent disk access. Files to be cached by mod_file_cache are listed in /opt/hpws/apache/conf/cache.conf file. The entries in this file are of the form: CacheFile /fullpath/file cache_util.pl examines the access_log file and determines the most frequently used resources in order to create a cache.conf file. USAGE: 1) Run the cache_util.pl : % cache_util.pl Default values for input parameters are displayed within square brackets when prompted for. Either enter a new value or hit RETURN (to accept default value) when prompted. 2) Verify the generated file (cache.conf): URLs found in access_log that are neither files nor directories are not listed in cache.conf. Following are the two primary steps involved in the verification of cache.conf. a) This utility does not distinguish between static and dynamic content files. Entries referring to files (such as *.jsp,*.pl,*.php) that are used to generate dynamic content need to be removed manually from the generated cache.conf. b) If a frequently accessed resource is a directory, the utility generates the following line: # CacheFile /directoryname/index.html The line is commented out and has a 'index.html' suffix. Often, in the simplest cases the default file served when accessing directory is index.html. When this is the case, the administrator can simply uncomment these lines. But when some other file is served by default, these entries need to be fixed on a case by case basis or left as it is since they are harmless comments. COMMENTS: cache_util also displays a table of the most frequently accessed resources (all kinds). This table does not necessarily directly correspond to the entries in the created cache.conf file. The difference being that the cache.conf file contains entries that refer to only files or directories whereas the table displays all resources. It ranks resources by the number of associated hits. Thus this tool can also be used to simply analyze which resources are being accessed most frequently. Creation of cache.conf file can be bypassed by answering 'N' when prompted "Create ./cache.conf file ?". If a cache.conf already exists, it is backed up into cache.conf.old before being overwritten.


Chroot Copy utility. This is a helper script that sets the stage for chroot by copying typical files needed by HP-UX Apache-based Web Server, into the chroot directory. We have selected a typical set of files that will allow demo web pages to run. A very secure Apache may require some of these files to be deleted. If you need additional things to be done as part of chroot setup, you are encouraged to customize this script for your site. The Chroot directive sets the root of the file system within HP-UX Apache-based Web Server. This prevents access outside of the chrooted directory. USAGE: % chroot_os_cp.sh OPTIONS: None ENABLING CHROOT: 1. Stop Apache. (Since Apache 2 re-reads the configuration file when stopping or starting, the next changes to the configuration file will cause Apache to look in the chroot path. 2. Uncomment the Chroot directive and define the chroot directory. By default the "Chroot" directive is set to "/var/chroot" in the httpd.conf file. You must specify an absolute path or Chroot will fail. 3. As root run the /opt/hpws/apache/util/chroot_os_cp.sh script to create the chroot directory. If mkdir fails to create the directory do it manually and rerun the script. 4. Start Apache. It is now running within the chrooted directory. Add or delete files as necessary. TROUBLESHOOTING: 1. Functionality such as perl fails Look in $APACHE_HOME/logs/error_log for "Can't open shared library" errors. Copy required file into chroot dirs. Use chatr to show shared library list. For example % chatr /opt/perl/bin/perl Another strategy is to test the executable directly. For instance % chroot /var/chroot $APACHE_HOME/cgi-bin/test-cgi 2. chroot_os_cp.sh script fails Comment out offending line and rerun the script. This is a helper script that may not work on all systems. This utility is provided as support for those using the chroot feature with HP-UX Apache-based Web Server. CAVEATS: - "apachectl restart" fails with chroot since it's outside the chroot file system. - suEXEC within chroot requires the user/group information to be valid within the chroot directory as well. - The following components are currently not supported with chroot: + cgid + DAV + server-status + server-info + Tomcat + suEXEC + FrontPage Server Extensions More information on cgid, DAV, server-status and server-info can be found in the FAQ.


SSL Certificate Generation Utility. This script generates private keys, certificate signing requests, and certificates for the CA, server, and client. Before you use mod_ssl you should prepare the SSL certificate system by running the 'mkcert.sh' command. For different situations, the following variants are provided: To view a certificate (displays the generated data) % mkcert.sh --view To generate a Client certificate (signed by own CA) % mkcert.sh --client To generate a custom CA certificate % mkcert.sh --ca To generate a custom certificate (signed by own CA) % mkcert.sh --custom To generate a dummy certificate (dummy self-signed MYCA cert) % mkcert.sh --dummy To generate a test certificate (test self-signed MYCA CA) % mkcert.sh --test Use type=dummy when you're a vendor package maintainer, type=test when you're an admin but want to do tests only, type=custom when you're an admin willing to run a real server (The default is type=test) Additionally add --algo=RSA (default) or --algo=DSA to select the signature algorithm used for the generated certificate.


This utility is a wrapper around certmig. It can be used to test the functionality of certmig, including certificate importing and extracting a certificate from a Netscape Certificate Database. OPTIONS AVAILABLE: --import : Imports a certificate (client.crt,client.key) into a Netscape Certificate datebase. --extract: Extracts a certificate from Netscape Certificate database into client_e.crt and client_e.key files. --list : List the certificate (names) in the Netscape Certificate database. --test : Tests the functionality of /opt/hpws/apache/bin/certmig, both import and extract features. REQUIREMENTS: a. A Netscape Certificate database (cert7.db and key3.db files) NOTE: If there is no database, invoke the netscape browser and it will create a database in $HOME/.netscape. You can use that database for performing any testing. Ensure that the Netscape Cert DB is valid HOW TO RUN: certmig -L -d <Netscape DB directory> b. For "import"ing a Certificate into Netscape database - A valid Netscape Certificate database as mentioned in "a" (above) - A Certificate file / key pair (client.crt, client.key files). c. For "extract"ing Certificates from Netscape database - A valid Netscape Certificate database as mentioned in "a" (above) HOW TO RUN/TEST: a. cd /opt/hpws/apache/util b. To test : ./test_certmig.sh --test c. To list certificates : ./test_certmig.sh --list c. To import certificate : ./test_certmig.sh --import d. To extract certificate : ./test_certmig.sh --export USAGE: ./test_certmig.sh [--import|--extract|--list|--debug|--test] NOTE: ./test_certmig.sh is a wrapper around the /opt/hpws/apache/bin/certmig. ***************************************************************************