I would like to announce the first public beta of AAMM-NG, the AREDN Alert Message Manager NG.

AAMM-NG grew out of my use of AREDN Alert Messages and the original AAMM project from Gerard Hickey, WT0F. Gerard's project established a very useful idea: managing all-node, group, and node-specific AREDN alerts through a web interface instead of logging into a node and manually editing files.

I wanted to take that concept further and build something designed around the current AREDN environment, with a stronger focus on safe operation, maintainability, security, and future development.

The result is AAMM-NG.

AAMM-NG is an independent, from-scratch implementation. It preserves the standard AREDN Alert Message conventions, but the application itself is new: new code, new web interface, new management API, new security model, and a new build and packaging system.

The current release is v0.1.2-beta, built and release-tested against AREDN 4.26.7.0.

AAMM-NG runs directly on an AREDN node. It does not require a separate server or cloud service.

It currently supports:

• All-node alerts
• Group/channel alerts
• Node-specific alerts
• Discovery of AREDN nodes on the local mesh
• Manual target entry when needed
• Creating and editing alerts
• Safe conversion of existing AAM files
• Backups before conversion or deletion
• Protection against unsafe or oversized alert operations
• Authenticated audit information for management changes
• Native integration with the AREDN administrator interface

One design goal has been to make AAMM-NG useful without making it dangerous.

For example, if AAMM-NG finds an existing alert file that it did not create, it does not silently rewrite it. It identifies the file as existing and requires an operator to explicitly convert it before editing. Destructive operations create backups, and operations that cannot be performed safely are refused rather than guessed at.

Administration is also tied to the authenticated AREDN administrator session. The management backend stays on the node's loopback interface instead of exposing another management service across the mesh.

This is still beta software, and I am calling it beta for a reason. I have put a lot of effort into automated testing, release reproducibility, architecture-specific builds, failure handling, and testing on real AREDN hardware, but I expect the wider AREDN community will find use cases that I have not.

Before installing the beta, I recommend making a normal backup of your AREDN node configuration.

Packages are currently available for the five AREDN package architectures I am targeting:

• mips_24kc
• arm_cortex-a7_neon-vfpv4
• mipsel_24kc
• aarch64_cortex-a53
• x86_64

The project, documentation, downloads, source code, and issue tracker are on GitHub:

github.com/k2exe/aamm-ng

If you try it, I would particularly appreciate feedback about installation on different hardware, node discovery on larger meshes, group alert workflows, usability, and anything that behaves differently than you expect.

If you find a bug, please open an issue. Please include the AAMM-NG version, AREDN version, hardware model/target, and enough information to reproduce the problem. As always, do not include passwords, session cookies, private keys, or other credentials in an issue.

I also welcome ideas for where this should go next. There are some interesting possibilities for automated and locally generated alerts, weather and SKYWARN use, emergency communications, and better management of alerts across larger meshes, but I want to get the fundamentals right first.

And finally, credit where it is due: AAMM-NG would not exist without the original AAMM project and the work Gerard, WT0F, did to demonstrate how useful a management interface for AREDN Alert Messages could be. AAMM-NG is not a fork or continuation of that codebase, but it absolutely builds on the idea and prior art that project introduced to the AREDN community.

Give it a try and let me know what you find.

73,

Mark, K2EXE