FreeNAS Replication with a Dedicated User

I ran across an interesting situation recently. A friend of mine wanted to start up an off site replication service for his small business customers. He has already deployed FreeNAS to a number of these customers, and the next logical step is for them to have their data off site. Wonderful! One of the requirements was that a dedicated user for each customer should be used for replication. The FreeNAS documentation for this is lacking.

This information is for FreeNAS 9.3, btw.

Why a Dedicated User?

So the first question you might ask is, "Why should we use a dedicated user," and the second question would be, "Why should we use a dedicated user for each client?"

Why a dedicated user? Security. Root is a known account on basically every *nix box. We're not going to allow ssh into a centralized repository as root with password, and we're not going to allow it via key based authentication where authorized keys are scattered across multiple client sites. 

Why a dedicated user for each client? Security. Always security. Let's say that one of the accounts is compromised and someone starts jacking with the data. The damage is limited to the data that the one account has access to. Is that bad? Yes, it is. Would it be far worse to have the data of 8 or 9 clients messed with at the same time? Yes, it would be.

So, dedicated users. Use 'em. After this document, you won't have any excuse not to.

Source FreeNAS Configuration

The Dedicated User

Let's start the configuration of the source FreeNAS server by creating our dedicated user.

Go to the Account menu, and then to the Users submenu and click on Add User

In the screenshot above, I have given a descriptive name for the Username, provided an entry for Full Name, E-mail, and password. I've also disabled password login. Other than that, I've left everything at default.

That's it. Thre is nothing special that this user needs. It just needs to exist. Those of you who are familiar with SSH keys may be tempted at this point to SSH into the system and start generating keys for this user. Don't do it. I will explain later, for now just resist the temptation.

The Snapshot Task

I'm going to gloss over a lot of the detail in creating a snapshot task. But in order to fire up replication, you must have an enabled snapshot task of the dataset you wish to replicate. Go to the Storage menu, and then the Periodic Snapshot Tasks submenu. Click on Add Periodic Snapshot, and you will be presented with a window that looks like the following screenshot.

This is a screenshot from my own personal FreeNAS box. CheetahZFS is where I keep all of my virtual machine virtual disks. Go ahead and modify the entries as your needs dictate.

The Replication Task

Now let's setup the replication task by going to the Storage menu, and the Replication Tasks submenu. Click Add Replication Task.

Once again, I've glossed over a lot of the options. For the case of using a dedicated user, the important pieces here are that you check the Dedicated User Enabled checkbox, and that you provide the user that we created a couple of steps ago.

Other than that, setup your replication task as your needs dictate. One thing to note is that if you have this task enabled, and have reporting properly enabled, you will receive a replication failure notice every minute until you get the receiving server setup. Just a little something to keep in mind.

One Last Thing

Before we leave the source FreeNAS server, in Storage -> Replication Tasks there is a button labeled View Public Key. Click that. This is the public key that FreeNAS will present when performing replication tasks. No amount of key generation at the command line will save you. This is the public key that must be put in place on the receiving FreeNAS server, so make sure to grab it and bring it with you when you configure the receiving FreeNAS server.

Receiving FreeNAS Configuration

Okay, in the Source FreeNAS Configuration section, I did a lot of glossing over. This is because the tasks are very well documented already. However, now we're getting into the undocumented territory. Brace yourself for some reading.

Preparation for the Dedicated User

The Dedicated User on the receiving server will need a writeable home directory. You might consider just creating a dataset for home directories that has a quota of like 100MB or something insignificant like that. The user won't need much space, but it will need enough to make an authorized_keys file.

Return of the Dedicated User

We need to create the same user on the receiving side that we created on the sending side, with a few modifications.

There are two important differences here. First, I've specified a home directory. Second, there is data in the SSH Public Key field! Remember grabbing the public key from the Source FreeNAS server? This field is where that information goes. So paste the Source FreeNAS public key into the Receiving FreeNAS dedicated user's SSH Public Key field.

One important bit that is not pictured here. This user is not a member of any additional groups. FreeNAS will make it a member of the staff group, IIRC. But specifically it does not need to be a member of the wheel group. And if you're doing this for security, it should not be a member of the wheel group. It should also not be allowed to use sudo. There is no reason to give it such permissions.

Create the Receiving Dataset

Next let's head over to the Storage menu, and under the Volumes submenu we will create our receiving dataset.

Select the dataset under which you would like to receive the replicated dataset and click the Create Dataset button at the bottom of the page. In my case I am just selecting the base dataset, FreeNASTestAntec. Make sure to create the dataset with the same name as on the Sending FreeNAS server. In my case I am creating CheetahZFS.

Enable SSH

SSH must be enabled on the receiving side for replication to work. I am going to gloss over this portion, as it is very well documented, and we could discuss endlessly about various security concerns.

Delegate ZFS Permissions

For this piece you will need to SSH into the receiving FreeNAS server. I am assuming that you are SSH'ing in as a specific user, and using sudo.

sudo zfs allow DescriptiveName create,destroy,diff,mount,readonly,receive,release,send,userprop FreeNASTestAntec/CheetahZFS

I'm not 100% sure that all of those permissions need be delegated. I will do some more testing and update this post.

But that is it. We have delegated the necessary ZFS permissions to our dedicated user on the receiving FreeNAS server.

FreeNAS System Tunables

Finally, we need to tell the receiving FreeNAS server that a regular user can take advantage of their newly delegated permissions. In the System menu, go to the Tunables submenu and click the Add Tunable button.

In the screenshot above, I have the tunable created already, but I have clicked the edit button so you can see how this is setup. The variable is vfs.usermount, the value is 1, the type is sysctl, you can put whatever you like in the comment, and make sure it's enabled. This does not require a reboot.

That's it.

Enable the replication task on your Sending FreeNAS server, and away it will go.