Bennyvision

NDOUtils vs Liveupdate - check latencies and the battle of the NDO modules

nospam@example.com (Chris Bensend) — Tue, 29 Nov 2011 15:32:45 +0000

One metric of Nagios that should be monitored at all times is the various check latencies (host, service, passive, etc). If Nagios gets "behind" in its scheduling queue, the various latencies increase. This causes serious issues that you must be aware of - your host and service checks can be rescheduled into a future (sometimes, FAR into the future). If you have several critical services that you need tested once every three minutes, Nagios' brain-dead scheduler might very well start checking them once every 15 minutes if you're not careful.

Typically, high host and service check latencies point to one of three things in my experience:

1) Too many things being monitored

2) Underpowered monitoring system

3) Use of NDOUtils

Let's address these one by one, and I'll explain in more detail.

Too many things being monitored: This is pretty self-explanatory. You're trying to do too much at once. If you have 10,000 hosts that you want polled once every five minutes, that's 33 host checks per second that you'll be attempting (for the sake of simplicity, assume a constant schedule instead of one that adapts like Nagios' does). 33 host checks per second, plus any service checks you're trying to do. Be realistic about what you want to do - this is probably just too much for a single instance to do, unless it's a very beefy machine. See the next point, they're related.

Your monitoring system is underpowered: We've all been in this situation - "do more with less," or "we don't have budget for that." If you have a lot of things to monitor, you need a lot of machine. Now, Nagios is MUCH more lightweight than most (all?) commercial monitoring packages. That doesn't mean that you can monitor 1,000 hosts and 3,000 services on a pre-Pentium class machine. If you're trying to come up with specifications for a new monitoring host, I would recommend a multi-core system with plenty of RAM. I don't mean a 16-core beast with 32GB of RAM for monitoring 300 hosts, I mean a quad-core system with 4 or 8 GB or RAM to monitor 1,000 hosts. System sizing has a touch of black magic in it, and your requirements will vary drastically with what you're trying to run. If 99% of your host and service checks use the standard Nagios plugins, you can get away with a lighter system. If you have a number of custom Java or perl plugins that you run, size your system larger (more CPU and RAM). Disk space is usually much less critical, unless you're processing massive amounts of performance data. In that case, split that storage up so the system isn't trying to update 50 RRD databases while trying to monitor and log everything on the same disk volume.

Use of NDOUtils: By far, I have had more problems with the NDOUtils NDO module than anything else, when looking at monitoring system latency. With NDOUtils loaded and running, Nagios daemon refreshes and seemingly random database tasks pushed my latencies ever-skyward, until I ended up having to restart Nagios (not reload, restart) several times a week to keep latencies "low enough." Now, mind you, having all of the Nagios status and historical data in a database (good lord, people, WHY MySQL?) was handy. However, it just wasn't worth it.

And that brings us to the point of this post: Livestatus. On a whim, I installed the Livestatus NDO module on my development Nagios systems, and disabled NDOUtils. What an incredible difference that made! Since I installed Livestatus on my production systems, my host and service check latencies have remained well under 5 seconds (averaging about 1.6s and 4.1s each respectively), which I could only enjoy for the first day or so after restarting Nagios when using NDOUtils.

Now, Livestatus doesn't use MySQL (thank goodness) or any other relational database on the back end - it stores everything internally, and is therefore incredibly fast. It only took a few hours to rewrite all my custom reports that had connected to the NDOUtils database to use the LQL query language that Livestatus uses, and now they run considerably faster.

All in all, I've been using Livestatus for about a month, and I couldn't be happier. It's quick, efficient, MUCH lighter than NDOUtils, and keeps my host and service check latencies much lower.

Monitoring the Monitoring System

nospam@example.com (Chris Bensend) — Fri, 05 Aug 2011 20:58:00 +0000

