I did some further testing and it seems that at the point it hangs, I am unable to ping any websites from the droplet as well. So the question is: is the virtualmin install configuring something IP related that would disrupt the droplet’s Internet stack until a reboot?
Just to clarify, are you saying that you’re able to perform an installation of Ubuntu 16.04 on a Linode that is configured only with an IPv6 address?
I know you had an suexec error, but other than that did the installation complete?
-Eric
Hi!
I experienced the same problem. I used a fresh DO droplet with ubuntu 16.04 x32. I tried the x64 Ubuntu, too ,without any luck.
Both my Linode and DO installation are configured with both IPv4 and IPv6.
For the Linode, upon further testing (I created tens of different VPS over the past few days) it seems the suexec error occurs perhaps 1 in every 10 installations. To fix it I did a complete reinstall (after doing a2enmod suexec and restarting apache the error did not seem to go away). But I guess that’s not a major issue. It completes installation every time–I get the update SpamAssassin rules.
With DO it consistently fails at the exact same spot, and upon a reboot I get the suexec error all the time.
Okay, while we’re not really sure what exactly is causing that, because of what you described Joe is making some networking changes to the Virtualmin software repository that we’re hoping will resolve that.
It may take some time to complete those changes, so you’ll need to use an IPv4 IP for the time being to get things setup, but hopefully once he’s done we hope that’ll resolve the issue you’re seeing.
-Eric
The only thing the installer touches is the hostname configuration, but even that doesn’t do anything to the network stack or restart anything. But, Virtualmin does install a ton of packages. It’s entirely possible one or more of them restarts the network or does something else.
Something that I’ve recommended to folks in the past (though with different symptoms than yours) is to install all of the dependencies manually. You can see what they are in the “ubudeps” list in install.sh. This would, at the least, allow you to see if maybe the trigger for the problem is among those packages, or if it’s somewhere else in the installation (maybe during our package installation).
One other thing: We do alter the firewall. But, only to open ports. I don’t think that could do anything here, but, it’s another possible area of the install touching networking in some way.
Thank you. I’m still happily chugging along with 14.04 at the moment. Do let me know once the changes have been made, so I can test further and make a migration to 16.04 once the bugs have been ironed out.
Thank you so much for your patience and assistance.
By the way, may I know what the step “/usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install” does? I know that the networking stack hangs during this step.
That’s installing packages (the list of packages in ubudeps and the list in vmpackage).
–config-file specifies an apt configuration that works non-interactively (i.e. without asking the user a bunch of questions about how to configure the apps being installed…we don’t need to ask, because our virtualmin-base package at the end will configure all of the services in a reasonable fashion, and then the postinstall wizard in Virtualmin itself will ask the user a few questions about stuff we can’t guess about (like running clamd and such).
-y and --force-yes just means it won’t ask for confirmation about installing packages, it’ll just do it.
As I mentioned above, I bet if you were to install those packages manually (the ones defined in ubudeps) we’d be able to get more information. It might even Just Work.
Thank you.
The command I should run is:
apt-get install bsdutils postfix postfix-pcre webmin usermin ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail procmail-wrapper libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libapache2-mod-php5 php5-mysql
right?
I am not very well versed in Linux though, so was wondering if you could guide me through how to add the Virtualmin repo to my sources list before I can install the above? Right now it is saying a couple of packages areen’t available.
I managed to get the sources installed and ran apt-get install on the $ubunewdeps manually. All seemed to work fine… Will need to look through the install.sh more carefully to see where it could’ve gone wrong.
EDIT: Further testing reveals that the hangs happen when apt-get installing virtualmin-base. It seems to hang when configuring BIND @ resolv.conf.
Okay, after more testing I can confirm that when Virtualmin-base tries to configure BIND, my connection is suddenly cut.
These are the commands I ran manually (I decided to apt-get install webmin only to rule out other causes of the problem):
add-apt-repository "deb http://software.virtualmin.com/gpl/ubuntu virtualmin-xenial main"
add-apt-repository "deb http://software.virtualmin.com/gpl/ubuntu virtualmin-universal main"
wget http://software.virtualmin.com/lib/RPM-GPG-KEY-virtualmin
wget http://software.virtualmin.com/lib/RPM-GPG-KEY-webmin
apt-key add RPM-GPG-KEY-virtualmin
apt-key add RPM-GPG-KEY-webmin
apt-get update
wget http://software.virtualmin.com/lib/apt.conf.noninteractive
/usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install webmin
/usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install virtualmin-base
Virtualmin-base works fine until it reaches the part on configuring BIND. The last line it reads is that it’s configuring /etc/resolv.conf, and then I lose connection.
Hi there, just a little bump to this thread.
Is there anything else I can do right now? Is there a way to modify how virtualmin-base is installed, perhaps to exclude the BIND configuration? Thank you.
Up. Any news in the case of DO IPv6?
Thanks!
Hi, if you must be running ubuntu, you should wait till ubuntu 16.04.1 or try debian.
Can you please explain how Ubuntu 16.04.1 will solve this IPv6 problem?
up
Can you please explain how Ubuntu 16.04.1 will solve this IPv6 problem?
Because looks like Ubuntu 16.04 have problems with IPv6 and you are not the only one facing them. Unborn said that because probably in next patch (16.04.01) they should repair this problem but ofc there is not 100% guarantee it will be then, or maybe in some next patch. It could happen like with Centos 7 on OpenVZ virtualization where was a problem what would prevent network to start after server reboot. They (Centos devs) took quite some time to sort this and until then was stay with Centos 6 or manually repair the problem.
I dont think this is Vmin bug so you have two options - stay with Ubuntu 14.04 or go for 16.04 but then you must find the solution online and manually patch the problem.
Yeah. but with Linode, IPV6 works like charm. Since I located in Europe I need a European bill and Linode cannot provide this me. I’ll stick to IPV4 with DO and hope for the best.
It could be that Linode is using different template than DO. Again, similar thing was happening with Centos where only OpenVZ virtualization was affected and not for everyone as some hosting companies patched Centos 7 before the official release. I know that with Centos 7 i dont have any problem with IPv6 so i took few minutes to see if your problem is something isolated or there are more cases like yours. It turns out that google show that many others have same or similar problem like yours and quick solution for each one of them was to turn off IPv6 but this doesnt mean you cant find a solution online and manually apply.
If this is OS problem (it looks like) then Vmin cant do anything because its pulling updates/patches from official sources, e.g. Vmin will patch your OS once they (in this case Ubuntu devs) release the patch.
P.S. Its always good to wait for at least 1 major update/patch before you start using new OS. EoL for Ubuntu 14.04 is April 2019 so you have 3 years until then to switch to Ubuntu 16.04.