企业官网建设流程全解析

1. 先把这件事想明白：为什么要自建一套 FreeIPA

1.1 从"三台机器三个密码"的真实窘境说起

我接手过一个小团队的环境，十几台 Linux 服务器，每台都有自己的/etc/passwd。听起来没什么，直到有人离职——运维要先在群里问"这台机器谁装过"，然后挨个 SSH 进去userdel -r，还要顺手清掉/etc/sudoers.d里散落的授权文件。更麻烦的是密码轮换，公司要求三个月改一次，结果就是一份 Excel 表格在群里传来传去，谁改过、谁没改，没人说得清。

这类环境的病根只有一个：身份没有唯一可信源。每台机器都是一个独立的"小王国"，账号、密码、权限各自为政。业务少的时候靠人肉能撑，机器一多、人员一流动，管理成本就是指数级上涨的。

FreeIPA 就是来干这件事的。它是 Red Hat 主导的一套开源身份管理集成方案，把 LDAP 目录、Kerberos 认证、DNS、CA 证书这几样东西打成一个包，对外只暴露一套命令和一个 Web 控制台。你在这套系统里建一个用户，几十台机器就能同时认这个人;你在这套系统里收回权限，所有机器上的授权也会同步失效。这篇搭建教程我尽量写得细一点，从主机名怎么改、DNS 怎么配，到ipa-server-install里每一个交互问题到底在问什么，都会逐条拆开讲——因为我自己踩过的坑，九成都埋在环境准备这一步。

1.2 FreeIPA 在技术栈里到底扮演什么角色

很多人第一次接触 FreeIPA，会把它理解成"一个带界面的 LDAP"。这个理解不算错，但漏掉了最关键的部分。FreeIPA 真正的定位是身份 + 策略 + 审计三位一体的域控系统，只不过它面向的是 Linux/Unix 生态，而不是 Windows。

它内部其实是由一堆成熟组件粘合起来的：

我打个比方：单独用 LDAP + Kerberos 手工拼装，像是自己买零件攒一台车——发动机、变速箱、底盘都是好东西，但你要自己解决接口匹配、线路走线、调校的问题。FreeIPA 做的是"原厂整车"，它把sssd.conf、krb5.conf、证书模板、DNS 区域文件这些东西全部按最佳实践预置好了，你只需要填几个参数就能跑起来。

更值钱的是那套统一的ipa命令行。用户管理、主机管理、HBAC 访问控制、sudo 规则、密码策略、证书签发，全都在一个命令体系里，权限模型也是一致的。这意味着你写自动化脚本的时候不用在四种工具之间来回切换。

1.3 部署拓扑和主机规格怎么定

FreeIPA 的部署规模分三档，选错了后期迁移成本很高，所以开工前先对号入座：

这里有几个常被忽略的点。

第一，副本不是备份。很多人觉得"我布了两台副本就高枕无忧了"，但误删一个用户，删除操作会同步到所有副本。真正的兜底手段是ipa-backup导出的离线备份，这个后面会详细讲。

第二，磁盘 I/O 比 CPU 重要。389 DS 是典型的写少读多且对 fsync 敏感的服务，跑在廉价共享存储上会明显卡顿。虚拟机的话尽量选本地 SSD，或者至少保证 IOPS 别低于 3000。

第三，目录分离。如果条件允许，把/var/lib/dirsvc单独挂一个盘，因为 LDAP 数据库（尤其是开启了审计日志之后）增长会比你想的快。我见过一个两百人规模的环境，跑了两年，/var分区被日志撑爆，直接导致服务起不来。

第四，动手前先打快照。无论虚拟机还是物理机，装之前一定留一个干净的快照。FreeIPA 安装失败后的清理非常麻烦，涉及十几个服务和配置文件的回滚，能直接回滚快照就不要硬扛。

1.4 域名和 Realm 的设计，一开始就要定死

这块我单独拎出来说，因为它是不可逆的。安装完成后改域名基本等于重建。

规则是这样的：假设你的 DNS 域名是corp.example.com，那么：

• Domain（域）：corp.example.com，这是 LDAP 的根后缀，也是客户端加域时填的域
• Realm（领域）：CORP.EXAMPLE.COM，Kerberos 的 Realm，通常是域名全大写

选域名的三个建议：

