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.
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?
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:
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.
|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.
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.
Never is wrong here
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.
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!
