I'm trying to set up rsync to be able to have my ReadyNAS pull and push backups.

On my Mac, this meant starting up rsync as a daemon and editing a configuration file. That much is done but I'm still having issues with the ReadyNAS for which I've posted to their forum.

However, I'm trying to local tests with my Mac and I'm not having any success here either.

I can easily rsync out to my dreamhost web server from the command line, however using the same arguments I am always refused the connection to my local machine when prompted for password.

Example: rsync -avz /Volumes/Play/test userid@192.168.1.197:~/testrs/

The IP address is the machine I'm using the terminal session on, the same machine running the rsync daemon. userid is my userid of course. I get prompted for password but it won't accept it. It exits out after 3 attempts.

Anyone know what's going on?

The issue I'm having with the ReadyNAS is that it can connect to my Mac, but only if I set the path as "/" - anything else in its Frontview UI and it only gives an "invalid path" error. With that same UI I can't connect to my dreamhost web server at all.


Fixed the connection to Mac issue on the ReadyNAS. Needed to specify the name of the "module" set up in my rsyncd.conf at the beginning of the path in the ReadyNAS UI.

The other ReadyNAS issue is that it doesn't support rsync over SSH. They disabled that feature to distinguish my POS version from the "Business" version. Both products are the "ReadyNAS Pro" - I still don't know why this feature would be missing from a professional product. They should really have just named it ReadyNAS NVX6 or ReadyNAS POS or something equally lame. Looks like I might not ever be able to make the NAS connect to Dreamhost since I think it requires SSH.

Doesn't it run Linux? Can't you hack it to enable rsync via ssh? I don't know what the architecture is like, but doing something like moving the rsync binary to rsync.bin and then making rsync be a script that sets the ssh option and then calls rsync.bin.

It does run Linux, but I also don't know how its UI passes in its parameters to rsync to be able to make such a script.

I'm hoping someone will make an add-on that enables the SSH option in the UI. That way you can selectively use it, and I won't have any manually made changes to the disk structure zapped when I perform the next update. Someone on their forum is a very prolific add-on maker and has already made the very same thing for the ReadyNAS Duo. Should be a piece of cake for them to make one for the Pro.

But that's very easy to find out, with an approach similar to what Bitt suggested.

Just rename the existing rsync binary to something like rsync.bin, and create a shell script called rsync in it's place, like this:

Code:

#!/bin/sh
EXTRA='xxxxx'   ## add whatever you need here
logger -- "$0 $*"   ## echo original command/args to syslog
exec /usr/bin/rsync.bin $EXTRA "$@"

And don't forget to do: chmod 0755 rsync

That will run rsync with the original args, plus any new ones you add in EXTRA.
Easy enough to try, and fully reversible.

EDIT: perhaps Bitt can help further, with the exact syntax for the rsync ssh options you might need. I'm not an rsync user myself, so I don't really know about those.

EDIT: Something like this, perhaps: EXTRA='-e ssh'


Cheers

Ok, here's the output created by the backup process captured as Mark suggested above (cool):




I'm going to check what some of those options mean. For this to work in multiple cases I'd have to do more than pass the existing args and add some extras. Maybe by checking for some passed info and then having a condition which changes the call to rsync based on that.

I know I'll have to replace the "::" after the DEST domain with a single colon for instance. Since "::" means that you're using a module name defined in rsyncd.conf which isn't in place at Dreamhost.

I have tested ssh out from the ReadyNAS shell to Dreamhost and that's working. Now I need to generate a public key on the NAS to send up to Dreamhost to allow ssh and rsync without specifying a password.

I'll definitely need help with the conditional logic and breaking apart the args in the shell script.

At this point I know what the args do, but I still don't know why there's a period between the SRC and DEST.

Ok, I've uploaded my NAS' public key to Dreamhost and have inserted it into my authorized keys list. I can now ssh from the NAS to Dreamhost without entering a password. Sweet.

