[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: A new utility to augment yum - machine cloner



Horst H. von Brand wrote:
David Timms <dtimms 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]