Technological Musings

What a title, eh?  Well, that little title up there may impact how you use the Internet in the future..  H.R. 5994, known as the "Internet Freedom and Non-Discrimination Act of 2008," is the latest attempt by the US Congress to get a handle on Internet access.  In short, this is another play in the Net Neutrality battle.  I'm no lawyer, but it seems that this is a pretty straightforward document.

H.R. 5994 is intended to be an extension of the Clayton Anti-Trust Act of 1914.  It is intended to "promote competition, to facilitate trade, and to ensure competitive and nondiscriminatory access to the Internet."  The main theme, as I see it, is that providers can't discriminate against content providers.  In other words, if they prioritize web traffic on the network, then all web traffic, regardless of origin, should be prioritized.

At first glance, this seems to be a positive thing, however there may be a few loopholes.  For instance, take a look the following from Section 28(a):

"(3)(A) to block, to impair, to discriminate against, or to interfere with the ability of any person to use a broadband network service to access, to use, to send, to receive, or to offer lawful content, applications or services over the Internet;"

From the looks of it, it sounds like you can't prevent known "bad users" from getting an account, provided they are using the account for legal purposes.  As an example, you couldn't prevent a known spammer from getting an account, provided, of course, that they obey the CAN-SPAM Act.

And what about blocklists?  Spam blocklists are almost a necessity for mail servers these days, otherwise you have to process every single mail that comes in.  3(A) specifically dictates that you can't block lawful content...  Unfortunately, it's not always possible to determine if the mail is lawful until it's processed.  So this may turn into a loophole for spammers.

The act goes on with the following:

"(4) to prohibit a user from attaching or using a device on the provider's network that does not physically damage or materially degrade other users' utilization of the network;"

This one is kind of scary because it does not dictate the type of device, or put any limitations on the capabilities of the device, provided it "does not physically damage or materially degrade other users' utilization of the network."  So does that mean I can use any type of DSL or Cable modem that I choose?  Am I considered to be damaging the network if I use a device that doesn't allow the provider local access?  Seems to me that quite a few providers wouldn't be happy with this particular clause...

Here's the real meat of the Net Neutrality argument, though.  Section 28(b) states this:

"(b) If a broadband network provider prioritizes or offers enhanced quality of service to data of a particular type, it must prioritize or offer enhanced quality of service to all data of that type (regardless of the origin or ownership of such data) without imposing a surcharge or other consideration for such prioritization or enhanced quality of service."

Wham!  Take that!  Basically, you can't prioritize your own traffic at the expense of others.  So a local provider who offers a VoIP service can't prioritize their own and not prioritize (or block) Skype, Vonage, or others.  But, there's a problem here..  Does the service have to use established standards to be prioritized?  For instance, Skype uses a proprietary VoIP model.  So does that mean that providers do not have to prioritize it?

Providers do, however, get some rights as well.  For instance, Section 28 (c) specifically states:

`(c) Nothing in this section shall be construed to prevent a broadband network provider from taking reasonable and nondiscriminatory measures--

`(1) to manage the functioning of its network, on a systemwide basis, provided that any such management function does not result in discrimination between content, applications, or services offered by the provider and unaffiliated provider;

`(2) to give priority to emergency communications;

`(3) to prevent a violation of a Federal or State law, or to comply with an order of a court to enforce such law;

`(4) to offer consumer protection services (such as parental controls), provided that a user may refuse or disable such services;

`(5) to offer special promotional pricing or other marketing initiatives; or

