В добре проектираната и поддържана HPC инфраструктура, всички изчислителни сървъри използват специално изграден за техните нужди локален NTP сървър. Това позволява всички изчислителни сървъри да сверят часовниците си спрямо един и същ източник на време, използвайки NTP клиент. Подобно йерархично подчинение на сверяването помага лесно да бъде проследено едно и също събитие, протичащо едновремено върху два или повече изчислителни сървъри, записи за което могат да бъдат намерени в журналните ("log") файлове на сървърите (в тези записи има и времето, с точност до секунда или милисекунда). Също така, някои изчислителни процеси, които се изпълняват паралелно на няколко изчислителни сървъра, се нуждаят от прецизно сверени локални часовници на сървърите и ако такова сверяване липсва, може да се стигне до забавяне на изчислитенията или техния провал.

По подразбиране, дистрибуциите CentOS 7 и Scientific Linux 7 предлагат пакета chrony, който може (в зависимост от конфигурацията) да се използва за изграждането и на NTP сървър, и на NTP клиент. Този документ показва как на базата на пакета chrony да бъде изграден NTP сървър, за сверяване на часовниците в системите в HPC инфраструктура.

В зависимост от инсталираната дистрибуция, вие може да имате или не инсталиран пакета chrony. Винаги е добре да проверите дали той е инсталиран, изпълнявайки следния команден ред (не е нужно да сте супер потребител):

$ rpm -q chrony

Ако пакетът е инсталиран, ще бъде изведена информация за името и версята на пакета:

chrony-3.2-2.el7.x86_64

В случай, че не бъде изведена информация за пакета, трябва да инсталирате chrony чрез yum и след това да го стартирате (с права на супер потребител):

# yum install chrony

Уверете се, че достъп до файла /etc/chrony.keys имат само супер потребителя и демона chronyd:

# chown root:chrony /etc/chrony.keys
# chmod 640 /etc/chrony.keys

След това, създайте копие на файла /etc/chrony.conf, ако случайно се наложи да върнете в сила подразбиращите се настройки на chrony:

# cp /etc/chrony.conf /etc/chrony.conf.orig

Отворете файла /etc/chrony.conf, изтрийте подразбиращото се съдържание, което се намира там и го заменете със следното (вижте и обясненията, които са дадени след конфигурацията):

server ntp0.nl.net iburst
server ntp1.nl.net iburst
server ntp2.nl.net iburst
server ntp0.ipv6.fau.de iburst
server ntp1.ipv6.fau.de iburst
server ntp2.ipv6.fau.de iburst
server ntp3.ipv6.fau.de iburst
server ntps1-0.uni-erlangen.de iburst
server ntps1-1.uni-erlangen.de iburst
server ntps1-2.uni-erlangen.de iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
allow 192.168.122.0/24
allow 2001:67c:20d0:ffff::/64
keyfile /etc/chrony.keys
logdir /var/log/chrony
log measurements statistics tracking

Отбележете списъка с референтни сървъри (всички декларации, които започват със server). Някои от тях (като ntp1.ipv6.fau.de, например) са само IPv6 базирани и ако нямате IPv6 свързаност, присъствието на техните декларации в /etc/chrony.conf не е ефективно, доколкото тези сървъри няма да бъдат запитвани. Освен това, може да изберете други референтни сървъри, различни от тези в примера по-горе. Освен сървърите, е нужно е да опишете IP адресните пространства на всички системи в HPC инфраструктурата, които в ролята си на NTP клиенти, ще запитват този NTP сървър. За примерната конфигурация, показана по-горе, декларацията allow 192.168.122.0/24 позволява на всички хостове, с IPv4 адрес в адресния сегмент 192.168.122.0/24, да запитват успешно NTP сървъра. Аналогично, декларацията allow 2001:67c:20d0:ffff::/64 позволява обработката на запитвания изпратени от хостовете с IPv6 адреси от адресния сегмент 2001:67c:20d0:ffff::/64. Последният ред разрешава използването на syslog за описанието на събитията относно сверяването на локалния часовник на сървъра. Съответните журнални ("log") файлове, в които ще се натрупват тези описания са measurements.log, statistics.log и tracking.log.

След като запазите така направените промени в /etc/chrony.conf, рестартирайте демона chronyd:

# systemctl restart chronyd

и се убедете, че той ще се стартира при зареждане на системата:

# systemctl enable chronyd

Добре е след тези промени да проверите статуса на chronyd, изпълнявайки:

# systemctl status chronyd

Ако няма проблеми с новите деклрации, направени във файла /etc/chrony.conf, ще видите статус "active(running)" (вижте съобщенията, маркирани в зелено по-долу):

● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-04-03 23:58:22 EEST; 12min ago
     Docs: man:chronyd(8)
           man:chrony.conf(5)
  Process: 21592 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
  Process: 21599 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 21591 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─21591 /usr/sbin/chronyd

Изчакайте поне 10-15 секунди след рестартирането/стартирането на демона chronyd и проверете хода на сверяването, изпълнявайки:

# chronyc tracking

При успешно сверяване, ще видите информация подобна на следната:

Reference ID    : 83BC03DE (ntp2.rrze.uni-erlangen.de)
Stratum         : 2
Ref time (UTC)  : Thu Apr 04 01:06:24 2019
System time     : 0.000385237 seconds fast of NTP time
Last offset     : +0.000451235 seconds
RMS offset      : 0.000451235 seconds
Frequency       : 3.504 ppm slow
Residual freq   : +96.069 ppm
Skew            : 0.089 ppm
Root delay      : 0.164173633 seconds
Root dispersion : 0.001770183 seconds
Update interval : 2.2 seconds
Leap status     : Normal

