understanding users - http, ssh, rsync

[toltmanns]

Hey everyone.

I'm running into an issue where I've got rsync doing it's thing through ssh authenticating as user2. I tested this all out in a small subdirectory with no issues - just had to chown the folder and contents to user2.

Now I am trying to backup the whole server but hitting an issue that I need help understanding and possibly a solution. The majority of the files in my public_html are set to user1 (really tied to the cpanel/ftp account). When I try to switch to user2 - the server goes down through http - 500 error. When I chown everything back to user1 it works as it did beforehand.

I need to change the owner of the files to user2 and have everything function as it should over http, is there a setting/config for this somewhere? Please advise.

Thanks!
Troy

[Irithori]

May I ask what the purpose of that backup is?

Do you intend to use it for a bare metal restore?
That wont work, because a rsync with the user2 will loose original uid/gid information.
Also, it wont have access to everything, logs for example.

Is it mainly to have a backup of the directory public_html?
Then it should be enough, that user2 is in a group, that has at least read access to this directoy.
But same as above applies: you will loose uid/gid information and possible also not have access to everything.


It seems tempting to just use root for the rsync, but this is a bad idea.
ssh offers an interactive shell, and by opening ssh root login for backup you also expose it for others.
Whoever has access to the backup script or backup machine automatically has root on your production machine.
Also, the root access is then only guarded by one token.
OT: A better approach would be to only allow key based ssh logins for regular users who then can potentially escalate to root via sudo.
The private keys of course have to have a passphrase.
This way, three tokens are needed for root access: private key, its passphrase and the users password.

But back to topic:
I would suggest to install a local backup solution.
You could rsync locally, make a tarball of the copy and scp that to a remote location.

This is a bit of a ducttape solution.
A more sophisticated approach is to use a backup suite like amanda or bacula, but this might be overkill in your situation.

Note: Make sure, you also dump and backup databases. A pure filecopy wont help here.

[toltmanns]

Irithori,

I tried adding user2 to the group that user1 belongs to, as a supplemental group, chowned all the public_html files to user2 but still get the 500 error.

While your ducttape solution may just work - I was really looking forward to taking advantage of the incremental changes that rsync implements. Not sure of how that would translate with your local backup solution.

The purpose of the backup is to have a repo on the owner's laptop/desktop that hold the server's backup. It's a rather large WP site with several contributors, so most of the file changes will be uploaded images.

I don't believe we need a bare metal restore at this point. Just files and db in case we need to restore or move to another location.

When you refer to root you mean "root" right? not the cpanel/ssh user? On my setup (Godaddy dedicated) they both have the same password.

I'm not 100% understanding ssh keys and why they would be needed in this case - doesn't the password protect the shell account?

I'll figure out a mysql backup solution when I get the file one in place, but thanks for looking out.

[um_nirvani]

you are not supposed to change the ownership of files in public_html. Apache will be configured to run scripts in public_html under the ownership of the actual user(user1). if there is a mismatch with httpd.conf and ownership, it will throw 500 internal server error on the webpage.

check out these two directives: group(mpm_common - Apache HTTP Server), user(mpm_common - Apache HTTP Server)

I guess creating a group with user1 and user2, changing the ownership of files to user1:group would work out for you.