A new utility to augment yum - machine cloner

[David Timms]

Horst H. von Brand wrote:
> David Timms <dtimms at iinet.net.au> wrote:
>> Jon Ciesla wrote:
> 
> [...]
> 
>>> My primary questions are these:
>>> 1. Yumdiff scratched my itch, namely to quickly compare machines to
>>> achieve software parity.  It was born in a data center composed of
>>> machines that change roles on a semi-regular basis.  Does it scratch
>>> anyone else's itch?
> 
>> Yes, often, I will want to move the complete configuration from one
>> machine to another, before "putting down" the old machine. I had been
>> thinking recently how I could script this to save time. The machines
>> are performing server roles with a reduced set of packages.
> 
> Easy:
> 
>    system-config-kickstart --generate /some/file
> 
> edit to taste, backup the local configuration tweaks.
   /\  this was the bit to actually avoid by using such a process. I 
have previously used the install generated ks.cfg, but found you need to 
tweak all the other bits of the ks to suit the local environment and 
machine, but the use of --generate at least get the package list entered.

There is also a need to get packages installed from outside the 
core/extras collective.

>> While kickstart capability is great, I have not tended to customize a
>> new kickstart file for every different machine. I just use
>> kickstart/network install to get the machine to a known state before
>> removing unneeded packages.
> 
> You can remove them in the kickstart file. It saves lots of time and
> aggravation (axed something that was needed, etc).
Currently I just use one ks.cfg for each machine architecture {x2}, 
having to make changes to this pair when I needed to change them was 
annoying enough, without having a series of ks.cfg for every machine.

note: I did read that it is possible to cascade ks files, so that 
certain settings could be pulled in from say a global.ks.cfg, but having 
machine specific commands in eg otrs-server.ks.cfg Unfortunately, I have 
yet to succeed in making a network book kickstart able to get the 
included file.

I guess a nicer why to get the local configuration tweaks like ip 
address, logins, dns, etc, could be to use rpm -qa to determine what are 
the modified config files, and script a backup of just those files.

>>> I'm contemplating/playing around with a feature that would use screen
>>> on the local machine to allow remotely updating multiple machines to
>>> match the local machine,
> 
>> I think this would be the most useful capability.
> 
> Not needed, if you have a kickstart file for the source machine.
While I can see the benefit {security / known starting point} I have 
needed to a few times get a machine that is already installed {ie raid 
already setup, partitioned, formatted and os operating} to match another 
package wise, in trying to determine if a fault is a bug or 
misconfiguration on my part. Reinstalling from scratch by kickstart 
would seem to waste more time.

Horst: knowing that you would be unlikely to use such a python/yum tool, 
do you see any specific problems with the general design of Jon's tool, 
for example in terms of security, or practical application that would be 
a show stopper in terms of fedora inclusion ?
For example would it be important for the developer of such a tool to 
*not* be the fedora packager for it, so that a separate individual is in 
the loop to verify / quality assure the underlying source before 
requesting builds ?

DaveT.