Recently I built a home NAS file server to finally consolidate all of my data into one easily managed network location. I have worked with Network Attached Storage systems before, and I’ve even played with SAN solutions before, but this was my first time building one from scratch.
The goal of this project is to have a massive, always-on, redundant, and wicked fast network accessible storage drive where I can save all of the files from my massive media collection for permanent archive. This central location will be my grand file repository for basically everything. Ideally I should be able to loose my desktop and laptop drives without losing anything that I care about.
I’ve had plenty of time to define exactly what I needed in a file server, and requirements were actually pretty simple:
- Separate system and storage arrays
- RAID failure protection on both arrays
- At least 7 terabytes of usable storage
- At least 60 MB/s of real world network throughput
- Expandable base that I can add storage to when it become necessary
- Excellent hard drive cooling
- Reasonably low power requirements
- Less than $2,000 total
This is the story of my particular NAS build and some of the stuff I learned during the course of this project.
If you run a public linux server of any kind then you should have a firewall running. Hopefully you already know that. I prefer iptables because it is so powerful, however the iptables language is a little less than intuitive.
If you’re just getting started with iptables and you want a good strong rule set to use or learn from then check out the Easy Firewall Generator for IPTables. This is a great little tool that will give you a shell script with a very nice rule set.
Just fill out the form and save the script to your server. Run the shell script and you have a great firewall with good logging. Though don’t auto-run the script on bootup until you are absolutely sure that you have the rules perfect, iptables can and will happily lock you out of your own server for good.
For the last few years I have spent more time working in the .NET framework than I do PHP. It’s not that I don’t like PHP, quite the opposite, I love PHP. However, it seems most of the work I’ve been seeing is for the .NET Framework. And there is a reason for that, .NET is more powerful in terms of pure control, the Visual Studio IDE is absolutely awesome for working with large solutions, and the .NET library provides so many powerful tools.
PHP has a lot going for it, it is powerful, scale-able, easy to work with, and free. The LAMP (Linux Apache MySQL PHP) solution is the standard on the internet. And for a good reason! It’s cheap, it’s fast, it’s memory efficient, and it is very secure (if run by a capable admin). I prefer to work on LAMP systems because I can lock it down so well with tools that are well tested and maintained, and to top it off Linux hosting is cheap!
But PHP does have some drawbacks. A large PHP project can be a nasty endeavor to catch up on. As a developer I always find it difficult coming into a PHP project and trying to figure out what is where. The conventions are simply the whims of whatever the original developer(s) were used to (sometimes none at all).
Recently I had to upgrade an install of MediaWiki from version 1.6.12 to the latest version. It was originally installed on a host that only had PHP4 and MySQL4. The 1.6.x versions of MediaWiki were the last to support PHP 4. We were moving the site to a new server with PHP5 and MySQL5 so it was time to upgrade to the latest release of MediaWiki, version 1.15.1.
I selected to use the new binary database format during install. After copying over the database and running the upgrade script I came across an interesting error:
Warning: you requested the mysql5-binary schema, but the existing database has the mysql4 schema. This upgrade script can’t convert it, so it will remain mysql4.