FreeNas – recovering from an upgrade that wipes out OpenVPN


Upgraded a couple of my FreeNas servers from 8.3.0 to 8.3.0 p1 last night.  That part went great.  What didn’t work as well is when I got to work today and tried to connect to the VPN on one of them.  Seems that the bone-head in me forgot that upgrading the FreeNas OS would wipe out the modifications to rc.conf to start OpenVPN as well as wipe out the entire /usr/local/etc/openvpn directory with all of the keys and openvpn configuration in it.

The nice folks over at FreeNas.org have anticipated me being a doof and created the upgrade process such that the old OS is preserved.  You can easily roll back to that if you are infront of your server by rebooting and hitting F2 (possibly F1) at the boot loader.

My problem was I wasn’t infront of my server and needed the VPN up ASAP.  So, I reached out to my big brother (Josh Paetzel) and magically the answer appeared in my inbox.

  1. ssh into the server.
  2. su to root
  3. mount
  4. You are looking for this “/dev/ufs/FreeNASs2a on / (ufs, local, read-only)”If it says that, then your old install is /dev/ufs/FreeNASs1a, if it says FreeNASs1a then the old install is FreeNASs2a
  5. Either way, mkdir /mnt/oldinstall
  6. mount /dev/ufs/FreeNASs1a /mnt/oldinstall 
  7. or mount /dev/ufs/FreeNASs2a /mnt/oldinstall
  8. ls /mnt/oldinstall/conf/base/etc/local/openvpn
  9. mount -uw /
  10. cp -r /mnt/oldinstall/conf/base/etc/local/openvpn /conf/base/etc/local/.
  11. grep openvpn /mnt/oldinstall/conf/base/etc/rc.conf >> /conf/base/etc/rc.conf
  12. Either reboot or repeat steps 10 and 11 replacing /conf/base/… with /etc/rc.conf and /usr/local/etc/openvpn

A great big thanks to Brother Josh on this one.  Always there saving me from myself.  Hope this helps someone else in some way, shape or form.

If I build it


I have the opportunity to build a server for a company that I’ve been doing some freelance work for.  It will mostly be a file server.  Originally it was just going to be an easily expandable archive/backup of digital images. Lots and lots and lots of digital images. (3-4 TB, I know…to some of you that isn’t very much) It was really only going to be accessed by a single employee on a daily basis.

Given that brief description of desires, I thought a FreeNas box would be perfect. Set up a VPN, a ZFS filesystem and some shares and be done.

Now, things have changed a little. The thought has been brought up that maybe the fileserver should become the primary repository for images. Currently all images are uploaded to the “cloud” by the various photographers and then downloaded to a disk as a backup. The “cloud” provider has been having some performance issues lately and has negatively impacted the back of house production workflow. Thus the idea to switch things up.

So the question is, does it still make sense to use FreeNas? The main issue as I see it is there is a desire for a super simple user-friendly way for all the photographers to be able to upload images to the fileserver. I thought that SFTP would be a winner, but sadly, some of the locations that the photographers shoot at have restricted web access. Also, the photographers have had problems in the past with FTP.(operator error mostly, but still a real issue) That makes me think that WebDAV might be a good solution, as it runs over port 80. However, I’ve had problems with it when trying to use certain OS’es to access a webdav share. For example, the apache webdav implementation under FreeBSD 8.x does not play nice with Mac OS X 10.6.x.

Another thought is to have all the photographers connect to the VPN and then do standard file sharing. That will mean running the VPN over a non-standard port to get around the restrictions at some of the sites. Not a deal breaker. However, I am not looking forward to trying to train all the photographers on how to use the VPN.

Last thing that I’ve looked at is a solution like ajaXplorer. I have no experience with this type of web software other than playing with it for an hour in a FreeNAS VM. It might be the best solution…just don’t know enough about it to make an educated decision.

So, if anyone is out there and listening, I could use some advice.

FreeNas Remote Backups


So I love that ZFS allows automated snapshots and that my FreeNas box is set up with a 3 disk Raid.  However, I’m paranoid.  What if the house burns down, or someone breaks in and steals all our computers?  A smart guy would have a remote backup somewhere.  So, I decided it was time to get my remote backup groove on.

I know that you can do a ZFS replication to another FreeNas box. The issue I have with that approach is that you have to replicate the entire ZFS volume. I needed something more granular.  So, I busted out some python and started working on a remote backup script. To give credit where it is due, my brother helped me get started…so thanks big brother. 

*Disclaimer*

I am not a programmer.  This code and instructions are provided “as is” with no warranty, promise that it works, promise that is won’t melt your computer or even cause the end of the World.  Use at your own risk.

The general overview of how the remote backup program works is like this. First the program connects to the remote computer and rsync’s all of your files. It’s setup so that you can have four different sets of remote backups all running on different days if you want. I personally am only using one backup that runs every day. Next, it determines the disk usage of the remote backup disk. It then calculates how long the backup took. Once it has all of that done, it compiles an email with a general status at the top and the details at the bottom. Continue reading

FreeNas Fix up


So here’s a quick tip. If you ever get your FreeNas install dorked up so bad that the Web-GUI stops working, grab your database file before you reinstall so you don’t have to re-configure.
The db file lives at:
/data/freenas-v1.db

You can then re-install a fresh FreeNas, drop this back in place via the webGUI and you should be up and running right where you were.

Not that I’d ever need to do something like that.

Edit:

So the really slick way to fix this is grab a FreeNas upgrade CD, slam it into the Nas box.  Boot from it.  Then let it “upgrade” your install and preserve your settings.

OpenVPN on FreeNAS 8.2


This article is no longer current, please go here for an updated writeup on OpenVPN on FreeNas

So I’ve been playing around with FreeNAS 8.2.  Decided it would be handy to have OpenVPN running on the fileserver so my wife and I can get to our files if we are away from home.  There are a couple of tricks that I discovered along the way to get this to work right.

***Make sure to read the comments as there are sample configs and a bunch of other useful stuff down there!!!***

If you find this super useful, I wouldn’t turn down paypal donations.

First the easy stuff.  We don’t have a static public IP, so I needed to set up a DynDNS account.  Once I did that, I configured the Dynamic DNS service on the FreeNAS box with my DynDNS account info.  Then started the service.

Next I needed to forward port 1194 on my gateway to the FreeNAS box.  So now I have a domain name to use and a port that forwards to my file server.

FreeNAS 8.2 has OpenVPN built in.  The config files that we need to be concerned with are:

/conf/base/etc/rc.conf
/conf/base/etc/local/openvpn

The thing about /conf/base/etc/local/etc/openvpn is that you need to create it.  Inorder to do that, you need to make the filesystem writeable.

mount -uw /
mkdir /conf/base/etc/local/openvpn

There is a really good tutorial on setting up OpenVPN here.  It goes through all the steps of generating your certificates, setting up your config files and the like. But pay no attention to the Adding routes to the OpenVPN server over at http://www.unix-heaven.org/node/47. The push route and route entries you enter below will handle that.

When you get to the point of configuring the /conf/base/etc/local/etc/openvpn/openvpn.conf file you’ll need to make a bit of a tweak from the norm to get things to work.  Here’s an excerpt of what was needed. You can find my full server and client configs in the comments below.

# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.0.0 255.255.255.0"
route 192.168.0.100 255.255.255.0 10.8.0.1

The “special” part is the route line. route (freeNAS-IP) subnet-mask 10.8.0.1
You’ll have to change the push “route” to match your network ip ranges too.

If you don’t make that entry, you’ll get an error like this in your server log:

OpenVPN ROUTE: OpenVPN needs a gateway parameter for a –route option and no default was specified by either –route-gateway or –ifconfig options
OpenVPN ROUTE: failed to parse/resolve route for host/network

Now add this to the end of /conf/base/etc/rc.conf

openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf"

If you make your config changes directly to /etc/rc.conf or /usr/local/etc/openvpn they will get blown away on restarts. So, now you should be able to restart your FreeNAS box. Then:

/usr/local/etc/rc.d/openvpn status

to see if OpenVPN is running.

I think that’s pretty much it. Let me know if you have any questions.

FreeNas Follies


Made the mistake of editing my zfs pools from the command line on FreeNas 8.0.2.  Ended up discovering something.  FreeNas uses a database to keep track of things like volumes and the like.  Manually messing with things from the command line throws things out of whack to the point that you have to go in and manually repair them.  So the procedure goes like this.

ssh into freenas.  su to root.  
Then sqlite3 /data/freenas-v1.db

Then list the tables

sqlite> .tables
account_bsdgroupmembership
account_bsdgroups
account_bsdusers
auth_group
auth_group_permissions
auth_message
auth_permission
auth_user
auth_user_groups
auth_user_user_permissions
django_content_type
django_session
network_alias
network_globalconfiguration
network_interfaces
network_lagginterface
network_lagginterfacemembers
network_staticroute
network_vlan
services_activedirectory
services_afp
services_cifs
services_dynamicdns
services_ftp
services_iscsitarget
services_iscsitargetauthcredential
services_iscsitargetauthorizedinitiator
services_iscsitargetextent
services_iscsitargetglobalconfiguration
services_iscsitargetportal
services_iscsitargettoextent
services_ldap
services_nfs
services_rsyncd
services_rsyncmod
services_services
services_smart
services_snmp
services_ssh
services_tftp
services_ups
sharing_afp_share
sharing_cifs_share
sharing_nfs_share
south_migrationhistory
storage_disk
storage_diskgroup
storage_mountpoint
storage_replication
storage_replremote
storage_task
storage_volume
system_advanced
system_cronjob
system_email
system_rsync
system_settings
system_smarttest
system_ssl
Then sqlite> select id, disk_description from storage_disk

Output for me was

1|Member of tank raidz
2|Member of tank raidz
3|Member of tank raidz
4|Member of tank raidz
5|Member of BigWest stripe
6|Member of BigWest stripe1

Now, delete your mistakes.

sqlite> delete from storage_disk where id=5;
sqlite> delete from storage_disk where id=6;

Now do the same for storage_volume and storage_diskgroup

I’m sure there are other ways you can make FreeNas unhappy, so maybe this little hint will help with that too.