Oh xdebug, where art thou?

I don’t have a stable development environment. I change hardware and software frequently so whenever my wife’s web site needs a revision I usually have to set everything up from scratch. I always develop on a Linux box (I am a Fedora user) and I’ll usually set up an apache server with MySQL running. For development I prefer NetBeans but I’ll use Eclipse if I have to.
For debugging I use XDebug and this is where the fun starts…

It never seems to be a smooth ride getting XDebug up and running, no matter what I do and judging from the many desperate cries for help on various forum threads I am not alone.

This blog post will not solve all your problems with getting xdebug working but I hope it might help you and give you a better set of tools to solve the problem.

The “problem” here manifests itself in NetBeans or Eclipse failing to connect to the debugger.

Firstly, if you have installed xdebug using any of the normal methods and phpinfo() shows an xdebug section then, at least in my experience, you’re good to go and any amount of hacks and fiddling in ini files is unlikely to fix your problem.
It is much more likely then that the problem is external and here is my simple check list of culprits that always seem to be behind my woes, either individually or together;

  • is your firewall allowing port 9000? (the default xdebug port, yours might be different but try not to fiddle with it too much)
  • is SELinux blocking you?

Run your firewall tool of choice (I just run system-config-firewall on Fedora) and check, or add, port 9000. Now try again…if working be happy, else…
Check if SELinux is barking about blocking a “name_connect” and see if port 9000 isn’t mentioned as well. If it is then you need to allow connections, obviously, and since I am not running my Linux box in an environment where I need to be too concerned about paranoid security I just blanket allow httpd (the apache server service I’m running on Fedora) to do whatever it wants;

#setsebool -P httpd_can_network_connect 1

If that doesn’t fix it then I sympathise because nothing is quite as frustrating as struggling with tools when all you want is to get the job done. But, in my humble experience at least, it seems to always end up being something like the above, I.e. something external is blocking xdebug from working. My point is that, unless you have a very peculiar set up, a plain vanilla install of xdebug with the standard ini file entries is fine and you should avoid fiddling with it before you’ve checked the external conditions – even though forum threads out there are quick to suggest it.

Good luck and happy debugging!

Advertisements

0x800F0A12 error when installing Win 7 SP 1 on dual boot machine

Here’s what I’ve got
  • I have a machine with two hard disks; on one there’s a Fedora (15) install and on the other Windows 7
  • I’ve got Grub set up to allow me to boot from either
And here’s the problem
  • The other day I fired up my Windows 7 install for the first time in a loong time and it wanted to install Service Pack 1 (SP1)
  • The install failed with nothing but an “0x800F0A12” message…not very helpful
The fix
The problem (as I found out from here) is that the service pack install requires the active boot partition to be the one with the Windows 7 install on. In my set up that partition is where the Grub loader lives so when the install checks the active partition it fails.
The article I’ve linked to outlines a solution involving the use of the Disk Management tool and DISKPART utility but there’s a simpler way to do this (at least in my situation).
  • Open the Disk Management tool (Computer->Manage->Disk Management)
  • Select the Disk/Partition on which your Windows install resides
    • In my case this was on Disk 1, Disk 0 was where the Grub loader and Fedora installs lived.
    • NOTE: The Disk Management tool will show which partition is “Active” and, since you’ve got the error, that will not be the one where Windows 7 lives. Check this: if your Windows 7 partition is Active and you still get the error then there’s something else going on…
  • Mark it as “active” by right clicking on it and selecting “Mark Partition as Active
  • You’re done
You will now have TWO (2) partitions active; one which is the one you had from before and one which is where Windows 7 lives. It doesn’t matter if you’ve got two, all the “marking as active” operation does is to inform the firmware that the partition can be booted from, not that it will
You can now proceed to install the Service Pack 1.
In my case it all worked.

installing msttcorefonts on Fedora 13 (fixing Wine problem)

I had to install msttcorefonts (the Microsoft TTF fonts used by most windows programs) to be able to run Wine in my Fedora 13 install. It was pretty clear that the fonts were missing; all Windows apps I tried to run, including the Wine config tool, were unusable with all text garbled.
To fix this I had to install the core fonts and as this was a (somewhat) non-trivial task I have decided to document it here:
Fundamentally I followed the steps on Benprove.com but had to do make some modifications to make it work.
Firstly I “su -“‘ed to get root access.
Then;
  1. cd /tmp or somewhere else convenient…
  2. Download font spec file for the rpm build process (2.0-1 at the time of writing):
    1. wget http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
  3. Install rpm-build and cabextract:
    1. yum install rpm-build cabextract
  4. Install ttmkfdir (required to build usable font files from TTF files):
    1. yum install ttmkfdir
  5. Now build the RPM package from the spec file:
    1. rpmbuild -ba msttcorefonts-2.0-1.spec
  6. Install chkfontpath (a util to configure X server font paths apparently)…and xfs which is a deamon that serves fonts to X server clients:
    1. Get chkfontpath (look for latest version if you do this):
      1. wget ftp://ftp.pbone.net/mirror/atrpms.net/f13-i386/atrpms/stable/chkfontpath-1.10.1-2.fc13.i686.rpm
    2. Get xfs:
      1. yum install xfs
    3. Build chkfontpath:
      1. rpm -ivh chkfontpath-1.10.1-2.fc13.i686.rpm
  7. Disable GPG (signature) checking in the yum config file so open /etc/yum.conf in your favourite editor, look for the line “gpgcheck=1” in the “[main]” section and change it to “gpgcheck=0”. Save the file.
  8. Now you can FINALLY install the fonts themselves from the RPM:
    1. yum localinstall  /usr/src/redhat/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
  9. Clean up by re-enabling gpg check in /etc/yum.conf (DON’T FORGET THIS!)
  10. Log-out and log back in…

And that was it; Wine is now usable.

Permission denied: rsync backup from my Fedora box to my DS207+ (DSM 2.3) NAS….

I’ve got a NAS that I’m very happy with; the DS207+ from Synology. I back up my wife’s massive Photoshop and Ilustrator files from her Mac without problems (using Superduper) – however, backing up stuff from my Linux box (Fedora) has turned out to be a little bit more tricky. I might have set up the DS207+ wrongly with respect to the users, groups and privileges from the start (I’ve had the box longer than I’ve had Linux) but regardless of what the reason is the practical problem is that trying to back up to the server – using DejaDup or grsync (can be found in the standard repositories both for Ubuntu and Fedora) – fails with “access permitted” problems.

I’ve tried to rsync using the server’s IP address;

192.168.0.193:/volume1/Jarl/backup

and I’ve tried to use a mount point after adding a cifs mount statement to my fstab file:

//192.168.0.193/Jarl /mnt/ds_jarl cifs credentials=/etc/.ds_credentials,_netdev 0 0

To no avail and still I get problems with rsync throwing up “Permission denied (13)” errors when it tries to create (or delete) directories.

From what I’ve been able to gleam from various fora there seems to be an issue that quite a few people have been struggling with in one form or other. If this is related to a subtle difference in the use of CIFS or Samba I don’t know but the bottom line is that it doesn’t work…for me at least.

Anyway, here be what I did to make this work for me. It might not work for you but hopefully it will give you a possible avenue to try out, should you have problems getting rsync to work with your DS207+.

  • Firstly I followed the instructions here to create an ssh key file. I subsequently copied one into my /home/jarl/.ssh folder (had to create it first) as per instructions. I also copied it over to a new /homes/admin/.ssh folder on the DS207+ (simply using the File Station.) Following that I could ssh in without entering a password BUT as opposed to what the instructions on said web site says I had to specify that I was the “admin” user for this to work. I believe this has something to do with the limitations on who can ssh into the DS207+. In short, the ssh line to log in had to be this:
    • ssh -l admin -i /home/jarl/.ssh/rsync-key 192.168.0.193
    • NOTE: the use of “-l admin” here!
  • Next I could compose the full rsync command line and instruct it to use ssh (as admin!) to connect to my NAS and do it’s thing:
    • rsync -rv -o -c -z -e ssh -l admin -i /home/jarl/.ssh/rsync-key 192.168.0.193:/volume1/Jarl/Backup /home/jarl/
    • NOTE: I composed the whole command line using grsync and just added the -e ssh… part manually

This works fine now, although all the files sync’d up are owned by “admin” of course…

I will try to make this work for the standard user as well; it makes no sense that you should have to be admin to make this work..!

Sorting out Rkhunter on Fedora 13 and hooking it up to Anacron

I’ve used rkhunter (Root Kit Hunter) in the past (on my old Ubuntu machine) and even though it might be a little overtly paranoid it’s not a bad idea to run sometimes and check your system integrity. Now that I’ve recently got a fresh Fedora 13 install I wanted to set up rkhunter again on my clean system.

I installed it with YUM:


# yum install rkhunter

and invoked it to make it update it’s file properties database (basically saying: this system is clean, use it as a reference for future checks)

# rkhunter --propupd

(note: run as root)

And then proceeded to run a check on the system (not really needed, since I just propupd’ it but I just wanted to check to see if things worked):

# rkhunter --check
Invalid XINETD_CONF_PATH configuration option - non-existent pathname specified: /etc/xinetd.conf

(my highlighting)..

Ok, so apparently this is a known problem on Fedora since version 11 and is fixed by commenting out the following line in the /etc/rkhunter.conf file:

XINETD_CONF_PATH=/etc/xinetd.conf

Having done that rkhunter runs as expected and checks the system for problems.
Btw, you can get more detailed info on rkhunter here.

Now I wanted to add rkhunter updates and checks to Anacron so that it could be run every couple of days. Since I’m on a laptop that isn’t always on Anacron is the right choice (as opposed to Cron.) More on that can be found here.

To make this work I had to edit the /etc/anacrontab file which lists the different tasks to be run. By default it contains some entries related to cron, there’s some trickery involved between the two, but that’s not relevant to the task at hand. All that was needed was to add the following two lines to the file:

5 5 rkhunter.update rkhunter --update
5 15 rkhunter.check rkhunter --check --sk --rwo

This reads:
No earlier than every 5 days, no earlier than 5 minutes after anacron first starts, a task we identify as “rkhunter.update” is run and the command is “rkhunter –update”…simples.