一是不要用.local结尾。这是给 mDNS 预留的，会和一堆服务冲突。二是不建议直接用公网顶级域名做内网域，除非你确实拥有它并做好了内外网视图分离。三是如果你打算和 AD 建信任关系，两边域名必须不同，否则直接卡死在第一步。这一点在做中长期规划时特别重要，很多公司是"先上了 FreeIPA，半年后老板说要和 AD 打通"，这时候改域名就是灾难。

我个人的习惯是用一个明显带内网标识的子域，比如idm.internal.example.com或者干脆用一个公司内部约定的独立域名空间。名字长一点无所谓，脚本里都是变量，写一次就行。

2. 环境准备：九成的安装失败都埋在这一步

2.1 主机名和 DNS 解析必须一次做对

FreeIPA 对主机名的要求是近乎偏执的，这不是设计者矫情，而是 Kerberos 的硬性约束：Service Principal Name 里绑定的就是 FQDN，主机名一乱，票据就签不出来。DNS 同理，客户端找 KDC 靠的是_kerberos._tcp这类 SRV 记录，解析不到就直接认证失败。

所以在安装前，请把这几条逐字检查一遍：

# 1. 设置静态主机名，必须是完整域名 hostnamectl set-hostname ipa.corp.example.com # 2. 验证短名和长名都能正确解析 hostname # 期望输出短名：ipa hostname -f # 期望输出全名：ipa.corp.example.com # 3. 检查 /etc/hosts，这是最容易配错的地方 cat /etc/hosts

/etc/hosts的标准写法是这样：

127.0.0.1 localhost localhost.localdomain ::1 localhost localhost.localdomain 192.168.10.10 ipa.corp.example.com ipa

这里有两个致命陷阱：

注意：127.0.0.1那一行千万不能写成127.0.0.1 ipa.corp.example.com，也不能出现127.0.1.1 ipa.corp.example.com这种写法。这会让安装器认为你的主机 IP 是回环地址，Kerberos KDC 绑定失败，报错信息还特别含糊，能折腾你半天。

注意：ipa.corp.example.com必须映射到这台机器的真实网卡 IP，而不是127.0.0.1。用ip addr确认一遍，别信ifconfig的老输出。

如果你打算让 FreeIPA 自建内置 DNS（这是推荐做法，省去手工维护 SRV 记录的麻烦），那么正反向解析的规划也要提前想好。正向区域是corp.example.com，反向区域就是网段反过来，比如10.168.192.in-addr.arpa。反向区域别偷懒跳过，很多应用在做主机名反解时会用到，缺了它后期会冒出一堆莫名其妙的告警。

2.2 时间同步、防火墙、SELinux 三件套

时间同步是 Kerberos 的生命线。Kerberos 默认允许的时间偏差是 5 分钟（300 秒），超过就直接拒绝认证。表现症状通常是"密码明明是对的，就是登录不上"，然后你看日志才会发现Clock skew too great。

# 配置 chrony，指向你现有的时间源 vi /etc/chrony.conf # 添加或修改 server 行，例如： # server ntp.internal.example.com iburst systemctl enable --now chronyd chronyc sources -v chronyc tracking

chronyc tracking里的System time那一行，偏差最好控制在几十毫秒以内。虚拟机有个经典坑：宿主机挂了、或者虚拟机被长按关机再恢复，时钟可能突然跳好几个小时，SSSD 缓存跟着乱掉。如果环境里虚拟机多，建议开启宿主机的时钟同步功能。

防火墙端口，FreeIPA 用到的比想象中多，我整理成表：

用 firewalld 的话，有现成的服务定义，省得一条条敲：

firewall-cmd --permanent --add-service=freeipa-ldap firewall-cmd --permanent --add-service=freeipa-ldaps firewall-cmd --permanent --add-service=dns firewall-cmd --permanent --add-service=ntp firewall-cmd --reload firewall-cmd --list-all

SELinux 不要关。网上很多教程图省事直接setenforce 0，这是给未来埋雷。FreeIPA 全套包都有现成的 SELinux 策略，保持enforcing反而能避免权限乱飞的问题。如果安装过程中真的遇到 SELinux 拦截，正确做法是看ausearch -m avc -ts recent定位，然后针对性放行，而不是一刀切关闭。

2.3 系统版本和仓库选择

推荐 RHEL 系：RHEL 8/9、Rocky Linux、AlmaLinux、CentOS Stream 都可以。原因是 FreeIPA 的包在这些发行版里是官方维护的，版本跟得紧，idm:DL1这个模块化仓库里的组件兼容性经过了充分测试。

Debian/Ubuntu 系列也能装，freeipa-server包是有的，但我实际用下来的感受是版本偏旧、坑更多，尤其是内置 DNS 和 Dogtag 的版本组合容易出问题。如果团队没有强制的发行版要求，别给自己找麻烦。

RHEL 8 及以后需要先启用模块：

# 查看可用模块流 dnf module list idm # 启用 DL1 流 dnf module enable idm:DL1 -y # 安装服务端，含内置 DNS 支持 dnf install -y ipa-server ipa-server-dns bind-dyndb-ldap

如果后续打算和 AD 建信任，还要多装一个包：

dnf install -y ipa-server-trust-ad samba-client samba-common-tools

这个包建议在安装阶段就一起装上，别等到要用的时候再补。原因是ipa-adtrust-install会改动 LDAP 的 schema 和一些服务配置，事后补装虽然也能跑通，但多一次服务重启和一次风险。

磁盘方面给个参考值：/var至少 40G（生产环境建议 60G 起），/boot1G，剩下的给根目录。如果/var和/是同一个分区，记得给整个根分区留够空间，因为 LDAP 数据库、审计日志、备份文件全在里面。

一切就绪之后，打一个快照。我再强调一次，这一步能救你半小时到半天的时间。

3. 服务端安装实操：从零到能登录控制台

3.1 一条命令和它背后的十几个参数

FreeIPA 的服务端安装，核心就是一条ipa-server-install。它可以全交互式跑，也可以带参数非交互跑。我的建议是：第一次装一定用交互模式，把每个问题看清楚，理解它在问什么;等熟练了再上非交互脚本做批量部署。

非交互的完整命令长这样，先给你一个整体印象：

ipa-server-install \ --realm=CORP.EXAMPLE.COM \ --domain=corp.example.com \ --hostname=ipa.corp.example.com \ --ds-password='目录管理员密码' \ --admin-password='IPA管理员密码' \ --setup-dns \ --forwarder=223.5.5.5 \ --forwarder=223.6.6.6 \ --mkhomedir \ --unattended

下面把关键参数一个个掰开说，因为漏掉任何一条，后面的行为都会不一样。

--realm和--domain前面已经讲过，是全大写和全小写的关系。--hostname会自动取hostname -f的结果，但如果你的主机名设置有问题，显式指定能避免误判。

--ds-password是Directory Manager的密码，也就是 LDAP 的超级管理员（相当于cn=Directory Manager）。这个账号权限极高，能直接操作 LDAP 数据，日常运维不要用它，只留作应急。--admin-password是 IPA 管理员（用户admin）的密码，这才是你日常该用的账号。

两个密码策略上建议不同，长度都别低于 12 位，含大小写、数字、符号。生产环境用密码文件读入会更安全：--ds-password=$(cat /root/.ds_pass)。

--setup-dns是安装内置 BIND。强烈建议加上，哪怕你公司已经有 DNS 服务器了。原因很直接：Kerberos 需要一堆 SRV 记录（_kerberos._tcp、_ldap._tcp、_kpasswd._udp等等），FreeIPA 在服务启动时会自动往自己的区域里写这些记录，还会随副本增减动态更新。你自己手工维护这套 SRV，几乎必然会出错。

--forwarder指定上游 DNS。FreeIPA 的内置 DNS 只负责自己区域的解析，其他域名要转发出去。可以指定多个，重复用这个参数即可。如果你想让它完全不转发（纯内网隔离环境），用--no-forwarders。这两个选项是互斥的。

注意：如果你的环境里有内网 DNS 需要解析的域名（比如git.internal.example.com），那么转发器一定要指向那个内网 DNS，而不是公网 DNS，否则加了域之后客户端反而解析不了内部资源。

--mkhomedir让用户在首次登录时自动创建家目录。不加的话，用户 SSH 登录进去会发现自己挂在一个不存在或者只有 root 才能写的目录下，体验极差。这个参数在服务端装完后，也会写入客户端的默认配置。

3.2 交互模式下每个问题的真实含义

不带--unattended跑的话，你会依次被问到这些问题，我把它们对应的实际影响列出来：

最后这个确认环节一定要认真看。我在这一步抓到过自己两次错误：一次是主机名带了个拼错的域名，一次是反向区域写成了另一个网段。这时候按no退出，什么都不会写;按yes之后就是一路装到底，中途失败清理起来很痛苦。

