Ручная синхронизация времени с сервером

Ручная синхронизация времени с сервером

Для настройки Windows Vista на получение точного времени с NTP сервера Mobatime необходимо выполнить следующие действия:
Щелкните один раз левой кнопкой мыши по часам в трее. Откроется следующее окно:

Щелкните по ссылке Изменение настройки даты и времени.

Это же окно можно открыть, последовательно выбрав Пуск — Панель управления — Часы, язык и регион (ссылка зелёного цвета) — Установка даты и времени.
В этом окне переключитесь на вкладку Время Интернета

Нажмите кнопку Изменить параметры. После нажатия будет выдан запрос на подтверждение выполняемого действия (если такие предупреждения не были отключены).

Подтвердите действие, после чего будет открыта форма, содержащая поле для ввода адреса NTP сервера.

Синхронизация времени на Mac OS настраивается в System Preferences — Date & Time.

Для настройки синхронизации дважды щелкните по часам в трее. Откроется окно свойств даты и времени. Это же окно можно открыть из Пуск — Панель управления — Дата и время. Переключитесь на последнюю вкладку Время Интернета. Обратите внимание на то, что вкладка появится в окне только при установленном подключении к интернету.

Информация о программе SP TimeSync

SP TimeSync является программой с многоязычным интерфейсом, предназначенной для синхронизации часов компьютера с любыми атомными часами (серверами точного времени) в Интернет. Для этих целей используется высокоточный сетевой протокол времени (NTP), который позволяет достичь точности синхронизации до нескольких миллисекунд в зависимости от характеристик источника времени и задержек распространения сигнала по сети.

Языки интерфейса SP TimeSync

Базовым языком интерфейса программы SP TimeSync является английский, но в настоящее время также поддерживаются следующие дополнительные языки (перечислены в алфавитном порядке):
белорусский, венгерский, голландский, датский, испанский, итальянский, литовский, немецкий, норвежский, польский, португальский (бразильский), румынский, русский, сербский, словенский, турецкий, украинский, фарерский, финский, французский, чешский.

Туннель во времени. Выводим данные с компьютера через Network Time Protocol

Пару месяцев назад я гулял по загнивающей Германии, где по каждому удобному и не очень поводу строят туннель. И тут мне пришла идея: а не сделать ли свой туннель? В качестве протокола я выбрал NTP — его использование не требует специальных привилегий, системы защиты не видят в нем никаких проблем, ведь там по определению быть ничего не может, кроме текущего времени, а его формат простой как палка, что позволяет нам использовать его без необходимости закапываться в документацию.

Этот трюк могут использовать и вирусописатели — для вывода данных из зараженных систем, причем незаметно для стандартных средств защиты.

WARNING

Создание и распространение вредоносных программ карается по статье 273 УК РФ. Ни автор, ни редакция «Хакера» не несут ответственности ни за какой вред, принесенный использованием материалов этой статьи.

Что такое NTP

NTP (Network Time Protocol) — протокол, который работает поверх UDP и используется для синхронизации локальных часов с часами на сервере точного времени. При работе в интернете точность синхронизации составляет до 10 мс, а в локальных сетях — до 0,2 мс. При этом NTP нечувствителен к задержкам канала.

Актуальная версия протокола (по данным Википедии) — 4, но мы будем использовать версию 3, которой для наших целей предостаточно.

Для максимальной точности служба обновления времени постоянно должна работать в фоновом режиме, регулярно отправляя запросы на сервер точного времени, то есть генерируя довольно много трафика. Это нам на руку, так как из-за этой особенности IDS давно не обращают внимания на трафик NTP.

За синхронизацию в Windows отвечает служба W32Time, а в Linux — демон ntpd или chronyd. Также существует более простая реализация этого протокола, известная как SNTP (Simple Network Time Protocol) — простой протокол сетевого времени. Применяют его во встраиваемых системах и устройствах, которые не требуют высокой точности, как, например, системы умного дома.

Структура пакета NTP

Структура пакета NTP описана в RFC 958 (v1), 1119 (v2), 1305 (v3) и 5905 (v4). Нас интересует версия 3, как довольно распространенная и простая, хотя ты свободно можешь пользоваться версией 4, она почти не отличается.

Для прожженных программистов на C есть псевдокод:

Теперь немного о назначении этих полей.

• Leap indicator (LI), 2 бита — число, предупреждающее о секунде координации. Может быть от 0 до 3, где 0 — нет коррекции, 1 — последняя минута дня содержит 61 с, 2 — последняя минута дня содержит 59 с, 3 — неисправность сервера. При значении 3 полученным данным доверять не следует. Вместо этого нужно обратиться к другому серверу. Наш псевдосервер будет всегда возвращать 0.
• Version number (VN), 2 бита — номер версии протокола NTP (1–4). Мы поставим туда 3.
• Mode — режим работы отправителя пакета. Значение от 0 до 7, где 3 — клиент, а 4 — сервер.
• Stratum — сколько посредников между клиентом и эталонными часами (включая сам NTP-сервер). 1 — сервер берет данные непосредственно с атомных (или других точных) часов, то есть между клиентом и часами только один посредник (сам сервер); 2 — сервер берет данные с сервера со значением Stratum 1 и так далее.
• Poll — целое число, задающее интервал в секундах между последовательными обращениями. Клиент может указать здесь интервал, с которым он хочет отправлять запросы на сервер, а сервер — интервал, с которым он разрешает, чтобы его опрашивали.
• Precision (точность) — число, которое сообщает точность локальных системных часов. Значение равно двоичному логарифму секунд.
• Root delay (задержка сервера) — время, за которое показания эталонных часов доходят до сервера NTP. Задается как число секунд с фиксированной запятой.
• Root dispersion — разброс показаний сервера.
• RefID (идентификатор источника) — ID часов. Если поле Stratum равно единице, то RefID — имя атомных часов (четыре символа ASCII). Если текущий сервер NTP использует показания другого сервера, то в RefID записан IP-адрес этого сервера.
• Reference — последние показания часов сервера.
• Originate — время, когда пакет был отправлен, по версии сервера.
• Receive — время получения запроса сервером.
• Transmit — время отправки ответа сервера клиенту, которое заполняет клиент.

В целом процесс крайне прост и понятен, если изучить картинку. Клиент посылает запрос на сервер, запоминая, когда этот запрос был отправлен. Сервер принимает пакет, запоминает и записывает в пакет время приема, заполняет время отправки и отвечает клиенту. Клиент запоминает, когда он получил ответ, и получает нечто вроде RTT (Round-Trip Time, в простонародье — пинг) до сервера. Дальше он определяет, сколько времени понадобилось пакету, чтобы дойти от сервера обратно ему (время между запросом и ответом клиента минус время обработки пакета на сервере, деленное на два).

Чтобы получить текущее время, нужно прибавить полученную задержку канала к времени отправки ответа сервером. Вот только UDP на то и UDP, что задержки могут быть случайные и непредсказуемые, так что замеры повторяются по многу раз в день, вычисляется средняя ошибка, и локальные часы корректируются.

Ограничения на трафик по порту UDP-123

Системы обнаружения вторжений не такие глупые, какими могут показаться, так что просто пустить трафик, например, OpenVPN по 123-му порту UDP мы не сможем, по крайней мере без риска спалиться. Соответствие RFC все же проверяется. Это можно посмотреть на примере Wireshark.

Один из NTP-пакетов, пойманных Wireshark

Придется нам заставить наши пакеты соответствовать RFC. Проще всего это сделать, назначая некоторые поля по своему усмотрению. Мы можем внедрить свои данные в поля Transmit и Originate . Последнее не вполне соответствует RFC, но так глубоко проверки обычно не добираются.

Концепт

Идея проста: мы составляем собственный «заряженный» пакет NTP и пытаемся синхронизировать время со своим сервером. Чтобы не привлекать лишнего внимания к своей передаче, на каждый запрос должен отправляться внешне валидный ответ, в котором могут быть инструкции для клиента (читай: бота).

Чтобы всякие там системы предотвращения утечек (DLP) не мешали нам, можно, например, поксорить наши данные со статическим ключом. Естественно, в рамках PoC я не буду этого делать, но в качестве простейшего способа сокрытия данных должно сработать.

Для передачи данных с клиента на сервер подходят поля Poll , Originate и Transmit . Из них Poll пригоден ограниченно, но мы на этом останавливаться не будем. Если ты задумаешь учесть его ограничение, то имей в виду, что использовать в этом поле можно только младшие три бита (как я понял из документации). Без учета этого мы можем использовать 17 байт из 48 (35% всего объема пакета) на отправку данных, что уже неплохо.

А что на прием? Сервер заполняет поля Precision , Root delay , Root dispersion , Reference , RefID , Receive и, ограниченно, Poll . На ответ сервера в этом поле распространяются такие же ограничения, как на клиента. Итого имеем 29 (28 без Poll ) байт из 48 (60% пакета). Полезный объем пакета — 46 из 48 байт (96%). Оставшиеся два байта — флаги и заголовки, которые мы менять не можем без вреда для скрытности.

Реализация

Писать код и дебажить наше творение мы будем в Visual Studio. Я использую версию 2019 Community, благо она бесплатная, а скачать ее можно с сайта Microsoft.

Сервер

Как только IDE установлена, включена темная тема и любимый плей-лист, можно приступать. Для начала создадим новый проект типа «консольное приложение» (мы ведь не прячемся от юзера) с названием NtpTun_SERVER .

Создание проекта

Теперь нам нужна структура, описывающая пакет. Обратившись к спецификации NTP, напишем простой класс. В нем также должны быть методы упаковки пакета в массив байтов, пригодный для передачи настоящему серверу и для распаковки пришедшего ответа из массива байтов обратно в пакет.

Весь код, используемый в статье, есть в моем репозитории на GitHub. Он намеренно подпорчен и для промышленного использования не годится, но для демонстрации работы вполне сойдет.

Объявляем структуру пакета. Не смотри на странные суффиксы в названиях функций, так задумано

Уже из этого кода видно, что мы будем притворяться сервером Stratum 3. Если бы мы были Stratum 1, то нужно было бы в поле RefID указывать ID атомных часов, которых у нас нет. А список серверов первого уровня общеизвестен, и, если IP нашего псевдосервера не окажется в таких публичных списках, обман быстро будет раскрыт.

Stratum 2 не следует использовать, потому что тогда RefID должен был бы содержать IP сервера первого уровня, список которых опять же известен. А вот третий уровень позволяет указывать в RefID IP сервера второго уровня, полного списка которых нет. То есть мы сможем в RefID передавать еще четыре байта произвольных данных.

Код методов упаковки и распаковки на скриншот не поместился, к тому же нам надо разобрать его отдельно. Вот он:

Тут никаких сложностей: принимаем массив байтов и при помощи BitConverter получаем оттуда данные.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Blog of Khlebalin Dmitriy

Настройка синхронизации времени в домене Active Directory.

Вообще служба времени является достаточно важной службой в работе всех систем в целом. Порой многие админы откладывают ее настройку на потом или вообще никак не настраивают ее в дальнейшем. И все бы ничего, но порой это начинает приводить к проблемам (например отказе некоторых сервисов, аутентификации по Kerberos в домене и прочим багам). В данном посте, я приведу некоторые настройки собственные и наших коллег по цеху и в двух словах расскажу о нюансах с которыми я столкнулся в жизни. Итак приступим:

• топологии синхронизации времени среди участников Active Directory
• оптимальной с моей точки зрения конфигурации сервера времени корневого эмулятора PDC
• полезных командах для настройки и диагностики синхронизации времени
• особенностях , которые нужно учитывать для виртуализированных контроллеров домена

Топология синхронизации времени среди участников Active Directory

Среди компьютеров, участвующих в Active Directory работает следующая схема синхронизация времени.

• Контроллер корневого домена в лесу AD, которому принадлежит FSMО-роль эмулятора PDC (назовем его корневым PDC), является источником времени для всех остальных контроллеров этого домена.
• Контроллеры дочерних доменов синхронизируют время с вышестоящих по топологии AD контроллеров домена.
• Рядовые члены домена (сервера и рабочие станции) синхронизируют свое время с ближайшим к ним доступным контроллером домена, соблюдая топологию AD.

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

