Salt: win_dacl module stacktrace: NameError: name 'ntsecuritycon' is not defined
Description of Issue/Question
[ERROR ] Failed to import module win_dacl, this is due most likely to a syntax error:
Traceback (most recent call last):
File "/opt/salt/lib/python2.7/site-packages/salt/loader.py", line 1253, in _load_module
), fn_, fpath, desc)
File "/opt/salt/lib/python2.7/site-packages/salt/modules/win_dacl.py", line 39, in <module>
class daclConstants(object):
File "/opt/salt/lib/python2.7/site-packages/salt/modules/win_dacl.py", line 47, in daclConstants
FILE_ALL_ACCESS = (ntsecuritycon.STANDARD_RIGHTS_REQUIRED | ntsecuritycon.SYNCHRONIZE | 0x1ff)
NameError: name 'ntsecuritycon' is not defined
Steps to Reproduce Issue
running a salt-call state.highstate
Versions Report
[root@testn /opt/salt]# ./bin/salt-call --versions-report
Salt Version:
Salt: 2016.3.0rc1-96-gfe86a3d
Dependency Versions:
Jinja2: 2.8
M2Crypto: Not Installed
Mako: Not Installed
PyYAML: 3.11
PyZMQ: 14.4.1
Python: 2.7.11 (default, Mar 18 2016, 13:38:08)
RAET: 0.6.5
Tornado: 4.3
ZMQ: 4.1.3
cffi: Not Installed
cherrypy: 3.8.0
dateutil: 2.4.0
gitdb: 0.6.4
gitpython: 1.0.2
ioflo: 1.5.1
libgit2: Not Installed
libnacl: 1.4.4
msgpack-pure: Not Installed
msgpack-python: 0.4.7
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: 2.0.2
smmap: 0.9.0
timelib: 0.2.4
System Versions:
dist:
machine: i86pc
release: 5.11
system: SunOS
version: Not Installed
sjorge
All 27 comments
@sjorge, thanks for reporting. I can confirm this on linux at the head of develop.
$ git fetch saltstack
remote: Counting objects: 543, done.
remote: Total 543 (delta 375), reused 375 (delta 375), pack-reused 168
Receiving objects: 100% (543/543), 164.43 KiB | 23.00 KiB/s, done.
Resolving deltas: 100% (415/415), completed with 239 local objects.
From https://github.com/saltstack/salt
2d1f2a0..ba5bf62 2015.5 -> saltstack/2015.5
b9d0336..c72ab6a 2015.8 -> saltstack/2015.8
fb6d5fa..fe86a3d 2016.3 -> saltstack/2016.3
46712f7..f267b7b develop -> saltstack/develop
$ git rebase saltstack/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to saltstack/develop.
$ python salt/modules/win_dacl.py
Traceback (most recent call last):
File "salt/modules/win_dacl.py", line 39, in <module>
class daclConstants(object):
File "salt/modules/win_dacl.py", line 47, in daclConstants
FILE_ALL_ACCESS = (ntsecuritycon.STANDARD_RIGHTS_REQUIRED | ntsecuritycon.SYNCHRONIZE | 0x1ff)
NameError: name 'ntsecuritycon' is not defined
Ping @sbreidba.
jfindlay
on 21 Mar 2016
I can also confirm this occurs on 2015.8.8. I upgraded an Ubuntu 14.04 box and started seeing this issue. I'll try that patch above to see if it fixes it.
jakehilton
on 23 Mar 2016
Yes seems to fix that.. and I did see it was merged into the 2015.8 branch. Really hoping a stable of 2015.8.8 hits soon. :)
jakehilton
on 23 Mar 2016
seeing this in 2015.8.8 that was just installed from repo.saltstack.com.
shawnbutts
on 23 Mar 2016
Upgraded to 2015.8.8 today and also seeing this error on each minion run.
anonymousobject
on 23 Mar 2016
This was fixed in the 2015.8 branch but didn't make it in for the 2015.8.8 tag, sorry for the annoyance.
It's fixed at the head of the 2015.8 and 2016.3 branches and also on develop. The fix will be included in the 2015.8.9 release, currently targeted for May.
meggiebot
on 24 Mar 2016
That is going to be painful for anyone running on non-windows. The logs will be full of mis-information which is not great. Consider maybe pushing a 2015.8.8.1 out for sanity sake? If not I'll just fork it and apply the fix and move on with my own hosted repo.. which is less desirable. May seems like a ways out to fix such an error.
jakehilton
on 24 Mar 2016
You can grab the fixed module from the 2015.8 branch here add it into _modules/ folder in the root of your state dir
sjorge
on 24 Mar 2016
This is not the first time this sort of thing has happened. The "KNOWN ISSUE IN BOTO_*" section of https://docs.saltstack.com/en/latest/topics/releases/2015.8.5.html is an example.
As a community member, what can I do to help prevent this from happening again.
As a user, I find it unacceptable to wait 1+ months for such a simple fix that just missed some arbitrary cutoff.
shawnbutts
on 24 Mar 2016
Of course a manual fix is possible.. I'm just thinking of all the people who install on non-windows and start seeing that error immediately. Doesn't look good for the product.
jakehilton
on 24 Mar 2016
It's absolutely unacceptable. We're working on patched 2015.8.8 packages with the fix for this and fixes for a few other issues.
meggiebot
on 24 Mar 2016
@jakehilton: I am that new user. I started using Salt just in time to get bitten by the BOTO issue, and the latest upgrade is now causing this issue. At the moment I'm feeling very nervous about my decision to use Salt in a client's infrastructure.
I guess I need to go learn how this _modules thing is supposed to work...
ralphrodkey
on 28 Mar 2016
@ralphrodkey: well if you don't have any windows minions, you can also disable the module completely!
Just add the following to your minion configuration:
disable_modules:
- win_dacl
Just a suggestion since issues like this have plagued a large number of releases recently, could you add a pre-release test that a plain salt-call state.highstate -l warning >/dev/null on a minion without any states doesn't have anything written to stderr? Since errors are logged to stderr this will ensure there's no warnings or higher severity logging messages just from importing modules.
thusoy
on 29 Mar 2016
A patched version of 2015.8.8 that includes the fix for this issue is now available on repo.saltstack.com.
https://docs.saltstack.com/en/latest/topics/releases/2015.8.8.html#salt-2015-8-8-2
meggiebot
on 29 Mar 2016
Will 2015.8.8.2 also get it's own tag on the releases page? https://github.com/saltstack/salt/releases
Glad to see this made it out.
Thanks!
jakehilton
on 30 Mar 2016
@jakehilton it will not, we patched the packages and did not create a new tag.
meggiebot
on 4 Apr 2016
@meggiebot So bootstrap folks will be left out in the cold? :) I worry that people will still hit the old 2015.8.8 branch without the fixes if they install outside of the repo.saltstack.com repo.. say using the bootstrap method unless there is a way to specify the proper build.
jakehilton
on 4 Apr 2016
@jakehilton there is a way to specify the proper build through boostrap and it's outlined on the repo.saltstack.com website (see "Pin to Minor Release" tab for Linux packages). But yes, people may still get the older version if they don't use that method.
meggiebot
on 6 Apr 2016
@meggiebot I'm afraid you misunderstand me. Please see here for an explanation of what bootstrapping means. https://github.com/saltstack/salt-bootstrap
Look under the "Install using curl" heading.. there is a code block outlining "If you want to install a specific release version (based on the Git tags)". That will fail with your current implementation. It shouldn't be hard to just tag another version.
jakehilton
on 6 Apr 2016
@jakehilton Sorry for the confusion. You are correct--with boostrap you can choose latest or stable and you will get the 2015.8.8-2 release since it is the most recent, but you can't pin to a specific version without a tag.
meggiebot
on 7 Apr 2016
See this stack trace every time when try to run salt-call with non-existing module. Salt version 2015.8.8
aleksmm
on 8 Apr 2016
@aleksmm are you on version 2015.8.8.2 ?
meggiebot
on 8 Apr 2016
salt-minion --versions-report
Salt Version:
Salt: 2015.8.8
Dependency Versions:
Python: 2.6.8 (unknown, Mar 15 2016, 21:23:59)
ZMQ: 4.0.5
--cut--
System Versions:
dist: redhat 6.5.0 xenenterprise
machine: x86_64
release: 3.10.0+2
system: XenServer 6.5.0 xenenterprise
On Fri, Apr 8, 2016 at 6:02 PM, Meggie Woodfield [email protected]
wrote:
@aleksmm https://github.com/aleksmm are you on version 2015.8.8.2 ?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/saltstack/salt/issues/32004#issuecomment-207468676
aleksmm
on 8 Apr 2016
@meggiebot Just upgraded to 2015.8.8.2 on this host from saltstack repo and issue is gone.
aleksmm
on 8 Apr 2016
meggiebot
on 8 Apr 2016
Very nice! Thank you!
jakehilton
on 11 Apr 2016
Related issues
twangboy
·
3Comments
sfozz
·
3Comments
layer3switch
·
3Comments
Arguros
·
3Comments
nixjdm
·
3Comments
Most helpful comment
It's absolutely unacceptable. We're working on patched 2015.8.8 packages with the fix for this and fixes for a few other issues.