Wbm-virtual-server fails to update

I am running Virtualmin GPL since many years. Recently there was another update. The updates

—> Package usermin.noarch 0:1.834-1 will be updated
—> Package usermin.noarch 0:1.840-1 will be an update
—> Package wbm-virtualmin-awstats.noarch 2:5.11-1 will be updated
—> Package wbm-virtualmin-awstats.noarch 2:6.0-1 will be an update
—> Package wbm-virtualmin-htpasswd.noarch 2:3.0-1 will be updated
—> Package wbm-virtualmin-htpasswd.noarch 2:3.1-1 will be an update
—> Package webmin.noarch 0:1.990-1 will be updated
—> Package webmin.noarch 0:1.991-1 will be an update

installed without any problems, as maybe 100 updates before.

But not

wbm-virtual-server Webmin module Virtualmin Virtual Servers 7.0.gpl-5

It throws many errors:

Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
Resolving Dependencies
→ Running transaction check
—> Package wbm-virtual-server.noarch 3:6.17.gpl-3 will be updated
—> Package wbm-virtual-server.noarch 3:7.0.gpl-5 will be an update
→ Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package               Arch      Version          Repository               Size
================================================================================
Updating:
 wbm-virtual-server    noarch    3:7.0.gpl-5      virtualmin-universal     22 M

Transaction Summary
================================================================================
Upgrade       1 Package(s)

Total size: 22 M
Downloading Packages:
Running rpm_check_debug
Running Transaction Test


Transaction Check Error:
  file /usr/libexec/webmin/virtual-server/CHANGELOG from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/backup-domain.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/backup.cgi from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/backup.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/backups-lib.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/bw.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch

  file /usr/libexec/webmin/virtual-server/virtualmin-licence.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/vui-lib.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/webmin_menu.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/wizard-lib.pl from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch
  file /usr/libexec/webmin/virtual-server/wizard.cgi from install of wbm-virtual-server-3:7.0.gpl-5.noarch conflicts with file from package wbm-virtual-server-3:6.17.gpl-3.noarch

Error Summary
-------------

.. install failed!

Does anyone have an idea what could have caused this problem?

Same issue here with conflicts when attempting to update from wbm-virtual-server-3:6.17.gpl-3.noarch to wbm-virtual-server-3:7.0.gpl-5.noarch.

Full list of errors is here for reference:

Does anyone know how we should resolve this?

Both @cmaxwell and @fut08-15

Please take a look here first . :wink:

Forum Guidelines: Please read before posting! - Help! (Home for newbies) - Virtualmin Community

Please always include your OS/version.

I don’t know. I can’t think of any reason why RPM would consider this a different package rather than upgrade.

Which Virtualmin repos are you using? (in /etc/yum.repos.d/virtualmin.repo)

I’ll have to try to reproduce the problem…my systems all upgraded correctly, so I need to figure out what’s different about yours.

Thanks for your reply.

In our case the OS is CentOS 6.10. Yes, we know it’s no longer maintained - it’s an internal non-production server. Contents of /etc/yum.repos.d/virtualmin.repo:

[virtualmin]
name=RHEL/CentOS/Scientific $releasever - $basearch - Virtualmin
baseurl=http://SERIALNUMBER:LICENSEKEY@software.virtualmin.com/gpl/rhel/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

[virtualmin-universal]
name=Virtualmin Distribution Neutral Packages
baseurl=http://SERIALNUMBER:LICENSEKEY@software.virtualmin.com/gpl/universal/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

I don’t have any CentOS 6 systems to test on (and we can’t support EOL systems in the general case and CentOS 6 is well past EOL).

Unless this is happening on newer RPM-based systems I have to chalk it up to being an incompatibility in the version of rpmbuild we’re now using (build system is now CentOS 8) with old RPM versions.

Since I can’t change that easily and since anyone using an OS that hasn’t been updated in a year and a half can’t possibly care much about use new software, I have to just say you’re stuck with 6.17. There are no known security issues, you just won’t get new features. I’m disabling the old repos once Virtualmin 7 goes live, anyway, so you were losing updates probably this weekend anyway.

You could also try to download the package and use the --force option to upgrade/install. That might work, or might blow up your server, I have no idea.

1 Like

|Operating system |CentOS Linux 6.10|
|Webmin version |1.991|
|Usermin version |1.840|
|Virtualmin version |6.17 |
|Authentic theme version |19.91.2 |

here. Same as cmaxwell, highly customized internal system, running for many years.
Without any faults so far, in daily use, hence reluctant to upgrade.

Then don’t. :wink:

Virtualmin can stay at 6.17-3 for as long as you want. (It’s the least of your potential risks from running an EOL OS.)

Hi Joe

thanks for all your support.

You surely know the thing, never change a running system, especially if it is an internal one, in every day use. I think I can live without updates and will deactivate the VM repo. It all worked flawless for the past years and I think it will continue to do exactly that for a while.

Our other server (exposed to the real world) runs Centos 7 and it did this update without any probs.

1 Like

Never is wrong here :wink:
Take care to plan new, upgrade or fase out if possible.
I know you need then much more updated/ upgraded mostly, but old APPS Software are at some point not supported anymore, you have to react to this intime then also if local use.

The only local use i know you can stay on old, is where you have a situation only for that specific use case, and it really never has to change itself.

Just wanted to say I get the same issue. Moving it all to a new server would take me weeks of no pay so its not something we can do. We just use these sites for old systems that would not work on newer PHP anyway. As customers have new websites/apps developed then they slowly move to new servers, but that will take years.

So is the only option disable the repo, so we dont get any more webmin updates? It worked in the past.

Thanks

I expect then the server goes down by hack, or virtual servers. Sorry but Production on very old longer EOL makes no sense.

Ok for PHP 5.6x Remi is doing a good job and some others are doing backport security updates for that php version.

But then still if Custommer Aplications has security bugs in those older versions the problem stay.

Sometimes if all is connected to kind of backoffice and API’s yes i understand, what todo is lot off extra work al the time for those to old APPS, for security BUGS / CVE and find workarrounds ASAP if there is one detected known new BUG.

Mostly a workarround then needed for some import export, api, connectors, forms, login… you can secure them extra by IP adress and php access and changing filenames and paths then.

I do that then, acces only from IP… and change file extension name and path, sofar as possible.
While all known aplications with BUGS the scammers are scanning with BOTS. There is then such a workarround a short time solution.

If they don’t do active checks on security bugs your custommers on their to old APPS, please take care of responsible for backups restore and damaged data for those and other custommers in the contracts!