Error 500 when client posts result to MuniReport

[jelockwood]

I have DEBUG enabled in my .env but that does not seem to help in this case. I have looked at apache2 logs and syslog but cannot spot nothing helpful there.

I am running Munkireport-PHP 5.8.0 on an Ubuntu server.

The client Mac is ending its run with the following.

    Need to update fan_temps (11KB)
    Need to update usage_stats (122KB)
    Need to update munkireport (2KB)
    Sending items (425KB)
    Status: 500
    Headers: {'Transfer-Encoding': 'Identity', 'Content-Type': 'text/html; charset=UTF-8', 'Connection': 'close', 'Server': 'Apache/2.4.58 (Ubuntu)', 'Date': 'Tue, 10 Sep 2024 17:49:35 GMT'}
ERROR: https://munkireport.mydomain.com/index.php?/report/check_in failed, HTTP returncode 500 (internal server error)
    ## Finished run

The following is the status page from MunkiReport, as you can see I have increased the upload size limits hoping that was the issue.

If there is a location I should look for a more detailed log file that would be much appreciated.

[tuxudo]

This is caused by a module. You will need to disable the modules on a test client until you can determine what module is causing the issue. Once determined, we can start troubleshooting that module.

[jelockwood]

Thanks @tuxudo I was starting to suspect that although my first thought had been it was contributing a larger result and hence my increasing to upload limits.

I will try the modules one at time tomorrow.

[jelockwood]

@tuxudo
You were right it was down to a module, your own tuxudo/jamf one in fact 😄

I had put place holder settings in my .env which were not valid and not updated them. However even after putting what I believe are now valid settings in place it is still failing. With no apparent log information it is hard to determine what is incorrect. I will investigate this further.

[jelockwood]

@tuxudo
I am still struggling apparently with the settings for your module. Firstly I can confirm php-curl is installed.

I added the five lines listed in your README and now have what I believe to be valid settings. If I have

JAMF_ENABLE="TRUE"

then I get the 500 error, if this is false or commented out then it succeeds in an upload but obviously without any Jamf data.

The next line is supposed to be the base URL for our Jamf server. This might be the cause. In our case we started off with an on-premise Jamf Pro installation which has a URL different and on a different port to a standard cloud Jamf Pro server. This URL obviously works for managing our Macs and has been moved to a Jamf Pro cloud instance, here is a sanitised copy of the URL.

JAMF_SERVER="https://my-old-server-name.mydomain.com:8443/"

The DNS record is a CNAME aka alias and points to mycompany.jamfcloud.com as instructed by Jamf and as mentioned works fine for admin login and MDM functions.

It is now using a certificate generated by Jamf which is valid as tested in a web-browser and from the fact all our devices work with it. I have however also tried

JAMF_VERIFY_SSL="FALSE"

For the username and password I created a dedicated user in Jamf Pro with Auditor access which I believe is READONLY, this did not work, I then tried my own full admin account, this also did not work. (In that both gave the 500 error.)

I don't know how your module communicates with Jamf Pro but if you are using the Jamf API then I know Jamf have changed the access method again. Does yours still work?

Doing the following in terminal works on the same Linux web server hosting MunkiReport but obviously is not using PHP.

curl -o file.html https://my-old-server-name.mydomain.com:8443/

My cloud hosted Jamf Pro is Version 11.7.1-t1721056075

[tuxudo]

I do not use the jamf module anymore. Be sure you are setting the JAMF_SERVER config item to the actual JSS server, not a CNAME or other DNS name.

[jelockwood]

@tuxudo
I had been previously instructed by Jamf to use the CNAME and the different port in order to leave already enrolled devices using the original address. However I just tested web login to it direct rather than via the CNAME and it does work to access the web admin page. HOWEVER I do have to use the non-standard port of 8443.

I therefore tried the direct non-CNAME address but with the non-standard port i.e. 8443 and it still fails. ☹️

If you are able to point me to some log that might help with diagnostics that would be great.

[tuxudo]

There are no logs for this kind of error.

MunkiReport is talking directly to the JSS' API, do not use a CNAME redirect with it.

The jamf_server config item should be exactly the same as the URL that you use to directly access the JSS. Jamf Cloud usually does not have an alternate port, but uses the standard 433. Try setting just the jamf_server to look like JAMF_SERVER="https://DOMAIN.jamfcloud.com/" where DOMAIN is your Jamf Cloud's subdomain.

[jelockwood]

@tuxudo
If in a web browser I accessing the jamfcloud site without specifying port 8443 I get the following error message displayed in the web browser.

Service Unavailable

Nether-the-less, I tried that in the .env and still get error 500. Using port 8443 and the correct Tennant name in a web browser works.

I agree that usually jamfcloud sites use 443 and not 8443 but if you originally setup Jamf Pro on premise then the on premise installer uses port 8443. When this is migrated to jamfcloud it migrates as port 8443 so that existing enrolled devices see exactly the same URL and hence do not loose connection. (Hence also the use of a CNAME.)

The following is from an official Jamf blog article about migrations.

There are three options for migration: standard, custom DNS and fresh start. A standard migration clones your current instance to the cloud and changes the URL of your instance, requiring all devices to re-enroll. The most popular option, custom DNS, allows you to redirect your Jamf URL behind the scenes without having to re-enroll your devices. This option requires you to have access to your DNS source. In some instances, a fresh start is the best option. This option has no prerequisites and involves no database migration. All devices are re-enrolled.

For direct API access the CNAME vs direct name should not matter but the PORT will matter.

[tuxudo]

Please contact your Jamf representative for the correct URL and port for accessing the API for your Jamf Cloud instance. Once that is obtained, MunkiReport should work properly.

[jelockwood]

@tuxudo
I have written shell scripts which call the Jamf api myself and run these from a Mac. For these the URL format I successfully used was https://my-server-name.mydomain.com:8443/

At the moment I am wondering if either PHP as a whole or your PHP code is being upset by the inclusion of the custom port.

My own shell script was happy enough with this and I was using the command line version of curl to do this not of course the PHP curl command.

[tuxudo]

I no longer use the jamf module and am not able to debug it. Pull requests are welcome on it to fix any issues you find. It was originally written with port options to be taken into account.

[jelockwood]

@tuxudo
Which of your files in the module does the actual connection to the Jamf server? I will as you suggest look at modifying it myself.

[tuxudo]

The Jamf module makes the connection

[jelockwood]

@tuxudo
Clearly in my case currently the module is not connecting. As you suggested I therefore may need to modify it to diagnose and workaround the issue. To do this it would help me to know which component/file of your module is responsible for connecting to Jamf Pro as that would presumably the problem area.

[jelockwood]

@tuxudo
Ah ha! As one might expect it is mostly my fault. It looks like whilst I did have a php-curl installed it was the wrong version. I have installed a newer one to match my PHP and we have now got past the 500 error.

We do however still have a remaining problem. I am getting the following shown on the client Mac when testing this.

<b>Warning</b>: Undefined property: stdClass::$token in <b>/usr/local/munkireport/vendor/tuxudo/jamf/lib/jamf_helper.php</b> on line <b>540</b><br />