You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@apache.org> on 2002/07/18 03:33:43 UTC

daedalus is running httpd-2.0.pre40

...since Wednesday, 17-Jul-2002 18:49:31 PDT .  Things look fine now, but we 
took about a 3 1/2 minute site outage because of:

[Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not 
open mime types config file /usr/local/apache/conf/mime.types.
Configuration Failed

That's the feechur where we no longer copy existing conf/ directories at make 
install time.  Remind me again:  what was wrong with simply not overlaying 
existing files?

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by Thom May <th...@planetarytramp.net>.
* William A. Rowe, Jr. (wrowe@rowe-clan.net) wrote :
> At 08:33 PM 7/17/2002, Greg Ames wrote:
> >...since Wednesday, 17-Jul-2002 18:49:31 PDT .  Things look fine now, but 
> >we
> >took about a 3 1/2 minute site outage because of:
> >
> >[Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not
> >open mime types config file /usr/local/apache/conf/mime.types.
> >Configuration Failed
> >
> >That's the feechur where we no longer copy existing conf/ directories at 
> >make
> >install time.  Remind me again:  what was wrong with simply not overlaying
> >existing files?
> 
> Because folks may have *valuable* and *important* config changes that
> shouldn't be wiped out?
> 
> That doesn't mean we couldn't overlay none the less... and save their
> existing files in .bak.# files.

Narrrgh. Put the new files as .new - that way we don't break anything.
We should only do this for $sysconfdir, too - it's the only place we can
pseudo guarantee that we're replacing like with like.

Cheers,
-Thom
-- 
Thom May -> thom@planetarytramp.net

Even Debian developers are human.

Re: daedalus is running httpd-2.0.pre40

Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Jul 18, 2002 at 01:05:19AM -0700, Aaron Bannert wrote:
> On Wed, Jul 17, 2002 at 09:37:55PM -0500, William A. Rowe, Jr. wrote:
> > That doesn't mean we couldn't overlay none the less... and save their
> > existing files in .bak.# files.
> 
> I like that much better. +1

Wait, that doesn't work for directories...

How about we go back to the way it was before and work from there? At
least that way there was an option (I could save any files that I modified
somewhere save in case they were overwritten for whatever reason).

-aaron

Re: daedalus is running httpd-2.0.pre40

Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Jul 17, 2002 at 09:37:55PM -0500, William A. Rowe, Jr. wrote:
> That doesn't mean we couldn't overlay none the less... and save their
> existing files in .bak.# files.

I like that much better. +1

-aaron


Re: daedalus is running httpd-2.0.pre40

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:31 AM 7/18/2002, Jeff Trawick wrote:
>"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
>Previously, foo-std.conf would always be copied but foo.conf wouldn't
>be overlaid.  That was a nice feature.

[on win32, we are using .default.conf at the moment.  That said...]

the current win32 behavior is the same, all 'templates' are overwritten
[for the current build] and all existing configs are left alone.

And myself?  ++1 for this [polite] behavior.


Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
Dale Ghent wrote:

> Apache configuration files can be pretty much considered user-land stuff
> that shouldnt be touched by 'make install'

definately.
 
> There are so many ways for an admin to organize his/her apache
> configuration files, from a flat httpd.conf to having it broken out into
> many Included files of arbritrary name. Not to mention custom entries in
> mime.types and so-forth.

of course.

> What may be good for you isnt necessarily good for everyone else. Keep
> a 'make install' over an existing installation as transparent as possible.

I am suggesting we do something like this:

for each file in the build conf/ directory
   if ((the file does not exist in the target directory || the filename is
*-std.*)
          && the filename isn't *.in)
       copy the file from the build conf/ directory to the target conf/
directory

I believe that would be transparent.  It should work for other non-code install
directories too, except the filename checks might be irrelevant.

> There's no need to fix something that's not broke.

It's broke IMO.  Please look at my initial post.  make install violated the
principle of least astonishment and we took an unneccessary outage.  I will
concede that the old code was broken too, if it clobbered an existing mime.types
file.

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by Dale Ghent <da...@elemental.org>.
On Thu, 18 Jul 2002, Greg Ames wrote:

| I guess I wasn't clear.  I have automation that creates a new conf/,
| then copies in httpd.conf* from the production conf/ with appropriate
| edits.  So my conf/ directory exists, but doesn't contain mime.types (or
| several other files which aren't relevant on daedalus).
|
| make install runs after that.  It used to copy in everything except the
| httpd.conf file, which worked perfectly for me.  Now it doesn't copy
| *any* of the conf/* files because the directory exists.  It would be
| better if we did this on a more granular level, i.e. check to see if the
| individual file exists in the target dir, then copy/don't copy as
| appropriate.
|
| If we had a customized mime.types, I wouldn't want it to get clobbered.
| I think the old code would have done that.

Apache configuration files can be pretty much considered user-land stuff
that shouldnt be touched by 'make install'

There are so many ways for an admin to organize his/her apache
configuration files, from a flat httpd.conf to having it broken out into
many Included files of arbritrary name. Not to mention custom entries in
mime.types and so-forth.

What may be good for you isnt necessarily good for everyone else. Keep
a 'make install' over an existing installation as transparent as possible.
There's no need to fix something that's not broke.

If there are pertinant changes to a config directive or something else
along those lines, the admins can add them to their configs after reading
about them in CHANGES .... right?

/dale


Re: [VOTE] httpd-std.conf WAS: RE: daedalus is running httpd-2.0.pre40

Posted by "johannes m. richter" <jo...@gmx.net>.
>Secondly consider that you have installed 2.0.35 and are upgrading to 2.0.40.
>If ${sysconfdir}/[examples/]httpd-std.conf would be overwritten, you would 
>have
>no chance to compare the old httpd-std.conf with the new httpd-std.conf 
>anymore.
>I consider that diff more usefull than the diff between httpd.conf and the new
>httpd-std.conf.

True. But this problem could be solved by appending the version number to 
the filename. httpd-std-2.0.36.conf and so on. So you'd get a nice 
collection of various standard conf files in your 
examples/templates/whatever directory.

(then we'd only need +VersionSort for our favorite file manager;-)

j.

-- 
Why did Nature create man? Was it to show that she is big enough to
make mistakes, or was it pure ignorance?  -- Holbrook Jackson
- http://jgcl.at/ - new photos from summer camp 2002 in Moosen/Tirol


Re: daedalus is running httpd-2.0.pre40

Posted by Chris Taylor <ch...@phi-web.co.uk>.
Hi,

Although I'm not one of the "Developers", I've been following the list for a
couple of weeks, waiting for release notifications so I can compile the PS2
binaries.

However, I'd just like to give my "users" view of this issue about
having -std.conf files placed in conf/ when a user upgrades. I think it's a
good idea personally, I like to check that nothing substantial has changed
in httpd.conf when I upgrade so having the -std.conf available would be
quite convenient.

On the other hand, I can appreciate the "clutter" opinion and possibly an
option should be added to ./configure so people can turn this behaviour off?

Just my 2p :)

Chris


SV: mysqlsupport for virtuals.

Posted by Jonas Eriksson <jo...@webkonsulterna.com>.
Well.. I want it to work with apache 2.0x
but thanks anyway.



-----Ursprungligt meddelande-----
Från: Jacob Rief [mailto:jacob.rief@tiscover.com] 
Skickat: den 30 juli 2002 14:20
Till: dev@httpd.apache.org
Ämne: Re: mysqlsupport for virtuals.


I did some work on this. I am using mod_rewrite
and do a dynamical lookup for a rewrite-map using
LDAP. If you wish you may use a RDB instead of LDAP:
This dynamic rewrite-map then can be used to map virtual
hosts and whatever you want.

The biggest problem with mod_rewrite is, that it does
allow only one instance of a mapping program to run.
And if this progam has a problem, the whole webserver
has a problem. I therefore wrote a patch which allows 
to link dynamically such a mapping-dso into mod_rewrite.

Unfortunately nobody from the Apache-group was ever
interrested in this patch. Not even comments.

Have a look at
http://bugs.apache.org/index.cgi/full/7688
and
http://homes.tiscover.com/jrief/apache_1.3.19-rewrite-dso.patch
BTW: the patch works up to version 1.3.26.

Jacob




On Wed, 2002-07-24 at 17:50, Jonas Eriksson wrote:
> Hi
> 
> My http.conf file grows every day and its getting big...
> It's getting hard to find anyting without seartching in it.
> 
> My question is :
> 
> I like to move all virtualshosts away from httpd.conf in to a mysql
server.
> My doing that it would be muth easy to maintain my virtualhosts.
> 
> Have someone tried this without loosing  preformance?
>  
>  
>    




Re: mysqlsupport for virtuals.

Posted by Jacob Rief <ja...@tiscover.com>.
I did some work on this. I am using mod_rewrite
and do a dynamical lookup for a rewrite-map using
LDAP. If you wish you may use a RDB instead of LDAP:
This dynamic rewrite-map then can be used to map virtual
hosts and whatever you want.

The biggest problem with mod_rewrite is, that it does
allow only one instance of a mapping program to run.
And if this progam has a problem, the whole webserver
has a problem. I therefore wrote a patch which allows 
to link dynamically such a mapping-dso into mod_rewrite.

Unfortunately nobody from the Apache-group was ever
interrested in this patch. Not even comments.

Have a look at
http://bugs.apache.org/index.cgi/full/7688
and
http://homes.tiscover.com/jrief/apache_1.3.19-rewrite-dso.patch
BTW: the patch works up to version 1.3.26.

Jacob




On Wed, 2002-07-24 at 17:50, Jonas Eriksson wrote:
> Hi
> 
> My http.conf file grows every day and its getting big...
> It's getting hard to find anyting without seartching in it.
> 
> My question is :
> 
> I like to move all virtualshosts away from httpd.conf in to a mysql server.
> My doing that it would be muth easy to maintain my virtualhosts.
> 
> Have someone tried this without loosing  preformance?
>  
>  
>    



Re: mysqlsupport for virtuals.

Posted by Jonas Eriksson <jo...@webkonsulterna.com>.
I wait for it..

/ Jonas






> Hi Jonas,
> 
> i'm actually workin on hacking a module for this. (ie, like mod_vhost_alias,
> but uses a db)
> 
> give me maybe a few weeks and i'll publish..
> 
>  -- james
> 
> >
> > Hi
> >
> > My http.conf file grows every day and its getting big...
> > It's getting hard to find anyting without seartching in it.
> >
> > My question is :
> >
> > I like to move all virtualshosts away from httpd.conf in to a
> > mysql server.
> > My doing that it would be muth easy to maintain my virtualhosts.
> >
> > Have someone tried this without loosing  preformance?
> >
> >
> >
> >
> >
> 
> 


RE: mysqlsupport for virtuals.

Posted by James Cox <im...@php.net>.
Hi Jonas,

i'm actually workin on hacking a module for this. (ie, like mod_vhost_alias,
but uses a db)

give me maybe a few weeks and i'll publish..

 -- james

>
> Hi
>
> My http.conf file grows every day and its getting big...
> It's getting hard to find anyting without seartching in it.
>
> My question is :
>
> I like to move all virtualshosts away from httpd.conf in to a
> mysql server.
> My doing that it would be muth easy to maintain my virtualhosts.
>
> Have someone tried this without loosing  preformance?
>
>
>
>
>


RE: mysqlsupport for virtuals.

Posted by jo...@sterls.com.
Even Better:  lets just make the whole damn configuration interface pluggable
(yup, this has been suggested since the dinosaurs.....).  We're on the right
track now that the config file is parsed at startup time....

sterling

>-- Original Message --
>Reply-To: dev@httpd.apache.org
>From: "Jonas Eriksson" <jo...@webkonsulterna.com>
>To: <de...@httpd.apache.org>
>Subject: mysqlsupport for virtuals.
>Date: Wed, 24 Jul 2002 17:50:22 +0200
>
>
>Hi
>
>My http.conf file grows every day and its getting big...
>It's getting hard to find anyting without seartching in it.
>
>My question is :
>
>I like to move all virtualshosts away from httpd.conf in to a mysql server.
>My doing that it would be muth easy to maintain my virtualhosts.
>
>Have someone tried this without loosing  preformance?
> 
> 
>   
>



mysqlsupport for virtuals.

Posted by Jonas Eriksson <jo...@webkonsulterna.com>.
Hi

My http.conf file grows every day and its getting big...
It's getting hard to find anyting without seartching in it.

My question is :

I like to move all virtualshosts away from httpd.conf in to a mysql server.
My doing that it would be muth easy to maintain my virtualhosts.

Have someone tried this without loosing  preformance?
 
 
   


Re: [VOTE] httpd-std.conf WAS: RE: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
Sander Striker wrote:

> Exactly, why should users that keep their config dir clean have to pay when
> some users don't want to be troubled with getting httpd-std.conf from elsewhere
> and need it installed at their fingertips?

Getting the defaults from elsewhere doesn't bother me if the dir has a decent
name.

> Secondly consider that you have installed 2.0.35 and are upgrading to 2.0.40.
> If ${sysconfdir}/[examples/]httpd-std.conf would be overwritten, you would have
> no chance to compare the old httpd-std.conf with the new httpd-std.conf anymore.
> I consider that diff more usefull than the diff between httpd.conf and the new
> httpd-std.conf.

Agreed.  diff'ing the defaults would be simple if we always installed them
somewhere, then copied them to conf/ only when conf/ is created.

"johannes m. richter" wrote:
> 
> True. But this problem could be solved by appending the version number to
> the filename. httpd-std-2.0.36.conf and so on. So you'd get a nice
> collection of various standard conf files in your
> examples/templates/whatever directory.

Sorry, but the thought of an ever-growing collection of files doesn't seem very
nice to me.  You can rename them if you really want this.

Greg

[VOTE] httpd-std.conf WAS: RE: daedalus is running httpd-2.0.pre40

Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu88-250-182.nc.rr.com
> [mailto:trawick@rdu88-250-182.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 23 July 2002 19:30

[...]
> I'm curious about how other people feel about this, so I started a
> vote in STATUS.

    * httpd-std.conf and friends

      a) httpd-std.conf should be tailored by install (from src or
         binbuild) even if user has existing httpd.conf
         +1:   trawick, slive, gregames, ianh

In the build tree?  If yes, then sure.

      b) tailored httpd-std.conf should be copied by install to
         sysconfdir/examples
         +1:   trawick
         -0:   striker

Installing in ${sysconfdir} or a subdir thereof is in my opinion not
an option.  If users go through the effort of keeping their config
directory clean, we shouldn't clutter it when they reinstall/upgrade
apache.

      c) tailored httpd-std.conf should be installed to
         sysconfdir/examples or manualdir/exampleconf/
         +1:   slive

Having an example config in the manual seems like a decent idea.

      d) Installing a set of default config files when upgrading a server
         doesn't make ANY sense at all.
         +1:   rbb, striker
           ianh - medium/big sites don't use 'standard config' anyway, as it
                  usually needs major customizations

Exactly, why should users that keep their config dir clean have to pay when
some users don't want to be troubled with getting httpd-std.conf from elsewhere
and need it installed at their fingertips?

Secondly consider that you have installed 2.0.35 and are upgrading to 2.0.40.
If ${sysconfdir}/[examples/]httpd-std.conf would be overwritten, you would have
no chance to compare the old httpd-std.conf with the new httpd-std.conf anymore.
I consider that diff more usefull than the diff between httpd.conf and the new
httpd-std.conf.


Sander


Re: daedalus is running httpd-2.0.pre40

Posted by Jeff Trawick <tr...@attglobal.net>.
"Ryan Bloom" <rb...@covalent.net> writes:

> > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> > >                                           Nor do I want spurious
> -std
> > > files copying in there to confuse matters.
> > 
> > Some of us want the -std files though.  From time to time I (and
> 
> That is the difference between developers and users.  I want the -std
> files on my DEVELOPER machines, and I have tricks to get them.  I don't
> want them anywhere near my PRODUCTION machines, because they get in the
> way.

not a valid description of how I use -std files...

> > I don't think anybody would be in favor of not providing
> > httpd-std.conf; perhaps the issue is just where to put it when the
> > user does an install (from binbuild or from make install it should
> > work the same).
> 
> I would be in favor of never installing them on an upgrade.  They are
> useless on a production machine that already has a configuration.  They
> are meant as DEFAULT values to help people get up and running.

I'm curious about how other people feel about this, so I started a
vote in STATUS.  

IMHO they *are* useful on a production machine.  The vast majority of
the Apache conf files I see, mine or from other users, started with
the default configuration file and could benefit by occasional
comparison with the current default.

> Is there ANY other software package anywhere that actually re-installs
> the default configuration files on an upgrade?????

I'm not too worried about what the other software packages do, though
I have no problem thinking of other examples (RedHat, which likes to
clobber what you already have with their idea of what the file should
be; some of the OS/390 products, which have libraries of samples which
are updated to reflect current-best-practices when the product is
updated).

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: daedalus is running httpd-2.0.pre40

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
> 
> > Stop handwaving.  No-one is suggesting overwriting httpd.conf.
> 
> Re-read that paragraph.  In no place did I say we were.  I said we were
> re-installing the default config files on an upgrade

Sorry if I misunderstood you, but I took 'default config files' to
mean httpd.conf.  If that's not what you meant, as it obviously
wasn't, then my remarks don't apply.

I'm -0 on the -*.conf files going into /conf/, so I guess we're
in agreement on that, but I'm absolutely -1 on them not being
supplied *somewhere*.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

RE: daedalus is running httpd-2.0.pre40

Posted by Ryan Bloom <rb...@covalent.net>.
> > I would be in favor of never installing them on an upgrade.  They
are
> > useless on a production machine that already has a configuration.
They
> > are meant as DEFAULT values to help people get up and running.
> 
> And they also provide examples of how things are done.  When those
> things change on an upgrade -- such as adding the <IfModule> wrappers
--
> it makes excellent sense for them to be provided.

Okay, I keep asking for the REASON for installing these files.  I have
heard a couple:

1)  People want to be able to get back to the standard config files
after they have modified them.

	--  Cool.  Back up the files before you modify them.  Having us
re-install the -std.conf files on upgrades is not a solution to this
problem, because it means that you need to re-install to get the default
files.

2)  People want to be able to compare previous default config files with
new ones.

	--  Fine, but the solution being proposed doesn't allow for
this, because the default config file is over written by the upgrade
step.  The only solution to this is to add the version to the end of the
file, which means that we just keep on adding new files.  No thanks.

3)  People want to see examples of how we think the config should look.

	--  Fine, but that is an example, and belongs as a part of the
manual.  Don't install the -std.conf files in conf/ at all if the goal
is for them to be examples, put them in the manual directory.

If there is another goal, then lets here it, but right now, we are doing
something to solve a problem with an external shell script.  With all of
the input for why this would be a good thing, the solution we are
proposing doesn't ACTUALLY solve any of the problem being proposed.

> > Is there ANY other software package anywhere that actually
re-installs
> > the default configuration files on an upgrade?????
> 
> Stop handwaving.  No-one is suggesting overwriting httpd.conf.

Re-read that paragraph.  In no place did I say we were.  I said we were
re-installing the default config files on an upgrade, which means that
after I get my conf/ directory down to:   httpd.conf and mime.types,
after the upgrade, I now have those files plus httpd-std.conf.  And
httpd-std.conf DOESN'T have any bearing to my site, and it will always
be installed.  Sorry, that is bogus.

Ryan


Re: daedalus is running httpd-2.0.pre40

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
> 
> That is the difference between developers and users.  I want the -std
> files on my DEVELOPER machines, and I have tricks to get them.  I don't
> want them anywhere near my PRODUCTION machines, because they get in the
> way.

You are hardly a typical user.  You shouldn't think that what's
good for Ryan-as-user is automatically good for *-as-user.

> I would be in favor of never installing them on an upgrade.  They are
> useless on a production machine that already has a configuration.  They
> are meant as DEFAULT values to help people get up and running.

And they also provide examples of how things are done.  When those
things change on an upgrade -- such as adding the <IfModule> wrappers --
it makes excellent sense for them to be provided.

> Is there ANY other software package anywhere that actually re-installs
> the default configuration files on an upgrade?????

Stop handwaving.  No-one is suggesting overwriting httpd.conf.
And yes, *many* packages provide their defaults as part of an
upgrade.  Some even move the existing user config aside and
put the new one in place.  As an example, look for .rpmnew and
.rpmsave files on a RH/MDK/... machine.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

Re: daedalus is running httpd-2.0.pre40

Posted by Oden Eriksson <od...@kvikkjokk.net>.
On Tuesday 23 July 2002 18.58, Ryan Bloom wrote:
> > From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-

[snip]

> I would be in favor of never installing them on an upgrade.  They are
> useless on a production machine that already has a configuration.  They
> are meant as DEFAULT values to help people get up and running.

why not install these prepended dy..., eg "date" if all else fail?

-- 
Regards // Oden Eriksson
Deserve-IT Networks -> http://d-srv.com

RE: daedalus is running httpd-2.0.pre40

Posted by Ryan Bloom <rb...@covalent.net>.
> From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> >                                           Nor do I want spurious
-std
> > files copying in there to confuse matters.
> 
> Some of us want the -std files though.  From time to time I (and

That is the difference between developers and users.  I want the -std
files on my DEVELOPER machines, and I have tricks to get them.  I don't
want them anywhere near my PRODUCTION machines, because they get in the
way.

> potentially many other people who start with Apache's basic
> httpd.conf) compare httpd.conf and httpd-std.conf to see if I want to
> merge in some of the Apache changes.
> 
> I don't think anybody would be in favor of not providing
> httpd-std.conf; perhaps the issue is just where to put it when the
> user does an install (from binbuild or from make install it should
> work the same).

I would be in favor of never installing them on an upgrade.  They are
useless on a production machine that already has a configuration.  They
are meant as DEFAULT values to help people get up and running.

Is there ANY other software package anywhere that actually re-installs
the default configuration files on an upgrade?????

Ryan



Re: daedalus is running httpd-2.0.pre40

Posted by Jeff Trawick <tr...@attglobal.net>.
James Tait <JT...@wyrddreams.demon.co.uk> writes:

> FWIW... I, as a user, agree wholeheartedly with this approach.  If
> I've taken the time out to write web pages then I don't want them
> clobbered when I upgrade Apache.  In the same way, if I've taken the
> time out to configure Apache the way I want it, I don't want that
> configuration clobbered when I upgrade.

nothing is getting clobbered

>                                           Nor do I want spurious -std
> files copying in there to confuse matters.

Some of us want the -std files though.  From time to time I (and
potentially many other people who start with Apache's basic
httpd.conf) compare httpd.conf and httpd-std.conf to see if I want to
merge in some of the Apache changes.

I don't think anybody would be in favor of not providing
httpd-std.conf; perhaps the issue is just where to put it when the
user does an install (from binbuild or from make install it should
work the same).

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
James Tait wrote:

>  Why risk confusing people by adding more clutter to an already-working directory?

If you look at the earlier posts in this thread, you'll see that my main
objective in making this change was to fix a non-functional conf/ directory (no
mime.types).  I can't imagine who would be confused by that.  In addition, some
people like having current -std.conf files available.

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by James Tait <JT...@wyrddreams.demon.co.uk>.
FWIW... I, as a user, agree wholeheartedly with this approach.  If I've 
taken the time out to write web pages then I don't want them clobbered when 
I upgrade Apache.  In the same way, if I've taken the time out to configure 
Apache the way I want it, I don't want that configuration clobbered when I 
upgrade.  Nor do I want spurious -std files copying in there to confuse 
matters.

I like to think of it this way:  while I'm controlling a machine, I'll keep 
thorough documentation of its configuration.  When I leave and Joe Bloggs 
takes over and upgrades Apache, my documentation will have no record of 
httpd.conf-std and such-like.  Why risk confusing people by adding more 
clutter to an already-working directory?

Just my tuppence worth.


Ryan Bloom wrote:
> The conf/ directory is mine as a user.  An initial installation copies
> some default files around, because that is nice for us to do.
> Subsequent installations should leave the directory alone, because that
> directory is mine.  The same way we leave the cgi-bin, htdocs, and error
> directories alone.  The only thing an upgrade should do, is to touch
> binaries and manuals.  Everything else is owned by the user.


-- 
+------------------------------------+------------------------------------+
| James Tait                         | ICQ# 17834893                      |
| MUD programmer and Linux advocate  | http://www.wyrddreams.demon.co.uk/ |
+------------------------------------+------------------------------------+


________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________

Re: daedalus is running httpd-2.0.pre40

Posted by David Shane Holden <dp...@yahoo.com>.

Greg Ames wrote:
> 
> uhhh, that clobbers httpd.conf, and they'd tar and feather us for sure.  But if
> we leave out that piece, it's close to what's happening now:

I didn't mean overwrite it, I shoulda said 'copy if it doesn't exist'.  My bad.

> 
> . make a conf/ directory if it doesn't already exist 
> . if mime.types or magic don't already exist, copy them
> . always copy in *-std.conf (httpd-std.conf and ssl-std.conf for now) with

We don't need the -std or the template files... they're useless if you 
already have a configured and running server.

Shane



Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
"johannes m. richter" wrote:
> 
> >If you read this whole thread, you'll see that I'm not the only one who likes
> >having current -std.conf files available.  They worked this way for ages.  I
> >don't recall seeing any complaints about this behavior until yesterday.
> 
> why not copy them somewhere in the documentation directory? 

why not indeed?  I could live with that.

>    People seem to
> want their conf-directories to be really "clean" - which is can understand.
> But i also understand it might be useful to have a current default
> configuration file around. IMHO the documentation dir
> SERVERROOT/manual/conf/ perhaps?) would be a good place for this.

SERVERROOT/manual/conf-default/ ?  That might make it clearer that this is just
for the default configs.  Opinions?

> my 0.02?-cents.. :o)

You don't give yourself enough credit.  This idea is worth at least a beer IMO
:-)

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by "johannes m. richter" <jo...@gmx.net>.
>If you read this whole thread, you'll see that I'm not the only one who likes
>having current -std.conf files available.  They worked this way for ages.  I
>don't recall seeing any complaints about this behavior until yesterday.

why not copy them somewhere in the documentation directory? People seem to 
want their conf-directories to be really "clean" - which is can understand. 
But i also understand it might be useful to have a current default 
configuration file around. IMHO the documentation dir 
SERVERROOT/manual/conf/ perhaps?) would be a good place for this.

my 0.02€-cents.. :o)
Nice afternoon,
johannes

-- 
Anyone who cannot cope with mathematics is not fully human. At best he
is a tolerable subhuman who has learned to wear shoes, bathe, and not
make messes in the house.  -- Robert A. Heinlein, Time Enough for Love
- http://jgcl.at/ - new photos from summer camp 2002 in Moosen/Tirol


Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
Ryan Bloom wrote:

> > >   You are working around a problem in your script in the Apache
> > > upgrade step.
> >
> > no sir.  It would have been a piece of cake to change my perl script
> to
> > insure
> > that conf/ has enough stuff so the server can start.  But I couldn't
> take
> > the
> > easy way out with a clear conscience because other people are likely
> to
> > get
> > burned in a similar manner.
> 
> Come off it.  That is insane.  You have a broken script, fix it.  Nobody
> else will get burned this way, as proof, this is how 1.3 has worked for
> years, and there were never any complaints.  Anybody who has an existing
> configuration who wants to copy that config to a new server MUST copy
> all of the config files.  You script didn't.  That is broken.  Period,
> end of story.

Let's check the proof:

[gregames@gandalf apache]$ grep "CONFIG" apache-1.3/Makefile
                        echo "[PRESERVING EXISTING CONFIG FILE:
$(root)$(sysconfdir)/$${target_conf}]"; \
                        echo "[PRESERVING EXISTING CONFIG FILE:
$(root)$(sysconfdir)/$${conf}]"; \

Actually, 1.3's make install-config works on a file-by-file basis, essentially
the same as HEAD for 2.0.

I certainly would never claim that 1.3 is perfect.  But it's a pretty decent
starting point, especially when it comes to externally visible behavior.

Greg

RE: daedalus is running httpd-2.0.pre40

Posted by Ryan Bloom <rb...@covalent.net>.
> From: gregames [mailto:gregames] On Behalf Of Greg Ames
> Ryan Bloom wrote:
> 
> >   You are working around a problem in your script in the Apache
> > upgrade step.
> 
> no sir.  It would have been a piece of cake to change my perl script
to
> insure
> that conf/ has enough stuff so the server can start.  But I couldn't
take
> the
> easy way out with a clear conscience because other people are likely
to
> get
> burned in a similar manner.

Come off it.  That is insane.  You have a broken script, fix it.  Nobody
else will get burned this way, as proof, this is how 1.3 has worked for
years, and there were never any complaints.  Anybody who has an existing
configuration who wants to copy that config to a new server MUST copy
all of the config files.  You script didn't.  That is broken.  Period,
end of story.

> >  Now, on EVERY production machine I have, I will always have
> > *-std.conf files.
> 
> Another way to word this is that whenever you do a make install your
> standard
> configuration files are updated to match the current code.

Why would I possibly want that?  The -std files have no relationship to
my server.  None.  I may have started with them years ago, but my
current config doesn't look anything like them.

> >  Why is that a good thing?????
> 
> Most of the time I use daedalus's config files or something that
closely
> resembles them.  Those are complex, but don't include every possible
> combination
> of config directives (thank goodness).  Every once in a while I need
to
> drop
> back to a simpler config to do benchmarking, or something with new
config

If you are doing benchmarking on deadalus, then we have issues.  Since
we are talking about your automation scripts on daedalus that is the
only thing you could mean, right?

> features to work on a problem for instance.  It's nice to be able to
grab
> one of
> the -std.conf files, make minimal/no changes, and have a working
server
> with
> guaranteed current config directives in short order.

Fine, so grab one, but DON'T put it in MY production conf/ directory
please.  I don't care where you keep a copy of those files, but they
don't belong in my product conf/ directory.

> If you read this whole thread, you'll see that I'm not the only one
who
> likes
> having current -std.conf files available.  They worked this way for
ages.
> I
> don't recall seeing any complaints about this behavior until
yesterday.

I don't care how many people like it, it is wrong (besides, if that
argument help any water at all, I could point how that in the last few
days, there have been at least three users disagreeing with the current
code).  It has only worked this way since 2.0, and we didn't spend a
whole lot of time on the install phases until recently.  As for
complaints.  If there hadn't been at least one (mine!), I wouldn't have
changed the install-conf target to match 1.3 weeks ago.

Ryan


Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
Ryan Bloom wrote:

>   You are working around a problem in your script in the Apache
> upgrade step.  

no sir.  It would have been a piece of cake to change my perl script to insure
that conf/ has enough stuff so the server can start.  But I couldn't take the
easy way out with a clear conscience because other people are likely to get
burned in a similar manner.  

>  Now, on EVERY production machine I have, I will always have
> *-std.conf files.  

Another way to word this is that whenever you do a make install your standard
configuration files are updated to match the current code.

>  Why is that a good thing?????  

Most of the time I use daedalus's config files or something that closely
resembles them.  Those are complex, but don't include every possible combination
of config directives (thank goodness).  Every once in a while I need to drop
back to a simpler config to do benchmarking, or something with new config
features to work on a problem for instance.  It's nice to be able to grab one of
the -std.conf files, make minimal/no changes, and have a working server with
guaranteed current config directives in short order.

If you read this whole thread, you'll see that I'm not the only one who likes
having current -std.conf files available.  They worked this way for ages.  I
don't recall seeing any complaints about this behavior until yesterday.

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ryan Bloom wrote:
> 
> Why is that a good thing?????

Because it's consistent with how it works on ten million
existing servers? :-)
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"

RE: daedalus is running httpd-2.0.pre40

Posted by Ryan Bloom <rb...@covalent.net>.
> From: gregames [mailto:gregames] On Behalf Of Greg Ames
> 
> David Shane Holden wrote:
> 
> > I agree with Ryan wholeheartedly here.
> >
> > Here's an idea...
> > If conf/ exist, copy httpd.conf, magic, and mime.types (These are
basic
> > files that all conf/ should have, right?).  If conf/ does not exist,
> copy
> > everything.
> 
> uhhh, that clobbers httpd.conf, and they'd tar and feather us for
sure.
> But if
> we leave out that piece, it's close to what's happening now:
> 
> . make a conf/ directory if it doesn't already exist
> . if mime.types or magic don't already exist, copy them
> . always copy in *-std.conf (httpd-std.conf and ssl-std.conf for now)
with
> appropriate substitutions for paths and modules etc learned during
> ./configure
> . look for files whose names match the *-std.conf files copied above
with
> the
> "-std" piece of the name removed (i.e., httpd.conf and ssl.conf).  If
they
> don't
> exist, copy them from the corresponding *-std.conf files.

Yep, that is the current algorithm, and it doesn't make any sense at
all.  You are working around a problem in your script in the Apache
upgrade step.  Once the first installation is done, the conf/ directory
doesn't belong to us anymore.  If the directory exists, then leave it
alone.  Now, on EVERY production machine I have, I will always have
*-std.conf files.  Why is that a good thing?????  For people with a
working server, this change doesn't make sense.

Ryan



Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
David Shane Holden wrote:

> I agree with Ryan wholeheartedly here.
> 
> Here's an idea...
> If conf/ exist, copy httpd.conf, magic, and mime.types (These are basic
> files that all conf/ should have, right?).  If conf/ does not exist, copy
> everything.

uhhh, that clobbers httpd.conf, and they'd tar and feather us for sure.  But if
we leave out that piece, it's close to what's happening now:

. make a conf/ directory if it doesn't already exist 
. if mime.types or magic don't already exist, copy them
. always copy in *-std.conf (httpd-std.conf and ssl-std.conf for now) with
appropriate substitutions for paths and modules etc learned during ./configure
. look for files whose names match the *-std.conf files copied above with the
"-std" piece of the name removed (i.e., httpd.conf and ssl.conf).  If they don't
exist, copy them from the corresponding *-std.conf files.

That's it.

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by David Shane Holden <dp...@yahoo.com>.
Ryan Bloom wrote:
 >
 > I don't, but I am not going to argue anymore.  I will simply say that
 > the way things work now, I am going to have a bunch of useless files
 > sitting in the conf/ directory of all of my production machines, because
 > every time I upgrade Apache, I will get all of the files that I have
 > deleted before.
 >
 > The conf/ directory is mine as a user.  An initial installation copies
 > some default files around, because that is nice for us to do.
 > Subsequent installations should leave the directory alone, because that
 > directory is mine.  The same way we leave the cgi-bin, htdocs, and error
 > directories alone.  The only thing an upgrade should do, is to touch
 > binaries and manuals.  Everything else is owned by the user.
 >

I agree with Ryan wholeheartedly here.

Here's an idea...
If conf/ exist, copy httpd.conf, magic, and mime.types (These are basic 
files that all conf/ should have, right?).  If conf/ does not exist, copy 
everything.

Or...
If we must pollute conf/ have a configure tag such as '--preserve-conf' 
which prevents conf/ from being played with at all.

I'd like to see conf/ left alone period, just like Apache was doing a week 
or so ago, but that's just me.

Shane



RE: daedalus is running httpd-2.0.pre40

Posted by Sander Striker <st...@apache.org>.
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 22 July 2002 20:06

>>> The situation that you are trying to protect against is most likely
>>> not standard.  My question, is why isn't your automation just copying
>>> the whole conf/ directory?
>> 
>> Keep in mind that I'm like the proverbial canary in the coal mine.  If
>> the canary suddenly keels over when entering the mine, there's not much
>> point in lecturing it to get more exercise, eat healthier, etc.
>> 
>> I believe that the way make install in HEAD works with conf/ is
>> satisfactory.
> 
> I don't, but I am not going to argue anymore.  I will simply say that
> the way things work now, I am going to have a bunch of useless files
> sitting in the conf/ directory of all of my production machines, because
> every time I upgrade Apache, I will get all of the files that I have
> deleted before.
> 
> The conf/ directory is mine as a user.  An initial installation copies
> some default files around, because that is nice for us to do.
> Subsequent installations should leave the directory alone, because that
> directory is mine.  The same way we leave the cgi-bin, htdocs, and error
> directories alone.  The only thing an upgrade should do, is to touch
> binaries and manuals.  Everything else is owned by the user.

I can only agree to every single point here, with the exception that I
want to discuss this.
 
> Oh well.

No, let's not do this away with a simple 'Oh well', if conf/ exists
should be left alone.  I feel quite strongly about this.  What I could
live with is an extra make target (install-config?) which does what
HEAD currently does.
 
> Ryan

Sander

RE: daedalus is running httpd-2.0.pre40

Posted by Ryan Bloom <rb...@covalent.net>.
> > The situation that you are trying to protect against is most likely
not
> > standard.  My question, is why isn't your automation just copying
the
> > whole conf/ directory?
> 
> Keep in mind that I'm like the proverbial canary in the coal mine.  If
the
> canary suddenly keels over when entering the mine, there's not much
point
> in
> lecturing it to get more exercise, eat healthier, etc.
> 
> I believe that the way make install in HEAD works with conf/ is
> satisfactory.

I don't, but I am not going to argue anymore.  I will simply say that
the way things work now, I am going to have a bunch of useless files
sitting in the conf/ directory of all of my production machines, because
every time I upgrade Apache, I will get all of the files that I have
deleted before.

The conf/ directory is mine as a user.  An initial installation copies
some default files around, because that is nice for us to do.
Subsequent installations should leave the directory alone, because that
directory is mine.  The same way we leave the cgi-bin, htdocs, and error
directories alone.  The only thing an upgrade should do, is to touch
binaries and manuals.  Everything else is owned by the user.

Oh well.

Ryan



Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
rbb@apache.org wrote:

> > If we had a customized mime.types, I wouldn't want it to get clobbered.  I think
> > the old code would have done that.
> 
> The old code was blowing away everything in the directory on my
> machine.  

no, I don't think it was blowing away existing conf/httpd.conf, conf/ssl.conf,
etc., or any conf/* files with your own names.  My ThinkPad has files in its
conf/ install directory dating back to 2001.  But the old code was blowing away
mime.types and magic, which wasn't good.

>  BTW, the current logic is precisely what 1.3 does, which is why
> I added it.  If you have an existing conf/ directory, the assumption is
> that you have been using it to run Apache.

bad assumption.  It's safer to deal with the files on an individual basis.

> The situation that you are trying to protect against is most likely not
> standard.  My question, is why isn't your automation just copying the
> whole conf/ directory?

Keep in mind that I'm like the proverbial canary in the coal mine.  If the
canary suddenly keels over when entering the mine, there's not much point in
lecturing it to get more exercise, eat healthier, etc.

I believe that the way make install in HEAD works with conf/ is satisfactory.

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by rb...@apache.org.
> I guess I wasn't clear.  I have automation that creates a new conf/, then copies
> in httpd.conf* from the production conf/ with appropriate edits.  So my conf/
> directory exists, but doesn't contain mime.types (or several other files which
> aren't relevant on daedalus).
> 
> make install runs after that.  It used to copy in everything except the
> httpd.conf file, which worked perfectly for me.  Now it doesn't copy *any* of
> the conf/* files because the directory exists.  It would be better if we did
> this on a more granular level, i.e. check to see if the individual file exists
> in the target dir, then copy/don't copy as appropriate.
> 
> If we had a customized mime.types, I wouldn't want it to get clobbered.  I think
> the old code would have done that.  

The old code was blowing away everything in the directory on my
machine.  BTW, the current logic is precisely what 1.3 does, which is why
I added it.  If you have an existing conf/ directory, the assumption is
that you have been using it to run Apache.

The situation that you are trying to protect against is most likely not
standard.  My question, is why isn't your automation just copying the
whole conf/ directory?

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------


Re: daedalus is running httpd-2.0.pre40

Posted by Greg Ames <gr...@apache.org>.
"William A. Rowe, Jr." wrote:
> 
> At 08:33 PM 7/17/2002, Greg Ames wrote:
> >...since Wednesday, 17-Jul-2002 18:49:31 PDT .  Things look fine now, but we
> >took about a 3 1/2 minute site outage because of:
> >
> >[Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not
> >open mime types config file /usr/local/apache/conf/mime.types.
> >Configuration Failed
> >
> >That's the feechur where we no longer copy existing conf/ directories at make
> >install time.  Remind me again:  what was wrong with simply not overlaying
> >existing files?
> 
> Because folks may have *valuable* and *important* config changes that
> shouldn't be wiped out?

I guess I wasn't clear.  I have automation that creates a new conf/, then copies
in httpd.conf* from the production conf/ with appropriate edits.  So my conf/
directory exists, but doesn't contain mime.types (or several other files which
aren't relevant on daedalus).

make install runs after that.  It used to copy in everything except the
httpd.conf file, which worked perfectly for me.  Now it doesn't copy *any* of
the conf/* files because the directory exists.  It would be better if we did
this on a more granular level, i.e. check to see if the individual file exists
in the target dir, then copy/don't copy as appropriate.

If we had a customized mime.types, I wouldn't want it to get clobbered.  I think
the old code would have done that.  

Greg

Re: daedalus is running httpd-2.0.pre40

Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:

> At 08:33 PM 7/17/2002, Greg Ames wrote:
> >...since Wednesday, 17-Jul-2002 18:49:31 PDT .  Things look fine now, but we
> >took about a 3 1/2 minute site outage because of:
> >
> >[Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not
> >open mime types config file /usr/local/apache/conf/mime.types.
> >Configuration Failed
> >
> >That's the feechur where we no longer copy existing conf/ directories at make
> >install time.  Remind me again:  what was wrong with simply not overlaying
> >existing files?
> 
> Because folks may have *valuable* and *important* config changes that
> shouldn't be wiped out?
> 
> That doesn't mean we couldn't overlay none the less... and save their
> existing files in .bak.# files.

Previously, foo-std.conf would always be copied but foo.conf wouldn't
be overlaid.  That was a nice feature.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: daedalus is running httpd-2.0.pre40

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:33 PM 7/17/2002, Greg Ames wrote:
>...since Wednesday, 17-Jul-2002 18:49:31 PDT .  Things look fine now, but we
>took about a 3 1/2 minute site outage because of:
>
>[Wed Jul 17 18:47:20 2002] [error] (2)No such file or directory: could not
>open mime types config file /usr/local/apache/conf/mime.types.
>Configuration Failed
>
>That's the feechur where we no longer copy existing conf/ directories at make
>install time.  Remind me again:  what was wrong with simply not overlaying
>existing files?

Because folks may have *valuable* and *important* config changes that
shouldn't be wiped out?

That doesn't mean we couldn't overlay none the less... and save their
existing files in .bak.# files.

Bill