[salt-users] Best way to do this in salt?

Hi folks,

We have ext_pillar configured to get pillar data from an external
system (xcat) which we use for bare-metal node
discovery/deployment. We want to disable PasswordAuthentication in
sshd on some nodes, and not others, which sounds like the solution
would be a pillar setting to me. The problem is we want to change
this one setting based on the group the node(s) belong to in xcat,
which is information only available to the master and therefore got
via the ext_pillar (i.e. I can't do '[email protected]:groups:private' or
similar in the pillar's top.sls to make the setting available).

What do people think is the best approach for this?

We want to get away from having host or group specific detection in
the config files, or the state files, themselves and relegate this
information to the top.sls file(s) so there's a single place to
look to see what configuration should be applied to a given host.

Laurence

On 2014-09-18 14:25, Florian Ermisch wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Laurence,

for using pillar-data to decide which pillar-data to pass to the
minion
I use includes with passed variables in pillar:

include:
- networking:
defaults:
ipv4addr: 10.0.0.34/24

Then networking.sls is a template that will figure out the subnet
based on the IP and include a subnet-specific file with stuff like
gateway and DNS-servers.

I got to admit, I have no Idea if you can make this approach work
with
ext_pillar. Maybe "Targeting minions by ext_pillar" is a reasonable
RFE and worth opening an issue on Github?

Regards, Florian

Am 18.09.2014 um 14:24 schrieb laurence:

On 2014-09-18 15:04, laurence wrote:
Florian,

That's quite neat for that sort of use-case (I'm going to have to try
that at home!).

I've kinda worked around it by deploying the sshd_config file (which
is templated, as it has an accumulator for Match sections at the end)
and then doing a replace in a separate sls for the line we want to
change (PasswordAuthentication no) but this results in the file
getting pushed out and then changed on every update. Is there a way
to set a context variable in another sls and have it available in the
template (with a required_in)?

Something like this:

--no_password_auth.sls--
sshd_config_no_passwd_auth:
context:
- set
- name: password_auth
- value: 'no'
- required_in:
- file: sshd_config

--sshd_config.sls--
sshd_config:
file:
- managed
- name: /etc/ssh/sshd_config
- source: salt://some/path/sshd_config.j2
- template: jinja
- default:
password_auth: 'yes'

--sshd_config.j2--
...
PasswordAuthentication {{ password_auth }}
...


Laurence

Ignore my last email, figure out a way to do what I needed:

--service/sshd.sls-- sshd_config: file: - managed - name:
/etc/ssh/sshd_config - source: salt://service/sshd/sshd_config.j2 -
template: jinja - user: root - group: root - mode: 400 - default:
password_authentication: 'yes'

--service/sshd/no_password_authentication.sls-- include: -
service.sshd

extend: sshd_config: file: - name: /etc/ssh/sshd_config - context:
password_authentication: 'no'

--sshd_config-- ... PasswordAuthentication {{
password_authentication }} ...
Hi Laurence,

for using pillar-data to decide which pillar-data to pass to the
minion I use includes with passed variables in pillar:

include: - networking: defaults: ipv4addr: 10.0.0.34/24

Then networking.sls is a template that will figure out the subnet
based on the IP and include a subnet-specific file with stuff like
gateway and DNS-servers.

I got to admit, I have no Idea if you can make this approach work
with ext_pillar. Maybe "Targeting minions by ext_pillar" is a
reasonable RFE and worth opening an issue on Github?

Regards, Florian

Am 18.09.2014 um 14:24 schrieb laurence:

Florian,

That's quite neat for that sort of use-case (I'm going to have to
try that at home!).

I've kinda worked around it by deploying the sshd_config file
(which is templated, as it has an accumulator for Match sections at
the end) and then doing a replace in a separate sls for the line we
want to change (PasswordAuthentication no) but this results in the
file getting pushed out and then changed on every update. Is there
a way to set a context variable in another sls and have it
available in the template (with a required_in)?

Something like this:

--no_password_auth.sls-- sshd_config_no_passwd_auth: context: -
set - name: password_auth - value: 'no' - required_in: - file:
sshd_config

--sshd_config.sls-- sshd_config: file: - managed - name:
/etc/ssh/sshd_config - source: salt://some/path/sshd_config.j2 -
template: jinja - default: password_auth: 'yes'

--sshd_config.j2-- ... PasswordAuthentication {{ password_auth }}
...


Laurence

On 2014-09-18 14:25, Florian Ermisch wrote: Hi Laurence,

for using pillar-data to decide which pillar-data to pass to the
minion I use includes with passed variables in pillar:

include: - networking: defaults: ipv4addr: 10.0.0.34/24

Then networking.sls is a template that will figure out the subnet
based on the IP and include a subnet-specific file with stuff like
gateway and DNS-servers.

I got to admit, I have no Idea if you can make this approach work
with ext_pillar. Maybe "Targeting minions by ext_pillar" is a
reasonable RFE and worth opening an issue on Github?

Regards, Florian

Am 18.09.2014 um 14:24 schrieb laurence: