Composer 9.92 and Drag and Drop Package Creation

[devlinford]

Hi guys....Newb question....

I am using Composer to create a package. One of the dependant files is located in the "/Users/~/Library" folder. When I find this folder in my user folder, and drag it in, it actually has my home folder name. I don't want this...I want this package to install this folder into "/Users/~/Library" of whatever logged in user is installed it.

Is this possible?

Many thanks,

[pat_best · Accepted solution]

you should be able to select the FUT (fill user template) to add this for new users and use FEU (fill existing users) to propagate it out to existing accounts. Just wondering... whatcha buildin' ?

[mm2270]

If you package it as a DMG and check the FEU (Fill Existing Users) option in the package in Casper Admin, then, yes it should do this. You can ignore the fact that it has your username in the package, because, as long as its in the standard /Users/ path, it should use your username as the wildcard for other user folders.

Outside of this, if I were doing it, I would probably move the user level stuff into /tmp/ and copy them in to the Composer source from there, then add a postinstall script to move the items from /tmp/ into place in the existing home folders and finally, build the package as a PKG format. But that's just me. Some people like using FEU or FUT options in a dmg. Others like scripting it with a pkg format.

[devlinford]

@pat.best

I am just building a VPN installer package to be deployed via Self Service. Two Apps and some system Library prefs (easy), and some /User/Library prefs (a little more difficult). Is FUT and FEU in Composer? In Casper Admin? Or is this while creating the policy inside JSS? If the latter is correct, would the plan be to remove these prefs from the installer package and add them as file copies after the installer, configured in JSS?

@mm2270

Thanks for the support. I think I'd like to try using FEU if possible, Is the only way to accomplish this is to create a DMG, instead of package? That said, I like the idea of installing into /tmp/ then moving afterwards - Pretty straightforward. Are there any compelling reasons other than personal preference to choose one method over the other?

[pat_best]

@mm2270 is correct, in order to do FEU FUT it will need to be a .dmg. The check boxes for these settings are in both casper admin as well as in the policy itself when you add the .dmg to your policy

edit: if you want to continue to build your package with the prefs included, you will want to build it as a DMG and select FEU and/or FUT in Casper Admin or in your Self Service policy. You could build the prefs into their own DMG and install them alongside your applications if you choose to but the FEU FUT options would still need to be set. I felt I needed to clarify my previous vague response. Hope this helps!

[devlinford]

@mm2270

@mm2270 is correct, in order to do FEU FUT it will need to be a .dmg. The check boxes for these settings are in both casper admin as well as in the policy itself when you add the .dmg to your policy

Is there a benefit to using a .dmg over a .pkg or vice versa?

edit: if you want to continue to build your package with the prefs included, you will want to build it as a DMG and select FEU and/or FUT in Casper Admin or in your Self Service policy. You could build the prefs into their own DMG and install them alongside your applications if you choose to but the FEU FUT options would still need to be set. I felt I needed to clarify my previous vague response. Hope this helps!

So, if I want to make it with embedded prefs (my pref, no pun intended), I need to create it as a .dmg - Got it. Once I select FUT and/or FET, it will find any 'user specific' path located in my .dmg and then replace that path with the logged in user, during installation?

Also, you mentioned FET and FUT in both Admin and the JSS policy. Do I need it in both places, or just one?

PS: You've both been a huge help.

[pat_best]

with FEU it will find the relative path for all user accounts on the computer and place those files there but it will not propagate to new users created after you deploy the package (this is where FUT comes in). If you select FEU and/or FUT in casper admin it will reflect that option in your policy. You will have the option to check or uncheck these options at any time in casper admin or your policy.

[devlinford]

@pat.best

with FEU it will find the relative path for all user accounts on the computer and place those files there but it will not propagate to new users created after you deploy the package (this is where FUT comes in). If you select FEU and/or FUT in casper admin it will reflect that option in your policy. You will have the option to check or uncheck these options at any time in casper admin or your policy.

Fantastic...Just to be clear. It will find the relative path for all users, for any portion of the .dmg that specifies a specific users home folder? For example: in the original image posted above. FUT and FET will replace the 'deford', and create a relative folder for any existing and new user on this system?

[pat_best]

that is correct

[devlinford]

Worked great!!!!

[mm2270]

@devlinford I'm not sure if this was actually directed toward me, or just the general public:

Is there a benefit to using a .dmg over a .pkg or vice versa?

But in case you were still looking for an opinion (there is no real answer for this, only opinions) I would say the big advantage a pkg has over a dmg is that its much more portable. If you set up your postinstall script correctly, you could literally hand the pkg installer to someone on a non Casper managed Mac and it could install the software + the preferences or configuration files you want to deploy along with it. Using the pkg method + postinstall could be used to install things like Configuration Profiles, make more surgical edits to existing plist files and more. DMGs are sort of dumb packages, not in the sense that they don't work mind you, just that it isn't going to respect an existing plist file that may already be in place. It will just overwrite it with the new plist, meaning the user could potentially lose some custom settings that you may not desire to do. And as mentioned, they are proprietary to Casper, so you really can't use them effectively outside of the Casper Suite deployment processes.

Another example, I have built some pkg installers that place LaunchAgent or LaunchDaemon plists in place that are part of the install and can activate them right away as part of the post install script, rather than waiting until the Mac reboots or the user logs out and back in. By itself a DMG can't do this because it can't contain any scripts. You would need to have a separate script run as "After" so it runs after the files are in place. That's sometimes seen as a plus because you can segregate items from your packages, making them a little more flexible. Still, it requires the Casper Suite or another management solution for proper deployment.

Hope that helps.

[devlinford]

@mm2270

But in case you were still looking for an opinion (there is no real answer for this, only opinions) I would say the big advantage a pkg has over a dmg is that its much more portable. If you set up your postinstall script correctly, you could literally hand the pkg installer to someone on a non Casper managed Mac and it could install the software the preferences or configuration files you want to deploy along with it. Using the pkg method postinstall could be used to install things like Configuration Profiles, make more surgical edits to existing plist files and more. DMGs are sort of dumb packages, not in the sense that they don't work mind you, just that it isn't going to respect an existing plist file that may already be in place. It will just overwrite it with the new plist, meaning the user could potentially lose some custom settings that you may not desire to do. And as mentioned, they are proprietary to Casper, so you really can't use them effectively outside of the Casper Suite deployment processes. Another example, I have built some pkg installers that place LaunchAgent or LaunchDaemon plists in place that are part of the install and can activate them right away as part of the post install script, rather than waiting until the Mac reboots or the user logs out and back in. By itself a DMG can't do this because it can't contain any scripts. You would need to have a separate script run as "After" so it runs after the files are in place. That's sometimes seen as a plus because you can segregate items from your packages, making them a little more flexible. Still, it requires the Casper Suite or another management solution for proper deployment. Hope that helps.

It was meant for general opinions but I value yours. Thank you sir.

[mscottblake]

@devlinford

Also, you mentioned FET and FUT in both Admin and the JSS policy. Do I need it in both places, or just one?

The setting in Casper Admin becomes the default for that package. Therefore, if you check both FEU and FUT in Casper Admin, then add the package to a policy, you will see FEU and FUT checked by default in the policy.

You don't need it checked in both, but I find it easier to check in Casper Admin so I don't have to remember to check it in the policy.

[dvasquez]

@mm2270

I was looking for the information you commented on about .pkg being portable. I am doing exactly this for our environment. It is a great feature and Composer is helpful.

Thanks!