headers
Dan Mahoney, System Admin | 24 Jun 2012 10:12

Blank Page Error with wordpress

Hey guys.

I've been an suPHP loyalist for years, I've loved it and it's saved me a 
ton of headaches.  I'm a sysadmin, not a PHP coder.

On a recent server upgrade, I'm now running the latest suPHP as well as 
apache2.2 and php 5.3.13.

One particular wordpress site is acting up on me, and it's driving me 
batty.

I can run the index.php both as root as well as as the user in question 
from the command line using /usr/local/bin/php-cgi, and it outputs 
content.

With suPHP however, suPHP logs that it's running the code as them, but 
then...nothing.  Blank page.  HTTP status 200, but Content-Length: 0 No 
errors logged.

Adding all the error reporting to PHP that I know how to turn on, does 
nothing.  No errors show up in the logs or in the HTML.

I started inserting various echo statements throughout the code, and 
*those* show up.  So somewhere in the deep include-laden structure of 
Wordpress, something's broken.

PHP seems to lack a simple interface of "trace which files we load and 
parse".

What I'd like to know here is: what is the calling-format of the
(Continue reading)

Permalink | Reply |
headers
Joe Gillotti | 24 Jun 2012 10:24
Favicon
Gravatar

Re: Blank Page Error with wordpress

WordPress can be annoying like that, and it usually isn't the fault of 
suPHP.

Remove all WordPress files except the config file, extract everything 
from http://wordpress.org/latest.tar.gz (except the config file), then 
run WordPress's update wizard (iirc it's at wp-admin/upgrade.php) to 
have it upgrade its mysql tables if necessary.

If that doesn't work, change the site theme to one of the default ones 
in them mysql options table.

I guarantee you this is WordPress's fault, not suPHP's.

On 6/24/2012 4:12 AM, Dan Mahoney, System Admin wrote:
> Hey guys.
>
> I've been an suPHP loyalist for years, I've loved it and it's saved me 
> a ton of headaches.  I'm a sysadmin, not a PHP coder.
>
> On a recent server upgrade, I'm now running the latest suPHP as well 
> as apache2.2 and php 5.3.13.
>
> One particular wordpress site is acting up on me, and it's driving me 
> batty.
>
> I can run the index.php both as root as well as as the user in 
> question from the command line using /usr/local/bin/php-cgi, and it 
> outputs content.
>
> With suPHP however, suPHP logs that it's running the code as them, but
(Continue reading)

Permalink | Reply |
headers
Dan Mahoney, System Admin | 24 Jun 2012 10:48

Re: Blank Page Error with wordpress

On Sun, 24 Jun 2012, Joe Gillotti wrote:

> WordPress can be annoying like that, and it usually isn't the fault of suPHP.
>
> Remove all WordPress files except the config file, extract everything from 
> http://wordpress.org/latest.tar.gz (except the config file), then run 
> WordPress's update wizard (iirc it's at wp-admin/upgrade.php) to have it 
> upgrade its mysql tables if necessary.
>
> If that doesn't work, change the site theme to one of the default ones in 
> them mysql options table.
>
> I guarantee you this is WordPress's fault, not suPHP's.

I'm sure it is, and your application level fix works.  However, the two 
questions remain:

1) How can I run this so I can actually truss it, if it were something 
more obscure than WP?

2) Why is it that it works from the command line but not via suPHP?  Like, 
what would cause that?

-Dan

--

-- 

Hate fedora with a white hot burning passion right now though ... damn thing is Linux-XP(tm)

-Bill Nolan
(Continue reading)

Permalink | Reply |
headers
Joe Gillotti | 24 Jun 2012 10:58
Favicon
Gravatar

Re: Blank Page Error with wordpress


1) With suPHP, it generally isn't possible for a malicious script to 
harm anything aside from what the user who's running the script can 
access. You shouldn't need to worry about trusting it at that point.

2) WordPress is quirky. Maybe it's an issue with a custom theme, or how 
it detects how to encode the content to the web browser based on the 
Accept or UserAgent headers which are nonexistent when ran from the 
command line.

Most likely if you try out a broken-ish WordPress install with mod_php 
rather than suPHP it will act the same way.

On 6/24/2012 4:48 AM, Dan Mahoney, System Admin wrote:
> On Sun, 24 Jun 2012, Joe Gillotti wrote:
>
>> WordPress can be annoying like that, and it usually isn't the fault 
>> of suPHP.
>>
>> Remove all WordPress files except the config file, extract everything 
>> from http://wordpress.org/latest.tar.gz (except the config file), 
>> then run WordPress's update wizard (iirc it's at 
>> wp-admin/upgrade.php) to have it upgrade its mysql tables if necessary.
>>
>> If that doesn't work, change the site theme to one of the default 
>> ones in them mysql options table.
>>
>> I guarantee you this is WordPress's fault, not suPHP's.
>
> I'm sure it is, and your application level fix works.  However, the
(Continue reading)

Permalink | Reply |
headers
Dan Mahoney, System Admin | 24 Jun 2012 11:15

Re: Blank Page Error with wordpress

On Sun, 24 Jun 2012, Joe Gillotti wrote:

>
> 1) With suPHP, it generally isn't possible for a malicious script to harm 
> anything aside from what the user who's running the script can access. You 
> shouldn't need to worry about trusting it at that point.

Not trust.  Truss.  FreeBSD's equivalent of strace.  I.e. figure out which 
files are being opened/stat'd, which filehandles are being touched, where 
session files are failing to be written, etc etc.  (Because PHP has 
crap-all for debugging support).

