Is there anything terribly unique on this that you couldn't take the /root/anaconda.ks file and adjust the partitions (partition lines always commented out) and use that file to make a kickstart of the current system?

There are some issues when you clone a system, one example, the host keys under /etc/ssh/*key will be the same, and that's generally "not good" to have identical host keys across two systems.

Is there some exotic third party software on this system you wish to "clone"? Could you kickstart a new system from the anaconda.ks file (as a starting point) and then perhaps rsync data from one system to another if that's important? Some ideas for cloning have been given in posts prior to mine, but give us an idea of the role of the system. If it's some really unique system, or some generic system that could be kickstarted and some configs carried over? Also what version of Red Hat (or Oracle Linux, or whatever version of Linux) are you using?

Thanks,

RJ

Couldn't agree with you more Christian, and nice example there. There's certainly multiple issues with cloning a system that we've not presented here. When someone comes to me saying they want to "clone" a system, I generally always ask them the role of the previous server, the intent of the new server and then attempt to use a fresh build.

Overwhelmingly it's a better choice, however there are some instances where it is valid, but if one really does clone a system, there's a number of things (for sanity) they really need to do to the new system afterwards.

If the old system is RHEL 6 and they want to clone it, it would be better to make a rhel 7 system if possible and mimic the role from the old to the new. There might be degraded or non-updated third party software that might chain someone to an older version of RHEL (version 6.x), however support for RHEL 6 is going away in 2020 and it's 2018 now.

Thanks for the additional info Christian

Regards,

-RJ

Ibrahim, there is a way to put a kickstart on a DVD and add the necessary items to the dvd menu for whatever kickstarts you wish. I've done this on occasion. There are other things, such as MAC addresses buried in other places than the usual locations as well. I have a checklist for systems we've cloned with VMware. We also modify the install date to the rpm named "basesystem" on the newly created (cloned) system (either Jan or Tom here in the Red Hat forums I believe gave us that tip here in the discussion forums some years ago).

There is no RH article for the below... This is intended for the ####cloned system

The idea here is to make the system unique from the previous one you just cloned it from.

• When you clone a system, the original system build date is recorded in the “basesystem” rpm.
• Unless this procedure is ran, the cloned system inherits the improper date from the system it was cloned from.
• This should be ran after the system was cloned to reflect a sensible date.

# yumdownloader basesystem
# rpm -q --qf '%{installtime:date}\n' basesystem
Tue 12 Jul 2016 11:24:06 AM EDT  # something from long ago
# rpm -i --force --justdb basesystem-VERSION.elX.noarch.rpm (YOUR RPM WILL BE DIFFRENT)
# rpm -q --qf '%{installtime:date}\n' basesystem
Wed 1 Aug 2018 09:21:13 PM EDT # something more current

• When you clone a system, the original system build date is recorded in the “basesystem” rpm.

rm -rf /etc/ssh/ssh_host_*
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key 
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key 
ssh-keygen -f  /etc/ssh/ssh_host_key

echo you might be using different keys if using FIPS or whatever your security folks wish.

/etc/ssh/ssh_host_ecdsa_key The ECDSA private key used by the sshd daemon. /etc/ssh/ssh_host_ecdsa_key.pub The ECDSA public key used by the sshd daemon.

touch /.unconfigured
echo not vetted for rhel7

rm -f /etc/sysconfig/rhn/systemid
service osad stop
# rm /etc/sysconfig/rhn/systemid /etc/sysconfig/rhn/osad-auth.conf

• https://access.redhat.com/discussions/916133
• https://access.redhat.com/solutions/198693
• https://access.redhat.com/solutions/271643
• https://access.redhat.com/discussions/916563

Remove unique network details including ifcfg scripts • At a minimum, replace or remove the HWADDR and Static lines from /etc/sysconfig/network-scripts/ifcfg-eth[x] • Also making sure the same content is in the following files, if they exist:

file /etc/sysconfig/networking/devices/ifcfg-eth[x]
file /etc/sysconfig/networking/profiles/default/ifcfg-eth[x] 
rm -f /etc/udev/rules.d/70-persistent-net.rules

If you are cloning a rhel6 system, consider building a fresh new RHEL 7 system and mimicking/adjusting the system to do what the previous one did.

Regards,

RJ