Formatting errors for Configuration Profiles

[smithjw]

When trying to create a Configuration Profile in Jamf Pro that contains a Certificate payload, I consistently receive plist line count mismatch errors during planning. In the past these errors have been generated because by default all files within my repo have a blank last line (added by VS Code). Prior to the formatting changes in the jamfpro_macos_configuration_profile_plist, I was able to mitigate this by wrapping the file object within the resource in a chomp() function but this no longer works as the line discrepancy is often quite large.

I believe this could be due to the formatting of the profile placing the data value all on one line rather than my formatted block within the mobile config file.

And just to confirm, this mobileconfig file example uploads and displays in Jamf without error.

profile.tf

resource "time_static" "example_certs" {
  triggers = {
    profile_path = "example.mobileconfig"
    profile_hash = filemd5("example.mobileconfig")
  }
}

resource "jamfpro_macos_configuration_profile_plist" "example_certs" {
  name                = "Example Certs"
  payloads            = chomp(file(time_static.example_certs.triggers.profile_path))
  redeploy_on_update  = "Newly Assigned"
  distribution_method = "Install Automatically"
  user_removable      = false
  level               = "System"
  description         = <<-EOT
    Updated: ${time_static.example_certs.id}
    Source Repo: github.com/example_repo
    Distributes the Root Cert for Google
  EOT

  scope {
    all_computers = false
    all_jss_users = false
  }
}

example.mobileconfig

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>PayloadDisplayName</key>
        <string>Google Example Root CA</string>
        <key>PayloadCertificateFileName</key>
        <string>GTS_Root_G1.cer</string>
        <key>PayloadContent</key>
        <data>
          MIIFYjCCBEqgAwIBAgIQd70NbNs2+RrqIQ/E8FjTDTANBgkqhkiG9w0BAQsFADBX
          MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UE
          CxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTIwMDYx
          OTAwMDA0MloXDTI4MDEyODAwMDA0MlowRzELMAkGA1UEBhMCVVMxIjAgBgNVBAoT
          GUdvb2dsZSBUcnVzdCBTZXJ2aWNlcyBMTEMxFDASBgNVBAMTC0dUUyBSb290IFIx
          MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAthECix7joXebO9y/lD63
          ladAPKH9gvl9MgaCcfb2jH/76Nu8ai6Xl6OMS/kr9rH5zoQdsfnFl97vufKj6bwS
          iV6nqlKr+CMny6SxnGPb15l+8Ape62im9MZaRw1NEDPjTrETo8gYbEvs/AmQ351k
          KSUjB6G00j0uYODP0gmHu81I8E3CwnqIiru6z1kZ1q+PsAewnjHxgsHA3y6mbWwZ
          DrXYfiYaRQM9sHmklCitD38m5agI/pboPGiUU+6DOogrFZYJsuB6jC511pzrp1Zk
          j5ZPaK49l8KEj8C8QMALXL32h7M1bKwYUH+E4EzNktMg6TO8UpmvMrUpsyUqtEj5
          cuHKZPfmghCN6J3Cioj6OGaK/GP5Afl4/Xtcd/p2h/rs37EOeZVXtL0m79YB0esW
          CruOC7XFxYpVq9Os6pFLKcwZpDIlTirxZUTQAs6qzkm06p98g7BAe+dDq6dso499
          iYH6TKX/1Y7DzkvgtdizjkXPdsDtQCv9Uw+wp9U7DbGKogPeMa3Md+pvez7W35Ei
          Eua++tgy/BBjFFFy3l3WFpO9KWgz7zpm7AeKJt8T11dleCfeXkkUAKIAf5qoIbap
          sZWwpbkNFhHax2xIPEDgfg1azVY80ZcFuctL7TlLnMQ/0lUTbiSw1nH69MG6zO0b
          9f6BQdgAmD06yK56mDcYBZUCAwEAAaOCATgwggE0MA4GA1UdDwEB/wQEAwIBhjAP
          BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTkrysmcRorSCeFL1JmLO/wiRNxPjAf
          BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzBgBggrBgEFBQcBAQRUMFIw
          JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnBraS5nb29nL2dzcjEwKQYIKwYBBQUH
          MAKGHWh0dHA6Ly9wa2kuZ29vZy9nc3IxL2dzcjEuY3J0MDIGA1UdHwQrMCkwJ6Al
          oCOGIWh0dHA6Ly9jcmwucGtpLmdvb2cvZ3NyMS9nc3IxLmNybDA7BgNVHSAENDAy
          MAgGBmeBDAECATAIBgZngQwBAgIwDQYLKwYBBAHWeQIFAwIwDQYLKwYBBAHWeQIF
          AwMwDQYJKoZIhvcNAQELBQADggEBADSkHrEoo9C0dhemMXoh6dFSPsjbdBZBiLg9
          NR3t5P+T4Vxfq7vqfM/b5A3Ri1fyJm9bvhdGaJQ3b2t6yMAYN/olUazsaL+yyEn9
          WprKASOshIArAoyZl+tJaox118fessmXn1hIVw41oeQa1v1vg4Fv74zPl6/AhSrw
          9U5pCZEt4Wi4wStz6dTZ/CLANx8LZh1J7QJVj2fhMtfTJr9w4z30Z209fOU0iOMy
          +qduBmpvvYuR7hZL6Dupszfnw0Skfths18dG9ZKb59UhvmaSGZRVbNQpsg3BZlvi
          d0lIKO2d1xozclOzgjXPYovJJIultzkMu34qQb9Sz/yilrbCgj8=
        </data>
        <key>PayloadDescription</key>
        <string></string>
        <key>AllowAllAppsAccess</key>
        <true />
        <key>KeyIsExtractable</key>
        <false />
        <key>PayloadEnabled</key>
        <true />
        <key>PayloadIdentifier</key>
        <string>e0eda400-195d-4e65-9719-ab6ab33910cf</string>
        <key>PayloadOrganization</key>
        <string>Example Org</string>
        <key>PayloadType</key>
        <string>com.apple.security.pkcs1</string>
        <key>PayloadUUID</key>
        <string>e0eda400-195d-4e65-9719-ab6ab33910cf</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
      </dict>
    </array>
    <key>PayloadDescription</key>
    <string>Distributes the Root Example Certificates</string>
    <key>PayloadDisplayName</key>
    <string>Example Certs</string>
    <key>PayloadEnabled</key>
    <true />
    <key>PayloadIdentifier</key>
    <string>d0fde289-97c3-4d7c-a218-89a70f88c5aa</string>
    <key>PayloadOrganization</key>
    <string>Example Org</string>
    <key>PayloadRemovalDisallowed</key>
    <true />
    <key>PayloadScope</key>
    <string>System</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>d0fde289-97c3-4d7c-a218-89a70f88c5aa</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
  </dict>
