Brian's Blog

Introduction

Since starting the project up to wire my house with Ethernet, I have been thinking of interesting ways to put my network to use. For awhile now, we have been using a Western Digital Media player and an external USB hard drive to watch video content on the television. With products like Google TV I have been thinking there would be a value to having attached network storage. My hope is that sometime in 2012, I will have a device plugged into my TV that can stream video over my network both locally and from the Internet.

Most of my thinking was spurred on by a recent sale that Drobo had on one of their low end models. I have been an admirer of the Drobo hardware for quite some time, but I have always found it to be cost-prohibitive; I had never thought I'd get the use to justify the price. In doing some research of the products out there, I felt I had about two choices: to either build a computer or to buy an enclosure with the functionality I need built into it.

The features that I was after were for the device to be network capable supporting Gigabit, to support at least 4 or more hard drives, to support redundancy via RAID, to have a smallish footprint and to be simple enough that I can manage it without having to hire an IT consulting firm. Being able to do this myself, without having to spend a ton of money on software or spending time teaching myself

Because of my requirements,I started off by researching quite a few enclosures, both USB and NAS-type devices. What I found, was that with the enclosures that had the features I was looking for you wound up paying a premium both for the smaller form factor and for the ease of use. Ultimately, a combination of this cost premium and my discovery of FreeNAS convinced me to go the do-it-yourself route.

Hardware

Because I decided to build the NAS from the ground up, I had the luxury to pick the parts I wanted and that suited my needs nearly perfectly. After researching hard drive prices (over half of the cost) I budgeted around $750-$800 in total and visited the website of my favorite vendor, Newegg. I probably could have saved a few dollars going with different vendors for different components, but I value getting all my parts from a company that I have enjoyed working with over the years.

Case

One of the most important requirements was to consolidate all of this equipment down into the smallest reasonable footprint possible. This caused me to invest a little bit of effort and value into the case. I spent more time shopping for the case than I did for any other component. I needed a case that would hold at least 6 different drives and a Mini-ITX motherboard. I wound up choosing the Lian Li PC-Q25B. The case has room for 7 different drives internally and features a hot swap-able drive cage all in small-ish footprint of 14.41" x 7.83" x 11.02".

Motherboard, CPU and RAM

For the motherboard I wanted something low power with an integrated CPU, Gigabit Ethernet and support for numerous (six or more) SATA drives. I wound up picking the ASUS E35M1-I Fusion, a mini-ITX board with an air cooled dual core 1.66GHz AMD CPU built on the board. The motherboard supports up to 8GB of RAM, so I chose two sticks of Crucial 4GB 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800).

Storage

The most important and most expensive part of the build is the hard drives. To start off, I decided that I would begin with four drives and then add two more down the road in the future. Because of hard drives' declining reliability, I wound up buying drives from two different manufacturer; the Western Digital Caviar Green WD20EARX and the HITACHI Deskstar 5K3000. Because hard drives often share problems across an entire batch there is a good chance that when buying two identical drives from the same vendor that both drives came from the same batch. By buying from two different manufacturers I help reduce the fact that half of the drives may in a short time span.

In addition to the disk drives, I purchased a small 8GB USB Flash Drive and a USB cable that plugs directly to the motherboard's USB header to mount inside the case. The purpose of the flash drive is to host the OS and the software to manage the NAS.

Software

The software to power the NAS was my biggest area of concern. I've tinkered with hardware RAID in the past using a 3Ware controller card. Once upon a time in a gaming rig, I had created a RAID 0 array across two disks for the fastest performance. My needs now are a little bit different, I need something cheaper and that is not hardware specific so there are fewer points of hardware failure. In researching how to configure and support the RAID software choices made me lean towards buying one of the all-in-one enclosures. However the discovery of FreeNAS enabled me to go the PC route instead.

Directly from FreeNAS' webpage:

FreeNAS™ is an Open Source Storage Platform based on FreeBSD and supports sharing across; Windows, Apple, and UNIX-like systems. FreeNAS™ 8 includes ZFS, which supports high storage capacities and integrates file systems and volume management into a single piece of software.

