httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: <Perl> vs. external config
Date Wed, 26 Apr 2000 23:17:35 GMT
You forced me to do some serious pondering. But I think I have

On Wed, Apr 26, 2000 at 03:11:45PM -0700, Doug MacEachern wrote:
> first of all, in terms of Perl, <Perl> sections provide a "standard" way
> of generating configuration.  if you take that away, not only do you break
> the hell out of existing systems, everybody ends up with their own
> generator implementation that nobody else understands.

I'm not talking at all about what's included with Apache, just what's
in the httpd binary. I think it's next to mandatory that we include a
default parser with Apache that will do DNS resolution and such.

> there is lots of info <Perl> sections can get at being inside the apache
> runtime that external generators cannot, at least not in a clean way i can
> think of.  for example:
> #whatever ServerRoot is already configured as or from -d
> $ServerRoot = Apache->server_root_relative;
> #now lots of things can be defined in terms of $ServerRoot
> push @Alias,
>    ["/icons/" => "$ServerRoot/icons"], ...
> push @INC, "$ServerRoot/lib/perl"; #local Perl libraries

If your entire configuration is generated by a Perl script, it has
this info anyway.

If you're worried about the case where only part of your configuration
is generated by Perl, then the perl script can process the existing
configuration easily, iff the httpd configuration syntax is stupidly
easy to parse. I'm thinking something similar to qmail's config file
format, with a whole directory hierarchy organizing the data. So for
your example:

# yeah, there are far more efficient ways to do this, but this is just
# an example
$Serverroot = `cat /usr/local/apache/conf/serverroot`

or the -d argument to the parser, or whatever.

I want the output of the parser (i.e. the input to Apache) to be a
scripting-level API to the current Apache configuration. It has to be
dead simple, or else your concerns will make this unfeasible.

> #multiple developers running a server on the same box
> #want to run the server as themselves for writability into
> #their sandbox or whatever
> #don't want to generate a dozen different config files to change this
> #value, when it can just be in one file

I don't see a problem with having lots of files around. It's not like
config files are multi-megabyte or anything.

> $User  = getpwuid $>;
> $Group = getgrgid $); 
> $Port = $> + 1024; #choose a unique, unprivleged port based on user id
> print "will listen on port $Port\n";

With qmail-style configuration, we might be able to use symlinks. Or,
the external parser can easily do this task as well. In fact, the
sandboxing setup I'm working on at Collab uses an external parser
(Perl-based of course).

I'd give similar answers to your other cases.

> #get a database password without ever saving it to disk
> #or keeping it around for long in memory
> my $database_password = prompt("enter database password:");
> connect_to_database($database_password);
> undef $database_password;

I guess this one's kind of nice. But, I'd say that if you can't trust
the filesystem permissions on your drive, I think you have bigger

> $Apache::Server::SaveConfig = 1;
> #by setting this variable, mod_perl does not clear the symbol table used
> #to generate the config, and all these variables are available at request
> #time in the Apache::ReadConfig:: namespace
> #if httpd.conf were generated externally, i would need another way to make
> #that config available to Perl code running inside the server

I don't quite understand this one. The current config isn't otherwise
available to the Perl code right now? Well, this setup makes that
easier. :)

> ok, thinking back to my first comment about everybody implementing their
> own generator, i suppose people are suggesting mod_perl ship with a
> generator.

You're one step ahead of me.

> keeping in mind that the implementation of <Perl> config can
> be sprinkled in with vanilla config in the same file, e.g.
> LoadModule proxy_module libexec/
> <Perl>
> if (Apache->module('mod_proxy.c')) {
>     ...
> }

IfModule takes care of this. And the only good reason I can think of
for IfModule anyway is to allow directives not to fail if they aren't
present. That can better be done with an "optional" flag or something.

> </Perl>
> if Apache/mod_perl can no longer deal with <Perl> sections, that means
> mod_perl has implement it's own config file parser

If the accessibility of the rest of the Apache config is dead simple
(and I think that's mandatory for the external config parser idea to
work), then I don't think it's a burden for a webmaster to write his
own Perl code to fill in the missing details of an Apache config if he
was already planning to use embedded Perl in the config file anyway.

View raw message