Настраиваем время
Узнать, какое время на сервере можно с помощью команды 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 — выбор диска и разметка. Тут нет универсальных советов, все зависит от назначения сервера и вашего понимания сути разделения диска на разделы. Лично я всегда выбираю ручную разметку диска и выполняю ее так:
- Раздел /boot размером в 1 Гб.
- Корневой раздел / на 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, если подобная служба работает в сети, на которую смотрит интерфейс:
- Включение ползунка в положение ON активирует интерфейс, он получает настройки по dhcp.
- Если вы хотите изменить эти настройки, нажимаете Configure.
- Указываете 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 же чаще всего аппаратные часы настраивают по гринвичу (времени нулевого меридиана), а программные по необходимому смещению для часового пояса где расположен сервер.
Абсолютное большинство программ (приложений и сервисов) в своей работе опираются на показания системных (программных) часов.
