Uncaught exception 'DOMException'

[KSchmeeds]

Running OS X Server 10.12.5

The error occurs in the /var/log/apache2/error_log when running the munki_enroll script on a machine. The manifest fails to create.

[:error] [pid 371] [client 127.0.0.1:49373] PHP Fatal error: Uncaught exception 'DOMException' in /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php:223\nStack trace:\n#0 /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php(129): CFPropertyList\CFPropertyList->load()\n#1 /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/enroll.php(55): CFPropertyList\CFPropertyList->__construct('/Library/Server...')\n#2 {main}\n thrown in /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php on line 223

[edingc]

Does Apache have write access to the Munki repository?

I don't have a machine with OS X Server on it at the moment so my ability to troubleshoot is limited.

Can you also post the output from running the munki_enroll.sh script in the Terminal on the client machine?

[KSchmeeds]

For testing I have modified the munki_repo/manifests file to be read-write by everyone so I don't have to pass any authentication with curl (as suggested on your wiki homepage).

Running the script creates a "clients" folder inside manifests, but not anything appears inside the clients folder.

Output from the script: sudo ./munki_enroll.sh Password: 2017-06-20 14:41:47.684 defaults[2818:36159] The domain/default pair of (/Library/Preferences/ManagedInstalls, ClientIdentifier) does not exist Remote munki-enroll location: /Library/Server/Web/Data/Sites/Default/munki_repo Computer hostname is: dosx1 Current ClientIdentifier is: Target manifest location: /Library/Server/Web/Data/Sites/Default/munki_repo/manifests/clients/dosx1 Computer manifest for dosx1 does not exist. Will create. Clients folder /Library/Server/Web/Data/Sites/Default/munki_repo/manifests/clients/ does not exist. Will create.

Here is the output in /var/log/apache2/access_log:

default 127.0.0.1 - - [20/Jun/2017:14:46:11 -0500] "GET /munki_repo/munki-enroll/enroll.php?hostname=dosx1&identifier= HTTP/1.1" 500 295 "-" "curl/7.51.0"

Here is the output in /var/log/apache2/error_log:

[Tue Jun 20 14:46:11.268940 2017] [:error] [pid 2742] [client 127.0.0.1:49519] PHP Warning: DOMDocument::load(): Document is empty in /Library/Server/Web/Data/Sites/Default/munki_repo/manifests, line: 1 in /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php on line 223 [Tue Jun 20 14:46:11.269236 2017] [:error] [pid 2742] [client 127.0.0.1:49519] PHP Fatal error: Uncaught exception 'DOMException' in /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php:223\nStack trace:\n#0 /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php(129): CFPropertyList\CFPropertyList->load()\n#1 /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/enroll.php(55): CFPropertyList\CFPropertyList->__construct('/Library/Server...')\n#2 {main}\n thrown in /Library/Server/Web/Data/Sites/Default/munki_repo/munki-enroll/cfpropertylist-2.0.1/CFPropertyList.php on line 223

[edingc]

Thank you. I'm going to try to reproduce the error here and get back with you ASAP.

[edingc]

@KSchmeeds

I was able to reproduce the error. The cause is that the machine does not have an existing ClientIdentifer and corresponding manifest assigned. An existing ClientIdentifier/manifest assignment is a requirement of munki-enroll.

The following lines in your information led me to test this as the problem:

The domain/default pair of (/Library/Preferences/ManagedInstalls, ClientIdentifier) does not exist Current ClientIdentifier is:

It is assumed the machine will have an already existing ClientIdentifier/manifest assigned. I don't, however, make assumptions as to what that ClientIdentifier/manifest should be. If you do not have a preference, I suggest site_default since Munki will fall back to that ClientIdentifier/manifest by default. It doesn't matter if the manifest is empty, it just needs to exist on the Munki server and the client must have it initially assigned before "enrolling" in munki-enroll.

As a longer term solution, modifying the code so that munki-enroll will write a blank manifest if a base ClientIdentifier isn't assigned would probably be prudent. This is not in line with the original intent of munki-enroll, but you're not the first person to experience this type of issue with an unset ClientIdentifier/manifest.

In the meantime, I suspect assigning a default manifest will solve your problem.

I'm going to mark this as both a bug and enhancement and leave it open until I can push a change to fix the behavior as I mentioned above.

[edingc]

Actually, the more I think about it, I'm just going to code the enroll script to stop if the ClientIdentifier is empty. I cannot feasibly guess at the name of the catalog to include in the new manifest.

Again, I suggest creating and using a site_default manifest if you are not going to assign anything else more specific to your clients.

Removing the bug tag and just switching this to an enhancement.

[KSchmeeds]

@edingc

I created a manifest named site_default using MunkiAdmin and then tried running the munki_enroll script again. It looks like I am getting the same result. I do not have /Library/Preferences/ManagedInstalls.plist on the client machine before running the script. Do I need to have a file there already and let the munki_enroll script modify it?

[edingc]

Is Munki installed on the client? It should put the plist there.

On Jun 20, 2017 4:51 PM, "KSchmeeds" notifications@github.com wrote:

@edingc https://github.com/edingc

I created a manifest named site_default using MunkiAdmin and then tried running the munki_enroll script again. It looks like I am getting the same result. I do not have /Library/Preferences/ManagedInstalls.plist on the client machine before running the script. Do I need to have a file there already and let the munki_enroll script modify it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/edingc/munki-enroll/issues/17#issuecomment-309887731, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0D5mnhb4QtenzdRkmmX23xj-Kg8Iyuks5sGDDWgaJpZM4OABNo .

[KSchmeeds]

Yes, Munki is installed on the client.

As a test I ran the two below commands first, and then ran your enroll script. That looks like it made things work as it enrolled the hostname as the manifest into Munki.

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://myserverhere/munki_repo" sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "site_default"

[edingc]

Thanks. I was thinking Munki set a ClientIdentifier and created the plist by default, but it doesn't.

I pushed 246edf049312e2721ce5682c1c47c88f8e9ef8d7 which includes a check in the munki_enroll.sh script to ensure a ClientIdentifier is set before continuing.

I also pushed d60c3ce4a9f4c4128b6544844062074ce725830e to clarify this requirement in the README.