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:

https://{domain-withheld}/phpmyadmin/js/get_scripts.js.php?scripts%5B%5D=jquery/jquery-2.1.4.min.js&scripts%5B%5D=sprintf.js&scripts%5B%5D=ajax.js&scripts%5B%5D=keyhandler.js&scripts%5B%5D=jquery/jquery-ui-1.11.4.min.js&scripts%5B%5D=jquery/jquery.cookie.js&scripts%5B%5D=jquery/jquery.mousewheel.js&scripts%5B%5D=jquery/jquery.event.drag-2.2.js&scripts%5B%5D=jquery/jquery-ui-timepicker-addon.js&scripts%5B%5D=jquery/jquery.ba-hashchange-1.3.js&scripts%5B%5D=jquery/jquery.debounce-1.0.5.js&scripts%5B%5D=menu-resizer.js&scripts%5B%5D=cross_framing_protection.js&scripts%5B%5D=rte.js&scripts%5B%5D=tracekit/tracekit.js&scripts%5B%5D=error_report.js&scripts%5B%5D=config.js&scripts%5B%5D=doclinks.js&scripts%5B%5D=functions.js&scripts%5B%5D=navigation.js&v=4.6.1

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.

Ubuntu 16.04 and PHP 7 not rendering

After reloading my work laptop with Ubuntu 16.04 LTS (I prefer to do a reload versus an upgrade, for each LTS version) I was very excited to install PHP 7, and installed using the standard Ubuntu repositories using typical commands:

$ sudo apt-get install apache2
$ sudo apt-get install php7.0

However, after doing the installs I discovered PHP scripts would not render in a browser. After a small amount of digging I realized that doing the base installs did not include one important piece. The package ‘libapache2-mod-php7.0’ was not automatically installed as expected, as it did in the past. (I don’t remember needing to install it separately in the past.) Hopefully the package maintainers fix this at some point. Your mileage may vary.

$ sudo apt-get install libapache2-mod-php7.0

So one quick install like shown previous and all is working fine.

Happy PHP’ing.

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 ‘127.0.1.1’ is not allowed to open debug sessions – please configure zend_debugger.allow_hosts in the ini file.Failed to connect to host ‘127.0.0.1’, 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 127.0.1.1 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 127.0.1.1 or 127.0.0.1 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. https://youtrack.jetbrains.com/issue/WI-7465

Fun with Travis CI and PHP projects

I know I should have done this a long time ago, but I finally got my hands dirty with Travis CI.  I wanted to set up a php project on github to use Travis CI to monitor the status, in case I forgot to run the tests prior to pushing.  Unfortunately it was not as easy as it’s made out to be.  But now that I’ve done it once, it’ll be easier next time.  So, here is how I tackled it.

First, creating an account and getting started was easy.  I simply clicked the “sign in” link on the Travis CI site and entered my github credentials which authorized Travis CI to connect to my account. (the site informs you exactly what Travis CI will have access to)  Once that’s done Travis gets all my repos, so I can then activate them for Travis CI.  If that doesn’t happen automatically there is a handy “sync now” button to coax Travis CI.

NOTE: To connect public repos you would use https://travis-ci.org, while for private repos you would use https://travis-ci.com.  While pubic repos are free private ones cost money, though you do get 100 pushes free to get you started.

Second, it’s now time to click the + and add a new repo to be tracked by Travis CI.  After clicking you will be presented with a list of your repos to choose from.  It is simply a matter of turning the repo ON by clicking the switch.  I also clicked the wrench to select the option to “Built only if .travis.yml is present”.

Travis CI add repo

The structure of the app I added looks like this: (including all files needed for travis and unit testing) https://github.com/adamculp/api-consumer

Application structure

Third, I needed to create the .travis.yml file with the directives needed to make it all work.  Here is what my file looked like.

travis.yml file

Pretty simple.  Here is what it all means: I specified what language to use (php), and what versions of the language to test with (5.3, 5.4, and 5.5), I also instructed to have Composer install prior to any other scripts run (needed to ensure there was an autoloader, created by Composer), and finally I add the phpunit command and tell it where to find the phpunit.xml file (in this case it was in the tests directory).

Fourth, ensure that PHPUnit runs as expected locally.  Yes, you will need unit tests on your code.  That’s like one of the main reasons to do this in the first place.  Here is what my phpunit.xml and bootstrap.php look like:

phpunit.xml file

The phpunit.xml file is fairly simple.  It informs where PHPUnit can find the bootstrap.php file (same directory as a the phpunit.xml), and sets a whitelist of directory where code can be found (some use a blacklist and specify not to use the /vendor directory), and what directory to find tests in (the current directory).

phpunit bootstrap.php file

The bootstrap.php file specified by the phpunit.xml file is even simpler, as it only specifies where to find the autoload.php file created by the Composer install.

Fifth, take a quick peek at the settings for the repo on github and you will notice that Travis CI should be already set up and ready for something to be pushed.

github settings

Final, that’s it!  That is everything needed for Travis CI.  Of course this example is very simplistic, since the repo and tests are only on a single wrapper class I created.  But it’s good enough for a start, and if you need more the documentation is pretty good.  With these files created, all that remains is for me to commit changes to git, then do a push to origin at github.  Once the push to origin happens a Travis CI trigger at github fires and informs Travis CI to create a new build on a VM (virtual machine) then run the tests on the newest code.  After Travis CI finishes it lets you know with an email, and through the site. (green = good)

Travis CI feedback

One last thing you may want to do is add the Travis CI image to your README.md at github.  This will allow you and others to see whether the current master branch had a successful build, or if it failed.

[![Build Status](https://travis-ci.org/adamculp/api-consumer.svg?branch=master)](https://travis-ci.org/adamculp/api-consumer)

Travis CI build status indicator

Enjoy!

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.