-
Notifications
You must be signed in to change notification settings - Fork 162
Azure-keystore credentials not set #180
Comments
Hey @okke-formsma, I just ran a deployment to test this. The values were inserted into the root@data-0:/# /usr/share/elasticsearch/bin/elasticsearch-keystore list
azure.client.default.account
azure.client.default.key
bootstrap.password
keystore.seed However, when trying to create a repository immediately, the following error is returned: PUT _snapshot/backup_1
{
"type": "azure"
}
----
{
"error": {
"root_cause": [
{
"type": "repository_verification_exception",
"reason": "[backup_1] path is not accessible on master node"
}
],
"type": "repository_verification_exception",
"reason": "[backup_1] path is not accessible on master node",
"caused_by": {
"type": "i_o_exception",
"reason": "Can not write blob master.dat-temp",
"caused_by": {
"type": "storage_exception",
"reason": "storage_exception: The specified container does not exist."
}
}
},
"status": 500
} According to the azure-repository documentation, the container needs to be created in the storage account before creating a repository. The default container name is Set-AzureRmCurrentStorageAccount -ResourceGroupName "<resource group>" -Name "<storage account name>"
New-AzureStorageContainer -Name "elasticsearch-snapshots" then PUT _snapshot/backup_1
{
"type": "azure"
}
----
{
"acknowledged": true
} and PUT /_snapshot/backup_1/snapshot_1?wait_for_completion=true
----
{
"snapshot": {
"snapshot": "snapshot_1",
"uuid": "hv5cp2e2TAqvC9RV29RsKQ",
"version_id": 6020399,
"version": "6.2.3",
"indices": [
".watcher-history-7-2018.04.18",
".triggered_watches",
".security-6",
".monitoring-kibana-6-2018.04.18",
".monitoring-es-6-2018.04.18",
".watches",
".monitoring-alerts-6"
],
"include_global_state": true,
"state": "SUCCESS",
"start_time": "2018-04-18T04:51:49.107Z",
"start_time_in_millis": 1524027109107,
"end_time": "2018-04-18T04:51:51.516Z",
"end_time_in_millis": 1524027111516,
"duration_in_millis": 2409,
"failures": [],
"shards": {
"total": 7,
"failed": 0,
"successful": 7
}
}
} Would you be able to try creating the container in the storage account, to see if this addresses the issue? |
@russcam Thanks for investigating. I'll try a new deployment to investigate later today. |
thanks @okke-formsma - you'll need to target master branch (commit e89baf2) as it contains a fix for the oracle-java8-installer apt package |
@russcam I ran with the latest commit but still have the same issue. When is the Maybe the x-pack or kibana plugins create the keystore in your case? I'm running with those turned off.
|
What version of Elasticsearch are you deploying? |
Actually we run a slightly modified version which installs 6.2.3 (6.2.2 has some issues with restoring backups from azure). I tested the elastic-keystore commands on 6.2.2 and these behaved identically. (both 6.2.2 and 6.2.3 don't create a keystore unless the 'create' command is issued) |
@okke-formsma do you also install X-Pack plugin in your template, and therefore set a bootstrap password? |
We do not install xpack or kibana. Configuration template follows below, we install using the following command;
|
Running a test without installing X-Pack plugin now |
Can replicate - will push a fix now |
@okke-formsma I've opened #184. Would you mind trying it from the |
This commit fixes a bug when installing repository-azure plugin without installing x-pack. When x-pack is installed, it creates the keystore. Without installing x-pack, the repository-azure plugin fails to set azure storage account credentials within the keystore because the keystore does not exist. Closes #180
@russcam Thank you for fixing, I have tested and it works perfectly now. |
Hi,
It seems that the azure-keystore credentials are not set even though the 'elasticsearch-keystore add' commands have executed successfully.
I think this is caused by a missing call to
elastic-keystore create
before theadd
commands.azure-marketplace/src/scripts/elasticsearch-ubuntu-install.sh
Line 704 in acd6ae2
https://www.elastic.co/guide/en/elasticsearch/reference/current/secure-settings.html
The text was updated successfully, but these errors were encountered: