Установка и настройка сервера времени в centos 7

Настраиваем время

Узнать, какое время на сервере можно с помощью команды date:

# date

Чтобы сменить часовой пояс, необходимо выбрать подходящий файл часовой зоны в /usr/share/zoneinfo. В случае, если у вас часовой пояс Москвы, выполните следующее:

# mv /etc/localtime /etc/localtime.bak
# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Либо можете воспользоваться специальной утилитой, которая входит в комплект CentOS 7. Делает она ровно то же самое:

# timedatectl set-timezone Europe/Moscow

В CentOS 7 есть утилита для синхронизации времени chrony. В стандартной установке она должна быть установлена в системе, в минимальной ее нет. Если у вас она не стоит, то устанавливайте вручную:

# yum install chrony

Запускаем chrony и добавляем в автозагрузку:

# systemctl start chronyd
# systemctl enable chronyd

Проверяем, нормально ли запустился:

# systemctl status chronyd
● chronyd.service - NTP client/server
 Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
 Active: active (running) since Fri 2016-08-05 00:33:09 MSK; 52min left
 Main PID: 667 (chronyd)
 CGroup: /system.slice/chronyd.service
 └─667 /usr/sbin/chronyd

Aug 05 00:33:09 centos.local systemd: Starting NTP client/server...
Aug 05 00:33:09 centos.local chronyd: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Aug 05 00:33:09 centos.local chronyd: Generated key 1
Aug 05 00:33:09 centos.local systemd: Started NTP client/server.
Aug 05 00:33:26 centos.local chronyd: Selected source 85.21.78.91
Aug 05 00:33:26 centos.local chronyd: System clock wrong by -3595.761368 seconds, adjustment started
Aug 04 23:33:30 centos.local chronyd: System clock was stepped by -3595.761368 seconds

Все в порядке, сервис работает. После запуска он автоматически синхронизирует время.

Для синхронизации времени вы можете воспользоваться более привычно программой, которая присутствует практически во всех unix дистрибутивах — ntp. Устанавливаем утилиту синхронизации времени ntp в CentOS:

# yum install ntp

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

# /usr/sbin/ntpdate pool.ntp.org

Если ntpdate не работает, посмотрите материал, может это ваш случай. Запустим демон синхронизации и запишем его запуск в автозагрузку:

# systemctl start ntpd
# systemctl enable ntpd
ln -s '/usr/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'

Теперь наши часы будут автоматически синхронизироваться с сервером времени.

Не используйте одновременно оба демона синхронизации времени — chrony и ntp. Выберите какой-нибудь один. Лично я не вижу в них разницы, сам чаще всего ставлю привычный ntp.

Синхронизация времени с помощью chrony, ntpdate

Способов синхронизации времени в centos существует как минимум три:

  • ручной с помощью утилиты ntpdate
  • автоматический при помощи сервиса ntp или chrony
  • автоматический через утилиту из пакета systemd — timesyncd.

Рассмотрим сначала вариант ручной однократной синхронизации при помощи программы ntpdate. Она позволяет разово синхронизировать локальное время с эталонным сервером времени в интернете. Подобных эталонов существует великое множество. Мы для примера воспользуемся одним из них — pool.ntp.org

Запускаем синхронизацию времени:

# ntpdate pool.ntp.org 21 Oct 11:50:37 ntpdate: adjust time server 85.21.78.8 offset -0.001664 sec

Если получите ошибку

-bash: ntpdate: command not found

значит утилита у вас не установлена. Установить ее можно из базового репозитория.

# yum install ntpdate

Это актуально только для 7-й версии, в В CentOS 8 ntp и ntpdate убрали из репозиториев. Для синхронизации времени можно использовать только chrony. Ее мы рассмотрим ниже.

Утилита ntpdate провела синхронизацию, в результате которой к моему системному времени было добавлено 0.001664 секунды для приближения к эталонному. Если в результате работы синхронизации вы получаете ошибку: no server suitable for synchronization found то попробуйте в работе утилиты использовать непривилегированный порт. По-умолчанию ntpdate работает по 123 порту. Если он закрыт на фаерволе, то помочь в синхронизации поможет следующий параметр:

# ntpdate -u pool.ntp.org

Если у вас запуск ntpdate завершается ошибкой — the NTP socket is in use, exiting, значит у вас уже установлена и запущена служба ntpd, которая заняла udp порт, необходимый для работы ntpdate. Установкой и настройкой этой службы мы и займемся далее.

Как я уже сказал, в CentOS 8 служба ntpd и утилита ntpdate стали недоступны в базовых репозиториях. Возможно, их как-то удастся установить из сторонних репозиториев, но большого смысла нет. Можно воспользоваться программой chrony. Ставим ее:

# yum install chrony

Запускаем и добавляем в автозагрузку.

# systemctl start chronyd # systemctl enable chronyd # systemctl status chronyd

Программа стартовала и уже выполнила синхронизацию с источниками точного времени в интернете. Каких-то особых настроек для получения точного времени больше не надо. Служба будет постоянно работать и выполнять синхронизацию. Проверим это с помощью timedatectl.

# timedatectl status

systemd-timesyncd

Отдельно пару слов о службе systemd-timesyncd, которая в системах с systemd выступает в роли простого sntp клиента, в отличие от chrony и ntp, которые в том числе могут работать в качестве сервера времени. В Debian служба systemd-timesyncd присутствует в составе systemd и ей можно пользоваться, что достаточно удобно. Легкий полновесный клиент, который по дефолту есть в составе системы.

Я сначала не мог понять, что с systemd-timesyncd в Centos. Команда вроде есть и работает, но как оказалось, это просто обертка над chrony. Реально команда управляет именно chrony и без него не работает. Без него вы получите ошибку, при попытке активировать компонент timesyncd.

# timedatectl set-ntp true Failed to set ntp: NTP not supported

Если вернете chrony в систему, то timedatectl будет запускать именно его. Немного погуглив, я понял в чем тут дело. Red Hat компилирует systemd без компонента systemd-timesyncd, предлагая по дефолту именно chrony.

установка, настройка и синхронизация времени в CentOS

Первым делом обновим базовую систему:

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntaxсинтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Перезаписываем файл unknown.syntax. Именно этот шаблон будет применяться к .conf и .cf файлам, так как к ним явно не привязано никакого синтаксиса.

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

И увидите ответ:

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

Вместо ifconfig в CentOS 7 теперь утилита ip. Я не понимаю, зачем пилить отдельные программы для управления сетевыми настройками, если ifconfig и так отлично справляется с задачей. К тому же мне всегда нравилось, что в различных дистрибутивах линукс все примерно одинаковое. С помощью ifconfig можно настроить сеть не только в linux, но и в freebsd. Это удобно. А когда в каждом дистрибутиве свой инструмент это неудобно. Так что предлагаю установить привычный ifconfig.

Теперь, чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

Так что устанавливаем bind-utils:

Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:

меняем значениеSELINUX=disabledЧтобы изменения вступили в силу, перезагружаемся:

Можно без перезагрузки применить отключение SElinux:

CentOS 8 minimal

Следующим этапом нужно указать, какой набор программного обеспечения будет установлен на сервер вместе с системой. Тут выбираете на свой вкус и потребности. Я обычно ставлю всегда самый минимальный набор, а все, что необходимо, добавляю позже. Уж точно мне на сервере не нужен GUI. Так что мой выбор — Minimal Install и установка Standart. Если ставлю на виртуальную машину, то дополнительно выбираю Guest Agents.

Следующий важный этап установки centos 8 — выбор диска и разметка. Тут нет универсальных советов, все зависит от назначения сервера и вашего понимания сути разделения диска на разделы. Лично я всегда выбираю ручную разметку диска и выполняю ее так:

  1. Раздел /boot размером в 1 Гб.
  2. Корневой раздел / на lvm на всем оставшемсяс вободном месте.

Чтобы перейти в ручную разметку диска, надо выбрать диск, нажать Custom и кнопку Done.

Дальше я жму на Click here to create them automatically и редактирую предложенную автоматическую разбивку.

В принципе, раздел /boot тоже можно было бы разместить в корне, работать будет нормально, но я сталкивался с неожиданными проблемами, когда /boot раздел был на lvm. Так что не буду вам рекомендовать его там размещать. Размера в 1 Гб мне всегда хватало, но в целом, если есть возможность, можно выделить и 2 Гб, чтобы было с заметным запасом.

