
Я заметил, что «предпочтительный» метод установки имени хоста системы принципиально отличается в системах Red Hat/CentOS и Debian/Ubuntu.
Документация CentOSиРуководство по развертыванию RHELпроизнесите имя хостадолжно быть полное доменное имя:
HOSTNAME=<value>
, где<value>
должно быть полное доменное имя (FQDN), напримерhostname.example.com
, , но может быть любым необходимым именем хоста.
TheРуководство по установке RHELнемного более двусмысленно:
Программа установки предложит вам указать имя хоста для этого компьютера, либо как полное доменное имя(FQDN) в форматеимя_хоста.имя_домена или как короткое имя хоста в форматеимя хоста.
Справочник Debianговорит имя хостане следует использовать полное доменное имя:
3.5.5 Имя хоста
Ядро поддерживает системуимя хоста. Скрипт инициализации на уровне запуска S, который связан с символической ссылкой на "/etc/init.d/имя_хоста.sh" устанавливает имя хоста системы во время загрузки (используяимя хостакоманда) к имени, сохраненному в "/etc/имя_хоста". Этот файл должен содержатьтолькоимя хоста системы, а не полное доменное имя.
Я не видел никаких конкретных рекомендаций от IBM по поводу того, что использовать, нонекоторое программное обеспечениепохоже, у него есть предпочтения.
Мои вопросы:
- Что лучше в гетерогенной среде: следовать рекомендациям поставщика или выбрать один и обеспечить единообразие на всех хостах?
- С каким программным обеспечением, чувствительным к тому, задано ли имя хоста как полное доменное имя или как короткое имя, вы сталкивались?
решение1
Я бы выбрал последовательный подход во всей среде. Оба решения работают отлично и будут совместимы с большинством приложений. Однако есть разница в управляемости.
Я использую короткое имя в качестве настройки HOSTNAME и устанавливаю полное доменное имя в качестве первого столбца /etc/hosts
для IP-адреса сервера, за которым следует короткое имя.
Я не встречал много программных пакетов, которые бы применяли или отображали предпочтение между ними. Я нахожу, что короткое имя более понятно для некоторых приложений, особенно для ведения журналов. Может быть, мне не повезло, и я увидел внутренние домены вроде server.northside.chicago.rizzomanufacturing.com
. Кто хочет видеть это в журналах илиприглашение оболочки?
Иногда я участвую в поглощениях или реструктуризации компаний, когда внутренние домены и/или поддомены меняются. Мне нравится использовать короткое имя хоста в таких случаях, потому что ведение журнала, кикстарты, печать, мониторинг систем и т. д. не требуют полной перенастройки для учета новых доменных имен.
Типичная настройка сервера RHEL/CentOS для сервера с именем «rizzo» и внутренним доменом «ifp.com» будет выглядеть следующим образом:
/etc/sysconfig/network:
HOSTNAME=rizzo
...
-
/etc/hosts:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.100.13 rizzo.ifp.com rizzo
-
[root@rizzo ~]# hostname
rizzo
-
/var/log/messages snippet:
Dec 15 10:10:13 rizzo proftpd[19675]: 172.16.100.13 (::ffff:206.15.236.182[::ffff:206.15.236.182]) - Preparing to
chroot to directory '/app/upload/GREEK'
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - FTP session opened.
Dec 15 10:10:51 rizzo proftpd[20660]: 172.16.100.13 (::ffff:12.28.170.2[::ffff:12.28.170.2]) - Preparing to chroot
to directory '/app/upload/ftp/SRRID'
решение2
Почти все программное обеспечение чувствительно к правильной настройке имени хоста. Когда я работал в Digg, я однажды вывел из строя весь сайт на 2 часа из-за внесения, казалось бы, невинного изменения, которое /etc/hosts
повлияло на системное представление имени хоста. Будьте осторожны. Тем не менее, вы можете быть немного сбиты с толку. Я не думаю, что эта HOSTNAME=
настройка напрямую эквивалентна тому, как дистрибутивы на основе Debian используют /etc/hostname
.
В гетерогенной среде мне помогает следующее:
- Задайте имя хоста способом, рекомендуемым поставщиком, используя условие в программном обеспечении для управления конфигурацией.
- Используйте
hostname
команду для установки имени хоста, используемого ядром и т. д. В
/etc/hosts
:127.0.0.1 localhost 10.0.0.1 hostname.example.com hostname
Эта конфигурация меня еще не подводила.
решение3
У вас, безусловно, не возникнет проблем с поиском ссылок в сети, которые скажут вам, что нужно сделать это тем или иным способом. Однако мне кажется, что использование короткого имени в качестве имени хоста и полное имя в /etc/hosts, безусловно, гораздо более распространено. Это кажется более разумным способом, поскольку тогда службы, которым требуется полное имя, могут быть адаптированы для вызова hostname --fqdn
вместо этого.
Недавно я столкнулся только с одним программным обеспечением, которое жестко требует возврата fqdn hostname
, это был ganeti. Они документируют этоздесь. Однако я не вижу причин, по которым они не могут адаптироваться к hostname --fqdn
.
решение4
Короткий ответ:Я обычно использую FQDN в качестве имени хоста (как рекомендовано в документации RH6/7). Однако более правильным подходом было бы использовать однокомпонентное имя в качестве имени хоста, устанавливая FQDN через /etc/hosts
. Поэтому выберите подход и придерживайтесь его, когда это возможно.
Длинный ответ:Главное преимущество использования FQDN в качестве имени хоста заключается в том, что имя машины по сути встраивает информацию о домене. Это очень полезно при получении оповещений по электронной почте и/или журналов для нескольких клиентов/доменов, поскольку позволяет избежать дублирования имен хостов (т. е. имена хостов более или менее гарантированно будут уникальными для нескольких сайтов/клиентов/доменов). Например, SNMP sysName
по умолчанию показывает имя хоста, а при использовании FQDN он просто передает более полезную информацию. То же самое относится к zabbix-agent
(и другим инструментам мониторинга) или к bash $HOSTNAME
. Хотя вы можете настроить такие инструменты для использования FQDN даже на машине с именем хоста из одной метки или настроить их в иерархической модели, которая четко показывает домен, содержащий машину, это дополнительная работа.
Некоторые приложения дажетребоватьиспользование FQDN в качестве имени хоста, но они являются исключением. Тем не менее, когда возникает исключение, однородное использование однокомпонентного имени хоста теряется. Это, вероятно, главная причина рекомендации RedHat использовать FQDN в качестве имени хоста на RH6/7. Более поздние документы более расплывчаты. На«Выполнение стандартной установки RHEL 8»можно прочитать:
Имя хоста может быть либо полностью определенным доменным именем (FQDN) в формате hostname.domainname, либо коротким именем хоста без доменного имени. Во многих сетях есть служба Dynamic Host Configuration Protocol (DHCP), которая автоматически предоставляет подключенным системам доменное имя. Чтобы разрешить службе DHCP назначить доменное имя этой машине, укажите только короткое имя хоста
пока«Выполнение расширенной установки RHEL 8»состояния:
Если ваша сеть не предоставляет службу DHCP, всегда используйте полное доменное имя в качестве имени хоста системы.
За годы, прошедшие с момента первоначального вопроса, пользовательские приложения научились обрабатывать имена хостов FQDN без проблемы, описанной в предыдущих ответах. Например, PS1
приглашение bash использует \h
(имя хоста до первой '.') по умолчанию и rsyslog
ненетсохранить FQDN в файлах журналов по умолчанию. Другими словами, недостаток удобства использования имени хоста FQDN больше не существует для многих распространенных инструментов. По этим причинам я обычно устанавливаю имя хоста системы как FQDN, оставляя короткое имя /etc/hosts
по мере необходимости.
Причинанетиспользовать полное доменное имя хоста, это, честно говоря,Правильный поступок. Как соответственно указано вдокументы Debianистраница руководства по имени хоста:
Этот файл должен содержать только имя хоста системы, а не полное доменное имя.
и
Рекомендуется, чтобы это имя содержало только одну метку, т.е. без точек.
Итак, пока я делаючувствоватьнеудобно использовать имя хоста FQDN, этоявляетсяпроще использовать его в моих условиях.
Обратите внимание, что это не апелляция против однокомпонентного имени хоста. Если они вам подходят, продолжайте их использовать. В противном случае попробуйте использовать полное доменное имя хоста.