</plist>

[smithjw]

Another issue with the validation that I run into is differences in indentation ("incorrect indentation on line 4"), and the modification of attributes in profiles.

Many of my profiles have <string /> in the body, which is replaced with <string></string>.

[w0de]

I can confirm that the data value's new lines are the issue. I've been able to work around it by removing them (programmatically, prior to apply, so as to preserve the neat formatting in repo).

Indentation, empty values' key style, and trailing new lines are also three annoyances I can confirm (and which I've also programmatically worked around).

[ShocOne]

@w0de , what steps are you taking ?

[smithjw]

@w0de Would love if you can share what you're doing to work around things. In my case I've tried turning validation on/off, modifying the indentation of my profiles, etc. All result in their own issues.

I'm passing fully valid config files that are kept in format by the VS Code XML plugin. At this stage, I'd be happy to go back to the 0.x days of the provider where it didn't even check what the remote profile looked like and simply checked whether the profile had changed from what was available in the state.

Turning validation off and having all profiles reupload every run isn't a great experience :(

[ShocOne]

Can you define valid? Since what a jamf pro server will accept vs. the post processing it performs are two very different things. the resp is what matters as that is what is compared to your hcl definition and it's this difference that needs to be suppressed within the provider. the reason there is strict validation rules applied up front is because i cannot account for every admins whims for how they want to style an xml file, nor is there any documentation from jamf on the formatting they accept for xml nor the post processing they perform server side once a config profile has been created.

therefore, the plist's should be exports from jamf pro as per the documentation and no other sources.

i've spent today trying to handle for a 3rd time your styling prefs re: tabs and spaces and it's proving very complex and for not a lot of value from my perspective.

im willing to take a look at anything that doesn't work and falls within the guidelines, but outside of that i have limited interest.