Basic hard-coded alarm system

[troglobit]

Errors encountered at startup, or validating system, should trigger alarms. For example:

• Broken VPD
• Missing secondary bootloader
• Broken primary bootloader
• Broken Linux partition
• Broken startup-config
• Broken failure-config

When encountered at boot (or during background checksumming after boot) these errors could simply be written to a structure in /run/system/alarm/, and if this (and subdirectories) are non-empty we trigger a summary alarm that in turn can trigger a LED indication.

/run/
  `- system/
      `- alarm/
          |- hw/
          |   `- broken-vpd.log
          |- bootloader/
          |   `- broken-primary.log
          |- infix/
          `- misc/

The contents are logged, at the time of detection, and also saved here for later replication and debugging.

[troglobit]

RFC-Based Alarm & Event System — Tasks

Base YANG Model

• Adopt RFC 8632 as core schema for alarm state, severity, and lifecycle.
• Plan extension hooks for Infix-specific alarms (temp, disk, memory, security).

Define Alarm Types & Thresholds

• Too high temperature (hw sensors)
• Disk space (almost full)
• Memory usage
• Security/penetration attempts (auditd)
• Firmware update availability, see also Add support for unattended upgrades #1301

Each alarm type needs: severity levels, threshold/clear conditions, optional shelving/acknowledgement.

Notifications & Event Streams

• NETCONF/RESTCONF notifications for alarm raise/clear/change per RFC 8632.
• Retention policy for notification history.

Alarm Engine

User-space daemon that watches thresholds/events, updates alarm operational state, and emits notifications.

OS Data Source Integration

• auditd: security events (unauthorized access attempts)
• sensors: hardware sensors (temp, fan, voltage) mapped to alarm thresholds
• Optionally correlate with existing syslog YANG logs

Syslog Integration

• Mirror critical alarms into syslog as structured entries via existing ietf-syslog.yang.

Operational Data & CLI

• Expose alarm state (list, severity, history) via NETCONF/RESTCONF and CLI.

Tests

• YANG module validation
• Functional tests for threshold crossing, notification delivery, alarm clearing
• Integration tests with sensors and auditd

Architecture (concept)

OS Sources
 ├── auditd ──► alarm engine (security events)
 ├── sensors ─► alarm engine (temp, fan, volt)
 └── update service ─► alarm engine (firmware)

alarm engine
 ├── updates RFC 8632 alarm operational state
 ├── sends NETCONF/RESTCONF notifications
 └── logs to ietf-syslog

Clients subscribe for events and read state.
"Critical" may also feed local indicators (LED/console).