Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Pack Install Doesn't Honor System user #3298
If you attempt to perform a pack install from a git repo it uses root ssh keys.
However since we clone from python action and python action is shelled out as
Noticed some strange behavior today that made me add the
I ran into this today attempting to install a pack from a private github repo. I'm posting the below in case it helps to verify/provide more detail about the issue.
The following snippet from the output when it failed indicates that it's attempting to clone it as root:
Looking at the traceback:
The following lines from /opt/stackstorm/packs/packs/actions/pack_mgmt/download.py seem to show why this is happening -- it's not attempting to run as the system user, it's running as whatever user is used to run the python script:
Sorry, I don't know how /opt/stackstorm/packs/packs/actions/pack_mgmt/download.py maps to code in the repo(s) - I used the curl command from https://docs.stackstorm.com/install/index.html to install stackstorm.
Hope this helps.
I am having a similar issue I think. I am using a private repo on an internal github implementation.
However if I try to do this 2-step process in 1 step it fails. i.e.
The action timesout after 600s with an error
I was planning to demo how to install packs using chatops which is why I wanted to do it this way. I suppose I could create my own pack / action to do it in 2 steps though
Here is the traceback
Of course, then the various install methods (one liner and ansible at least) add
Now I'm seeing root owned files all over the place as my actions edit or modify files. A file owned by root has many potential actors (any service running as root). But
Especially problematic is when an action edits a file that happens to be on our NFS v3 NAS. See, all users have the same access to the NAS as a system mounted drive except root who has special NFS permissions. All other users get mapped to a single NAS user, but root is root. So suddenly, files that are supposed to be world readable/writable are suddenly locked and only root can edit them. It can take a bit to reset those permissions so that they are again accessible correctly over both NFS (and to complicate it even further, through CIFS).
And then, there's all of the sshconfig that I have to add to the root user. Yes, there's passwordless sudo on that special system user, but I would rather not attach all of that config to the root user.
In sum, I have two conflicting suggestions to fix this: