apache multiviews

Dear Julius,

I'm aware your message dates back to dec 2005. I'm not sure if you fixed 
it or you decided to take another route. Anyhow, for those facing this 
same problem, here is the solution:

(Applicable to Gentoo, should be similar for other distributions)
In your mod_suphp.conf comment out <Location /> and </Location> leaving 
SuPHP_addhandler's in the wild.

Don't ask why... it was a long journey of hit-n-miss

That worked on 3 Gentoo webservers.

Best regards,
xiwen

--

-- 
Xiwen Cheng
---
E-mail: xcheng@...
GPG id: 01BA91D1
www: http://www.liacs.nl/~xcheng

_______________________________________________
suPHP mailing list
suPHP@...
http://lists.marsching.com/mailman/listinfo/suphp

Re: File permissions

1) Did you read the documentation that came with suPHP at all?  In your
suphp.conf, there is a umask setting.

2) If by "uploads" you mean HTTP uploads through an Apache server, then
suPHP is not responsible for such.  You'll need to provide more details
about how the "uploads" are being done *exactly*.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Tue, Jun 10, 2008 at 03:55:43PM +0200, baldy wrote:
> Hi all,
> 
> i installed suPHP fort some speszial reasons ;)
> 
> Now, I have the problem when I set umask 0022 in the suphp.conf but it wont
> work 
> All files which gets uploaded via Website shows like these:
> 
> -rw-------   1 web15 web15      10482 2008-06-10 15:19 10-Kunst-am-Bau-2.jpg
> -rw-------   1 web15 web15      85845 2008-06-10 15:54
> 5-Kunst_am_Bau11-g.jpg
> 
> Is there any reason why it dont work? All files need to be 755 (bash chmod)
> 
> Will be happy when anyone can help me.
> 

Re: File permissions

What does the uploading?  Are you using a web browser to do the uploads?

If so, Apache is what's handling the HTTP uploading and storage of the
file on the filesystem.

