Re: Massive IP address change.

[Vern Hamberg <vhamberg@xxxxxxxxxxx>]

Hey man, I do like tangents!

As Jim said, there are all kinds of ways to make this work more easily 
for users. I'm pretty much a novice with this, too.

With our document management product, we do generally have users create 
a separate instance, each with their own port. And we recommend that 
people create bookmarks or favorites, so that they don't have to fight 
the blasted port issue. They are welcome to put everything into 
APACHEDFT, but i don't usually recommend it - especially because the 
shutdown issue I posited.

It is possible to use a redirect or redirectmatch that will use the port 
without the user knowing about it. For example,

|Redirect /service http://foo2.bar.com/service

According to the documentation,

|If the client requests |http://myserver/service/foo.txt|, it will be 
told to access |http://foo2.bar.com/service/foo.txt| instead.

There's no reason the redirect can't have a port in it - then the users 
are insulated from weirdness.

Does that make any sense? I know we have one customer who really pushed 
this hard, and it was quite instructive to see what they did.

Vern

On 4/26/2011 7:11 AM, rob@xxxxxxxxx wrote:
> Vern,
>
> It was rather tangential, true.  And your points are valid.  And I really
> am raw in this area.  I just think the average user doesn't like URLs like
> http://something:83
>
>
> Rob Berendt
> -- Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 
> Ship to: Dock 108 6928N 400E Kendallville, IN 46755 
> http://www.dekko.com From: Vern Hamberg <vhamberg@xxxxxxxxxxx> To: 
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> Date: 
> 04/26/2011 08:02 AM Subject: Re: Massive IP address change. Sent by: 
> midrange-l-bounces@xxxxxxxxxxxx Rob I'm not sure how this is a 
> response to what I said. Nonetheless, there are advantages to multiple 
> server instances. Simplicity is one of these. Maybe this can be 
> compared to the simplicity in the single modules of modular 
> programming, but some might consider that a stretch. The other is 
> administration - if all of your apps are configured in one file, with 
> multiple "listen" directives and virtual hosts or redirects, then when 
> you shut it down, you shut down everything. With multiple server 
> instances, if there is a problem with one, it does not have to affect 
> everyone else. So there's no right or wrong here - Apache has so many 
> options, so many ways to do things - you'd almost think it is Perl! 
> TMTOWTDI - There's more than one way to do it! Vern On 4/26/2011 6:10 
> AM, rob@xxxxxxxxx wrote:
> > >  While it may be possible for a good person to get by with one apache
> > >  config file and coding for all the variety of things they may be running
> > >  you often find that "vendor a" wants his own config file and their
> support
> > >  will look upon a shared config file with about as much disdain as an ERP
> > >  vendor will with a modified order entry program.