I believe this problem is now fixed in the latest 6.0.3 version of the install script (it’s what you get when you download from the standard links). I was able to do a dozen or so test installs without error on both Debian 9.1 and Ubuntu 16.04 last night before rolling it out, going through all possible permutations (uninstalling it, switching from LAMP to LEMP and vice versa, both minimal and full installs, etc.)
nginx with Virtualmin is more popular than I’d assumed until recently. I still prefer Apache, just because it’s familiar and despite assertions to the contrary it isn’t much less performant or efficient (in terms of CPU or memory) than nginx in the majority of cases, particularly if Apache is configured with its options as stripped down as the default nginx configuration. But, the wind blows the way of nginx, and we’ll go where the wind blows, since nginx is also very good software. And, now that we have installer support, I expect a lot more users will choose it. I hope folks will read up to understand that it is still less capable than Apache (partly because we just haven’t had feature requests to add some of the stuff that’s been available in Virtualmin in Apache for years, and our development is very much driven by user feedback).
Anyway, it boiled down to two problems, which have been mentioned above:
- The “PHP causes installation of Apache” problem identified by mikrobug.
- The “fail2ban breaks firewalld and apt-get/dpkg” problem caused by the default fail2ban.service unit being broken (it depends on iptables.service, which doesn’t even appear to be a thing on Debian, and is apparently an incorrect use of the PartOf option.
Either could cause an install failure because either can cause package installation to fail. And, it was pretty intermittent which one would cause a problem and under what circumstances.
I worked around it by forcing installation of fail2ban before everything else, just so I can shut the damned thing down (the installation auto-starts it, and when it’s running it breaks any triggers that call firewalld, which several of the packages we install do). And, then it gets turned back on during the configuration step after all the packages have been installed.
Likewise I solved the php->apache2 problem by forcing installation of php-fpm before anything else. Again, this forces apt-get to behave in a reasonable way.
The problem with the latter solution is that it breaks the install script on both Ubuntu 14.04 and on Debian 7 (and maybe Debian 8, I haven’t tested yet). So, that sucks, and will be part of my day today to straighten it out. I was so enjoying Debian 9 until all these ugly little warts showed up and reminded me why I still so strongly prefer yum/RPM. (I still think Debian 9 is a great release. The problems I’ve had are old and kinda ingrained in apt-get/dpkg and the packaging policy of conflating package installation and configuration, and so current maintainers can’t really be blamed for them.)