Initial Release Of Virtualmin Pro

Hi Jeromy,

We've had no customers asking for slack, so far. I'm not opposed to it, as we hope to address as many platforms as is economically feasible. Slack doesn't have very good package management (ala yum/apt-get/up2date/urpmi) but we have to solve that problem for FreeBSD and Gentoo (which we have had some pretty vocal requests for) so there's no reason we can't solve it in the same way for Slackware.

I haven't actually solved the problem for FreeBSD or Gentoo, however, so it's hard to estimate exactly when Virtualmin Professional will be available on the non-package manager platforms.

There is a poll going on here:

http://www.virtualmin.com/vote

You can vote for what OS you'd most like to see Virtualmin Professional on. We are paying attention, and the results of the polls, plus the feedback we get from early adopters, will dictate where we go with the product.

In the short term, our OS support list, in order of appearence over the next few days/weeks, looks like this:

Fedora
RHEL/CentOS
SuSE
Mandriva
FreeBSD
Debian
Gentoo
Ubuntu
...whatever comes after...

I'd like to have all of these rolling out the door by the end of the month, though some of them might prove more difficult than I anticipate.

We will be focusing on the latest couple of releases of each OS, so that we don't have to commit to maintaining support for very old systems, especially since there are a few packages that we have to provide ourselves and can't be pulled directly frmo the vendor.

Hope this answers your questions.

I suppose I should also note that if you're bold enough, you can make Virtualmin run on any OS that Webmin supports. We'll help as best we can, and we'll integrate as much of what is learned during the process into our installer as possible. It is entirely possible that if you've got some experience with your OS' inner workings, and some virtual hosting experience, you can jumpstart the support for your OS. We aren't going to fight you if you try to run it somewhere we don't support yet.

Hi Brad,

Good question, and you're not the only one who's asked. ;-)

So, I'll go ahead and let the cat out of the bag. Pricing will be:

$149 10 domains 3 support incidents
$199 50 domains 3 support incidents
$399 250 domains 6 support incidents
$499 Unlimited domains 6 support incidents
$999 10+10 bundle ten ten domain packs with 3 support incidents per server

Support incidents can be purchased at $39 each, or in bundles. Bug reporting is always free, as are the resulting fixes (and if a support incident turns out to be a bug, it doesn't count against your total).

Annual renewals (which includes updates to the latest version of everything, so it comparable to upgrade pricing) will be roughly half of purchase price.

Early adopters, or those who purchase during the first month or so, will get a significant discount off of the initial purchase price, as we know there are going to be bugs and problems as the product gets installed on a wide variety of operating systems in a wide variety of environments.

In other, related, news I have just tried out the early version of the registration manager that I'm having developed by a great OpenACS developer named Malte Sussdorff...It is coming along very nicely and I expect it to be completed by the weekend. Assuming I can wrap up the installers by then, we'll be taking orders by next week!

Hey James and all,

I never even thought of it, but monthly "leased" pricing does seem to be very popular. Our card processor supports recurring purchases...so I think we can do this. Not immediately--the shopping cart doesn't support it at the moment--but in a couple of weeks I ought to be able to figure something out.

Excellent idea. Thanks for bringing it to my attention.

Hi Glen,

The installer is ready for Early Adopter release for Fedora Core 3 and 4 and CentOS/RHEL 3 and 4. I am working with the OpenACS developer to get the final bugs worked out of the software registration system...and I expect to begin selling sometime tomorrow.

There will be a few bits and pieces of the system that aren't in yet but will be in the official release (specifically, SuExec FastCGI and PHP4/PHP5 configurable on a per-domain and per-script basis, scponly and possibly another restricted shell), but otherwise everything is working great and makes for a thoroughly useful system.

In short, if it isn't available for purchase tomorrow, I will make elaborate excuses for why it isn't. ;-)

Hi James,

The same script will install for all supported systems. Right now, it supports Fedora and RHEL/CentOS. The OS is detected very early in the script so that the right stuff can happen later on. The shopping cart will ask you what OS you're using it on, because we want that data so we can decide where our efforts are most useful for customers, but the same script will run on any OS. It just needs a reasonable shell to run in, a download program (either wget or curl), Perl, and the package manager of the OS.