Similar for the next line, which is the actual rootkit check. (The parameters “–sk” and “–rwo” mean: don’t ask for key presses and only output warnings.)

NOTE: I had to search around a bit before I realized that all the tasks in the anacron (and presumably cron-) -tab files are run as root…

Anacron (and cron) both email the output from these runs to the root account. To see what’s been emailed the simple (but not elegant!) method is this:

cat /var/spool/mail/root

So now you know how to install and run rkhunter on Fedora 13 and to get it set up to run on a regular basis using anacron.

How to mend a broken GRUB after swapping Ubuntu with Fedora…and understanding partition indexing in the process

Long story short; I’ve got a laptop with Windows 7, Linux Mint and Ubuntu Linux on it. I installed Linux Mint last and got the grub2 menu at boot up which let me choose Windows or Ubuntu or Mint. All was well.
Then I decided that I was grown up enough to run Fedora linux instead of Ubuntu and so it was time to replace the latter with the former. That was no problem but for some reason or other (not presently known) the Fedora grub loader install didn’t detect any of the other OS’es in their respective partitions on the hard drive.

So what I had was a Fedora-only boot.

To fix this and get my Windows 7 and Mint installs back again I had to do the following:

  • Understand that Fedora (13) uses “legacy grub” and not “grub2”
  • Identify where the other partitions existed in “grub speak” and how to map from something like “/dev/sdaN” to “(hd0,M)…
  • Edit GRUB file and be done with it

Step 1: the difference between legacy and 2.0
Legacy grub and grub2 are different. I had been using grub2 via my Mint 8 install (which is also what Ubuntu 9+ uses.) The most important two differences (and the only ones that mattered for me in my quest to restore normality) were these:

  1. Legacy grub enumerates partitions on a hard drive starting at 0, grub2 starts at 1. This threw me when I referred to my Mint (Ubuntu) grub2 parameters side by side with the (now active) Fedora legacy grub parameters. Just keep it in mind…
  2. Legacy grub has all it’s options in a file called “menu.lst” usually (probably always..?) stored in the /boot/grub folder, grub2 stores it’s options (and menu items) in a file called “grub.cfg” in that same folder.

Step 2: Identify where your other partitions are
In this case my Fedora install was the 1st logical partition in the 1st extended partition of my main hard drive. Extended partitions always start at 4 (i.e. the first extended partition is partition primary number 4 on a disk, see this excellent guide for more on this.)
Now, to map from your /dev/sdaN to a corresponding grub (hd0,M) you do the following:

if is Legacy Grub then M = N-1
else
M = N

Simples…

So, in my case, the 1st Logical Partition in the 1st Extended Partition is /dev/sda5 = (hd0,4) in legacy grub speak but (hd0,5) in grub2 speak. (NOTE: the 1st Extended Partition itself was /dev/sda4, but it’s just a “container” so it isn’t bootable.)

To identify which sdN corresponds to what I used the DiskUtility because it gives a nice visual overview of your drive and all the info you need (it also shows you how things are physically laid out, which is nice.)

The windows 7 partition was further down (not in the extended area) on /dev/sda3 and hence was mapped directly to (hd0,2/3) in legacy/2 grub speak.
My Mint partition sat a bit higher up at /dev/sda8 = (hd0,7/8).

Step 3: Edit GRUB file and be done with it
Ok, this is all you need and now for the editing. Recall that I started out with this legacy GRUB menu.lst (after installing fedora over my old Ubuntu partition);

default=0
timeout=5
splashimage=(hd0,4)/boot/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.33.4-95.fc13.i686)
root (hd0,4)
kernel /boot/vmlinuz-2.6.33.4-95.fc13.i686 ro root=UUID=6d1df250-76a4-4fe8-9afc-4d398a9b6eac rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet
initrd /boot/initramfs-2.6.33.4-95.fc13.i686.img

And so, armed with the correct (hd0,M)’s, added Mint and Windows like this:

title Linux Mint 8 Helena, linux 2.6.31-14-generic
root (hd0,7)
kernel /boot/vmlinuz-2.6.31-14-generic ro root=UUID=a2d1515b-d544-4475-9f0d-a111e2b61e77 quiet splash
initrd /boot/initrd.img-2.6.31-14-generic

title Windows 7 (loader)
rootnoverify (hd0,2)
chainloader +1

Btw, I’ve assumed you know how to specify the other GRUB parameters but quite frankly you can do this without understanding them completely… All I did (before I actually spent some time RTFM’ing) was to copy’n paste the entry from the Fedora install and just making the adjustments needed. The Windows7 entry seems to be standard for booting Windows (and perhaps Mac OS too, but I don’t know) and basically says “don’t try to figure out what it is, just load up and let go.”

One last word: how did I figure out the UUIDs for the partitions? Well, there’s many ways to skin this cat too but DiskUtility is the easiest because it presents the information when you click on a partition. Another option is to run “blkid” in the terminal (you don’t need to be su to do this) which lists all the drives and partitions in your system together with their UUIDs and file system types. Handy.

And that, as they say, was that.