CentOS - Dec 2011 - why not have yum-updatesd running by default?

Ever since someone told me that one of my servers might have been hacked
(not the most recent instance) because I wasn't applying updates as soon as
they became available, I've been logging in and running "yum
update"
religiously once a week until I found out how to set the yum-updatesd
service to do the equivalent automatically (once per hour, I think).

Since then, I've leased dedicated servers from several different companies,
and on all of them, I had to set up yum-updatesd to run and check for
updates -- by default it was off.  Why isn't it on by default?  Or is it
being considered to make it the default in the future?

Power users can always change it if they want; the question is what would
be better for the vast majority of users who don't change defaults.  In
that case it would seem better to have updates on, so that they'll get
patched if an exploit is released but a patch is available.

If the risk is that a buggy update might crash the machine, then that has
to be weighed against the possibility of *not* getting updates, and getting
hacked as a result -- usually the latter being worse.

After all, if users are exhorted to log in to their machines and check for
updates and apply them, that implies that the risk of getting hosed by a
buggy update is outweighed by the risk of getting hacked by not applying
updates.  If that's true for updates that are applied manually, it ought to
be true for updates that are downloaded and applied automatically,
shouldn't it?

Bennett

On Wed, Dec 28, 2011 at 4:04 PM, Bennett Haselton <bennett at
peacefire.org> wrote:
> Power users can always change it if they want; the question is what would
> be better for the vast majority of users who don't change defaults. ?In
> that case it would seem better to have updates on, so that they'll get
> patched if an exploit is released but a patch is available.
>
> If the risk is that a buggy update might crash the machine, then that has
> to be weighed against the possibility of *not* getting updates, and getting
> hacked as a result -- usually the latter being worse.
IMHO, the risk of applying patches blindly outweight the benefit of
automatic update.
Yum-updatesd would not only fixes security bug, but also other things
that may not be good for our system.
Consider a database server that got automatically updated and the
sysadmin is so contemplate that it's only after a month or so he
realized the update have caused a corruption in the database. I don't
think his boss would be happy.

If a sysadmin is concern of the security of the servers, he should
subscribe to security advisory mailing list and do any required update
in time.
Laziness is not an excuse. Anyway, should he decides, he can always
easily activate the automatic updates.

On 12/28/2011 02:04 AM, Bennett Haselton wrote:
> Ever since someone told me that one of my servers might have been hacked
> (not the most recent instance) because I wasn't applying updates as
soon as
> they became available, I've been logging in and running "yum
update"
> religiously once a week until I found out how to set the yum-updatesd
> service to do the equivalent automatically (once per hour, I think).
> 
> Since then, I've leased dedicated servers from several different
companies,
> and on all of them, I had to set up yum-updatesd to run and check for
> updates -- by default it was off.  Why isn't it on by default?  Or is
it
> being considered to make it the default in the future?
> 
> Power users can always change it if they want; the question is what would
> be better for the vast majority of users who don't change defaults.  In
> that case it would seem better to have updates on, so that they'll get
> patched if an exploit is released but a patch is available.
> 
> If the risk is that a buggy update might crash the machine, then that has
> to be weighed against the possibility of *not* getting updates, and getting
> hacked as a result -- usually the latter being worse.
> 
> After all, if users are exhorted to log in to their machines and check for
> updates and apply them, that implies that the risk of getting hosed by a
> buggy update is outweighed by the risk of getting hacked by not applying
> updates.  If that's true for updates that are applied manually, it
ought to
> be true for updates that are downloaded and applied automatically,
> shouldn't it?
The first part of your question is answered simply as ... it defaults to
do what the upstream distro does.  If they (the upstream provider) set
their distro to automatically run updates by default, then so will
CentOS.  I do not think they will do that though.

The last question (does the security risk of not applying auto updates
quickly outweigh the risk of the system breaking because of a bad
update) depends on the situation.

If you are doing some things, auto updates are probably fine.  I build
and release these packages for CentOS and I fully trust them ...
however, even I do not auto update my production servers at work.