安装过程大概需要 5 到 20 分钟，取决于机器性能。期间它会做这些事：初始化 LDAP 实例、签发 CA 证书、启动 Dogtag、配置 BIND 区域、启动 KDC、注册 HTTP 服务、生成 Web 界面资源。日志在/var/log/ipaserver-install.log，如果卡住了，盯着这个文件看，比盯着屏幕瞎猜强。

3.3 装完之后的验证清单

看到The ipa-server-install command was successful千万别急着收工，按这个清单逐项验一遍：

# 1. 拿到管理员票据，这一步是"能不能用"的分水岭 kinit admin # 输入密码后无报错即为成功 # 2. 查看票据 klist # 3. 查看当前身份 ipa whoami # 4. 确认服务全部在跑 ipactl status

ipactl status会列出所有组件状态，理想情况是全部RUNNING。如果有STOPPED的，先用ipactl restart试一次，还不行就看对应组件的日志：LDAP 看/var/log/dirsrv/slapd-CORP-EXAMPLE-COM/errors，Kerberos 看/var/log/krb5kdc.log。

然后跑一次健康检查，这是 RHEL 8.1 以后提供的好东西，能提前发现很多隐患：

ipa-healthcheck

它会检查副本状态、证书有效期、CA 配置、DNS 记录、服务运行状态等，输出分SUCCESS、WARNING、ERROR三级。刚装好一般是全绿，如果报证书相关的警告，八成是时间没同步好。

最后验证 Web 界面。浏览器打开https://ipa.corp.example.com/ipa/ui，用admin登录。第一次访问会有自签名证书警告，这是正常的——因为你用的是 FreeIPA 自己的 CA。生产环境如果要消掉告警，可以从 Web 界面或者用命令导出 CA 证书，下发到各个客户端的信任库：

# 在服务端导出 CA 证书 ipa-getcert list # 证书位置通常在 /etc/ipa/ca.crt

确认这三块——命令行（kinit+ipa命令）、服务状态（ipactl）、Web 界面——都通了，服务端才算真正搭好。

4. 客户端接入与身份策略落地

4.1 Linux 客户端加域全过程

服务端只是"大脑"，真正当"手脚"的是每一台客户端。加域这一步有一半的失败来自客户端本身的 DNS 配置——它得先能解析到 IPA 服务器，才知道去哪儿认证。

前置条件三条：客户端的 DNS 指向 IPA 服务器（或者你的 DNS 能正确转发）。客户端时间和服务端偏差在 5 分钟内。客户端主机名同样是 FQDN。

操作如下：

# 1. 指向 IPA 的 DNS vi /etc/resolv.conf # nameserver 192.168.10.10 # 2. 安装客户端包 dnf install -y ipa-client # 3. 加域 ipa-client-install \ --domain=corp.example.com \ --server=ipa.corp.example.com \ --principal=admin \ --password='管理员密码' \ --mkhomedir \ --unattended

加域过程中它会做几件事：写/etc/sssd/sssd.conf、写/etc/krb5.conf、申请一张主机证书、在服务端注册这台主机的记录。跑完之后用这两条命令验证：

# 用域用户登录测试 id someuser # 查看 SSSD 是否正常工作 systemctl status sssd sssctl domain-status corp.example.com

sssctl domain-status输出里的Online status: Online是关键，如果显示Offline，说明客户端连不上服务端，回去查 DNS 和 88/389 端口。

这里有个很实用的技巧：加域时加--mkhomedir只是给这台机器开了开关，如果你想让整个域的新机器默认都自动建家目录，可以在服务端统一配置：

ipa config-mod --addattr=ipaConfigString=enabledService \ --addattr=ipaConfigString=mkhomedir

甚至可以让它去读一个骨架目录，把公司统一的.bashrc、.vimrc之类分发给所有新用户，这个后面单独写一篇展开。

4.2 用户、组、HBAC 和 sudo 规则的设计思路

加完域只是"能认证"，真正管住权限靠的是策略。FreeIPA 的策略体系有几个层次，容易搞混，我按从粗到细的顺序理一遍。

