我试图找到关于此的最佳实践的文档.应该如何设置,如何处理不同的拱门,如何处理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)的渠道管理文档没有向我提供有关如何解决任何问题的足够信息.
所有关于此的提示,技巧和信息都会很棒！
解决方法
我建议人们使用Satellite的一件事是在本地文件中保留可用频道的副本：
# satellite-sync -l > channel_list
这将节省您必须等待卫星同步与RHN通信以下载列表的麻烦.将频道添加到下载重建后,列表是一个好主意,因为“p”get已添加到您已经同步的频道中.
另外运行Satellite Sync on a nightly basis,不会伤害并且可以使事情变得更容易.但请注意,同步将从当地时区的凌晨1点到凌晨2点30分开始,并且可能会在之后的任何时间段内运行.确保卫星数据库的任何备份都不会在相似的时间发生.如果需要,您可以减少cron工作中的睡眠时间.这是放在那里,所以每个人都不会在凌晨1点在各自的时区击中RHN.
好了,你现在问的是什么.不幸的是,由于使用Satellite的每个组织都存在差异,因此没有办法创建一个包罗万象的“最佳实践”.然而,经常建议使用克隆通道的组织认为它们是Dev / Qa / Prod类型的生命周期.如果Dev通道在特定时间线上同步到RHN通道(每晚同步),那么如果Dev通过所有需要的更新测试,则会在某个时间点更新Qa和prod.当Qa通道通过测试时,Prod通道将被更新.假设您每月更新一次开发者频道,然后您将在一周后针对开发者频道更新Qa频道,除非更新存在问题.然后,除非出现问题,否则Prod频道将在一周后更新.出现两个问题,如何处理关键漏洞的紧急更新以及如何处理组织摩擦.二,许多组织希望这三层方法给出的控制级别,然而许多组织可能不愿意遵守1Month / 1Week / 1Week时间表.因此,您可能更适合以类似方式建模一个或两个层系统.
还建议将所有其他包放入子通道.因此,如果您使用的是木偶版本,请将其放入您自己创建的顶级通道中,然后创建此通道的克隆作为Dev通道的子级.您还需要为Qa和Prod创建此子项的克隆,初始克隆来自下一级别(Dev – > RHN,Qa – > Dev,Prod – > Qa).这很重要,因为如果您需要使用UI执行频道更新,它会使UI更加简化.还建议您为所有克隆通道克隆RHN-Tools通道.
此外,您可能遇到实体中的组要求所有系统都是RHEL X.Y且没有更新的情况.虽然这很容易使用诸如spacewalk-create-channel之类的软件包(抱歉链接是仅向RH订户提供的文档),但您的组将面临风险,因为他们不会获得最新的更新.这是理解Red Hat发布周期非常重要,并了解供应商发布策略的地方.例如,许多人认为SAP只能在RHEL A.B上工作,他们在文档中实际上说他们将使用任何目前支持的批准操作系统版本.此外,您可以“欺骗”并且不更新更新克隆通道中的/ etc / RedHat-release文件的程序包,但是您以后可能会面临支持挑战的风险,因此不建议这样做.
在命名克隆频道时,重要的是要记住Satellite将使用简单的字符串排序显示它们.因此,如果您希望在UI中易于理解您的频道,请使用简单的字符串排序方式命名它们.我建议人们在开始时使用“clone”或类似名称命名他们的克隆通道,并且所有关联的子通道都遵循类似的模式.将架构添加到名称的决定取决于您.因此,克隆通道可以命名为clone-rhel-5-x86_64或mycompany-rhel-5(如果我在组织中使用一个体系结构).我也可能选择不将RHEL放在名称中.最好始终包含足够的信息以充分了解频道的性质.
创建克隆通道时,除非创建kickstart distributions within Satellite first,否则无法对克隆通道执行kickstart安装.链接中的指示假定您正在导入ISO,因此可以跳过步骤5的前半部分.将ISO复制到文件系统时,你可以删除packages目录.要记住的关键是您需要为计划克隆的每个RHEL版本创建kickstart分发.此外,每个版本的RHEL都有一个稍微不同的引导加载程序,因此尽可能使用最新的版本.但是,如果您计划使用RHEL 5.6的“冻结”克隆,则不建议使用5.7安装程序.在命名kickstart树时,一个建议是clone-rhel5-u1,其后的数字对应于点释放.因此6.0将是u0,6.3将是u3.您不需要为每个克隆通道导入kickstart树.获得ISO的最佳位置是从Red Hat下载,只需下载第一张CD或DVD即可.我没有尝试任何其他图像,所以我不能告诉你他们有多好不行.
最后,尽可能使用API编写所有可用的脚本.人类懒惰并犯错误,通常用户界面需要第二次“确认”点击,我看到人们多次跳过以为他们的行动已经完成.此外,我上面提到的关于udpate循环的组织摩擦可以通过API克服.例如,每月一次,您可以使用API更新您的Dev频道与RHN频道.然后你会发给每个人一封电子邮件.一周后,QA频道将针对Dev频道进行更新,每个人都会收到一封电子邮件.一周之后,Prod频道将针对Qa频道进行更新.如果您的频道名称足够一致,或者您在整个api脚本中使用一致的名称,则可以推广到接受来自频道的频道,例如：
# update-channel --to prod --from qa
然后,这将更新以下通道：prod-rhel5-x86_64和qa-rhel5-x86_64.更聪明的是,它也会更新所有子频道.
希望能让你更进一步.
*注意：我的日常工作是与Red Hat合作,但上述内容并不代表任何官方支持信息.以上信息仅是帮助您更好地了解RHN Satellite的建议.
