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 at 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, 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 ++++++++++++++++++++++++++++++++++++++++
--On Friday, January 27, 2017 11:11 AM -0600 Valeri Galtsev <galtsev at 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, Jan 27, 2017 at 06:05:54PM +0100, Leon Fauster wrote:> > Am 27.01.2017 um 17:27 schrieb m.roth at 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 > # rebootThe 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 -- Jon H. LaBadie jon at jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)