You basically have it right.  In my case, it's all on one subnet, and 
100MB is fast enough to meet my needs.  We run DHCP, so the Live CD 
configures its network automagically.

But if the network is the issue, then it's just as easy to use a USB hard 
drive or big USB stick to hold the images.

And you are also correct that the Grub stuff is needed to install the MBR, 
and this, and the partitioning, are extra effort. The upside of doing it 
this way is that the hard disk doesn't have to be the same, and you only 
overwrite the one partition, leaving the rest of the data on the 
drive intact.

cheers,

Steve Gaarder
System Administrator, Dept of Mathematics
Cornell University, Ithaca, NY, USA
[log in to unmask]

On Tue, 29 Jan 2013, Yasha Karant wrote:

> There are advantages and disadvantages of the methodology you use.  I have 
> the following questions:
>
> 1.  The SL live CD presumably requires a manual configuration of the network 
> -- this university uses /22 IPv4 subnets (we have not made the full 
> conversion to IPv6, although we support IPv6 addresses and most IPv6 
> utilities/services) and Network Manager does not seem to be able to detect 
> this.  Thus, during the SL live CD boot, the network must be manually 
> configured one machine at a time.
>
> 2.  On the target machine, one must repeat step (1) and get past LAN security 
> (assuming that the machine that contains the tar image is not on the WAN with 
> additional issues thereby created due to network security control) to untar / 
> onto the target machine.  Note that (to the best of my knowledge), tar does 
> not create the MBR (I am being specific to the IA-32/X86-64 typical boot 
> architecture in this comment) and thus requires the additional manual steps 
> you outline.  dd of an entire hard drive does clone the MBR and also 
> effectively does the formatting step of each partition (we are not using 
> logical volumes, but "old fashioned" distinct partitions).
>
> You also presume a high throughput network, depending upon the size of the 
> tar file image, as otherwise the time for getting the tar image can be 
> substantial.  Whilst the network here is adequate at switched 802.11 100BT, 
> with only limited segments at 1 Gbit/sec or higher bandwidth, the actual 
> throughput -- as measured -- can be less than 1 Mbit/sec causing substantial 
> delays.  These workstations are NOT on a 1 Gbit/sec segment, but only at 
> 100BT, and we (locally) have network issues.  As the workstations have 
> physical security locks and are cabled through raised flooring, physically 
> moving the machines to a location with a proper 1 Gbit/sec LAN segment, 
> bypassing the local university security implementations, VLAN segments, etc., 
> is a significant amount of physical work.
>
> Am I misstating your methodology?
>
> Yasha Karant
>
> On 01/29/2013 07:56 AM, Steve Gaarder wrote:
>> I've done cloning for many years with tar:
>> 
>> On the source machine, boot from an SL live CD and mount the source's
>> root file system.  Make a tar file of this system with a command like:
>> 
>> cd /mnt/wherever
>> tar -cSf - . | ssh someuser@somewhere 'cat >mysystem.tar'
>> 
>> Then, on the target, boot the live CD, partition the disk, create the
>> root filesystem and mount it.  THen untar the contents with something like:
>> 
>> cd /mnt/wherever
>> ssh someuser@somewhere cat mysystem.tar | tar -xpSf -
>> 
>> You may need to change /etc/fstab and /boot/grub/grub.conf, if the
>> partition layout is different or the files use UUIDs.  In the latter
>> case, I just change to partition names (e.g./dev/sda1).
>> 
>> Then run grub to install the boot loader:
>> 
>> grub
>> root (hd0,X)
>> setup (hd0)
>> 
>> This works great as long as the hardware is similar enough that the
>> initrd/initramfs still works.  Otherwise, there's an extra step to
>> regenerate it, which I can explain if people want.
>> 
>> Steve Gaarder
>> System Administrator, Dept of Mathematics
>> Cornell University, Ithaca, NY, USA
>> [log in to unmask]
>> 
>> On Tue, 29 Jan 2013, Yasha Karant wrote:
>> 
>>> We have a limited, small, number of IEEE 802.3 connected hardware
>>> platform identical workstations to clone -- no 802.11 nor any shared
>>> (remote, distributed) disk storage (at this time).  My plan was to get
>>> one fully operational and configured, and then clone the hard drive
>>> image onto the remaining machines one hard drive at a time.
>>> 
>>> Let A represent the operational (clone source) machine, and Bhd a
>>> target hard drive.  The hard drive on A is /dev/sda, call it Ahd.  A
>>> is shut down power off.  Bhd is installed into an available bay on A,
>>> A is booted, and Bhd appears as /dev/sdb in A.  Using dd on A, clone
>>> /dev/sda to /dev/sdb .  Mount on A the partition of /dev/sdb that
>>> contains /etc (there are no end user home directories -- only home
>>> directories are those of the system administration users).  Using a
>>> text editor (e.g., vi), modify the /etc/sysconfig/net*
>>> scripts/directories, as well as /etc/hosts. for the name and IP
>>> address of machine B that will contain Bhd (resolv.conf will be the
>>> same -- all of these machines are in the same DNS subzone, same TCP/IP
>>> subnet).  Iterate through all of the target workstation hard drives.
>>> As there are no other distributed services running, this should suffice.
>>> 
>>> Shutdown A, remove Bhd, install Bhd into B, boot B upon which Bhd
>>> should appear as /dev/sda .  Done.
>>> 
>>> Is there a better method in terms of software?  At this time, I do not
>>> want to setup a remote image server that effectively will download the
>>> full image of Ahd onto Bhd over a network, nor do I want to make a
>>> custom install DVD as we only have a small number of workstations to
>>> clone, not, say, one hundred.
>>> 
>>> I do understand that if Ahd and Bhd present different bad blocks to
>>> the OS, and these are not "hidden" by the intelligence on each
>>> individual hard drive, then dd may not work.  However, the drives
>>> already have been surveyed and the bad block situation should not be
>>> an issue.
>>> 
>>> A related question (that was partially addressed in a different
>>> thread):  is there a way to remove/disable Network Manager and use a
>>> traditional static configuration?  On a laptop that needs to move
>>> within the field from one 802.11 network to another, with a different
>>> DNS zone and TCP/IP configuration, Network Manager provides similar
>>> ease and functionality to the end user autoconfiguration applications
>>> that are used under Mac OS X or modern MS Win.  This is unnecessary
>>> and in some sense dangerous for static workstations that need no such
>>> dynamic configuration.
>>> 
>>> My thought was to find the RPM that installs Network Manager and
>>> simply uninstall it, either via yum or a simple rpm -e command.  Is
>>> Network Manager too deeply ingrained in current EL6 (using TUV
>>> compliant model) to make this feasible?
>>> 
>>> Yasha Karant
>>> 
>