我目前正在build立RHN Satellite，并且运行良好。 我正在创build自定义频道，因为我们有一些软件可以用于卫星的所有节点，例如puppet，facter，subversion，php（比现在的版本更新的版本）。
我试图find有关这方面最佳做法的文档。 他们应该如何设置，如何处理不同的拱门，如何处理noarch包。 在自定义通道中更新自定义包时，如何将更新同步到依赖项（例如，php已更新，如何获取所有更新的依赖项）。
来自RHEL的渠道pipe理文档（ 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 ）没有提供足够的关于如何解决这些问题。
所有提示，技巧和信息将是伟大的！
有几件事你可以做，让你的生活更轻松。 首先是要充分了解红帽发布的生命周期 。
我build议人们使用卫星的一件事是保留一个本地文件中的可用频道的副本：
# satellite-sync -l > channel_list 这将节省您不得不等待卫星同步与RHN通信下载列表的麻烦。 添加频道到下载重build后，列表是一个好主意，因为“p”get添加到您已经同步的频道。
除此之外，每晚进行卫星同步 ，不会受到伤害，而且可以让事情变得更容易。 但是请注意，同步将在您当地时区的凌晨1点到凌晨2点半之间开始，并可能在之后的任意时间段内运行。 确保卫星数据库的任何备份不会在相似的时间发生。 如果需要，你可以减less在cron工作的睡眠时间。 这是放在那里，所以每个人都不在凌晨1点在他们各自的时区打RHN。
现在确定你所问的问题。 不幸的是，由于使用卫星的每个组织都存在差异，因此没有办法创build一个全面的“最佳实践”。 然而，经常有人build议使用克隆渠道的组织认为它们是Dev / Qa / Prodtypes的生命周期。 在特定的时间线上，开发者频道与RHN频道同步（每晚进行同步），那么如果开发者通过所有必要的更新testing，那么Qa和产品将在稍后的时间点被更新。 当Qa频道通过testing时，Prod频道将被更新。 假设您每月更新开发人员频道，那么您将在一周后针对开发人员频道更新Qa频道，除非更新有问题。 然后，Prod频道将在一周后更新，除非有问题。 出现两个问题，如何处理关键漏洞的紧急更新以及如何处理组织摩擦。 二，许多组织想要这三层方法给予的控制水平，但很多组织可能不愿意坚持1 / 1Week / 1Week时间表。 因此，以相似的方式build模一个或两个层次的系统可能更适合您。
还build议将所有附加软件包放入子频道。 因此，如果您使用的是您使用的木偶版本，请将其放入您自己创作的顶级频道中，然后创build此频道的克隆，作为开发者频道的子版本。 您还需要为Qa和Prod创build一个这个孩子的克隆，这个初始克隆来自下一级（Dev→RHN，Qa→Dev，Prod→Qa）。 这很重要，因为如果您需要使用UI执行频道更新，它会使UI更加简化。 还build议您克隆所有克隆频道的RHN-Tools频道。
此外，您可能会遇到这样的情况，您的实体中的团体要求所有系统都是RHEL XY，而不是新的。 虽然使用诸如spacewalk-create-channel之类的软件包很容易，但是您的团队将面临风险，因为他们不会获得最新的更新。 了解红帽发行周期非常重要，并了解供应商发布政策。 例如，许多人认为SAP只会在RHEL AB上工作，他们在文档中实际上会说，他们将使用任何目前支持的经过批准的操作系统版本。 另外，你可以“欺骗”而不更新在你的克隆频道里更新/ etc / RedHat-release文件的软件包，但是你以后面临支持挑战的风险，因此不build议这样做。
当命名您的克隆频道时，重要的是要记住，卫星将使用简单的stringsorting来显示它们。 因此，如果您希望自己的频道在用户界面中易于理解，请使用简单的stringsorting方式对其进行命名。 我build议人们在开始时用“克隆”或类似的名称命名他们的克隆频道，并且所有相关的子频道都遵循类似的模式。 将架构添加到名称的决定取决于您。 因此，一个克隆通道可能被命名为clone-rhel-5-x86_64或mycompany-rhel-5（如果我在我的组织中使用一个体系结构）。 我也可能select不把RHEL列入名称。 最好总是包含足够的信息来充分理解频道的性质。
创build克隆频道时，除非您先在Satellite内创buildkickstart分发，否则无法对克隆频道执行kickstart安装。 链接中的指示假设您正在导入ISO，因此您可以跳过步骤5的前半部分。将ISO复制到文件系统时，可以删除软件包目录。 关键要记住的是，您需要为计划克隆的每个RHEL版本创build一个kickstart分发。 此外，每个版本的RHEL都有一个稍微不同的引导程序，因此尽可能使用最新的引导程序非常重要。 但是，如果您计划使用RHEL 5.6的“冻结”克隆，则不build议使用5.7安装程序。 当命名你的kickstart树时，一个build议是clone-rhel5-u1，u之后的数字对应于发布点。 因此6.0将是u0，6.3将是u3。 您不需要为每个克隆通道导入kickstart树。 获得ISO的最佳地点是从红帽下载，只需下载第一张CD或DVD，即可离开。 我还没有尝试过任何其他的图像，所以我不能告诉你他们没有工作。
最后，只要有可能，你就可以使用API更新脚本。 人类是懒惰的，会犯错误，而且UI往往需要第二次“确认”点击，我看过人们多次跳过，认为他们的行动已经完成。 另外，上面提到的有关udpate循环的组织摩擦可以通过API来克服。 例如，一个月一次，您可以使用API来更新您的Dev频道与RHN频道。 那么你会发送每个人一封电子邮件。 一周后，QA频道将针对开发频道进行更新，每个人都会收到一封电子邮件。 一周后，Prod频道将更新为Qa频道。 如果您的频道名称足够一致，或者您在整个api脚本中使用的是一致的名称，则可以将其概括为接受来往频道，例如：
# update-channel --to prod --from qa
这会更新以下通道：prod-rhel5-x86_64和qa-rhel5-x86_64。 即使更聪明，它也会更新所有的孩子频道。
希望能让你更进一步。
*注：我的日常工作是与红帽，但以上不代表任何官方的支持信息。 以上信息只是一个build议，以帮助您更好地了解RHN Satellite。
如果是我，我会以受控的方式与reposync或其他类似的方式来获取它们。 每隔一两个月把它们拉下来，或者当你看到重要的安全更新时，在dev / qa / test / whatever_you_have_you_can_break_at_will中testing它们，然后将它们同步到已经告诉Spacewalk / RHN SS的内部生产回购站。