Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 684992 - app-admin/salt installs complete package on every system
Summary: app-admin/salt installs complete package on every system
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Patrick McLean
Depends on:
Reported: 2019-05-03 18:11 UTC by luckylinux
Modified: 2019-05-04 04:48 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

Test ebuild to selectively enable master/minion functionality (salt-2019.2.0.ebuild,5.34 KB, text/plain)
2019-05-03 18:11 UTC, luckylinux

Note You need to log in before you can comment on or make changes to this bug.
Description luckylinux 2019-05-03 18:11:38 UTC
Created attachment 575018 [details]
Test ebuild to selectively enable master/minion functionality

Hi all,

I'm experimenting with using Salstack as a distributed configuration management system (amongst other things).

I had no trouble setting up a master and associating with it a few Debian minions. However I saw that on Gentoo installing app-admin/salt installs automatically the complete package. There is no possibility of specifying what to install: master, minion, api, ...

I reported this on Saltstack Github tracker but it got rejected, static that the Saltstack ebuilds are maintained by Gentoo directly. See

I see this as a potential major security risk: why should be the master be installed on every systems? Only salt-minion and salt-call should be installed.

Comment 1 luckylinux 2019-05-03 18:18:35 UTC
I tried experimenting a bit with the ebuild but I'm definitively not an advanced Gentoo user, so I don't know what I'm supposed to tweak exactly.

I managed to only install the SERVICE salt-minion. The command salt-master is however in any case installed.

I don't think installing the complete package and then doing a rm /usr/bin/salt-master is the proper way to fix this. This should somehow be fixed IMHO in the line

USE_SETUPTOOLS=1 distutils-r1_python_install_all

(but I don't know what I should change)

Using Saltstack boostrap install could be an option. However it appears that app-admin/salt-9999 was removed from the tree due to it being broken / unmaintained (see

I'm not sure if using "pip install salt" would only install the minion or also the master. I didn't see any "salt-minion" or "salt-master" package so I assume it would install exactly the same components as the ebuild.

Could the Bugtracker moderators please add the ebuild responsible to this bug so that he also receives the notifications? From what I could gather the ebuild maintainer should be "Patrick McLean".

Thank you!
Comment 2 Patrick McLean gentoo-dev 2019-05-03 20:04:37 UTC
This is not ebuild specific, the ebuild only does the exact same thing "pip install salt" would do, which is functionally equivalent to running "python install" from the source tree.

There are really only 2 possible approaches to solve this:

- delete the code after the fact (though deleting the command from the system will do very little, as almost all the relevant code lives in the modules). This is the "rm -f /usr/bin/salt" you mentioned above. This approach only removes the command-line wrapper, not the module code that actually implements the master.

- heavily patch the to make it selectively install only what is needed for a particular configuration. This has the problem of determining what parts of the module code are needed for which configuration and the maintenance burden of maintaining said patch.
Comment 3 luckylinux 2019-05-04 04:48:09 UTC
So I assume you don't see that installing salt-master on every system is a potential security risk?

Is it possible to somehow blacklist the service, the /usr/bin/salt-master from executing? Or possibly some iptables rules to reject all incoming connections?