Fix module test failure on Debian 12 #818
Conversation
…installation On a freshly configured system (VM/container/server) the apt cache may not be populated. This causes any remediation task that requires package installation to happen to fail. Ensure we update the package cache on the first invocation of a function that attempts to install a package.
Happy to split the PR and or delay this (since it only affects remediation), but combined here for narrowing down moduletest failures. |
| OsConfigLogError(log, "AptGetUpdateOnce: apt-get update failed with %d", status); | ||
| } | ||
|
|
||
| g_aptGetUpdateExecuted = true; |
There was a problem hiding this comment.
Should we set to true even though it fails on L198 so it can try again on a subsequent run?
| OsConfigLogError(log, "AptGetUpdateOnce: apt-get update failed with %d", status); | ||
| } | ||
|
|
||
| g_aptGetUpdateExecuted = true; |
| } | ||
|
|
||
| status = ExecuteCommand(NULL, command, false, false, 0, 0, NULL, NULL, log); | ||
| if (0 == status) |
There was a problem hiding this comment.
nit: combine in one line to match existing code?
Like this:
if (0 == (status = ExecuteCommand(NULL, command, false, false, 0, 0, NULL, NULL, log)))
|
Yes, second that, this is an awesome find. Also same question (do we need to retry if the command fails?) In reply to: 2452224606 |
|
No need to split in my opinion. If you can add the fix for the ModuleTest (the SecurityBaseline module test recipe) in this PR, it would be great. Make sure that you will fix the ordering there of the MIM objects under test to match the policy MOF for all sequences, Get/Audit, Init, and Set/Remediate. The test recipe is at https://github.com/Azure/azure-osconfig/blob/main/src/modules/test/recipes/SecurityBaselineTests.json. Please validate this locally before submitting to PR, with: In reply to: 2491873158 |
|
Another thing to consider, we cannot rely on the exact order in which the MC calls will arrive. So we may need also a change in Asb.c where in case one check is executed before the other, the necessary update to happen (with a new global there like here). In reply to: 2492095717 |
Description
Two issues:
apt-cache
On a freshly configured system (VM/container/server) the apt cache may not be populated initially. This causes any remediation task that requires package installation to happen to fail. Ensure we update the package cache on the first invocation of a function that attempts to install a package.
With this change
apt-get updateis done once and only on demand. Some remediation functions need to be revised to better interact with this, for exampleRemediateEnsureAuditdServiceIsRunning.RemediateEnsureAuditdServiceIsRunningattempts to install 4 different package candidates, some of which may not be available in a distro version at all. Each such probe could trigger anapt-get update, even if a later package in the list is already installed. This scenario is not critical because:Test()call that would never invokeapt-get upateand that would suppress the call toSet()apt-get updateper lifetime ofosconfig-platformdaemon which is acceptable.cronie
The order of remediate tasks differs between moduletest and MC policy. The remediation tasks that modify permissions of cron files in
/etc/do nothing until these files are created by installing crond. Subsequent audit tasks related to these cron files can fail. Move theremediateEnsureCronServiceIsEnabledtask in moduletest earlier, so that the files are created before the permission remediation tasks run.Checklist
mainbranch prior to this PR submission.mainbranch.