Disabled IPv6 and services doesn't start

ipv6

#21

Sure, that is what @miska stated earlier, but that requires the boot arg to be removed first or else the setup from medkit reset is no dice.

And it is not really answering the question about the decision logic to cease.


#22

You can modify the medkit as it is ordinary tarball.


#24

The funny thing is looking into the conf of lighttpd

Use IPv6 if available

#include_shell “/usr/share/lighttpd/use-ipv6.pl”

Being a conditional directive the logic is apparently to continue with ipv4 and yet when the ipv6 sock is not available is does not work. Just a point in case about the twisted logic.


#25

@miska @vcunat

Just discovered that dnsmasq seemed to have a similar issue in the past and which backs what I said earlier - application logic. See release history 1.3


#26

I’m late here, but it should be noted that ipv6.disable will break various stuff, partially because IPv4+IPv6 binding logic in kernel.

As an example that it is not TO-specific problem see e.g.
https://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration

It explicitly mentions that ipv6.disable breaks Samba and recommends to use sysctl net.ipv6.conf.all.disable_ipv6 = 1 instead.


#27

I am not concerned about Samba since not utilizing it. The kernel has no issue with the ipv6 stack disabled and the linux boxes I am running with all kind of apps neither.

They just recommend it because Samba (conveniently) designed its stack logic that way, which most other apps do not, just to name a few are dnsmasq, ngix and and unbound.


#28

Sure. I’m just trying to explain that fixing all apps is long run because it is widespread and would require changes in many apps to make it reliable for everyone instead if just make it work in your particular use-case.


#29

(And of course, is questionable if it is worth the effort at all.)


#30

Not asking to re-design your app (stack logic) as such design is your prerogative certainly. I have been sharing an observation.

I am using unbound anyway once through the TOS vanilla setup.


#31

all the efforts to push ipv6 adoption taken in good faith, i also do not agree that silently requiring a specific (and essentially optional) protocol is the right way to go.


#32

Might as well embrace nftables which in comparison to iptables are less CPU expensive, faster, feature atomic reload, don’t need ipset and best of all do not require separate rule sets for ipv4 and ipv6 :wink: :mrs_claus:
Or skip that and jump straight to BPF