Pinning sshd-server to a specific IP is only possible by directly configuring it via sshd_config:ListenAddress, which is cumbersome and requires one to supply duplicate data to all minions (duplicate in a sense, that the IP may be available elsewhere in the pillar data).
Describe the solution you'd like
Being able to designate a source pillar key to use, maybe something like:
Supplementing the matcher sources (i.e. 'I:SUB@pillar:key:to:lookup', but that is not really documented well, and I could not find out, if lookup and inserting under a different dict-key is possible at all.
Additional context
Binding sshd to a specific IP may be desirable in more complex networks, where hosts have more than one network interface, but should expose OpenSSH only on one specific card.
Setting the listen address dynamically is not a problem, when using pillar files, as we can write some jinja-logic into the correct pillar.
That approach is not feasible with dynamically provided pillar data (i.e. like Tower/Foreman/Puppet/...) where only yaml is available.
Is your feature request related to a problem?
Pinning sshd-server to a specific IP is only possible by directly configuring it via
sshd_config:ListenAddress, which is cumbersome and requires one to supply duplicate data to all minions (duplicate in a sense, that the IP may be available elsewhere in the pillar data).Describe the solution you'd like
Being able to designate a source pillar key to use, maybe something like:
which would then be converted in map.jinja to the actual value:
Describe alternatives you've considered
Supplementing the matcher sources (i.e. 'I:SUB@pillar:key:to:lookup', but that is not really documented well, and I could not find out, if lookup and inserting under a different dict-key is possible at all.
Additional context
Binding sshd to a specific IP may be desirable in more complex networks, where hosts have more than one network interface, but should expose OpenSSH only on one specific card.
Setting the listen address dynamically is not a problem, when using pillar files, as we can write some jinja-logic into the correct pillar. That approach is not feasible with dynamically provided pillar data (i.e. like Tower/Foreman/Puppet/...) where only yaml is available.