某企业生产系统升级Linux系统及内核

一、背景介绍

    Phoenix Talon漏洞曝光后，影响激活目前市面上99%的Linux系统版本，某企业为了提升系统安全性，并满足合规性要求，计划将目前redhat 6.2版本升级到6.8版本后，再将内核升级到符合要求的4.11.6版本。由于企业生产系统部署在VMware 虚拟化平台上，为了安全起见，先将生产系统中的一套业务系统（3台）虚拟机克隆一份，在克隆出来的虚拟机上进行测试，测试完成后，关闭原有虚拟机运行观察一个月，确认运行正常，删除原有虚拟机。

二、操作步骤

1.在vCenter上找到目标虚拟机并进行克隆（步骤略）

2.启动克隆后的虚拟机，此时克隆后的虚拟机无法连接网络，此时使用ifconfig命令看到设备名称变为eth3

3.打开/etc/sysconfig/network-script目录，发现克隆后的虚拟机多出一个ifcfg-Auto_eth2的设备名称，但是原有虚拟机的IP地址等设置信息并不在ifcfg-eth0中

4.打开此虚拟机的设置，找到虚拟网卡的mac地址

5.再到/etc/udev/rules.d/目录下找到70-persistent-net.rules文件

6.打开70-persistent-net.rules文件发现克隆后的虚拟机在70-persistent-net.rules文件中变成了4个网卡，与虚拟机网卡mac地址相吻合的设备名称变成了eth3，这也就能解释步骤2中ifconfig命令看到的设备名称是eth3。

7.删除70-persistent-net.rules文件中多余的网卡信息，并将eth3改为eth0后，删除/etc/sysconfig/network-script目录下现有网卡配置文件，并将ifcfg-Auto_eth2改名为ifcfg-eth0后重启虚拟机，此时克隆后的虚拟机网络连接就恢复正常。

8.将光盘分别挂载到3台虚拟机上，并将光盘设置为本地yum源，使用yum update命令进行操作系统及内核升级（步骤略）

9.升级完成后系统由redhat6.2升级到6.8，内核版本由2.6.2升级到2.6.4，下载4.11.6内核源码包上传至其中一台VM上，进行内核编译，编译完成后更改/boot/grub/grub.conf文件，将默认使用的内核设置为编译后的内核，重启虚拟机确认内核版本是否为4.11.6（步骤略）

10.编译后的内核其实就是在/boot目录下多了新的initramfs、Syste.map、vmlinuz内核启动时用到的文件

以及在/lib/modules目录下新内核的库文件（64位系统编译完后modules目录也在/lib而不是/lib64目录下）

11.由于内核编译过程很费时间，而3台VM都是运行在虚拟化平台上，且平台硬件和VM系统信息完全一样，所以其他2台VM就不需要再进行编译，而是将编译好的VM /boot目录下的initramfs、Syste.map、vmlinuz文件和/lib/modules目录下新内核的库文件拷贝到其他2台VM对应目录下后，再使用编译好的VM /boot目录下的grub目录覆盖其他2台VM的grub目录后，其他2台VM重启也就是4.11.6内核了。

产生的疑问

1.grub.conf文件记录的是各分区的uuid号，直接覆盖掉待升级内核的grub.conf文件还可以正常启动，3个VM的uuid完全一样？

答：得益于业务系统使用的3台虚拟机都是基于同一模板创建，UUID一样。如果不是基于同一模板创建的虚拟机，直接覆盖grub目录启动会报错，原因是grub.conf文件和/etc/fstab文件中/的UUID不一致，内核无法找到/。实际操作中建议不要拷贝grub目录，而是手动修改grub.conf文件中kernel和initrd的指向。

2.升级内核后操作系统比发生改变，而是用yum update命令内核和操作系统都会升级，说明内核和操作系统是两个独立的存在，对于内核来说操作系统是不是个类似rpm包的东西，如果是，包名是什么？

3.通过上述测试发现升级完内核后，程序可以正常启动，个人感觉内核是一个比操作系统更底层的东西，并且和操作系统无太大直接关系，而应用程序是跑在操作系统上的，与内核的直接关系更小，那么内核在不同系统版本见是否可以使用直接拷贝的方式