Will you share your changes (diff) with us?
Regards,
Basant.
On Wed, Aug 08, 2007 at 04:48:36PM +0530, Seema Alevoor wrote:
> Hi,
>
> I tried prototyping this layout structure with multiple MPMs using sfw build
> environment.
> I modified sfw build scripts to build and install prefork, worker
Another point which I forgot to mention.
With the current layout (existing one), trying to create a sample module failed
with the following error.
-
% apxs -n foo -g
% cd foo
% make all reload
make: Warning: Can't find `/usr/
> 1. I was wondering, for simplicity sake, should we not compile the
> apache httpd in the same way for both MPM models. This would allow us to
> use same configure script and change only line '--with-mpm' depending on
> which model we build. This way, going forward, if we need to add another
As far as I poked around the source, these header files are not
actively used by any modules. So, it is okay , in my opinion, to simply
leave with the default MPM model.
thanks
sriram
Seema Alevoor wrote:
>> 1. I was wondering, for simplicity sake, should we not compile the
>> apache httpd i
The convention seems to be that build directory is found in the same
place / level where apache modules are kept. So, if we are going to
keep the modules under /usr/apache2/modules then the corresponding build
directory also needs to reside under /usr/apache2/build.
thanks
sriram
Seema Alevo
Seema
1. I was wondering, for simplicity sake, should we not compile the
apache httpd in the same way for both MPM models. This would allow us to
use same configure script and change only line '--with-mpm' depending on
which model we build. This way, going forward, if we need to add another
MP
>> I tried prototyping this layout structure with multiple MPMs using sfw
>> build environment.
>> I modified sfw build scripts to build and install prefork, worker mpm
>> binaries under usr/apache2/bin directory.
>
> Perhaps this is covered in another email but how does the administrator
> sele
What are the advantages/disadvantages of including *.conf e.g
Include /etc/apache2/extra/*.conf
compare to including separate conf files e.g
Include /etc/apache2/extra/ssl.conf
Include /etc/apache2/extra/dav.conf
In the later case, users can comment/uncomment lines in httpd.conf to
enable/disable
David.Comay at sun.com wrote:
>> I was hoping we will use 'conf.d' as a wrapper directory for all task
>> specific configurations underneath and totally not need a directory like
>> 'extra'. I thought, the name 'extra' sounds yucky
>>
>
> However, "extra" is the name currently used by the e
It is definitely a very cool and easily manageable thing. But please
note that every vendor who redistributes Apache has done it slightly in
his own way. So, my humble request would be to thoroughly think this
through with an administrative view of point without breaking the
convention.
thanks
> In addition to my earlier comments, it doesn't seem that this proposal
> allows for multiple versions of Apache 2 to be present on the system.
> I thought at one time someone had said this was something we might
> want/have to do in the future. Is this a goal or are we fairly certain
> that only
David.Comay at sun.com wrote:
>> The initial proposal mentioned about a new directory, "conf.d" under
>> /etc/apache2 to host various Apache 2.2.4
>> server configuration files. I don't think we need this new directory.
>> We already have "extra" directory under
>> /etc/apache2 which can serve
> I was hoping we will use 'conf.d' as a wrapper directory for all task
> specific configurations underneath and totally not need a directory like
> 'extra'. I thought, the name 'extra' sounds yucky
If you see our directory structure, /etc/apache2 contains only configuration
specific files.
R
> I just posted my thoughts on as to how Apache 2.2.4 file layout could
> look so as to support multiple MPM support as part of our SAMP stack
> effort within SXDE. I would very much appreciate, if you could take a
> moment to review this proposal and let us know your concerns / suggestions.
>
> H
> I was hoping we will use 'conf.d' as a wrapper directory for all task
> specific configurations underneath and totally not need a directory like
> 'extra'. I thought, the name 'extra' sounds yucky
However, "extra" is the name currently used by the existing OpenSolaris
Apache. Unless there's a
> The initial proposal mentioned about a new directory, "conf.d" under
> /etc/apache2 to host various Apache 2.2.4
> server configuration files. I don't think we need this new directory. We
> already have "extra" directory under
> /etc/apache2 which can serve this purpose. Currently, httpd.conf-e
> I tried prototyping this layout structure with multiple MPMs using sfw build
> environment.
> I modified sfw build scripts to build and install prefork, worker mpm
> binaries under usr/apache2/bin directory.
Perhaps this is covered in another email but how does the administrator
select which m
Seema Alevoor wrote:
> Hi,
>
> I tried prototyping this layout structure with multiple MPMs using sfw build
> environment.
> I modified sfw build scripts to build and install prefork, worker mpm
> binaries under usr/apache2/bin directory.
I'd be interested in seeing the corresponding diffs that
There were some errors in the Apache Test suite conf files. I fixed them and
ran the tests again.
The result is as below:
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/modules/include.t
Seema Alevoor wrote:
>
> Some thoughts on the new layout :
> The initial proposal mentioned about a new directory, "conf.d" under
> /etc/apache2 to host various Apache 2.2.4
> server configuration files. I don't think we need this new directory. We
> already have "extra" directory under
> /etc/
+1 for enabling the extra conf files. This is the new way of doing
Apache configs and we should be supporting that rather than sticking to
the old single file httpd.conf.
Shanti
Seema Alevoor wrote:
> There were some errors in the Apache Test suite conf files. I fixed them and
> ran the tests
Just a clarification on the directory name change.
The change from libexec to modules was not required for building the co-located
httpd binaries.
Stefan had suggested this change. So, I just modified the required files along
with the other build related files.
Thanks,
Seema.
Seema Alevoor wrot
Hi,
I tried prototyping this layout structure with multiple MPMs using sfw build
environment.
I modified sfw build scripts to build and install prefork, worker mpm binaries
under usr/apache2/bin directory.
First I built apr and apr-util libraries with --enable-threads option and then
built pref
Hi
I just posted my thoughts on as to how Apache 2.2.4 file layout could
look so as to support multiple MPM support as part of our SAMP stack
effort within SXDE. I would very much appreciate, if you could take a
moment to review this proposal and let us know your concerns / suggestions.
Here
24 matches
Mail list logo
