Virtualmin 6 beta available for testing

"Am I really the only one where the Virtualmin/webmin can not be installed using ./install.sh? "

I don't think that's what's happened here. I think everything is installed, but a couple of things didn't get configured right or started up.

What do you get from the following commands?

Those are the primary packages...so if they're installed, then Webmin/Virtualmin are installed, and we just have configuration to worry about. If they are not installed, then there's some other issue, which I don't think anyone else has reported. (In every case I've seen thus far, there are configuration issues, which I'm fixing as I find them and as they get reported.)

Edit: Note I had a typo in my commands above...I accidently put -i instead of -s. Fixed now.

OK, I'm able to reproduce the missing virtualmin CLI (the virtualmin command) on Debian. I think it's related to the postinstall scripts failing to run because it can't find WebminCore as the packages are being installed. I don't know why it's doing that, but will get it sorted out.

But, other than the missing virtualmin CLI command, my test install resulted in a pretty much functional system. Webmin/Virtualmin are running on port 10000. I did get the wrong firewall configured (Firewall instead of Firewalld, as happened in your case) so I needed to manually add a rule to allow port 10000 access. I'm not sure why it's detecting the wrong firewall.

Since the virtualmin command doesn't get setup, you can still run the config-system command with:

That should open up the ports so you can try to access Webmin.

So, what I think is broke, right now:

• Wrong firewall detection (iptables instead of firewalld).
• "virtualmin" command doesn't get created (side effect of the WebminCore module loading problem during deb package postinstall)

Am I missing anything?

I'm not sure that's the same thing. But, it might be. Are you saying Webmin is not responding on port 10000 after installation (that would be the "same thing" as the prior message)?

I'm running a test here to see if I can reproduce the problem.

"But this line is quite strange to finish the install.sh, no? ./install.sh: 15: kill: Illegal number: 9019 2290 2670 2688 2706 2733 2768 2801 2831 3173 3542 3617 5471 5844 4464 9000"

That's harmless. Just a mistake in my shell scripting. There's a couple of places where we can end up with a spinner process living past its usefulness (though I think most of those bugs are fixed now), and there's a step at the end where we do a "kill them just in case" thing. I did it wrong. But, it doesn't actually do anything since I did it wrong. It should be fixed in the latest release of install.sh and slib.sh (slib is a library of shell functions that is downloaded automatically by install.sh) in the repos.

Regardless, completely ignorable. Not interesting at all. ;-)

There does seem to be an issue with Let's Encrypt, but I'm not sure exactly what's going on there. We've had sort of a weird assortment of error reports, but we're not seeing the problems on our servers (we eat our own dog food, so we use Let's Encrypt certs on all of our systems). There are a couple of tickets in the issue tracker about Let's Encrypt right now, and we'll hopefully have it sorted out soon. I'm not working directly on that (that's Jamie territory, and I'd only step in if he didn't have time to work on it; installer and repos are my job, and it seems like we're really close to having that working nicely for Virtualmin 6 and for Debian 9). Anyway, LE should be fixed soon, since Jamie does know about the problem.

I just rolled out a new virtualmin-config package, which will fix the "wrong firewall being setup" problem during install.

The only other outstanding issue I know of is with Webmin and the Perl version in Debian 9. We need a one-line change in one command line tool within Webmin to make it work with the new Perl...I've checked in the fix, and I'm just waiting for Jamie to roll a new devel package so I can stick it in the repos.

I think we're really close to being able to call Virtualmin 6 stable, which is super exciting.

Look in the /root/virtualmin-install.log to see if activity is happening. If it's still downloading and installing packages, you'll see them ticking by, and you should keep waiting! If nothing is happening, there might be an error or some other indication of why it's hung.

Depending on how fast your network is, it can take a good while. My test systems take anywhere from a couple of minutes to maybe five minutes to install, but they're all on pretty fast networks. It's faster than it used to be (I'm not actually sure why, as it's mostly doing the same amount of download it's always done...a little more, actually, since we're installing and configuring more stuff by default), but it still takes a while just to download everything.

Hmm...that's a new one. Net plugin only does two very simple things: Add 127.0.0.1 as a name server in resolv.conf, and restarts Postfix so it'll pick up the change. I can't figure out how that could hang.

I wonder if maybe your session just timed out? Was the spinner still going when it stopped responding? Or did it stop, too? (By "spinner" mean the progress indicator thingy.")

Oh! You're saying you lost access to the server completely. That sounds like a firewall problem (i mean during the installation). I fixed several bugs in how the firewall is detected across different systems in the virtualmin-config 6.0.8 package, which may fix this, but I wasn't seeing the problem even on my Debian 9 test system, so I'm not sure at all that it's what you're seeing. And, it's also weird, because the current ssh session should pretty much always remain active even if every port is closed down by something going wrong with the firewall setup (but it could potentially prevent new connections if something went wrong).

Have you tried an install since yesterday? (I rolled out 6.0.8 I think yesterday.)

If so, and it still had problems, can you post any of parts of the virtualmin-install.log that refer to firewall, iptables, or firewalld? That might help me sort out where it's going wrong on your system. I'm not sure it's firewall, but since the log shows the install completing I'm pretty sure the system itself is fine and it's just locking you out for some reason.

"I was on the stable virtualmin, but unfortunately virtualmin itself upgraded me to Debian 9 from jessie"

Virtualmin only uses apt-get upgrade. It doesn't do a dist-upgrade. Virtualmin has no way to change your repos. It's just asking apt-get what packages are available and then installing them when you tell it to. I'm not sure how we'd protect against that happening, since we don't have any way to know when Debian has changed the stable repo to point to the new distro version. It just looks like an unusually long list of packages, as far as Virtualmin can tell.

"and that borked up virtualmin. So I installed the beta installer on Debian 9."

Are you saying you ran the install script on a system that already had Virtualmin installed on it with the old install script? That will never work (really, it's impossible for it to do good things in that circumstance) and will make things much more broken (and there's two warnings about that when you run the script to try to prevent folks from running it on a production system).

If you've got a system that broke due to package upgrades or similar, post about those specific problems; they're gonna be minor issues (upgrading from Debian 8 to Debian 9 is not a big change and won't break much, but running install.sh again will break a lot of things).

Please never run install.sh on a production system. The two warnings it prints are real.

The clamav error is probably harmless. But it may also mean there was a different configuration from the old install script and the new configuration put in place by the new install script isn't compatible. That might need to be manually corrected. Worst case, AV scanning won't work until the right clamd service is being started up.

For your sites not working, I would guess maybe the default virtual host got re-enabled when your system upgraded. Try this:

See if that helps. If not, we'd need to see the apache log entries when you're trying to access the site, both for the system and the virtual host that is misbehaving.

That's tricky. I do a lot of install/uninstall loops in my testing, and I update the uninstall to include everything I know about as I go along. So, there aren't any secret tips I have that'll make it right (they're in the install script...there's a couple of extra dependencies that are in the next version rolling out today). It Works For Me(tm). But, that's not saying much.

The problem isn't really "the install script did things that the install script can't undo". The problem is "the user did things that the install script doesn't know about and so can't undo". When I talk about not installing on a production system, I mean, you've got a system that's been in use with Virtualmin for some length of time. It's got domains, it's got mail users, it's got configuration changes you made to make it suit your needs, it's maybe got extra software you installed (that might be incompatible with the extra software the new install script sets up, like PHP7 and some EPEL packages). That's a system that you can't safely run install.sh on.

Any upgrades need to happen using the normal package manager. Virtualmin 6 does have a new repository path and so you won't automatically get the new repo and the new packages (though Virtualmin virtual-server module 5.99 is already in the regular old repos, and 6.0 will go in there, too, when it's released in a day or two), but I'll roll out a script for upgrading to the Virtualmin 6 repositories and setting up virtualmin-config packages in the near future; there will never be a reason to run the install script again. It's just not designed to upgrade a system.

The problem of understanding the state of a running system is a huge one. There's entire projects with more code than the entirety of Virtualmin/Webmin that are dedicated to the problem (Chef, Puppet, etc.) and they still can't do it. We have a little bit less complexity because we know some of the initial state of the system, but even so there's infinite variables. Part of the reason I created the new virtualmin-config program is to solve some of that complexity. It's basically a configuration management tool (like Puppet/Chef/etc.), but with a much more specific set of goals and smaller problem domain.

So...in short: --uninstall is best for when the first install failed, and you want to start fresh. I also use it a ton during testing. It might work for taking an old install.sh installed system and making it able to have the new vm6-install.sh run on it, but I wouldn't bet on it. And, it'll really, truly, wreck whatever configuration you had on the system before, including domain configuration and such. The install process still really is only happy with a freshly installed OS, and I don't think there's any good way to make it not have that requirement, without writing thousands of lines more code to accommodate all the possible differences (and still probably failing).

In shorter short: If you have a system with Virtualmin running well (or that was running well), don't uninstall it and don't run install.sh on it again. In the case of an OS upgrade, fix the problems and upgrade the repos to point to the new Virtualmin 6 paths (I'll make a script for this really soon, and it'll probably even make it into the GUI as a button to upgrade). install.sh/vm6-install.sh wants a freshly installed OS, and if you give it anything else, you're probably gonna have a bad time.

Edit: But, if you show me the last few lines of the virtualmin-install.log, I might be able to guide you on getting it working on your system.

OK, that one is from way out in left field. Your apt-get isn't working for some reason. I've been trying to figure out how that would happen, but I can't reproduce it here.

Test apt-get from the command line. Just try to install some random package and then uninstall it and see what happens. Without apt-get the installer definitely can't work.

Edit: And, no I didn't say php 7.1 wouldn't work. As far as I know it'll work fine if it's coming from the system-standard repositories. It may require configuration changes in Virtualmin, but I'm not sure how that detection works these days. Third party packages might be weird.

You find the weirdest errors. ;-)

This one indicates Webmin isn't installed when it gets to installing the webmin-virtual-server package. But...it's all installed by the same set of dependencies in virtualmin-core. I have no idea how that would happen.

Can you tell me a little more about this system? What kind of VM is it running on? How much memory? I feel like something is going wrong with apt-get or something that I don't understand, but I've never seen this exact behavior in my testing.

It's not installed by default, but we plan to keep maintaining it until accessibility is up to par in the new theme.

It does look like I forgot to add it into the new repos, but I'll take care of that today.

Eventually (we don't know how long "eventually" will be, but certainly a few more months), the old themes will be deprecated and completely remove, so please let us know what needs to improve to make Authentic work well for your needs (we know about speed, and Ilia already has a beta version out that solves that, but has some quirks with File Manager and a couple of other pages). We need clear actionable data on what doesn't work for you in the new theme.

It currently does not require a lot of work to maintain, but we're branching Webmin 2.0 in a couple of months, and it will become a lot harder to keep the old themes going. There will be a new "minimal" theme that doesn't use (much) JavaScript and uses very basic CSS, but it won't be the Framed Theme. It's too convoluted to bring over (it's convoluted because of the theming system).