> 
> --On 08/26/00 18:51:31 +0200 Stas Bekman <[EMAIL PROTECTED]> wrote:
> 
> > Heh, obviously you have to supply the password on the server startup,
> > unless you use one of the workarounds described in the ssl docs
> > (secured utility that feeds the passwd is the best IMHO).
> 
> Naw, something else is going on and I just haven't had the time ( or 
> inclination -- all the pieces are working together without a hitch) to 
> really investigate it.  I, in fact, run my SSL servers as you suggest 
> since I don't like to be around to have to provise a password.  The 
> crux of the problem is that mod-perl, in it's test phase, is quit 
> unaware -- or seems to be -- of any configuration outside of what it 
> sets up for itself when running 'make test'.  Moreover, if you're 
> building for the first time, you won't have anything in place yet.

Hmm, I don't remember one around to test and was long time ago when I've
installed the last one, but I think there were no problems at that
stage. Am I wrong? 

> > And of course like many have mentioned already, it's better to install
> > mod_ssl and alike in the front end server. See an extensive
> > discussion in the mail archives and somewhere in the guide.
> >
> 
> The problem with light and heavy servers is that what is technically 
> the best option and corporate culture often clash with corporate 
> culture winning more often than not.  To use mod_proxy on a "light" SSL 
> server acting as a mirror for the real beast requires certain 
> constraints in how links are specified (this we all know).  I work in 
> higher education, a 4 year college to be exact.  We have a webmaster 
> who is really only in charge of content.  I'm the technical systems 
> guy.  But even though content is the webmaster's job, he hasn't got 
> complete control.  Many a professor is in charge of various academic 
> departmental web pages.  You talk about relative links and he has no 
> idea what you're talking about, and doesn't want to know.  Nor is he 
> willing to change the way he does things, he hasn't got time to learn a 
> new tool, etc, etc, etc.....  And the thing with tenured faculty is 
> they win -- even in cases where they're being totally uncooperative (I 
> decided to be polite here) for no reason other than they don't feel 
> like being cooperative.

There is no need for a relative links. You should use
mod_rewrite and/or mod_proxy to ProxyPass the requests fron the light
server to another see:
http://perl.apache.org/guide/scenario.html#Concepts_and_Configuration_Direc

So once you have things installed it's absolutely transparent for your
content writers.

> We use SSL on our main external server because enrollment will soon be 
> taking on-line applications and payment for distance learning and our 
> bookstore is doing e-commerce, and everybody wants they're URL to be 
> the main campus server.  So, what you say is absolutely true is we 
> lived in an ideal world where the technically best option defined the 
> course of action because it was technically best.  But we live in a 
> world where non-technical issues cloud the decision process, and for 
> non-technical reasons we are sometimes stuck with a technically poor 
> solution.

I'm almost sure that you can find a solution that will be nice to the
content provider and technicaly sophisticated. There are lots of examples
of different techniques in the guide and I'm sure that there are many more
that aren't there. Of course I might be wrong and in your particular
situation none will apply, but it worth investigation.

> BTW Stas, I haven't downloaded the current version of the guide, I'm 
> using 1.24 so my comments might be dated.  But, if folks in the US 
> simply follow your instructions they will be illegal even after Sept 
> 21.  Using the rsaref libraries is an absolute requirement.  Take a 
> look at the mod_ssl install instructions and you might want to 
> incorporate them in the guide at the appropriate spot.  Just a 
> suggestion.

Weird, it's a first time I hear about that. The Guide explains the details
of installation of the apache-ssl, mod_ssl and few others, which I don't
think have any US regulation problems. I might be wrong of course, since
I'm not in US... But if there is a real problem with this, I'll definitely
add a note in the appropriate place. I really don't want someone to have
troubles with the material in the Guide. I'm really surprised nobody have
ever rised this issue before. I know for sure that *some* people on the
list and among Guide readers are American :) 

So just tell me what to fix and where, and I'll do it.

P.S. I think the ssl notes in the guide are at least one year old. How
many of you had a legal trouble with these notes?

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com   perl.org   apache.org


Reply via email to