macOS: preferences should be in a preference domain, not inside GLPI-Agent.app/etc

[grahampugh]

Documentation

• [X] Yes, I do

Professional support

Still not applicable

Is your feature request related to a problem?

It is outdated and bad practise to require config to be added to an application bundle on macOS, as it means that the app cannot be signed and notarised. The current version of GLPI-Agent.app requires config being added to GLPI-Agent.app/etc.

Configuration is best supplied via preferences domain (e.g. org.glpi.agent), so that it can be configured with a configuration profile for deployment via MDM, or preferences PLIST file (/Library/Preferences/org.glpi.agent.plist). Failing that, configuration files should be placed elsewhere, such as /Library/Application Support/GLPI.

I expect that this behaviour will be enforced by Apple at some point in the future, so it's worth you considering these changes now.

Expected behavior

I should be able to configure the agent via configuration profile, preferences PLIST file, or from a file placed in a conventional location for macOS which does not break the ability to notarize the app.

Alternatives you've considered

N/A.

Additional context

No response

[g-bougard]

Hi @grahampugh

thank you for your suggestion.

At the moment, the latest nightly builds are notarized without any problem but we should do anything that will guarantee it will continue to be notarized in the future.

The simplest way at the moment, would probably be to modify the default agent.cfg include directive to:

include "/Library/Application Support/GLPI-Agent"

And create that folder during installation.

Actually, it is set by default to "conf.d", which means the included folder is /Applications/GLPI-Agent.app/etc/conf.d.

Another way would be to install the default conf into /Library/Application Support/GLPI-Agent so the include folder would be /Library/Application Support/GLPI-Agent/conf.d. But here the question would be should we always override /Library/Application Support/GLPI-Agent/agent.cfg during upgrade but keeping cfg files under conf.d ? or only copy it if it is missing ?

I'm not aware of configuration profile for deployment, so I don't see how it could fit the purpose. Have you any official documentation link about that ? Thank you

[grahampugh]

@g-bougard Hi, thanks for your response. The folder will indeed successfully notarise, but when the files are changed on the client, that will break the notarisation signature.

However, I hadn't seen until now that you are not really shipping an app bundle at all. You are basically putting a UNIX agent into a folder called GLPI-Agent.app, but it isn't an app bundle, as it doesn't have the basic app bundle structure (a Contents folder, containing an Info.plist, and a MacOS folder containing a binary, etc). And I see you have hidden the GLPI-Agent.app folder from Finder by using the chflags command.

This is highly unusual - I don't think I've ever seen this done before, and I have to deal with packaging up hundreds of apps for managed deployment as part of my job.

I would argue that a UNIX tool that is not an app should not be placed in a folder that pretends to be an app. It belongs in /opt or /usr/local.

So that discovery somewhat negates my request for where the config goes, as I had assumed (without first looking) that this was an actual app compiled in Xcode. If you ever do intend to convert the tool to an actual macOS app, you might want to look into https://developer.apple.com/documentation/foundation/nsuserdefaults through you will have to handle the interaction of Perl with Objective-C in that case.

[g-bougard]

Thank you for your comment.

Yes, I'm basically putting a dedicated perl unix command with all its related perl environment (including glpi-agent script) into a folder called GLPI-Agent.app. And yes, this is not an app bundle with the basic app bundle structure. Yes, the folder is made hidden under Applications as it is not meant to be started by users but only as a service.

I understand this is highly unusual. I'm not usually a MacOS software packager and I tried to made something that just works embedding some years of fusioninventory-agent packaging history. This project is a fork of fusioninventory-agent and that one was previously installed under /opt/fusioninventory-agent. But we run with some issues with Catalina and I decided to install glpi-agent more like I thought a MacOS app should be installed. I can hear this can be a problem in the future if Apple decides to apply some strict rules on how an app should be installed. Now, on my point of view, MacOSX is just an unix system like others ;-)

So do you mean it's still okay for you, now you understood how it is packaged under MacOSX, to leave configuration under GLPI-Agent.app/etc ? Or still using /Library/Application Support/GLPI-Agent folder would be better ? Does it matter for a configuration profile for deployment via MDM ?

[grahampugh]

Hi @g-bougard Yes, it basically makes no difference where the config file is when it's not an app bundle, as any signing and notarisation will be ignored since the ".app" is not an app.

I'm not sure what problems you had using /opt but it should be fine - even Homebrew moved their default installation to /opt (previously in /usr/local, which had its issues). There is anyway (currently) no problem creating a folder in /Applications called GLPI-Agent. I just don't think it should be called GLPI-Agent.app as that's a misrepresentation of the contents. macOS expects something with the ".app" suffix to be an app bundle, not just a folder. That's similar to how a ".pkg" bundle can be a folder but has an expected structure containing metadata.

Renaming GLPI-Agent.app to GLPI-Agent would not affect the agent's functionality at all (and you could still hide the folder).

[g-bougard]

Hi @grahampugh I'm closing this issue now as I updated the packaging following your advice and as it is now released. Thank you for your contribution.

[grahampugh]

Thanks for the fast turnaround!