grafana / grafana-image-renderer

A Grafana backend plugin that handles rendering of panels & dashboards to PNGs using headless browser (Chromium/Chrome)
Apache License 2.0
361 stars 151 forks source link

Image renderer refers to localhost #191

Open Faholan opened 3 years ago

Faholan commented 3 years ago

What happened:

Image-renderer failed to render an image

What you expected to happen:

Obviously, I wanted it to render an image

How to reproduce it (as minimally and precisely as possible):

The root of the issue is that it somehow refers to localhost instead of referring to the domain name configured. And as it tries to use https, it obviously fails because the certificate wasn't issued for localhost.

Anything else we need to know?:

The exact error is :

Rendering failed: Error: net::ERR_CERT_COMMON_NAME_INVALID at https://localhost:3000/d-solo/qVtkD6tMz/chaotic-bot?orgId=1&panelId=8&width=1000&height=500&tz=Europe%2FParis&render=1

Environment:

miken32 commented 3 years ago

Having the same issue here; there appears to be no reasonable way to change the domain name from "localhost". If you aren't using a remote renderer, the only way to change it is to set http_addr in the [server] section, which for some reason is the same setting that specifies the bind interfaces. 🤷🏻‍♂️

And unless I'm missing something (possible since I don't know Go) none of this is even set in this codebase; for some reason it's all in the main codebase here: https://github.com/grafana/grafana/blob/master/pkg/services/rendering/rendering.go#L62

Faholan commented 3 years ago

Does http_addr actually works using a domain name ? Because the docs say that it is expecting an ip adress

miken32 commented 3 years ago

As long as it can reverse resolve it, yes it will work. But it can only listen on a single interface, which isn't useful unless you have a reverse proxy in place and can have Grafana only listening on 127.0.0.1.

FLeven commented 3 years ago

I have the same error: Grafana Image Renderer version: 2.0.1 Grafana version: 7.5.1 Installed plugin or remote renderer service: Image renderer is the only additional plugin installed (local) OS Grafana Image Renderer is installed on: Windows Container Build 1809 User OS & Browser: Accessed Under Windows / Chrome

UlrichThiess commented 3 years ago

The message net::ERR_CERT_COMMON_NAME_INVALID indicates that the certificate is not correct.

This can be solved by the following entry in the INI file:

[plugin.grafana-image-renderer] rendering_ignore_https_errors = true

miken32 commented 3 years ago

Disabling peer verification is not acceptable in any environment. If the certificate is not correct, you should use the correct certificate; and if you can't do that, it's a problem with the software.

AlexHeylin commented 3 years ago

I also see this problem. Setting

[plugin.grafana-image-renderer]
rendering_ignore_https_errors = true

Does work around the issue, but the real fix needs to be stop using localhost and use the FQDN specified in Grafana config.

adamquan commented 11 months ago

Any update on this? Run into the same issue. The setting fixes it but ideally localhost should not be used. Also, this seem to cause issues for csv report generation too.

Clarity-89 commented 11 months ago

When rendering, Grafana will use the value of http_addr from the settings as the value for domain, if that value is not the same as the default, so the solution here would be to specify http_addr value in the settings, which is the same as the custom domain name:

protocol = https
http_port = 443
http_addr = myDNS.name # Add this line
domain = myDNS.name
miken32 commented 11 months ago

@Clarity-89 I said that 3 years ago. I also said that setting is supposed to be used for specifying the bind interface. It can’t do both properly.

Clarity-89 commented 11 months ago

@miken32 thank you for the context. I'm trying to understand what would be a use case for having a different server host and domain for the image renderer?

miken32 commented 11 months ago

I haven’t looked at this in years so I don’t even remember how we were trying to use it. But looking at the past comments: when you set http_addr to a domain name it resolves the name and uses the address as a bind interface. Most Linux boxes will resolve the name of the server to 127.0.0.1, which is not helpful.

This is all academic anyway. It’s two separate functions so should be two separate settings. Would they use the http_port setting to also specify the image renderer timeout?

dparker-coder commented 3 weeks ago

This issue still exists. I asked Grafana tech support to request a config param be added to set the URL used by the image rendering plugin, separate from http_addr. Maybe someone will assist.

AgnesToulet commented 2 weeks ago

Hello!

I looked at this issue again, and I think the image render should actually use the domain setting (see doc) instead of the http_addr. Would this solve your issue?

ethirolle commented 2 weeks ago

Hi @AgnesToulet I just tested this in on-prem Grafana 11.0.0, and if I define domain (with export GF_SERVER_DOMAIN="grafana.localhost.tv"), but do not define http_addr, my image renderer plugin callback requests go to localhost, like this:

logger=plugin.grafana-image-renderer t=2024-06-18T11:16:48.537532092-06:00 level=debug msg="Browser request" url="http://localhost:3100/d-solo/b-Lm0o3Wk/new-dashboard?orgId=1&from=1718709407253&to=1718731007253&panelId=2&width=1000&height=500&scale=1&tz=America%2FDenver&render=1" method=GET

but as soon as I set http_addr to the FQDN of my server (export GF_SERVER_HTTP_ADDR="grafana.localhost.tv"), the same log lines show that the image renderer plugin is using the FQDN in its callbacks, like:

logger=plugin.grafana-image-renderer t=2024-06-18T11:13:59.118762862-06:00 level=debug msg="Browser request" url="http://grafana.localhost.tv:3100/d-solo/b-Lm0o3Wk/new-dashboard?orgId=1&from=1718709237123&to=1718730837123&panelId=2&width=1000&height=500&scale=1&tz=America%2FDenver&render=1" method=GET

I think the code is misleading because it seems to use rs.domain here:

return fmt.Sprintf("%s://%s:%s%s/%s&render=1", protocol, rs.domain, rs.Cfg.HTTPPort, subPath, path)

but rs.domain does not seem to be populated from the [server]domain parameter in the grafana.ini settings.

The problem may be here:

    switch {
    case cfg.RendererUrl != "":
        // RendererCallbackUrl has already been passed, it won't generate an error.
        u, err := url.Parse(cfg.RendererCallbackUrl)
        if err != nil {
            return nil, err
        }

        sanitizeURL = getSanitizerURL(cfg.RendererUrl)
        domain = u.Hostname()
    case cfg.HTTPAddr != setting.DefaultHTTPAddr:
        domain = cfg.HTTPAddr
    default:
        domain = "localhost"
    }

Thanks!

AgnesToulet commented 2 weeks ago

Yes, the image renderer definitely uses http_addr as its domain. What I was asking is, if we change the code to use domain instead of http_addr, would it solve all the issues? Or should we still introduce a new setting only for the URL the image renderer should use (because of some use cases that I wouldn't know about)?

dparker-coder commented 2 weeks ago

I would prefer a new setting for image rendering URL. it's possible that using domain would work, but I don't know it won't cause other issues.

On Thu, Jun 20, 2024 at 3:52 AM Agnès Toulet @.***> wrote:

Yes, the image renderer definitely uses http_addr as its domain. What I was asking is, if we change the code to use domain instead of http_addr, would it solve all the issues? Or should we still introduce a new setting only for the URL the image renderer should use (because of some use cases that I wouldn't know about)?

— Reply to this email directly, view it on GitHub https://github.com/grafana/grafana-image-renderer/issues/191#issuecomment-2180043121, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSADX5WYQDYIDQJ4XBR3MTZIKC5FAVCNFSM6AAAAABJOZIXHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBQGA2DGMJSGE . You are receiving this because you commented.Message ID: @.***>