Remote Debugging of PHP with Komodo IDE on Mac OS X

I am doing development on Mac OS X 10.7, with Komodo IDE 6.1.3 using PHP and Apache, both installed from Macports.

I want to enable remote debugging of my PHP scripts running under Apache using Komodo.  Following instructions from Activestate’s website, I have configured my system as shown below to make it work.

I have already installed Apache and PHP using Macports, so I only needed to install php5-xdebug using the following command:

sudo port install php5-xdebug

I then added the following to the /opt/local/etc/php5/php.ini file:

;xdebug config
;the .so file is loaded under /opt/local/var/db/php5/xdebug.ini
;zend_extension=no-debug-non-zts-20090626/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
;xdebug.idekey=<idekey>

Then in Komodo IDE, set the tcp port to listen for debugging connection as shown below:

When I wish to debug a script, I just add the following query to the end of the browser url for the script, and xdebug sets a browser cookie that turns on debugging for all scripts from that point forwards.  The query string to add is:

?XDEBUG_SESSION_START=1

To disable the debugging again, you just need to delete the cookie from your browser.  Using Firefox, go to the Privacy settings under preferences:

Then click on the “remove individual cookies” link, and type in “localhost” as the search criteria for the cookie.  This will show all cookies for the localhost where you are debugging, and you will see the XDEBUG cookie as shown below.

Simply click on the Remove Cookie button, and debugging is turned off again.

The Mac OS X Terminal – My keyboard mappings

I made the switch from Windows to Mac OS as my chosen desktop operating system nearly 4 years ago, and I’ve never looked back.  I continue to use Linux as my preferred server operating system. Of a handful of frustrations from my switch to Mac OS, one I have solved today.  The Mac OS Terminal application has always seemed quite limp as compared to the various terminals offered by Linux distributions such as those from KDE and Gnome.  Even terminals from Windows such as PuTTY seemed more capable.

However after spending a little time to get to know my Mac OS Terminal, I have come to realise that it isn’t quite as limp as I thought.  Either through the Leopard or Snow Leopard updates, Tabs were introduced (I don’t recall seeing them in Tiger which was when I last paid any attention to Terminal).  Neat!

So I starting looking at the biggest annoyance with Terminal, the inability to navigate the Bash shell command line with the keyboard.  With other terminals I have used on both Windows and Linux, it was possible to press Home to go to the start of the shell command, End to go to the end, and use Ctrl-Left and Ctrl-Right to move the cursor word by word through a command line.  This might seem trivial but I’m quite proficient with the UNIX shell (from my days as a UNIX Sys-admin) and tend to write reasonably complex shell commands.  There is nothing more frustrating than realising you omitted a switch to one of the first commands in a pipeline.  There was no choice but to hold down the left arrow cursor key and wait for the cursor to gingerly wander back to the start of the command where it can be positioned to insert or correct a switch. This has always given me the shits!!

So after some investigation and reading a couple of blog posts on this issue, I found an article: The complete keyboard mapping for Leopard’s Terminal.app by Henrique Bastos which provides instructions on how to configure these keys.

Restoring a PGP WDE Encrypted drive

When using PGP (now owned by Symantec) Whole Disk Encryption (WDE) to encrypt your system drive, there are some hoops to jump through to do a system restore from backups. If you backup your system drive using SuperDuper! or Carbon Copy Cloner, then your backups will not be bootable. There are some things you need to do to the backup copy before the drive will boot again and you can re-encrypt.

The problem is that PGP WDE creates a extra partition on your drive, usually at slice 3 (ie. /dev/disk0s3) that contains a copy of the /System/Library/CoreServices directory of your existing Boot Volume which is typically /dev/disk0s2. This copy is unencrypted and used to boot the OS, and load the PGP WDE drivers which can then access your encrypted /dev/disk0s2 partition (ie your main drive). Backup tools such as SuperDuper do not copy this extra partition to the new drive/image, but the drive is still blessed to boot from /dev/disk0s3, which no longer exists. To fix the problem, mount the restored volume. If you cannot access the backup/restored drive from an operating mac, then you need to boot your Mac using your OSX install DVD. Once you have booted the install DVD, choose the Utilities menu and select Terminal. Mount your drive by typing:

diskutil mount disk1

This should mount it under /Volumes/MacIntosh HD
or whatever the name of your volume is.

