Системный журнал — практичная база знаний по VPS и Linux
Системный журнал Системный журнал
Linux • VPS • systemd • hostname • время

Hostname, время и часовой пояс на Linux VPS: правильная настройка

5 мин чтения Урок 4 из 6

Корректные hostname и системное время нужны не только для удобства. От них зависят журналы, TLS, cron и systemd timers, работа баз данных, почты, мониторинга и распределённых приложений. Ошибка на несколько минут может нарушить проверку сертификатов, а непоследовательное имя сервера усложняет поиск событий и резервных копий.

Какие имена есть у Linux-сервера

На обычном VPS важны три понятия:

  • Static hostname — постоянное системное имя, сохранённое в /etc/hostname.
  • Pretty hostname — необязательное человекочитаемое описание.
  • FQDN — полное доменное имя, например web01.example.net, которое должно согласовываться с DNS и /etc/hosts.

Посмотрите текущее состояние:

hostnamectl
hostname
hostname -f
cat /etc/hostname
getent hosts "$(hostname)"

Выберите понятную схему именования

Хорошее имя короткое, стабильно и описывает роль, а не временный проект:

web01
db01
monitor01
proxy-eu1

Используйте латинские буквы в нижнем регистре, цифры и дефис. Не включайте IP-адрес, пароль, имя клиента или другую чувствительную информацию. Если сервер должен иметь FQDN, заранее создайте DNS-запись.

Измените hostname через hostnamectl

sudo hostnamectl hostname web01.example.net
hostnamectl

На большинстве современных Debian и Ubuntu команда сразу обновляет постоянное имя. Перезагрузка обычно не нужна, но старые оболочки могут продолжать показывать прежнее приглашение до нового входа.

Настройте /etc/hosts без поломки sudo

Откройте файл:

sudoedit /etc/hosts

Для VPS с динамическим или внешним адресом безопасный базовый вариант:

127.0.0.1   localhost
127.0.1.1   web01.example.net web01

::1         localhost ip6-localhost ip6-loopback

Не привязывайте публичное имя к случайному адресу, если IP меняется или управляется облачной сетью. На сервере со статическим адресом и корректным reverse DNS можно использовать реальный адрес, но сначала проверьте требования провайдера.

Проверка:

getent hosts web01
getent hosts web01.example.net
hostname -s
hostname -f
sudo -n true || sudo true

Сообщение unable to resolve host обычно означает несоответствие /etc/hostname и /etc/hosts.

Учтите cloud-init

Некоторые VPS создаются через cloud-init, который способен вернуть имя при перезагрузке. Проверьте:

test -d /etc/cloud && grep -R "preserve_hostname" /etc/cloud 2>/dev/null

Если провайдер разрешает локальное управление именем, задайте в конфигурации cloud-init:

preserve_hostname: true

Не меняйте cloud-init вслепую на управляемом облачном сервере: имя может использоваться для внутреннего DNS и автоматизации.

Проверьте текущее время

timedatectl
date --iso-8601=seconds
date -u --iso-8601=seconds

Системные часы в Linux обычно ведутся в UTC, а часовой пояс влияет на отображение времени. Для сервера UTC часто удобнее: события из разных регионов проще сопоставлять. Локальный часовой пояс выбирайте, если он нужен операционным процедурам и расписаниям.

Установите часовой пояс

Найдите доступное имя:

timedatectl list-timezones | grep -i berlin

Установите его:

sudo timedatectl set-timezone Europe/Berlin
timedatectl

Для UTC:

sudo timedatectl set-timezone UTC

Не копируйте файл зоны вручную, если доступен timedatectl: команда корректно управляет ссылкой /etc/localtime.

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

sudo timedatectl set-ntp true
timedatectl show -p NTP -p NTPSynchronized -p Timezone

Какой именно клиент используется, зависит от образа VPS. Проверьте активные службы:

systemctl status systemd-timesyncd --no-pager
systemctl status chrony --no-pager
systemctl status chronyd --no-pager

Достаточно одного NTP-клиента. Одновременная работа нескольких демонов может создавать конфликты.

Проверка systemd-timesyncd

timedatectl timesync-status
journalctl -u systemd-timesyncd --since today --no-pager

Если служба отсутствует в минимальном образе Debian, установите её или используйте chrony:

sudo apt update
sudo apt install systemd-timesyncd
sudo systemctl enable --now systemd-timesyncd

Когда лучше использовать chrony

Chrony полезен на виртуальных машинах с нестабильной задержкой, после длительных пауз, при необходимости указать собственные NTP-серверы или предоставить время другим узлам.

sudo apt install chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

После установки убедитесь, что другой NTP-клиент не конкурирует с chrony.

Не устанавливайте время вручную без необходимости

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

sudo timedatectl set-ntp false
sudo timedatectl set-time '2026-07-15 15:00:00'
sudo timedatectl set-ntp true

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

Как время влияет на cron и systemd timers

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

systemctl list-timers --all
sudo crontab -l
ls -la /etc/cron.d /etc/cron.daily

Cron обычно использует локальное время системы. Systemd timers могут быть заданы локально или в UTC в зависимости от выражения. После изменения зоны следующий запуск может произойти не тогда, когда ожидалось.

Проверка DNS и reverse DNS

Hostname сам по себе не создаёт DNS-записи. Проверьте прямое разрешение:

getent ahosts web01.example.net

Reverse DNS настраивается в панели провайдера IP-адреса:

dig -x SERVER_IP +short

Для веб-сервера совпадение PTR и hostname не обязательно, но для почтового сервера согласованность имени, A/AAAA и PTR критична.

Проверка после настройки

hostnamectl
hostname -f
timedatectl
systemctl --failed
journalctl -b -p warning --no-pager

Дополнительно проверьте:

  • в журналах новые записи имеют ожидаемое время;
  • мониторинг видит правильное имя узла;
  • резервные копии не создают второй «новый» хост;
  • сертификаты и API-токены проходят проверку времени;
  • cron и timers запускаются по нужному расписанию.

Типовые ошибки

  • hostname возвращается после перезагрузки. Проверьте cloud-init или панель провайдера.
  • hostname -f не показывает FQDN. Исправьте DNS или /etc/hosts.
  • NTP active, но часы не синхронизированы. Проверьте UDP/123, DNS и журнал клиента.
  • Сертификат «ещё не действителен». Обычно системное время отстаёт.
  • Задача запустилась на час раньше. Проверьте смену летнего времени и используемую временную зону.

Итог

Правильная настройка состоит из согласованных элементов: постоянного hostname, корректного разрешения имени, выбранного часового пояса и одного работающего NTP-клиента. После изменений обязательно проверяйте расписания, журналы и интеграции, а не только вывод date.