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

Re: A new utility to augment yum



Jon Ciesla wrote:
Hi.  I'm an unsponsored, aspiring Extras contributor and author of
Yumdiff, a tool to help quickly determine and resolve differences in the
software installed on two Fedora machines.  I submitted a review request,
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206478, and after the
initial round of corrections to my packaging, there have been suggestions
made concerning Yumdiff's functionality.  I've refined Yumdiff somewhat in
response to this, and the suggestion was made to solicit feedback from the
Extras and Yum communities with regard to Yumdiff's potential niche in the
greater ecosystem.

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.

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.

2. If this is a useful itch to have scratched, is Yumdiff the best way to
scratch it?

2a. Might this functionality be better included in Yum?
I would think not.
Is there a security risk in allowing a tool to make connections to other machines where you have to provide the remote password ?

3. If 1==yes, 2==yes and 2a==no, are there any other features that should
be included in Yumdiff?

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. Given a remote known, working machine to mirror the package installation of:
- check connect ability
- get /etc/fedora-release to check distro + version {might want to ignore - any rpm distro might be reasonable, but would need a warning of not same dist/release}
- get it's list of packages and versions.
- yum check-update of remote so can inform user if remote machine is not up2date. - yum update {perhaps optionally, but it is generally difficult to install old fedora packages - ie if a remote machine had not been updated recently - the old package files disappear from most mirrors.
- yum install {is this OK ? Y } any packages not on the remote
- yum remove {is this OK ? } any packages that aren't on the remote
  - if no {would you like to remove packages one at a time ? - etc }
- give a final result comparison of the continued differences

Perhaps a name like:
yum-machine-package-mirror
yum-mirror-remote-packages would be clearer (for such a capability).

as well as a "supercompare" mode which would allow
updating the local machine to include a superset of the packages on
multiple remote machines.  Are these attractive, or would they be a step
toward feature bloat?
I would have only one use for such a feature - my internal yum repository. All other internal machines can be yum configured to only get files from this machine, so that there is no way to {automatically} install packages if they are not on the internal yum repo.

But to get the internal yum repo to have all the packages that the differing servers use is currently manual download; such a tool would be nice.

I'm open to any and all suggestions, and am looking forward to a frank
dialog with all interested parties.
Would you be able to put the raw scripts or a tar.gz on your web site, rather than in the package, so that we can more easily take a look at the underlying code ? {by the way, the .spec url must include a source line like:
Source0:	http://serverhost.my/~mine/%{name}-%{version}.tar.gz
that actually works, there is no harm in doing this while developing.

It would also make sense to version the code starting at 0.1, moving to 0.1.1 etc. 1.0 suggests a certain amount of community testing and quality {this will work anywhere, and there is no known crashes etc}, documentation is good etc.

Also, being able to to the diff against a local file that provides the remote file list would be good {ie if the remote machine is dead, you could still use the tool to build a {near} identical {packages} machine.

DaveT.


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