On Fri, January 27, 2017 10:27 am, m.roth@xxxxxxxxx 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@xxxxxxxxxx
> 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
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