Установщик автоматически предложит вам сделать swap раздел на отдельном lvm томе. Я обычно отказываюсь от этого и вообще не делаю swap. Это не принципиальный момент, мне так просто удобно. После установки я подключаю swap в виде отдельного файла. Так им проще управлять. Если вам не хочется с этим возиться, оставьте как есть. Финальная разметка диска получается следующая.

После того, как нажмете Done, появится предупреждение.

Warning checking storage configuration. Click for details or press Done again to continue.

Можете прочитать суть предупреждения, хотя я знаю, что там будет указано. Вас предупредят, что вы забыли создать раздел swap. А если у вас на сервере меньше 512 Мб памяти, то еще скажут, что без swap продолжить установку невозможно с таким количеством памяти. Тогда вариантов нет, подключайте swap.

Не буду подробно задерживаться на настройке KDUMP, просто отключите его. Если не знаете, что это такое, значит вам 100% это не нужно. Подробнее рассмотрим настройку сетевых интерфейсов. Идем в раздел NETWORK & HOST NAME (раньше было NETWORK & HOSTNAME, без пробела, еще один плюс к квартальной премии, кажется я начинаю понимать суть нововведений и объявлений deprecated в современных системах).

Ставим переключатель в положение ON и получаем автоматически настройки по dhcp, если подобная служба работает в сети, на которую смотрит интерфейс:

  1. Включение ползунка в положение ON активирует интерфейс, он получает настройки по dhcp.
  2. Если вы хотите изменить эти настройки, нажимаете Configure.
  3. Указываете Host Name. Если забудете, то после установки этот параметр можно изменить.

Завершаем настройку традиционным нажатием на Done. Теперь можно вернуться в настройки часов и активировать Network Time.

Подготовка по сути завершена. Раздел Security Policy оставляем пустым. Теперь можно нажать на кнопку Begin installation и запустить непосредственно установку Centos 8. Делаем это и параллельно задаем пароль для root пользователя. Нравится, как это реализовано в centos.

Синхронизация времени с NTP в Linux

В каждой операционной системе есть свой метод поддержания точного времени машины в соответствии с часовым поясом. В Linux работу по поддержанию точного времени вашего компьютера выполняет Chrony. Chrony — это сетевой протокол времени для Debian, Red Hat, Arch и других дистрибутивов Linux, который может синхронизировать время по сетевому протоколу.

У Chrony есть демон, который незаметно работает на вашем компьютере с Linux. Разработчики программного обеспечения Red Hat создали Chrony; сейчас он широко используется во всех операционных системах на базе Linux. Он написан на языке программирования C и имеет лицензию конфиденциальности GNU. Этот пост покажет вам, как синхронизировать время с NTP в Linux с помощью инструмента Chrony (NTP).

Шаг 1. Установите Chrony в Linux

Самый первый шаг — установка Chrony в Linux. Его легко установить на Debian, Red Hat, серверах и других дистрибутивах Linux из официального репозитория Linux. Если вы являетесь пользователем Debian / Ubuntu Linux, вы можете запустить следующую команду aptitude, указанную ниже, чтобы установить Chrony в вашей системе.

sudo apt-get install chrony

Если вы являетесь пользователем Red Hat или Fedora Linux, вы можете установить Chrony, выполнив следующую команду DNF или YUM в оболочке терминала.

Установите Chrony в Red Hat Linux

sudo yum install chrony

Установите Chrony в Fedora Linux

sudo dnf install chrony

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

# systemctl enable --now chronyd 
# systemctl status chronyd

Вы также можете выполнить следующую команду, чтобы проверить активность Chrony на вашем компьютере с Linux.

# chronyc activity

Шаг 2. Отслеживайте параметры Chrony в Linux

После установки инструмента Chrony на вашем Linux теперь вы можете отслеживать режим источника, состояние источника, IP-адрес, частоту дискретизации NTP из оболочки терминала. Выполните следующую команду в оболочке терминала с правами root, чтобы проверить параметры Chrony.

chronyc sources -v

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

chronyc sourcestats -v

Шаг 3. Настройте Chrony для синхронизации времени

Chrony запускает в системе демон для автоматической синхронизации времени в системе Linux через сервер NTP. Вы можете найти сценарий конфигурации Chrony в файле /etc/chrony/chrony.conf. Чтобы отредактировать и настроить конфигурацию Chrony, вы можете запустить следующую команду в оболочке терминала. Здесь я использую редактор сценариев Nano для редактирования сценария конфигурации Chrony; вы также можете использовать другие редакторы.

