2006

I’d like to take this time and wish everyone a very Happy New Year!  I hope that the Lord has blessed you this past year, and I hope that He will continue to bless you in the new year.

“Seek ye first the kingdom of God, and his righteousness; and all these things shall be added unto you.” (Matthew 6:33 KJV)

Network Appliance Snapshots—point-in-time copies of a file system that can be created almost instantaneously and which generally require much smaller amounts of storage to keep—are an integral part of NetApp’s value over other storage systems.  These snapshots make it far easier and quicker to recover from data loss or corruption than a tape backup system.

But how do we go about recovering individual files from a snapshot when those files are stored in a virtual disk (VMDK) file used by a VM?  After all, VMware proponents tout the encapsulation property of virtualization as a benefit: “One file to back up and you get a backup of your entire server!”  Fortunately, there’s a way to continue to reap the benefits of encapsulation while still allowing for the ability to recover individual files from a snapshot of the VM’s virtual disk file.  Here’s how.

The trick here is to take advantage of LUN cloning, a feature on the NetApp storage systems that allows you to take a snapshot—which is a read-only point-in-time copy of the file system—and create a clone, which is a read-write point-in-time copy of the file system.  This clone takes only seconds to create, like the snapshot on which it is based, and requires only enough storage to store the changed blocks, i.e., the “deltas” between the clone and the original.  We can then present that clone back to VMware ESX Server to manipulate in whatever way we see fit.

There are three parts to this process.  First, we configure ESX Server to recognize snapshot LUNs on the SAN (this is a one-time configuration change).  Then, we take the snapshot on the NetApp storage system, create a LUN clone from the snapshot, and present that LUN clone back to the ESX servers.  Finally, we manipulate the LUN clone within ESX in order to retrieve the specific data we need.

Enable Resignaturing on ESX Server

In the ESX SAN Configuration Guide (found here on VMware’s site), there is this blurb about resignaturing:

VMFS volume resignaturing allows you to make a hardware snapshot of a VMFS volume and access that snapshot from an ESX Server system.

This is the functionality that allows us to use LUN clones on the NetApp storage system in ESX Server.  Without this functionality, the LUN clones aren’t properly recognized by ESX Server and can’t be utilized to allow us to perform data recovery.

To enable VMFS volume resignaturing, set the LVM.EnableResignature option to 1 (on).  This option can be set in VirtualCenter using these steps:

1. Set the ESX Server host for which you want to enable VMFS volume resignaturing.
2. Go to the Configuration tab for that host, then select Advanced Settings.
3. Change the LVM.EnableResignature to 1 (on).  The default is off.

After this option is set, you’ll be able to present LUN clones (or other hardware snapshots) to ESX Server and it will recognize them as such.

Now we’re ready to move to the NetApp storage system.

Taking a Snapshot and Making a LUN Clone

By default, snapshots are already enabled and scheduled, so unless you’ve modified the configuration, the NetApp storage system is already taking snapshots of the volumes that hold the LUNs where the VMware VMFS partitions (and thus the VMDK virtual disk files) are stored.

We can view the list of snapshots like this:

filer> snap list vol_name
Volume vol_name
working...

  %/used       %/total  date          name
----------  ----------  ------------  --------
  0% ( 0%)    0% ( 0%)  Dec 30 08:00  hourly.0
  1% ( 0%)    0% ( 0%)  Dec 30 00:00  nightly.0
  1% ( 0%)    0% ( 0%)  Dec 29 20:00  hourly.1
  1% ( 0%)    0% ( 0%)  Dec 29 16:00  hourly.2
  1% ( 0%)    0% ( 0%)  Dec 29 12:00  hourly.3
  2% ( 1%)    0% ( 0%)  Dec 29 08:00  hourly.4
  2% ( 0%)    0% ( 0%)  Dec 29 00:00  nightly.1
  3% ( 0%)    0% ( 0%)  Dec 28 20:00  hourly.5

