![]() It also adds a little extra useful security through the separation - if you make sure that the live and backup servers do not share any credentials then if someone manages to hack into (or just obtain/guess a password for) a privileged account on either the live or the backup servers they can't then use access to one to easily gain access to the other. For one thing, as root you can edit files your computer uses to start up the operating system or load your graphical environment, effectively breaking your computer. First, on the remote server add the rsync user to the sudoers file, so that he can execute rsync with no password. This adds a little complication, but means you do not need to enable logins to privileged accounts via SSH at either end. And the staging server does not need any access to make connections to either live or backup machines. The (possible) reason this was downvoted may be that the PostgreSQL database usually is run as the postgres or postgresql (or similar) user, not as an actual human user. ![]() ![]() My solution to not opening servers to root access when needed for rsync to operate and maintain all ownerships/privs is to both push from the live server(s) and pull to the backups, using an intermediate staging area on an extra machine.ĭone this way, both the backup and live servers have SSH access and root privileges on the staging area, but never need to communicate at all directly so do not need privileged access to each other. Edit the sudoers file (as root) and insert one line to allow the rsync command to run as sudo. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |