Add the support for package installation #110

ecanault · 2019-05-14T12:11:51Z

Hi,

A very basic update to add the path of a package file in parameter #10.

Based on v2.7.2.1 of the original script.
Main changes are between lines 112-115, lines 381-385, line 388 and line 390.

Regards,
Emmanuel

kenchan0130 · 2019-05-14T17:16:18Z

macOSUpgrade.sh

@@ -374,12 +378,16 @@ if [[ ${pwrStatus} == "OK" ]] && [[ ${spaceStatus} == "OK" ]]; then
        eraseopt='--eraseinstall'
        /bin/echo "   Script is configured for Erase and Install of macOS."
    fi
+    ##Check if installPackage is Enabled
+    if [ ! -z "${installPkg}" ]; then
+        pkgopt="--installpackage ${installPkg}"


@taniguti

There is something I would like to discuss with you.

I would say @ecanault's work has partially good points.
But it might be better to use following steps than to use the installpackage option of startosinstall command.

Steps (draft)

Get the trigger name of a policy in the argument from the user with jamf script argument.

Create a pkg which runs jamf policy-event <the trigger name>.

Set the value of the installpackage option to run the pkg (created in step2).

This is because it is difficult to put pkg on the local device beforehand.
The advantage of running a policy is that we can run a variety of subsequent processes, not just a pkg.

Cons
If the device cannot connect to the Internet, it may not work as expected.

@kenchan0130

Summary)
The addition of pkgopt complicates the functionality of macOSUpgrade.sh, so I object to adding this functionality.
I think that it is possible to realize this function by the function of JamfPro.

It is of course possible to use macOSUpgrade.sh alone, but I understand that it is assumed to be used with JamfPro.
This means that the Mac computer on which macOSUpgrade.sh is to be run is under control of JamfPro.

Considering putting the pkg file in the path pointed to by "$ pkgotp", it seems more straightforward to do with JamfPro's Policy processing than processing in macOSUpgrade.sh. In other words, check the version of os etc. If there is no element added by the pkg file, pkg will be sent and installed.

Even through, when adding "pkgopt" to macOSUpgrade.sh, there should be confirmation of the existence of the pkg file expected by this switch. There should also be verification of the package itself, if it might not be signed or the file has been corrupted. The implicit premise and expectation that management will definitely put the pkg file in its place as expected brings the possibility of interfering with stable operation.
It is possible to make the above implementation macOSUpgrade.sh, but the code gets more complicated. I think it would be better to adopt a solution using JamfPro's Policy.

Thank you for your suggestions. @ecanault

The addition of pkgopt complicates the functionality of macOSUpgrade.sh, so I object to adding this functionality.
I think that it is possible to realize this function by the function of JamfPro.

I have the same opinion as you.
As mentioned #110 (comment)
, I recommend to use the install pkg feature of prestage enrollment if the admin want to use erase option of the startosinstall command.

However, when the device does not have DEP, the installpackage option may be useful.
Therefore, if package validation is correct, we may be able to accept the changes.
We will not continue to adopt it aggressively, as it will not be complicated. (In other words, if we get the right response, we may adopt it.)

taniguti · 2019-05-24T01:20:28Z

macOSUpgrade.sh

@@ -261,7 +265,7 @@ fi
 # CREATE FIRST BOOT SCRIPT
 # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

-/bin/mkdir -p /usr/local/jamfps
+/bin/mkdir /usr/local/jamfps


If there is already this directory, It would be got an error.
The switch '-p' will be workaround.

taniguti · 2019-05-24T01:22:35Z

macOSUpgrade.sh

-description="This process will take approximately 5-10 minutes.
-Once completed your computer will reboot and begin the upgrade."
+description="Your computer will reboot in 5-10 minutes and begin the upgrade.
+This process will take approximately 30-40 minutes."


LGTM to description strings changes.

taniguti · 2019-05-24T02:02:12Z

macOSUpgrade.sh

