SCIENTIFIC-LINUX-USERS Archives

January 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Wed, 28 Jan 2015 13:51:51 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (38 lines)
On 28/01/15 10:35, John Rowe wrote:
>
> And indeed, if yum updates a daemon due to security fixes does the
> daemon restart?

Yes and no.  It mostly depends on what kind of package has been updated.
 Some packages triggers restart of daemons, some does not.  Generally
speaking, packages such as httpd, postfix, openssh-server and such
usually restarts the service when the package is updated.

But for library packages it may be mixed.  Some times daemons are
restarted, but it usually depends on helper scripts (which glibc does
have).  But having that said, it doesn't mean all daemons are restarted.

> If it doesn't protect us is there practicable way to make sure we are
> genuinely protected short of rebooting the whole system every time there
> is a security update?

I generally treat core system libraries (such as glibc) on the same line
as kernel updates.  So I try to do a reboot as soon as possible.
Depending on the severity of the system library update and the time
until I can schedule a reboot defines if I do a restart of critical
daemons.  Generally I only restart daemons using the network, but I have
very few boxes where users log into with shell access.

All non-restarted processes will use the old library until it is
restarted.  This is why a reboot is helpful when core system libraries
are updated, it reassures you that all processes use the latest code.
And having a reboot every now and then is also good sys-admin practice,
to ensure the setup/configuration is always persistent - for the times
if an abrupt reboot happens.


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2