目录
摘要
SUSE® Linux Enterprise (SLE) 使您可以将现有系统更新为新版本而不用完全重安装系统。不需新安装。用户主目录和系统配置等现有数据保持不变。在产品的生命周期内,您可以应用服务包以提高系统安全性,更正软件缺陷并获取对新功能的访问权限。从本地 CD 或 DVD 驱动器安装或从中央网络安装源安装。
本章使用了若干术语。为了理解该信息,请阅读以下定义:
向后移植是指通过较新版本的软件采取特定的更改,然后将这些更改应用到较旧版本的做法。最常见的用例是修复较旧软件组件中的安全漏洞。通常,它也是用于提供增强或新功能(不太常见)的维护模型的一部分。
deltarpm 仅包含某个包的两个已定义版本之间的有区别二进制文件,因此其下载大小最小。安装前,需要在本地计算机上重构建完整 rpm 包。
开放源代码领域中的软件开发方式的形象说法(与上游相对)。术语下游表示从上游将源代码与其他软件集成以构建可供最终用户使用的分发包的人员或组织(例如 SUSE)。因此,软件将从其开发者开始,通过集成者向下游流向最终用户。
通过使用联机更新工具(而不是安装媒体)对服务包 (SP) 进行更新,以安装相关的增补程序。它会将已安装的系统的所有包都更新到最新状态 — 包括 SP3 与 SP2 的更新。
包是 rpm 格式的压缩文件,其中包含特定程序的所有文件,包括配置、示例和文档等可选组件。
增补程序由一个或多个包组成,可通过 deltarpm 方式应用。它也可能带来与尚未安装的包的依赖性。
将几个增补程序合并到便于安装或部署的一个组织体中。服务包是有编号的并通常包含安全性修复、更新、升级或程序增强。
开放源代码领域中的软件开发方式的形象说法(与下游相对)。术语上游表示以源代码形式分发的软件的原始项目、作者或维护者。反馈、增补程序、功能增强或其他改进措施将从最终用户或贡献者流向上游开发者。开发者决定是要集成还是拒绝请求。
如果项目成员决定集成请求,则会在更新版本的软件中显示这一点。接受的请求将为所有相关方带来好处。
如果某个请求未被接受,则可能是因其他原因而遭到拒绝。原因是该请求的状态不符合项目的准则、该请求无效、已集成该请求,或者它不在项目的考虑范围或路线图内。未接受的请求会给上游开发者带来不利,因为他们必须使其增补程序与上游代码同步。通常会避免这种做法,但有时仍有必要予以采取。
安装包的更新次要版本。
安装包或分发包的更新主要版本,引入新功能。
SUSE Linux Enterprise 11 Maintenance Model 集服务包的灵活性和控制度于一体。它提供以下优势:
使服务包变得更轻便,更易于测试和部署。
允许使用更旧版本,但支持完整系统。
通过选择性增强来实现在各服务包发行间隔期间迎合市场需求,并允许常规更新安装源中的更多更新。通过选择增强,可将各服务包发行间隔维持得更长。
过去数年以来,SUSE 已经明确认识到需要根据用户反馈进行改进,在向用户递送更新的方式上做出了诸多改变:
在 SLES 9 中只有一个更新安装源,其中收集了所有更新;最新的版本更新是唯一要支持的更新。
从 SLES 10 SP1 开始,我们引入了“特定于 SP 的安装源”的概念。这意味着将在一个特定的安装源中递送特定服务包的所有更新。在用户迁移到更新的服务包后,如果他们直接在 Novell Customer Center 上注册,将会失去对先前安装源的访问权限。SMT 或 SUSE Manager 的用户无论是过去还是现在都能自由订阅任何 SP 通道。之所以发生这种变化,主要得益于采用了允许在 6 个月重叠期(n-1 服务包支持)内验证发布的服务包的思路,并为客户提供一个迁移时间范围,在此时间范围内,他们可以继续在旧 SP 中获得完全的维护和支持服务。
SLES 11 GA 和 SLES 11 SP1 沿用了 SLES 10 模型。随着 SLES 11 SP2 的发布,我们引入了一个新的安装源模型,其中包括:
SLES 11 SP1 更新安装源保持订阅状态。同样适用于 SP2 的所有更新也会或者只会发布到 SP1 更新安装源中。也就是说,任何更新只要不破坏 ABI 和 API 兼容性,就会继续在此处递送。
SLES 11 SP2 更新安装源(出于各种原因)只包含无法递送到 SP1 更新安装源的最新更新和所有创新性更新。除此之外,我们还引入了一个核心安装源,它为那些完全没有发布到 SP1 或 SP2 更新安装源的包提供了“游隙”。
图 7.1 “维护递送演进(也适用于 SLED)”描述了以上某些方面。
产品的生命周期为 10 年:7 年常规支持和 3 年扩展支持。主要版本每 4 年发布一次,服务包每 18 个月发布一次。长期服务包支持是一段扩展期或扩展主版本生命周期(请参见图 7.2 “长期服务包支持”)。
长期服务包支持需要标准或优先级活动订阅。它不影响 L1 或 L2 订阅条款。“主动”处理安全性更新:这些是非用户驱动的关键漏洞、内核中的本地 root 攻击或无需用户干涉可直接执行的其他 root 攻击。
扩展支持级别的范围从第 8 年开始直至第 10 年。这些包含持续的 L3 工程级别诊断和反应性关键 bug 修复。这些支持级别主动更新内核中的普通本地 root 攻击或无需用户干涉即可直接执行的其他 root 攻击。而且,它们借助有限包排除列表支持现有工作负载、软件堆栈和硬件。可在表 7.1 “安全更新和 bug 修复”中找到概述。
表 7.1. 安全更新和 bug 修复¶
|
- 常规支持 - |
延长支持 | ||||
|---|---|---|---|---|---|
|
主题 |
当前 SP |
SP (n-1) 6 个月 |
SP (n-1) ,带 LTSS |
第 6 和 7 年 ,带 LTSS |
第 8、9 和 10 年 ,带 LTSS |
|
L1/L2 技术服务 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
主动维护 |
✓ |
✓ |
✓ | ||
|
通过 PLDP 的驱动程序更新 |
✓ |
✓ |
✓ | ||
|
主动安全更新 |
✓ |
✓ |
✓ |
✓ | |
|
L3 工程支持 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
后端可用 |
✓ |
✓ |
✓ |
✓ | |
在先前的维护模型 SUSE Linux Enterprise Server 上指派了两个通道:SLES11-SPx-Pool 和 SLES11-SPx-Updates。在联机迁移到 SPx+1 的过程中,这些通道会暂时替换为 SLES11-SPx-Online。
在 SUSE Linux Enterprise SP 2 上,通道布局已发生更改,以利用新维护模型的优势。表 7.2 “SUSE Linux Enterprise 11 SP1、SP2 和 SP3 的通道布局”包含从 SP1 到 SP3 的所有通道的列表。
表 7.2. SUSE Linux Enterprise 11 SP1、SP2 和 SP3 的通道布局¶
|
类型 |
SLES |
SLED | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
必要通道 |
SP1
SP2
SP3
|
SP1
SP2
SP3
| ||||||||||||||||||||
|
可选通道 |
SP1
SP2
SP3
|
SP1
SP2
SP3
| ||||||||||||||||||||
|
特定于产品(示例) |
|
|
针对必要通道的说明
解包后的安装媒体的子集,它只包含被视为 SPx “核心”的那些包(大约占包总数的 30%)。SP 安装源只包含特定于 SP 及其主题(例如硬件支持)的包。只在 SP2 中存在。
对相应 Core 或 Pool 安装源中的包进行的维护更新。
包含安装媒体中的所有二进制 RPM,外加模式信息和支持状态元数据。
针对可选通道的说明
这些通道包含静态内容。但是,只有 Debuginfo-Updates 通道可接收更新。如果您需要安装包含调试信息的库以备不时之需,请启用这些通道。
尚未使用。预期将会包含(将来发布的)附加产品的包。
对相应 Pool 安装源中的包进行的维护更新,适用于包含长期支持服务 (LTSS) 的安装。此特定通道需要签署 LTSS 合同。
SUSE Linux Enterprise 11 SP1.
SUSE Linux Enterprise 11 SP1 的基本通道是 SLES11-SP1-Pool。在 SUSE Linux Enterprise 11 的整个生命周期内,此通道及其内容不会更改。只要某个包没有可用的更新,就会从此通道为此包提供服务。
更新某个包后,将从 SLES11-SP1-Updates 为更新提供服务。此通道包含自从发布 SP1 以来已更新的所有包。
SUSE Linux Enterprise 11 SP2.
在安装服务包 2 之后,将额外添加两个通道:SLES11-SP2-Core 和 SLES11-SP2-Updates。SP2-Core 包含来自 SP1-Pool 的包的子集。这些包比两个 SP1 通道中的版本更新。更新 SP2-Core 包后,将从 SLES11-SP2-Updates 为更新提供服务。此通道包含自从发布 SP2 以来已更新的所有包。
SUSE Linux Enterprise 11 SP3.
安装 SP3 后,只有两个可用的通道:SLES11-SP3-Pool 和 SLES11-SP3-Updates。来自 SP2 的所有先前通道会显示出来,但并未启用。只有具有特殊需求的用户才需要这些已禁用的通道。
注册时,系统将从 Novell Customer Center 接收通道。通道名称将映射到客户中心内的特定 URI(请访问 http://www.novell.com/ncc)。要列出系统中的所有可用通道,请按如下所示使用 zypper:
zypper repos -u
随后将会提供您系统中所有可用通道的列表。每个通道已按其别名、名称及其启用状态列出,并且将被刷新。使用选项 -u 也可以从 URI 的来源处获取该 URI。
如果您要去除旧通道(例如从 SP1 中),请使用 zypper removerepo 以及通道的名称。例如,要去除旧的 SP1 和 SP2 通道,请使用以下命令:
zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \ SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \ SLES11-SP2-Core SLES11-SP2-Updates \ SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\ SLE11-SP2-Debuginfo-Updates
如果您要重新添加某些通道,请登录到 http://www.novell.com/ncc 并从菜单+中进行选择。随后将会显示 URI 列表;只能添加此产品列表中的通道。例如,要添加 SP2 Extension Store,请使用以下命令(以一行输入,不能使用反斜杠):
zypper addrepo -n SLES11-SP2-Extension-Store \ https://nu.novell.com/repo/$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store
这些版本没有支持的直接升级路径。建议执行全新安装。
SUSE Linux Enterprise 11 SP3 没有支持的直接迁移路径。您需要全新安装 SUSE Linux Enterprise 11 SP3。进行第 6 章 使用 YaST 进行安装。
SUSE Linux Enterprise 11 SP3 没有支持的直接迁移路径。必须先从 SUSE Linux Enterprise 11 GA 升级到 SP1,然后遵照第 7.5 节 “从 SLE 11 SP1 更新到 SLE 11 SP2”中的说明。
有关详细信息,请参见第 7.5 节 “从 SLE 11 SP1 更新到 SLE 11 SP2”。
有关详细信息,请参见第 7.6 节 “从 SLE 11 SP2 更新到 SLE 11 SP3”。
在开始更新过程之前,请确保对您的系统进行适当的准备。这些准备工作包括备份数据,查看发行说明,以及其他工作。
在更新之前,请将现有配置文件复制到单独一个媒体(如磁带设备、可卸硬盘等)上,用以备份数据。这主要适用于储存在 /etc 中的文件以及 /var 和 /opt 中的一些目录和文件。最好将 /home(HOME 目录)中的用户数据也写入备份媒体。以 root 的身份备份这些数据。只有 root 用户才对所有本地文件具有读许可权限。
如果您已在 YaST 中选择作为安装模式,则可以选择在以后的某个时间执行(系统)备份。您可以选择包含所有已修改的文件以及 /etc/sysconfig 目录中的文件。但是,此备份尚不完整,因为缺少了上述所有其他重要目录。在 /var/adm/backup 目录中查找备份。
在开始更新之前,记录必要的根分区信息。命令 df / 可以列出根分区的设备名。在例 7.1 “使用 df -h 列示信息”中,要记录的根分区是 /dev/sda3(作为 / 装入)。
例 7.1. 使用 df -h 列示信息¶
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 74G 22G 53G 29% /
tmpfs 506M 0 506M 0% /dev/shm
/dev/sda5 116G 5.8G 111G 5% /home
/dev/sda1 44G 4G 40G 9% /data从旧版本到新版本,软件的大小有“增长”的趋势。因此,在进行更新之前,请使用 df 查看可用分区空间。如果怀疑磁盘空间不足,请在更新和重分区系统前保证数据安全。对于每个分区应该具有多少空间,没有一般的经验可以借鉴。空间要求取决于特定的分区配置文件和选定的软件。
如果您的计算机充当 KVM 或·Xen 的 VM Host Server,请确保在更新之前关闭所有正在运行的 VM Guest。否则,更新后您可能无法访问 guest。
有关特定于版本的要求,请参考更新产品随附的发行说明。在发行说明中,您可以找到有关升级过程的详细信息。
可以在 http://www.suse.com/doc/sles11/#additional 上联机阅读包含针对 SUSE Linux Enterprise Server 最新信息的发行说明文档的最新版本。
系统支持通过多种方法将 SUSE Linux Enterprise 11 SP1 系统更新到服务包 2。要执行更新,您可以使用联机更新工具来安装相关的增补程序(“联机迁移”),也可以通过服务包安装媒体进行更新。此外,还可以通过托管 Subscription Management Tool 或 SUSE Manager 的服务器执行更新。
以下工具支持联机迁移:
(图形用户界面)
zypper(命令行)
或者,可以下载整个服务包媒体(DVD ISO 映像)。通过从物理服务包媒体或网络安装源引导来启动更新过程。
可以从运行中的系统内部,通过联机迁移完成系统更新。更新完毕后,您只需要重引导一次。
要执行联机更新,必须符合以下要求。另外,请确保阅读第 7.4 节 “有关更新的一般准备工作”。
要连接到更新通道,您的产品必须经过注册。如果尚未注册产品,请在 YaST 中运行 模块,或者运行 suse_register 命令行工具来开始注册。
确保已在当前安装的版本中安装了最新的增补程序。在执行联机迁移之前运行联机更新。当使用图形界面时,请启动 YaST 联机更新或更新程序小程序。在命令行上运行以下命令(最后一条命令需要运行两次):
zypper ref -s zypper update -t patch zypper update -t patch
需要时请重引导系统。
请参见第 1 章 YaST 联机更新 (↑管理指南)或第 6.1.3 节 “使用 Zypper 更新软件” (第 6 章 使用命令行工具管理软件, ↑管理指南),了解有关联机更新工具的更多信息。
如果您的设置包含第三方软件或外接式附件软件,则在另一台计算机上测试此过程以确保升级未破坏依赖性。
![]() | 始终运行完整的联机迁移 |
|---|---|
始终要自始而终地完成整个联机迁移过程。如果联机迁移中途中断,则会损坏系统且无法恢复。 | |
如果符合所有要求(参见第 7.5.1.1 节 “要求”),托盘中的更新小程序将显示一条讯息,表示有可用的分发包升级。单击该讯息以启动 YaST 。或者,通过命令行以 root 的身份运行 /usr/sbin/wagon。
单击以确认对话框。
如果 发现不符合要求(必需的维护更新可用,但尚未安装),它将会自动执行自助更新,这可能需要重引导计算机。按屏幕上的说明进行操作。
在后续对话框中选择更新方法。选择以使用默认设置(推荐)。
单击 以手动选择用于联机迁移的软件通道。随后将显示通道列表,其中提供了用于手动启用、禁用、添加或删除通道的选项。添加 SP2 更新源更新源可以是 SP2 安装媒体,也可以是 SP2-Core 和 SP2-Updates 通道。单击返回到对话框。
如果您想要查看更新过程对通道设置所做的更改,请选择。
按继续。
随后将重新注册系统。在此过程中,SP2-Core 和 SP2-Updates 通道将加入系统(参见第 7.2.3 节 “通道模型”以获取更多信息)。确认添加通道。
如果您已在对话框中选择,将显示安装源的列表,其中提供了用于手动启用、禁用、添加或删除通道的选项。完成后单击继续。
选择迁移类型:
将所有包更新到最新的 SP2 级别。
将最低限度的一组包更新到最新的 SP2 级别。
单击可以手动选择用于升级的安装源。
确认所做的选择。
系统会打开屏幕,其中显示了升级配置的摘要,提供了以下部分:
可以在此处添加 SUSE Linux Enterprise Server 附加产品或第三方产品。
列出在更新期间将要执行的操作。您可以选择先下载所有包,然后一并安装(推荐的默认设置),也可以选择逐个下载包并逐个安装。
更新的统计概述。
设置备份选项。
依次单击和以继续。
![]() | 中止联机迁移 |
|---|---|
在单击之前,您可以安全地在此屏幕以及所有先前的屏幕上中止联机迁移。单击将会退出更新过程,并将系统恢复到启动 YaST wagon 之前的状态。在退出 Wagon 之前,请按照屏幕上的指导操作并执行重新注册,以从系统中去除 SP2 通道。 | |
在更新过程中,将执行以下步骤:
更新包。
运行 SuSEconfig。
重引导系统(按)。
重新注册最近更新的系统。
您的系统已成功更新到服务包 2。
如果符合所有要求(参见第 7.5.1.1 节 “要求”),则意味着执行联机迁移所需的“产品”已添加到 /etc/products.d 中。运行以下命令可获取这些产品的列表:
zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2
此命令至少应返回 SUSE_SLES-SP2-migration。根据安装的范围,可能会列出更多的产品。
使用命令 zypper in -t product 产品列表安装上一步骤检索到的迁移产品,例如:
zypper in -t product SUSE_SLES-SP2-migration
注册上一步骤中安装的产品,以获取相关的更新通道:
suse_register -d 2 -L /root/.suse_register.log'
再次刷新安装源和服务:
zypper ref -s
使用 zypper lr 检查您可以检索的安装源列表。至少需要以下安装源:
SLES11-SP1-Pool
SLES11-SP1-Updates
SLES11-SP2-Core
SLES11-SP2-Updates
根据安装的范围,可能需要启用附加产品或扩展的其他安装源。
如果未启用其中的某个安装源(在遵循此工作流程时,默认情况下不启用 SP2 安装源),请使用 zypper modifyrepo --enable 安装源别名启用该安装源,例如:
zypper modifyrepo --enable SLES11-SP2-Core SLES11-SP2-Updates
如果您的设置包含可能与 SP2 不兼容的第三方安装源,请使用 zypper modifyrepo --disable 安装源别名禁用这些安装源。
现在所有工作准备就绪,可以使用 zypper dup --from REPO 1 --from REPO 2 ... 执行分发包升级了。确保使用 --from 列出全部所需的安装源,例如:
zypper dup --from SLES11-SP2-Core --from SLES11-SP2-Updates
按 确认开始升级。
在上一步骤中完成分发包升级后,会执行最小迁移(已将最低限度的一组包更新到最新的 SP2 级别)。如果您不打算执行完整迁移,请跳过此步骤。
要执行完整迁移(将所有包更新到最新的 SP2 级别),请运行以下命令:
zypper update -t patch
在完成升级到 SP2 之后,您需要重新注册产品:
suse_register -d 2 -L /root/.suse_register.log
最后,重引导您的系统。
您的系统已成功更新到服务包 2。
作为联机迁移(参见第 7.5.1 节 “联机迁移”以获取细节)的一种备用方法,您也可以通过从安装源(DVD 或网络安装源)引导来更新系统。更新的启动方式与正常安装相同。
可以从 http://download.novell.com/ 获取服务包 2 ISO 映像。请将映像刻录到 DVD,或者按照第 14.2 节 “设置存放安装源的服务器”中所述方法准备一个网络安装源。
启动 SUSE Linux Enterprise 服务包的新安装之前,请确保所有服务包安装媒体 (DVD) 都可用。
过程 7.1. 从服务包媒体引导¶
插入第一张 SUSE Linux Enterprise SP 媒体后引导计算机。一个类似于 SUSE Linux Enterprise 11 原始安装的引导屏幕就会出现。
选择并按照第 6 章 使用 YaST 进行安装中的 YaST 安装说明所述继续。
在从网络安装源开始更新 SUSE Linux Enterprise SP 之前,请确保符合以下要求:
已按照第 14.2 节 “设置存放安装源的服务器”中所述方法设置网络安装源。
安装服务器和目标计算机上存在包含名称服务、DHC(可选,但 PXE 引导需要)和 OpenSLP(可选)的网络连接,并且正在运行。
存在用于引导目标系统的 SUSE Linux Enterprise SP DVD 1,或者根据第 14.3.5 节 “准备目标系统的 PXE 引导”为 PXE 引导设置的目标系统。
请参考第 14 章 远程安装,以获取有关从远程服务器开始升级的深度信息。
要用 SP DVD 作为引导媒体执行网络安装,请执行如下操作:
插入 SUSE Linux Enterprise SP DVD 1 后引导计算机。一个类似于 SUSE Linux Enterprise 11 原始安装的引导屏幕就会出现。
选择引导服务包内核,然后使用 F4 选择网络安装源的类型(FTP、HTTP、NFS 或 SMB)。
提供相应的路径信息或选择 作为安装源。
从所提供的服务器里选择相应的安装服务器,或用引导选项提示提供安装源类型和实际地址(如 第 6.1.2 节 “从没有 SLP 的网络源安装” 中所示)。YaST 启动。
按第 7.5.2.3 节 “更新过程”中所述完成安装。
要通过网络执行 SUSE Linux Enterprise 服务包网络安装,请执行以下操作:
按照第 14.3.5 节 “准备目标系统的 PXE 引导”调整您的 DHCP 服务器设置以提供 PXE 引导需要的地址信息。
设置 TFTP 服务器来储存 PXE 引导需要的引导映像。
为此使用 SUSE Linux Enterprise 服务包的第一张 CD 或 DVD 或者遵循第 14.3.2 节 “设置 TFTP 服务器”中的指导。
在目标计算机上准备 PXE 引导和局域网唤醒。
对目标系统引导进行初始化,并用 VNC 远程连接到此计算机正运行的安装例程上。有关更多信息,请参见第 14.5.1 节 “VNC 安装”。
按第 7.5.2.3 节 “更新过程”中所述完成安装。
从安装媒体或网络成功引导后,根据如下所述继续开始更新:
在屏幕上选择和,并接受许可协议。按继续。
如果您已从物理媒体引导,请执行以校验媒体的完整性。除非您先前检查过媒体,否则请勿跳过此步骤。
在屏幕上,选择。单击将启动更新过程。
作为从 Novell 更新服务器为每一个客户端系统下载更新的备用方法,您可以使用适用于 SUSE Linux Enterprise 的 Subscription Management Tool (SMT) 将更新镜像到本地服务器。
此工具既可以充当客户端注册的 Novell Customer Center 代理,也可以充当软件更新安装源。http://www.suse.com/doc/smt11/ 上的 SMT 文档扼要介绍了此工具的功能及实施方式。
SUSE Manager 是一种服务器解决方案,用于为 SUSE Linux Enterprise 客户端提供更新、增补程序和安全修复。它随附了一套工具和基于 Web 的用户界面,用于执行管理任务。
http://www.suse.com/doc/suse_manager/ 上的 SUSE Manager 文档扼要介绍了此解决方案的功能以及服务器和客户端的设置方法。
以下工具支持联机迁移:
(图形用户界面)
zypper(命令行)
如果通过联机迁移更新您的系统,则会在系统运行时执行更新。更新完毕后,您只需要重引导一次。您仍然可以使用以下备用方法执行更新:
要执行联机更新,必须符合以下要求。另外,请确保阅读第 7.4 节 “有关更新的一般准备工作”。
要连接到更新通道,您的产品必须经过注册。如果尚未注册产品,请在 YaST 中运行 模块,或者运行 suse_register 命令行工具来开始注册。
确保已在当前安装的版本中安装了最新的增补程序。在执行联机迁移之前运行联机更新。当使用图形界面时,请启动 YaST 联机更新或更新程序小程序。在命令行上运行以下命令(最后一条命令需要运行两次):
zypper ref -s zypper update -t patch zypper update -t patch
需要时请重引导系统。
请参见第 1 章 YaST 联机更新 (↑管理指南)或第 6.1.3 节 “使用 Zypper 更新软件” (第 6 章 使用命令行工具管理软件, ↑管理指南),以获取有关联机更新工具的更多信息。
如果您的设置包含第三方软件或外接式附件软件,则在另一台计算机上测试此过程以确保升级未破坏依赖性。
![]() | 始终运行完整的联机迁移 |
|---|---|
始终要自始而终地完成整个联机迁移过程。如果联机迁移中途中断,则会损坏系统且无法恢复。 | |
如果符合所有要求(参见第 7.5.1.1 节 “要求”),托盘中的更新小程序将显示一条讯息,表示有可用的分发包升级。单击该讯息以启动 YaST 。或者,通过命令行以 root 的身份运行 /usr/sbin/wagon。
单击以确认对话框。
如果 发现不符合要求(必需的维护更新可用,但尚未安装),它将会自动执行自助更新,这可能需要重引导计算机。按屏幕上的说明进行操作。
在后续对话框中选择更新方法。选择以使用默认设置(推荐)。
单击 以手动选择用于联机迁移的软件通道。随后将显示通道列表,其中提供了用于手动启用、禁用、添加或删除通道的选项。添加 SP3 更新源更新源可以是 SP3 安装媒体,也可以是 SP3-Pool 和 SP3-Updates 通道。单击返回到对话框。
如果您想要查看更新过程对通道设置所做的更改,请选择。
按继续。
随后将重新注册系统。在此过程中,SP3-Pool 和 SP3-Updates 通道将加入系统(参见第 7.2.3 节 “通道模型”以获取更多信息)。确认添加通道。
如果您已在对话框中选择,将显示安装源的列表,其中提供了用于手动启用、禁用、添加或删除通道的选项。完成后单击继续。
系统会打开屏幕,其中显示了升级配置的摘要。提供了以下部分:
可以在此处添加 SUSE Linux Enterprise Server 附加产品或第三方产品。
列出在更新期间将要执行的操作。您可以选择先下载所有包,然后一并安装(推荐的默认设置),也可以选择逐个下载包并逐个安装。
更新的统计概述。
设置备份选项。
依次单击和以继续。
![]() | 中止联机迁移 |
|---|---|
在单击之前,您可以安全地在此屏幕以及所有先前的屏幕上中止联机迁移。单击将会退出更新过程,并将系统恢复到启动 YaST wagon 之前的状态。在退出 Wagon 之前,请按照屏幕上的指导操作并执行重新注册,以从系统中去除 SP2 通道。 | |
在更新过程中,将执行以下步骤:
更新包。
运行 SuSEconfig。
重引导系统(按)。
重新注册最近更新的系统。
您的系统已成功更新到服务包 3。
如果符合所有要求(参见第 7.5.1.1 节 “要求”),则意味着执行联机迁移所需的“产品”已添加到 /etc/products.d 中。运行以下命令可获取这些产品的列表:
zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2
此命令至少应返回 SUSE_SLES-SP3-migration。根据安装的范围,可能会列出更多的产品。
使用命令 zypper in -t product 产品列表安装上一步骤检索到的迁移产品,例如:
zypper in -t product SUSE_SLES-SP3-migration
注册上一步骤中安装的产品,以获取相关的更新通道:
suse_register -d 2 -L /root/.suse_register.log
刷新安装源和服务:
zypper ref -s
使用 zypper lr 检查您可以检索的安装源列表。
如果未启用其中的任一安装源(在遵循此工作流程时,默认情况下不启用 SP3 安装源),请使用 zypper modifyrepo --enable 安装源别名启用该安装源,例如:
zypper modifyrepo --enable SLES11-SP3-Core SLES11-SP3-Updates
如果您的设置包含可能与 SP3 不兼容的第三方安装源,请使用 zypper modifyrepo --disable 安装源别名禁用这些安装源。
现在所有工作准备就绪,可以使用 zypper dup --from REPO 1 --from REPO 2 ... 执行分发包升级了。确保使用 --from 列出全部所需的安装源,例如:
zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates
按 确认开始升级。
在通过上一步骤完成分发包升级后,请运行以下命令:
zypper update -t patch
在完成升级到 SP3 之后,您需要重新注册产品:
suse_register -d 2 -L /root/.suse_register.log
最后,重引导您的系统。
您的系统已成功更新到服务包 3。
SUSE 广泛使用了向后移植。本部分中的信息将会帮助您理解为何通过比较版本号来判断软件功能和问题的做法并不可靠。
上游开发者主要关心所开发软件的进度。在许多情况下,他们会一边修复 bug,一边引入尚未接受广泛测试并可能会造成新 bug 的新功能。
对于分发包开发者而言,必须区分两种情况:
在对功能造成有限中断的情况下执行的 bug 修复;以及
可能会中断现有功能的更改。
在大多数情况下,当某个包已属于所发布的分发包时,分发包开发者不会遵照所有的上游更改。通常,他们会继续使用最初发布的上游版本,并根据上游更改来创建增补程序以修复 bug。这种做法称为向后移植。
通常,分发包开发者只会在两种情况下引入软件的更新版本:
当他们的包与上游版本之间的差异过大,以致向后移植的做法不再可行,或者
软件(例如防恶意软件的软件)由于固有的性质而变得不合时宜。
由于我们致力于在大量企业软件考虑因素之间实现合理的平衡,SUSE 广泛使用了向后移植。其中,最重要的考虑因素包括:
提供稳定的接口 (API),软件供应商在构建可用于 SUSE 企业产品的产品时可以依赖这些接口。
确保 SUSE 企业产品版本中使用的包具有最好的质量,这些包本身以及在成为整个企业产品一部分后已经过充分的测试。
由其他供应商对 SUSE 的企业产品维持各种认证,就像对 Oracle 或 SAP 产品进行认证一样。
使 SUSE 开发者能够专注于竭尽所能开发出下一个版本的优质产品,而不是狭隘地将注意力分散于如何推出更多的版本。
清楚地了解特定企业版本的功能,使得 我们的支持人员能够准确及时地提供相关功能的信息。
不要将新的上游包版本引入我们的企业产品,这是常见的策略规则,但不是硬性规则。对于有限种类的包,尤其是防病毒软件,我们考虑更多的是安全方面的因素,而不是质量保证方面优先考虑的保守性因素。对于这个种类的包,偶尔会将更新的版本引入企业产品系列的发布版本。
有时,对于其他类型的包,我们也会选择引入新版本,而不是向后移植。当生成向后移植在经济效益上不可行,或者由于极其相关的技术原因而需要引入更新版本时,我们会采取这种做法。
由于采用向后移植的做法,用户不能简单地通过比较版本号来确定 SUSE 包是否包含针对特定问题的修复,或者其中是否添加了特定的功能。在使用向后移植时,SUSE 包版本号的上游部分只是表示 SUSE 包基于的上游版本。它可能包含不在相应上游版本中,但已向后移植到 SUSE 包中的 bug 修复和功能。
有关 bug 修复和功能等的信息可以储存在许多位置:
包的更改日志:
rpm -q --changelog name-of-installed-package rpm -qp --changelog packagefile.rpm
其输出简要记录了包的更改历史记录。
包的更改日志可能包含类似于引用 Novell Bugzilla 跟踪系统中的 bug 的 bnc#1234 之类的项,或者包含指向其他 bug 跟踪系统的链接。(出于保密政策,您不一定能够访问所有此类信息)。
包可能包含 /usr/share/doc/packagename/README.SUSE 或 README.SuSE 文件,该文件包含特定于 SUSE 包的常规综合信息。
RPM 源包包含构建普通二进制 RPM 期间应用的增补程序,这些增补程序以独立文件的形式存在,如果您熟知如何阅读源代码,可以对这些文件进行解释。请参见《Maximum RPM》(《充分利用 RPM》)一书以获取更多信息。
有关安全 bug 修复,请参见 SUSE 安全通知。这些修复往往通过公共漏洞和披露项目所维护的标准化名称(例如 CAN-2005-2495)来引用 bug。
在涉及到向后移植时,版本号的这种有限价值可能会造成在特定情况下产生问题,也就是在使用安全扫描工具的时候。某些安全漏洞扫描工具(或者在此类工具中进行特定的测试)只能基于版本号运行。在涉及到向后移植时,这些工具/测试很容易生成“误报”(声明找到了有漏洞的软件片段,但事实上这个片段没有漏洞)。在评估安全扫描工具生成的报告时,用户始终应该调查某个项是仅仅基于版本号,还是基于对是否存在实际漏洞而展开的实际测试。
Atomic Update 所基于的工具能够管理系统的两个副本,并在更新失败后可以轻松地恢复系统。提供的工具需要特殊的磁盘分区设置。每个系统副本都驻留在自己的主分区上。如果更新失败,总是可以转换回以前的系统状态,该系统状态在其他分区上。
![]() | 严格的分区要求 |
|---|---|
磁盘分区的实施有严格的要求,第一个 root 分区是
整个磁盘大小减去 | |
用 /dev/sda1 作为单个 root 分区安装系统,其空间小于整个磁盘大小的一半。
根据需要自定义已安装系统。确保 multi-update-tools 包已安装。
运行 multi-update-setup --partition,创建大小类似的第二个 root 分区 (/dev/sda2)。
根据需要对剩余磁盘空间分区,并继续自定义 (*)。
运行 multi-update-setup --clone 将系统复制到其他分区。用此命令还可以更改目标系统 /etc/fstab 中的 /(root) 条目。
如果需要,请执行进一步自定义 (*)。
运行 multi-update-setup --bootloader 初始化引导加载程序设置。这样引导加载程序菜单就会包含一个条目,用于引导另一个系统。
![]() | 强制安装 GRUB 引导加载程序 |
|---|---|
安装 GRUB 引导加载程序属于强制性操作。这些工具与其他引导加载程序不兼容。 | |
如果没有对标有 (*) 的项进行自定义,请运行 multi-update-setup --complete 执行所有三个步骤。
运行 multi-update。此命令在 chroot 环境中运行 zypper,更新另一个系统 - 不管哪一个处于活动状态。其引导菜单在引导时作为默认值提供。
如果更新的系统在更新之后引导加载程序受损,则必须更改“活动”标志,将它分配给另一个系统的根分区,以便可以引导该系统。
如果更新的系统根本无法引导,则需要访问引导加载程序菜单以选择另一个系统。
有关 GRUB 的更多信息,请参见第 10 章 引导加载程序 GRUB (↑管理指南)。
根分区必须按分区名、ID 或其他方式进行装载。不支持按分区 UUID 或标签进行装载。
有关更多信息,请参见随 multi-update-tools 包一起提供的 /usr/sha e/doc/packages/multi-update-tools/README。
在迁移过程中的某个时间点,您可以使用迁移钩子来运行自定义的外部脚本。这些脚本可让您处理无法通过正常 RPM 脚本处理的具体问题,或者让您执行迁移期间可能需要执行的任何附加操作(在正常包更新期间不需要执行)。
迁移钩子需要以 root 特权执行,因此,可以在脚本中执行任何维护任务(启动/停止服务、数据备份、数据迁移等)。脚本不能是交互性的;STDIN 和 STDOUT 在 YaST 中运行时将被重定向到管道。不应使用 X 会话,因为它不一定在所有情况下都可用(例如以文本模式运行时)。不要忘记设置对钩子脚本的可执行许可权限。
yast2-wagon 包版本 2.17.32.1(以 SLES11-SP2 的更新的形式提供)或 2.17.34(包含在 SLES11-SP3 中)或更高版本支持迁移钩子。
可以在 /var/lib/YaST2/wagon/hooks/ 目录中搜索这些脚本。预期的脚本名称采用步骤_顺序号_前缀_名称格式,其中:
步骤
是预定义的迁移步骤名称,描述当前的迁移步骤。
顺序号
是 00...99 范围内的顺序号,您可以根据此顺序号设置脚本的执行顺序。(为确保正确排序,必须保留开头的零!)
前缀
应该唯一,以避免冲突(类似于名称空间)。使用包名称(如果它是包的一部分)或供应商名称、因特网域名等,简而言之,请使用您认为唯一性充足的任何内容
名称
可以是任何字符串(只是用于区分脚本)。建议使用某个描述性名称。
脚本应返回退出值 0。如果该脚本失败(返回任何非零退出值),Wagon 中会显示错误讯息,此时您可以重启动脚本,忽略失败(并继续执行其他脚本),或者完全取消当前步骤和阶段的钩子。
钩子脚本有时可以运行多次(在 Wagon 对话框中前后切换时,Wagon 可能会自行重启动,或者迁移工作流程中的某些步骤可能会执行多次),因此,脚本必须处理这种情况(它们可以在开始时确认是需要执行操作还是操作已经执行,或者它们可以创建一个简单的临时戳记文件,或正确解决多次运行的问题)。
某些钩子是可选的(因为它们依赖于前面的结果,或依赖于用户选择的值)。请注意,有些钩子会多次调用(例如,在迁移之前和迁移之后会调用注册)。以下是按执行顺序列出的受支持钩子(步骤名称)的列表:
最开始启动(注意:在重启动 Wagon 后会再次调用)
在显示欢迎对话框之前/之后启动
Wagon 将检查注册状态(如果某些产品的注册已失效,迁移可能失败)。如果任何情况都正常,则不显示对话框,Wagon 将自动继续下一步
启动安装源管理器(可选,仅限增补程序 CD 模式)
在 Wagon 更新自身之前/之后调用(以确保使用最新版本进行迁移)
在安装迁移产品之前/之后调用
Wagon 将询问用户是要通过 Novell Customer Center 安装源还是使用自定义安装源进行迁移;下一步则依赖于用户的选择
运行 SUSE 注册(以添加迁移安装源)
手动安装源管理
选择迁移安装源(使用 Novell Customer Center 时进行完整/最小迁移)或选择更新安装源(自定义安装源迁移)
在启动包更新之前,执行此步骤之后,实际迁移将会开始,此时无法自动返回到前一状态;这是因为在此阶段中止会导致系统不一致(升级到一半),导致需要手动回滚
运行 SUSE 注册(以注册更新的产品)
Wagon 在成功迁移后显示恭喜对话框之前/之后
在 Wagon 退出之前的那一刻调用(不管迁移结果如何,始终会调用;另外,在中止之后以及在重启动时也会调用)
这是一些特殊的中止钩子,在用户中止迁移时调用。这些钩子可以在迁移工作流程的任一步骤中调用,因此,无法保证执行顺序。如果这些钩子依赖于其他钩子的结果,则脚本需要检查当前状态。
用户已确认中止迁移
用户已确认在中止后回滚(还原到开始迁移之前安装的旧产品)。这些钩子在 before_abort 之后调用,如果用户未确认回滚则跳过此步骤。
每当 Wagon 重启动自身时就会调用这些钩子。
Wagon 正在完成,并将再次启动
Wagon 已重启动,并在运行迁移工作流程中的下一步
钩子列表的内容相当广泛,但其中的许多钩子只在特殊情况下才有效果。在正常的用例中,应该给这些钩子指定优先顺序:
要在迁移系统之前(系统仍在运行上一版本)执行某项操作,请使用 before_package_migration 钩子。
此时,用户清楚地知道迁移已准备就绪并即将开始;在此前的所有步骤中,可以中止迁移。
要在系统迁移之后(系统正在运行新的迁移版本,但某些功能可能尚未激活,例如,更新的内核需要重引导,更新的服务可能需要重启动,等等)执行某项操作,请使用 before_congratulate 或 after_congratulate 钩子。
此钩子也可用于清理 before_package_migration 钩子的临时结果。此时,迁移已成功完成。
要在中止迁移的情况下还原更改,请根据情况使用 abort 钩子之一。请记住,可以在任何时间调用 abort 钩子,因此,可能无需还原(可能尚未调用执行更改的钩子)。abort 钩子需要检查当前状态。
旧版 Wagon 仅支持两个钩子脚本:/usr/lib/YaST2/bin/wagon_hook_init 和 /usr/lib/YaST2/bin/wagon_hook_finish。问题在于,只能将一个脚本作为钩子运行,并且无法将钩子直接放入 RPM 包中。
新版 Wagon 仍然支持这些旧钩子脚本以实现向后兼容,但是,应该使用新的钩子 before_init 和 before_exit 来取代对应的已过时钩子。