docs: worker.local.env, and the search flag that silently does nothing - #177
Merged
Conversation
Search configuration was documented nowhere in this repo - not the correct variable names, not where to put them, not that they are dropped on reinstall. An operator configuring it had to get the names from somewhere else, and at least one circulating spelling is wrong. The variable is SEARCH_ENABLED. `SEARCH_ENABLE` without the D is read by nothing: the worker starts cleanly, reports healthy, and never advertises search. There is no error and no log line, so the only way to notice is to observe that the capability never appears - which can take a while, and looks like a network problem rather than a typo. Verified against the shipped image rather than assumed: strings /bin/worker | grep -oE '\bSEARCH_[A-Z_]+\b' -> SEARCH_ENABLED `SEARCH_ENABLE` does not occur in the binary at all. The doc includes that command so the next reader can check their own image instead of trusting a file that may age badly. Also records the two things that cost real time when setting this up by hand: the container must run as root (session-keys.enc is root:root 0600, so the image's default appuser cannot read its own keystore and crash-loops), and this file alone is not a complete environment - without the installer's -e flags the worker exits with "CHAIN_ID is required" and four more.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Search configuration is documented nowhere in this repo — not the variable names, not where to put them, not that they get dropped on reinstall. An operator configuring it has to get the names from elsewhere, and at least one circulating spelling is wrong.
The variable is
SEARCH_ENABLED, with a DSEARCH_ENABLEis read by nothing. Set it and the worker starts cleanly, reports healthy, and never advertises search. No error, no log line — the only way to notice is that the capability never shows up, which looks like a network problem rather than a typo.Verified against the shipped image, not assumed:
SEARCH_ENABLEdoes not occur in the binary at all. The doc includes that command so readers can check their own image rather than trust a file that may age.Also recorded
Two things that cost real time doing this by hand:
--user root—session-keys.encisroot:root 0600, so the image's defaultappusercannot read its own keystore and crash-loops onpermission denied.worker.local.envalone is not a complete environment. Starting with only--env-filefails withCHAIN_ID is requiredplus four siblings; the installer's-eflags supply those.Pairs with #176, which added the
--env-filesupport this documents.