collector crashes with KeyError 'store_path' on fresh install (config template omits the key) #53

New Issue

2026-09-10T04:10:11Z

xavierk commented

2026-09-10 04:10:11 +00:00

Symptom

On a fresh v0.3.1 rpm install (zypper install fenris, openSUSE Tumbleweed), fenris-collect.service fails on every run:

Sep 10 09:38:56 fenris-collect[16882]: Collection error: 'store_path'

Root cause

collect.py load_config() documents and returns exactly one key: device.
collector.py:295 calls get_store_path(config).
store.py:20 does return Path(config["store_path"]) — bare [] lookup, no default.
monitor.py has DEFAULT_STORE_PATH = Path("/var/lib/fenris/observations.db") with getattr(args, 'store_path', DEFAULT_STORE_PATH) fallbacks; the collector path has no equivalent.

The shipped /etc/fenris/fenris.conf template does not mention store_path, so every fresh install crashes until the key is added manually:

store_path = /var/lib/fenris/observations.db

Why tests missed it

370 tests pass because tests call the collector with an in-memory config dict that includes store_path. Nothing exercises the packaged config-file → collector path end to end.

Suggested fix

Default in get_store_path (or collector config load):

def get_store_path(config: dict) -> Path:
    return Path(config.get("store_path", "/var/lib/fenris/observations.db"))

Plus: document store_path in the packaging/fenris.conf template, and add an integration test that loads the packaged template through load_config() → run_collect.

Found while verifying — second, environment-specific issue

On zypper/Tumbleweed, packaging/fenris.repo gpgkey= points at the packaging key, but Gitea signs repodata/repomd.xml with its per-owner RPM signing key (repository.key). zypper uses gpgkey= to verify repo metadata → "Signature verification failed for repomd.xml". dnf is unaffected (repo_gpgcheck=0, package sigs checked against the packaging key). A space-separated double gpgkey (metadata key + packaging key) may satisfy both; needs a Tumbleweed consumer test.

Local workaround applied on the affected machine: gpgkey= repointed to https://git.bongbetic.com/api/packages/xavierk/rpm/repository.key (packaging key separately imported into rpmdb for package verification).

## Symptom On a fresh v0.3.1 rpm install (`zypper install fenris`, openSUSE Tumbleweed), `fenris-collect.service` fails on every run: ``` Sep 10 09:38:56 fenris-collect[16882]: Collection error: 'store_path' ``` ## Root cause - `collect.py` `load_config()` documents and returns exactly one key: `device`. - `collector.py:295` calls `get_store_path(config)`. - `store.py:20` does `return Path(config["store_path"])` — bare `[]` lookup, no default. - `monitor.py` has `DEFAULT_STORE_PATH = Path("/var/lib/fenris/observations.db")` with `getattr(args, 'store_path', DEFAULT_STORE_PATH)` fallbacks; the collector path has no equivalent. The shipped `/etc/fenris/fenris.conf` template does not mention `store_path`, so every fresh install crashes until the key is added manually: ``` store_path = /var/lib/fenris/observations.db ``` ## Why tests missed it 370 tests pass because tests call the collector with an in-memory config dict that includes `store_path`. Nothing exercises the packaged config-file → collector path end to end. ## Suggested fix Default in `get_store_path` (or collector config load): ```python def get_store_path(config: dict) -> Path: return Path(config.get("store_path", "/var/lib/fenris/observations.db")) ``` Plus: document `store_path` in the `packaging/fenris.conf` template, and add an integration test that loads the packaged template through `load_config()` → `run_collect`. ## Found while verifying — second, environment-specific issue On zypper/Tumbleweed, `packaging/fenris.repo` `gpgkey=` points at the packaging key, but Gitea signs `repodata/repomd.xml` with its per-owner RPM signing key (`repository.key`). zypper uses `gpgkey=` to verify repo metadata → "Signature verification failed for repomd.xml". dnf is unaffected (`repo_gpgcheck=0`, package sigs checked against the packaging key). A space-separated double `gpgkey` (metadata key + packaging key) may satisfy both; needs a Tumbleweed consumer test. Local workaround applied on the affected machine: `gpgkey=` repointed to `https://git.bongbetic.com/api/packages/xavierk/rpm/repository.key` (packaging key separately imported into rpmdb for package verification).

xavierk referenced this issue from a commit

2026-09-10 04:15:04 +00:00

fix(store): default store_path when config omits it (issue #53)

xavierk commented

2026-09-10 04:17:22 +00:00

Resolved in v0.3.2 (commit 512df2a, release):

get_store_path() falls back to DEFAULT_STORE_PATH = /var/lib/fenris/observations.db when the config omits store_path (src/fenris/store.py)
packaging/fenris.conf template documents the optional key
tests/test_store_config.py covers default fallback, override, and the packaged-template → collector-ready path (would have caught #53)

Verified end to end on the reporting machine (openSUSE Tumbleweed): removed the manual store_path line, upgraded 0.3.1 → 0.3.2, fenris-collect.service green, fenris status fresh.

The zypper metadata-signing quirk noted in the report is left open for a follow-up (a double gpgkey line may serve dnf and zypper from one repo file; needs a Tumbleweed consumer probe before changing the shipped fenris.repo).

Resolved in **v0.3.2** (commit 512df2a, [release](https://git.bongbetic.com/xavierk/Fenris/releases/tag/v0.3.2)): - `get_store_path()` falls back to `DEFAULT_STORE_PATH = /var/lib/fenris/observations.db` when the config omits `store_path` (src/fenris/store.py) - `packaging/fenris.conf` template documents the optional key - `tests/test_store_config.py` covers default fallback, override, and the packaged-template → collector-ready path (would have caught #53) Verified end to end on the reporting machine (openSUSE Tumbleweed): removed the manual `store_path` line, upgraded 0.3.1 → 0.3.2, `fenris-collect.service` green, `fenris status` fresh. The zypper metadata-signing quirk noted in the report is left open for a follow-up (a double `gpgkey` line may serve dnf and zypper from one repo file; needs a Tumbleweed consumer probe before changing the shipped `fenris.repo`).

xavierk closed this issue

2026-09-10 04:17:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xavierk/Fenris#53