Howdy all,
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:
CentOS/RHEL/Fedora:
[code:1] rpm -e virtualmin-base yum install virtualmin-base [/code:1]
Debian/Ubuntu:
[code:1] dpkg -r virtualmin-base apt-get install virtualmin-base [/code:1]
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.
THIS SUCKED !!!
webmin completely killed VM2 and VM pro and all my themes and modules...... I am not happy
Hey Scott,
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).
--
Check out the forum guidelines!
all i did was install the update and when it was done all i had left was standard webmin install
i wasn't happy
What update are you talking about?
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!?
--
Check out the forum guidelines!
"as the post installation script (the only thing contained in virtualmin-base) never runs when upgrading the package--only when doing a fresh install"
THIS IS NOT TRUE!
Frankly I am less then impressed with the new webmin.
<div class='quote'>Frankly I am less then impressed with the new webmin. </div>
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?
--
Check out the forum guidelines!
Updating webmin does NOT transfer ANY modules from the old version to the new version. What you get is a fresh install of webmin.
<div class='quote'>Updating webmin does NOT transfer ANY modules from the old version to the new version. What you get is a fresh install of webmin.</div>
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)?
--
Check out the forum guidelines!
It didn't matter how it was installed.
I used tarballs, rpms and debs and they all did the same thing.
<div class='quote'>It didn't matter how it was installed.
I used tarballs, rpms and debs and they all did the same thing.</div>
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.
--
Check out the forum guidelines!
See http://www.virtualmin.com/forums/webmin/re%3awebmin-1.401-breaks-and-del...
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. :-)
thanks sgrayban but i have other issus after that.
i made a post in the general section for all of my problem.
Link please... I don't see any post made by you there. I guess I am looking in the wrong place.
Sorry i wrote here before i made my topic
there is the link
<a href='http://www.virtualmin.com/forums/general-discussion/debian-4-etch-instal... target='_blank'>http://www.virtualmin.com/forums/general-discussion/debian-4-etch-instal...
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).
You need to run:
dpkg -e virtualmin-base
apt-get install virtualmin-base
Running install.sh again will not do anything useful (and will actually break stuff).
--
Check out the forum guidelines!
Hi i think i have a problem with the new installer or i did something wrong
i have a debian 4.0 64bits newly instaled and updated
after that i get the srcipt and install it
[code:1]wget http://software.virtualmin.com/glp/scripts/install.sh
chmod +x install.sh
./install.sh[/code:1]
at the end i get an INFO - SUCCED
and when i connect to my server and i use the check function i get
[code:1] BIND DNS server is installed, and the system is configured to use it.
A problem was found with your Postfix virtual maps : No map sources were found in the Postfix configuration
.. your system is not ready for use by Virtualmin.
[/code:1]
after that i get an error with appache and suexec
Configure postfix -- you haven't done that yet.
You are missing...
virtual_mailbox_maps = hash:/etc/postfix/mailboxes
virtual_alias_maps = hash:/etc/postfix/aliases