perchild

2006-07-09 Thread Guy Hulbert
I'm looking at perchild with the aim of getting it working.

In STATUS I see:

 Get perchild to work on platforms other than Linux. This will require a
portable mechanism to pass data and file/socket descriptors between
vhost child groups.

But I am lead to believe (from the users list) that it needs work on
Linux as well.

If someone else is working on it then I will focus on testing it.

So far I am just looking at the code from trunk in reference to worker.

-- 
--gh




Re: perchild

2006-07-09 Thread Paul Querna

Guy Hulbert wrote:

I'm looking at perchild with the aim of getting it working.

In STATUS I see:

 Get perchild to work on platforms other than Linux. This will require a
portable mechanism to pass data and file/socket descriptors between
vhost child groups.

But I am lead to believe (from the users list) that it needs work on
Linux as well.


Yes. It could be broken on linux and all other platforms.


If someone else is working on it then I will focus on testing it.


No one is working on perchild ATM.

-Paul



Re: perchild

2006-07-10 Thread Guy Hulbert
On Sun, 2006-09-07 at 19:30 -0700, Paul Querna wrote:
> Guy Hulbert wrote:
> > I'm looking at perchild with the aim of getting it working.

> Yes. It could be broken on linux and all other platforms.
> 
> > If someone else is working on it then I will focus on testing it.
> 
> No one is working on perchild ATM.

I had gathered that from looking at the subversion logs.

I will see what I can do then.

I have been using prefork from debian (customers with PHP).

So it will take me a while to get up to speed.

> 
> -Paul
> 

-- 
--gh




Re: perchild

2006-08-30 Thread Enrico Weigelt
* Guy Hulbert <[EMAIL PROTECTED]> wrote:

Hi,

> I'm looking at perchild with the aim of getting it working.

maybe you're looking for: http://www.metux.de/mpm

The project has been stalled for quite a while :(
But maybe it's time for revival ?

> In STATUS I see:
> 
> Get perchild to work on platforms other than Linux. This will require a
> portable mechanism to pass data and file/socket descriptors between
> vhost child groups.

Perchild *never* worked. The idea isn't bad - we took much of it
into metuxmpm, but there were major design problems. For example:
each childs can accept clients. That's very bad, because it allows
some user to intercept another's requests with some probability.

The whole idea of passing *sockets* (instead of requests) between
processes only works on very few systems, ie. Linux, BSD and 
perhaps some others. So the whole portability issue is useless - 
those MPMs only work some Unix'es, and there evrythere the same.


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-


Re: perchild

2006-08-30 Thread Colm MacCarthaigh
On Wed, Aug 30, 2006 at 12:59:02PM +0200, Enrico Weigelt wrote:
> The whole idea of passing *sockets* (instead of requests) between
> processes only works on very few systems, ie. Linux, BSD and 
> perhaps some others. So the whole portability issue is useless - 
> those MPMs only work some Unix'es, and there evrythere the same.

None of our MPMs offers that kind of portability.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]


Re: perchild

2006-08-30 Thread Guy Hulbert
On Wed, 2006-30-08 at 12:59 +0200, Enrico Weigelt wrote:
> * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> 
> Hi,
> 
> > I'm looking at perchild with the aim of getting it working.
> 
> maybe you're looking for: http://www.metux.de/mpm

I found that.  The links don't work.

