Notes from when I got & installed the "IBM HTTP Server Powered by Apache!" from http://w3.software.ibm.com/webservers/html/downloads.html#apache, I followed the "56-bit IBM HTTP Server powered by Apache 1.3.3" link, which took me to ftp://f3.networking.ibm.com/pub/products/websphere/httpservers/v133/aix/56bit/HTTPServer.aix.export.tar.Z. Downloading that file got me -rw-rw-r-- 1 jasper jasper 11207701 Feb 04 14:29 HTTPServer.aix.export.tar.Z which expanded to these 4 files, -rw-r--r-- 1 jasper jasper 31744 Nov 10 05:23 gskre301 -rw-r--r-- 1 jasper jasper 7205888 Nov 10 05:24 gskrf301 -rw-r--r-- 1 jasper jasper 5120000 Jan 27 13:53 http_server.base -rw-r--r-- 1 jasper jasper 819200 Jan 27 13:54 http_server.modules I created a .toc file from these 4 files & installed these 5 filesets, gskre301.base gskrf301.base http_server.base.core http_server.base.source http_server.modules.ssl The 2 "gsk" filesets are the "Global Security Kit" which includes a ikmgui utility to handle SSL keys. The http_server.base.core fileset contains a /usr/lpp/HTTPServer/Readme.httpserver, but it doesn't say too much. The default web configuration brings up the web server documentation, but how do you start the web server? The answer is, as root, type /usr/lpp/HTTPServer/sbin/apachectl start (for earlier versions of Apache) /usr/HTTPServer/bin/apachectl start (for later versions of Apache) How did you know to do that? Look at the online documentation. What? You can't look at it 'till you bring up the server? Sounds like a Catch-22 situation to me. Where's the default httpd.conf file? It's not in /etc. For early versions of IBM's Apache web server, it was at /usr/lpp/HTTPServer/etc/httpd.conf (for earlier versions of Apache) /usr/HTTPServer/conf/httpd.conf (for later versions of Apache) How are you suppose to know that? Again, I'm not sure. I found it out by doing an AIX kernel trace of File Opens. ------------------------------------------------------------------------ Notes from when I tried getting the Apache server to use the Verisign SSL certificates in the keyfile.kyr & keyfile.sth files, in the /afs/alm/cs/datafactory/Pserver/source/makepass/SSL_Certificates/www directory. 1) The default place the /usr/lpp/HTTPServer/etc/httpd.conf.sample.ssl wanted the keyfile to be at was /usr/lpp/HTTPServer/keys/keyfile.kdb, but that directory didn't exist, so as root, I mkdir /usr/lpp/HTTPServer/keys 2) Start IBM's Key Management GUI program. Again, as root and AFS-authenticated as jasper ('cause the /afs/alm/cs/datafactory/Pserver directories are protected), export JAVA_HOME=/usr/jdk_base ikeyman & 3) From within that program, select Key Database File Open (or just click the "Open a key database file" icon) /afs/alm/cs/datafactory/Pserver/source/makepass/SSL_Certificates/www/keyfile.kyr The Password is "Melanie is in 1st grade." without the double quotes. A lesson on terminology first. - /afs/alm/cs/datafactory/Pserver/source/makepass/SSL_Certificates/www/keyfile.kyr is a "key ring" file. It contains the public/private key pair for the Patent Server www certificate. It also contains the Verisign certificate. This file is encrypted. Key ring files have a .kyr extension. - /afs/alm/cs/datafactory/Pserver/source/makepass/SSL_Certificates/www/keyfile.sth is a "stash" file. It contains the password used to decrypt the key ring file. The web server uses this file when it runs. Stash files have a .sth extension. - A "Key Database" file has a .kdb extension, and is what the Apache web server wants in its Keyfile statement in its httpd.conf file. Note this is different than the IBM's Internet Connection Secure Server (ICSS) for example, where it wanted a key ring file, e.g. /usr/lpp/internet/server_root/keyfile.kyr. The Key Management utility calls this a "CMS key database file". We are going to take the key ring file used on the Patent Server's www web servers and convert it to a key database file, useable for the Apache web server. 4) Save as a key database file. Select - Key Database File - Save As... - Change "File Name:" field to patent.www.kdb - and "Location:" field to /usr/lpp/HTTPServer/keys. If you notice, the "DB-Type:" field changed to "CMS key database file". - Exit the Key Management program. 5) Point the Apache web server to that key database file, cd /usr/lpp/HTTPServer/etc cp -p httpd.conf.sample.ssl httpd.conf vi httpd.conf - Change the "Keyfile /usr/lpp/HTTPServer/keys/keyfile.kdb" line to "Keyfile /usr/lpp/HTTPServer/keys/patent.www.kdb". 6) Start the web server. /usr/lpp/HTTPServer/sbin/apachectl start and ... I couldn't connect to the SSL port. Had a problem that was identified in the error log at /usr/lpp/HTTPServer/var/log/error_log, namely [Thu Jun 17 11:55:46 1999] [crit] mod_ibm_ssl: GSK could not initialize, Invalid password for keyfile. I had forgotten to copy the "stash" file. As root, cd /afs/alm/cs/datafactory/Pserver/source/makepass/SSL_Certificates/www cp -p keyfile.sth /usr/lpp/HTTPServer/keys/patent.www.sth Restart the web server /usr/lpp/HTTPServer/sbin/apachectl stop /usr/lpp/HTTPServer/sbin/apachectl start and everything worked as expected. ================================================================================= Apache comes with its own utility, /usr/HTTPServer/bin/dbmmanage, to manage those AuthDBMUserFile password files, those guys with the .pag and .dir file extensions. Here's the help text on it. Usage: dbmmanage [enc] dbname command [username [pw [group[,group] [comment]]]] where enc is -d for crypt encryption (default except on Win32, Netware) -m for MD5 encryption (default on Win32, Netware) -s for SHA1 encryption -p for plaintext command is one of: add|adduser|check|delete|import|update|view pw of . for update command retains the old password pw of - (or blank) for update command prompts for the password groups or comment of . (or blank) for update command retains old values groups or comment of - for update command clears the existing value groups or comment of - for add and adduser commands is the empty value The check command is used to validate a password, i.e. it'll tell you whether a password you type in, is valid for a given userid or not. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - There is also htpassd that allows you to manage DBM files. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - What I wanted to do at NIPO/BIE, was to run the loading tool which required me to be authenticated as somebody in the admin group. On spn07, I found in /arc/ips/config/websrv_ext/httpd.conf that the password file was /arc/ips/security/users_ext, that is, /arc/ips/security/users_ext.dir and .pag. Although there is a dbmmanage in /usr/HTTPServer/bin, the one BIE uses is at /arc/ips/security, which is an old version with little function, only dbmmanage filename [add|adduser|delete|view] [username] versus dbmmanage filename [add|adduser|delete|view|check|import|update] [username] Doing /arc/ips/security/dbmmanage /arc/ips/security/users_ext view ibm commands, I could see ibm:vG32Vd2KZLPWo, and by doing /arc/ips/security/dbmmanage /arc/ips/security/users_ext view | grep -i admin I could see there were 3 admin userids, admin, eric and enbbeh. Eric says this eric userid is probably his, but he doesn't rememeber the password. I could change the password for ibm, delete it, and add it back in, but I couldn't figure out how to modify the group. Through trial and error, I found that the next word after "... add ibm" was the already-encrypted(!!) password. So I swiped the password from a "... view ibm" command, delete ibm, then readded it with the password followed by :admin, like so /arc/ips/security/dbmmanage /arc/ips/security/users_ext add ibm vG32Vd2KZLPWo:admin This seemed to do the trick, but then I found out the loading tool isn't done from the external web server on port 80. It's done from the internal one running on port 180 and whose password file is /arc/ips/security/users_int. A /arc/ips/security/users_int view ibm command gave me the encrypted pasword and the existing groups the ibm userid is in (coll_IntUser and prn_BDO), so I /arc/ips/security/dbmmanage /arc/ips/security/users_int delete ibm /arc/ips/security/dbmmanage /arc/ips/security/users_int add ibm XXv6wC05V4AGc:coll_IntUser,prn_BDO,admin *------------------------------------------------------------------------* * * * There is another password file on spn09 (bidocw2) at * * /arc/ips/security/users.dir & .pag. To manipulate that, you can * * /arc/ips/security/dbmmanage /arc/ips/security/users view * * * *------------------------------------------------------------------------* ========================================================================================= Notes from my /afs/d/software/base/IHS-2.0.42/README from when I downloaded and started to take a look at IBM's April, 2003 release of Apache version 2. I didn't do any more than download & install it on my jasper machine. Here's the README. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- This is IBM's HTTP Server V2.0, which is based on Apache V2.0.42. This was downloaded from IBM's web site on July 1, 2003. Start at http://www-3.ibm.com/software/webservers/httpservers, and eventually get to the actual FTP site of ftp://service2.boulder.ibm.com/httpservers/2.0.42.1/HTTPServer.aix.2042.tar I then cd /afs/d/software/base tar tvf ~/HTTPServer.aix.2042.tar which created this /afs/d/software/base/IHS-2.0.42 directory, which held the following 4 files and 2 (IMO, junk) directories. drwxr-x--- 2 jasper staff 2048 Apr 07 11:52 license drwxr-x--- 2 jasper staff 2048 Apr 07 12:21 readme -rwxr-xr-x 1 jasper staff 1684 Apr 07 10:48 gskit.sh -rw-r----- 1 jasper staff 12665856 Apr 07 11:53 gskkm.rte -rw-r--r-- 1 jasper staff 13326713 Apr 07 10:48 setup.jar -rw-r--r-- 1 jasper staff 395 Apr 07 11:54 silent.res - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The installation instructions are at http://www-3.ibm.com/software/webservers/httpservers/doc/v20/manual/ibm/9ainstal.htm which tell you that you first of all need Java 1.3 installed and to run this jar file like so export PATH=$PATH:/usr/java131/bin /usr/java131/bin/java -jar setup.jar This brought up a Windows-like InstallShield GUI, which stepped through the basic "Accept the License" and install in /usr/IBMIHS. I installed this on my jasper machine (but later overwrote). ========================================================================================= On August 7th, 2003, I downloaded the latest, this time HTTPServer.aix.20422.tar, which was IBM's HTTP Server version 2.0.42.2. Unlike the 2.0.42.0 version, after running their Java-based InstallShield GUI, there WAS installp-able, lslpp-able filesets loaded, namely Fileset Level State Description ------------------------------------------------------------------------------------- IHS2 2.0.42.2 C IBM HTTP Server IHS2.base 2.0.42.2 C IHS Base Server IHS2.base.application_files 2.0.42.2 C IHS Application Files IHS2.base.application_files.progexe 2.0.42.2 C IHS Program Executables IHS2.base.application_files.readmeEn 2.0.42.2 C IHS Readme/License - U.S. English IHS2.base.doc.manpagesEn 2.0.42.2 C IHS Manual Pages - U.S. English IHS2.base.docs 2.0.42.2 C IHS Documentation IHS2.base.docs.manEn 2.0.42.2 C IHS Documentation - U.S English IHS2.base_ext 2.0.42.2 C IHS Base Extentions IHS2.base_ext.security 2.0.42.2 C IHS SSL Security IHS2.install.component 2.0.42.2 C IHS Install Component IHS2.ssl 2.0.42.2 C IHS SSL IHS2.ssl.msg.en_US 2.0.42.2 C IHS SSL Messages - U.S. English which I installed on spectre. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Unlike the previous "IBM Web Server Powered by Apache" version 1.3.x.y, this new server did NOT put a line in /etc/inittab to start itself at boot time. Beware, though! The 1.3 version of Apache added this /etc/inittab line ihshttpd:2:wait:/usr/HTTPServer/bin/httpd > /dev/console 2>&1 # Start HTTP daemon which you CANNOT simply change (like I initially did) to ihshttpd:2:wait:/usr/IBMIHS/bin/httpd > /dev/console 2>&1 # Start HTTP daemon because you'd get these error messages, exec(): 0509-036 Cannot load program /usr/IBMIHS/bin/httpd because of the following errors: 0509-150 Dependent module libaprutil-0.so could not be loaded. 0509-022 Cannot load module libaprutil-0.so. 0509-026 System error: A file or directory in the path name does not exist. You need to use the apachectl script to start it up, ala ihshttpd:2:wait:/usr/IBMIHS/bin/apachectl start > /dev/console 2>&1 # Start HTTP daemon because it sets up the correct environment variables. ------------------------------------------------------------------------ 2-15-2005 This is what I did on walrus (our Net Commerce Front End machine) to create a self-signed certificate. As root, grep keyfile /dfs/prod/nc/config/ncprod.conf shows me that the keyfile is at /usr/HTTPServer/keys/keyfile.kdb cd /usr/HTTPServer/keys export JAVA_HOME=/usr/jdk_base ikeyman & Then from within that GUI, create a new "Key Database File", calling it keyfile.new.kdb Made the password the Southbury "standard" of henryII and made sure I clicked the "Stash the password to a file?" button !!! Then under "Create" -> "New Self-Signed Certificate ...", set the "Key Label" to "walrus self-signed 2005" the "Organization to "Thomson Delphion" and the "Validity Period" to 3650 Days (10 years) (the "Common Name" was already "walrus.delphion.com" That was it. Exit the ikeyman utility and you're done. Warning! Don't be alarmed when the ikeyman aborts when you exit. Everything worked ok. Just erase the core & javacore* files. This created 4 files, -rw------- 1 root system 80 Feb 15 15:51 keyfile.new.rdb -rw------- 1 root system 80 Feb 15 15:51 keyfile.new.crl -rw------- 1 root system 129 Feb 15 15:51 keyfile.new.sth -rw------- 1 root system 45080 Feb 15 15:54 keyfile.new.kdb I don't know what the rdb & crl files are. The kdb file is your keyfile database and the sth file is your "stashed" password. If you want to switch to these new certificates right away, mv keyfile.kdb keyfile.old.kdb mv keyfile.sth keyfile.old.sth cp -p keyfile.new.kdb keyfile.kdb cp -p keyfile.new.sth keyfile.sth kill -1 $(cat /weblogs/http/httpd.pid) # The primary web server ------------------------------------------------------------------------