No matter the size of your network monitoring system, you need to be aware of what it's doing at any given time. This doesn't just apply to Nagios - it applies to any open-ish monitoring system that you're able to customize with plugins/service checks. And this doesn't apply to the services you're being tasked to monitor, either. This means the monitoring system itself.

There are several rules I follow when I set up a monitoring system, be it one monitoring server or three:

1) Know when your monitoring system isn't monitoring. It happens, people - between system load, software bugs, and just bad luck, your monitoring system will give up the ghost at some point. Know when that happens - monitor it out-of-band. In other words, don't monitor your monitoring system with .. wait for it .. your monitoring system. Write a shell script, perl program, or use a pre-existing plugin to watch over things. Myself, I use the check_nagios plugin to monitor my Nagios servers via cron. It doesn't depend on Nagios, but it runs every five minutes to make sure that Nagios is monitoring things and updating its status log as it should. With the numbers of hosts and services that I monitor, if that status log isn't getting updated dozens or hundreds of times a minute, something's wrong.

2) Know what software your clients are running. I will leave the definition of "software" very open-ended - it doesn't matter that much. It might mean the version of NRPE on *NIX hosts, the version of NSClient++ on a bunch of Windows servers, or the version of OpenView clients out in the field. Know what version they're running. I don't send notifications if any of them are out-of-date, but I can tell with one glance at a service group. And before you say something like "I install all my clients myself, I know they're all up-to-date", think about virtual machine snapshots. If one of your customers reverts to an older snapshot, are they still running the client you need them to?

3) Know what configuration your clients are running. Again, I'll purposely leave the definition of "configuration" loose. Personally, I define it as the NSC.ini file versions running on my hundreds of Windows clients, as well as what version of Nagios plugins they're running. I wrote a plugin to parse the config version of NSC.ini (it's just a VB script that parses the comments in the ini file), as well as a plugin to parse the version of my custom plugins (another VB script to parse a text file, similar to a changelog). When I push out updates, I can watch the appropriate service group and see the changes propagate.

4) Automate, automate, automate. If you have over a few dozen hosts and you're editing files by hand, you're probably doing it wrong. I use NConf and several custom perl programs to automate my configuration file generation for Nagios. If you're not using Nagios, you may or may not have that luxury - but I have the capability to change a service check on hundreds of hosts with just a few mouse clicks. Not all changes are that easy, of course, but the capabilities given to me by NConf and my programs are invaluable. And when it comes to maintaining the clients, use the tools you [hopefully] already have in place to maintain the rest of those systems - Puppet, SCCM, whatever. I use SCCM to maintain the clients and plugins on all of the Windows servers I monitor, and it works great. Puppet takes care of the Linux boxes I'm watching, too.

These items may sound like common sense, but far too many sysadmins out there monitor their client hosts, but never monitor their monitoring system. Keep an eye on things, and not always in the obvious way.

NRPE: Handy program or Satan's mistress?

nospam@example.com (Chris Bensend) — Tue, 05 Jul 2011 17:59:00 +0000

Over the years, I have spent a lot of time troubleshooting client/server problems as I create new Nagios service checks. I have compiled a list of common problems with the NRPE (Nagios Remote Plugin Executor) client/server, and how to fix them. Perhaps you'll find them useful. While NRPE is a great little program, sometimes things are not what they seem to be.

Overview: NRPE, as noted above, is a remote plugin executor. It allows you to execute Nagios plugins on a remote host, and passes along the result. Many plugins are not network aware, like check_disk or check_swap. NRPE can be used to run these local-host-only plugins on the remote system.

Common problems:

1) "NRPE: Unable to read output"

Oh, ${DEITY} bless this error message. This is an overly generic "wow, something's wrong" message, and could mean anything from the NRPE daemon not running properly on the remote client to being blocked by a firewall. Let's examine this scenario a bit more, and list questions you must ask yourself when faced with this error.

Is the remote host running the NRPE daemon? Are you sure? Ie, have you checked to make sure it's actually up and running?

