Running salt-master and salt-minion in parallel

[Ulrich Dangel]

Hi,

I stumbled upon a small problem when salt-master and salt-minion are
installed on the same machine and salt-master is run as non root user.

Problem
========

Currently salt-master and salt-minion share the pki directory per
default. This is works great unless salt-minion and salt-master run as
different users.

On startup salt-{master,minion} check and fix the permissions for
pki_dir, cachedir and logfile. If salt-master is executed under a non root
user all permissions will be adjusted accordingly. If salt-minion is
started afterwards the permissions will be fixed and adjusted for the
root user. This means salt-master can no longer read or write to pki_dir
and cachedir.

Solutions
=========

I don't know what the best solution is so please suggest or vote for a
specific solution. As I wanted to change the salt-package in debian to
run salt-master under a non-root user i would also like to get your
input how what the debian package should do per default.

* One possible solution is to change the default pki_dir and chachedir
for master and minion, e.g. /var/cache/salt/{master,minion} and
/etc/salt/pki/{master,minion}
- IMO the best solution from a user POV but will/can breake old
installations

* Just document the necessary changes and adjustments and let users
figure it out themselfs.
- This would require a modified master and minion config in debian as
we would have to change the defaults as we want to run salt-master as
non-root

* Only support root user for salt-master


cheers,
Ulrich
--
twitter: @mr_ud | identica: @mru
IRCNet: mru | freenode: mrud

[Jeff Schroeder]

You missed one :)

Make the minion not break perms. I see a good use case where
salt-master runs as user/group salt:salt. Then (in theory) you could
chown /etc/salt/pki over to salt:salt and Set the perms to 750. Then
if you wanted to give a user the ability to runs salt as themselves
without sudo, they could be added to the salt group and as a result,
would have access to the keys. This would be a relatively simple code
change I believe on the verify stuff that checks permissions.

Thanks for taking the initiative on this. Good stuff!

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

[Thomas S Hatch]

Yes, this is a problem, the problem with solution 1 is that salt supports running multiple master and minions on one piece of hardware, and they could all be running as different users.

I like 2, since it does not begin to introduce constraints about how the systems are run

3, is right out :) because in the long run I would like it very much if the salt master was never run as root.

In the end, I think that the solution is to document this, and then when a user runs salt, if they don't have rights to the primary locations then it should fall back to a location in the user's home directory

thoughts?

[Ulrich Dangel]

> Yes, this is a problem, the problem with solution 1 is that salt supports
> running multiple master and minions on one piece of hardware, and they
> could all be running as different users.
>
> I like 2, since it does not begin to introduce constraints about how the
> systems are run
>
> 3, is right out :) because in the long run I would like it very much if the
> salt master was never run as root.
>
> In the end, I think that the solution is to document this, and then when a
> user runs salt, if they don't have rights to the primary locations then it
> should fall back to a location in the user's home directory
>
> thoughts?

I don't really like 2 (just document it) as i wanted to run salt-master
per default as a non-root user in Debian. This would mean we would have
to adjust pkidir/cache_dir for the minion&master but i'd like to change
as less as possible. I think the best solution is to change the
verification as Jeff suggested, e.g:

1) If the directory/file exists and is readable by the minion do nothing
2) If the director/file exists and is not readable - abort and log
3) If the directory/file does not exist create one with the correct
permissions


Ulrich

[Jeff Schroeder]

Text by Jeff, typos by iPhone

Awesome idea Tom! What about:

    ~/.salt/minionid.pem

[Thomas S Hatch]

I will go with that one. The checks will need to be a little more granular then they are are now, but that should not be a big deal, and we can also have a fallback for the minions to resort to home directory files if the global ones cannot be reached.

Can you please file an issue for this so I remember to get to it?

[Ulrich Dangel]

On 06/23/12 00:36, Jeff Schroeder wrote:

>> Yes, this is a problem, the problem with solution 1 is that salt supports running multiple master and minions on one piece of hardware, and they could all be running as different users.
>>
>> I like 2, since it does not begin to introduce constraints about how the systems are run
>>
>> 3, is right out :) because in the long run I would like it very much if the salt master was never run as root.
>>
>> In the end, I think that the solution is to document this, and then when a user runs salt, if they don't have rights to the primary locations then it should fall back to a location in the user's home directory
>>
>> thoughts?
>
> Awesome idea Tom! What about:
>
> ~/.salt/minionid.pem

How about using XDG Base Directory, e.g. ~/.cache/salt/minionid.pem?

For more information about XDG see
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

$XDG_CACHE_HOME defines the base directory relative to which user
specific non-essential data files should be stored. If $XDG_CACHE_HOME
is either not set or empty, a default equal to $HOME/.cache should be used.

[Ulrich Dangel]

> I will go with that one. The checks will need to be a little more granular
> then they are are now, but that should not be a big deal, and we can also
> have a fallback for the minions to resort to home directory files if the
> global ones cannot be reached.

This sounds great.

> Can you please file an issue for this so I remember to get to it?

https://github.com/saltstack/salt/issues/1488

Ulrich

[Thomas S Hatch]

Thanks Ulrich!