rename error and permissions

Uh oh.

Can you tell me what the configuration options are for the script?

I'm assuming that the target dir is "httpdocs"?

Thanks,

-- Doug

Hi Doug,

The configuration options are:

Backup Location - /var/www/vhosts/btmnetworks.com/subdomains/base/httpdocs/bk

bk is target directory, and is 777 for the time being to rule out permissions

Capture errors from backup run? TRUE
Backup from parent directory? FALSE

-John

Okay, can you please check permissions on the "httpdocs" directory?

Thanks,

-- Doug

Hi Doug,

The httpdocs is the root of the site and is currently is at 750. The httpdocs/bk directory is currently 777.

Thanks,

John

Okay, here's what I think is happening: the user that the webserver is running as does not have permissions to write to the httpdocs directory. A couple of ways to test my theory:

1) Change permissions to 770 and try again

2) If that doesn't work, try permissions 777 and see what happens.

Thanks,

-- Doug

Hi Doug,

You were right, 770 did it, it was grouping. Sorry about the ghost chase!

Though, I now get the following error:

backup_files(): Command 'tar cfz /tmp/backup-htdocs-fjjnJC MAINTAINERS.txt bk xmlrpc.php profiles update.php index.html favicon.ico modules themes css INSTALL.txt LICENSE.txt install.php scripts sites test index.php .htaccess misc CHANGELOG.txt INSTALL.mysql.txt includes cron.php robots.txt INSTALL.pgsql.txt UPGRADE.txt img files drupal-backup-db-20070613184543-120056719.sql.gz 2&>1' returned value: 2

Any ideas? I saw this error earlier and updated the module to today's release. This error stopped showing after updating, though of course I was seeing the previous errors. Now that they are solved, this is showing...

Thanks,

John

Cool! I'll make some changes to the code at some point to catch this sort of scenario instead of throwing an error.

As for the current return value of 2, try unchecking the box that says "capture errors". (It's supposed to capture errors, but sometimes *causes* error 2. I have no idea why!)

-- Doug

Almost!

It ran this time and completed, though the URL generation is off a bit...

Instead of http://www.something.com/path/backuphere.tar.gz

It is using the absolute path from root in the link showing:

http://var/www/vhosts/oursite.com/subdomains/base/httpdocs/bk/drupal-bac...

Any ideas?

Thanks!

-john

> It is using the absolute path from root in the link showing:

Yes, it means I screwed something up! I'm going to start working on a patch right now.

In the meantime, you should be able to still download the backups via FTP or SCP.

-- Doug

Hi Doug,

Thanks so much for the quick responses, you rock.
If you need any testing, i'd be happy help.

Thanks,

-John

Okay, I have good news and bad news.

The good news is that I wrote some code to handle the issues that you found early in this bug. Backup will now react a little better and give useful information if anyone else encounters them.

The bad news is that Drupal's CVS tagging system is just plain awful, and it forced me to create a new version of the software, which will not be packaged for about 10 hours. When it is packaged, look for version 5.x-4.x.

Also, I was unable to reproduce the last problem, where you cited issues with the links. What I'd like to ask if for you to go into the help section from the module page, click on the "phpinfo" link, and send the contents of the resulting page off to me. If there are any security concerns, feel free to email it to me.

Thanks,

-- Doug

I've just installed backup and have created a backups directory in the drupal root, however backups failed until I chmodded the drupal root to 777, which just seems insecure to me. I then investigated further, and found that while the backup was being created it added the database dump file in to the drupal root. The backup module however does use the /tmp directory - would it not be possible to do the database dump to /tmp instead of the drupal root? I'm going to stick with svn for file/module backups and a shell database backup script for now, but this may well change as I move away from my home server into a production environment.

My 2c.
kehan

See comment #5 above.

I believe that it is, in general, a very bad idea to grant the webserver write access to the files in htdocs. This opens up a huge number of exploits.