CentOS - Feb 2018 - a few simple questions about upgrading an "official" centos 7 release

again, some fairly trivial(?) questions about working with centos
7.4, given my time immersed in fedora so i want to make sure i'm not
carrying over any bad habits.

  first, is there anything untoward in updating an installed version
of centos 7.4 with a simple "yum update"? i'm well aware of
keeping in
mind the goal of stability with centos, so am unsure what the
philosophy is of pulling in new updates as cavalierly as i do with
fedora. currently, "yum list updates" shows me 206 possible updates;
should i have any concern about updating packages coming from the
standard centos repos?

  next, are there any issues replacing yum wihth dnf? i found this
piece:

https://www.vultr.com/docs/use-dnf-to-manage-software-packages-on-centos-7

which suggests it shouldn't be a problem. thoughts?

  finally, any concerns i should have about upgrading the kernel from
3.10 to 4.14 or 4.15, as explained in a number of places like this:

https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/

  i simply prefer to run a current kernel but i can resist the
temptation if upgrading that on a centos 7.4 system would introduce
more problems than are worth it.

  thoughts?

rday

On 2018-02-22, Robert P. J. Day
<rpjday at crashcourse.ca> wrote:
>
>   again, some fairly trivial(?) questions about working with centos
>   7.4, given my time immersed in fedora so i want to make sure i'm not
>   carrying over any bad habits.
>
>   first, is there anything untoward in updating an installed version
>   of centos 7.4 with a simple "yum update"? i'm well aware of
keeping
>   in mind the goal of stability with centos, so am unsure what the
>   philosophy is of pulling in new updates as cavalierly as i do with
>   fedora. currently, "yum list updates" shows me 206 possible
updates;
>   should i have any concern about updating packages coming from the
>   standard centos repos?
No. The updates provided over an x.y series are relatively minor and
generally well tested. It's very different to the version churn
associated with Fedora. The updates also include important security
fixes, and it's not advisable to try to apply those in isolation. But I
would add the usual caveat: if you're doing anything business-critical
with your installation, test the upgrade on comparable hardware first.
>
>   next, are there any issues replacing yum wihth dnf? i found this
> piece:
>
> https://www.vultr.com/docs/use-dnf-to-manage-software-packages-on-centos-7
>
> which suggests it shouldn't be a problem. thoughts?
Being from the EPEL repository, dnf is not supported by CentOS. So I
would avoid using it on a machine which serves a critical function.
>   finally, any concerns i should have about upgrading the kernel from
> 3.10 to 4.14 or 4.15, as explained in a number of places like this:
>
> https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/
>
>   i simply prefer to run a current kernel but i can resist the
> temptation if upgrading that on a centos 7.4 system would introduce
> more problems than are worth it.
>
>   thoughts?
Again, EL Repo packages are not supported by CentOS. Therefore the above
warnings apply here too.

If, on the other hand, you can afford to tinker with the system and
experiment a bit, then go for it. Oh, and welcome to the CentOS
community.
>
> rday
-- 

Liam

> 
>   finally, any concerns i should have about upgrading the kernel from
> 3.10 to 4.14 or 4.15, as explained in a number of places like this:
> 
> https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/
> 
>   i simply prefer to run a current kernel but i can resist the
> temptation if upgrading that on a centos 7.4 system would introduce
> more problems than are worth it.
> 
The only reason to use a kernel version that isn't provided with the
distro is if the newer kernel provides features that you **NEED**.

Remember, the whole point of something like CentOS is to provide a
stable, solid OS. This requires a whole bunch of testing of the OS as a
whole - and RHEL (and hence CentOS) does all that testing using kernels
it provides. What's more RH will backport critical kernel updates if
appropriate - so it's not the case that an older kernel is lacking in
security.

I seem to remember you said you were going to teach using these
machines - surely you want those machines to be as stable and as
standard as possible to the machines the students will find in the
wild. I would definitely not encourage students to upgrade kernels -
novices sysadmins don't need an extra level of uncertainty in their
life!

P.

On Thu, 22 Feb 2018, Pete Biggs wrote:
>
> >
> >   finally, any concerns i should have about upgrading the kernel from
> > 3.10 to 4.14 or 4.15, as explained in a number of places like this:
> >
> > https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/
> >
> >   i simply prefer to run a current kernel but i can resist the
> > temptation if upgrading that on a centos 7.4 system would introduce
> > more problems than are worth it.
> >
> The only reason to use a kernel version that isn't provided with the
> distro is if the newer kernel provides features that you **NEED**.
>
> Remember, the whole point of something like CentOS is to provide a
> stable, solid OS. This requires a whole bunch of testing of the OS
> as a whole - and RHEL (and hence CentOS) does all that testing using
> kernels it provides. What's more RH will backport critical kernel
> updates if appropriate - so it's not the case that an older kernel
> is lacking in security.
>
> I seem to remember you said you were going to teach using these
> machines - surely you want those machines to be as stable and as
> standard as possible to the machines the students will find in the
> wild. I would definitely not encourage students to upgrade kernels -
> novices sysadmins don't need an extra level of uncertainty in their
> life!
  oh, i appreciate the need for caution; on the other hand, it always
struck me that the training room is the *ideal* place for students to
experiment with things they're too nervous or unsure of to try back at
the office. this is typically why, when i'm teaching, i save friday
afternoon for trying things that are typically not covered by standard
courseware.

  so as long as one delivers the proper caution, i see no problem with
something like, "ok, you might never have to do this at your site, but
just in case you ever need to upgrade your kernel, let's try it and
see what happens." so if the need ever arises, at least they can say
they've done it once and know what the end result is supposed to be.

rday