Last week we almost wrapped up our discussion of the Snap Server 2200 from Snap Appliance Inc. but were left with what looked like a bug. And indeed it was, as far as can be determined, a “you’re kidding me, are you sure? wha’ the? never seen it before” kind of thing that has not happened since. Why is it we always get these weird things happening in the Gearhead Underground Highly Secret Bunker?
Anyway, we stick with our assessment of the Snap Server 2200 as a good workgroup-level storage appliance. We’d go so far as to boost that to “excellent.”
Oh, but don’t expect to be thrilled with the bundled Windows back-up software called DataKeeper that comes with the Snap Server. It works, but it is odd. For example, you can’t browse your network neighbourhood for a back-up destination, even though you can specify a network server and subdirectory by typing the full Universal Naming Convention path.
DataKeeper also has a horrible mechanism that enumerates all the files it is supposed to back up, and reports them as errors if you tell it to stop a backup before it finishes. If you do this and the backup involves, say, 10,000 or more files, you might want to consider going for coffee, a massage and a haircut while it finishes. Or just kill it off with the task manager, which is faster but ugly, ugly, ugly.
That said, the product does do continuous real-time backups and is smart enough to perform a backup to local storage if the network storage is unavailable and then synchronize when it does become available.
So what have we learned from this and the other storage servers we’ve looked at? To begin with, if you are going to use one to support a remote workgroup you absolutely need a Web interface like the Snap Server’s.
But you absolutely must hide the storage server behind a firewall unless the server supports Secure Sockets Layer (SSL) or Transport Layer Security. Otherwise, don’t even think of providing access by forwarding Port 80 from the firewall – it isn’t a safe architecture because any weakness in the server could be exploited and a wily hacker could “listen in” to discover your server access name and password.
There are a couple of solutions. First, you could use a firewall that supports VPN links. Or you could use your Web browser to make an HTTPS (HTTP with SSL) connection (which defaults to Port 443) to an HTTP proxy that can speak and terminate SSL. In other words the connection from the browser through the firewall to the proxy is HTTPS, while from the proxy to the server everything is HTTP. This lets you defend your communications right through the firewall and change to an unsecured connection where it is safe to do so.
A proxy server that you might want to check out for this kind of configuration is Http Bridge, an open source proxy released under the Massachusetts Institute of Technology license.
Http Bridge is written in Java and requires the Tomcat Java servlet container. Note that this combination – Http Bridge and Tomcat – can be run on Windows, Linux or pretty much any platform that supports Java.
That wraps it up for the Snap Server 2200, but before we head off we’d like to note some comments from reader Doug Porter regarding our recent columns on Samba. He points out that: 1) You only need WINS for Windows 98 and 95 clients that connect to existing resources within the Windows NT environment; 2) Win 98 machines can use DNS and Active Directory “lookups” to replace the functionality WINS provides; and 3) Windows 2000 training materials indicate that Windows clients running 2000, XP or later no longer use WINS, but rather, DNS.
Yep, Doug, this is the usual mess that makes companies throw up their hands and upgrade just to try to stay out of trouble. It never quite keeps you out of trouble, but it won’t get you fired.
Points to gearhead@gibbs.com.