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. Thank you! -- Chris O'Regan <[log in to unmask]> Senior Unix Systems Administrator, Academic IT Services Faculty of Engineering and Computer Science Concordia University, Montreal, Canada