Technical Resources for Technical People
Header

Openfiler rsync over SSH

July 13th, 2011 | Posted by techblog in Linux

Openfiler is a nice bit of software for a NAS box, but when it comes to setup and configuration you’re pretty much left on your own. There’s no good documentation (even the paid user manual is quite vague – it only describes the various checkboxes and fields and how to navigate the UI). The openfiler forums are littered with people asking the same questions you are… and getting no answers.

After hours of searching, wasting time reading the forums and messing around a bit ourselves, we’ve gotten rsync over ssh working on openfiler! (Yes, SSH is a requirement in order to secure the data transfer – we don’t want anyone sniffing the traffic and picking up anything in transit).

This article assumes you’ve successfully setup LDAP and have created a few users, groups, shares and network blocks that you’ll be using.

LDAP Users & Groups

On our Openfiler system we have various users and groups, not all of which are used in this how-to, but they are as follows:

example: (user-name.group-name)

  • user.local
  • backup.remote
  • external.untrusted

For this article we’ll be focusing in the user “backup” as part of the “remote” usergroup.

File Shares & Permissions

We’ve setup a share called “BACKUPS” which is located at /mnt/volume-group/volume/BACKUPS

The remote group is the primary group (PG) for this share and has read/write (RW) access. The local group is granted read only (RO) access, so that we are able to safely access the share on our internal to view or copy backup data.

Under the host access configuration, (Which we’ll assume you’ve setup “trusted” networks or the ip’s of your remote servers/machines that you wish to have connect to your openfiler box). We’ve set our “Remote-servers” network to have Read/Write access to rsync. (Ignore the rsync options for now unless you have specific needs or issues later)

rsync daemon

You may have trouble enabling the rsync service/daemon from the web gui, no problem – login to the openfiler server via ssh or physical terminal and start it manually.

# /etc/init.d/rsync start

You may or may not get any errors, should be fairly easy to read the error output and fix as necessary. Below is what our /etc/rsyncd.conf file looks like:

port = 873

motd file = /opt/openfiler/etc/rsync.motd

[ volume-group.volume.BACKUPS ]
path = /mnt/volume-group/volume/BACKUPS
comment = rsync-comment
hosts allow =  192.168.1.1/27 192.168.2.1/29
hosts readonly allow =
auth use pam = yes
read only = no
write only = no
use chroot = no
max connections = 0
list = yes

modifying LDAP user for SSH

In order to properly use our LDAP user “backup” over SSH, we’ll first need to give him a proper home directory (as it’s currently set to /dev/null).

Searching for the user gives us some information:

# ldapsearch -x uid=backup

Now in order to modify this user we’ll need to make an ldif file using your favourite editor (Keep in mind you’ll need to use the options you’ve set on your openfiler LDAP – Hint: accounts tab on openfiler shows the DN info).

Since we’ll want to also create an SSH key pair (as not to prompt for a password), we’ll first create the /home/backup directory with our root account under ssh and grant it the proper permissions; otherwise using /tmp is acceptable as a home directory if you’d prefer to be prompted for a password.

# nano backup.ldif
dn: uid=backup,ou=People,dc=openfiler,dc=nas
changetype: modify
replace: homeDirectory
homeDirectory: /home/backup
-
replace: loginShell
loginShell: /bin/bash

Enable SSH directory for LDAP user “backup”:

# ldapmodify -W -x -D 'cn=Manager,dc=openfiler,dc=nas' < ./backup.ldif
Enter LDAP Password: ************

modifying entry "uid=backup,ou=People,dc=openfiler,dc=nas"

Router/Firewall setup – Port forwarding

A common area for headaches is not having the proper ports opened or forwarded on your network. A good practice to get into is DENY all traffic and open the ports you know are needed for various services. (Which openfiler practices).

If you have a level 3 switch/router make sure you forward the proper ports to the destination NAS. (SSH is port 22, rsync is port 873).

Remote Client Configuration (files sent from here)

Now onto the good stuff – we’re done with our setup on the Openfiler box, time to transfer some files from a remote machine to the rsync server.

# rsync -avz -e ssh /home backup@rsync.mydomain.tld:/mnt/volume-group/volume/BACKUPS/myserver1

In the above command we’re telling rsync to use -a (archive mode) -v (increase verbosity) -z (compress file data) -e ssh (use the ssh protocol).

Currently this will prompt you for a password for the backup user. This is fine. We can add SSH keys to remove this prompt and add the command to cron shortly. For now we want to test that it’s working.

You can try running the rsync command without SSH on a few individual test files to make sure that rsync in itself is actually setup properly. Then troubleshoot why it won’t work over SSH. (That’s why we modified the LDAP to give the remote user “backup” the ability to have a home directory on SSH) Otherwise we get errors about /dev/null not being a directory.

There is a difference in using trailing slashes at the end of the directory. We’re backing up the entire /home directory to a directory called /myserver1 (without the trailing slash it creates the directory /home under /myserver1) So we get /myserver1/home. If you add a trailing slash to /myserver1/, the contents of home are written directly into /myserver1/*.

Creating an SSH key pair and cronjob

Creating an ssh key pair (linux to linux) is fairly easy and done by the following steps on the remote machine that will be sending data to the rsync server. If you require root privileges, create the keypair from the root account.

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx user@remote-machine
# ssh-copy-id -i ~/.ssh/id_rsa.pub backup@rsync.mydomain.tld
backup@rsync.mydomain.tld's password:
Now try logging into the machine, with "ssh 'backup@rsync.mydomain.tld'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Now when we ssh over to our Openfiler system, we’re no longer prompted for a password. (If you’re prompted for a password more than once, try creating a symbolic link on the openfiler box of .ssh/authorized_keys that links to .ssh/authorized_keys2)

Script executed by cron

In order to create the cron job, we’ll first need to create a simple script that has the rsync command.

# nano rsync.sh
rsync -avz -e ssh /home backup@rsync.mydomain.tld:/mnt/volume-group/volume/BACKUPS/myserver1
# chmod 777 rsync.sh

Save this script in a directory that cron will have access to and create a new cronjob under the user account which will be executing the script. (Since we’re backing up our entire /home directory we’re using the root account)

# crontab -e
0 */12 * * * /user-directory/rsync.sh

This cron runs every 12 hours and emails the output to the user to which it belongs.

If you’d like to suppress email output

0 */12 * * * /user-directory/rsync.sh > /dev/null 2>&1

Now you have a successful rsync over ssh setup which runs every 12 hours.

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

One Response

  • Victor says:

    Hi,

    There is no need to activate the rsync daemon if you use ssh! They are two different channel of communication toward the machine, then using ssh, you just need rsync to be available on the machine and it will be spawned by the rsync client!



Leave a Reply to Victor Cancel reply

Your email address will not be published. Required fields are marked *