On Jetson (Tegra) the integrated GPU is enumerated by NVML
(nvidia-l4t-nvml) and reports its name (e.g. "Orin (nvgpu)"), but the
per-metric NVML queries return NVML_ERROR_NOT_SUPPORTED, so the GPU
plugin only ever showed N/A for proc/mem/temperature.
Add a Tegra sysfs backend (glances/plugins/gpu/cards/tegra.py) and wire
it into the NVIDIA card as a per-metric fallback: when NVML returns None
for a device detected as Tegra (name contains "nvgpu", or the Tegra GPU
sysfs node exists), read:
- proc: /sys/devices/platform/gpu.0/load (per-mille -> percent)
- temperature: the gpu-thermal /sys/class/thermal zone (milli-C -> C)
Memory stays N/A by design: the Tegra GPU shares system RAM, already
reported by the MEM plugin. Scales verified against tegrastats
(GR3D_FREQ and gpu@).
Adds unit tests with committed sysfs fixtures, a NEWS.rst entry and a
docs note.
Verified on JetPack 6.2.1 (L4T R36.4.7) and JetPack 7.2 (L4T R39.2):
identical sysfs node layout and gpu-thermal zone selection on both, with
temperature cross-checked against tegrastats on each.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cover the non-RCE behaviour of the new JSON cache:
- round-trip: written file is valid JSON, re-read produces equivalent dict
- legacy pickle: a pre-fix pickle cache is treated as a cache miss, not
a crash (upgrade path)
- expiry: caches older than 7 days are invalidated
- version skew: caches written by a different installed version are
invalidated
- first run: a missing file is not an error
Regression test for GHSA-9837-48hr-q32j: glances/outdated.py reads its
version-check cache file via pickle.load(), a deserialization format
that executes arbitrary callables embedded via __reduce__.
The test plants a poisoned pickle at the cache path and asserts that
_load_cache() does NOT trigger the embedded callable. Against the
current (vulnerable) code this fails because the payload fires before
the TypeError is raised on the unrelated dict subscript.
The fix in the next commit replaces pickle with json, which is a passive
data format.
Adds a second test server bound to a config that enables xmlrpc_allowed_hosts,
plus the failing assertion that a spoofed Host header returns 400. The fix in
glances/server.py follows in the next commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This test passes on the unpatched server and proves the CVE-2026-46611
vulnerability exists today: a spoofed Host header is accepted.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Re-creates tests/test_xmlrpc.py (deleted symlink) with a pytest module
modelled on test_restful.py: subprocess-launched server and a helper
to POST XML-RPC calls with a controllable Host header. Restores the
existing 'make test-xmlrpc' Makefile target.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Occasionally, columns got misaligned, because auto_unit returned too
many decimals when the number was slightly below 10 or 100.
Actually, when (9.995 <= n < 10) and (99.95 < n < 100).
For example,
10*2**20-1 returned 10.00M instead of 10.0M and
100*2**20-1 returned 100.0M instead of 100M.
Tests added to verify correctness.
connect() unconditionally stored server_name as local_node, and
update() filtered instances whose location did not match. On a
standalone LXD host, instance.location is empty, so every container
was dropped and the user saw no LXD stats at all.
Gate the filter on environment.server_clustered — only apply the
cluster-member filter when the daemon reports itself as clustered.
Also promote the connect() failure log from debug to error so that
future connectivity issues are visible in the default log.
- Add [mpp] section to conf/glances.conf with disable=True
- Add docs/aoa/mpp.rst documentation page and index entry
- Add unit test test_026_mpp with Rockchip MPP test fixtures
Introduce a generic Min/Max/Mean (mmm) mechanism at the plugin model level.
When a field in `fields_description` defines `'mmm': True`, the plugin
automatically generates and maintains the following derived fields:
<field>_min
<field>_max
<field>_mean
The computation is handled in the base plugin model to ensure the
feature is reusable across all plugins. Mean is calculated as a
running mean, and min/max are updated on each refresh cycle.
This implementation:
- Keeps the feature opt-in per field
- Avoids hardcoding logic in individual plugins
- Maintains full backward compatibility
- Preserves existing API v4 response structure
- Ensures no regression in existing behavior
Unit tests have been added to validate correct field generation
and update behavior.