From what I have been able to research so far, I am going to be able to place FreeNAS directly on a bootable USB device, and be able to configure/use it remotely via a web-interface running on NAS itself. I have read over their user documentation and I think that FreeNAS is something that a novice like myself can tackle.

Next Steps

Right now, my parts are coming in three different packages making the trek from Memphis, TN to my house. I have been eagerly tracking the packages throughout beginning of the week. Hopefully over the next week or so I will have time to wrap up my other ongoing projects and begin to tackle this new project.

For those of you that follow my Twitter feed and those of you who live within a block or so of my house, then you already know that we have had a pretty difficult day in the MyNetworkCupboard effort two weeks ago.

Our goals were pretty simple; cable up the patch panel, test the existing cable runs, run the network drops to the remaining rooms, and relocate the Verizon FiOS router. From what we had accomplished the night before, I thought it was a slam dunk that we would have the project wrapped up in a few hours and then be eating burgers and drinking beers. In retrospect, it is funny how wrong your assumptions can be about the work that is immediately before you.

We started off by measuring out and crimping down network cables for the patch panel. To be meticulous, we tested each cable we created. Our intent was to wire up the patch panel to such an extent that we could plug in the existing runs and do some throughput testing.

Upon completing the cable cutting, the wheels on our project began wobbling. We attempted to move the FiOS hardware into the cupboard. The FiOS router/modem has both a coaxial cable and an Ethernet cable run into it from the Verizon box on the side of the house. In our research online, we'd read that it needs one or the other, not necessarily both. To test things out, we powered off the FiOS router and disconnected the coaxial cable. With only the Ethernet plugged in, we were not able to access any of the Video-on-Demand services that we get with Verizon's FiOS TV services. We were hoping that it would work with just Ethernet, but that was not the case. For the last step of project reroute both the coaxial cable and Ethernet cable fed into the FiOS router.

The wheels continued to wobble when we noticed during our throughput testing that on roughly half of the drops (8) we were only getting 100Mb and in some cases 10Mb from our runs. When we initially ran each of the drops, we put a cable tester and made sure that each jack lit up on all 8 strands so this came as a bit of surprise. What we found, was that the tool-less RJ45 keystone jacks we had been using were either a little fragile or that we were being careless with them after crimping them down. We had fix and re-test several of the network jacks before they lit up the lights on the switches that we expected and measured out at gigabit speeds.

The next part of the project was a little fun and kind of humorous. Our house is a ranch style house and we have a two-sided fireplace right in the middle of the house. The fireplace separates the office/den and living room, the network cupboard is in the laundry room which is attached to the office/den, and the living room has vaulted ceilings. Getting the cable from one side of the house past the chimney, over the vaulted ceiling and within arm's reach of the other attic access point was going to take some creativity, luck and athleticism; basically we needed Tim Tebow up in the attic with us. Although, I'm not sure Tebow would fit comfortably in the attic or that his awkward left-handed throwing motion would be conducive to making the throw at all.

I purchased a ball of very lightweight but sturdy twine and grabbed one of my puppy's bone-shaped dog toys. I tied the twine to the toy and Pat held one end while I threw the toy, trying to thread a needle across the room near the roof. Twenty or thirty tries later, I finally hit the hole that I was aiming for, but the dog toy was going to be out of our reach from the other side of the attic. However, the dog toy snagged when I tried to pull it back and rather risk losing one of the puppy's favorite toys I decided to go up into the other side of attic and try and retrieve it somehow. From the other side of the attic the toy was out of reach and out of sight, we could see the twine hanging down across a round HVAC duct. But it's resting place was going to be too small and cramped to crawl into.

Thankfully we had a 8-10 foot length of 1"x2" leftover from building the framing and equipment rack. Pat went down into the garage and rummaged around and managed to turn it into a hook of sorts with one of the clamps I we had been using. Thankfully, it was barely long enough that I could lean forward and snag the loose twine and retrieve the dog toy on the end.

