proNovell

Имеется энное количество серверов(5.1, 6.0х, 6.5SPх, OES2SP1, OES2SP2).
Один из северов на NW5.1 смотрит в инет берет время с http://pool.ntp.org и является эталонным. На всех серверах установлено зона EAT-4EATD с апреля 2011. Везде убрано смещение на один час. Синхронизация в норме!

Теперь о проблемах.
Имеется ограничение пользователей по режиму работы, т.е. временной интервал. И стали происходить проблемы - т.е у всех установлено что могут работать с 8:00, но не пускает. Ставишь 7:00 то пользователи могут залогиниться в 8:01 по Москве. И то же время всё великолепно отрабатывает вечером. Всех за милую душу вышибает в назначенное время.
Где может быть порыта собака?

Михаил Цветаев писал(а):Имеется энное количество серверов(5.1, 6.0х, 6.5SPх, OES2SP1, OES2SP2).
Один из северов на NW5.1 смотрит в инет берет время с http://pool.ntp.org и является эталонным. На всех серверах установлено зона EAT-4EATD с апреля 2011. Везде убрано смещение на один час. Синхронизация в норме!

Теперь о проблемах.
Имеется ограничение пользователей по режиму работы, т.е. временной интервал. И стали происходить проблемы - т.е у всех установлено что могут работать с 8:00, но не пускает. Ставишь 7:00 то пользователи могут залогиниться в 8:01 по Москве. И то же время всё великолепно отрабатывает вечером. Всех за милую душу вышибает в назначенное время.
Где может быть порыта собака?

А в какое время пускает, ставили опыты? При настройке пускать с 8:00 - пускает в 8:02, 8:30, 9:00 ?
И что с синхронизацией времени на клиенте, сиречь на рабочей станции?

Ковалев Артем писал(а):

Михаил Цветаев писал(а):Имеется энное количество серверов(5.1, 6.0х, 6.5SPх, OES2SP1, OES2SP2).
Один из северов на NW5.1 смотрит в инет берет время с http://pool.ntp.org и является эталонным. На всех серверах установлено зона EAT-4EATD с апреля 2011. Везде убрано смещение на один час. Синхронизация в норме!

Теперь о проблемах.
Имеется ограничение пользователей по режиму работы, т.е. временной интервал. И стали происходить проблемы - т.е у всех установлено что могут работать с 8:00, но не пускает. Ставишь 7:00 то пользователи могут залогиниться в 8:01 по Москве. И то же время всё великолепно отрабатывает вечером. Всех за милую душу вышибает в назначенное время.
Где может быть порыта собака?

А в какое время пускает, ставили опыты? При настройке пускать с 8:00 - пускает в 8:02, 8:30, 9:00 ?
И что с синхронизацией времени на клиенте, сиречь на рабочей станции?

На рабочих станциях всё в норме со временем и синхронизацией. Проверил все сервера - время везде идентичное. В dsrepair показывает что синхронизация в норме. Пробовал и 30 минут прибавлять и разные часы ставить. Всегда лаг 1 час.

А состояние "лето/зима" проверял?
На виндовых станциях явно показывается, что сейчас "лето". А на сервере какое состояние после твоих манипуляций осталось? Может теперь на нем "зима" стала?

Помнится давно, еще на 9x вендах была подобная заморочка, лечилось tzedit. Очевидно и сейчас, после нашей отмены времени, пока не накатаны патчи на временные зоны нужно как-то аналогично шаманить.

Павел Гарбар писал(а):А состояние "лето/зима" проверял?
На виндовых станциях явно показывается, что сейчас "лето". А на сервере какое состояние после твоих манипуляций осталось? Может теперь на нем "зима" стала?

Да, проблема достала.
Это на эталонном сервере времени в сети

Код: Выделить всё

  Time zone string: "EAT-4EATD"
  DST status:  OFF
  DST start:   not set
  DST end:     not set
  Time synchronization is active.
  Time is synchronized to the network.
Monday, 27 June 2011  13:56:53.255  UTC
Monday, 27 June 2011  17:56:53.255  EAT


