<p dir="ltr">We've drifted this well outside distro dev and into admin theory. I'd appreciate it if you'd relocate this to the main list. </p>
<div class="gmail_quote">On Jul 12, 2014 10:41 AM, "Les Mikesell" <<a href="mailto:lesmikesell@gmail.com">lesmikesell@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jul 11, 2014 at 11:34 PM, Nico Kadel-Garcia <<a href="mailto:nkadel@gmail.com">nkadel@gmail.com</a>> wrote:<br>
>> But, I don't think there is even anything that will tell you the<br>
>> differences between two systems or verify that they have matching<br>
>> installations at the same update levels.<br>
><br>
> This has drifted profoundly from the delta rpms question, and might be<br>
> better over in the userland. I'll toss in a last note, if no one<br>
> minds.<br>
<br>
I just brought it up here on the slim chance the the rpm-building<br>
events could be used as a repository transaction id to constrain<br>
updates.<br>
<br>
> Everyone in the business for a while runs into this. Almost everyone<br>
> winds up writing their own, because they have subtle differences in<br>
> what they want, and I'm afraid that most of them are quite amateurish<br>
> and do not scale well.<br>
<br>
But that's a horrible thing to do.  When the person who wrote it<br>
leaves, no one else will know how to deal with it, and there will<br>
always be subtle changes in the underlying tools that make it need<br>
maintenance.<br>
<br>
> Full blown package management at complete RPM<br>
> version and release control is theoretically straightforward. We've<br>
> discussed a basic "select a template environment, record it, and<br>
> propagate that package list" approach, which I've had fairly good<br>
> success with in environments up to 200 hosts. And the "do it in a<br>
> chroot cage", which is supported by mock based setups these days, is<br>
> very helpful because it allows very fast template setup and<br>
> modification, very efficiently, without actually building new hosts.<br>
<br>
The part I don't understand about this is that no one would consider<br>
source code work without using a version control system that could<br>
assemble the set of file versions they want on demand.  Yet they<br>
ignore exactly the same need for the resulting binaries.<br>
<br>
> Auditing system packages is straightforward: no one I know if does it<br>
> without enormous infrastructure used for other ereasons, or without<br>
> simply running "ssh $hosnname rpm -qa" from an authoized central<br>
> server across all the hosts. You don't need yum for that, which is a<br>
> very network burdensome tool and blocks other yum activities.<br>
<br>
I run ocsinventory-ng so I actually have a central database of all<br>
installed software.   But nothing really uses it and it doesn't have a<br>
'compare' operation.<br>
<br>
> But there's additional infrastructure needed. For example, the CentOS<br>
> releases go out of date. If you want to replicate a stable CentOS 6.1<br>
> environment, or pull in even *one* expired package from that<br>
> distribution for between your test setup and your production setup,<br>
> you either have to enable and talk to the CenOS 6.1 archive server,<br>
> which is not widely mirrored and therefore quite slow, or you have to<br>
> set up an internal CentOS 6.1 local mirror and configure it.<br>
<br>
And worse, the usual scenario is that you have to replicate some other<br>
company's back-rev system to duplicate and find a bug.<br>
<br>
> That's.... a bunch of extra work. A lot of admins wind up simply<br>
> ignoring it and hoping the problem will not surface, much like they<br>
> ignore putting passphrases on their SSH keys or much like they just<br>
> disable SELinux instead of learning it. They just don't consider it<br>
> worth the effort.<br>
<br>
Yes, there is that nasty bottom line issue.  It is not cheap to<br>
retrain groups engineers to deal with the subtle problems of any<br>
single platform when they are supposed to be doing other things.  And<br>
Centos is a fairly small percentage of systems for us.<br>
<br>
> And until they git bit, hard, by subtle package discrepancies, they're<br>
> often quite correct. It's not worth the effort, just do 'yum install'<br>
> and hope for the best. It's not my approach, but it's understandable.<br>
<br>
The point of using an 'enterprise' OS is that it is never supposed to<br>
have subtle package discrepancies.  I mentioned the java versions to<br>
show there are rare exceptions.  But, going back to that bottom line<br>
issue, realistically we would have just grabbed an Oracle binary if we<br>
had to fix that one quickly.<br>
<br>
--<br>
   Les Mikesell<br>
     <a href="mailto:lesmikesell@gmail.com">lesmikesell@gmail.com</a><br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</blockquote></div>