FAQ
I have the following pillar set up:

/srv/pillar/top.sls:
---------
base:
   - '*':
     - users

And then in the users folder:

/srv/pillar/users/init.sls:
---------
admins:
   - jsmith

jsmith:
   pub_keys:
     work: <key>
     laptop: <key>
   full_name: John Smith
   password: <hash>

And then the following in my states (/srv/salt/core/init.sls):


{% for admin in pillar.get('admins') %}
{{admin}}:
   group.present:
     - gid:
   user.present:
     - shell: /bin/bash
     - home: /home/{{admin}}
     - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
     - gid_from_name: True
     - groups:
       - sudo
       - admin
       - {{admin}}
     - password: {{ salt['pillar.get']('jsmith:password') }}
     - require:
         - group: {{admin}}
{% endfor %}

Is there a way to replace the hard coded name with {{ admin }} in the above
state that is replace {{ salt['pillar.get']('jsmith:full_name') }} with {{
salt['pillar.get']('{{ admin }}:full_name') }}?

I'm not sure if its related but when I run `salt '*' pillar.get jsmith`
from the saltmaster all but one of the minions returns jsmith. The other
doesn't return anything but will run the state declaration above without
issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

Any help or suggestions would be greatly appreciated.

Cheers,
Tyler

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

  • Warren Turkal at Oct 16, 2014 at 8:03 pm
    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a python dict
    (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your pillars.
    You should probably put it into a hierarchy since (a) pillar data exists in
    a flat namespace and (b) you can use that structure to iterate over the
    entries.

    Also, I would also encourage you to look at the scoping rules of jinja2
    especially in loops. It's probably not quite what you're expecting if you
    haven't used it much before.

    wt
    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in the
    above state that is replace {{ salt['pillar.get']('jsmith:full_name') }}
    with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get jsmith`
    from the saltmaster all but one of the minions returns jsmith. The other
    doesn't return anything but will run the state declaration above without
    issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    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.
  • Tyler Field at Oct 16, 2014 at 9:37 pm
    Hi Warren,

    The first option worked perfectly. My experience with jinja2 is limited to
    some basic front end stuff with the Django templating so I guess its time
    to review it a little more in depth.

    Could you clarify what you meant by putting 'jsmith' into a hierarchy? The
    basic idea was to maintain some users in different groups (admins, devs,
    etc) and then add them to the servers with the correct levels of access.

    Relatively new to Salt and still trying to feel my way around and am happy
    to hear how to do things better.

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 2:03 PM, Warren Turkal wrote:

    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a python dict
    (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your
    pillars. You should probably put it into a hierarchy since (a) pillar data
    exists in a flat namespace and (b) you can use that structure to iterate
    over the entries.

    Also, I would also encourage you to look at the scoping rules of jinja2
    especially in loops. It's probably not quite what you're expecting if you
    haven't used it much before.

    wt

    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in the
    above state that is replace {{ salt['pillar.get']('jsmith:full_name') }}
    with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get jsmith`
    from the saltmaster all but one of the minions returns jsmith. The other
    doesn't return anything but will run the state declaration above without
    issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Warren Turkal at Oct 16, 2014 at 10:16 pm
    like so:

    users: # <-- that is the top level of the user hierarchy
       - jsmith:
           group: users
           uid: 1000
       - wt:
           group: users
           uid: 1001

    Notice how I have all users inside another namespace so that they aren't
    sitting in the global namespace.

    wt
    On Thu, Oct 16, 2014 at 2:37 PM, Tyler Field wrote:

    Hi Warren,

    The first option worked perfectly. My experience with jinja2 is limited to
    some basic front end stuff with the Django templating so I guess its time
    to review it a little more in depth.

    Could you clarify what you meant by putting 'jsmith' into a hierarchy? The
    basic idea was to maintain some users in different groups (admins, devs,
    etc) and then add them to the servers with the correct levels of access.

    Relatively new to Salt and still trying to feel my way around and am happy
    to hear how to do things better.

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 2:03 PM, Warren Turkal wrote:

    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a python
    dict (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your
    pillars. You should probably put it into a hierarchy since (a) pillar data
    exists in a flat namespace and (b) you can use that structure to iterate
    over the entries.

    Also, I would also encourage you to look at the scoping rules of jinja2
    especially in loops. It's probably not quite what you're expecting if you
    haven't used it much before.

    wt

    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in the
    above state that is replace {{ salt['pillar.get']('jsmith:full_name')
    }} with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get jsmith`
    from the saltmaster all but one of the minions returns jsmith. The other
    doesn't return anything but will run the state declaration above without
    issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal

    --
    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.
  • Tyler Field at Oct 16, 2014 at 10:54 pm
    Warren,

    got it. Thanks, so this would mostly be to avoid namespace clashes when the
    pillars are flattened?

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 4:16 PM, Warren Turkal wrote:

    like so:

    users: # <-- that is the top level of the user hierarchy
    - jsmith:
    group: users
    uid: 1000
    - wt:
    group: users
    uid: 1001

    Notice how I have all users inside another namespace so that they aren't
    sitting in the global namespace.

    wt
    On Thu, Oct 16, 2014 at 2:37 PM, Tyler Field wrote:

    Hi Warren,

    The first option worked perfectly. My experience with jinja2 is limited
    to some basic front end stuff with the Django templating so I guess its
    time to review it a little more in depth.

    Could you clarify what you meant by putting 'jsmith' into a hierarchy?
    The basic idea was to maintain some users in different groups (admins,
    devs, etc) and then add them to the servers with the correct levels of
    access.

    Relatively new to Salt and still trying to feel my way around and am
    happy to hear how to do things better.

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 2:03 PM, Warren Turkal wrote:

    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a python
    dict (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your
    pillars. You should probably put it into a hierarchy since (a) pillar data
    exists in a flat namespace and (b) you can use that structure to iterate
    over the entries.

    Also, I would also encourage you to look at the scoping rules of jinja2
    especially in loops. It's probably not quite what you're expecting if you
    haven't used it much before.

    wt

    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in the
    above state that is replace {{ salt['pillar.get']('jsmith:full_name')
    }} with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get jsmith`
    from the saltmaster all but one of the minions returns jsmith. The other
    doesn't return anything but will run the state declaration above without
    issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.
  • Warren Turkal at Oct 17, 2014 at 6:40 am
    Yes.

    wt
    On Oct 16, 2014 3:54 PM, "Tyler Field" wrote:

    Warren,

    got it. Thanks, so this would mostly be to avoid namespace clashes when
    the pillars are flattened?

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 4:16 PM, Warren Turkal wrote:

    like so:

    users: # <-- that is the top level of the user hierarchy
    - jsmith:
    group: users
    uid: 1000
    - wt:
    group: users
    uid: 1001

    Notice how I have all users inside another namespace so that they aren't
    sitting in the global namespace.

    wt

    On Thu, Oct 16, 2014 at 2:37 PM, Tyler Field <tylerrfield@gmail.com>
    wrote:
    Hi Warren,

    The first option worked perfectly. My experience with jinja2 is limited
    to some basic front end stuff with the Django templating so I guess its
    time to review it a little more in depth.

    Could you clarify what you meant by putting 'jsmith' into a hierarchy?
    The basic idea was to maintain some users in different groups (admins,
    devs, etc) and then add them to the servers with the correct levels of
    access.

    Relatively new to Salt and still trying to feel my way around and am
    happy to hear how to do things better.

    Cheers,
    Tyler

    On Thu, Oct 16, 2014 at 2:03 PM, Warren Turkal <wt@signalfuse.com>
    wrote:
    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a python
    dict (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your
    pillars. You should probably put it into a hierarchy since (a) pillar data
    exists in a flat namespace and (b) you can use that structure to iterate
    over the entries.

    Also, I would also encourage you to look at the scoping rules of jinja2
    especially in loops. It's probably not quite what you're expecting if you
    haven't used it much before.

    wt

    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in the
    above state that is replace {{ salt['pillar.get']('jsmith:full_name')
    }} with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get
    jsmith` from the saltmaster all but one of the minions returns jsmith. The
    other doesn't return anything but will run the state declaration above
    without issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 Oct 18, 2014 at 6:56 am
    Hi Tyler,

    this also enables you to do a `salt $MINION pillar.items users` to get all the users your minion has enough details about to create accounts for at once.

    Regards, Florian

    Am 17. Oktober 2014 00:54:07 MESZ, schrieb Tyler Field <tylerrfield@gmail.com>:
    Warren,

    got it. Thanks, so this would mostly be to avoid namespace clashes when
    the
    pillars are flattened?

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 4:16 PM, Warren Turkal wrote:

    like so:

    users: # <-- that is the top level of the user hierarchy
    - jsmith:
    group: users
    uid: 1000
    - wt:
    group: users
    uid: 1001

    Notice how I have all users inside another namespace so that they aren't
    sitting in the global namespace.

    wt

    On Thu, Oct 16, 2014 at 2:37 PM, Tyler Field <tylerrfield@gmail.com>
    wrote:
    Hi Warren,

    The first option worked perfectly. My experience with jinja2 is
    limited
    to some basic front end stuff with the Django templating so I guess
    its
    time to review it a little more in depth.

    Could you clarify what you meant by putting 'jsmith' into a
    hierarchy?
    The basic idea was to maintain some users in different groups
    (admins,
    devs, etc) and then add them to the servers with the correct levels
    of
    access.

    Relatively new to Salt and still trying to feel my way around and am
    happy to hear how to do things better.

    Cheers,
    Tyler
    On Thu, Oct 16, 2014 at 2:03 PM, Warren Turkal wrote:

    It's jinja2. Does the following work?

    {{ salt['pillar.get'](admin + ':password') }}

    If that doesn't work, does this?

    {%- set admin_pass_pillar = '%s:password'|format(admin) %}
    {%- set admin_pass = salt['pillar.get'](admin_pass_pillar) %}

    Then use {{ admin_pass }} for the password.

    You could also do the following:
    {{ set admin_data = salt['pillar.get'](admin) }}

    Now you have a dict admin_data that you can use similarly to a
    python
    dict (e.g. admin_data.get('password', '')).

    Also, you probably shouldn't put 'jsmith' at the top level of your
    pillars. You should probably put it into a hierarchy since (a)
    pillar data
    exists in a flat namespace and (b) you can use that structure to
    iterate
    over the entries.

    Also, I would also encourage you to look at the scoping rules of
    jinja2
    especially in loops. It's probably not quite what you're expecting
    if you
    haven't used it much before.

    wt

    On Thursday, October 16, 2014 11:54:02 AM UTC-7, Tyler Field wrote:

    I have the following pillar set up:

    /srv/pillar/top.sls:
    ---------
    base:
    - '*':
    - users

    And then in the users folder:

    /srv/pillar/users/init.sls:
    ---------
    admins:
    - jsmith

    jsmith:
    pub_keys:
    work: <key>
    laptop: <key>
    full_name: John Smith
    password: <hash>

    And then the following in my states (/srv/salt/core/init.sls):


    {% for admin in pillar.get('admins') %}
    {{admin}}:
    group.present:
    - gid:
    user.present:
    - shell: /bin/bash
    - home: /home/{{admin}}
    - fullname: {{ salt['pillar.get']('jsmith:full_name')}}
    - gid_from_name: True
    - groups:
    - sudo
    - admin
    - {{admin}}
    - password: {{ salt['pillar.get']('jsmith:password') }}
    - require:
    - group: {{admin}}
    {% endfor %}

    Is there a way to replace the hard coded name with {{ admin }} in
    the
    above state that is replace {{
    salt['pillar.get']('jsmith:full_name')
    }} with {{ salt['pillar.get']('{{ admin }}:full_name') }}?

    I'm not sure if its related but when I run `salt '*' pillar.get
    jsmith`
    from the saltmaster all but one of the minions returns jsmith. The
    other
    doesn't return anything but will run the state declaration above
    without
    issue (e.g `salt 'minion_not_returning_jsmith' state.sls core`).

    Any help or suggestions would be greatly appreciated.

    Cheers,
    Tyler
    --
    You received this message because you are subscribed to a topic in
    the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to a topic in
    the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/JKLqewUz_Vc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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.

    --
    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 @
postedOct 16, '14 at 6:54p
activeOct 18, '14 at 6:56a
posts7
users3

People

Translate

site design / logo © 2022 Grokbase