Special satellites rejected with DUPLICATE_UNAME since v1.31.1 — uname uniqueness check has no special-satellite exemption

[mateo-moon]

Summary

Since v1.31.1, only the first special satellite (e.g. EBS_TARGET) can connect to the controller. Every further special satellite is de-authenticated with connection status DUPLICATE_UNAME:

Satellite has an uname 'linstor-controller-xxxxxxxxxx-yyyyy' that is already used by a different satellite 'EBS-TARGET-EU-CENTRAL-1A'

This makes the documented multi-AZ native-EBS setup (one EBS target per availability zone, per the LINBIT EBS blog post) impossible to bootstrap on ≥1.31.1. Works fine on ≤1.30.4.

Root cause

Two interacting pieces:

1. Satellites always report the process hostname as uname. satellite/src/main/java/com/linbit/linstor/api/protobuf/CtrlAuth.java:

// get the host uname for the drbd config
String nodeUname = LinStor.getHostName();

The --override-node-name value is transmitted in the same auth response but as a separate field — it is not used as the uname. Special satellites spawned by the controller run inside the controller process's UTS context, so all of them report the controller's hostname.

2. v1.31.1 added one-node-per-uname enforcement at auth time. Commit 37fb41cb94 introduced updateUnameMap() in controller/.../internal/CtrlAuthResponseApiCallHandler.java:

if (curNodeName != null)
{
    peer.setAuthenticated(false);
    peer.setConnectionStatus(ApiConsts.ConnectionStatus.DUPLICATE_UNAME);
    ...
}

There is no exemption for special-satellite node types, and no property/config to relax the check. Notably, the commit's changelog entry describes only a display improvement (mapping DRBD peer names to node names for replication-state reporting) — the auth-time rejection appears to be an unintended side effect; it isn't mentioned anywhere in the 1.31.x release notes.

Reproduction

On linstor-server ≥1.31.1:

linstor remote create ebs ebs-rem-a eu-central-1a $KEY $SECRET
linstor remote create ebs ebs-rem-b eu-central-1b $KEY $SECRET
linstor node create-ebs-target ebs-target-a ebs-rem-a   # Online
linstor node create-ebs-target ebs-target-b ebs-rem-b   # DUPLICATE_UNAME

Workaround (validated live)

Pin the controller's hostname to a stable value and pre-seed each special-satellite node's persisted NodeUname property to that same value (in our k8s-CRD-backed DB: PropsContainers rows with prop_key: NodeUname, props_instance: /NODES/<NODE>), then restart the controller. With reported uname == persisted NodeUname, updateUnameMap() takes the reconnect path and all targets come Online. This works but is clearly DB surgery, not a supported interface.

Suggested fix

Exempt special-satellite node types from the uname-uniqueness check in updateUnameMap() (they intentionally share the controller's process/UTS context, and the uname map's purpose — mapping DRBD peer unames to node names — doesn't apply to them: special satellites never participate in DRBD). Alternative: have special satellites report their --override-node-name as uname.

I'm happy to open a PR for the exemption approach if that direction is acceptable.

Environment

Observed on linstor-server 1.31.1 → 1.34.1 (verified live on 1.33.3 and 1.34.1; confirmed absent on 1.30.4), Kubernetes / piraeus-operator v2.10.7, arm64 — though the mechanism is platform-independent.

Related

Part of a set of four native-EBS issues: #505 (DUPLICATE_UNAME), #506 (no resource dispatch to EBS targets), #507 (snapshot rate-limit storm), #508 (/dev/sdz attach collision).