Backup and restore

• Save a copy of your currently installed "lib/moodlelib.php" file (to be able to go back to the original).
  
• Edit the original and make this changes:
  • Look for the zip_files() function.
    
  • Near de end of it (just before the start of the unzip_files() function) you will see this lines:
    

            //All converted to backslashes in WIN
    
            if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
    
                $command = str_replace('/','',$command);
    
            }
    
            

  • Replace the last one (the Exec one) by these lines:
    

            echo '<pre>'.$command.'</pre>';
    
            $lastline = Exec($command,$output,$status);
    
            echo '<pre>'.$lastline.'</pre>';
    
            print_object($output);
    
            echo '<pre>'.$status.'</pre>';

  • Run the backup and you will see a lot of info near the end of the process.
    
  • Does such output throw any idea about your problem?
    
  
  
  Ciao

It took me some weeks to track it down. Here my results:

1) On one system safe_mode is OFF and everything works fine, no matter whether using external utilities with /usr/bin/zip and /usr/bin/unzip or leaving those paths empty and thus using internal pclzip.lib.php functions

2) On the other system the responsible admin turned safe_mode=On in php.ini

After some tests I discovered that the slash in the previous post comes from the safe_mode_exec_dir setting when safe_mode is turned on. If I put a correct path in there, as should be, eg. safe_mode_exec_dir=/webserver/safe_mode_exec_dir, then the whole path is set before the cd command which is executed by the zip_files() function in our moodlelib.php, resulting in something like that:

/webserver/safe_mode_exec_dir/cd

which, again, does not exist. The admin had copied zip and unzip to that safe_mode_exec_dir path to allow the execution of those external utilities. But as I realised in my tests, the real problem is not COPYING the zip-file to its destination path, but the execution of the whole $command mentioned in the previous posts BECAUSE of safe_mode being on.

I think this explains, why the zip files are not there even if we succeed creating them manually as root or webserver users and why some run into this problem while others do not have it.

After that I dived into the problem of how to solve Moodle AND safe_mode. And the discussion is endless on php's side and on Moodle's side see the according forum:

http://moodle.org/mod/forum/discuss.php?d=1374#286772

If I find a viable solution to have safe_mode ON and do Moodle course backups, I will post it there.

We must differentiate also the case where Moodle is installed on a server where you have root access and where you DO NOT, eg. if you run Moodle on a provider's host.

In the first case, Moodle runs normally as the web-server-user, and apparently everything should work fine even with safe_mode turned on, which definitely is not the case, as we can see whith Moodle's course backups. Not because of the different UID/GID which are affected by the safe_mode but because the safe_mode_exec_dir alters the simple commands like cd. (Please correct me, if I am mistaken by my tests or this problem can be solved so that cd gets executed correctly in $command.)

On the other hand, on a provider's host, having safe_mode On, Moodle's php scripts run into problems much earlier because of the UID/GID being different when creating/copying/deleting directories and files.

I hope this explains why course backups are not possible with external utilities when safe_mode is On. Leaving the paths empty in that case, so that Moodle will use the built in pclzip.lib.php, will work correctly, if php was installed with zlib support.

Rosario