Horst H. von Brand wrote:
David Timms <dtimms@xxxxxxxxxxxx> 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.
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
