also sprach Michael Prokop <m...@debian.org> [2012.10.22.2229 +0200]: > > I am not running a minion on the host the master runs on, currently. > > Did you restart the salt process?
Yes, of course. The problem is not with the daemon. The problem is
that the salt CLI writes directly to the filesystem.
> Do you have the exact steps you did available for us so we can
> try to reproduce the issue?
Here you go, this is on a fresh system after installing salt-*
0.10.2-1~experimenal+1.
% sudo adduser --system --disabled-password --group nogroup salt
% sudo sed -i -e 's,^#interface:,interface:,;s,^#user:.*,user: salt,'
/etc/salt/master
% sudo /etc/init.d/salt-master start
[....] Starting salt master control daemon: salt-master[....] Starting
salt-master daemon: :[WARNING ] Starting the Salt Master
. ok
. ok
% ps aux | grep [s]alt
#10014
salt 20747 0.0 0.3 232800 15084 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20748 0.0 0.3 117952 14204 ? S 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20755 0.0 0.3 167128 14488 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20758 0.0 0.3 167396 14480 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20761 0.1 0.3 200048 14920 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20762 0.1 0.3 265588 14860 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20765 0.1 0.3 265588 14928 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20766 0.1 0.3 265588 14928 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
salt 20767 0.1 0.3 200052 14928 ? Sl 10:37 0:00
/usr/bin/python /usr/bin/salt-master -d
% sudo sed -i -e 's,^#master:.*,master: localhost,' /etc/salt/minion
% sudo /etc/init.d/salt-minion restart
[ ok ] Restarting salt minion control daemon: salt-minion[....] Stopping salt
minion control daemon ....
[ ok ] Starting salt-minion daemon: :.
. ok
This already creates the first problem, as the following is written
to the terminal by the backgrounded salt-master processes (which
should not happen, this should probably go to a log file instead):
Process MWorker-4:
#10012
Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in
_bootstrap
self.run()
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 431, in run
self.__bind()
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 369, in __bind
ret = self.serial.dumps(self._handle_payload(payload))
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 392, in
_handle_payload
'clear': self._handle_clear}[key](load)
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 399, in
_handle_clear
return getattr(self.clear_funcs, load['cmd'])(load)
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 1147, in _auth
with open(pubfn_pend, 'w+') as fp_:
IOError: [Errno 13] Permission denied:
'/etc/salt/pki/minions_pre/fishbowl.rw.madduck.net'
Because:
# ls -la /etc/salt/pki/minions_pre/fishbowl.rw.madduck.net
-rw-r--r-- 1 root root 796 Oct 24 09:35
/etc/salt/pki/minions_pre/fishbowl.rw.madduck.net
is not writeable by the master user (salt).
Moving on:
% sudo salt-key -A
% sudo -u salt salt \* test.ping
Could not access directory /var/cache/salt. Please give salt read permissions.
% sudo chown -R salt.nogroup /var/cache/salt
And now:
% salt \* test.ping
Could not access directory /var/cache/salt. Try running as user salt.
But first as root (to reproduce the actual problem):
% sudo salt \* test.ping
#2,10015
Process MWorker-8:
Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in
_bootstrap
self.run()
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 431, in run
self.__bind()
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 369, in __bind
ret = self.serial.dumps(self._handle_payload(payload))
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 392, in
_handle_payload
'clear': self._handle_clear}[key](load)
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 399, in
_handle_clear
return getattr(self.clear_funcs, load['cmd'])(load)
File "/usr/lib/python2.7/dist-packages/salt/master.py", line 1259, in
publish
os.makedirs(jid_dir)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied:
'/var/cache/salt/jobs/d3/35da8f5aa4774a5f7dfd2fe9c2b041'
(the CLI now hangs forever and must be ctrl-c'd)
The reason is that the salt CLI created
/var/cache/salt/jobs/d3/35da8f5aa4774a5f7dfd2fe9c2b041 and the
parent directories as root. Why doesn't it talk to the master or
a proxy via IPC and let the master (or the proxy) write the cache
files (if at all necessary)?
Trying to run as the salt user also does not work:
% sudo -u salt salt \* test.ping
Failed to connect to the Master, is the Salt Master running?
{}
(yes it is)
% sudo find /var/cache/salt -type f -ls
391025 4 -rw------- 1 salt nogroup 20 Oct 24 10:57
/var/cache/salt/jobs/59/100cbb040c965010e644a90fd6da05/jid
[…]
I cannot really explain this.
In any case, it seems that the master cannot just yet be run
non-root. The cleanest solution IMHO would be to let /usr/bin/salt
talk to the master not via the filesystem, but via an additional
socket in /tmp/.salt-unix.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
if you see an onion ring -- answer it!
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
