June 2013 - Installer-dev - lists.apple.com

Re: Newbie Packages Questions
by Conor Schutzman 26 Jun '13

26 Jun '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Newbie Packages Questions
by Edward Spiegel 26 Jun '13

26 Jun '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Verify productsign on flat packages
by Khushneet Inder Singh 21 Jun '13

21 Jun '13

Hi, Is there any way to get/extract certificate from the Flat package so that it can be accessed via openssl x509 on 10.7.5 and later MacOSX. My intent is to validate the digital signing of flat package on USER's machine. I know the pkgutil--check-signature and spctl commands. But I want something more reliable as I want to validate programmatically the SHA fingerprint of package. Open to any ideas to validate the productsign on all 10.7.5 and later MacOSX Thanks and regards, Khushneet -----Original Message----- From: installer-dev-bounces+ksingh=quark.com(a)lists.apple.com [mailto:installer-dev-bounces+ksingh=quark.com@lists.apple.com] On Behalf Of Khushneet Inder Singh Sent: Monday, October 29, 2012 12:34 PM To: Stephane Sudre; installer-dev(a)lists.apple.com Subject: RE: Verify productsign on flat packages Hi Stephane, The --extract-certs option somehow doesn't work. xar said unrecognized option `--extract-certs` and the manual of xar doesn't have any extract-certs option :( ... NOTE: xar version is 1.6dev But --dump-toc works well :), I just want to know that the following info is about the "MY Apple Developer ID Installer certificates" ? "<X509Data> <X509Certificate>CERT1<\X509Certificate> <X509Certificate>CERT2<\X509Certificate> <\X509Data>" And is this info is different for different Apple Developer ID certificates ? I signed two different payload with same developer ID, then I check the diff of both xml header info. There is no diff between the signature info part of header file. That's why I am assuming the above xml info has one-to-one relation with certificate used to sign the package. I don't have any other certificate to counter check this which makes it sure. Thanks, Khushneet -----Original Message----- From: installer-dev-bounces+ksingh=quark.com(a)lists.apple.com [mailto:installer-dev-bounces+ksingh=quark.com@lists.apple.com] On Behalf Of Stephane Sudre Sent: Friday, October 26, 2012 12:52 PM To: installer-dev(a)lists.apple.com Subject: Re: Verify productsign on flat packages On Fri, Oct 26, 2012 at 7:15 AM, Khushneet Inder Singh <ksingh(a)quark.com> wrote: > Hi, > > Thanks for reply, but the "--check-signature" option in pkgutil was > introduced later in 10.7(Lion). So for me the problem remains the same > , I am still unable to verify signature on snow leopard and leopard. Considering that a flat package/distribution is a xar archive, a solution could be to: 1. extract the certificates from the archive either using --dump-toc and some XML parsing or using a fork of the xar project: http://mackyle.github.com/xar/howtosign.html 2. use 'openssl x509' to retrieve the information you need. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/ksingh%40quark.com This email sent to ksingh(a)quark.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/ksingh%40quark.com This email sent to ksingh(a)quark.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rebuilding kext caches
by Philip Petev 17 Jun '13

17 Jun '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rebuilding kext caches
by Andrew Keller 16 Jun '13

16 Jun '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Rebuilding kext caches
by Philip Petev 16 Jun '13

16 Jun '13

_______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: preinstall/preupgrade scripts: The revenge
by Per Olofsson 10 Jun '13

10 Jun '13

6 jun 2013 kl. 07:28 skrev Paul Cook <cook.p.d(a)comcast.net>: > Great info, but don't those sample tests & scripts only work if you are installing on the boot drive? Yes, afaict. Untested, but try: foundPackage=$(/usr/sbin/pkgutil --volume "$3" --pkgs="$INSTALL_PKG_SESSION_ID") As always, don't forget to use $3 in your package scripts lest the wrath of sysadmins come upon you. -- Per Olofsson, IT-service, University of Gothenburg _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tell why it failed
by Conor Schutzman 06 Jun '13

06 Jun '13

