Тотальная неудачница и убийца жёстких дисков.
#post-id: 6604-02-07
#original-date: 25.08.2018 Sat
#original-time: 2:07 AM
#original-day: 6604
#original-host: WinXP Home SP3 (Build 2600)
Местный провайдер долбанулся и блокирует NTP запросы. В результате синхронизация времени везде поломалась.
Я об этом уже писала: по умолчанию NTP запрос открывается с порта 123 на клиенте на порт 123 на сервере, ну так провайдер блокирует все пакеты с иходящих портов вроде 123, и синхронизация заканчивается неудачей. В Windows, как я понла, без сторонних утилит это не побороть, там синхронизация работает только так и никак иначе. В Linux ntpd не то тоже не умеет работать иначе, не то без плясок с бубном не перенастраивается. Поэтому я пришла к такому костылю: на машине с Линуксом по крону вызывается ntpdate с флагом, требующим создание запроса с «непривилигированного» порта, а через пару минут с виндовой машины моя утилита через Самбу получает время с Линукса и поправляет в системе.
И всё работало, я даже забыла, откуда что получается. На Линуксе заблокированный ntpd даже успел очнуться, но синхронизации не мешал (без флага – мешает). А сегодня взяли и рубанули свет на пару минут. А обе машины с Линуксом питаются от розетки, и у обеих в итоге сбросились часы. И тут подошло время сихронизации. Но оказалось, что ntpdate запускается только на одной машине, а на другой не то распиания улетели, не то я просто забыла их настроить. И виндовая машина была настроена именно на неё. Точнее, изначально настроена она была на другую, но потом у неё блок питания пришлось забрать (это ноутбук), и она долго стояла выключенной. Ну я и перекинула задание...
Короче, случилось это.
Об этом я узнала, когда всякие программы, общающиеся с сервером по HTTPS (ownClound, например) и прочим SSL (Пидгин), начали орать о неправильных сертификатах.
#original-date: 25.08.2018 Sat
#original-time: 2:07 AM
#original-day: 6604
#original-host: WinXP Home SP3 (Build 2600)
Местный провайдер долбанулся и блокирует NTP запросы. В результате синхронизация времени везде поломалась.
Я об этом уже писала: по умолчанию NTP запрос открывается с порта 123 на клиенте на порт 123 на сервере, ну так провайдер блокирует все пакеты с иходящих портов вроде 123, и синхронизация заканчивается неудачей. В Windows, как я понла, без сторонних утилит это не побороть, там синхронизация работает только так и никак иначе. В Linux ntpd не то тоже не умеет работать иначе, не то без плясок с бубном не перенастраивается. Поэтому я пришла к такому костылю: на машине с Линуксом по крону вызывается ntpdate с флагом, требующим создание запроса с «непривилигированного» порта, а через пару минут с виндовой машины моя утилита через Самбу получает время с Линукса и поправляет в системе.
И всё работало, я даже забыла, откуда что получается. На Линуксе заблокированный ntpd даже успел очнуться, но синхронизации не мешал (без флага – мешает). А сегодня взяли и рубанули свет на пару минут. А обе машины с Линуксом питаются от розетки, и у обеих в итоге сбросились часы. И тут подошло время сихронизации. Но оказалось, что ntpdate запускается только на одной машине, а на другой не то распиания улетели, не то я просто забыла их настроить. И виндовая машина была настроена именно на неё. Точнее, изначально настроена она была на другую, но потом у неё блок питания пришлось забрать (это ноутбук), и она долго стояла выключенной. Ну я и перекинула задание...
Короче, случилось это.
Об этом я узнала, когда всякие программы, общающиеся с сервером по HTTPS (ownClound, например) и прочим SSL (Пидгин), начали орать о неправильных сертификатах.