Archive for the ‘PHP’ Category

Remote PHP Debugging with Emacs

Saturday, June 21st, 2008

It’s an Emacs weekend here at blog.arithm.

I was recently asked if it was possible to do remote PHP debugging with Emacs. We’re talking about Emacs, so the answer is:  Of course!  How to do it:

  1. Grab Tohru Fujinaka’s GEBEN library.  It’s an aging alpha release, but works fairly well.
  2. Make sure you also have CEDET installed.  I’m using the 1.0 pre4 release.
  3. Drop debugclient somewhere in your path.  (Here Emacs is running on Windows, so I just threw it into the C:\WINDOWS\ directory.)  Make sure the executable is named “debugclient” and not “debugclient-0.9.0″ or whatever.
  4. If you’re using the standard xdebug port 9,000 (recommended), make sure that port is open on your firewall.  For most folks these days that means opening up the default OS firewall as well as forwarding a port from the router.  See the exceptional portforward.com for more information on router port forwarding specifics.

Now, assuming you already have xdebug plugged into PHP, modify php.ini or an .htaccess file with the following settings:

  • xdebug.remote_enable = true
  • xdebug.remote_handler = dbgp
  • xdebug.remote_host = your_client_ip

For security reasons it’s wiser to do this via .htaccess on directories that permit only authenticated access.

To debug, ask Emacs to listen for connections by going into GEBEN Mode with Meta-x geben. You should see “xdebug started.” in the status row at the bottom of the Emacs window.

Run your PHP script with the xdebug switch on, eg.

http://www.example.com/script.php?XDEBUG_SESSION_START

If everything is setup correctly, Emacs will load the source of script.php (be wary of security!) and allow you to step through the code.

Available commands are:

spc step into/step over
i   step into
o   step over
r   step out
b   set a breakpoint at a line
u   unset a breakpoint at a line
g   run
q   stop

Some gotchas: I’ve noticed the GEBEN expects the first keystroke to be “space”; often it will freeze otherwise.  GEBEN may also run into problems on certain session-related PHP commands.

Happy debugging!

Running Windows commands from PHP over IIS

Friday, January 4th, 2008

In order to run Windows commands via PHP functions such as open_proc(), apparently one has to grant read/execute permissions to the account under which IIS is running (usually IUSR_<servername>) on C:\WINDOWS\System32\cmd.exe. Be sure to do this for web apps that rely on external commands.

This of course took me an eternity to figure out. I was only able to piece together WebSVN‘s bizarre Windows mis-behavior after scouring through the remnants of forum posts limboed in Google cache. PHP.net of course has no proper details on this, though I do now better understand what proc_open‘s obscure and undocumented bypass_shell parameter might be about.

Ah yes, PHP on Windows. Obscure and irritating.

Kind of like me. Not that that makes it any better.

The MySQL extension (php_mysql.dll) won’t load after upgrading PHP

Friday, January 4th, 2008

Ugh. As usual, more weird problems while trying to upgrade PHP on a Windows box. Are we having fun yet?

If you find that the MySQL extension won’t load, then probably a previous PHP installer has placed a version of libmysql.dll somewhere else in your path. Look in c:\WINDOWS\system32\

The problem is almost certainly the reason for the following obscure comment

Although copying libmysql.dll to the Windows system directory also works (because the system directory is by default in the system’s PATH), it’s not recommended.

in the PHP MySQL documentation.

Make sure your home PHP directory is in your path, and that its finding libmysql.dll there and only there.

“This page cannot be found” (404) error when upgrading ISAPI PHP on Windows

Friday, January 4th, 2008

iis mappings for php This page cannot be found (404) error when upgrading ISAPI PHP on Windows

If you are using Zend’s installer to upgrade PHP on Windows, the installer will probably break your file type mappings. Double check to make sure that .php points to the correct ISAPI dll in IIS.

(IIS -> Home Directory -> Configuration… -> Mappings)

pmafind

Friday, July 27th, 2007

Ugh. Nobody seems to know what this thing is, though it seems to be some kind of PHP worm roving the internet looking for phpMyAdmin exploits. It appears to have been around since 2005 and searches for an exploit in the phpMyAuth class of older phpMyAdmin distributions.

I’ve seen it knock one of my servers on three seperate occasions; this from the first:

[05/Jul/2007:20:26:42 -0500] "GET /mysql-admin/main.php HTTP/1.0" 404 280 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /main.php HTTP/1.0" 404 268 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 285 "-" "pmafind"

Interesting that it looks for specific versions of PHP. And odd that it announces itself by specifying a user-agent. (“Hi, worm here. Please let me in. Got a bit of infesting to do.”)

Deadmoo has a good, recent-ish post about it, though mostly Google just returns random posts and stats pages listing the pmafind referer. Where do these things come from?