sudo nano /etc/chrony/chrony.conf

Обычно NTP использует пакетный сервер пула 0.pool.ntp.org для синхронизации времени с NTP в Linux. Но вы можете добавить следующие адреса серверов NTP в сценарий конфигурации для синхронизации времени с NTP в Linux.

server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org ibusrt
server 3.europe.pool.ntp.org ibusrt

После настройки адресов NTP-серверов в вашей системе Linux не забудьте перезапустить службы Chrony на вашем компьютере. Выполните следующую команду управления системой, чтобы перезапустить демон Chrony на вашем компьютере с Linux.

sudo systemctl restart chrony

Шаг 4. Отслеживайте время с помощью Chrony

Ранее мы видели, как отслеживать параметры Chrony и как настраивать параметры Chrony. Теперь мы можем видеть источники Chrony для отслеживания параметров демона Chrony. Выполните следующую команду в оболочке терминала с правами суперпользователя, чтобы отслеживать исходный код Chrony.

# chronyc sources

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

# chronyc tracking

Наконец, запустите следующую команду timedatectl в оболочке терминала, чтобы отобразить текущее местное время, всемирное время, время RTC, часовой пояс и статус сервера NTP на вашем компьютере с Linux.

# timedatectl

Отключаем флуд сообщений в /var/log/messages

В дефолтной установке системы CentOS 7, весь ваш системный лог /var/log/messages через некоторое время работы сервера будет забит следующими записями.

Oct 16 14:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 14:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 14:01:01 xs-files systemd: Started Session 14440 of user root.
Oct 16 14:01:01 xs-files systemd: Starting Session 14440 of user root.
Oct 16 14:01:01 xs-files systemd: Removed slice user-0.slice.
Oct 16 14:01:01 xs-files systemd: Stopping user-0.slice.
Oct 16 15:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 15:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 15:01:01 xs-files systemd: Started Session 14441 of user root.
Oct 16 15:01:01 xs-files systemd: Starting Session 14441 of user root.
Oct 16 15:01:01 xs-files systemd: Started Session 14442 of user root.
Oct 16 15:01:01 xs-files systemd: Starting Session 14442 of user root.
Oct 16 15:01:01 xs-files systemd: Removed slice user-0.slice.
Oct 16 15:01:01 xs-files systemd: Stopping user-0.slice.
Oct 16 16:01:01 xs-files systemd: Created slice user-0.slice.
Oct 16 16:01:01 xs-files systemd: Starting user-0.slice.
Oct 16 16:01:01 xs-files systemd: Started Session 14443 of user root.
Oct 16 16:01:01 xs-files systemd: Starting Session 14443 of user root.
Oct 16 16:01:01 xs-files systemd: Removed slice user-0.slice.

Никакой практической пользы они не несут, поэтому отключим их. Для этого создадим отдельное правило для rsyslog, где перечислим все шаблоны сообщений, которые будем вырезать. Разместим это правило в отдельном файле /etc/rsyslog.d/ignore-systemd-session-slice.conf.

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf
if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of") then stop

Сохраняем файл и перезапускаем rsyslog для применения настроек.

# systemctl restart rsyslog

Необходимо понимать, что в данном случае мы отключаем флуд в лог файл только на локальном сервере. Если вы храните логи на удаленном syslog сервере, то данное правило нужно будет настраивать именно на нем.

Включить брандмауэр в CentOs 7

Firewalld — это основная утилита брандмауэра, с которой взаимодействует для управления правилами iptables.

Чтобы включить, запустить и проверить брандмауэр в CentOS 7, выполните следующие команды.

Чтобы открыть определенную службу для входящих подключений, сначала проверьте, присутствует ли приложение в правилах firewalld, а затем добавьте правило для службы, как показано в следующем примере, который разрешает входящие подключения SSH. Используйте ключ —permanent для постоянного добавления правила.

Если служба уже определена в правилах firewalld, вы можете вручную добавить порт службы, как показано в примере ниже.

Базовая настройка сети

Смотрим все установленные сетевые адаптеры в системе:

ip a

