Support

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.

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.

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.

You're welcome!