A shared hosting server I use suffered a break-in which defaced many sites. As a result the admin made some modifications in settings in the aid of upgrading security on the server. Among these he activated open_basedir in PHP. This caused some problems with Akeeba and can possibly affect many other components. Following are my observations, my understandings (not necessarily accurate) and the workarounds I implemented.
The first indication I noticed was the failure of a Command Line BU of Akeeba run from Cron. The error was detailed in the email that Cron sends and part of it follows:
I checked the PHP settings shown in Joomla! Help->System Info and found that the open_basedir value was
My first workaround was to stop using the Command Line Backup option and instead set Cron to run Front End Backkups using curl. At the same time I bounced the open_base dir issue off the hosting support team but did not get very far. They do not allow users to set their own php.ini files but they do have a user specific php.ini files. The existence and location of this user specific file can be found again in Joomla! help->system info->php information as shown:
OK - my understanding is that in the case of my particular hosting, when php is run via appache the two php.ini configuration files that are parsed are the general server one in /usr/local/etc... and a specific file for my hosting. The open-base dir value
As far as the Command Line Back Up - It appears that when the php processor is run from the command line it is not using my user specific .ini file. I tried pointing the Cron run to the user specific file by using the -c option in the command line and the backup ran with no ERRORS. The command was:
However the Cron report showed a few WARNINGS. These follow:
There were several of these warning as well as one for CURLPROTO_FILE. The backup completed included post processing (to RackCloud).
I tried one more workaround. This time I used the -n option on the php run which ignores all php.ini configuration files
The result was a perfect backup run - no errors and no warnings. In effect I had cancelled the open_basedir restrictions (default setting is off). This doesn't say much for server security but it worked. Alternately it is possible to create your own php.ini file inside the hosting area and point to it with the -c option.
I hope that this helps someone with open_basedir blues.
The first indication I noticed was the failure of a Command Line BU of Akeeba run from Cron. The error was detailed in the email that Cron sends and part of it follows:
Warning: include_once(): open_basedir restriction in effect. File(/home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/version.php) is not within the allowed path(s): (/var/www/html/:/tmp/) in /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/backup.php on line 41
I checked the PHP settings shown in Joomla! Help->System Info and found that the open_basedir value was
/home/myUser/:/tmp/:/var/www/html/which included the base of my hosting package whereas the open-basedir setting shown in the Cron error,
/var/www/html/:/tmp/, did not!
My first workaround was to stop using the Command Line Backup option and instead set Cron to run Front End Backkups using curl. At the same time I bounced the open_base dir issue off the hosting support team but did not get very far. They do not allow users to set their own php.ini files but they do have a user specific php.ini files. The existence and location of this user specific file can be found again in Joomla! help->system info->php information as shown:
Loaded Configuration File /usr/local/etc/php5/cgi/php.ini Scan this dir for additional .ini files /usr/local/directadmin/data/users/myUser/php/ additional .ini files parsed /usr/local/directadmin/data/users/myUser/php/php.ini
OK - my understanding is that in the case of my particular hosting, when php is run via appache the two php.ini configuration files that are parsed are the general server one in /usr/local/etc... and a specific file for my hosting. The open-base dir value
/home/myUser/:/tmp/:/var/www/html/is a result of both files being parsed.
As far as the Command Line Back Up - It appears that when the php processor is run from the command line it is not using my user specific .ini file. I tried pointing the Cron run to the user specific file by using the -c option in the command line and the backup ran with no ERRORS. The command was:
/usr/local/bin/php -c /usr/local/directadmin/data/users/myUser/php/php.ini /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/backup.php -profile 1 -description "db-only"
However the Cron report showed a few WARNINGS. These follow:
Warning: curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /home/myUser/domains/myDomain/public_html/administrator/components/com_akeeba/akeeba/plugins/utils/cloudfiles.php on line 213
There were several of these warning as well as one for CURLPROTO_FILE. The backup completed included post processing (to RackCloud).
I tried one more workaround. This time I used the -n option on the php run which ignores all php.ini configuration files
/usr/local/bin/php -n /home/myUser/domains/myDomain.org/public_html/administrator/components/com_akeeba/backup.php -profile 1 -description "db-only"
The result was a perfect backup run - no errors and no warnings. In effect I had cancelled the open_basedir restrictions (default setting is off). This doesn't say much for server security but it worked. Alternately it is possible to create your own php.ini file inside the hosting area and point to it with the -c option.
I hope that this helps someone with open_basedir blues.