So there are two tasks we need to perform, using a single command. We need to set the boot partition as /dev/disk1s2 rather than /dev/disk1s3 (substitute the disk? number for your drive – make sure you get this right – if unsure, seek assistance from an expert). The other task is to re-enstate the original apple boot.efi file, overwriting the pgpboot.efi file. The pgpboot.efi is not required because the drive is no longer encrypted (at this stage). So execute the following command:

cd /Volumes/<mount point>
sudo bless --folder System/Library/CoreServices/ --bootefi System/Library/CoreServices/appleboot.efi --setboot

Now the drive should be bootable once again.

Once you have rebooted the drive, you can use the PGP tools to encrypt the drive again as was done previously.

Damien.

Macports: How to configure php5 for apache2

I guess I am spoiled with Redhat’s integration of all these packages where you simply install and away you go. Macports isn’t quite a polite in this regard. The default config files are incomplete and not enabled when it is installed.

So I have had to do some massaging to get php working.

The file /opt/local/apache2/conf/extra/mod_php.conf is missing some configuration parameters. I’ve changed mine to look like this:

<IfModule mod_php5.c>

AddType  application/x-httpd-php         .php
AddType  application/x-httpd-php-source  .phps

AddHandler php5-script .php
AddType text/html .php

DirectoryIndex index.php

</IfModule>

I specifically had to add the handler and also load the module. Then in the /opt/local/apache2/conf/httpd.conf file, I had to add the line: Include conf/extra/mod_php.conf as there wasn’t even a commented out line that would include this module.  Also in the /opt/local/apache2/conf/httpd.conf file, also need to add the line LoadModule php5_module modules/libphp5.so so that the php library is loaded into Apache.

A graceful on the server:

sudo /opt/local/apache2/bin/apachtctl graceful

and away we went.

Damien.

Addendum

Turns out that a message is printed at completion of the install, which was not apparent to me because I used a GUI to do the installation. The message states:

If this is your first install, you need to activate PHP in your web server.

To enable PHP in Apache, run
cd /opt/local/apache2/modules
/opt/local/apache2/bin/apxs -a -e -n “php5″ libphp5.so

A useful tip I highlighted in a previous post helps to find this sort of information after installation.  This command simply adds a LoadModule option to the main httpd.conf file, but does not add the other configuration options above.  So you still need to make the above changes.

Macports: How to install mod_perl2

When attempting to install mod_perl2, I received an error code 2. Very unhelpful error message, but after some googling, I found this bug ticket which explains what you need to do.

Essentially, you need to forcibly uninstall perl5.12 (or perl5.10) and then re-install with the threads variant:

sudo port -f uninstall perl5.12
sudo port install perl5.12+threads

Then you can install mod_perl2 with:

sudo port install mod_perl2

Not a particularly elegant solution, but nonetheless gets the job done. Hopefully this issue will be fixed in the future.

Damien.

Macports: Some useful tricks

I have decided to jump ship from Fink over to Macports.  Out of the frying pan and into the fire perhaps, but Fink’s packages just don’t seem to be kept up to date as well as Macports.  I’m keeping a close eye on brew as well, although I too am skeptical of its dependence on Apple packaged software, especially when it comes to OS upgrades.

Anyway, here are some very handy tips that I have discovered in my travels.

Post-installation instructions

Some packages provide instructions on installation completion.  At times you may have ingored them or used tools such as Porticus to do the installation in which case the instructions are lost in the scroll from all the dependencies that went along with it.  So, there are a couple of commands that you can use to get this vital information back:

This command looks at the notes for a package (if it has any):

sudo port notes $packagename

If there are no notes, you can look at the portfile directly using:

sudo port cat $packagename

You will probably see some instructions to be printed at the end of the script

How do I start or stop daemon processes

So this always frustrates me, and each packaging system does it differently. Macports wraps some scripts around the launchd system of MacOS 10.4+. So you can use the launchctl load -w /Library/LaunchDaemons/${packagename}.plist to do it. But a more convenient way is to use the load/unload option to the port command.

sudo port load $packagename
sudo port unload $packagename

Sadly, this not only starts and stops the daemon process, but also enables or disables auto-startup at the same time. You can do things separately, or at least not without knowing the individual package’s startup scripts.

As I come up with new tips and tricks, I’ll add them to this blog post.

