Closed felskrone closed 8 years ago
@felskrone, thanks for the report. What version of salt are you using?
I was afraid you might ask that, rather old :-)
Salt: 2014.7.0
Python: 2.7.9 (default, Mar 1 2015, 12:57:24)
Jinja2: 2.7.3
M2Crypto: 0.21.1
msgpack-python: 0.4.2
msgpack-pure: Not Installed
pycrypto: 2.6.1
libnacl: Not Installed
PyYAML: 3.11
ioflo: Not Installed
PyZMQ: 14.4.0
RAET: Not Installed
ZMQ: 4.0.5
Mako: Not Installed
A saltmaster running with an apache-configured cherrypy_rest-api might break if the user/root has the "wrong" umask set. In my case that was '0026'.
The saltmaster is running and requests to the cherrypy-api are executed successfully. The master pings the minion and the minion returns 'true' to the master (thats in the logs). Its just the apache that keeps returning a 500 error without any error message in the logs (even in debug). The missing error message is due to
/usr/share/pyshared/salt/netapi/rest_cherrypy/app.py
not having a console-logger configured. If im not mistaken, WSGI only forwards errors on stderr to the error-log? Anyway, i think thats the problem, because thats how i finally managed to see an error in apaches error_log.
After restarting apache+master and sending curl-request, i finally got the error message:
A "permission denied" on a file the master created itself seemed really weird and led me to roots .bashrc where the umask was set to 0026 instead of the (debian-)default 0022. If root (re)starts the saltmaster with a "wrong" umask, the master inherits the umask and breaks.
Not many people will trip over this, but i think the required umask should be mentioned in the docs somewhere. This is sort of related to #10418 with umasks being scattered all over the place :-)