Now, we can make a LUN clone from one of these snapshots and map it to an igroup (this would normally all be on a single line, but I’ve wrapped it here for readability):

filer> lun clone create /vol/vol_name/lun0_clone -b /vol/vol_name/lun0_vmfs nightly.1
filer> lun map /vol/vol_name/lun0_clone igroup_name 0

The LUN clone has now been created and presented back to the igroup named igroup_name as LUN ID 0.  A rescan of the storage adapters in ESX Server (iSCSI was being used in this case) will now show the LUN clone as “snap-00000001-lun0_vmfs” (the number will change depending upon how many snapshot LUNs have been presented to the server farm).  Now that we have access to the VMFS, we can do any number of things:

• We can create a new VM with the same configuration as the original VM and boot it up to recover data from the VM in that manner (be cautious of networking issues, such as duplicate IP addresses).  You’ll just need to select the existing VMDK (or VMDKs, if there are more than one) on the snapshot VMFS LUN instead of creating a new virtual disk file when creating the VM.
• We can attach the VMDK(s) to an existing VM running the same operating system (or an operating system that will read the file system used inside the VMDKs in question) and then browse the file system to retrieve data stored inside the VM.
• We could shut down the original VM and boot up the clone VM instead.  This might be helpful if you needed to recover data but also needed network connectivity, or if the two VMs couldn’t be running at the same time.  (In theory, this might work for Microsoft Exchange, if you aren’t using SnapManager for Exchange.)

As you can see, this allows us to take full advantage of encapsulating the server in the VMDK file(s) but also allows us to retrieve individual files or groups of files from a snapshot of the VMDK file(s).

In future articles, I’ll touch on restoring entire VMs using NetApp snapshots, as well as talk about getting consistent snapshots of the VMs.

Other Information

This process was performed on a Network Appliance FAS810 running Data ONTAP 7.1.1.1 and servers running VMware ESX Server (both 3.0.0 and 3.0.1) with the software iSCSI initiator.  VMs running Windows Server 2003 R2 were used for testing.

There appear to be basically two views on how virtualization will affect the future development of operating systems and computing environments in the personal computing space.  One camp believes that virtualization functionality will be present within the operating system.  Whether that virtualization functionality comes bundled with the operating system or is a third-party add-on to the operating system is, quite frankly, irrelevant to this particular discussion.  The other camp believes that virtualization will be outside the operating system, perhaps in the form of a hypervisor or thin virtualization layer that resides “below” the OS and governs access to hardware.  Again, the discussion of whether this virtualization layer comes bundled with the hardware or comes from a third-party vendor is an interesting discussion (and one that I’d like to have), but is not relevant right at this moment.

My discussions of application agnosticism puts me in the camp that places virtualization functionality in the operating system.  On the desktop side (not speaking of servers here), that kind of makes sense to me.  It seems to me that the simplest approach—placing virtualization functionality within the operating system—is likely to be the approach that most people will accept.  We have to keep in mind that millions of users out there are not nearly as technical as we are, and for them simple is good.  It may not be the most technologically advanced approach but rather the simpler approach that wins out (especially on the consumer side).

Now, having said all that, I’d like to take a closer look at the alternate approach to having virtualization placed within the operating system.  In this scenario, there is virtualization functionality that sits below the idea of today’s general purpose OS.  For those of you familiar with ESX Server, think of it that way—some sort of bare metal virtualization layer that controls the hardware.  From there, a collection of VMs will cooperatively provide the various services that are today provided by the general purpose OS.  This idea is expressed in this article by Ron Oglesby (also linked to by this VMTN Blog entry as well).

