Loading

Install Elasticsearch with RPM

Self Managed

The RPM package for Elasticsearch can be downloaded from our website or from our RPM repository. It can be used to install Elasticsearch on any RPM-based system such as OpenSuSE, SLES, Centos, Red Hat, and Oracle Enterprise.

Note

RPM install is not supported on distributions with old versions of RPM, such as SLES 11 and CentOS 5. Please see Install Elasticsearch from archive on Linux or MacOS instead.

This package contains both free and subscription features. Start a 30-day trial to try out all of the features.

The latest stable version of Elasticsearch can be found on the Download Elasticsearch page. Other versions can be found on the Past Releases page.

Note

Elasticsearch includes a bundled version of OpenJDK from the JDK maintainers (GPLv2+CE). To use your own version of Java, see the JVM version requirements.

Before you install Elasticsearch, do the following:

We sign all of our packages with the Elasticsearch signing key (PGP key D88E42B4, available from https://pgp.mit.edu) with fingerprint:

4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4

Download and install the public signing key:

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

You have several options for installing the Elasticsearch RPM package:

Create a file called elasticsearch.repo in the /etc/yum.repos.d/ directory for RedHat based distributions, or in the /etc/zypp/repos.d/ directory for OpenSuSE based distributions, containing:

[elasticsearch]
name=Elasticsearch repository for 9.x packages
baseurl=https://artifacts.elastic.co/packages/9.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md

And your repository is ready for use. You can now install Elasticsearch with one of the following commands:

sudo yum install --enablerepo=elasticsearch elasticsearch 1
sudo dnf install --enablerepo=elasticsearch elasticsearch 2
sudo zypper modifyrepo --enable elasticsearch && \
  sudo zypper install elasticsearch; \
  sudo zypper modifyrepo --disable elasticsearch 3
  1. Use yum on CentOS and older Red Hat based distributions.
  2. Use dnf on Fedora and other newer Red Hat distributions.
  3. Use zypper on OpenSUSE based distributions.

The RPM for Elasticsearch 9.0.0 can be downloaded from the website and installed as follows:

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-x86_64.rpm
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-x86_64.rpm.sha512
shasum -a 512 -c elasticsearch-9.0.0-x86_64.rpm.sha512 1
sudo rpm --install elasticsearch-9.0.0-x86_64.rpm
  1. Compares the SHA of the downloaded RPM and the published checksum, which should output elasticsearch-<version>-x86_64.rpm: OK.
Note

On systemd-based distributions, the installation scripts will attempt to set kernel parameters (e.g., vm.max_map_count). You can skip this by masking the systemd-sysctl.service unit.

When you install Elasticsearch, the installation process configures a single-node cluster by default. If you want a node to join an existing cluster instead, generate an enrollment token on an existing node before you start the new node for the first time.

  1. On any node in your existing cluster, generate a node enrollment token:

    /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node
    
  2. Copy the enrollment token, which is output to your terminal.

  3. On your new Elasticsearch node, pass the enrollment token as a parameter to the elasticsearch-reconfigure-node tool:

    /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node --enrollment-token <enrollment-token>
    

    Elasticsearch is now configured to join the existing cluster.

  4. Start your new node using systemd.

Some features automatically create indices within Elasticsearch. By default, Elasticsearch is configured to allow automatic index creation, and no additional steps are required. However, if you have disabled automatic index creation in Elasticsearch, you must configure action.auto_create_index in elasticsearch.yml to allow features to create the following indices:

action.auto_create_index: .monitoring*,.watches,.triggered_watches,.watcher-history*,.ml*
Important

If you are using Logstash or Beats then you will most likely require additional index names in your action.auto_create_index setting, and the exact value will depend on your local configuration. If you are unsure of the correct value for your environment, you may consider setting the value to * which will allow automatic creation of all indices.

Elasticsearch can be started and stopped as follows:

sudo systemctl start elasticsearch.service
sudo systemctl stop elasticsearch.service

These commands provide no feedback as to whether Elasticsearch was started successfully or not. Instead, this information will be written in the log files located in /var/log/elasticsearch/.

If you have password-protected your Elasticsearch keystore, you will need to provide systemd with the keystore password using a local file and systemd environment variables. This local file should be protected while it exists and may be safely deleted once Elasticsearch is up and running.

echo "keystore_password" > /path/to/my_pwd_file.tmp
chmod 600 /path/to/my_pwd_file.tmp
sudo systemctl set-environment ES_KEYSTORE_PASSPHRASE_FILE=/path/to/my_pwd_file.tmp
sudo systemctl start elasticsearch.service

To configure Elasticsearch to start automatically when the system boots up, run the following commands:

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service

By default, the Elasticsearch service doesn’t log information in the systemd journal. To enable journalctl logging, the --quiet option must be removed from the ExecStart command line in the elasticsearch.service file.

When systemd logging is enabled, the logging information are available using the journalctl commands:

To tail the journal:

sudo journalctl -f

To list journal entries for the elasticsearch service:

sudo journalctl --unit elasticsearch

To list journal entries for the elasticsearch service starting from a given time:

sudo journalctl --unit elasticsearch --since  "2016-10-30 18:17:16"

Check man journalctl or https://www.freedesktop.org/software/systemd/man/journalctl.html for more command line options.

Startup timeouts with older systemd versions

By default Elasticsearch sets the TimeoutStartSec parameter to systemd to 900s. If you are running at least version 238 of systemd, then Elasticsearch can automatically extend the startup timeout, and will do so repeatedly until startup is complete even if it takes longer than 900s.

Versions of systemd prior to 238 do not support the timeout extension mechanism and will terminate the Elasticsearch process if it has not fully started up within the configured timeout. If this happens, Elasticsearch will report in its logs that it was shut down normally a short time after it started:

[2022-01-31T01:22:31,077][INFO ][o.e.n.Node               ] [instance-0000000123] starting ...
...
[2022-01-31T01:37:15,077][INFO ][o.e.n.Node               ] [instance-0000000123] stopping ...

However the systemd logs will report that the startup timed out:

Jan 31 01:22:30 debian systemd[1]: Starting {{es}}...
Jan 31 01:37:15 debian systemd[1]: elasticsearch.service: Start operation timed out. Terminating.
Jan 31 01:37:15 debian systemd[1]: elasticsearch.service: Main process exited, code=killed, status=15/TERM
Jan 31 01:37:15 debian systemd[1]: elasticsearch.service: Failed with result 'timeout'.
Jan 31 01:37:15 debian systemd[1]: Failed to start {{es}}.

To avoid this, upgrade your systemd to at least version 238. You can also temporarily work around the problem by extending the TimeoutStartSec parameter.

When you start Elasticsearch for the first time, the following security configuration occurs automatically:

  • Certificates and keys for TLS are generated for the transport and HTTP layers.
  • The TLS configuration settings are written to elasticsearch.yml.
  • A password is generated for the elastic user.
  • An enrollment token is generated for Kibana, which is valid for 30 minutes.

You can then start Kibana and enter the enrollment token. This token automatically applies the security settings from your Elasticsearch cluster, authenticates to Elasticsearch with the built-in kibana service account, and writes the security configuration to kibana.yml.

Note

There are some cases where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled.

The password for the elastic user and the enrollment token for Kibana are output to your terminal.

We recommend storing the elastic password as an environment variable in your shell. For example:

exportELASTIC_PASSWORD="your_password"

If you have password-protected the Elasticsearch keystore, you will be prompted to enter the keystore’s password. See Secure settings for more details.

To learn how to reset this password, refer to Set passwords for native and built-in users in self-managed clusters.

You can test that your Elasticsearch node is running by sending an HTTPS request to port 9200 on localhost:

curl --cacert /etc/elasticsearch/certs/http_ca.crt \ 1
-u elastic:$ELASTIC_PASSWORD https://localhost:9200 2
  1. --cacert: Path to the generated http_ca.crt certificate for the HTTP layer.
  2. Ensure that you use https in your call, or the request will fail.

The call returns a response like this:

{
  "name" : "Cp8oag6",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "AT69_T_DTp-1qgIJlatQqA",
  "version" : {
    "number" : "9.0.0-SNAPSHOT",
    "build_type" : "tar",
    "build_hash" : "f27399d",
    "build_flavor" : "default",
    "build_date" : "2016-03-30T09:51:41.449Z",
    "build_snapshot" : false,
    "lucene_version" : "10.0.0",
    "minimum_wire_compatibility_version" : "1.2.3",
    "minimum_index_compatibility_version" : "1.2.3"
  },
  "tagline" : "You Know, for Search"
}

The /etc/elasticsearch directory contains the default runtime configuration for Elasticsearch. The ownership of this directory and all contained files are set to root:elasticsearch on package installations.

The setgid flag applies group permissions on the /etc/elasticsearch directory to ensure that Elasticsearch can read any contained files and subdirectories. All files and subdirectories inherit the root:elasticsearch ownership. Running commands from this directory or any subdirectories, such as the elasticsearch-keystore tool, requires root:elasticsearch permissions.

Elasticsearch loads its configuration from the /etc/elasticsearch/elasticsearch.yml file by default. The format of this config file is explained in Configure Elasticsearch.

The RPM package also has a system configuration file (/etc/sysconfig/elasticsearch), which allows you to set the following parameters:

Parameter Description
ES_JAVA_HOME Set a custom Java path to be used.
ES_PATH_CONF Configuration file directory (which needs to include elasticsearch.yml, jvm.options, and log4j2.properties files); defaults to /etc/elasticsearch.
ES_JAVA_OPTS Any additional JVM system properties you may want to apply.
RESTART_ON_UPGRADE Configure restart on package upgrade, defaults to false. This means you will have to restart your Elasticsearch instance after installing a package manually. The reason for this is to ensure, that upgrades in a cluster do not result in a continuous shard reallocation resulting in high network traffic and reducing the response times of your cluster.
Note

Distributions that use systemd require that system resource limits be configured via systemd rather than via the /etc/sysconfig/elasticsearch file. See Systemd configuration for more information.

When you start Elasticsearch for the first time, TLS is configured automatically for the HTTP layer. A CA certificate is generated and stored on disk at:

/etc/elasticsearch/certs/http_ca.crt

The hex-encoded SHA-256 fingerprint of this certificate is also output to the terminal. Any clients that connect to Elasticsearch, such as the Elasticsearch Clients, Beats, standalone Elastic Agents, and Logstash must validate that they trust the certificate that Elasticsearch uses for HTTPS. Fleet Server and Fleet-managed Elastic Agents are automatically configured to trust the CA certificate. Other clients can establish trust by using either the fingerprint of the CA certificate or the CA certificate itself.

If the auto-configuration process already completed, you can still obtain the fingerprint of the security certificate. You can also copy the CA certificate to your machine and configure your client to use it.

Copy the fingerprint value that’s output to your terminal when Elasticsearch starts, and configure your client to use this fingerprint to establish trust when it connects to Elasticsearch.

If the auto-configuration process already completed, you can still obtain the fingerprint of the security certificate by running the following command. The path is to the auto-generated CA certificate for the HTTP layer.

openssl x509 -fingerprint -sha256 -in config/certs/http_ca.crt

The command returns the security certificate, including the fingerprint. The issuer should be {{es}} security auto-configuration HTTP CA.

issuer= /CN={{es}} security auto-configuration HTTP CA
SHA256 Fingerprint=<fingerprint>

If your library doesn’t support a method of validating the fingerprint, the auto-generated CA certificate is created in the following directory on each Elasticsearch node:

/etc/elasticsearch/certs/http_ca.crt

Copy the http_ca.crt file to your machine and configure your client to use this certificate to establish trust when it connects to Elasticsearch.

The RPM places config files, logs, and the data directory in the appropriate locations for an RPM-based system:

Type Description Default Location Setting
home Elasticsearch home directory or $ES_HOME /usr/share/elasticsearch
bin Binary scripts including elasticsearch to start a node and elasticsearch-plugin to install plugins /usr/share/elasticsearch/bin
conf Configuration files including elasticsearch.yml /etc/elasticsearch [ES_PATH_CONF](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#config-files-location)
conf Environment variables including heap size, file descriptors. /etc/sysconfig/elasticsearch
conf Generated TLS keys and certificates for the transport and http layer. /etc/elasticsearch/certs
data The location of the data files of each index / shard allocated on the node. /var/lib/elasticsearch path.data
jdk The bundled Java Development Kit used to run Elasticsearch. Can be overridden by setting the ES_JAVA_HOME environment variable in /etc/sysconfig/elasticsearch. /usr/share/elasticsearch/jdk
logs Log files location. /var/log/elasticsearch path.logs
plugins Plugin files location. Each plugin will be contained in a subdirectory. /usr/share/elasticsearch/plugins
repo Shared file system repository locations. Can hold multiple locations. A file system repository can be placed in to any subdirectory of any directory specified here. Not configured path.repo

When you install Elasticsearch, the following certificates and keys are generated in the Elasticsearch configuration directory. These files are used to connect a Kibana instance to your secured Elasticsearch cluster and to encrypt internode communication. The files are listed here for reference.

http_ca.crt
The CA certificate that is used to sign the certificates for the HTTP layer of this Elasticsearch cluster.
http.p12
Keystore that contains the key and certificate for the HTTP layer for this node.
transport.p12
Keystore that contains the key and certificate for the transport layer for all the nodes in your cluster.

http.p12 and transport.p12 are password-protected PKCS#12 keystores. Elasticsearch stores the passwords for these keystores as secure settings. To retrieve the passwords so that you can inspect or change the keystore contents, use the bin/elasticsearch-keystore tool.

Use the following command to retrieve the password for http.p12:

bin/elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password

Use the following command to retrieve the password for transport.p12:

bin/elasticsearch-keystore show xpack.security.transport.ssl.keystore.secure_password

You now have a test Elasticsearch environment set up. Before you start serious development or go into production with Elasticsearch, you must do some additional setup: