Closed jelockwood closed 1 month ago
The inventory
module dynamically detects what the set ManagedInstallDir
is when it is installed on the client. By default this is /Library/Managed Installs/
, but an admin can specify something different in Munki's preference file at /Library/Preferences/ManagedInstalls.plist
or with a profile using the ManagedInstalls
domain.
Run sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
on a client and see what Munki is reporting the ManagedInstallDir
to be.
@tuxudo I get the following
sh-3.2# sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
ManagedInstallDir: '/Library/Managed Installs' [MANAGED]
What do you get when running sudo osascript -l JavaScript -e "ObjC.import('Foundation'); ObjC.unwrap($.NSUserDefaults.alloc.initWithSuiteName('ManagedInstalls').objectForKey('ManagedInstallDir'))"
on that client?
I get the following
sh-3.2# sudo osascript -l JavaScript -e "ObjC.import('Foundation'); ObjC.unwrap($.NSUserDefaults.alloc.initWithSuiteName('ManagedInstalls').objectForKey('ManagedInstallDir'))"
/Library/Managed Installs
The configuration looks to be correct for Munki and MunkiReport's install script is correctly detecting the proper Munki install directory. I am unable to reproduce this.
You can try reinstalling the MunkiReport client package to properly set the location of the ApplicationInventory.plist
file and verifying that you do not have any extra ManagedInstalls.plist
settings in /Library/Preferences/
and /var/root/Library/Preferences/
. Also review your profiles to be sure only one ManagedInstallDir
is specified
There was an extra ManagedInstalls.plist in /Library/Preferences but its contents did not have any incorrect locations defined so should have had no effect. I have deleted it although I think Munki may be guilty and may re-create it.
I checked /var/root/Library/Preferences there is no ManagedInstalls.plist there, I also checked the normal actual user location e.g. /Users/myname/Library/Preferences. I checked the contents of /Library/Managed Preferences/ManagedInstalls.plist and it is fine with one correct value, I use a Jamf profile pre-defined template for this profile and hence it is impossible to add duplicate fields.
I renamed /usr/local/munkireport and ran the installer again to create a fresh copy. and ran it. It still afterwards shows
munkireport_runner --show-config
shows the following entry inventory = "/Library/Preferences/Managed Installs/ApplicationInventory.plist";
Hmmm. Interestingly I have discovered the following. I did these steps in the listed order, immediately after each other.
sh-3.2# sudo rm /Library/Preferences/ManagedInstalls.plist
sh-3.2# defaults read /Library/Preferences/ManagedInstalls.plist
2024-09-12 18:11:54.627 defaults[35360:39129108]
Domain /Library/Preferences/ManagedInstalls.plist does not exist
sh-3.2# ./munkireport-runner --show-config | grep ApplicationInventory
inventory = "/Library/Preferences/Managed Installs/ApplicationInventory.plist";
sh-3.2# ./munkireport-runner -S
....lots of lines....
sh-3.2# ./munkireport-runner --show-config | grep ApplicationInventory
inventory = "/Library/Preferences/Managed Installs/ApplicationInventory.plist";
sh-3.2# ls -l /Library/Preferences/ManagedInstalls.plist
-rw-r--r-- 1 root wheel 264 12 Sep 18:13 /Library/Preferences/ManagedInstalls.plist
It had re-created the copy in /Library/Preferences
I did this more than once so unless MunkiReport triggers the execution of Munki, then something MunkiReport is doing is causing the creation of this copy. There was not enough time for a normal Munki execution to occur.
Here is a sanitised copy of my normal /Library/Managed Preferences/ManagedInstalls.plist
sh-3.2# defaults read /Library/Managed\ Preferences/ManagedInstalls.plist
{
AccessKey = "";
AdditionalHttpHeaders = (
"Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx="
);
AppleSoftwareUpdatesOnly = 0;
CatalogURL = "";
ClientCertificatePath = "";
ClientIdentifier = "";
ClientKeyPath = "";
ClientRepoCAPath = "";
ClientResourceURL = "";
ClientResourcesFilename = "";
DaysBetweenNotifications = 1;
FollowHTTPRedirects = none;
HelpURL = "";
IconURL = "";
IgnoreSystemProxies = 0;
InstallAppleSoftwareUpdates = 0;
InstallRequiresLogout = 0;
LicenseInfoURL = "";
LocalOnlyManifest = "";
LogFile = "/Library/Managed Installs/Logs/ManagedSoftwareUpdate.log";
LogToSyslog = 0;
LoggingLevel = 1;
MSUDebugLogEnabled = 0;
MSULogEnabled = 0;
ManagedInstallDir = "/Library/Managed Installs";
PackageURL = "";
PackageVerificationMode = none;
PerformAuthRestarts = 0;
RecoveryKeyFile = "";
Region = "";
SecretKey = "";
ShowOptionalInstallsForHigherOSVersions = 0;
ShowRemovalDetail = 0;
SoftwareRepoCACertificate = "";
SoftwareRepoURL = "https://munki.mydomain.com:8443";
SoftwareUpdateServerURL = "";
SupressAutoInstall = 0;
SupressLoginwindowInstall = 0;
SupressStopButtonOnInstall = 0;
SupressUserNotifcation = 0;
UnattendedAppleUpdates = 1;
UseClientCertificate = 0;
UseClientCertificateCNAsClientIdentifier = 0;
UseNotificationCenterDays = 3;
}
Run sudo rm /Library/Preferences/MunkiReport.plist
, then collect the output of sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
.
Reinstall MunkiReport and run sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
again.
What is the output of both of those?
@tuxudo (As an aside I fixed part of the problem I am having with your Jamf module and now have a new issue, the 500 error was my fault, I had the wrong version of curl-php installed, the second current error may be a genuine issue, I would be grateful for your feedback.)
I did your latest request and it has the following results.
sh-3.2# sudo rm /Library/Preferences/MunkiReport.plist
sh-3.2# sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
ManagedInstallDir: '/Library/Managed Installs' [MANAGED]
(install MunkiReport client again.)
sh-3.2# sudo managedsoftwareupdate --show-config | grep ManagedInstallDir
ManagedInstallDir: '/Library/Managed Installs' [MANAGED]
It should be noted that Munki aka managedsoftwareupdate has always shown the correct location. In case you got the second command wrong I also ran the following
sh-3.2# ./munkireport-runner --show-config | ApplicationInventory
It STILL results in listing /Library/Preferences/Managed Installs/ApplicationInventory.plist
After a great deal of pain since plutil does not update the plist cache and defaults write is terrible at modifying arrays, I was able to manually set /Library/Preferences/MunkiReport.plist
to the correct path for ApplicationInventory.plist this then resulted in data being successfully uploaded via ./munkireport-runner -U
running munkireport-runner as normal after left this setting correct for now.
However since I have repeatedly deleted the entire MunkiReport.plist and reinstalled, I am still concerned that installing additional clients will hit the same problem and this approach is not sustainable for that, also it might break the value at some point on my now currently working client.
A potential workaround but an extremely ugly one would be to create a symbolic link between the wrong file path and the correct file path for ApplicationInventory.plist
Possible red-herrings, the script for inventory is called inventory_add_plugins.py I believe this merely reflects a past improvement to also inventory plugins but could something have been broken? Also there is a script called managedinstalls.py which also looks at Munki activity, however I do not believe this is for the inventory.
@tuxudo I have been on holiday and now back and had a chance to use Pacifist to examine the client installer pkg generated by MunkiReport. It seems the problem with the preference file for the MunkiReport client having the wrong file path for the ApplicationInventory.plist is being caused by MunkiReport-PHP itself generating an installer with the wrong path.
The PostInstall script in the installer pkg contains the following line
/usr/bin/defaults write "${TARGET}"/Library/Preferences/MunkiReport ReportItems -dict-add inventory "/Library/Preferences/Managed Installs/ApplicationInventory.plist"
It should be
/usr/bin/defaults write "${TARGET}"/Library/Preferences/MunkiReport ReportItems -dict-add inventory "/Library/Managed Installs/ApplicationInventory.plist"
Therefore the issue appears to be a bug in MunkReport-PHP 5.8.0.4284 and not my client Mac or setup.
I have a suspicion this bug may have existed a while and therefore possibly also in 5.7.
Since the bug is I believe now shown to be in MunkiReport-PHP itself and not the Inventory module I am closing this issue and re-opening my original issue for MunkiReport-PHP itself.
I already have Munki deployed and working to all our Macs. I push out settings via a managed profile i.e. an MDM server.
The Munki working directory location is the usual
/Library/Managed Installs/
and in that directory isApplicationInventory.plist
Unfortunately MunkiReport seems to be confused and its setup shows it is looking in
/Library/Preferences/Managed Installs/
does not exist and hence it does not findApplicationInventory.plist
There is a
/Library/Preferences/ManagedInstalls.plist
but this is not the same thing.munkireport_runner --show-config
shows the following entryinventory = "/Library/Preferences/Managed Installs/ApplicationInventory.plist";
and the actual execution gives the corresponding error ofWARNING: Can't open /Library/Preferences/Managed Installs/ApplicationInventory.plist
As a result the Inventory choice in Listings is effectively empty as it only lists the computer, and App Versions Report shows no version information and clicking on an entry as per APPS_TO_TRACK in my .env goes to a table saying 'No data available in table', this includes the default Safari app.
I am using an Ubuntu 20 Server running Apache2 and PHP8 and MunkiReport-PHP 5.8.0.4284