In this approach, you might have a networking VM that is responsible for scanning inbound and outbound traffic, managing security policies, interacting with corporate networks and network access controls, etc.  You can think of this as the “firewall” component of the general purpose OS (Windows Firewall on Windows, ipfw on Mac OS X, iptables on Linux), but more feature-rich and more isolated (the idea being that it is therefore more secure and harder to bypass or disable).  Likewise, you might have a VM designed specifically for running sensitive corporate applications, a VM for surfing the Internet, and a VM that provides anti-virus services to the other VMs.  Taken individually, none of these VMs could replace today’s general purpose OS; taken as a whole, the collection of VMs provides the services and functionality of a general purpose OS, but with greater isolation, encapsulation, and protection between these “service” VMs.

Is this a viable approach?  Not today, in my opinion, but certainly in the future.  (To be completely fair, Ron’s article was written in the context of the long-term impact of virtualization, so we can’t really look at today’s feasibility.)  As Intel and AMD continue to add virtualization support in hardware and performance draws nearer to “native” performance, this definitely becomes a more viable approach.  A couple questions persist in my mind, though:

• What is the mechanism whereby a user adds new functionality to their computing environment, i.e., how does a user add a new service VM?
• What kind of mechanism or tools are provided to the user to help manage, operate, or configure these service VMs?

Let’s say that the user’s “normal” working environment exists in a VM that runs Windows, Linux, or the like.  We’ll call this VM-Home.  From VM-Home, the user needs to be able to access the functionality of a networking/firewall VM (we’ll call this VM-FW) and a corporate applications VM (we’ll call this VM-Corp).  How does the user go about switching between these VMs, like between VM-Home and VM-Corp?  Does each VM provide its own windowing environment?  How is switching between these windowing environments handled?  Is there a common windowing environment provided by the virtualization layer?  Is there some internal networking connectivity between VM-Home and VM-FW that allows the user to manage the VM-FW functionality?  Where does the user go, or what program does the user run, to add a new VM (say, an anti-virus VM) to his/her environment?

“Scott, stop being so picky,” you say. “This is all being talked about in theory, anyway. It’s not like we need to have all the answers right now.”

You’re right, we don’t.  But as we look at how these questions may be answered (someone’s got to answer them sometime), it seems that we’ll need to add some functionality to the virtualization layer in order to make it easier/more seamless to switch between the VM environments.  Users will want a seamless UI to work with, so we may need to add a windowing environment to the virtualization layer.  Either that or we’ll have to enable some sort of mechanism whereby other VMs can display windows inside another VM, and now we’re breaking down the isolation/protection boundaries that we originally found to be desirable.  Users will want to be able to copy and paste between the VM environments, so we’ll need to add that functionality to the virtualization layer.  Users will want to be able to double-click an icon and have it launch in the appropriate VM environment, so now we’ve got to add some links and communications channels between the various VM components in our computing solution.  As each of these pieces of functionality is added, the virtualization layer starts to look more like a general purpose OS—just one that’s leaner, meaner, and free of years of legacy code.

As this virtualization layer starts to resemble a general purpose OS and as the general purpose OS starts to incorporate technologies such as virtualization, application-specific subsystems, and the like, these two start to look a lot like each other.  That brings us back to a central question in this discussion, a question I asked when I first started discussing the future of the OS:

So I guess the future of the operating system depends on your perspective.  If you’re an operating system guy, you’ll say that the OS has a bright future, and point to developments such as built-in paravirtualization and bundled hypervisors to prove your point.  If you’re a virtualization guy, you’ll say that the OS is dead, and you’ll point to developments such as third-party paravirtualization and independent hypervisors to prove your point.  Which of these two is correct?

Indeed!  Which approach do you think desktop computing will take?  Application agnosticism, in which virtualization and other technologies are placed within the operating system, or groups of virtual machines (“VM cooperatives”?  “VM federations”?  “OS agnosticism”?  Need a fancy marketing term again…) coordinated by a hardware/firmware virtualization layer?

What do you think?

By default, the SSH configuration on VMware ESX Server only supports AES encryption types (specifically, AES-256 and AES-128).  If you need SSH connectivity from ESX Server to a Network Appliance storage system running Data ONTAP, you’ll need to modify this to support 3DES.

