Re: simple-conf branch

2005-04-05 Thread Justin Erenkrantz
On Mon, Apr 04, 2005 at 03:01:34PM -0700, Greg Stein wrote:
 Sorry, but I very much disagree. I think back to the old days of
 access.conf, httpd.conf, and srm.conf. As an administrator, I absolutely
 detested that layout. I could NEVER figure out which file a given
 configuration was in. I always had to search, then edit.
 
Some of us have never left that world.  Darnit.

 We've been to the multiple .conf world before. It sucked. We pulled
 everything back into a single .conf to get the hell outta there.

Agreed.

 Small examples are fine. The default configuration should remain as a
 single .conf file.

+1.  -- justin


Re: simple-conf branch

2005-04-05 Thread Paul A. Houle
On Mon, 4 Apr 2005 15:01:34 -0700, Greg Stein [EMAIL PROTECTED] wrote:

Sorry, but I very much disagree. I think back to the old days of
access.conf, httpd.conf, and srm.conf. As an administrator, I absolutely
detested that layout. I could NEVER figure out which file a given
configuration was in. I always had to search, then edit.
We've been to the multiple .conf world before. It sucked. We pulled
everything back into a single .conf to get the hell outta there.
Small examples are fine. The default configuration should remain as a
single .conf file.
	After a few years of running moderate-sized virtual hosting servers
(2 to a few hundred) I've settled in on a multiple-file organization for  
virtual hosts.

	I use the usual httpd.conf for server-wide settings,  but that includes  
vhost.conf which contains a bunch of virtual host containers that then  
include configuration files for the various virtual hosts.  These days I  
tend to create a set of directories,  like

/www/sites/vhost-1.com
which then have logs,  htdocs,  and other supporting directories.  What's  
nice about this is that vhosts are easily portable from one server to  
another.  I've got a script that automatically punches in a new vhost,  so  
I can have one up and running in two minutes.

	My big project these is a site with a database that's still useful in  
read-only mode when the database goes down;  it's got mirror sites and all  
kinds of funny details,  and we have a runlevel.conf symlink that points  
to one of several files that let us adapt the system to various degraded  
states such as database maintainance,  software upgrade,  etc.

	That same site also has several test instances,  and we have a single  
configuration file that has all the variables that change between  
different instances,  so it's easy to maintain the conf files in CVS.

	There are good operational reasons to split up configuration in different  
files -- if the Apache install can encourage good practices,  based on the  
decade of experience we've had with it,  that's a good thing.


Re: [1.3 PATCH] Win32 RewriteLog deadlock

2005-04-05 Thread Jeff Trawick
On Apr 2, 2005 2:54 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
 At 05:45 AM 4/2/2005, Jeff Trawick wrote:
 On Apr 1, 2005 2:17 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
  At 09:16 AM 4/1/2005, Eric Covener wrote:
 
  Attempt at a patch using CriticalSection instead of _locking() is
  attached, but I am by no means a win32 person -- hopefully someone can
  take a look.
 
  However, it will break Windows 9x/ME so, for 1.3, we need at least
  some detection to decide if we use this solution.
 
 I don't have a Win9x box any more to test, but doc says this
 
 Requirements
 Client  Requires Windows XP, Windows 2000 Professional, Windows NT
 Workstation, Windows Me, Windows 98, or Windows 95.
 Server  Requires Windows Server 2003, Windows 2000 Server, or Windows NT 
 Server.
 
 Doh!!! TryEnterCriticalSection() is the NT specific API I was
 thinking about.  If this is a blocking EnterCriticalSection(),
 there is no Win32 version issue.

yep; I'll add the patch to STATUS...


Re: simple-conf branch

2005-04-05 Thread Jim Jagielski
Admittedly, there are times when having multiple conf files
and conf directories makes things much easier. Other
time, more difficult. But that is a SysAdmin decision.
We should keep with one-true config file for defaults.


Re: simple-conf branch

