Posted by: Anonymous Coward
on February 24, 2006 09:12 AM
This is the very basics of patch management. The attitude of "if you don't have a test environment, just use the most important part of the infrastructure - your management workstation" shows a lack of Enterprise experience.
The management systems are the worst place to test new patches. Even if you have an environment of ten desktops, the cost of an additional desktop for testing is (by definition) 10% of the overall cost, at worst. If you have a live system involving ten servers and 100 desktops, then one additional test server and one additional test desktop is a trivial cost compared to the risk of rolling out an untested patch.
The idea of a small network with the one sysadmin being unable to reboot his PC because he tried out a new patch which doesn't work is cowboy principles at best.
The idea of anything larger than that, not having a test environment (at least a complete backout plan at every stage in case the testing goes wrong) is professional suicide.
One easy way to do this in a small environment is to make use of mirrored storage (which you are hopefully already using). Here's an example (for a small firm):
You have a webserver (let's say it's a Linux x86 box, or a small Solaris server). The OS, application and data are all stored on the rootdisk. This is mirrored in software or hardware.
If you want to test a patch, then (logically or physically, depending on the technology - logical is probably better) remove one part of the mirror, test your patch on the remaining half of the mirror, and if it works, re-attach the second half of the mirror and resynchronise. If it all goes wrong, reboot from the known-good half of the mirror and resync (or debug, learn lessons, resync and try again).
Better still is to take a 3rd mirror copy (that is, mirror the OS/App/Data across 3 disks, or sets of disks, then test it one on disk (or set of disks) so that you've still got a fully-mirrored, known-good environment to boot back into if necessary. That way, you avoid the dual-failure situation, whereby you install a broken patch onto one half of the mirror, and (Sod's Law) the disk holding the good half of the mirror dies at the same time.
This article is pushing cowboy attitudes as far as possible, whilst trying to claim credibility just because it's pointing out that you need to test patches before you deploy them.
Learn about Linux
Download Linux
Get Linux help
Well, Duh!
Posted by: Anonymous Coward on February 24, 2006 09:12 AMThe management systems are the worst place to test new patches. Even if you have an environment of ten desktops, the cost of an additional desktop for testing is (by definition) 10% of the overall cost, at worst. If you have a live system involving ten servers and 100 desktops, then one additional test server and one additional test desktop is a trivial cost compared to the risk of rolling out an untested patch.
The idea of a small network with the one sysadmin being unable to reboot his PC because he tried out a new patch which doesn't work is cowboy principles at best.
The idea of anything larger than that, not having a test environment (at least a complete backout plan at every stage in case the testing goes wrong) is professional suicide.
One easy way to do this in a small environment is to make use of mirrored storage (which you are hopefully already using). Here's an example (for a small firm):
You have a webserver (let's say it's a Linux x86 box, or a small Solaris server). The OS, application and data are all stored on the rootdisk. This is mirrored in software or hardware.
If you want to test a patch, then (logically or physically, depending on the technology - logical is probably better) remove one part of the mirror, test your patch on the remaining half of the mirror, and if it works, re-attach the second half of the mirror and resynchronise. If it all goes wrong, reboot from the known-good half of the mirror and resync (or debug, learn lessons, resync and try again).
Better still is to take a 3rd mirror copy (that is, mirror the OS/App/Data across 3 disks, or sets of disks, then test it one on disk (or set of disks) so that you've still got a fully-mirrored, known-good environment to boot back into if necessary. That way, you avoid the dual-failure situation, whereby you install a broken patch onto one half of the mirror, and (Sod's Law) the disk holding the good half of the mirror dies at the same time.
This article is pushing cowboy attitudes as far as possible, whilst trying to claim credibility just because it's pointing out that you need to test patches before you deploy them.
#