Large Update – Best Practice

Home » CentOS » Large Update – Best Practice
CentOS 9 Comments

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

9 thoughts on - Large Update – Best Practice

  • 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 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

  • 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

  • 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.


    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 ;-(

    Just my $0.02

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • –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.

  • 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

  • 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

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • 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

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

LEAVE A COMMENT