SCIENTIFIC-LINUX-USERS Archives

July 2009

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:
Kelvin Raywood <[log in to unmask]>
Reply To:
Kelvin Raywood <[log in to unmask]>
Date:
Thu, 23 Jul 2009 09:48:16 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Now that a couple of package updates (libtiff, libtiff-devel) have been
signed with the new SL signing key, a couple of issues have arisen that 
are causing automatic updates to fail.

In SL 5.1 (and possibly SL 5.0) the release number of the sl-release
package was not incremented and so those systems did not receive the new
keys.

[log in to unmask]> rpm -q --changelog sl-release
* Fri May 23 2008 Troy Dawson <[log in to unmask]> - 5.1-2
- Changed sources to be 51 instead of 5rolling

...

ie,  sl-release has been at at 5.1-2 since May 2008

The new version of the package is the same release number and the May
23, 2008 entry from the changelog has disappeared.

Another cause of update failures is that if the yum repo files have been 
modified (e.g. to enable signature checking), then the update to 
yum-conf added created .rpmnew files but left the modified files in 
place.  This is correct behaviour but it means that the path to  the new 
key is not in the .repo files and so security updates fail because the
repository now has packages signed with the new key.

For some systems it is not sufficient to just fix the .repo files. If
they have missed the update to sl-release because they've been
offline, or because of the release number problem above, then updates
will continue to fail because they don't have the new key. The solutions
on any individual system is fairly straight forward; disable signature
checking or import the new keys manually. However at TRIUMF (and I
suspect other institutions) there are a large number of desktop PCs
managed by their owners; some of whom are less than diligent about
reading email sent to root about failing yum updates.

When Fedora changed their signing key last year, they created new
repositories (i386.newkey, x86_64.newkey) and systems were updated in a
two-step.  First the yum-conf package installed new .repo files pointing
at the new repositories.  Then all new updates went to the new 
repositories.  This avoided update failures because of missing keys.

Do most people just leave their signature checking disabled and so don't 
have the problem or have I missed something obvious here?

I'm a little surprised that this issue has not already been raised.

Kel Raywood
TRIUMF

ATOM RSS1 RSS2