That was kind of my point, but perhaps I could have been more clear. Instead of exit codes, instead build your if-thens to include different log messages based on on success or failure, than your log becomes a history of not only what failed, but when. If you don't want further commands to be process downstream in any failure condition, then just include exit lines in the if-then so that any unwanted state results in the script halting. On Jun 6, 2013, at 10:11 AM, Bill Coderre <bc(a)apple.com> wrote: > No, that failure message cannot be changed. > > Apple's installer, officially, does not support returning anything other than "0" in a preflight or postflight script. If your product installer is chained together with a bunch of other installers, returning non-zero causes all the downstream installers to be skipped. > > Suggestion: have your app do "first run setup" and have a full GUI in place to help. This will also cover the case that the user has been naughty and drag-installed. If you wish, you can have your postflight do some variant on launching the app. > > > > > On Jun 6, 2013, at 10:01 AM, Conor Schutzman <conor(a)mac.com> wrote: >> You have pretty limited control over that UI. In fact, I don't even know if any of the GUI tools (Packages, PackageMaker, Casper Composer, etc.) even let you customize the failure message, let alone offer different screens for different failures. >> >> Therefore, your script has to do all of the heavy lifting. There are two main ways to log what your script is doing, you can either redirect std out and std err messages into a text file somewhere, or you can use logger to write directly to the syslog (and thus viewable in Console.app). You can even go one step further, and write a function to use echo to write log messages to a file, this is what I do. >> >> Here is a a little quick and dirty uninstall script for VMware that demonstrates both building a function for echo, and redirecting std out to a log file. >> >> >> #!/usr/bin/env bash >> >> ## HEADER >> SoftwareTitle=VMware >> LogFolder="$3/Library/Logs/Packages" >> LogFile="$LogFolder/Uninstall.log" >> TimeStamp=`date "+%a %b%e %Y %T"` >> writeLog(){ >> LogMessage=$1 >> echo "[$TimeStamp] [$SoftwareTitle]: $LogMessage" >> "$LogFile" >> } >> >> ## LOGGING >> if [[ ! -d $LogFolder ]]; then >> mkdir -p $LogFolder >> chown root:wheel $LogFolder >> chmod 775 $LogFolder >> fi >> if [[ ! -w $LogFile ]]; then >> touch -f $LogFile >> chown root:wheel $LogFile >> chmod 775 $LogFile >> fi >> echo "====================" >> "$LogFile" >> >> ## QUITTING APP >> writeLog "Quitting application." >> osascript -e 'tell application "VMware Fusion" to quit' >> >> ## APPLICATION >> AppName="VMware Fusion" >> if [[ -e "$3/Applications/$AppName.app" ]]; then >> rm -Rdv "$3/Applications/$AppName.app" >> $LogFile >> fi >> if [[ -e "$3/Users/$USER/Applications/$AppName.app" ]]; then >> rm -Rdv "$3/Users/$USER/Applications/$AppName.app" >> $LogFile >> fi >> if [[ -e "$3/Library/Preferences/$AppName" ]]; then >> rm -Rdv "$3/Library/Preferences/$AppName" >> $LogFile >> fi >> >> ## RECEIPT >> ReceiptList=$(pkgutil --packages | grep vmware) >> for EachReceipt in ${ReceiptList[@]}; do >> pkgutil --forget $EachReceipt >> $LogFile >> done >> >> ## FOOTER >> echo "====================" >> "$LogFile" >> exit 0 >> >> >> On Jun 6, 2013, at 9:27 AM, Scott Grosch <scott.grosch(a)gmail.com> wrote: >> >>> My installer depends heavily on a postinstall script to do most of the work. The "install" part of the package just copies some data in, but then in postinstall I turn on Postgres, create the user/db, configure a bunch of files, etc…. >>> >>> There are many ways it can fail though, and right now I just do an "exit 1" and then the installer says the installation failed. >>> >>> How do I provide the user with a message as to exactly *why* it failed? For example, I'd like to be able to say, "Unable to connect to Postgres" so that they know to go check their configuration, for example. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tell why it failed
by Bill Coderre 06 Jun '13

06 Jun '13

