I'm in the process of attempting to install Elasticsearch on a group of CentOS 7 servers. I am installing using the rpm provided in the Elasticsearch repo. However there appears to be an issue with the automated security auto-configuration. The auto-configuration steps are skipped but it is not clear what has led to them been deemed unnecessary. Install output is below:
~]# yum install --enablerepo=elasticsearch elasticsearch
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Resolving Dependencies
--> Running transaction check
---> Package elasticsearch.x86_64 0:8.0.0-1 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===============================================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================================
Installing:
elasticsearch x86_64 8.0.0-1 elasticsearch 492 M
Transaction Summary
===============================================================================================================================================
Install 1 Package
Total download size: 492 M
Installed size: 1.0 G
Is this ok [y/d/N]: y
Downloading packages:
elasticsearch-8.0.0-x86_64.rpm | 492 MB 00:00:15
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Creating elasticsearch group... OK
Creating elasticsearch user... OK
Installing : elasticsearch-8.0.0-1.x86_64 1/1
--------------------------- Security autoconfiguration information ------------------------------
Skipping auto-configuration because security features appear to be already configured.
-------------------------------------------------------------------------------------------------
### NOT starting on installation, please execute the following statements to configure elasticsearch service to start automatically using systemd
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
### You can start elasticsearch service by executing
sudo systemctl start elasticsearch.service
Created elasticsearch keystore in /etc/elasticsearch/elasticsearch.keystore
Verifying : elasticsearch-8.0.0-1.x86_64 1/1
Installed:
elasticsearch.x86_64 0:8.0.0-1
Complete!
These servers are new builds that have not been used for anything previously and no configuration has been done prior to the installation.
Is anyone able to advise why security auto-configuration is being skipped?
I can't find any details in the documentation as to what elements are checked to arrive at the conclusion that security features have already been configured. I have unpacked the scripts in the rpm but it isn't clear from them either how the decision is reached.
I agree that the message is not informational enough and we should do a better job at describing what went wrong. I’ll open an issue and we will attempt to make this better, thanks for raising this!
The cases for not doing the security autoconfiguration are a few, most often it is that the configuration files already exist from a previous installation or that the user doing the installation doesn’t have permission to write to the directory where Elasticsearch config resides. I see you run yum as root so the latter should not be the case.
Are you certain that there is no previous package installation in the server you are doing the ‘yum install’ ?
Were /var/lib/Elasticsearch , /usr/share/Elasticsearch and /etc/elastisearch non existent before you ran the command ?
Can you reproduce the behaviour in every server ?
I’ll try and reproduce this in our side too with centos 7
I think you've probably hit on the issue. I have created the /var/lib/Elasticsearch directory and mounted it on a separate hard disk prior to installation. The aim being that it would allow for easier expansion of the disk in future if required. It seemed cleaner to create this prior to installation.
Moving forward would you advise unmounting this disk, deleting the directory, running the install and then moving the contents of the /var/lib/Elasticsearch created by the install to the new hard disk?
Also for the sake of completeness and for others who may stumble across this in the future the answers to all your questions are below:
There is no previous package installation present.
As stated above /var/lib/Elasticsearch was created prior to installation. None of the other directories have been created.
Every server has the same behaviour, however they also all have the /var/lib/Elasticsearch already created.
This should happen only if the /var/lib/elsticsearch is non-empty or if the user that installs Elasticsearch can’t write to it. It’s perfectly fine for the dir to pre-exist.
Can it be that this is shared between all the servers (so a previous installation has already written there)or that other data resides there too ?
This is the data dir for the Elasticsearch node so it would make sense for you to not share between nodes and not store any additional data there. We stop autoconfiguration if we find any data in the data dir as this is a strong indication that Elasticsearch is not starting up for the first time.
The /var/lib/Elasticsearch/ directory only contains the below prior to installation.
~]# ls -la /var/lib/elasticsearch/
total 24
drwxr-xr-x 3 root root 4096 Feb 22 22:47 .
drwxr-xr-x. 37 root root 4096 Feb 22 22:47 ..
drwx------ 2 root root 16384 Feb 22 22:47 lost+found
This is what I would expect for a newly created directory.
The installation is being done as root so there should be no issue writing to the directory. To confirm I've shown the permissions of the directory below:
~]# ls -la /var/lib/ |grep elastic
drwxr-xr-x 3 root root 4096 Feb 22 22:47 elasticsearch
This directory is unique to the server the installation is being completed upon. It isn't shared between servers. Each node has a separate /var/lib/Elasticsearch/ directory on separate virtual disks.
I can confirm however that by unmounting and removing the /var/lib/Elasticsearch/ directory the security auto-configuration element of the installation now completes as expected so this is obviously the root cause of the issue.
It looks like that the lost+found dir is tripping this. The dir is technically not empty so we do not proceed with the autoconfiguration.
This is a corner case we hadn’t considered. We can look into how and if we should incorporate this in the check we’re making. Thanks for raising this and working with us to figure out the root cause.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.