На рабочей станции такое же время, что и на сервере.
Да я предполагаю, что твориться на рабочей станции не так и важно. Возьмёт, что предложит сеть.
Но если смотреть в С1, когда зарегистрировался пользователь, то это всегда + 1 час.
Откуда, что берется не понятно!!!
Сделал даже такую глупость как объявил новую эпоху. Проблемы от этой задачи были, а вот решение не последовало. И чем и где копать уже и не знаю.

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

Есть предложение вернуть летнее/зимнее время в autoexec'е, но смещение указать 0. Тогда на сервере будет летнее время, как и на всех станциях.
А откуда час набегает - синхронизация идет по UTC, а потом сравнивается состояние "лето/зима" и утилиты вносят поправку при отображении. Ты в свойства пользователя посмотри сначала С1, а потом dsbrowse на консоли сервера.
А через 4 месяца проблемы точно будут.

У меня сегодня возникли проблемы такого же рода (сразу оговорюсь: использую NW65SP8 и XNTPD). Сначала время на рабочих станциях на час отставало от реального. После того как поигрался с TIME ZONE и установкой времени вручную - время на станциях вообще стало UTC , а не локальное с сервера. По совету Павла Гарбара откатил дату на 1 января (зимнее время), потом вернул (летнее время), еще раз установил TIME ZONE. Запустил "xntpd -S" - получил время от ближайшего NTP-сервера. Через примерно час всё вернулось на свои места.
Потом В интернете почитал еще доку. Прелюбопытные вещи нашел.

Server timezone does not reflect DST time after restart

Суть в следующем: xntpd надо грузить последней строчкой в autoexec.ncf, а не в timeserv.ncf - вот это скорее всего и есть мое лекарство, т.к. xntpd у меня грузится в timeserv, и буквально за пару дней перед этим поставил себе SP8 (т.е. изменился autoexec и порядок загрузки NLM-ок в нём). Точно утверждать не берусь, т.к. сервер еще не перегружал после прочтения этой статейки.

А вот еще информация с одного из форумов Новела:

XNTPD.nlm takes a bit longer to synchronize than timesync.nlm by default.
Also, NTP does not synchronize with a server that is around 1,000 seconds
off from itself declaring the source server as "Insane" (no really, it
calls it insane). Anyway, if your server is going off by an hour per day
then NTP won't work unless it synchronizes more-often than every 4.8 hours
(double-check my math). I'm sure it does by default but that's something
to keep in mind.

bgInner писал(а):У меня сегодня возникли проблемы такого же рода (сразу оговорюсь: использую NW65SP8 и XNTPD). Сначала время на рабочих станциях на час отставало от реального. После того как поигрался с TIME ZONE и установкой времени вручную - время на станциях вообще стало UTC , а не локальное с сервера. По совету Павла Гарбара откатил дату на 1 января (зимнее время), потом вернул (летнее время), еще раз установил TIME ZONE. Запустил "xntpd -S" - получил время от ближайшего NTP-сервера. Через примерно час всё вернулось на свои места.
Потом В интернете почитал еще доку. Прелюбопытные вещи нашел.

Server timezone does not reflect DST time after restart

Суть в следующем: xntpd надо грузить последней строчкой в autoexec.ncf, а не в timeserv.ncf - вот это скорее всего и есть мое лекарство, т.к. xntpd у меня грузится в timeserv, и буквально за пару дней перед этим поставил себе SP8 (т.е. изменился autoexec и порядок загрузки NLM-ок в нём). Точно утверждать не берусь, т.к. сервер еще не перегружал после прочтения этой статейки.

А вот еще информация с одного из форумов Новела:

XNTPD.nlm takes a bit longer to synchronize than timesync.nlm by default.
Also, NTP does not synchronize with a server that is around 1,000 seconds
off from itself declaring the source server as "Insane" (no really, it
calls it insane). Anyway, if your server is going off by an hour per day
then NTP won't work unless it synchronizes more-often than every 4.8 hours
(double-check my math). I'm sure it does by default but that's something
to keep in mind.

