I have need to duplicate centos 6 on 133 computers. I purchased a disk duplicator make my master and the duplicator does 11 at a time.
All is good so far...
When I take a duplicated disk and stick it in the "new" box which is different than the master machine of course all seems to work except the network.
So of course the MAC address for the NIC doesn't match so the network doesn't work.
My solution was to edit ifcfg-eth0 and remove the HDADDR line and edit udev/70-persistant-net.rules and remove the MAC address from the network SUBSYSTEM line.
The network does come back on and everything seems fine.
Is this the correct way to do this? Making a master and being able to stick the duplicated disk in another machine?
Thanks,
Jerry
On 2011-09-09 14:22, Jerry Geis wrote:
I have need to duplicate centos 6 on 133 computers. I purchased a disk duplicator make my master and the duplicator does 11 at a time.
All is good so far...
When I take a duplicated disk and stick it in the "new" box which is different than the master machine of course all seems to work except the network.
Is this the correct way to do this? Making a master and being able to stick the duplicated disk in another machine?
Take a look at automated install using pxe. That way you can install all clients identical with a short command on each client. Some scripting is of course necessary to define the kickstart scripts. Several good tutorials on this topic are available. Below is the a link to the centos intro on this.
http://www.centos.org/docs/5/html/Installation_Guide-en-US/ch-kickstart2.htm...
/THomas
On 2011-09-09 14:22, Jerry Geis wrote:
I have need to duplicate centos 6 on 133 computers. I purchased a disk duplicator make my master and the duplicator does 11 at a time.
All is good so far...
When I take a duplicated disk and stick it in the "new" box which is different than the master machine of course all seems to work except the network.
The problem (you don't mention if you figured it out or not) is that the MAC address will be wrong--one sees the same thing when cloning a VMware machine. (Or VirtualBox for that matter.)
If you go into /etc/udev/rules.d and look for the network file (probably 70-persistent-net.rules) you'll see that it will have a line for eth0 (or whatever card) with the original machine's MAC address. It will hopefully also have a new one with eth1. In VMware clones, I just delete the eth0 line, change eth1 at the end of the line to eth0, and edit the /etc/sysoconfig/network-scripts/ifcfg-eth0 to bring the hardware address in line with udev. (However, I've never had to do it on more than 2 or 3 at a time, doing it on 300 plus seems like a lot).
Take a look at automated install using pxe. That way you can install all clients identical with a short command on each client. Some scripting is of course necessary to define the kickstart scripts. Several good tutorials on this topic are available. Below is the a link to the centos intro on this.
http://www.centos.org/docs/5/html/Installation_Guide-en-US/ch-kickstart2.htm...
Thomas,
I do use PXE install, however, in this case it takes upwards of 2 hours plus for each box to install CentOS and all my "other" items.
With disk duplication I can copy 11 disks in 30 minutes.
jerry
On Fri, Sep 9, 2011 at 8:16 AM, Jerry Geis geisj@pagestation.com wrote:
Take a look at automated install using pxe. That way you can install all clients identical with a short command on each client. Some scripting is of course necessary to define the kickstart scripts. Several good tutorials on this topic are available. Below is the a link to the centos intro on this.
http://www.centos.org/docs/5/html/Installation_Guide-en-US/ch-kickstart2.htm...
Thomas,
I do use PXE install, however, in this case it takes upwards of 2 hours plus for each box to install CentOS and all my "other" items.
With disk duplication I can copy 11 disks in 30 minutes.
Clonezilla (especially with the drbl server) can do this pretty quickly over the network without having to juggle disks, but you end up with the same problem with the NICs - and in fact you will have it with any method of backing up and restoring on a different machine so it is something to consider even if you aren't cloning. On 5.x, kudzu would normally run on the new machine, rename all the NIC-related files and create new default dhcp-based copies. Not sure how 6.0 works in that respect. If it doesn't do it automatically, you could make an init script that would do it on startup and then remove itself. 6.1 is supposed to have some more sensible ways of naming the NICs but I don't know how they work yet. When I update my existing servers I'll probably work out a script that gathers all of the mac/ip/route info from the running machines into a table I can include in the master image along with the script that re-creates the configurations based on the MAC it finds.
Les Mikesell wrote:
On Fri, Sep 9, 2011 at 8:16 AM, Jerry Geis geisj@pagestation.com wrote:
Take a look at automated install using pxe. That way you can install all clients identical with a short command on each client. Some scripting is of course necessary to define the kickstart scripts. Several good tutorials on this topic are available. Below is the a link to the centos intro on this.
http://www.centos.org/docs/5/html/Installation_Guide-en-US/ch-kickstart2.htm...
<snip>
Clonezilla (especially with the drbl server) can do this pretty quickly over the network without having to juggle disks, but you end up with the same problem with the NICs - and in fact you will have it with any method of backing up and restoring on a different machine so it is something to consider even if you aren't cloning. On 5.x, kudzu would normally run on the new machine, rename all the NIC-related files and create new default dhcp-based copies. Not sure how 6.0 works in that respect. If it doesn't do it automatically, you
<snip> We've gone to upgrading using rsync, and NICs are a problem. UDEV renames the NICs - eth0 to eth2, eth1 to eth3, and so there are no ifcfg-eth? for them. Removing the MAC fixes this, including down in /etc/udev/rules.d//70-persistant-net.rules
mark, who just had that happen in the last week
On Fri, Sep 9, 2011 at 11:51 AM, m.roth@5-cent.us wrote:
Clonezilla (especially with the drbl server) can do this pretty quickly over the network without having to juggle disks, but you end up with the same problem with the NICs - and in fact you will have it with any method of backing up and restoring on a different machine so it is something to consider even if you aren't cloning. On 5.x, kudzu would normally run on the new machine, rename all the NIC-related files and create new default dhcp-based copies. Not sure how 6.0 works in that respect. If it doesn't do it automatically, you
<snip> We've gone to upgrading using rsync, and NICs are a problem. UDEV renames the NICs - eth0 to eth2, eth1 to eth3, and so there are no ifcfg-eth? for them. Removing the MAC fixes this, including down in /etc/udev/rules.d//70-persistant-net.rules
So how do you know which NIC is which then? Most of my boxes have 4 to 6 and they appear in random order (well, flipped in pairs by driver) on reboots without being anchored with MAC addresses? I need each one to keep the same IP and associated routes.
Les Mikesell wrote:
On Fri, Sep 9, 2011 at 11:51 AM, m.roth@5-cent.us wrote:
Clonezilla (especially with the drbl server) can do this pretty quickly over the network without having to juggle disks, but you end up with the same problem with the NICs - and in fact you will have it with any method of backing up and restoring on a different machine so it is something to consider even if you aren't cloning. On 5.x, kudzu would normally run on the new machine, rename all the NIC-related files and create new default dhcp-based copies. Not sure how 6.0 works in that respect. If it doesn't do it automatically, you
<snip> We've gone to upgrading using rsync, and NICs are a problem. UDEV renames the NICs - eth0 to eth2, eth1 to eth3, and so there are no ifcfg-eth? for them. Removing the MAC fixes this, including down in /etc/udev/rules.d//70-persistant-net.rules
So how do you know which NIC is which then? Most of my boxes have 4 to 6 and they appear in random order (well, flipped in pairs by driver) on reboots without being anchored with MAC addresses? I need each one to keep the same IP and associated routes.
Yeah, I wasn't thinking of that. At some point, I should probably go back into that rulefile and fix it. Hmmm, or write a simple script....
mark
From: Jerry Geis geisj@pagestation.com
When I take a duplicated disk and stick it in the "new" box which is different than the master machine of course all seems to work except the network. Is this the correct way to do this? Making a master and being able to stick the duplicated disk in another machine?
Not sure but maybe also regenerate the server's ssh keys..?
JD
On Mon, 12 Sep 2011, John Doe wrote:
From: Jerry Geis geisj@pagestation.com
When I take a duplicated disk and stick it in the "new" box which is different than the master machine of course all seems to work except the network. Is this the correct way to do this? Making a master and being able to stick the duplicated disk in another machine?
Not sure but maybe also regenerate the server's ssh keys..?
Good idea. I think you can just delete them off the image, and they'll get automatically generated on first boot. I'm almost surprised you can't do the same with the network (by just deleting the ifcfg-eth* files).
jh
-
Jerry Geis -
John Doe -
John Hodrien -
Les Mikesell -
m.roth＠5-cent.us -
Scott Robbins -
Thomas Johansson