slug@nks.net wrote:
> slug@nks.net wrote:
> > I use rsynch over ssh and specifty recursive and follow symlinks ...
>
> You sure about following symlinks?
> That can get one into trouble at times (e.g., recursive trees).
No, in fact that didn't over-ride the original permissions.
>
> James Marcinek wrote:
> > I like this approach. Simple and elegant
I liked the idea of creating the named pipes
>
> Also, I wanted to point out that just because you use "root" on the
> original system to backup, you don't necessarily have to use "root" on
> the target/destination system where the files are going. E.g., you can
> have a SSH client that runs as "root" on a system connect to the SSH
> server as a "non-root" user.
The user on the original system to backup is not root but another; why I'm
having the permissions problems. The system security is configured to not allow
root to ssh directly. One way I was considering circumventing this would be to
set the rsync executable to the root user so any user that has access to execute
it would run it as root. Obviously this would open security risks. I was
planning to setting the rsync executable access so that only the user (by group
acl) or root could run the command to lock it down...
>
> I typically don't like to exchange keys between "root" accounts on two
> systems. I typically have the attitude that I will always ssh in as a
> "regular" user, copying a public key to a non-root user's directory,
> even if the private key is stored under the root account of the client.
ditto
>
> Although this does make it tricky for rsync, because non-root users
> cannot change the permissions on files. That's why I build a "sister"
> script (using find -printf '') that does a "chown" (as well as a
> "chmod"). Sometimes just having a script that can re-apply permissions
> is just as good of a backup.
I'd be interested in any examples. But wouldn't this require that would require
the 'original backup server' to initiate this or would you have the ssh initiate
the script? I still run into the DHCP dilema...
Thanks,
James
>
>
> --
> Bryan J. Smith b.j.smith@ieee.org
> ------------------------------------------------------------------
> Beware of advocates who justify their preference not in terms of
> what they like about their "choice," but what they did not like
> about another option. Such advocacy is more hurtful than helpful.
>
>
> -----------------------------------------------------------------------
> This list is provided as an unmoderated internet service by Networked
> Knowledge Systems (NKS). Views and opinions expressed in messages
> posted are those of the author and do not necessarily reflect the
> official policy or position of NKS or any of its employees.
>
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:21:25 EDT