diff --git a/Imaging-SUSE-Linux-With-tbku.txt b/Imaging-SUSE-Linux-With-tbku.txt
index 7ce8118..dc688c7 100644
--- a/Imaging-SUSE-Linux-With-tbku.txt
+++ b/Imaging-SUSE-Linux-With-tbku.txt
@@ -17,9 +17,9 @@
Suppose we need to build a new instance of a ``SUSE Linux`` system.
Perhaps we need to replace one that just had a hard drive failure.
Maybe we want to build a new server that is based on our "standard"
-system configuration. In other words, we want to go from "bare
-metal" hardware to a fully running *and configured* system as quickly
-as possible.
+system configuration. In other words, we want to go from "bare metal"
+hardware to a fully running *and configured* system as quickly as
+possible.
There are a number of commercial and open source solutions to this
problem, but they all have one thing in common: We want to minimize
@@ -34,6 +34,24 @@
drive with this image and *voila'*, "instant" running system.
+When Does Imaging NOT Make Sense?
+=================================
+
+Imaging works best when the system you are targeting is very similar
+or identical to the system that made the image in the first place.
+For example, Imaging is a great way to restore a single machine from
+its own backups - say after a hard disk crash or upgrade.
+
+Imaging is more complex when the source of the image and the target
+machines are different. The more different they are, the harder it
+will be to get the image running on the new target machine.
+
+As a practical matter, production Data Centers tend to keep a separate
+restore image around *for each different system variant*. So, for
+example, you might have a separate image for your IBM servers, your
+Dell servers, your Toshiba laptops, and so on.
+
+
What Is ``tbku``?
=================
@@ -139,22 +157,15 @@
of them off-site.
-
-
-
-
-
-
-
Provisioning With The Master Image
==================================
-Now that we have a "snapshot" or master image, we can use it
-to (re)provision machines.
+Now that we have a "snapshot" or master image, we can use it to
+(re)provision machines.
Provisioning Machines With A Master Image
- 1. Boot the SUSE Linux installation disk and load the
+ 1. Boot the SUSE Linux installation disk and load the
``Rescue System``.
2. Now we have to prepare the disk to receive a Linux
@@ -283,8 +294,8 @@
This may all seem complex the first time you do it, but after a couple
of times, you'll be able to do this in your sleep. This is one of
-those things where describing it is more complicated than just
-doing it!
+those things where describing it is more complicated than just doing
+it!
Depending on how large your backup image is, a complete system restore
can typically be done in less than an hour. That's less than an hour
@@ -296,18 +307,17 @@
=======
-If you use the approach described above to reprovision the
-same machine - say after a disk failure or disk upgrade -
-then that's all you have to do. Your "target" machine is
-essentially identical to the one from which you got the backup
-image ... the same machine.
+If you use the approach described above to reprovision the same
+machine - say after a disk failure or disk upgrade - then that's all
+you have to do. Your "target" machine is essentially identical to the
+one from which you got the backup image ... the same machine.
-However, there are some circumstances where you cannot avoid doing some
-configuration on the newly provisioned machine. This is the case where
-there is a significant difference between the machine that took the
-snapshot and the machine receiving it. This might be because the
+However, there are some circumstances where you cannot avoid doing
+some configuration on the newly provisioned machine. This is the case
+where there is a significant difference between the machine that took
+the snapshot and the machine receiving it. This might be because the
target machine has different hardware, needs a different IP address,
-uses a different chipset, and so on.
+uses a different chipset, and so on.
There is no general way to solve these sorts of problems. You'll have
to dig through YAST (if the system boots at all) and/or the individual
@@ -315,28 +325,26 @@
As a personal preference, I like to work directly with configuration
files from the command line whenever I can. If the target machine
-will not boot, you sort of have no other choice. You'll have to
-do something like this to get to those files to edit them.
-Boot the installation CD and select ``Rescue System``, then
-mount the target drive(s)::
+will not boot, you sort of have no other choice. You'll have to do
+something like this to get to those files to edit them. Boot the
+installation CD and select ``Rescue System``, then mount the target
+drive(s)::
mount /dev/hda2 /mnt
You can then edit the files found under /mnt.
+ A. Environmental Differences
-A. Environmental Differences
+ B. Different Hardware
-B. Different Hardware
-
- 1. CPU Architecture
- 2. Motherboard Chipset
- - Disk Controllers
- - Network Controllers
- - Audio
- - Video
-
+ 1. CPU Architecture
+ 2. Motherboard Chipset
+ - Disk Controllers
+ - Network Controllers
+ - Audio
+ - Video
Author
======
@@ -350,9 +358,9 @@
====================
This document produced using the amazing ``reStructuredText`` tools in
-the ``docutils`` package. For more information, see:
+the ``docutils`` package. For more information, see:
http://docutils.sourceforge.net/rst.html
-``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.105 2008/03/12 23:06:34 tundra Exp $``
+``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.106 2008/03/12 23:17:24 tundra Exp $``