In order to be able to do that, I need to be able to call the "suphp" 
binary just as mod_suphp would, and supply the same environment the 
webserver would.

> 2) WordPress is quirky. Maybe it's an issue with a custom theme, or how it 
> detects how to encode the content to the web browser based on the Accept or 
> UserAgent headers which are nonexistent when ran from the command line.

Entirely likely, and it worked, but I'm looking for the system-level 
diagnostic, rather than the application-level fix, if that makes sense.

Ah well.

-Dan

--

-- 

"I'll commit ritual suicide before I whore myself out to Disney."
(Continue reading)

Permalink | Reply |
headers
Sebastian Marsching | 24 Jun 2012 11:30

Re: Blank Page Error with wordpress

Am 24.06.2012 10:12, schrieb Dan Mahoney, System Admin:

> What I'd like to know here is: what is the calling-format of the
> /usr/local/sbin/suphp binary -- for example, if I want to call IT from
> the command line, so I can run truss on it to figure out what files are
> being called, and what's vomiting. (As there's no other convenient way I
> can find to stick a debugger in the middle).
>
> (Feel free to reply to me privately with this info if you feel it's
> dangerous).

The calling syntax is not a secret (after all the source code is open), 
however I think that this might not be very helpful.

As suPHP has the setuid bit set, the kernel should not allow debugging 
(or rather ignore the setuid bit, if a debugger is attached). However, 
as suPHP checks for the calling user to be the webserver, calling it as 
root does not help either.

In general, the best way to do debugging (e.g. using strace), is to 
create a small wrapper shell-script calling PHP with a debugger attached 
and writing the results to a file. You can then configure suPHP to call 
this wrapper instead of PHP directly. If you want, you can even limit 
this to a different handler, thus enabling debugging for certain scripts 
only.
Attachment (smime.p7s): application/pkcs7-signature, 4474 bytes
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Dan Mahoney, System Admin | 24 Jun 2012 22:58

Re: Blank Page Error with wordpress

On Sun, 24 Jun 2012, Sebastian Marsching wrote:

> Am 24.06.2012 10:12, schrieb Dan Mahoney, System Admin:
>
>> What I'd like to know here is: what is the calling-format of the
>> /usr/local/sbin/suphp binary -- for example, if I want to call IT from
>> the command line, so I can run truss on it to figure out what files are
>> being called, and what's vomiting. (As there's no other convenient way I
>> can find to stick a debugger in the middle).
>> 
>> (Feel free to reply to me privately with this info if you feel it's
>> dangerous).
>
> The calling syntax is not a secret (after all the source code is open), 
> however I think that this might not be very helpful.
>
> As suPHP has the setuid bit set, the kernel should not allow debugging (or 
> rather ignore the setuid bit, if a debugger is attached). However, as suPHP 
> checks for the calling user to be the webserver, calling it as root does not 
> help either.

Yeah -- adding a minor check that says "or root" might be helpful there 
(or having suPHP be able to check for multiple webserver UIDs, for those 
of us that run webservices under several main uids), but your instructions 
below are useful.

> In general, the best way to do debugging (e.g. using strace), is to create a 
> small wrapper shell-script calling PHP with a debugger attached and writing 
> the results to a file. You can then configure suPHP to call this wrapper 
> instead of PHP directly. If you want, you can even limit this to a different
(Continue reading)

Permalink | Reply |
headers
Daniel Llewellyn | 25 Jun 2012 00:29
Picon
Gravatar

Re: Blank Page Error with wordpress

In the wordpress community this problem is known as a WSOD or White
Screen Of Death.

In my experience it is usually caused by wordpress requesting a
function which hasn't been installed or enabled, such as if you
haven't got the mysql module (php5-mysql in debian). Different
wordpress plugins also come with their own requirements and will also
cause this WSOD failure when the relevant modules aren't available.
Remember that in at least debian-based systems there are different
php.ini locations for cli, cgi, fpm and apache2 SAPIs, so having a
successful execution in php-cli may not be indicative that it will
work correctly when running through php-cgi (the sapi that suphp
interfaces).

--

-- 
Regards,
    The Honeymonster aka Daniel Llewellyn

_______________________________________________
suPHP mailing list
suPHP <at> lists.marsching.com
https://lists.marsching.com/mailman/listinfo/suphp
Permalink | Reply |
headers
Dan Mahoney, System Admin | 25 Jun 2012 01:34

Re: Blank Page Error with wordpress

On Sun, 24 Jun 2012, Daniel Llewellyn wrote:

> In the wordpress community this problem is known as a WSOD or White
> Screen Of Death.
>
> In my experience it is usually caused by wordpress requesting a
> function which hasn't been installed or enabled, such as if you
> haven't got the mysql module (php5-mysql in debian). Different
> wordpress plugins also come with their own requirements and will also
> cause this WSOD failure when the relevant modules aren't available.
> Remember that in at least debian-based systems there are different
> php.ini locations for cli, cgi, fpm and apache2 SAPIs, so having a
> successful execution in php-cli may not be indicative that it will
> work correctly when running through php-cgi (the sapi that suphp
> interfaces).

Generally, when WP calls a bad function it logs to the error log, which in 
this case it did not.

And I was testing it from the command line with /usr/local/bin/php-cgi, 
which worked, although the previous comment about not duplicating the 
calling environment exactly does apply.

-Dan

--

-- 

"Check it out, it's just like Christmas.  Except it sucks."

-Jason Seguerra, 3/2/05
(Continue reading)

Permalink | Reply |

Gmane