关于红帽Linux补丁管理的尝试和思考

因为没有安装红帽专门用于补丁管理的satelite服务器,很多单位yum服务器的现状,多为通过reposync命令将所有的该操作系统指定的订阅频道下载。通过http来提供web供其他服务器访问。

这种方法有一个不完美的地方,就是没有办法针对某一个小版本做yum源,只能是针对大版本提供更新。没有办法使用update命令在当前操作系统小版本内升级。例如:在当前版本rhel7.1操作系统中使用yum update –y 命令,最终将会升级到目前保哥本地的rhel7的最高版本rhel7.7。关于红帽Linux补丁管理的尝试和思考

在当前系统安全要求越来越高,linux毕竟不像Windows那样有各种的补丁分发工具,可以很方便的获知某台服务器上缺失的补丁。但是,Linux又不可能万年不更新,什么时候宕机什么时候算,主动的去尝试思考如何解决该问题,能否可以利用yum仓库在时间上做到相对的基线版本。

有了思考,就要动手找寻相关的解决方案,经过几天闭门造车的整理,关于红帽Linux补丁管理有了以下想法和尝试。

    方法一

(1),依旧使用reposync更新包,保持原有和官网保持更新,update直接到最新版本。平时不对内网服务器提供yum仓库服务。仅在紧急状况下提供最新的补丁包更新,此处需要rhel6、rhel7、rhel8、nfs/web服务器4台,每台服务器将对应版本的补丁包下载到NFS共享盘中不同目录内,通过NFS/WEB服务器来统一处理、发布。

(2),挂载指定版本的iso光盘,例如:rhel7.1。平时对相同版本的内网服务器提供yum仓库服务,更新方式为官网有新版本的iso光盘。此外,利用Yum命令获取安全相关的补丁包,并处理整合到仓库内。所有使用该yum的服务器能初步达到统一基线。缺点为包版本不是最新,基本上1年更新一次。但是Linux服务器,多数时候也不会更新最新的包。

    方法二

同方法一基本相同,但仅需要1台服务器,使用docker来替代4台服务器。挂载本地文件系统,将下载的包在宿主机上统一处理。缺点和优点也基本相同,差异在于订阅的使用数量和如果有了rhel9,可能处理起来更检单。

    方法三(正在测试)

[content_hide]该方法正在测试,目前在互联网上未发现相关使用案例的分享,没有参考的测试和部署文档。保哥由于单位网速比较慢,更新一次7000多个包,需要的时间按照200小时起步。情况艰苦,但是也测试成功更新到指定版本,从理论分析reposync应该是可以指定版本。

(1),先指定release版本,再使用reposync更新包。

(2),通过http来提供web供其他服务器访问指定release版本的yum仓库,此种方式可以使得,使用update命令保证相同版本内最新。代替直接挂载ISO镜像更新不及时的问题。

(3),通过在某个时间点,拷贝下载包,经过处理和发布,来创建yum基线。此种方式可以在一年内多次更新Linux。

(4),测试成功后,还能容器化。[/content_hide]

    结论

以上都是保哥这两天,闭门造车的结果,分享到了保哥笔记。可能因为保哥水平有限,很多地方让人忍俊不禁。有错误请指出,我来学习,供其他人一起交流。

原创文章,作者:shengbao,如若转载,请注明出处:https://baogebiji.com/11.html

发表评论

电子邮件地址不会被公开。