Support

Akeeba Backup for Joomla!

#9212 – Var/log path changed in config.php file

Posted in ‘Akeeba Backup for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Sunday, 04 December 2011 20:05 CST
user52412
Hi,
Joomla 1.5.25
Akeeba Backup 3.3.9 (at time of issue)
http://varuna.com.au/alumniweb/

On Friday 1 Dec 2011, the config.php file settings, on a joomla website I am administering had been altered.
Specifically the var $log_path had changed from:
var $log_path = 'var/logs'; to ...
var $log_path = '/home/content/v/a/r/varuna141/html/alumniweb/var/logs';
So, the website could not be accessed and the admin area could not be accessed.

I am sure someone has changed this manually, however there is a claim being made that: (quote)..."There have been instances where Akeeba backup has changed the path of the log file." And ..."It is possible that the Akeeba backup has thrown a code conflict and this could be because of a conflict between Akeeba and the version of Joomla on the Alumni website. If you run the backup again, it might fall over again."

Those statements are being made by a so-called Joomla 'expert'.

Could you confirm if Akeeba Backup can change the config.php file in such a way due to such a 'conflict'?

Monday, 05 December 2011 01:47 CST
nicholas
Akeeba Backup Installer always proposes a new tmp and log directory when restoring a site, if and only if the ones you had in your configuration.php file can not be written to. This is written in the documentation that your "expert" didn't bother reading.

Moreover, your "expert" has no idea whatsoever about Linux and shared hosts, which makes him anything but an "expert". The kind of path you are seeing in your logs directory is almost normal. The "/home/content/v/a/r/varuna141/html/alumniweb/" part is the path to your site's root. What doesn't fit the picture, is that it ends with "var/logs" which points to a most likely inexistent directory. I guess that you followed some misleading information off the Internet which instructed you to change your logs directory to "/var/log" (with leading slash) and you mistakenly typed "var/log" (without leading slash) creating that problem in the first place. Not that using /var/log is a good idea. No! It means that everyone on that server can easily hack you.

So, your "expert" double failed because:
1. He did not understand the nature of the problem. The problem is not that the log path is an absolute directory (actually, it should be), but that it is most likely unwritable. You can change its permissions to 0777 and upload a .htaccess file inside it, with the following lines:
order deny, allow
deny from all
for security reasons.
2. Not only he doesn't know how the restoration works, he never bothered reading the fine manual. So he decided to assume things and put the blame to Akeeba Backup, when the problem was actually a simple mistake when restoring the backup.

So much for an expert.


Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



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



Monday, 05 December 2011 02:33 CST
user52412
Thanks Nicholas.

Actually we were not using Akeeba for Backup or Restore.
Someone (call it a 'hacker') changed the config.php file.
I found the change and corrected it, put the full website root path to the log folder.

When I ran this past the organisation's CEO, the reply was a statement that ..."Akeeba backup has thrown a code conflict..."

So I am asking you is that possible, that Akeeba would actually create a 'false' or 'fake' var/log path setting in the config.php file, from a normal Backup procedure?


Monday, 05 December 2011 04:09 CST
nicholas
Hm, I just got an email which gives me a completely different picture of what was said. It appears that you were told that, maybe, the problem was caused by installing Akeeba Backup because we stopped supporting Joomla! 1.6. However, that was said in the context of possible causes for this error, not as the definite and conclusive source of the problem. I think that you made a leap of logic by assuming that what was said is that Akeeba Backup caused the problem. In fact, all the other explanations given to you as most likely to have caused the issue are, indeed, most likely to have caused the issue!

The short answer to your question is no, Akeeba Backup can not cause that change spontaneously, because the code in Akeeba Backup (the component) can not change the configuration.php file of your site. The only piece of code which can change your configuration.php file is in the restoration script. We have stopped supporting Joomla! 1.6 because our back-end backup notification module could be made to work in either Joomla! 1.6 or Joomla! 1.7, but not both. Since 1.6 is end-of-life since August, I chose to drop support for Joomla! 1.6. That said, the component won't, OF COURSE, deliberately destroy your site by doing an unnecessary change in your site's configuration.php file!!! That would be absurd.

If you have not used the restoration script –and you are certain, beyond any reasonable doubt, that nobody else did– then you have the following possible explanations:

- Someone who has administrator access on your site changed it manually form the Global Configuration page
- Someone with FTP access edited the configuration.php file
- You were hacked

Out of the three, I consider the last one the least likely. A hacker would never change the log path and leave everything unchanged. Most likely it's one of the first two, with my money put on the first case. Most likely someone with administrator access did the change because of something stupid he read on the Internet, hit the Save button, everything went to hell and he decided to lay low and deny all responsibility. Maybe this is what you want to check first.



Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



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



Monday, 05 December 2011 04:45 CST
user52412
Thanks Nicholas,
I am also sure it was someone using my super admin access to change the config.php file, however I cannot prove it!
Monday, 05 December 2011 04:49 CST
nicholas
I would take a look at the file's modification date, then download Apache's log files for that day. If you search the logs for administrator URLs you will see the IP address of the person who had logged in. At the very least, you will get a country of origin and see which pages he visited, which will give you a good clue about what happened.


Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



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



Monday, 05 December 2011 04:57 CST
user52412
Ok, thanks Nicholas, will do some detective work!
Monday, 05 December 2011 05:27 CST
nicholas
You're welcome!


Nicholas K. Dionysopoulos

Lead Developer and Director



πŸ‡¬πŸ‡·Greek: native

πŸ‡¬πŸ‡§English: excellent

πŸ‡«πŸ‡·French: basic



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



This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!