With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
Thanks, Jon
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
Thanks, Jon
It is certainly better to upgrade with less things running as a general practice.
One should never update from a Remote X type connection via VNC or NX, etc.
The absolute safest way to upgrade would be to do so via the console and a keyboard on the actual machine if there is some issue with sshd, etc.
But generally, this upgrade should be OK via ssh, etc.
Johnny Hughes wrote:
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
It is certainly better to upgrade with less things running as a general practice.
One should never update from a Remote X type connection via VNC or NX, etc.
The absolute safest way to upgrade would be to do so via the console and a keyboard on the actual machine if there is some issue with sshd, etc.
But generally, this upgrade should be OK via ssh, etc.
On our about 200 workstations and servers, we just ssh in and run the yum update. Workstations... we co-ordinate with the user, and yes, it's better if they log off. Still, ssh in has always been fine (unless you have to worry about the video, such as NVidia or AMD proprietary video drivers).
mark
Am 27.01.2017 um 17:27 schrieb m.roth@5-cent.us:
Johnny Hughes wrote:
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
It is certainly better to upgrade with less things running as a general practice.
One should never update from a Remote X type connection via VNC or NX, etc.
The absolute safest way to upgrade would be to do so via the console and a keyboard on the actual machine if there is some issue with sshd, etc.
But generally, this upgrade should be OK via ssh, etc.
On our about 200 workstations and servers, we just ssh in and run the yum update. Workstations... we co-ordinate with the user, and yes, it's better if they log off. Still, ssh in has always been fine (unless you have to worry about the video, such as NVidia or AMD proprietary video drivers).
In such scenario (xxx packages to update) I normally split the update command into
# yum clean all # yum update glibc* rpm* yum* # yum update # reboot
-- LF
On Fri, Jan 27, 2017 at 06:05:54PM +0100, Leon Fauster wrote:
Am 27.01.2017 um 17:27 schrieb m.roth@5-cent.us:
Johnny Hughes wrote:
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
...
In such scenario (xxx packages to update) I normally split the update command into
# yum clean all # yum update glibc* rpm* yum* # yum update # reboot
The update to glibc*, wouldn't that replace the current versions on disk? If so, wouldn't there be a problem if one had to reboot before the yum update could run or complete. Or do applications not need specific glibc versions but only version X or newer.
Jon
On Fri, January 27, 2017 12:19 pm, Jon LaBadie wrote:
On Fri, Jan 27, 2017 at 06:05:54PM +0100, Leon Fauster wrote:
Am 27.01.2017 um 17:27 schrieb m.roth@5-cent.us:
Johnny Hughes wrote:
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
...
In such scenario (xxx packages to update) I normally split the update command into
# yum clean all # yum update glibc* rpm* yum* # yum update # reboot
The update to glibc*, wouldn't that replace the current versions on disk? If so, wouldn't there be a problem if one had to reboot before the yum update could run or complete.
Theoretically this wouldn't be a problem, as execution of next yum command after installation of new yum and glibc will load new image of glibc into RAM, and will be happy, but other stuff that still runs may not (as they will be expecting to use old glibc image). So, last but one line before reboot in his script has no reason to fail. I'm sure this is his production script or sequence of commands, so he experimentally confirms the above.
Just my $0.02
Valeri
Or do applications not need specific glibc versions but only version X or newer.
Jon
Jon H. LaBadie jon@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C) _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, January 27, 2017 10:27 am, m.roth@5-cent.us wrote:
Johnny Hughes wrote:
On 01/27/2017 09:19 AM, Jon LaBadie wrote:
With a large update to be made, eg. the 900 package one I questioned yesterday, are there any suggestions to avoid possible complications?
Two examples, I'd like to know of others too:
I'm not running the most recently installed kernel, I assume I should reboot to that.
I normally have a graphical environment running. Would it be better to: a) shutdown X and update from a straight CLI environment b) logout from the GUI and update from a vt CLI c) update from a GUI login as root or d) doesn't matter, do as normal -- from an ssh login, "sudo yum update"?
It is certainly better to upgrade with less things running as a general practice.
One should never update from a Remote X type connection via VNC or NX, etc.
The absolute safest way to upgrade would be to do so via the console and a keyboard on the actual machine if there is some issue with sshd, etc.
But generally, this upgrade should be OK via ssh, etc.
On our about 200 workstations and servers, we just ssh in and run the yum update. Workstations... we co-ordinate with the user, and yes, it's better if they log off. Still, ssh in has always been fine (unless you have to worry about the video, such as NVidia or AMD proprietary video drivers).
On comparable number of workstations and number crunchers (servers as well in the past, but now servers are running FreeBSD) we just run "yum -y update" command over ssh remotely. Before doing that we check what this new updates do on similar system(s) on virtual machine(s). We only notify users before update when something is expected to affect them, like glibc update (they are OK after update with image of old glibc in RAM until starting new application loads new glibc image... But we do schedule reboot with users who do not log off or constantly run their code (or vnc, screen,...) on workstations when we need to reboot because of kernel or glibc. As far as proprietary video drivers are concerned: Mark put it best. You need to restart whatever daemons were updated or use libraries that were updated. Incidentally, restarting sshd does not disrupt existing ssh connections.
<rant> Even with having to notify users/schedule reboots as rarely as once every 54 days on average, this is really PITA, because it is often. That, BTW is why we fled our servers away from Linux ;-( </rant>
Just my $0.02
Valeri
mark
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
--On Friday, January 27, 2017 11:11 AM -0600 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
<rant> Even with having to notify users/schedule reboots as rarely as once every 54 days on average, this is really PITA, because it is often. That, BTW is why we fled our servers away from Linux ;-( </rant>
Towards what? What other system has few updates and yet remains secure and bug-free?
I know I dread when Windows drops a pile of updates, as I'm never sure it's going to come back up.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Fri, January 27, 2017 11:48 am, Kenneth Porter wrote:
--On Friday, January 27, 2017 11:11 AM -0600 Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
<rant> Even with having to notify users/schedule reboots as rarely as once every 54 days on average, this is really PITA, because it is often. That, BTW is why we fled our servers away from Linux ;-( </rant>
Towards what? What other system has few updates and yet remains secure and bug-free?
You are right. None of them are bug free, you have to update, update, update... any one of them. With FreeBSD (sorry for mentioning, I promised once I wouldn't...) I only had to reboot the machines with about 200 days uptime last time. 4 - 5 times less often than Linux. (Of course, we are not going to go into other differences which are beyond updates, and what glibc and kernel updates entail).
I'm not certain, if I had to put my answer into rant tags... please do it for me if you feel it is.
Valeri
I know I dread when Windows drops a pile of updates, as I'm never sure it's going to come back up.
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
-
Johnny Hughes -
Jon LaBadie -
Kenneth Porter -
Leon Fauster -
Leonard den Ottolander -
m.roth＠5-cent.us -
Valeri Galtsev