Elasticsearch connection error

On attempting to start Octane after installation, I receive an error message:

2022/05/05 16:04:05 | ************************************************************
2022/05/05 16:04:05 | ** Error #2: Elasticsearch connection error
2022/05/05 16:04:05 | ************************************************************
2022/05/05 16:04:05 | No access to Elasticsearch. Elastic rest client get elastic version failure (Hosts: [10.150.145.78], Port: 9300, HttpPort: 9200, Cluster name: m42-alm-es01, Sniff Enabled: false)Check port and elastic credentials
2022/05/05 16:04:05 |
2022/05/05 16:04:05 | +-------------------------------------------------------------------------
2022/05/05 16:04:05 | | How to fix:
2022/05/05 16:04:05 | |
2022/05/05 16:04:05 | | - Validate Elasticsearch machine is configured according KM02494295.
2022/05/05 16:04:05 | | - Use 'curl -X GET <machine>:<port>' to get elasticsearch details.
2022/05/05 16:04:05 | | - Validate Elasticsearch machine is accessible from current machine.
2022/05/05 16:04:05 | | - Validate Elasticsearch ports are accessible.
2022/05/05 16:04:05 | | - Validate Elasticsearch cluster name is correct.
2022/05/05 16:04:05 | | - Validate Elasticsearch configuration is correct.
2022/05/05 16:04:05 | +-------------------------------------------------------------------------
2022/05/05 16:04:05 |
2022/05/05 16:04:05 | Exception during validation:
2022/05/05 16:04:05 | Elastic rest client get elastic version failure
2022/05/05 16:04:05 | could not create the default ssl context
2022/05/05 16:04:05 | Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)
2022/05/05 16:04:05 | problem accessing trust store
2022/05/05 16:04:05 | Keystore was tampered with, or password was incorrect
2022/05/05 16:04:05 | Password verification failed
2022/05/05 16:04:05 | com.hp.mqm.configuration.Exceptions.ConfigurationException: Elastic rest client get elastic version failure

Any ideas on how to address this (not using TLS)? I do have connection to the Elasticsearch server:

# curl -XGET '10.150.145.78:9200/.../health
{
  "cluster_name" : "m42-alm-es01",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 0,
  "active_shards" : 0,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

  • Which versions of Octane and Elasticsearch are you using?

    As you just installed Octane, ensure that you are using compatible versions for both products. The support matrix is accessible here: Octane 16.0.100-300.

  • Hi... the versions installed are:

    On the search server (standalone) Elasticsearch "7.9.1",
    Octane: octane-onprem-16.0.300.70.rpm

    /Per Anders

  • Hi!

    please, review the elasticsearch related lines inside your <octane_repo_base>/repo/conf/octane.conf

    Here I paste an example:

    elasticsearch {
    hosts = ["HOSTNAME1","HOSTNAME2", "HOSTNAME3"]
    port = 9300
    http-port = 9200
    cluster-name = "ES-CLUSTER"
    include "elasticsearch-security.conf"
    }

    Your octane.conf should look like:

    elasticsearch {
    hosts = ["<your_standalone_elastic_server_hostname>"]
    port = 9300
    http-port = 9200
    cluster-name = "<your_cluster_name>"
    include "elasticsearch-security.conf"
    }

    Mind that Elasticsearch is always a cluster, although it has only one server, so you need to set the cluster name (the same that appears in your <path_to_elastic_config>/elasticsearch.yml

    In addition, might you confirm the reponse you get when running the "curl -X GET" to the es cluster from one of the Octane node(s)?

    Thank you & regards

  • Hi,

    From the Octane server:
    [root@m42-alm-oct01 ~]# curl -X GET '10.150.145.78:9200'
    {
      "name" : "m42-alm-es01.cloud.local",
      "cluster_name" : "m42-alm-es01",
      "cluster_uuid" : "0ns2Z6LBToeszAUFBIoz3g",
      "version" : {
        "number" : "7.9.1",
        "build_flavor" : "oss",
        "build_type" : "rpm",
        "build_hash" : "083627f112ba94dffc1232e8b42b73492789ef91",
        "build_date" : "2020-09-01T21:22:21.964974Z",
        "build_snapshot" : false,
        "lucene_version" : "8.6.2",
        "minimum_wire_compatibility_version" : "6.8.0",
        "minimum_index_compatibility_version" : "6.0.0-beta1"
      },
      "tagline" : "You Know, for Search"
    }

    From the /opt/octane/repo/conf/octane.conf

    elasticsearch {
      hosts = [10.150.145.78]
      port = 9300
      http-port = 9200
      cluster-name = "m42-alm-es01"
      include "elasticsearch-security.conf"
    }

    From all what I can see, this should be in line wirh the guidelines...

    Kind regards
    Per Anders

  • Hi,

    Try to use quotes for the IP address in octane.conf, like this:

    elasticsearch {
      hosts = ["10.150.145.78"]
      port = 9300
      http-port = 9200
      cluster-name = "m42-alm-es01"
      include "elasticsearch-security.conf"

    If the problem it's still there, please open a support ticket so that we can investigate further.

    Thanks,

    Alex

  • Hi Alex,

    Thank you replying and your suggestion.

    However, a few days after the previous message in the thread, we got in a position where it became pressing to document we could get the installation to work. After spending some 30 hours debugging (several people for the most part of a day), we found the root cause of the problem:

    We are running Octane behind a firewall, and are not using SSL/TLS, running http rather than https, etc between the Octane and Elasticsearch servers and in the UI. Eventually, it proved that the "java-default-trust-store-password" parameter in octane.conf was still validated. That was a bit unexpected, as the Octane Installation Guide only refers to that password set-up in a section "Configure trust on the ALM Octane server", which starts-out by suggesting such configuration is only required when "...you connect to any remote server... over a secure channel"  - which we had not set it up do do.

    Anyway... problem solved for now.

    Thanks,
    Per Anders