FreeIPA: что проверить до ipa-server-install

Установка FreeIPA внешне выглядит довольно просто:

ipa-server-install

Дальше installer задаёт несколько вопросов, настраивает компоненты — и через некоторое время перед нами готовый сервер управления идентификацией.

Именно эта простота иногда создаёт ложное ощущение: сначала установим, а DNS, имя сервера и остальные детали поправим потом. Для FreeIPA такой подход особенно рискован. Здесь hostname, DNS, Kerberos realm, сертификаты и служебные записи — не декоративные настройки вокруг приложения. Они являются частью архитектуры самой системы. Поэтому хороший deployment FreeIPA начинается до запуска ipa-server-install.

1. Сначала определяем, что именно строим

FreeIPA — это не просто LDAP-сервер. В типовой установке вокруг одной системы объединяются:

• каталог пользователей и групп;
• Kerberos-аутентификация;
• управление Linux-хостами;
• политики доступа;
• sudo rules;
• сертификаты;
• Web UI и API;
• DNS — если используется integrated DNS;
• механизмы обнаружения сервисов через DNS.

Поэтому вопрос: «Как установить FreeIPA?» лучше сначала заменить на: «Как будет выглядеть наш identity-контур?» До установки желательно понимать хотя бы:

DNS domain
        ↓
Kerberos realm
        ↓
имя IPA-сервера
        ↓
DNS architecture
        ↓
клиентские сети
        ↓
реплики / дальнейший рост

2. FQDN сервера нельзя выбирать как временное имя

Допустим, будущий сервер называется:

ipa.infra.example.com

Это его FQDN — полное доменное имя. Проверяем:

hostname
hostname -f

Ожидаем стабильное имя:

ipa.infra.example.com

Не:

localhost

не:

ipa

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

• Kerberos service principals;
• сертификатами;
• LDAP;
• DNS;
• конфигурацией клиентов;
• репликацией;
• URL сервисов.

Поэтому:

hostname
        ≠
просто косметическое имя ОС

Для FreeIPA это часть идентичности сервера. Имя выбираем до установки и считаем постоянным.

3. DNS — одна из основ FreeIPA

Следующий вопрос: куда разрешается FQDN сервера? Например:

dig +short ipa.infra.example.com

ожидаем:

192.0.2.10

Также полезно проверить разрешение через системный resolver:

getent ahostsv4 ipa.infra.example.com

Почему одной проверки через dig недостаточно? Потому что приложение может использовать не прямой DNS-запрос, а механизм разрешения имён системы, порядок которого определяется в том числе:

/etc/nsswitch.conf

То есть:

DNS отвечает правильно
        ≠
ОС обязательно получает тот же результат

Поэтому проверяем оба уровня.

4. PTR тоже имеет значение

Если сервер имеет адрес:

192.0.2.10

проверяем reverse DNS:

dig +short -x 192.0.2.10

Ожидаемый результат:

ipa.infra.example.com.

Получаем важную симметрию:

ipa.infra.example.com
        ↓ A/AAAA
192.0.2.10
        ↓ PTR
ipa.infra.example.com

Для FreeIPA корректное прямое и обратное разрешение имён нужно воспринимать как часть подготовки production-системы, а не как необязательную косметику. Особенно плохая ситуация:

IP
↓
несколько разных PTR

или:

FQDN → один адрес
PTR → совершенно другое имя

Такие несоответствия затем могут проявляться далеко не там, где администратор ожидает увидеть проблему DNS.

5. /etc/hosts не должен становиться заменой нормальному DNS

Иногда возникает желание быстро решить проблему:

FreeIPA не видит своё имя

добавлением строки в:

/etc/hosts

Такой вариант допустим только если мы понимаем итоговую схему разрешения имён. Если запись для IPA-хоста присутствует, она должна быть корректной. Например:

192.0.2.10 ipa.infra.example.com ipa

FQDN — перед коротким именем. При этом имя IPA-сервера не должно быть привязано к loopback:

127.0.0.1 ipa.infra.example.com

Это уже совсем другая адресация. И главное: если инфраструктура должна работать через DNS, не стоит маскировать ошибки DNS локальными записями в /etc/hosts. Иначе сервер может прекрасно находить сам себя, а будущие клиенты — нет.