第一层是用户和组。ipa user-add建用户，ipa group-add建组。组有两种：POSIX 组（有 GID，用于文件权限）和非 POSIX 组（纯逻辑分组，用于策略绑定）。做访问控制时我强烈建议全用非 POSIX 组，把"业务分组"和"文件权限分组"彻底分开，否则改文件权限的时候会把访问策略一起改乱。

# 建非 POSIX 组（不加 --posix 参数即是） ipa group-add ops-team --desc="运维组" # 加人 ipa group-add-member ops-team --users=zhangsan

第二层是 HBAC（Host-Based Access Control）。这是很多人不知道但极其有用的东西：它控制"谁能在哪台机器上用哪个服务"。默认有一条allow_all规则，很多教程让你留着，我不建议。

# 关掉默认的万能规则 ipa hbacrule-disable allow_all # 建一条精准规则 ipa hbacrule-add ops-ssh --desc="运维组 SSH 到生产机" ipa hbacrule-add-user ops-ssh --groups=ops-team ipa hbacrule-add-host ops-ssh --hostgroups=prod-servers ipa hbacrule-add-service ops-ssh --hbacsvcs=sshd

这条规则的意思是：ops-team组的人，只能 SSH 到prod-servers主机组里的机器。设置好之后再测试，效果立竿见影——不在规则里的人，密码再对也进不去，而且报错信息是标准的认证失败，不会泄露任何内部结构。这就是"默认拒绝"的威力。

第三层是 sudo 规则。这是 FreeIPA 相比纯 LDAP 最舒服的地方：sudo 规则集中管理，客户端自动下发，不用再往每台机器的/etc/sudoers.d里塞文件。

# 建规则 ipa sudorule-add ops-reboot --desc="允许重启服务" # 允许谁 ipa sudorule-add-user ops-reboot --groups=ops-team # 允许在哪 ipa sudorule-add-host ops-reboot --hostgroups=prod-servers # 允许执行什么（这里用命令组更利于维护） ipa sudorule-add-allow-command ops-reboot --sudocmds=/usr/bin/systemctl

我个人的经验是优先用--sudocmds绑定具体命令而不是给ALL，同时用命令组（ipa sudocmdgroup-add）来批量管理。真的需要临时提权的时候，在 Web 界面点两下把命令加进组里，比每台机器改配置安全得多，而且有审计记录。

第四层是密码策略。默认策略对现代环境来说偏松，建议调紧：

# 全局策略：最小长度 12，历史 5 次，90 天过期 ipa pwpolicy-mod --minlength=12 --history=5 --maxlife=90 \ --minlife=1 --priority=0

如果某个特殊账号（比如服务账号）需要不同的策略，可以用--priority做优先级覆盖，数值大的优先。

4.3 证书、备份与日常巡检

证书这块，FreeIPA 用自己的 Dogtag CA 给每台主机签证书，用于 HTTPS、LDAP over TLS、以及跨服务的相互认证。这些证书不是永久的，默认有效期两年，到期不续就全面报错。好在有 certmonger 自动盯着：

# 查看所有受管理的证书 getcert list # 重点看这两行：expires 和 status

如果某张证书status显示MONITORING就是正常的，它会在快到期时自动续签并在服务端重新签发。但有一个必须注意的点：CA 证书本身到期是个麻烦事，它不会自动续（因为签名链的问题），需要提前规划。建议在巡检脚本里加上：

# 查看 CA 证书有效期 openssl x509 -in /etc/ipa/ca.crt -noout -enddate

备份是这套系统的命门。ipa-backup支持全量和增量：

# 全量备份，默认输出到 /var/lib/ipa/backup/ ipa-backup # 指定输出目录，建议放到独立存储 ipa-backup --data --gpg --gpg-keyring=/root/backup-key

--gpg会把备份加密，适合明文存储的环境。备份内容包含 LDAP 数据、CA 私钥、配置文件，CA 私钥尤其重要——丢了它，所有已签发的证书全部作废，等于要重建整个域。所以备份文件一定要异地存放，并且定期做恢复演练。恢复用ipa-restore，注意它需要在单用户模式下或者停掉 IPA 服务后执行。

日常巡检我一般做成一个 cron 脚本，跑这几项：

# 1. 健康检查 ipa-healthcheck --failures-only # 2. 服务状态 ipactl status # 3. 复制状态（多副本环境） ipa-replica-manage list ipa-replica-manage status # 4. 磁盘余量 df -h /var # 5. 最近失败的登录 ipa hbacrule-find

5. 与 AD 建立信任关系的关键环节

5.1 信任模型和不可动摇的前置条件

很多公司是混合环境：Windows 侧用 AD，Linux 侧用 FreeIPA。早期常见的做法是在两边各建一套账号，一个人两个身份，权限还得手工对齐，运维苦不堪言。正确的做法是让 FreeIPA 和 AD 建立跨域信任，实现 AD 用户直接登录 Linux 机器。

信任的本质是两边 KDC 互相认对方的票据，路径是"跨领域认证"（Cross-Realm）。要实现它，硬性前置条件有几个，缺一个都做不成：

DNS 这一条是最容易卡住的。双向解析意味着：FreeIPA 这边要能解析 AD 域（靠转发器指向 AD 的 DNS，或者在 AD 上建条件转发指向 FreeIPA）;AD 那边也要能解析 FreeIPA 域（在 AD 的 DNS 里建条件转发）。这两步任何一边没配好，ipa trust-add就会报Unable to resolve AD domain之类的错误，而且提示很不明确。

我的建议是在规划阶段就画一张 DNS 转发关系图，两边都留好配置记录，后面出问题排查起来会快很多。

5.2 建立信任的实操步骤

前置条件满足后，先跑信任准备：

# 1. 让 FreeIPA 具备作为信任方的能力 ipa-adtrust-install --netbios-name=CORP

这个命令会问你几个问题，其中 NetBIOS 名建议和 AD 域短名区分开，避免混淆。执行完后它会提示你重启相关服务，记下它输出的那几条systemctl restart命令，一条条执行到位。

然后建立信任：

# 2. 建立到 AD 的单向信任（FreeIPA 信任 AD） ipa trust-add --type=ad ad.example.com \ --admin=Administrator \ --password # 3. 验证信任状态 ipa trust-show ad.example.com ipa trust-find

ipa trust-find里如果看到Trust status: established and verified，说明信任已经通了。

接下来是验证的临门一脚：找一台已经加了 FreeIPA 域的 Linux 客户端，用 AD 用户登录。

# 在客户端上直接查 AD 用户 id aduser@ad.example.com # SSSD 里要能看到这个用户 getent passwd aduser@ad.example.com

如果id命令能返回 UID/GID，说明整个链路——Linux 客户端 → FreeIPA SSSD → 跨域票据 → AD KDC——全部打通了。

这一步有几个常见的坑，我先替你踩过：

第一，AD 用户默认的 UID/GID 是 SSSD 用算法动态映射出来的（一致性哈希），不是 AD 里存的真实值。这导致同一个 AD 用户在不同客户端上 UID 可能不同，如果做 NFS 共享或者跨机文件授权就会出问题。解法是配置 ID 映射或者用sssd.conf里的ldap_id_mapping相关选项，这块内容比较多，值得单独写一篇。

第二，加了信任之后，HBAC 规则对 AD 用户同样生效。也就是说 AD 用户不会自动获得访问权限，你还得把他们对应的 AD 组加到 HBAC 规则里，或者用外部组（External Group）的方式桥接。这是很多人以为"信任建好就能用"、结果发现登录不上时的最大盲点。

第三，AD 那边禁用或删除了用户，FreeIPA 侧因为 SSSD 有缓存，可能还会"残留"一段时间，过期后自然消失。如果要求即时生效，需要在 SSSD 配置里调短缓存时间。

6. 常见问题排查实录

6.1 DNS 和 Kerberos 问题速查表

把这两年遇到过的高频问题整理成表，出问题先来这里对号：

补一个万能排查起手式，遇到任何认证问题都可以按顺序走一遍：

# 1. 时间对不对 chronyc tracking | grep "System time" # 2. DNS 通不通 dig ipa.corp.example.com dig _kerberos._tcp.corp.example.com SRV # 3. 拿票行不行 kinit admin # 4. 端口通不通（从客户端发起） nc -zv ipa.corp.example.com 88 nc -zv ipa.corp.example.com 389 # 5. SSSD 状态 sssctl domain-status corp.example.com

这五步走下来，八成的问题都能定位到具体环节，比漫无目的地翻日志高效得多。

6.2 安装中断后的清理和重装

安装失败是必然要经历的事。两种情况：一种是安装器自己回滚了，相对好办;一种是装到一半磁盘满、网络断，进程被杀死，这时候系统里残留了一堆半成品配置。

先别急着重装，正确顺序是这样：

# 1. 先看日志，弄清到底卡在哪一步 tail -100 /var/log/ipaserver-install.log # 2. 如果安装器提示可以清理，用它自带的卸载命令 ipa-server-install --uninstall # 3. 如果上面的命令也跑不起来，强清理 ipa-server-install --uninstall -U

--uninstall会尽力把 LDAP 实例、Kerberos 数据库、DNS 区域、证书、服务配置全部移除。但它不总是干净的，尤其是中断发生在后期阶段时。我遇到过清理完还有残留的情况，这时候要手工检查这几处：

# 检查残留的服务 systemctl list-unit-files | grep -E "ipa|dirsrv|pki|krb5|httpd" # 检查残留目录 ls -la /etc/dirsrv/ /var/lib/dirsrv/ /etc/pki/pki-tomcat/ /var/lib/ipa/ # 检查残留 LDAP 数据 ls /etc/dirsrv/slapd-*/

我个人的强烈建议是：能用虚拟机快照就用快照。新装一个干净系统重新跑一遍安装，通常比在残留系统上折腾清理要快，而且结果可预期。这也是我前面反复强调"安装前打快照"的原因。

如果实在不能用快照，还有个折中办法：在安装前把/etc、/var/lib里的关键目录做个 tar 备份，出问题直接覆盖回去，比--uninstall更彻底。

6.3 性能、容量和一些踩出来的心得

最后聊点运维层面的实际体会，这些是文档里不会写、但用久了必然会碰上的。

关于副本数量。很多人觉得副本越多越安全，其实不是。每多一个副本，就多一条复制协议，写入操作要在副本之间同步，冲突解决也更复杂。三副本在大多数场景下已经是上限，再多就是给自己加负担。真正需要的是"每个机房的容灾副本 + 一份离线备份"。

关于监控。FreeIPA 有几个关键指标必须监控起来，否则出事的时候你只是"被动救火"：

# LDAP 连接数、操作响应时间，可以通过 389 DS 的监控条目看 ldapsearch -D "cn=Directory Manager" -W -b "cn=monitor" -s base # 副本延迟，这是最关键的指标 ipa-replica-manage status # 磁盘余量，LDAP 日志涨得比想象中快 df -h /var

副本延迟如果超过几分钟，就要警惕网络或者同步队列积压。我见过一次因为磁盘写满导致复制协议断开，两边数据分叉了两天才发现，最后靠手工导出比对才补齐。

关于审计日志。FreeIPA 默认会记录 LDAP 的写操作审计日志，这在合规场景下是必需的，但会显著增加磁盘 I/O 和空间占用。如果环境规模不大、又对审计没有硬性要求，可以适度调整日志级别：

# 查看当前日志级别 ldapsearch -D "cn=Directory Manager" -W -b "cn=config" \ "(nsslapd-pluginId=nsslapd-audit-log)" nsslapd-errorlog-level

调整前一定先确认清楚合规要求，别自己图快把审计关了。

关于密码策略的落地节奏。策略不要一次调得太狠。我经历过一次：直接把最小长度从 8 改成 16、历史改成 10，结果第二天一堆人的服务账号认证失败，因为那些账号密码是多年前手工设的、存在配置文件里。正确的做法是先调影响面小的参数（比如历史次数），观察一周，再逐步收紧长度和复杂度要求，同时提前把所有服务账号梳理出来单独加策略。

关于文档。这个听起来像废话，但真的重要。FreeIPA 这种集中式系统，最怕的就是"只有一个人懂"。我现在的习惯是在内部 Wiki 里固定维护几样东西：域名和 Realm 的规划、所有主机的 FQDN 和 IP 对照表、副本拓扑图、备份恢复的操作步骤、以及每次变更的记录。真到了出故障的时候，这些文档能帮你省下大量回忆的时间。

ipa-backup配上ipa-restore的演练，我建议每季度做一次，在测试环境完整走一遍"备份 → 模拟故障 → 恢复 → 验证用户能登录"。没演练过的备份等于没有备份，这句话在身份系统上尤其成立——等真出事的时候才发现备份文件损坏或者恢复步骤漏了一环，代价就不是加班能解决的了。这套东西现在我在三四个环境里跑着，最久的一个跑了三年多，中间经历过副本迁移、域信任调整、证书轮换，整体稳定性是让人放心的，前提是前期规划别偷懒、日常巡检别省。