Damien.

Installation of Postgresql on MacOS X using Macports

Installing and configuring postgresql using Macports is a nightmare.  Documentation is very difficult to find.  Trawling the blogosphere, I have assembled the following procedure that I have had to follow to make it all happen, as it should.

To install postgresql84 on Snow Leopard (10.6) using Macports, execute the following commands:

sudo port install postgresql84-server
sudo mkdir -p /opt/local/var/db/postgresql84/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql84/defaultdb
sudo -u postgres /opt/local/lib/postgresql84/bin/initdb -D /opt/local/var/db/postgresql84/defaultdb

Now to make sure that the postgres user account can be executed using the su command, we need to give postgres a shell:

sudo dscl . -create /Users/postgres UserShell /bin/sh

Then merge the Sys V Shared Memory Kernel parameters from the /etc/sysctl.conf.pg file with your existing /etc/sysctl.conf file (if you already have one):

sudo sh -c "cat /etc/sysctl.conf.pg >>/etc/sysctl.conf"

You can reboot at this point so that the new Sys V shared memory configuration in /etc/sysctl.conf is loaded by the kernel.  Alternately, being a UNIX you can execute the following command to get you going right away:

sudo sysctl -w `cat /etc/sysctl.conf.pg`

Next, we need to create the logfile directory and make it writable by the postgres user:

sudo mkdir -p /opt/local/var/log/postgresql84
sudo chown postgres:postgres /opt/local/var/log/postgresql84

Next, add to the /opt/local/lib/postgresql84/bin directory to your path variable in either /etc/profile or ~/.profile and you should be set

export PATH=/opt/local/bin:/opt/local/sbin:/opt/local/lib/postgresql84/bin:$PATH

Now create yourself a postgres database user account

$ createuser `whoami`
Shall the new role be a superuser? (y/n) y

To make the database server accessible via a TCP socket, edit the /opt/local/var/db/postgresql84/defaultdb/pg_hba.conf file and add the following two lines:

host    all         all         127.0.0.1/32          md5
host    all         all         0.0.0.0/0                md5

Edit the /opt/local/var/db/postgresql84/defultdb/postgresql.conf file and add the following line:

listen_addresses = '*'

Now, we should be right to start the server.  We use MacOS’ launchctl command:

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql84-server.plist

Now you can connect to the database server with:

psql template1
psql (8.4.7)
Type "help" for help.

template1=#

Hopefully this has been useful to someone else, as I have spent over 2 hours *&^%*&% around with this to get it working.

 

Damien.

DVICO Remote Control for MythTV Frontend on Mac OS

Have a Mac OS MythTV Frontend, and a DVICO remote control and USB receiver?  Like them to work together?  This blog post may help you.

I have the above scenario and was looking for a way to remote control an old Power Mac G4 (circa 2001) running MythTV as a frontend.  The machine does a stellar job running my 42″ Fujitsu Plasma panel, however the inconvenience of having to get off my arse to fast forward advertisements was just too much.  So I searched around and found the wonderful DVICO Remote Application for Mac OS by Peter Wyss.  The way DVICO Remote works is to call an Applescript each time a remote button is pressed.  The Applescript is passed some parameters from the DVICO USB Receiver driver (also by Peter) which it then uses to determine which remote button was pressed.  The Applescript then simply performs an action based on the remote button.  The Applescripts provided by Peter supported only iTele and iTunes, neither of which I was using.  So I read through Peter’s Applescripts and did some Google searches.  I found Applescript to be a very cryptic and difficult language to learn, due to the scattered and sketchy online documentation it has – unless of course purchasing a book.  I’m too cheap for that.  Anyway, after a little frustration and hair pulling, I created an Applescript that would translate DVICO remote control buttons into instructions for a MythTV Frontend on a Mac.

The script cannot be uploaded to my blog, so it is linked to my Dropbox account.  After downloading the .scpt file, copy it over the IrRemote.scpt file located in Peter’s DVICO Remote Control Application.  The path is:

/Applications/DVICO Remote.app/Contents/Resources/AppleScripts

Then point and shoot.

Peter also has instructions on his website for replacing the default Applescripts with custom ones.

If anyone finds this script useful, I’d love to hear from you.  Leave me a message at the bottom of this post. :)

Follow

Get every new post delivered to your Inbox.