fix(local): gate client-log scrape on the same SCCM-client check as WMI - #10
Open
chryzsh wants to merge 1 commit into
Open
fix(local): gate client-log scrape on the same SCCM-client check as WMI#10chryzsh wants to merge 1 commit into
chryzsh wants to merge 1 commit into
Conversation
local_client_logs_targets() only checked platform.system() == "Windows" before scraping CCM/ccmsetup logs, unlike the three WMI resources beside it which all gate on _wmi_ccm() (root\CCM namespace present). CMBP's original Invoke-LocalCollection returned at its own top when that namespace was absent, before ever reaching its log-scrape code -- a fidelity gap introduced when the port split one PS1 function into separate resource functions, not a deliberate divergence. Now gates on _wmi_ccm() too, so a box with leftover log folders from an uninstalled client is skipped before opening any log file. Ticket: con-8bed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
local_client_logs_targets()incollectors/local.pyonly checkedplatform.system() == "Windows"before scrapingCCM\Logs/ccmsetup\Logs. The three WMI resources beside it all gate on_wmi_ccm()(root\CCM namespace present, confirming this box is a currently-enrolled SCCM client). The log scrape never got that gate.CMBP's original
Invoke-LocalCollection(PowerShell) returns at its own top when the root\CCM namespace is absent, before ever reaching its log-scrape code later in the same function. Splitting that into separate resource functions during the port dropped the gate for the log scrape specifically. Not a deliberate divergence, a fidelity gap.Found against a real environment: a box with a large
DataTransferService.log(one line per content byte-range chunk) printed thousands of VERBOSE "Found URL" lines per second, and the scrape ran on any Windows box regardless of whether it was actually a current SCCM client.Fix
local_client_logs_targets()now gates on_wmi_ccm()too. A box with leftover log folders from an uninstalled client, or any non-client box, is skipped before opening a log file. A real, currently-enrolled client scrapes its logs the same as before.Type of Change
Testing
New regression test
test_log_scrape_skipped_when_not_an_sccm_clientintests/local_log_scrape_regex_test.py. Existing tests updated to mock_wmi_ccminstead ofplatform.system. Full suite passes.