A new utility to augment yum

[David Timms]

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.