This kind of connectivity would be necessary if you were interested in running scripts on ESX Server that connected to the NetApp storage system via SSH to run commands (for example, to initiate a snapshot via the command line).  This arrangement is described in this document from NetApp.

To modify the ciphers supported by ESX Server, edit the /etc/ssh/ssh_config file and change this line:

Ciphers aes256-cbc,aes128-cbc

Instead, it should look like this:

Ciphers aes256-cbc,aes128-cbc,3des-cbc

This will enable SSH connections from ESX Server to find a compatible cipher with the SSH daemon running in Data ONTAP.  Note that we change the SSH configuration on ESX Server because, as far as I know, the ciphers supported by the SSH daemon in Data ONTAP are not configurable by the user.

Note that you’ll also need to enable SSH traffic through the ESX firewall:

esxcfg-firewall -e sshClient

And, of course, you’ll need to configure and enable SSH access on the Network Appliance storage system itself using the “secureadmin” command in Data ONTAP:

secureadmin setup ssh
secureadmin enable ssh2

Once SSH is reconfigured on ESX Server and configured/enabled in Data ONTAP, then using SSH to run commands remotely from ESX Server to the NetApp storage system should work without any problems.  For complete automation, you’ll also want to setup SSH shared keys as well, but I’ll save those details for a future article.

I coined the term “application agnosticism” in the context of the discussion surrounding virtualization and its impact on the future of the operating system.  Virtualization proponents, such as VMware, say that virtualization means the end of the general purpose operating system and instead point to the rise of virtual appliances.  In the virtual appliance realm, the operating system exists to provide services to the application, and unnecessary components of the operating system are stripped away.  This is a good solution in the datacenter, but is it an equally valid approach on the desktop?

My view is that the forces that shape the desktop market are going to push operating systems and OS functionality in a different direction.  This is not to say that virtual appliances don’t have a place in the personal desktop world, just that they won’t have the same level of importance.  This is also not to say that virtualization doesn’t have a place in the personal desktop world.  Virtualization does have a place and will play an important role moving forward.  The functionality of virtualization will just be put to use in a different way.

Simply put, application agnosticism is the ability for a general purpose operating system (such as Windows, Linux, or Mac OS X) to run any kind of application without regard to operating system for which that application was designed.  Want to run Linux applications on Windows?  Or Windows applications on Mac OS X?  Application agnosticism would allow that functionality.  There are a number of components that play into making application agnosticism possible:

• Convergence on x86 hardware:  For better or worse, the hardware industry is converging on x86-compatible hardware.  (Fortunately, we aren’t tied to just one vendor in that regard, but that’s another story for another day.)  This means that coding for many different platforms isn’t as necessary today, nor is it quite as likely to have applications written for many different CPU platforms.
• Application-specific subsystems:  Like the POSIX subsystem in Windows NT and successive generations, the OS/2 subsystem in early Windows NT generations, or the X11 application in Mac OS X today, these application-specific subsystems provide the necessary resources to run applications not specifically designed to run on that particular OS.  Windows seems to be moving away from this functionality, having removed the OS/2 subsystem and (I believe) the POSIX subsystem as well.  Mac OS X, on the other hand, seems to be moving strongly in this direction, with the BSD subsystem and X11 support.  API emulators, such as WINE, are also forms of application-specific subsystems (more on that in a moment).
• Virtualization:  Virtualization is a key enabling technology for application agnosticism.  As vendors such as VMware, Parallels, and Microsoft move to provide greater integration between the host and guest environments, this role becomes more evident.  Excellent examples of this type of host-guest interaction are the drag-and-drop file sharing of VMware’s Fusion beta, the Coherence feature in Parallels Desktop for Mac, and the ability of the now-defunct Microsoft Virtual PC for Mac to launch the PC guest environment when a user double-clicked on a PC file type in the host environment.

