The scenario: the home network is centered around a Linux server. This acts as (amongst a number of other things) a large data repository. All our media files, photos, music and so on are stored on it. Apart from the convenience of having it all centrally located, it also provides data security: all critical data is archived hourly using rsnapshot, such that there is always a backup from at least one month ago in the event of data being e.g. accidentally deleted. It uses a single 1TB disk as the main data store, with a second 1TB disk for the snapshots. Then in addition to that, really really critical data (the irreplaceable stuff) is archived every night to an off-site location. Anyway, in recent times my children have discovered the pleasures of photography… Vast quantities of pictures to be put on a PC and secured. To date it’s gone like this:

• Kids use a single laptop, running Linux.
• Each has an account on the laptop.
• Plug camera in to laptop and pull the pictures on to the laptop.
• In background, cron archives them off to the server using rsync over ssh.

As far as the kids themselves are concerned, there’s (a) a single laptop and (b) it has all their photos on it and (c) papa has assured them that if something terrible happened to the laptop, the pictures can be restored from the server.

Thus far, fine.

The network expands

Time to change… Precipitated by an additional laptop, things get kinda complicated. I want the laptops to be “floating”, and used by either child. No “the HP is mine, the IBM is his”. However that then makes it tricky: with only the single laptop it is the primary (since only) data store for their photos. Backups aside, it’s straightforward. So I need to shift the primary data stores off the laptops themselves and having them full-time on the server, and accessed over the network. Which is fine, except that performance it going to be an issue: these are laptops, and they are connected to the home network using wifi, so network file systems are potentially a problem (you ever tried regularly scanning several thousand photos over a wifi connection…? …it’s not what you want to do regularly!)

So we’re going to need network file systems with some sort of magical optimisation…

The solution

We’re going to create a solution with several key elements:

• The server is going to have data stores for each laptop user, shared out on the network using NFSv4.
• The clients (the laptops) are going to use a caching file system on top of the NFS shares, to attempt to provide less load on the wifi connections.
• The clients are going to need to auto-mount the correct data stores depending upon which user is using them.

A quick word on file system caching here: books can (and have!) been written on such subjects… Suffice to say that it’s easy to fall in to the trap of thinking that caching is always a good idea, and simply must improve performance. Not at all. Any file system cache can provide improved OR degraded performance depending upon how it is used (e.g. lots of small files, or large files, regularly accessed, infrequently accessed, underlying file system type,…. the list is long and has multiple permutations)

Suffice to say that here the “performance improvement” we are after is load reduction on the wifi network. I am not going to go in to the whys and wherefores, but here will blindly assume that a caching layer between the client and the NFS shares is a good idea in the circumstances. Your mileage may vary – and BTW, it’s rather fun to test and compare. Try it!

The Elements

• The server is a Linux server running Ubuntu Server 11.04. (None of this configuration is going to be too highly Ubuntu, or even Debian-derived, specific, so any Linux will do)
• NFS Server on the, er, server.
• Ubuntu laptop clients, again 11.04, but also fairly generically applicable.
• Clients to have NFS v4 client code, Cache-fs and automouting capability.

Setting up the Server side

We’ve 3 users to be catered for in this exercise. For the rest of this article I’m going to call them A, B and C. The server itself goes by the name bobby.

On bobby, if not there already, I need to install the following packages:

• nfs-common
• nfs-kernel-server
• portmap

The locations, on the server, of my data stores are going to be:

• /data/A
• /data/B
• /data/C

First step is to create binding within the exports directory. Edit /etc/fstab to look like this:

# NFS bindings to /export
/data/A              /export/A        none    bind    0 0
/data/B              /export/B        none    bind    0 0
/data/C              /export/C        none    bind    0 0

Make sure that the directories /export/A, B & C are created, then a

mount -a

should bind the real locations to the export locations. Check with a

mount

which should be display something like this:

/mnt/DATA1/data/A on /export/A type none (rw,bind)
/mnt/DATA1/data/B on /export/B type none (rw,bind)
/mnt/DATA1/data/C on /export/C type none (rw,bind)

and shows that the bindings are there. This also actually illustrates another point: in actual fact, the ultimate location of the data stores are /mnt/DATA1/data/A, …B etc. These are then symlinked to /data/A, …B etc. for convenience. One can refer to the symlinked location on fstab no problem. However the mount command dereferences that and shows the final location as here. That’s all fine.

