Zoom Media Gallery 2.5.1 RC4 Freezes or Crashes Apache2

After getting a little bit of time to research the new problem causing Apache2 to crash or freeze up and use 100% CPU utilization, I believe I have found at least part of the problem.

The Zoom Media Gallery 2.5.1 RC4 does not check to ensure that the Page Number is legit.  I kept checking the server-status on Apache and each of the times, I kept noticing that the website address including an address with a negative page number.  How could it be possible for a page number to be negative?  I don’t know, but ask Google!  Google keeps spidering the web sites here and many times has a negative page  number – which doesn’t make any sense.

To head off this issue, I inserted a few lines of code into the zoom.php file in the /components/com_zoom directory.  I created these lines directly under the:

//error reporting(E_ALL)

comment around line 34 – just before the:

// Create zOOm Image Gallery object

Here is the code to insert:

// Check to ensure the Page number is valid (not negative) or throw an error
$PageCheck = mosGetParam($_REQUEST,’PageNo’);
if ($PageCheck < 1 && isset($PageCheck)) {
     echo (‘Page number cannot be zero or negative.’);

I am not 100% sure yet if this will fix all the problems with Zoom Media Gallery 2.5.1 RC4 and the 100% CPU utilization with Apache, but I know this will help curtail the problem.  When I tried to put the same URL that caused an Apache process to use 100% of the CPU into my web browser, it sat there until the five minute timeout period for scripts (I set a five minute, or 300 second timeout period in the php.ini file under max_execution_time).

I have completed all changes needed for this issue in my Downloads section.  You can simply download the full component there and install it as required.

Problem Arises with Zoom Media Gallery 2.5.1 RC4 (Week 8 Release)

After updating the website to Zoom Media Gallery 2.5.1 RC4 (Week 8 Release) from Zoom Media Gallery 2.5.1 RC1, there are now more troubles that are occurring. The update does fix the problem with your gallery being deleted with the upgrade and a SQL vulnerability, but it now introduces a new problem.

Since development has stopped on Zoom Media Gallery, I am now contemplating changing to another gallery component.  Unfortunately, I have over 750 pictures on the site with plenty of descriptions of each.  Changing to a new gallery possibly means doing all of this again.

The problem I have now seen with Zoom Media Gallery is 100% CPU usage.  Google indexes my site on a regular basis and because of this, it seems to overwhelm PHP and cause Apache to create several threads – all take up the CPU and the processes will not terminate unless killed manually.

I uncovered this by using the built-in Apache server-status mechanism that gives you information about the process id, CPU usage, and the web page requested.  All of the processes frozen had an address for the Zoom Media Gallery.

All of the processes had a "sectionid" of one specific number – a number not used on any links anywhere on the site.  So, the question is – where is this 'sectionid' number coming from?  Maybe after some time and after Google gets all of the pages spidered, the issue will go away – hopefully.

Zoom Media Gallery 2.5.1 RC4 Upgrade

Last night I was doing some research on the Zoom Media Gallery – which I have used for over a year on my site.

I found that there has been some vulnerabilities in the Zoom Media Gallery 2.5.1 that was addressed and resolved with the latest version – Zoom Media Gallery 2.5.1 RC4 (Week 8 Release).

I know a few months back, I attempted to update my gallery to RC4 and it completely wiped out all of my galleries!  I wasn’t going to rebuild everything since I have over 750 pictures in my galleries at the time of this writing.

I setup the newest gallery on two client sites and they love it; it has many new features like automatically adding watermarks to images in the gallery to prevent individuals from downloading and printing them (if running a photography business) and also has the feature where it will not allow people to link directly to the picture because it hides the true address for the picture.

Well, I wanted to get this update on my site and another client site that I originally built using the Zoom Media Gallery 2.5.1 RC1.  The first thing I decided to do was to backup all of my tables that started with jos_zoom so I had everything.

I then began comparing the differences in the tables from my installation of Zoom Media Gallery 2.5.1 RC1 and another installation of a client site running Zoom Media Gallery 2.5.1 RC4.  I found a few differences:

Table:  jos_zoom

Field:  custom_order
Type:  varchar(20)
Collation:  latin1_swedish_ci
<no attributes>
Null:  Yes
Default:  NULL

Field:  catimg
Default:  Change from 0 to NULL

Table:  jos_zoomfiles

Field:  imgname
Type:  Change varchar(50) to varchar(255)
Null:  Change No to Yes
Default:  Change <empty> to NULL

Field:  imgfilename
Type:  Change varchar(70) to varchar(255)
Null:  Change No to Yes
Default:  Change <empty> to NULL

Field:  imgdescr
Type:  Change varchar(20000) to mediumtext

Table:  jos_zoom_comments


Table:  jos_zoom_ecards


Table:  jos_zoom_editmon


Table:  jos_zoom_getid3_cache




So those were the differences in the database between Zoom Media Gallery 2.5.1 RC1 and Zoom Media Gallery 2.5.1 RC4 (Week 8 Release).

I then proceeded to uninstall the current version I had (2.5.1 RC1) and install the new version (2.5.1 RC4 Week 8 Release).

After I was done, I was extremely happy to see that with the latest release, all of my galleries and pictures were still intact!  Apparently before the creator of Zoom Media Gallery closed the project down indefinitely, he put out an update to address the issue of the galleries and media being deleted.  I have to thank the developer for that, because it made doing the update painless and seamless.

I have posted the newest version of Zoom Media Gallery under my Downloads section just in case anyone is looking for this version.  It is also available on the developer’s site, but I’m not sure how long it will be available there.

Automatic MySQL Monthly Backups

As the number of users on my systems increase, so do the number of databases. I do a MySQL monthly backup at the first of each month just in case of anything happening that could corrupt the data. Well, this starts to be a time consuming process when the number of databases increases.

So, I thought I would share with everyone a quick solution that I have done for automated monthly backups of the SQL databases.

# Script will backup databases
directory=$(date +%m-%d-%Y)
cd "/home/www/Database Backup"
mkdir $directory
cd $directory
mysqldump –user=USER_HERE –password=PASSWORD_HERE –databases DATABASE_NAME > DATABASE_NAME.sql

So, lets dissect this to make it easy to understand.

directory=$(date +%m-%d-%Y)

This line creates a variable called directory. It will then assign the month, day, and year to this. Since I create a folder each month to hold the backups, this is how I set it up. So, the directory variable will contain "12-01-2008" for December 1st, 2008.

The next couple of lines:

cd "/home/www/Database Backup"
mkdir $directory cd $directory

will move the current directory to where I store the database backups. Then, it will create (mkdir) the new directory name by using "mkdir $directory" as listed above. since "directory" is holding 12-01-2008, this is the same as "mkdir 12-01-2008". By using the variable, however, this will allow the script to change this each time the script is run instead of putting a hard-coded directory. Lastly, it will then go into the new directory that was created.

Lastly, the last bit of code:

mysqldump –user=USER_HERE –password=PASSWORD_HERE –databases DATABASE_NAME > DATABASE_NAME.sql

mysqldump is a program that comes with the MySQL server that will allow you to dump the contents of a database into a file. This way, if you ever need to restore a database, it is just a matter of dropping all the information in the database and then importing it from this file.

For –user=USER_HERE, you need to put your MySQL username in here. Most likely if you are the owner of the system, you will have to use –user=root because the root user has full access to all the databases on the server. Or, you may have another user that simply has read-only access to all of the databases, such as a backup user. In that case, use something like –user=backup. Again, this all depends upon what username you have.

For –password=PASSWORD_HERE, this is where you will put in the password of the user you just specified beforehand.

For –databases DATABASE_NAME, you will list one or more databases after this. So, you could have –databases database1 database2 and so on. However, I have created one mysqldump line per database that I have, and only listed that database after it – that way there is one SQL dump file per database – instead of all the databases being in one file.

Lastly, the > DATABASE_NAME.sql is the name of the file you wish to save it as. So, lets give a quick example of one if you are using user "backup" and password "testing" with database name of database1:

mysqldump –user=backup –password=testing –databases database1 > database1.sql

Now, if you have three databases, database1, database2, and database3 – and you want each of them in an individual file, there are then three of the above lines:

mysqldump –user=backup –password=testing –databases database1 > database1.sql
mysqldump –user=backup –password=testing –databases database2 > database2.sql
mysqldump –user=backup –password=testing –databases database3 > database3.sql

So, if you have 20 different databases and want each in an individual file, you will have 20 different lines where the name of the database and the name of the file saved to is different. If you don't mind having all of your databases backed up into one file, the following line will put all three databases (like above) into one file named database-backup.sql:

mysqldump –user=backup –password=testing –databases database1 database2 database3 > database-backup.sql