Install Elasticsearch with RPM
editInstall Elasticsearch with RPM
editThe RPM 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.
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.
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
For a step-by-step example of setting up the Elastic Stack on your own premises, try out our tutorial: Installing a self-managed Elastic Stack.
Import the Elasticsearch GPG Key
editWe 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
Installing from the RPM repository
editVersion 9.0.0-beta1 of Elasticsearch has not yet been released.
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:
Download and install the RPM manually
editVersion 9.0.0-beta1 of Elasticsearch has not yet been released. The RPM might not be available.
The RPM for Elasticsearch v9.0.0-beta1 can be downloaded from the website and installed as follows:
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-beta1-x86_64.rpm wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-beta1-x86_64.rpm.sha512 shasum -a 512 -c elasticsearch-9.0.0-beta1-x86_64.rpm.sha512 sudo rpm --install elasticsearch-9.0.0-beta1-x86_64.rpm
Compares the SHA of the downloaded RPM and the published checksum, which should output
|
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.
Start Elasticsearch with security enabled
editWhen installing Elasticsearch, security features are enabled and configured by default. When you install Elasticsearch, the following security configuration occurs automatically:
-
Authentication and authorization are enabled, and a password is generated for
the
elastic
built-in superuser. - Certificates and keys for TLS are generated for the transport and HTTP layer, and TLS is enabled and configured with these keys and certificates.
The password and certificate and keys are output to your terminal.
You can reset the password for the elastic
user with the elasticsearch-reset-password
command.
We recommend storing the elastic
password as an environment variable in your shell. For example:
export ELASTIC_PASSWORD="your_password"
Reconfigure a node to join an existing cluster
editWhen 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.
-
On any node in your existing cluster, generate a node enrollment token:
/usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node
- Copy the enrollment token, which is output to your terminal.
-
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.
-
Start your new node using
systemd
.
Enable automatic creation of system indices
editSome commercial 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
the commercial features to create the following indices:
action.auto_create_index: .monitoring*,.watches,.triggered_watches,.watcher-history*,.ml*
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.
Running Elasticsearch with systemd
editTo 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
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
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 Elasticsearch... 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 Elasticsearch.
To avoid this, upgrade your systemd
to at least version 238. You can also
temporarily work around the problem by extending the TimeoutStartSec
parameter.
Check that Elasticsearch is running
editYou 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 -u elastic:$ELASTIC_PASSWORD https://localhost:9200
Ensure that you use
|
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" : "9.12.0", "minimum_wire_compatibility_version" : "1.2.3", "minimum_index_compatibility_version" : "1.2.3" }, "tagline" : "You Know, for Search" }
Configuring Elasticsearch
editThe /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 Configuring Elasticsearch.
The RPM also has a system configuration file (/etc/sysconfig/elasticsearch
),
which allows you to set the following parameters:
|
Set a custom Java path to be used. |
|
Configuration file directory (which needs to include |
|
Any additional JVM system properties you may want to apply. |
|
Configure restart on package upgrade, defaults to |
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.
Connect clients to Elasticsearch
editWhen 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.
Use the CA fingerprint
editCopy 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 Elasticsearch security auto-configuration HTTP CA
.
issuer= /CN=Elasticsearch security auto-configuration HTTP CA SHA256 Fingerprint=<fingerprint>
Use the CA certificate
editIf 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.
Directory layout of RPM
editThe 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 |
|
|
bin |
Binary scripts including |
|
|
conf |
Configuration files including |
|
|
conf |
Environment variables including heap size, file descriptors. |
|
|
conf |
Generated TLS keys and certificates for the transport and http layer. |
|
|
data |
The location of the data files of each index / shard allocated on the node. |
|
|
jdk |
The bundled Java Development Kit used to run Elasticsearch. Can
be overridden by setting the |
|
|
logs |
Log files location. |
|
|
plugins |
Plugin files location. Each plugin will be contained in a subdirectory. |
|
|
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 |
|
Security certificates and keys
editWhen you install Elasticsearch, the following certificates and keys are generated in the Elasticsearch configuration directory, which 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
Next steps
editYou 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:
- Learn how to configure Elasticsearch.
- Configure important Elasticsearch settings.
- Configure important system settings.