Now a word about NFS server configuration….! It’s a potential minefield. If you need to, start off over here: Ubuntu Guide to NFS

But you may be better off trying this ultra-simplified version I present, before thinking about tweaking stuff.

For now, all I do is edit /etc/exports to contain:

/export	 192.168.0.0/24(rw,fsid=0,insecure,no_subtree_check,async)
/export/A    192.168.0.0/24(rw,nohide,insecure,no_subtree_check,async)
/export/B    192.168.0.0/24(rw,nohide,insecure,no_subtree_check,async)
/export/C    192.168.0.0/24(rw,nohide,insecure,no_subtree_check,async)

The only parts of that I’ll go in to are:

• The /export locations are those that you bind to in the fstab declarations.
• The ip range (note it’s a range, not a single address) covers the location of my clients (i.e. the laptops on the home network all have addresses of the form 192.168.0.XXX)
• That first line is required!
• rw = read/write access (probably what you want)

and then fire up the NFS server with:

/etc/init.d/nfs-kernel-server start

All being well, we’re then pretty much done on the server side.

A word on user IDs…

NFS is….. kinda quirky. Some of those quirks relate to how remote clients are recognised (authenticated) by the server. There are a multitude of ways this can happens, all optional and all somewhat different. Many are also rather complex… Want some advice? OK: since the server and the clients are all under “your” control, make it easy. And “easy” here means as follows: ensure that users’ UIDs are the same on the server and all the clients.

Put practically, here’s what I’m talking about: on the server, do:
cat /etc/passwd
to produce something reminiscent of this (lightly obfuscated)

.
.
.
A:x:1001:100:person named A:/home/A_directory:/bin/sh
B:x:1002:100:person named B:/home/B_directory:/bin/sh
C:x:1003:100::/home/c_directory:/bin/sh

It’s the numbers you care about: for example, User A has UID=1001 and GID=100.

Now check the same file on either future client laptop:

.
.
.
C:x:1003:1000:c,,,:/home/ccc:/bin/bash
A:x:1001:1001:a:/home/aaa:/bin/bash
B:x:1002:1002:b:/home/bbb:/bin/bash

Note that we’ve used the same UIDs for a given user.

If you’ve a lot of users, or an existing setup which you cannot easily change, then pick (and learn about!) one of the many NFS schemes for dealing with this. But if you’ve a small, and/or changeable set up, do yourself a big favour and go with matched UIDs…!

The Clients – Basic NFS

This is where things get fun. Before we dive in to caching, automounting and so on, let’s make sure that basic NFS works OK for us. On a laptop, edit /etc/fstab to be like this:

.
.
.
# NFS
bobby:/C /home/cc/bobby    nfs4     rw,hard,intr    0 0
bobby:/A /home/aa/bobby    nfs4     rw,hard,intr    0 0
bobby:/B /home/bb/bobby    nfs4     rw,hard,intr    0 0

Note:

• bobby is the server name. You could use the raw IP address here, or if DNS is working (or you’ve a static entry ion /etc/hosts) you can use the name.
• Note the server location is only given as “/A”, not “/export/A”. This is a difference between NFS3 and NFS4.
• the mount point on the client is entirely arbitrary, but it makes sense for it to be “under” the particular user’s home directory, as here.

With that done, do a

mount -a

and check that all the three mounts work. Apart from checking via a mount command’s output, also login as each user, go to that user’s NFS-mounted directory, and create a file, edit it, and delete it. Does that all work OK? If so, grand. If not, STOP and get the basic NFS setup working before proceeding! This is really important… Debug basic NFS issues first.

The Clients – Caching

The next layer we are going to introduce is client-side caching.

Again, I’m going to present a highly simplified (and highly effective!) setup, glossing over a vast array of optional complexity and trouble… (If you fancy it, here’s a good starting point for the details: Red Hat Guide to FS-Cache

We’re going to use FS-Cache. Install it using:

apt-get install cachefilesd

All you really need to then change is to edit /etc/default/cachefilesd and set:

RUN=yes

Then start it using:

/etc/init.d/cachefilesd start

Note that you may need to add the mount-attribute user_xattr on the file system containing the cache files (which will typically be the root file system or, if you have /var broken out on a separate partition, then that one) So your /etc/fstab entry might look like this:

UUID=5f63b76a-d367-49e4-a540-d7ab77b891fe /               ext4    errors=remount-ro,user_xattr 0       1

Go back to your /etc/fstab and edit each NFS line to include the option fsc, like this:

.
.
.
# NFS
bobby:/C /home/cc/bobby    nfs4     rw,fsc,hard,intr    0 0
bobby:/A /home/aa/bobby    nfs4     rw,fsc,hard,intr    0 0
bobby:/B /home/bb/bobby    nfs4     rw,fsc,hard,intr    0 0

Then (re)mount the NFS shares and see if it works!

Here’s a good point, if you wish, to test one mount with caching and one without, and run some comparisons in your environment and mode of using it, to see how much (if at all!) caching helps… If you alternatively wish to skip that and just check that “caching is doing doing something so I know it works in some manner or other” then you can just

cat /proc/fs/fscache/stats

and check for signs of any life. See some? Great. Plough on.

The Clients – Automounting

Why not just leave things as they are? Each laptop, when powered up, mounts all the users’ NFS shares? Well, you could. But it’s not ideal.

• Bandwidth and time. Mounting all, when likely only one will be used takes time and bandwidth.
• Concurrency. In theory, and hopefully practice, NFS will handle this. But it’s just so much neater and less contentious (joke intended…) to only mount the share where and when it’s being used. Then it gets dropped when it’s not used.

So unmount the NFS shares in place, and then edit /etc/fstab to comment them out there too. From here on the shares will not be mounted from fstab, but by the automounter.

We need to install automounter first, so do that using:

apt-get install autofs

The autofs documentation, and many of the online resources, are fairly confusing for a newcomer! The automounter is a very flexible piece of software, and has to handle many different situations – hence the complexity. But we can keep it simple…

• First, edit /etc/default/autofs
• Add/uncomment

MOUNT_NFS_DEFAULT_PROTOCOL=4

• In theory, you can leave this and specify we’re using NFSv4 on the mount options – however I had a lot of trouble with this, and given that we’re in a simple all-v4 environment, it’s a lot simpler to just change it here.
• You might want to think of tuning the timeouts here, but don’t feel obliged. Leave everything else as-is.
• Edit /etc/auto.master
• Comment out the last line, and add a new one, like this:

.
.
.
# Commented out next line:
#+auto.master
# My new nfs automount details:
/-	/etc/auto.nfs

• So you comment out the +auto.master and add in the reference to /etc/auto.nfs
• Now create /etc/auto.nfs and make it similar to this:

/home/aa/bobby	-rw,fsc,hard,intr	bobby:/export/A
/home/bb/bobby	-rw,fsc,hard,intr	bobby:/export/B
/home/cc/bobby	-rw,fsc,hard,intr	bobby:/export/C

• Note the /home/aa/bobby line is arbitrary – it is the local mount point and can have any name.
• Note also the fsc parameter, to ensure we use the caching filesystem layer as previously setup.

Conclusion

And that’s about it. With such a configuration, my kids can logon to either laptop, open “their” folder called bobby/ and, hey presto, they have full access to their data on the server, all invisibly assisted by a caching layer.

It’s a little fiddly to set up, but not so confusing if you remember how it breaks down:

• Set up NFS on the server and share out the server locations.
• Set up NFS on the clients and ensure simple mounting works.
• Set up FS-Cache on the clients and check that NFS uses it OK via normal mounting.
• Finally set up automounter on the client to have NFS automagically only mount as and when required.

Addendum 1: Shutdown hangs…

With everything up and running nicely, I noticed one frequent problem with the client machines: they would no longer shutdown (or thus reboot) properly. The shutdown started but usually “hung” before completion. I’m pretty certain it’s a “shutdown job ordering” type of issue, whereby NFS unmounts, turning of caching and killing the wifi are either in the wrong order or maybe just too close in time.. So one may need to tweak the shutdown/reboot kill tasks. Which these days is more of a headache than it used to be “in the good old days” since we have to consider tasks run via SysV rcN.d/ jobs and “upstart” jobs as well…

When I’ve tuned them right, I’ll try and remember to update here. But if you see the shutdown/reboot hanging issue, the solution is in that whole area. Strictly speaking, it’s a Ubuntu distro bug.

EDIT: 17 May. The hang on shutdown/reboot issue is surprisingly difficult to resolve! Looking in to it it seems that autofs and wifi have a long history of not getting along – Ubuntu has a heap of bug reports concerning this issue, over quite a period of time. Yet they seem to not get resolved. For my part, for now I’ve actually stopped using the auto-mounting feature, as it’s just a “nice to have” and far and away the least critical aspect of the above setup. A shame, but not a big shame.

As a parent I do not believe in raising children in some sort of bubble, totally devoid of anything that could possibly “harm” them. That applies to the Internet too – my hope is to raise children who are able to understand and deal with things, rather than require protection from them. To that end, Internet access for my children involves their parents first and foremost! They use a laptop, after asking permission, in the kitchen, in view of everyone else. I’m interested in what they are doing on it (genuinely so, not as some excuse to snoop!) and they want me to help and guide them. Email? Sure, make full use of it. But all emails sent to your address also get forwarded to me too guys… Why? So I can see what you’re receiving! Very open. Very honest. Nothing underhand. Those are the rules in this house.

And that approach actually covers probably 90% of what is required. However there’s still a small part that needs attention. As most adults know, there’s some weird stuff in some corners of the Internet. Really weird. Disturbingly weird. Stuff which I do not want my young children to see, even if accidentally. Being a very liberal sort, and totally anti-censorship with regard to what consenting adults view, I do not support any move to remove such stuff from the Internet. Weird, sick, depraved, whatever… Some of it may not be at all nice, but it’s there and it can be found. I just don’t want young children to accidentally find it. So what is a network engineer father to do…?

Content filtering – 4 approaches

Broadly speaking there are four way of approaching content filtering in the home environment:

• Workstation filtering
• Network filtering
• ISP filtering
• DNS blocking

The first three are all variations on the same theme. They vary in terms of the “Where do you do it?”

Workstation

There are many software packages out there which will filter content locally on the PC being used to browse the web. In a similar manner to that used by the more familiar virus detection software, one can purchase and run content filtering software which aims to identify and block various categories of content. The difficulty faced with this approach is that it’s not at all easy to identify what to block! Just to take the most obvious candidate category for blocking: pornography. The software can, and will, have lists of the names of the popular, known web-sites with porn. And with some enormous proportion of the Internet being porn, that will already be a long long list! Then we have the challenge of the fact that every day goodness knows how many hundreds of new porn sites will appear, and old ones disappear. The list of sites cannot be fully up to date. So the software will also need to include elements of heuristic detection: identifying porn indirectly and blocking it. So we’re now into looking and scanning all the traffic to and fro for words or patterns which might identify it as porn.  And so on. It’s a computationally intensive exercise, and requires frequent updating with new lists of patterns, URLs, IP addresses and so on.

The task is very similar to virus detection, with the frequent updates required, slowing down of communication to an extent, higher CPU usage, and so on.

The software out there is worth consideration for some – I’m not saying it’s a bad approach. But it has unavoidable limitations. Two obvious ones which apply to me are:

• Locked to a particular PC – If I install the software on one PC, then I cannot let the kids use another PC as it will be unprotected, unless I pay for and install the software there too.
• Linux. A big issue for me is that we only have a single Windows PC in the house (hooray!) All the others (too many… way too many…) including that used by the children, run Linux. And such packages are few and far between for Linux…

Home network

An approach I used for a while, with success, was to filter on the gateway device on my network. A quick summary here: at home my Internet connection terminates on a gateway firewall/router system. This system performs all manner of network-related functions. The key one is to run my Linux-based firewall. A host of other jobs get handled by this box too: VPN termination, media serving, DHCP, IPv6 routing, the list is long. Given that all of our Internet traffic traverses this system it is ideally suited to perform a filtering function.

To that end, for a while I ran Dans Guardian on my firewall. This is a sophisticated bit of software, and not entirely trivial to set up and get working. Apart from quite a lot of configuration itself, it also requires a web-proxy to be running on the firewall. I ran squid to fulfil that requirement. And then there’s the requirement to “hook” users into it. That involves either configuring the workstation to use a designated web proxy (and possible authentication required there – depends upon what exactly you want to achieve) or using IPTables on the firewall to intercept traffic from a given workstation and force it via the proxy. Various approaches, all quite interesting, but only if you find networks interesting… Many would find it simply “complicated”.

Once up and running, however, there are then further challenges to be faced. Firstly there’s the question of overhead. That is, how much load does it place on the gateway device, and hence how much delay or slowness does it introduce to the web browsing. My kids may not need the snappiest, lightening fast response times possible, but nor do they want to wait tens of seconds to see a page, or have some You Tube video constantly stop and start. Let me be clear here (and make sure I’m fair to Dans Guardian): if the device running it is powerful (in terms of CPU, memory, disk and so on) then it’s great. Really good. Trouble is, however, that a lot of boxes used as gateway routers/firewalls are not, by their nature, so highly specified. And that applied to me. My installation was, frankly, not fast enough. Much of the time it would work OK-ish, but often there would be very long delays indeed.

If you have a powerful box you can dedicate to such filtering, then do go ahead and consider it.

On other issue I also had to tackle was that of updates: as described for the Workstation solution, filtering software, wherever it is located, needs to be kept up to date. Dans Guardian does not come with an update mechanism, nor source of updates. There are sources of such updates out there if you search, but again, it’s an extra piece of work to do this and get it all set up correctly, auto updating silently every day.  As before, not a criticism of the software that has been made freely available – but something that does need to be taken in to account.

ISP

Many ISPs offer a filtering service to their customers. This is of course attractive, as it entirely removes the need to perform the filtering and blocking locally to the home network. The work is offloaded to the ISP. While there may be a charge associated with this, it may be worth considering. The main, and maybe for many significant, disadvantage to it is the all-or-nothing approach. If you have many PCs (and hence different users) within the home network, you may only want to block certain stuff from certain PCs. I may not want my kids viewing DominatrixFrenchMaids.com, but (purely for research purposes, of course) their father may need to. (God knows, such a site probably exists, but I dare not look…) More realistically, there are other sites which are more genuinely OK for adults, but not for young children. If one has an interest in 20th Century history, a sad reflection on humankind is that there are some horrible things which can be seen… For older children and adults, that’s fine and indeed educational. But not below a certain age. I’d like to maintain the illusion of a nice world for at least a little while longer.

So ISP filtering is attractive in terms of removing the work from the home. But it does come, in general, with a certain amount of inflexibility.

DNS blocking

This last technique is somewhat different from the others. Most people have at least some awareness that the names we use on the Internet (www.ipsidixit.net) actually map on to so-called IP addresses. For example www.ipsidixit.net is mapped via a DNS (Domain Name Service) to the IP address 217.70.191.54 (And to IPv6 2001:4b98:dc0:41:216:3eff:feaa:964a – I’m soooo hip and trendy…)

Yet no one in their right mind (nor even a network engineer) bothers with the numerical version. You just bang in the name and have your computer us DNS to resolve it to an IP address.

Most PCs will use one or more DNS devices specified and operated by their ISP. Used “normally, for example, my ISP (free.fr) provides two DNS systems for workstations to use.

However one does not need to use their suggestions. One can, in general, use other DNSs operated by third-parties.

The point is, then, that if one used a DNS service which had a constantly updated blacklist of sites which are “undesirable”, one could block access to them by simply declining to resolve them to their correct address. This then offers the benefits of ISP Blocking in so far as the load of shifted outside of the home network, but with the added flexibility that only workstations that require protection need use the “filtering” DNS. Other workstations can use the normal DNS.

I found that OpenDNS provide such a service, and have stated to make use of it. It’s free (they have some paid options too – but the free one seems fine for me) I have no association with OpenDNS, and am only “promoting” them as what they offer seems neat and useful. If others have knowledge of other similar services, please do post them in a comment – I’m not trying to make this exclusive to OpenDNS! In fact I’d like to compare OpenDNS to some others.

The service they offer is to provide DNS addresses which can have a selectable level of filtering applied. The spectrum is covered, from porn, violence, drug use, etc. through to shopping sites, social networking sites, etc. You get to choose which categories to block and which to allow.

And it does seem to work really rather well indeed. Below I am going to detail how I set it up within my network, integrating it within the DNS caching system already used.

The main weakness of the system is that with some knowledge and effort it can be circumvented (as, of course, can most systems) One could take the trouble to manually find the Name <–> IP mapping for a domain and enter that directly into a browser, thereby bypassing the DNS. However such a bypass would be very cumbersome to use, since even if you use an IP to land on a page, probably any link off that page will in turn require DNS, and would then need to be manually decoded, etc. Workable, but hard work. By the time my kids are knowledgeable enough to work all that out, they will probably be old enough to look after themselves!

Integrating OpenDNS into a Linux firewall, already running DNSMasq

My home network has DNSMasq running on a central gateway/server/firewall box. DNSMasq is responsible for DHCP (i.e. allocating IP addresses on my home network) and also DNS caching. To that end, it announces, via DHCP, that it  is the DHCP server to be used by devices. Then it, in turn, resolves addresses via the ISP-supplied DNSs. It caches then DNS lookups locally.

In the DHCP configuration it has a pool of addresses available for any device to use, but most of the devices on the network have pre-allocated addressees reserved for them within the DNSMasq configuration. These are allocated based upon the Ethernet MAC address of a device. This is a very common technique to use with DHCP.

Given that, where now a device will be handed an IP address and the address of a DNS server to use (where that DNS server will actually be the same as the DNSMasq device itself) we want to change the config so that for certain devices (the childrens’ PC) when an IP address is handed out it will instead be given with the DNS addresses of the OpenDNS filtering systems. Then all DNS requests from that PC will no longer be locally forwarded to the gateway device, but will instead be routed out externally to OpenDNS, where they can be answered or blocked as appropriate.

The DNSMasq config to achieve this is slightly fiddly, so I am providing it here more or less in its entirety (a few names omitted and some light obfuscation of MACs etc.), but only highlighting the parts that particularly pertain to the OpenDNS filtering setup.

# Configuration file for dnsmasq.
domain-needed
resolv-file=/etc/resolv.conf
no-resolv
no-poll

# Add other name servers here, with domain specs if they are for
# non-public domains.
server=/localnet/192.168.0.22

This part is not related to OpenDNS in any way: I don't use my ISP's DNS for normal use - I instead use Google's Public DNS.
# Google Public DNS servers
server=8.8.8.8
server=8.8.4.4

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.
local=/localnet/

interface=eth1
expand-hosts
domain=localnet

# For general purpose use, use this range.
dhcp-range=192.168.0.128,192.168.0.160,12h

This is for OpenDNS. We use the dhcp-mac config to tag these special devices for filtering:
# MAC list for openDNS filtering
dhcp-mac=opendns,00:c0:9f:12:34:56	# Laptop on-board
dhcp-mac=opendns,00:90:4b:12:34:56	# Laptop wifi

Here we're back for normal dhcp-host preallocation for known unfiltered devices:
# Most ip addresses are pre-allocated here
dhcp-host=00:50:ba:12:34:56,aname,192.168.0.2,720m
dhcp-host=00:18:8B:12:34:56,anothername,192.168.0.3,5m
dhcp-host=00:90:4b:12:34:56,laptop_wifi,192.168.0.4,720m
dhcp-host=00:26:37:12:34:56,galaxy,192.168.0.5,60m
dhcp-host=00:18:41:12:34:56,magic,192.168.0.6,60m
dhcp-host=00:26:82:12:34:56,eva9150,192.168.0.7,720m
dhcp-host=00:c0:9f:12:34:56,laptop_eth,192.168.0.8,720m
dhcp-host=00:14:29:12:34:56,camera,192.168.0.10,120m
dhcp-host=00:21:5A:12:34:56,printer,192.168.0.11,720m
dhcp-host=00:40:63:12:34:56,aservername,192.168.0.22,infinitem

The devices tagged "opendns" above here get special DHCP options pointing them to the OpenDNS filtering-servers.
# OpenDNS content filtering servers
# Specify the two OpenDNS first, then ourselves third for local stuff
dhcp-option=opendns,6,208.67.222.222,208.67.220.220,192.168.0.22

Note also the "192.169.0.22" on the end - this is optional, if you still want the filtered devices to be able to resolve local names.

dhcp-authoritative
cache-size=150
clear-on-reload

Anyone who has an existing DNSMasq configuration should find the above more than enough to change it to point arbitrary devices at the OpenDNS systems.

Summary

Nothing, but nothing, replaces a conscientious adult supervising, guiding and helping get to grips with the Internet. However even with that it’s still all too easy for some stuff to pop up which is better left hidden! This article highlight some of the general technical approaches one can take, and in particular that of DNS filtering with a service such as OpenDNS, optionally using a Linux device to semi-automatically allocate filtering to some device but not others.

Not self-build?

I wanted a device with similar functionality, to play my large collection of videos stored on a server and also allow occasional photo browsing. I didn’t have many hard and fast requirements, but as far as they went they were:

• support a wide range of media formats, particularly DivX variants and MKV hi-def.
• support a wide range of output (today we still have a large but rather old normal-def TV – I am sure in the lifetime of a new device our TV will get replaced with something HDMI-ish)
• smart networking: my house is a mixture of Ethernet-over-power and wi-fi, with little cabled Ethernet)
• Open. Very important. No proprietary crap, either in terms of what it can play or what I am allowed to do with it.

Given this and my propensity for building my own kit, a self-build seemed like an obvious idea. I toyed with the obvious mini-ITX options, with appropriately funky video cards and one of the Linux TV-based distros. But when I did a rough calculation of both the cost and the work required I couldn’t help but check if there was anything ready-built which would also do the job. I didn’t expect to find anything, to be honest. It was almost a “Due Diligence” exercise which I had to perform so that when I then spent day after day getting my self-build working OK I could mentally justify the effort. However the formality of proving there was nothing which met my needs turned out to have a surprise ending.

Netgear EVA9150

To cut a long story short, I came across the Netgear EVA 9150. Lovely device. Absolutely spot on. And no, I have no affiliation with Netgear! I paid € 270 of my hard-earned cash for it. I’ll not run through the spec (you can get that here) but will mention some key features it has which make it rather special and ideal for my requirements.

Server support

Go back to the recent past and devices such as the Pinnacle Showcenter used a web-based client-server architecture. The mediaplayer was, for many purposes, a web-client. It obtained metadata, menus, etc. from the server which had to run either proprietary software or, thanks to some open-source projects, a web server. Either way, you had to run “special” software on the media server. Then, to actually play something, the mediaplayer would initiate a web-streaming transfer of the data. Given the limited buffering capability available this meant that the server and network had to, more or less, deliver the required bit-rate in real-time. Any variations (due to a server hit or a network glitch) would result in degraded or completely stopped video playback.

The EVA9150, as I gather with many of the newer generation of mediaplayers, has a quite different architecture. They are actually simpler. The player itself is now much smarter and so demands correspondingly less smarts of the server. All the server has to be is what it already is: a network file server. The mediaplayer runs a local operating system (Linux in the case of the EVA9150) and just scans the server and, when required, copies stuff across. See below where I talk about caching for what this means in practice…

The version of firmware that came installed on my EVA9150 only supported Samba (i.e. Windows) shared file systems from the server. However the EVA9150 software seems to be under pretty active development, and a newer version (easy install: USB key in the front panel) now provides NFS support too. Since I run a Linux-based file server, this is great.

Networking

It has the almost obligatory 10/100 wired Ethernet port. I’m currently using that into a Ethernet-over-power adapter. The box also has built-in (and it really is built-in: the antennae are completely hidden inside the casing) 802.11a/b/g/n. That last one is interesting: nominal 300Mbps, 5GHz band, wi-fi. I’ve not tested it yet, but it could be useful in the future.

Caching

Ahhhh. This is, for me anyway, the killer feature. My home network works OK most of the time. Like most home networks, it will occasionally hiccup. And during a 2 hour movie even the occasional hiccup or two can become madly apparent when one is streaming in near-real time. Here the EVA9150 does something so simple. It’s not at all unique, it’s just done so well and transparently. It caches to the local 500GB disk. So you start a 2 hour movie and, probably within a few minutes of the start, it’s cached the whole thing successfully to the local disk. Network glitches be dammed. Simple. Perfect. Me like.

Media formats supported

The independent reviews of the EVA9150 make this point pretty strongly: try and find something, anything, it can’t play. OK, I best they exist. But it does everything I’ve chucked at it. I’ve got the output connected to a low-def standard TV. I start playing a hi-def Matroska file. Apart from the fact that is support MKV in the first place, I don’t get any crap about “this is hi-def, the output is not” etc. It just PLAYS IT, and down-specs (or, apparently, up-specs under other conditions) as required.

Physical support

There’s a plug on the back for anything I’ve ever heard about. From SCART up to HDMI, with loads in between.

Value for money?

All in all, it’s a very good mediaplayer. Not cheap, but if I’d built a box with the same spec myself, quite apart from my time, I don’t think the parts would have come to less than the €270 I paid anyway.