Documentation
¶
Overview ¶
Package configreceiver implements the agent side of the pull-based plugin-config flow defined by alpacon-server. Plugins (dhcp, dns, proxy, …) embed a Receiver in their WS command loop and supply an Applier; the package owns the fetch / verify / report machinery that every plugin needs identically.
Flow:
- alpacon-server emits a “config_updated“ WS event with the “plugin_config_id“ of the freshly-rendered config row.
- The plugin receives that event and hands it to Receiver.Handle.
- Receiver fetches the body via “GET /api/plugins/configs/{id}/“, verifies the sha256 hash matches what the event reported, then decodes the standard “{files, metadata}“ envelope and calls the plugin-supplied Applier.
- Receiver reports success or failure via “POST /api/plugins/configs/{id}/applied/“ so the server can tell which version is live (drift detection / audit).
Lives under github.com/alpacax/alpamon because every plugin already depends on alpamon; adding a separate "alpacon-plugin-sdk" repo would add release-coordination overhead with no offsetting benefit.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Applier ¶
Applier installs a fetched config on disk and restarts/reloads the service. Errors returned from Apply are reported verbatim to the server so administrators can debug from the alpacon UI.
type Envelope ¶
type Envelope struct {
Files map[string]string `json:"files"`
Metadata map[string]json.RawMessage `json:"metadata"`
}
Envelope is the standardised config-text shape the server emits. “files“ carries one or more files keyed by on-disk name; metadata is plugin-specific structured data (raw JSON so plugins decode only the keys they understand).
type Receiver ¶
type Receiver struct {
Session *scheduler.Session
Applier Applier
// contains filtered or unexported fields
}
Receiver wires REST fetch + hash check + Applier dispatch into the plugin's WS command loop.
applyMu serialises Handle calls so two “config_updated“ events arriving in quick succession cannot have their applies interleave (older config finishing after newer would leave the plugin in a stale state). Apply itself can be long-running (file writes + service reload) and is per-Receiver, so a plain mutex is enough.
Source Files