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
gaar...@math.cornell.edu
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
--
Mr. Mark V. Stodola
Senior Control Systems Engineer
National Electrostatics Corp.
P.O. Box 620310
Middleton, WI 53562-0310 USA
Phone: (608) 831-7600
Fax: (608) 831-9591
