-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
[Reporting] Better handle system font package dependencies on Linux #18100
Comments
Original comment by @alexfrancoeur: @kobelb this is the first time I've heard a request like this, any thoughts on how we could approach this? |
Original comment by @kobelb: I think the suggestions that @geekpete made are worth investigating. With that being said, neither are "low effort". Providing a package (.rpm, .deb) that has the necessary fonts would be quite convenient, but in my experience the font packages that are required differ from distro to distro and this could potentially become a maintenance burden to keep up with, but something we should definitely investigate. In an ideal world, we could turn the Reporting plugin "yellow/red" when the system dependencies aren't there, but the only way we find out about this currently is after running the Reporting process and responding to the messages that are thrown. We'd have to find a way to proactively detect whether these dependencies are present, which would require additional research. |
Original comment by @geekpete: The first line of defence is improving the docs to tell users up front specifically what packages they need to have installed if they’re going to use X-Pack for Reporting, probably at the time of X-Pack install (so in the Kibana X-Pack install docs section) but also on that troubleshooting page where the existing mention of of these required packages is and perhaps also make mention of these possible dependencies for Reporting on the Kibana install page as well. On RHEL the packages required seem to be
Once I confirm, I'll update the docs. |
My understanding is that the deps for Reporting vary from on OS to another, and are even different for Ubuntu vs CentOS. So far it looks like the best source for reference on the deps is here: https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md#chrome-headless-doesnt-launch We're working on adding a startup check in Reporting that will see what happens when we try to launch Chromium. If there's a failure, we'll tell the user how to find the chromium log file. |
This part is implemented in #28001. There's more I'd like to do, such as warn if network settings seem to be wrong.
This was the behavior before we switched to Puppeteer for launching Chromium. There is an open issue on this: #28408
Implemented in #29940 |
Remaining issues with Reporting docs: Reporting Troubleshooting page:
Getting Started page:
|
Closing for #31518 |
Original comment by @geekpete:
Describe the feature:
Provide either a better user experience (warnings/feedback/alerts) or better handling of the font/freetype dependency with Reporting when using Linux.
Currently we have a small warning some parts of our docs:
Reporting:
https://www.elastic.co/guide/en/kibana/6.0/xpack-reporting.html
Troubleshooting
https://www.elastic.co/guide/en/kibana/6.0/reporting-troubleshooting.html#_phantom_error_when_generating_reports
But this is a system level dependency that must be installed for a particular feature in X-Pack (reporting).
Was asked by a customer what the best practice is for handling this dependency, which seems to be to react to it not working by running the install after you detect an issue or to have known ahead of time that Reporting would hit this issue if the right packages were not installed. For my particular customer this means going through a new bunch of approval process for change management that would have been better done during the original install of Kibana packages with their original change request paperwork.
So I'm wondering if there's a better way but not sure what that better way might be.
Perhaps there could be two packages available for Kibana, one just called
Kibana
and one calledKibana-with-Reporting-deps
. Where the second package just ropes in those extra fonrt package dependencies if X-Pack is intended to be used. The first package would suit opensource users.Another idea might be to drag the dependencies in "just in case" a user both wants to install X-Pack and also use Reporting, but unsure if that's desirable depending on how many users fall into this category.
Or we could just throw some warns in the Kibana logs if these packages are detected as missing and platform is Linux,
warning: the libfontconfig and libfreetype6 packages and system fonts are required to generate PDF reports, not detected as installed.
or perhaps in the UI if this dependency info could be fed up to the UI from Kibana there could be a warning popped up at the user to warn them. The last suggestions would still have them installing the dependencies after the initial install instead of during.Also this might all just be a lot of work for a scenario that just doesn't pop up that often, for example of many distros install these packages by default anyway. Unsure about that.
The text was updated successfully, but these errors were encountered: