SheevaPlug: a Tiny Computer for $99

This computer introduced by Marvell is very tiny, and very interesting.  Despite the fact that Marvell’s wireless chipset has been closed to open source developers, it appears that the Sheeva Plug computer is being released as an open product: running Linux on an ARM processor, it is now available for $99 as a pre-release developer’s edition. There is already a place for developers to congregate and for documentation and so forth.

LinuxDevices had a delightful article on the technical aspects of the SheevaPlug, and it is very enlightening.

What would I use such a computer for?  I would quite possibly make it into a NAS solution with OpenFiler or FreeNAS; make it serve IP addresses via DHCP; make it into a web cache like squid; or make it serve music with subsonic.

This is one beautiful box.  One drawback I see is that with the way it is configured, there is no way to get it off the wall and out of the way.  Too many boxes plug right into the wall, which means there is no place for another box to plug in.

Another deficiency, which is silently ignored in a lot of applications shown: there is only one network connection. For the system to be a router of any type, it needs to have multiple network connections. If a SheevaPlug is to be a wireless router – or a cellular router – or other similar configurations, it needs to have more than one network connection. With the USB connection available, this is possible – but only if the USB isn’t taken with something else.

One nuisance to note, like others of its ilk: it requires added peripherals, so the “tiny” box could expand to include an external hard drive, and external USB hub with its own AC plug, a bluetooth USB plug, a USB cellular modem, a USB network port, and two network cables. This is the curse of tiny electronics today: one day, all of these extras will be included in a box the same size, and the cabling will be history.

One disadvantage that no one seems to have mentioned yet: the box is not grounded.  That’s right: only two prongs – no grounding plug.  This is totally baffling to me: no ground?

Still, these are really minor disadvantages: I want one – or even two!

It would be interesting to consider the use of these in the enterprise (although they are specifically designed for the home). The biggest places I could see these used in the enterprise would be for testing purposes, and for disaster recovery. If you had one of these ready as a DHCP server and DNS server, one as a NIS server – perhaps a medium-sized enterprise could run off of these until the real servers are built and ready to go.

They could also be used to support people in the field: preconfigured, ready to run: demonstration systems, VPN end points, presentation systems, security test launching points… What else can you think of?

Powered by ScribeFire.

The Dark Side of Cloud Computing

If you have information in “the cloud” instead of on your personal computer, there is a dark side that you should be aware of.

The information that you save to the cloud resides on servers elsewhere, such as California or Korea or Canada. Wherever those servers reside, there are laws that govern them and the corporation that controls them. These laws may permit access to that information that is much looser than where you are.

Even within the United States, there is a big difference between the data stored on your personal computer or laptop and the information stored on external servers. The United States government must get a warrant signed by a judge before searching your home (and home computer); however, a warrant is not necessary to get a corporation such as an Internet Service Provider (ISP) or others to give the police your data. Companies such as Google and others can be forced to give the police data without notifying you.

This data is not just on the servers, but can also be found on backup tapes as well. Some services – either by their nature or by design – will keep multiple versions of your data, so all past versions can be scanned.

Cloud computing can be brought in-house to some extent, most notably by using open source projects such as eyeOS (which provides a remote desktop). If you are truly concerned by leaving your data open, do not use unsecured network protocols, and do not set up a server with a hosting service: you must run your own server internally.

Other services will provide a key which encrypts the data on their servers – such that the hosting service cannot read any of your data. These are the best services to use, although they may be harder to find. The most likely cloud computing services to do this are backup services as well as those specializing in privacy.

For example, SpiderOak keeps all data on their servers encrypted – so even they can’t read it. Mozy appears to offer the same capability.

Password storage sites also have security built-in; both Clipperz and PassPack have encrypted all of the data on their servers, preventing anyone from reading your data.

However, Google Docs, Zoho, and Thinkfree Office all appear to keep data on their servers readable by anybody – thus, your data could be subponeaed by a court of law if necessary.

It’s unlikely that any of the “micro” services would offer encryption of your data – services like del.icio.us or Joe’s Goals or Zotero.

There is also the possibility of losing all of your data due to a site shutting down. Some sites, polished though they may be, are run by individuals or tiny companies; thus one should not rely on cloud computing alone. Backups should be replicated internally – including backups of all data stored externally.

One good example of this would be the service Magnolia – the service suffered a total data loss stemming from a disaster that took place in February.

Thus, like RAID, cloud computing alone is not a backup!

Backup in depth

