ntp-сервер, который синхронизируется с другими ntp-серверами, но предоставляет модифицированный utc

Во-первых, три ура вам, WolfThreeFeet, за объяснение того, что вы пытаетесь сделать; без этого это действительно ромовый вопрос.

Если я правильно понимаю, вы хотите подтвердить, что когда вы меняете часы сисплекса с местного времени на всемирное координированное время, все LPAR не падают и не умирают ужасно, и вы хотите протестировать это в сисплексе разработчика перед его развертыванием. по всей машине.

Я не думаю, что можно делать то, что вы описываете как вы это описываете, но я думаю, что вы можете сделать что-то подобное. Настройте тестовую машину, единственная задача которой - быть сервером NTP с неправильными часами; Вполне возможно указать серверу NTP рассматривать его собственные часы материнской платы как авторитетные, разрешить клиентам NTP связываться с ними и обнародовать это время. Затем синхронизируйте рассматриваемый сисплекс через STP (который, как вы говорите, является NTP) с этим сервером с неправильными часами.

Предостережение (не волнуйтесь, у меня есть три предложения):

Я не уверен насчет:

Нам нужно создать ntp-сервер, который синхронизируется с другими ntp-серверами, но дает своему клиенту модифицированный utc.

Зачем он нужен для синхронизации с внешними часами? Вам нужно отбыть фальшивое время и убедиться, что время не блуждает?

Я могу думать / знать о трех способах. Первый из них самый простой и может иметь дело с дрейфом / блужданием, если вы подключите источник PPS.

• Эталонная реализация ntpd с нестандартными локальными часами (рекомендуется / проще всего):

  Если вы хотите, чтобы сервер ntp обслуживал ложное время, это довольно просто. Установите аппаратные часы / часы ядра на любое нужное вам ложное время. Затем настройте ntpd на использование драйвера недисциплинированных локальных часов (127.127.1.x) и без внешних часов. Сервер ntp с радостью будет работать и обслуживать местные часы. Одна проблема заключается в том, что, поскольку вы используете локальный драйвер часов, время не будет стабильным и будет дрейфовать на миллисекунды в ту или иную сторону, потому что кристалл кварца не является эталоном рубидия. Если вам нужна фиктивность и стабильность; вам нужно использовать ULC и добавить источник PPS. После того, как вы добавите источник PPS, вам нужно будет добавить ключевое слово preference для записи ULC в ntp.conf.

• Эталонная реализация ntpd с дисциплиной внешних часов и драйвером локальных часов (сложная):

  Это все еще решение, основанное на использовании эталонной реализации ntpd, но я не очень хорошо с ним знаком. Все, что я могу сделать, это дать вам ссылку на более подробную информацию: http://www.eecis.udel.edu/~mills/ntp/html/extern.html

• Jans - сторонний инструмент для тестирования ntp

  У меня нет опыта работы с этим продуктом, но я знаю о нем из списка рассылки ntp. Это позволит вам использовать ложное время на сервере, но в отличие от эталонной реализации, в нем нет дисциплины часов. Больше информации: http://www.vanheusden.com/time/jans/