BenV's notes

Those of you running Slackware 14 or current probably have noticed the move to the Apache httpd v2.4 already.
On my webservers I haven’t yet dared to upgrade from the stable 2.2 version, but I figured it might be a good time to test out an upgrade procedure.

Notable problems / changes

This new version of the Apache httpd brings a few things that you should really pay attention to before attempting to upgrade. Well, you could ignore it, but it would surprise me if you wouldn’t end up with a broken webserver 😉
So you might want to look into these things:

1. Configuration syntax changes
2. Handling the Pleuris-Hoeren-Paaltjes aka PHP disaster
3. Switching to the MPM-event module

Of course you’ve already done your homework and read upgrading to 2.4 from 2.2, right? 😉 (continue reading…)

The challenge of today: Installing the latest Magento version on some virtual host owned by a generic webhoster on the other side of the planet for some friends. Shouldn’t be too hard, right? Well, it isn’t really, but I ran into two annoying things that took me longer to work around than I would like.
So if you found this article through google, maybe this saves you the time :-p

First annoyance: Where do we get the source for the latest Magento release?
“Stupid BenV. Obviously you get that from the Magento homepage from their downloads section”.
Yeah, that’s what you’d think. So you go there, hit ‘download’ (or go to /download in your url bar, surprisingly it works) and now you have to “Select your format“. So much for getting a wget-able url here, but we’ll copy paste that from our browser, right?

Well, after selecting your format (“Your disk.” Ha. Ha.) and clicking on the Download buttong, you are faced with?
Oh of course.

The URL shown when hovering the download button already gave it away – “http://www.magentocommerce.com/download/login_form“. A fucking login form. FOR A FREE OPEN SOURCE PRODUCT. *RAGE*.
“Login, it’s Easy!“, they say.
“Join the community now and take advantage of the following: *bullshit*“, they say.
Well “FUCK YOU MAGENTO WEBSITE“, I say.
(if you do take the time to fill out their login form, make sure to enter something@mangetocommerce.com as your email address and enable all the checkboxes)

Until they change it again you can use this wget command to work around this bullshit:

benv@vhost:~$ wget --referer http://www.magentocommerce.com/download/get-started http://www.magentocommerce.com/getmagento/1.7.0.2/magento-1.7.0.2.tar.bz2


Next up, the issue I ran into. After creating a database, untarring the tarball and pointing the webserver to the right place it was time for the web based installer. Just click next a few times, enter the database info, next …. what’s that?
PHP Extension “pdo_mysql” must be loaded..
Errh… ok. So I check what this webhoster’s PHP configuration flags are … phew, they included PDO. As a shared module. Oh well, guess we’ll need to enable this in php.ini then. Long story short: it’s not enough to just include pdo_mysql.so.
If you include only pdo_mysql.so, PHP will not complain, at least not in any log file I could find on that webhost, but PDO is still not loaded.

Solution:
Make sure php.ini contains:

extension=pdo.so
extension=pdo_mysql.so
extension=mcrypt.so

(that mcryp one should not be necessary there, but they say without it you could run into other issues, like mcrypt not being loaded either).

PHP. What’s worse than having to work with PHP? Working with PHP that you didn’t compile yourself :-p

One of our customers has a website with some custom-made CMS made in php.
The customer asked us to fix some things, but since I hate touching pleuris-hoeren-product code, especially when the original coder is prutser and has never heard of templates (which is really weird, considering this is a CMS… maybe it’s just lazyness… then again, the echo "blabla\"escaping\"quotes\"is\"so\"much\"fun\n\n\n50 more lines here"; style really doesn’t show much intelligence…)

Anyway, I figured I might as well move the entire thing to an open CMS project that I’ve heard some good things about and already implements everything and more that the customer could ever want. That’s CmsMadeSimple.

Converting the old website to the new one was trivially easy. Copy/paste the stylesheet (first mistake), edit the basic template with a menu section, create the pages (copy/paste, copy/paste).
After fixing the html errors that were in the source the page looked like a pixel-perfect copy of the original.
Except for the places where the HTML errors were fixed that is. (the center class now actually worked for instance)

However, when adding the print links I ran into an interesting issue.
Adding print links is also a trivial thing, simply put {print} somewhere in the template, and possibly add some options to show an image instead of a text link etc.
However, the links were kinda broken, they gave empty pages. So I figured “duh, the print template still needs to be fixed”. However, as soon as I added the {content} tag to the template, I got a nice internal server error. WTF.

Checking the logs I could only find nice reports of this:

php-cgi[2530]: segfault at bf04b3f0 ip 08348d32 sp bf04b3f4 error 6 in php-cgi[8048000+6e9000]
php-cgi[2564]: segfault at bf639750 ip 08348d32 sp bf639754 error 6 in php-cgi[8048000+6e9000]
php-cgi[2804]: segfault at bf200230 ip 08348d32 sp bf200234 error 6 in php-cgi[8048000+6e9000]
php-cgi[2896]: segfault at bf00cbb0 ip 08348d32 sp bf00cbb4 error 6 in php-cgi[8048000+6e9000]

Well… .I expect nothing less from php. Pleuris-hoere-product. But how the heck… just because I added content to the print page? What’s so special about that?

After digging around (enabling logs etc) and enabling fopen for php (which I had disabled for security), I noticed this:

[Wed Jul 14 12:22:29 2010] [error] [client 123.611.204.37] PHP Warning: file_get_contents(http://some-site/oncmsmadesimple/) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required\r, referer: http://some-site/oncmsmadesimple/
[Wed Jul 14 12:22:29 2010] [error] [client 123.611.204.37] in /www/vhosts/some-site/cmsmadesimple/modules/Printing/Printing.module.php on line 96, referer: http://some-site/oncmsmadesimple/


AHA!. Apparently the printing module fetches the content (or at least, tries to) from the webserver, fails, and then segfaults php. Excellent code guys!
The reason for the failing is obvious from the logs here, I require authentication for the website since this is a test location that shouldn’t be public. Quick fix, allow the server to skip the login (vhost config):


AuthType Basic
AuthName "Testsite CmsMadeSimple"
AuthUserFile /lala/passwordfile
Require valid-user
Allow from 127.0.0.1
Allow from 192.168.1.1
Satisfy Any



Problem solved. (Hint Printing Module: render your own shit, don’t cheat with fopen/curl)

Oh yeah: CmsMadeSimple rocks for these simple websites where your customer wants to “change some texts and add a picture”. If they can handle word, you can make them handle this (but show them how!).
Give them permissions to add pages and nothing else, write a decent template for them, done.

As I love to tinker around with apache/php installations to get them to work as fast as possible while still keeping some security in tact, I found myself messing around with FastCGI today. But why?! Here’s why:
On this machine I previously installed suPhP to get php scripts to run as a normal unix user instead of user apache (so users have the ability to completely lock out their database settings etc for other users on that machine). However, to speed stuff up on a magento webshop I wanted to have a PHP opcode cache running (I tried out APC). (continue reading…)

That IS what it stands for, right?
Or maybe the last P is for Programs….. oh no, silly me. It’s for PEOPLE. Now I get it.
Anyway, the quote of the day:

configure: error: There is something wrong. Please check config.log for more information.

(continue reading…)