Virtualmin 6 beta available for testing

The installation still wants to run on a freshly installed OS; which, if it's CentOS 7, is gonna have firewalld after install (unless you do a minimal install of the OS).

But, nothing else would change...you'd just configure it to not start firewalld and start iptables instead and remove the fail2ban-firewalld package, if you want to use fail2ban with iptables. So, you'd do the same things you'd do without Virtualmin on the system, but you'd do it after Virtualmin is installed. You could use the virtualmin config-system --include firewall command to setup the iptables firewall once you've disabled firewalld and turned it off.

The other option would be a semi-automated install, which is a (mostly untested and undocumented) feature of the new installer. You can pick and choose what bits of the install process you want to use.

We're not forcing you to use any feature. But, a firewall was a very frequently requested feature, so we did a bunch fo research, testing, etc. and settled on firewalld as the best compromise of features, compatibility across our supported distros, existing Webmin support, popularity, etc. But, we don't care what firewall you use. The Webmin module for iptables will stick around indefinitely (until a few years after nftables comes along and replaces it in common usage).

If firewalld is available, that's what the installer sets up. We're not really making a recommendation; you can use whatever you like. But, the default will be to install firewalld, configure it to be mostly closed by default, and to open up the ports Virtualmin and the services it manages need. It's in there because people wanted a firewall. Firewalld was a good balance of features, ease of use (kinda), good Webmin support (again, kinda, but we're improving it for VM6), good support in fail2ban, and it has the bonus of being kinda future-proof, as the filter backend can evolve to suit whatever kernel it runs on.

Fail2ban is orthogonal to the firewall. It gets setup regardless of whether your system has iptables or firewalld. Fail2ban isn't a firewall, it's a log analysis tool that adds firewall rules (or performs other actions) based on log activity. It can work with firewalld or iptables.

This works for reporting problems. Ticket tracker works too.

Can you post the last few lines of /root/virtualmin-install.log? I'd like to know what packages are failing.

That's actually really close to success, and it's probably just a missing package. Is this a 32-bit or 64-bit system?

Not intentional at all. I have no idea what happened there. Two posts have been deleted. That's really strange.

The link is the same as the previous VM6 announcement: http://software.virtualmin.com/gpl/scripts/vm6-install.sh

I'm gonna look through the logs and see if I can figure out where the heck the original post went.

Fixed! I have no idea why this changed, and I have no idea why only a handful of posts were effected. But, I found errors about the PHP option always_populate_raw_post_data in the logs, so I disabled that option, and now everything's back to normal.

Drupal is such a damned mystery sometimes.

Yep, I saw the firewalld bug in my own testing. For anyone else that runs into it, you can re-do the firewalld step manually after install with:

# virtualmin config-system --include Firewalld

That'll complain a bit about some existing rules (also fixed in the next version), but will set up firewalld correctly. It'll be fixed tomorrow when I have time to roll out a new version.

I'd planned to wrap it up today, but we had a server crash which took most of my day (getting back online wasn't too long, but I also spent some time setting up a mirror and getting it working with the license server).

ERROR: Could not lookup : Servname not supported for ai_socktype

Egads. I can't believe this is still an issue! We're waiting like 90 seconds for it to start at this point. I'm running out of ideas for fixing it. I haven't seen the error in my testing, since I increased the wait time, but I guess I need to increase it even more.

I believe it's actually working...but, the problem is that the clamd server takes a long time to start. It feels like years...but, it's really about a minute, or a minute and a half. We don't want to wait forever when testing it (because something could actually be wrong), but we also don't want to make it look like it's not working when it (probably) is. They add ~9000 hashes per day to the clamav virus database, so it's just taking a really long time to load. There's a new project where they're trying to reduce the size of the virus database, but it's likely months away from being a core part of ClamAV. So, we're stuck with this awful user experience.

I covered the firewalld problem in a comment above. It'll be fixed in the next roll out of the virtualmin-config package, and can be fixed immediately with the command I gave above.

Edit: Can you check to be sure you have an /etc/clamav/clamd.conf or /etc/clamd.conf file? And, let me know which one you have, if you do. That may also be an issue. ClamAV has horrible, broken-by-default, configuration on every distro (it's because the upstream clamav documentation recommends stupidly complicated configurations, on the assumption that people will be running multiple scanners for multiple purposes on a single machine...which is a thoroughly nonsensical assumption). So, we may not be tweaking it correctly on Debian.

Debian 9 might work now, but it's way untested. I've been fighting with my VM for Debian 9 (I had to make one from scratch, as we don't currently have any in the Cloudmin image repos, and I couldn't find a suitable KVM image in the wild). It's got a bunch of broken stuff, and I can't figure out which is the Virtualmin installer breaking or what's already broken in the image.

But, all the packages should be in the virtualmin-stretch repo, and the new virtualmin-lamp-stack package should have the right bits for Debian 9 (php7.0 and php, which is cool), and the vm6-install.sh knows about Debian 9. So, it might work fine, but I'd consider it alpha (while the other distros are probably beta-ish quality).

ClamAV has apparently gotten even slower since I wrote that module a few weeks ago. It's long past ridiculous. The ai_socktype error usually just means clamd failed to start during after a minute and a half of waiting. I probably need to just skip testing it, and do something else to make sure the service has started; it's already to the point where testing clamd takes as long as the entire rest of the install (on a fast network).

Quotas are expected to fail frequently on a CentOS 7 system, because you can't enable quotas on a boot or root XFS filesystem without a system reboot. After a reboot, quotas may turn on on their own, but some virtual machines need to have additional boot options added on the host machine (so, in some cases disk quotas can't be turned on at all).

In other words, that's almost certainly successful install! (The "kill: Illegal number" bit can be ignored; it'll go away in the next roll of install.sh.)

Yes, that would be one solution; I don't currently do anything async in the installer (except the progress indicators, which spin while other stuff happens in the background), because usually if something goes wrong, we often can't continue successfully (and in fact, a few of the current bugs I know about are that we don't give up on the install in some cases where we should).

The more I think about it, though, the more I think clamd just shouldn't be started, even temporarily for testing, during the initial install. It can be disabled during a semi-automatic install, but it'd likely cause trouble on a small system with less than 768MB. So, it's probably worth just removing that test. We'll install the stuff, hope it's right, and let it get tested if/when the user turns it on during the postinstall wizard.

It's supposed to be, but my Webmin roll-up script might be missing some of the new repos. I'll check.

Edit: Fixed now. And the roll-up script has been corrected to include the new vm6 repos.

If you see the $clocksource error again, could you post the exact message? I don't have any OpenVZ systems here to test on. I see a couple of places in the code where it could go wrong, but I'm not sure how to deal with it without more detail.

Is there a "/sys/devices/system/clocksource/clocksource0/current_clocksource" file in your VZ container? If so, what's in it?

We don't touch DHCP, so that one is probably entirely unrelated to Virtualmin or the installer.

There may be something going on with the "can't make websites visible" problem, but we'd need more detail to sort out what.

What distro and version are you installing on? There are interesting problems there I'd like to sort out. Postfix failing to start is a weird one that I haven't seen in any testing, so far.

That's correct. We'll bump rev to 6.0 when the beta is over. 5.99 is feature complete for 6 but needs testing.

So, I see two problems, and I'll get them sorted for the next release. There may be others.

First up is the address and network parsing and hostname setting code is broken. That one is tricky; the format we're working with has changed a couple of times across the distros/versions we support, so I'm gonna have to have multiple code paths, and I hate that in shell scripts, but it's gotta be done.

Next, for some reason it configured Firewall (iptables) instead of Firewalld. Which is wrong for Debian 9, where firewalld is available.

The latter problem is probably why you can't reach Webmin. Try running:

See if that makes Webmin accessible. (Test ssh access after doing this before you end your current session, as I think someone else reported that one of the firewall config modules broke all of their access...which shouldn't happen, and I can't figure out how it could happen, but better safe than sorry if it's a remote system.)