Enhancement: add support for /api/startup-status

[ecanault]

Hi,

Following the implementation of /api/startup-status in the SDK (deploymenttheory/go-api-sdk-jamfpro#603), is it possible to add support in the terraform provider?

Thanks in advance,
Emmanuel

[thejoeker12]

@ecanault what is the purpose of allowing Terraform to access this API endpoint? It's a one time use utility in the majority of cases and does not control any resources.

[ecanault]

Hi @thejoeker12,

Getting informations regarding this endpoint, especially the setupAssistantNecessary key will permit, if it's true, to use /api/v1/system/initialize (see #514) endpoint for initial setup through Terraform.

Once this setup has been done, this key could then be used as a condition in Terraform to build the rest of an instance (settings, management items, ...).

I agree that it can be an overkill load of work for possibly a one time usage for those 2 endpoints, but my goal is to be able to build (and maintain) multiple Jamf Pro instances based on a template with the maximum of automations. For the moment, assuming that all SDK capabilities could be integrated in the provider in a near future, the only manual actions I see are: ADE / VPP / APNs / IdP integrations that are linked to external services and FILEVAULT2COMM certificate that can not be downloaded via API (you can vote my feature request here for that 😉 https://ideas.jamf.com/ideas/JPRO-I-797).

Regards,
Emmanuel

[ShocOne]

hi @ecanault ,

i don't think this should live within the provider as there is no resource to manage to speak of. i think for your usecase within your pipeline you need a script to run to monitor the init of a jamfpro server and upon that completion, carry out any other pre flight checks before running your tf.

i put this together - https://github.com/deploymenttheory/go-api-sdk-jamfpro/blob/main/recipes/jamf_pro_initialization_server/InitializeAndcheckStatus.go to give you an idea. thanks

[ecanault]

Hi @ShocOne

I totally agree that implementing those 2 endpoints (/api/startup-status and /api/v1/system/initialize #514) is a little bit overkill if we consider them as a "one time" information for the example I gave you above.

That being said, and on the other hand, why not?

In my opinion, if a product can be managed with Terraform, it has to be complete regardless the fact that some datas or resources may or may not be used the way you may want or think. Let people build new ideas 😉!

I think also that it is an advantage to be able to completely build a Jamf Pro management with the same tool (Terraform in our case): this will avoid multiple languages, and therefore errors, and will permit to centralize in the same place (Terraform states files) the whole status of an instance.

If we agree that the 2 endpoints come together as they are related to similar datas/resources steps, let me give you another example for the /api/v1/system/initialize endpoint: as an MSP provider, Jamf gives us regularly a new Activation Code for all our clients (same code for all): this endpoint, with the /api/v1/activation-code one, will permit to build and maintain this information (the code) with the same tool (Terraform).

Thanks for your reading, and hope I was able to convince you!
Emmanuel

[ShocOne]

I'm still with the opinion that you should have a preflight script run within your pipeline that checks for a jamf pro server initialisation and upon a successful check then allow the terraform step in the pipeline to occur.

Could you describe all of the steps you perform (manual / automated) when you stand up a new jamf pro instance ? The context might give me some ideas 💡.

Thanks

Dafydd

[ecanault]

Hi @ShocOne,

Here is the actual workflow:

• By script:

  • Setup assistant: activation code, organization name, local admin account
  • Local admin account preferences: language, timezone, search preferences

• By hand, mainly because it requires access to resources outside Jamf Pro that are not always available programmatically (e.g. Apple Business Manager):

  • Cloud identity provider or LDAP server (depending of the customer context)
  • VPP integration
  • ADE integration
  • APNs and Jamf Push Proxy
  • Jamfcloud distribution point settings
  • Security settings (not available with Jamf Pro API)
  • App updates settings (not available with Jamf Pro API)
  • Single sign-on integration

• By script:

  • SMTP server settings
  • Single sign-on settings and obtain the failover URL
  • User accounts & groups settings
  • MDM profile settings
  • UIE and re-enrollment settings
  • Cloud services connection settings
  • Self Service, branding and onboarding settings
  • Inventory collection and checkin settings -> currently working on getting these ones in Terraform
  • Cleanup (remove default inventory policy and default groups)

• By terraform:

  • Activation code
  • Buildings
  • Categories
  • Computer checkin
  • Configuration profiles
  • Departments
  • Device enrollments
  • Dock items
  • Extension attributes
  • Icons (for Self Service, policies and configuration profiles)
  • Network segments
  • Packages
  • Policies
  • Prestages
  • Printers
  • Restricted softwares
  • Scripts
  • Sites
  • Smart and static groups

The main goal is to avoid the mix of "tools" (preflight script first and terraform after) if, for example, we want to run/maintain all that stuff outside GitLab and inside Terraform Cloud. Obviously, being also able to perform the 2nd "By script" section with Terraform will be mandatory for that.

Finally, having /api/startup-status and /api/v1/system/initialize available will permit to gather information in the Terraform state (no idea of use cases for the moment by the way 😉).

Emmanuel