[TriLUG] SSL Issues

[Robert Porter]

On Tuesday 17 September 2002 11:01 pm, Benjamin Reed wrote:
> On Tuesday, September 17, 2002, at 10:26 PM, Robert Porter wrote:
> > I have paid for the up2date subscription and use it, but that caused
> > other
> > issues, especially with OpenSSL.  Redhat "backpatched" versions of the
> > SSL
> > libraries to fix the recent buffer overruns, this means that the
> > versions
> > reported don't match anymore.  I did do a binary install of MySql via
> > RPM's
> > from the ISO images with no problem.  However I am finding that some
> > packages
> > installed via RPM and some installed via source tar balls seem to cause
> > problems, the least of which is the RPM's tend to conform to RedHat's
> > idea of
> > file locations and the source tar balls adhere to more "standard"
> > locations
> > if there is such a thing :'>  If you ask me RPM's are creating a Linux
> > version of Microsoft DLL Hell.  But that's most likely my ignorance of
> > RPM
> > technology speaking.
>
> You only get DLL hell if you just install RPMs willy-nilly from
> anywhere.  Anything I download that isn't direct from my distro, I
> rebuild from source RPM, and then everything is fine.  (well, there's
> always exceptions, but it's much safer than overwriting system libs)
>
> > My real issue is how to get rid of the RedHat RPM based version of
> > OpenSSL and
> > replace it with a configure/make/make install version without
> > destroying my
> > system.  Any help would be most appreciated.
>
> Your real issue is that you're asking the wrong question.  You're
> basically saying, "How do I break this window without putting a hole in
> it?"  =)

Well I would not have put it quite like that, but ... Yes!

> What you really need to do is rephrase what you want.
>
> OpenSSL breaks binary compatibility pretty regularly, so you *can't* be
> certain, without making sure you have your new libraries *and* leave
> redhat's libraries alone.

That's what I was looking for, yes.  Can two versions of OpenSSL safely exist 
on one system?  This same system will be using SSL wrappers for Qmail's pop3 
and couriers imap services.  Which version of SSL is going to get invoked? 

I also need to make and submit a server certificate etc, I assume I would do 
the "make certificate" in the sandbox version?

> The best way to handle it is to just not do it.  In your initial
> reasoning, you said you needed a rebuilt apache for mod_jk, but mod_jk
> works just fine as a DSO module, so I'm not sure why the instructions

Mainly, its a high volumn application, I am trying to avoid DSO modules in 
favor of compiled in modules for stability.  We use Covalent's Apache server 
in some other apps and noticed a marked decrease in stability when using 
DSO's as opposed to compiled in code.  Their own tech support strongly favors 
the compiled approach as well.  Just figured it would work for *regular* 
Apache as well, could be wrong though. Same story from IBM's Websphere group 
as well.  They always favor compiled in vs. DSO model for high volume 
modules.  But I think in their case it is because it gives them more control 
over the environment from a support point of view, rather than any perceived 
or real stability increase.  After all its the same code running right?

> you found required you to build things specially.  Even if you *have*
> to build it in, the only safe way to do it is to leave redhat's stuff
> alone, and then put your build in a sandbox, if you don't want to break
> all of the other things that depend on RedHat's OpenSSL.  So your
> *real* goal is to have a custom-built apache in a sandbox, not to
> replace important system libraries.

That sound's perfect, well as close to perfect as I am going to get I think.  
My experience to date has been its better off to leave stuff RedHat installs 
alone if I can, too many cross dependancies.

>
> (disclaimer, this isn't *everything* step-by-step, but should give you
> an idea of how to handle it)
>
> So what you'll want to do is make, say, an /opt/custom-apache directory
> (or /usr/local/custom-apache, or whatever, just something that's
> guaranteed not to be in "normal" system paths).
>
> Then set up your environment to look there:
>
> export PATH="/opt/custom-apache/bin:$PATH"
> export LD_LIBRARY_PATH="/opt/custom-apache/lib:$LD_LIBRARY_PATH"
>
> ...and then build openssl with --prefix=/opt/custom-apache
> ...and then build apache with --prefix=/opt/custom-apache
> ...and build everything else that you want in your "apache sandbox" in
> there
>
> Then you only need to make a script that sets up LD_LIBRARY_PATH and
> runs your custom httpd, and it will be the *only* thing that sees your
> custom libraries, rather than overwriting the defaults that the rest of
> the system uses.

Thanks!  This gets me going, I appreciate the clarifications, I don't always 
communicate what I mean/want too as clearly as I could, but I can always 
learn =}

Cheers,

Robert Porter

> _______________________________________________
> TriLUG mailing list
>     http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ:
>     http://www.trilug.org/~lovelace/faq/TriLUG-faq.html

-- 
Cheers,

Robert Porter			http://www.rp2c.com
RP2C Inc			robertporter at rp2c.com