These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Virtualmin update on the new forum.
This website is deprecated, and remains online only for historic access to old issues and docs for historic versions of Virtualmin. It has been unmaintained for several years, and should not be relied on for up-to-date information. Please visit www.virtualmin.com instead.
(I'm assuming we're talking about Virtualmin Professional, since GPL doesn't yet have any update repositories...though GPL will have them later this week for a couple of platforms.)
That's weird. The installation process should have set it up for you.
Any chance the "virtualmin-release" package was removed for some reason? That's the only thing I can think of that would lead to not having the virtualmin.repo file.
The repository path depends on your OS and the serial number and license key in the /etc/virtualmin-license file, so I can't just copy/paste an example here that would work for you. The easiest thing is probably to download the virtual-release-latest package from:
Use your serial number as the username and the license key as the password. Then install it.
Assuming you have an /etc/virtualmin-license file, this package will setup the repository for you and import the correct keys.
If you don't have an /etc/virtualmin-license file, something broke during install, and we'll need to fix it. In which case, we should probably take it over the a private issue and get me logged into your box for a look around.
Yes I am running the pro version and the license file. I installed it by selecting upgrade to pro from the GPL version I am not sure if that had anything to do with it.
The RPM installed the repository and I ran update. some files were updated from the virtualmin repositoyy but the version of virtualmin is still 3.41
The upgrade from GPL feature works a bit differently--at this point it uses its own repository of .wbm packages, so it is not the same as a system that starts off installed from install.sh (it's kind of dangerous to upgrade via install.sh on a production system, so we do things a bit more gently). yum isn't involved at all. This is kind of bug-like, but it seemed the lesser of two evils (where one option involved possibly breaking a production system...this one just misses a few of the niceties of a yum-installed box).
Anyway, the reason for there being no updates for you is that I forgot to add the .wbm repo update to my repo management scripts. My fault. It should be fixed now. (And module updates should show up in the Virtualmin package updates page, though our binary packages won't.)
If you'd like to convert to using all of our packages, including binaries like Apache and such, let me know. I'll try to come up with a script that can do it without danger to a production system.
If it works on your desktop, but not your server, it's possible a bad response got cached in the DNS. If it's your DNS server where it's cached, you may be able to resolve it by restarting BIND.
One of our DNS servers was down briefly a couple of days ago. It was out while I was upgrading BIND, and for a few hours after, as I didn't notice that Red Hat had politely destroyed our named.conf...same problem that effected quite a few Virtualmin users, but I'd been unable to reproduce it, until I upgraded our production boxes. It only affected one server, and I didn't actually notice any problems connecting, and nobody else reported any problems...but I suppose it's possible that a name server upstream from you cached a negative result and continues to serve that negative result--it shouldn't happen, as negative results are only safe to cache for a very short time (a few hours, tops, but most folks reckon a few minutes is a better choice).
Let me know if the problem persists for you, and I'll walk you through locating the bad data--you may need to notify the administrator of the offending machine.
Hey Bill,
(I'm assuming we're talking about Virtualmin Professional, since GPL doesn't yet have any update repositories...though GPL will have them later this week for a couple of platforms.)
That's weird. The installation process should have set it up for you.
Any chance the "virtualmin-release" package was removed for some reason? That's the only thing I can think of that would lead to not having the virtualmin.repo file.
The repository path depends on your OS and the serial number and license key in the /etc/virtualmin-license file, so I can't just copy/paste an example here that would work for you. The easiest thing is probably to download the virtual-release-latest package from:
http://software.virtualmin.com/centos/5/x86_64/virtualmin-release-latest...
Use your serial number as the username and the license key as the password. Then install it.
Assuming you have an /etc/virtualmin-license file, this package will setup the repository for you and import the correct keys.
If you don't have an /etc/virtualmin-license file, something broke during install, and we'll need to fix it. In which case, we should probably take it over the a private issue and get me logged into your box for a look around.
--
Check out the forum guidelines!
Yes I am running the pro version and the license file. I installed it by selecting upgrade to pro from the GPL version I am not sure if that had anything to do with it.
The RPM installed the repository and I ran update. some files were updated from the virtualmin repositoyy but the version of virtualmin is still 3.41
Hey Bill,
The upgrade from GPL feature works a bit differently--at this point it uses its own repository of .wbm packages, so it is not the same as a system that starts off installed from install.sh (it's kind of dangerous to upgrade via install.sh on a production system, so we do things a bit more gently). yum isn't involved at all. This is kind of bug-like, but it seemed the lesser of two evils (where one option involved possibly breaking a production system...this one just misses a few of the niceties of a yum-installed box).
Anyway, the reason for there being no updates for you is that I forgot to add the .wbm repo update to my repo management scripts. My fault. It should be fixed now. (And module updates should show up in the Virtualmin package updates page, though our binary packages won't.)
If you'd like to convert to using all of our packages, including binaries like Apache and such, let me know. I'll try to come up with a script that can do it without danger to a production system.
--
Check out the forum guidelines!
Mmm, it seems to work okay for me.
Are you able to go to this URL in your browser from your desktop:
http://software.virtualmin.com/gpl/
And if so, what about if you try it from a command line browser from your server, such as links or lynx:
links http://software.virtualmin.com/gpl/
If it works on your desktop, but not your server, it's possible a bad response got cached in the DNS. If it's your DNS server where it's cached, you may be able to resolve it by restarting BIND.
On CentOS, for example, you could run:
/etc/init.d/named restart
Um, I can see results of both of those links.
Failed to lookup IP address for software.virtualmin.com
from running version of virtual.min. On a Debian etch server.
Have restarted BIND.
Oh well never mind will try it again in a day or two, nothing spoiling.
One of our DNS servers was down briefly a couple of days ago. It was out while I was upgrading BIND, and for a few hours after, as I didn't notice that Red Hat had politely destroyed our named.conf...same problem that effected quite a few Virtualmin users, but I'd been unable to reproduce it, until I upgraded our production boxes. It only affected one server, and I didn't actually notice any problems connecting, and nobody else reported any problems...but I suppose it's possible that a name server upstream from you cached a negative result and continues to serve that negative result--it shouldn't happen, as negative results are only safe to cache for a very short time (a few hours, tops, but most folks reckon a few minutes is a better choice).
Let me know if the problem persists for you, and I'll walk you through locating the bad data--you may need to notify the administrator of the offending machine.
--
Check out the forum guidelines!
Thanks Joe, have re-tried and all ok now.
Must have been just a blip?