In the datacenter, these kinds of host-guest interactions are not only unnecessary, but actually undesired—very few would actually want the ability to drag and drop files between a host server (assuming there’s actually a host OS present) and a guest server, especially if that guest server is running in a “headless”-type scenario in the background.  On the desktop side, however, these kinds of interactions are quite useful, and help extend the desire and ability of users to actually make use of these kinds of technologies.  It’s these kind of forces that I believe will drive virtualization on the desktop in a different direction than virtualization on the server, and what will bring about application agnosticism.

In the initial discussions of application agnosticism, I mentioned that I believed Mac OS X to be further along the curve to embracing application agnosticism than other general purpose operating systems.  If you look at the components that make application agnosticism possible, it appears to me that Apple embraces and utilizes more of these components than some of the other major operating systems on the market.  Without this devolving into a discussion of one operating system versus another or which OS is better, allow me to mention the ways in which this appears to be the case:

1. Mac OS X currently utilizes application-specific subsystems:
• There is a BSD subsystem that allows many UNIX command-line applications to run without modification.  Some require a simple recompile in order to run.  Future versions of Mac OS X are seeking certification as an “official” flavor of UNIX from The Open Group, further increasing the compatibility and usefulness of this subsystem and its ability to run command-line UNIX applications.
• Likewise, there is an X11 subsystem for Mac OS X as well, allowing users to run native Mac OS X applications side-by-side with X11 applications.  Of course, this is certainly not an advantage possessed solely by Mac OS X as there are X11 subsystems available for Windows, and X11 is “native” to Linux distributions.
• Future versions of Mac OS X (the next version, code-named “Leopard,” in particular) may include technologies developed years ago by Apple.  Called “Red Box” at the time, these technologies would allow Mac OS X to run Windows applications at near-native speeds.  Like the Intel version of Mac OS X that was buried for years before resurfacing at the start of the Intel transition, it’s very possible that Red Box could rise again in Leopard and enable Mac users to run Windows applications on their Macs.  A number of others have written about this possibility; see here and here for more information.  And let’s not discount WINE, which currently runs on Linux and is being ported to Mac OS X.  Both of these could be considered application-specific subsystems designed to support Windows applications on Mac OS X.
2. Mac OS X seems to be at the forefront of host-guest integration:
• Parallels Desktop for Mac offers a Coherence mode, which I mentioned earlier in this article as well as here; this allows you to run virtualized applications side-by-side with host applications.  No separate desktop environment, or windows inside another window.  Just applications running.
• VMware’s Fusion product, now in public beta, offers drag-and-drop interaction between the host and guest environments.  Again, drag-and-drop is a function that users on the desktop have come to expect, so embedding this into a virtualization solution makes perfect sense.
• The now-defunct Virtual PC for Mac, from Microsoft, offered a number of very innovative host-guest integrations during its lifetime.  I mentioned guest file type registration already, in which guest file types that were double-clicked in the host environment caused the guest environment to launch and load the document.  If I’m not mistaken, Virtual PC also offered clipboard integration as well.  (I never used Virtual PC on the Windows platform, so these features may have been present or still be present in that version.)

Take a moment and think about an environment utilizing a virtualization engine with all three of the functional integrations I described above—drag-and-drop between host and guest, side-by-side host/guest windows in the same windowing system, and the ability to double-click a file in the host and have it launch in a guest.  In that kind of environment, a user could easily run just about any application for just about any operating system and not have to really worry about the details.  (Of course, this glosses over little details like installing the guest operating systems and the applications for those respective guest operating systems.)  Being able to do that is what application agnosticism is all about.  In my humble opinion, application agnosticism is virtualization’s “killer app” on the desktop.

So there’s my thoughts.  What about you?  Do you buy into the idea of application agnosticism?  Or do you think that virtualization on the desktop is headed in a different direction?  Speak up in the comments and let me know.