При липсата на комуникация с референтните сървъри, ще виждате следното (забележете "Not synchronised" в края):

Reference ID    : 00000000 ()
Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.000000000 seconds slow of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 3.397 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.000000000 seconds
Root dispersion : 1.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised

Допълнителна информация относно сверяването, която може да помогне при анализ и отстраняване на проблеми, може да намерите в следните журнални ("log") файлове: measurements.log, statistics.log и tracking.log.

След като бъде сверен локалния часовник, NTP сървъра ще започне да обслужва заявките на клиентите (не преди това).

За да може клиент на така изградения NTP сървър, да бъде сигурен, че наистина комуникира с този сървър (а не с някой друг, който злонамерено се представя като оригиналния, чрез IP или DNS измама), е нужно комуникацията с този сървъра да се подписва цифрово с използване на криптографски ключове. Генерирането и обмяната на ключа между двата участника в NTP комуникацията (NTP сървър и NTP клиент), следва протокола описан в част 5 на този документ. Тук е описан процеса по генерирането. За всеки клиент трябва да се генерира по един уникален ключ и този ключ да се инсталира и при сървъра и при клиента (такъв ключ се нарича "споделен"). Не използвайте един ключ за повече от един клиент - това ограничение се налага поради високите изисквания относно сигурността на комуникацията в HPC инфраструктурата, свързана с дистанционното сверяване на локалните часовници на сървърите.

Генерирането на ключа може да се извърши на произволна сигурна Linux-базирана система (може да използвате работна станция, а не системата, в която работи NTP сървъра). За целта трябва да укажете парола (до 4096 бита) и хеш-функция, на база на която ключа да бъде изчислен от паролата. Това може да направите поне по два начина, при това без да е нужно да имате права на super user или root:

• с използване на вградения в командния интерпретатор на chrony инструмент keygen:

  Може да използвате keygen в командния интерпретатор на пакета chrony (този команден интерпретатор се изиква при изпълнение на chronyc):

  $ chronyc
  chronyc> keygen 1000001 SHA256 4096

  Изпълнението на горното ще изведе запис за ключ, подобен на следния:

  1000001 SHA256 HEX:111C2B0CD214AC063...6557562DB2C54A09B

  който трябва да бъде поставен на един ред във файла /etc/chrony.keys на NTP сървъра и NTP клиента. Генерираният запис е инструкция към chronyd да генерира ключ, като използва хеш-функцията SHA256 (може да използвате друга, например SHA512, но не използвайте SHA1 или MD5), на база на паролата, която се намира след "HEX:". Ключът ще има уникален идентификатор 1000001 (заменете 1000001 с уникално за всеки ключ число - не може в конфигурацията на NTP сървъра или клиента да имате два ключа с един и същи уникален номер).

• без използване на готови инструменти:

  Запис за ключ може да генерирате в команден ред под Linux (като непривилигерован потребител - не е нужно да сте super user или root):

  echo -n "1000001 SHA256 HEX:" && dd if=/dev/urandom bs=512 count=1 status=none | od -A n -t x1 | sed 's/ *//g' | sed ':a;N;$!ba;s/\n//g' | tr '[:lower:]' '[:upper:]'

  Изпълнението на горния команден ред, ще даде резултат подобен на този, получен чрез инструмента keygen:

  1000001 SHA256 HEX:111C2B0CD214AC063...6557562DB2C54A09B

  който трябва да бъде поставен на един ред във файла /etc/chrony.keys на NTP сървъра и NTP клиента. Генерираният запис е инструкция към chronyd да генерира ключ, като използва хеш-функцията SHA256 (може да използвате друга, например SHA512, но не използвайте SHA1 или MD5), на база на паролата, която се намира след "HEX:". Ключът ще има уникален идентификатор 1000001 (заменете 1000001 с уникално за всеки ключ число - не може в конфигурацията на NTP сървъра или клиента да имате два ключа с един и същи уникален номер).

Протоколът съдържа следните етапи:

• двете страни договарят уникален идентификатор на ключа:

  Уникалният номер на ключа е десетично число, което трябва да е уникален идентификатор на ключа при NTP сървъра и NTP клиента. Не може NTP сървъра или NTP клиента, да имат в конфигурациите си два ключа с един и същи уникален идентификатор. Именно това налага договарянето на числовият идентификатор.

• ключът се генерира:

  След като ключът ще бъде използван като споделен (известен и на двете страни в цифрово подписаната NTP комуникация), е все едно коя страна в комуникацията ще го генерира. По-горе е описано как става генерирането на този ключ.

• ключът се обменя:

  Обмяната на ключа трябва да става по канал за сигурна комуникация. Никога не публикувайте ключа! Ако ключът е генериран от администратора на NTP сървъра, той следва да изпрати копие от него до клиента. В случай, че ключът е генериран от

• ключът се задава за използване от NTP софтуера:

  След като ключът е обменен, и двете страни го задават в съответните конфигурационни файлове.

• започва сверяването на часовниците на база на цифрово подписана NTP комуникация:

  След като ключът е обменен и заден в конфигурационните файлове на участниците в NTP комуникацията, започва цифровото ѝ подписване (и валидирането на подписването).