Version 0.0.29.post5

Summary

This maintenance release makes Proxmox reads and writes endpoint-exact, lets non-superusers receive endpoint-scoped operational permissions, adds a capture-only operating mode, and correlates WebSocket completion with the backend run that produced it. It also hardens device ownership, remote NetBox connection approval, SSH credential handling, and the release pipeline.

The release pairs with proxbox-api 0.0.27.post3 and includes one database migration: 0106_device_sync_scope_and_netbox_token_approval.

Release identity

The package and plugin source both identify this maintenance release as 0.0.29.post5.

Endpoint-exact HA reads

The virtual machine HA tab and per-VM HA API now query only the Proxmox endpoint recorded by the VM's authoritative typed sync state. Linked cluster and node rows must agree with that endpoint, and the caller must be able to view both the NetBox VM and the enabled endpoint. Missing, conflicting, disabled, or hidden identity is refused before backend I/O.

GET /api/plugins/proxbox/ha/vm/{vmid}/ now requires virtual_machine_id={netbox_vm_pk}. The plugin verifies that the selected VM's synchronized Proxmox VM ID matches {vmid} before contacting the backend.

Grantable operational actions

Operational verbs, firewall actions, tags, template builds, packer builds, and instance creation now use the run_proxmox_action custom action on the exact owning ProxmoxEndpoint. The authorized NetBox endpoint is translated to proxbox-api's independent endpoint ID and remains bound to the dispatch. A disabled or conflicting endpoint is refused without backend resolution or network I/O, including firewall previews.

Create a NetBox ObjectPermission with these values:

• Object type: Proxbox > Proxmox endpoint.
• Actions: view when endpoint visibility is required, plus run_proxmox_action. Template-build REST actions also require add.
• Users or groups: the intended operators.
• Constraints: the permitted endpoint set, such as {"pk": 17} or {"name": "lab-pve"}.

Use separate constrained grants for different endpoint sets. An unconstrained grant covers every Proxmox endpoint. The literal core.run_proxmox_action permission remains an additive, deprecated compatibility path and should not be used for new grants. Unsafe requests authenticated by an API token additionally require write_enabled=True; session authentication is unchanged.

SSH credential handling

Creating a Proxmox endpoint with reuse endpoint username/password now recognizes the submitted password during model validation without storing it early. This also fixes adding a password to a token-only endpoint and creating an endpoint with service monitoring enabled. API and serializer paths still reject reuse when neither a stored nor pending password exists.

An SSH terminal request for a disabled endpoint now returns HTTP 409 before credential access, provider reads, writes, or backend I/O. This applies to endpoint and node targets and to stored, one-shot, and newly stored credentials. The credential, save, readiness, and terminal paths were split into small typed helpers so each modified function remains within the repository's complexity limit.

Capture-only NetBox instances

Set PLUGINS_CONFIG["netbox_proxbox"]["automatic_background_tasks"] to the boolean False to retain Proxbox inventory models, APIs, explicit sync jobs, integrity handlers, and audit records while suppressing startup discovery and stock one-minute service-monitor registration. An existing stock unowned, unscoped monitor drains without polling or re-enqueueing. User-created, custom, or scoped jobs are preserved. Restart every application and worker process after changing this setting.

Run-correlated WebSocket completion

When the connected backend advertises ws_run_id: 1, each sync command carries a run identifier and only a matching aggregate terminal may complete it. Failed aggregate status reaches the browser as an error, while malformed, foreign, and late frames cannot release another run. Endpoint trust is revalidated before every transmission and retry.

The plugin and proxbox-api 0.0.27.post3 may be upgraded in either order. A backend without the capability continues to receive legacy bare commands. In a mixed-version rolling deployment, one attributable rejected envelope is retried once in legacy form and later commands on that connection remain legacy.

Device ownership and connection approval

Migration 0106_device_sync_scope_and_netbox_token_approval adds nullable proxmox_endpoint_raw_id to device sync state. Existing rows remain null and unclaimed because historical identifiers cannot prove present endpoint ownership. Consumers must corroborate cluster, site, and placement before adopting a legacy candidate. Claims lock the sidecar row atomically: a null or same-ID claim succeeds, while changing a committed owner returns HTTP 409 with endpoint_ownership_conflict.

Remote NetBox connection approval now binds the effective token version and the non-secret token reference or key selected for transmission. Token changes therefore require explicit reapproval. The migration clears existing NetBox endpoint approvals once without approving any target; Proxmox endpoint approvals are unchanged. Review and approve each affected NetBox endpoint through its connection-authority panel after migration.

Release pipeline

The public mirror now carries only the authoritative main branch, and the mocked CI job installs the CLI extra required by its tests. OCI release validation requires both package indexes to expose a usable source archive or compatible pure-Python wheel, resolves the backend version from the unique release row in COMPATIBILITY.md, smoke-tests the amd64 manifest from the final multi-architecture index, and publishes that same tested digest without a rebuild.

OpenBao storage guards

Switching the credential storage backend, changing an endpoint storage override, or deleting an owner now locks the settings state first and validates the final state on the write database, so primary/replica routing is respected. A blank endpoint override is resolved against the locked global selection. Both the default and base managers are guarded, including bulk updates and conflict upserts. Deleting an owner is refused while provider assignments remain, even without an owned material reference; a legacy endpoint holding only assignment relations is cleaned up inside the surrounding transaction after every assignment deletion is authorized. No migration is involved.

Upgrade notes

1. Upgrade the separately deployed backend to proxbox-api 0.0.27.post3 and install netbox-proxbox 0.0.29.post5. Either service may be upgraded first.
2. Run python manage.py migrate netbox_proxbox; this applies only 0106_device_sync_scope_and_netbox_token_approval for this release.
3. Run python manage.py collectstatic --no-input and restart every NetBox application and worker process.
4. Review and explicitly reapprove every remote NetBox endpoint whose approval was cleared. Do not infer approval from backend health.
5. Create or review endpoint-constrained run_proxmox_action ObjectPermissions for non-superuser operators, and enable write_enabled only on API tokens that are authorized for unsafe actions.
6. Verify one endpoint-scoped HA read, one permitted operational action, and one full synchronization before returning the installation to service.

Compatibility baseline

Current backend-runtime pairing: netbox-proxbox 0.0.29.post5 <-> proxbox-api 0.0.27.post3 <-> proxmox-sdk 0.0.15 <-> netbox-sdk 0.0.13. This netbox-sdk version is proxbox-api's REST dependency only and does not provide the semantic MCP bridge.

NetBox	netbox-proxbox	proxbox-api	netbox-sdk	proxmox-sdk
4.5.8-4.7.0 GA	v0.0.29.post5	v0.0.27.post3	v0.0.13	v0.0.15

The plugin declares NetBox 4.5.8 through 4.7.99; continuous integration verifies the listed GA range through NetBox 4.7.0.

Known limitations

• Legacy device sync-state rows remain deliberately unclaimed until the paired backend corroborates and stamps their endpoint identity.
• Backends without run-correlation capability retain legacy virtual-machine terminal completion and the 600-second idle latch.
• Changing automatic_background_tasks requires a restart of all application and worker processes; it does not cancel explicit or user-owned jobs.
• The OCI appliance remains a testing topology, not a production deployment.