On 07 Oct 2014, at 05:36, Raymond Toy toy.raymond@gmail.com wrote:
"Mark" == Mark Evenson evenson.not.org@gmail.com writes:
Mark> On 10/5/14 16:58, Raymond Toy wrote:
On 10/5/14 2:18 AM, Mark Evenson wrote:
On 10/5/14 0:41, Raymond Toy wrote:
As the subject says, rsync appears to be down.
I've been using rsync to do periodic backups of ], so can we get rsync restored?
Hmmm. The 'rsync' binary is still present:
what do you mean by "rsync" is down? Did you use something other than "rsync through ssh connection"?
Sorry, I should have been clearer. I've had a cronjob for years that basically does:
rsync -av rsync://common-lisp.net/project/cmucl/cvsroot cmucl/cvsroot
When I run this now, I get this error:
Mark> Indeed rsyncd is not running as a service.
Mark> Any reason you don't simply change your usage to:
Mark> rsync -avz rtoy@common.lisp.net:/project/cmucl/cvsroot cmucl/cvsroot
Mark> using "rsync over ssh" instead of "rsyncd"?
Doesn't that require that I supply my password (or ssh credentials)? I don't know how to do that in a crontab script.
One would use the public key based authentication scheme. From the ssh(1) manual page:
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.
The user creates his/her key pair by running ssh-keygen(1). This stores the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), ~/.ssh/id_ecdsa (protocol 2 ECDSA), ~/.ssh/id_ed25519 (protocol 2 ED25519), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), ~/.ssh/id_ecdsa.pub (protocol 2 ECDSA), ~/.ssh/id_ed25519.pub (protocol 2 ED25519), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user's home directory. The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the pass- word. […]
To distill this:
1. create an ssh keypair for the user that willing be running the cron entry with ssh-keygen(1)
2. Copy the public part of the key (the file ending in ‘.pub’) into the ~/.ssh/authorized_keys of the common-lisp.net account. Ensure that the file has only user read and write permissions
Now you should be able to ssh to common-lisp.net as that user without needing to enter your password.
We (meaning mostly Erik with my prodding) spent a lot of time ensuring that the new host has reasonable backups. But it is always a good idea to have another copy, so I definitely want to support your ability to rsync locally.
-- "No, this is not a disentanglement, but a progressive /knotting-into/."