You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joe Orton <jo...@redhat.com> on 2002/05/27 11:15:46 UTC
[PATCH] improve config dir processing
Currently config directory processing isn't very useful in practice
because all files in the config dir are loaded - so if you use an editor
which creates backup files, the backup file will still be loaded.
A simple way to fix this is to only load files in the config dir which
match the pattern "[A-Za-z0-9]*.conf", as in the following patch (which
also removes the noise produced on stderr when processing config dirs)
--- server/config.c 20 May 2002 15:05:43 -0000 1.151
+++ server/config.c 27 May 2002 09:09:31 -0000
@@ -75,6 +75,7 @@
#include "apr_strings.h"
#include "apr_portable.h"
#include "apr_file_io.h"
+#include "apr_fnmatch.h"
#define APR_WANT_STDIO
#define APR_WANT_STRFUNC
@@ -1442,7 +1443,6 @@
* entries here and store 'em away. Recall we need full pathnames
* for this.
*/
- fprintf(stderr, "Processing config directory: %s\n", fname);
rv = apr_dir_open(&dirp, fname, p);
if (rv != APR_SUCCESS) {
fprintf(stderr, "%s: could not open config directory %s: %s\n",
@@ -1455,7 +1455,9 @@
while (apr_dir_read(&dirent, APR_FINFO_DIRENT, dirp) == APR_SUCCESS) {
/* strip out '.' and '..' */
if (strcmp(dirent.name, ".")
- && strcmp(dirent.name, "..")) {
+ && strcmp(dirent.name, "..")
+ && apr_fnmatch("[A-Za-z0-9]*.conf", dirent.name,
+ FNM_PERIOD) == APR_SUCCESS) {
fnew = (fnames *) apr_array_push(candidates);
fnew->fname = ap_make_full_path(p, fname, dirent.name);
}
@@ -1472,7 +1474,6 @@
*/
for (current = 0; current < candidates->nelts; ++current) {
fnew = &((fnames *) candidates->elts)[current];
- fprintf(stderr, " Processing config file: %s\n", fnew->fname);
ap_process_resource_config(s, fnew->fname, conftree, p, ptemp);
}
}
Re: [PATCH] improve config dir processing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 09:32 AM 5/28/2002, Justin asked:
>On Tue, May 28, 2002 at 02:04:47PM +0100, Joe Orton wrote:
> > This removes support for "Include <somedir>", by the argument that
> > include dirs will just trip people up unexpectedly, and "Include
> > <somedir>/*" is equivalent if they really want that behaviour. (Although
> > the ability to recurse into subdirectories is also removed, I don't
> > think that's particularly useful either)
>
>Why do we want to remove the "Include <somedir>" feature that has
>been there for a while? I'm not sold on removing that so quickly
>without a good rationale. -- justin
What if we comprimized by accepting Include somedir/ with a trailing
delimiter, while refusing to Include somedir [which is arguably confusing
and more prone to typos.]
Bill
Re: [PATCH] improve config dir processing
Posted by Sander van Zoest <sa...@yahoo-inc.com>.
On Tue, May 28, 2002 at 04:01:57PM +0100, Joe Orton wrote:
> On Tue, May 28, 2002 at 07:32:10AM -0700, Justin Erenkrantz wrote:
> > On Tue, May 28, 2002 at 02:04:47PM +0100, Joe Orton wrote:
> > > This removes support for "Include <somedir>", by the argument that
> > > include dirs will just trip people up unexpectedly, and "Include
> > > <somedir>/*" is equivalent if they really want that behaviour. (Although
> > > the ability to recurse into subdirectories is also removed, I don't
> > > think that's particularly useful either)
> > Why do we want to remove the "Include <somedir>" feature that has
> > been there for a while? I'm not sold on removing that so quickly
> > without a good rationale. -- justin
> The rationale goes: the feature is not really usable (you can't use it
> easily with any editor which creates config files), and has surprising
> behaviour (it works fine until you change a config file).
> I'd be surprised if very many people are using it, and they can still
> get the same effect using Include dir/* (except for the recursion).
We use it to add module specific functionality with just dropping in
a config file. Then doing a restart we automaticly get the new
components added. No need to adjust the actual httpd.conf file.
Granted this doesn't work for everything, but works pretty well for
most of our cases.
--
Sander van Zoest +1 (619) 881-3000
Yahoo!, Inc. sander@yahoo-inc.com
<http://www.yahoo.com/> <http://sander.vanzoest.com/>
Re: [PATCH] improve config dir processing
Posted by Thom May <th...@planetarytramp.net>.
* Joshua Slive (joshua@slive.ca) wrote :
>
> On Tue, 28 May 2002, Thom May wrote:
> > I'd be quite surprised if anyone in a mass vhosting environment _wasn't_
> > using it, to be honest. Especially the recursion.
> >
> > This seems like a pretty bad thing to remove.
>
> Could you provide more details about this? I can imagine some very
> limited situations were the recursion might be helpful, but I would expect
> it to be very rare.
>
Our shared servers host around a thousand vhosts each between 4 or 500
users.
Recursion allows us to group vhosts by user under a central directory
structure - it saves a huge amount of time being able to do this rather than
having either one huge httpd.conf or a thousand files in one directory.
Also, it allows automated tools to easily and efficiently create and delete
users and vhosts.
> Include is really only a convenience to the administrator. It can't be
> used for distributed management, because anyone with write access to one
> of these directories could easily crash the server at the next restart.
>
Certainly. As an administrator I'm all for as much convenience as possible
;)
-Thom
--
Thom May -> thom@planetarytramp.net
<aj> *sigh* you'd think a distribution composed of 6000
packages distributed across 13 different architectures (in various stages
between pre-alpha and release quality), maintained by 700 amateurs with often
conflicting goals who're globally distributed and have rarely met each other
-- you'd think a distribution like that would be simpler...
Re: [PATCH] improve config dir processing
Posted by Oden Eriksson <od...@kvikkjokk.net>.
On måndagen den 5 augusti 2002 21.16 Sander van Zoest wrote:
> On Tue, May 28, 2002 at 12:20:10PM -0700, Joshua Slive wrote:
> > OK. I'm convinced. At least three people have said they use this
> > extensively, so we should continue to support it. Why don't we just keep
> > the existing behavior and add "Include dir/*.conf" as an option. We can
> > assume that people who are using recursively included directories are
> > smart enough that they can avoid the backup problem on their own.
>
> Did we ever add this functionality? If not, I would like to see this
> added and I am willing provide a patch for 1.3 and 2.0 to add the
> "Include dir/*.conf" functionality as described above.
>
> Any objections?
What patch are you referring to?
I use this "Include dir/*.conf" feature for Mandrake Linux 9.0 (Cooker) as do
RedHat (Rawhide), and PLD (sort of).
Chears.
--
Regards // Oden Eriksson
Deserve-IT Networks -> http://d-srv.com
Re: [PATCH] improve config dir processing
Posted by Sander van Zoest <sa...@yahoo-inc.com>.
On Tue, May 28, 2002 at 12:20:10PM -0700, Joshua Slive wrote:
> OK. I'm convinced. At least three people have said they use this
> extensively, so we should continue to support it. Why don't we just keep
> the existing behavior and add "Include dir/*.conf" as an option. We can
> assume that people who are using recursively included directories are
> smart enough that they can avoid the backup problem on their own.
Did we ever add this functionality? If not, I would like to see this
added and I am willing provide a patch for 1.3 and 2.0 to add the
"Include dir/*.conf" functionality as described above.
Any objections?
--
Sander van Zoest +1 (619) 881-3000
Yahoo!, Inc. sander@yahoo-inc.com
<http://www.yahoo.com/> <http://sander.vanzoest.com/>
Re: [PATCH] improve config dir processing
Posted by di...@covalent.net.
> OK. I'm convinced. At least three people have said they use this
> extensively, so we should continue to support it. Why don't we just keep
> the existing behavior and add "Include dir/*.conf" as an option. We can
> assume that people who are using recursively included directories are
> smart enough that they can avoid the backup problem on their own.
This is certainly -good enough- this is not quite as ideal as true
recursion; i.e. if you need to do an upfront
Include conf/base/*.conf
Include conf-local/${CUSTOMERID}.conf
Include conf/ssl/*.conf
Include conf/creditcard/*.conf
Include conf/excell-stock/*.conf
Include conf/php4/4.4.3-p3/*.conf
you kind of need to 'hope' that the directories are 'there'; or risk
errors/supress errors.
Bear in mind that a lot of folks try to reconfigure without actually
changing a config file (yes - I agree - this is a bid 'odd').
But again - a *.foo include is good enough compromize for all cases I am
familliar with - but would like to stress that a recursive include can
make live easer. (but so could true XML as a config file; a
mod_ldap_config and half a dozen other things).
Another compromize may be to make 'Include' or 'IncludeFile' to be very
strict and a second directive 'IncludeDirectory' or
'RecurseConfigDirectory' to be very slack and suck anything in.
Dw
Re: [PATCH] improve config dir processing
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 28 May 2002 dirkx@covalent.net wrote:
>
> On Tue, 28 May 2002, Joshua Slive wrote:
>
> > Sure, I agree with all that. I'm just trying to figure out the use-case
> > for having "Include dir/" recursively include subdirectories. If there is
> > such a case, we should keep it, but I don't know if there is.
>
> In my experience tremendously useful in server farms which central CVS
> controlled 'stock' configs - using things like 'depot' and symlinks; you
> link in your base-line farm wide directories; your server specific ones;
> map in what you do on a per functionality block. While still allowing
> modularity and central management. Also - when using coda, afs or evil
> things like amd - it really allows you 'boot' up a web server, or with a
> graceful restart, (re)configure a virgin server without any concatenation
> or editing operations on the box.
OK. I'm convinced. At least three people have said they use this
extensively, so we should continue to support it. Why don't we just keep
the existing behavior and add "Include dir/*.conf" as an option. We can
assume that people who are using recursively included directories are
smart enough that they can avoid the backup problem on their own.
Joshua.
Re: [PATCH] improve config dir processing
Posted by di...@covalent.net.
On Tue, 28 May 2002, Joshua Slive wrote:
> Sure, I agree with all that. I'm just trying to figure out the use-case
> for having "Include dir/" recursively include subdirectories. If there is
> such a case, we should keep it, but I don't know if there is.
In my experience tremendously useful in server farms which central CVS
controlled 'stock' configs - using things like 'depot' and symlinks; you
link in your base-line farm wide directories; your server specific ones;
map in what you do on a per functionality block. While still allowing
modularity and central management. Also - when using coda, afs or evil
things like amd - it really allows you 'boot' up a web server, or with a
graceful restart, (re)configure a virgin server without any concatenation
or editing operations on the box.
Dw
Re: [PATCH] improve config dir processing
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 28 May 2002, Marc Slemko wrote:
> On Tue, 28 May 2002, Joshua Slive wrote:
>
> > Include is really only a convenience to the administrator. It can't be
> > used for distributed management, because anyone with write access to one
> > of these directories could easily crash the server at the next restart.
>
> and that is different from having write access to the directory
> the config file is in... how?
>
> There are many people don't go out and edit files on production
> servers using editors that drop turds around, and just because it
> isn't appropriate for those that do... They may generate various
> files that make up configurations and automatically push them, etc.
> Sure, they could combine them all into one file as part of the
> generation, and that is what I would do. However there are reasons
> for wanting to keep them separate, depending on the environment
> and exactly what sort of config information you are generating.
Sure, I agree with all that. I'm just trying to figure out the use-case
for having "Include dir/" recursively include subdirectories. If there is
such a case, we should keep it, but I don't know if there is.
Joshua.
Re: [PATCH] improve config dir processing
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 28 May 2002, Joshua Slive wrote:
> Include is really only a convenience to the administrator. It can't be
> used for distributed management, because anyone with write access to one
> of these directories could easily crash the server at the next restart.
and that is different from having write access to the directory
the config file is in... how?
There are many people don't go out and edit files on production
servers using editors that drop turds around, and just because it
isn't appropriate for those that do... They may generate various
files that make up configurations and automatically push them, etc.
Sure, they could combine them all into one file as part of the
generation, and that is what I would do. However there are reasons
for wanting to keep them separate, depending on the environment
and exactly what sort of config information you are generating.
Re: [PATCH] improve config dir processing
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 28 May 2002, Thom May wrote:
> I'd be quite surprised if anyone in a mass vhosting environment _wasn't_
> using it, to be honest. Especially the recursion.
>
> This seems like a pretty bad thing to remove.
Could you provide more details about this? I can imagine some very
limited situations were the recursion might be helpful, but I would expect
it to be very rare.
Include is really only a convenience to the administrator. It can't be
used for distributed management, because anyone with write access to one
of these directories could easily crash the server at the next restart.
Joshua.
Re: [PATCH] improve config dir processing
Posted by Thom May <th...@planetarytramp.net>.
* Joe Orton (jorton@redhat.com) wrote :
> On Tue, May 28, 2002 at 07:32:10AM -0700, Justin Erenkrantz wrote:
> > On Tue, May 28, 2002 at 02:04:47PM +0100, Joe Orton wrote:
> > > This removes support for "Include <somedir>", by the argument that
> > > include dirs will just trip people up unexpectedly, and "Include
> > > <somedir>/*" is equivalent if they really want that behaviour. (Although
> > > the ability to recurse into subdirectories is also removed, I don't
> > > think that's particularly useful either)
> >
> > Why do we want to remove the "Include <somedir>" feature that has
> > been there for a while? I'm not sold on removing that so quickly
> > without a good rationale. -- justin
>
> The rationale goes: the feature is not really usable (you can't use it
> easily with any editor which creates config files), and has surprising
> behaviour (it works fine until you change a config file).
>
> I'd be surprised if very many people are using it, and they can still
> get the same effect using Include dir/* (except for the recursion).
>
I'd be quite surprised if anyone in a mass vhosting environment _wasn't_
using it, to be honest. Especially the recursion.
This seems like a pretty bad thing to remove.
Cheers,
-Thom
--
Thom May -> thom@planetarytramp.net
<alp> proprietary software is kind of love/hate by definition. you
love the vendor for giving you a useful software tool, but
hate them when you find out that the tool is bug-riddled and
you'll have to pay for an upgrade. In that respect, free software
is pure love, i guess. heh
Re: [PATCH] improve config dir processing
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, May 28, 2002 at 04:01:57PM +0100, Joe Orton wrote:
> The rationale goes: the feature is not really usable (you can't use it
> easily with any editor which creates config files), and has surprising
> behaviour (it works fine until you change a config file).
I'm assuming you meant: s/config/backup/.
That's an editor thing. Personally, I rely on version control rather
than backup suffixes. I shut off backup suffixes on all of my
editors. I'd imagine that others may do the same. -- justin
Re: [PATCH] improve config dir processing
Posted by Joe Orton <jo...@redhat.com>.
On Tue, May 28, 2002 at 07:32:10AM -0700, Justin Erenkrantz wrote:
> On Tue, May 28, 2002 at 02:04:47PM +0100, Joe Orton wrote:
> > This removes support for "Include <somedir>", by the argument that
> > include dirs will just trip people up unexpectedly, and "Include
> > <somedir>/*" is equivalent if they really want that behaviour. (Although
> > the ability to recurse into subdirectories is also removed, I don't
> > think that's particularly useful either)
>
> Why do we want to remove the "Include <somedir>" feature that has
> been there for a while? I'm not sold on removing that so quickly
> without a good rationale. -- justin
The rationale goes: the feature is not really usable (you can't use it
easily with any editor which creates config files), and has surprising
behaviour (it works fine until you change a config file).
I'd be surprised if very many people are using it, and they can still
get the same effect using Include dir/* (except for the recursion).
joe
Re: [PATCH] improve config dir processing
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, May 28, 2002 at 02:04:47PM +0100, Joe Orton wrote:
> This removes support for "Include <somedir>", by the argument that
> include dirs will just trip people up unexpectedly, and "Include
> <somedir>/*" is equivalent if they really want that behaviour. (Although
> the ability to recurse into subdirectories is also removed, I don't
> think that's particularly useful either)
Why do we want to remove the "Include <somedir>" feature that has
been there for a while? I'm not sold on removing that so quickly
without a good rationale. -- justin
Re: [PATCH] improve config dir processing
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 28 May 2002, Joe Orton wrote:
> Sounds reasonable: patch is below.
>
> This removes support for "Include <somedir>", by the argument that
> include dirs will just trip people up unexpectedly, and "Include
> <somedir>/*" is equivalent if they really want that behaviour. (Although
> the ability to recurse into subdirectories is also removed, I don't
> think that's particularly useful either)
+1 (untested)
Joshua
Re: [PATCH] improve config dir processing
Posted by Joe Orton <jo...@redhat.com>.
On Mon, May 27, 2002 at 10:43:32PM -0700, Brian Pane wrote:
> As a compromise solution, how about:
>
> * Implement user-defined patterns for now, using apr_fnmatch(), but
> restrict the patterns to matching a single directory (so that we
> only need fnmatch and not full glob support).
> * Later, add a more general glob() function in APR, and retrofit it
> into the httpd config processing so that people can do things like
> "Include local/*/*.conf"
Sounds reasonable: patch is below.
This removes support for "Include <somedir>", by the argument that
include dirs will just trip people up unexpectedly, and "Include
<somedir>/*" is equivalent if they really want that behaviour. (Although
the ability to recurse into subdirectories is also removed, I don't
think that's particularly useful either)
Index: server/config.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/config.c,v
retrieving revision 1.151
diff -u -r1.151 config.c
--- server/config.c 20 May 2002 15:05:43 -0000 1.151
+++ server/config.c 28 May 2002 13:02:50 -0000
@@ -75,6 +75,7 @@
#include "apr_strings.h"
#include "apr_portable.h"
#include "apr_file_io.h"
+#include "apr_fnmatch.h"
#define APR_WANT_STDIO
#define APR_WANT_STRFUNC
@@ -1422,31 +1423,50 @@
return;
}
- /*
- * here we want to check if the candidate file is really a
- * directory, and most definitely NOT a symlink (to prevent
- * horrible loops). If so, let's recurse and toss it back
- * into the function.
- */
- if (ap_is_rdirectory(ptemp, fname)) {
+ /* Disallow using whole-directory includes. */
+ if (ap_is_rdirectory(p, fname)) {
+ fprintf(stderr, "%s: Including a directory is not supported, use "
+ "a wildcard pattern\n", ap_server_argv0);
+ exit(1);
+ }
+
+ /* Load files matching fnmatch pattern */
+ if (apr_is_fnmatch(fname)) {
apr_dir_t *dirp;
apr_finfo_t dirent;
int current;
apr_array_header_t *candidates = NULL;
fnames *fnew;
apr_status_t rv;
- char errmsg[120];
+ char errmsg[120], *pattern, *path = apr_pstrdup(p, fname);
+
+ pattern = ap_strrchr(path, '/');
+
+ AP_DEBUG_ASSERT(pattern != NULL); /* path must be absolute. */
+
+ *pattern++ = '\0';
+
+ if (apr_is_fnmatch(path)) {
+ fprintf(stderr, "%s: multi-directory wildcard patterns not allowed "
+ "in Include (%s)\n", ap_server_argv0, fname);
+ exit(1);
+ }
+
+ if (!ap_is_rdirectory(p, path)) {
+ fprintf(stderr, "%s: Include directory '%s' not found",
+ ap_server_argv0, path);
+ exit(1);
+ }
/*
* first course of business is to grok all the directory
* entries here and store 'em away. Recall we need full pathnames
* for this.
*/
- fprintf(stderr, "Processing config directory: %s\n", fname);
- rv = apr_dir_open(&dirp, fname, p);
+ rv = apr_dir_open(&dirp, path, p);
if (rv != APR_SUCCESS) {
fprintf(stderr, "%s: could not open config directory %s: %s\n",
- ap_server_argv0, fname,
+ ap_server_argv0, path,
apr_strerror(rv, errmsg, sizeof errmsg));
exit(1);
}
@@ -1455,9 +1475,11 @@
while (apr_dir_read(&dirent, APR_FINFO_DIRENT, dirp) == APR_SUCCESS) {
/* strip out '.' and '..' */
if (strcmp(dirent.name, ".")
- && strcmp(dirent.name, "..")) {
+ && strcmp(dirent.name, "..")
+ && apr_fnmatch(pattern, dirent.name,
+ FNM_PERIOD) == APR_SUCCESS) {
fnew = (fnames *) apr_array_push(candidates);
- fnew->fname = ap_make_full_path(p, fname, dirent.name);
+ fnew->fname = ap_make_full_path(p, path, dirent.name);
}
}
@@ -1472,7 +1494,6 @@
*/
for (current = 0; current < candidates->nelts; ++current) {
fnew = &((fnames *) candidates->elts)[current];
- fprintf(stderr, " Processing config file: %s\n", fnew->fname);
ap_process_resource_config(s, fnew->fname, conftree, p, ptemp);
}
}
Index: docs/manual/mod/core.xml
===================================================================
RCS file: /home/cvspublic/httpd-2.0/docs/manual/mod/core.xml,v
retrieving revision 1.10
diff -u -r1.10 core.xml
--- docs/manual/mod/core.xml 27 May 2002 02:22:09 -0000 1.10
+++ docs/manual/mod/core.xml 28 May 2002 13:02:50 -0000
@@ -1034,7 +1034,7 @@
<name>Include</name>
<description>Includes other configuration files from within
the server configuration files</description>
-<syntax>Include <em>file-path</em>|<em>directory-path</em></syntax>
+<syntax>Include <em>file-path</em>|<em>wildcard-pattern</em></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
@@ -1043,11 +1043,13 @@
<p>This directive allows inclusion of other configuration files
from within the server configuration files.</p>
- <p>If <directive>Include</directive> points to a directory, rather than a
- file, Apache will read all files in that directory, and any
- subdirectory, and parse those as configuration files.</p>
+ <p>If <directive>Include</directive> is used with a wildcard
+ pattern, then Apache will read all the configuration files which
+ match the pattern. The pattern may only select files from a
+ single directory; <code>/foo/*.conf</code> is valid, but
+ <code>/foo/*/*.conf</code> is not.</p>
- <p>The file path specified may be a fully qualified path (i.e.
+ <p>The file path or pattern specified may be a fully qualified path (i.e.
starting with a slash), or may be relative to the
<directive module="core">ServerRoot</directive> directory.</p>
@@ -1055,7 +1057,7 @@
<example>
Include /usr/local/apache/conf/ssl.conf<br />
- Include /usr/local/apache/conf/vhosts/
+ Include /usr/local/apache/conf/vhosts/*.conf
</example>
<p>Or, providing paths relative to your <code>ServerRoot</code>
@@ -1063,27 +1065,9 @@
<example>
Include conf/ssl.conf<br />
- Include conf/vhosts/
+ Include conf/vhosts/*.conf
</example>
- <p>Make sure that an included directory does not contain any stray
- files, such as editor temporary files, for example, as Apache will
- attempt to read them in and use the contents as configuration
- directives, which may cause the server to fail on start up.
- Running <code>apachectl configtest</code> will give you a list of
- the files that are being processed during the configuration
- check:</p>
-
-<example><pre>
- root@host# apachectl configtest
- Processing config directory: /usr/local/apache/conf/vhosts
- Processing config file: /usr/local/apache/conf/vhosts/vhost1
- Processing config file: /usr/local/apache/conf/vhosts/vhost2
- Syntax OK
-</pre></example>
-
- <p>This will help in verifying that you are getting only the files
- that you intended as part of your configuration.</p>
</usage>
<seealso><a href="../programs/apachectl.html">apachectl</a></seealso>
Re: [PATCH] improve config dir processing
Posted by Brian Pane <bp...@pacbell.net>.
On Mon, 2002-05-27 at 05:51, Joe Orton wrote:
> On Mon, May 27, 2002 at 08:02:13AM -0400, Joshua Slive wrote:
> > Joe Orton wrote:
> > > Currently config directory processing isn't very useful in practice
> > > because all files in the config dir are loaded - so if you use an editor
> > > which creates backup files, the backup file will still be loaded.
> > >
> > > A simple way to fix this is to only load files in the config dir which
> > > match the pattern "[A-Za-z0-9]*.conf", as in the following patch (which
> > > also removes the noise produced on stderr when processing config dirs)
> >
> > Fine, but I still prefer my solution: allow the user to supply the
> > fnmatch, so that they could just do
> > Include *.conf
> > or
> > Include *.whatever
> > or
> > Include File??.conf
> > etc.
>
> I agree that would be better, but it would really require a glob()
> function to implement properly; I don't know how portable that is.
As a compromise solution, how about:
* Implement user-defined patterns for now, using apr_fnmatch(), but
restrict the patterns to matching a single directory (so that we
only need fnmatch and not full glob support).
* Later, add a more general glob() function in APR, and retrofit it
into the httpd config processing so that people can do things like
"Include local/*/*.conf"
--Brian
Re: [PATCH] improve config dir processing
Posted by Joe Orton <jo...@redhat.com>.
On Mon, May 27, 2002 at 08:02:13AM -0400, Joshua Slive wrote:
> Joe Orton wrote:
> > Currently config directory processing isn't very useful in practice
> > because all files in the config dir are loaded - so if you use an editor
> > which creates backup files, the backup file will still be loaded.
> >
> > A simple way to fix this is to only load files in the config dir which
> > match the pattern "[A-Za-z0-9]*.conf", as in the following patch (which
> > also removes the noise produced on stderr when processing config dirs)
>
> Fine, but I still prefer my solution: allow the user to supply the
> fnmatch, so that they could just do
> Include *.conf
> or
> Include *.whatever
> or
> Include File??.conf
> etc.
I agree that would be better, but it would really require a glob()
function to implement properly; I don't know how portable that is.
Regards,
joe
Re: [PATCH] improve config dir processing
Posted by Joshua Slive <jo...@slive.ca>.
Joe Orton wrote:
> Currently config directory processing isn't very useful in practice
> because all files in the config dir are loaded - so if you use an editor
> which creates backup files, the backup file will still be loaded.
>
> A simple way to fix this is to only load files in the config dir which
> match the pattern "[A-Za-z0-9]*.conf", as in the following patch (which
> also removes the noise produced on stderr when processing config dirs)
Fine, but I still prefer my solution: allow the user to supply the
fnmatch, so that they could just do
Include *.conf
or
Include *.whatever
or
Include File??.conf
etc.
Joshua.