is it an oversight, or intentional that the current release wbm-virtual-server-7.20.2.gpl-1 is only on the “7” repo, with the “6” repo having the previous minor version of wbm-virtual-server-7.20.1.gpl-1 ?
I suppose this is a good reason for me to review all my servers to be sure, if appropriate, they are reconfigured to use the “7” repo
p.s. not sure how to, or if its good or bad, in my above quoted blocks, to show the https link instead of whats there now, aka the ‘page title’
I am inquiring not about Centos6, but the virtualmin repo “6”
if the 6 repo is really being frozen, I respectfully suggest some ideas for your consideration (note this frozen repo does contain 7.20.1) –
post an announcement in one or more forum categories about 6 being frozen and no longer receiving updated releases
if possible, write code into Virtualmin to check if 6 is in use and display a large warning, perhaps offering to do the repo update
place the retirement of 6 in the Virtualmin release notes
and I must apologize in advance if one or more of these actions has taken place and I missed it !!
[time passes]
OR — as I can use my browser and see both 7.20.1 and 7.20.2 in the ‘6’ repo, perhaps the metadata (?) simply has not been rebuilt — as all four cmds return RPM files (two from the old 6 repo and the same two from the newer 7 repo):
The date on the repodata folder for ‘6’ is 2024-07-15 while for ‘7’ that date is 2024-08-18 … note the date on the wbm-virtual-server-7.20.2.gpl-1.noarch.rpm file in both is 2024-07-25
I already covered it in the link you posted (a couple of comments up the thread). The vm6 repo key is expired. I’m not updating it any more, there’s no point. You can’t update from it without jumping through hoops.
Switching to the new repos continues to be the solution, there is no discussion to be had about it.
There are no distributions that ever used the rebuilt httpd package found in the vm6 repos that are still supported (as discussed in several other threads), so there can’t be any remaining reason to use the old repo. If you’re still on an EOL OS, you have bigger problems than updating Virtualmin.
so why is the 7.20.2 file present in the ‘6’ repo but not in its metadata ???
for some reason several of my RedHat8 production systems (all using php-fpm) are still using the ‘6’ repo … and things like yum list webmin and yum list wbm-virtual-server give results … but I forget what YUM actions make use of the repo key to locally see the expired key issue.
someone on staff put 7.20.2 in both the ‘7’ and ‘6’ repos, but simply forgot (in my opinion) to rebuild the metadata
Yes I can upgrade to using the ‘7’ repo with very little effort, but wanted to bring this issue to light – that is, the stale repodata/metadata on the repo itself.
Because the signing key is expired, and aptly won’t generate metadata for it. I don’t know what else you want me to say. The vm 6 repo will never be updated.
If you don’t want to use the new repo, you won’t get new versions of Virtualmin packages.
“Someone” is me. It’s a script. The script copied the file in automatically. But, aptly rightly would not sign the repo with an expired key.
This is not a mystery. The key is expired. There is no reason to use the old repo; there are no supported operating systems that need the rebuilt httpd package, so there is nothing in the vm6 repo that anyone could need.
ok ok ok — I will update my systems to the ‘7’ repo !!
I hope you collectively will find a way to shed more light on the fact the ‘6’ repo basically will never be updated again – that is, the metadata will never be updated rendering it frozen if not thought of (now) as broken.
I would assume tracking any connections/usage of the ‘6’ repo is a huge job, if not impossible — to then somehow notify those users/systems they are (trying to) use a retired repo.
the next big question would be — how long will you keep the ‘6’ repo online in its frozen state — is it better to have some kind of access to whatever modules (versions) are there now VS having it offline/deleted?
While I do recall various posts over the last few years about the ‘7’ repo being current and the best/only one to use, I don’t recall (I could have a bad memory) anything alerting me to any actual danger to still using ‘6’ – naturally not being able to see and download recent packages (like 7.20.2) would be a danger
and out of curiosity, as the July 15th date on the ‘6’ metadata suggests the key was working then, when did the key actually expire?
I could be thinking way too much of myself (being good at my job, etc), but as I have come across this issue, I worry that others will too — with the key expired and it being frozen, how can the need to migrate to the ‘7’ repo be better publicized ?
and THANK YOU all collectively for your reasoned and professional responses … this possibly is my last post on this topic.
No! This should not be done as part of a package unrelated to repos.
There’s a virtualmin-release package on RPM-based distros, that includes keys and repo paths. I don’t know exactly how it’s supposed to be handled on deb-based systems. But, it’s definitely wrong to make postinstall do package repo changes. Our postinstall in the Virtualmin package already does too much for comfort. Packages should be predictable and minimize side effects.