Is this host allowed to connect to NRPE on the remote host? Check the allowed_hosts directive in the remote host's NRPE configuration file (typically /etc/nrpe.cfg or /etc/nagios/nrpe.cfg, your mileage may vary). The allowed_hosts directive is a comma-delimited list of IP addresses that NRPE will allow to talk to the NRPE daemon. Make sure the IP address of the host you're connecting from is in this list! If you need to add it, make the change and restart the NRPE daemon so the change takes effect.

Is the remote host behind a firewall, or running a firewall? If so, have you allowed the NRPE port (5666/TCP)?

If the daemon is up, what IP/port is it listening on? Check the server_port directive in nrpe.cfg. Now, check server_address. Are they what you expect? If they are commented out in the config file, NRPE will run on all configured IP addresses, on TCP port 5666. Check the output of 'netstat -an | grep 5666' - is it what you expect?

Is the remote command you're trying to execute using sudo to do it? If so, check whatever log you have sudo complaining to - it may be complaining about needing a TTY (set 'Defaults:nagios !requiretty', replacing 'nagios' with whatever user NRPE is running as), or the command you're trying to run may not match the sudoers definition you have set up (this will show up in the log as 'command not allowed', fix your sudoers definition). Or, you may have forgotten to configure sudo completely!

2) "Connection refused"

Go start NRPE. No, really.

If it is running and listening to the IP/port you expect, is there a firewall in the way? If there is, resist the urge to just disable the firewall - it probably should be running. Instead, learn how to configure the firewall properly to allow the connections from your Nagios server. Be sure you allow it only from your server - you don't want the unwashed masses to connect to your NRPE daemon!

3) "Return code of 127 for check of service "bob" on host "foo" ws out of bounds. Make sure the plugin you're trying to run actually exists"

While this one appears fairly straight-forward, it still causes no end of heartache. As the error message states, check to make sure the plugin exists. And then, check to be sure that the user the NRPE daemon is running as has access to the plugin (including execute privileges!), and to the entire directory path to the plugin. The user doesn't need write permissions, it just needs to be able to get to it (with execute permissions for the user on all directories in the path).

For example, if your plugin 'bob' is in /usr/local/nagios/libexec, check all elements of the path:

[root@nagioshost ~/]# ls -ld /usr /usr/local /usr/local/nagios /usr/local/nagios/libexec

drwxr-xr-x root root 4096 Feb 15 2009 /usr
drwx------- root root 4096 Feb 15 2009 /usr/local <--- problem!
drwxr-xr-x nagios nagios 4096 Feb 15 2009 /usr/local/nagios

There are, of course, many other errors that can pop up with NRPE and monitoring remote hosts. But these steps are good starting points to being troubleshooting, and take care of the most common errors.

Movies on demand, on a budget, part II

nospam@example.com (Chris Bensend) — Tue, 11 Jan 2011 18:57:37 +0000

This is a followup to the first blog posting, Movies on demand, on a budget.

First Pro-Tip: Don't buy the Seagate NAS I selected. It is drastically, shockingly, grossly underpowered. Running backups to an external USB drive rendered the unit unusable - we couldn't even watch a movie while backups were running. And the backups are not incremental - they are full, copy-the-whole-thing backups. So, each time it started to backup my TV shows (650GB) or my movies (600GB), it would render the NAS largely useless for a day or more. Hell, the web interface wouldn't even work reliably while backups were running.

Oh, and get this - the Seagate BlackArmor 220 wouldn't back up files to a Seagate 2TB drive - the rsync process would fail every time. I tried this with two different Seagate 2TB drives, and two NAS units. Seagate support couldn't figure that one out, so I finally bought Western Digital drives, and it works great. It just buries the poor, pitiful little CPU when it does. but at least it works.

