Jim Salter wrote:
yeah, except that the directory is not 700 but 600, so even user backup
cannot traverse it... but root can.
Have you considered using sudo such that the fileserver isn't actually
logging into the backupserver as root, but only logging in as a heavily
*un*privileged account
The rsync command tries to send sample_file to the backup server,
which cannot write it because it was not able to recurse into
my_directory.
Removing the -p switch and removing the backup file did not succeed,
and rsync continued to preserve the perms even without the switch. I am
running
Jim Salter wrote:
The rsync command tries to send sample_file to the backup server,
which cannot write it because it was not able to recurse into
my_directory.
Removing the -p switch and removing the backup file did not succeed,
and rsync continued to preserve the perms even without
yeah, except that the directory is not 700 but 600, so even user backup
cannot traverse it... but root can.
Ah, I see. Sounds like you're down to either running as root on both
ends, or ignoring errors.
Have you considered using sudo such that the fileserver isn't actually
logging into the
Ah, I see. Sounds like you're down to either running as root on both
ends, or ignoring errors.
Have you considered using sudo such that the fileserver isn't actually
logging into the backupserver as root, but only logging in as a
heavily *un*privileged account which can do nothing but run a
Or he could use SSH2 keys and an authorized_keys2 file,
Waxing pedantic, that really ought to be and/or. SSH2 keys are great as
an added layer of security to apply some paranoia as to *what* box is
calling the script, no matter what user account you're using to log in with.
allow root on
Hi,
I am currently setting up a backup script for the /home directory of a
server. I send all the files on a remote machine through LAN connection
using rsync to optimize bandwidth usage.
The script is run as root on the server by a cron job but rsync connects
to the remote machine as a
sure avoid all perm/user issues by making the whole server suid. seen
kids do that when they tired of having to su - root on their linux systems.
The alternative would be to enable ssh for root for those particular
cron jobs make sure the sshd_config is edited to disable this mischeif
after
On Mon, Dec 22, 2003 at 09:11:26PM +0100, Sayan wrote:
Hi,
I am currently setting up a backup script for the /home directory of a
server. I send all the files on a remote machine through LAN connection
using rsync to optimize bandwidth usage.
The script is run as root on the server by a
Ron DuFresne wrote:
sure avoid all perm/user issues by making the whole server suid. seen
kids do that when they tired of having to su - root on their linux systems.
this command is only one line extracted from a script. Syncing of other
files require root privileges one the server side, eg
On Mon, Dec 22, 2003 at 10:14:05PM +0100, Sayan wrote:
Ron DuFresne wrote:
sure avoid all perm/user issues by making the whole server suid. seen
kids do that when they tired of having to su - root on their linux systems.
this command is only one line extracted from a script. Syncing of
jw schultz wrote:
On Mon, Dec 22, 2003 at 09:11:26PM +0100, Sayan wrote:
I am currently setting up a backup script for the /home directory of a
server. I send all the files on a remote machine through LAN connection
using rsync to optimize bandwidth usage.
The script is run as root on the
12 matches
Mail list logo
