1

I have heard of leap second vulnerability. The Redhat has recommended to the following fix https://access.redhat.com/articles/15145

My system is currently installed with RHEL 6.1. By following the link Redhat recommends to update to this kernel-2.6.32-131.30.2.el6.x86_64 .

But i cannot find this kernel version in the redhat.

I have searched the internet but cannot get this version.

I need the support for it.

KALAI SELVAN
  • 119
  • 4
  • 1
    if you don't want reboot your server and update the kernel, you can update the ntp package and use -x options for the ntp – c4f4t0r Jun 13 '15 at 10:51

1 Answers1

3

With regard to getting the correct package: Red Hat updates are provided to their paying customers, the current subscription holders, and can be accessed from https://access.redhat.com/ if yum is not configured with your subscription and/or excluding/missing the updates channel.

If you don't have a current subscription and don't want to get one, the suggested approach is to go the route of CentOS, which is derived from and binary compatible with Red Hat.

Regardless the recommended approach is of course to regularly patch your environment.

RHEL 6.1 is a RHEL 6 system that has not been patched since 2011 so compared to everything else, this patch is a really interesting one to start losing sleep over.

Due to the complete binary and ABI compatibilities within a major Red Hat release and back-porting more or less the only reason valid reason for most to not maintain a roughly current patch level is a dependancy on a specific kernel package. Apparently that is not the issue for you.


Red Hat also has two documented work-arounds which allows you to more or less ignore the actual leap second and slew the clock slowly instead.

  • stop ntpd
  • run ntptime -s 0 to reset the kernel status
  • run ntptime and verify it doesn't print INS or DEL on the status line
  • run the system now without ntp active during the leap second
  • at some point in the future you might want to sync the systems idea of time again with the rest of the world

Or alternatively:

  • stop ntpd
  • run ntptime -s 0 -f 0 beforehand to reset the kernel status and frequency
  • configure ntp with the -x option (ntp slew mode)
  • start ntpd (now in slew mode), have it running during the leap second.
HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • Hm, I doubt that using ntp makes the problem moot. At least I am quite confident that e.g. the Quantas (and other) servers that suffered from deadlock because of the June 2012 leap second *did* make use of ntp, which will typically sync the time at quite long intervals whereas the leap second logic is done with the kernel doing its local timekeeping – Hagen von Eitzen Jun 13 '15 at 14:27
  • You're of course absolutely correct, have coffee first next time. Ammended accordingly. – HBruijn Jun 13 '15 at 17:50