A little over a month ago, for reasons that I suppose everyone knows, I decided to "test" Virtualmin as a replacement for cPanel. It wasn't so much the cPanel price increase as the way it was implemented that drove my decision. I lost faith in the company's ethics.
So I leased a server, installed a fresh CentOS 7 on it, updated it, and installed Virtualmin. I also created a dummy site on a domain that I registered because the name rolls off the tongue nicely. (Seriously.) I then moved a monetized (barely) site that I own over from the cPanel server. And then one by one, I migrated the rest of my personally-owned sites with the exception of two whose domains are hostnames for other servers; so now my Virtualmin "testing" server is in full-time revenue service and generating about a third of my income.
All in all, the process has been painless and the learning curve shallow. I've encountered several quirks, but only three that I can fairly call bugs, all of which have easy workarounds:
Sometimes, on a migrated site, Virtualmin creates a duplicate SPF entry. But only sometimes. When it happens, the solution is to delete the duplicate.
On sites with unusual DNS entries (for example, on one site that had sub.domain.tld pointed to a remote webcam's IP address), the unusual settings may not migrate with the site (using the same example, sub.domain.tld was pointed to the new server's shared IP rather than the webcam's IP). The solution is to copy the DNS before migrating and fix any incorrect entries.
In fairness, I've also had this happen when migrating sites from one cPanel server to another. In fact, I'd guesstimate that more than half of the cPanel -> cPanel migrations I've done over the past ~20 years have hosed DNS in some way or another -- and usually far more seriously than Virtualmin did.
Those are really the only quirks that I would rate serious enough to be called "bugs." So all in all, I'm overjoyed. I honestly expected a lot worse. I'd rate the cPanel -> Virtualmin as an "A" because the bugs were so few, so minor, and so easily fixed. Stomp them, and I'll make it an A+.
Now, as for quirks...
cPanel used non-standard paths to PHP (and pretty much everything else, truth be told). Most of these are brilliantly sorted out by the migration script. But PHP paths in cron jobs are not. They have to be fixed manually. I won't call that a "bug" because it's something where there are options involved, and I would rather make those decisions myself than have the machine guess at them. However, it would be nice if the migration routine notified the user that the paths are invalid when the cron jobs are imported.
On a freshly-migrated site, it's a good idea to have a cup of coffee between changing the nameservers at the registrar and requesting the SSL cert from Let's Encrypt. If it hasn't propagated yet, Let's Encrypt will reject the request. That's not a bug. It's really not even a quirk. Let's Encrypt waits until the change has been made at the registrar and has propagated at least as far as whatever DNS server they use. So give it 10 or 15 minutes. Too many failures in too short a time will put you in Let's Encrypt's penalty box for a while.
If you want to use KernelCare, you have to change the update setting in Webmin / Virtualmin to "Notify Only," then manually run all the updates except the kernel updates (for example, on CentOS, yum update --exclude=kernel*).
And that's about it. All in all, it's been a wonderfully painless experience. Knowing how many things cPanel does in, shall we say, "unorthodox" ways, it's actually very impressive how well Virtualmin sorts them out and how little manual post-migration tweaking is needed. I'm impressed.
Thanks so much for the great feedback!
Jamie has done a tremendous amount of work on making the cPanel migration as seamless as possible (really, it's a lot of code!), which is no small feat given the...um...creativity of how cPanel does things, compared to Virtualmin, which tries to stick to OS defaults as much as possible (with a few divergences to accommodate multi-tenant systems a little better). But, we're always trying to improve on it. We'll look into the cronjob PHP path issue, as it's come up a couple of times lately. I think we're a bit cautious about modifying cronjobs, for obvious reasons, but I think it's probably reasonable to correct PHP paths, because PHP definitely won't be where cPanel puts it.
I don't have any familiarity with KernelCare, but I assume it's a wrapper around kexec. I'll look into whether that's something we ought to consider adding awareness of. Mostly we want to do whatever we can to insure people are updating everything pretty regularly on their servers, and make it as painless as possible. It's such an important part of server security.
--
Check out the forum guidelines!
It's a beautiful piece of work, Joe. Jamie and the rest of the crew deserve knighthoods or something.
I've posted quite a bit on WHT to the effect that Virtualmin really deserves more attention as a cPanel replacement than it's been getting; but the objection there (as here) is that the interface is "too different" to keep some clients happy. I don't necessarily disagree: I have a few clients who downright hate it. But they're the same clients who hate when you change an icon design, a font, or the hover color of a link. They're the ones who are never happy. In other words, they're the ones who are the pains in my gluteus maximus. But they still pay the bills, so I can't just blow them off.
Most clients, however, don't give a rat's about the UX as long as they can access their mail and AWStats. They seem to especially like Roundcube, which was a bit of a surprise to me. Not that I have anything against Roundcube, mind you, but I had no idea how many clients use it. I suppose some of them would like Usermin just as much; but since giving them Roundcube, too, costs about a minute and zero $$, they can have it if they love it so much.
KernelCare is one of Igor Seletskiy's projects over at CloudLinux. It's basically a kernel live-patching system to avoid reboots. I use it pretty much routinely; but sometimes there's a lag of a few days between a kernel release and Igor's developing a live patch. That's why automatic kernel updates the "usual" way need to be disabled. It would defeat the purpose of using KernelCare.
By the way, in my previous posts, the forum software cut off the "*" at the ends of the kernel exclude codes that should be used if using KernelCare.
I suspect Igor would be happy to give you some licenses if you want to play around with KernelCare. Aside from the update changes, I don't know exactly what would be involved in "supporting" it. Maybe running a manual check as a cron job and a manual update if one is available; but the KernelCare install script sets those up anyway. There's not much to configure, so there's not much to "support" -- at least not as far as I can tell.
Another thing I've been thinking about is coding Backblaze support into the backup script. The problem is that my Perl skills are... Well, let's just say "less-than-wonderful" would be a compliment. It's no biggie for me because I can manually configure backups to Backblaze as a post-backup script in about three minutes (literally) using rclone in the shell. But I think having it in the GUI would be a nice selling point for Virtualmin. I'm not aware of any other panel that supports it. People have been asking for it at cPanel for several years, but as of the last time I checked, they still hadn't implemented it. (JetBackup might, however.)
The thing that makes Backblaze attractive is that both uploads and storage are dirt cheap, making longer retention affordable. That being said, I wouldn't recommend any cloud provider as a sole backup solution; but I'm a bit of a backup nut, so take that for what it's worth.
As for my own plans, I have a second server running Virtualmin (GPL for the time being) that I want to play with for a while. I want to become a bit more expert in it before I start moving clients onto it (at which time I'll upgrade the license). Or I may move everyone on yet another server currently running Cpanel back to the same server after wiping it and installing Virtualmin on a fresh CentOS. I haven't decided yet.
If I move them, they need to change the NS at the registries (which some clients find challenging, believe it or not). And then there will be those who have no idea what their passwords are, although I can just change them if I have to. Plus we have client-side caching and possible minor mail issues (people who used the hostname in their mail settings, having to accept a new cert, possible SPF issues, etc.).
On the other hand, if I wipe the server and migrate them back onto it, we have downtime. So I have to ponder it some more.
I also have another server than a client owns but that I manage. He pays the full cost for the server and licenses, so ultimately it will be his decision what panel he wants to use. I plan to recommend Virtualmin. But I do have some concerns about some non-standard things that I did on his site because of the peculiar way the site grew over the years (and because of some underlying non-standard things that I inherited from the previous maintainer). I'll have to clean those things up before migrating, if that's what the client decides to do. I'm pretty sure they would confuse the migration script if I didn't clean them up first.
Two things, however, are certain: Firstly, I am no longer providing nor supporting cPanel for new clients. If existing clients insist on it, they'll also be paying for it. Secondly, any new sites that I build for myself will be on a server running Virtualmin. cPanel is a dead man walking as far as I'm concerned.
--Richard