CentOS 7 queries

Submitted by cyrus on Fri, 01/30/2015 - 19:33 Pro Licensee
  1. I installed the EPEL repo on my new server to obtain a couple of required packages like php-mailparse, etc.
yum install epel-release

Will there be any problems if I have this repo on the list? I noticed that ClamAV was updated from this repo and shows as unknown under System Information > Programs

  1. Trying to familiarize myself from within Virtualmin I noticed GRUB boot loader under Unused Modules. This tells me that: The GRUB menu file /boot/grub/grub.conf was not found on your system. Maybe GRUB is not installed, or the module configuration is incorrect.

Is that normal? In CentOS 6 I could see the images.

Status: 
Active

Comments

Submitted by andreychek on Fri, 01/30/2015 - 20:16

Howdy -- we would advise being cautious working with third party repositories, as packages installed from them can conflict with existing packages on your server.

We would suggest only installing the packages you need from any third party repository.

Regarding the Webmin grub module --

Jamie may need to comment on that more, but it appears that it's designed to work with Grub 1.x, and not the 2.x version that comes with CentOS 7.

It looks like with a little bit of configuration, some people have gotten it to work, but before doing that on your production server I'd suggest seeing what Jamie's thought's on that are.

Jamie, can Webmin's Grub module work with Grub 2 in CentOS 7?

Submitted by JamieCameron on Fri, 01/30/2015 - 22:23

No, the GRUB module doesn't support GRUB 2. Now that most distributions auto-generate the GRUB configs, it is not really needed anymore.

Joe's picture
Submitted by Joe on Sat, 01/31/2015 - 19:36 Pro Licensee

For what it's worth, if you're going to use a third party repo, EPEL is the one to choose. It's where most of our packages that aren't in core CentOS come from. Though in the case of ClamAV their packages are kinda broken by design, and I changed them a bit. That may or may not cause brokenness if they are replaced by the EPEL packages (I don' t remember everything I changed or how we interact with the package in Virtualmin).

I always recommend proceeding with caution when introducing huge new piles of packages to a system, but at least EPEL is mostly reliable (with the exception of the stupid ClamAV packages, specifically, the clamav-server-systemd, clamav-scanner-systemd and clamav-scanner packages, which are just idiotically broken. I filed tickets, but never got a response, so we packaged our own to fix the worst of the stupid.

Submitted by cyrus on Sat, 01/31/2015 - 23:22 Pro Licensee

I did 'enable=0' the EPEL repo after I noticed an update from there for ClamAV that I accepted and then realised that I should have waited for Virtualmin updates specifically for that package as I saw errors in the logs and the Clam server didn't restart, I think. I removed Clam and the other associated packages and noticed that I had to remove virualmin-base as well. After 'yum clean all' without the EPEL repo I installed Clam again with virtualmin-base. I wish that they could be some way to ensure that packages installed from the Virtualmin or CentOS repo don't get updated by another.

Thanks for your information on EPEL packages in relation to Virtualmin. Now I have to figure how to detect what I had originally installed from EPEL with dependencies to ensure that I keep those packages periodically upto date.

On a side note, I have noticed a rant and a rave in the forum but from my part, as an individual who has used Virtualmin for quite a few years now I'd like to say that the three of you are providing a fantastic service that bigger companies would not be able to do. That personal service has been absolutely outstanding. 'andreychek' has always been on hand to sort out any Virtualmin related issues and more. This has been evident for me when I upgraded to CentOS 7 with a fresh install.

Couldn't do without your panel and more importantly that individualized personal service. Thank you.

Joe's picture
Submitted by Joe on Sun, 02/01/2015 - 02:55 Pro Licensee

Instead of disabling it entirely, just use the includepkgs/exclude feature in yum repo config file to either include only the packages you need, or exclude the packages we provide. That way you can continue to update packages from EPEL without accidentally replacing the ones you want to keep from us (or other sources).

It is possible for us to make packages that can't be overwritten without extreme measures, but it requires the rather heavy handed use of Epoch, which I hate to do (we use it for the Apache httpd packages, but that's because it really can't be allowed to be replaced with non-Virtualmin packages, or all web applications on a system would break). I opt not to do that for anything that isn't a case of it being absolutely vital that it be our packages.

Submitted by cruiskeen on Wed, 02/04/2015 - 15:12

Or use yum priorities and make sure the priorities are in the order you want - in this case making sure that EPEL is a lower priority than the virtualmin repos ---

Submitted by eddieb on Mon, 06/29/2015 - 15:50

So if I want to switch between one kernel and another as first option I have to manually edit the file? Which file do I edit?