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.