Akeeba Backup for Joomla!

Wednesday, 07 January 2015 12:35 CST

mhilliard

Hi, I've been backing up my sites manually using Akeeba for several years and am just now setting up CRON to do this automatically. CRON seems to be firing normally and I can tell from the confirmation message that Akeeba is being triggered, but I keep getting thrown an error:

X-Powered-By: PHP/5.4.22
Content-type: text/html

Akeeba Backup CLI 4.1.0 (2014-12-27)
Copyright (C) 2010-2015 Nicholas K. Dionysopoulos
-------------------------------------------------------------------------------
Akeeba Backup is Free Software, distributed under the terms of the GNU General
Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the
license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------
You are using PHP 5.4.22 (cgi-fcgi)

Starting a new backup with the following parameters:
Profile ID  1
Description "Command-line backup"

Current memory usage: 1.32 Mb

Unsetting time limit restrictions.

Site paths determined by this script:
JPATH_BASE : /home/sitename/public_html/futurist
JPATH_ADMINISTRATOR : /home/sitename/public_html/futurist/administrator

Error displaying the error page: Application Instantiation Error: Could not connect to MySQL

That last line about not connecting to MySQL has me puzzled... Everything should be in order since it's the same settings as the manual backups. I suspect it might have to do with the complex passwords we use including punctuation and symbols like: * ] ~ . $).

Is there a way to escape characters for the MySQL password in the CRON script or somewhere else in the Akeeba Backup settings? My current CRON job command looks like this:

0 0 1,15 *  *  /usr/bin/php /home/sitename/public_html/futurist/cli/akeeba-backup.php

Thanks for any guidance you can provide.

Wednesday, 07 January 2015 15:10 CST

dlb

Non-alphanumeric MySQL passwords have been a problem in the past, but I haven't seen one that wouldn't work in quite a long time. You can test that theory by creating a new database user with an alphanumeric password (a-z, A-Z, 0-9) and enter the modified information in the Site Override section of the Akeeba Backup profile. That is a little more trouble but it doesn't affect your live site.

You are calling the cgi-fcgi version of PHP, you should be using the cli version. You can contact your host to find out the path to PHP-CLI. I don't think that is the problem at this point, it is something that may be a problem later.

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Wednesday, 07 January 2015 17:30 CST

mhilliard

Thanks Dale.

That got me to look at this from a different angle and I realized what was preventing the MySQL connection was having moved our configuration.php file to a directory above the site root. We use RSFirewall for site hardening against hacking and SQL inclusions, and part of their protocol is to move the config file and rewrite the two defines.php file to point to the new path.

Once I moved configuration.php back into the site root and restored the defines.php files it worked flawlessly. But now I’d like to adapt cli/akeeba-backup.php to use the updated defines.php files to find the configuration.php path, OR if necessary, be able to explicitly write the hard path to the configuration.php file in akeeba-backup.php. I’m unclear which lines to modify in the cli/akeeba-backup.php file but it looks like it’d be around lines 104-117. Does that sound right to you?

Many thanks for your help.

Wednesday, 07 January 2015 20:34 CST

dlb

That I can't help you with. I'll leave a note for Nicholas and Davide.

Dale L. Brackin
Support Specialist

English: native

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

Thursday, 08 January 2015 04:14 CST

nicholas

I have explained this a million times. Here it goes again.

You DO NOT gain ANYTHING AT ALL in terms of security by moving the configuration.php file anywhere outside your site's root. Remember that this file MUST be readable for Joomla! to work at all. As an attacker I have the following options to read it:

1. Read it directly through a vulnerable extension / script. If you move it outside your site's root you are NOT stopping me. I will first read includes/defines.php which tells me exactly where this file is stored, then read it in my very next try. You slowed me down by 20 seconds. I still have pwned your site.

2. If I can execute arbitrary code on your site I can launch attack #1. Again, I have pwned your site.

3. If I can execute arbitrary code INSIDE the Joomla! context I can simply var_dump(JFactory::getConfig()). I have pwned your site.

4. If I have Super User access to your site I can go to the Configuration page and read the values myself. I have pwned your site.

5. If I have FTP or other kind of file access to your site I can launch any of these 4 attacks. I have pwned your site.

As you understand now moving your configuration.php file outside the site's root is about as effective as putting a sign on your unlocked door reading "Please don't rob my house". At the same time it makes it impossible for us to reliably detect that file from the context of the restoration script which means that we'll never support it. Furthermore, if you forget to add a cli/defines.php file all CLI scripts –both core Joomla! and 3PD scripts like our CRON jobs– cannot run.

So, please let me know exactly why RS!Firewall suggests you doing that exercise in futility? Because they want to sell you a false sense of security. Because some person who didn't know better wrote that instruction in the Joomla! security wiki page even though I told them that it's an exercise in futility and I can still hack their site if it's vulnerable.

Therefore: DON'T DO IT. There's a good reason we don't support it AND you don't get any security benefit whatsoever.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support