Avoid FileZilla Like The Plague

Filed under Webmasters | Leave a Comment

If you are using the free FileZilla FTP program you should remove it immediately and remove any files it leaves behind. There are a number of viruses that read some FileZilla files that expose your FTP details in plain text and then these viruses will alter EVERY index file (i.e. index.php,index.html etc) on your website.

The author has publicly stated that it isn’t his problem and he has no plans to encrypt the plain text data that FileZilla stores. You can find out about these files (which you also need to remove) at:


The author’s attitude is totally irresponsible. Granted, all computer users should keep their anti-virus up to date but I also think it is the responsibility of software developers to ensure that any private and/or confidential data is encrypted. I’ve been a developer myself for 30 years and there is no way I would ever store passwords in plain text.

Most open source / free software is high quality. The unfortunate fact is that if it’s free then the author has no level of responsibility as there is no customer relationship. It’s worth considering this when deciding which FTP client you are going to use.


Tip: Check those Apache log files

A problem that I’ve been asked to fix several times now is a slow Apache server. In several of these cases the slowness was caused because of the size of the logs. Most servers are set up to rotate the logs, but everynow and then things can go awry and the rotation stops. On a busy server you can find the logs growing over 500MB over the course of a couple of weeks. Once they get to this size it will generally start to slow Apache down as it has to open and write to that logfile.

I’ve seen logfiles that had grown to greater than 1GB and Apache really starts to strain at that point.

So… don’t forget to check the logs in /etc/httpd/logs (and /etc/httpd/domlogs if you have CPanel accounts). If the logfiles aren;t rotaing then logrotate is your friend (and youshould get acquainted with it right now).


Installing Clamscan on CentOS 5

I spent a bit of time searching for an answer to this and found it in a couple of places. Here are the required step to get clamscan installed on Centos 5.

1. Download the rpmforge package
wget http://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

2. import the rpmforge GPG key
rpm –import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

3. Check that you have a valid RPM file
rpm -K rpmforge-release-0.3.6-1.el5.rf.*.rpm

4. Install rpmforge
rpm -i rpmforge-release-0.3.6-1.el5.rf.*.rpm

5.  Install yum priorities
yum install yum-priorities

Yum-priorities allows you to add a priority parameter to each of the repositories listed in /etc/yum.repos.d. You need to do this to ensure that the base repositories always take precedence over the rpmforge repository.

6. Edit each of the .repo files in /etc/yum.repos.d adding a priority line to each repository like this:

name=CentOS-$releasever – Base

Give all of the repositories a priority of 1 except the repositories in the rpmforge.repo file – they should have a priority of 2

7. Install clamav (alter the filename if you have a 64 bit server)
yum install clamav.i386

8. Install the clamd daemon (you need this for freshclam which updates the virus database
yum install clamav.i386

9. Configure the clamd daemon to start at reboot
chkconfig clamd on

10. Start the clamd daemon
service clamd start

Run freshclam to update the database


mysqldump: Got error: 1017: Can’t find file: (errno: 24) when using LOCK TABLES

I was recently moving a site from one WHM/CPanel server to another WHM/CPanel server and found that this error was causing some problems. This was particularly interesting as I remember trying to move a CPanel account in the past (using /scripts/pkgacct) and we found that everything was fine except that none of the database tables had been backed up. On that occassion we were able to just recreate the empty tables as there wasn’t a whole lot of data but we never did get to the root cause of the problem.

This recent move was similar. It was actually a site that hosts around 2100 blogs with the WordPress WPMU version. Given that there were a lot of blogs with a lot of data, failure wasn’t an option so I decided to do a manual dump of the database. That’s when I saw the error from mysqldump. A quick Google of the error message turned up a similar issue and it wasn’t until after I read carefully that I found this person had the solution. It was in a bug report though and not all that descriptive so I thought it was worth blogging.

The cause of the problem is the default limit that MySQL has on open files. If you fire up your favourite SSH client and login to your server and issue the command:

mysqladmin variables

…it’s going to tell you this:

open_files_limit   | 1024

So, we now know that MySQL has a default limit of 1024 open files. That’s a lot of files…in most cases… but consider my situation where I have over 2000 blogs and each blog has multiple files. Even with 1 file per blog we’d be over that limit. Note that this issue should only happen with MyISAM databases as they use separate files for each table. Knowing that this open files limit was the issue my next step was to find out exactly how many files were in the database directory. To do that you can issue a command like:

ls /var/lib/mysql/my_database/ | wc -l

The /var/lib/mysql part is the default directory for MySQL MyISAM files and the my_database part would be the directory that is named the same as the database you are trying to back up. The command line above will list (ls) the files in the directory and the pipe to ‘wc -l’ will count how many words are displayed in the resulting ‘ls’ listing. In my case the number was:


That’s a heck of a lot of files! The fix was to edit /etc/my.cnf and add the following line to the [mysqld] section:


I then restarted the MySQL server and it completed the backup of the database and all of its tables.


Do Your Customers Trust You?

Filed under Webmasters | Leave a Comment

I’m sure you’ve seen web sites that carry various ‘trust’ logos. Trust is important when you expect the public to enter their personal information on your website. It may well be that you are entirely trustworthy and dedicated to the protection of your customers information, but is that the first perception they get when they land on your website?

Website and business certification services have been around since the 1990’s. The main difficulty with most services has been the high cost. Most small businesses can’t afford several thousand dollars per year. There have been (and probably still are) a handful of cheaper services around but you generally get what you pay for and some of the cheaper services are a bit dubious. They only provide very basic verification checks and for that reason they aren’t particularly trustworthy.

Trust-Guard provide business verification, PCI compliance/security scanning and other verification services at a fraction of the cost of most similar services. Their verification methods are second to none and include verification of your businesses website URL, business address, support phone number, support email address, managing member address (kept private), managing member phone number (kept private) and managing member email address (kept private). All of these aspects of your business are checked and verified, not by simply looking up online records but by actual contact being made to each of these contact points. Trust-Guard are just as diligent with PCI compliance, security scanning and privacy policy compliance.

The best part is that the cost for these very professional services ranges from $47-$87 per month. Business and website certification can significantly increase your website sales and with such a low cost there is no excuse to be missing out on sales due to a poor perception of the trustworthiness of your web site.

Full details and pricing are available at  The Trust-Guard Website.