On Wed, Jan 13, 2016 at 10:51:26AM -0600, Jim Campbell wrote:
> 
> As I understand it, one of the key values of SL is that it allows you to
> stay on a point release and obtain only security fixes for your packages
> (someone else mentioned this, too). This is important when running
> scientific experiments where you can't allow changes in software to
> impact your research results. Unless something has changed, neither
> CentOS nor the North American Upstream Vendor provide this service. This
> feature from Scientific Linux is a valuable one if you need it.
> 


Something strange happened during the move from el6 to el7 - 

CERN Linux el6 was always automatically self-updating to latest point release,
without causing any problems, so I came to like that and now configure SL6 
machines
to automatically update (using the SL6x repo).

Now CERN Linux el7 comes in and I see the machines installed as 7.1 stay there,
no automatic update to 7.2. Odd.

Then here, I see same with CentOS7 - no automatic updates by default, no 
automatic
updates to latest point release, 7.1 machines stay at 7.1. (I do not have any 
SL7 to compare)

So I am puzzled by all this. Maybe I should ask google: "is centos7 supposed to 
self update to latest point release?"


Then I takes quite a bit of work to get automatic updates to work at all on 
CentOS7
(CERN el7 seems to be okey):

a) The yum.cron package is crazy - each time I need to use yum, I have to wait
until it finishes some useless background tasks. Then "yum remove yum.cron" has
no effect because all the cron jobs are part of the main yum package. Go figure.

b) the CERN yum-autoupdate package, which we use for SL6 updates, depends
on a yum plugin not available anywhere (except from a CERN repo) and then 
actually
does not work out of the box because of strange interaction with systemd - only 
works after a reboot.

bb) then it does not send any email about updates - the el6 yum-autoupdate did 
this,
where did this function go?!?

(Hmm... maybe I should try these auto update scripts from the SL7 repository?)


So as they say, 1 step forward, 2 steps back.


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Reply via email to