PHPMyAdmin blank whitescreen (414 Request-URI Too Long)

Ran across an interesting issue where PhpMyAdmin on a newly installed CentOS server was not rendering in a browser. Or more accurately, it was rendering but the CSS kicked in and caused the browser to display a blank page rather than the desired login screen. (Doing a View Source on the page showed that the login form was in fact there, but hidden by CSS.)

After checking the obvious things: PHP running (with error reporting on), file permissions, Apache working, VirtualHost definition correct, I was stuck. There were no indications of a problem, and PHP reported nothing. (Because, as we will see, there were no errors to be displayed…or was there?)

Finally, I turned on Firebug and refreshed the page. Voilà! There were actually two issues, but they were hidden within additional calls in the backend:

Screenshot from 2016-05-05 17-29-03

Wow, those two long URL strings! One URL was:


A quick search uncovered a possible fix. The default Apache limit of the request line needed to be made longer to accomodate PhpMyAdmin. Doing this was simple. I added the directive to ‘/etc/httpd/conf/httpd.conf’ like so:

LimitRequestLine 800

I tried a few different lengths and found that 700 was too short, but 800 worked fine. Also, though I simply added this to the conf file, according to the docs you can add this within the VirtualHost rather than making it blanket covering the entire server.

Hope this helps others.

PHPStorm and debugging IP issue

Recently I was helping someone troubleshoot an issue using PHPStorm and Zend Debugger. In this case Zend Studio was able to debug an application using Zend Debugger while PHPStorm was failing unless an SSH tunnel was used. The error received was:

Host ‘’ is not allowed to open debug sessions – please configure zend_debugger.allow_hosts in the ini file.Failed to connect to host ‘’, reason: ‘Connection refused’.

The person experiencing this issue was attempting to debug a site in a VirtualBox virtual machine from the host machine. Both the host machine and the virtual machine were running Ubuntu 14.04. At first glance I thought adding to the allowed hosts would do it. But turns out it was more than that.

In this case we knew there was not a firewall blocking access, so it had to be networking.

To start things off I wanted to take a look at what PHPStorm was listening to, so I used the broadcast port 20080 to see this in a browser:

Screenshot from 2016-04-04 16:13:09

So it appears PHPStorm was attempting to use the IP addresses linked to the host systems ‘localhost’ and ‘hostname’, but not an IP address accessible via the network. This meant the server would never be able to send information back to the IDE without the use of an SSH tunnel, because it could not reach or of the host.

Unfortunately PHPStorm doesn’t provide a way to alter the listening IP addresses in the preferences, so we were left with either using an SSH tunnel to allow port forwarding of the listening port (10137) back to the host, or manually informing Zend Debugger where the IDE would be located.

Zend Debugger Tweak

By default Zend Debugger will automatically attempt to detect the IDE settings, as shown below:

Screenshot from 2016-04-04 16:23:04

However, this wasn’t working because PHPStorm was not reporting a usable IP address, so we needed to update the settings manually:

Screenshot from 2016-04-04 16:22:37

NOTE: Checking the box “Use browser’s IP Address” did not fix the issue. The IP address needed to be entered.

With this done, the server now knew where to reach the IDE for debugging sessions. One downside to this is if the host machines IP address changes, this setting will need to be updated.

This post is one in a series on debugging. For others click below:

Setting up step debugging in Zend Studio
Using an SSH tunnel to step debug through a firewall

Edit: Please head out to the PHPStorm ticket system and +1 this fix to make this a thing of the past.

Clone Hard Drive to External USB Drive via CLI

Thumb and USB drives

No matter what OS you’re cloning, using “dd” via command line will still work.  I personally tested while cloning a 1TB Ubuntu hard drive to a fancy new 1TB SSD.

Backstory: I purchased a new Dell 7737 laptop with a 1TB hybrid drive, which turned out to be slower than watching paint dry compared to the old SSD I’d been using for a few years.  Otherwise it is a kickass laptop.  So I purchased a 1TB SSD after finding they are roughly 50 cents per GB these days…very affordable.

First I put the new SSD into USB caddy I had laying around for backup purposes.

Next I created a bootable USB stick with an Ubuntu ISO image following the instructions at:

Windows =
Ubuntu =

With the USB stick created I booted the system to Ubuntu using the USB LiveCD disk image.  It may require a BIOS change to enable the PC/Laptop to boot from USB device.  Doing this will not make any changes to your current hard drive as long as “Install Ubuntu” is not chosen.

Once booted up I was able to use Gparted, which is a standard app on the LiveCD, to create a new partition table on the new drive in the external USB caddy.

I then used fdisk via command line to find all disks and gain their identifiers needed.

fdisk -l

With the new partition and the identifier of the USB drive I was now ready to initiate the copy.  I used the following command to do that:

dd if=/dev/sdc of=/dev/sdb mb=8M && sync

NOTE: ‘if’ = read from and ‘of’ = write to.

It takes a very long time for this to finish up, especially with larger drives, but the end result was a working drive with my data on it.

After completion I simply switched out the SSD from the caddy with the internal HD in the laptop and all worked well.

Good luck!

Zend Server and Sendmail failure bug

While trying to test the sendmail feature of Zend Server 6.3, on Ubuntu and CentOS, there was a bug.  I discovered that utilizing the Mail Preferences area of the Adminitration->Settings page and sending a test email to myself with the Sendmail option ended in an “Unknown error”.

The error returned by Zend Framework 2, which is used by Zend Server 6 was a generic error (Unknown error) if Sendmail returned an error status, but an empty error message.  Not much help, or was it?

Since the error appeared to be caused by Sendmail not returning a proper error the search for the issue led there.  See where my logic was going? My next step was to test sending an email with the PHP mail() function, and see if that shed any light on the issue.  Unfortunately it worked, which meant the issue was elsewhere.  But if the error wasn’t with PHP, Apache, Sendmail, Zend Server, or Zend Framework, where could it be?

At this point I enlisted one of my coworkers, Roman Basayev, who nailed it down.

Of course!  Zend Server on Linux installs Lighttpd for the Zend Server gui, and there must be a setting there for using Sendmail.  Sure enough in the file ‘/usr/local/zend/gui/lighttpd/etc/php-fcgi.ini’ there is a setting for ‘sendmail_path’ and it was empty.  So PHP running on Lighttpd was not able to find Sendmail, and therefore was not getting a decent error message.

The fix:

In the file ‘/usr/local/zend/gui/lighttpd/etc/php-fcgi.ini’ update the ‘sendmail_path’ to be ‘/usr/sbin/sendmail -ti’.  These are the paths on Ubuntu and CentOS, others may vary.

sendmail_path = "/usr/sbin/sendmail -ti"

After restarting Zend Server, all should be good  to go now.

CentOS networking not active after installation

I needed to install a CentOS 6.4 server in a VM and after installing I was not able to hit anything on the Internet, or any network for that matter.  When I tried using the yum packages manager I received the error “Couldn’t resolve host ‘…” and I was at a loss on what to do next.  I was not able to ping anything.

This led me to look into the networking and and upon opening the /etc/resolv.conf I found it totally empty.  So I then opened /etc/sysconfig/network-scripts/ifcfg-eth0 and found the issue.  The line “ONBOOT” was set to “no”.

The complete file /etc/sysconfig/network-scripts/ifcfg-eth0 after I altered it: (NOTE: the only thing I altered was the ONBOOT flag.)


After changing “ONBOOT” to “yes”, then rebooted for the configuration to take effect, all is good now.  I probably could have simply done a networking restart, but reboot on a fresh system was pretty fast.