You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by André Malo <nd...@perlig.de> on 2004/09/14 08:14:02 UTC
Shorten the default config and the distribution (was: IfModule in
the Default Config)
* Paul Querna <ch...@force-elite.com> wrote:
> A couple months the IfModule block was modified so that it can use
> foo_module instead of the Source File name (ie foo.c).
>
> I believe that using the ${name}_module syntax is clearer than using the
> source file name. I would like to encourage using this newer syntax in
> the 2.2 Stable Cycle.
>
> Currently PHP users must use:
> <IfModule sapi_apache2.c>
> Using the Source File name seems completely non-intuitive to me.
>
> In 2.1 they can use:
> <IfModule php5_module>
> This seems more logical to me.
>
> I would like to change the default httpd.conf.in to use this syntax
> instead of the source file name.
>
> Anyone (+|-)1 for it?
I'm rather for removing the whole crap from the default config and simplifiy
as much as possible.
A >30 KB default config, which nobody outside this circle here
really understands, isn't helpful - especially for beginners.
In the same cycle we could remove the docs from the default distribution and
start distributing them officially as separate packages. (But we could
distribute a separate config snippet for the multilingual docs, which can
be included in the httpd.conf). The more translations we add, the less
applicable is it to include the whole doc tree.
nd
(Otherwise, I'm +1 for your suggestion ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was:
IfModule in the Default Config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:30 PM 9/14/2004, Joshua Slive wrote:
>On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
>>I'm trying to understand what other anomalies you mean between
>>Unix and Win32, they aren't that dis-similar.
>
>I was mainly refering to the big block of mpm-control directives near the top.
>
>But I like the suggestion of getting rid of almost all of that (besides some basic things like MaxClients) and not discriminating against non-unix mpms.
I'm actually thinking that httpd-mpm.conf would include -all- of
the performance characteristics and server resources (e.g. the
switchboard and other mechanical tools) for running the server.
Existing directives I'd suggest (beyond the big-per-mpm block :-)
include the following (and don't include enablesendfile/mmap etc
because those are filesystem dependant and can vary by <dir > block)
but only one-mpm-per-flavor of the .conf files...
52 #
53 # The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
54 #
55 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #<IfModule !mpm_winnt.c>
56 #<IfModule !mpm_netware.c>
57 striker 1.1 #LockFile @rel_logfiledir@/accept.lock
58 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #</IfModule>
59 #</IfModule>
60 striker 1.1
61 #
62 # ScoreBoardFile: File used to store internal server process information.
63 # If unspecified (the default), the scoreboard will be stored in an
64 # anonymous shared memory segment, and will be unavailable to third-party
65 # applications.
66 # If specified, ensure that no two invocations of Apache share the same
67 # scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL DISK.
68 #
69 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #<IfModule !mpm_netware.c>
70 #<IfModule !perchild.c>
71 striker 1.1 #ScoreBoardFile @rel_logfiledir@/apache_runtime_status
72 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #</IfModule>
73 #</IfModule>
74 striker 1.1
75
76 #
77 # PidFile: The file in which the server should record its process
78 # identification number when it starts.
79 #
80 <IfModule !mpm_netware.c>
81 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.1&r2=1.2>jerenkrantz 1.2 PidFile @rel_runtimedir@/httpd.pid
82 striker 1.1 </IfModule>
83
84 #
85 # Timeout: The number of seconds before receives and sends time out.
86 #
87 Timeout 300
88
89 #
90 # KeepAlive: Whether or not to allow persistent connections (more than
91 # one request per connection). Set to "Off" to deactivate.
92 #
93 KeepAlive On
94
95 #
96 # MaxKeepAliveRequests: The maximum number of requests to allow
97 # during a persistent connection. Set to 0 to allow an unlimited amount.
98 # We recommend you leave this number high, for maximum performance.
99 #
100 MaxKeepAliveRequests 100
101
102 #
103 striker 1.1 # KeepAliveTimeout: Number of seconds to wait for the next request from the
104 # same client on the same connection.
105 #
106 KeepAliveTimeout 15
107
108 ##
109 ## Server-Pool Size Regulation (MPM specific)
110 ##
111
112 # prefork MPM
113 # StartServers: number of server processes to start
114 # MinSpareServers: minimum number of server processes which are kept spare
115 # MaxSpareServers: maximum number of server processes which are kept spare
116 # MaxClients: maximum number of server processes allowed to start
117 # MaxRequestsPerChild: maximum number of requests a server process serves
118 <IfModule prefork.c>
119 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 5
120 MinSpareServers 5
121 MaxSpareServers 10
122 MaxClients 150
123 MaxRequestsPerChild 0
124 striker 1.1 </IfModule>
125
126 # worker MPM
127 # StartServers: initial number of server processes to start
128 # MaxClients: maximum number of simultaneous client connections
129 # MinSpareThreads: minimum number of worker threads which are kept spare
130 # MaxSpareThreads: maximum number of worker threads which are kept spare
131 # ThreadsPerChild: constant number of worker threads in each server process
132 # MaxRequestsPerChild: maximum number of requests a server process serves
133 <IfModule worker.c>
134 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 2
135 MaxClients 150
136 MinSpareThreads 25
137 MaxSpareThreads 75
138 ThreadsPerChild 25
139 MaxRequestsPerChild 0
140 striker 1.1 </IfModule>
141
142 # perchild MPM
143 # NumServers: constant number of server processes
144 # StartThreads: initial number of worker threads in each server process
145 # MinSpareThreads: minimum number of worker threads which are kept spare
146 # MaxSpareThreads: maximum number of worker threads which are kept spare
147 # MaxThreadsPerChild: maximum number of worker threads in each server process
148 # MaxRequestsPerChild: maximum number of connections per server process
149 <IfModule perchild.c>
150 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 NumServers 5
151 StartThreads 5
152 MinSpareThreads 5
153 MaxSpareThreads 10
154 MaxThreadsPerChild 20
155 MaxRequestsPerChild 0
156 striker 1.1 </IfModule>
157
158 # WinNT MPM
159 # ThreadsPerChild: constant number of worker threads in the server process
160 # MaxRequestsPerChild: maximum number of requests a server process serves
161 <IfModule mpm_winnt.c>
162 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 ThreadsPerChild 250
163 MaxRequestsPerChild 0
164 striker 1.1 </IfModule>
165
166 # BeOS MPM
167 # StartThreads: how many threads do we initially spawn?
168 # MaxClients: max number of threads we can have (1 thread == 1 client)
169 # MaxRequestsPerThread: maximum number of requests each thread will process
170 <IfModule beos.c>
171 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartThreads 10
172 MaxClients 50
173 MaxRequestsPerThread 10000
174 </IfModule>
175 striker 1.1
176 # NetWare MPM
177 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.6&r2=1.7>slive 1.7 # ThreadStackSize: Stack size allocated for each worker thread
178 # StartThreads: Number of worker threads launched at server startup
179 # MinSpareThreads: Minimum number of idle threads, to handle request spikes
180 # MaxSpareThreads: Maximum number of idle threads
181 # MaxThreads: Maximum number of worker threads alive at the same time
182 # MaxRequestsPerChild: Maximum number of requests a thread serves. It is
183 # recommended that the default value of 0 be set for this
184 # directive on NetWare. This will allow the thread to
185 # continue to service requests indefinitely.
186 striker 1.1 <IfModule mpm_netware.c>
187 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 ThreadStackSize 65536
188 StartThreads 250
189 MinSpareThreads 25
190 MaxSpareThreads 250
191 MaxThreads 1000
192 MaxRequestsPerChild 0
193 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.56&r2=1.57>bnicholes 1.57 MaxMemFree 100
194 striker 1.1 </IfModule>
195
196 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 # OS/2 MPM
197 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.6&r2=1.7>slive 1.7 # StartServers: Number of server processes to maintain
198 # MinSpareThreads: Minimum number of idle threads per process,
199 # to handle request spikes
200 # MaxSpareThreads: Maximum number of idle threads per process
201 # MaxRequestsPerChild: Maximum number of connections per server process
202 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 <IfModule mpmt_os2.c>
203 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 2
204 MinSpareThreads 5
205 MaxSpareThreads 10
206 MaxRequestsPerChild 0
207 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 </IfModule>
Re: Shorten the default config and the distribution (was:
IfModule in the Default Config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:30 PM 9/14/2004, Joshua Slive wrote:
>On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
>>I'm trying to understand what other anomalies you mean between
>>Unix and Win32, they aren't that dis-similar.
>
>I was mainly refering to the big block of mpm-control directives near the top.
>
>But I like the suggestion of getting rid of almost all of that (besides some basic things like MaxClients) and not discriminating against non-unix mpms.
I'm actually thinking that httpd-mpm.conf would include -all- of
the performance characteristics and server resources (e.g. the
switchboard and other mechanical tools) for running the server.
Existing directives I'd suggest (beyond the big-per-mpm block :-)
include the following (and don't include enablesendfile/mmap etc
because those are filesystem dependant and can vary by <dir > block)
but only one-mpm-per-flavor of the .conf files...
52 #
53 # The accept serialization lock file MUST BE STORED ON A LOCAL DISK.
54 #
55 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #<IfModule !mpm_winnt.c>
56 #<IfModule !mpm_netware.c>
57 striker 1.1 #LockFile @rel_logfiledir@/accept.lock
58 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #</IfModule>
59 #</IfModule>
60 striker 1.1
61 #
62 # ScoreBoardFile: File used to store internal server process information.
63 # If unspecified (the default), the scoreboard will be stored in an
64 # anonymous shared memory segment, and will be unavailable to third-party
65 # applications.
66 # If specified, ensure that no two invocations of Apache share the same
67 # scoreboard file. The scoreboard file MUST BE STORED ON A LOCAL DISK.
68 #
69 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #<IfModule !mpm_netware.c>
70 #<IfModule !perchild.c>
71 striker 1.1 #ScoreBoardFile @rel_logfiledir@/apache_runtime_status
72 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.44&r2=1.45>fielding 1.45 #</IfModule>
73 #</IfModule>
74 striker 1.1
75
76 #
77 # PidFile: The file in which the server should record its process
78 # identification number when it starts.
79 #
80 <IfModule !mpm_netware.c>
81 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.1&r2=1.2>jerenkrantz 1.2 PidFile @rel_runtimedir@/httpd.pid
82 striker 1.1 </IfModule>
83
84 #
85 # Timeout: The number of seconds before receives and sends time out.
86 #
87 Timeout 300
88
89 #
90 # KeepAlive: Whether or not to allow persistent connections (more than
91 # one request per connection). Set to "Off" to deactivate.
92 #
93 KeepAlive On
94
95 #
96 # MaxKeepAliveRequests: The maximum number of requests to allow
97 # during a persistent connection. Set to 0 to allow an unlimited amount.
98 # We recommend you leave this number high, for maximum performance.
99 #
100 MaxKeepAliveRequests 100
101
102 #
103 striker 1.1 # KeepAliveTimeout: Number of seconds to wait for the next request from the
104 # same client on the same connection.
105 #
106 KeepAliveTimeout 15
107
108 ##
109 ## Server-Pool Size Regulation (MPM specific)
110 ##
111
112 # prefork MPM
113 # StartServers: number of server processes to start
114 # MinSpareServers: minimum number of server processes which are kept spare
115 # MaxSpareServers: maximum number of server processes which are kept spare
116 # MaxClients: maximum number of server processes allowed to start
117 # MaxRequestsPerChild: maximum number of requests a server process serves
118 <IfModule prefork.c>
119 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 5
120 MinSpareServers 5
121 MaxSpareServers 10
122 MaxClients 150
123 MaxRequestsPerChild 0
124 striker 1.1 </IfModule>
125
126 # worker MPM
127 # StartServers: initial number of server processes to start
128 # MaxClients: maximum number of simultaneous client connections
129 # MinSpareThreads: minimum number of worker threads which are kept spare
130 # MaxSpareThreads: maximum number of worker threads which are kept spare
131 # ThreadsPerChild: constant number of worker threads in each server process
132 # MaxRequestsPerChild: maximum number of requests a server process serves
133 <IfModule worker.c>
134 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 2
135 MaxClients 150
136 MinSpareThreads 25
137 MaxSpareThreads 75
138 ThreadsPerChild 25
139 MaxRequestsPerChild 0
140 striker 1.1 </IfModule>
141
142 # perchild MPM
143 # NumServers: constant number of server processes
144 # StartThreads: initial number of worker threads in each server process
145 # MinSpareThreads: minimum number of worker threads which are kept spare
146 # MaxSpareThreads: maximum number of worker threads which are kept spare
147 # MaxThreadsPerChild: maximum number of worker threads in each server process
148 # MaxRequestsPerChild: maximum number of connections per server process
149 <IfModule perchild.c>
150 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 NumServers 5
151 StartThreads 5
152 MinSpareThreads 5
153 MaxSpareThreads 10
154 MaxThreadsPerChild 20
155 MaxRequestsPerChild 0
156 striker 1.1 </IfModule>
157
158 # WinNT MPM
159 # ThreadsPerChild: constant number of worker threads in the server process
160 # MaxRequestsPerChild: maximum number of requests a server process serves
161 <IfModule mpm_winnt.c>
162 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 ThreadsPerChild 250
163 MaxRequestsPerChild 0
164 striker 1.1 </IfModule>
165
166 # BeOS MPM
167 # StartThreads: how many threads do we initially spawn?
168 # MaxClients: max number of threads we can have (1 thread == 1 client)
169 # MaxRequestsPerThread: maximum number of requests each thread will process
170 <IfModule beos.c>
171 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartThreads 10
172 MaxClients 50
173 MaxRequestsPerThread 10000
174 </IfModule>
175 striker 1.1
176 # NetWare MPM
177 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.6&r2=1.7>slive 1.7 # ThreadStackSize: Stack size allocated for each worker thread
178 # StartThreads: Number of worker threads launched at server startup
179 # MinSpareThreads: Minimum number of idle threads, to handle request spikes
180 # MaxSpareThreads: Maximum number of idle threads
181 # MaxThreads: Maximum number of worker threads alive at the same time
182 # MaxRequestsPerChild: Maximum number of requests a thread serves. It is
183 # recommended that the default value of 0 be set for this
184 # directive on NetWare. This will allow the thread to
185 # continue to service requests indefinitely.
186 striker 1.1 <IfModule mpm_netware.c>
187 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 ThreadStackSize 65536
188 StartThreads 250
189 MinSpareThreads 25
190 MaxSpareThreads 250
191 MaxThreads 1000
192 MaxRequestsPerChild 0
193 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.56&r2=1.57>bnicholes 1.57 MaxMemFree 100
194 striker 1.1 </IfModule>
195
196 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 # OS/2 MPM
197 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.6&r2=1.7>slive 1.7 # StartServers: Number of server processes to maintain
198 # MinSpareThreads: Minimum number of idle threads per process,
199 # to handle request spikes
200 # MaxSpareThreads: Maximum number of idle threads per process
201 # MaxRequestsPerChild: Maximum number of connections per server process
202 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 <IfModule mpmt_os2.c>
203 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.27&r2=1.28>wsanchez 1.28 StartServers 2
204 MinSpareThreads 5
205 MaxSpareThreads 10
206 MaxRequestsPerChild 0
207 <http://cvs.apache.org/viewcvs.cgi/httpd-docs-2.0/conf/httpd-std.conf.in?r1=1.3&r2=1.4>bjh 1.4 </IfModule>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
> I'm trying to understand what other anomalies you mean between
> Unix and Win32, they aren't that dis-similar.
I was mainly refering to the big block of mpm-control directives near the
top.
But I like the suggestion of getting rid of almost all of that (besides
some basic things like MaxClients) and not discriminating against non-unix
mpms.
> We have httpd-std.conf.in and ssl-std.conf.in, why not break
> some of these more lengthy 'passages' into their very own
> includes? First and foremost, httpd-intl.conf.in - this
> would take tons of lines across and leave a couple lines
Honestly, I prefer the one-config format, because I think it is easier for
the new user to find what is going on if they know everything is in one
file. But this is a situation where personal preferences will vary.
But I have a compromise suggestion (based on Manoj's idea). What about a
conf/examples/ directory that would contain a bunch of little files with
config snipets (like international.conf.in, proxy.conf.in,
vhosts.conf.in). Given the name of the directory, I would expect people
to either copy-paste the stuff in httpd.conf or move the file before
Include'ing it. I wouldn't provide commented-out Include directives for
these files.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
> I'm trying to understand what other anomalies you mean between
> Unix and Win32, they aren't that dis-similar.
I was mainly refering to the big block of mpm-control directives near the
top.
But I like the suggestion of getting rid of almost all of that (besides
some basic things like MaxClients) and not discriminating against non-unix
mpms.
> We have httpd-std.conf.in and ssl-std.conf.in, why not break
> some of these more lengthy 'passages' into their very own
> includes? First and foremost, httpd-intl.conf.in - this
> would take tons of lines across and leave a couple lines
Honestly, I prefer the one-config format, because I think it is easier for
the new user to find what is going on if they know everything is in one
file. But this is a situation where personal preferences will vary.
But I have a compromise suggestion (based on Manoj's idea). What about a
conf/examples/ directory that would contain a bunch of little files with
config snipets (like international.conf.in, proxy.conf.in,
vhosts.conf.in). Given the name of the directory, I would expect people
to either copy-paste the stuff in httpd.conf or move the file before
Include'ing it. I wouldn't provide commented-out Include directives for
these files.
Joshua.
Re: Shorten the default config and the distribution (was:
IfModule in the Default Config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:21 AM 9/14/2004, Joshua Slive wrote:
>On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
>>A >30 KB default config, which nobody outside this circle here
>>really understands, isn't helpful - especially for beginners.
>
>I agree that the current config file is too big and ugly. But let's be a little careful here. There needs to be a balance. Detailed config files do help users understand the capabilities of the server and make it much easier to activate features.
>
>So I suggest we talk about specifics, rather than just trying to reduce the size. For example:
>
>- Can we get rid of the non-unix mpm stuff from the default config. (Don't mean to offend os/2 and beos (and possibly netware), but they are really superfluous and confusing for most people.)
I'd vote -no-, with a caviat. In our main example.conf, they should
be shown side-by-side. E.g.
# Threaded Unix MPMs, e.g. Worker, require mod_cgid which forks
# it's own seperate process to dispatch the startup of cgi executables
#
<IfModule mpm_worker.c>
LoadModule mod_cgid.conf
</IfModule>
# Most non-threaded Unix MPMs, e.g. Prefork, and non-unix MPM's
# use mod_cgi, where the httpd server process spawns the cgi
# process itself.
#
<IfModule !mpm_worker.c>
LoadModule mod_cgi.conf
</IfModule>
... so any user trying to understand why they don't have mod_cgid
would run across this note and gasp "Ahhh! That's what cgid means!"
I'm trying to understand what other anomalies you mean between
Unix and Win32, they aren't that dis-similar.
Honestly - this could be improved;
<IfModule !mpm_netware.c>
<IfModule !perchild.c>
#ScoreBoardFile @rel_logfiledir@/apache_runtime_status
</IfModule>
</IfModule>
with some multiple-condition IfModule clause...
<IfModule !perchild.c && !mpm_netware.c>
#ScoreBoardFile @rel_logfiledir@/apache_runtime_status
</IfModule>
but that's neither here nor there. In this case, you have an
exceptional case for Netware and a specific Unix MPM. Are you
suggesting keep all the mpm exceptions for unix and ditch those
for the "Other" platforms? Bleh. But I have a productive
suggestion (I hope)...
>- Can we get rid of most of the AddLanguage/AddCharset directives? They are a constant source of bug reports, and I really can't imagine that many people use them as-is. (Do people really name their files index.html.utf32be.el?)
We have httpd-std.conf.in and ssl-std.conf.in, why not break
some of these more lengthy 'passages' into their very own
includes? First and foremost, httpd-intl.conf.in - this
would take tons of lines across and leave a couple lines
# Internationalization - Character Sets and Languages
#
# mod_mime and mod_negotiation can serve alternate content, based
# on the client's request headers and server content filenames.
# Uncomment this directive to serve multiple languages or character sets
# based on the filename extention.
#
#Include httpd-intl.conf
We could do this to proxy and many other "complex" modules. Best yet:
drop lines and lines of 'if this mpm we need that', and create
detailed and easy-to-read per-mpm subconfigs. That would offer
us httpd-prefork.conf, httpd-worker.conf etc etc. Only the
respective, installed mpm's conf would need to be present. All
such characteristics would move out to this file.
If that's too confusing, have these per-mpm subconfigs in the src,
but install only httpd-mpm.conf into every installation.
(Oh, for those who install all configs into /usr/etc or other common
conf locations, ssl-std.conf.in should really be installed as
httpd-ssl.conf to avoid ambiguity.)
But there is no reason to keep as many lines as we have in a single
config, multiple config files can be enormously helpful to the admin
to break apart these entirely separate aspects of configuration.
This would also reintroduce httpd-proxy.conf if someone wanted our
example (again) rather than one of many bad examples out there.
Bill
Re: Shorten the default config and the distribution (was:
IfModule in the Default Config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:21 AM 9/14/2004, Joshua Slive wrote:
>On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
>>A >30 KB default config, which nobody outside this circle here
>>really understands, isn't helpful - especially for beginners.
>
>I agree that the current config file is too big and ugly. But let's be a little careful here. There needs to be a balance. Detailed config files do help users understand the capabilities of the server and make it much easier to activate features.
>
>So I suggest we talk about specifics, rather than just trying to reduce the size. For example:
>
>- Can we get rid of the non-unix mpm stuff from the default config. (Don't mean to offend os/2 and beos (and possibly netware), but they are really superfluous and confusing for most people.)
I'd vote -no-, with a caviat. In our main example.conf, they should
be shown side-by-side. E.g.
# Threaded Unix MPMs, e.g. Worker, require mod_cgid which forks
# it's own seperate process to dispatch the startup of cgi executables
#
<IfModule mpm_worker.c>
LoadModule mod_cgid.conf
</IfModule>
# Most non-threaded Unix MPMs, e.g. Prefork, and non-unix MPM's
# use mod_cgi, where the httpd server process spawns the cgi
# process itself.
#
<IfModule !mpm_worker.c>
LoadModule mod_cgi.conf
</IfModule>
... so any user trying to understand why they don't have mod_cgid
would run across this note and gasp "Ahhh! That's what cgid means!"
I'm trying to understand what other anomalies you mean between
Unix and Win32, they aren't that dis-similar.
Honestly - this could be improved;
<IfModule !mpm_netware.c>
<IfModule !perchild.c>
#ScoreBoardFile @rel_logfiledir@/apache_runtime_status
</IfModule>
</IfModule>
with some multiple-condition IfModule clause...
<IfModule !perchild.c && !mpm_netware.c>
#ScoreBoardFile @rel_logfiledir@/apache_runtime_status
</IfModule>
but that's neither here nor there. In this case, you have an
exceptional case for Netware and a specific Unix MPM. Are you
suggesting keep all the mpm exceptions for unix and ditch those
for the "Other" platforms? Bleh. But I have a productive
suggestion (I hope)...
>- Can we get rid of most of the AddLanguage/AddCharset directives? They are a constant source of bug reports, and I really can't imagine that many people use them as-is. (Do people really name their files index.html.utf32be.el?)
We have httpd-std.conf.in and ssl-std.conf.in, why not break
some of these more lengthy 'passages' into their very own
includes? First and foremost, httpd-intl.conf.in - this
would take tons of lines across and leave a couple lines
# Internationalization - Character Sets and Languages
#
# mod_mime and mod_negotiation can serve alternate content, based
# on the client's request headers and server content filenames.
# Uncomment this directive to serve multiple languages or character sets
# based on the filename extention.
#
#Include httpd-intl.conf
We could do this to proxy and many other "complex" modules. Best yet:
drop lines and lines of 'if this mpm we need that', and create
detailed and easy-to-read per-mpm subconfigs. That would offer
us httpd-prefork.conf, httpd-worker.conf etc etc. Only the
respective, installed mpm's conf would need to be present. All
such characteristics would move out to this file.
If that's too confusing, have these per-mpm subconfigs in the src,
but install only httpd-mpm.conf into every installation.
(Oh, for those who install all configs into /usr/etc or other common
conf locations, ssl-std.conf.in should really be installed as
httpd-ssl.conf to avoid ambiguity.)
But there is no reason to keep as many lines as we have in a single
config, multiple config files can be enormously helpful to the admin
to break apart these entirely separate aspects of configuration.
This would also reintroduce httpd-proxy.conf if someone wanted our
example (again) rather than one of many bad examples out there.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, Manoj Kasichainula wrote:
> How about separating the "example" and "default" configs? Make the default
> config short, but provide an example config with all the meat that can be
> easily cut-and-pasted.
Or put richer examples in the docs. We have been working on that a
little. Some of the module docs now come with a nice example config at
the top which can be cut-pasted into httpd.conf (see
mod_dav/mod_cache/mod_proxy/mod_defalte for examples).
> For example, I think <IfModule> lines in a config file are usually a bad
> idea, since the webserver should complain loudly if a needed module isn't
> present, instead of just ignoring the situation.
I've always been a strong supporter of that argument. I frequently see
people on the users list who try a directive and find that it doesn't work
and they get no error message. If they removed the <IfModule> they would
get a nice message telling them why it didn't work.
But there are several people who have argued strongly that they want the
default config to work regardless of what modules people include in their
build.
> +1 to your proposal in the meantime (given my proposal above). I'd probably
> just get rid of all of the per-mpm stuff even. The mpms should have
> reasonable default values, so unless the admin needs to make a specific
> change, there should be no need for any of those directives in the default
> config.
+1!
If any changes in the defaults are necessary, then this would need to be
2.1 only. But I guess we are mostly talking about 2.1 in general anyway.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, Manoj Kasichainula wrote:
> How about separating the "example" and "default" configs? Make the default
> config short, but provide an example config with all the meat that can be
> easily cut-and-pasted.
Or put richer examples in the docs. We have been working on that a
little. Some of the module docs now come with a nice example config at
the top which can be cut-pasted into httpd.conf (see
mod_dav/mod_cache/mod_proxy/mod_defalte for examples).
> For example, I think <IfModule> lines in a config file are usually a bad
> idea, since the webserver should complain loudly if a needed module isn't
> present, instead of just ignoring the situation.
I've always been a strong supporter of that argument. I frequently see
people on the users list who try a directive and find that it doesn't work
and they get no error message. If they removed the <IfModule> they would
get a nice message telling them why it didn't work.
But there are several people who have argued strongly that they want the
default config to work regardless of what modules people include in their
build.
> +1 to your proposal in the meantime (given my proposal above). I'd probably
> just get rid of all of the per-mpm stuff even. The mpms should have
> reasonable default values, so unless the admin needs to make a specific
> change, there should be no need for any of those directives in the default
> config.
+1!
If any changes in the defaults are necessary, then this would need to be
2.1 only. But I guess we are mostly talking about 2.1 in general anyway.
Joshua.
Re: Shorten the default config and the distribution (was: IfModule in
the Default Config)
Posted by Manoj Kasichainula <ma...@io.com>.
On Tue, Sep 14, 2004 at 11:21:15AM -0400, Joshua Slive wrote:
>
>On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
>>A >30 KB default config, which nobody outside this circle here
>>really understands, isn't helpful - especially for beginners.
>
>I agree that the current config file is too big and ugly. But let's be a
>little careful here. There needs to be a balance. Detailed config files
>do help users understand the capabilities of the server and make it much
>easier to activate features.
How about separating the "example" and "default" configs? Make the
default config short, but provide an example config with all the meat
that can be easily cut-and-pasted.
For example, I think <IfModule> lines in a config file are usually a bad
idea, since the webserver should complain loudly if a needed module
isn't present, instead of just ignoring the situation. Because the
example config is serving as a sort of documentation for all these
modules, but yet still has to work on whatever the user happens to
build, it has to include those <IfModule>s, and it then encourages
people to use them in a bad way.
>- Can we get rid of the non-unix mpm stuff from the default config.
>(Don't mean to offend os/2 and beos (and possibly netware), but they
>are really superfluous and confusing for most people.)
+1 to your proposal in the meantime (given my proposal above). I'd
probably just get rid of all of the per-mpm stuff even. The mpms should
have reasonable default values, so unless the admin needs to make a
specific change, there should be no need for any of those directives in
the default config.
>- Can we get rid of most of the AddLanguage/AddCharset directives?
>They are a constant source of bug reports, and I really can't imagine
>that many people use them as-is. (Do people really name their files
>index.html.utf32be.el?)
+1
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
I agree that the current config file is too big and ugly. But let's be a
little careful here. There needs to be a balance. Detailed config files
do help users understand the capabilities of the server and make it much
easier to activate features.
So I suggest we talk about specifics, rather than just trying to reduce
the size. For example:
- Can we get rid of the non-unix mpm stuff from the default config.
(Don't mean to offend os/2 and beos (and possibly netware), but they are
really superfluous and confusing for most people.)
- Can we get rid of most of the AddLanguage/AddCharset directives? They
are a constant source of bug reports, and I really can't imagine that many
people use them as-is. (Do people really name their files
index.html.utf32be.el?)
The above two changes alone would get rid of almost 200 lines.
>
> In the same cycle we could remove the docs from the default distribution and
> start distributing them officially as separate packages. (But we could
> distribute a separate config snippet for the multilingual docs, which can
> be included in the httpd.conf). The more translations we add, the less
> applicable is it to include the whole doc tree.
+1
Joshua.
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 14 Sep 2004, [ISO-8859-15] Andr� Malo wrote:
> * Paul Querna <ch...@force-elite.com> wrote:
> (chop)
> > Using the Source File name seems completely non-intuitive to me.
Agreed.
> I'm rather for removing the whole crap from the default config and simplifiy
> as much as possible.
I'd be cautious about that. The default httpd.conf contains a fair chunk
of documentation that isn't available elsewhere. We need to work
carefully on making sure this isn't lost.
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
I disagree.
Think about a situation where you're on the learningcurve for working with
a big package. A big and well-commented config file is the most useful
thing available. I'm thinking of compiling kernels, and contrasting Linux
(where "make menuconfig" is very nice but hides what's really happening)
with FreeBSD, where keeping the "LINT" config open in another window
while editing my config is the absolute best documentation I could wish.
If the default is shortened, we should package a long and highly-commented
file in the manner of LINT. It would be nice also to integrate the
documentation in httpd.conf into the main docs as and when round tuits
can be sourced.
> In the same cycle we could remove the docs from the default distribution and
> start distributing them officially as separate packages. (But we could
> distribute a separate config snippet for the multilingual docs, which can
> be included in the httpd.conf). The more translations we add, the less
> applicable is it to include the whole doc tree.
Hmmm, does that risk generating a higher volume of dumb-newbie questions
in all the public fora? And perhaps also "apache-is-hard" articles in
the press?
--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution
Posted by Greg Ames <gr...@remulak.net>.
Paul Querna wrote:
> On Tue, 2004-09-14 at 08:14 +0200, André Malo wrote:
>
>>I'm rather for removing the whole crap from the default config and simplifiy
>>as much as possible.
>>
>>A >30 KB default config, which nobody outside this circle here
>>really understands, isn't helpful - especially for beginners.
>
>
> +1
+1. I don't think it's appropriate to use the default config file for a manual
or to advertise features.
Greg
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Paul Querna <ch...@force-elite.com>.
On Tue, 2004-09-14 at 08:14 +0200, André Malo wrote:
> I'm rather for removing the whole crap from the default config and simplifiy
> as much as possible.
>
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
+1
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Joshua Slive <jo...@slive.ca>.
On Tue, 14 Sep 2004, [ISO-8859-15] Andr� Malo wrote:
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
I agree that the current config file is too big and ugly. But let's be a
little careful here. There needs to be a balance. Detailed config files
do help users understand the capabilities of the server and make it much
easier to activate features.
So I suggest we talk about specifics, rather than just trying to reduce
the size. For example:
- Can we get rid of the non-unix mpm stuff from the default config.
(Don't mean to offend os/2 and beos (and possibly netware), but they are
really superfluous and confusing for most people.)
- Can we get rid of most of the AddLanguage/AddCharset directives? They
are a constant source of bug reports, and I really can't imagine that many
people use them as-is. (Do people really name their files
index.html.utf32be.el?)
The above two changes alone would get rid of almost 200 lines.
>
> In the same cycle we could remove the docs from the default distribution and
> start distributing them officially as separate packages. (But we could
> distribute a separate config snippet for the multilingual docs, which can
> be included in the httpd.conf). The more translations we add, the less
> applicable is it to include the whole doc tree.
+1
Joshua.
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Paul Querna <ch...@force-elite.com>.
On Tue, 2004-09-14 at 08:14 +0200, André Malo wrote:
> I'm rather for removing the whole crap from the default config and simplifiy
> as much as possible.
>
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Shorten the default config and the distribution (was: IfModule
in the Default Config)
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 14 Sep 2004, [ISO-8859-15] Andr� Malo wrote:
> * Paul Querna <ch...@force-elite.com> wrote:
> (chop)
> > Using the Source File name seems completely non-intuitive to me.
Agreed.
> I'm rather for removing the whole crap from the default config and simplifiy
> as much as possible.
I'd be cautious about that. The default httpd.conf contains a fair chunk
of documentation that isn't available elsewhere. We need to work
carefully on making sure this isn't lost.
> A >30 KB default config, which nobody outside this circle here
> really understands, isn't helpful - especially for beginners.
I disagree.
Think about a situation where you're on the learningcurve for working with
a big package. A big and well-commented config file is the most useful
thing available. I'm thinking of compiling kernels, and contrasting Linux
(where "make menuconfig" is very nice but hides what's really happening)
with FreeBSD, where keeping the "LINT" config open in another window
while editing my config is the absolute best documentation I could wish.
If the default is shortened, we should package a long and highly-commented
file in the manner of LINT. It would be nice also to integrate the
documentation in httpd.conf into the main docs as and when round tuits
can be sourced.
> In the same cycle we could remove the docs from the default distribution and
> start distributing them officially as separate packages. (But we could
> distribute a separate config snippet for the multilingual docs, which can
> be included in the httpd.conf). The more translations we add, the less
> applicable is it to include the whole doc tree.
Hmmm, does that risk generating a higher volume of dumb-newbie questions
in all the public fora? And perhaps also "apache-is-hard" articles in
the press?
--
Nick Kew