I think we’re ready to unleash the alpha version of Virtualmin 6 for adventurous testers. I am not gonna roll it into the existing repositories until we’ve had a few people bang on it in non-critical situations, because it is the biggest release of Virtualmin since 5.0 about 18 months ago. There are huge new features in this release, and a lot of surface area for bugs, so we want to roll it out in stages.
Some new stuff in Virtualmin 6 (there will be a full “what’s new” post in a couple of days, when it rolls out for broad usage):
Jailkit support for user jails. All of my major concerns about chroot jail security risks have been resolved over the past couple of years, so I didn’t have any good reasons to argue against including them. So, VM6 has a user jail feature, and we provide Jailkit packages for our supported distros (and they’re built with all of the latest security features, including using kernel capabilities instead of being suid root).
Tons of new UI features and enhancements. If you’re tracking Authentic theme development and updating regularly, you’ve already seen this. There’s a couple of other things in the pipeline that didn’t quite make this release but might be usable by the time we call 6 stable.
Many performance improvements in the UI. The biggest improvement is still in development, but will come sometime during the 6 release cycle…maybe weeks away.
Wholly rebuilt installer and install configuration system. My time for the past several months has been dedicated to making the install more reliable, easier to extend, and easier to customize. There’s a new micro configuration management system called virtualmin-config that allows all of the install configuration steps to be called independently (they used to all be bundled into the virtualmin-base package and could only be run or not run…no fine-grained control). It also allows for custom “bundles” of packages and configuration. Currently there is just the LAMP bundle, which is very similar to what virtualmin-base configured in the past; but in a few days I’ll wrap up the finishing touches on a LEMP (with nginx instead of Apache) stack, too.
Conversion of our dependency management to yum groups on RHEL/CentOS/Fedora, and metapackages on Debian/Ubuntu. Again, this makes it easier to maintain the installer across all of our supported distros, and supports the ability to install custom bundles of packages, and allows bigger or smaller installations (e.g. including or excluding some optional packages).
The usual pile of bugfixes, enhancements, and Install Script updates.
Inclusion of the WordPress Install Script in the Virtualmin GPL package. As WordPress is the most popular Install Script, by far, we wanted to make it more widely available. Hopefully that won’t hurt our sales (y’all, please, buy some Virtualmin Pro, so we can keep giving away more with each major release!).
So, if your interest is piqued and you want to try it out, go here and read the “Pre-release Virtualmin 6” installation instructions:
If you want a smooth experience or don’t want to setup a new system to test on, wait a couple of days while we iron out the bugs and we’ll add Virtualmin 6 to the existing repositories and provide some automated tools to switch to the new VM6 repositories (which will have a variety of new packages, and is the only place Virtualmin Config will appear).
I’ve been up way too many hours, so I’m about to crash for a good nine hours or so…I’m hoping everything is in a reasonably functional state. My last installs on CentOS, Debian, and Ubuntu were successful (with some minor quirks), so, I think it should be usefully testable for adventurous types. But, if it breaks, you get to keep both pieces. If you come into it expecting things to be messy, you won’t be disappointed!
I would like to see the ability for better per-host config for nginx on CentOS, and ability to modify nginx templates, so permalinks and an include to a /home/user/public_html/nginx.conf file can be used. I’ve been testing Virtualmin LEMP on CentOS 7, and it somewhat works, but I can’t figure out how to modify the template, or where to add permalinks rewriting to the host nginx configuration using the GUI… So I have been modding the main nginx config. I really prefer the way it’s done in Ubuntu, with per-host /sites-enabled/ conf files.
It is possible to switch configuration to per-host configuration files, at least for Apache. I haven’t spent enough time with the nginx module to know…but, if it’s supported on Ubuntu/Debian, it’s probably in there for nginx, too. It may not be as well-exposed as it ought to be, though.
Have you filed tickets about these feature requests? Sometimes if Jamie sees things like this he just quietly implements them the next time he’s coding. Especially for easy stuff like the per-host config files thing (the code already exists, if it works that way on Ubuntu, so it’s just a matter of adding UI, if it’s not already in there). Server templates additions for nginx are also probably pretty easy, though I’ll have to defer to Jamie on whether it gets implemented, at least in the short term (my plate is super full for the next couple of weeks, while we roll out all the new VM6 stuff).
Anyway, I’ll be working on the LEMP stack bundle for the virtualmin-config tool in a day or two, and will get some more familiarity with the nginx support (I’ve played with it when it was new, but I use Apache on all of our servers, so my experience is limited).
I’m confused. It sounds like that’s been implemented. Is it possible you’ve got a third party nginx module there, instead of the one we provide? (There is, I believe, a third party nginx plugin out there somewhere, but I haven’t looked at it.)
I believe that error indicates your server isn’t responding correctly when the LE server tries to validate that you own the domain (e.g.
DNS isn’t resolving to the server in question).
This probably isn’t a problem with Let’s Encrypt (or Virtualmin’s support of it). It probably indicates another problem. Make sure DNS resolves to this domain, make sure the server is actually serving the right domain when you access it in a browser. It’s probably one of those two. Could also be access rules or redirects in Apache, as well, but if it’s a fresh domain, accessing .well-known should be allowed.