On Fri, January 27, 2017 10:27 am, m.roth at 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 at 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 ++++++++++++++++++++++++++++++++++++++++