-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialize Paths before loading the keystore #10706
Initialize Paths before loading the keystore #10706
Conversation
@urso @kvch I would like your input here, due to a bug the location of the keystore was not clear and could have been created in the config dir instead of the data dir. So by making the above change, it ensures that the Keystore file is always created in the data dir. But after slack discussion maybe the real location of the keystore should be in the configuration directory next to the yaml. WDYT? |
Copying over from our chat, the issue arose when the default
vs:
The docs are currently clear that the keystore goes in the config dir but 7.0 is an opportunity to change this. https://www.elastic.co/guide/en/apm/server/current/keystore.html#creating-keystore. |
I think keystore should go under the data dir. It is a file manipulated by a Beat, so it is more similar to a registry file. Under the config folder, there are files which can be edited by users using a text editor of their choice. However, keystore is not intended to be modified via such tools, only using the Beat. |
@kvch It is indeed a file manipulated by the beat CLI, but at the same time creating a file on a single host and deploy it to multiple machines is a possibility. |
@ph True. Then I agree with you, it should go under the dir config. |
The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack.
Ok, I will do the path change in another PR, this still need to go in and it will make sure the data path is correctly respected. |
cf2933a
to
fb1949b
Compare
rebased on top of master. |
* Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233)
…re (#11325) * Initialize Paths before loading the keystore (#10706) * Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233) * Update CHANGELOG.next.asciidoc
* Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233)
…re (#11497) Cherry-pick of PR #10706 to 6.7 branch. Original message: The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack.
The paths were incorrectly initialized meaning that instead of creating
the keystore in the data directory it was created next to the binary.
The problem was the call to
paths.InitPaths()
was done after loadingthe keystore, this was causing a chicken and egg situation and
paths.Resolve(path.Data, "hello")
was returning "hello" instead ofdata/hello
.To solve that situation we do a partial extract of the configuration,
just enough to initialize the paths and we move on to the keystore and
the complete unpack.