Virtualmin 7.20.2 missing from older virtualmin-6 repo

on my older RedHat7 test system, I see its using the newer repo

Index of /vm/7/gpl/rpm/noarch

but on my newer production RedHat8 system, for some reason I still have the older repo

Index of /vm/6/gpl/universal

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 :smile:

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’

run virtualmin setup-repos to fix repos.

@staff – thoughts?

Yes, run the following command to fix the repositories:

wget https://raw.githubusercontent.com/virtualmin/virtualmin-install/refs/heads/master/virtualmin-install.sh
sh virtualmin-install.sh --setup

Please note that we don’t provide custom Apache builds in the new repositories.

Consider upgrading to Alma or Rocky 9, as CentOS 7 has reached end-of-life a long time ago.

perhaps I was not clear in my actual question/concern — is the “6” repo intentionally out of date?

and/or — this is the first step towards the retirement of “6” :smile:

I would think that is the case, upgrade to the version 7 repros as suggested

6 is dead :slight_smile:

Yes, it is, and Joe had mentioned it before.

I am inquiring not about Centos6, but the virtualmin repo “6” :smile:

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 :smile: — as all four cmds return RPM files (two from the old 6 repo and the same two from the newer 7 repo):

wget https://software.virtualmin.com/vm/6/gpl/universal/wbm-virtual-server-7.20.1.gpl-1.noarch.rpm
wget https://software.virtualmin.com/vm/6/gpl/universal/wbm-virtual-server-7.20.2.gpl-1.noarch.rpm
wget https://software.virtualmin.com/vm/7/gpl/rpm/noarch/wbm-virtual-server-7.20.1.gpl-1.noarch.rpm
wget https://software.virtualmin.com/vm/7/gpl/rpm/noarch/wbm-virtual-server-7.20.2.gpl-1.noarch.rpm

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

Yes, I realized that later after my initial reply and rereading this thread.

This must be possible and sounds great!

About notifications, it was mentioned several times!

@Joe, could you shed more light on this?

@verne Yet, I suggest you switch to the newer repositories using the command above.

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 :smile:

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.

1 Like

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 :smile:

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.

@Jamie, how about we address it (update Virtualmin repos using a new setup-repos sub-command) in the post-install, if old repos are found?

:smile: Though, I think it’s a bit too late to do that, as the key has already expired!

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.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.