On 01/29/2013 08:55 AM, Mark Stodola wrote:
> On 01/29/2013 10:43 AM, 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
>>>>
>
> As this is a support mailing list, people are not intimately
> knowledgeable of other users' environments and hurdles.  At some point,
> the help and information provided must be digested and handled by the
> person seeking help instead of over-analyzing every angle of a
> suggestion.  Typically what is expected is a nudge in a direction, not a
> fully fleshed out IT plan.  At some point, you need to think for
> yourself and take responsibility.  If you are not a system administrator
> in your organization, might I suggest seeking their advice?  They
> perhaps may already have a cloning solution that will work well for your
> needs.
>
> -Mark
>

Mark,

It is not a question of getting a "nudge in the right direction" or the 
specific details of a particular network.  I personally do have the 
necessary experience and actually teach this material (albeit not 
strictly to technicians -- but rather to computer scientists who need to 
understand the technology, the practice, as well as the underlying 
concepts).  However, there are numerous contributors (and presumably 
readers) on this list who do not -- and from what I have read, attempt 
to take suggestions ("nudges") as the literal best method.  Thus, by 
clarifying the assumptions under a particular approach, one gets at 
least some engineering idea of the possible limitations in applicability 
of various approaches -- and the unwary may realize the need to consider 
first, act second.  I am not listing herein the engineering criteria 
that are needed for an appropriate solution to a problem.

I am looking into the "ghost" applications mentioned as these may indeed 
be a better solution.

Yasha