1. Into Linux & server management
2. Interested in building fail over Linux VPS solutions
3. Happy to play about creating your own hosting environment

This one might be for you…

Webbynode have a coming soon Beta. According to their blurb.

…the killer new flexible Xen VPS service for developers & for people in need of better hosting.

….advanced features to create clusters between webbys, iscsi San storage, amazon ec2, and more.

Sounds like it could be something worthwhile to test, can’t wait to have a go.

Permission denied: /path/to/web/data/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Think permissions, permissions, permissions. If you have chmod’ed your .htaccess 644 or even 777 and it’s still not working, start traversing up your directory tree and make sure apache can access everything at each level.

Permissions required will depend on the exact server and software setup, but generally something like 755 (drwxr-xr-x) is probably a good start.

After “yum update” and a reboot, we see:

[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1
/dev/sda1:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate
superblock:
e2fsck -b 8193

Followed by:

Give root password for maintenance
(or type Control-D to continue):

How not very nice!

It seems the UDEV and XEN aren’t playing nicely, I’ve had problems with UDEV and OPENVZ in the past. Could also be to do with the kernel versions running on the DOM0. Anyways…

umount / <--- un-mount the file system
mount -n -o remount, rw / <--- mount the file system in read/write

To disable udev in CentOS 5 you edit /etc/rc.d/rc.sysinit file and comment out the line: /sbin/start_udev

Didn’t work for me though, things must have been a bit messed up, so to get going I used.

/bin/mknod /etc/udev/devices/sda b 8 0
/bin/mknod /etc/udev/devices/sda1 b 8 1

After a reboot we were back in business, or are we…

INIT: no more processes left in this runlevel
INIT: Switching to runlevel: 6

LOL… or not

Even more udev breakage that can be fixed with:

/bin/mknod /dev/null c 1 3
/bin/mknod /dev/random c 1 8
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

Bah!

* JInstaller::install: SQL Error. DB function failed with error
number 2006
MySQL server has gone away SQL=CREATE TABLE IF NOT EXISTS
`jos_comprofiler` ( `id` int(11) NOT NULL default ‘0′, `user_id` int(11) NOT

Other modules and components would install fine, the only one failing to install was comprofiler, part of the Community Builder module for Joomla/Mambo. Other parts of the same module were also installing fine.

The full error was a bunch of MySQL inserts headed by the message above.

I had a bit of a look around and couldn’t locate any particular permission or other issues, the server was running fine with just this single module being a pain.

The Apache error log was showing line after line of errors when you tried to install the module.

PHP Notice: Only variable references should be returned by reference in /***.com/html/libraries/joomla/application/module/helper.php on line 288, referer: http://***.com/administrator/index.php

PHP Notice: Trying to get property of non-object in /***.com/html/libraries/joomla/application/module/helper.php on line 93, referer: http://***.com/administrator/index.php

Having a look through the referenced code didn’t point out anything at all and Google wasn’t much help either So I started having a look elsewhere.

When I set the php debug errors for this domain to go to syslog I noticed in the logs that just before the error showed up each time in the logs, there was an FTP connection from 127.0.0.1

I looked into this a bit further and discovered hundreds of lines in the FTP log containing the name of the module/component that was being installed.

Breaking this down it seems to go like this, using the Joomla admin interface you select to install a module, choose a zip file from you local disk and hit install, this is uploaded to the server in the browser, straight after this we see:

Fri Jun 6 06:26:03 2008 0 127.0.0.1 563483 /***.com/html/tmp/com_comprofiler.zip b _ i r username ftp 0 * c

The web server connects to itself via FTP and uploads the zip file to a tmp folder, this is the file that you just uploaded via the web browser, huh? Next we see:

Fri Jun 6 06:26:04 2008 0 127.0.0.1 133024 /***.com/html/tmp/install_4848d87b323b5/com_comprofiler/admin.comprofiler.controller.php b _ i r username ftp 0 * c

It looks like the files have now been expanded from the zip and are being uploaded to a randomly named install directory under tmp. Next up we see more FTP action:

Fri Jun 6 06:26:19 2008 0 127.0.0.1 133024 /***.com/html/administrator/components/com_comprofiler/admin.comprofiler.controller.php b _ i r username ftp 0 * c

The exact same files that were ftp’ed into the tmp/random install directory are coming in again, this time being uploaded into the components folder.

Mean time back at the ranch, PHP has given up waiting. In /etc/php.ini this particular web server has max_execution_time = 30, so after 30 seconds of the script running it dies with an error. I assume this feeds back into the main install script which doesn’t do a great job of catching it and triggers the random errors noted above, error messages that don’t exactly lead you to the right thing

Working around this was simple enough, I uploaded the zip file to the server, unzipped it to a location inside the customer folder and pointed the Joomla admin install module at the location on disk.

The module installed successfully with no issues, but interestingly enough the admin script grabbed it from the disk location on the drive and uploaded it via FTP to the components folder.

So how many files came in over FTP in 30 seconds before the PHP execution limit was reached?

[root@server ~]# grep “06:26″ /var/log/xferlog | grep -c 127.0.0.1
821
[root@server ~]#

Not nice.

And how many files were FTP’ed from the server to itself when doing the install from a directory location on disk, inside the same webspace even.

[root@server ~]# grep “06:37″ /var/log/xferlog | grep -c 127.0.0.1
206
[root@server ~]#

It still took 8 seconds or so to do this, but at least it was inside the PHP execution limit.

I’m no Joomla guru, today was the first time I’ve even looked at it, however it seems rather a broken and inefficient way to go about trying to get module or component files into the right spot.

You could also increase the PHP max execution time to work around this problem, I didn’t bother trying but somewhere around 60 seconds might work.

So if your Joomla module/component installs are randomly failing with error messages that are clearly wrong, you might be hitting this issue, especially for a larger module or component with a lot of files.

UPDATE: 30/06/2008

The other reason you will get this error is if your MYSQL timeout limit is too low. I’ve been using the following settings and haven’t run into any more problems installing Joomla modules.

php.ini

max_execution_time = 60

max_input_time = 60

my.cnf

wait_timeout = 60

connect_timeout = 60

Pingdom GIGRIB is a unique, distributed website monitoring service. GIGRIB users can add websites they want monitored, and in return their computers become a part of the GIGRIB monitoring network.

A while back I setup the GIGRIB client on the only Windows PC in the house and it seemed to run ok. I was contributing several thousands of checks a day to the project and monitoring a couple of sites I was interested in.

The reporting is pretty basic and alerting fairly non-existent so I stopped using the service, however I forgot that the GIGRIB client is setup as a service on the Windows computer and just keeps chugging away.

I was poking around our network recently and saw this traffic on the router ethernet port that the Windows PC is connected to. Bearing in mind we weren’t home the whole day so the PC was just sitting there….

Investigation tracked the usage back to the GIGRIB service that was running on the PC, it was using around 500MB per day, yeah a cool 15GB per month. I stopped the Windows GIGRIB service and you can see the traffic stop at the right hand end of the graph.

It’s a pity the client is so basic and you can’t seem to customise how much time you want to give back to the project, at 15GB a month I’m not that keen to leave it going 24×7.

As I shifted the last of my sites from Dreamhost to a VPS I was wondering about some of the values I was seeing. For example here’s a fairly normal day in the life of a wordpress site hosted at Dreamhost.

Lots of spikes all over the place, fairly average huh? What was weird was that a different site hosted on the same server wasn’t as bad, although still a bit average.

Looking into a bit more I wondered if it was because the site above was a database intensive site, driven by Wordpress CMS. Dreamhosts’ mysql driven sites have always been dog slow compared to everywhere else I’ve hosted, so that would make sense.

I dropped a note to the guys at mon.itor.us just to confirm what is being measured in the http test. I received a prompt reply which confirmed that the http test measures the time taken to receive the http header, not the loading of the page as such.

So how does the mon.itor.us http response measurement look for the same site now it’s on a small VPS? Take a look below…

Waaay better on average over the day. The mysql driven sites especially feel faster on my VPS as compared with the Dreamhost shared account, mon.itor.us just confirmed the “feeling”.

Like a lot of people I just forward all my email to Gmail, it’s got a great spam filter, plenty of storage, accessible via web, POP & IMAP, maybe the only downside is they can just de-activate your account without warning

Recently my email seemed to stop working, on investigation it seemed that Dreamhost were still accepting the email however it wasn’t arriving at my Gmail account.

So I logged a ticket and got a reply 12 hours later saying they were aware of a slowness issue with email forwarding to Gmail and I would be updated when it was fixed.

Quoting: “Right now we are experiencing some slowdowns sending emails to Google’s GMail service.”

Days later still no news from my ticket, however earlier this week I got a test message that I had sent… last week.

Received: from staffnet.xxx.com.au (staffnet.xxx.com.au [203.x.x.x])
by spunkymail-mx5.g.dreamhost.com (Postfix)
Thu, 29 Nov 2007 20:07:59 -0800 (PST)

Received: from brazilian.dreamhost.com ([66.33.209.64])
by mx.google.com with ESMTP id k19si1079983rvb.2007.12.05.13.29.07;
Wed, 05 Dec 2007 13:29:07 -0800 (PST)

6 days

Thankfully I was in the process of moving the last of my hosting away from them.