Are you sure SSH access isn't already on? With version 4 of the firmware for my NV+, it was just automatically on, and it used the web admin password as the root password. Rsync over SSH works either direction as well, with no setup or changes.

*edit* never mind, I'm getting it backwards. 3 had SSH on by default for support reasons, but someone figured out the algorithm they used to generate root passwords. So it's off by default, but is toggled on by using the Netgear provided addon. I applied that shortly after updating to 4.0.

I haven't poked at the rsync options in the WebUI, but I did find someone saying that you can enable rsync over SSH in the GUI by editing /etc/default/services, and add a "RSYNC_OVER_SSH=1" to it.

Ouh! Thanks Tom, I'm about to look at that.

SSH can be toggled on as you suggested. That was by adding an add-on which runs once. You also need to enable ROOT_SSH to be able to actually connect to it with a terminal - no other user accounts can be used to log in without further changes (which require root connection).

So, while SSH is enabled and rysnc is enabled, there's normally no UI bits in the web interface to tell the backup process to use SSH (and a direct to shell connection) instead of name/password and a connection using a module via definition in the remote rsyncd.conf

Ok, I believe this will work, however it's essentially a way to achieve what the external script would do with hard-coded parameters. It means all rsync operations would be over SSH since this change doesn't bring up the toggle button in the UI for SSH nor the link to create a new public key.

I think I'll have to keep looking at making the script for now as I'd like to avoid using SSH for my internal (LAN) backup of my photos.

I started poking around in the webUI source files on the disk to find where the various bits get enabled/disabled and discovered that two variables determine the ssh options for rsync. One variable declares if this NAS is a "home" or "business" product and the other declares whether ryncoverssh is ON or OFF. The product must not be "home" ad must contain TRUE for the other variables for these options to appear in the UI.

I then tried to find out where the values for these variables came from, but was unsuccessful - they probably come from a perl file that's been compressed making them difficult to search.

So the next best thing was to search Google which led me to this:



So, just mark the product with some mode other than "home" and set rsyncshh to true at the top of each UI html file. Simple enough.

The newer versions of the files use "NN" instead of "NasState" - and so far the options appear in the UI. Now to see if the logic in the UI is enough to get the underlying code to actually work properly.

Cool, the connection test is working. For Dreamhost, using this UI, you have to supply the path to your directories as "home/userid/sub-dir" where userid is your account ID at Dreamhost. The "~" shortcut often used at the command prompt won't work in the web UI because it's hardcoded to start at the root "/" and append whatever you type into the path.

I finished testing and am now in the process of uploading to my web account. Unless my math is off, at a sustained transfer speed of about 60KB/s, it's going to take me over 20 days of continuous uploading to get my photos up there. It will also tear through 83% of my entire month's bandwidth allocation.

I may have to spread it over two billing periods.

Dude, you *really* need to get off of Dreamohst. As a recovering Dreamhoster myself, it pains me to see your struggles.

From your later posts, I'm guessing that you might not be hacking this script after all. But to answer your question, that "stray" period is actually the tail end of the first path pictures/DPhotos/. -- it means "current directory". And yes, it's totally redundant there.

Cheers

I really do need to go to a different host. But in this instance all my pains have been due to Netgear.

Dreamhost pains were email being up and down for the better part of 3 days a couple of months ago. My site being down for an entire weekend due to an unannounced server move, also a couple of months ago. Recently having the site down for the whole afternoon which just repeated itself again this past week.

The problem is that I haven't found another host where I can be at least somewhat certain to receive much better service, even at up to twice the price. Media Temple sounded nice, but then I saw so many bad reviews that it scared me off.

I don't think I can seriously think about moving at least until February at the earliest. Just too busy around here with other things right now. It would be a little work to make sure the environment is set up to work properly with the various PHP pages on my site, including the cart and license generation code.

Mark... Right, I don't know why it didn't click that period was the current path. Duh. I feel like a total shell newb now. Can you tell I've only been using a unix-like command-line shell for just over 20 years?