diff --git a/Imaging-SUSE-Linux-With-tbku.txt b/Imaging-SUSE-Linux-With-tbku.txt index c048e1f..8fb9a5f 100644 --- a/Imaging-SUSE-Linux-With-tbku.txt +++ b/Imaging-SUSE-Linux-With-tbku.txt @@ -4,9 +4,11 @@ This document describes how to use the TundraWare Inc. ``tbku`` utility to "image" or "clone" SUSE Linux systems. - .. Note:: - Most/Much of this will also be relevant to other Linux distributions, - though some of the fine points may be different. + .. Note:: + + Most/Much of this will also be relevant to other Linux + distributions, though some of the fine points may be + different. Why Bother Imaging? @@ -28,17 +30,20 @@ "Imaging" or "Cloning" allows us to keep a copy of the entire OS *as configured* - that means with all its applications and configuration -options set up as desired. We then load a new hard drive with this -image and *voila'*, "instant" running system. +options set up as desired. We then load or "Provision" a new hard +drive with this image and *voila'*, "instant" running system. What Is ``tbku``? ================= -``tbku`` is a shell script that makes it easy to create tarballs -of some of all of your filesystems. If you've never used it before, -take a moment to download it and read the documentation. You'll -find the latest copy at: +``tbku`` is a shell script that makes it easy to create tarballs of +some of all of your filesystems. ``tbku`` does not help you with +*restoring* your image, it's just handy for creating the image in the +first place. + +If you've never used it before, take a moment to download it and read +the documentation. You'll find the latest copy at: http://www.tundraware.com/Software/tbku @@ -47,13 +52,14 @@ by to use it, so take a moment to read the license in the distribution tarball. - .. Note:: - You don't *have* to use ``tbku`` to create your backup image. - The description below should work fine so long as you have a - backup of all the relevant files that preserves all the - appropriate file information such as ownership and permissions. - ``tbku`` just makes it easy to automate the creation of such - backups. + .. Note:: + + You don't *have* to use ``tbku`` to create your backup + image. The description below should work fine so long + as you have a backup of all the relevant files that + preserves all the appropriate file information such as + ownership and permissions. ``tbku`` just makes it easy + to automate the creation of such backups. The Big Picture @@ -63,20 +69,20 @@ overall process. Imaging a system requires the following steps: -1) Create the "master" image + A. Create the master image: - - Create a baseline system configured as you want it. - - Take an "image" of it. (That's where ``tbku`` is helpful.) - - Save the image somewhere (DVD, USB drive, network drive ...). - you can get at when you need it to (re)install a system. + - Create a baseline system configured as you want it. + - Take an "image" of it. (That's where ``tbku`` is helpful.) + - Save the image somewhere (DVD, USB drive, network drive ...) + you can get at when you need it to (re)install a system. -2) Use the master image to (re)provision a machine + B. Use the master image to (re)provision a machine: - - Prepare the target hard disk to receive the image. - - Dump the image onto the hard disk. - - Adjust the configuration if/as needed for the new hardware. + - Prepare the target hard disk to receive the image. + - Dump the image onto the hard disk. + - Adjust the configuration if/as needed for the new hardware. + - Creating The Master Image ========================= @@ -87,15 +93,56 @@ can clone systems back and forth between SCSI, IDE, and SATA. You can clone from smaller disks to larger ones or go the other way. - .. Note:: + .. Note:: - The whole point of doing imaging is to avoid having to do custom - configuration for each new installation. However, some small - amount may be necessary when the target hardware is different - than the hardware on which the master image was created. This is - discussed a bit more below in the `Gotchas`_ section. + The whole point of doing imaging is to avoid having to + do custom configuration for each new installation. + However, some configuration changes may be necessary + when the target hardware is different than the hardware + on which the master image was created. This is + discussed a bit more below in the `Gotchas`_ section. + Creating The Master Image + + 1. Select the machine whose existing SUSE Linux installation + you want preserved or used as a standard installation image. + + 2. Image that system with ``tbku`` using the following + fileset:: + + /bin + /boot + /dwnl + /etc + /home + /lib + /local + /opt + /root + /sbin + /srv + /usr + /var + + Notice that we do *not* backup the dynamic kernel-created + filesystems like ``/dev`` or ``/proc``. + + 3. Save the resulting ``.tar.gz`` (tarball) file somewhere + it can be retrieved later when you want to image another + machine. This can be a network server, a USB drive, + a DVD or whatever makes sense in your environment. As + with all backup systems, it's pretty important to make + multiple copies of the backup image, and keep a couple + of them off-site. + + + + + + + + Provisioning With The Master Image ================================== @@ -103,13 +150,149 @@ 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 + ``Rescue System``. + + 2. Now we have to prepare the disk to receive a Linux + filesystem. The example below assumes we are installing on + /dev/hda - a PATA master on the first IDE controller - but + you can do what follows with any of the drives on your + system. Just substitute the device names as appropriate:: + + # Partition the drive: + + fdisk /dev/hda + + # Delete and create partitions as you like + # Make sure the partition that will mount / + # is toggled to be bootable + # Be sure to use the 'write' option before exiting + + # Suppose you end up with this: + # + # /dev/hda1 is for swap (type 82) + # /dev/hda2 is for your filesystem (type 83) + + mkswap /dev/hda1 + mkfs.reiserfs /dev/hda2 + mount /dev/hda2 /mnt + + # Now, let's create the top level directories that that + # were not backed up and/or will be used by the kernel + # for its own filesystems: + + cd /mnt + mkdir dev media mnt proc sys tmp + + # Now it's time to mount your backup medium. Depending + # on your backup medium this can be one of several + # devices. CD/DVDs are often found at /dev/hdc1. USB + # drives show up as SCSI drives such as /dev/sda1, and + # so on. You'll also need to know the type of the + # backup medium (see: man mount for the details): + + mount -tvfat /dev/sda1 /mnt/mnt # This is a USB drive + + # OK, time to dump the image previously created by tbku + # onto our shiny new filesystem (make sure your current + # directory is still /mnt before doing this): + + tar -xzvf /mnt/my-system-image.tar.gz + + # Now we have to make sure that the boot tables and + # default file mounts are correct - Our target system + # may have a different drive type or device (SCSI, sata, + # pata) than the system from which tbku took the image: + + # Edit /mnt/etc/fstab to reflect the partitioning + # you did with fdisk. Remember that drives can be + # named by device name (/dev/xxxx) or by the vendor + # name (/dev/disk/by-id/xxxx). In our case the + # relevant portion of /mnt/etc/fstab looks like this: + + /dev/hda1 swap swap defaults 0 0 + /dev/hda2 / reiserfs acl,user_xattr 1 1 + + # Be sure not to disturb the other stuff in the fstab + # file + + # Now, check and fix the device map file, + # /mnt/boot/grub/device.map Say we took the tbku image + # from a system that boot from SCSI, that file + # would look like this: + + (fd0) /dev/fd0 + (hd0) /dev/sda + + # But our new system wants to boot from ATAPI so it + # now needs to look like this: + + (fd0) /dev/fd0 + (hd0) /dev/hda + + # We also have to correct any differences in the boot + # menu that appears when you first start the system. + # This is in /mnt/boot/grub/menu.lst Near the top of + # this file you'll see something like this: + + gfxmenu (hd0,1)/boot/message + + # hd0 is right - we made sure of that when we edited + # the map file above. Make sure that the offset (1 in + # this case) is also right. This is the number, + # *counting from 0* of the root/boot partition within that + # drive. In our case, (hd0,1) is correct because our + # root/boot partition is /dev/hda2. + + # Following this are the individual menu entries. + # Make sure you check each line of every entry. + # Suppose we find this: + + title SLED 10 - 2.6.16.54-0.2.5 + root (hd0,1) + kernel /boot/vmlinuz-2.6.16.54-0.2.5-default root=/dev/sda2 + resume=/dev/sda1 splash=silent showopts + initrd /boot/initrd-2.6.16.54-0.2.5-default + + # All references to /dev/sda2 have to be changed to /dev/hda2 + # All references to /dev/sda1 have to be changed to /dev/hda1 + # Repeat this for every menu entry. + + # Finally, lets make sure that the boot loader + # is properly installed and configured: + + grub-install --root-directory=/mnt /dev/hda + + +We're DONE! Well ... maybe. If the hardware (chipset, CPU) of your +target machine is similar/same as the machine from which you took the +original image OR if the kernel you plan to boot has support for your +new target hardware, you should just be able to boot and run at this +point. If not, read the following `Gotchas`_ section for further +explanation. + +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. 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 to a *completely +configured system* with all your applications, custom configuration, +and so on as you last left them. Gotchas ======= There are some circumstances where you cannot avoid doing some -small amount of configuration on the newly provisioned machine. +configuration on the newly provisioned machine. + +A. Network differences + +B. Different Hardware + +C. Different Chip Architectures + Author @@ -120,7 +303,13 @@ Comments and/or improvements welcome! -Document Revision Information -============================= +Document Information +==================== -``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.103 2008/03/11 23:11:20 tundra Exp $`` +This document produced using the amazing ``reStructuredText`` tools in +the ``docutils`` package. For more information, see: + + http://docutils.sourceforge.net/rst.html + + +``$Id: Imaging-SUSE-Linux-With-tbku.txt,v 1.104 2008/03/12 22:40:44 tundra Exp $``