> 
> The project has been stalled for quite a while :(
> But maybe it's time for revival ?

Has it been uploaded into the apache svn ?

-- 
--gh




Re: perchild

2006-08-30 Thread Enrico Weigelt
* Guy Hulbert <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-30-08 at 12:59 +0200, Enrico Weigelt wrote:
> > * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> > 
> > Hi,
> > 
> > > I'm looking at perchild with the aim of getting it working.
> > 
> > maybe you're looking for: http://www.metux.de/mpm
> 
> I found that.  The links don't work.

ah, bug in the php script (was too old for my server - still relied 
on register_globals ;-o)

> > The project has been stalled for quite a while :(
> > But maybe it's time for revival ?
> 
> Has it been uploaded into the apache svn ?

IMHO not. Had stalled long before the switch to svn.


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-


Re: perchild

2006-08-30 Thread Guy Hulbert
On Wed, 2006-30-08 at 23:02 +0200, Enrico Weigelt wrote:
> * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-30-08 at 12:59 +0200, Enrico Weigelt wrote:
> > > * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> > > 
> > > Hi,
> > > 
> > > > I'm looking at perchild with the aim of getting it working.
> > > 
> > > maybe you're looking for: http://www.metux.de/mpm
> > 
> > I found that.  The links don't work.
> 
> ah, bug in the php script (was too old for my server - still relied 
> on register_globals ;-o)
> 


Ok.  I have the patch against 2.0.48 ... I will see what I can do with
it.

--gh




Re: perchild

2006-08-31 Thread Enrico Weigelt
* Guy Hulbert <[EMAIL PROTECTED]> wrote:

> 
> Ok.  I have the patch against 2.0.48 ... I will see what I can do with
> it.

Yeah, it's quite old. But perhaps you can get it into current 2.2.
Please give us feedback.


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-


Re: perchild

2006-08-31 Thread Guy Hulbert
On Thu, 2006-31-08 at 13:37 +0200, Enrico Weigelt wrote:
> * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Ok.  I have the patch against 2.0.48 ... I will see what I can do with
> > it.
> 
> Yeah, it's quite old. But perhaps you can get it into current 2.2.
> Please give us feedback.

It is not clear to me yet whether I should work on metux or perchild.

I'll give you some feedback once I am able to decide (weeks rather than
days).

> 
> 
> cu
-- 
--gh




Re: perchild

2006-08-31 Thread Enrico Weigelt
* Guy Hulbert <[EMAIL PROTECTED]> wrote:



> It is not clear to me yet whether I should work on metux or perchild.

Unless I missed some major redesign in perchild, you should drop it.
It has some design flaws which make it insecure. metuxmpm was forked
off to fix them.


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-


Re: perchild

2006-09-02 Thread Guy Hulbert
On Thu, 2006-31-08 at 16:21 +0200, Enrico Weigelt wrote:
> * Guy Hulbert <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> > It is not clear to me yet whether I should work on metux or perchild.
> 
> Unless I missed some major redesign in perchild, you should drop it.
> It has some design flaws which make it insecure. metuxmpm was forked
> off to fix them.

ok ... can you reply to me off-list with an outline

if/when i start working on this, I will post a URL to the list on which
I will post progress reports until I have something that can be uploaded
to mpm/experimental

> 
> 
> cu
-- 
--gh




PerChild Error

2003-06-20 Thread Pablo Yaggi
Hi, 
well after the chat about "worker hungs"..., by the way Bill, Cliff did you 
check my last post ? the question about the prefork, is it fixable ?
besides is prefork using threads ?

i installed a server with perchild and this is a strip from my error log:

[Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal Segmentation fault (11)
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.

any advice ?

this is a strip from my conf, my local domain name server is responding for test.local


NumServers   5
StartThreads 5
MinSpareThreads  5
MaxSpareThreads 10
MaxThreadsPerChild  20
MaxRequestsPerChild  0


NameVirtualHost *
UseCanonicalName Off
ChildPerUserID pablo apache 1

 ServerName test.local
 AssignUserID pablo apache





perchild mpm

2002-10-17 Thread Jonas Eriksson



 
Any progress in getting perchild to work ?
 
/ Jonas
 


MPM perchild.

2002-11-26 Thread Jonas Eriksson

Hi

I Still get error "Unable to find process with matching uid/gid."
after compileing 2.43 with
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/experimental/perc
hild/perchild.c

Any ideas?





Perchild on Solaris (was: Perchild works again.... kind of)

2002-08-19 Thread Tsuyoshi SASAMOTO

On Solaris, this macro definition is required to build successfully:
  -D_XOPEN_SOURCE=500 -D__EXTENSIONS__

By the way, with the perchild MPM, httpd performance is
"T2 (alternate) thread lib < T1 (default) thread lib".

http://groups.google.com/groups?[EMAIL PROTECTED]

By contrast, with the worker MPM, "T2 thread lib > T1 thread lib"
(But the difference is smaller than the perchild MPM).

With the perchild MPM and the T2 thread lib, mutex contention
may cause performance penalty, I guess...


Tsuyoshi SASAMOTO
[EMAIL PROTECTED]



perchild is broken

2002-12-13 Thread Dirk Nehring
Dear Apache developer,

I try to use Apache's perchild MPM. Unfortunately, it seems to be broken
under Linux. I'm using RedHat 8.0 (glibc-2.2.5, gcc 3.2), took the
latest CVS sources for httpd-2.0, apr and apr-util (today's CVS
checkout), and compiled with the perchild MPM. The following happened
after starting:

[Fri Dec 13 17:21:45 2002] [notice] suEXEC mechanism enabled (wrapper: 
/opt/apache/bin/suexec)
[Fri Dec 13 17:21:45 2002] [notice] Digest: generating secret for digest 
authentication ...
[Fri Dec 13 17:21:45 2002] [notice] Digest: done
[Fri Dec 13 17:21:46 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Dec 13 17:21:46 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Dec 13 17:21:46 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Dec 13 17:21:46 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Dec 13 17:21:46 2002] [notice] Apache/2.1.0-dev (Unix) DAV/2 configured -- 
resuming normal operations
[Fri Dec 13 17:21:46 2002] [notice] child pid 16287 exit signal Segmentation fault (11)
[Fri Dec 13 17:21:46 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[...]

Any idea?

Regards,

Dirk Nehring

--
Dirk Nehring | PGP: 69AA BD83 8065 A1DE BBA4
[EMAIL PROTECTED] |  DE54 1F14 C2AE 739A 32D9

- End forwarded message -

--
Dirk Nehring | PGP: 69AA BD83 8065 A1DE BBA4
[EMAIL PROTECTED] |  DE54 1F14 C2AE 739A 32D9



Re: PerChild Error

2003-06-20 Thread gregames
Pablo Yaggi wrote:

> besides is prefork using threads ?

prefork does not use threads.

	i installed a server with perchild and this is a strip from my error log:

[Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal Segmentation fault (11)
do you have a coredump?  We the backtrace from it if so.  otherwise, we can't do 
squat with these messages.

If this is Linux, you should see more text at the end of this message saying 
that there is a possible coredump.  Make sure you have "CoreDumpDir 
/directory/writeable/by/Apache/User " in your httpd.conf or it's hard to get 
coredumps.

[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process gracefully.
[Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process gracefully.
what kind of locking is your apr using?  (hint:  bin/httpd -V)

Greg



Re: PerChild Error

2003-06-20 Thread Pablo Yaggi
It doesn't dump anything, i have this
CoreDumpDirectory /tmp/
and it dumps nothing there.

What I saw is that a new process for the site (user pablo)
is being started about 2 seconds all the time and
each process logs what I mention before, so I think
the process is not even starting in the right way.
The main process is starting, because I can stablish
a connection with a browser, but the request is never
attended.

Please let me know how I can log something else or
dump the core. I can't open the process with gdb because
the process is dieing permantly, is it any usefull for you a dump from
the main process? wich kind ?.

Yes I 'm using linux, version 2.4.21 from mandrake 9.1

Regards,
Pablo


[Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal
is in the log all the

On Friday 20 June 2003 06:35 pm, [EMAIL PROTECTED] wrote:
> Pablo Yaggi wrote:
>  > besides is prefork using threads ?
>
> prefork does not use threads.
>
> > i installed a server with perchild and this is a strip from my error
> > log:
> >
> > [Fri Jun 20 18:29:52 2003] [notice] child pid 14291 exit signal
> > Segmentation fault (11)
>
> do you have a coredump?  We the backtrace from it if so.  otherwise, we
> can't do squat with these messages.
>
> If this is Linux, you should see more text at the end of this message
> saying that there is a possible coredump.  Make sure you have "CoreDumpDir
> /directory/writeable/by/Apache/User " in your httpd.conf or it's hard to
> get coredumps.
>
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully.
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully.
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_lock failed. Attempting to shutdown process gracefully.
> > [Fri Jun 20 18:29:52 2003] [emerg] (13)Permission denied:
> > apr_proc_mutex_unlock failed. Attempting to shutdown process gracefully.
>
> what kind of locking is your apr using?  (hint:  bin/httpd -V)
>
> Greg



Re: PerChild Error

2003-06-21 Thread Pablo Yaggi
I forgot this in my last post, output from httpd -V

Server version: Apache-AdvancedExtranetServer/2.0.46
Server built:   Jun 20 2003 04:31:08
Server's Module Magic Number: 20020903:3
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR="server/mpm/experimental/perchild"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/etc/httpd/2.0"
 -D SUEXEC_BIN="/usr/sbin/apache2-suexec"
 -D DEFAULT_PIDLOG="/var/run/httpd.pid"
 -D DEFAULT_LOCKFILE="/var/run/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd2.conf"

Pablo



Re: PerChild Error

2003-06-23 Thread gregames
Pablo Yaggi wrote:
It doesn't dump anything, i have this
CoreDumpDirectory /tmp/
and it dumps nothing there.
ok, that looks good so far...

What I saw is that a new process for the site (user pablo)
is being started about 2 seconds all the time and
each process logs what I mention before, so I think
the process is not even starting in the right way.
The main process is starting, because I can stablish
a connection with a browser, but the request is never
attended.
Please let me know how I can log something else or
dump the core. I can't open the process with gdb because
the process is dieing permantly, is it any usefull for you a dump from
the main process? wich kind ?.
Yes I 'm using linux, version 2.4.21 from mandrake 9.1
There is a fix in the open source version of 2.0.46

http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz

...which allows coredumps on Linux when you start httpd as root and code 
CoreDumpDirectory in httpd.conf.  If you start httpd as non-root, it should just 
work (i.e., you don't need the fix), assuming CoreDumpDirectory points to 
somewhere like /tmp where the non-root user can create files.

Pablo Yaggi wrote:
> I forgot this in my last post, output from httpd -V
>
> Server version: Apache-AdvancedExtranetServer/2.0.46
I don't know what is in this vendor's version of Apache.  You might want to talk 
to them, or try the open source version.

Greg



Re: PerChild Error

2003-06-23 Thread gregames
[EMAIL PROTECTED] wrote:

There is a fix in the open source version of 2.0.46

http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz

...which allows coredumps on Linux when you start httpd as root and code 
CoreDumpDirectory in httpd.conf.  If you start httpd as non-root, it 
should just work (i.e., you don't need the fix), assuming 
CoreDumpDirectory points to somewhere like /tmp where the non-root user 
can create files.
ps.  This fix is mainly to os/unix/unixd.c::unixd_setup_child() .  That 
function is not called by the perchild mpm, so it won't help your situation.

I'm assuming perchild does its own setuid calls, since the user ids are a unique 
feature of perchild.  You could look for this and code prctl(PR_SET_DUMPABLE,1) 
after the setuid.  Here's what I did in the mainstream code:

http://cvs.apache.org/viewcvs.cgi/httpd-2.0/os/unix/unixd.c.diff?r1=1.56&r2=1.57&diff_format=h

Good luck!

Greg "not about to become the PerChild maintainer" Ames



Re: PerChild Error

2003-06-23 Thread Pablo Yaggi
No, it was running as less privileged user ,
and the version Extranet is just somthing mandrake puted there, 
I'm recompiling mandrakes rpms, maybe there's some patch there that stops the dumps, 
i'll try
to rebuild the source.

But now I'm trying muxmpm cause somebody told me that perchild it was not
working at all, did you manage to make it work ?
if it is so, are you cgi working at right userid ? do you have php running ?
what happens with ssl request on namebased virtual hosts ? who attends ?

Thank's
Pablo




On Monday 23 June 2003 11:36 am, [EMAIL PROTECTED] wrote:
> Pablo Yaggi wrote:
> > It doesn't dump anything, i have this
> > CoreDumpDirectory /tmp/
> > and it dumps nothing there.
>
> ok, that looks good so far...
>
> > What I saw is that a new process for the site (user pablo)
> > is being started about 2 seconds all the time and
> > each process logs what I mention before, so I think
> > the process is not even starting in the right way.
> > The main process is starting, because I can stablish
> > a connection with a browser, but the request is never
> > attended.
> >
> > Please let me know how I can log something else or
> > dump the core. I can't open the process with gdb because
> > the process is dieing permantly, is it any usefull for you a dump from
> > the main process? wich kind ?.
> >
> > Yes I 'm using linux, version 2.4.21 from mandrake 9.1
>
> There is a fix in the open source version of 2.0.46
>
> http://www.apache.org/dist/httpd/httpd-2.0.46.tar.gz
>
> ...which allows coredumps on Linux when you start httpd as root and code
> CoreDumpDirectory in httpd.conf.  If you start httpd as non-root, it should
> just work (i.e., you don't need the fix), assuming CoreDumpDirectory points
> to somewhere like /tmp where the non-root user can create files.
>
> Pablo Yaggi wrote:
>  > I forgot this in my last post, output from httpd -V
>  >
>  > Server version: Apache-AdvancedExtranetServer/2.0.46
>
> I don't know what is in this vendor's version of Apache.  You might want to
> talk to them, or try the open source version.
>
> Greg



Re: PerChild Error

2003-06-23 Thread gregames
Pablo Yaggi wrote:
No, it was running as less privileged user ,
and the version Extranet is just somthing mandrake puted there, 
I'm recompiling mandrakes rpms, maybe there's some patch there that stops the dumps, i'll try
to rebuild the source.
you might want to have a look at my other post where I talked about prctl(). 
PerChild might need something like that in order to dump on Linux, if it does 
its own setuid().

But now I'm trying muxmpm cause somebody told me that perchild it was not
working at all, 
I've heard that too.

did you manage to make it work ?
haven't tried it, and I don't plan on it in the near future.

Greg



MPM-Module perchild

2009-11-23 Thread christian4apache
Hello,

We have an internal project where we need the MPM module perchild. The 
Apache 2.0 documentation says that the development is not completed. I 
talked to my boss and he says I could take maybe any necessary residual 
activities, (depending on the size). Therefore, the following questions:

* What is currently state of this module?
* What would a collaboration?
* How is the planning of this module in Apache 2.2. The link of 'user' 
(http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user) and 'group' 
(http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group) only brings 
a 404 (http://httpd.apache.org/docs/2.2/mod/perchild.html).

Thank you for your info.
Christian



Re: perchild mpm

2002-10-18 Thread Johannes Erdfelt
On Thu, Oct 17, 2002, Jonas Eriksson <[EMAIL PROTECTED]> wrote:
> Any progress in getting perchild to work ?

I've started some debugging.

In my case, passing the request off to a different process is causing
corruption and the request to fail.

That's as far as I have gotten so far :)

What problems are you having?

JE




SV: perchild mpm

2002-10-18 Thread Jonas Eriksson

Last time i was compileing apache it was 2.39 and I hade the same
problem as you.
I quess nobody have had the time to work with it get then..

/ Jonas




I've started some debugging.

In my case, passing the request off to a different process is causing
corruption and the request to fail.

That's as far as I have gotten so far :)

What problems are you having?

JE





MPM perchild againg

2002-11-26 Thread Enrico Weigelt

hi folks, 

it seems that under some circumstances the messages for connection
passing between childs are not received at the destination process.
sometimes it also happened, that apr_poll() returned w/o error, 
but scan through the listener list does not find the touched socket.
perhaps there's a leak in the listener list. where could it be modified ? 
should the pollset better be recreated before each poll ?

~-n
--
Bestes Mittel gegen Mailviren: Outlook löschen.
-
 Enrico Weigelt==   metux ITS 
 Webhosting ab 5 EUR/Monat.  UUCP, rawIP und vieles mehr.

 phone: +49 36207 519931 www:   http://www.metux.de/ 
 fax:   +49 36207 519932 email: [EMAIL PROTECTED]
 cellphone: +49 174 7066481  smsgate:   [EMAIL PROTECTED]
-
 Diese Mail wurde mit UUCP versandt.  http://www.metux.de/uucp/



Re: MPM perchild.

2002-11-26 Thread Johannes Erdfelt
On Tue, Nov 26, 2002, Jonas Eriksson <[EMAIL PROTECTED]> wrote:
> I Still get error "Unable to find process with matching uid/gid."
> after compileing 2.43 with
> http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/experimental/perc
> hild/perchild.c

Are you sure you configured your setup correctly?

Do you have a ChildPerUserId before you use AssignUserId?

Can you give us the configuration you're using?

JE




SV: MPM perchild.

2002-11-26 Thread Jonas Eriksson


Hmm sorry! I did a bougus error in http.conf ...

When i now start the server i get the following in my shell promt and
the server starts.
What does the debug info tell? Is it all ok or do i have to change
anyting?

[root@mose /usr/local/apache2.0.43/bin]# ./httpd -f
/usr/local/apache2.0.43/conf/httpd.conf
[Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
0
[Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
1
[Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
2
 



On Tue, Nov 26, 2002, Jonas Eriksson <[EMAIL PROTECTED]> wrote:
> I Still get error "Unable to find process with matching uid/gid."
> after compileing 2.43 with
>
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/experimental/perc
> hild/perchild.c

Are you sure you configured your setup correctly?

Do you have a ChildPerUserId before you use AssignUserId?

Can you give us the configuration you're using?

JE





Re: MPM perchild.

2002-11-26 Thread Enrico Weigelt
On Tue, Nov 26, 2002 at 06:44:13PM +0100, Jonas Eriksson wrote:


> /usr/local/apache2.0.43/conf/httpd.conf
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 0
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 1
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 2

Little question about ChildPerUserId. The manual states, that the 
first parameter n is the ID of the child to assign, but the 
set_child_per_user_id function seems to assign n childs to the given uid/gid.

is that ok ?

~-n
--
Bestes Mittel gegen Mailviren: Outlook löschen.
-
 Enrico Weigelt==   metux ITS 
 Webhosting ab 5 EUR/Monat.  UUCP, rawIP und vieles mehr.

 phone: +49 36207 519931 www:   http://www.metux.de/ 
 fax:   +49 36207 519932 email: [EMAIL PROTECTED]
 cellphone: +49 174 7066481  smsgate:   [EMAIL PROTECTED]
-
 Diese Mail wurde mit UUCP versandt.  http://www.metux.de/uucp/



Re: Perchild on Solaris (was: Perchild works again.... kind of)

2002-08-19 Thread Aaron Bannert

On Tue, Aug 20, 2002 at 11:07:37AM +0900, Tsuyoshi SASAMOTO wrote:
> On Solaris, this macro definition is required to build successfully:
>   -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
> 
> By the way, with the perchild MPM, httpd performance is
> "T2 (alternate) thread lib < T1 (default) thread lib".
> 
> http://groups.google.com/groups?[EMAIL PROTECTED]
> 
> By contrast, with the worker MPM, "T2 thread lib > T1 thread lib"
> (But the difference is smaller than the perchild MPM).
> 
> With the perchild MPM and the T2 thread lib, mutex contention
> may cause performance penalty, I guess...

Having just first seen your original post a few seconds ago, I
wanted to point out a couple problems with the test you performed.
The first problem is you had the client and the server on the
same machine, which means that they were fighting each other
for timeslices, which is bad. The second problem is AB isn't
the greatest tool for measuring performance and concurrency. It
is useful for a quick test, and for single-threaded performance,
but terrible at testing the various threaded MPMs.

-aaron



Re: Perchild on Solaris (was: Perchild works again.... kind of)

2002-08-19 Thread Ian Holsman

Tsuyoshi SASAMOTO wrote:
> On Solaris, this macro definition is required to build successfully:
>   -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
> 
> By the way, with the perchild MPM, httpd performance is
> "T2 (alternate) thread lib < T1 (default) thread lib".
when I was speaking to the sun people they said that in order to get 
better performance with the Solaris9(t2) threading we need to bind the 
processes to individual CPU's.
> 
> http://groups.google.com/groups?[EMAIL PROTECTED]
> 
> By contrast, with the worker MPM, "T2 thread lib > T1 thread lib"
> (But the difference is smaller than the perchild MPM).
> 
some comments..
the stats seems high.. make sure you have the:
Options FollowSymLinks
AllowOverrides none
specified
also try 'AcceptMutex pthread' this worked better for my tests.
there may be some other things, but I would need to see your config file.

> With the perchild MPM and the T2 thread lib, mutex contention
> may cause performance penalty, I guess...
> 
> 
> Tsuyoshi SASAMOTO
> [EMAIL PROTECTED]
> 





Re: Perchild on Solaris (was: Perchild works again.... kind of)

2002-08-20 Thread rbb

On Mon, 19 Aug 2002, Aaron Bannert wrote:

> On Tue, Aug 20, 2002 at 11:07:37AM +0900, Tsuyoshi SASAMOTO wrote:
> > On Solaris, this macro definition is required to build successfully:
> >   -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
> > 
> > By the way, with the perchild MPM, httpd performance is
> > "T2 (alternate) thread lib < T1 (default) thread lib".
> > 
> > 
>http://groups.google.com/groups?[EMAIL PROTECTED]
> > 
> > By contrast, with the worker MPM, "T2 thread lib > T1 thread lib"
> > (But the difference is smaller than the perchild MPM).
> > 
> > With the perchild MPM and the T2 thread lib, mutex contention
> > may cause performance penalty, I guess...
> 
> Having just first seen your original post a few seconds ago, I
> wanted to point out a couple problems with the test you performed.
> The first problem is you had the client and the server on the
> same machine, which means that they were fighting each other
> for timeslices, which is bad. The second problem is AB isn't
> the greatest tool for measuring performance and concurrency. It
> is useful for a quick test, and for single-threaded performance,
> but terrible at testing the various threaded MPMs.

The third problem with this measurement, is that the Perchild MPM is in
no way ready to be benchmarked.  :-)  This MPM just barely works, let
alone optimized.

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---




Re: Perchild on Solaris (was: Perchild works again.... kind of)

2002-08-20 Thread rbb

On Tue, 20 Aug 2002, Tsuyoshi SASAMOTO wrote:

> On Solaris, this macro definition is required to build successfully:
>   -D_XOPEN_SOURCE=500 -D__EXTENSIONS__

This is because APR doesn't understand file descriptor passing, which
means that I hard-coded that logic into Perchild.  I used the logic that
Linux understands.  I will abstract that logic out at some point, but it
will take some time.

Ryan

___
Ryan Bloom  [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---




mpm perchild and mod_php4

2002-12-08 Thread Jochen Kächelin
Can somebody give me hint how to get Apache 2.0.43, perchild
and mod_php4 running to do some testing?

When I try to connect with http://192.168.0.1
I will get no answer (browser ist loading, loading, loading


httpd.conf:

Listen 80
ServerAdmin [EMAIL PROTECTED]
ServerName 192.168.0.1:80
NameVirtualHost 192.168.0.1
Include /etc/apache/virtual.conf


virtual.conf:


Servername 192.168.0.1
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /www
#   AssignUserid nobody nobody
ChildPerUserId jochen jochen 2


What should I insert into AssignUserId?
Apache ist running as

user: nobody
group: nobody.

ps aux:

root 20015  0.0  1.5  3600 2024 ?S16:01   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   20016  0.0  1.5  3536 1964 ?S16:01   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   23779  0.0  1.7 13916 2160 ?S16:05   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   23781  0.0  1.7 13916 2160 ?S16:05   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   23788  0.0  0.0 00 ?Z16:05   0:00 [httpd ]
nobody   23789  0.0  1.7 13916 2160 ?S16:05   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   23790  0.0  1.7 13916 2160 ?S16:05   0:00 
/usr/local/apache2/bin/httpd -k start
nobody   23791  0.0  0.0 00 ?Z16:05   0:00 [httpd ]
jochen   24161  0.0  0.0 00 ?Z16:05   0:00 [httpd ]
nobody   24162  0.0  0.0 00 ?Z16:05   0:00 [httpd ]

error_log:

[Sun Dec 08 16:03:03 2002] [notice] child pid 21526 exit signal Segmentation fault (11)
[Sun Dec 08 16:03:03 2002] [notice] child pid 21524 exit signal Segmentation fault (11)
[Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process
gracefully.
[Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process
gracefully.
[Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock failed. 
Attempting to shutdown process
gracefully.
[Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
failed. Attempting to shutdown process
gracefully.


-- 
Jochen Kaechelin




Re: perchild is broken

2002-12-13 Thread Enrico Weigelt
On Fri, Dec 13, 2002 at 06:21:09PM +0100, Dirk Nehring wrote:


> I try to use Apache's perchild MPM. Unfortunately, it seems to be broken
> under Linux. I'm using RedHat 8.0 (glibc-2.2.5, gcc 3.2), took the
> latest CVS sources for httpd-2.0, apr and apr-util (today's CVS
> checkout), and compiled with the perchild MPM. The following happened
> after starting:

yes, it _is_ broken.

i've started working on an new MPM (multiplexer), derived from perchild, 
which also provides the possibility for assigning UIDs to vhosts, but 
is (should be) a bit more secure. 

but the muxmpm isnt really stable yet, there's still the problem that
worker threads are dying out after a while ...

perhaps you wanna help ?


~-n
-- 
Bestes Mittel gegen Mailviren: Outlook löschen.
-
 Enrico Weigelt==   metux ITS 
 Webhosting ab 5 EUR/Monat.  UUCP, rawIP und vieles mehr.

 phone: +49 36207 519931 www:   http://www.metux.de/ 
 fax:   +49 36207 519932 email: [EMAIL PROTECTED]
 cellphone: +49 174 7066481  smsgate:   [EMAIL PROTECTED]
-
 Diese Mail wurde mit UUCP versandt.  http://www.metux.de/uucp/



State of perchild MPM

2007-01-29 Thread devkit1

I have gotten the impression this may be a sore subject for the list based on 
searching through the archives, but I do not intend to work anyone up.  I have 
been trying to find a solution to the problem of shared hosting with a dynamic 
language such as PHP.  I found the old perchild MPM and it appears it is not 
being maintained or there was possibly a design problem.  I would like to know 
two things.

1. Is there a mechanism (other than suexec) that allows functionality similar 
to perchild, that will allow a uid to be assigned on a per request basis?

2. If there is, do the developers need help with it?  I can write C and I am 
willing to help out with this.  If there is not, Would anyone from the Apache 
team be interested in working with me so I may write such functionality, maybe 
for a future version of Apache?


I would appreciate all constructive criticism.  If there is a good technical 
reason this cannot be done, please explain it to me.  I am also willing to work 
on a patch for the kernel to hook calls that Apache makes to system calls such 
as open and execve if necessary.


Thank you for your time,
devkit1




Re: MPM-Module perchild

2009-11-23 Thread Graham Dumpleton
2009/11/23  :
> Hello,
>
> We have an internal project where we need the MPM module perchild. The
> Apache 2.0 documentation says that the development is not completed. I
> talked to my boss and he says I could take maybe any necessary residual
> activities, (depending on the size). Therefore, the following questions:
>
> * What is currently state of this module?
> * What would a collaboration?
> * How is the planning of this module in Apache 2.2. The link of 'user'
> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user) and 'group'
> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group) only brings
> a 404 (http://httpd.apache.org/docs/2.2/mod/perchild.html).

First off I would be asking what specific code are you wanting to run
which requires this MPM. There are other means of achieving process
separation and dropping of privileges to different users than this
MPM. Whether other solutions are suitable really depends on what you
are wanting to do though.

So, explain what the actual requirement is rather than than your
suspected solution and may be can save you some time by suggesting
other ways you can achieve the same which doesn't require as much
work.

Graham

Graham


Re: MPM-Module perchild

2009-11-23 Thread Jeff Trawick
On Mon, Nov 23, 2009 at 4:40 AM,
 wrote:
> Hello,
>
> We have an internal project where we need the MPM module perchild. The
> Apache 2.0 documentation says that the development is not completed. I
> talked to my boss and he says I could take maybe any necessary residual
> activities, (depending on the size). Therefore, the following questions:
>
> * What is currently state of this module?
> * What would a collaboration?
> * How is the planning of this module in Apache 2.2. The link of 'user'
> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user) and 'group'
> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group) only brings
> a 404 (http://httpd.apache.org/docs/2.2/mod/perchild.html).

perchild is no longer maintained here.

See

http://httpd.apache.org/docs/2.3/mod/mod_privileges.html (in future httpd 2.4)
http://mpm-itk.sesse.net/

(perhaps there are other projects out there which are still active?
Metux was active at some point.)


RE: MPM-Module perchild

2009-11-23 Thread Herring, Ed
I would like to discuss a collaborative effort to get this module working.

-Original Message-
From: christian4apa...@lists.muthpartners.de 
[mailto:christian4apa...@lists.muthpartners.de] 
Sent: Monday, November 23, 2009 3:40 AM
To: dev@httpd.apache.org
Subject: MPM-Module perchild

Hello,

We have an internal project where we need the MPM module perchild. The 
Apache 2.0 documentation says that the development is not completed. I 
talked to my boss and he says I could take maybe any necessary residual 
activities, (depending on the size). Therefore, the following questions:

* What is currently state of this module?
* What would a collaboration?
* How is the planning of this module in Apache 2.2. The link of 'user' 
(http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user) and 'group' 
(http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group) only brings 
a 404 (http://httpd.apache.org/docs/2.2/mod/perchild.html).

Thank you for your info.
Christian



Re: MPM-Module perchild

2009-11-23 Thread Graham Dumpleton
2009/11/23 Jeff Trawick :
> On Mon, Nov 23, 2009 at 4:40 AM,
>  wrote:
>> Hello,
>>
>> We have an internal project where we need the MPM module perchild. The
>> Apache 2.0 documentation says that the development is not completed. I
>> talked to my boss and he says I could take maybe any necessary residual
>> activities, (depending on the size). Therefore, the following questions:
>>
>> * What is currently state of this module?
>> * What would a collaboration?
>> * How is the planning of this module in Apache 2.2. The link of 'user'
>> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user) and 'group'
>> (http://httpd.apache.org/docs/2.2/mod/mpm_common.html#group) only brings
>> a 404 (http://httpd.apache.org/docs/2.2/mod/perchild.html).
>
> perchild is no longer maintained here.
>
> See
>
> http://httpd.apache.org/docs/2.3/mod/mod_privileges.html (in future httpd 2.4)

FWIW, contrary to what is suggested by documentation for
mod_privileges, I would anticipate that modules which embed a Python
interpreter such as mod_python and mod_wsgi are not going to be
compatible with at least SECURE mode of mod_privileges. This is
because after a fork of a Python process special Python interpreter
core function has to be called to do some fixups. This is fine if fork
done from Python code as it will be done automatically, but not if
done from external C code in same process. Not sure how well things
will work if that fixup function isn't called.

So, in order for it to work, there would need to be optional hook
functions exposed by mod_privileges which would allow other modules to
run special actions after the fork. This though means that the
distinct modules would need to be customised to know about
mod_privileges.

BTW, what operating system feature does this use that means it is only
usable on Solaris?

Graham


Re: MPM-Module perchild

2009-11-23 Thread Nick Kew

Graham Dumpleton wrote:


http://httpd.apache.org/docs/2.3/mod/mod_privileges.html (in future httpd 2.4)


FWIW, contrary to what is suggested by documentation for
mod_privileges, I would anticipate that modules which embed a Python
interpreter such as mod_python and mod_wsgi are not going to be
compatible with at least SECURE mode of mod_privileges. This is
because after a fork of a Python process special Python interpreter
core function has to be called to do some fixups. This is fine if fork
done from Python code as it will be done automatically, but not if
done from external C code in same process. Not sure how well things
will work if that fixup function isn't called.


That's entirely likely.  Fast mode is straightforward, but secure
mode is only sparsely tested, and could easily fall down when presented
with complex problems as you suggest.  In such a scenario we could
either fix it as you suggest (how does ITK deal with this?), or
bow out and recommend alternatives.


BTW, what operating system feature does this use that means it is only
usable on Solaris?


Is there another OS that supports solaris-style privileges?
One could envisage other modules to harness operating system
security - such as SElinux - but I don't think it would look
similar enough to abstract out a common API.

--
Nick Kew


Apache 20020213 anonCVS perchild

2002-02-13 Thread Jeroen Massar


I compiled a 20020213 httpd anoncvs today to try the perchild module.

And I think that:
8<-
Out of Memory: Killed process 4768 (apache2).
Out of Memory: Killed process 4774 (apache2).
Out of Memory: Killed process 4775 (apache2).
Out of Memory: Killed process 4783 (apache2).
Out of Memory: Killed process 4790 (apache2).
Out of Memory: Killed process 4791 (apache2).
Out of Memory: Killed process 4798 (apache2).
->8

Kinda show that it's not entirely okay on my machine ;)
I also tried the 2.0.28-beta which is found on the distribution site.

The system is a mere p3 750 with 128mb running linux 2.5.1
Linux calvin 2.5.1 #1 Mon Jan 14 15:08:00 CET 2002 i686 unknown

The effect seen is that mozilla (nope not only apache is bad ;)
8<---
Out of Memory: Killed process 4713 (mozilla-bin-cvs).
Out of Memory: Killed process 4728 (mozilla-bin-cvs).
Out of Memory: Killed process 4729 (mozilla-bin-cvs).
Out of Memory: Killed process 4730 (mozilla-bin-cvs).
Out of Memory: Killed process 4731 (mozilla-bin-cvs).
--->8

At least something is filling the memory ;)
Well it's apache aparently because a simple:

root@calvin:/home/staff/jeroen/data/apache2/deb/2.0.28-perchild/apache2-2.0.28#
telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: calvin.ics.hro.nl

^]q

telnet> Connection closed.

Wellps that makes apache2 go rogue too and no response ;(

The configlines which when removed make it work, but when added make it break:
ChildperUserID wwwics wwwics 1

and in one of the 3 vhosts:
AssignUserID wwwics wwwics

(little background, the idea is to secure every vhost so that it runs
under a seperate user and that there is no way that some random user reads
the cleartext passwords for databases etc through something like a php.
Every vhost will be seperate... )

The host: http://calvin.ics.hro.nl

Server Info at http://calvin.ics.hro.nl/server-info
Server Stats at http://calvin.ics.hro.nl/server-status
Currently running without assignuserid and childperuserid, otherwise it simply doesn't 
respond :(
The debian tag is because I built it using the debian build rules:

The configure options:
AP2_CONFARGS =  --enable-layout=Debian --enable-so \
--with-program-name=apache2 --enable-speling=shared \
--enable-rewrite=shared --enable-cgid=shared \
--enable-vhost-alias=shared --enable-info=shared \
--enable-suexec=shared --enable-ssl=shared \
--enable-unique-id=shared --enable-usertrack=shared \
--enable-expires=shared --enable-cern-meta=shared \
--enable-mime-magic=shared --enable-headers=shared \
--enable-auth-anon=shared --enable-proxy=shared \
--enable-dav=shared --with-suexec-caller=www-data 
--with-suexec-docroot=/www --with-suexec-logfile=/var/log/apache2/ \
--with-mpm=perchild

Something else broke the php handling through a cgi using the trick:
Action application/x-httpd-php /cgi-bin/php4

Which results in a:
[Wed Feb 13 16:37:56 2002] [warn] [client 145.24.239.47] handler "cgi-script" not 
found for: /usr/lib/cgi-bin/php4

Every query but that's prolly something different and not related to mpm_perchild

If somebody can give me some clue... I welcome it ;)

Greets,
 Jeroen




Move perchild to experimental?

2002-04-16 Thread Justin Erenkrantz

Would people have issues if we move perchild to experimental?

We're getting a number of PRs related to perchild because it isn't
working.  For the next release, I think it would be a bit better if
we made it somewhat obvious that perchild isn't expected to
work.  -- justin



[patch] small perchild fixes

2002-04-22 Thread Scott Lamb

I've attached a small patch to perchild that

- makes perchild compile with the server/mpm/perchild ->
  server/mpm/experimental/perchild move.
- fixes a typo I made in an earlier patch. It ran the GID through the user
  name lookup. (I didn't notice because on my test syste the uid, gid,
  username, and group name were all the same.) oops.

Please apply.

(It doesn't address the larger problem that perchild just didn't work for
me, requests hung.  rbb's last commit message to mpm.h suggests this is not
unexpected. Since I know nothing of either the old or new locking APIs, I'll
leave that alone.)

--
Scott Lamb



state of mpm perchild

2002-06-24 Thread Nick De Decker



Hi guys,
 
Any progress on the mpm perchild for linux 
?
I'm setting up a production webserver and really 
would like to use this mpm.
Any date set ?
 
Regards
Nick De Decker


perchild on FreeBSD 5?

2002-08-13 Thread Gabriel Ambuehl

Hello,
I've more or less accepted that perchild on FreeBSD 4.X isn't going to
happen (as sad as it is, I always considered it to be THE feature [1] in
2.0 that would warrant an upgrade for us) but what I'd like to know is
if there is any chance to see perchild on FreeBSD 5 which gets wholly
new threading and SMP libs?


My company would happily pay someone a few thousand US$ to come up
with a working perchild implementation on FreeBSD 5 and from what
I've gathered on the FreeBSD mailing lists, there might be other
parties that would contribute to the funding, too. We haven't got any
reasonable in-house knowhow to contribute with code but we'd surely
help beta testing.




[1] Name based vhosts with PHP scripts running under the UID
of the user. Great for all ISPs out there.


Regards,
Gabriel




Re: Perchild on Solaris

2002-08-19 Thread Tsuyoshi SASAMOTO

>Having just first seen your original post a few seconds ago, I
>wanted to point out a couple problems with the test you performed.
>The first problem is you had the client and the server on the
>same machine, which means that they were fighting each other
>for timeslices, which is bad. The second problem is AB isn't
>the greatest tool for measuring performance and concurrency. It
>is useful for a quick test, and for single-threaded performance,
>but terrible at testing the various threaded MPMs.

Thanks... I agree your suggestion, but currently,
I don't have good 2 machines (one for server, other for client)
that are suitable for load test.

So, absolute values of those result are not so meaningful,
and I want those result to be treated as a relative comparison
between T1 and T2 thread lib.


Tsuyoshi SASAMOTO
[EMAIL PROTECTED]



Re: Perchild on Solaris

2002-08-19 Thread Tsuyoshi SASAMOTO

>some comments..
>the stats seems high.. make sure you have the:
>   Options FollowSymLinks
>   AllowOverrides none
>specified
>also try 'AcceptMutex pthread' this worked better for my tests.
>there may be some other things, but I would need to see your config file.

Thanks... The previous config was:
Options All MultiViews
AllowOverride All
I was interested in the "relative" comparison between T1 and T2 threads,
so httpd.conf itself was not tuned well...

Under config you suggested above and so on, the result is as below.


Tsuyoshi SASAMOTO
[EMAIL PROTECTED]
--

Result of
ab -c128 -n8192 127.0.0.1:3080/
[T1 thread lib]---
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   14.586689 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15810560 bytes
HTML transferred:   13352960 bytes
Requests per second:561.61 [#/sec] (mean)
Time per request:   227.917 [ms] (mean)
Time per request:   1.781 [ms] (mean, across all concurrent requests)
Transfer rate:  1058.50 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   1.3  0  84
Processing:29  224  24.9222 442
Waiting:3  112  65.8112 360
Total: 29  224  25.0222 444

Percentage of the requests served within a certain time (ms)
  50%222
  66%223
  75%223
  80%223
  90%225
  95%240
  98%306
  99%310
 100%444 (longest request)
[T2 thread lib]---
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   15.981754 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15810560 bytes
HTML transferred:   13352960 bytes
Requests per second:512.58 [#/sec] (mean)
Time per request:   249.715 [ms] (mean)
Time per request:   1.951 [ms] (mean, across all concurrent requests)
Transfer rate:  966.10 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.7  0  58
Processing:56  245  29.3266 398
Waiting:3  123  71.0123 307
Total: 56  246  29.3266 398

Percentage of the requests served within a certain time (ms)
  50%266
  66%267
  75%268
  80%268
  90%270
  95%271
  98%284
  99%285
 100%398 (longest request)
--

Result of
truss -c -p (pid of the working httpd process) & \
ab -c128 -n768 127.0.0.1:3080/ >&/dev/null; \
pkill -u $user -x truss
[T1 thread lib]---
syscall  seconds   calls  errors
read .201540  5
write.12 768
close.201534
brk  .31 774
times.05 768
sysi86   .02  40
fcntl.341536
sendfilev64  .28 768
poll .151540
sigaction.00  14
mmap .02  58
mprotect .07 184
lwp_sema_wait.02 283
lwp_sema_post.04 283
gettimeofday .704889
lwp_create   .02  80
lwp_continue .01  40
lwp_self .04 141
lwp_mutex_wakeup .06 205
lwp_mutex_lock   .15 971
lwp_cond_wait.05 157
lwp_cond_signal  .04 157
lwp_schedctl .00  40
signotifywait.00  43
lwp_sigredirect  .00  43
stat64   .251536
fstat64  .271536
open64   .301536768
accept   .32 768
shutdown .17 767
getsockname  .17 768
getsockopt   .201536
setsockopt   .11 768
lwp_mutex_unlock .12 768
 ---  --   
sys totals: 4.80   26839773
usr time:.58
elapsed:8.54
[T2 thread lib]---
syscall  seconds   calls  errors
read 

Re: Perchild on Solaris

2002-08-20 Thread Ian Holsman

Tsuyoshi SASAMOTO wrote:
>>some comments..
>>the stats seems high.. make sure you have the:
>>  Options FollowSymLinks
>>  AllowOverrides none
>>specified
>>also try 'AcceptMutex pthread' this worked better for my tests.
>>there may be some other things, but I would need to see your config file.
> 
> 
> Thanks... The previous config was:
>   Options All MultiViews
>   AllowOverride All
> I was interested in the "relative" comparison between T1 and T2 threads,
> so httpd.conf itself was not tuned well...

the problem is that with all the other things going on you don't get
a fair comparision of the threading systems, as you were spending all 
your time in the file system.


> 
> Under config you suggested above and so on, the result is as below.

It looks like the changes doubled your performance.. not bad for 2 lines 
  :-)
Also.. if you want to get a bit faster try preloading the 
/usr/lib/libmtmalloc.so library.
also.. have you compared perchild to worker ? (yes I know perchild isn't 
finished..I'm just curious)
> 
> 
> Tsuyoshi SASAMOTO
> [EMAIL PROTECTED]
> --
> 
> Result of
> ab -c128 -n8192 127.0.0.1:3080/
> [T1 thread lib]---
> This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
>   :
>   :
> Server Software:Apache/2.0.39
> Server Hostname:127.0.0.1
> Server Port:3080
> 
> Document Path:  /
> Document Length:1630 bytes
> 
> Concurrency Level:  128
> Time taken for tests:   14.586689 seconds
> Complete requests:  8192
> Failed requests:0
> Write errors:   0
> Total transferred:  15810560 bytes
> HTML transferred:   13352960 bytes
> Requests per second:561.61 [#/sec] (mean)
> Time per request:   227.917 [ms] (mean)
> Time per request:   1.781 [ms] (mean, across all concurrent requests)
> Transfer rate:  1058.50 [Kbytes/sec] received
> 
> Connection Times (ms)
>   min  mean[+/-sd] median   max
> Connect:00   1.3  0  84
> Processing:29  224  24.9222 442
> Waiting:3  112  65.8112 360
> Total: 29  224  25.0222 444
> 
> Percentage of the requests served within a certain time (ms)
>   50%222
>   66%223
>   75%223
>   80%223
>   90%225
>   95%240
>   98%306
>   99%310
>  100%444 (longest request)
> [T2 thread lib]---
> This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
>   :
>   :
> Server Software:Apache/2.0.39
> Server Hostname:127.0.0.1
> Server Port:3080
> 
> Document Path:  /
> Document Length:1630 bytes
> 
> Concurrency Level:  128
> Time taken for tests:   15.981754 seconds
> Complete requests:  8192
> Failed requests:0
> Write errors:   0
> Total transferred:  15810560 bytes
> HTML transferred:   13352960 bytes
> Requests per second:512.58 [#/sec] (mean)
> Time per request:   249.715 [ms] (mean)
> Time per request:   1.951 [ms] (mean, across all concurrent requests)
> Transfer rate:  966.10 [Kbytes/sec] received
> 
> Connection Times (ms)
>   min  mean[+/-sd] median   max
> Connect:00   0.7  0  58
> Processing:56  245  29.3266 398
> Waiting:3  123  71.0123 307
> Total: 56  246  29.3266 398
> 
> Percentage of the requests served within a certain time (ms)
>   50%266
>   66%267
>   75%268
>   80%268
>   90%270
>   95%271
>   98%284
>   99%285
>  100%398 (longest request)
> --
> 
> Result of
> truss -c -p (pid of the working httpd process) & \
> ab -c128 -n768 127.0.0.1:3080/ >&/dev/null; \
> pkill -u $user -x truss
> [T1 thread lib]---
> syscall  seconds   calls  errors
> read .201540  5
> write.12 768
> close.201534
> brk  .31 774
> times.05 768
> sysi86   .02  40
> fcntl.341536
> sendfilev64  .28 768
> poll .151540
> sigaction.00  14
> mmap 

Re: Perchild on Solaris

2002-08-20 Thread Tsuyoshi SASAMOTO

>It looks like the changes doubled your performance.. not bad for 2 lines 
>  :-)

Yes :-)

>Also.. if you want to get a bit faster try preloading the 
>/usr/lib/libmtmalloc.so library.
>also.. have you compared perchild to worker ? (yes I know perchild isn't 
>finished..I'm just curious)

Linked with libmtmalloc, and tested again (as below).


Tsuyoshi SASAMOTO
[EMAIL PROTECTED]
--

Result of
ab -c128 -n8192 127.0.0.1:3080/
[T1 perchild]-
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   16.129322 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15851520 bytes
HTML transferred:   13352960 bytes
Requests per second:507.89 [#/sec] (mean)
Time per request:   252.021 [ms] (mean)
Time per request:   1.969 [ms] (mean, across all concurrent requests)
Transfer rate:  959.74 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   2.6  0 175
Processing:28  249  46.2247 741
Waiting:1  130  71.7129 537
Total: 28  249  46.3247 741

Percentage of the requests served within a certain time (ms)
  50%247
  66%248
  75%249
  80%249
  90%264
  95%311
  98%408
  99%444
 100%741 (longest request)
[T2 perchild]-
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   22.792954 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15851520 bytes
HTML transferred:   13352960 bytes
Requests per second:359.41 [#/sec] (mean)
Time per request:   356.140 [ms] (mean)
Time per request:   2.782 [ms] (mean, across all concurrent requests)
Transfer rate:  679.16 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   1.9  1 117
Processing:57  351  84.03491277
Waiting:3  185 102.91881174
Total: 57  352  84.03501278

Percentage of the requests served within a certain time (ms)
  50%350
  66%394
  75%401
  80%403
  90%413
  95%459
  98%555
  99%609
 100%   1278 (longest request)
[T1 worker]---
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   18.109316 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15851520 bytes
HTML transferred:   13352960 bytes
Requests per second:452.36 [#/sec] (mean)
Time per request:   282.958 [ms] (mean)
Time per request:   2.211 [ms] (mean, across all concurrent requests)
Transfer rate:  854.81 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.9  0  50
Processing:25  280  42.6275 747
Waiting:3  144  83.8143 676
Total: 26  280  42.7275 747

Percentage of the requests served within a certain time (ms)
  50%275
  66%280
  75%281
  80%282
  90%308
  95%370
  98%407
  99%466
 100%747 (longest request)
[T2 worker]---
This is ApacheBench, Version 2.0.37-dev <$Revision: 1.105 $> apache-2.0
  :
  :
Server Software:Apache/2.0.39
Server Hostname:127.0.0.1
Server Port:3080

Document Path:  /
Document Length:1630 bytes

Concurrency Level:  128
Time taken for tests:   14.78003 seconds
Complete requests:  8192
Failed requests:0
Write errors:   0
Total transferred:  15851520 bytes
HTML transferred:   13352960 bytes
Requests per second:581.90 [#/sec] (mean)
Time per request:   219.969 [ms] (mean)
Time per request:   1.719 [ms] (mean, across all concurrent requests)
Transfer rate:  1099.59 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect: 

perchild on Darwin, hmmm

2002-08-30 Thread Jim Jagielski

Except for the poll.h header line, perchild compiled quite nicely on
Darwin (Jaguar - 10.2). Also confirmed that it serves pages. Have *NOT*
yet checked to see if the perchild specific goodies actually work yet.
Next on the list :)

Wish there were at least 5 hours more per day...  ;)
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson



perchild under Solaris 8

2002-09-10 Thread Jim Jagielski

If '-D_XPG4_2 -D__EXTENSIONS__' are added to CPPFLAGS during the configure
process, perchild will compile relatively cleanly under Solaris 8 and
result in a binary that actually serves content!! Haven't yet
playing with using the actual uid/gid aspects of perchild yet.

I'm looking to see what affects, if any, adding these by default to
APR and httpd will be... If anyone has some better experience with
these, please let me know :)

The hope is a perchild that runs, and then APR'ising it as much as
possible. The passing might be somewhat doable.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
 will lose both and deserve neither" - T.Jefferson



trouble w/ perchild MPM

2002-11-25 Thread Enrico Weigelt

hi folks

i've got some trouble with the perchild MPM in httpd-2.0.43.
Especially forwarding connections to other childs seems to be
a little bit buggy. 

an little bug in receive_from_other_child() was:

>iov[0].iov_base = headers;
>iov[0].iov_len = HUGE_STRING_LEN;
>iov[0].iov_base = request_body;
>iov[0].iov_len = HUGE_STRING_LEN;

perhaps should be:

iov[0].iov_base = headers;
iov[0].iov_len = HUGE_STRING_LEN;
iov[1].iov_base = request_body;
iov[1].iov_len = HUGE_STRING_LEN;

with this correction it mostly works, but sometimes the connection
passing fails, no child seems to receive the connection. 

also there are some other strange things:

* on connection forwarding, in the receiving child, perchild_post_read()
  is called twice, first w/ the right request, then an empty one.
  i've modified the code to drop these requests (return DECLINE;)

* sometimes the socket fd (sock->socketdes) changes on return 
  from receive_from_other_child() to worker_thread to an 
  enormously high number (i.e.136489464)
  
could anyone help ? 

~-n
--
Bestes Mittel gegen Mailviren: Outlook löschen.
-
 Enrico Weigelt==   metux ITS 
 Webhosting ab 5 EUR/Monat.  UUCP, rawIP und vieles mehr.

 phone: +49 36207 519931 www:   http://www.metux.de/ 
 fax:   +49 36207 519932 email: [EMAIL PROTECTED]
 cellphone: +49 174 7066481  smsgate:   [EMAIL PROTECTED]
-
 Diese Mail wurde mit UUCP versandt.  http://www.metux.de/uucp/



Re: MPM perchild againg

2002-11-26 Thread Johannes Erdfelt
On Tue, Nov 26, 2002, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> it seems that under some circumstances the messages for connection
> passing between childs are not received at the destination process.
> sometimes it also happened, that apr_poll() returned w/o error, 
> but scan through the listener list does not find the touched socket.
> perhaps there's a leak in the listener list. where could it be modified ? 
> should the pollset better be recreated before each poll ?

What version of the perchild MPM are you using?

There were some significant bugs earlier that I've fixed, but there's
still one significant bug that prevents perchild from being useful.

JE




SV: MPM perchild againg

2002-11-26 Thread Jonas Eriksson

I'm usning 

Revision 1.136  

./configure  --enable-so --prefix=/usr/local/apache2.0.43
--with-mpm=perchild


On Tue, Nov 26, 2002, Enrico Weigelt <[EMAIL PROTECTED]> wrote:
> it seems that under some circumstances the messages for connection
> passing between childs are not received at the destination process.
> sometimes it also happened, that apr_poll() returned w/o error, 
> but scan through the listener list does not find the touched socket.
> perhaps there's a leak in the listener list. where could it be
modified ? 
> should the pollset better be recreated before each poll ?

What version of the perchild MPM are you using?

There were some significant bugs earlier that I've fixed, but there's
still one significant bug that prevents perchild from being useful.

JE





Re: SV: MPM perchild.

2002-11-26 Thread Johannes Erdfelt
That looks about good.

Do you only have one child defined?

JE

On Tue, Nov 26, 2002, Jonas Eriksson <[EMAIL PROTECTED]> wrote:
> 
> 
> Hmm sorry! I did a bougus error in http.conf ...
> 
> When i now start the server i get the following in my shell promt and
> the server starts.
> What does the debug info tell? Is it all ok or do i have to change
> anyting?
> 
> [root@mose /usr/local/apache2.0.43/bin]# ./httpd -f
> /usr/local/apache2.0.43/conf/httpd.conf
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 0
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 1
> [Tue Nov 26 18:35:41 2002] [debug] perchild.c(2007): filling out
> child_info_table; UID: 1096, GID: 1094, SD: 4 4, OUTPUT: 5 5, Child Num:
> 2
>  
> 
> 
> 
> On Tue, Nov 26, 2002, Jonas Eriksson <[EMAIL PROTECTED]> wrote:
> > I Still get error "Unable to find process with matching uid/gid."
> > after compileing 2.43 with
> >
> http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/mpm/experimental/perc
> > hild/perchild.c
> 
> Are you sure you configured your setup correctly?
> 
> Do you have a ChildPerUserId before you use AssignUserId?
> 
> Can you give us the configuration you're using?
> 
> JE
> 
> 



looking for mpm-perchild info

2004-05-20 Thread Binam, Jesse
I apologize if this is the wrong forum. I saw in the documentation that the perchild 
mpm development has ceased. I have looked on apache.org for info but did not find 
anything. I am curious if anyone in here can tell me where else I might look for 
information on why it stopped, as I would like to investigate the possibility of 
giving it another go at life.

Jess


Re: mpm perchild and mod_php4

2002-12-08 Thread Johannes Erdfelt
On Sun, Dec 08, 2002, Jochen Kächelin <[EMAIL PROTECTED]> wrote:
> Can somebody give me hint how to get Apache 2.0.43, perchild
> and mod_php4 running to do some testing?

perchild is broken right now. Unless you're willing to do some coding,
don't expect it to work :/

However, it appears that you're having some other problems as well since
the bugs in perchild I know of wouldn't cause a segfault.

> error_log:
> 
> [Sun Dec 08 16:03:03 2002] [notice] child pid 21526 exit signal Segmentation fault 
>(11)
> [Sun Dec 08 16:03:03 2002] [notice] child pid 21524 exit signal Segmentation fault 
>(11)
> [Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock 
>failed. Attempting to shutdown process
> gracefully.
> [Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
>failed. Attempting to shutdown process
> gracefully.
> [Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_lock 
>failed. Attempting to shutdown process
> gracefully.
> [Sun Dec 08 16:03:03 2002] [emerg] (13)Permission denied: apr_proc_mutex_unlock 
>failed. Attempting to shutdown process
> gracefully.

JE




Re: mpm perchild and mod_php4

2002-12-08 Thread Colm MacCárthaigh
On Sun, Dec 08, 2002 at 10:57:32PM +0100, Jochen Kächelin wrote:
> Will perchild work on the next release or are there any other
> workarounds to secure php-scripts (module) such as suEXEC and cgis?

if you *need* mod_php instances that run as seperate users the
easiest solution is to reverse proxy instances of Apache
running on different ports (and ideally, only listening on 
localhost), each running as the desired user.

To make the most of it use mod_rewrite and mod_proxy, and try
to avoid proxying non-dynamic content for the sake of 
efficiency.

There are some disadvantges, the only access you have to
the originating IP address is HTTP_X_FORWARDED_FOR, it's
a lot more management and can complicate scripts if they
rely on thigns like SERVER_NAME. 

-- 
[EMAIL PROTECTED]PubKey: [EMAIL PROTECTED]  
Web: http://devnull.redbrick.dcu.ie/ 



Fwd: [users@httpd] MPM Perchild

2003-02-28 Thread kenwood
I have already post this message to [EMAIL PROTECTED] and got no answer.
May be here anyone help me...
---
Hello!

>From "http://httpd.apache.org/docs-2.0/mod/perchild.html":
This MPM does not currently work on most platforms. Work is ongoing to make it 
functional. 


Anyone knows, what I need to make it functional? On what platforms does it 
work? 

When new releases of apache 2.0 are expected with MPM "Perchild" working on an 
ordinary linux distributives?

Thank in advance,
Admin of DGAP MIPT.


-
Письмо отправлено с сайта Факультета Общей и Прикладной Физики МФТИ ( 
http://www.dgap.mipt.ru/ )



does perchild work in Linux?

2003-08-14 Thread Jeremy Hansen

I've been trying to use perchild and I've been looking for information on 
whether this is actually work or not.  I realize this is an experimental 
module but I'm just trying to eliminate the possibility that it's a 
configuration problem vs. a broken module.

As soon as I assign more then one ChildPerUserID and coresponding virtual 
host, apache just hangs and will no longer serve our pages.

I see the processes for each ChildPerUserID in ps.

If someone says, yes, this is broken, swell, but I'm just trying to be 
sure I'm not just doing something wrong in my config. 

Here is my config for perchild:

AcceptMutex  fcntl
LockFile logs/accept.lock
ServerLimit  100
NumServers   20
StartThreads 10
MinSpareThreads  10
MaxSpareThreads 20
MaxThreadsPerChild  40
MaxRequestsPerChild  0

ChildPerUserID virtual virtual 2
ChildPerUserID methsea methsea 2
ChildPerUserID ssltest ssltest 2

and here is an example of one of my virtual hosts:


# SuexecUserGroup methsea methsea
AssignUserID methsea methsea
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/WWW/methanesea.com/htdocs
ServerName methanesea.com
ServerAlias www.methanesea.com
ErrorLog /var/log/httpd/methanesea.com/error_log
CustomLog /var/log/httpd/methanesea.com/access_log combined
ScriptAlias /cgi-bin/ /home/WWW/methanesea.com/cgi-bin/


Thanks for any feed back.

-jeremy



Re: State of perchild MPM

2007-01-29 Thread William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
> 
> 2. If there is, do the developers need help with it?  I can write C and I am 
> willing to help out with this.  If there is not, Would anyone from the Apache 
> team be interested in working with me so I may write such functionality, 
> maybe for a future version of Apache?

The module, at

http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/server/mpm/experimental/perchild/

was never ported to the API in trunk.

It uses unix domain sockets to replicate the request into a per-host process.
This is necessary because we don't trust a root process to parse and dispatch
the requests.  This provides a certain process separation and a more secure
model, but had various complications.

If it's something you and others would like to work on, I personally have no
problem reviving it to trunk/ (once ported to the current API), with the
understanding that until it has a small community around its maintenance, it
will not hit a release branch.

The biggest complication was SSL communications; the protocol level handlers
did not have an easy time passing off the request.  Perhaps the problemset
was wrong - perhaps we didn't want to try to pass these off, only properly
isolate the protocol layer from the content layer.

Bill


Re: State of perchild MPM

2007-01-29 Thread William A. Rowe, Jr.
William A. Rowe, Jr. wrote:
> [EMAIL PROTECTED] wrote:
>> 2. If there is, do the developers need help with it?  I can write C and I am 
>> willing to help out with this.  If there is not, Would anyone from the 
>> Apache team be interested in working with me so I may write such 
>> functionality, maybe for a future version of Apache?
> 
> The module, at
> 
> http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/server/mpm/experimental/perchild/
> 
> was never ported to the API in trunk.

My bad...

http://svn.apache.org/repos/asf/httpd/httpd/trunk/server/mpm/experimental/perchild/

Patches, as I mentioned, are welcome!


Re: State of perchild MPM

2007-01-30 Thread Nick Kew
On Mon, 29 Jan 2007 20:31:40 -0600
<[EMAIL PROTECTED]> wrote:

> 
> I have gotten the impression this may be a sore subject for the list
> based on searching through the archives, but I do not intend to work
> anyone up.  I have been trying to find a solution to the problem of
> shared hosting with a dynamic language such as PHP.  I found the old
> perchild MPM and it appears it is not being maintained or there was
> possibly a design problem.  I would like to know two things.
> 
> 1. Is there a mechanism (other than suexec) that allows functionality
> similar to perchild, that will allow a uid to be assigned on a per
> request basis?

There are several third-party solutions: google for metux, peruser,
mod_ruid, and fastcgi.

> 2. If there is, do the developers need help with it?  I can write C
> and I am willing to help out with this.  If there is not, Would
> anyone from the Apache team be interested in working with me so I may
> write such functionality, maybe for a future version of Apache?

Patches welcome.

Bear in mind that perchild was threaded, and therefore never
likely to be suitable for php.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/


Re: State of perchild MPM

2007-01-31 Thread Arnold Daniels

Hi,

We run a shared hosting company as well and taken upon the route to 
patch the linux kernel to allow switching of user of the current 
process. An apache module allows you to switch the process based on the 
virtual host. Our current module also implements mass virtual hosting, 
but any open source module should also work with normal vhost files.


We've been discussing this in the PHP internals mailing list and are 
preparing an open source solution, which can be tested by interested 
parties. Please read the message below, where security concerns of the 
PHP are addressed. I'll be sure to post a message on the apache list 
when the patch is made ready for public viewing.


Best regards,

Arnold Daniels
Javeline (www.javeline.net)

-

Rik Arends schreef:

Hi Andi,

I'm Rik Arends, i co-wrote the kernel patch + apache module for 
in-process user switching.

After reading your concerns i might shed some light on these issues.

First of all, i know that there are some possible security holes with 
this system.
One of the biggest problems i could see is triggering a bufferoverflow 
in mod_php, so the user can get its own assembler code to run.
Then by knowing how to do the kernel calls, he could, theoretically 
switch the user of the process back to www-data, after which he could 
switch to
any 'shared hosting user' (not just any user) in the system to access 
their shared hosting files.
The complexity of this hack, plus that your apaches will be 
segfaulting continously while a person is trying this might not make 
it too plausible to happen.
Second, the main system would not be at risk, just some of the shared 
hosting users-files that might be accessed. In 99.99% of the cases, 
there really is not all that much to steal and the amount of effort to 
actually hack this is pretty huge and requires exploitation of a 
hardcore hole in an in-process scripting engine (mod_php for 
instance), plus the knowledge on how to trigger the right kernel 
calls, and the userID's to switch to (which, unless the user somehow 
gained shell access to his targets directory he has no clue about)


The same way i think we can approach the, the 'resources that are 
still open from other users' hole, if it might be there. I expect 
mod_php or other modules to do proper cleanup of their handles or else 
they would be leaking a lot in an apache process thats being reused. 
This is not a new problem, and also a very very difficult one to 
succesfully exploit.
Say we have 256 apache processes with user switching. You are 
targetting site X running on the 'same machine'. Then you'd have to 
poll continously and hope you are served by an apache process that 
also served the other site AND know which resources to access, and how 
to do that. Please note that you can only use the resource leak bug 
when you are using an in-process scripting engine so you cant just go 
poke around your memory. This same 'bug' if you will is also there in 
shared hosting structures with reused apache processes that don't do 
user switching at all. Again the risk of this exploit actually being 
used seems well, remote. Add to this the fact that in shared hosting 
environments, nobody runs any security critical applications such as 
full creditcard payment systems. For that people employ their own 
server with SSL and certificates. That is just beyond the scale of 
shared hosting.


I hope i might have lessened your concerns. I think the security risk 
our patch poses is mostly theoretical, have a very difficult exploit 
route and in almost all cases have a 0 to almost nil payoff. Its much  
much simpler to try to hack the other persons site via bugs in forms 
or other installed applications.


Regards,

Rik Arends




 Originele bericht 
Onderwerp: RE: [PHP-DEV] Comments on PHP security
Datum: Thu, 18 Jan 2007 14:14:17 -0800
Van: Andi Gutmans <[EMAIL PROTECTED]>
Aan: 'Arnold Daniels' <[EMAIL PROTECTED]>, 



I haven't seen the patch yet but my concern would be with resources 
which have already been opened. Unless you guys clean that up in
between requests it can be very dangerous as I doubt Linux 
re-verify's permissions when those are accessed. In any case, I'd be

happy to review and might be completely wrong...




-

Nick Kew schreef:

On Mon, 29 Jan 2007 20:31:40 -0600
<[EMAIL PROTECTED]> wrote:

  

I have gotten the impression this may be a sore subject for the list
based on searching through the archives, but I do not intend to work
anyone up.  I have been trying to find a solution to the problem of
shared hosting with a dynamic language such as PHP.  I found the old
perchild MPM and it appears it is not being maintained or there was
possibly a design problem.  I would like to know two things.

1. Is there a mechanism (other than suexec) that allows

Re: State of perchild MPM

2007-01-31 Thread Ivan Ristic
 Its much  much simpler to
try to hack the other persons site via bugs in forms or other installed
applications.

 Regards,

 Rik Arends




  Originele bericht 
 Onderwerp: RE: [PHP-DEV] Comments on PHP security
 Datum: Thu, 18 Jan 2007 14:14:17 -0800
 Van: Andi Gutmans <[EMAIL PROTECTED]>
 Aan: 'Arnold Daniels' <[EMAIL PROTECTED]>, 



 I haven't seen the patch yet but my concern would be with resources which
have already been opened. Unless you guys clean that up in
 between requests it can be very dangerous as I doubt Linux re-verify's
permissions when those are accessed. In any case, I'd be
 happy to review and might be completely wrong...


 -

 Nick Kew schreef:
 On Mon, 29 Jan 2007 20:31:40 -0600
<[EMAIL PROTECTED]> wrote:



 I have gotten the impression this may be a sore subject for the list
based on searching through the archives, but I do not intend to work
anyone up. I have been trying to find a solution to the problem of
shared hosting with a dynamic language such as PHP. I found the old
perchild MPM and it appears it is not being maintained or there was
possibly a design problem. I would like to know two things.

1. Is there a mechanism (other than suexec) that allows functionality
similar to perchild, that will allow a uid to be assigned on a per
request basis?

 There are several third-party solutions: google for metux, peruser,
mod_ruid, and fastcgi.



 2. If there is, do the developers need help with it? I can write C
and I am willing to help out with this. If there is not, Would
anyone from the Apache team be interested in working with me so I may
write such functionality, maybe for a future version of Apache?

 Patches welcome.

Bear in mind that perchild was threaded, and therefore never
likely to be suitable for php.






--
Ivan Ristic


Re: State of perchild MPM

2007-01-31 Thread Arnold Daniels

Hi,

I can't answer all your questions, since I'm not the developer of the 
patch and module. I've forwarded this message to Rik Arends. But let me 
answer the onces I can.


We've looked at running PHP as CGI, but we've noticed a performance drop 
compared to running PHP as module, effectively being able to run 25% to 
30% less accounts on a server, which is significant when you're running 
discount hosting.


Besides this performance drop, running PHP as CGI doesn't really solve 
the problem. We run about 300 customers per server. All of which have 
their own system user, the 'shared hosting users'. We want all files, 
PHP files as well as HTML files, images, etc, to be owned by the shared 
hosting user without privileges for others (660). For Apache to handle a 
request, it needs to run under that user instead of www-data. We tried 
the perchild, but starting a new apache process for just about each 
request, promoted serious performance issues (I don't have the figures 
at hand, but it wasn't an option) as well as not being stable.


It's not common for a setup like this to offer SSL, since it requires an 
unique IP address to be save. The module currently also implements mass 
virtual hosting, making it even impossible to support SSL.


You do not need a secret, but the users who may changed are specified. 
In our setup user 'www-data', which has no privileges on the server, may 
change into any shared hosting user. Within the process where www-data 
changed into the shared hosting user, a call can be made to change back 
into 'www-data'. Since running a CGI script starts a new process, it is 
not possible for a shared hosting user to change into 'www-data' using a 
custom CGI script.


We don't log to file, but use UDP, still the same goes. A hacker can't 
really accomplish anything with writing data to the log, except maybe a 
bit of vandalism. Perhaps you give some examples on how the file 
descriptors can be used to take over the network sockets.


We are aware that the solution might not yet be solid, be we think the 
approach is the right way to go. Of course, we're currently enjoying 
security by obscurity, but with your help and other experts on Apache 
internals, we should be able to make this into a good solution.


Best regards,
Arnold


Ivan Ristic schreef:

Hi Arnold,

You have obviously spent a great deal of time implementing your
solution. Personally I have always felt complete separation (e.g. what
is done with FastCGI) is a more robust approach. But I don't think the
issues surrounding the choices have been discussed enough in the
public. If you don't mind I would appreciate if you could share your
opinions and experiences.

In particular, I am wondering if and how are you handling the issue of
"leaked" Apache file descriptors (under quotes because they are not
really leaked - it's the same process)? These file descriptors can be
abused to, for example, log to the Apache log files and take over the
network sockets.

The other issue is the users loading custom shared libraries to gain
direct access to the process memory and then extract sensitive
information from it (e.g. SSL keys).

Other questions that come to mind:

1) Have you ever evaluated a FastCGI-based approach?

2) Have you ever measured the performance increase you gain with your
solution (as opposed to having a "pure" suExec-based approach)?

3) Do you require a secret of some kind to change users? For example,
can I change the user from custom CGI script or a binary executed from
PHP?

Thanks,
Ivan

On 1/31/07, Arnold Daniels <[EMAIL PROTECTED]> wrote:


 Hi,

We run a shared hosting company as well and taken upon the route to 
patch

the linux kernel to allow switching of user of the current process. An
apache module allows you to switch the process based on the virtual 
host.
Our current module also implements mass virtual hosting, but any open 
source

module should also work with normal vhost files.

 We've been discussing this in the PHP internals mailing list and are
preparing an open source solution, which can be tested by interested
parties. Please read the message below, where security concerns of 
the PHP
are addressed. I'll be sure to post a message on the apache list when 
the

patch is made ready for public viewing.

 Best regards,

 Arnold Daniels
 Javeline (www.javeline.net)

 -

 Rik Arends schreef:
Hi Andi,

 I'm Rik Arends, i co-wrote the kernel patch + apache module for 
in-process

user switching.
 After reading your concerns i might shed some light on these issues.

 First of all, i know that there are some possible security holes 
with this

system.
 One of the biggest problems i could see is triggering a 
bufferoverflow in

mod_php, so the user can get its own assembler code to run.
 Then by knowing how to do the

Re: State of perchild MPM

2007-02-01 Thread Enrico Weigelt
* Nick Kew <[EMAIL PROTECTED]> wrote:
> On Mon, 29 Jan 2007 20:31:40 -0600
> <[EMAIL PROTECTED]> wrote:
> 
> > 
> > I have gotten the impression this may be a sore subject for the list
> > based on searching through the archives, but I do not intend to work
> > anyone up.  I have been trying to find a solution to the problem of
> > shared hosting with a dynamic language such as PHP.  I found the old
> > perchild MPM and it appears it is not being maintained or there was
> > possibly a design problem.  I would like to know two things.
> > 
> > 1. Is there a mechanism (other than suexec) that allows functionality
> > similar to perchild, that will allow a uid to be assigned on a per
> > request basis?
> 
> There are several third-party solutions: google for metux, peruser,
> mod_ruid, and fastcgi.

Quite a bit outdated:

http://mpm.metux.de


cu
-- 
-
 Enrico Weigelt==   metux IT service

  phone: +49 36207 519931 www:   http://www.metux.de/
  fax:   +49 36207 519932 email: [EMAIL PROTECTED]
  cellphone: +49 174 7066481
-
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
-


Re: State of perchild MPM

2007-02-02 Thread Ivan Ristic

Comments below.

On 1/31/07, Arnold Daniels <[EMAIL PROTECTED]> wrote:

Hi,

I can't answer all your questions, since I'm not the developer of the
patch and module. I've forwarded this message to Rik Arends. But let me
answer the onces I can.

We've looked at running PHP as CGI, but we've noticed a performance drop
compared to running PHP as module, effectively being able to run 25% to
30% less accounts on a server, which is significant when you're running
discount hosting.

Besides this performance drop, running PHP as CGI doesn't really solve
the problem. We run about 300 customers per server. All of which have
their own system user, the 'shared hosting users'. We want all files,
PHP files as well as HTML files, images, etc, to be owned by the shared
hosting user without privileges for others (660). For Apache to handle a
request, it needs to run under that user instead of www-data.


That should be possible to do using suExec and some juggling of file
permissions. Although it does create a problem where the user scripts
run as also has write permissions over all files. I prefer to use two
accounts, one to manipulate the files with, the other to execute
scripts with. But this is difficult to pull off with mass hosting.



We tried
the perchild, but starting a new apache process for just about each
request, promoted serious performance issues (I don't have the figures
at hand, but it wasn't an option) as well as not being stable.

It's not common for a setup like this to offer SSL, since it requires an
unique IP address to be save. The module currently also implements mass
virtual hosting, making it even impossible to support SSL.

You do not need a secret, but the users who may changed are specified.
In our setup user 'www-data', which has no privileges on the server, may
change into any shared hosting user. Within the process where www-data
changed into the shared hosting user, a call can be made to change back
into 'www-data'. Since running a CGI script starts a new process, it is
not possible for a shared hosting user to change into 'www-data' using a
custom CGI script.


Good. Still, if you allow PHP users to load their own code from shared
libraries they'll be able to revert back to the www-data user.



We don't log to file, but use UDP, still the same goes. A hacker can't
really accomplish anything with writing data to the log, except maybe a
bit of vandalism.


I actually think that is a very serious problem. With the ability to
add to the access logs someone could frame a person for hacking.



Perhaps you give some examples on how the file
descriptors can be used to take over the network sockets.


I haven't tried to exploit the issue myself but, from memory, I
believe it is enough to duplicate the original descriptor, close the
original (thus preventing Apache from using it), and then serve your
own stuff using the duplicate.

The last time I looked PHP leaked file descriptors even on execution
of external binaries, making it trivial to exploit the issue provided
external command execution is allowed.

Disclaimer: I played with this two years ago. It might have been
silently fixed since then. But with a large number of different
versions of Apache and PHP in deployment the only way to be sure is to
test. I recommend env_audit (http://www.web-insights.net/env_audit/).



We are aware that the solution might not yet be solid, be we think the
approach is the right way to go. Of course, we're currently enjoying
security by obscurity, but with your help and other experts on Apache
internals, we should be able to make this into a good solution.

Best regards,
Arnold


Ivan Ristic schreef:
> Hi Arnold,
>
> You have obviously spent a great deal of time implementing your
> solution. Personally I have always felt complete separation (e.g. what
> is done with FastCGI) is a more robust approach. But I don't think the
> issues surrounding the choices have been discussed enough in the
> public. If you don't mind I would appreciate if you could share your
> opinions and experiences.
>
> In particular, I am wondering if and how are you handling the issue of
> "leaked" Apache file descriptors (under quotes because they are not
> really leaked - it's the same process)? These file descriptors can be
> abused to, for example, log to the Apache log files and take over the
> network sockets.
>
> The other issue is the users loading custom shared libraries to gain
> direct access to the process memory and then extract sensitive
> information from it (e.g. SSL keys).
>
> Other questions that come to mind:
>
> 1) Have you ever evaluated a FastCGI-based approach?
>
> 2) Have you ever measured the performance increase you gain with your
> solution (as opposed to having a "pure" suEx

Re: State of perchild MPM

2007-02-02 Thread Arnold Daniels

Hi,

Comments below.

Arnold

Ivan Ristic schreef:

Comments below.

On 1/31/07, Arnold Daniels <[EMAIL PROTECTED]> wrote:

Hi,

I can't answer all your questions, since I'm not the developer of the
patch and module. I've forwarded this message to Rik Arends. But let me
answer the onces I can.

We've looked at running PHP as CGI, but we've noticed a performance drop
compared to running PHP as module, effectively being able to run 25% to
30% less accounts on a server, which is significant when you're running
discount hosting.

Besides this performance drop, running PHP as CGI doesn't really solve
the problem. We run about 300 customers per server. All of which have
their own system user, the 'shared hosting users'. We want all files,
PHP files as well as HTML files, images, etc, to be owned by the shared
hosting user without privileges for others (660). For Apache to handle a
request, it needs to run under that user instead of www-data.


That should be possible to do using suExec and some juggling of file
permissions. Although it does create a problem where the user scripts
run as also has write permissions over all files. I prefer to use two
accounts, one to manipulate the files with, the other to execute
scripts with. But this is difficult to pull off with mass hosting.

I don't directly see how this is done. Anyway our customers upload their 
own files, so we can't control the permission flags of each file. The 
fact that the webroot directory doesn't have execute permissions for 
others, prevents other users from accessing the files. We recommend 
users to set privileges on 660, but this is not always the case.



We tried
the perchild, but starting a new apache process for just about each
request, promoted serious performance issues (I don't have the figures
at hand, but it wasn't an option) as well as not being stable.

It's not common for a setup like this to offer SSL, since it requires an
unique IP address to be save. The module currently also implements mass
virtual hosting, making it even impossible to support SSL.

You do not need a secret, but the users who may changed are specified.
In our setup user 'www-data', which has no privileges on the server, may
change into any shared hosting user. Within the process where www-data
changed into the shared hosting user, a call can be made to change back
into 'www-data'. Since running a CGI script starts a new process, it is
not possible for a shared hosting user to change into 'www-data' using a
custom CGI script.


Good. Still, if you allow PHP users to load their own code from shared
libraries they'll be able to revert back to the www-data user.

Due to permissions it isn't possible for customers to place any files in 
the extension directory and PHP won't load any binaries outside that 
directory. Anyhow it is highly recommended that dl() is disabled. Which 
is the case on our system.



We don't log to file, but use UDP, still the same goes. A hacker can't
really accomplish anything with writing data to the log, except maybe a
bit of vandalism.


I actually think that is a very serious problem. With the ability to
add to the access logs someone could frame a person for hacking.

I'm not sure how the privileges of the access log are currently set on 
our system. But the access log could of course be written by www-data, 
so before the user is switched, which solves the problem.



Perhaps you give some examples on how the file
descriptors can be used to take over the network sockets.


I haven't tried to exploit the issue myself but, from memory, I
believe it is enough to duplicate the original descriptor, close the
original (thus preventing Apache from using it), and then serve your
own stuff using the duplicate.

The last time I looked PHP leaked file descriptors even on execution
of external binaries, making it trivial to exploit the issue provided
external command execution is allowed.

Disclaimer: I played with this two years ago. It might have been
silently fixed since then. But with a large number of different
versions of Apache and PHP in deployment the only way to be sure is to
test. I recommend env_audit (http://www.web-insights.net/env_audit/).

Perhaps you could help to look into this. It doesn't look like an 
insolvable problem.


We are aware that the solution might not yet be solid, be we think the
approach is the right way to go. Of course, we're currently enjoying
security by obscurity, but with your help and other experts on Apache
internals, we should be able to make this into a good solution.

Best regards,
Arnold


Ivan Ristic schreef:
> Hi Arnold,
>
> You have obviously spent a great deal of time implementing your
> solution. Personally I have always felt complete separation (e.g. what
> is done with FastCGI) is a more robust approach. But I don'

Re: State of perchild MPM

2007-02-05 Thread Ivan Ristic

[Let's continue the discussion privately from now on as it's becoming
less relevant for the httpd project...]

On 2/2/07, Arnold Daniels <[EMAIL PROTECTED]> wrote:


...

>> You do not need a secret, but the users who may changed are specified.
>> In our setup user 'www-data', which has no privileges on the server, may
>> change into any shared hosting user. Within the process where www-data
>> changed into the shared hosting user, a call can be made to change back
>> into 'www-data'. Since running a CGI script starts a new process, it is
>> not possible for a shared hosting user to change into 'www-data' using a
>> custom CGI script.
>
> Good. Still, if you allow PHP users to load their own code from shared
> libraries they'll be able to revert back to the www-data user.
>
Due to permissions it isn't possible for customers to place any files in
the extension directory and PHP won't load any binaries outside that
directory. Anyhow it is highly recommended that dl() is disabled. Which
is the case on our system.


Good. Still, you are relying on mod_php to enforce certain
restrictions. I prefer a mechanism where you can deploy securely with
any module and any module configuration.



>> We don't log to file, but use UDP, still the same goes. A hacker can't
>> really accomplish anything with writing data to the log, except maybe a
>> bit of vandalism.
>
> I actually think that is a very serious problem. With the ability to
> add to the access logs someone could frame a person for hacking.
>
I'm not sure how the privileges of the access log are currently set on
our system. But the access log could of course be written by www-data,
so before the user is switched, which solves the problem.


If you are using syslog/UDP then, because syslog lacks authentication,
any user can fake an access log entry. As for the access log
permissions - root should be the only user allowed write access.

Either way, if a file descriptor is inherited then any user can write
to it (permissions of the user that opened the FD are used).

--
Ivan Ristic


Re: State of perchild MPM

2007-02-05 Thread devkit1
ht 
>>> Onderwerp: RE: [PHP-DEV] Comments on PHP security
>>> Datum: Thu, 18 Jan 2007 14:14:17 -0800
>>> Van: Andi Gutmans <[EMAIL PROTECTED]>
>>> Aan: 'Arnold Daniels' <[EMAIL PROTECTED]>, 
>>>
>>>
>>>
>>> I haven't seen the patch yet but my concern would be with resources
>>> which have already been opened. Unless you guys clean that up in
>>> between requests it can be very dangerous as I doubt Linux
>>> re-verify's permissions when those are accessed. In any case, I'd be
>>> happy to review and might be completely wrong...
>>>
>>
> -
> 
> Nick Kew schreef:
>> On Mon, 29 Jan 2007 20:31:40 -0600
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I have gotten the impression this may be a sore subject for the list
>>> based on searching through the archives, but I do not intend to work
>>> anyone up.  I have been trying to find a solution to the problem of
>>> shared hosting with a dynamic language such as PHP.  I found the old
>>> perchild MPM and it appears it is not being maintained or there was
>>> possibly a design problem.  I would like to know two things.
>>>
>>> 1. Is there a mechanism (other than suexec) that allows functionality
>>> similar to perchild, that will allow a uid to be assigned on a per
>>> request basis?
>>>
>>
>> There are several third-party solutions: google for metux, peruser,
>> mod_ruid, and fastcgi.
>>
>>
>>> 2. If there is, do the developers need help with it?  I can write C
>>> and I am willing to help out with this.  If there is not, Would
>>> anyone from the Apache team be interested in working with me so I may
>>> write such functionality, maybe for a future version of Apache?
>>>
>>
>> Patches welcome.
>>
>> Bear in mind that perchild was threaded, and therefore never
>> likely to be suitable for php.
>>
>>
> 
> 



Re: State of perchild MPM

2007-02-05 Thread devkit1
nless you guys clean that up in
>>> between requests it can be very dangerous as I doubt Linux
>>> re-verify's permissions when those are accessed. In any case, I'd be
>>> happy to review and might be completely wrong...
>>>
>>
> -
> 
> Nick Kew schreef:
>> On Mon, 29 Jan 2007 20:31:40 -0600
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I have gotten the impression this may be a sore subject for the list
>>> based on searching through the archives, but I do not intend to work
>>> anyone up.  I have been trying to find a solution to the problem of
>>> shared hosting with a dynamic language such as PHP.  I found the old
>>> perchild MPM and it appears it is not being maintained or there was
>>> possibly a design problem.  I would like to know two things.
>>>
>>> 1. Is there a mechanism (other than suexec) that allows functionality
>>> similar to perchild, that will allow a uid to be assigned on a per
>>> request basis?
>>>
>>
>> There are several third-party solutions: google for metux, peruser,
>> mod_ruid, and fastcgi.
>>
>>
>>> 2. If there is, do the developers need help with it?  I can write C
>>> and I am willing to help out with this.  If there is not, Would
>>> anyone from the Apache team be interested in working with me so I may
>>> write such functionality, maybe for a future version of Apache?
>>>
>>
>> Patches welcome.
>>
>> Bear in mind that perchild was threaded, and therefore never
>> likely to be suitable for php.
>>
>>
> 
> 



Re[2]: MPM-Module perchild

2009-11-26 Thread christian4apache
>> ... we need the MPM module perchild ...
> ... http://mpm-itk.sesse.net/ ...

The mpm-itk is what we search,

Thanks



2.0.24 and ssl and perchild

2001-08-24 Thread Gomez Henri

The problem I related previously appears only when using --with-mpm=perchild
No problem with threaded or worker

===>

ssl_engine_rand.c: In function `ssl_rand_seed':
ssl_engine_rand.c:154: `ap_scoreboard_image' undeclared (first use in this
function)
ssl_engine_rand.c:154: (Each undeclared identifier is reported only once
ssl_engine_rand.c:154: for each function it appears in.)
ssl_engine_rand.c:155: `SCOREBOARD_SIZE' undeclared (first use in this
function)
make[4]: *** [ssl_engine_rand.slo] Error 1
make[4]: Leaving directory `/usr/src/redhat/BUILD/httpd-2_0_24/modules/ssl'
make[3]: *** [shared-build-recursive] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/httpd-2_0_24/modules/ssl'
make[2]: *** [shared-build-recursive] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/httpd-2_0_24/modules'
make[1]: *** [shared-build-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/httpd-2_0_24'
make: *** [all-recursive] Error 1
Bad exit status from /var/tmp/rpm-tmp.81533 (%build)

<

Any idea ?






[PATCH] fix setjmp in perchild

2001-12-18 Thread Aaron Bannert

My setjmp man page on Linux says it returns zero or non-zero, so is
this patch more correct?


Index: server/mpm/perchild/perchild.c
===
RCS file: /home/cvs/httpd-2.0/server/mpm/perchild/perchild.c,v
retrieving revision 1.93
diff -u -u -r1.93 perchild.c
--- server/mpm/perchild/perchild.c  2001/12/19 01:22:03 1.93
+++ server/mpm/perchild/perchild.c  2001/12/19 01:22:21
@@ -807,7 +807,7 @@
 thread_socket_table[thread_num] = dp;
 apr_os_sock_put(&csd, &child_info_table[child_num].sd, ptrans);
 }
-if (setjmp(jmpbuffer) != 1) {
+if (!setjmp(jmpbuffer)) {
 process_socket(ptrans, csd, conn_id);
 }
 else {

-aaron



Re: Move perchild to experimental?

2002-04-16 Thread Aaron Bannert

On Tue, Apr 16, 2002 at 04:37:45PM -0700, Justin Erenkrantz wrote:
> Would people have issues if we move perchild to experimental?
> 
> We're getting a number of PRs related to perchild because it isn't
> working.  For the next release, I think it would be a bit better if
> we made it somewhat obvious that perchild isn't expected to
> work.  -- justin

++1

-a



Re: Move perchild to experimental?

2002-04-16 Thread Brian Pane

Aaron Bannert wrote:

>On Tue, Apr 16, 2002 at 04:37:45PM -0700, Justin Erenkrantz wrote:
>
>>Would people have issues if we move perchild to experimental?
>>
>>We're getting a number of PRs related to perchild because it isn't
>>working.  For the next release, I think it would be a bit better if
>>we made it somewhat obvious that perchild isn't expected to
>>work.  -- justin
>>
>
>++1
>

+1

--Brian





Re: Move perchild to experimental?

2002-04-16 Thread Roy T. Fielding

+1

Roy




RE: Move perchild to experimental?

2002-04-16 Thread Sander Striker

+1

Sander



Re: Move perchild to experimental?

2002-04-17 Thread Justin Erenkrantz

On Tue, Apr 16, 2002 at 04:37:45PM -0700, Justin Erenkrantz wrote:
> Would people have issues if we move perchild to experimental?

Okay, so it seems we have consensus to move it.

Uh, how do we move it?

- Delete it and re-add them in the new directory
- Move the .v files on icarus

Thoughts?  -- justin



Re: Move perchild to experimental?

2002-04-17 Thread Aaron Bannert

On Wed, Apr 17, 2002 at 03:10:10PM -0700, Justin Erenkrantz wrote:
> Okay, so it seems we have consensus to move it.
> 
> Uh, how do we move it?
> 
> - Delete it and re-add them in the new directory
> - Move the .v files on icarus

If you move the ,v files you'll be messing with history, how about just
delete and add?

*cough*svn could probably do it*cough*

-aaron



RE: Move perchild to experimental?

2002-04-17 Thread Ryan Bloom

I would much rather move the ,v files.  This is a standard argument on
this list, and there has never been consensus.  The history is important
with stuff like MPMs, and doing a cvs rm, cvs add removes the history.

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 17, 2002 3:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Move perchild to experimental?
> 
> On Wed, Apr 17, 2002 at 03:10:10PM -0700, Justin Erenkrantz wrote:
> > Okay, so it seems we have consensus to move it.
> >
> > Uh, how do we move it?
> >
> > - Delete it and re-add them in the new directory
> > - Move the .v files on icarus
> 
> If you move the ,v files you'll be messing with history, how about
just
> delete and add?
> 
> *cough*svn could probably do it*cough*
> 
> -aaron




Re: Move perchild to experimental?

2002-04-17 Thread Aaron Bannert

On Wed, Apr 17, 2002 at 03:16:43PM -0700, Ryan Bloom wrote:
> I would much rather move the ,v files.  This is a standard argument on
> this list, and there has never been consensus.  The history is important
> with stuff like MPMs, and doing a cvs rm, cvs add removes the history.

I'm more concerned that it alters the state of things like our tags.
Now if you check out APACHE_2_0_35 it won't be the same as in our
tarballs.

-aaron



RE: Move perchild to experimental?

2002-04-17 Thread Ryan Bloom

Then copy the ,v file, then do a cvs rm of the original file.  Finally,
remove the tags from the new file.

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 17, 2002 3:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Move perchild to experimental?
> 
> On Wed, Apr 17, 2002 at 03:16:43PM -0700, Ryan Bloom wrote:
> > I would much rather move the ,v files.  This is a standard argument
on
> > this list, and there has never been consensus.  The history is
important
> > with stuff like MPMs, and doing a cvs rm, cvs add removes the
history.
> 
> I'm more concerned that it alters the state of things like our tags.
> Now if you check out APACHE_2_0_35 it won't be the same as in our
> tarballs.
> 
> -aaron




RE: Move perchild to experimental?

2002-04-17 Thread Scott Hess

In my experience this argument always ends with: copy the ,v files, then
cvs rm the old version, with a comment on the order of "moved to
../wherever".  Perhaps with a "moved from .../wherever" comment added to
the new version.  I think it's even ended that way on this list a couple 
times.

Messing with history is bad!

Later,
scott

On Wed, 17 Apr 2002, Ryan Bloom wrote:
> I would much rather move the ,v files.  This is a standard argument on
> this list, and there has never been consensus.  The history is important
> with stuff like MPMs, and doing a cvs rm, cvs add removes the history.
> 
> Ryan
> 
> --
> Ryan Bloom  [EMAIL PROTECTED]
> 645 Howard St.  [EMAIL PROTECTED]
> San Francisco, CA 
> 
> > -Original Message-
> > From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 17, 2002 3:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Move perchild to experimental?
> > 
> > On Wed, Apr 17, 2002 at 03:10:10PM -0700, Justin Erenkrantz wrote:
> > > Okay, so it seems we have consensus to move it.
> > >
> > > Uh, how do we move it?
> > >
> > > - Delete it and re-add them in the new directory
> > > - Move the .v files on icarus
> > 
> > If you move the ,v files you'll be messing with history, how about
> just
> > delete and add?
> > 
> > *cough*svn could probably do it*cough*
> > 
> > -aaron
> 




Re: Move perchild to experimental?

2002-04-17 Thread Aaron Bannert

On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> Then copy the ,v file, then do a cvs rm of the original file.  Finally,
> remove the tags from the new file.

+1

-aaron



RE: Move perchild to experimental?

2002-04-17 Thread Cliff Woolley


-0.9 on simply moving them... this would make it impossible to check out
an older version of Apache (even 2.0.35!) and get the same thing that's in
the tarball.

We don't have much choice but to cvs rm, cvs add IMO.

--Cliff




Re: Move perchild to experimental?

2002-04-17 Thread Cliff Woolley

On Wed, 17 Apr 2002, Aaron Bannert wrote:

> On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> > Then copy the ,v file, then do a cvs rm of the original file.  Finally,
> > remove the tags from the new file.
>
> +1

Better, though it still makes checkout by date be wrong.  +0

--Cliff




Re: Move perchild to experimental?

2002-04-17 Thread William A. Rowe, Jr.

At 05:28 PM 4/17/2002, Cliff Woolley wrote:
>On Wed, 17 Apr 2002, Aaron Bannert wrote:
>
> > On Wed, Apr 17, 2002 at 03:21:51PM -0700, Ryan Bloom wrote:
> > > Then copy the ,v file, then do a cvs rm of the original file.  Finally,
> > > remove the tags from the new file.
> >
> > +1
>
>Better, though it still makes checkout by date be wrong.  +0

+.5 here.  We've used that technique and really only received 'theoretical'
complaints.  Sure, if you did this to http_main.c -> main.c, you could end
up compiling both on a checkout-by-date.  But since the mpm directory
isn't processed quite the same way, they shouldn't pose a problem.

Bill





Re: [patch] small perchild fixes

2002-04-22 Thread Scott Lamb

On Mon, Apr 22, 2002 at 01:46:58PM -0500, Scott Lamb wrote:
> I've attached a small patch to perchild that

Oops. No, I didn't. Lemme try that again...

--
Scott Lamb


Index: server/mpm/experimental/perchild/config5.m4
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/experimental/perchild/config5.m4,v
retrieving revision 1.1
diff -u -r1.1 config5.m4
--- server/mpm/experimental/perchild/config5.m4 3 Apr 2001 18:37:12 -   1.1
+++ server/mpm/experimental/perchild/config5.m4 21 Apr 2002 14:28:46 -
@@ -1,6 +1,5 @@
 dnl ## XXX - Need a more thorough check of the proper flags to use
 
 if test "$MPM_NAME" = "perchild" ; then
-
-APACHE_FAST_OUTPUT(server/mpm/$MPM_NAME/Makefile)
+APACHE_FAST_OUTPUT(server/mpm/$MPM_SUBDIR_NAME/Makefile)
 fi
Index: server/mpm/experimental/perchild/perchild.c
===
RCS file: /home/cvspublic/httpd-2.0/server/mpm/experimental/perchild/perchild.c,v
retrieving revision 1.122
diff -u -r1.122 perchild.c
--- server/mpm/experimental/perchild/perchild.c 5 Apr 2002 02:23:02 -   1.122
+++ server/mpm/experimental/perchild/perchild.c 21 Apr 2002 14:28:47 -
@@ -1834,7 +1834,7 @@
 }
 
 ug->uid = ap_uname2id(u);
-ug->gid = ap_uname2id(g); 
+ug->gid = ap_gname2id(g); 
 
 #ifndef BIG_SECURITY_HOLE
 if (ug->uid == 0 || ug->gid == 0) {
@@ -1851,7 +1851,7 @@
 int i;
 int matching = 0;
 int u = ap_uname2id(uid);
-int g = ap_uname2id(gid);
+int g = ap_gname2id(gid);
 const char *errstr;
 int socks[2];
 perchild_server_conf *sconf = (perchild_server_conf *)



RE: [patch] small perchild fixes

2002-04-22 Thread Ryan Bloom

I didn't get the patch, can you re-send it?  Please put the patch
inline.

Thanks,

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: Scott Lamb [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 11:47 AM
> To: [EMAIL PROTECTED]
> Subject: [patch] small perchild fixes
> 
> I've attached a small patch to perchild that
> 
> - makes perchild compile with the server/mpm/perchild ->
>   server/mpm/experimental/perchild move.
> - fixes a typo I made in an earlier patch. It ran the GID through the
user
>   name lookup. (I didn't notice because on my test syste the uid, gid,
>   username, and group name were all the same.) oops.
> 
> Please apply.
> 
> (It doesn't address the larger problem that perchild just didn't work
for
> me, requests hung.  rbb's last commit message to mpm.h suggests this
is
> not
> unexpected. Since I know nothing of either the old or new locking
APIs,
> I'll
> leave that alone.)
> 
> --
> Scott Lamb




RE: [patch] small perchild fixes

2002-04-22 Thread Ryan Bloom

Never mind, just saw the second message.

Ryan

--
Ryan Bloom  [EMAIL PROTECTED]
645 Howard St.  [EMAIL PROTECTED]
San Francisco, CA 

> -Original Message-
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 11:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [patch] small perchild fixes
> 
> I didn't get the patch, can you re-send it?  Please put the patch
> inline.
> 
> Thanks,
> 
> Ryan
> 
> --
> Ryan Bloom  [EMAIL PROTECTED]
> 645 Howard St.  [EMAIL PROTECTED]
> San Francisco, CA
> 
> > -Original Message-
> > From: Scott Lamb [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 22, 2002 11:47 AM
> > To: [EMAIL PROTECTED]
> > Subject: [patch] small perchild fixes
> >
> > I've attached a small patch to perchild that
> >
> > - makes perchild compile with the server/mpm/perchild ->
> >   server/mpm/experimental/perchild move.
> > - fixes a typo I made in an earlier patch. It ran the GID through
the
> user
> >   name lookup. (I didn't notice because on my test syste the uid,
gid,
> >   username, and group name were all the same.) oops.
> >
> > Please apply.
> >
> > (It doesn't address the larger problem that perchild just didn't
work
> for
> > me, requests hung.  rbb's last commit message to mpm.h suggests this
> is
> > not
> > unexpected. Since I know nothing of either the old or new locking
> APIs,
> > I'll
> > leave that alone.)
> >
> > --
> > Scott Lamb





Re: Move perchild to experimental?

2002-04-23 Thread Greg Stein

And copying the ,v files messes with history!

Damn. Will people just never realize this? Go and check out a copy of the
tree by date. Oh! it's fucked. Somebody copied a ,v file.

It isn't all about tags. Use add and rm, with a pointer in the initial
checkin comment to where the file came from (and where the history is).

Cheers,
-g

p.s. and yes, subversion rocks the world here, but IMO, we want to use that
to set up the "next" free-reign development tree. apache 1.3 and 2.0 will
stay in CVS for a while. (well, we could throw them at cvs2svn...)

On Wed, Apr 17, 2002 at 03:27:17PM -0700, Scott Hess wrote:
> In my experience this argument always ends with: copy the ,v files, then
> cvs rm the old version, with a comment on the order of "moved to
> ../wherever".  Perhaps with a "moved from .../wherever" comment added to
> the new version.  I think it's even ended that way on this list a couple 
> times.
> 
> Messing with history is bad!
> 
> Later,
> scott
> 
> On Wed, 17 Apr 2002, Ryan Bloom wrote:
> > I would much rather move the ,v files.  This is a standard argument on
> > this list, and there has never been consensus.  The history is important
> > with stuff like MPMs, and doing a cvs rm, cvs add removes the history.
> > 
> > Ryan
> > 
> > --
> > Ryan Bloom  [EMAIL PROTECTED]
> > 645 Howard St.  [EMAIL PROTECTED]
> > San Francisco, CA 
> > 
> > > -Original Message-
> > > From: Aaron Bannert [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 17, 2002 3:12 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Move perchild to experimental?
> > > 
> > > On Wed, Apr 17, 2002 at 03:10:10PM -0700, Justin Erenkrantz wrote:
> > > > Okay, so it seems we have consensus to move it.
> > > >
> > > > Uh, how do we move it?
> > > >
> > > > - Delete it and re-add them in the new directory
> > > > - Move the .v files on icarus
> > > 
> > > If you move the ,v files you'll be messing with history, how about
> > just
> > > delete and add?
> > > 
> > > *cough*svn could probably do it*cough*
> > > 
> > > -aaron
> > 

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



RE: state of mpm perchild

2002-06-24 Thread Ryan Bloom









There is no date set, because this is all
volunteer work.  It will not be production quality for a number of
months.  I hope to have it working again by the end of the week.

 

Ryan

 



--
Ryan
Bloom 
[EMAIL PROTECTED]
645 Howard
St. 
[EMAIL PROTECTED]
San Francisco, CA 





-Original Message-
From: Nick De Decker
[mailto:[EMAIL PROTECTED]] 
Sent: Monday, June 24, 2002 10:15
AM
To: [EMAIL PROTECTED]
Subject: state of mpm perchild

 



Hi guys,





 





Any progress on the mpm perchild for linux ?





I'm setting up a production webserver and really would like
to use this mpm.





Any date set ?





 





Regards





Nick De Decker












Re: state of mpm perchild

2002-06-24 Thread Nick De Decker



hehe, ok thanks, i'll stick with 1.3 series till 
than.
 
Nick

  - Original Message - 
  From: 
  Ryan Bloom 
  To: [EMAIL PROTECTED] 
  Sent: Monday, June 24, 2002 7:21 PM
  Subject: RE: state of mpm perchild
  
  
  There is no date set, 
  because this is all volunteer work.  It will not be production quality 
  for a number of months.  I hope to have it working again by the end of 
  the week.
   
  Ryan
   
  
  --Ryan 
  Bloom  
  [EMAIL PROTECTED]645 Howard 
  St.  
  [EMAIL PROTECTED]San Francisco, CA 
  
  
  -Original 
  Message-From: Nick De 
  Decker [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 10:15 
  AMTo: [EMAIL PROTECTED]Subject: state of mpm 
  perchild
   
  
  Hi guys,
  
   
  
  Any progress on the mpm perchild 
  for linux ?
  
  I'm setting up a production 
  webserver and really would like to use this mpm.
  
  Any date set 
  ?
  
   
  
  Regards
  
  Nick 
  De Decker


Re: perchild on FreeBSD 5?

2002-08-13 Thread Rasmus Lerdorf

> Hello,
> I've more or less accepted that perchild on FreeBSD 4.X isn't going to
> happen (as sad as it is, I always considered it to be THE feature [1] in
> 2.0 that would warrant an upgrade for us) but what I'd like to know is
> if there is any chance to see perchild on FreeBSD 5 which gets wholly
> new threading and SMP libs?

I agree, and I have been preaching the same thing for a while.  Almost no
point in releasing Apache2 without a working perchild.  Unfortunately
there are other issues as well.  A lot of the 3rd party libs that
something like PHP or mod_perl depends on are not necessarily threadsafe.
As witnessed by FreeBSD's incredibly buggy threading code there aren't a
lot of things using threads heavily on UNIX.  With some notable
exceptions, of course, but very few try to pull in 30 or 40 3rd-party
libraries as well.  We are going to have to fix a bunch of them and mutex
some others before Apache2 with a threaded MPM will be of any use with PHP
or mod_perl.  And I am not sure how to go about identifying the libraries
that aren't qiute threadsafe.  Problems generally only show up under load
and only in certain circumstances.  Especially for the libraries that
claim to be threadsafe but aren't quite for whatever reason.

-Rasmus




Re: perchild on FreeBSD 5?

2002-08-13 Thread Pier Fumagalli

"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote:

>> Hello,
>> I've more or less accepted that perchild on FreeBSD 4.X isn't going to
>> happen (as sad as it is, I always considered it to be THE feature [1] in
>> 2.0 that would warrant an upgrade for us) but what I'd like to know is
>> if there is any chance to see perchild on FreeBSD 5 which gets wholly
>> new threading and SMP libs?
> 
> I agree, and I have been preaching the same thing for a while.  Almost no
> point in releasing Apache2 without a working perchild.  Unfortunately
> there are other issues as well.  A lot of the 3rd party libs that
> something like PHP or mod_perl depends on are not necessarily threadsafe.
> As witnessed by FreeBSD's incredibly buggy threading code there aren't a
> lot of things using threads heavily on UNIX.  With some notable
> exceptions, of course, but very few try to pull in 30 or 40 3rd-party
> libraries as well.  We are going to have to fix a bunch of them and mutex
> some others before Apache2 with a threaded MPM will be of any use with PHP
> or mod_perl.  And I am not sure how to go about identifying the libraries
> that aren't qiute threadsafe.  Problems generally only show up under load
> and only in certain circumstances.  Especially for the libraries that
> claim to be threadsafe but aren't quite for whatever reason.

Luckily, in Java land things are more or less brighter, and I can say that
for what matters to me (I don't use PHP on big production servers, apart
from a couple of things which are thread safe - IMP and related), the
threaded MPM is giving me nothing but joy every single friggin' day! :)

Keep up the "gud staf" guys! :)

Pier (working his ass off on a deadline!)




  1   2   3   >