Scott O'Brien

Cifs Share

CIFS (Common Internet File System), the protocol windows users for all it’s ‘windows file sharing’ is the method I’ll allow for my desktops and roaming computers to access files on the file server.

Before we begin, Make sure we install the CIFS kernal modules

# pkg install SUNWsmbs # pkg install SUNWsmbskr

next we issue this command to make sure it auto starts

# svcadm enable -r smb/server

I’ve decided for every day use, I want a data store on the server, so..

# zfs create datastore/homes # zfs create datastore/homes/scott

now, set up compression on my home directory

# zfs set compression=on datastore/homes

Time to do some setup so we can log into this share, I’ll make the box join the workgroup ‘home

# smbadm join -w home

To start sharing with windows boxes, I need to change the pam.conf file to generate windows passwords too. Add the line below /etc/pam.conf

other password required pam_smb_passwd.so.1 nowarn

reset the password for my user scott, then I’ll be able to authenticate with him

# passwd scott

The next step is setting up guest access. You may remember we created a media share datastore/media. We want to share that with guests to the network (on the trusted subnet anyway). Before we go ahead and set that up, we want to map the windows Guest user to the unix user nobody.

# idmap add winname:Guest unixuser:nobody

then we’ll allow guest access to our media box

# zfs set sharesmb=name=media,guestok=true datastore/media

I also want to make my home directory only accessible by me, so I’m going to own the directory

chown scott /datastore/homes/scott chgrp staff /datastore/homes/scott chmod 700 /datastore/homes/scott

and share it

# zfs set sharesmb=name=scott datastore/homes/scott

So there we have it, a media folder anyone can access, and a ‘scott’ share that I’ll need to authenticate with (HOME\scott user)

NFS Shares

Now we’ve got CIFS set up for our clients, I want to set up NFS shares for other Linux boxes on the network (at this point, only my router) to be able to access. The idea is that my router will have all the home directories on the FileServer (so it’ll get the advantages of snapshots, etc) we well as not being limited to the dying 60GB hard disk for torrenting and such things.

As mentioned, I’m only interested in NFS shares with my router at this point, so we’ll make sure my routers IP address (10.12.1.254) is restricted in the shares.

The first thing we want to try is setting up the nfs mount on our homes directory.

# zfs set sharenfs=root=@10.12.1.254,rw=@10.12.1.254 datastore/homes

Now, on my debian router box I want to see if I can mount this (assuming the directory /home2/scott exists on the client)

sudo mount -t nfs -o nfsvers=3 10.12.1.1:/datastore/homes/scott /home2/scott

and Ta-Da! My home directory is mounted. What I want to do now is to set up auto-mounts. That is, when a directory is accessed for my users home directory, it’d mount it on the fly.

First, install the autofs package

apt-get install autofs

Add the following line into /etc/auto.master

/home2 /etc/auto.home -–timeout=60

and the following into the file /etc/auto.home

* -fstype=nfs,rw,nosuid,soft,vers=3 server:/datastore/homes/&

the * and /datastore/homes/& do their magic by automatically mounting the required directory when needed (as long as the /etc/init.d/autofs is started)

Now lets add a place for our downloads

# zfs create datastore/media/downloads # zfs set sharenfs=root=router,rw=router datastore/media/downloads

I chose to just mount this using the automounter under the home2 directory, I added this to the /etc/auto.home file

downloads -fstype=nfs,rw,nosuid,soft,vers=3 10.12.1.1:/datastore/media/downloads

Pretty neat, now when you head to a directory that’s not mounted yet (like /home2/scott/) in the linux client, it will auto mount the required NFS volume and presto, we’ve got ourselves network storage.

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

In part 1 of this blog post, I showed you how I created a script that would, when run, rotate your snapshots on a ZFS filesystem. For this to be usable, we need to create a mechanism for having it be automatically ran. We’ll do this with a cronjob.

