You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the puppet agent runs in a scheduled manner under the puppet service on a Linux server, it uses umask 022 when it installs python modules and gems via the package resource type. When forced to run by sudo puppet agent --test, the python and gem packages get installed so that only root can use the packages. This is frustrating as the package then needs to be manually uninstalled, and then reinstalled being sure to set umask 022. This assumes the team member running the command even noticed there was an issue in the first place. Generally the issue appears when a GitLab Runner process begins to fail or another process begins to fail.
Describe the Solution You Would Like
I would like to see one of the following:
Resource type package uses umask 022 by default in the background, maybe for:
gem
pip, pip2, pip3
puppet_gem
puppetserver_gem
Or
Add attribute umask to resource type package
Describe Alternatives You've Considered
We currently use npwalker-recursive_file_permissions in our various Puppet modules based on server type and whether or not we are installing a gem or a python module.
Additional Context
N/A
The text was updated successfully, but these errors were encountered:
@bobnegri Thank you for opening this issue, would it be possible to check if this behavior is being caused by puppet or if it's being caused by running the python and gem commands? Thank you!
Use Case
When the puppet agent runs in a scheduled manner under the puppet service on a Linux server, it uses umask 022 when it installs python modules and gems via the package resource type. When forced to run by
sudo puppet agent --test
, the python and gem packages get installed so that onlyroot
can use the packages. This is frustrating as the package then needs to be manually uninstalled, and then reinstalled being sure to set umask 022. This assumes the team member running the command even noticed there was an issue in the first place. Generally the issue appears when a GitLab Runner process begins to fail or another process begins to fail.Describe the Solution You Would Like
I would like to see one of the following:
Or
Describe Alternatives You've Considered
We currently use npwalker-recursive_file_permissions in our various Puppet modules based on server type and whether or not we are installing a gem or a python module.
Additional Context
N/A
The text was updated successfully, but these errors were encountered: