fix: Meraki-only setup blocked by Mist-hardcoded init and $HOME env loader#54
Merged
Conversation
…oader
Two bugs in the init path stop a Meraki-only (or Ubiquiti-only)
deployment from running multi-vendor commands like `refresh all`,
even though those commands don't need a Mist client at all.
1. xdg.FindEnvFile() only searches CWD and $XDG_CONFIG_HOME/wifimgr/.
The most common dotenv location, $HOME/.env.wifimgr, is invisible
to the loader. WIFIMGR_PASSWORD lives in that file, so when it
doesn't get into the process env, credential decryption silently
skips and the user sees:
Failed to load .env.wifimgr file: env file not found
Add $HOME to the search path between CWD (project override) and
XDG (system fallback). Purely additive — existing CWD and XDG
placements keep working.
2. cmd/root.go's initializeAPI hard-required a Mist API in the
registry. The legacy globalClient (single-Mist api.Client) is
built from the first Vendor=="mist" entry, and if none exists,
init bails with:
Error: no Mist API credentials found - ensure api.mist is
configured and -e flag is used
Multi-vendor commands (refresh, show, search) never touch
globalClient — they go straight to the registry. Make the
legacy construction conditional: skip globalClient when no Mist
API is configured, but still build globalConfig with the Files
section populated so non-API-touching code paths work.
Add a requireMistClient(commandName) guard and wire it into the
four legacy entry points (apply, set ap, backup, site ap) so
they emit a clear error instead of nil-dereferencing if invoked
without a Mist API.
Test plan:
- internal/xdg: TestFindEnvFile gains "env file in HOME" and
"HOME takes precedence over XDG" cases; sandboxes $HOME so the
test never sees the developer's real dotfile.
- Meraki-only manual flow:
wifimgr -e refresh all
No longer errors on missing Mist credentials.
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
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
Two bugs that together stopped a Meraki-only deployment from running
wifimgr -e refresh all, even though no Mist code path is involved.1.
xdg.FindEnvFile()ignored\$HOME/.env.wifimgrThe loader searched only:
./.env.wifimgr(CWD)\$XDG_CONFIG_HOME/wifimgr/.env.wifimgrA
.env.wifimgrin\$HOME— the most common dotenv convention (ssh, gitconfig, dotenv libraries) — was invisible.WIFIMGR_PASSWORDlives there for many users, so without it the encrypted Merakiapi_keycouldn't decrypt and the run continued in a half-initialized state.Fix: search
\$HOMEbetween CWD (project override) and XDG (system fallback). Purely additive.2.
initializeAPIhard-required a Mist APIcmd/root.gowalked the registry looking forVendor == \"mist\"to build the legacy single-MistglobalClient. If none existed, it killed init with:Multi-vendor commands (
refresh,show,search) never touchglobalClient— they use the registry directly. So a Meraki-only setup couldn't reach any command, including ones that don't need Mist at all.Fix:
Skip
globalClientconstruction when no Mist API is configured. Still buildglobalConfigwithFilespopulated, so paths-only consumers work.Add
requireMistClient(commandName)and wire it into the four legacy Mist-only entry points (apply,set ap,backup,site ap). They emit a clean message instead of nil-derefing if invoked without a Mist API:Test plan
go test ./...— all greeninternal/xdg/TestFindEnvFile— adds "env file in HOME" and "HOME takes precedence over XDG" cases; sandboxes\$HOMEso the test no longer reads the developer's real dotfilewifimgr -e refresh allruns to completion