On Mon, May 28, 2012 at 3:30 PM, Chris O'Regan <ch...@encs.concordia.ca>wrote:
> We are in the process of patching our hosts, going from SL5.7 to SL5.8. > After updating a couple of systems, we found a handful of rpmnew/rpmsave > files for some of the files that we've customized, and so we merged the > changes. These files are copied via cfengine, and we have some scripts > that handle cleaning up the rpmnew/rpmsave files that we've already > addressed. In preparation for patching the rest of our systems, we > pushed out the new files, but to our surprise, the systems we had just > updated to SL5.8 still had the old files! Those still at SL5.7 had > received them as expected. > > After some investigation, we discovered that the default cfengine > classes have changed in SL5.8, and as a result, some of our cfengine > scripts were no longer functioning correctly. Here are the SL-related > classes that are defined in SL5.7: > > scientific > scientific_sl > scientific_sl_5 > scientific_sl_5_7 > scientificsl > scientificsl_5 > scientificsl_5_7 > scientificsl_boron > > And here's what are defined in SL5.8: > > scientific > scientific_5 > scientific_5_8 > scientific_boron > > We were making use of the 'scientific_sl' and 'scientific_sl_5' classes, > but now those no longer exist. It was simple enough to fix our cfengine > scripts (e.g. 'scientific_sl' is now '(scientific|scientific_sl)') but > we are puzzled as to why this would change so suddenly and quite > concerned that such an unexpected change could possibly break our > systems. > > Our version of cfengine has not changed and it is not installed as part > of the operating system but within our own software tree. For the sake > of completeness, however, it is v2.2.9. I'm not exactly sure how > cfengine generates these classes, but I think it is based on the text > in /etc/issue. I see that there has been a slight change: > > Scientific Linux SL release 5.7 (Boron) > Scientific Linux release 5.8 (Boron) > > It neatly explains where the 'sl' went from the cfengine default > classes! :-) While we have our work-around, I think it would be kind to > put the 'SL' back into /etc/issue for others who may be facing a similar > situation. > > Gahhh!!!! Thanks for the heads up, I was looking at cfengine for a project. Parsing /etc/issue.net is a tradional quagmire, but much faster and lighter weigbht than trying to run "rpm" commands. Looks like a problem to notify the cfengine maintainers of.
