LAMP with ·dotmanila » Apache

Internal Server Error (500) From Your PHP Application

admin — Wed, 28 Jul 2010 03:29:05 +0000

Recently I was working on a script on a fresh virtual server. The script was pulled from a production server and was being actively used. When I try to run it on the test server, it was mysteriously not working, Apache access_log shows 500 HTTP response code, PHP log_errors is ON,even display_errors is set to ON but there were no errors being displayed or logged. Thoroughly deducing my .htaccess, Apache virtual host configuration and doing a sanity check on the application itself, the mysterious error was being caused by one PHP extension missing, in this case php-ldap.

/var/www/sites/mediaweb

FFMpeg-PHP: undefined symbol: php_gd_gdImageSetPixel

jervin — Fri, 02 Oct 2009 15:01:32 +0000

I was recently updating ffmpeg-php on one of our servers to the latest SVN release of the 0.6.3 branch. On a 64bit CentOS 5.3 with PHP 5.2.11, the extension compiled and installed fine however Apache will not load it and spit out the error below:

PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/ffmpeg.so’ – /usr/lib64/php/modules/ffmpeg.so: undefined symbol: php_gd_gdImageSetPixel in Unknown on line 0

Surely enough, the GD extension was there, but why is ffmpeg complaining about not finding that shared symbol? Because, ffmpeg is loading first than GD (alphabetically) and such symbol has not been loaded. After adding the GD extension line on top of ffmpeg making sure it loads first the error went away and all is well again.

mod_perlite: Reviving an old part of the dynamic web.

jervin — Thu, 15 Jan 2009 11:33:14 +0000

Back in the 90′s, when the web was new and anything dynamically scripted is ever exciting, CGI scripts takes the role.As the web evolved, mod_perl made it simpler for programmers to write highly capable web applications. And indeed the web is constantly evolving. With the advent of PHP and its upload and run deployment, it took the lead with statistics.

But Perl and CGI scripts may not be lagging behind forever, with the development of mod_perlite, an Apache module the matches deployment simplicity of that of PHP, Perl may again be on the rise.

From its freshmeat.net project page, the creators Aaron Stone and Byrne Reese describes:

mod_perlite is a lightweight Apache module that embeds a Perl interpreter and suggests a default configuration where any file ending in “.pl” is interpreted by Perl. It is the Perl equivalent of PHP in its simplicity and nothing like mod_perl in its complexity.

I believe truly, these is one of the 5 things Perl absolutely needs to gain more adaptations from new breeds. As chromatic from the O’Reilly blog network writes on his article Five Features Perl 5 Needs Now:

mod_perlite, the equivalent of mod_php for Perl. mod_perl is an amazing piece of technology, but it asks a lot of administrators — it effectively takes over the web server. Perl on the web could benefit from a system which allows cheap hosting providers to say “Just upload a few files into this directory, and everything will happen for you automatically!” without worrying about other customers on the same host fighting for resources (or namespaces or memory or…).

Very Serious Developers may still use mod_perl — but novices and the rest of us who aren’t handling more than a hit per second at peak time should have something easier to set up and gentler on resources than CGI.

There are many programming languages out there, and many would argue popularity is a major factor for adaptation. I’d agree most of the time, as soon as mod_perlite hits your local repository shelves Perl could again gain the internet buzzwords.