2005-04-05 Thread Greg Stein
On Tue, Apr 05, 2005 at 08:38:44AM -0400, Paul A. Houle wrote:
...
   There are good operational reasons to split up configuration in 
   different  files -- if the Apache install can encourage good practices, 
  
 based on the  decade of experience we've had with it,  that's a good thing.

You have a complex series of sites and a deep understanding of
configuration and sysadmin issues to keep it manageable. For somebody
*new* to this, they need the utmost simplicity. Even a strong sysadmin
needs something simple so they can figure out what they're working with
and then blend that into their environment.

If we shipped a setup similar to yours, most people would cry with
frustration trying to figure out where to turn this or that knob.

Documentation to help people with configuration issues and ideas can
easily be provided for admins who have moved past the single static file
website. We already have a lot of documentation. Admittedly, it doesn't
describe scenarios like yours, but I'll venture to guess that you're in
the few-percent case. I'm more than happy to have our doc folks
concentrating on the other 97% :-)

Cheers,
-g

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


Re: svn commit: r160209 - httpd/httpd/trunk/server/mpm/winnt/child.c

2005-04-05 Thread William A. Rowe, Jr.
How is this worthless?  IIUC, the unix mpm's announce the
creation of each worker.  This should remain consistant,
however if I'm mistaken, ignore me.

Bill

At 02:01 PM 4/5/2005, [EMAIL PROTECTED] wrote:
Author: stoddard
Date: Tue Apr  5 12:01:09 2005
New Revision: 160209

URL: http://svn.apache.org/viewcvs?view=revrev=160209
Log:
Win32: Eliminate useless debug error message

Modified:
httpd/httpd/trunk/server/mpm/winnt/child.c

Modified: httpd/httpd/trunk/server/mpm/winnt/child.c
URL: 
http://svn.apache.org/viewcvs/httpd/httpd/trunk/server/mpm/winnt/child.c?view=diffr1=160208r2=160209
==
--- httpd/httpd/trunk/server/mpm/winnt/child.c (original)
+++ httpd/httpd/trunk/server/mpm/winnt/child.c Tue Apr  5 12:01:09 2005
@@ -739,8 +739,6 @@
 int thread_num = (int)thread_num_val;
 ap_sb_handle_t *sbh;
 
-ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, ap_server_conf,
- Child %d: Worker thread %d starting., my_pid, thread_num);
 while (1) {
 conn_rec *c;
 apr_int32_t disconnected;
@@ -801,8 +799,6 @@
 ap_update_child_status_from_indexes(0, thread_num, SERVER_DEAD, 
 (request_rec *) NULL);
 
-ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, ap_server_conf,
- Child %d: Worker thread %d exiting., my_pid, thread_num);
 return 0;
 }
 



Re: svn commit: r160209 - httpd/httpd/trunk/server/mpm/winnt/child.c

2005-04-05 Thread Paul Querna
William A. Rowe, Jr. wrote:
How is this worthless?  IIUC, the unix mpm's announce the
creation of each worker.
Worker, Prefork and Event do not.



Re: simple-conf branch

2005-04-05 Thread Rich Bowen
Greg Stein wrote:
 On Tue, Apr 05, 2005 at 08:38:44AM -0400, Paul A. Houle wrote:
 
...
  There are good operational reasons to split up configuration in 
  different  files -- if the Apache install can encourage good practices, 
  
based on the  decade of experience we've had with it,  that's a good thing.
 
 
 You have a complex series of sites and a deep understanding of
 configuration and sysadmin issues to keep it manageable. For somebody
 *new* to this, they need the utmost simplicity. Even a strong sysadmin
 needs something simple so they can figure out what they're working with
 and then blend that into their environment.
 
 If we shipped a setup similar to yours, most people would cry with
 frustration trying to figure out where to turn this or that knob.

You mean, like when new users encounter a default Debian Apache
installation?
/me hides from the Debian users.

--Rich


Re: simple-conf branch

