On Mon, May 28, 2012 at 3:30 PM, Chris O'Regan <[log in to unmask]>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.