Each of my servers is a unique and complex system of several 3rd party
applications/repos as well as the CentOS operating system.  So while the
CentOS updates almost always "just work", the 3rd party apps (or 3rd
party repos) might need looking at after the update to verify everything
is still functioning properly.

Now, we do have some servers that are just create and teardown for extra
work load and these do auto update ... but I would never do that (auto
update) for things that I consider critical.

Over the years there have been updates where permissions issues
prevented DNS servers from restarting, etc.   ...  it is just too
important to me that my machines run to trust pushing auto updates to
critical servers.  At least that is my take.  But, then again, I have
test servers for my most critical stuff and I push the updates there for
a couple of days to verify that they work before I move the updates into
production.

All that being said, if your server is a LAMP machine with MYSQL and
Apache from CentOS and other standard CentOS packages like dhcp, bind,
etc., then auto updates will likely never cause you problems.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20111228/82279055/attachment-0005.sig>

On Wednesday, December 28, 2011, Johnny Hughes <johnny at centos.org>
wrote:
> On 12/28/2011 02:04 AM, Bennett Haselton wrote:
>> Ever since someone told me that one of my servers might have been
hacked
>> (not the most recent instance) because I wasn't applying updates as
soon
as
>> they became available, I've been logging in and running "yum
update"
>> religiously once a week until I found out how to set the yum-updatesd
>> service to do the equivalent automatically (once per hour, I think).
>>
>> Since then, I've leased dedicated servers from several different
companies,
>> and on all of them, I had to set up yum-updatesd to run and check for
>> updates -- by default it was off.  Why isn't it on by default?  Or
is it
>> being considered to make it the default in the future?
>>
>> Power users can always change it if they want; the question is what
would
>> be better for the vast majority of users who don't change defaults.
In
>> that case it would seem better to have updates on, so that they'll
get
>> patched if an exploit is released but a patch is available.
>>
>> If the risk is that a buggy update might crash the machine, then that
has
>> to be weighed against the possibility of *not* getting updates, and
getting
>> hacked as a result -- usually the latter being worse.
>>
>> After all, if users are exhorted to log in to their machines and check
for
>> updates and apply them, that implies that the risk of getting hosed by
a
>> buggy update is outweighed by the risk of getting hacked by not
applying
>> updates.  If that's true for updates that are applied manually, it
ought
to
>> be true for updates that are downloaded and applied automatically,
>> shouldn't it?
>
> The first part of your question is answered simply as ... it defaults to
> do what the upstream distro does.  If they (the upstream provider) set
> their distro to automatically run updates by default, then so will
> CentOS.  I do not think they will do that though.
>
> The last question (does the security risk of not applying auto updates
> quickly outweigh the risk of the system breaking because of a bad
> update) depends on the situation.
>
> If you are doing some things, auto updates are probably fine.  I build
> and release these packages for CentOS and I fully trust them ...
> however, even I do not auto update my production servers at work.
>
> Each of my servers is a unique and complex system of several 3rd party
> applications/repos as well as the CentOS operating system.  So while the
> CentOS updates almost always "just work", the 3rd party apps (or
3rd
> party repos) might need looking at after the update to verify everything
> is still functioning properly.
>
> Now, we do have some servers that are just create and teardown for extra
> work load and these do auto update ... but I would never do that (auto
> update) for things that I consider critical.
>
> Over the years there have been updates where permissions issues
> prevented DNS servers from restarting, etc.   ...  it is just too
> important to me that my machines run to trust pushing auto updates to
> critical servers.  At least that is my take.  But, then again, I have
> test servers for my most critical stuff and I push the updates there for
> a couple of days to verify that they work before I move the updates into
> production.
>
> All that being said, if your server is a LAMP machine with MYSQL and
> Apache from CentOS and other standard CentOS packages like dhcp, bind,
> etc., then auto updates will likely never cause you problems.
>
>
This would not be a good idea in general. (just my opinion). I think back
to one update (can't remember which update - 5.x something) where it
swapped the eth0 and eth1 on all our dells. So every server was taken down
after update and then required the nics to be reconfigured (or cables
swapped) to get proper connectivity.

D