This is the worse webmin release ever.
Out of 7 clients I have each of them have all lost VM Pro features/addons/modules.
On my own box it completely deleted VM2 and VM Pro.
I had to reinstall VM Pro on all my clients boxes including mine plus re-download every friggin plugin.
Frankly I am less then impressed with webmin at this point and I advise anyone that hasn’t updated to NOT update webmin at all until Jamie/Joe fix this problem.
What OS/version have you seen this behavior on? Were there any errors when updating Webmin?
It happened on…
debian 4.0
Ubuntu Linux 6.10
Mandriva 2007 and 2007.1
And the updates took place automatic so I have no clue if there were any errors but I have disabled all automatic updates from now on because of this.
Oh! So it might not be the Webmin update…it could be virtualmin-base? jezdez has reported the postinst running on upgrades (which shouldn’t happen, but if it does might cause the theme to be switched back to default, among other things). I’m trying to reproduce this behavior now.
If you’d like me to drop in on your box, I’d be happy to. I’d actually like to see what happened. This is clearly dramatic behavior…but I don’t see it on my boxes, and so I’m at a loss for how to fix it.
There was no changing of types of installs either – tar to rpm or tar to deb
These updates have been the same from day one – automatic and with no issues before until now.
What are you wanting to look at? I can’t give you access right now but I can paste what ever you need.
Doing a upgrade for webmin…
debian package
Setting up webmin (4.0.1) …
Error: Script was not run with full path (failed to find /usr/share/webmin/run-postinstalls.pl under /usr/share/webmin)
This was intentional to break the postinstall and to show you that it DOES run the postinstall even for a upgrade.
That’s supposed to happen, and should be harmless (actually it’s a positive thing, as it update stuff that has changed between versions). If it’s not harmless, we’d want to fix it. I’m testing on an already installed Debian system now to see if there are any issues with the new Webmin or virtualmin-base (I only tested fresh installs over the weekend, though Jamie upgraded all of his Debian and Ubuntu installs without any errors, as far as I know).
The post install script running problem I’m talking about would be with the postinst in the virtualmin-base Debian package. Wholly orthogonal to Webmin’s postinstalls scripts. The script I’m talking about is one triggered by Debian’s packaging systemm and included in the virtualmin-base deb. This postinstalls.pl is a standard Webmin thing that always gets run on updates–and has been so for many years.
All I know is that upgrading webmin to 4.0.1 is broken. It removes all VM Pro plus plugins and even the VM Pro theme.
I prevented one of my biggest customer from upgrading webmin for fear it will completely kill his users and accounts.
But I know for a fact when webmin upgrades no existing modules from the previous version was transfered.
In fact it deleted the old version on a tarball upgrade before it copied the existing modules.
This is a webmin bug clearly.
I know I’m going to sound stupid saying the same thing again…but I just don’t understand what’s happening on your sytsems. I just can’t reproduce this behavior, and nothing has changed in the Webmin upgrade process in several revisions.
1.400 had the referer lockdown that affected the install.sh installation process…and it also had a bug that made some BIND installations look like they weren’t running, when they actually were. The former was fixed by an update to virtualmin-base, while the latter was fixed by the release of 1.401. But nothing changed in the way Webmin is upgraded.
If, as jezdez indicated, the virtualmin-base postinst script is running under some circumstances on updates, then Debian and Ubuntu systems would possibly see some configuration breakage on installation of that package (which could make the theme switch back to the blue framed theme, but wouldn’t delete any modules or themes…just some configuration files might change). This wouldn’t effect tarball or RPM installed systems, at all (and couldn’t–tarball systems don’t have a virtualmin-base, and RPM uses a completely different test to determine if the package is being upgraded or installed fresh).
Of course, if the Webmin upgrade process is the culprit, then virtualmin-base is irrelevant, and I should stop worrying over it in this thread–that’s something I’ll have to work with jezdez to figure out. I just can’t think of how the Webmin upgrade would suddenly behave so differently on some subset of systems (the subset that is wholly contained by the subset that you manage). 
It’s not just mine system – it was all my clients that updated that were affected. The big client of mine I have prevented the upgrade of webmin until I see fit.
Upgrading webmin did NOT – I repeat DID NOT transfer any previous installed modules to the new version. I can’t make this any clearer.
this happened to me too! please HELP!!!
What happened to you, too? You need to tell us something about your system–this is not an issue I have ever seen with my own eyes, and I’ve never been able to reproduce it.
If I’m ever going to be able to do anything about this issue, I need to know:
What OS/version you are running
What version of Webmin you started with and what version you upgraded to
What kind of package you’re using (and whether you used the same package type for the original install and the upgrade)
Where the package came from (Webmin.com, Virtualmin.com, some OS repo)
Any errors you saw during the upgrade
Without all of that, I have no clue what happened, because I’ve never seen it myself.
Linda & Filip from Joyent will be in touch with you shortly. I have this web meeting open right now where I can share my desktop:
Please join my meeting at https://www1.gotomeeting.com/join/141901137
Call me if you need to at 1.817.312.8211 (please delete this # after you write it down"
Here are some screen shots: http://picasaweb.google.com/billyclark/WorkStuff
Even I fail to see what is broken.
You are using a theme that is NOT virtualmin aware. That has nothing to do with VM Pro missing.
If you click on System Information does your license show up?
Looks like there’s a bug in the upgrade from GPL to Pro process on Solaris. The theme should be “virtual-server-theme”, but it’s set to “blue-theme” here, which, if it isn’t actually available (I know Joyent use a custom minimized Webmin with all extraneous stuff removed) would lead to you seeing the ancient unthemed Webmin appearance, which I believe is what you’re seeing.
So, if you switch to the Virtualmin theme in Webmin:Webmin Configuration:Webmin Themes do things look normal again? If you don’t have that option in the themes page, maybe the new directory doesn’t contain all of the additional modules–this would be congruent with what Scott has reported, and I seem to recall he has at least some systems installed from tarball (I’ve never been able to replicate it with RPM or deb installed systems, but maybe the copy step is broken in tarb upgrades).
You can see whether you have the Virtualmin module and theme by looking in the currently running Webmin versions directory to see if a "virtual-server" and "virtual-server-theme" directory exist.
I’d be happy to drop in on your box and have a look to see what is actually going on. I’m having a hard time really grasping what’s going on.