You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stanley Gambarin <st...@cs.bu.edu> on 1997/07/15 17:21:50 UTC
config files stuff
Greetings, fellow Apacheers :) I wanted to complain about the
organization of the configuration files. Recent growth of the directives
had resulted in the increased size of the config files and the complexity
in their maintenance. However, the code for processing of all 3
configuration files is the same, which allows you to put directives
intended for one config file into another. The patch below takes the idea
one step further by allowing you to specify your own config files.
Hopefully, this would make it easy for module developers to specify their
own configuration (modules not distributed with Apache), as well as
virtual host management. Stuff below works for me (although minimally
tested) and can probably be applied to core to get away with using
resource and access.conf completely.
To use:
- apply path and recompile.
- in httpd.conf add
# This must be a server-root relative path, but can probably be
# extended to support full path to config file
ConfigFile conf/myconfig
ConfigFile conf/myconfig2
- create myconfig and myconfig2 in conf directory.
- start server.
If anyone would like to take the code and generalize it even
further, please do, as I think it would be a good addition. Any feedback
is welcomed.
Stanley.
*** http_config.h Mon Jul 14 00:31:48 1997
--- http_config.h.bak Mon Jul 14 00:27:52 1997
***************
*** 150,163 ****
const command_rec *cmd; /* configuration command */
} cmd_parms;
- /*
- * This structure is a linked list of the configuration files.
- */
- typedef struct config_file_rec_t {
- struct config_file_rec_t *next;
- char *config_file;
- } config_file_rec;
-
/* This structure records the existence of handlers in a module... */
typedef struct {
--- 150,155 ----
*** http_config.c Tue Jul 15 00:00:17 1997
--- http_config.c.bak Tue Jul 8 21:00:16 1997
***************
*** 1187,1193 ****
listeners = new;
}
! extern config_file_rec *config_files;
server_rec *read_config(pool *p, pool *ptemp, char *confname)
{
server_rec *s = init_server_config(p);
--- 1187,1193 ----
listeners = new;
}
!
server_rec *read_config(pool *p, pool *ptemp, char *confname)
{
server_rec *s = init_server_config(p);
***************
*** 1199,1209 ****
process_resource_config (s, confname, p, ptemp);
process_resource_config (s, s->srm_confname, p, ptemp);
process_resource_config (s, s->access_confname, p, ptemp);
! for (;config_files;) {
! process_resource_config (s, config_files->config_file, p, ptemp);
! config_files = config_files->next;
! }
!
fixup_virtual_hosts (p, s);
default_listeners (p, s);
--- 1199,1205 ----
process_resource_config (s, confname, p, ptemp);
process_resource_config (s, s->srm_confname, p, ptemp);
process_resource_config (s, s->access_confname, p, ptemp);
!
fixup_virtual_hosts (p, s);
default_listeners (p, s);
*** http_core.c Mon Jul 14 23:53:16 1997
--- http_core.c.bak Sat Jul 12 21:00:13 1997
***************
*** 945,965 ****
return NULL;
}
- config_file_rec *config_files = NULL;
- const char *add_config_file (cmd_parms *cmd, void *dummy, char *arg)
- {
- config_file_rec *c;
- size_t arg_size;
-
- c = pcalloc (cmd->pool, sizeof(config_file_rec));
- c->config_file = pstrdup (cmd->pool, arg);
-
- c->next = config_files;
- config_files = c;
-
- return NULL;
- }
-
const char *set_timeout (cmd_parms *cmd, void *dummy, char *arg) {
cmd->server->timeout = atoi (arg);
return NULL;
--- 945,950 ----
***************
*** 1287,1294 ****
{ "ResourceConfig", set_server_string_slot,
(void *)XtOffsetOf (server_rec, srm_confname), RSRC_CONF, TAKE1,
"The filename of the resource config file" },
- { "ConfigFile", add_config_file, NULL, RSRC_CONF, TAKE1,
- "Additional configuration file to be processed" },
{ "ServerAlias", set_server_string_slot,
(void *)XtOffsetOf (server_rec, names), RSRC_CONF, RAW_ARGS,
"A name or names alternately used to access the server" },
--- 1272,1277 ----
***************
*** 1339,1345 ****
{ "ThreadsPerChild", set_threads, NULL, RSRC_CONF, TAKE1, "Number of threads a child creates" },
{ "ExcessRequestsPerChild", set_excess_requests, NULL, RSRC_CONF, TAKE1, "Maximum number of requests a particular child serves after it is ready to die." },
{ "ListenBacklog", set_listenbacklog, NULL, RSRC_CONF, TAKE1, "maximum length of the queue of pending connections, as used by listen(2)" },
! { NULL },
};
/*****************************************************************
--- 1322,1328 ----
{ "ThreadsPerChild", set_threads, NULL, RSRC_CONF, TAKE1, "Number of threads a child creates" },
{ "ExcessRequestsPerChild", set_excess_requests, NULL, RSRC_CONF, TAKE1, "Maximum number of requests a particular child serves after it is ready to die." },
{ "ListenBacklog", set_listenbacklog, NULL, RSRC_CONF, TAKE1, "maximum length of the queue of pending connections, as used by listen(2)" },
! { NULL },
};
/*****************************************************************
Re: config files stuff
Posted by Dean Gaudet <dg...@arctic.org>.
On Thu, 17 Jul 1997, Stanley Gambarin wrote:
> P.S> any chance of this making into 1.3 ?
I'm happy with some form of ConfigFile directive making 1.3.
I'm happy blowing away directives ... but others will caution that
we wait for 2.0 for that.
Why is it that we inherit access_conf and resource_conf into virtualhosts?
There's a merge that happens anyhow, so if the files are the same as
the main server then it's pointless to inherit them.
Allow me to change my mind and say that what I'd prefer is to ditch
AccessConfig, and ResourceConfig entirely. Add an IncludeConfig or
whatever directive which includes another file immediately, at that
spot, and doesn't save it up for later. This is the minimum required
to get the functionality we have now plus the new functionality. KISS.
This is almost what Randy's patch does ... 'cept I'm not sure about the
recursive stuff :) Someone else submitted a simple include directive
a month or so ago.
Dean
Re: config files stuff
Posted by Stanley Gambarin <st...@cs.bu.edu>.
On Thu, 17 Jul 1997, Martijn Koster wrote:
> So to be backwards compatible you need to preserve this difference,
> and that requires "the name of the second file to be read" etc. to be
> stored somewhere. Then you might as well keep it explict and clear, in
> its current place, no? Otherwise I fear the code is becoming
> unnecesarrily complex.
>
If you also deal away with AccessConfig, you would loose some
backward compatibility with NCSA. However, NCSA docs state that there
could only be one AccessConfig per server, so we can do as following
(at least i think we can):
- deal away with Resource and Access config completely
- config file array will start indexing from cell #2, not cell #0.
(cell #0 - Resource Config, cell #1 - AccessConfig)
- replace call to set_string_slot() (for Access and Resource)
with call to config_file (passing 0 or 1 as additional flag).
What the above accomplishes is : remain backward compatible with
NCSA. Remain same config file semantics, so that old config files won't
break. Distribute the configuration information throughout the server.
Also, note that since Martijn's patch does check for duplicate config
files, then we prevent from including AccessConfig multiple times.
On the side note, I like that you are using arrays, rather than
linked list, as it retains the proper ordering of the config files. On
the different note, there are 2 issues that trouble me:
- how, if any, is the override mechanism affected
- what if i do the folowing:
ConfigFile relative_path_to_foo
ConfigFile absolute_path_to_foo (is this allowed)
Stanley.
P.S> any chance of this making into 1.3 ?
Re: config files stuff
Posted by Martijn Koster <ma...@webcrawler.com>.
On Thu, Jul 17, 1997 at 01:17:18AM -0700, Dean Gaudet wrote:
> Ok then +1, but I'd prefer if AccessConfig and ResourceConfig make use of
> the new code.
Having looked at it a little, the difficulty is that the semantics are
different: AccessConfig means "replace the name of the second file to
be read", whereas ConfigFiles mean "Load these files in order after
the current file". Consider:
ConfigFile aaa
ConfigFile bbb
AccessConfig foo
AccessConfig bar
You'd want bar-aaa-bbb.
So to be backwards compatible you need to preserve this difference,
and that requires "the name of the second file to be read" etc. to be
stored somewhere. Then you might as well keep it explict and clear, in
its current place, no? Otherwise I fear the code is becoming
unnecesarrily complex.
Of course I'd be inclined to see "bugger compatibility", nuke all
traces of AccessConfig/ResourceConfig alltogether, and force people to
do explicit ConfigFiles if they want them :-)
I sat down and produced some more general code to implement multiple
config files than the explicit calls to named .conf files hack I'd
done before, and came up with the attached, failry untested, patch
against stock 1.2.1. I don't normally use fancy configs/virtual hosts,
so I have little idea if this is the correct way of doing it. Also
note it is not an IncludeConfig.
Comments?
-- Martijn Koster, m.koster@pobox.com
Re: config files stuff
Posted by Dean Gaudet <dg...@arctic.org>.
Ok then +1, but I'd prefer if AccessConfig and ResourceConfig make use of
the new code.
Dean
On Thu, 17 Jul 1997, Martijn Koster wrote:
> On Wed, Jul 16, 1997 at 10:00:10PM -0700, Dean Gaudet wrote:
>
> > Can you give an example where [arbitrary number of config files] is useful?
>
> We do that for a distributed server farm, in multiple locations, with
> differently configured machines. In addition to httpd/access/srm.conf
> we have a company.conf, network.conf and host.conf. And access/srm
> are optional, and in fact not used here anymore.
>
> httpd.conf contain a standard Apache setup, on all machines
> company.conf contains our own directives, on all machines
> network.conf overrides some directives, on specific networks
> host.conf overrides some directives that depend on the host (MaxClients etc)
>
> This way we can dist out cross-service changes in the first 4 to all
> hosts, dist out network.conf to target networks, and still have more
> speciifc conf files take effect.
>
> Yes, we could achieve the same by disting and catting them all
> together. Or, because we have three targets, we could use the
> httpd/access/srm.conf, and live with the unobvious naming.
>
> But we've found this easier, and as the guy said -- the
> code is so general it's an obvious step.
>
>
> He -- this and child_init() on one day, cool :-)
>
> -- Martijn Koster, m.koster@webcrawler.com
>
>
Re: config files stuff
Posted by Rob Hartill <ro...@imdb.com>.
On Thu, 17 Jul 1997, Martijn Koster wrote:
> On Wed, Jul 16, 1997 at 10:00:10PM -0700, Dean Gaudet wrote:
>
> > Can you give an example where [arbitrary number of config files] is useful?
>
> We do that for a distributed server farm, in multiple locations, with
> differently configured machines. In addition to httpd/access/srm.conf
> we have a company.conf, network.conf and host.conf. And access/srm
> are optional, and in fact not used here anymore.
I use mod_perl to conditionally parse a single config file shared by
a dozen machines with different needs.
it's a hard life,
rob
--
Rob Hartill Internet Movie Database (Ltd)
http://www.moviedatabase.com/ .. a site for sore eyes.
Re: config files stuff
Posted by Martijn Koster <ma...@webcrawler.com>.
On Wed, Jul 16, 1997 at 10:00:10PM -0700, Dean Gaudet wrote:
> Can you give an example where [arbitrary number of config files] is useful?
We do that for a distributed server farm, in multiple locations, with
differently configured machines. In addition to httpd/access/srm.conf
we have a company.conf, network.conf and host.conf. And access/srm
are optional, and in fact not used here anymore.
httpd.conf contain a standard Apache setup, on all machines
company.conf contains our own directives, on all machines
network.conf overrides some directives, on specific networks
host.conf overrides some directives that depend on the host (MaxClients etc)
This way we can dist out cross-service changes in the first 4 to all
hosts, dist out network.conf to target networks, and still have more
speciifc conf files take effect.
Yes, we could achieve the same by disting and catting them all
together. Or, because we have three targets, we could use the
httpd/access/srm.conf, and live with the unobvious naming.
But we've found this easier, and as the guy said -- the
code is so general it's an obvious step.
He -- this and child_init() on one day, cool :-)
-- Martijn Koster, m.koster@webcrawler.com
Re: config files stuff
Posted by Dean Gaudet <dg...@arctic.org>.
Can you give an example where this is useful? I'm not a fan of having
three config files... let alone an arbitrary number :)
'sides if you're going to this effort you might as well make the
AccessConfig and ResourceConfig directives use your ConfigFile code and
ditch the extra structure members.
Dean
On Tue, 15 Jul 1997, Stanley Gambarin wrote:
> Greetings, fellow Apacheers :) I wanted to complain about the
> organization of the configuration files. Recent growth of the directives
> had resulted in the increased size of the config files and the complexity
> in their maintenance. However, the code for processing of all 3
> configuration files is the same, which allows you to put directives
> intended for one config file into another. The patch below takes the idea
> one step further by allowing you to specify your own config files.
> Hopefully, this would make it easy for module developers to specify their
> own configuration (modules not distributed with Apache), as well as
> virtual host management. Stuff below works for me (although minimally
> tested) and can probably be applied to core to get away with using
> resource and access.conf completely.