Advanced Issues and Recompiling

1. Can one recompile SWS and still have SSL in it?

It is not possible to recompile SWS, because we are not permitted to ship the cryptographic source code and the source code is needed to compile the server. We aren't allowed to ship it as a separate, dynamically loadable object.

2. I have just updated my RedHat Linux version and I tried to keep apache from being installed so that it would not overwrite my configuration but I missed it. Now what do I do?

Simply reinstall the secureweb package, and any module packages that you require (mod_ssl and/or mod_php3). To get around the problems with it already thinking that sws is on the system, do an rpm -e apache and an rpm -e secureweb.

However, because secure web server and apache have different binaries (/usr/sbin/httpd and /usr/sbin/httpsd) Secure Web server should still be present on the computer. The only thing that Red Hat might have "overwritten" would be some of the dynamic modules (mod_ssl and/or mod_php3). You have to use the modules that come with secure web server, because they are created specifically for SWS.

3. Is there any reference on compiling php3 with secure server as a DSO? Every time I try and compile stuff, it wants to build it into the server (which it can't do).

Correct. Both PHP3 and mod_perl include documentation that tells you how to build them as DSOs. You have to use the apxs utility (which comes in secureweb-devel). But not directly; both programs have makefiles to do so.

Your best bet for compiling is to look at the source RPMs that we shipped for both of these modules and see how we do it there. It is a bit of a convoluted process, but that is unfortunately because Apache doesn't have a very good module design at the moment, and probably won't until 2.0. There's not a whole lot we can do about this situation, which is, I agree, unfortunate.

4. Is there a version of the binary compiled for something besides 386 that is faster?

Not currently. We have found through our research that the optimizations produced by egcs 1.1.2 are negligible in most cases. Those produced by pgcc are sometimes faster, but pgcc has also proven itself unstable.

If there becomes a compelling reason to do so, we will probably provide processor-optimized versions in the future.

5. I tried enabling PERLSTACKEDHANDLERS in the rpm build but persistent db connections still don't work. What's the story?

We have seen some problems with stacked handlers, so we have disabled them in the default build. Things may have improved in the latest mod_perl iterations.

More in depth questions about persistent db connections would best be handled on the mod_perl mailing list.

6. I have SWS 2.0 installed and I'm having a lot of trouble with perl scripts. They just flat out will not run! What should I do?

Make sure you don't have mod_perl 1.16 enabled. It is broken. Or, de-install mod_perl if you don't use it, and no, you do not need mod_perl to run cgi scripts or perl scripts.

7. Is there some documentation that details how to build and add new modules like dbm_auth?

Because each module has a different build process, this probably wouldn't be practical. What you do need to know is that modules must be built as DSOs to work. DSO stands for Dynamic Shared Object. We included packages for the apache source code and apache headers, the latter which SHOULD be all you need to compile a DSO module. once you have compiled it, simply put the module in /usr/lib/apache/ and enable it in the httpd.conf.