TT Bigdata TT Bigdata
首页
GitHub (opens new window)
JaneTTR

JaneTTR

数据酿造智慧,每一滴都是沉淀!
  • Ambari 安装

  • 组件安装

  • Kerberos 旧版专题

    • 实战 Kerberos
    • 自建 Kerberos

    • FreeIPA 认证

      • FreeIPA服务端初始化

      • FreeIPA客户端初始化及Ambari开启IPA认证

      • 部分踩坑-问题发现

        • Ambari Server 启动失败:no valid keystore
        • FreeIPA Client 导致 Ambari 权限异常问题排查
          • 一、问题背景与现象说明
            • 1.1 典型症状对照
          • 二、根因分析:登录链路触发 pam_umask
            • 2.1 现象确认:当前会话的 umask
            • 2.2 查看 PAM 是否启用了 pam_umask
            • 2.3 确认 sshd/login 是否 include postlogin
            • 2.4 查找真正的默认值来源
          • 三、为什么 UMASK=077 会导致 Ambari 安装失败?
            • 3.1 权限计算对比
          • 四、标准修复方案:恢复 UMASK=022
            • 4.1 备份原始文件
            • 4.2 修改 UMASK
            • 4.3 新会话验证(必须)
          • 五、服务重启要求
      • 部分踩坑-完美解决

      • 辅助测试

    • 其他优化技巧

    • 部分组件踩坑合集

    • 实战技巧

    • 其他技巧

  • Ranger 旧版专题

  • 旧版部署
  • Kerberos 旧版专题
  • FreeIPA 认证
  • 部分踩坑-问题发现
JaneTTR
2026-02-14
目录
一、问题背景与现象说明
1.1 典型症状对照
二、根因分析:登录链路触发 pam_umask
2.1 现象确认:当前会话的 umask
2.2 查看 PAM 是否启用了 pam_umask
2.3 确认 sshd/login 是否 include postlogin
2.4 查找真正的默认值来源
三、为什么 UMASK=077 会导致 Ambari 安装失败?
3.1 权限计算对比
四、标准修复方案:恢复 UMASK=022
4.1 备份原始文件
4.2 修改 UMASK
4.3 新会话验证(必须)
五、服务重启要求

FreeIPA Client 导致 Ambari 权限异常问题排查

需要 ttr-release 版本 >= 2.2.3

适用于 Ambari 3.0.0 + FreeIPA Client 已安装环境 Kylin / Rocky / Ubuntu 均适用

# 一、问题背景与现象说明

在节点安装 freeipa-client 后,如果配置处理不当,极易引发 Ambari 安装组件阶段的权限异常。

最直观表现:

  • /usr/bigtop/current 目录相关操作失败
  • distro-select 执行异常
  • 组件安装阶段提示 no permission
  • 文件权限默认变为 600 / 700

这类问题本质并非 Ambari 逻辑错误,而是系统默认权限策略被收紧。

# 1.1 典型症状对照

现象 表现形式
distro-select 执行失败 无法切换组件版本
组件安装中断 文件无法创建
目录权限异常 当前用户可用,其他用户无权限
默认权限过严 新建文件为 600,新建目录为 700

# 二、根因分析:登录链路触发 pam_umask

问题核心在于:

sshd/login → include postlogin → pam_umask.so → 读取 login.defs → UMASK=077
1

也就是说:

  • 并不是 authselect 修改了 umask
  • 而是 PAM 登录流程触发了 pam_umask
  • 最终读取 /etc/login.defs 中的 UMASK

# 2.1 现象确认:当前会话的 umask

umask
bash -l -c 'umask'
1
2

说明:

  • bash -l 用于模拟新登录会话
  • 避免当前 shell 被手工修改

若输出:

0077
1

说明默认权限掩码已变为 077。

# 2.2 查看 PAM 是否启用了 pam_umask

grep -RIn 'pam_umask\.so' /etc/pam.d 2>/dev/null
1

典型结果:

/etc/pam.d/postlogin: ... pam_umask.so
1

# 2.3 确认 sshd/login 是否 include postlogin

grep -RIn 'include\s\+postlogin|substack\s\+postlogin' \
  /etc/pam.d/sshd /etc/pam.d/login 2>/dev/null
1
2

若命中,说明每次登录都会执行 pam_umask。

# 2.4 查找真正的默认值来源

grep -nE '^\s*UMASK|^\s*USERGROUPS_ENAB' /etc/login.defs
1

若显示:

UMASK 077
1

即为根因。

下面截图为现场排查结果示例:

image-20260207001555747

# 三、为什么 UMASK=077 会导致 Ambari 安装失败?

# 3.1 权限计算对比

UMASK 新建目录 新建文件
022 755 644
077 700 600

在 077 情况下:

  • 目录仅当前用户可访问
  • 其他用户无读写权限
  • Ambari Server / Agent 协同执行时无法访问文件

尤其在:

/usr/bigtop/current
1

相关目录中,多用户协作访问非常频繁。

注意

大数据组件安装涉及多进程、多用户访问,默认 umask=077 会直接导致权限链断裂。

# 四、标准修复方案:恢复 UMASK=022

# 4.1 备份原始文件

cp -a /etc/login.defs /etc/login.defs.$(date +%F_%H%M%S).bak
1

# 4.2 修改 UMASK

sed -ri 's/^\s*UMASK\s+[0-9]+/UMASK 022/' /etc/login.defs
grep -nE '^\s*UMASK\b' /etc/login.defs
1
2

预期结果:

UMASK 022
1

# 4.3 新会话验证(必须)

ssh localhost 'umask'
1

或:

bash -l -c 'umask'
1

预期输出:

0022
1

提示

必须开启新登录会话,旧 shell 不会重新读取 PAM 配置。

# 五、服务重启要求

修改 UMASK 后,仅修改文件并不会立即生效。

必须执行:

systemctl restart sshd
systemctl restart ambari-server
systemctl restart ambari-agent
1
2
3

若为客户端节点,建议直接:

reboot
1

原因:

  • sshd 需要重新加载 PAM 链路
  • ambari-agent 需刷新文件创建上下文
  • ambari-server 需重新建立执行环境
#Kerberos#安全认证#FreeIPA#Ambari
Ambari Server 启动失败:no valid keystore
Ambari Server 启动失败:no valid keystore

← Ambari Server 启动失败:no valid keystore Ambari Server 启动失败:no valid keystore→

最近更新
01
当前版本 2026/08
08-29
02
把 Ambari Server HA 稳稳地跑起来
08-17
03
从一次启用操作追到主备就绪
08-17
更多文章>
Theme by Vdoing | Copyright © 2017-2026 JaneTTR | MIT License
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式