Rumors had been building for the last few days, and in response VMware finally released the public beta for VMware Fusion, the Mac desktop virtualization product.  I’d written about my first impressions earlier; now I’d like to share my thoughts on the public beta build.

Keep in mind that this is still a beta; it’s too early to make any sort of performance comparisons.  (Having said that, I’m not really worried about performance; Windows XP Professional seems to run just fine for what I need.  Of course, your mileage may vary.)

Here’s what I’ve picked up in the 10 minutes or so I’ve had to work with the new build:

• The user interface is more polished, as to be expected.  The icon has changed slightly (I actually prefer the old color scheme, for what it’s worth), and more commands have been edited.  In particular, there is now a UI for editing the VM configuration, although some parts of that screen are still incomplete.  I can finally tell Fusion not to connect the sound card to my VMs now!
• VMware has added bridged networking to the product.  This is a big one for many people, I suspect, as it is with me.  Putting VMs into a bridged networking configuration will help with connectivity, both between the VMs and the physical network and between the VMs and the host system.
• I anticipate that the networking functionality has been made more robust as well; a few of the private beta testers ran into issues when frequently changing networks, when resuming VMs from suspend, or when waking the host system.  Those kinds of bugs are to be expected in a beta product and I have no doubt that the Fusion development team will take care of (or has already taken care of) those issues.

I’m sure that there’s more to the new version than just what I’ve seen so far in the last few minutes.  As I get the opportunity to continue to explore the product, I’ll post any additional information.

Suggestions to use Samba in Linux-AD integration scenarios appeared in the comments for the following articles:

Linux, Active Directory, and Windows Server 2003 R2 Revisited
Kerberos-Based SSO with Apache

The idea was that Samba could be used to help automate the process of creating the appropriate service principals in Active Directory.  Previously, I had recommended the use of ktpass.exe and separate user accounts for each service principal (i.e., HOST/ or host/, HTTP/, etc.) because of the limitations of ktpass.exe and adding service principals in Active Directory.  However, a number of readers pointed out that Samba’s “net ads join” and “net ads keytab” commands could help automate and streamline this process.

Since one of my Linux servers had crashed anyway, I decided to try out the Samba toolset while integrating this new Linux server into my existing Active Directory infrastructure.  Here’s what I found and the process that I used to successfully integrate the new Linux server into AD with the Samba tools.

1. First, the Kerberos client had to be configured properly.  I’ll refer you back to any one of the various Linux-AD integration articles I’ve written for more information on how to setup the /etc/krb5.conf file.  You should be able to do a successful “kinit username@AD.DOMAIN.NAME” when /etc/krb5.conf is configured correctly.
2. Next, Samba must be properly configured.  I used the following settings in /etc/samba/smb.conf:

   workgroup = <NetBIOS name of AD domain>
   security = ads
   realm = <DNS name of AD domain>
   use kerberos keytab = true
   password server = <Space-delimited list of AD DCs>

3. For full Linux-AD integration, you must configure the nss_ldap client.  Again, I’ll refer you to any one of the various AD integration articles I’ve written for more details on a suggested nss_ldap configuration.  When nss_ldap is correctly configured, you should be able to do a “getent password <username>” and get back a list of properties (including UID, home directory, login shell, etc.) for that username.
4. Use “kdestroy” to kill any Kerberos credentials you may have established during testing, and then run “kinit <administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an administrative user in the AD domain.
5. If the DNS domain of your Linux server will be different than the DNS domain of the AD domain (for example, perhaps your Linux server will be web1.linux.corp.com whereas Active Directory uses ad.corp.com), then create a computer account in Active Directory.  If the Linux server’s DNS domain will be the same as the DNS domain for AD, then we can have Samba create it for us.  (I ran into problems here since the Linux server does use a different DNS domain than Active Directory, and pre-creating the computer account was the only way to make it work.)
6. Run “net ads join” to join the Linux server to Active Directory.  As part of this process, it will add various SPNs to the computer account in Active Directory automatically and create the appropriate entries in the local Kerberos keytab (/etc/krb5.keytab, by default).  No more ktpass.exe!

