• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Updates failed due to epel repo disabled.

Dave W

Regular Pleskian
Server operating system version
CentOS 7.9.2009 x86_64
Plesk version and microupdate number
Plesk Obsidian 18.0.43.1
Hello,

Product version: Plesk Obsidian 18.0.43.1
OS version: CentOS 7.9.2009 x86_64
Build date: 2022/04/14 18:00
Revision: 1a6b26fb2fd0ac923f3ca10bdfd13b721cb5c676


Just had a bunch of servers fail to update because
Code:
Plesk installation requires 'epel' OS repository to be enabled.
Make sure it is available and enabled, then try again.

Didnt think the epel repo had to be enabled for Plesk?
Is this new?
Dave_W
 
What is the output of the following commands:

# yum repolist | grep epel

# ls -la /etc/yum.repos.d/epel.*
 
Hi Igor

Code:
yum repolist | grep epel
epel/7/x86_64                  EPEL YUM repo                              13,753

 ls -la /etc/yum.repos.d/epel.*
-rw-r--r-- 1 root root  130 May 31 01:01 /etc/yum.repos.d/epel.repo
-rw-r--r-- 1 root root 1358 Sep  4  2021 /etc/yum.repos.d/epel.repo.rpmnew

Rgds
Dave_W
 
Try to fix it with:

# mv /etc/yum.repos.d/epel.repo /root/
# mv /etc/yum.repos.d/epel.repo.rpmnew /etc/yum.repos.d/epel.repo
 
Hi Igor,
Updates are running, but when did Plesk start using the Epel repo?
We normally install it for some added packages that we use on our servers but leave it disabled as it used to interfere with Plesk updates previously?

Will need to change our ansible configs for these servers.

Rgds
Dave
 
Then, should Epel repo be enabled ?
If I update using yum at ssh, it will list several updates, all of them form Epel; but if I run update from Plesk panel itself, it won't show any update.
We are running updated Obsidian 18.0.44 update 1.

Please advice

Regards,
 
Hi Igor,

Shouldn't the upgrade test if an epel repo is already installed and accommodate that?

Also what do you mean by "not the one you might have used before", the epel repo is just one repo?

Rgds
Dave_W
 
Yes, they were, but now epel.repo.rpmew is epel.repo but we are talking about the same thing right? Its the epel repo?
When you run yum update the epel repo will come into play and update any packages that were originally installed from base if there are newer versions on epel, thats not always desirable?
 
Yes, they were, but now epel.repo.rpmew is epel.repo but we are talking about the same thing right? Its the epel repo?
When you run yum update the epel repo will come into play and update any packages that were originally installed from base if there are newer versions on epel, thats not always desirable?
Exactly! In the past, enabling Epel led to linux updates not always welcomed and some even conflicting Plesk's updates.

Our upgrade to version 18.0.44, was done seamlessly through the panel itself BUT I am almost certain we had Epel repo already installed and as far as I remeber it was disabled 'cause it was only used to install some specific files needed for a customer's web app.

So, the question is how can we be certain that we are using and enabling the right Epel repo?

Thanks again for your help,

Regards
 
So, the question is how can we be certain that we are using and enabling the right Epel repo?
On my personal Plesk 18.0.44 server where epel was not previously used, I see after update:

Code:
# cat /etc/yum.repos.d/epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=http://download.example/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=http://download.example/pub/epel/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place it's address here.
#baseurl=http://download.example/pub/epel/7/source/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

Code:
# rpm -qf /etc/yum.repos.d/epel.repo
epel-release-7-14.noarch
 
Thanks Igor,

Our Epel.repo is exactly the same.
Still, the "problem" persists, if updated through control panel everything is ok and updated but if updated through yum, I get:

# yum update
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: download.cf.centos.org
* epel: dl.fedoraproject.org
* extras: download.cf.centos.org
* updates: download.cf.centos.org
Resolving Dependencies
--> Running transaction check
---> Package libbsd.x86_64 0:0.6.0-3.el7 will be updated
---> Package libbsd.x86_64 0:0.8.3-1.el7 will be an update
---> Package libc-client.x86_64 0:2007f-4.el7.1.art will be updated
---> Package libc-client.x86_64 0:2007f-16.el7 will be an update
---> Package libidn2.x86_64 0:2.0.4-3.el7 will be updated
---> Package libidn2.x86_64 0:2.3.2-1.el7 will be an update
---> Package libopendkim.x86_64 0:2.11.0-0.1.el6 will be updated
---> Package libopendkim.x86_64 0:2.11.0-0.1.el7 will be an update
---> Package lua-socket.x86_64 0:2.0.2-4.el7.art will be updated
---> Package lua-socket.x86_64 0:3.0.0-1.el7 will be an update
---> Package mod_qos.x86_64 0:11.24-1.el7.art will be updated
---> Package mod_qos.x86_64 0:11.70-1.el7 will be an update
---> Package perl-JSON-XS.x86_64 0:3.01-centos7.17100419 will be updated
---> Package perl-JSON-XS.x86_64 1:3.01-2.el7 will be an update
---> Package pigz.x86_64 0:2.3.3-1.el7.centos will be updated
---> Package pigz.x86_64 0:2.3.4-1.el7 will be an update
---> Package python-boto.noarch 0:2.32.1-1.el7.art will be obsoleted
---> Package python-iso8601.noarch 0:0.1.10-1.el7.art will be obsoleted
---> Package python2-boto.noarch 0:2.45.0-3.el7 will be obsoleting
--> Processing Dependency: python-rsa for package: python2-boto-2.45.0-3.el7.noarch
---> Package python2-iso8601.noarch 0:0.1.11-8.el7 will be obsoleting
---> Package ssdeep.x86_64 0:2.12-1.el7.art will be updated
---> Package ssdeep.x86_64 0:2.14.1-1.el7 will be an update
---> Package ssdeep-libs.x86_64 0:2.12-1.el7.art will be updated
---> Package ssdeep-libs.x86_64 0:2.14.1-1.el7 will be an update
---> Package webalizer.x86_64 0:2.23_05-7.el7 will be updated
---> Package webalizer.x86_64 0:2.23_08-6.el7 will be an update
---> Package zstd.x86_64 0:1.5.0-1.el7 will be updated
---> Package zstd.x86_64 0:1.5.2-1.el7 will be an update
--> Running transaction check
---> Package python2-rsa.noarch 0:3.4.2-3.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================
Package Arch Version Repository Size
=========================================================================================================
Installing:
python2-boto noarch 2.45.0-3.el7 epel 1.7 M
replacing python-boto.noarch 2.32.1-1.el7.art
python2-iso8601 noarch 0.1.11-8.el7 epel 20 k
replacing python-iso8601.noarch 0.1.10-1.el7.art
Updating:
libbsd x86_64 0.8.3-1.el7 epel 85 k
libc-client x86_64 2007f-16.el7 epel 562 k
libidn2 x86_64 2.3.2-1.el7 epel 148 k
libopendkim x86_64 2.11.0-0.1.el7 epel 75 k
lua-socket x86_64 3.0.0-1.el7 epel 115 k
mod_qos x86_64 11.70-1.el7 epel 1.2 M
perl-JSON-XS x86_64 1:3.01-2.el7 epel 103 k
pigz x86_64 2.3.4-1.el7 epel 81 k
ssdeep x86_64 2.14.1-1.el7 epel 24 k
ssdeep-libs x86_64 2.14.1-1.el7 epel 19 k
webalizer x86_64 2.23_08-6.el7 epel 134 k
zstd x86_64 1.5.2-1.el7 epel 424 k
Installing for dependencies:
python2-rsa noarch 3.4.2-3.el7 epel 68 k

Transaction Summary
=========================================================================================================
Install 2 Packages (+1 Dependent package)
Upgrade 12 Packages

Which one is the right way and solution?

Thanks again,
 
Which one is the right way and solution?
If we are talking in the context of Plesk, the right way is to update everything through its interface. If you ignore Plesk and use OS command-line utilities as a Linux system administrator, that's your right, but we are not responsible for that.
 
If we are talking in the context of Plesk, the right way is to update everything through its interface. If you ignore Plesk and use OS command-line utilities as a Linux system administrator, that's your right, but we are not responsible for that.
OK, but Plesk has enabled the epel repo without notifying administrators, thats a pretty big change to a servers configuration and may impact hard on some servers. Why not install the epel repo and default it as disabled, but use --enable-repo within the Plesk update script if it requires the epel repo?
 
Can someone from the Plesk devs please answer Dave's question?

It's weird that there is a difference between manual updating using yum and automatic updates using Plesk. Also, the decision to use the epel.repo is totally unexpected as it has led to big issues in the past in combination with Plesk.

We always update our servers manually as updates via Plesk is IMHO not the best way to update a Linux server. You need to check if there are processes that need a restart after each update. We always use the command "needs-restarting -s" for this. You would be surprised how many processes need a restart after a typical update.
 
Any update on this?

We cant have the epel repo enabled so that plesk can selectively update packages.
 
Back
Top