2005-04-05 Thread Dan Udey
What makes matters worse is that the update-apache2-script that apache2
comes with in Debian doesn't seem to work in any situation I've tried
it in (or maybe I'm just not using it right), rendering the entire
configuration confusing for no substantial reason.

That being said, the idea behind the Debian configuration makes things
like adding vhosts easy - put them in a file, drop them into
sites-enabled, and restart. Definitely easier than adding them to the
httpd.conf file by hand (and then having to re-order them when you want
one to be the default). One vhost (or set of relevant vhosts) per file,
and you can swap in/out at will.

Personally, I'm inclined to think this would be useful to new users.
It's easier for newbies to worry about one 10-line file at a time,
instead of a monolithic 1000-line file (for reference, my httpd.conf
from apache1 in Debian is now at 1091 lines, while my apache2.conf is
at 394), and for sysadmins, they don't have to worry about where which
directive is and whether or not there's an important LoadModule or
SetEnvIf somewhere between two unrelated vhosts.On Apr 5, 2005 4:16 PM, Rich Bowen [EMAIL PROTECTED] wrote:Greg Stein wrote: On Tue, Apr 05, 2005 at 08:38:44AM -0400, Paul A. Houle wrote:...There are good operational reasons to split up configuration indifferentfiles -- if the Apache install can encourage good practices,based on thedecade of experience we've had with it,that's a good thing. You have a complex series of sites and a deep understanding of configuration and sysadmin issues to keep it manageable. For somebody *new* to this, they need the utmost simplicity. Even a strong sysadmin needs something simple so they can figure out what they're working with and then blend that into their environment. If we shipped a setup similar to yours, most people would cry with frustration trying to figure out where to turn this or that knob.You mean, like when new users encounter a default Debian Apacheinstallation?/me hides from the Debian users.--Rich-- Dan Udey

[NOTICE] Tagging 2.0.54, WAS: Re: Time for 2.0.54?

2005-04-05 Thread Sander Striker
Sander Striker wrote:
Hi guys,
It's been almost 2 months since 2.0.53.  Think it is time for 2.0.54 yet?
I'll volunteer to RM if that is a yes ;)
Just a heads up: I'm planning on starting the TR of 2.0.54 on thursday 
night
(UTC +1).  I would be thankful if someone could start backporting the suggested
backports with enough votes in STATUS.  If noone has any round tuits, I'll
get to it before doing the tag.
Thanks,
Sander


Re: svn commit: r160209 - httpd/httpd/trunk/server/mpm/winnt/child.c

2005-04-05 Thread Bill Stoddard
Paul Querna wrote:
William A. Rowe, Jr. wrote:
How is this worthless?  IIUC, the unix mpm's announce the
creation of each worker.

Worker, Prefork and Event do not.
Correct. Only Windows logs a debug message for each and every thread created. I added these two debug messages 
to winnt_mpm a couple of years back to help track down what appeared to be a shutdown bug. Problem actually 
was that thread creation at startup was failing due to the huge 1MB default stack size on windows; we now log 
thread creation failure and do our active thread accounting properly; these two debug messages unnecessarily 
clutter up the error log and we can live w/o them imho.

Bill



Re: svn commit: r160240 - httpd/httpd/branches/2.0.x/STATUS

2005-04-05 Thread Jeff Trawick
On Apr 5, 2005 7:31 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: jim
 Date: Tue Apr  5 16:31:30 2005
 New Revision: 160240
 
 URL: http://svn.apache.org/viewcvs?view=revrev=160240
 Log:
 Tested and voted
 
 Modified: httpd/httpd/branches/2.0.x/STATUS
  *) several changes to improve logging of connection-oriented errors, 
 including
 ap_log_cerror() API (needs minor bump in addition to changes below)
 @@ -178,7 +178,7 @@
been committed to trunk.  The equivalent patch for 2.0.x is at:
   http://www.apache.org/~trawick/20reqbody.txt
 
 -  +1: trawick, jerenkrantz
 +  +1: trawick, jerenkrantz, +1

I assume that second +1 should instead be jim ;)