The new Webmin, and it’s tighter referer checking, has caused some issues with our automated installation process.
I’ve just rolled out new virtualmin-base packages for all supported platforms that corrects this issue. If you have been bitten by the issue during installation, you probably don’t have to start from scratch to get things spinning smoothly. I believe you can get a correctly configured system with the following steps:
I haven’t actually tested this very much, but I wanted to get the word out about the issue, since it can seem very frustrating to complete the installation and find a seemingly minimal system (all of the packages are correctly installed…but this doesn’t switch everything over to looking like Virtualmin and doesn’t configure all of the packages to work with Virtualmin, so it looks like it just installed Webmin and nothing else happened).
As always, file a ticket if you’re running into problems and we’ll help you get it straightened out.
I have no idea what you’re talking about. This post is about botched installations–e.g. fresh systems that never got off the ground. It has nothing to do with systems that are already successfully installed. It can only make things better on a broken installation (since the issue it’s meant to address is a failed installation).
Again, this thread is about a fresh installation. Updating virtualmin-base shouldn’t have any impact on your system at all, as the post installation script (the only thing contained in virtualmin-base) never runs when upgrading the package–only when doing a fresh install (which is what the steps above do).
You didn’t follow the above steps on a running Virtualmin system, did you!?
Frankly I am less then impressed with the new webmin.
I still have no idea what you’re talking about. What exactly are you seeing wrong with the new Webmin? (And why are we talking about it in a thread about virtualmin-base?)
I’m thoroughly confused…no one is telling me what they’re seeing that is so dramatic and terrible. Scott’s saying Webmin removed Virtualmin…but I don’t see any way it possible could. Perhaps it switched the theme to the default Webmin theme? Or are you saying the Virtualmin package is actually gone?
Updating webmin does NOT transfer ANY modules from the old version to the new version. What you get is a fresh install of webmin.
That would be a serious bug…but we haven’t seen it on any of our boxes, and this has been our most tested Webmin update in ages because of the stupid BIND issue and the new referer checking that broke the installer–we’ve upgraded and installed this webmin on a half dozen systems over the past few days.
What OS/version do you see this on? Did you upgrade from/to the same package type (e.g. RPM->RPM or deb->deb or tgz->tgz)?
I used tarballs, rpms and debs and they all did the same thing.
Were there any errors during the upgrade?
And, did you upgrade from/to the same package type? I wasn’t really asking which package type you tried. Switching back and forth between package types can cause failures of the type you describe…particularly going from a tgz to an RPM or deb, and that should never be done, as the RPM and deb package managers don’t know anything about tarball installations and so would ignore them and leave them hanging about in /usr/local or /opt or something but Webmin would restart with the fresh package in /usr/libexec or /usr/share that was installed by the package–this would make it look like everything extra was deleted, when in fact you’re just looking at a completely different Webmin installation (without any of the extra stuff).
But same-type upgrades should never cause problems, and in my tests they do not.
So, I’m guessing this was a move from a tarball to an RPM or deb? If so, all of your extra stuff should still exist in /usr/local/webmin-VERSION.
I don’t know if I’m at the right place, or if I should make a new topic, but I’ll start by posting here anyway.
But the (automatic) upgrade to Virtualmin 3.52 also crashed my Virtualmin GPL installation on a fully updated CentOS 5.0.
Installation must’ve went fine as my log only states this line:
Feb 23 04:36:43 qonstrukt Updated: wbm-virtual-server.noarch 3.52.gpl-2
But afterwards (2 days) later, I tried to login to Virtualmin, just to find out not only Virtualmin had stopped running, but so did ProFTPD, Postfix and Dovecot.
I think this is a serious issue which should be looked at.
It doesn’t seem any of my settings have been altered though, so no problems there.
Jayce, see the very first post in this thread. You have a botched install, exactly like the problem I was describing in the very first post. Ignore all of the other stuff in this thread, as it isn’t related to the install.sh or virtualmin-base issues (and I probably ought to move it to a new thread or something…but this forum kinda sucks and so I’d probably break something if I moved it).