В результате получаем что-то подобное:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:81:28:3c brd ff:ff:ff:ff:ff:ff
    inet 192.168.156.22/22 brd 192.168.159.255 scope global ens32
       valid_lft forever preferred_lft forever
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:50:56:81:3f:22 brd ff:ff:ff:ff:ff:ff
    inet 10.243.254.68/26 brd 10.243.254.127 scope global ens34
       valid_lft forever preferred_lft forever

* Из примера видно, что в моем CentOS есть 3 сетевых карты — lo (локальная петля), ens32 и ens34 — сетевые Ethernet адаптеры.

Если нужно настроить сеть для адаптера ens32, открываем на редактирование следующий конфигурационный файл:

vi /etc/sysconfig/network-scripts/ifcfg-ens32

И приводим его к следующему виду:

DEVICE=ens32
BOOTPROTO=static
IPADDR=192.168.0.155
NETMASK=255.255.255.0
GATEWAY=192.168.0.1
DNS1=192.168.0.54
DNS2=192.168.0.11
ONBOOT=yes

… а также для CentOS 8 добавим:

NM_CONTROLLED=yes

Основные опции

Опция Описание Возможные значения
DEVICE Имя сетевого адаптера Должно совпадать с именем в системе. В данном примере ens32
BOOTPROTO способ назначения IP-адреса static: ручное назначение IP, dhcp: автоматическое получение IP
IPADDR IP-адрес адрес, соответствующий вашей сети
NETMASK Сетевая маска должна соответствовать вашей сети
GATEWAY Шлюз по умолчанию IP-адрес сетевого шлюза
DNS1 Основной DNS-сервер IP-адрес сервера имен
DNS2 Альтернативный DNS-сервер IP-адрес сервера имен
ONBOOT Способ запуска сетевого интерфейса yes: автоматически при старте сервера, no: запускать вручную командой
NM_CONTROLLED Указываем, должен ли интерфейс управляться с помощью NetworkManager yes: управляется NetworkManager, no: не может управляться NetworkManager

Чтобы настройки применились, перезапускаем сетевую службу.

а) для CentOS 7:

systemctl restart network

б) для CentOS 8 вводим 2 команды:

systemctl restart NetworkManager

nmcli networking off; nmcli networking on

* в большей степени, это основное отличие версий 7 и 8. Чтобы команды смогли поменять настройки, для интерфейсов необходима настройка NM_CONTROLLED=yes.

Дополнительные опции (не обязательны для работы сети)

Опция Описание Возможные значения
IPV4_FAILURE_FATAL Отключение сетевого интерфейса, если IP-адрес (v4) имеет неверную конфигурацию yes: отключать, no: не отключать
IPV6_FAILURE_FATAL Отключение сетевого интерфейса, если IP-адрес (v6) имеет неверную конфигурацию yes: отключать, no: не отключать
IPV6_AUTOCONF Разрешает или запрещает автоконфигурирование IPv6 с помощью протокола Neighbor Discovery yes: разрешить автоконфигурирование, no: запретить
IPV6INIT Говорит о возможности использовать сетевой интерфейс для адресации IPv6 yes: адресация может использоваться, no: не используется
PEERROUTES Задает приоритет настройки шлюза по умолчанию, полученного от DHCP yes: маршрут от DHCP важнее, чем назначенный вручную, no: важнее маршрут, заданный вручную
IPV6_PEERROUTES Задает приоритет настройки шлюза по умолчанию, полученного от DHCP (для IPv6)
UUID Уникальный идентификатор сетевого интерфейса. Его можно сгенерировать самостоятельно командой uuidgen Строка из 32-х символов в формате 8-4-4-4-12.
Например: fca8cc84-6f21-4bac-9ccb-36f281321ba4

Step 3 — Configuring NTP to Join the Pool

To use your server with the NTP pool, and configure your new time servers, you’ll need to make some modifications to your NTP daemon’s configuration. To do so, edit the file:

First, make sure a driftfile is configured. A driftfile stores the frequency offset between the system clock running at its nominal frequency, and the frequency required to remain in synchronization with correct time. It helps to achieve a stable and accurate time. You should find this at the top of your configuration file on a default installation:

/etc/ntp.conf

Next, remove the default time source entries from the configuration. You’re looking for all lines which are of the pattern . If you’re using a default configuration, remove the highlighted lines as shown in the following example:

