@jcrespo do you know if that bug got fixed and if we could have that daemon listen on IPv6 now ?

No idea, it is the first time I've seen this task. Do you want me to test a bacula storage to listen on :: ?

Sure, thanks ! I also discovered it just now by reviewing the sub-tasks of T253173: Some clusters do not have DNS for IPv6 addresses (TRACKING TASK).

Doing:

SDAddresses = {
    ipv4 = {
        addr = backup1012.eqiad.wmnet;
        port = 9103;
    }
    ipv6 = {
        addr = backup1012.eqiad.wmnet;
        port = 9103;
    }
}

(and removing SDPort, which is incompatible) seems to work:

root@backup1012:~$netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
...
tcp        0      0 10.64.154.11:9103       0.0.0.0:*               LISTEN      3578577/bacula-sd   
...     
tcp6       0      0 2620:0:861:122:10::9103 :::*                    LISTEN      3578577/bacula-sd   
✔

Although it requires a full restart, a reload didn't bring up the ipv6 listen. Backups worked, although I presume do it still through ipv4 as I have not changed the client config.

Would that be acceptable? Is there a scenario where we setup hosts with more than one production ip (here production== for public network communication within the production cluster)? Is ipv6 only the final goal, or dual stack?

The migration of this would take a bit more steps- client configuration, preference, firewall tuning but nothing extremely complex (unless we run into bugs).

Interestingly, if I do:

SDAddresses = {
    ipv4 = {
        addr = 0.0.0.0;
        port = 9103;
    }
    ipv6 = {
        addr = ::;
        port = 9103;
    }
}

It fails with:

bacula-sd[3581622]: backup1012.eqiad.wmnet-fd: Warning: Cannot bind port 9103: ERR=Address already in use: Retrying

So there could be a bug, but something that it seems mostly on usability rather than actual functionality (and no, :: doesn't bind the ipv4 address, I checked), so it must be the local loopack conflict (?).

If you want to bind any address, from the docs at [1] it seems that you can just omit the setting and not specify any of SDAddresses and SDAddress. SDPort seems optional as we're using the default port.

[1] https://www.bacula.org/9.6.x-manuals/en/main/Storage_Daemon_Configuratio.html

In T253986#11412976, @Volans wrote:

If you want to bind any address, from the docs at [1] it seems that you can just omit the setting and not specify any of SDAddresses and SDAddress. SDPort seems optional as we're using the default port.

[1] https://www.bacula.org/9.6.x-manuals/en/main/Storage_Daemon_Configuratio.html

I tested it and it doesn't work. In that case it does only ipv6.