The plan after that was to use the string to pull through network cable to the other attic access point and to attach a new stretch of twine to the network cable we pulled through, that way we would have enough twine to pull cables back and forth between the two sides of the house. We pulled the first cable across without too much difficulty and then we ran into the Immovable Object.

The master bedroom, spare bedroom #1, spare bedroom #2 and guest bathroom are in a row through the hall. The hall is nearly intersected by the doorway to the living room. With the attic access in that hallway. Up in the attic, the HVAC unit runs along the wall between the bedrooms and the hallway. HVAC ducting extends towards the front of the house to spare bedroom #2, towards the back of the house to the Master bedroom and then hangs off the back of the unit.

In order to run network cable into the two remaining bedrooms (spare bedroom #2 was already wired up with CAT5e by a previous owner), I was going to have to find a way over the HVAC unit, or the main trunk and then over another smaller HVAC duct. I raked away as much of loose insulation as I could and was dismayed to find that the rafters were running 90 degrees differently than they were over the office/den. The rafters were running parallel to the HVAC unit and there was only one rafter between HVAC & Main Trunk and the next run of HVAC ducting. Being a man of limited mobility and coordination, I had no faith that I would be able to climb over two obstacles, place my boards and move to drill holes down and run cables through them. To make matters worse, the roof slopes down three sides of the master bedroom, even if I could navigate safely past the HVAC obstacles being able to worm into the master bedroom and run a cable down the far wall was a very, very unlikely proposition. With that, the wheels finally shot off on the weekend's progress and any promise of completing the project that weekend was lost.

By the time we finished that Saturday night (very very late), it turned out to be a very frustrating and disappointing day. At one point, I was afraid that we would not be able to complete my goal of cabling every room but the kitchen and bathrooms with Ethernet. However there are always alternatives and I have been thinking about it for two weeks now; right now I'm trying to decide how feasible it would be to use a flexible drill bit (and a some flexible extensions) to try and drill up into the attic and then fish the cable back down. Unfortunately, to buy all of those tools it is going to cost quite a few dollars. Since I am a new home owner, I'm not opposed to buying most tools, since they will likely come in handy down the road on another project. But in this case, I'm hesitant to buy the tools because it's going to wind up being something I only use this one time. We will see what kind of zany/creative/expensive solution we can come up with!

I recently decided to replace my frustrating mobile phone (a Samsung Galaxy S phone, the Vibrant) because Samsung and T-Mobile has been terrible at keeping current with the latest version of Android. I did a bit of research on eBay and Craigslist, and found that the myTouch 4G (aka HTC Glacier) was a comparable phone with more memory and faster data speeds.

I spent New Year's weekend crawling Craigslist trying to find the cheapest MyTouch 4G nearby. I figured it'd be a bit of a calculated risk, but I felt pretty good about it. I found a guy selling one nearby and met up and grabbed up the phone in the parking lot of a nearby McDonald's. From what I could tell, the phone was in good shape but it had been a little loved.

I took the phone straight home, rooted it and installed my favorite Android ROM, CyanogenMod. It was not until a couple days later that I realized the phone had a quirky problem. Whenever I would receive (or place) a phone call, the screen would immediately go dark and remain dark until I either pulled the battery or received another call (and didn't answer it).

After about a hundred different searches on Google, I began to suspect that the proximity sensor on the phone was not behaving properly. The proximity sensor's purpose on phones is to detect how close to your face the phone is. When the phone is right up next to your face, the screen goes dark and does not respond to touch. Once you move the phone away from your face the screen should light back up.

I began by digging around in the CyanogenMod and Android settings. There were some settings that sounded like they might disable or ignore the proximity sensors, but unfortunately they did not quite do the trick for me. Regardless of what I tried, the proximity sensor remained enabled.

I wound up finding an app on the market that I used to troubleshoot the sensor. The name of the app was Proximity Sensor, when I opened the app it told me that the sensor was permanently engaged. Just for fun, I took my flash light and I turned it on and pointed it right at the sensor. When the flashlight was flush up against the phone at it's brightest setting, the app began to report intermittently that the sensor was clearing.

But if it took a flashlight right up against the phone in order for the sensor to turn off, then surely the sensor is most likely kaput.

Since my phone is rooted, I thought I'd give a few different "fixes" a try. According to some of my research, the HTC's proximity sensor is a CM3062. In considering options, I thought we'd have a few options:

1. Deny all permissions on the CM3062 file in the /dev/ folder.
2. Use an application like Tasker or Proximity Screen Off to disable the sensor.
3. Switch to the MIUI ROM since it has an option to disable the proximity sensor.

Ultimately, setting the permissions had no effect. Tasker could read the sensor, but could not disable it and the Proximity Screen Off app seemed a little convoluted to use. I briefly tried out the MIUI ROM, which fixed the issue. But, I have grown pretty accustomed to CyanogenMod and it was hard to give that up.

Ultimately, 8 or 9 pages deep into Google's search results was a suggestion to hex edit file and overwrite information about the sensor. Because I was determined to make CyanogenMod work on the phone, I decided to give it a shot. Within the file, /system/lib/hw/sensors.glacier.so, I searched for and overwrote the "CM3062" text with "xxxxxx" and then rebooted the phone.

Thankfully it worked, the proximity sensor is disabled on my phone and I am able to make phone calls without causing my phone's display to turn off indefinitely. This was confirmed by the Proximity Sensor app, which indicates now that there's an error while trying to read sensor data. This basically turned my dysfunctional phone into something that I could continue to use until my contract runs out and I can upgrade my phone to something with native support for Ice Cream Sandwich in a few months.

According to Google, people frequently have problems with the proximity sensor; people do not seem to like them, they seem to interfered with by screen protectors and phone cases, and then in a lot of instances (and probably mine) people drop their phones and damage the proximity sensor.

I've posted this online in both on XDA Forums and in the CyanogenMod forums. And now, it's forever preserved on my blog. Hopefully, someday down the road it'll help a few other people out.

As a TFS administrator one of the questions I get asked frequently is why someone's build seems to be stuck in queue. Our TFS deployment has quite a few machines that each have a single build agent and build controller installed on them. To complicate things further, we have a few dozen different project collections in TFS.

Since you can only view builds queued up from a single project collection, finding the source of these issues has always been a bit annoying. Moving through each project collection in Visual Studio and viewing the queued builds to find out what was taking so long was usually a frustrating and fruitless endeavor as the builds usually

Generally speaking, I would just write back and let them know I was keeping an eye on things and that they should just be patient for the build queue to clear itself up. But every now and then, something would hang indefinitely and the possibility of that always hung out in the back of my mind..

Thankully, I found an article on Bart Wullem's The Art of Simplicity blog that set me off on the right direction: a console application that got all of the queued build information from the TFS API and wrote it out to the screen. Even better, the source code to the console app was published too.

I made a few changes; instead of hard coding the TFS URL into the app I added a config file and put the URL in there so that you could easily change it, I prettied up the output a little bit by sorting the builds by the by the Build Controller it's assigned to and then by the time it was queued, and lastly I added an elapsed time to the output.

In following Bart's example, I thought I'd share this and save another TFS administrator the effort I went through:

Update (12/28/2011): Fixed an issue where queued builds caused the application to crash.

using System;

using System.Configuration;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Data;

using Microsoft.TeamFoundation.Client;

using Microsoft.TeamFoundation.Build.Client;

namespace TFSBuildQueue

{

    class Program

    {

        static void Main(string[] args)

        {

            int BuildCount = 0;

            string TFS_URL = ConfigurationManager.AppSettings["TFS_URL"];

            Console.WriteLine("\nTFS Build Queue");

            Console.WriteLine("===============\n");

            Console.WriteLine("Connecting to: " + TFS_URL+ " and querying build controllers...");

            TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(TFS_URL));

            IBuildServer bs = tfs.GetService<IBuildServer>();

            IQueuedBuildSpec qbSpec = bs.CreateBuildQueueSpec("*", "*");

            IQueuedBuildQueryResult qbResults = bs.QueryQueuedBuilds(qbSpec);

            

            

            // Define DataTable for storage and manipulation of currently queued builds.

            DataTable QBTable = new DataTable();

            QBTable.Columns.Add("Controller");

            QBTable.Columns.Add("Project");

            QBTable.Columns.Add("BuildDefinition");

            QBTable.Columns.Add("BuildStatus");

            QBTable.Columns.Add("Priority");

            QBTable.Columns.Add("Date");

            QBTable.Columns.Add("ElapsedTime");

            QBTable.Columns.Add("User");

            // Query TFS For Queued builds and write each build to QBTable

            foreach (IQueuedBuild qb in qbResults.QueuedBuilds)

            {

                string RequestedBy = qb.RequestedBy.PadRight(18);

                if (qb.RequestedBy != qb.RequestedFor)

                {

                    RequestedBy = String.Concat(qb.RequestedBy," (for ",qb.RequestedFor,")").PadRight(18);

                }

                DateTime CurrentTime = DateTime.Now;

                TimeSpan ElapsedTime = CurrentTime.Subtract(qb.QueueTime);

                string ElapsedTimeString = ElapsedTime.ToString();

                String TFSET = ElapsedTimeString;

                String TFS_TEAMPROJECT;

                if (qb.Status.ToString() == "Queued")

                {

                    TFS_TEAMPROJECT = "-------";

                }

                else TFS_TEAMPROJECT = qb.Build.TeamProject;

                QBTable.Rows.Add(

                    qb.BuildController.Name.Replace(" - Controller", "").PadRight(17).ToUpper() + "(" + qb.BuildServer.Name.PadRight(17).ToUpper() +")",

                    TFS_TEAMPROJECT.PadRight(22),

                    qb.BuildDefinition.Name.PadRight(55),

                    qb.Status.ToString().PadRight(15),

                    qb.Priority.ToString().PadRight(12),

                    qb.QueueTime.ToString().PadRight(23),

                    TFSET.PadRight(18),

                    RequestedBy.PadRight(18)

                    );

                BuildCount++;

            }

            // Sorts QBTable on Build controller then by date

            DataRow[] QBSorted = QBTable.Select("", "Controller ASC, Date ASC");

            

            // Writes the headers 

            WriteHeaders();

            foreach (DataRow dataRow in QBSorted) 

            {

                WriteReportLine(

                    dataRow[0].ToString(),

                    dataRow[1].ToString(),

                    dataRow[2].ToString(),

                    dataRow[3].ToString(),

                    dataRow[4].ToString(),

                    dataRow[5].ToString(),

                    dataRow[6].ToString(),

                    dataRow[7].ToString());

            }

                            

            Console.WriteLine("\n\nTotal Builds Queued: " + BuildCount + "\n\n");

        }

        static void WriteHeaders()

        {

            Console.WriteLine("\n\n");

            Console.WriteLine("Controller (Agent)".PadRight(34) + " " +

                              "Project".PadRight(22) + " " +

                              "Build Definition".PadRight(55) + " " +

                              "Build Status".PadRight(12) + " " +

                              "Build Priority".PadRight(15) + " " +

                              "Date & Time Started".PadRight(23) + " " +

                              "Elapsed Time".PadRight(18) + " " +

                              "User".PadRight(18));

            Console.WriteLine("=================".PadRight(34) + " " +

                              "=======".PadRight(22) + " " +

                              "================".PadRight(55) + " " +

                              "============".PadRight(12) + " " +

                              "==============".PadRight(15) + " " +

                              "====================".PadRight(23) + " " +

                              "==================".PadRight(18) + " " +

                              "============".PadRight(18));

        }

        static void WriteReportLine(string TFSBuildController, string TFSProject, string TFSBuildDefinition, string TFSBuildStatus, string TFSBuildPriority, string TFSBuildDateTime, string ElapsedTime, string TFSBuildUser)

        {

            Console.WriteLine("{0} {1} {2} {3} {4} {5} {6} {7}", TFSBuildController, TFSProject, TFSBuildDefinition, TFSBuildStatus, TFSBuildPriority, TFSBuildDateTime, ElapsedTime, TFSBuildUser);

        }

    }

}