Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Fri, 18 May 2001 18:49:12 -0700
From: Danek Duvall <dduvall@eng.sun.com>
To: new-httpd@apache.org
Subject: Re: [PATCH] option to remove default listener
Message-ID: <20010518184912.E16023@viper.eng.sun.com>
Mail-Followup-To: new-httpd@apache.org
References: <20010516121558.B18485@viper.eng.sun.com>
 <Pine.LNX.4.33.0105161723570.15009-100000@twinlark.arctic.org>
 <20010518135002.A11232@viper.eng.sun.com>
 <20010518152836.B898@waka.ebuilt.net>
 <20010518154310.B13263@viper.eng.sun.com>
 <20010518181243.F898@waka.ebuilt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20010518181243.F898@waka.ebuilt.net>;
 from fielding@ebuilt.com on Fri, May 18, 2001 at 06:12:43PM -0700

On Fri, May 18, 2001 at 06:12:43PM -0700, Roy T. Fielding wrote:

>    - use another config file as a list of enabled services
> 
>    - use another config file that set environment variables and test them
>      (this is what Linux typically does)

These would also work pretty well, though it would mean designing and
implementing an ad-hoc, Solaris-specific 'standard' that wouldn't do much
good for anyone else.  The magic config directory, I think, is a little
closer to what I might call a 'native Apache' solution, and is therefore
cleaner.

>    - use a specific format for the httpd config file that inserts a
>      comment before each Listen directive identifying it by service

Doable, and in fact there's plenty of that to be found, both in Sun
products and elsewhere, but it's such a fragile method.

>    - use a separate httpd instance for each service (recommended because
>      IPP doesn't have even remotely the same application profile as a
>      normal Web server and thus needs different request limits)

Hmm.  I don't particularly like the idea of starting up a bunch of
processes for every service that might or might not be used, and would
likely be sitting idle most of the time.  The idea is to emulate the best
aspects of inetd, which is something that web servers seem to be tending
towards anyway.

>    - egrep the httpd config file for Listen directives

That doesn't work; it's pretty easy to write a module that makes Apache
listen on a port via a configuration directive other than Listen.  It may
not be a public interface, but I've thought for a while that it probably
should be.  (I've decided not to use that and just live with an explicit
Listen directive plus a port-based VirtualHost, so no, I'm not actually
requesting that now.)

> In short, if it is possible for Apache to know what its config will be,
> it is possible for a script to know it as well.

That's not necessarily true, though you can certainly set up a
configuration style that approximates it well enough for what I need it to
do.

> But if you want my recommendation, just don't install a Web server by
> default.  It is a dumb idea regardless of how many OSes do it already.
> A Web server needs to be carefully set up, just like any network service.

And this is exactly the reason that I'm trying to find a solution to this
at all.  We don't ship Apache turned on because we don't feel that Solaris
should ship with an enabled web server, period.  But if we do use Apache as
a super-server, then we need to be able to enable that aspect of it,
without the web server, trivially and programmatically.

Thanks for your suggestions,
Danek