Pass cacert file with the correct type to the elasticsearch loader

[ph]

We were sending the cacert as [/tmp/cacert] instead of
[]string{"/tmp/cacert"} making the Elasticsearch loader crash with a
file not found.

[ph]

With the fix:

 ✘  ph@sashimi  ~/go/src/github.com/elastic/beats/libbeat/dashboards   fix/support-tls-import-dashboard ± ./import_dashboards -cacert /Users/ph/es/elastic-tls-testing/certs/ca/ca.crt -file ./testdata/testbeat-dashboards.zip -es https://localhost:9200 -user elastic -pass changeme
Initialize the Elasticsearch 6.2.3 loader
Elasticsearch URL https://localhost:9200
For Elasticsearch version >= 6.0.0, the Kibana dashboards need to be imported via the Kibana API.

Without the fix:

fail to create the Elasticsearch loader: Error creating Elasticsearch client: 1 error: open [/Users/ph/es/elastic-tls-testing/certs/ca/ca.crt]: no such file or directory reading [/Users/ph/es/elastic-tls-testing/certs/ca/ca.crt]
Exiting

[ph]

We seems to have quite a few things that break on this branch, the error related to elasticsearch probably mean the snapshot doesn't exist. I will take a quick look at this.

[tsg]

LGTM.

[kvch]

@ph are the errors related to your change?

[andrewkroh]

With this fixed, the one thing I notice is that when import_dashboards fails to connect to ES due to certificate issues it doesn't tell you that it's a certificate problem. It just says that it couldn't connect. Do you see this too if you use an invalid CA cert?

[ph]

@kvch Not at all related, I having a hard time to run the 5.6 suite locally without my patch.

@andrewkroh Same errors as your, let me check If I can bubble up something better without making too much changes.

[ph]

@andrewvc It's a bit of the downside of using the same package that we use inside the elasticsearch output. The binary import_dashboards doesn't expose the logs. If logs were enabled we could see the real errors which is meaningful in that case.

I could change the code to use the multierror package and return all the errors, I don't believe it would be dangerous in that case because we return an adhoc error. It would be surprising that consumer of that library assert on the content of the error.

WDYT?

Get https://localhost:9200: x509: certificate signed by unknown authority

[ph]

@andrewkroh that would give us something like

fail to create the Elasticsearch loader: Error creating Elasticsearch client: couldn't connect to any of the configured Elasticsearch hosts, errors: 1 error: Get https://localhost:9200: x509: certificate signed by unknown authority

• This might expose unwanted things in the logs.

[ph]

@andrewkroh @kvch @tsg

I've fixed some of the failling tests in this PR which are related to 5.6.X and not on feature created in this PR, I would be in favor to get that PR merged in and create another issue to fix the 5.6.x branch.

[ph]

The faillure on Travis/Darwin might be related to golang/go#19734 since we are still running 1.7.6

[andrewkroh]

LGTM, but can you add a CHANGELOG entry please.

[ph]

@andrewkroh I have added the changelog and squashed the history into meaningful commits.