-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix configuration directory and file permissions #563
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just setting dir permissions in specific installer won't help much, because there are many other installers too (Ansible, packages, Puppet, Chef, Docker, etc).
Instead we have to rely on st2 login -w
, and avoid creating CLI config files in curl|bash
installer.
The best is to keep this responsibility on st2
as single source of config creation logic.
See #520. We didn't had st2 login -w
at that moment. Now it's a good time to switch.
49cec89
to
c16ba54
Compare
scripts/includes/common.sh
Outdated
username = ${USERNAME} | ||
password = ${PASSWORD} | ||
EOT" | ||
sudo sh -c st2 login --config ${CURRENT_USER_CLI_CONFIG_PATH} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why using sudo
and sh
is required? Ideally is to avoid something like that, making sure that st2
does the right thing.
Just st2 login
would be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, as described in another comment, 1 run sudo st2 login -w
is needed to write config for root and another st2 login -w
is needed to write user's config.
Still adding sh -c
is excessive in this scenario.
scripts/includes/common.sh
Outdated
username = ${USERNAME} | ||
password = ${PASSWORD} | ||
EOT" | ||
sudo sh -c st2 login --config ${ROOT_USER_CLI_CONFIG_PATH} \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need explicit ROOT_USER_CLI_CONFIG_PATH
?
With that, the logic defined in configure_st2_cli_config()
needs a cleanup. All dir/config file creation should be a st2 login -w
responsibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need explicit
ROOT_USER_CLI_CONFIG_PATH
?
Technically, no, but it makes it easier to verify that the two calls to st2 login
(one for root, one for the user) are doing similar things.
I have found it easier to make more variables in Bash than to hard code everything.
All dir/config file creation should be a
st2 login -w
responsibility.
Yep, fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining that.
To ensure st2 login config is created for both user
and root
, would it be enough to run
st2 login -w
(for user)sudo st2 login -w
(for root)
Can st2 login handle that correctly?
Additionally, there is no such --config
option for st2 login
command.
We shouldn't hardcode the dirs in every installer. It's a st2 responsibility to decide on config dirs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can st2 login handle that correctly?
Should be able to, yes.
Additionally, there is no such --config option for st2 login command.
Good catch, thanks! Fixed.
We shouldn't hardcode the dirs in every installer. It's a st2 responsibility to decide on config dirs.
That's true, but I'm just trying to maintain backwards compatibility. We can take care of that in a different PR.
c16ba54
to
de8a668
Compare
scripts/st2bootstrap-deb.sh
Outdated
|
||
# Fix the permissions | ||
sudo chown -R ${CURRENT_USER}:${CURRENT_USER} ${CURRENT_USER_CLI_CONFIG_DIRECTORY} | ||
chown -R ${CURRENT_USER}:${CURRENT_USER} ${CURRENT_USER_CLI_CONFIG_DIRECTORY} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need to chown
anymore.
Keep in mind that curl|bash
installer is not idempotent and runs only once (first install), and so the config files/dirs are created with the correct permissions on first run making chown
excessive in this case.
Backwards compatibility you mentioned should be guaranteed by st2 login
functionality.
That's why we moved this permissions logic into st2 login
itself, see: StackStorm/st2#4173
…-file option to st2 instead of the login subcommand
8269ead
to
2c2cad3
Compare
@armab I fixed the issues you pointed out. Let me know if there's anything else I need to fix. |
Thanks @blag! The logic LGTM. |
@armab Waiting on your approval to merge this. |
@blag Per previous discussion, did you end-to-end test this change manually and can confirm working behavior? |
I will merge it and test it out. If it doesn't work, I will revert it since we don't want to delay the release any longer. |
I pushed a fix, yet things are still breaking (38fdd4e). This requires more work. @blag for future reference, that's how you tested installer script changes from a branch: wget https://stackstorm.com/packages/install.sh
bash install.sh --user=st2admin --password=Ch@ngeMe --staging --unstable --force-branch=fix-config-permissions The problem seems to be that This means we will probably still need to manually create and chmod directories and config inside the installer script. Either that, or change st2 CLI to create directories and file if they don't exist yet, but that's a lot more involved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per my comment in #563 (comment), it needs more work.
Agree, that's the point which I'd like us ideally to follow. We just need to get rid of all the config/dir paths in scripted installer and let the st2 handle it correctly. This leaves scripted installer with less logic to juggle with which is a good part. |
With this release timing pressure, I've made a change to this PR to have a more simplified & working st2 config behavior in scripted installer. Per quick manual tests it looks ok:
@Kami Please take a look again. |
Companion PR to st2#4173.
Fixes configuration directory permissions to
2770
and the configuration file permissions to660
.Fixes #558
Closes #520
Closes #565