In security circles, there is often talk about “defense in depth.” This refers to the fact that a security system is not relying on a single element to accomplish its goal; the “defense in depth” strategy is a form of remove a single point of failure from security mechanisms. That is, if one element in the security infrastructure goes down (such as firewall collapse) other elements will be waiting to prevent an attacker from entering further.

Backup in depth (my term) is similar. In one environment I was priviledged to be in, the database administrator and I worked out a backup plan like this: each database would be backed up on the machine itself (backup #1); this backup would be saved to a location on a central server for up to 30 days (backup #2); and both the database servers and the central repository would be backed up to tape daily (backups #3 and #4). In at least one case, having the database backup on the local disk saved the database administrator from a long drawn out restore from tape.

When you are backing up your own personal data, this is also a good procedure to follow. Don’t rely just on tape or a remote site. Backup your data in several ways and in several locations (varying by ease of access and completeness of backup).

One could, for example, save your home directory to SpiderOak (the remote backup facility I mentioned earlier) and a copy to an external USB drive. SpiderOak thus provides the space and deep history, and the external drive provides immediate and fast restores that are not dependent on the Internet.

Virtual environments provide an inherint ability to create a “backup in depth” – the host can be backed up (including the virtual environments) and the virtual environments can do a standard backup.

With multiple backups in place, restoring a file should not be a problem in most cases – or restoring entire directories or systems. Isn’t that worth taking some time to accomplish on your personal machines?

RAID is not a backup!

This post describes the authors experience, almost losing his data on a RAID disk set. He also gives good details on why RAID is not a backup and how he rectified the situation. Remember: RAID is not a backup!

When working with corporate systems, a complete, reliable, and tested backup system is important. RAID does not protect you against many (or even most) disasters that could happen.

RAID is designed to protect against one thing: disk failure. It does not protect against user error, operator error, site destruction, and many more possibilities.

So how do I back things up? I must admit, I’ve improved my backup strategies of late. I currently have several tools that I use and would recommend to you:

• SpiderOak. This is an online backup service which offers the first 2Gb backup free. They also maintain multiple version backup, so if you want a file from two versions back, it’ll still be there. This service is worth paying for, I’d say.
• For my Mac, I’ve used PsyncX periodically (albeit not automated). It has come in handy more than once as my laptop died several times – I’ve one of those iBooks that was notorious for video hardware that failed annually (and Apple would fix for free, but never admitted fault). If you’ve a Mac, get an external drive and use PsyncX to save your home directory off. Also recommended: put your applications in your home directory, not the system directory: restoring your home directory will then be enough to get your applications back.
• For UNIX, the similar alternative to PsyncX is rsync: again, get an external drive and save your home directory off to it regularly.
• Also, come at it from the other direction: save your configuration by putting it into a cfengine or puppet setup and saving that as well. If the machine fails, running cfengine or puppet on startup will restore the system to its original state.
• One other item – that may seem a bit unusual – is using Thinkfree Office. Thinkfree Office gives you a way to save documents locally and have them mirrored in the Internet cloud – and you can also manipulate your documents on the web as well. Of course, this is only entirely true for documents that Thinkfree Office can edit.

It would seem that cfengine v3 is now available for download – that will have to be a subject for a new article.

Pull files out of a Ignite-UX recovery archive

Perhaps you have a regular backup utilizing make_net_recovery, and want to get some files out of it. How is this done? The standard way to utilize a Ignite-UX backup is to restore the machine completely, using Ignite-UX.

However, if just one file – or a series of files – is desired, log into the Ignite server. Change to the directory /var/opt/ignite/recovery/archives and then into the directory matching the host you want to restore files to. The files in these directories are gzipped archives of the sort that you specified when you did the make_net_recovery (tar files by default). The file names are of the format YYYY-MM-DD,HH:MM.

Use your favorite tools to extract the files from the desired archive. For example, the following will extract the /stand directory (where HP-UX keeps its kernels):

gunzip -c 2009-01-24,07:05 | tar xvf - stand

The actual configuration of the archive process is kept in a different directory in /var/opt/ignite/clients followed by the host name. Most of these files should not be changed, as it would be easy to mangle the backup (or restore) process by making a bad change to one of these files.

JournalSpace Dies by Data Loss

The blogging site JournalSpace has been shut down after there was significant data loss without backups. The entrepeneur’s blog has more information – apparently, the most likely cause seems to be sabotage by a former IT staff person, combined with the lack of working backups.

What can we learn from this unfortunate incident? There are a number of things to note here:

• Remove all access for former staff in its entirety – don’t skimp! All access, passwords, server access, everything. Lock it down. If you have only one IT staffer, you are also at risk: you need to be able to call on someone who can lock out your fired (or laid off) employee completely.
• Disk RAID is not a backup solution. RAID protects you from disk failure, not from “data failure” or operator mistakes. Do not forget to have a complete backup solution in place. It also pays to enable a “hot spare” so that if one of the disks fail, that there is still protection from disk loss.
• Have a backup solution. You must have a comprehensive backup plan working, tested, and implemented.
• Have a working backup solution. This point cannot be stressed enough: Test your backup solution before you need to use it! When the data is gone is no time to realize that the backups are useless. Test your backups in real-world scenarios as well: one story described a backup solution that was well-tested, then the tapes went off-site in the operator’s car. Unfortunately, sitting in the car caused the tapes to be demagnetized and this was realized only after the data was gone. Test those backups!

The dreadful story of JournalSpace might have had a different ending if they had only tested their backups: that alone would have saved them. However, solutions (like security) should be in depth: working backups might not be enough next time.

UNIX Filesystems: Understanding Alternate Superblocks

This article by the learned Hal Pomeranz is very educational and may be just the thing you need for recovery one day.

Read this article! It may just satisfy your craving for expanding your mind for the day…

Automation: Live and Breathe It!

Automation should be second nature to a system administrator. I have a maxim that I try to live by: “If I can tell someone how to do it, I can tell a computer how to do it.” I put this into practice by automating everything I can.

Why is this so important? If you craft every machine by hand, then you wind up with a number of problems (or possible problems):

• Each machine is independently configured, and each machine is different. No two machines will be alike – which means instead of one machine replicated one hundred times, you’ll have one hundred different machines.
• Problems that exist on a machine may or may not exist on another – and may or may not get fixed when found. If machine alpha has a problem, how do you know that machine beta or machine charlie don’t have the same problem? How do you know the problem is fixed on all machines? You don’t.
• How do you know all required software is present? You don’t. It might be present on machine alpha, but not machine delta.
• How do you know all software is up to date and at the same revision? You don’t. If machine alpha and machine delta both have a particular software, maybe it is the same one and maybe not.
• How do you know if you’ve configured two machines in the same way? Maybe you missed a particular configuration requirement – which will only show up later as a problem or service outage.
• If you have to recover any given machine, how do you know it will be recovered to the same configuration? Often, the configuration may or may not be backed up – so then it has to be recreated. Are the same packages installed? The same set of software? The same patches?

To avoid these problems and more, automation should be a part of every system wherever possible. Automate the configuration – setup – reconfiguration – backups – and so forth. Don’t miss anything – and if you did, add the automation as soon as you know about it.

Things like Perl, TCL, Lua, and Ruby are all good for this.

Other tools that help tremendously in this area are automatic installation tools: Red Hat Kickstart (as well as Spacewalk), Solaris Jumpstart, HP’s Ignite-UX, and OpenSUSE Autoyast. These systems can, if configured properly, automatically install a machine unattended.

When combined with a tool like cfengine or puppet, these automatic installations can be nearly complete – from turning the system on for the very first time to full operation without operator intervention. This automated install not only improves reliability, but can free up hours of your time.

Laptop “Disaster Recovery”

Over at the Productivity501 blog, there is a good article about laptop contigency planning. It is a must read. Go read it!

I’d like to take this one step further. Here in Wisconsin, we are having one back-breaker of a snowstorm (one and a half days so far). Closings everywhere – and people are looking to use the corporate VPN to work from home.

Here are some things to do to prepare for this ahead of time:

• Make sure your certificate is current. You don’t want to find out your certificate is expired when you are desperately trying to get in.
• Have you tried the VPN already? Does it work? When you are buried in snow and can’t reach the help desk is not the time to find out your software doesn’t work.
• Try accessing everything you need to use. Is it responsive? Does it work? What are the quirks? If it’s slow, you can plan a backup strategy; if it’s not slow, you’ll know it’s not your machine when the VPN slows to a crawl.
• Try accessing the VPN from where you would be when the snow flies (or wherever you would be when disaster strikes). Some ISPs have restrictive policies that will prevent your laptop from working if you are visiting someone. Try it first and find out how to solve any problems ahead of time.
• Do you have your laptop with you? It won’t do you any good if you are caught without it when you need it. Do you have charging cords? Network cables? Wireless cards? Cellular phone modems? And test the connections!
• Create backup plans. For all your careful planning, your laptop and Internet connection have gone south. Now what? Most likely, you’ll need phone numbers of your boss and coworkers, pager numbers, and other such things.

With this wintery weather upon us, it will be very important to be ready if you have to do your admin work from home (or on the road).