Skip to content
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

Closed
elasticmachine opened this issue Dec 7, 2017 · 7 comments
Closed
Labels
Feature:Reporting Reporting (PDF, CSV, ..) feature Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@elasticmachine
Copy link
Contributor

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 called Kibana-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.

@elasticmachine
Copy link
Contributor Author

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?

@elasticmachine
Copy link
Contributor Author

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.

@elasticmachine
Copy link
Contributor Author

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

freetype.x86_64
fontconfig.x86_64

Once I confirm, I'll update the docs.

@elasticmachine elasticmachine added :Sharing Feature:Reporting Reporting (PDF, CSV, ..) feature labels Apr 24, 2018
@timroes timroes added Team:Visualizations Visualization editors, elastic-charts and infrastructure and removed :Sharing labels Sep 13, 2018
@tsullivan
Copy link
Member

Perhaps there could be two packages available for Kibana, one just called Kibana and one called Kibana-with-Reporting-deps. Where the second package just ropes in those extra fonrt package dependencies if X-Pack is intended to be used

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.

@tsullivan
Copy link
Member

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

This part is implemented in #28001. There's more I'd like to do, such as warn if network settings seem to be wrong.

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

This was the behavior before we switched to Puppeteer for launching Chromium. There is an open issue on this: #28408

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,

Implemented in #29940

@tsullivan
Copy link
Member

tsullivan commented Feb 19, 2019

Remaining issues with Reporting docs:

Reporting Troubleshooting page:

  • Page headings are disorganized. There are h4 tags that have nothing to do with the section created by the previous h3
  • It looks like the h3 items belong to the text You might see "There was an error generating your report" or one of the following errors when you download your report which is higher up in the page
  • The last sections about system font packages should probably go in the section for Text is Not rendered correctly in generated reports

Getting Started page:

  • Make mention of these possible dependencies for Reporting on the Kibana

@tsullivan
Copy link
Member

Closing for #31518

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Reporting Reporting (PDF, CSV, ..) feature Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

No branches or pull requests

3 participants