Category: Configuration

Joomla! upgrade

Unbelievable that such a simple thing as an upgrade to a newer version of CMS may cause any headache these times. Recently I have received a warning message from my host (lunarpages.com) that I still use an old version (1.7.2) of Joomla! for my company site, while a newer version is available. I have tried to follow official upgrade procedures for about an hour without success, resulting in wrong layouts and half-working admin functionality, and finally ended up just downloading the complete package for Joomla_3.1.5-Stable-Full_Package.zip and simply unzipping it to the current installation folder. That did the trick (well, almost) leaving me with the similarly popular warning message

Joomla upgrade warning Error
Your host needs to disable magic_quotes_gpc to run this version of Joomla!

After some googling around the following solution worked. I have created two files as shown below in the folder with Joomla! installation (so not affecting other websites) and that did the trick.


[php.ini]
magic_quotes_gpc = Off
session.save_path = "/home/<user>/tmp"


[.htaccess]
/home/<user>/www/<site>/php.ini

Enjoy!

(Re-)configuring Apache SSL on Ubuntu server

Since my old server died there were many things waiting to happen. First of all the main ‘carrier’ for my project information was located on a webserver obviously hosted on the dead server. For security reasons it only serves HTTPS, so, guess what, I needed to setup it up again.
The very first thing I found that my SSL certificates were no longer valid as the key used to generate them was happily buried on (both) dead hard disks. Arrrgghhh. OK, luckily it takes only few mouse clicks on GoDaddy site to re-generate the certificates. You perform

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

on the server where the domain is to be hosted (in my case my smallish-greenish server) and copy/paste the content of the .csr file to the GoDaddy’s interface. Viola! You can download your certificates now and put them under e.g. the corresponding VirtualHost:


SSLEngine on
SSLCertificateFile /etc/apache2/certificates/watchitforme/watchitfor.me.crt
SSLCertificateKeyFile /etc/apache2/certificates/watchitforme/watchitfor.me.key
SSLCertificateChainFile /etc/apache2/certificates/watchitforme/gd_bundle.crt
ServerSignature Off

Good. Restart Apache using e.g.

sudo /etc/init.d/apache2 restart

…browse to your https://domain.tld and WTF-WTF-WTF…

Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Watta… well, this is something new apparently, but you are also required to edit the Apache ports.conf file, and add

Listen 443
NameVirtualHost *:443

and then in your virtual host setup you need to say instead of

<VirtualHost domain.tld:443>

put

<VirtualHost *:443>

Restart Apache again and you get your pages nicely served through HTTPS. C’mon, why so much trouble each time?..

p.s. There are a lot of posts about Chrome, IE, etc settings, but check the root cause first!

Running external FastCGI XMLRPC server behind Apache 2.2

Another frustration and several lost hours worth few lines in blog. My goal was to run our FastCGI application locally behind a Web server. Our production setup has Lighttpd, but installing it on my just reinstalled MacBook looked a bit too much. Well, not now having lost so many hours trying to figure out few steps, but nevertheless…

Another frustration and several lost hours worth few lines in blog. My goal was to run our FastCGI XMLRPC server locally behind a Web server. Our production setup uses Lighttpd, but installing it on my just reinstalled MacBook looked a bit too much. Well, not anymore, having lost so many hours trying to figure out few steps, but nevertheless…

What we have

  • A standalone FastCGI application that serves XMLRPC and is already started by hand or another way (active fcgi back-end mode) running on e.g. post 8081
  • A Web server acting as a front-end running on e.g. post 8080

All we need is to forward the XMLRPC calls from clients received by the front-end to the back-end.

Lighttpd

server.modules += ( "mod_fastcgi" )
$SERVER["socket"] == ":8080" {
fastcgi.server = (
"/RPC2" =>(( "host" => "127.0.0.1",
"port" => 8081,
"check-local" => "disable",
"docroot" => ""))) }

(I have removed a lot of ‘beautification’ for brevity).

Apache
Well, this caused me hours of trial and error, but finally it is shockingly simple


Listen 8080
FastCgiExternalServer /var/www/blah -host 127.0.0.1:8081
<VirtualHost *:8080>
RewriteEngine On
RewriteRule ^/RPC2$ /blah [QSA,L]
</VirtualHost>

So where is the catch? Well, there seem to be several. And I am not saying that they are completely not described, it is just that it was not obvious for some reason. Anyway…

  1. The path to the external FastCGI server. There is no ‘blah’ in my ‘/var/www/’ ! Moreover, my application has a totally different name, but… that does not matter. What does matter is that the path mentioned before the ‘blah’ MUST exist and Apache MUST have access to it. As correctly described in some very good documentation this is just a ‘handle’, but Apache still checks whether it has proper access rights to this path. So DO NOT put ANY path there as some may suggest, but make sure it is a valid one. The easiest ‘hack’ is to use the overall DocumentRoot.
  2. Depending on your implementation of the FastCGI XML-RPC server you may want to rewrite ^/$ or ^/RPC2$, but note that here you have to use the same name ‘/blah’ provided for the external FastCGI server. This is the only place the name is needed to have the mapping (pretty confusing actually and looks more like a hack to me).

After all the mod_proxy_fastcgi seemed like a better alternative, but that one is only for Apache 2.3, while I am happily stuck with 2.2 on MacOSX Snow Leopard for the moment.

Happy configuring!

More on MySQLdb on Snow Leopard

Well, my frustrations with MySQL and MacOSX continue. This time after a copmlete clean reinstall of everything I have stumbled upon the ‘old friend’ MySQLdb Python module. Apparently setting up this one causes a lot of frustration and blogging. Here is what I have found.

1. Check your platform. I have an old MacBook and naively installed 32 bit MySQL on it. Man, I was wrong. Since I wanted to use the default MacOSX Python I should have checked that one fist. You can do that by executing the following commands in the Python interactive shell:

import sys
import math
math.log(sys.maxint, 2)

It gave me… “63.0”. Wow… Apparently I do have 64-bit Python!

2. Having 64 bit Python you must install 64 bit MySQL. So go and get the proper version.

3. If you think you’re there you’re not getting my frustration yet. If you would get MySQLdb, build it now and run as I did, the following statement

import MySQLdb

will likely to result in

Traceback (most recent call last):
File "", line 1, in
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/oleksii/.python-eggs/MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Library not loaded: libmysqlclient.18.dylib
Referenced from: /Users/oleksii/.python-eggs/MySQL_python-1.2.3-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Reason: image not found

Ok, this was it. I had to dig around and finally found out that it is a known bug in the at least 5.5 version of MySQL, explanation and the fix can be looked up at the MySQL bugs website.

In short you have to perform the following

sudo install_name_tool -id /usr/local/mysql/lib/libmysqlclient.18.dylib libmysqlclient.dylib

where ’18’ needs to be replaced with your version.

4. Finally get the MySQLdb (I’ve got 1.2.3). Build it, make sure the proper architecture is used. The architecture can be enforced with e.g. the following commands:

export VERSIONER_PYTHON_PREFER_64_BIT=yes

(or the coresponding one for 32 bits)

Wow, finally import worked as I had expected. WTFx10…

…and all this after several hours debugging for a problem that existed for 10+ years and appeared due to changes in the new Visual Studio compiler optimizations… great… another sleepless night…