On Fri, Jul 11, 2014 at 11:32 PM, Les Mikesell lesmikesell@gmail.com wrote:
Yes, that's my point, None of them do what I want a configuration tool to do. Which I'd think anyone with more than a few machines would want. And given that the packages are versioned and all that needs to happen is that the production updates need to go to the same version numbers that were tested together earlier, it doesn't seem like it should be a difficult thing for a tool to handle for you. But, I don't think there is even anything that will tell you the differences between two systems or verify that they have matching installations at the same update levels.
This has drifted profoundly from the delta rpms question, and might be better over in the userland. I'll toss in a last note, if no one minds.
Everyone in the business for a while runs into this. Almost everyone winds up writing their own, because they have subtle differences in what they want, and I'm afraid that most of them are quite amateurish and do not scale well. Full blown package management at complete RPM version and release control is theoretically straightforward. We've discussed a basic "select a template environment, record it, and propagate that package list" approach, which I've had fairly good success with in environments up to 200 hosts. And the "do it in a chroot cage", which is supported by mock based setups these days, is very helpful because it allows very fast template setup and modification, very efficiently, without actually building new hosts.
Auditing system packages is straightforward: no one I know if does it without enormous infrastructure used for other ereasons, or without simply running "ssh $hosnname rpm -qa" from an authoized central server across all the hosts. You don't need yum for that, which is a very network burdensome tool and blocks other yum activities.
But there's additional infrastructure needed. For example, the CentOS releases go out of date. If you want to replicate a stable CentOS 6.1 environment, or pull in even *one* expired package from that distribution for between your test setup and your production setup, you either have to enable and talk to the CenOS 6.1 archive server, which is not widely mirrored and therefore quite slow, or you have to set up an internal CentOS 6.1 local mirror and configure it. That's.... a bunch of extra work. A lot of admins wind up simply ignoring it and hoping the problem will not surface, much like they ignore putting passphrases on their SSH keys or much like they just disable SELinux instead of learning it. They just don't consider it worth the effort.
And until they git bit, hard, by subtle package discrepancies, they're often quite correct. It's not worth the effort, just do 'yum install' and hope for the best. It's not my approach, but it's understandable.