我目前正在设置 RHN Satellite，一切运行良好。我正在创建自定义频道，因为我们有某些软件应该可用于 Satellite 的所有节点，例如 puppet、facter、subversion、php（比基础中现有的版本更新）。
我尝试寻找这方面的最佳实践文档。如何设置它们，如何处理不同的 arch，如何处理 noarch 包。如何在自定义频道中更新自定义包时同步依赖项的更新（例如 php 已更新，如何获取所有更新的依赖项）。
RHEL 中的频道管理文档（http://www.redhat.com/docs/en-US/Red_Hat_Network_Satellite/5.3/Channel_Management_Guide/html/Channel_Management_Guide-Custom_Channel_and_Package_Management.html) 没有向我提供足够的信息来指导我如何解决这些问题。
与此相关的所有提示、技巧和信息都非常棒！
答案1
有几件事可以让你的生活更轻松。首先是充分了解Red Hat 发布生命周期。
我建议使用卫星的人在本地文件中保留可用频道的副本：
# satellite-sync -l > channel_list
这样可以省去等待 satellite-sync 与 RHN 通信以下载列表的麻烦。将频道添加到下载后重建列表是个好主意，因为“p”会添加到您已经同步的频道中。
此外运行每晚卫星同步，不会造成任何影响，而且可以让事情变得更容易。但是请注意，同步将从您当地时区的凌晨 1 点到凌晨 2:30 的任何时间开始，并且可能会在之后持续任意长的时间。确保任何 Satellite Database 的备份都不会在相似的时间发生。如果需要，您可以减少 cron 作业中的休眠时间。这样做是为了让每个人都不会在各自时区的凌晨 1 点准时到达 RHN。
好的，现在开始讨论您所问的问题。不幸的是，由于使用 Satellite 的每个组织都存在差异，因此无法创建包罗万象的“最佳实践”。然而，人们经常建议使用克隆渠道的组织考虑 Dev/Qa/Prod 类型的生命周期。在特定时间线上，Dev 渠道与 RHN 渠道（每晚同步）同步，然后如果 Dev 通过了所有必需的更新测试，则 Qa 和 prod 将在稍后的某个时间点更新。当 Qa 渠道通过测试时，Prod 渠道将进行更新。假设您每月更新 Dev 渠道，那么除非更新存在问题，否则您将在一周后针对 Dev 渠道更新 Qa 渠道。然后，除非出现问题，否则 Prod 渠道将在一周后更新。出现了两个问题，一个是如何处理关键漏洞的紧急更新，另一个是如何处理组织摩擦。二，许多组织都希望获得这种三层方法所能提供的控制级别，但许多组织可能不愿意遵守 1 个月/1 周/1 周的计划。因此，以类似方式建模的一层或两层系统可能更适合您。
还建议将所有附加软件包放入子频道。因此，如果您有要使用的 puppet 版本，请将其放入您自己创建的顶级频道，然后创建此频道的克隆作为 Dev 频道的子频道。您还需要为 Qa 和 Prod 创建此子频道的克隆，初始克隆来自下一个级别（Dev -> RHN、Qa -> Dev、Prod -> Qa）。这很重要，因为如果您需要使用 UI 执行频道更新，它会使 UI 更加精简。还建议您为所有克隆频道克隆 RHN-Tools 频道。
此外，您还可能遇到这样的情况：您的实体内的团队要求其所有系统均为 RHEL XY，且不更新。虽然使用以下软件包可以轻松实现这一点太空行走-创建频道 （抱歉，链接指向的文档仅对 RH 订阅者可用），您的团队将面临风险，因为他们将无法获得最新更新。这就是了解 Red Hat 发布周期和了解供应商发布政策的重要性所在。例如，许多人认为 SAP 只能在 RHEL AB 上运行，而实际上他们在文档中说，它们可以与任何当前支持的已批准操作系统版本一起使用。此外，您可以“作弊”而不更新克隆频道中更新 /etc/RedHat-release 文件的软件包，但您以后可能会面临支持挑战，因此不建议这样做。
在命名克隆频道时，请务必记住 Satellite 将使用简单的字符串排序来显示它们。因此，如果您希望频道在 UI 中易于理解，请以适合简单字符串排序的方式命名它们。我建议人们在开头使用“clone”或类似名称来命名克隆频道，并且所有关联的子频道都遵循类似的架构。是否将架构添加到名称中由您决定。因此，克隆频道可以命名为 clone-rhel-5-x86_64 或 mycompany-rhel-5（如果我在组织中使用一种架构）。我也可以选择不在名称中添加 RHEL。最好始终包含足够的信息以充分了解频道的性质。
创建克隆频道时，您无法针对克隆频道执行 kickstart 安装，除非您创建首先在 Satellite 中启动分发版。链接中的说明假设您正在导入 ISO，因此您可以跳过步骤 5 的前半部分。将 ISO 复制到文件系统时，您可以删除软件包目录。要记住的关键是您需要为计划克隆的每个 RHEL 版本创建一个 kickstart 发行版。此外，每个版本的 RHEL 都有一个略有不同的引导加载程序，因此尽可能使用最新版本很重要。但是，如果您计划使用 RHEL 5.6 的“冻结”克隆，则不建议使用 5.7 安装程序。在命名您的 kickstart 树时，一个建议是 clone-rhel5-u1，u 后面的数字对应于点版本。因此 6.0 将是 u0，6.3 将是 u3。您不需要为每个克隆频道导入 kickstart 树。获取 ISO 的最佳位置是从 Red Hat 下载，您只需下载第一张 CD 或 DVD 即可。我没有尝试过任何其他图像，所以我无法告诉你它们的效果有多好。
最后，尽可能地编写脚本，以便使用 API 更新所有内容。人类很懒，会犯错误，而且 UI 经常需要第二次“确认”点击，我见过很多人跳过这个步骤，以为他们的操作已经完成。此外，我上面提到的与更新周期有关的组织摩擦可以通过 API 克服。例如，每月一次，您可以使用 API 针对 RHN 频道更新您的 Dev 频道。然后，您将向所有人发送一封电子邮件。一周后，QA 频道将针对 Dev 频道进行更新，再次向所有人发送一封电子邮件。一周后，Prod 频道将针对 Qa 频道进行更新。如果您的频道名称足够一致，或者您在整个 api 脚本中使用一致的名称，则可以将其概括为接受来往频道，例如：
# update-channel --to prod --from qa
这将更新以下频道：prod-rhel5-x86_64 和 qa-rhel5-x86_64。更智能的是，它还会更新所有子频道。
希望这能让你走得更远。
*注：我的日常工作是在 Red Hat，但以上内容并不代表任何官方支持信息。以上信息仅作为帮助您更好地了解 RHN Satellite 的建议。
答案2
如果是我，我会使用 reposync 或类似方法以受控方式获取它们。每隔一两个月将它们拉下来，或者当您看到其中出现重要的安全更新时，在 dev/qa/test/whatever_you_have_you_can_break_at_will 中测试它们，然后将它们同步到您已经告诉 Spacewalk/RHN SS 的内部生产存储库。