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.
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
