os_family 专题

本章节的修改位置如下：

ambari-common/src/main/python/ambari_commons/resources/os_family.json

一、前情回顾 从 OSCheck 继续

在上一节中，我们扩展了 os_check.py，让 Ambari 能够正确识别出系统类型为 Kylin。
但仅仅识别出系统名称还不够 —— Ambari 仍然不知道 Kylin 属于哪个系统家族（Family）。

而 Ambari 的系统兼容性判断依托于一份“家族定义文件”：

os_family.json
它是系统识别的第二个核心组件，用来确定“当前系统属于哪个家族”，
例如：

• Rocky 属于 RedHat 家族；
• OpenEuler 属于 RedHat 家族；
• Debian 属于 Ubuntu 家族。

因此，为了让 Ambari 能够顺利在 Kylin 上初始化和部署，我们需要在该文件中增加映射定义。

二、源码文件结构与加载机制

文件路径如下：

ambari-common/src/main/python/ambari_commons/resources/os_family.json

Ambari 启动时，会通过 OSConst.initialize_data() 方法加载此文件， 并生成以下内部数据结构：

名称	含义	来源
OS_FAMILY_COLLECTION	系统家族集合	mapping 中的每个家族定义
OS_COLLECTION	所有发行版标识集合	各家族中的 distro 数组
FAMILY_COLLECTION	家族名称集合	顶层 mapping 键名
OS_TYPE_ALIASES	系统别名映射	文件中的 aliases 节点

这些数据被 OSCheck.is_in_family() 和 OSCheck.is_redhat_family() 调用，用于判定继承关系。

小结

os_check.py 负责识别类型， 而 os_family.json 则负责建立家族血统关系。 两者结合才能让 Ambari 判断：某系统是否“属于” RedHat。

三、完整文件示例 完整版参考

{
  "mapping": {
    "redhat": {
      "distro": [
        "redhat",
        "rhel",
        "centos",
        "oraclelinux",
        "ascendos",
        "xenserver",
        "oel",
        "ovs",
        "cloudlinux",
        "slc",
        "scientific",
        "psbm",
        "centos linux",
        "rocky"
      ],
      "versions": [
        6,
        7,
        8,
        9
      ]
    },
    "redhat-ppc": {
      "extends": "redhat",
      "distro": [
        "redhat-ppc",
        "centos-ppc"
      ],
      "versions": [
        6,
        7
      ]
    },
    "openeuler": {
      "extends": "redhat",
      "distro": [
        "openeuler"
      ],
      "versions": [
        22
      ]
    },
    "fedora": {
      "extends": "redhat",
      "distro": [
        "fedora"
      ],
      "versions": [
        36,
        38
      ]
    },
    "amazonlinux": {
      "extends": "redhat",
      "distro": [
        "amazonlinux"
      ],
      "versions": [
        2
      ]
    },
    "debian": {
      "extends": "ubuntu",
      "distro": [
        "debian"
      ],
      "versions": [
        10,
        11
      ]
    },
    "ubuntu": {
      "distro": [
        "ubuntu"
      ],
      "versions": [
        20,
        22
      ]
    },
    "suse": {
      "distro": [
        "sles",
        "sled",
        "opensuse",
        "suse"
      ],
      "versions": [
        11,
        12
      ]
    },
    "winsrv": {
      "distro": [
        "win2008server",
        "win2008serverr2",
        "win2012server",
        "win2012serverr2"
      ],
      "versions": [
        6
      ]
    },
    "kylin": {
      "extends": "redhat",
      "distro": [
        "kylin"
      ],
      "versions": [
        10
      ]
    }
  },
  "aliases": {
    "suse11sp3": "suse11"
  }
}

四、修改说明与结构解析

在原始文件中，我们仅需在 "mapping" 节点下增加如下内容：

"kylin": {
"extends": "redhat",
"distro": ["kylin"],
"versions": [10]
}

字段名	含义	示例
extends	继承的父系统家族	"redhat"
distro	/etc/os-release 中的发行版标识	"kylin"
versions	可识别版本号列表	[10]

为什么要这样写？

这段定义让 Ambari 理解「Kylin 属于 RedHat 家族」， 从而在执行包管理、模板渲染、脚本生成等阶段自动复用 RedHat 的逻辑。

五、为什么不直接放进 redhat 段落？

很多人第一反应是：

“既然 Kylin 兼容 RHEL，直接在 redhat 的 distro 里加一个 ‘kylin’ 不就好了？”

但这样做会造成识别逻辑上的混乱。原因如下👇

1. RedHat 段落是核心定义区

"redhat": {
"distro": ["redhat", "rhel", "centos", "rocky"],
"versions": [6, 7, 8, 9]
}

这里是 RedHat 官方系的核心分支，不适合混入衍生系统。

2. Kylin 是国产化延展系统

• 底层兼容 RHEL 8；
• 在内核、包签名、工具链等层面均做过深度定制；
• Kylin SP3 甚至基于 OpenEuler 20.03。

因此，它既“像 RedHat”，又不完全相同。 这时就应该单独成族，通过 extends 明确继承关系。

推荐写法

"kylin": {
"extends": "redhat",
"distro": ["kylin"],
"versions": [10]
}

六、安装中的问题

当修改完成后，重新启动 Ambari 并进入安装向导， 即可在“操作系统选择”界面中看到新增的 Kylin 10 选项：

界面变化

新增的 Kylin 10 表示该系统族群已被识别， 可以在界面中为其单独配置仓库镜像源。

下一节预告

接下来我们将讲解 镜像源如何植入。