/etc/ntp.conf

Replace the lines you removed with the hand-picked servers you selected in the previous step.

/etc/ntp.conf

We use the option for each servers, per the NTP Pool recommendations. That way, if the server is unreachable, this will send a burst of eight packets instead of the usual one packet. Using the option in the NTP Pool Project is considered abuse as it will send those eight packets every poll interval, whereas sends the eight packets only the first time.

Next, make sure the default configuration does not allow management queries. If you don’t, your server could be used in NTP reflection attacks, or could be vulnerable to and queries that attempt to modify the state of the server. Check that the option is added to the default lines. Also make sure you add the options and as they restrict too eagerly asking clients and enforce rate limiting.

/etc/ntp.conf

You can find more information about the other options in the .

Your NTP daemon configuration file now should look like the following, although your file may have additional comments, which you can safely disregard:

/etc/ntp.conf

Save the file and exit the editor.

Now restart the NTP service and let your time server synchronize its clock to the upstream servers.

After a few minutes, check the health of your time server with the command:

The output should look similar to this:

The remote column tells you the hostname of the servers the NTP daemon is using, and the refid column tells you the source the servers are using. So for Stratum 1 servers, the refid field should show GPS, PPS, ACTS, or PTB, and Stratum 2 and higher servers will show the IP address of the upstream server. The st column shows the stratum, and delay, offset and jitter tell you about the quality of the time source. Lower values are better for these three fields.

Your time server is now able to serve time to the public. You can verify this by calling from another host:

The output should look similar to this and it tells you it adjusted the time server and the offset:

You are now ready to register your NTP server with the NTP Pool Project so others can use it.

Установка и настройка Winlogbeat

Для настройки централизованного сервера сбора логов с Windows серверов, установим сборщика системных логов winlogbeat. Для этого скачаем его и установим в качестве службы. Идем на страницу загрузок и скачиваем msi версию под вашу архитектуру — 32 или 64 бита.

Запускаем инсталлятор и в конце выбираем открытие директории по умолчанию.

Создаем и правим конфигурационный файл winlogbeat.yml. Я его привел к такому виду:

winlogbeat.event_logs:
  - name: Application
    ignore_older: 72h
  - name: Security
  - name: System

tags: 

output.logstash:
  hosts: 

logging.level: info
logging.to_files: true
logging.files:
  path: C:/ProgramData/Elastic/Beats/winlogbeat
  name: winlogbeat.log
  keepfiles: 7

xpack.monitoring:
  enabled: true
  elasticsearch:
    hosts: ["http://10.1.4.114:9200"]

В принципе, по тексту все понятно. Я беру 3 системных лога Application, Security, System (для русской версии используются такие же названия) и отправляю их на сервер с logstash. Настраиваю хранение логов и включаю мониторинг по аналогии с filebeat

Отдельно обращаю внимание на tags: . Этим тэгом я помечаю все отправляемые сообщения, чтобы потом их обработать в logstash и отправить в elasticsearch с отдельным индексом

Я не смог использовать поле type, по аналогии с filebeat, потому что в winlogbeat в поле type жестко прописано wineventlog и изменить его нельзя. Если у вас данные со всех серверов будут идти в один индекс, то можно tag не добавлять, а использовать указанное поле type для сортировки. Если же вы данные с разных среверов хотите помещать в разные индексы, то разделяйте их тэгами.

Для того, чтобы логи виндовых журналов пошли в elasticsearch не в одну кучу вместе с nginx логами, нам надо настроить для них отдельный индекс в logstash в разделе output. Идем на сервер с logstash и правим конфиг output.conf.

output {
    if  == "nginx_access" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "nginx-%{+YYYY.MM.dd}"
        }
    }
    else if  == "nginx_error" {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "nginx-%{+YYYY.MM.dd}"
        }
    }
    else if "winsrv" in  {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "winsrv-%{+YYYY.MM.dd}"
        }
    }
    else {
        elasticsearch {
            hosts     => "localhost:9200"
            index    => "unknown_messages"
        }
    }
	#stdout { codec => rubydebug }
}

Думаю, по тексту понятен смысл. Я разделил по разным индексам логи nginx, системные логи виндовых серверов и добавил отдельный индекс unknown_messages, в который будет попадать все то, что не попало в предыдущие. Это просто задел на будущее, когда конфигурация будет более сложная, можно будет ловить сообщения, которые по какой-то причине не попали ни в одно из приведенных выше правил. Я не смог в одно правило поместить оба типа nginx_error и nginx_access, потому что не понял сходу, как это правильно записать, а по документации уже устал лазить, выискивать информацию. Так получился рабочий вариант.

После этого перезапустил logstash и пошел на windows сервер, запустил службу Elastic Winlogbeat 7.11.0.

Подождал немного, пока появятся новые логи на виндовом сервере, зашел в kibana и добавил новые индексы. Напомню, что делается это в разделе Stack Management ->  -> Index Patterns.

Добавляем новый индекс по маске winsrv-*.

Можно идти в раздел Discover и просматривать логи с Windows серверов.

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

На этом я закончил настройку ELK стека из Elasticsearch, Logstash, Kibana, Filebeat и Winlogbeat. Описал основной функционал по сбору логов. Дальше с ними уже можно работать по ситуации — строить графики, отчеты, собирать дашборды и т.д. В отдельном разделе ELK Stack у меня много примеров на этот счет.

Синхронизация времени с помощью ntp и ntpdate

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

Покажу теперь простую утилиту ntpdate, с помощью которой можно разово синхронизировать время, не автоматически. Для начала ее нужно установить в систему.

Дальше запускаем для разовой синхронизации.

В данном случае pool.ntp.org — адрес сервера времени. Можно использовать любой. Все, время синхронизировано и никаких автоматических служб не запущено.

Если у вас ntpdate выдает ошибку — the NTP socket is in use, exiting, значит у вас уже установлена и запущена служба ntp, которая заняла udp порт 123, необходимый для работы ntpdate. Установкой и настройкой этой службы мы и займемся далее. Также, если ntpdate не работает, посмотрите материал, может это ваш случай.

Для обновления времени сервера можно воспользоваться службой ntp. Ее так же надо установить отдельно.

Это старая проверенная служба времени, которую использовали еще задолго до появления systemd и его юнитов. Запустим ее и добавим в автозагрузку.

После запуска она сразу же автоматически синхронизирует время. Проверим статус службы ntp в Debian.

Синхронизация времени через ntp заработала сразу же. Дополнительная настройка не нужна, если вас не интересует свой сервер времени, который мы настроим ниже.

При этом, для проверки статуса службы времени ntp можно использовать утилиту ntpq. Посмотрим статус синхронизации.

Поясню значения каждого столбца.

remote Адрес удаленного эталона времени, с которого была синхронизация
refid Указывает, откуда каждый эталон получает точное время. Это могут быть другие сервера времени, система GPS и другое
st Stratum (уровень) это число от 1 до 16, которое указывает на точность эталона. 1- максимальная точность, 16 — сервер недоступен. Уровень вашего сервера будет равен уровню наименее точного удаленного эталона плюс 1.
poll Интервал в секундах между опросами
reach Восьмеричное представление массива из 8 бит, отражающего результаты последних восьми попыток соединения с эталоном. Бит выставлен, если удаленный сервер ответил.
delay Время задержки ответа на запрос о точном времени
offset Разница между вашим и удаленным сервером
jitter Дисперсия (Jitter) — это мера статистических отклонений от значения смещения (поле offset) по нескольким успешным парам запрос-ответ. Чем меньше значение дисперсии, тем лучше, поскольку позволяет точнее синхронизировать время.

Какие часы бывают в Linux

Немного теории. В любом компьютере есть два вида часов. Одни аппаратные (ЧРВ — часы реального времени или RTC — real time clock), которые работают даже при выключенном блоке питания, на это у них есть батарейка на материнской плате. Другие программные, то есть часы операционной системы. Показания этих часов могут различаться. При этом программные часы опираются на показания аппаратных при старте операционной системы. А в дальнейшем могут синхронизироваться через интернет с эталонными и корректировать ход аппаратных.
В большинстве случаев если компьютер работает под управлением операционной системой Windows показания аппаратных и программных часов совпадают. В linux же чаще всего аппаратные часы настраивают по гринвичу (времени нулевого меридиана), а программные по необходимому смещению для часового пояса где расположен сервер.
Абсолютное большинство программ (приложений и сервисов) в своей работе опираются на показания системных (программных) часов.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: