This shows you the differences between two versions of the page.
Next revision | Previous revision Last revision Both sides next revision | ||
cmd:ntp [2016/06/13 15:16] mcb30 created |
cmd:ntp [2017/01/26 12:49] mcb30 |
||
---|---|---|---|
Line 24: | Line 24: | ||
===== See also ===== | ===== See also ===== | ||
+ | * ''[[:cfg:unixtime]]'' | ||
* [[:cmd|List of all iPXE commands]] | * [[:cmd|List of all iPXE commands]] | ||
Line 29: | Line 30: | ||
This command is available only when the build option ''[[:buildcfg:NTP_CMD]]'' is enabled. | This command is available only when the build option ''[[:buildcfg:NTP_CMD]]'' is enabled. | ||
+ | |||
+ | ===== Notes ===== | ||
+ | |||
+ | You can use the ''[[:cfg:unixtime]]'' setting to obtain the current time after running the ''ntp'' command. | ||
+ | |||
+ | iPXE uses the time and date primarily for validating [[:crypto|X.509 certificates]]. If your system clock is inaccurate, then iPXE may erroneously decide that a valid certificate has expired. You can use the ''ntp'' command to work around this problem, by fetching the time and date from an external NTP server. You should be aware that there is no security or authentication used for NTP, and so using the ''ntp'' command is effectively equivalent to ignoring the validity period of any X.509 certificates. | ||
+ | |||
+ | The NTP protocol requires that the system clock is already set within 34 years of the correct date. If the system clock is inaccurate by more than 34 years, then the ''ntp'' command will not be able to determine the current time and date. | ||