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@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
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
Robert P. J. Day wrote:
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.
The students you need to teach things like this are the ones that will never become good admins.
On Thu, 22 Feb 2018, hw wrote:
Robert P. J. Day wrote:
... snip ...
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.
The students you need to teach things like this are the ones that will never become good admins.
uh, that's kind of a condescending attitude to take towards students who simply want to learn. are you this way with everyone?
rday
Robert P. J. Day wrote:
On Thu, 22 Feb 2018, hw wrote:
Robert P. J. Day wrote:
... snip ...
oh, i appreciate the need for caution; on the other hand, italways 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 problemwith 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.
The students you need to teach things like this are the ones that will never become good admins.
uh, that's kind of a condescending attitude to take towards students who simply want to learn. are you this way with everyone?
Yes, and there´s nothing condescending about this. A student who is too chicken to try out basic things, be it within dedicated testing environments or, if need be, otherwise, will not become a good admin and is probably not a person well suited to bearing the responsibility that will be bestowed upon them, partly due to a lack of good judgement.
I think that is something you should teach your students --- in the hope that their attitude may change. Isn´t that your intention to begin with?
On Feb 22, 2018, at 9:34 AM, hw hw@gc-24.de wrote:
Robert P. J. Day wrote:
On Thu, 22 Feb 2018, hw wrote:
The students you need to teach things like this are the ones that will never become good admins.
uh, that's kind of a condescending attitude to take towards students who simply want to learn. are you this way with everyone?
Yes, and there´s nothing condescending about this. A student who is too chicken to try out basic things, be it within dedicated testing environments or, if need be, otherwise, will not become a good admin and is probably not a person well suited to bearing the responsibility that will be bestowed upon them, partly due to a lack of good judgement.
I was going to let this go, as we’re getting farther and farther from CentOS, but this has been bothering me. I don’t think you’ve evaluated how the attitude expressed in your statement would tend to encourage hotshots who dive in and make changes without knowing enough, and would tend to weed out inexperienced potential sysadmins who have any degree of caution. Confidence comes from knowledge, knowledge comes from practice… and there are a lot of potential sysadmins from non-standard backgrounds who have the potential to be great at the work, but need extra encouragement in the beginning, with a safe place to learn and make mistakes.
If my past teachers and mentors had had the attitude you expressed there, I’d never have gotten into systems administration—and I can tell that I’m going to be a good sysadmin, so that would have been a shame. (I’ve been in systems administration for a grand total of about five months, after over a decade in related IT work.)
Liza Furr
-
hw -
Liam O'Toole -
liza＠avoke.com -
Pete Biggs -
Robert P. J. Day