httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: <Perl> vs. external config
Date Fri, 28 Apr 2000 09:35:20 GMT
On Wed, 26 Apr 2000, Manoj Kasichainula wrote:
>...
> 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.

See my other comments re: binary vs separate tool. We must write it, so
the division is purely artificial and contrived.

>...
> > 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.

Bullshit. As Doug has said, to truly know this, the Perl script must not
only replicate the Apache parser, but it has to duplicate the *semantics*
of the directives. What argument formats? What ranges are used? How do
those arguments map into the configuration of a virtual server? How is the
nesting/overriding of values performed when a <Directory> is present? etc.

To require somebody to duplicate all of this knowledge into an external
tool, simply because you desire to have external tools, is totally
backwards.

>...
> > #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.

You don't. I agree with Doug: I do. I have a dozen virtual hosts in my
httpd.conf. I keep them in one file for management simplicity. I like it
that way. Saying "sorry, that is no longer acceptable. you must use
'ApacheConfigSplitter' if you want a single file since Apache now requires
multiple files." Feh.

> > $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

Great! Make my job harder! Thank you!

</sarcasm>  :-)

>...
> > #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
> problems.

As Doug said. So? That's my policy and my problem :-)

>...
> > 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.

Optional flag? Eh? Can you explain this idea further?

[ I'm presuming the answer isn't that "the optional flag is in the
  command_rec" since (by definition) the command_rec is not present. ]

> > </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.

Why must I sprinkle all my configuration handling across httpd.conf,
mungeconfig.pl, and othermunger.pl?

Empirically-proven, the embedded configuration of mod_perl is useful.
(personally, I find Perl in any form blows, but can accept its utility :-)


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/


Mime
View raw message