diff --git a/docs/AlarmProbeFindings.md b/docs/AlarmProbeFindings.md index 91afcb9..f062ba6 100644 --- a/docs/AlarmProbeFindings.md +++ b/docs/AlarmProbeFindings.md @@ -24,13 +24,13 @@ the blocker rather than rediscovering it. |---|---| | GUID stable across polls and `ALM → RTN` | Answered — yes (2026-05-01 capture in `AlarmClientDiscovery.md`, reconfirmed 2026-08-18) | | GUID stable across clear-then-re-raise | Answered 2026-08-18 — **no**, a re-raise mints a new GUID | -| GUID stable across `UNACK → ACK` | **Open** — the rig cannot be driven into an acknowledged state at all | +| GUID stable across `UNACK → ACK` | **Open** — the rig cannot be driven into an acknowledged state; 2026-08-18 (third attempt) identifies the reason as the test attribute's `MxSecurityOperate` classification, which no non-interactive ack surface on the rig can satisfy | | `COUNT` = total active vs records-in-reply under a capped fetch | Answered 2026-08-18 — **records in the reply** | The 2026-08-17 run below is kept because it is the record of the wrong-verb blocker. The 2026-08-18 run cleared that blocker with `AuthenticateUser` + `WriteSecured` and answered two of the three questions; the acknowledge leg is now blocked on something narrower and -different, described in "Second attempt". +different, described in "Second attempt" and diagnosed in "Third attempt". ## First attempt (2026-08-17): plain `Write` @@ -264,8 +264,147 @@ MXAccess-side entry point and the wnwrap-side entry point is inert. spurious Clear plus a spurious Raise, which is the same shape the now-observed re-raise behaviour produces and which `ComputeTransitions` already handles as two instances. +## Third attempt (2026-08-18): why the acknowledge is refused + +The second attempt left two candidate explanations for `AlarmAckByName` returning `rc=0` +and changing nothing: the rig enforces an acknowledgement security requirement the wnwrap +consumer cannot meet, or wnwrap's ack is simply broken here. This attempt was read-only — +no writes, no alarms raised, no configuration touched — and settles the first question: +the requirement is **enforced**, and the alarm attribute's security classification is what +enforces it. + +### Method + +Read-only inspection of the `ZB` Galaxy Repository over `sqlcmd -S localhost -d ZB -E`, +plus the already-built `mxa` CLI (`C:\Users\dohertj2\Desktop\wwtools\mxaccesscli\src\MxAccess.Cli\bin\x86\Release\net48\mxa.exe`) +for runtime reads. Nothing was written and nothing was installed. The `lmxopcua\gr` schema +notes referenced elsewhere in this repo are **not present on this box** (`Test-Path` is +`False`), so the schema was located by querying `sys.tables` / `sys.columns` directly. + +### The test attribute is classified `MxSecurityOperate` + +UDA security classification lives in `dynamic_attribute.security_classification`, keyed by +`gobject_id` — for the `$TestMachine` template that is `1055`: + +``` +attribute_name | security_classification | mx_attribute_category +ProtectedValue | 2 | 10 +ProtectedValue1 | 3 | 10 +TestAlarm001 | 1 | 10 +TestAlarm002 | 1 | 10 +TestAlarm003 | 1 | 10 +TestChangingInt | 1 | 10 +``` + +The enum is pinned by two independent sources rather than assumed. `ProtectedValue` and +`ProtectedValue1` are the mxaccess analysis project's documented *secured-write* and +*verified-write* fixtures (`C:\Users\dohertj2\Desktop\mxaccess\docs\galaxy-test-fixtures.md`), +and `docs/NMX-COM-Contracts.md` in the same project records "Galaxy security classification +(`2` for `SecuredWrite`, `3` for VerifiedWrite)" — so `2` and `3` land on exactly the two +attributes that are supposed to carry them. `galaxy-test-fixtures.md` also records the +provisioning verb used for every UDA in that inventory: `--security MxSecurityOperate`. +`TestAlarm001` therefore reads `1` = **`MxSecurityOperate`**. + +That is the missing piece from 2026-08-17. `Operate` is not free access: it requires an +authenticated galaxy identity holding Operate permission on the object's security group. +An unauthenticated `Write` is refused with `SecurityError` `1008`, and the same write after +`AuthenticateUser` succeeds — which is precisely the pair of results both prior attempts +recorded. Galaxy security is live on this rig, not disabled. + +`wwAlarmConsumerClass.AlarmAckByName` carries an operator *name* string and a comment. It +carries no authenticated user id, no credential, and no token — there is no parameter on +either the 6-arg or the 8-arg overload that could convey one. A consumer calling it cannot +satisfy an `Operate` classification, and `rc=0` followed by no state change is what an ack +dropped downstream of an accepted call looks like. + +The one step this stops short of is a direct experiment: the rig's security configuration +is out of scope for a read-only probe, so "an `Operate` alarm cannot be acknowledged +without an authenticated identity" is inferred from the classification plus the observed +`1008`/`rc=0` pattern rather than observed by relaxing the classification and watching the +ack start working. The human step below is exactly that experiment. + +### There is no writeable `.Ack` attribute — the second attempt targeted the only one there is + +A plausible reading of the second attempt was that it wrote the wrong sub-attribute: +ArchestrA alarm extensions are commonly described as exposing a writeable `.Ack` alongside +the read-only `.Acked`. On this galaxy they do not. Every `Ack`-named attribute the alarm +primitives define: + +``` +attribute_name | security_classification | mx_attribute_category +Acked | -1 | 2 +AckMsg | 0 | 6 +Bad.Acked | -1 | 2 +Bad.AckMsg | 0 | 6 +TimeAlarmAcked | -1 | 2 +AlarmAckCnt | -1 | 2 +AlarmAckErrorsCnt | -1 | 2 +AlarmMostUrgentAcked | -1 | 2 +AlarmUnAckedCnt | -1 | 2 +``` + +No `Ack`. `Acked` carries `security_classification = -1` — no classification at all, which +is what a non-writeable attribute carries, as distinct from the `1` on the writeable +`TestAlarm001`. That is the configuration-side counterpart of the `detail=1007` +operational refusal the second attempt got when it wrote `.Acked`: not a permission +refusal, but an attribute that has no write path to refuse. The second attempt had already +found the only MXAccess-side candidate, and it is read-only by definition. + +### No non-interactive acknowledge surface is installed + +The `wwtools` collection on the box (`aalogcli`, `aot`, `graccesscli`, `grdb`, `histdb`, +`mbproxy`, `mxaccesscli`, `secrets`) is the most likely home for a scriptable ack. There +isn't one. `mxa --help` lists `diag`, `info`, `read`, `read-batch`, `subscribe`, +`subscribe-batch`, `write`, `write-batch` — a tag data-plane only, with no alarm surface. +`graccesscli` is a Galaxy Repository configuration tool (`object uda add`, `instance +deploy`), which acts at configure/deploy time and not on live alarm state. Reading the +galaxy's own authentication mode at runtime is also unavailable: `Galaxy.AuthenticationMode` +does not resolve over MXAccess (`Category=4 Detail=6`), and the value is not in +`dynamic_attribute` — only the attribute *definition* names `AuthenticationMode` and +`_AuthenticationModeEnum` exist in `attribute_definition`. + +So every remaining acknowledge surface on this rig is interactive: the IDE's alarm client, +InTouch, or an ArchestrA graphic bound to the alarm. Driving those is out of scope. + +### Status of the acknowledge leg + +**Unavailable by configuration, and the GUID question stays assumed.** The two are separate +statements and both matter: + +- The wnwrap ack path is unavailable on this rig as configured, for an identified reason + rather than an unknown one. This is a real finding for the gateway: `AcknowledgeByName` + will behave the same way — accepted, inert — on any customer galaxy whose alarmed + attributes carry a non-free-access security classification. It is worth noting in the + alarm client's documentation that a silent `rc=0` is not proof of acknowledgement. +- Whether wnwrap re-mints the record GUID on `UNACK_ALM → ACK_ALM` is still unobserved, and + after three attempts it stays assumed. As the second attempt already noted, this remains + a documentation gap rather than a correctness one: a re-minted GUID produces a spurious + Clear plus a spurious Raise, the same shape the observed re-raise behaviour produces, and + `ComputeTransitions` already handles that correctly as two instances. + +#### What a human would need to do + +Either of these answers it; the second is cheaper and also confirms or refutes the +classification hypothesis above, which the read-only probe could only infer. + +1. Acknowledge `TestMachine_001.TestAlarm001` from an interactive System Platform client + (IDE alarm client, InTouch, or an ArchestrA graphic) while a wnwrap probe polls + `GetXmlCurrentAlarms2` against `\\DESKTOP-6JL3KKO\Galaxy!TestArea`, and record whether + `STATE` reaches `ACK_ALM` and whether `GUID` survives the transition. Raise the alarm + first with `AuthenticateUser` + `WriteSecured` as the second attempt did. +2. Reclassify `TestAlarm001` on the `$TestMachine` template to free access and redeploy — + `graccesscli object uda ... --security MxSecurityFreeAccess` against `$TestMachine`, + then `instance deploy TestMachine_001` — and re-run the second attempt's ack probe + unchanged. If `AlarmAckByName` then moves `STATE` to `ACK_ALM`, the classification is + confirmed as the blocker and the GUID question is answered in the same run. Restore the + classification to `MxSecurityOperate` afterwards, since the secured-write fixtures in + `WorkerLiveMxAccessSmokeTests` depend on the alarm UDAs being secured. + ### Rig state left behind +The third attempt changed nothing. `TestMachine_001.TestAlarm001` and its `.Acked` subtag +both read `false` at the end of the session, matching the state the second attempt left. + The three `TestMachine_00{1,2,3}.TestAlarm001` UDAs are back to `false` and their `.InAlarm` subtags read `false`, but each leaves a `UNACK_RTN` record in the wnwrap snapshot, since nothing can acknowledge them away. `SnapshotActiveAlarms` counts only