The HTTP form action should refer to a PHP script of some sort (e.g.
<form action="whatever.php"><input name="myfile" type="file" /><input
type="submit" value="Click here" />.

The whatever.php script would then refer to
$_FILES['myfile']['tmp_name'], which is where the file just uploaded via
HTTP would be placed.  The file permissions of that file, however, are
based on Apache and not suPHP.

It's the job of the PHP script to change the permissions of the file,
and/or rename it or move it as it sees fit.  PHP has a function called
move_uploaded_file() which can relocate HTTP-uploaded files.  It should
work fine under suPHP, **and** will inherit the umask set by suPHP prior
to the PHP interpreter being called (which is what the umask setting in
suphp.conf is for).

Here's some reference material for you:

http://lists.marsching.com/pipermail/suphp/2005-February/000725.html
http://us.php.net/manual/en/features.file-upload.php

--

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |

Re: File permissions

Also, don't forget that umask will remove existing permissions when
creating a file but will *not* give additional permissions.

In this case, we want the file to be created with 755. A umask of 022
will ensure the permissions are not *more* than 755, nothing else. Check
the umask man page..

The only way to fix the problem is to have the script set the permission
on the file after the upload took place.

-- 
Cedric Veilleux <cveilleux@...>
Neopeak Internet Solutions inc.

Le mardi 10 juin 2008 à 07:43 -0700, Jeremy Chadwick a écrit :
> What does the uploading?  Are you using a web browser to do the uploads?
> 
> If so, Apache is what's handling the HTTP uploading and storage of the
> file on the filesystem.
> 
> The HTTP form action should refer to a PHP script of some sort (e.g.
> <form action="whatever.php"><input name="myfile" type="file" /><input
> type="submit" value="Click here" />.
> 
> The whatever.php script would then refer to
> $_FILES['myfile']['tmp_name'], which is where the file just uploaded via
> HTTP would be placed.  The file permissions of that file, however, are
> based on Apache and not suPHP.
> 
> It's the job of the PHP script to change the permissions of the file,

Re: File permissions

On Tue, 10 Jun 2008, Jeremy Chadwick wrote:

> The file permissions of that file, however, are
> based on Apache and not suPHP.

What makes you say that?  It's still a script being run to manipulate the 
file, parsing standard input and moving the file out.  Apache doesn't do 
anything natively to handle the files -- if this were the case, then the 
following statement would not make sense:

"Files will, by default be stored in the server's default temporary 
directory, unless another location has been given with the upload_tmp_dir 
directive in php.ini. The server's default directory can be changed by 
setting the environment variable TMPDIR in the environment in which PHP 
runs. Setting it using putenv() from within a PHP script will not work. 
This environment variable can also be used to make sure that other 
operations are working on uploaded files, as well."

Thus, the file will still get uploaded as the owner of the script.  The 
file *mode* may be wierd with respect to apache's umask versus suphp's 
umask.

> It's the job of the PHP script to change the permissions of the file,
> and/or rename it or move it as it sees fit.  PHP has a function called
> move_uploaded_file() which can relocate HTTP-uploaded files.  It should
> work fine under suPHP, **and** will inherit the umask set by suPHP prior
> to the PHP interpreter being called (which is what the umask setting in
> suphp.conf is for).

The point of move_uploaded_file is mainly so that you don't have to do raw 

MPM Worker Sleeping PHP Processes

_______________________________________________
suPHP mailing list
suPHP@...
http://lists.marsching.com/mailman/listinfo/suphp

Re: MPM Worker Sleeping PHP Processes

Doesn't PHP have a huge warning on their documentation page that says
"PHP doesn't work correctly under threaded environments/under a threaded
MPM?"

What I'm saying is: what makes you think this is suPHP's fault?  (I'm
not doubting you, I'm just unsure what evidence you have of it being
suPHP).

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Wed, Jun 11, 2008 at 09:28:19AM -0400, Tony Baird wrote:
> I'm attempting to run suPHP with mpm_worker under Apache 2.2.8 and I end up
> with sleeping PHP threads at random.  This cannot be produced while using
> prefork it only happens when running worker.
> 
>  
> 
> OS: CentOS 4.6 (2.6.9-67.0.7.ELsmp)
> 
>  
> 
> Apache: 2.2.8
> 
> PHP: 5.2.6
> 
>  
> 
> What you end up with is something like this:
> 
>  
> 
> nobody   19363  0.1  2.0 343464 83292 ?      Sl   07:08   0:12  \_
> /usr/local/apache/bin/httpd -k start -DSSL
> 
> username    21265  0.0  0.3 26752 13116 ?       S    07:11   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
> username    21275  0.0  0.2 25764 10964 ?       S    07:11   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
> username    28965  0.0  0.2 25140 11036 ?       S    07:26   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
>  
> 
>  
> 
> In this case they came from the same apache process, however they can be
> spread around as well.
> 
>  
> 
> status looks something like this:
> 
>  
> 
> Name:   php
> 
> State:  S (sleeping)
> 
> SleepAVG:       97%
> 
> Tgid:   21265
> 
> Pid:    21265
> 
> PPid:   19363
> 
> TracerPid:      0
> 
> Uid:    32809   32809   32809   32809
> 
> Gid:    32811   32811   32811   32811
> 
> FDSize: 8192
> 
> Groups: 32811 
> 
> VmSize:    26752 kB
> 
> VmLck:         0 kB
> 
> VmRSS:     13116 kB
> 
> VmData:     4976 kB
> 
> VmStk:       768 kB
> 
> VmExe:      6182 kB
> 
> VmLib:     12998 kB
> 
> StaBrk: 0869e000 kB
> 
> Brk:    09dbb000 kB
> 
> StaStk: bff48fa0 kB
> 
> ExecLim:        ffffffff
> 
> Threads:        1
> 
> SigPnd: 0000000000000000
> 
> ShdPnd: 0000000000000000
> 
> SigBlk: fffffffe3bfbe007
> 
> SigIgn: 0000000000001000
> 
> SigCgt: 0000000184000000
> 
> CapInh: 0000000000000000
> 
> CapPrm: 0000000000000000
> 
> CapEff: 0000000000000000
> 
>  
> 
>  
> 
> I wasn't sure what all to include or what information would be useful.
> Anything else that might be useful I can add.
> 
>  
> 
>  
> 

> _______________________________________________
> suPHP mailing list
> suPHP@...
> http://lists.marsching.com/mailman/listinfo/suphp

Re: MPM Worker Sleeping PHP Processes

My understanding that warning applies when running PHP as a DSO.  Taken from
the PHP manual:

"If you feel you have to use a threaded MPM, look at a FastCGI configuration
where PHP is running in its own memory space."

This would also apply to a CGI setup which would include suPHP would it not?

-----Original Message-----
From: Jeremy Chadwick [mailto:suphp@...] 
Sent: Wednesday, June 11, 2008 10:34 AM
To: Tony Baird
Cc: suphp@...
Subject: Re: [suPHP] MPM Worker Sleeping PHP Processes

Doesn't PHP have a huge warning on their documentation page that says
"PHP doesn't work correctly under threaded environments/under a threaded
MPM?"

What I'm saying is: what makes you think this is suPHP's fault?  (I'm
not doubting you, I'm just unsure what evidence you have of it being
suPHP).

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

On Wed, Jun 11, 2008 at 09:28:19AM -0400, Tony Baird wrote:
> I'm attempting to run suPHP with mpm_worker under Apache 2.2.8 and I end
up
> with sleeping PHP threads at random.  This cannot be produced while using
> prefork it only happens when running worker.
> 
>  
> 
> OS: CentOS 4.6 (2.6.9-67.0.7.ELsmp)
> 
>  
> 
> Apache: 2.2.8
> 
> PHP: 5.2.6
> 
>  
> 
> What you end up with is something like this:
> 
>  
> 
> nobody   19363  0.1  2.0 343464 83292 ?      Sl   07:08   0:12  \_
> /usr/local/apache/bin/httpd -k start -DSSL
> 
> username    21265  0.0  0.3 26752 13116 ?       S    07:11   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
> username    21275  0.0  0.2 25764 10964 ?       S    07:11   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
> username    28965  0.0  0.2 25140 11036 ?       S    07:26   0:00  |   \_
> /usr/bin/php /home/username/public_html/index.php
> 
>  
> 
>  
> 
> In this case they came from the same apache process, however they can be
> spread around as well.
> 
>  
> 
> status looks something like this:
> 
>  
> 
> Name:   php
> 
> State:  S (sleeping)
> 
> SleepAVG:       97%
> 
> Tgid:   21265
> 
> Pid:    21265
> 
> PPid:   19363
> 
> TracerPid:      0
> 
> Uid:    32809   32809   32809   32809
> 
> Gid:    32811   32811   32811   32811
> 
> FDSize: 8192
> 
> Groups: 32811 
> 
> VmSize:    26752 kB
> 
> VmLck:         0 kB
> 
> VmRSS:     13116 kB
> 
> VmData:     4976 kB
> 
> VmStk:       768 kB
> 
> VmExe:      6182 kB
> 
> VmLib:     12998 kB
> 
> StaBrk: 0869e000 kB
> 
> Brk:    09dbb000 kB
> 
> StaStk: bff48fa0 kB
> 
> ExecLim:        ffffffff
> 
> Threads:        1
> 
> SigPnd: 0000000000000000
> 
> ShdPnd: 0000000000000000
> 
> SigBlk: fffffffe3bfbe007
> 
> SigIgn: 0000000000001000
> 
> SigCgt: 0000000184000000
> 
> CapInh: 0000000000000000
> 
> CapPrm: 0000000000000000
> 
> CapEff: 0000000000000000
> 
>  
> 
>  
> 
> I wasn't sure what all to include or what information would be useful.
> Anything else that might be useful I can add.
> 
>  
> 
>  
> 

> _______________________________________________
> suPHP mailing list
> suPHP@...
> http://lists.marsching.com/mailman/listinfo/suphp

No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.100 / Virus Database: 270.2.0/1497 - Release Date: 6/11/2008
8:32 AM

Re: MPM Worker Sleeping PHP Processes

On Wed, 11 Jun 2008, Tony Baird wrote:

php is not threadsafe, because it is "glue" (yes, that's the developers 
excuse).  Why they can't go on a certification mission, and determine 
which versions of which libraries are and are not, I don't know).

However, with suPHP, each php instance is a separate subprocess, which 
should eliminate this issue, i.e. there should be no difference between 
worker and prefork.  The problems only become apparent when using mod_php.

Note that I still run 1.3 anyway, though.

_-Dan

--

-- 

"Hey, call me anything you like.  I'm Dan to my friends, gushi to my
close friends, 'hey, you' to my girlfriend, 'mrrow?' to my cat, and 'why
the hell is the router on fire?' to my job.

-Dan Mahoney
  12/2/02

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------

Re: MPM Worker Sleeping PHP Processes

I found someone who brought up the fact of sigblk not being set to 0 in 2.2
with worker and with prefork in 2.0 it was.  Now I can confirm this to be
the case when running 2.2 with prefork as well.  I'm not sure of the person
was onto something about this being the cause or not.  I just can't find
similar PHP scripts causing it so I can't pinpoint a specific call that can
cause the sleeping processes.

Name:   php
State:  S (sleeping)
SleepAVG:       98%
Tgid:   5545
Pid:    5545
PPid:   1
TracerPid:      0
Uid:    33417   33417   33417   33417
Gid:    33419   33419   33419   33419
FDSize: 8192
Groups: 33419 
VmSize:    30512 kB
VmLck:         0 kB
VmRSS:     16276 kB
VmData:     7940 kB
VmStk:      1172 kB
VmExe:      6130 kB
VmLib:     13458 kB
StaBrk: 08694000 kB
Brk:    08f60000 kB
StaStk: bfee7f10 kB
ExecLim:        ffffffff
Threads:        1
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000003000
SigCgt: 0000000184000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

-----Original Message-----
From: Dan Mahoney, System Admin [mailto:danm@...] 
Sent: Wednesday, June 11, 2008 11:36 AM
To: Tony Baird
Cc: 'Jeremy Chadwick'; suphp@...
Subject: Re: [suPHP] MPM Worker Sleeping PHP Processes

On Wed, 11 Jun 2008, Tony Baird wrote:

php is not threadsafe, because it is "glue" (yes, that's the developers 
excuse).  Why they can't go on a certification mission, and determine 
which versions of which libraries are and are not, I don't know).

However, with suPHP, each php instance is a separate subprocess, which 
should eliminate this issue, i.e. there should be no difference between 
worker and prefork.  The problems only become apparent when using mod_php.

Note that I still run 1.3 anyway, though.

_-Dan

-- 

"Hey, call me anything you like.  I'm Dan to my friends, gushi to my
close friends, 'hey, you' to my girlfriend, 'mrrow?' to my cat, and 'why
the hell is the router on fire?' to my job.

-Dan Mahoney
  12/2/02

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------

No virus found in this incoming message.
Checked by AVG. 
Version: 8.0.100 / Virus Database: 270.2.0/1497 - Release Date: 6/11/2008
8:32 AM