I just want to share some hard work that I've been going through ...
We run WebAccess on our company network, but of course we also want to run it so that users can reach it from the Internet. So I set up a SLES 10 SP1 box, since I want to run the latest software on my new server.
When you install WebAccess Application on a linux server you have 2 options:
- Install the application using the apache2 and tomcat5 that come with the distribution (SLES10).
- Install the application bundled with apache2 and tomcat4.
The installation is straightforward, until you want to configure WebAccess. Then you have to connect to your eDirectory to get the configuration to be performed. This has to be done to an empty post office in GroupWise. This is because the WebAccess configuration wants to create certain objects in eDirectory, and it will NOT use the ones that were created when you installed the first (internal) WebAccess agent. As a side note, WebAccess running standalone will never contact eDirectory again, but you have to create the objects anyway!
To connect to the Agent on the inside, WebAccess uses the file commgr.cfg, as you may know, and you specify it when you configure the application. In normal installation scripts I have seen (not created by GroupWise Linux-guys), the installation ensures the correct rights for the files it installs. By mistake, the commgr.cfg that I used had the unix rights "-rw-------" For those who don't know, this means read and write rights for the owner of the file. And since the script copied the file as root, only the root had read access to the file. Tomcat runs as user tomcat.
It took me quite some time to find out why I only got a blank web site when I asked for http://aaa.bbb.ccc.ddd/gw/webacc. To understand why, I had to run "strace" on the tomcat process and analyze the file that was produced. After a while I found an "Access denied" when tomcat was trying to read the commgr.cfg file. When I changed the rights to "-rw-r--r--" Tomcat was happy, and it produced the WebAccess login page.
It doesn't end here, though. Because the server is on the Internet, I wanted it to run with the latest Apache and Tomcat, and of course with SSL enabled. I uninstalled the 2 packages novell-httpd-2.0.49-20040303.120046 and novell-tomcat4-4.1.30-4 and installed what comes with SLES 10 SP1. To help with this, Novell has TID 5007722 "Linux Script to Assist in GroupWise 7.x Webaccess Application Install on SLES 10 or Linux OES2". This TID explains that there is a new connection between the apache server and the tomcat server. It is "mod_proxy" instead of "mod_jk", which has become obsolete. I ran the script and WebAccess worked fine. So I started up YAST (as this is the way SUSE Linux wants us to configure services on the server) to configure the server to run with SSL. I ran "rcapache2 restart", and guess what ... Apache would not start. That's because apache2-prefork doesn't like the mod_proxy module, so it refuses to start apache.
So here's what I did:
1. Uninstalled the Apache and Tomcat that come with SLES 10 SP1.
2. Installed the old ones that come with GroupWise WebAccess.
3. Delete the objects created by WebAccess the last time I configured it.
4. Re-ran the WebAccess configuration.
5. Edited the configuration files needed for SSL, and a bit more.
And now I'm up and running with WebAccess with SSL on SLES 10 SP1.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.