[SOLVED] Setting up an rsync server: advice needed
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You have to be root also on the remote system to be able to have correct file owners and groups in the copy.
I would create separate public key pairs for root. (Same keys would give "hazel" root access without password asked.) ssh does not use /etc/ssl.
I guess your AntiX and Slackware have user and group names corresponding to different numbers in /etc/passwd and /etc/group. Your rsync will probably need --numeric-ids.
You have to be root also on the remote system to be able to have correct file owners and groups in the copy.
OK. Good to know.
Quote:
I would create separate public key pairs for root. (Same keys would give "hazel" root access without password asked.)
Wow! Thanks for the warning!
Quote:
ssh does not use /etc/ssl.
So what are those keys actually for?
Quote:
I guess your AntiX and Slackware have user and group names corresponding to different numbers in /etc/passwd and /etc/group. Your rsync will probably need --numeric-ids.
My personal UIDs are the same on both. I always arrange it that way because I use a common data directory across systems. But I'm not sure about the various system user UIDs. I can do a quick comparison and report back.
Oops! I've just realised that if I do it on a mounted system, there are three sets of ownership that could be involved: the ones on the source, the ones on the local host system, and the ones on the remote system. I assume that the actual UIDs and GIDs in the inodes won't be modified during transfer, but the three systems might interpret them differently.
There are links to CA certificates in /etc/ssl/certs needed to authenticate SSL connections. You could use openssl to make SSL/TLS encrypted connections, e.g. https:
Code:
openssl s_client -connect google.com:443
Yes, openssh uses the the libcrypto.so library from openssl, too, but ssh uses its own keys.
So the next one to set up is definitely AntiX because that is also updated weekly and can be dumped weekly out of Slackware. I can use the same script basically, with just a few adjustments. I've already added the --numeric-ids option to the script (thank you, Petri!). Now I just need to create keys for root@bigboy and pass the public key over to littleboy.
Slackware gets updated only once a month, so I shall need a variant script with calculated month numbers rather than week numbers. Should be easy enough to arrange without further help. Once I've done the first root dump of AntiX, I'll let the community know how it went.
Finally got it. As well as using -d for the test, I also need to use ordinary local pathnames on the remote system (i.e. no duplication of "hazel@littleboy" there).
Now I think I am ready to proceed cautiously to Part 2 of the project: dumping my root partitions. I plan to do this while not logged in to the system in question (i.e. dump Slackware out of AntiX and vice versa). That way I won't have to make any special arrangements for excluding dynamic directories.
I understand that I have to be root on the local system (bigboy) because some files are only accessible to root. But can I just be me on the remote system? Or do I have to be root there too? Am I even allowed to be root when working remotely? I don't particularly want to post sshd_config files on a public forum but I can answer questions about what is in them.
And I need to know what ssl keys will be used because I'm rather confused about that. I made a pair of keys for myself at the outset and copied the public key over to littleboy, so that's what I've been using up to now. But do I have to make a different pair for root or can I just copy my personal .ssh directory over? What about the system keys in /etc/ssl? Would they be used automatically for a root ssh? Some pointers would be useful.
If you were using real backup software the permissions would be in the backup metadata and you would not need to be root. Since you are using a file/folder syncronization tool it needs enough authority to change ownerships and permissions, and the easy way is to give it superuser/root authority.
I have run into a problem trying to dump AntiX as root. It's probably some silly obvious thing but right now I feel as if I am .
I created keys for root@bigboy and I tried to copy the public key over to littleboy using ssh-copy-id. This is the method recommended in BLFS and it certainly worked for my personal key. But I can't get it to work for root.
Code:
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@littleboy
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@littleboy's password:
Permission denied, please try again.
And so round and round. Yet the password I am using works normally when I'm on littleboy and I su to root.
Before someone came up with that script (and before I DISCOVERED it) I copied the key over manually. This also gave me an opportunity to check the folder and files for existence and permissions. Have you considered using that procedure?
Is ssh root login enabled? i.e PermitRootLogin yes or PermitRootLogin without-password
Many distributions default to without-password now days but you can not login without having keys already configured.
You can change it to yes, copy the public key and then change it to without-password. Or you can transfer it via your regular user and then use sudo or su to copy the key to root's authorized_keys file.
I copied it by hand. The dump is running! Thanks, everyone.
[Edit] Finished ca.18:00. Approximate time 1 hr 40 min.
Now, one more question: can I copy /root/.ssh on Slackware to /root on AntiX so that I can use the same key, which littleboy already recognises, to do my monthly Slackware dump?
Now, one more question: can I copy /root/.ssh on Slackware to /root on AntiX so that I can use the same key, which littleboy already recognises, to do my monthly Slackware dump?
I have had that work. IT has been a LONG time, but it used to work.
DDG found this. It isn't quite the same thing as it deals with using the same key pair on two different machines. But since that is apparently OK, two distros on the same machine should be OK.
Actually it should be safer, because with two machines, there's always the risk of one of them being stolen and then the keys on the other machine would be compromised.
First Slackware dump done today and it took 1 hr 46 minutes, just a little bit longer than the AntiX one. Which is a bit odd actually because I just did a du of the dump directories and the Slackware one is much bigger (11 GB compared with 6.3). Of course I expect the later differential dumps to be much faster.
@wpeckham: Copying the keys between the two root home directories did indeed work.
I'm really delighted with the way this all worked out. Thank you again everybody for all the help you gave.
Is the target drive encrypted? I find that slows things way down. Depending on the brand/model of drive, encryption can slow it down by a factor of 10 or so.
This thread has encouraged some experimentation with these methods. On one project, I've moved to a rolling differential backup using Rsync and a --link-dest target based on the previous day. That one takes only a few minutes each time. I save some time by doing SSH multiplexing for a bunch of connections in sequence rather than building up and tearing down whole SSH sessions. The start of the script establishes a master connection and the absolute last step (whether through normal execution or an abort) stops the master connection.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
. 
