tor*_*re- 7 redhat satellite channel
我目前正在设置 RHN Satellite，一切正常。我正在创建自定义频道，因为我们有某些软件应该可用于所有卫星节点，例如 puppet、facter、subversion、php（比 base 中的版本新）。
我试图找到有关这方面最佳实践的文档。它们应该如何设置，如何处理不同的 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 ) 没有为我提供有关如何解决任何问题的足够信息这些问题。
所有与此相关的提示、技巧和信息都会很棒！
Red*_*Tux 10
您可以做一些事情来让您的生活更轻松。首先是全面了解Red Hat 的发布生命周期。
我向使用 Satellite 的人建议的一件事是在本地文件中保留可用频道的副本：
# satellite-sync -l > channel_list
这将为您省去必须等待卫星同步与 RHN 通信以下载列表的麻烦。将频道添加到下载后重建列表是一个好主意，因为“p”获取已添加到您已经同步的频道。
此外，每晚运行卫星同步，不会受到伤害，并且可以使事情变得更容易。但是请注意，同步将在您当地时区的凌晨 1 点到凌晨 2 点 30 分之间的任何时间开始，并且可能会持续任何时间。确保卫星数据库的任何备份不会同时发生。如果需要，您可以减少 cron 作业中的睡眠时间。这被放在那里，这样每个人都不会在各自时区的凌晨 1 点准时到达 RHN。
好的，现在开始你所问的问题。不幸的是，由于每个使用 Satellite 的组织存在差异，因此无法创建一个包罗万象的“最佳实践”。然而，通常建议使用克隆渠道的组织将其视为 Dev/Qa/Prod 类型的生命周期。如果 Dev 频道在特定时间线上同步到 RHN 频道（每晚同步），那么如果 Dev 通过所有必需的更新测试，则 Qa 和 prod 会在稍后的某个时间点更新。当 Qa 通道通过它的测试时，Prod 通道将被更新。假设您每月更新 Dev 频道，然后您将在一周后针对 Dev 频道更新 Qa 频道，除非更新出现问题。除非出现问题，否则产品频道将在一周后更新。出现了两个问题，一是如何处理关键漏洞的紧急更新以及如何处理组织摩擦。第二，许多组织希望这三层方法提供的控制级别，但是许多组织可能不愿意坚持 1Month/1Week/1Week 计划。因此，以类似方式建模的一层或两层系统可能更适合您。
还建议将所有附加包放入子频道。因此，如果您有使用的 puppet 版本，请将其放入您自己创建的顶级频道，然后创建该频道的克隆作为 Dev 频道的子频道。您还需要为 Qa 和 Prod 创建此子项的克隆，初始克隆来自下一个级别（Dev -> RHN，Qa -> Dev，Prod -> Qa）。这很重要，因为如果您需要使用 UI 执行频道更新，它会使 UI 更加精简。还建议您为所有克隆频道克隆 RHN-Tools 频道。
此外，您可能会遇到实体内的团体要求其所有系统均为 RHEL XY 且不得更新的情况。虽然使用诸如spacewalk-create-channel 之类的软件包很容易做到这一点（抱歉，链接指向仅适用于 RH 订阅者的文档），您的小组将面临风险，因为他们将无法获得最新更新。这就是了解 Red Hat 发布周期和了解供应商发布政策很重要的地方。例如，许多人认为 SAP 只能在 RHEL AB 上工作，而他们实际上在文档中说他们将与任何目前支持的已批准操作系统版本一起工作。此外，您可以“作弊”而不更新用于更新克隆频道中的 /etc/RedHat-release 文件的软件包，但您以后会面临支持挑战的风险，因此不建议这样做。
在命名您的克隆频道时，请务必记住卫星将使用简单的字符串排序来显示它们。因此，如果您希望您的频道在 UI 中易于理解，请以适用于简单字符串排序的方式命名它们。我建议人们在开始时用“clone”或类似的名称命名他们的克隆频道，并且所有关联的子频道都遵循类似的模式。将架构添加到名称中的决定取决于您。因此，克隆通道可以命名为 clone-rhel-5-x86_64 或 mycompany-rhel-5（如果我在我的组织中使用一种架构）。我也可能选择不将 RHEL 放在名称中。最好始终包含足够的信息以充分了解频道的性质。
创建克隆频道时，除非您先在 Satellite 中创建kickstart 发行版，否则无法针对克隆频道执行 kickstart 安装. 链接中的说明假设您正在导入 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 频道更新您的开发频道。然后你会给每个人发一封电子邮件。一周后，QA 频道将针对 Dev 频道进行更新，每个人都会再次收到一封电子邮件。一周后，Prod 频道将针对 Qa 频道进行更新。
# update-channel --to prod --from qa
这将更新以下通道：prod-rhel5-x86_64 和 qa-rhel5-x86_64。更聪明的是它也会更新所有子频道。
希望这能让你走得更远。
*注：我的日常工作是在 Red Hat，但以上不代表任何官方支持信息。以上信息仅为帮助您更好地了解 RHN Satellite 的建议。
小智 0
如果是我，我会使用 reposync 等以受控方式获取它们。每隔一两个月将它们拉下来，或者当您看到其中出现重要的安全更新时，在 dev/qa/test/whatever_you_have_you_can_break_at_will 中测试它们，然后将它们同步到您已经告知 Spacewalk/RHN SS 的内部生产存储库。