docker: run chown on Elasticsearch directory #55
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With Elasticsearch 5, proper permissions (by default for user 1000) must be set on the data directory on the host system. Users have consistently run the `pelias` helper script as users with a different UID than 1000, or the one configured in `.env` (usually root), so this change uses `chown` to set ownership of the Elasticsearch data directory. Connects #33
This was referenced Nov 26, 2018
|
i can attempt to test this as soon as i have some info out of my freshly-working pelias install from master - i dont have enough disk right now to do both |
|
This worked well for us in our automated builds, and looks safe enough. |
|
this worked for me as well - after changing ownership to root:root for my data dir the |
orangejulius
added a commit
that referenced
this pull request
Jan 16, 2019
In #55 we added a `chown` line that attempts to set proper permissions on the Elasticsearch data directory. `chown` can generally only be run as root, so this PR adds handling for the common case where `chown` fails. In general, either the pelias CLI is run as root, and the `chown` will succeed, or the CLI is run as the same user the Docker container processes will run as. In this case the `mkdir` on the preceeding line will set up the directory with proper ownership. We can't really do anything in an automated way to handle people running the Pelias CLI as a different, non-root, user than the one they want the containers to run with, so I think this is the best we can do. This will be even more useful once #62 is merged.
orangejulius
added a commit
that referenced
this pull request
Jan 16, 2019
In #55 we added a `chown` line that attempts to set proper permissions on the Elasticsearch data directory. `chown` can generally only be run as root, so this PR adds handling for the common case where `chown` fails. In general, either the pelias CLI is run as root, and the `chown` will succeed, or the CLI is run as the same user the Docker container processes will run as. In this case the `mkdir` on the preceding line will set up the directory with proper ownership. We can't really do anything in an automated way to handle people running the Pelias CLI as a different, non-root, user than the one they want the containers to run with, so I think this is the best we can do. This will be even more useful once #62 is merged.
orangejulius
added a commit
that referenced
this pull request
Mar 5, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. command is run to update those permissions. This code attempts to detect that case and recommend the proper command to fix it. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Mar 5, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Mar 5, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Mar 5, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Mar 6, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Mar 6, 2019
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
orangejulius
added a commit
that referenced
this pull request
Sep 15, 2020
If the Elasticsearch datadir is not owned by the user specified in $DOCKER_USER, Elasticsearch will fail to start. Since #55 the helper scripts attempt to remedy this situation if the `pelias` script is run as root (which is not recommended but is often done). However, if the `pelias` script is not run as root and the permissions are incorrect, this situation cannot be automatically fixed. This code attempts to detect that case and recommend the proper command to run (with sudo) and set proper directory permissions. Connects #31 Connects #73
calpb
pushed a commit
to sorelle/docker
that referenced
this pull request
Mar 29, 2021
docker: run chown on Elasticsearch directory
calpb
pushed a commit
to sorelle/docker
that referenced
this pull request
Mar 29, 2021
In pelias#55 we added a `chown` line that attempts to set proper permissions on the Elasticsearch data directory. `chown` can generally only be run as root, so this PR adds handling for the common case where `chown` fails. In general, either the pelias CLI is run as root, and the `chown` will succeed, or the CLI is run as the same user the Docker container processes will run as. In this case the `mkdir` on the preceding line will set up the directory with proper ownership. We can't really do anything in an automated way to handle people running the Pelias CLI as a different, non-root, user than the one they want the containers to run with, so I think this is the best we can do. This will be even more useful once pelias#62 is merged.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With Elasticsearch 5, proper permissions (by default for user 1000) must
be set on the data directory on the host system.
Users have consistently run the
peliashelper script as users with adifferent UID than 1000, or the one configured in
.env(usually root),so this change uses
chownto set ownership of the Elasticsearch datadirectory.
Connects #33
Connects #53