MunkiReport on High Sierra is unable to poll location from pinpoint successfully #31
Comments
|
Please take a look at PR #32 I added an option to allow for fallback if the other location service doesn't work. Maybe if you registered for an API key with Google (as described in the docs) and write the fallback option to the plist on some of your machines it will help out. Otherwise, is this just on one machine or is it on multiple? Also, are they all located in the same area having the same issue or are they located in different areas? I have an issue at the organization I work at where some of our machines on one part of our campus cant report because of some weird SSID's that are messing with the script. The fallback option fixed our specific issue though. |
|
I'll give the fallback option a shot. The logs above are all from the same machine before and after the upgrade to High Sierra (it's my iMac and it definitely hasn't moved) - I've observed the issue in several machines now - the only commonality is that they're running High Sierra - some are in Canada, some are in Australia. So far none of our High Sierra machines (~5 out of our fleet of ~80) are able to do the lookup when MunkiReport is calling for it. Hopefully the Google lookup will make the difference! Will report back as soon as I can test. |
|
Did that happen to work for you? Or are you still having an issue? |
|
I was able to give it a shot today with your PR. I added my google api key and enabled fallback in the plist, but no luck. It seems that the problem is coming earlier in the process than the actual address lookup - it appears to be during the interface with location services on the mac... Again, it works fine if I run the process from the terminal manually - this only seems to be a problem with the background process. |
|
So after some fresh eyes on this issue this looks like an issue with the wireless interface. Can you try leaving the wireless interface on for a few days and see if that changes the results? It is still strange that this works via the cli call but not via the launch daemon. |
|
Turned on the wireless this morning to start testing this and so far no change (4 hours later, so it's tried doing a location lookup several times now): |
|
I have been able to replicate this but I'm no closer to resolving the issue. It looks as if High Sierra is now limiting location services so they can't be ran as root via a LaunchDaemon. I've played around with the idea of moving this specific task to run under the console user but that isn't a simple refactor. I'm not sure when I'll have more time to look into this issue. In the meantime I'll cut a release this week that includes the latest Fallback option and wireless SSID scanning fix. That should allow users to switch to the google api call if desired. |
|
What I did for now: I created a munki nopkg with auto-install with the following: launchctl unload -w /Library/LaunchDaemons/com.clburlison.pinpoint.plist It kinda works |
|
I have been having this problem for much longer than this ticket and had previously discussed it via email with @clburlison . I was finding only two or three of the machines I had installed it on worked automatically with MunkiReports the rest failed as described here. The version of macOS did not shed any light since my 10.12.6 Mac and another 10.13.3 Mac both worked and a mixture of Sierra and High-Sierra Macs did not. I believe I have now finally pinned down the cause of this issue. When I first started using this tool the installer set the permissions of the following /Library/Application Support/pinpoint both to drwxr-xr-x This allowed none root level users to run the pinpoint tool - even if it had limited functionality for none sudoers. More recent installers of pinpoint set the permissions of both above folders to drwx------ It is my belief that this change is preventing the MunkiReport client scripts from being able to run the pinpoint tool. I believe this is supported by the fact that on these machines I can manually run pinpoint via sudo pinpoint and the cached result is then obtained by MunkiReports, but it fails to update automatically on machines with the new permissions. My own laptop being the one I installed an older version of pinpoint on originally has less secure permissions of drwxr-xr-x and still allows MunkiReport to work. A possible temporary workaround would be to add a post-install script in Munki for installing pinpoint containing the following. #!/bin/sh (Since this discussion is about using pinpoint with MunkiReports the presumption is that everyone will be logically using Munki to deploy pinpoint.) Note: The presumed reason the method proposed by @ofirgalcon works is that launchctl will be in this case be running pinpoint as root unlike the MunkiReport script. I also notice that the permission of the /Library/LaunchDaemons/com.clburlison.pinpoint.plist file is rw------- which is not technically illegal but highly unusual, normally this would be rw-r--r-- It would be helpful for @clburlison to comment on the reasoning behind the new permissions and whether he feels this is indeed the cause. |
|
I found my 'solution' didnt really work and when I change the service from Apple to Google everything started working. |
|
Corrections. :( It turn out only Sierra Macs are working, the fact that MunkiReport is able to retrieve cached location data on High-Sierra Mac was confusing the matter. For what its worth running pinpoint via AppleRemoteDesktop Admin as root works, it looks like running it via a JAMF script might not - still testing this. So the user account the process runs as might indeed be the issue. However launchctl is supposed to run processes as root and it still seems to have a problem on High-Sierra. I see that the launchdaemon is actually not directly running pinpoint but instead is running supervisor which in turn runs pinpoint. This is actually running the equivalent cli of /Library/Application\ Support/pinpoint/bin/supervisor --delayrandom 300 --timeout 180 -- /Library/Application\ Support/pinpoint/bin/pinpoint --auto Whereas everyone doing cli tests uses a command like /Library/Application\ Support/pinpoint/bin/pinpoint -f Is it running the supervisor binary that is the issue or the fact that you have a binary calling another binary? |
|
I have now finished implementing it in JAMF and it is getting the same problem as MunkiReport, it comes back with the message - Script result: [WARNING]: Unable to determine address The script I am running via JAMF directly calls the pinpoint executable with the -f parameter, so this seems to suggest the fact that launchctl is using supervisor to indirectly run pinpoint is not the cause. I might have to try a cron job next and see if that has any better success than launchctl. To summarise, so far running pinpoint via an interactive environment under High-Sierra works e.g. Terminal.app or AppleRemoteDesktop Admin, running via a scripted environment such as launchctl or a JAMF initiated script does not, based on this logically a cron job will also fail. Not that it is a practical scenario but doing an SSH connection to a Mac and running pinpoint therefore interactively should also work. Based on this we need to some how have a scriptable solution that to High-Sierra looks like an interactive session. It does not appear to be the type of shell e.g. sh vs bash but maybe something else e.g. tty type, being linked to the loginwindow process i.e. process owner, or some other process via which it determines whether it is an interactive session or not. For anyone interested the way I am running it in JAMF is to create a script which uses the JSS API to write the result from pinpoint to an extension attribute. I can then set a policy to run this script everytime a Mac checks in to JAMF. Normally extension attributes are only updated when you do a full recon which might only occur weekly, whereas the checkin interval is around about every 20 minutes. This approach is apparently frowned upon by JAMF because if you are using the extension attribute to define a smartgroup the data can become inconsistent. However I could not conceive of a case where you would want to use the location to define a smartgroup membership. |
The above has nothing to do with this issue. That was an issue in the v2.0.1 release that I didn't catch. This has been resolved with the v2.0.2 package that was just released. @jelockwood As for all your other comment, they simply confirm my prior comment #31 (comment). I doubt your cron job resolves the issue but I look forward to your report. The way this is reporting to me and from what I've seen this is an issue with how the service is launched. In older OS versions we could run this as root without issue but either 10.13 or a point release of 10.13 locked this down so it must be ran as the console user with a current interactive session. |
|
@clburlison
Turns out ARD only works if a user is logged in. What about trying a launchagent instead of a launchdaemon? With a launchagent it would be only running when a user is logged in, could this be run every so often whilst a user is logged in? Obviously it would be preferably to also do this even if a user is not logged in but this might be better than nothing. If root privileges are required you might need to look at a way of adding SetUID to the python scripts, since I believe this is not possible with a script you might need to look at something like this https://stackoverflow.com/questions/8314012/setuid-bit-on-python-script-linux-vs-solaris and using Cython to 'embed' the python script, or 'Python Freeze'. http://docs.python-guide.org/en/latest/shipping/freezing/ Update: If it is working properly it looks like a launchagent makes no difference. :( |
|
For what it's worth I tried a couple of other tools that allow calling CoreLocation via the command line and both seem to have the same problem that they do not work unless a user is logged in and it is run from the users session e.g. via Terminal. At least one of them did not require admin/sudo privileges which was a bonus but it did not handle the error caused by being blocked by Location Services as well as pinpoint. Maybe @clburlison needs to file a bug or enhancement request with Apple as this is a change of behaviour. If Apple's concern is only allowing it to run when a user is logged in then they should allow it to work via a launchagent which my testing suggests is currently not possible. |
|
Latest news. I changed my pinpoint preferences to use Google to do an address lookup and added an API key to enable this. This works fines when run manually but fails again identically when run via the launchdaemon. @clburlison could you consider adding an option to pinpoint to use Google's geolocation api? See https://developers.google.com/maps/documentation/geolocation/intro Since this does not use CoreLocation I would hope and expect it would not be blocked by Apple. (Sadly the former free Google browserlocation api which did not need an API key is no longer available.) |
|
Future development has been stopped. Please see https://github.com/clburlison/pinpoint/#deprecated for more information. |
As discussed on Slack, I've noticed that for some reason munkireport is unable to successfully determine an address, however a manual run of the pinpoint command seems to work just fine. Here's what I've gathered from logs:
Last Successful run on Sierra:
Run by MunkiReport after upgrading to High Sierra :
Manual run on High Sierra:
After this, the plist file is properly updated and on the next run of MunkiReport the new data is reported to the server. If I leave these to their own devices the address info goes to a 'stale' status after a couple of days.
The text was updated successfully, but these errors were encountered: