FAQ
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

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Florian Ermisch at Sep 18, 2014 at 1:25 pm
    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:
    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


    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laurence at Sep 18, 2014 at 2:04 pm
    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:
    -----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:
    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
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Laurence at Sep 18, 2014 at 2:21 pm
    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 }}
    ...
    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
    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:
    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
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Florian Ermisch at Sep 19, 2014 at 12:15 pm
    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!

    Am 18.09.2014 um 16:21 schrieb 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 }} ...
    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

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


    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Florian Ermisch at Sep 19, 2014 at 12:12 pm
    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,

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


    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedSep 18, '14 at 12:25p
activeSep 19, '14 at 12:15p
posts6
users2

2 users in discussion

Florian Ermisch: 3 posts Laurence: 3 posts

People

Translate

site design / logo © 2022 Grokbase