Синхронизация клиентов корневого PDC может осуществятся как с его внутренних часов, так и с внешнего источника. В первом случае сервер времени корневого PDC объявляет себя как «надежный» (reliable).

Далее будет приведена оптимальная конфигурация сервера времени корневого PDC, при которой сам корневой PDC периодически синхронизирует свое время от достоверного источника в интернете, а время обращающихся к нему клиентов синхронизирует со своими внутренними часами.

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр. Где возможно, будут показаны оба варианта.

Включение синхронизации внутренних часов с внешним источником

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
  «Type»=»NTP»
• w32tm /config /syncfromflags:manual

Подробности — в библиотеке TechNet.

Объявление NTP-сервера в качестве надежного

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig]
  «AnnounceFlags»=dword:0000000a
• w32tm /config /reliable:yes

Подробности — в библиотеке TechNet.

NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer]
  «Enabled»=dword:00000001

Задание списка внешних источников для синхронизации

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
  «NtpServer»=»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8»
• w32tm /config /manualpeerlist:»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8″

Флаг 0×8 на конце означает, что синхронизация должна происходить в режиме клиента NTP, через предложенные этим сервером интервалы времени. Для того, чтобы задать свой интервал синхронизации, необходимо использовать флаг 0×1. Все остальные флаги описаны в библиотеке TechNet.

Задание интервала синхронизации с внешним источником

Время в секундах между опросами источника синхронизации, по умолчанию 900с = 15мин. Работает только для источников, помеченных флагом 0×1.

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient]
  «SpecialPollInterval»=dword:00000384

Установка минимальной положительной и отрицательной коррекции

Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig]
«MaxPosPhaseCorrection»=dword:FFFFFFFF
«MaxNegPhaseCorrection»=dword:FFFFFFFF

Все необходимое одной строкой

w32tm.exe /config /manualpeerlist:»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8» /syncfromflags:manual /reliable:yes /update

• Применение внесенных в конфигурацию службы времени изменений
  w32tm /config /update
• Принудительная синхронизация от источника
  w32tm /resync /rediscover
• Отображение состояния синхронизации контроллеров домена в домене
  w32tm /monitor
• Отображение текущих источников синхронизации и их статуса
  w32tm /query /peers

Особенности виртуализированных контроллеров домена

Контроллеры домена, работающие в виртуализированной среде, требуют к себе особенного отношения.

• Средства синхронизации времени виртуальной машины и хостовой ОС должны быть выключены. Во всех адекватных системах виртуализации (Microsoft, vmWare и т. д.) присутствуют компоненты интеграции гостевой ОС с хостовой, которые значительно повышают производительность и управляемость гостевой системой. Среди этих компонентов всегда есть средство синхронизации времени гостевой ОС с хостовой, которое очень полезно для рядовых машин, но противопоказано для контроллеров домена. Потому как в этом случае весьма вероятен цикл, при котором контроллер домена и хостовая ОС будут синхронизировать друг друга. Последствия печальны.
• Для корневого PDC синхронизация с внешним источником должна быть настроена всегда. В виртуальной среде часы не настолько точны как в физической, потому как виртуальная машина работает с виртуальным процессором и прерываниями, для которых характерно как замедление, так и ускорение относительно «обычной» частоты. Если не настроить синхронизацию виртуализированного корневого PDC с внешним источником, время на всех компьютерах предприятия может убегать/отставать на пару часов в сутки. Не трудно представить неприятности, которые может принести такое поведение.

В данном посте Максим Ефремов рассказал о настройке NTP в Win2008, Vista в семерке это делается аналогично.

Если у Вас домен, то он сам синхронизирует время на рабочих станциях. Только, для того чтоб он сам не искал с кем-бы ему синхронизироваться, надо в реестре:
«HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters»
Установить значение параметра LocalNTP равным 1.
На рабочих станциях (на всех) один раз прописать «net time \имя_сервера /set»
Ах да, после изменений в реестре еще надо перезапустить службу: «net w32time stop» и «net w32time start» поочереди.

Если скажем, вы хотите чтоб время синхронизировалось каждый час, то сделайте следуеще:
1. В реестре, по тому же адресу, удалить параметр «Period».
2. Вместо него создать параметр с тем же именем, только типа REG_DWORD.
3. Для нового параметра задать значение 24

