[小技巧] 巧用yum三板斧,巧解软件源重复导致的软件包冲突
在使用yum的过程中,我们经常会遇到冲突的情况。有时冲突来源于同时安装了多个版本/架构的软件包,但更多时候冲突来源于当前安装的软件与依赖的软件来自不同软件源。由于yum基于rpm,而rpm包名的规则为
包名-版本号-发布次数-发行商-Linux平台-适合的硬件平台-包扩展名
,这就造成了不同软件源中包名上的差别会直接导致冲突。本文将以一个简单的小例子,来为读者讲解如何解决软件源重复导致的yum冲突。
在使用yum的过程中,我们经常会遇到冲突的情况。有时冲突来源于同时安装了多个版本/架构的软件包,但更多时候冲突来源于当前安装的软件与依赖的软件来自不同软件源。由于yum基于rpm,而rpm包名的规则为
包名-版本号-发布次数-发行商-Linux平台-适合的硬件平台-包扩展名
,这就造成了不同软件源中包名上的差别会直接导致冲突。本文将以一个简单的小例子,来为读者讲解如何解决软件源重复导致的yum冲突。
为了保证Linux的安全性和稳定性,我们经常需要对安装的软件进行更新。但如果某些更新与当前环境存在兼容性问题(最典型的例子是内核更新与虚拟机Hypervisor的兼容性),我们应该怎么做呢?在CentOS/Fedora/RHEL中(后文以CentOS为例),大部分用户可能会直接修改仓库配置文件,或者执行
yum update --exclude=xxx
,但这两种方法都不够直观,操作也比较繁琐。本文将为读者介绍一种使用yum/dnf的versionlock插件避免特定软件被更新的方法。
近年来,几乎所有现代Linux发行版都将service替换成了systemd以实现更完善的服务管理,而随之变化的是相关用户策略的变化。可能不少读者都遇到过systemd服务提示打开文件数过多,但设置ulimit无效的问题,尤其是对于数据库这种并发数较大的业务。本文将为读者讲解如何正确地为systemd的服务配置ulimit限制。
在前一篇文章中,我简述了CentOS下安装旧版本软件的方法,该文章以
kubeadm
为例完成了安装,但不久后我发现该方法对Docker不奏效,需要额为的操作。因此我撰写这篇补充的文章,专门介绍如何安装旧版本Docker。
由于最近要做关于Kubernetes的一系列漏洞分析,需要安装大量旧版本的Kubernetes,通常安装旧版本软件的方法是直接找到旧版本源码,然后从源码进行构建,但该方案过于复杂,恰好测试环境是CentOS操作系统,那么能不能直接通过CentOS的包管理器yum来安装旧版本软件呢?方法其实很简单。