SCIENTIFIC-LINUX-USERS Archives

May 2016

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:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Sun, 1 May 2016 12:49:01 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (48 lines)
On Sat, Apr 30, 2016 at 11:37 PM, Konstantin Olchanski
<[log in to unmask]> wrote:
> On Sat, Apr 30, 2016 at 10:20:13PM -0400, Nico Kadel-Garcia wrote:
>> >
>> > Use the much better yum-autoupdate from CERN instead:
>> > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29
>>
>> Sorry, but that thing is a complex nightmare.
>>
>
>
> Excuse me? Complex nightmare? What?

[ Innocent bystanders, I may be a bit cranky here. ]

The directions include a hard-coded third party kernel and kernel
module, which may or may not be a kernel regression in a running
system. Doing this is entirely unnecessary for running "a simple
script", and the steps do not even include the necessary reboot to
activate the new kernel.  Having to do this extra work is perhaps not
that complex, but it's time and bandwidth and resources better spent
elsewhere.

The directions and tools are also entirely incompatible with older
versions of Scientific Linux, such as SL 6 or the still supported SL
5. They don't provide any *benefit* over, for example, editing
/etc/cron.daily/yum-cron to use "tee" and pipe its "yum" commands to a
mail command to a particular user or group of users. For example
simply setting a "MAILADDRESS" setting in the relevant templates, and
editing the yum-cron yum commands as folows:

If I need to publish a patch for that, I can and shall. Let me know if
it's needed.

> It is just a cron job script that runs "yum update" and emails you the result (with email subject
> saying the machine name and success/failure status). You can write replacement in 5 minutes.

Replacing a live, standard upstream kernel for such a small reason is
always a bad idea. It's worse when the directions don't even include
rebooting, nor apply the extra settings to lock in the desired
versions of things.

> To use it or not is a choice. Nothing wrong with the tool itself.

It's what is effectively a cron script called from systemd. Like
trimming your ear hairs with a blender, it can be done, but it's
really the wrong tool for the job.

ATOM RSS1 RSS2