@@ -374,12 +378,16 @@ if [[ ${pwrStatus} == "OK" ]] && [[ ${spaceStatus} == "OK" ]]; then
        eraseopt='--eraseinstall'
        /bin/echo "   Script is configured for Erase and Install of macOS."
    fi
+    ##Check if installPackage is Enabled
+    if [ ! -z "${installPkg}" ]; then
+        pkgopt="--installpackage ${installPkg}"


@kenchan0130

Summary)
The addition of pkgopt complicates the functionality of macOSUpgrade.sh, so I object to adding this functionality.
I think that it is possible to realize this function by the function of JamfPro.

It is of course possible to use macOSUpgrade.sh alone, but I understand that it is assumed to be used with JamfPro.
This means that the Mac computer on which macOSUpgrade.sh is to be run is under control of JamfPro.

Considering putting the pkg file in the path pointed to by "$ pkgotp", it seems more straightforward to do with JamfPro's Policy processing than processing in macOSUpgrade.sh. In other words, check the version of os etc. If there is no element added by the pkg file, pkg will be sent and installed.

Even through, when adding "pkgopt" to macOSUpgrade.sh, there should be confirmation of the existence of the pkg file expected by this switch. There should also be verification of the package itself, if it might not be signed or the file has been corrupted. The implicit premise and expectation that management will definitely put the pkg file in its place as expected brings the possibility of interfering with stable operation.
It is possible to make the above implementation macOSUpgrade.sh, but the code gets more complicated. I think it would be better to adopt a solution using JamfPro's Policy.

Thank you for your suggestions. @ecanault

ecanault · 2019-05-24T07:14:09Z

Hi,

Thanks for reviewing.
Agree with you regarding confirmation of existence etc... As said initially it's a "very basic update".

By the way, the use of pkgopt was motivated by personal needs: use macOSUpgrade.sh to erase the Mac and reinstall macOS. After reinstall, a pkg (passed with pkopt) is in charge to remove the computer record from the Jamf Pro server.
And I don't want the Mac to be removed from Jamf BEFORE it has been restored.

Regards,
Emmanuel

taniguti · 2019-05-24T10:27:39Z

Hi, Emmanuel,

It's interesting.

You mean you want to remove the computer record after erasing and re-installing it, don't you?
I image that the pkg file specified by pkgopt is a payload-free pkg file. It will execute postinstall script.

As you said, you don't want the Mac to be removed from Jamf before it has been restored, you must want to make sure if it has been restored in sucess.
I think it is the easiest way is to make the computer report on it to your Jamf Server.

macOSUpgrade.sh has a postinstall script that runs only once to update the record information after installing the OS.

Instead of distributing a pkg file to delete records, it is recommended to call a policy to do that after restore.
What I have in mind is a policy that runs a script that calls the API to delete its own computer record. Such a policy works the same as a payload-free pkg file.

You can do this by extending the script defined in $ finishOSInstallScriptFilePath like as following.
https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh#L283-L296

--- a/macOSUpgrade.sh
+++ b/macOSUpgrade.sh
@@ -109,6 +109,9 @@ fi
 userDialog="$9"
 if [[ ${userDialog:=0} != 1 ]]; then userDialog=0 ; fi
 
+## Post policy
+policyID="$10"
+
 # Control for auth reboot execution.
 if [ "$versionMajor" -ge 14 ]; then
     # Installer of macOS 10.14 or later set cancel to auth reboot.
@@ -288,6 +291,10 @@ fi
 /bin/sleep 2
 ## Update Device Inventory
 /usr/local/jamf/bin/jamf recon
+## post policy.
+if [ -n "$policyID" ]; then
+    /usr/local/jamf/bin/jamf policy -id "$policyID"
+fi
 ## Remove LaunchAgent and LaunchDaemon
 /bin/rm -f "$osinstallersetupdAgentSettingsFilePath"
 /bin/rm -f "$osinstallersetupdDaemonSettingsFilePath"

I think it takes less time than creating and distributing pkg files. How about that?

Best regards,

takanori

ecanault · 2019-05-24T10:55:45Z

Hi,

