[CentOS-devel] Delta RPMs disabled by default?

[Nico Kadel-Garcia]

On Fri, Jul 11, 2014 at 11:32 PM, Les Mikesell <lesmikesell at 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.