Re: Apache::Config module
On Tue, 27 Jun 2000, Nathan Wiger wrote:
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
ServerName www.mydomain.com
UseCanonicalName Off
And parse it case-insensitively, returning a ref to a hash:
my $ac = new Apache::Config;
my $conf = $ac-readconf($configfile);
print $conf-{servername}; # = "www.mydomain.com";
print $conf-{usecanonicalname}; # = 0 (not undef so can test
#for defined() still)
it would be really cool if this module could support dumping of a parsed
config file into the same format that Perl sections understand. and the
other way around, dumping a Perl section back into a .conf that Apache
can read without Perl sections.
In any case, I have several questions:
1. Does a module like this exist anywhere? I saw Doug's
Apache::httpd_conf, but this only takes care of writing
a very minimal config file. I looked thru all the
Apache:: modules but didn't see one.
yeah, Apache::httpd_conf was something that was started and never
finished. i think ken williams is working on something in this area, for
modules to write test config files.
2. Is the name Apache::Config a good name for this module?
It seems like the obvious choice to me, and doesn't
look like it's taken. I've also played around with
Apache::ConfigFile and Apache::ReadConf, either of
which I'm open to as well (or other suggestions?).
i'd go with Apache::ConfigFile.
Re: Apache::Config module
No wonder Nathan Wiger on Jun 29 said that, NW] NW] In any case, I have several questions: NW] NW] NW] NW] 1. Does a module like this exist anywhere? NW] NW] You may want to take a look at AppConfig module. It does provide NW] generic capability to parse various kinds of config file. But I'll NW] be a happy user to have more spesific Apache related in this regard. NW] NW] Yeah, I checked out AppConfig, and I actually emailed the author about NW] modifying it a little so I could use it as a base class possibly for NW] Apache::Config. Unfortunately, I haven't heard anything back yet. NW] AppConfig would be a great base class, the only problem is that: NW] NW] # it handles comments like this NW] NW] # but not like this NW] NW] that's the only sticking point to not being able to extend AppConfig. NW] Hopefully I'll hear something back from him. The fix is just the NW] addition of a \s* to a regexp. Yeah, at least the author could let the subclass to override some aspects. The comment for example, smb.conf and php.ini use `;' as well. NW] Apache::Config will be sufficient, IMHO, as later someone might NW] write another module, say Apache::Config::Deploy, that syncronize NW] the configuration of some httpds across some networks. NW] NW] Not bad - I like the idea for an extension. NW] NW] I'll keep plugging away on it then, hopefully the author of AppConfig NW] will get back to me as that would help save some work, but regardless NW] the parsing of the httpd.conf is not really that hard in and of itself. NW] I'll use the name Apache::Config unless I hear otherwise. So you may want to take a time to confirm the name to [EMAIL PROTECTED] NW] Thanks again to everyone who responded for their input! Good luck with the project! san -- trabasLabs * [EMAIL PROTECTED] * http://www.trabas.com Zero Point * [EMAIL PROTECTED] * http://www.zp.f2s.com -- Kesenian hanyalah dusta, dusta yang mengungkap kebenaran --Plato, kurang lebih
Re: Apache::Config module
James-
You and are are saying the same thing, just with different terminology.
I agree completely. :-)
-Nate
James G Smith wrote:
Nathan Wiger [EMAIL PROTECTED] wrote:
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
#UseCanonicalName On# = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf-{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf-{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
I think I would prefer it not exist in the hash if it is commented out in the
config file (the same as not existing in the config file). Then
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
UseCanonicalName # = undef
#UseCanonicalName On# = non-existant (commented out)
Otherwise, we can't distinguish between the last two possibilities.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Apache::Config module
NW] In any case, I have several questions: NW] NW] 1. Does a module like this exist anywhere? You may want to take a look at AppConfig module. It does provide generic capability to parse various kinds of config file. But I'll be a happy user to have more spesific Apache related in this regard. Yeah, I checked out AppConfig, and I actually emailed the author about modifying it a little so I could use it as a base class possibly for Apache::Config. Unfortunately, I haven't heard anything back yet. AppConfig would be a great base class, the only problem is that: # it handles comments like this # but not like this that's the only sticking point to not being able to extend AppConfig. Hopefully I'll hear something back from him. The fix is just the addition of a \s* to a regexp. Apache::Config will be sufficient, IMHO, as later someone might write another module, say Apache::Config::Deploy, that syncronize the configuration of some httpds across some networks. Not bad - I like the idea for an extension. I'll keep plugging away on it then, hopefully the author of AppConfig will get back to me as that would help save some work, but regardless the parsing of the httpd.conf is not really that hard in and of itself. I'll use the name Apache::Config unless I hear otherwise. Thanks again to everyone who responded for their input! -Nate
Re: Apache::Config module
Perhaps
3. multi-level hash, i.e.
$conf-{directory}-{'/'}-{sethandler}
This is, afaik, more in-line with what the Perl.../Perl sections do. I
would suggest making it so the output of this module could easily be fed into
the mod_perl configuration engine in the Perl sections. This gives us the
ease of the second example with the programming simplicity of the first (i.e.,
no new functions).
I actually like this alot. My question would be how to parse something
that didn't have one element, or that had multiple ones, for example I
can envision:
Perl /Perl
SomeContext "/a" "/b" /SomeContext
The first one exists, while the second one is (as far as I'm aware) only
theoretical. However, should they be solved as:
$conf-{perl}-{somesetting}
$conf-{somecontext}-{'/a'}-{'/b'}-{somesetting}
Not sure about the 'multi' context version. It's ugly though and I
hope it doesn't happen. However, for the 'no context' version, I
suggest:
Perl
foo();
/Perl
Perl
bar();
/Perl
The you could have either:
$conf-{perl}
returns
foo();
bar();
or
["foo();\n", "bar();\n"];
I *think* I prefer the latter.
--
Piers
BEGIN {$^H {integer} = sub {chr shift}; $^H=3312}
print 74,117,115,116,32,97,110,111,116,104,101,114;
print 32,80,101,114,108,32,72,97,99,107,101,114,10;
Re: Apache::Config module
Nathan Wiger [EMAIL PROTECTED] wrote:
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
#UseCanonicalName On# = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf-{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf-{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
I think I would prefer it not exist in the hash if it is commented out in the
config file (the same as not existing in the config file). Then
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
UseCanonicalName # = undef
#UseCanonicalName On# = non-existant (commented out)
Otherwise, we can't distinguish between the last two possibilities.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Apache::Config module
No wonder Nathan Wiger on Jun 27 said that,
NW] Hi all-
NW]
NW] I've written a module that can parse the Apache httpd.conf config file
NW] (and in fact any Apache-like config file). It will take a set of
NW] directive like:
NW]
NW] ServerName www.mydomain.com
NW] UseCanonicalName Off
NW]
NW] And parse it case-insensitively, returning a ref to a hash:
NW]
NW] my $ac = new Apache::Config;
NW] my $conf = $ac-readconf($configfile);
NW] print $conf-{servername}; # = "www.mydomain.com";
NW] print $conf-{usecanonicalname}; # = 0 (not undef so can test
NW] #for defined() still)
NW]
NW] I am also finishing up the ability to parse within contexts, such as
NW] Directory and Location. I am still unsure of the interface, I have
NW] two ideas:
NW]
NW] 1. multi-level hash, i.e.
NW] $conf-{"directory /"}-{sethandler}
NW]
NW] 2. individual functions, i.e.
NW] $conf-directory("/")-{sethandler}
NW]
NW] If anyone has any input, I'm all ears. Right now I'm leaning towards the
NW] second one, if I can get it working. The first one is really flexible
NW] and easy, the problem is that it's difficult to search. The second one
NW] helps with this issue, but the downside is that new functions have to be
NW] added if new Apache contexts are defined. I'm trying to play some tricks
NW] with the AutoLoader ala Shell to get new functions defined on the fly.
NW] If anyone has good ideas for a better interface, I'd also like to hear
NW] them.
NW]
NW] In any case, I have several questions:
NW]
NW] 1. Does a module like this exist anywhere? I saw Doug's
NW]Apache::httpd_conf, but this only takes care of writing
NW]a very minimal config file. I looked thru all the
NW]Apache:: modules but didn't see one.
You may want to take a look at AppConfig module. It does provide
generic capability to parse various kinds of config file. But I'll
be a happy user to have more spesific Apache related in this regard.
NW]
NW] 2. Is the name Apache::Config a good name for this module?
NW]It seems like the obvious choice to me, and doesn't
NW]look like it's taken. I've also played around with
NW]Apache::ConfigFile and Apache::ReadConf, either of
NW]which I'm open to as well (or other suggestions?).
Apache::Config will be sufficient, IMHO, as later someone might
write another module, say Apache::Config::Deploy, that syncronize
the configuration of some httpds across some networks.
[snip]
san
--
trabasLabs * [EMAIL PROTECTED] * http://www.trabas.com
Zero Point * [EMAIL PROTECTED] * http://www.zp.f2s.com
--
bahkan mahasiswa yang memperjuangkan reformasi
pun masih menempatkan wanita pada posisi inferior
--Sudjiwo Tejo 14/12/1998
tentang kiriman ayam betina kepada Jaksa Agung
Apache::Config module
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
ServerName www.mydomain.com
UseCanonicalName Off
And parse it case-insensitively, returning a ref to a hash:
my $ac = new Apache::Config;
my $conf = $ac-readconf($configfile);
print $conf-{servername}; # = "www.mydomain.com";
print $conf-{usecanonicalname}; # = 0 (not undef so can test
#for defined() still)
I am also finishing up the ability to parse within contexts, such as
Directory and Location. I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf-{"directory /"}-{sethandler}
2. individual functions, i.e.
$conf-directory("/")-{sethandler}
If anyone has any input, I'm all ears. Right now I'm leaning towards the
second one, if I can get it working. The first one is really flexible
and easy, the problem is that it's difficult to search. The second one
helps with this issue, but the downside is that new functions have to be
added if new Apache contexts are defined. I'm trying to play some tricks
with the AutoLoader ala Shell to get new functions defined on the fly.
If anyone has good ideas for a better interface, I'd also like to hear
them.
In any case, I have several questions:
1. Does a module like this exist anywhere? I saw Doug's
Apache::httpd_conf, but this only takes care of writing
a very minimal config file. I looked thru all the
Apache:: modules but didn't see one.
2. Is the name Apache::Config a good name for this module?
It seems like the obvious choice to me, and doesn't
look like it's taken. I've also played around with
Apache::ConfigFile and Apache::ReadConf, either of
which I'm open to as well (or other suggestions?).
I'm aware of the Apache and Apache::Constants modules, which do provide
Apache API methods for getting to this data that work great for
mod_perl. My goal with this module was to make it general enough to be
used to parse any Apache-style config file. That way, if you wanted (a)
write a CGI script outside of mod_perl that used httpd.conf data, or (b)
wrote a custom (maybe non-web) app that used an Apache-like config file,
you could get at the data quickly. In this way it would be like
Apache::Session, where it can work either in a CGI or mod_perl context.
Thanks for your help and input.
-Nate
Re: Apache::Config module
Nathan Wiger [EMAIL PROTECTED] wrote:
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
[snip]
I am also finishing up the ability to parse within contexts, such as
Directory and Location. I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf-{"directory /"}-{sethandler}
2. individual functions, i.e.
$conf-directory("/")-{sethandler}
Perhaps
3. multi-level hash, i.e.
$conf-{directory}-{'/'}-{sethandler}
This is, afaik, more in-line with what the Perl.../Perl sections do. I
would suggest making it so the output of this module could easily be fed into
the mod_perl configuration engine in the Perl sections. This gives us the
ease of the second example with the programming simplicity of the first (i.e.,
no new functions).
We can also pull out the information we might want: I can get a list of all
the directories I'm configuring with the first or third method, but the first
is messy. The second method doesn't give us an obvious solution to this.
Even though I would not suggest configuring Apache by reading in a
configuration file and feeding it to the mod_perl engine, it does have a
certain aesthetic appeal to me... besides, I only have to learn one way of
thinking about it :)
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Apache::Config module
James-
You might want to reconsider the usecanonicalname setting. The hash element
should exist if and only if it appears in the configuration file. It should
be defined if and only if it has an argument in the configuration file.
Thus, the following results:
UseCanonicalName
results in $conf-{usecanonicalname} == undef
UseCanonicalName Off
results in $conf-{usecanonicalname} == 0
Then use existance in the hash array to test existance in the configuration
file. You may have already been thinking along this line. If so, then I'm
only clarifying a point...
You're exactly right - that's why I make a distinction between 0, 1, and
undef, so:
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
#UseCanonicalName On# = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf-{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf-{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
This lets you default to any value you want (on or off). Does this help
clarify?
Regarding this:
Perhaps
3. multi-level hash, i.e.
$conf-{directory}-{'/'}-{sethandler}
This is, afaik, more in-line with what the Perl.../Perl sections do. I
would suggest making it so the output of this module could easily be fed into
the mod_perl configuration engine in the Perl sections. This gives us the
ease of the second example with the programming simplicity of the first (i.e.,
no new functions).
I actually like this alot. My question would be how to parse something
that didn't have one element, or that had multiple ones, for example I
can envision:
Perl /Perl
SomeContext "/a" "/b" /SomeContext
The first one exists, while the second one is (as far as I'm aware) only
theoretical. However, should they be solved as:
$conf-{perl}-{somesetting}
$conf-{somecontext}-{'/a'}-{'/b'}-{somesetting}
Input??? I just want to plan this out from the start so that as things
are added later the syntax and/or structures don't get unwieldy. I don't
want to change the "API" to such a module once it's out there.
Thanks again for the feedback.
-Nate
