Allow to listen on multiple IP addresses

[smortex]

Allow to pass multiple IP addresses. The default behavior is to listen on IPv4 only so this is only a breaking change because the interface change.

[smortex]

But maybe since #173 breaks backward compatibility, no need to support a String for the parameters and only accept Array[String[1]]?

[neomilium]

But maybe since #173 breaks backward compatibility, no need to support a String for the parameters and only accept Array[String[1]]?

I agree, this makes code more simple.

[smortex]

☑️ backward compatibility code removed

[neomilium]

@smortex Whould you like I merge too on this project after a review?

[smortex]

I would prefer to have a second approval by somebody external of @opus-codium we both belong to before merging 😉

If we have no news in a few day, no objection to pull the trigger.

[smortex]

I updated the PR to not set an explicit listen address by default, which bacula understands as listen on all IPv4 only (so same behavior as before).

[neomilium]

I updated the PR to not set an explicit listen address by default, which bacula understands as listen on all IPv4 only (so same behavior as before).

IMHO, this behavior should be shorty documented. Could you put a note in the variable documentation?

[smortex]

The fact that :: also listen on IPv4 is linked to Linux's default of /proc/sys/net/ipv6/bindv6only which is 0. I just checked on FreeBSD where the default is not to do this kind of thing and the service only listen on IPv6 with such a configuration. Putting both 0.0.0.0 and :: on FreeBSD listen on both addresses, doing so on Linux fail because the service wants to bind twice on the same port for IPv4. Setting /proc/sys/net/ipv6/bindv6only to 1 "fix" this behavior and we can put explicitly :: and 0.0.0.0 as listen addresses and the service will be reachable over IPv4 and IPv6.

The only thing that annoys me here is that the service only listen on IPv4 by default (which is an issue at Bacula's level), and I do not think the module documentation is the right place to describe this since this can change at any point upstream?

[neomilium]

The only thing that annoys me here is that the service only listen on IPv4 by default (which is an issue at Bacula's level), and I do not think the module documentation is the right place to describe this since this can change at any point upstream?

OK, so we had to support OS-independent and idempotent way. What about putting some hiera files, OS-dependant to reach the same behavior on each OS?

[smortex]

The only thing that annoys me here is that the service only listen on IPv4 by default (which is an issue at Bacula's level), and I do not think the module documentation is the right place to describe this since this can change at any point upstream?

OK, so we had to support OS-independent and idempotent way. What about putting some hiera files, OS-dependant to reach the same behavior on each OS?

I really don't know how we could deal with this: system dependent config also look wrong to me: the default behavior of FreeBSD and e.g. Debian is not the same in the way that Debian offer IPv6 mapped IPv4 by default while FreeBSD doesn't. But as stated above, Debian can be tuned to opt-out, and of course FreeBSD can be tuned to opt-in 🤷 Above I wrote "Linux" but I really meant "Debian", I don't know if the default is the same for every Linux distro, and I would not be surprised to see it is not. And since it is tunable, I think that sticking to upstream default is the best way to not break POLA.

Maybe in the end a note in the README is better? What information would you like to see there?

[smortex]

Could you put a note in the variable documentation?

"variable documentation" 🤯

Yeah! Did that! Thanks!

[neomilium]

Excellent explanation (in reference documentation)!