I just completed a rolling upgrade of our ES and Kibana (PRO) cluster, from 6.6.2 with the 1.17.5 versions of each plug-in, to now 6.7.1 with 1.18.0 versions. Everything appeared to go fine, and after the Kibana upgrade, as usual, my currently-open Kibana windows told me at the next refresh attempt that the back-end was newer than my loaded front-end code, and so I was to refresh them, which also worked. I am pleased that in the rewritten Scala version of LDAP, the ha keyword “ROUND_ROBIN” is no longer misspelled with an extra R, and it continues to be nice and stable, talking to all our three domain controllers all day.
However, in this version, the magenta button that shows my logged-in username and allows me to intentionally log out (clear my auth cookie) has moved over to the far right lower corner of the window, hovering over the results of my queries or visualizations, instead of the far left corner at the bottom of the left nav bar, under the Collapse button. So it’s kind of in my way now, occasionally obscuring results. This is not a showstopper, just weird. I didn’t quite notice whether this happened at the upgrade of Kibana itself or the RoR PRO plug-in to Kibana, because naturally I did it all in a sequence, per node. But it also happens even in an Incognito window or when I switch from Chrome to Safari on my Mac, so I don’t think it’s just a matter of some leftover cached CSS files.
Anyone else notice this? Is there something I can do about it? Thanks.
– Jeff Saxe
Quantitative Investment Management
Charlottesville, Virginia
Thanks for the feedback: the logout button has been decoupled from the Kibana sidebar in the master branch in order to create a UI that would work all across the board from the old Kibana 6.x and 7.x entirely redesigned interface.
So two things:
this is the first design iteration for the decoupled ROR controls, suggestions are warmly welcome for nicer positioning and CSS in general.
You can experiment hiding, repositioning or modifying it using the CSS/JS injection in ROR Enterprise.
Ah, good, I’m glad this move came out of a need to be cross-compatible. I know it must be incredibly challenging for your programming to be subject to the changing winds of Elastic’s decisionmaking. When they wrote “hey! we’re making limited, local parts of X-Pack Security free now!” you must have been shaking your head.
Anyway, we’re using PRO, not Enterprise, so I can’t follow the injection directions. But I did just manually grep around in the optimize/bundles directory, and I manually edited the commons.style.css file for the ROR Logout button, changing “right: 0%;” to “left: 0%;”. This is much better I think. The button still hovers entirely above everything and is not contained inside any other container, so if I use the “Collapse” button, the left nav bar gets narrower but the ROR Logout button is still the same width and “broken out” above the nav bar. In the previous design, collapsing the nav bar would also truncate the magenta logout button. If you can make it work as it used to, in a way that is magically compatible over all versions, then great… if not, then “left: 0%” seems a decent workaround to me. Thanks for your consideration.
By the way, on a related note: in the process of trying to troubleshoot this, I did temporarily try to uninstall RoR PRO plug-in from Kibana and just start it up without RoR for a minute, and Kibana would not start because there was a subdirectory owned by root that could not be erased by the non-root “kibana” user for the service. In other words, the RoR PRO plug-in installer creates a few dozen loose files in “/usr/share/kibana/optimize/bundles”, all owned by root but that is harmless, and then it also creates a subdirectory “/usr/share/kibana/optimize/bundles/src” that goes a few levels down with another handful of files. Then the Remove script for the plug-in cleans up the loose files, but it didn’t recursively remove that “src” subdirectory, and then regular Kibana got upset that it was still there but was unable to delete it, so it crashed and restarted over and over. The “journalctl” utility is your friend here on Ubuntu, because it’s hard to see what the final crashing message is in the normal “systemctl status” output.
