Category Archives: php

Today has been a day for buggy php modules.

I was installing the xhprof module for a client when I got this error back from pecl:

running: phpize
Cannot find config.m4.
Make sure that you run ‘/usr/bin/phpize’ in the top level source directory of the module

ERROR: `phpize’ failed

It didn’t take me terribly long to find the bug report.

Inside of it is the steps to get around the bug:

pear update-channels
pecl install --force xhprof
cd /tmp/pear/download/
cp -a xhprof-0.9.2/extension/* xhprof-0.9.2/
sed -i -r -e "s%()%\1\2%" package.xml
tar czf xhprof-0.9.2.tgz package.xml xhprof-0.9.2
pecl install --force xhprof-0.9.2.tgz

Worked like a charm.


Category: php

Here’s a fun one I’ve not run into in some time:

I was installing the php mailparse extension for a client. Same old, same old. Did the usual pecl install (with a -n flag because the mbstring requirement was installed from RPM and the mailparse pecl installer was not recognizing that). It installed without issue, I made my /etc/php.d/mailparse.ini file and went to check my work with a php -m command. Low and behold…. an error!

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/mailparse.so’ – /usr/lib64/php/modules/mailparse.so: undefined symbol: mbfl_name2

I scratched my head a bit, poking around, before I found it. Mailparse requires mbstring but was somehow being loaded before it and, as a result, failing. I renamed my ini file to z_mailparse.ini, to ensure it loads after everything else, and the error cleared.


Category: php

This is a short and easy way to track down the source of a compromised PHP script that is spamming out of your system.

Change the /etc/php.ini sendmail path to:

sendmail_path = /usr/local/bin/sendmail-php -t -i

and then create that file with the following contents:

#!/bin/sh

logger -p mail.info sendmail-php: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, filename=${SCRIPT_FILENAME}, docroot=${DOCUMENT_ROOT}, pwd=${PWD}, uid=${UID}, user=$(whoami)

/usr/sbin/sendmail -t -i $*

chmod +x that file and restart apache.

Now when a php script is called and sends a piece of mail, it is logged to the log file and you can then trace back what is legitimate and what isn’t. Spammers tend to be very…brute force…so it is usually pretty apparent, fairly quickly, which script is being abused.


Category: linux, php, spam

These days, I am finding it harder and harder to justify mod_php as the default behavior of an apache webserver over the advantages of mod_suphp. A lot of this has to do with my clients and their everyday needs, but I’ve become a pretty strong proponent of mod_suphp as the default for a server and only enabling mod_php if required.

It’s actually pretty easy to do, surprisingly. suPHP used to be a process that involved sacrificing chickens in the midnight hours to get to work correctly. Now? All it takes is the below. I’ve included instructions for centos and ubuntu both.

 

Centos

yum install mod_suphp
mv /etc/httpd/conf.d/php.conf /root/saved.conf/

Obviously the path /root/saved.conf/ can be wherever you want to put the original php.conf file. I suggest saving it somewhere in case you need it in the future to specifically enable mod_php for a site. Then you need to modify the file /etc/httpd/conf.d/mod_suphp.conf to look like:

# This is the Apache server configuration file providing suPHP support..
# It contains the configuration directives to instruct the server how to
# serve php pages while switching to the user context before rendering.

LoadModule suphp_module modules/mod_suphp.so

### Uncomment to activate mod_suphp
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php

# This option tells mod_suphp if a PHP-script requested on this server (or
# VirtualHost) should be run with the PHP-interpreter or returned to the
# browser “as it is”.
suPHP_Engine on

# This option tells mod_suphp which path to pass on to the PHP-interpreter
# (by setting the PHPRC environment variable).
# Do *NOT* refer to a file but to the directory the file resists in.
#
# E.g.: If you want to use “/path/to/server/config/php.ini”, use “suPHP_Config
# /path/to/server/config”.
#
# If you don’t use this option, PHP will use its compiled in default path.
suPHP_ConfigPath /etc

and then modify /etc/suphp.conf to change this line:

x-httpd-php=php:/usr/bin/php

to:

x-httpd-php=php:/usr/bin/php-cgi

Restart apache and then check a phpinfo page. You should see that the Server API line now reads: “CGI/FastCGI”.

 

Ubuntu

Ubuntu was actually much easier, surprisingly:

aptitude install libapache2-mod-suphp
a2enmod suphp
a2dismod php5

Restart apache and check your phpinfo page.

To be honest, given the way web applications function these days, I’m truly surprised that this hasn’t become default behavior for php at this point…that they have not absorbed the suphp project into their own work. Until that day comes, that’s all that is required to start running with your own suphp install.

Edit: Also, I’ve not tested this on RHEL, but given the way fedora/centos/RHEL works, you should be able to follow these instructions for that OS as well.


Category: linux, php

Categories


gives good tech

tech.superhappykittymeow.com
Kale is one of the smartest people I know

Racker Hacker
Major is always good for leet deetz