На компах с 2000 и выше «левые» программы не нужны, все решается стандартными средствами.

Например, на компе подключенном к Инету:
1. net time /setsntp:»192.5.41.209 192.5.41.41″
2. Рестарт time service

На контроллере домена:
1. net time /setsntp:»АйПи_компа_подключенного_к_инету»
2. Рестарт time service

Да, но все вышенаписанное, при правильной настройке, нормально работает в виндовых платформах. Но в определенный момент, я столкнулся с тем, что сервак телефонии Авая, так и не смог синхронизироваться с виндовым сервером времени, как я ни старался. Зато с сервером времени развернутым на линухе (или на юнихе, я уже не вспомню точно) синхронихировался за 2 секунды и без проблем.

По сему для себя мы сделали вывод, что при наличии в компании смешанной инфраструктуры (windows+nix) актуальней будет использовать NTP сервер на nix платформе (в моем случае это будет freebsd), а далее соответственно как сами настроите. О настройке NTP сервака на freebsd в моих будущих постах.

Всем удачи в работе .

P.S. Здесь же будут полезны вот эти сайты:

за что ее автору большое спасибо.

P.S. Здесь еще будет полезна краткая сводка команд:

w32tm /config /update /manualpeerlist:»ntp.mobatime.ru» /syncfromflags:MANUAL /reliable:YES

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр. Где возможно, я приведу оба варианта.

Включение синхронизации внутренних часов с внешним источником

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters] «Type»=»NTP»
• w32tm /config /syncfromflags:manual

Подробности — в библиотеке TechNet.

Объявление NTP-сервера в качестве надежного

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig] «AnnounceFlags»=dword:0000000a
• w32tm /config /reliable:yes

Подробности — в библиотеке TechNet.

Включение NTP-сервера

NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer] «Enabled»=dword:00000001

Задание списка внешних источников для синхронизации

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters] «NtpServer»=»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8»
• w32tm /config /manualpeerlist:»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8″

Флаг 0×8 на конце означает, что синхронизация должна происходить в режиме клиента NTP, через предложенные этим сервером интервалы времени. Для того, чтобы задать свой интервал синхронизации, необходимо использовать флаг 0×1. Все остальные флаги описаны в библиотеке TechNet.

Задание интервала синхронизации с внешним источником

Время в секундах между опросами источника синхронизации, по умолчанию 900с = 15мин. Работает только для источников, помеченных флагом 0×1.

• [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient] «SpecialPollInterval»=dword:00000384

Установка минимальной положительной и отрицательной коррекции

Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig] «MaxPosPhaseCorrection»=dword:FFFFFFFF «MaxNegPhaseCorrection»=dword:FFFFFFFF

Все необходимое одной строкой

w32tm.exe /config /manualpeerlist:»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8″ /syncfromflags:manual /reliable:yes /update

Полезные команды

• Применение внесенных в конфигурацию службы времени изменений w32tm /config /update
• Принудительная синхронизация от источника w32tm /resync /rediscover
• Отображение состояния синхронизации контроллеров домена в домене w32tm /monitor
• Отображение текущих источников синхронизации и их статуса w32tm /query /peers

Проверяем что не включена Локальная политика контроллера домена

1) Отключаем здесь настройки NTP клиента и сервера
2) Проверяем команда gpresult.

Для настройки вашего доменного контроллера с ролью “Эмулятора PDC” на синхронизацию с внешним источником, необходимо сначала выполнить команду

w32tm /stripchart /computer: 3.pool.ntp.org /samples:5 /dataonly

которая произведет 5 сравнений с источником, а затем:

w32tm /config /manualpeerlist: 3.pool.ntp.org / syncfromflags:manual /reliable

команду выполнять с повышенными правами

Проверяем внешний источник контроллера: W32TM /Query /Source

Настройка часового пояса (timezone), синхронизация системного времени с NTP server в OpenBSD

С течением времени системные часы компьютера имеют тенденцию отставать. Network Time Protocol — Сетевой Протокол Времени (NTP ) является одним из способов вести точное системное время. Если системное время в операционной системе OpenBSD не синхронизировано с NTP server, то могут возникнуть проблемы в работе программного обеспечения используемого на различных серверах и рабочих станциях.

Многие сервисы Интернет опираются или сильно зависят от точности системных часов компьютеров. К примеру, веб-сервер может получать запрос на посылку файла, который был недавно модифицирован. В локальной сети необходимо, чтобы часы компьютеров, совместно использующих файлы, были синхронизированы, чтобы время модификации файлов устанавливалось правильно. Такие службы, как cron , также зависят от правильности установки системных часов, поскольку запускают команды в определенное время.

Эта ошибка возникает при использовании всех браузеров кроме FireFox, при этом также во всех браузерах кроме FireFox невозможно авторизироватся в CMS Drupal, авторизация проходит без ошибок но, снова видна главная страница с формой авторизации!

Проблема заключается в разном времени установленном на локальной и виртуальной машине. Так например на виртуальной машине установлено время » Sun Dec 4 09:25:18 EET 2011 «, а на локальной » Fri Dec 30 09:35:18 EET 2011 «.

Казалось бы причем тут настройки времени к ошибке » You have an error in your SQL syntax » но, увы — это такой себе БАГ в Drupal-e которого нет в Joomla. Подробнее про этот Drupal-овский БАГ можно почитать тут:

Настройка часового пояса (timezone) в OpenBSD

Наверное не сложно догадаться, что полный список файлов часовых зон в OpenBSD можно полистать по адресу: ls /usr/share/zoneinfo/

Синхронизация системного времени с NTP server в OpenBSD

Демон ntpd специально предназначен для установки и поддержания системного времени в синхронизации со стандартными серверами времени в Интернете. По умолчанию для распределения времени используется протокол SNTP (порт 123 UDP) версии 4 (RFC 2030), а для получения поддерживается совместимость с версиями протокола NTP 3 (RFC -1305), а также 1 и 2 (RFC -1059 и RFC -1119).

Флаг » -s » позволит немедленно синхронизировать время (часы) при очередном запуске/перезагрузке системы и в дальнейшем позволяет исправлять время в течении длительного периода, исключая необходимость управлять rdate (8), при этом создается файл » /var/db/ntpd.drift «.

Нужно взять во внимание, что если файл » /var/db/ntpd.drift » был создан вручную и в нем отсутствуют данные, то при запуске демона » ntpd » будет выдана ошибка: » ntpd can’t read /var/db/ntpd.drift «. Файл » /var/db/ntpd.drift » содержит данные о поправке времени:

Настройки демона » ntpd » хранятся в файле «/etc/ntpd.conf«, как правило его дополнительная конфигурация не требуется:

Следует заметить, что в конфигурационный файл » /etc/ntpd.conf » ( man ntpd.conf ) не предусматривает указание директивы » driftfile «, определяющей путь к файлу » ntpd.drift «, что позволяется в FreeBSD !:

Параметр driftfile задает файл, который используется для хранения смещения частоты системных часов. Программа ntpd(8) использует его для автоматической компенсации естественного смещения часов, позволяя ему поддерживать достаточно правильную настройку, даже если он на некоторый период отключается от внешнего источника информации о времени.

Для одноразовой коррекции системного времени (часов) можно использовать команду » ntpd -s » или » rdate «:

Перед одноразовой синхронизацией системного времени (часов) с помощью команды » rdate » можно предварительно проверить время на удалённом сервере командой:

Интервал синхронизации системного времени с NTP server в OpenBSD

Это описание демона В OpenBSD для синхронизации системного времени используется OpenNTPD у которого довольно скудная документация Вероятно, что для выяснения интервала коррекции системного времени демоном » ntpd » придется обращаться к астрологам либо самому гадать на картах или кофейной гуще но, мы пойдём другим путём 🙂

Статья применима к операционным системам :

• OpenBSD 4.x
• OpenBSD 5.x

Рекомендуемый контент

А тут же ж мог быть рекомендуемый контент от гугла 🙂 Для отображения рекомендуемого контента необходимо в браузере разрешить выполнение JavaScript скриптов, включая скрипты с доменов googlesyndication.com и doubleclick.net

Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).