On Unix systems, the cron daemon is used to execute scheduled commands. Picture it much like windows task scheduler for all you windows kiddies.

I saved the backup script we wrote yesterday to /FileStore/backups.sh. The first thing I want to get running is my hourly backups. To do this, we’ll start editing our cron file

sudo crontab -e

The crontab utility is a program used to edit the tables that drive the cron daemon.

On my OSX box, information about how to set up the cron file can be found in ‘man 5 crontab’

Basically, cron examines cron entries once every minute. the fields that we’ve got to play with are (in this order)

field allowed values
—– ————–
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)

Having said that, it’s time to think about when we want to create our snapshots. Because I intend machines to do their backups to the server on the hour, I’ll be creating my snapshots at half past the hour. My cron file now looks like this (for hourly snapshots with 24 rotations, daily snapshots with 7 rotations, Weekly snapshots with 4 rotations.

#**Snapshots for the Filesystem**
30 * * * * /bin/bash /FileSystem/backups.sh hourly 24
30 6 * * * /bin/bash /FileSystem/backups.sh daily 7
30 6 * * sun /bin/bash /FileSystem/backups.sh weekly 4

Now that that concludes our section on setting up my rotating snapshots.

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

Installing OS and setup Network

For the following set of posts, I have chosen to use VirtualBox to run through how to use ZFS in building your FileSystem. The first step is downloading and installing OpenIndiana. Get the latest build from http://openindiana.org/download/ (at the time of writing, I’m using oi-dev-148-x86) and install it onto your system. In VirtualBox I chose to install onto a 64 bit Solaris setup.

Make a hard disk when you’re setting up your VM image (I called mine OS_SSD1 because the HD is eventually going to be installed onto a solid state drive.)

Now, the VM is booted, we can start having some fun (SSH into it and Away we go)

Our first step is to setup the address for the box. I must admit, I’m pretty new to Solaris but from what I’ve found, we’ll run these commands to disable Auto Configuration via DHCP then enable our static config.

svcadm disable physical:nwam
svcadm enable physical:default

My fileserver is currently not on a domain (I’ll change this later), so I’ve added the line into my /etc/hosts file

10.12.1.1 thumper.local thumper

Put your hostname that you want to use (‘thumper’ for me) in /etc/nodename

Your default gateway (routers) address should go in /etc/defaultrouter

The last thing to do is tell the host about what subnet it’s on, For me, I added (for my server subnet)

10.12.1.0 255.255.255.0

The next step is set up your nameserver for DNS (/etc/resolv.conf) mine looks like this

nameserver 10.12.1.254

Copy /etc/nsswitch.dns to /etc/nsswitch.conf – so dns is used.

Now so the adaptor comes up on boot, find out the status of your network I/O by running

dladm show-link

(for me was e1000g0). Once you have this, you need to ‘plumbe” to set up the software in the kernel to set this interface on the TCP/IP stack.

ifconfig e100g0 plumb
echo 10.12.1.1/24 > /etc/hostname.e100g0

Last but not least for your network stack,

svcadm restart milestone/network

From this point on, that concludes the base setup with networking that I’m using for the FileServer. If this happened to be a critical server for you, perhaps you’d consider setting up redundant bootable drives with ZFS. It looks pretty cool.

Setting up the storage pool

Now we can get into the fun part. The first thing I want to do with this server is be able to store my data on it, so lets set up our storage pool. In my VM I’m using to test this I’ve added the disks I want to include in my pool (1GB disks for this test)

Once we’ve booted out VM (first thing I always do is ‘sudo bash’ because I’m evil in these silly little test environments).

I want to find out the device ID’s for these hard disks I just added

root@thumper:~# iostat -En | egrep Size\|Soft
c1t0d0 Soft Errors: 0 Hard Errors: 6 Transport Errors: 0
Size: 0.00GB <0 bytes>
c1t1d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 17.18GB <17179869184 bytes>
c1t2d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t3d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t4d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>
c1t5d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Size: 1.07GB <1073741824 bytes>

As we can see, c1t0d0 is my CD-ROM drive, c1t1d0 is my hard disk, so I’ll want to create a Raidz-2 (two redundant drive) storage pool with the drives c1t2d0 c1t3d0 c1t4d0 c1t5d0

root@thumper:~# zpool create datastore raidz2 c1t2d0 c1t3d0 c1t4d0 c1t5d0
root@thumper:~# zpool list
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
datastore 3.94G 256K 3.94G 0% 1.00x ONLINE –
rpool 15.9G 4.17G 11.7G 26% 1.00x ONLINE –
root@thumper:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
datastore 128K 1.93G 44.8K /datastore
rpool 4.52G 11.1G 45K /rpool
rpool/ROOT 3.61G 11.1G 31K legacy
rpool/ROOT/openindiana 3.61G 11.1G 3.58G /
rpool/dump 383M 11.1G 383M –
rpool/export 1002K 11.1G 32K /export
rpool/export/home 970K 11.1G 32K /export/home
rpool/export/home/scott 938K 11.1G 938K /export/home/scott
rpool/swap 544M 11.5G 187M –

We can see now we’ve created a pool of storage across our data (that’s zfs raided) that gives us double parity so we can loose two drives and still be running and we’ve got 2GB of usable space here (I’m using 1GB hard disks, in my real production box these will be 1TB disks).

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up File systems & Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.

Note: This post is one in a series aimed to be a tutorial eventually, it’s not currently finalised and at the moment exists as a place for collating thought and collecting feedback

This will be my first blog post into a guide of setting up a fileserver using Solaris (well, OpenIndiana) and ZFS to create a fileserver that has a main purpose of being a reliable server (the focus on this build is more about reliability then throughput).

My build will probably be different then most. One of the deciding factors in me choosing my hardware would have to be physical space and energy requirements. With this server, I’ve got this relatively unused space sitting behind my 27” monitor that is reserved for the box and as the primary purpose of this box is to backup and store my data in an effort to become paperless, the power requirements are going to be trying aimed at being energy efficient.

I have found a nice tower that I’d like to use that is attractive for a few reasons. It will fit the space behind my monitor nicely but also comes with a very efficient power supply.

For the CPU, at the time of writing (March 2011), the new Sandy Bridge processors are looking like they give a big bang for your buck in terms of power usage. The only problem now is that I have to find a mini-itx motherboard that is compatible with the sandy bridge architecture (has to be mini-itx because of the form factor of the case) and has enough SATA ports (or the ability to expand to meet my requirements) and is compatible with OpenIndiana. So far, the best I’ve found is the the DH67CF. Unfortunately for a fileserver that’s going to be hosting important information, this build won’t support ECC memory, which is pretty important as you can see here (probably a better article required to link there) but hopefully not regrettably, I’ll chose to risk it.

I’ve chosen to go with RAIDZ-2 to give two redundant hard disks in my data pool (with a total of 4 hard drives.) The reason being that if they are coming from the same batch then as hard disks stand, it’s likely that two will fail at more or less a similar time. It’s also worth mentioning for the critical data on my fileserver I’m going to be implementing remote off-site backups so while a dead pool will be frustrating, the likelihood of recovering some data should not be compromised.

I’ve decided that 2TB of storage should be sufficient for my requirements. For my storage array I’ve chosen to go with 4 1TB drives [[ToDo: Choose hard disks and why]] set up in Raidz-2.

Other things that I might require to put in are I/O expansion cards for more SATA drives.

Other posts to come in the series:
1. Selecting the hardware
2. Installing the Operating System
3. Setting up Snapshots
4. Allowing access through NFS & SAMBA
5. Setting up encrypted off-site backups
6. Configuring Windows & Linux clients to dump backup info to the FileServer
7. My router setup, configuring IP tables & torrents on a low-powered server.