I’m not sure why you would disable IPV6 even if it isn’t used? Even if it is a local assigned number?
You aren’t looking at install-related code in the script. That would only be for converting old repos to Virtuamin 6 repos. Has nothing to do with fresh installs. It’s an accident of history that the “repo updater” is built into the install script. We probably ought to split it out.
The Virtualmin 7 repos are not versioned for the OS they’re being installed on, as we’ve pruned out all the binary deps that would need custom builds for a given distro (and rebuilt the one remaining one to be as generic as possible so it’ll run across all versions and architectures).
OK thanks Joe.
Is this an issue you can trap in a future installer?
Cheers
Spart
That’s exactly what I was saying. Because it has an IPV6 address locally it is available to the dovecot listener when it tries to setup dovecot so it continues.
The ubuntu subiquity installer also does not allow you to disable IPV6. Even though you disable it in the installer you still get an IPV6 on the eth cards. You have to disable it in the bootloader before it loads the OS!
Cheers
Spart
The very fact that a working IPV6 stack is there is a security risk! That is why.
Cheers
Spart
I’d suggest trying a different cloud provider.
Hmm… One of the reasons for going to IPV6 was enhanced security. A quick search only shows mis-configuration as a possible security weakness. Could you provide a source for me to check out? I’d appreciate it. Thanks.
What are you talking about. If you had taken the time to read my post you would realise this is on our own infrastructure. i.e. We are the cloud provider!
And you’d suggest trying a different cloud provider for what reason?
This issue is caused by the dovecot config file setting the expectation that IPV6 is enabled on the target host. When it is not, it crashes out rather than falls back to IPV4. Which is the cause of the installer failing and leaving the system unusable.
The offending line is # listen = *, ::
Which is the default for dovecot these days. Instead of listen = * which would allow initially only IPV4 connections. As you know you can set this in the webmin CP for Dovecot but only once it is installed and webmin is up.
Which is not the case after the installer crashes.
IPV6 existence could be checked in the installer script and the config mode made if dovecot crashes rather than fail out.
On my testing it is the only server process that fails.
Cheer
Spart
While I would agree the IP6 existence could and possibly should be checked, this is an exceptional case (not having IP6 on a “clean” OS - even if it is “local”). just how many folk installing Virtualmin go to the trouble of disabling IP6 on the bootloader?
A graceful exit with some note that Dovecot was not installed could be a better option. Does it even load and integrate fully on only IP4? Could it be the case that Dovecot config uses IP6 for a reason or is it just a whim on their part? making a change to Dovecot config (3rd party) is not the sort of policy I believe Virtualmin supports at least until it is installed and running.
IPV6 is insidious. Unless you know what you are doing. It has crept into a lot of software for no other reason than to make it ‘compatible’ with IPV6. Dovecot is no difference. However rather than use the perfectly good IPV4 stack it crashes when it can’t bind to IPV6 that was never there!
Dovecot works perfectly well on IPV4. It is lazy programming to implement compatibility with IPV6. Setting the default to IPV4 in the config and allowing users to enable IPV6 support would be a much easier option. Rather than the lazy assume both stacks are there and crash if not.
I agree but why should it fall to Virtualmin to correct the inadequacies of Dovecot?
Especially for this extreme outlier case?
I am sure the maintainers of Dovecot have greater funding, time and staff to fix their faults (if they could ever be persuaded it is a fault) than Virtualmin.
IPv6 is the future, not an inadequacy. If the OP doesn’t want to use it, that’s their choice. Like it or not, that’s where the world HAS to go. The OP is free to disagree and find a work around. It isn’t up to the world to go backwards to accommodate.
The issue is your own misconfigured infrastructure, not Virtualmin or Dovecot.
If Dovecot knows it has an IPv6 but your own routers block that IPv6 HOW WOULD THAT BE THE FAULT OF DOVECOT OR VIRTUALMIN?
Just remove them damn IPv6 from your own infrastructure, OR ALLOW it to make connection trough it.
Simple as that
I see now! What’s really failing is installation process for dovecot-imapd package.
There is absolutely nothing Virtualmin install script can do, like literally! Virtualmin install script installs the stack of packages. If apt-get install dovecot-imapd fails (in scriptlets), then the whole Virtualmin installation process just stops!
This is out of our control, as we don’t provide dovecot-imapd package. However, you’re welcome to file a bug report upstream though.
Nevertheless, there is no reason to disable IPv6 for your instances.
1 Like
If that is so then why do DO (as an example) make it an optional extra?
I’m too old to care about the future. I’m sure one day someone will say we will all connect to the cloud with a brain implant or we should all live on the moon 
I have spent years teaching my staff that changes should be progressive and never sudden or catastrophic and to accommodate those who are not using the latest fad or hip whizzo function. Of course doing so may inhibit so called progress but that isn’t bad.
We are from the same generation. 30 years ago knowledge could be used for a long time. Now what you learned 5 years ago changes and is no longer useful. Look at how quickly the hardware and especially the software side evolve, where new solutions appear like mushrooms. It is enough to sit outside the domain for a few years and you are completely erased from the advanced knowledge, you are only left with the basics. Who doesn’t agree with me, take a Linux manual from 30 years ago and understand how much has changed.
Your response tells me how much you understand about networking. Our infrastructure is not misconfigured it is configured perfectly. The point is Dovecot doesn’t know it has anything. It simply assumes that IPV4 and IPV6 stacks are there on the target host. And, rather than simply ignore the fact that IPV6 is not there it crashes out. All due to a config variable change in the default config file and lazy programming. I have also said as much to the Dovecot team!
This has nothing to do with anything outside of the host we are installing. It is the network stack on the host and the fact that Dovecot assumes IPV6 is there that is the issue here. No reason to shout at anyone as I am not making it Virtualmins fault just looking for a practical solution. I have already reported the issue to the dovecot developers. I have already posted my workaround which currently is operating normally without IPV6!
@xlad Your attitude is symptomatic of the stuff I see online all the time these days. It is very difficult to have an intelligent discussion without keyboard warriors who have either not read or did not understand the core issue being discussed jumping in and giving their clearly well thought out and reasoned opinion! Shouting is also very rude. ITRW and online.
@Ilia I am not sure I agree with your assertion that there is nothing the script can do. I also not suggesting it is your problem. Just sharing my experience and admittedly a little frustration as a paying customer. But, it is entirely feasible to catch this in an installer script. Modify the config file and re-start Dovecot and carry on with the install. And again before I once again get attacked by the keyboard warriors. I am not saying you need to fix it. But, it is entirely possible to script around the issue. Catching the failed start of Dovecot, modify the config file and loop around and continue.
There is also every reason to disable IPV6 when we do not support it or use it and therefore remove any possible attack vectors.
I thank you for your consideration. Please read my post before attacking me. I have already identified the root cause, the fix and the workaround. Yes, it would be nice to have it taken care of by the installer as we are all now aware of it.
Onwards…
Spart
I don’t need to know an entire story:
- Your server is assigned an IPv6
- YOU blocked that IPv6 on your network
result:
Your server thinks that has a legit IPv6, and preffers it over the old IP (version 4), but HAS NO ACCes to the network that YOU blocked it.
I didn’t read your post because you lose everyone’s time.
Edit: as a note, you could stop autodiscovery for IPv6 on your network based on your new server MAC, but hey, you’re the expert, so your server take by itself IPv6 that you blocked on network level.
I am stupid, not an expert, I hope that helps you in some way my admittance.
Wow, I think you are making my point for me. My server is not assigned anything. My server knows it does not have IPV6. By not reading the post you missed the important details but yet still felt able to comment incorrectly on almost every point.
There is no IPV6 network!
And no, not a single thing you have posted in any way helps this discussion. And thank you for the apology!
Cheers
Spart
RIght.
Just disable the damn IPv6 you superadmin of your damn network.
You did disabled it at boot as I showed you.
Why people should read nonsense if they don’t give solutions?
*you do know IPv6 is assigned automatically BY NETWORK? I hope so.