Hey Faisal,
Ok, I’ve been able to reproduce this–my earlier tests weren’t catching the problem as I was only uninstalling the Virtualmin packages (and not all of the other stuff). A fresh install revealed that in the new virtualmin-base package I had removed several deps without adding them to the install script, so they never got installed, and then the postinstall script in virtualmin-base crapped out before finishing in addition to some stuff not getting installed. So, in short, everything went pear-shaped due to a few missing dependencies.
The following instructions also apply to anyone else who has run into this issue–the offending virtualmin-base package went up about 36 hours ago, so any installs during that time are probably broken in many ways, so reinstalling is a great idea if you haven’t begun adding domains yet–if you have, let me know and I’ll assist you with resolving all of the issues…I have a standalone script that can fix most problems without a lot of hassle.
The old installation script (install.sh) is also broken, and you’ll need to download the newest one from http://www.virtualmin.com/serial . This makes me realize I need to figure out a way to automatically update to the latest version of the install script…
First, run the uninstallation script so we’re starting fresh. You can get it here:
http://software.virtualmin.com/lib/virtualmin-uninstall.sh
This will remove all of our packages and flush the yum header and package caches.
Next up, just run the new install:
./install.sh
This time it should all Just Work, and if it doesn’t I, of course, want to know about it.
Oh, yeah, I’ve also uploaded an scponly package into the repository and added it to the deps list so it gets installed during the installation process. It also gets added to the /etc/shells file, so you can access it from the dropdowns. It’s not chroot-enabled yet, but it is still a very nice restricted shell. chrooted scponly will come in EA2 or EA3, or as soon as I figure out how to package it and make it work seamlessly, just like any other shell.
I have tested this pretty thoroughly on Fedora Core 4. I am now booting up my Xen kernel so I can test it on CentOS3/4 and FC3. RHEL3/4 will have to wait until I’m back in the office, as I have to set the BIOS in one of my servers to re-install (it’s got SUSE on it now). If you’ve been burned often enough by my shoddily tested installer, you can wait an hour or two and it will be extremely well-tested and ready for mainstream consumption.
Apologies for the rough early experience with the installer…I’ve been so focused on issues with SUSE that I didn’t even notice that the changes I was making might break installation on the already supported systems. Gotta get a better test procedure in place for the installer script and file…