Perhaps I'm missing something, but postinstall script / launchd included in macOSUpgrade.sh can't be used in my case !?

After restore:

No more /usr/local/jamfps/finishOSInstall.sh script
No more /Library/LaunchDaemons/com.jamfps.cleanupOSInstall.plist launchd
No more Jamf framework to use jamf policy and jamf recon

Still in work, but have a look here if you want to see how I handle the payload free package with postinstall script: https://github.com/ecanault/scripts/blob/master/s_macOSReinstall_deleteFromJamfPackageMaker

Regards,
Emmanuel

taniguti · 2019-05-24T22:14:36Z

Hi, Emmanuel,

If you delete and reinstall, the jamf binary will also be erased, so you can not use the jamf binary.
I'm so sorry I made you confused. I don't consider these obvious and simple things.

The jamf binary has disappeared, and nothing can be done from the Jamf Pro Server without initializing the system.So there seems to be only one way to use "pkgopt" like your first idea.

It would be nice if you could add a part to verify that the pkg file to be installed is appropriate.

Best regards,

takanori

taniguti · 2019-05-24T22:44:37Z

macOSUpgrade.sh


-    osinstallLogfile="/var/log/startosinstall.log"


keep $osinstallLogfile

taniguti · 2019-05-24T22:45:00Z

macOSUpgrade.sh

    if [ "$versionMajor" -ge 14 ]; then
-        eval /usr/bin/nohup "\"$OSInstaller/Contents/Resources/startosinstall\"" "$eraseopt" --agreetolicense --nointeraction --pidtosignal "$jamfHelperPID" >> "$osinstallLogfile" &


Use eval for safe.

taniguti · 2019-05-24T22:46:45Z

macOSUpgrade.sh

    else
-        eval /usr/bin/nohup "\"$OSInstaller/Contents/Resources/startosinstall\"" "$eraseopt" --applicationpath "\"$OSInstaller\"" --agreetolicense --nointeraction --pidtosignal "$jamfHelperPID" >> "$osinstallLogfile" &
+        "$OSInstaller/Contents/Resources/startosinstall" $pkgopt $eraseopt --applicationpath "$OSInstaller" --agreetolicense --nointeraction --pidtosignal "$jamfHelperPID" &


--installpackage supports 10.13 or later.

ecanault added 3 commits May 13, 2019 16:08

Update macOSUpgrade.sh

b697b81

Update macOSUpgrade.sh

1d2d001

Update macOSUpgrade.sh

c807b78

kenchan0130 reviewed May 14, 2019

View reviewed changes

taniguti reviewed May 24, 2019

View reviewed changes

This was referenced Jun 25, 2019

automated re-enrollment support with --installpackage #119

Open

Support install package for running startosinstall #122

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add the support for package installation #110

Add the support for package installation #110

ecanault commented May 14, 2019 •

edited

Loading

kenchan0130 May 14, 2019 •

edited

Loading

taniguti May 24, 2019

kenchan0130 May 27, 2019

taniguti May 24, 2019

taniguti May 24, 2019

taniguti May 24, 2019

ecanault commented May 24, 2019

taniguti commented May 24, 2019

ecanault commented May 24, 2019

taniguti commented May 24, 2019

taniguti May 24, 2019

taniguti May 24, 2019

taniguti May 24, 2019

		if [ "$versionMajor" -ge 14 ]; then
		eval /usr/bin/nohup "\"$OSInstaller/Contents/Resources/startosinstall\"" "$eraseopt" --agreetolicense --nointeraction --pidtosignal "$jamfHelperPID" >> "$osinstallLogfile" &

Add the support for package installation #110

Are you sure you want to change the base?

Add the support for package installation #110

Conversation

ecanault commented May 14, 2019 • edited Loading

kenchan0130 May 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ecanault commented May 24, 2019

taniguti commented May 24, 2019

ecanault commented May 24, 2019

taniguti commented May 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ecanault commented May 14, 2019 •

edited

Loading

kenchan0130 May 14, 2019 •

edited

Loading