At this point, you can configure PAM appropriately (again, refer to one of the previous integration articles for full details on PAM configuration) and login to the Linux server with an Active Directory account.

I used this process to integrate a new CentOS 4.4 server into Active Directory without any problems whatsoever.  I used the Kerberos, LDAP, nsswitch.conf, and PAM configurations from this Linux-AD integration article within the framework of the steps listed above and ran into only one problem (that was the issue with the differing DNS domains).  Otherwise, it worked just fine.

Thanks to those readers who suggested the use of Samba!

Changing the IP address of a system running Solaris (Solaris 10, specifically) is different than a lot of other operating systems out there.  Really, all you have to do is just edit a few files and then take the interface down and back up again.  However, there seems to be a “gotcha” with Solaris 10.  (I don’t know how far back this procedure goes—it is unclear to me if this is new to Solaris 10, or if it extends back to Solaris 8 or 9.)

Most of the sites out there I found indicated that you only needed to edit the /etc/hosts file (which is actually just a symlink to /etc/inet/hosts) and place the new IP address of the server in that file.  Since I wasn’t changing the hostname or default gateway, there was no need to edit /etc/hostname.pcn0 (the hostname file for the only interface in the system), /etc/nodename, or /etc/defaultrouter.  So I edited the /etc/inet/hosts file, rebooted the server, and expected to see the new IP address show up on the network.

It didn’t work.  A bit more research indicates that in Solaris 10, the operating system uses /etc/inet/ipnodes over /etc/inet/hosts.  This is a bit odd since ipnodes is only supposed to be used for IPv6, and I know that I specifically disabled IPv6 in this installation.  Some additional targeted searches I performed, however, showed that this was indeed the case even if IPv6 is disabled.

Upon editing /etc/inet/ipnodes and rebooting the server, the IP address change took effect.

So, if you need to change the IP address of a server running Solaris 10, change the following files:

/etc/inet/hosts
/etc/inet/ipnodes

Upon a reboot, the server will now have the new IP address.

(By the way, Solaris 10 U3 runs perfectly under ESX Server.)

Due to a massive spam flood amounting to practically a Denial of Service (DoS) attack, all commenting functionality on the site was temporarily disabled for a couple of days.  As of Saturday, 12/16/06, commenting/trackback functionality has been restored.

I’ve had literally thousands upon thousands of comment spam requests in the last couple of days, knocking the site offline several times and forcing Akismet to work three times as hard trying to keep the spam out.  This is now the third or fourth time the site has come under extreme pressure from comment spam bots in the last two weeks, and each time it seems to get a bit worse.

Until I can figure out a way to help keep this comment spam flood from repeatedly taking the site offline, I had to disable all comment functionality on the site.  I apologize to my legitimate readers who wanted to leave valid comments.  Hopefully the changes that I’ve made will help prevent this problem from recurring in the future.

More information on the various zero-day exploits can be found at the following web sites:

New Report of A Word Zero Day
<http://blogs.technet.com/msrc/archive/2006/12/10/
new-report-of-a-word-zero-day.aspx>

Double Trouble: Microsoft Confirms Another Word Zero-Day Flaw
<http://www.eweek.com/article2/0,1759,2071558,00.asp>

Third MS Word Code Execution Exploit Posted
<http://www.eweek.com/article2/0,1759,2072969,00.asp>

Exploit Code Targets Third Microsoft Zero-Day Word Bug
<http://www.darkreading.com/document.asp?doc_id=112974
&f_src=darkreading_section_318>

As before, the advice on protecting yourself is don’t open Word documents from any source, trusted or untrusted.  Kind of puts the kibosh on the whole sharing-documents-via-email thing, doesn’t it?