-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[build] Commit install/remove scripts #6674
Conversation
LGTM - I did not test rpm package but Jon says its the same scripts. Testing installing 5.0-snapshot on a previously uninstalled (but not purged) 4.5 install I get a screen asking what to do with the previous kibana.yml. I think this is good.
I entered Y and took the new kibana.yml. Then I edited it with a comment to mark it.
I checked the user id before and after the upgrade and it did not change (good);
Next test, I changed the kibana.yml before making a 5.2. When I installed it I was prompted with the choices again. So it is smart enough to know if nothing has changed in the packages yml file to leave the existing one. If there are existing installedPlugins, Upgrade and Purge Leave them there.
I'll write an issue about these if there isn't one already.
|
@gmoskovicz yes, with these changes it should only be deleting the kibana user on remove on RHEL |
Thanks for confirming @jbudz . |
if ! user_check "kibana" ; then | ||
user_create "kibana" | ||
fi | ||
chown kibana /opt/kibana/optimize |
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.
Does this need to be recursive or is deliberately not recursive?
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.
The only file in the optimize folder on install is .empty so it shouldn't be needed.
jenkins, test it |
if ! user_check "<%= user %>" ; then | ||
user_create "<%= user %>" | ||
fi | ||
chown <%= user %>:<%= group %> /opt/kibana/optimize |
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.
Are you sure this doesn't need to be recursive? After installing the kibana-5.0.0_snapshot-1.i686.rpm
package, I found a bunch of folders and files under /opt/kibana/optimize
that are owned by root
:
$ tree -ug /opt/kibana/optimize | head -20
/opt/kibana/optimize
└── [root root ] bundles
├── [root root ] a573941f02f4331f81046356ebb667eb.swf
├── [root root ] commons.bundle.js
├── [root root ] commons.style.css
├── [root root ] console.bundle.js
├── [root root ] console.entry.js
├── [root root ] console.style.css
├── [root root ] fbe046f38bf68f1469110319dee9bbfd.js
├── [root root ] kibana.bundle.js
├── [root root ] kibana.entry.js
├── [root root ] kibana.style.css
├── [root root ] node_modules
│ ├── [root root ] bootstrap
│ │ └── [root root ] fonts
│ │ ├── [root root ] glyphicons-halflings-regular.eot
│ │ ├── [root root ] glyphicons-halflings-regular.svg
│ │ ├── [root root ] glyphicons-halflings-regular.ttf
│ │ ├── [root root ] glyphicons-halflings-regular.woff
│ │ └── [root root ] glyphicons-halflings-regular.woff2
I am unable to upgrade from Kibana 4.5.0 to Kibana 5.0.0_snapshot on CentOS 6:
Note the last two steps in particular. Kibana 5.0.0 does get installed but the old Kibana is still running. I realize this is exactly the issue this PR will fix for versions of Kibana 5.0.0 onwards. I'm just wondering if there should be a preinstall script as well that takes another shot at stopping the Kibana service. What do you think? |
@epixa any thoughts on @ycombinator's comment above? It would look the same as https://github.com/jbudz/kibana/blob/50ab1b97a3a2af76ce518f345ffef38ef0c0d97d/tasks/build/package_scripts/pre_remove.sh. For 5.x upgrades it would try stopping kibana twice, and add some code debt, but would workaround the upgrade issue for 4.x->5 users. |
What impact does it have on upgrades post 5.0? Also, what's the alternative? People would need to stop Kibana before attempting to upgrade? |
No visible impact on upgrades post 5.0 - it will try and stop the service twice. And yes, the alternative is to stop the Kibana service or do a fresh install |
What do you mean by "try to stop the service twice"? If it succeeds on the first try, does the second try error, or is it more like a noop? |
Butting in here: Ideally we wouldn't try to stop the service the second time if it is already stopped. |
it would be more like a noop, no errors. @ycombinator - makes sense |
50155ad
to
0187dc5
Compare
…vice before removing
Getting back to testing this PR today:
|
@jbudz I'm still seeing the same error I reported in an earlier comment when upgrading from Kibana 4.5.* to 5.0.0:
|
@ycombinator do you have any more info, can we double check the built rpm has updated scripts? I wasn't able to reproduce with both sysv and systemd.
|
@jbudz That's so bizzare. I'm on CentOS 6.8. What OS are you on? |
Merged as part of #7308 |
After install - create a kibana user if one doesn't exist, chown /optimize
Upgrade - stop kibana, upgrade files
Remove (red hat), purge (debian) - delete the kibana user, remove files
Fixes #6262
Fixes #6729