Second Pro-Tip: I am not very experienced with video files and encoding formats, so ripping to AVI with various encodings was probably a mistake. I have since begun re-ripping my DVD collection to pure ISO images. They are much larger files (most are 4.4GB each), but I get all the special features, the DVD menus, and most importantly: the DVD quality. Some of the AVI qualities were terrible. I'm sure I could have figured that out, but now I'm just ripping everything to ISO and getting all of the things I wanted. God help me when I start working on the Blu-Ray movies - those suckers can be upwards of 30GB each...

Synology DS710+ NAS

Now, you may be asking - well, if the Seagate NAS is such a dog, what do you use? I bought a Synology DS710+ with a DX510 expansion shelf. Yeah, much more expensive, but MUCH more powerful/capable/expandable/useful. Their management interface is light years ahead of Seagate's, it's rock-solid, and I can take this bad boy up to 21TB raw. And since I'm re-ripping into ISO images, I need the expandability.

Synology DX510 expansion unit

Oh, and by the way, this NAS has a 1.6GHz processor under the hood. I haven't been able to get it to hit 20% utilization yet, even when copying ISO files and maxing out the network.

This NAS rocks. That is all.

Nagios Plugins - Part 2: Practical Examples for Nagios Commands and Plugins

nospam@example.com (Chris Bensend) — Mon, 16 Aug 2010 13:50:43 +0000

In Part 1, I described what Nagios plugins are, a very basic primer on building them from scratch, and a simple example of constructing a Nagios command using a plugin.

Typically, functional Nagios commands are not quite as simple as my earlier demonstration. For example, I have the following command configured on one of my servers:

define command {
    $USER1$/check_nrpe -H $HOSTADDRESS$ -u -t $USER11$ -c CheckDriveSize -a ShowAll=long MaxWarnUsed="$ARG1$" MaxCritUsed="$ARG2$" Drive="$ARG3$"
    command_name check_windows_disk_custom
}

This command uses the check_nrpe plugin to query an NSClient++ agent on a remote Windows system to check a Windows volume's utilization. It uses three arguments - $ARG1$, $ARG2$, and $$ARG3$, which are configured to be the warning threshold, critical threshold, and the volume to check respectively.

It also uses a macro ($USER11$), which is a variable set in resource.cfg. Typical Nagios installations can have up to 32 user-defined macros set in this file, and the CGIs will refuse to display anything in this file via the web server. Therefore, it is handy to define variables such as SNMP communities, passwords, etc here. NOTE: These variables will be exposed in the system's process listing, so if you have other users on your Nagios system and any of these items are sensitive, find another way to do it!

Plugin and process timeouts are another handy thing to define in resource.cfg - the $USER11$ macro used above is actually a global timeout value (in seconds) for any commands I define using check_nrpe. That way, if I decide to change the timeout value, I change it in one place and not dozens.

While these are user-defined, it is recommended to leave $USER1$ configured as the full path to the Nagios plugins. If you have a different location for some of them, define an additional macro for that path and use it in the same way.

So, let's create a new Nagios check command that uses the check_rpc plugin and some arguments, so you can see how it all comes together:

Building a flexible Nagios command

Imagine that you need to test NFS on a remote server. Doing this is simple, as the Nagios plugins include one named check_rpc, which can test any of the portmapper-provided services. So, you create a Nagios check command to test NFS:

# 'check_nfs' command definition
define command{
    command_name check_nfs
    command_line $USER1$/check_rpc -H $HOSTADDRESS$ -C nfs
    }

This will work well. But now, your boss just ran in and said that you need to test mountd as well. OK, fine, here we go:

# 'check_mountd' command definition
define command{
    command_name check_mountd
    command_line $USER1$/check_rpc -H $HOSTADDRESS$ -C mountd
    }

There we go! Ooops, he just returned, and said that it's absolutely critical to test rquotad as well. You could make a third check command to do this:

# 'check_rquotad' command definition
define command{
    command_name check_rquotad
    command_line $USER1$/check_rpc -H $HOSTADDRESS$ -C rquotad
    }

But isn't this a pain? Now, you have three separate check commands to do the same basic thing - test to make sure an RPC program is available. How about a much simpler, and more flexible, check command:

# 'check_rpc_program' command definition
define command{
    command_name check_rpc_program
    command_line $USER1$/check_rpc -H $HOSTADDRESS$ -C $ARG1$
    }

This one check command can take care of the previous three, simply by replacing one of the parameters to check_rpc with an argument (ARG1) that is specified in the Nagios service definition.

OK, groovy. How can I use this?

It's very simple - you just need to specify a single argument to the check command when you're defining your Nagios services. To specify arguments, you must separate them with an exclaimation mark. So, a service to test rquotad might look like:

# myhost - rquotad service
define service{
    use generic-service
    host_name myhost
    service_description rquotad RPC service
    check_period 24x7

...

    contact_groups admins-email
    notification_interval 240
    notification_period 24x7
    notification_options w,u,c,r
    check_command check_rpc!rquotad
    }

Once you understand the flexibility of the Nagios plugins, it becomes very easy to build complex service checks to test whatever you need to test!

Nagios Plugins - Part 1: An Introduction to Nagios Plugins

nospam@example.com (Chris Bensend) — Tue, 10 Aug 2010 13:01:29 +0000

Nagios is an open-source network monitoring system. I've been using it for a decade now, since the days of Netsaint 0.0.4. I think it's a great product, and is my clear favorite when I need to monitor hosts or services on a network.

The Plugins - an Overview
Nagios itself is a daemon that schedules service and host checks, handles notifications, and a web interface to view status and issue commands to the daemon. Nagios is great, but it's nothing without the plugins. The plugins are the service and host checks that actually test things, and present the results back to the Nagios daemon.

For example, when you want to make sure your Sendmail server is up and accepting messages, you can connect to TCP port 25 (SMTP) and see if it's listening. Keep in mind, this only tests to make sure the daemon is accepting connections, not that the mail is routed correctly or filtering properly or anything like that. This is a very simple example.

To connect to port 25, Nagios has no idea what to do. It needs a plugin to do so - in this case, check_smtp. This plugin will make the required connection to TCP port 25, look for the correct greeting, do authentication if need be, and then present the results to Nagios.

There are many plugins available... There are approximately 50 or so available via the base plugin distribution, and thousands more available via the Nagios community. And, in additional articles, I'll show how easy it is to create your own plugins.

Building the Base Plugins

The first thing to address is: packages or source? Chances are pretty good that there is a pre-built package available for your Linux distribution if you're running Linux, or for whatever UNIX variant you're running. I build my plugins from source, simply because it gives me more control about where the binaries end up, what features are included, etc. This is a decision you must make - do you want to build them from source, or install a package if one is available?

If you want to build from source, continue on with this section. I'm making the assumption that you're on a relatively "normal" distribution like Linux, Solaris, or BSD. If you're on a "not normal" distribution like AIX, good luck. Yes, it can be done. No, nothing is fun on AIX.

First, go get the source distribution from the Nagios site. It can be found here: Nagios plugins

Download the file and save it on your Nagios server. Use the tar command to unpack it like so:

tar zxvf nagios-plugins-X.Y.Z.tar.gz (where X.Y.Z is the version number)

This command will uncompress the gzip'ed file, and unpack the tar archive into a nagios-plugins-X.Y.Z directory. cd into that new directory.

Now, the simple thing to do here is run configure with no options. This will create the Makefile with default options, and is suitable for probably 90% of you. To do so, simply run the configure script with no options:

./configure

However, if you'd like to see what options are available:

./configure --help

Once you have settled on the options, build the Makefile. When that is complete, compile the plugins:

make all

And when you're ready, install them:

make install

Now, a few notes of interest: Doing this entire process as a non-privileged user works just fine, as long as the target directory (--prefix/libexec) exists and is writable by the non-privileged user. If it doesn't or isn't, do this as the root user. Your individual security policy/process may dictate other courses of action, be sure you follow the local policy that is required of you.

I've Built the Plugins - Now What the Heck Do I Do?

The resulting binaries, regardless of whether you built from source or installed a distribution's package, landed somewhere on the filesystem. If you built from source, the default path is /usr/local/nagios/libexec. If you built from source but you altered the path, you already know where they are. If you installed a package, go find them.

Once you've found the binaries and have cd'ed into the directory, you can immediately begin exploring their options. All of the Nagios base plugins should include the '-h' option which gives the help output for the plugin. This will list the available options and what arguments those options expect. For example, the check_rpc plugin gives the following output:

[nagios@host]$ ./check_rpc -h
check_rpc v1.4.14 (nagios-plugins 1.4.14)
The nagios plugins come with ABSOLUTELY NO WARRANTY. You may redistribute
copies of the plugins under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
Copyright (c) 2002 Karl DeBisschop/Truongchinh Nguyen/Subhendu Ghosh

Check if a rpc service is registered and running using
rpcinfo -H host -C rpc_command

Usage:
check_rpc -H host -C rpc_command [-p port] [-c program_version] [-u|-t] [-v]
check_rpc [-h | --help]
check_rpc [-V | --version]

The server providing the rpc service
The program name (or number).
The version you want to check for (one or more)
Should prevent checks of unknown versions being syslogged
e.g. 2,3,6 to check v2, v3, and v6
[-u | -t] Test UDP or TCP
[-v] Verbose
[-v -v] Verbose - will print supported programs and numbers

Send email to nagios-users@lists.sourceforge.net if you have questions
regarding use of this software. To submit patches or suggest improvements,
send email to nagiosplug-devel@lists.sourceforge.net.
Please include version information with all correspondence (when possible,
use output from the --version option of the plugin itself).

Try the '-h' option with several of the plugins just to get an idea of what is available.

Building a Check Command

Now that the plugins are installed, you need to create a check command. A check command is a command that is used within Nagios to test a real host or service. It ties a plugin together with its arguments and makes it useful for Nagios. Here is an example:

define command {
command_name check_my_website
command_line $USER1$/check_http -H $HOSTADDRESS$ -u $ARG1$
}

This defines a check command that will connect to the host you're checking, and requires a single argument - the URL you want to check. It will return the result of the plugin's test to Nagios, and Nagios will alert accordingly. If you're curious, the $USER1$ macro is, by default, set to the location of the plugin binaries. The $HOSTADDRESS$ macro is typically the IP address of the host being tested.

Once you have this command built, you can use it for Nagios services.

That's a Wrap

That's about as simple as you can get when it comes to plugins and check commands. There are MANY more options and possibilities, I only wanted to give a very basic set of instructions for people sticking their toe in the water. A very good next step is to consult the official Nagios documentation to learn more about the options available to you for building check commands and using plugins:

The official Nagios documentation

Movies on demand, on a budget

nospam@example.com (Chris Bensend) — Sat, 07 Aug 2010 21:57:00 +0000

I recently finished with a video project at home - video on demand.

For many years, I've wanted to have all of my movies on the network, so I could view them from any of our TVs or computers, whenever I liked, without hunting for the physical DVD. Not to mention, I've grown weary of the four large DVD shelving units in the living room. What a waste of space!

So, I finally built a video-on-demand system that stores all of my movies digitally. They are available to any TV in the house, whenever I like, and the DVDs are now stored in the basement. I can pick any of our movies or TV shows on DVD via a graphical menu and watch, just as if I had loaded the DVD.

There are many ways of doing this, some of them cheaper than the solution I built. That's fine - I'm just detailing one possibility that works very well for us. I chose the products I chose due to features, reliability, and cost. You may choose others if you're working on a similar project.

Movie Storage

Seagate BlackArmor 220

There are many ways to store the movies... I chose a NAS (Network Attached Storage) with 2 TB of storage, gigabit ethernet, and simple backup abilities. The one I selected was the Seagate BlackArmor 220 - it has dual 2 TB drives in it, giving it a maximum of 4 TB of capacity. I opted for RAID 1 (mirrored drives) for redundancy, so I have a capacity of 2 TB in the one unit. It has USB ports on it, allowing me to plug an external drive in to back up all of my movie files. The speed is not blazing, but it is fast enough, reliable, and has a decent enough web interface for management.

Eventually, I will have the NAS and two 2 TB external hard drives. I will keep one drive plugged into the NAS for a month, running backups to it. At the end of the month, I'll take it to the bank and put it in the safety deposit box, retrieving the other 2 TB drive. That will be plugged into the NAS for the following month. I will keep rotating them between the NAS and the safety deposit box, ensuring that I won't lose more than a month's worth of changes if the NAS fails. Yes, the NAS is RAID and therefore should not lose data if I lose a drive, but RAID has its own problems, and the NAS itself might have issues that could lose data. Always have backups, people. It took me about 10 weeks of ripping on two computers simultaneously to rip all of my DVDs, I don't intend to have to do that ever again.

Cost: ~ $400

Data Format

I chose AVI for the data format... It is mostly portable, has good video/audio quality, and is good enough for me.

Media Player

Western Digital WD TV Live media player

I chose the WD TV Live media player. It is a small box, just a bit larger than a pack of cigarettes. It has a 10/100 Mb ethernet port, HDMI output, optical audio output, and composite and component video out. Its menu system is fairly rudimentary, but it works well and is reasonably stable. Its not the fastest thing in the world, so if you flip between menus/screens faster than it can keep up, you may send it off into la-la land. If you realize its limitations and take your time, it's pretty close to bulletproof.

It also plays about every media format known to man, so it will likely be able to show you your pictures, play your music, and almost do your dishes.

Cost: ~ $89 per player (2 for us)

The Software

You need software to rip DVDs, and some of this software may or may not be legal in your area. Keep that in mind - I am not advocating you do anything illegal.

I purchased a software package called DVDFab, available at DVDFab.com. Their support is great, they have frequent updates, and it's very reasonably priced (under $100 for two years of support). I used it to rip my DVDs into AVI files, which I then stored on the NAS.

Note - if you choose to use DVDFab, you need to buy both the "DVD to DVD" product as well as the "DVD to Mobile". The "DVD to DVD" product is the base that all the other options require, and the "DVD to Mobile" option allows you to rip directly to AVI files (and many other formats suitable for portable devices).

One nice thing about DVDFab - they give you 30 days to try any of their software to make sure it will work for you. So, download it, take it for a spin, you probably won't be disappointed!

Cost: ~ $80

How the Whole Thing Comes Together

It's pretty simple in the end:

DVD -> DVDFab -> AVI file -> NAS -> WD TV Live -> Eyeballs and ear holes

I used DVDFab to rip all of my physical DVDs to AVI files. These AVIs are stored on the NAS - I have saved over 400 movies to my NAS so far, and I still have considerable capacity free (probably enough for another 300 or so movies and TV shows).

The WD TV Live units connect to the NAS, and present a GUI listing of the movies and TV shows on the NAS. I select the one I want to watch, and voila - I'm watching my DVDs without touching a disk.

You may be thinking "Wow, is this dude lazy or what?!? He can't even expend the energy to put a DVD in the player?" Well, that's not what this is about. This project is about having any of my movies or TV shows available at the click of a button, with no hunting for disks. No storing hundreds or thousands of DVD cases in the living room. No misplaced or scratched DVDs.

And it works beautifully. For under $700, I can now pick a movie from either TV in the house in about 15 seconds. I can pause them, play different shows on the two TVs at once, as well as play almost any other format of media as I choose to.