FAQ
Hello,
I've recently started working with salt, and I was attempting to create a
state file to manage a number registry settings on a Windows server. I'm
pretty sure I've got the syntax down, but every time I apply it, I get the
error below.

[INFO ] Running state [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\
Lsa\DisableDomainCreds] at time 18:33:13.783000
[INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\Lsa\DisableDomainCreds
[ERROR ] An exception occurred in this state: Traceback (most recent call
last):
  File "salt/state.py", line 1379, in call
  File "salt/states/reg.py", line 42, in present
  File "salt/states/reg.py", line 20, in _parse_key
IndexError: pop from empty list

I do see a commit in the 2014.1 branch on 4 Apr 2014 that mentions fixing a
bug in _parse_key function. Has that commit made its way into the 2014.1
Windows package? I've tried both the 2014.1.7 and 2014.1.10 packages, and
they both generate the same error.

Here's the content from the state file:

#The system must be configured to prevent the storage of passwords and
credentials
CCE-23358-5:
   reg:
     - present
     - name:
'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds'
     - value: '1'
     - vtype: REG_DWORD
     - reflection: False

I'm really new to salt, so please forgive me if I'm missing something
really obvious... :)

Thanks,
-Loren

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

  • Loren Gordon at Aug 8, 2014 at 9:45 pm
    Aha, I'm getting closer! I found that if I double up the backslashes then I
    can get past the 'pop from empty list' error. However, now I've run into a
    couple new problems... When 'vtype' is 'REG_DWORD', if I wrap the 'value'
    in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords and
    credentials
    CCE-23358-5:
       reg:
         - present
         - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
         - value: '1'
         - vtype: REG_DWORD
         - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most recent call
    last):
       File "salt/state.py", line 1379, in call
       File "salt/states/reg.py", line 54, in present
       File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the single
    quotes from around the value, then it sometimes sets the reg key properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
       reg:
         - present
         - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
         - value: 0
         - vtype: REG_DWORD
         - reflection: False

    will claim the key is already configured, as seen below, but the reg key
    does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
       reg:
         - present
         - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
         - value: 1
         - vtype: REG_DWORD
         - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
                   ----------
                   reg:
                       configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state file
    results in salt claiming the value is configured to 0, but it's not, it's
    still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
       reg:
         - present
         - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
         - value: 0
         - vtype: REG_DWORD
         - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
                   ----------
                   reg:
                       configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems something weird
    is going on when trying to set a REG_DWORD to 0.

    -Loren

    --
    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.
  • Loren Gordon at Aug 8, 2014 at 9:52 pm
    Bah, that second failure case is actually ok. I was working on two keys and
    was modifying one while looking in the registry at the other. Sorry about
    that.

    But the first failure case I described is definitely an issue.

    -Loren


    On Friday, August 8, 2014 5:45:32 PM UTC-4, Loren Gordon wrote:

    Aha, I'm getting closer! I found that if I double up the backslashes then
    I can get past the 'pop from empty list' error. However, now I've run
    into a couple new problems... When 'vtype' is 'REG_DWORD', if I wrap the
    'value' in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords and
    credentials
    CCE-23358-5:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
    - value: '1'
    - vtype: REG_DWORD
    - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most recent
    call last):
    File "salt/state.py", line 1379, in call
    File "salt/states/reg.py", line 54, in present
    File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the single
    quotes from around the value, then it sometimes sets the reg key properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    will claim the key is already configured, as seen below, but the reg key
    does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 1
    - vtype: REG_DWORD
    - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state file
    results in salt claiming the value is configured to 0, but it's not, it's
    still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems something
    weird is going on when trying to set a REG_DWORD to 0.

    -Loren
    --
    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 Aug 8, 2014 at 10:02 pm
    Hi Loren,

    my guess is there's some logic interpreting 0 as False in the module involved. Something like

    value = read_registry(regiztry_key)
    if value:
          do_stuff_to_registry

    so your 0 in the registry looks like the key doesn't exist and passing 0 to the module makes the module ignore the task of setting the value b/c there's nothing to set.

    Good Luck hunting this bug down!

    Florian
    On 8. August 2014 23:45:32 MESZ, Loren Gordon wrote:
    Aha, I'm getting closer! I found that if I double up the backslashes
    then I
    can get past the 'pop from empty list' error. However, now I've run
    into a
    couple new problems... When 'vtype' is 'REG_DWORD', if I wrap the
    'value'
    in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords and
    credentials
    CCE-23358-5:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
    - value: '1'
    - vtype: REG_DWORD
    - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most recent
    call
    last):
    File "salt/state.py", line 1379, in call
    File "salt/states/reg.py", line 54, in present
    File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the single

    quotes from around the value, then it sometimes sets the reg key
    properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    will claim the key is already configured, as seen below, but the reg
    key
    does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\
    Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 1
    - vtype: REG_DWORD
    - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state
    file
    results in salt claiming the value is configured to 0, but it's not,
    it's
    still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems something
    weird
    is going on when trying to set a REG_DWORD to 0.

    -Loren

    --
    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.
  • Loren Gordon at Aug 9, 2014 at 12:16 am
    Ahh, that does seem to be it. I just reviewed the code in the 2014.1 and
    2014.7 branches. In 2014.1, the read_key function in the reg.py module does
    return False if there's an exception (as it would, presumably, if the key
    didn't yet exist). The reg.present function that calls read_key compares
    the return value to the value I pass in, so we get `if 0 == False`
    resolving to True and it then returns without setting the key.

    In 2014.7, read_key returns 'None' on exception. I'm not sure if 0 == None?

    Thanks for your help!

    -Loren

    On Friday, August 8, 2014 6:02:22 PM UTC-4, Florian Ermisch wrote:

    Hi Loren,

    my guess is there's some logic interpreting 0 as False in the module
    involved. Something like

    value = read_registry(regiztry_key)
    if value:
    do_stuff_to_registry

    so your 0 in the registry looks like the key doesn't exist and passing 0
    to the module makes the module ignore the task of setting the value b/c
    there's nothing to set.

    Good Luck hunting this bug down!

    Florian

    On 8. August 2014 23:45:32 MESZ, Loren Gordon <lo...@fleet-it.com
    <javascript:>> wrote:
    Aha, I'm getting closer! I found that if I double up the backslashes then
    I can get past the 'pop from empty list' error. However, now I've run
    into a couple new problems... When 'vtype' is 'REG_DWORD', if I wrap the
    'value' in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords and
    credentials
    CCE-23358-5:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
    - value: '1'
    - vtype: REG_DWORD
    - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most recent
    call last):
    File "salt/state.py", line 1379, in call
    File "salt/states/reg.py", line 54, in present
    File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the single
    quotes from around the value, then it sometimes sets the reg key properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    will claim the key is already configured, as seen below, but the reg key
    does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 1
    - vtype: REG_DWORD
    - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state file
    results in salt claiming the value is configured to 0, but it's not, it's
    still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems something
    weird is going on when trying to set a REG_DWORD to 0.

    -Loren
    --
    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 Aug 9, 2014 at 6:17 am
    And once again for the list...
    On 9. August 2014 08:15:12 MESZ, Florian Ermisch wrote:
    Good morning/TZAG,

    0, None and False all evaluate to False in a boolean context so
    comparing those can be tricky. If Windows' registry doesn't allow unset
    values but also has booleans the function for getting those should
    return None for inexistent keys instead so one could differentiate
    between an inexistent and a value evaluating to False:

    reg_val = reg_get(reg_key)
    if reg_val is None:
    # handle inexistent reg_key
    elif reg_val != should_be:
    # handle reg_key with wrong value
    else:
    # reg_key already set the
    # way it should be

    Things will get more complicated if the registry allows existing keys
    w/ unset values. I guess the function has to return a dict { key: value
    } where value is None for an existing, unset registry key and only None
    for an inexistent registry key then.

    Regards, Florian
    (still barely awake)
    On 9. August 2014 02:08:19 MESZ, Loren Gordon wrote:
    Ahh, that does seem to be it. I just reviewed the code in the 2014.1
    and
    2014.7 branches. In 2014.1, the read_key function in the reg.py module
    does
    return False if there's an exception (as it would, presumably, if the
    key
    didn't yet exist). The reg.present function that calls read_key
    compares
    the return value to the value I pass in, so we get `if 0 == False`
    resolving to True and it then returns without setting the key.

    In 2014.7, read_key returns 'None' on exception. I'm not sure if 0 ==
    None?

    Thanks for your help!

    -Loren

    On Friday, August 8, 2014 6:02:22 PM UTC-4, Florian Ermisch wrote:

    Hi Loren,

    my guess is there's some logic interpreting 0 as False in the module
    involved. Something like

    value = read_registry(regiztry_key)
    if value:
    do_stuff_to_registry

    so your 0 in the registry looks like the key doesn't exist and passing 0
    to the module makes the module ignore the task of setting the value b/c
    there's nothing to set.

    Good Luck hunting this bug down!

    Florian

    On 8. August 2014 23:45:32 MESZ, Loren Gordon <lo...@fleet-it.com
    <javascript:>> wrote:
    Aha, I'm getting closer! I found that if I double up the backslashes
    then
    I can get past the 'pop from empty list' error. However, now I've
    run
    into a couple new problems... When 'vtype' is 'REG_DWORD', if I wrap
    the
    'value' in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords
    and
    credentials
    CCE-23358-5:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
    - value: '1'
    - vtype: REG_DWORD
    - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for
    HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most
    recent
    call last):
    File "salt/state.py", line 1379, in call
    File "salt/states/reg.py", line 54, in present
    File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the
    single
    quotes from around the value, then it sometimes sets the reg key
    properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key
    already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    will claim the key is already configured, as seen below, but the reg
    key
    does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\
    Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 1
    - vtype: REG_DWORD
    - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state
    file
    results in salt claiming the value is configured to 0, but it's not,
    it's
    still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems
    something
    weird is going on when trying to set a REG_DWORD to 0.

    -Loren
    --
    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.
  • Loren Gordon at Aug 13, 2014 at 2:01 am
    In case anyone else is having this problem and happens across this thread,
    today I tested the reg.py code in the 2014.7 branch and it doesn't have
    this bug. It also doesn't have the problem parsing single backslashes in
    the reg key path. In fact, in that branch, if you use double backslashes
    then you'll get another error, key/path not found.

    Thanks,
    -Loren

    On Saturday, August 9, 2014 2:17:48 AM UTC-4, Florian Ermisch wrote:

    And once again for the list...

    On 9. August 2014 08:15:12 MESZ, Florian Ermisch <
    florian...@alumni.tu-berlin.de <javascript:>> wrote:
    Good morning/TZAG,

    0, None and False all evaluate to False in a boolean context so
    comparing those can be tricky. If Windows' registry doesn't allow unset
    values but also has booleans the function for getting those should
    return None for inexistent keys instead so one could differentiate
    between an inexistent and a value evaluating to False:

    reg_val = reg_get(reg_key)
    if reg_val is None:
    # handle inexistent reg_key
    elif reg_val != should_be:
    # handle reg_key with wrong value
    else:
    # reg_key already set the
    # way it should be

    Things will get more complicated if the registry allows existing keys
    w/ unset values. I guess the function has to return a dict { key: value
    } where value is None for an existing, unset registry key and only None
    for an inexistent registry key then.

    Regards, Florian
    (still barely awake)
    On 9. August 2014 02:08:19 MESZ, Loren Gordon <lo...@fleet-it.com
    <javascript:>> wrote:
    Ahh, that does seem to be it. I just reviewed the code in the 2014.1 and
    2014.7 branches. In 2014.1, the read_key function in the reg.py module does
    return False if there's an exception (as it would, presumably, if the key
    didn't yet exist). The reg.present function that calls read_key compares
    the return value to the value I pass in, so we get `if 0 == False`
    resolving to True and it then returns without setting the key.

    In 2014.7, read_key returns 'None' on exception. I'm not sure if 0 ==
    None?

    Thanks for your help!

    -Loren

    On Friday, August 8, 2014 6:02:22 PM UTC-4, Florian Ermisch wrote:

    Hi Loren,

    my guess is there's some logic interpreting 0 as False in the module
    involved. Something like

    value = read_registry(regiztry_key)
    if value:
    do_stuff_to_registry

    so your 0 in the registry looks like the key doesn't exist and passing 0
    to the module makes the module ignore the task of setting the value b/c
    there's nothing to set.

    Good Luck hunting this bug down!

    Florian

    On 8. August 2014 23:45:32 MESZ, Loren Gordon <lo...@fleet-it.com>
    wrote:
    Aha, I'm getting closer! I found that if I double up the backslashes
    then I can get past the 'pop from empty list' error. However, now I've
    run into a couple new problems... When 'vtype' is 'REG_DWORD', if I wrap
    the 'value' in single quotes, then I get a type error. i.e. This code:

    #The system must be configured to prevent the storage of passwords and
    credentials
    CCE-23358-5:
    reg:
    - present
    - name:
    'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\DisableDomainCreds'
    - value: '1'
    - vtype: REG_DWORD
    - reflection: False

    Results in this error:

    [INFO ] Executing state reg.present for HKEY_LOCAL_MACHINE\\System\\
    CurrentControlSet\\Control\\Lsa\\FIPSAlgorithmPolicy\\Enabled
    [ERROR ] An exception occurred in this state: Traceback (most recent
    call last):
    File "salt/state.py", line 1379, in call
    File "salt/states/reg.py", line 54, in present
    File "salt/modules/reg.py", line 116, in set_key
    ValueError: Could not convert the data to the specified type.

    Ok, I can understand that may be a syntax error. If I remove the single
    quotes from around the value, then it sometimes sets the reg key properly.
    One failure case is when the key doesn't yet exist, and the value in
    reg.present is set to 0 (no quotes). Then salt claims the key already
    exists and doesn't actually create the key! Oops... i.e. This code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    will claim the key is already configured, as seen below, but the reg
    key does not actually exist.

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT
    \\Terminal Services\\fAllowToGetHelp is already configured
    Changes:
    ----------

    Flipping the value to 1 and salt will create the key. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 1
    - vtype: REG_DWORD
    - reflection: False

    Result (and the key really does exist):

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 1
    ----------

    The second failure case is setting the value back to 0 in the state
    file results in salt claiming the value is configured to 0, but it's not,
    it's still 1 in the registry. Code:

    #Solicited Remote Assistance must not be allowed
    CCE-25590-1:
    reg:
    - present
    - name: 'HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows
    NT\\Terminal Services\\fAllowToGetHelp'
    - value: 0
    - vtype: REG_DWORD
    - reflection: False

    Result:

    ----------
    ID: CCE-25590-1
    Function: reg.present
    Name: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\
    Terminal Services\\fAllowToGetHelp
    Result: True
    Comment:
    Changes:
    ----------
    reg:
    configured to 0
    ----------

    But like I said, it's not 0 now, it's still 1. So, it seems something
    weird is going on when trying to set a REG_DWORD to 0.

    -Loren
    --
    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 @
postedAug 8, '14 at 7:11p
activeAug 13, '14 at 2:01a
posts7
users2

2 users in discussion

Loren Gordon: 5 posts Florian Ermisch: 2 posts

People

Translate

site design / logo © 2022 Grokbase