I thought this problem had been solved long ago with NTP and similar time synchronization mechanisms... I am finding IT projects that seem to have overlooked how important time sync is when building an infrastructure.
One interesting problem I ran into recently was that the hardware clock on a system that was being re-provisioned was off. Waaaay off. The hardware had a time setting of 2001. When the provisioning was nearing the completion, the system is supposed to register to a RHN Satellite Server that uses SSL certificates for it's communication. The certificate is valid from 2012 to 2014. Hence, the registration failed and the customer ended up wondering why the provisioning failed.
The standard solution to this is to make sure that the hardware has the right time set before we try provisioning. That requires getting console access, navigating through the uEFI/BIOS menus, setting the time, etc.
A more elegant solution is to use a kickstart templating engine, ie. cobbler, razor., and then write a snippet that sets the hardware clock before the installation begins. This will then solve the hardware clock being set incorrectly when the registration happens. The server or engine that provides the kickstart can insert a timestamp into the kickstart, then in a %pre script, you can validate the hardware clock's time with the timestamp (the timestamp in the kickstart should be OLDER than the hardware clock) and then either set the hardware clock or halt the installation process.
Technically, anything that uses certificates or crypto keys that use the current time will benefit from this kind of solution.
1 comment:
Yes, very important. I use a pre snippet in Cobbler that parses the dhclient config so I can use ntpdate and if that isn't available (bash if/else in the snippet), it falls back to setting the time to a static value from when the kickstart was rendered. Good enough for the install and the NTP will kick in on first boot.
Post a Comment