fix(installer): resolve the gateway config dir like the CLI does - #4063
Open
fede-kamel wants to merge 1 commit into
Open
fede-kamel wants to merge 1 commit into
fede-kamel wants to merge 1 commit into
Conversation
install.sh hardcoded $TARGET_HOME/.config/openshell in two places: the readiness check, which reads the client certificates it expects the gateway registration to have written, and the cleanup that removes a stale openshell entry before re-adding it. The CLI instead keeps both under $XDG_CONFIG_HOME/openshell whenever that variable is set, so with the variable pointing anywhere other than ~/.config the installer and the CLI looked in different directories: the readiness check waited for certificates that were never going to appear there, and the cleanup left the real stale entry in place. Resolve the directory through as_target_user instead, which answers from the same environment the CLI is invoked in. That covers both branches without duplicating their logic: the same-user branch inherits the caller's XDG_CONFIG_HOME, while the sudo and runuser branches reset the environment and fall back to the target user's home. An empty XDG_CONFIG_HOME falls back to $HOME/.config, following the XDG base directory specification. The CLI diverges here: xdg_config_dir treats a set-but-empty value as set and joins onto it, yielding the relative path "openshell", which no installer path can usefully match. Worth fixing separately in the CLI. Signed-off-by: fede-kamel <fkamelhar@gmail.com>
fede-kamel
requested review from
a team,
derekwaynecarr,
mrunalp and
sjenning
as code owners
October 1, 2026 17:35
This branch has not been deployed
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.
Summary
install.shhardcoded$TARGET_HOME/.config/openshellin two places while theCLI keeps gateway entries and client certificates under
$XDG_CONFIG_HOME/openshellwhenever that variable is set:wait_for_local_gateway_listener, which reads the mTLS client bundle that thegateway registration writes.
remove_local_gateway_registration, which clears a staleopenshellentrybefore re-adding it.
With
XDG_CONFIG_HOMEpointing anywhere other than~/.config, the installerand the CLI looked in different directories: the readiness check waited out its
timeout on certificates that were never going to appear there, and the cleanup
left the real stale entry untouched.
Related Issue
Fixes #4042
Changes
target_openshell_config_dir, which resolves the directory throughas_target_userso the answer comes from the same environment the CLI isinvoked in. This covers both branches without restating their logic: the
same-user branch inherits the caller's
XDG_CONFIG_HOME, while thesudoandrunuserbranches reset the environment and fall back to the target user'shome.
remove_snap_gateway_registrationis deliberately untouched: the snap confinesits own config root under
~/snap/openshell/common/.config, which is notXDG_CONFIG_HOME.Testing
Added three assertions to
tasks/scripts/test-install-sh.sh, which sourcesinstall.shand exercises the function directly. Full suite passes:They are a real guard, not a vacuous pass — reverting only the helper to the old
hardcoded path fails the suite:
Resolution probed against the CLI's own rule
(
openshell_core::paths::xdg_config_dirjoined withopenshell), running thereal
as_target_user:XDG_CONFIG_HOME$HOME/.config/openshell/home/u/cfg/home/u/cfg/openshellopenshell(relative)$HOME/.config/openshellA divergence worth a separate look
The empty case is the one place this does not match the CLI byte for byte. The
installer follows the XDG base directory specification, which says an empty
value is treated as unset.
xdg_config_dirinstead takesenv::var'sOk("")as set and joins onto it, so it yields the relative path
openshell,resolved against the process working directory. No installer path can usefully
match that, and it looks like a bug on the CLI side rather than something to
mirror here. Happy to file it separately if you agree.