Сделал как предлагали, т.е. после рестарта сервера с мастер-репликой запустил xntpd.nlm
Минут через 10 можно было видеть что синхронизация ЕСТЬ.
Но ..... не более того. Достало конечно - стал экспериментировать и смотреть.

Н-да, более маразматического результата я ещё не получал. В зависимость с какого сервера(5.1, 6.0, 6.5) был запуск и в зависимости от приложения(С1 или NWAdmin), где можно установить ограничения времени регистрации и видеть время регистрации пользователя - результаты были РАЗНЫЕ. Повторюсь - время на серверах одно, синхронизация в сети по времени имеется.

То у Вас красиво смотрится в NWAdmin-е (т.е. как бы правильно отображается когда можно логиниться с 08-30 до 19-30), но тут же видишь что ВСЕ регистрировались не в 9 с копейками а в 10 с копейками. Хотя я точно знаю, что все приходят и начинают работать с 9.
На NW6.5 в С1 время регистрации в сети правильное - уехало дозволенное время прибывания на работе.
На NW6.0 в С1 время регистрации и дозволенное время прибывания на работе отображается неверно.
Час летает куда хочет.

Дерево одно. У всех правильное время на компьютерах и правильное время на серверах.


P.S. При любые откровения по этому маразму.

А уточните схему времени в вашей сети, пож.

Предполагается, что если в сети не очень много серверов, то можно обойтись одним синглом и остальные -вторым слоем- секондари.

А если вы говорите про "эталонный", то тогда ... ? тогда что - три слоя серверов?

Эталон -> пул опорных (от трех??) -> остальные секондари-> ...

Если схема такая, то не следует ли её упростить? может, излишняя сложность даёт такие неприятные побочные?

Музалёв Николай
Ето, возможно, справедливо в случае с timesync. Насколько я помню, должно быть либо-либо - либо везде timesync, либо везде xntpd.

Музалёв Николай писал(а):А уточните схему времени в вашей сети, пож.

Предполагается, что если в сети не очень много серверов, то можно обойтись одним синглом и остальные -вторым слоем- секондари.

А если вы говорите про "эталонный", то тогда ... ? тогда что - три слоя серверов?

Эталон -> пул опорных (от трех??) -> остальные секондари-> ...

Если схема такая, то не следует ли её упростить? может, излишняя сложность даёт такие неприятные побочные?

Всё проще.

Имеется сервер смотрит в инет на 4 эталонных сервера в разных частях света. Сервера брались проекта нтп.орг.
На нем запущен timesync. Это сервер NW5.1 и он объявлен REFERENCE. На него смотрят все остальные. И работают они в режиме SECONDARY.
Вот такая незамысловатая схема.

Н.....да. Не прошло и года.
Всё оказалось не так чтобы проще, но после того что все стали суетиться со сменой времени прояснилось
1. Запуская iMonitor - надо учитывать, что и для java надо корректировать с помощью tzupdater.jar
2. Запуская C1 надо учитывать, что и для java надо корректировать с помощью tzupdater.jar.
3. ....

Везде где имеется ..\java\bin\ и важна информация о времени надо произвести процедуру java -jar tzupdater.jar -u -f -v
И после этого проблемы( не соответствия) со временем при запуске приложений С1, iMonitor и NWAdmin - пропадают!

добавлю что орацле/сун упорно упаковывают в свежие явы старый tzdata. доступен tzupdater -> tzdata 1.3.42 = Olsen 2011 k а вот tzdata 1.3.44 aka Olsen 2011m только за отдельные $$$

Dimerson писал(а):добавлю что орацле/сун упорно упаковывают в свежие явы старый tzdata. доступен tzupdater -> tzdata 1.3.42 = Olsen 2011 k а вот tzdata 1.3.44 aka Olsen 2011m только за отдельные $$$

На оракл-сане висит сообщение, что новая версия (сегодня уже TZUT v1.3.45) доступна в их представительствах, обращайтесь. Вы с ними общались и правда только за отдельный $$$?