php -s fails

[xris]

Using [1809], tried to view a php file, and I get:

Running (php -s) failed: 255, .

php -s works fine when I run it on the command line (even as an unprivileged "apache" user, via sudo)

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/cgi_frontend.py", line 103, in run
    dispatch_request(os.getenv('PATH_INFO', ''), req, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 421, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 285, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/Browser.py", line 133, in process_request
    self._render_file(req, repos, node, rev)
  File "/usr/lib/python2.3/site-packages/trac/Browser.py", line 240, in _render_file
    annotations=['lineno'])
  File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 215, in render
    return self._annotate(result, annotations)
  File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 243, in _annotate
    for num, line in enum(_html_splitlines(lines)):
  File "/usr/lib/python2.3/site-packages/trac/util.py", line 42, in enum
    for item in iter(iterable):
  File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 259, in _html_splitlines
    for line in lines:
  File "/usr/lib/python2.3/site-packages/trac/mimeview/php.py", line 73, in render
    raise Exception, err
Exception: Running (php -s) failed: 255, .

[xris]

just to update, I tried hard-coding the path into trac.ini and I still get the same error.

[chris@…]

Duplicate of #1676

Solution is to use source:/trunk/trac/mimeview/php.py#1620

A simple merge should do it but this is the complicated case where I am merging the trunk changes out of the anydiff branch. You'd want 1809 as your first revision number.

[root@summer mimeview]# svn merge -r1792:1620 http://svn.edgewall.com/repos/trac/trunk/trac/mimeview/php.py
U    php.py
[root@summer mimeview]#

[cboos]

This doesn't look like a duplicate of #1676 to me.

#1676 was about an error in the rendering code, which was fixed in [1810].

This issue is about an error when starting up the php process from trac apache/cgi.

[cboos]

xris, is this still happening with the current trunk? (e.g. r2012)

[mgood]

This has been open long enough without an answer that I think it's safe to assume it's working.

[jkloske@…]

actually, i'm getting this problem as well - wonder what 255 error code with an empty string means from NaivePopen?...

[anonymous]

Replying to jkloske@itee:

actually, i'm getting this problem as well - wonder what 255 error code with an empty string means from NaivePopen?...

Are you also using Apache-CGI? Do you get the same error if running tracd as the Apache user?

[jkloske@…]

Ahh yes, I'm using the apache-cgi, which would explain it. I wrote a script to wrap the call to php through sed to add newlines after <br /> tags, like so:

#!/bin/bash
cat > /tmp/phpsees.txt
php -qsn < /tmp/phpsees.txt | sed -e 's/<br \/>/<br \/>\n/g'

What I saw when running this manually on the command line was syntax highlighted output like I would expect (via root, apache, any user account.)

Then I switched this for the php binary in trac.ini and tried to view a .php file and got this in the trac source browser:

Content-type: text/'''htmlSecurity Alert!''' The PHP CGI cannot be accessed directly.
This PHP CGI binary was compiled with force-cgi-redirect enabled.  Thismeans that a page will only be served up if the REDIRECT_STATUS CGI variable isset, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the [http://php.net/security.cgi-bin manual page for CGI security].

For more information about changing this behaviour or re-enabling this webserver,consult the installation file that came with this distribution, or visit

Seems the fancy php 'security' feature to stop it being run from inside apache on the command line is what's breaking this, since the trac cgi's copy the apache environment variables all the way down into php.

In fact:

# env SERVER_NAME=bob php -qsn
Status: 400
Content-type: text/html

<b>Security Alert!</b> The PHP CGI cannot be accessed directly.

<p>This PHP CGI binary was compiled with force-cgi-redirect enabled.  This
means that a page will only be served up if the REDIRECT_STATUS CGI variable is
set, e.g. via an Apache Action directive.</p>
<p>For more information as to <i>why</i> this behaviour exists, see the <a href="http://php.net/security.cgi-bin">manual page for CGI security</a>.</p>
<p>For more information about changing this behaviour or re-enabling this webserver,
consult the installation file that came with this distribution, or visit
<a href="http://php.net/install.windows">the manual page</a>.</p>

I really haven't had a chance to look much further at this (I just wrote a shell script last friday as a quick workaround that simply spat out non-highlighted code) so I may have missed something simple or misinterpreted stuff.

I tried doing what the php user comments suggested and temporarily setting REDIRECT_STATUS, but that didn't seem to work (it ignored the command line arguments, which kind of defeated the purpose.)

I guess the solution is to install the cli version of php and link to that instead from trac.ini.

Thanks again.

[jkloske@…]

I should probably also point out:

1. I changed the status of this ticket to "wontfix" because even though it'd be nice if trac was changed to deal with php-cgi installs properly, it's not necessary.

and

2. Not sure if the security implications of doing so, but if you edit trac.ini and change the php_path variable to this:

php_path = /usr/bin/env -u GATEWAY_INTERFACE -u PATH_TRANSLATED -u REQUEST_METHOD -u SCRIPT_FILENAME -u SERVER_NAME -u SERVER_SOFTWARE /usr/bin/php -q

it seems to fool php enough that it works as a CLI mode binary. This was on a recent centos using the php-cgi from the standard yum repos, ymmv.