The script makes use of the system standard package manager when possible, so everything is installed from RPMs using up2date and yum on Red Hat based systems. On FreeBSD ports will be used for everything except for our components, which will be installed from tarballs. On Gentoo we will use Portage and install local ebuild scripts for our components. And on Debian apt-get will be used for most everything. This is one of the reasons things are taking a bit of time to get rolling--but in the long run it will allow us to provide more timely updates and track the latest versions of the OS more closely. We know that a very common complaint about many of the other proprietary virtual host administration systems is that they trail so far behind the latest releases of operating systems. I don't want that to be a problem for our customers.

Hi Ken,

James has answered pretty thoroughly, but I'll weigh in with an official response.

The installer does the following:

Installs all necessary components (web, mail, name, databases, spam/av, Webalizer/AWstats, Mailman, Webmin/Usermin/Virtualmin, etc.)

Configures quotas and all services for use in a virtual hosting environment

Starts all necessary services

Sets up Virtualmin to work specifically with all of the components we just installed (as you may know, Virtualmin is extremely flexible, and can be used with many different components--Sendmail or QMail instead of Postfix, for example)

Bandwith monitoring is not enabled by default, but it can be enabled easily in the GUI after installation.

Remote storage of account information is not supported, though we're adding LDAP mailbox users in a not too distant version. Also, there is a pretty comprehensive Perl API, which can be accessed from any Webmin server using the RPC API (i.e. you can do it from a remote server). So far, no one has implemented anything making use of this.

There will be a time-limited demo version.

On the reporting question...The following is supported:
[list]

[*]Webalizer[/*]

[*]AWStats[/*]

[*]Bandwidth monitoring with email alerts on overage (and optionally when approaching overage)[/*]

[*]System and Server Status monitors, which has dozens of types of checks, with emailed alerts on service failure[/*]

[*]Quota overage email notification and optional approaching overage email notification[/*]

[/list]

As for RPMs installed, mails blocked, ssh failed logins, etc., on a Red Hat based system, this is already handled by logwatch (assuming you have it enabled). No reason for us to reinvent the wheel. Now that you mention it, however, we may very well add a plugin module for some mail log analysis tool. And it might be useful for us to help you make sure you get those log reports from logwatch and cron, by insuring that your root alias points to some mailbox that is read by a human.

In short, I think reporting is pretty good, but it doesn't answer all of your wishes.

Hey Glen,

Elaborate Excuse #13: Aliens
Elaborate Excuse #79: Corporate Espionage
Elaborate Excuse #101: A dingo ate it
Elaborate Excuse #231: Michael Jackson

Real Excuse #1: It isn't ready yet. I simply can't bring myself to release it when I <i>know</i> the installer is going to fail in some way on one of the first round of supported Operating Systems. I suppose this also indicates that I'm not willing to drop any of the first round of supported systems (FC3/4, CentOS3/4, RHEL3/4). The list of supported systems is short enough without dropping one or more of them just to get it out the door a day sooner!

The good news is that none of the problems are huge, and I keep thinking the one I'm working on right now will be the last one (but that's been my thought for several days now).

I'd like to tell you that it will be released today, but no one will believe me at this point. So let's just say I'm doing an all-platform test, as we speak. If it passes, it goes out today.

To get specific:

The current problem is that the Mailman module is configured with the wrong paths, and so the Virtualmin Configuration check fails. A minor thing, but the real fix has to happen in both Webmin and in the Virtualmin Mailman module. Jamie has sent me the fixed Mailman module, but the new devel Webmin version isn't ready yet. I'm working around the problem in the installation script, I think...I'll find out if my workaround actually works around in just a few minutes.

Hey Glen,

Thanks a lot! Be sure to let us know of any problems or questions you have. We're shooting for perfection by October 11th. ;-)

Howdy,

Nope, there's no additional charges... it's just the flat rate for Virtualmin Pro (unlimited), and there's a lower rate for all subsequent renewals.

Also, you're welcome to try it for 45 days -- if it doesn't do what you need, just file a Support request and you can receive a refund.

You can see some details regarding Virtualmin features here:

https://www.virtualmin.com/compare.html

If you have additional questions, we'd be happy to answer them -- but you may want to start a new Forum post, this one is 8 years old :-)

Thanks!

-Eric