Summary: | app-admin/salt installs complete package on every system | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | luckylinux <stefano13no> |
Component: | Current packages | Assignee: | Patrick McLean <chutzpah> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Test ebuild to selectively enable master/minion functionality |
Description
luckylinux
2019-05-03 18:11:38 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 https://gitweb.gentoo.org/repo/gentoo.git/log/app-admin/salt?showmsg=1). 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! 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 setup.py 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 setup.py 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. 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? |