You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Danek Duvall <dd...@eng.sun.com> on 2001/05/04 01:11:42 UTC
[PATCH] option to remove default listener
When we packaged up Apache for delivery with Solaris, we had a requirement
that it not be run by default at boot-time unless it was explicitly
configured by an administrator. We did this by moving the configuration
file out of place, and putting a few lines in the boot script to check for
the placement of the config file.
The reason for all this rigmarole was so that if a customer upgraded a
system without Apache to a version of the OS which came with Apache, then
it wouldn't clobber any other web server they might happen to have
installed and configured.
We are considering using Apache to host an IPP server, and this kludge no
longer works the way we'd like. Essentially, we need a solution whereby
Apache will not listen on port 80 unless it is explicitly configured to do
so. Since currently it will create a server on port 80 if nothing else is
configured, we need for this behavior to change.
I'm attaching a patch which disables this creation of a default listener by
passing httpd a new config define -- NO_DEFAULT_LISTENER. With the patch,
unless someone has specified a Port or Listen directive (or otherwise added
a listener), apache will read its configuration files and keel over.
Please consider this for inclusion into Apache 2.0.
Thanks,
Danek
Re: [PATCH] option to remove default listener
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: <rb...@covalent.net>
Sent: Friday, May 18, 2001 5:48 PM
> > +1 on this patch, reason being...
> >
> > we have a bunch of confusion over the port/listen directives. I believe this
> > patch is headed in the right direction.
> >
> > We NEED to depreciate the old Port behavior. It is terribly confusing to folks
> > to change their port, and have nothing happen.
> >
> > Listening should be through a Listen directive, alone. A few folks need to
> > change the .conf file, but this is 2.0, so everyone will be changing their
> > .conf file for varied reasons.
> >
> > By assuming port 80, we make the user believe that the Port directive is actually
> > in control of something. Of course, it's not.
> >
> > Let's get the pain over with, finally. If they forget Listen, then don't make
> > assumptions for them.
>
> How would you solve the problem of having the server listen on one port,
> but report that it is listening on another?
1. It needs to be solved, and needs to be intuitive. That's why I suggested renaming
the Port directive to ServerPort [corresponding to ServerName]. It's a pure identity,
and doesn't have any relationship to the listener.
2. I'd rather have the user omit ServerPort and solve that [as we do for ServerName]
than omit their Listen directive.
3. Would need an additional patch, without a doubt. But this is a good first step.
Bill
Re: [PATCH] option to remove default listener
Posted by rb...@covalent.net.
> +1 on this patch, reason being...
>
> we have a bunch of confusion over the port/listen directives. I believe this
> patch is headed in the right direction.
>
> We NEED to depreciate the old Port behavior. It is terribly confusing to folks
> to change their port, and have nothing happen.
>
> Listening should be through a Listen directive, alone. A few folks need to
> change the .conf file, but this is 2.0, so everyone will be changing their
> .conf file for varied reasons.
>
> By assuming port 80, we make the user believe that the Port directive is actually
> in control of something. Of course, it's not.
>
> Let's get the pain over with, finally. If they forget Listen, then don't make
> assumptions for them.
How would you solve the problem of having the server listen on one port,
but report that it is listening on another?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] option to remove default listener
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
+1 on this patch, reason being...
we have a bunch of confusion over the port/listen directives. I believe this
patch is headed in the right direction.
We NEED to depreciate the old Port behavior. It is terribly confusing to folks
to change their port, and have nothing happen.
Listening should be through a Listen directive, alone. A few folks need to
change the .conf file, but this is 2.0, so everyone will be changing their
.conf file for varied reasons.
By assuming port 80, we make the user believe that the Port directive is actually
in control of something. Of course, it's not.
Let's get the pain over with, finally. If they forget Listen, then don't make
assumptions for them.
Bill
----- Original Message -----
From: "Danek Duvall" <dd...@eng.sun.com>
To: <ne...@apache.org>
Sent: Thursday, May 03, 2001 6:11 PM
Subject: [PATCH] option to remove default listener
> When we packaged up Apache for delivery with Solaris, we had a requirement
> that it not be run by default at boot-time unless it was explicitly
> configured by an administrator. We did this by moving the configuration
> file out of place, and putting a few lines in the boot script to check for
> the placement of the config file.
>
> The reason for all this rigmarole was so that if a customer upgraded a
> system without Apache to a version of the OS which came with Apache, then
> it wouldn't clobber any other web server they might happen to have
> installed and configured.
>
> We are considering using Apache to host an IPP server, and this kludge no
> longer works the way we'd like. Essentially, we need a solution whereby
> Apache will not listen on port 80 unless it is explicitly configured to do
> so. Since currently it will create a server on port 80 if nothing else is
> configured, we need for this behavior to change.
>
> I'm attaching a patch which disables this creation of a default listener by
> passing httpd a new config define -- NO_DEFAULT_LISTENER. With the patch,
> unless someone has specified a Port or Listen directive (or otherwise added
> a listener), apache will read its configuration files and keel over.
>
> Please consider this for inclusion into Apache 2.0.
>
> Thanks,
> Danek
>
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Wed, May 16, 2001 at 05:24:32PM -0700, dean gaudet wrote:
> what does a server do when it has no default listener? i.e. what's the
> point again?
With this patch applied, the server will exit. The chain is
ap_listen_open() returns -1, so
ap_setup_listeners() returns 0, so
ap_mpm_run() logs an error and returns 1, so
the inifinite loop in main() is exited, falling off the end of the
program
Without this patch, a server is set up on port 80, as if there were one
configured in the config file. This is behavior I'd like to avoid,
optionally.
> (does the child_main code even work when the listener ring is empty?? i
> swear it'll core dump, but i haven't looked.)
As far as I can tell, child_main() won't have been called yet when this
logic is encountered. At least at initial startup. If you've removed
all your listeners from the config of a running server, well, that probably
isn't good, either.
Thanks,
Danek
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
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
Re: [PATCH] option to remove default listener
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > There are hundreds of ways to add such a check within the rc files.
>
> Could you name one? I can't think of any, but I'm not sure I'm thinking
> along the same lines you are.
Aside from the one Greg mentioned, you can also
- 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)
- use a specific format for the httpd config file that inserts a
comment before each Listen directive identifying it by service
- 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)
- egrep the httpd config file for Listen directives
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.
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.
....Roy
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Fri, May 18, 2001 at 03:28:36PM -0700, Roy T. Fielding wrote:
> There are hundreds of ways to add such a check within the rc files.
Could you name one? I can't think of any, but I'm not sure I'm thinking
along the same lines you are.
> We aren't going to change the default for Port on all platforms, breaking
> backwards compatiblity for millions of servers, just so that you can
> run-check httpd when it shouldn't be invoked in the first place.
I didn't ask for any defaults to be changed. The code only makes a
difference when -DNO_DEFAULT_LISTENER is passed on the command line, and no
one but the Solaris packages need do that. I specifically wanted to avoid
changing any defaults that others might be relying on.
Danek
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Fri, May 25, 2001 at 05:20:22PM -0700, dean gaudet wrote:
> do you use include directives or something to include partial configs for
> each of the services you want to activate?
Well, I'm not that far along yet. I hadn't planned on doing it that way,
but I certainly could. In fact, that's pretty much what Greg suggested,
and something I need to try out -- start up Apache if a magic directory has
files in it, and have the default config Include that directory. Then each
service can have the necessary module directives, the Listen directive, and
the virtual host block.
> can your package manager handle multiple packages owning a file, say
> /etc/apache_enabled ?
Sadly, no; SVID/Solaris packages don't support that for files, only
directories. There are ways around it, through postinstall and preremove
scripts, but that's just too hacky.
Thanks,
Danek
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Fri, May 18, 2001 at 05:22:31PM -0700, Greg Stein wrote:
> Use the new "include all .conf files in <this> directory" feature (it is
> actually in 1.3 and 2.0). As each service is added, they drop their
> specific configuration file into the directory. When the service is
> removed, they remove their .conf file. The web service is just the same:
> add a file and remove on deinstall.
>
> Your .rc file can simply see if any files are present in the directory.
> If there, then start httpd. If none are present, then don't start.
Yes, I think that should work. I know I ran across that feature before,
but I can't remember now why I couldn't make it do what I needed. Perhaps
I was mistaken, or maybe I'll remember again. At any rate, this ought to
do what I need, and it's a good way of doing it. (And it works on 1.3,
which may be necessary for me.)
Thanks, Greg!
Danek
Re: [PATCH] option to remove default listener
Posted by Greg Stein <gs...@lyra.org>.
On Fri, May 18, 2001 at 04:12:10PM -0700, Danek Duvall wrote:
> On Fri, May 18, 2001 at 05:59:15PM -0500, William A. Rowe, Jr. wrote:
>
> > It sounds like you would be better off installing the 'stock' apache,
> > but setting up a second .conf for the 'system services' you want to add,
> > running them to their own logs/scoreboard/pidfile.
> >
> > That way, the user doesn't mangle those services, and the two never
> > interfere with one another.
>
> Yeah, that's certainly an option, and one we may very well decide on. It
> has the advantage that it separates the 'system Apache' from the 'user
> Apache', and the two never mix, stomp on each other, &c.
>
> On the other hand, that sort of solution says to me that something is
> broken in the design of the configuration of the system. It's inelegant.
> I shouldn't *need* to have two instances of Apache running, but instead I
> should be able to have a configuration that neatly partitions services from
> each other. Cf inetd, which is essentially the same thing, except it
> doesn't provide HTTP support.
Oh no... this should be able to be done quite easily.
Use the new "include all .conf files in <this> directory" feature (it is
actually in 1.3 and 2.0). As each service is added, they drop their specific
configuration file into the directory. When the service is removed, they
remove their .conf file. The web service is just the same: add a file and
remove on deinstall.
Your .rc file can simply see if any files are present in the directory. If
there, then start httpd. If none are present, then don't start.
That should be doable today.
(I don't have details on the feature, but I remember the commit from jimjag
going in there a while back)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Fri, May 18, 2001 at 05:59:15PM -0500, William A. Rowe, Jr. wrote:
> It sounds like you would be better off installing the 'stock' apache,
> but setting up a second .conf for the 'system services' you want to add,
> running them to their own logs/scoreboard/pidfile.
>
> That way, the user doesn't mangle those services, and the two never
> interfere with one another.
Yeah, that's certainly an option, and one we may very well decide on. It
has the advantage that it separates the 'system Apache' from the 'user
Apache', and the two never mix, stomp on each other, &c.
On the other hand, that sort of solution says to me that something is
broken in the design of the configuration of the system. It's inelegant.
I shouldn't *need* to have two instances of Apache running, but instead I
should be able to have a configuration that neatly partitions services from
each other. Cf inetd, which is essentially the same thing, except it
doesn't provide HTTP support.
Danek
Re: [PATCH] option to remove default listener
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Danek Duvall" <dd...@eng.sun.com>
Sent: Friday, May 18, 2001 5:52 PM
> On Fri, May 18, 2001 at 03:28:36PM -0700, Roy T. Fielding wrote:
>
> > That doesn't make any sense. If you don't want to start httpd, then
> > don't run httpd at all.
>
> We have no way of knowing whether or not httpd should be started from
> outside Apache. Certainly we know that it *shouldn't* be started if the
> config file isn't in place -- like I said, that's what happens in Solaris
> now.
>
> But because we want to use Apache for things other than a web server,
> Apache needs to come configured and ready to run, but enabled only when
> there are services which have been configured to run. For my purposes,
> this means that Apache's configuration tells it to listen on some port, and
> nothing but running Apache can tell me that.
Danek,
It sounds like you would be better off installing the 'stock' apache, but
setting up a second .conf for the 'system services' you want to add, running
them to their own logs/scoreboard/pidfile.
That way, the user doesn't mangle those services, and the two never interfere
with one another.
Bill
Re: [PATCH] option to remove default listener
Posted by dean gaudet <dg...@arctic.org>.
do you use include directives or something to include partial configs for
each of the services you want to activate?
can your package manager handle multiple packages owning a file, say
/etc/apache_enabled ? if so then it should be trivial to create
/etc/apache_enabled in every one of your packages that needs apache.
presumably if your package manager handles multiple owners of the same
file it keeps reference counts or something and will deal with deleting
/etc/apache_enabled when there are no more owners.
-dean
On Fri, 18 May 2001, Danek Duvall wrote:
> On Fri, May 18, 2001 at 03:28:36PM -0700, Roy T. Fielding wrote:
>
> > That doesn't make any sense. If you don't want to start httpd, then
> > don't run httpd at all.
>
> We have no way of knowing whether or not httpd should be started from
> outside Apache. Certainly we know that it *shouldn't* be started if the
> config file isn't in place -- like I said, that's what happens in Solaris
> now.
>
> But because we want to use Apache for things other than a web server,
> Apache needs to come configured and ready to run, but enabled only when
> there are services which have been configured to run. For my purposes,
> this means that Apache's configuration tells it to listen on some port, and
> nothing but running Apache can tell me that.
>
> Perhaps a patch to spit out a list of configured listeners and exit (sort
> of like -t -D DUMP_VHOSTS) would be preferable?
>
> Danek
>
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
On Fri, May 18, 2001 at 03:28:36PM -0700, Roy T. Fielding wrote:
> That doesn't make any sense. If you don't want to start httpd, then
> don't run httpd at all.
We have no way of knowing whether or not httpd should be started from
outside Apache. Certainly we know that it *shouldn't* be started if the
config file isn't in place -- like I said, that's what happens in Solaris
now.
But because we want to use Apache for things other than a web server,
Apache needs to come configured and ready to run, but enabled only when
there are services which have been configured to run. For my purposes,
this means that Apache's configuration tells it to listen on some port, and
nothing but running Apache can tell me that.
Perhaps a patch to spit out a list of configured listeners and exit (sort
of like -t -D DUMP_VHOSTS) would be preferable?
Danek
Re: [PATCH] option to remove default listener
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > what does a server do when it has no default listener? i.e. what's the
> > point again?
>
> Without my patch, a listener is created on port 80 if none has been
> configured. With my patch, no such listener is created, and the
> appropriate return code is set such that the main loop is broken, the fact
> that there are no listeners is logged, and Apache exits cleanly.
>
> This latter behavior is one that I'd like to make available, so that we in
> Solaris-land can configure Apache to run by default, but make it up to the
> end-user to enable the web server, or some other package to install a
> listener on another port.
That doesn't make any sense. If you don't want to start httpd, then don't
run httpd at all. There are hundreds of ways to add such a check within
the rc files. We aren't going to change the default for Port on all
platforms, breaking backwards compatiblity for millions of servers, just
so that you can run-check httpd when it shouldn't be invoked in the first
place.
....Roy
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
[Sorry for the delay, and if two messages show up; I'm not sure what
happened to the message I sent out on Wednesday.]
On Wed, May 16, 2001 at 05:24:32PM -0700, dean gaudet wrote:
> what does a server do when it has no default listener? i.e. what's the
> point again?
Without my patch, a listener is created on port 80 if none has been
configured. With my patch, no such listener is created, and the
appropriate return code is set such that the main loop is broken, the fact
that there are no listeners is logged, and Apache exits cleanly.
This latter behavior is one that I'd like to make available, so that we in
Solaris-land can configure Apache to run by default, but make it up to the
end-user to enable the web server, or some other package to install a
listener on another port.
> (does the child_main code even work when the listener ring is empty?? i
> swear it'll core dump, but i haven't looked.)
Well, I get no core dump, either in the threaded or the prefork MPMs, and
it looks like child_main() isn't even hit when this conditional is hit.
Danek
Re: [PATCH] option to remove default listener
Posted by dean gaudet <dg...@arctic.org>.
what does a server do when it has no default listener? i.e. what's the
point again?
(does the child_main code even work when the listener ring is empty?? i
swear it'll core dump, but i haven't looked.)
-dean
On Wed, 16 May 2001, Danek Duvall wrote:
> Any comment on the following patch?
>
> Thanks,
> Danek
>
> Two weeks ago, I wrote:
>
> > Index: server/listen.c
> > ===================================================================
> > RCS file: /home/cvspublic/httpd-2.0/server/listen.c,v
> > retrieving revision 1.53
> > diff -u -r1.53 listen.c
> > --- server/listen.c 2001/04/05 19:04:14 1.53
> > +++ server/listen.c 2001/05/03 22:27:58
> > @@ -275,6 +275,8 @@
> >
> > /* allocate a default listener if necessary */
> > if (ap_listeners == NULL) {
> > + if (ap_exists_config_define("NO_DEFAULT_LISTENER"))
> > + return -1;
> > alloc_listener(process, NULL, port ? port : DEFAULT_HTTP_PORT);
> > }
> >
>
Re: [PATCH] option to remove default listener
Posted by Danek Duvall <dd...@eng.sun.com>.
Any comment on the following patch?
Thanks,
Danek
Two weeks ago, I wrote:
> Index: server/listen.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/server/listen.c,v
> retrieving revision 1.53
> diff -u -r1.53 listen.c
> --- server/listen.c 2001/04/05 19:04:14 1.53
> +++ server/listen.c 2001/05/03 22:27:58
> @@ -275,6 +275,8 @@
>
> /* allocate a default listener if necessary */
> if (ap_listeners == NULL) {
> + if (ap_exists_config_define("NO_DEFAULT_LISTENER"))
> + return -1;
> alloc_listener(process, NULL, port ? port : DEFAULT_HTTP_PORT);
> }
>