Best way to do this in salt?

[laurence]

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
'I@xcat: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

[Florian Ermisch]

-----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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUGt08AAoJECgjvD+8219lbqAH/0x5Iq8ZLPSHRhjeNgs4LYkG
pjdIEcDxGS5dH78tdSwGHH/6bYVKxlY87FZpGwsao43lx93iIXxmieMWWzmIuNzV
QF8g7zU+77pg9QiNf6F8Rt8G92+xc+7QfZjqkZ3DWjjDv7wn9mzo2pnyUtzCNqop
kO7Q4Ob8YgvY55SfY0z2Ayw/R129KJzH/sMUX7unlJwJ9FPlX9WrfWsbn4kgcIeb
ODwuzB02HyOOkaWvgVr4AlwYAaWa32LAvuhC3WxbFYLfdOFCLg27HOn2IkWAijXH
a0c7C6JoXwyuZcTIcmuHd9+i7ZP/pIGaJ5jiINTpTfTNJh/sE+vWqVCemmDIUr4=
=FcR5
-----END PGP SIGNATURE-----

[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

[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 }}
...

[Florian Ermisch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey Laurence,

hmmmmmmm... maybe it will be easier using the augeas.change state [0]
instead of a template for sshd_config then?

The augeas-lens for sshd_config has support for match-sections (see
[1], under "More advanced usage") so one state could set-up the Matches
and another one could set the "PasswordAuthentication no" bit.
Augeas would parse the sshd_config and only check if the bits it's
supposed to check/set are correct so your won't see changes everytime
you call the state.

On most distributions you just have to install `python-augeas` (and
maybe libpython2.7) and restart the minion to enable the module.
Then you could use states like this...:

sshd_config_Matches:
augeas.change:
- context: /files/etc/ssh/sshd_config/
- changes:
- set Match[1]/Condition/User "foo"
- set Match[1]/Settings/X11Forwarding "yes"

...and this:

sshd_config_no_passwd_auth:
augeas.set:
- context: /files/etc/ssh/sshd_config/
- changes:
- set PasswordAuthentication no

Kind Regards, Florian

[0]
http://docs.saltstack.com/en/latest/ref/states/all/salt.states.augeas.html
[1] http://augeas.net/docs/references/lenses/files/sshd-aug.html

Am 18.09.2014 um 16:04 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,

iQEcBAEBCgAGBQJUHB2RAAoJECgjvD+8219lHgAIAIKu29VhLHTxKNnz6vtDXfPM
rysMn+wHlXAWxYNZnm9wZ5S0XVxaE84eR+5s5/zsBJ4H/eJX/Zeyv2Wjwk0p2AEL
ATXsY42Zn+/8GyoGsUjKTvGanV3rVvUiBIMTYf1MfNtlkRyZuLw08+6wBWXeI447
xB4iTXtFMBlYhvDlET3GD6KaIj+W9WqbAFPtMeLtck9wCQnKeM02Qbi3LMPzabna
OrhXSTqyZaxQDYmnkVX8elnmwkWZRrFRwtZbymKDMLk6+onVj+t/MVB7lmUcruKL
qonC+vkZcwwKjrx3wR/wj09GV9iqvPAuEXOEFGdh+QfFbeEXhMHR3wvlcqJjg9I=
=hA3z
-----END PGP SIGNATURE-----

[Florian Ermisch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ah, crap, when I first took a quick glance at your mails last night
I've thought this one would just contain some output like an error
message so I was still thinking this problem needs to be solved ^^"

That's a nice solution, too!

iQEcBAEBCgAGBQJUHB53AAoJECgjvD+8219luacIAIggSflm1fHkb+RdY0cX8ryi
q2l9FjQbpcbOxSNqaPpSiQYfYxtvNG1MSw2wGxfPdEGzaaspOJ3Ka2BIn5qx8Byg
tJT1KHNGFU0dboojb3AgGV7nQkdIMbBjAaTi7sCjnN8vltTO7gccUfxMjBtLwV2J
V6v/tEE1tcenMhTSFRjeqXJ8ZTD8tGkUwm4zarT6FKITY6H5AZIVWH6A9cRJzvdc
0ylKhUHU1T2JIWmOTrTMMCGoCLRc+vVF0SzXYkG2yNm2UHwnYmQPEPeqfsZ0Z1Dm
9ZiN0RpTSvqaPVVU5xK1NmVnT77wuL8oUflEE7k7b86cbY0fpnZYtoeOmsMzN6k=
=0GY+
-----END PGP SIGNATURE-----