Dealing with multiple repositories on CentOS 4/5/6/7 with YUM and Protectbase Plugin


Use the Protectbase yum plugin when using 3rd party repos to protect your system from dependency conflicts and stability issues in the long run.


As a system administrator, you try to control every aspect of the system so you can replicate it and push it to new boxes.
I myself use Ansible for orchestration, I manage my files and configurations in a git repo and push my changes to all servers in a uniform way.
This makes administrating multiple systems easy, no more login-in into every single server to update your /etc/hosts or /etc/resolv.conf now you can just edit it one time and push your changes to 1, 2 or even 10,000 servers.

So all that is great, but what if your using 3rd party yum repositories like EPEL, Elastics, 2600hz, Cachewall, CloudLinux etc.
Normally on a system, you just have the BASE repo. This is everything officially release by the CentOS team of developers.

They essentially pull all the official repositories from Red Hat Enterprise Linux, remove branding and then release it.
So they usually only support stable and heavily tested software.

But… we live in a cutting-edge world and sometimes we want to move faster than our upstream provider (RHEL, CentOS) so we install repositories like EPEL (Extra Packages for Enterprise Linux) that allow us to install an updated version that RHEL, CentOS before they are available or 3rd party “unapproved” packages.

Normally it shouldn’t be an issue. You install EPEL and install software like HTOP, IFTOP, AG. Cool now your system has all the reliable packages from your upstream and has the possibility to install 3rd party plugins that are very useful for daily administration.

But what if you install another repo outside of BASE and EPEL? like CloudLinux?

Well, Cloud Linux (CL) has a repository that replaces, patches or updates base packages! Usually, that’s wanted, you paid for the licence and it makes sense that you want their packages and update because you’re literally paying for it.

So now maybe the problem is starting to peek through..

You have two repositories that could start conflicting.

Thankfully there’s a solution to this, usually yum does conflict resolution very well. But that generally only works when dealing with 1 repo, you can’t really have conflicts if your using 1 repo that has all the same version numbers, conflicts happen when you have two or more repositories and one repository is ahead of another.


gcc is version 4.8.5-28.el7_5.1 on BASE.
gcc is version 5.3.4-3-epel on EPEL

You run yum update and yum sees an updated for GCC on EPEL and tries to update it but GCC has reverse dependencies.

rpm -q --whatrequires gcc


Some of these dependencies could conflict. Why does it conflict? because the dependencies rely on GCC version 4.8 and don’t have equivalents on EPEL so they can’t update.

Then you’re faced with a choice. Do you run –skip-broken and continue or do you solve this problem the recommended way?
Or even worse, remove the package just to pass dependency check… (if that’s your only choice I’d recommend running “rpm -q –whatrequires <>”

And that way is using the plugin Protectbase.

As per the official CentOS Wiki (

The purpose of the Protectbase plugin is to protect certain repositories from updates from other repositories. Repositories that are to be protected will not be updated by newer files from unprotected repositories. This plugin is recommended for anyone who routinely enables 3rd party repositories, as these non-CentOS repositories may update certain system files, potentially causing your CentOS installation to become unstable.

We mentioned CloudLinux and they also recommend using this plugin to protect your repositories. (

To protect packages from CloudLinux repositories from being updated from 3rd party repositories like rpmforge, and to prevent such dependencies issues

Example of cPanel / WHM package update after enabling protectbase

checkyum version 22.3
Loaded plugins: protectbase, rhnplugin, universal-hooks
This system is receiving updates from CLN.
158 packages excluded due to repository protections
Resolving Dependencies
--> Running transaction check
---> Package kernel-headers.x86_64 1:3.10.0-714.10.2.lve1.5.19.7.el7 will be updated
---> Package kernel-headers.x86_64 1:3.10.0-714.10.2.lve1.5.19.8.el7 will be an update
---> Package kernel-tools.x86_64 1:3.10.0-714.10.2.lve1.5.19.7.el7 will be updated
---> Package kernel-tools.x86_64 1:3.10.0-714.10.2.lve1.5.19.8.el7 will be an update
---> Package kernel-tools-libs.x86_64 1:3.10.0-714.10.2.lve1.5.19.7.el7 will be updated
---> Package kernel-tools-libs.x86_64 1:3.10.0-714.10.2.lve1.5.19.8.el7 will be an update
---> Package libgudev1.x86_64 1:219-57.el7_5.1 will be updated
---> Package libgudev1.x86_64 1:219-57.el7_5.3.cloudlinux will be an update
---> Package python-perf.x86_64 1:3.10.0-714.10.2.lve1.5.19.7.el7 will be updated
---> Package python-perf.x86_64 1:3.10.0-714.10.2.lve1.5.19.8.el7 will be an update
---> Package systemd.x86_64 1:219-57.el7_5.1 will be updated
---> Package systemd.x86_64 1:219-57.el7_5.3.cloudlinux will be an update
---> Package systemd-libs.x86_64 1:219-57.el7_5.1 will be updated
---> Package systemd-libs.x86_64 1:219-57.el7_5.3.cloudlinux will be an update
---> Package systemd-sysv.x86_64 1:219-57.el7_5.1 will be updated
---> Package systemd-sysv.x86_64 1:219-57.el7_5.3.cloudlinux will be an update
--> Finished Dependency Resolution

Installed Packages
Name        : libgudev1
Arch        : x86_64
Epoch       : 1
Version     : 219
Release     : 57.el7_5.3.cloudlinux
Size        : 50 k
Repo        : installed
From repo   : cloudlinux-x86_64-server-7
Summary     : Libraries for adding libudev support to applications that use glib
URL         :
License     : LGPLv2+
Description : This package contains the libraries that make it easier to use libudev
            : functionality from applications that use glib.

Package libgudev1.x86_64 1:219-57.el7_5.3.cloudlinux will be an update

As you can see, after enabling protectbase and editing the .repo files and/or (/etc/yum/pluginconf.d/rhnplugin.conf) you can add “protect=0 or protect=1”


protect = 1


name=CentOS-$releasever - Base - OVH BHS

Repos with Protect=1 can update each other and repos with Protect=0 cannot, even if the repo has a package that’s newer.

Usually, for a stable working system, I’d recommend protec=1 for CentOS protect=0 for EPEL or RPMForge, protect=1 for CloudLinux since your paying for the patches. But if you have CloudLinux maybe remove protect=1 from CentOS base.

In the end, it’s your choice and what needs to be done and why based on your needs. But in general most admins I’ve spoken to always forget the protectbase package when using 3rd party repositories.

Hence this post.