No, that failure message cannot be changed. Apple's installer, officially, does not support returning anything other than "0" in a preflight or postflight script. If your product installer is chained together with a bunch of other installers, returning non-zero causes all the downstream installers to be skipped. Suggestion: have your app do "first run setup" and have a full GUI in place to help. This will also cover the case that the user has been naughty and drag-installed. If you wish, you can have your postflight do some variant on launching the app. On Jun 6, 2013, at 10:01 AM, Conor Schutzman <conor(a)mac.com> wrote: > You have pretty limited control over that UI. In fact, I don't even know if any of the GUI tools (Packages, PackageMaker, Casper Composer, etc.) even let you customize the failure message, let alone offer different screens for different failures. > > Therefore, your script has to do all of the heavy lifting. There are two main ways to log what your script is doing, you can either redirect std out and std err messages into a text file somewhere, or you can use logger to write directly to the syslog (and thus viewable in Console.app). You can even go one step further, and write a function to use echo to write log messages to a file, this is what I do. > > Here is a a little quick and dirty uninstall script for VMware that demonstrates both building a function for echo, and redirecting std out to a log file. > > > #!/usr/bin/env bash > > ## HEADER > SoftwareTitle=VMware > LogFolder="$3/Library/Logs/Packages" > LogFile="$LogFolder/Uninstall.log" > TimeStamp=`date "+%a %b%e %Y %T"` > writeLog(){ > LogMessage=$1 > echo "[$TimeStamp] [$SoftwareTitle]: $LogMessage" >> "$LogFile" > } > > ## LOGGING > if [[ ! -d $LogFolder ]]; then > mkdir -p $LogFolder > chown root:wheel $LogFolder > chmod 775 $LogFolder > fi > if [[ ! -w $LogFile ]]; then > touch -f $LogFile > chown root:wheel $LogFile > chmod 775 $LogFile > fi > echo "====================" >> "$LogFile" > > ## QUITTING APP > writeLog "Quitting application." > osascript -e 'tell application "VMware Fusion" to quit' > > ## APPLICATION > AppName="VMware Fusion" > if [[ -e "$3/Applications/$AppName.app" ]]; then > rm -Rdv "$3/Applications/$AppName.app" >> $LogFile > fi > if [[ -e "$3/Users/$USER/Applications/$AppName.app" ]]; then > rm -Rdv "$3/Users/$USER/Applications/$AppName.app" >> $LogFile > fi > if [[ -e "$3/Library/Preferences/$AppName" ]]; then > rm -Rdv "$3/Library/Preferences/$AppName" >> $LogFile > fi > > ## RECEIPT > ReceiptList=$(pkgutil --packages | grep vmware) > for EachReceipt in ${ReceiptList[@]}; do > pkgutil --forget $EachReceipt >> $LogFile > done > > ## FOOTER > echo "====================" >> "$LogFile" > exit 0 > > > On Jun 6, 2013, at 9:27 AM, Scott Grosch <scott.grosch(a)gmail.com> wrote: > >> My installer depends heavily on a postinstall script to do most of the work. The "install" part of the package just copies some data in, but then in postinstall I turn on Postgres, create the user/db, configure a bunch of files, etc…. >> >> There are many ways it can fail though, and right now I just do an "exit 1" and then the installer says the installation failed. >> >> How do I provide the user with a message as to exactly *why* it failed? For example, I'd like to be able to say, "Unable to connect to Postgres" so that they know to go check their configuration, for example. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Tell why it failed
by Conor Schutzman 06 Jun '13

06 Jun '13

You have pretty limited control over that UI. In fact, I don't even know if any of the GUI tools (Packages, PackageMaker, Casper Composer, etc.) even let you customize the failure message, let alone offer different screens for different failures. Therefore, your script has to do all of the heavy lifting. There are two main ways to log what your script is doing, you can either redirect std out and std err messages into a text file somewhere, or you can use logger to write directly to the syslog (and thus viewable in Console.app). You can even go one step further, and write a function to use echo to write log messages to a file, this is what I do. Here is a a little quick and dirty uninstall script for VMware that demonstrates both building a function for echo, and redirecting std out to a log file. #!/usr/bin/env bash ## HEADER SoftwareTitle=VMware LogFolder="$3/Library/Logs/Packages" LogFile="$LogFolder/Uninstall.log" TimeStamp=`date "+%a %b%e %Y %T"` writeLog(){ LogMessage=$1 echo "[$TimeStamp] [$SoftwareTitle]: $LogMessage" >> "$LogFile" } ## LOGGING if [[ ! -d $LogFolder ]]; then mkdir -p $LogFolder chown root:wheel $LogFolder chmod 775 $LogFolder fi if [[ ! -w $LogFile ]]; then touch -f $LogFile chown root:wheel $LogFile chmod 775 $LogFile fi echo "====================" >> "$LogFile" ## QUITTING APP writeLog "Quitting application." osascript -e 'tell application "VMware Fusion" to quit' ## APPLICATION AppName="VMware Fusion" if [[ -e "$3/Applications/$AppName.app" ]]; then rm -Rdv "$3/Applications/$AppName.app" >> $LogFile fi if [[ -e "$3/Users/$USER/Applications/$AppName.app" ]]; then rm -Rdv "$3/Users/$USER/Applications/$AppName.app" >> $LogFile fi if [[ -e "$3/Library/Preferences/$AppName" ]]; then rm -Rdv "$3/Library/Preferences/$AppName" >> $LogFile fi ## RECEIPT ReceiptList=$(pkgutil --packages | grep vmware) for EachReceipt in ${ReceiptList[@]}; do pkgutil --forget $EachReceipt >> $LogFile done ## FOOTER echo "====================" >> "$LogFile" exit 0 On Jun 6, 2013, at 9:27 AM, Scott Grosch <scott.grosch(a)gmail.com> wrote: > My installer depends heavily on a postinstall script to do most of the work. The "install" part of the package just copies some data in, but then in postinstall I turn on Postgres, create the user/db, configure a bunch of files, etc…. > > There are many ways it can fail though, and right now I just do an "exit 1" and then the installer says the installation failed. > > How do I provide the user with a message as to exactly *why* it failed? For example, I'd like to be able to say, "Unable to connect to Postgres" so that they know to go check their configuration, for example. > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/installer-dev/conor%40mac.com > > This email sent to conor(a)mac.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0