`get_packages` named the Debian source package and never its version, so a
consumer was handed two numbers on different axes and no way to tell.
OSV states Debian ranges in *source* versions. libldb2 is
2:2.11.0+samba4.22.11+dfsg-… while its source, samba, is 2:4.22.11+dfsg-…;
comparing the first against a samba range is meaningless, and dpkg reads
ldb's 2.11.0 as older than the 2:4.17.4+dfsg-1 that fixed CVE-2022-44640.
Reporting the source without its version is worse than reporting neither,
because it looks usable.
Measured on three live Proxmox nodes: every one of their 2 349 packages
was in that state — 802 of 802, 774 of 774, 773 of 773 — while twenty
non-Proxmox hosts had both fields. It was not a parsing bug. The
dpkg-query format string never asked for ${source:Version}, so nothing
downstream could have recovered it.
Now asked for and reported, with the same fallback napalm-linux uses:
dpkg leaves the field empty when it equals Version, and an older dpkg
leaves it empty because it does not know the field at all. Neither may
produce a package without a coordinate.
tests/test_packages.py covers all of it, including that the *query* names
the field — the assertion that would have caught this.
dpkg-query now also reports ${source:Package} as source_package, so consumers
can match installed binaries to the correct Debian source (e.g. openssh-server
-> openssh) for accurate OSV vulnerability lookups.
get_device_warnings() now returns only {code, meta} — severity, title,
message, and action are resolved centrally by netork's
WARNING_CATALOG (netork/core/device_warnings.py), not by the driver.
Keeps this driver independent of netork and avoids per-vendor drift in
how the same warning code is presented.
Implements get_system_config() in ProxmoxSystemMixin:
- cluster_name from /cluster/status (type=cluster entry)
- cluster_nodes list of online node hostnames
- timezone from /nodes/{node}/time
- hostname, ssh_port, ssh_password_auth with safe defaults
Used by NetOrk's sync task to name the NetBox Cluster after the
actual Proxmox cluster rather than falling back to the site name.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
After renaming /etc/hostname, Proxmox boots under the new node name and
looks for VM/CT configs in /etc/pve/nodes/<new>/qemu-server/. Without
migrating the directory first, all VMs appear missing after the reboot.
Now renames /etc/pve/nodes/<old>/ to /etc/pve/nodes/<new>/ while
pve-cluster is running (pmxcfs supports live rename). Also replaces
pvecm updatecerts -f with pvenode cert create --overwrite — pvecm
updatecerts restarts pve-cluster, unmounts /etc/pve and can crash VMs.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
netOrk's generic reboot helper (_do_reboot) calls conn._send_command()
which did not exist on ProxmoxDriver — the resulting AttributeError was
silently swallowed, so reboot commands never executed on Proxmox nodes.
Delegates to the existing _exec_ssh_command so all generic SSH-based
actions (reboot, dns_port check, etc.) work correctly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implements set_hostname on ProxmoxSystemMixin:
1. Writes /etc/hostname (short name, base64-safe transfer)
2. Replaces old hostname in /etc/hosts via Python regex + base64
3. Updates /etc/mailname if present
4. Updates Postfix myhostname via postconf -e if installed
5. Applies hostname immediately at runtime via hostname(1)
6. Regenerates Proxmox node TLS certificate via pvecm updatecerts -f
(falls back to pvenode cert create → pveproxy restart)
Accepts bare hostname or FQDN. A reboot is required for the Proxmox
node name to update in the web UI / cluster — the driver logs this.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>