Синхронизация времени ubuntu с контроллером домена windows
Время – краеугольный камень всех “этих их интернетов”. Контроллер домена на Ubuntu 18.04 – не исключение. Если в вашей локальной сети, различие во времени между контроллером и устройствами, превышает 5 минут, у вас проблемы. AD использует время для разрешения конфликтов репликации. Какие-то рабочие станции не смогут авторизоваться в домене. Какие-то из устройств что были авторизованы в домене ранее, не смогут получить доступ к папкам внутри сети. Начнется хаос и беспорядки.
Немного теории
На сайте Samba как рекомендуемое лучшее решение указана следующая схема:
internet time server
^
|
|
PDC Emulator DC
^ ^
| |
| |
Other DC <----Workstation
Primary Domein Cotroller получает время из интернета, остальные DC получают время от PDC, рабочие станции получают время от любого DC в сети. Тем не менее, существует проблема с вендами. Клиенты венды, получают время исключительно от PDC и если PDC оффлайн, они перестают обновлять своё время. В то же время DC перестает обновлять своё время до тех пор, пока не включится PDC. Актуальным решением проблемы на данный момент будет настройка как PDC так и DC на получение времени с одинаковых внешних серверов. А в случае падения PDC без возможности включить его в строй в кратчайшие сроки – перенос роли PDC на другой DC внутри сети. Ясное дело что для реализации данного сценария в сети уже должны функционировать как PDC так и резервный DC.
Контроллер домена на Ubuntu 18.04 – Синхронизация времени с помощью ntpd
1. Требования
ntpd >= 4.2.6 скомпилированный с параметрами –enable-ntpd-signd
2. Устанавливаем пакет
3. Проверяем права на сокет
Демон должен иметь права на чтение директории ntp_signd
3.1 Ищем директорию ntp_signd
В результате, мы видим что папка ntp_signd расположена в /var/lib/samba/ntp_signd
3.2 Смотрим права на директорию
Мы должны увидеть следующее:
drwxr-x--- 2 root root 4096 сен 24 12:33 /var/lib/samba/ntp_signd
3.3 Настраиваем права на директорию
3.3.1 Меняем группу владельца директории на ntp
3.3.2 Устанавливаем права на директорию 750
Несмотря на то, что скорее всего изначально права на эту директорию выставлены 750, не лишним будет показать команду с помощью которой это можно сделать:
Данная команда, для директории /var/lib/samba/ntp_signd/ установит следующие права:
Владелец – root – 7 – любые действия
Группа владельцев – ntp – 5 – чтение и выполнение
Для guest (гостя) – 0 – запрет на любые действия
3.4 Проверяем права на директорию
В результате, после всех манипуляций, должно появиться следующее:
drwxr-x--- 2 root ntp 4096 сен 24 12:33 /var/lib/samba/ntp_signd
Права доступа: drwxr-x— , что означает 750
Владелец: root
Группа владельцев: ntp
4. Настраиваем файл ntpd.conf
Создаем файл ntpd.conf
И вносим в него стандартные настройки:
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp
ntpsigndsocket /var/lib/samba/ntp_signd
Обращая внимание на строку ntpsigndsocket /var/lib/samba/ntp_signd , путь в ней должен быть такой же, как найденный в пункте 3.1. После проведенных манипуляций, сохраняем все командой Ctrl+O
5. При настройке NTP сервера в виртуальной среде
5.1 Отключаем панику NTP
Вносим в конец файла /etc/ntp.conf запись tinker panic 0
Делаем это на bash, потому что просто echo "tinker panic 0" >> /etc/ntp.conf система вероятнее всего отклонит
5.2 Для чего нужна команда tinker panic 0
Если ваш ntp сервер настраивается на виртуальной машине, то у него нету физических часов измеряющих время. Работа виртуальной машины по той или иной причине в любой момент может быть приостановлена и возобновлена спустя много часов. В таком случае, в момент обновления времени из интернета, если локальное время и время из интернета сильно различаются, ntpd запаникует и самовыпилится.
5.3 Пункт 5.1.1.4 официальной документации
В идеале, эталонное время по всему миру – одинаковое. Будучи синхронизированным однажды, между локальным и эталонным временем не должно появиться неожиданных различий. В связи с этим, NTP не обладает какими-либо механизмами для разрешения возникающей проблемы.
Однако реакция ntpd будет зависеть от величины разницы между локальным и эталонным временем. При очень маленьком различии во времени, ntpd подкорректирует локальное время как и обычно. При маленьких и средних отклонениях, ntpd будет игнорировать эталонное время в течении небольшого промежутка. В последнем случае, локальные часы продолжат работать с тем временем, которое было на момент последней успешной синхронизации. Эталонное время, получаемое из вне, содержащее отклонение от локального – будет игнорироваться. При этом, постепенно, маленькие отклонения (намного меньше секунды), будут выравниваться, путем пошаговой подстройки локальных часов к эталонному времени. Средние же отклонения приведут к переустановке значения времени локальных часов на эталонное, без пошаговой подстройки. Огромные же отклонения будут проигнорированы и приведут к тому, что ntpd самовыпилится, будучи уверенным в том что в мире полном зла, творится что-то очень для него непонятное. Этот же алгоритм действий применяется при первом запуске ntpd после перезагрузки.
Вывод: Таким образом, на виртуальной машине, только что вышедшей из сна, даже после непродолжительного по человеческим меркам простоя, ntpd будет биться в истерике, что приведет к его преждевременной кончине. Без настройки tinker panic 0 , однажды случившись, эта ситуация не разрешится без человеческого вмешательства.
5.4 Отключаем синхронизацию времени с хостом
У гипервизоров есть очень удобная и вне всяких сомнений нужная функция. Но настраивая контроллер домена на Ubuntu 18.04, помните! По дефолту, все виртуальные машины работающие на нём, получают от него время. Проблема в том, что гипервизор может например не находиться в домене, в котором находится ntp сервер. И может даже не быть подключен к внешнему источнику времени. В этом случае, он навяжет своё время ntp серверу расположенному на одной из его вирт машин. При следующей синхронизации времени, ntpd увидит что локальные часы и эталонное время отличаются например на 5-10 минут и у него случится припадок. Последствия которого вполне вероятно придется разгребать собственными ручками. Ниторт.
Задача: разобрать действия по организации сервиса времени для всей локальной сети дабы рабочие станции, сервера получали точное время и оно везде было одинаковым . Сервис времени организовывается на домен контроллере под управлением операционной системы Windows Server 2012 R2, также действия ниже аналогичны и для Server 2008 R2
Открываю на srv-dc консоль командной строки с правами администратора:
Win + X — Command Prompt (Admin)
Определяю какой домен контроллер (Windows Server 2012 R2 Std) имеет роль PDC если домен контроллеров несколько в домене:
C:\Windows\system32>netdom query fsmo
- Schema master srv-dc.polygon.local
- Domain naming master srv-dc.polygon.local
- PDC srv-dc.polygon.local
- RID pool manager srv-dc.polygon.local
- Infrastructure master srv-dc.polygon.local
The command completed successfully.
Как видно из вывода, это контроллер домена srv-dc.polygon.local, подключаюсь теперь к нему по RDP или VNC соединению для выполнения следующих команд:
C:\Windows\system32>net stop w32time
Настраиваем внешний источник времени:
C:\Windows\system32>w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org"
Cделать ваш контроллер домена PDC доступным для клиентов:
C:\Windows\system32>w32tm /config /reliable:yes
Запускаю службу времени:
C:\Windows\system32>net start w32time
Также можно изменения вносить и через реестр в ключе: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Чтобы после принудительно запросить получение точного времени проделываем:
C:\Windows\system32>W32tm /config /reliable:yes
The command completed successfully.
C:\Windows\system32>W32tm /config /update
The command completed successfully.
C:\Windows\system32>W32tm /resync
Sending resync command to local computer
The command completed successfully.
Вот и все, служба времени Windows начинает синхронизацию времени с внешним источником, посмотреть этот процесс можно так:
C:\Windows\system32>w32tm /query /configuration
После нужно добавить параметр в DHCP оснастку, что сервер времени это наш домен контроллер:
Win + X — Control Panel — Administrative Tools — запускаю оснастку DHCP: DHCP → srv-dc.polygon.local → IPv4 → Scope [10.10.10.0] local → и через правый клик мышью по Scope Options вызываю меню Configure Options… где добавляю опцию для всего домена: 042 NTP Servers
Теперь доменные Windows станции будут знать, что сервер времени это домен контроллер, а для моих Ubuntu системы после установке sudo apt-get install ntp -y в файле /etc/ntp.conf нужно будет в параметре server указать IP адрес этого домен контроллера и перезапустить службу времени sudo service ntp restart.
Если же у Вас DHCP сервис развернут не на Windows, то донести до всех где брать точное время можно через групповые политики GPO. Создаем GPO_NTP и предопределяем, что ориентирована она будет на текущий домен и все рабочие станции посредством WMI-фильтра.
Открываю оснастку на srv-dc управления групповыми политиками домена:
и
нажимаю OK, OK, Save
После перехожу к редактированию групповой политики для рабочих станции домена , через правый клик мышью по GPO_NTP вызываю меню Edit.
Computer Configuration → Policies → Administrative Tools → System → Windows Time Service → Time Providers → Configure Windows NTP Client, включаю ее Enabled и определяю настройки:
NtpServer: srv-dc.polygon.local,0x9
все остальное оставляю по умолчанию.
После нажимаю Apply & OK.
И не забываем к политике добавить WMI фильтр. В конечном итоге политика должна выглядеть так:
После когда политика применится к системам согласно WMI-фильтру можно будет проверить куда смотрит рабочая станции если ей нужно точное время:
C:\Users\alektest>w32tm /query /status
Индикатор помех: 0(предупреждений нет)
Страта: 4 (вторичная ссылка - синхронизирована с помощью (S)NTP)
Точность: -6 (15.625ms за такт времени)
Задержка корня: 0.0876923s
Дисперсия корня: 7.8503892s
Идентификатор опорного времени: 0x0A0A0A02 (IP-адрес источника: 10.10.10.2)
Время последней успешной синхронизации: 30.04.2017 16:46:38
Интервал опроса: 10 (1024s)
C:\Users\alektest>w32tm /monitor
srv-dc.polygon.local *** PDC ***[10.10.10.2:123]:
ICMP: 0ms задержка
NTP: +0.0000000s смещение относительно srv-dc.polygon.local
На замету: Если же в локальной сети появятся рабочие станции под управлением Windows 8 и выше, то нужно будет модифицировать WMI фильтр.
Но как известно, в случае чего с домен контроллером его роли можно забирать, так может произойти в случае различных проблем. Вот забрали роль PDC и время поехало во всем домене, чтобы этого не произошло нужно создать групповую политику ориентированную только на домен контроллер с ролью PDC: GPO_PDC и WMI фильтр с именем PDC следующего содержания:
Select * from Win32_ComputerSystem where DomainRole = 5
Computer Configuration → Policies → Administrative Tools → System → Windows Time Service → Time Providers → Configure Windows NTP Client, включаю ее Enabled и определяю настройки:
все
остальное оставляю по умолчанию.
После нажимаю Apply & OK.
и Computer Configuration → Policies → Administrative Tools → System → Windows Time Service → Time Providers -> Enable Windows NTP Client включить Enable.
Также параметр Type вместо NT5DS можно использовать и NTP
И не забываем к политике добавить WMI фильтр ← PDC. Теперь не важно кто является домен контроллером, точное время на нем будет.
А раз так, что рабочие станции не обязательно привязывать/создавать к политике назначения точного времени, ведь по умолчанию рабочие станции домена, итак, забирают точное время с контроллера домена по умолчанию.
- Настраиваю GPO и привязываю ее через WMI фильтр к серверу у которого есть роль PDC
- В оснастке DHCP указываю параметр кто в домене является сервером у которого клиентским рабочим станциям запрашивать точное время.
- Если DHCP не на базе Windows, то можно настроить GPO и сделать нацеливание на определенную ось.
На заметку: Если домен контроллер развернут на виртуальной системе, то следует проверить, что время берется не с гипервизора, а через настройку этой заметки.
На заметку: если роль PDC б ыла переназначена на другой сервер, то я советую перезагрузить домен контроллер и все остальные также.
На этом у меня все. Задача выполнена и задокументирована, с уважением автор блога Олло Александр aka ekzorchik.
Более того: некоторые из нас одержимы временем. Мои часы питаются от солнечной энергии и получают точное время из Национального института стандартов и технологий (NIST) в Форт-Коллинз (штат Колорадо) через длинноволновую радиостанцию WWVB. Сигналы времени синхронизируются с атомными часами, также расположенными в форте Коллинз. Мой Fitbit синхронизируется с моим телефоном, который синхронизируется с сервером NTP, который в конечном итоге синхронизируется с атомными часами.
Устройства тоже следят за временем
Есть много причин, по которым нашим устройствам и компьютерам нужно точное время. Например, в банковской сфере, на фондовых рынках и других финансовых предприятиях транзакции должны выполняться в надлежащем порядке, и для этого критически важны точные временные последовательности.
Наши телефоны, планшеты, автомобили, системы GPS и компьютеры требуют точной настройки времени и даты. Я хочу, чтобы часы на рабочем столе моего компьютера показывали правильное время. Я хочу, чтобы в моём локальном календаре напоминания появлялись в нужное время. Правильное время также гарантирует, что задания cron и systemd запускались в нужное время.
Дата и время также важны для ведения журнала, поэтому немного проще найти те или иные логи, ориентируясь по дате и времени. Например, однажды я работал в DevOps (в то время его так не называли) и занимался настройкой системы электронной почты в штате Северная Каролина. Раньше мы обрабатывали более 20 миллионов писем в день. Отслеживание электронной почты через серию серверов или определение точной последовательности событий с использованием файлов журналов на географически разнесенных хостах может быть намного проще, если соответствующие компьютеры синхронизированы по времени.
Время одно — часов много
Хосты Linux должны учитывать, что существует системное время и время RTC. RTC (Real Time Clock — часы реального времени) является немного странным и не особо точным названием для аппаратных часов.
Аппаратные часы работают непрерывно, даже когда компьютер выключен, используя аккумулятор на материнской плате системы. Основная функция RTC — хранить время, когда соединение с сервером времени недоступно. В те времена, когда нельзя было подключиться к серверу времени через интернет каждый компьютер должен был иметь точные внутренние часы. Операционные системы должны были обращаться к RTC во время загрузки, и пользователь должен был вручную установить системное время, используя аппаратный интерфейс конфигурации BIOS, чтобы убедиться, что оно правильное.
Аппаратные часы не понимают концепцию часовых поясов; в RTC хранится только время, а не часовой пояс или смещение от UTC (Всемирное координированное время, которое также известно как GMT или среднее время по Гринвичу). Вы можете установить RTC с помощью инструмента, о котором я расскажу позже в этой статье.
Системное время — это время, которое ОС отображает на часах GUI на вашем рабочем столе, в выходных данных команды date, в метках времени журналов. Это также относится ко времени создания, изменения и открытия файлов.
На странице man для rtc есть полное описание RTC и системных часов.
Что там у NTP?
Компьютеры во всем мире используют NTP (сетевой протокол времени) для синхронизации своего времени со стандартными эталонными часами через интернет с помощью иерархии серверов NTP. Основные серверы времени находятся на уровне 1, и они напрямую подключены к различным национальным службам времени на уровне 0 через спутник, радио или даже модемы по телефонным линиям. Службы времени на уровне 0 могут быть атомными часами, радиоприёмником, который настроен на сигналы, передаваемые атомными часами, или приёмником GPS, использующим высокоточные сигналы часов, передаваемые спутниками GPS.
На подавляющем большинстве эталонных серверов открыто несколько тысяч общедоступных серверов NTP stratum 2, которые доступны для всех. Многие организации и пользователи (включая меня) с большим количеством хостов, которым требуется NTP-сервер, предпочитают устанавливать свои собственные серверы времени, поэтому только один локальный хост обращается к stratum 2 или 3. Затем они настраивают оставшиеся узлы в сети для использования локального сервера времени. В случае моей домашней сети это сервер уровня 3.
Различные реализации NTP
Первоначальная реализация NTP — это ntpd. Затем к ней присоединились две более новых, chronyd и systemd-timesyncd. Все три синхронизируют время локального хоста с сервером времени NTP. Служба systemd-timesyncd не так надёжна, как chronyd, но этого достаточно для большинства целей. Если RTC не синхронизирован, она может постепенно корректировать системное время, чтобы синхронизироваться с NTP-сервером, когда локальное системное время немного смещается. Служба systemd-timesync не может использоваться в качестве сервера времени.
Chrony — это реализация NTP, содержащая две программы: демон chronyd и интерфейс командной строки под названием chronyc. У Chrony есть некоторые функции, которые во многих случаях просто незаменимы:
- Chrony может синхронизироваться с сервером времени намного быстрее, чем старый сервис ntpd. Это хорошо для ноутбуков или настольных компьютеров, которые не работают постоянно.
- Он может компенсировать колебания тактовых частот, например, когда хост переключается в спящий режим или входит в спящий режим, или когда тактовая частота изменяется из-за скачкообразного изменения частоты, которое замедляет тактовые частоты при низких нагрузках.
- Он решает проблемы со временем, связанные с нестабильным сетевым соединением или перегрузкой сети.
- Он регулирует задержки в сети.
- После начальной временной синхронизации Chrony никогда не останавливает часы. Это обеспечивает стабильные и согласованные временные интервалы для многих системных служб и приложений.
- Chrony может работать даже без подключения к сети. В этом случае локальный хост или сервер можно обновить вручную.
- Chrony может выступать в качестве NTP-сервера.
RPM-пакеты NTP, Chrony и systemd-timesyncd доступны в стандартных репозиториях Fedora. RPM systemd-udev — это менеджер событий ядра, который в Fedora установлен по умолчанию, но не является обязательным для использования.
Вы можете установить все три и переключаться между ними, но это создаст лишнюю головную боль. Так что лучше не стоит. Современные релизы Fedora, CentOS и RHEL перешли на Chrony как стандартную реализацию, и кроме того, у них есть systemd-timesyncd. Я считаю, что Chrony работает хорошо, обеспечивает лучший интерфейс, чем служба NTP, предоставляет гораздо больше информации и повышает контроль, что безусловно понравится системным администраторам.
Отключение служб NTP
Возможно, на вашем хосте уже запущена служба NTP. Если это так, вам нужно отключить её перед переключением на что-то другое. У меня был запущен chronyd, поэтому я использовал следующие команды, чтобы остановить и отключить его. Запустите соответствующие команды для любого демона NTP, который вы используете на своем хосте:
Проверьте, что служба остановлена и отключена:
Проверка статуса перед запуском
Статус системной синхронизации часов позволяет определить, запущена ли служба NTP. Поскольку вы ещё не запустили NTP, команда timesync-status намекнёт на это:
Прямой запрос статуса даёт важную информацию. Например, команда timedatectl без аргумента или параметров выполняет подкоманду status по умолчанию:
Так вы получите местное время для вашего хоста, время UTC и время RTC. В данном случае системное время установлено на часовой пояс America / New_York (TZ), RTC установлено на время в местном часовом поясе, а служба NTP не активна. Время RTC начало немного отклоняться от системного времени. Это нормально для систем, часы которых не были синхронизированы. Величина смещения на хосте зависит от времени, прошедшего с момента последней синхронизации системы.
Мы также получили предупреждение об использовании местного времени для RTC — это относится к изменениям часового пояса и настройкам летнего времени. Если компьютер выключен в тот момент, когда необходимо внести изменения, время RTC не изменится. Но для серверов или других хостов, которые работают круглосуточно, это вообще не проблема. Кроме того, любая служба, которая обеспечивает синхронизацию времени NTP, будет корректировать время хоста ещё на начальном этапе запуска, поэтому после завершения запуска время вновь станет правильным.
Установка часового пояса
Обычно вы указываете часовой пояс во время процедуры установки, и у вас нет задачи менять его в дальнейшем. Однако бывают случаи, когда необходимо изменить часовой пояс. Есть несколько инструментов, которые могут помочь. Для определения местного часового пояса хоста Linux использует файлы часовых поясов. Эти файлы находятся в каталоге /usr/share/zoneinfo. По умолчанию для моего часового пояса система прописывает вот это: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Но вам не нужно знать такие тонкости, чтобы изменить часовой пояс.
Главное — знать официальное название часового пояса для вашего местоположения и соответствующую команду. Скажем, вы хотите изменить часовой пояс на Лос-Анджелес:
Теперь вы можете установить часовой пояс. Я использовал команду date для проверки изменений, но вы также можете использовать timedatectl:
Теперь вновь можете изменить часовой пояс своего хоста на местное время.
systemd-timesyncd
Демон systemd timesync предоставляет реализацию NTP, которой легко управлять в контексте systemd. Он устанавливается по умолчанию в Fedora и Ubuntu. Однако запускается он по умолчанию только в Ubuntu. Я не уверен насчёт других дистрибутивов. Вы можете проверить у себя сами:
Конфигурирование systemd-timesyncd
Файл конфигурации для systemd-timesyncd — это /etc/systemd/timesyncd.conf. Это простой файл с меньшим количеством включенных опций, чем в старых сервисах NTP и chronyd. Вот содержимое этого файла (без дополнительных изменений) на моей виртуальной машине с Fedora:
Единственный раздел, который он содержит, кроме комментариев, это [Time]. Все остальные строки закомментированы. Это значения по умолчанию, их не нужно менять (если у вас нет для этого причин). Если у вас нет сервера времени NTP, определенного в строке NTP =, по умолчанию в Fedora используется резервный сервер времени Fedora. Я обычно добавляю свой сервер времени:
Запуск timesync
Запустить и сделать systemd-timesyncd активным можно так:
Установка аппаратных часов
Вот как выглядит ситуация после запуска timesyncd:
Изначально разница между RTC и местным временем (EDT) не превышает секунды, и расхождение возрастает ещё на пару секунд в течение следующих нескольких дней. Поскольку в RTC нет понятия часовых поясов, команда timedatectl должна выполнить сравнение, чтобы определить нужный часовой пояс. Если время RTC точно не соответствует местному времени, то значит, оно не соответствует и местному часовому поясу.
В поисках дополнительной информации я проверил состояние systemd-timesync и обнаружил вот что:
Команда timedatectl не имеет возможности взять значение аппаратных часов из системных часов. Она может установить время и дату только из значения, введённого в командной строке. Вы можете установить RTC на то же значение, что и системное время, используя команду hwclock:
Опция --localtime говорит о том, что аппаратные часы показывают местное время, а не UTC.
Зачем вам вообще RTC?
Любая реализация NTP установит системные часы во время запуска. И зачем тогда RTC? Это не совсем так: это произойдет только в случае, если у вас есть сетевое соединение с сервером времени. Однако многие системы не имеют постоянного доступа к сетевому соединению, поэтому аппаратные часы полезны для того, чтобы Linux мог на их основе установить системное время. Это лучше, чем установка времени вручную, даже если оно может отклоняться от реального времени.
Заключение
В этой статье рассмотрены некоторые инструменты для управления датой, временем и часовыми поясами. Инструмент systemd-timesyncd предоставляет NTP-клиента, который может синхронизировать время на локальном хосте с NTP-сервером. Однако systemd-timesyncd не предоставляет серверную службу, поэтому, если вам нужен NTP-сервер в вашей сети, вы должны использовать что-то ещё — например, Chrony, для работы в качестве сервера.
Я предпочитаю иметь единственную реализацию для любой служб в моей сети, поэтому использую Chrony. Если вам не нужен локальный NTP-сервер или если вы не против использовать Chrony в качестве сервера и systemd-timesyncd в качестве SNTP-клиента. Ведь нет необходимости использовать дополнительные возможности Chrony как клиента, если вас устраивает функционал systemd-timesyncd.
Еще одно замечание: вы не обязаны использовать инструменты systemd для реализации NTP. Вы можете использовать старую версию ntpd, Chrony или другую реализацию NTP. Ведь systemd состоит из большого количества сервисов; многие из них являются необязательными, поэтому их можно отключить и использовать вместо них что-то ещё. Это не огромный монолитный монстр. Можно не любить systemd или его части, но вы должны принять обоснованное решение.
Мне нравится реализация NTP в systemd, но я предпочитаю Chrony, потому что он лучше отвечает моим потребностям. Это Linux, детка -)
На правах рекламы
VDSina предлагает серверы под любые задачи, огромный выбор операционных систем для автоматической установки, есть возможность установить любую ОС с собственного ISO, удобная панель управления собственной разработки и посуточная оплата. Напомним, у нас есть вечные серверы, которые точно неподвластны времени ;)
Возможно, вы настроили задания cron, которые запускаются в определенное время, для резервного копирования важных файлов или выполнения каких-либо системных задач.
Или, возможно, вы настроили сервер журналов на регулярную ротацию логов в вашей системе.
Если ваши часы не синхронизированы, эти задания не будут выполняться в нужное время.
Вот почему важно установить правильный часовой пояс в системах Linux и синхронизировать часы с Интернетом.
В этом руководстве рассказывается, как настроить синхронизацию времени в Ubuntu Linux.
Приведенные ниже шаги были протестированы в Ubuntu 18.04, однако они одинаковы для других систем на основе Ubuntu, которые используют службу timedc systemd.
Настройка синхронизации времени в Ubuntu
Обычно мы устанавливаем часовой пояс во время установки.
Однако вы можете изменить его или установить другой часовой пояс, если хотите.
Во-первых, давайте посмотрим текущий часовой пояс в нашей системе Ubuntu с помощью команды «date»:
Как видно из вышеприведенного вывода, команда «date» показывает фактическую дату, а также текущее время.
Кроме того, вы можете посмотреть файл /etc/timezone, чтобы найти текущий часовой пояс.
Теперь посмотрим, синхронизированы ли часы с интернетом. Для этого просто запустите:
Как вы можете видеть, команда «timedatectl» отображает местное время, универсальное время, часовой пояс, а также то, синхронизированы ли системные часы с интернет-серверами и активен или неактивен systemd-timesyncd.service.
В моем случае системные часы синхронизируются с интернет-серверами.
Примечание: скриншот выше. Вот почему вы видите разные даты.
Если вы видите «System clock synchronized: значение установлено как no, служба timesyncd может быть неактивна.
Итак, просто перезапустите сервис и посмотрите, поможет ли это
Теперь проверьте статус сервиса timesyncd:
Если эта служба включена и активна, ваши системные часы должны синхронизироваться с интернет-серверами времени.
Вы можете проверить, включена ли временная синхронизация или нет, используя команду:
Если это все еще не работает, выполните следующую команду, чтобы включить синхронизацию времени:
Теперь ваши системные часы будут синхронизироваться с интернет-серверами времени.
Изменить часовой пояс с помощью команды Timedatectl
Что если я хочу использовать другой часовой пояс, отличный от UTC? Это легко!
Во-первых, список доступных часовых поясов можно вывести с помощью команды:
Вы увидите вывод, похожий на изображение ниже.
Вы можете установить желаемый часовой пояс (например, Asia/Kolkata), используя команду:
Еще раз проверьте, действительно ли был изменен часовой пояс с помощью команды «date»:
$ date
Tue Jul 30 17:52:33 IST 2019
Или используйте команду timedatectl, если хотите получить подробный вывод:
Как вы заметили, я изменил часовой пояс с UTC на IST (индийское стандартное время).
Читайте также: