Fixing json_encode() Problem in PHP 5.5 on Ubuntu 13.10

I upgraded to Ubuntu 13.10 over the weekend and everything went pretty well. It automatically brings PHP 5.5 with it, too. When I tried to run a web app I was working on, though, I received this message:

Fatal error: Call to undefined function json_encode()

I subsequently Googled around and came across a highly-ranked blog article which makes it sound like PHP 5.5 drops support for json_encode because of some silly licensing argument. The truth is, PHP 5.5 does NOT drop support for json_encode. For a much better and much clearer explanation, I recommend reading this article.

Now, enough of the balleyhoo! How do we fix it?

It was was easy! Install the php5-json package and restart Apache. Voilà!

sudo apt-get install php5-json
sudo /etc/init.d/apache2 restart

Note that the author of the blog article linked above mentions that re-installing the php5-dev pacakged fixed his woes. While that didn't help me, you may want to give it a try if the above didn't help you.

Error starting Apache (httpd) - Configuration files not readable

Here is an interesting issue I ran into today while setting up a new VM. I had copied the Apache conf file and SSL/TLS certificate files onto my new server as root using wget. All of the file's ownerships and permissions looked right and I thought I was ready to go. Then I ran into these two misleading errors:

Could not open configuration file /etc/httpd/conf.d/ssl.conf: Permission denied

and

SSLCertificateFile: file '/etc/pki/tls/certs/mydomain.com.crt' does not exist or is empty

Contrary to what Apache reported, the ssl.conf file did have the correct permissions and the crt file did exist and had contents. So what gives? Our trusty SELinux friend is at it again, it seems. Because I had copied these files in from somewhere else, SELinux was detecting something off. It is an easy fix, though. Just run this command, specifing each of the files above:

restorecon -v /etc/httpd/conf.d/ssl.conf

and

restorecon -Rv /etc/pki/tls/certs/

That -R is for "recursive" and it means I want it to do the whole directory.

After fixing up the SELinux permissions for these files I brought in, everything started up just fine!

PHP to Remote Database Error: "Can't connect to MySQL server on..."

On a new server migration project I am working on I have separate web and database servers. So, I use a private network to connect them. It took me a day to get working, so I am putting up a post to help others in similar situations.

First, just to clarify, I knew it was a web server problem (and not a network or db permissions issue), because I could connect to the MySQL server just fine from the MySQL command line on the web server. But, when I pinged the PHP web page from my browser I'd get this error:

Can't connect to MySQL server on '10.1.1.1' (13)

The problem was SELinux, which was installed and crackin' down on Apache rights.

One simple fix:
setsebool -P httpd_can_network_connect=1

More information can be found in this nice article:
http://www.ehow.com/how_2090983_connect-remote-database-under-selinux.html

SELinux would allow me to connect from the command line just fine. I could even execute the PHP script from the command line and connect fine. But SELinux did not like it when Apache tried to connect to a computer on the network. Hence the policy update, as stated above.

If you have other issues or it appears that your db server is having issues, here are some other MySQL debug tips as well.

APC.php not Working

I was getting a new server up and running and wanted to install APC (Alternative PHP Cache). Things were going great. I even ran phpinfo() and noted that APC had an entry. Everything was super, right?

I wanted more confirmation, so I used SSH, located apc.php and copied it to a domain for public access. I wanted to know how well APC was working for me. However, it wouldn't run. It sent back errors and when I tried to debug it I got no where.

Turns out, APC wasn't really doing much of anything. I had PHP installed and running as a CGI instead of an Apache Module. If PHP runs as a CGI, APC closes at the end of each script run and the cache is lost—it doesn't make much sense to use APC in this situation. While runing as a CGI has some security benefits you lose a bit of performance and, more importantly to me, APC doesn't really work.

I use WHM and so I went to "Main >> Service Configuration >> Apache Configuration" and then changed the PHP 5 handler to DSO. This solved the problem and apc.php loaded just fine the next time I tried. And it even had some pretty stats for me to see.