`(6) to prioritize or offer enhanced quality of service to all data of a particular type (regardless of the origin or ownership of such data) without imposing a surcharge or other consideration for such prioritization or quality of service.

So providers are allowed to protect the network, protect consumers, and still make a profit.  Of course, assuming this becomes law, only time will tell what the courts will allow a provider to consider "protection" to be...

It looks like this is, at the very least, a good start to tackling this issue.  That is, if you believe that the government should be involved with this.  At the same time, this doesn't appear to be something most providers would be interested in.  From a consumer standpoint, I want to be able to get the content I want without being blocked because it comes from Google and not Yahoo, who the provider has an agreement with.  Since most consumers are in an area with only one or two providers, this can be a good thing, though.  It prevents a monopoly-type situation where the consumer has no choice but to take the less-than-desirable deal.

This is one of those areas where there may be no solution.  While I side with the providers in that they should be able to manage their network as they see fit, I can definitely see how something needs to be done to ensure that providers don't take unfair advantage.  Should this become law, I think it will be a win for content providers rather than Internet providers and consumers.

As we become a more technologically evolved society, our reliance on data increases.  E-Mail, web access, electronic documents, bank accounts, you name it.  The loss of any one of these can have devastating consequences, from loss of productivity, to loss of home, health, or even, in extreme cases, life.

Unfortunately, I get to experience this first hand.  At the beginning of the week, there was a failure on the shared system I access at work.  Initially it seemed this was merely a permissions issue, we had just lost access to the files for a short time.  However, as time passed, we learned that the reality of the situation was much worse.

Like most companies, we rely heavily on shared drive access for collaboration and storage.  Of course, this means that the majority of our daily work exists on those shared drives, making them pretty important.  Someone noticed this at some point and decided that it was a really good idea to back them up on a regular basis.  Awesome, so we're covered, right?  Well, yeah..  sort of, but not really.

Backups are a wonderful invention.  They ensure that you don't lose any data in the event of a critical failure.  Or, at the very least, they minimize the amount of data you lose..  Backups don't run on a constant basis, so there's always some lag time in there...  But, regardless, they do keep fairly up-to-date records of what was on the drive.

To make matters even better, we have a procedure for backups which includes keeping them off-site.  Off-site storage ensures that we have backups in the event of something like a fire or a flood.  This usually means there's a bit of time between a failure and a restore because someone has to go get those backups, but that's ok, it's all in the name of disaster recovery.

So here we are with a physical drive failure on our shared drive.  Well, that's not so bad, you'd think, it's a RAID array, right?  Well, no.  Apparently not.  Why don't we use RAID arrays?  Not a clue, but it doesn't much matter right now, all my work from that past year is inaccessible.  What am I supposed to do for today?

No big deal, I'll work on some little projects that don't need shared drive access, and they'll fix the drive and restore our files.  Should only take a few hours, it'll be finished by tomorrow.  Boy, was I wrong...

Tomorrow comes and goes, as does the next day, and the next.  Little details leak out as time goes on.  First we have a snafu with the wrong backup tapes being retrieved.  Easily fixed, they go get the correct ones.  Next, we receive reports of intermittent corruption of files, but it's nothing to worry about, it's only a few files here and there.  Of course, we still have no access to anything, so we can't verify any of these reports.  Finally, they determine that the access permissions were corrupted and they need to fix them.  Once completed, we re-gain access to our files.

A full work week passes before we finally have drive access back.  Things should go back to normal now, we'll just get on with our day-to-day business.  *click*  Hrm..  Can't open the file, it's corrupt.  Oh well, I'll just have to re-write that one..  It's ok though, the corruption was limited.  *click*  That's interesting..  all the files in this directory are missing..  Maybe they forgot to restore that directory..  I'll have to let them know...  *click*  Another corrupt file...  Man, my work is piling up...

Dozens of clicks later, the full reality hits me...  I have lost hundred of hours of work.  Poof, gone.  Maybe, just maybe, they can do something to restore it, but I don't hold much hope...  How could something like this happen?  How could I just lose all of that work?  We had backups!  We stored them off-site!

So, let this be a lesson to you.  Backups are not the perfect solution.  I don't know all the details, but I can guess what happened.  Tape backup is pretty reliable, I've used it myself for years.  I've since graduated to hard drive backup, but I still use tapes as a secondary backup solution.  There are problems with tape, though.  Tapes tend to stretch over time, ruining the tape and making them unreliable.  Granted, they do last a while, but it can be difficult to determine when a tape has gone bad.  Couple that with a lack of RAID on the server and you have a recipe for disaster.

In addition to all of this, I would be willing to bet that they did not test backups on a regular basis.  Random checks of data from backups is an integral part of the backup process.  Sure, it seems pointless now, but imagine how pointless it'll be after hours of restoring files, you find that they're all corrupt.  Random checks aren't so bad when you think of it that way...

So I've lost a ton of data, and a ton of time.  Sometimes, life just sucks.  Moving forward, I'll make my own personal backup of files I deem important, and I'll check them on a regular basis too...

Server downtime is the scourge of all administrators, sometimes to the extent of bypassing necessary security upgrades, all in the name of keeping machines online.  Thanks to an MIT graduate student, Jeffery Brian Arnold, keeping a machine online, and up to date with security patches, may be easier than ever.

Ksplice, as the project is called, is a small executable that allows an administrator the ability to patch security holes in the Linux kernel, without rebooting the system.  According to the Ksplice website :

"Ksplice allows system administrators to apply security patches to the Linux kernel without having to reboot. Ksplice takes as input a source code change in unified diff format and the kernel source code to be patched, and it applies the patch to the corresponding running kernel. The running kernel does not need to have been prepared in advance in any way."

Of course, Ksplice is not a perfect silver bullet, some patches cannot be applied using Ksplice.  Specifically, any patch that require "semantic changes to data structures" cannot be applied to the running kernel.  A semantic change is a change "that would require existing instances of kernel data structures to be transformed."

But that doesn't mean that Ksplice isn't useful.  Jeffery looked at 32 months of kernel security patches and found that 84% of them could be applied using Ksplice.  That's sure to increase the uptime.

I have to wonder, though, what is so important that you need that much uptime.  Sure, it's nice to have the system run all the time, but if you have something that is absolutely mission critical, that must run 24x7, regardless, won't you have a backup or two?  Besides which, you generally want to test patches before applying them to such sensitive systems.

There are, of course, other uses for this technology.  As noted on the Ksplice website, you can also use Ksplice to "add debugging code to the kernel or to make any other code changes that do not modify data structure semantics."  Jeffery has posted a paper detailing how the technology works.

Pretty neat technology.  I wonder if this will lead to zero downtime kernel updates direct from Linux vendors.  As it is now, you'll need to locate and manually apply kernel patches using this tool.

Web-based exploits are pretty common nowadays.  It's almost daily that we heard of sites being compromised one way or another.  Today, it's IIS servers.  IIS is basically a web-server platform developed by Microsoft.  It runs on Windows-based servers and generally serves ASP, or Active Server Pages, dynamic content similar to that of PHP or Ruby.  There is some speculation that this is related to a recent security advisory from Microsoft, but this has not been confirmed.

Several popular blogs, including one on the Washington Post, have posted information describing the situation.  There is a bit of confusion, however, as to what exactly the attack it.  It appears that the IIS servers were infected by using the aforementioned vulnerability.  Other web servers are being infected using SQL injection attacks.  So it looks like there are several attack vectors being used to spread this particular beauty.

Many of the reports are using Google searches to estimate the number of infected systems.  Estimates put that figure at about 500,000, but take that figure with a grain of salt.  While there are a lot affected, using Google as the source of this particular metric is somewhat flawed.  Google reports the total number of links found referring to a particular search string, so there may be duplicated information.  It's safe to say, however, that this is pretty widespread.

Regardless of the method of attack, and which server is infected, an unsuspecting visitor to the exploited site is exposed to a plethora of attacks.  The malware uses a number of exploits in popular software packages, such as AIM, RealPlayer, and iTunes, to gain access to the visitor's computer.  Once the visitor is infected, the malware watched for username and password information, reporting that information back to a central server.  Both ISC and ShadowServer have excellent write-ups on both the server exploit as well as the end-user exploit.

Be careful out there, kids...

I had the chance to install VirtualBox and I must say, I'm pretty impressed.  To start, VirtualBox is only a 15 meg download.  That's pretty small when compared to Virtual PC, and downright puny when compared to VMWare Workstation.  There seems to be a lot packed in there, however.  As with VMWare, VirtualBox has special extensions that can be installed into the guest OS for compatibility.

Installation was a snap, similar to that of VMWare, posing no real problem.  The first problem I encountered was after rebooting the guest and logging in.  Apparently, I ran out of memory on the host OS, so VirtualBox gracefully paused the guest OS and alerted me.  After closing some open programs, I was able to resume the guest OS with no problem.  These low memory errors remain the only real problem I have with VirtualBox at this point.

Networking in VirtualBox is a little different from that of VMWare, and took me a few tries before I figured it out.  By default, the system is installed with no virtual adapters, making NAT the only means by which the guest OS can speak to the world.  By installing a virtual interface on the host, through the use of Host Interface Networking (HIF), you can allow the guest OS direct access to the network.  After the interface is created, it is bridged, through the use of a Windows Network Bridge interface, with the interface you want the traffic to flow out of.  Adding and removing an interface in the bridge sometimes takes a minute or two.  I honestly have no idea what Windows is doing during this time, but until the interface is added/removed, networking ceases to function.  I have also noticed that if VirtualBox is running, regardless of the state of the guest OS, modifying the bridge will fail.

Installation of the guest extensions, which required GCC and the kernel headers on the guest OS to be installed, was relatively painless.  After making sure the necessary packages were installed in CentOS, VirtualBox compiled and installed the extensions.  This allowed me to extend my desktop resolution to 1024x768, as well as enabling auto-capture of the mouse pointer when it enters the virtual machine window.  According to the documentation, the extensions also add support for a synchronized clock, shared folders and clipboard, as well as automated Windows logins (assuming you are running a Windows guest OS).

VirtualBox is quite impressive, and I've started using it full time.  It's not quite as polished as VMWare is, but it definitely wins price-wise.  I'm sure VMWare has many more features that I am not using, that may actually justify the price.  For now, I'll stick with VirtualBox until something forces me to switch.

In related news, I've been informed by LonerVamp that VMWare Server, which is free, would also satisfy my needs.  I am a bit confused, though, that a server product would be released for free while a workstation product would not.  I was initially under the impression that the server product merely hosted the OS, allowing another VMWare product to remotely attach to it.  That doesn't appear to be correct, however.  Can someone explain the major differences to me?  Why would I want to use Workstation as opposed to Server?