Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the support for package installation #110

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

ecanault
Copy link

@ecanault ecanault commented May 14, 2019

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

@@ -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}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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)

  1. Get the trigger name of a policy in the argument from the user with jamf script argument.
  2. Create a pkg which runs jamf policy-event <the trigger name>.
  3. 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

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

/bin/mkdir -p /usr/local/jamfps
/bin/mkdir /usr/local/jamfps
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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."
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM to description strings changes.

@@ -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}"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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


osinstallLogfile="/var/log/startosinstall.log"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keep $osinstallLogfile

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use eval for safe.

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" &
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--installpackage supports 10.13 or later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants