March 2010 - Installer-dev - lists.apple.com

Re: Struggles with PackageMaker and Iceberg scripts
by Karl Kuehn 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Mar 16, 2010, at 12:45 PM, Iceberg-Dev wrote: >> I would be curious to get the Installer.app team's thoughts here; I would think that all the scripts would be getting executed the same way...It kind of makes sense that InstallationCheck is different, but at the same time I'm curious as to the Why. > > IIRC, it's not the installer process that is installing files on Snow Leopard. > > It is a launchd daemon (/System/Library/PrivateFrameworks/PackageKit.framework/Resources/installd). This does not seem to be exactly the right description. I have been working a lot with this recently to try and work around badly written packages[1] for InstaDMG. A major trick for me in 10.5 was to wrap the installer process in a chroot jail, and that worked perfectly for the actual files that were installed, but did not work at all for things like Distribution Scripts (broke most of the iLife updaters for us). Recently I added a trick where I load a modified launchd plist in place of the one that operates the installd process, one that is chrooted into my target environment, and this works perfectly for Distribution Scripts (anything that uses the JavaScript environment). Note that this latest trick does not actually do anything for prefilight/postflight scripts (anything that is not JavaScript) as these are run by the installer process (so don't bounce though launchd). I have filed bugs requesting ways around this, but in most cases the problems can actually be laid at the feet of the installer writer (use the "Target" rather than "System" methods and you should be better off, and use $3 when writing scripts). So I don't know if I am going to get any traction on this. And the folks writing the iLife Updater installers don't seem to care about my outstanding bugs (not even enough to just close them as "won't fix"). -- Karl Kuehn larkost(a)softhome.net [1] At least badly written from the perspective of not installing on volumes other than the boot drive. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Iceberg-Dev 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:in-reply-to :references:content-type:message-id:content-transfer-encoding:from :subject:date:to:x-mailer; bh=8LTZgVZ3cMSBWVb+NsvJKEKuMVPHGuARHeEXBl5CJW4=; b=krWsX+JJSlsBHNUkrHjS3hmJ7y60HdBbfz2vlgzn0iHQL1ch6pt66bxLxIBYyQTKQs sYvkrvbCbWpCc5YIEBQMTTUa/YmkSujT09pTC6D86UFxx5cs/k7aNChHdcRVY0HoRONO w1yxKn2+h4BwHFGBb2yDPANh5rN5WpM0yfnAw= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:content-type:message-id :content-transfer-encoding:from:subject:date:to:x-mailer; b=uBio4gEONfyIaL050NfotKhAs1n2S/dBlZL06ud2JHV27wyDCgfqbeylvbA4sqsh5D ddn3D9+TPj7WLeQRuEYmdobOK8iOjUYcuBrAWTUbgz2uiglRlUkPArUDR6/+DIkYQ/RK 0tQF8JSPE22pnxEpfTjr3+hdHXbkuDzvWxcO4= On Mar 16, 2010, at 8:21 PM, Nick Peelman wrote: I would be curious to get the Installer.app team's thoughts here; I would think that all the scripts would be getting executed the same way...It kind of makes sense that InstallationCheck is different, but at the same time I'm curious as to the Why. _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… IIRC, it's not the installer process that is installing files on Snow Leopard. It is a launchd daemon (/System/Library/PrivateFrameworks/ PackageKit.framework/Resources/installd). This email sent to site_archiver(a)lists.apple.com

1 0

ruby glitch in 10.5 and 10.6
by Karl Kuehn 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com In the InstaDMG project we just figured out a glitch in the way Ruby is installed on MacOS X, one that is probably only going to surface for installer devs working on InstaDMG/SystemImageUtility compatible packages. I thought that it might be a good idea to get it on record here: The problem is that the path referenced from the soft link: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/site_ruby namely: ../../../../../../../../../../Library/Ruby/Site is incorrect. It has 10 back-references, but there are only 9 items in its path. This is not normally a problem when you are booted to that volume because the extra back-reference is silently swallowed. But in the case of InstaDMG this winds up putting the path into out protective outer folder (outside the image), and that winds up causing the installer to think a folder does not exits, so it makes one (which later causes problems when booted). This problem exists on all versions of 10.5 and 10.6 to date, but does not seem to exist on 10.4. So if you are making a package involving installing something to /usr/lib/ruby/site_ruby, you might want to target /Library/Ruby/Site directly. I filed a bug on this one, but do not expect that this will ever be fixed for 10.5 (even if it is fixed for 10.6). -- Karl Kuehn larkost(a)softhome.net _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Nick Peelman 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=z2na50V6xH3fLguylZ8VleNQyy6Ow6vrnAAXuGVUyOU=; b=gxADku7/i+Dvl/QDbTaR1Tzub6RBIrkwCfuVT4iBBOxtzaw1pio6hTRMkNslwnQH4r V0WtT4Ppgn4P5b9ROo3KbfxDFiNoQ+amz7ggZnVoT4gEwZSnc7ISjPn1AbxVuX9rANjw JjhW109nlY1O7yFBkLzEofsE5CcjgWg7qhYoE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=aJ4X2zprGhmXgefjfcU5tfF/sYhUtrKvTvBiqNQzN6PnHGZ+mjfA6JctGyXKL1mh/D Cpk03LL9CIV7r5c8ZKG9OI+GH9jtLUXWA6dRCC22r7pTm1Y4dSWdguU+zlKRWctPo42O s67d39nSJcs/wFUIzgc8nT51qWxbsLC9/Bwao= I would be curious to get the Installer.app team's thoughts here; I would think that all the scripts would be getting executed the same way...It kind of makes sense that InstallationCheck is different, but at the same time I'm curious as to the Why. I would avoid tinkering with the HOME path, that could get messy :) Are you still checking for multiple users in your pre/post install scripts? -nick -- Nick Peelman nick(a)peelman.us On Tue, Mar 16, 2010 at 2:29 PM, Xochitl Lunde <Xochitl_Lunde(a)tripplite.com> wrote: > On Tue, Mar 16, 2010 at 11:32 AM, Xochitl Lunde > <Xochitl_Lunde(a)tripplite.com> wrote: > If I use 'sudo' to run the installer on the >> command line, the $USER parameter is set to 'root' instead. Because my >> script checks for users logged in who are not $USER, I get the error. > > Yeah, that's what I get for opening my mouth/keyboard without testing > first. When sudo is invoked, it sets several variables as well, > including $SUDO_USER which should contain the username of the user who > invoked it. You may have to do an else if in your bash to handle > that. > > XO: I just tried this out, and it only works in the InstallationCheck > script. I think it's pretty interesting, so I made all my scripts print out > their environment. Only the InstallationCheck script gets the SUDO_USER > variable, have a look! Do you think this is a bug? I wrote some kind of > weird stuff to guess the name of the user from the HOME path, but I haven't > decided yet if that's a bad idea. > > xochitl-lundes-imac:installcomponents xlunde$ sudo installer -verbose > -dumplog -pkg sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target > /Volumes/SNOWLEOPARD > > ----INSTALLATIONCHECK---- > SHELL=/bin/bash > TERM=xterm-color > USER=root > COMMAND_MODE=legacy > SUDO_USER=xlunde > SUDO_UID=501 > SCRIPT_NAME=InstallationCheck > SSH_AUTH_SOCK=/tmp/launch-KwW0dY/Listeners > __CF_USER_TEXT_ENCODING=0x0:0:0 > USERNAME=root > PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin > PWD=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents > LANG=en_US.UTF-8 > PACKAGE_PATH=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents/sda/iceberg/build/PowerAlertSA-12.04.0050.pkg > SHLVL=1 > SUDO_COMMAND=/usr/sbin/installer -verbose -dumplog -pkg > sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target /Volumes/SNOWLEOPARD > HOME=/Users/xlunde > LOGNAME=root > COMMAND_LINE_INSTALL=1 > SUDO_GID=20 > DISPLAY=/tmp/launch-abhWeL/:0 > _=/usr/bin/env > ------------------------- > installer[3604]: ./preupgrade: -------PREINSTALL-------- > installer[3604]: ./preupgrade: > INSTALLER_TEMP=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./preupgrade: DSTVOLUME=/ > installer[3604]: ./preupgrade: > TMPDIR=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./preupgrade: DSTROOT=/ > installer[3604]: ./preupgrade: DYLD_NO_FIX_PREBINDING=YES > installer[3604]: ./preupgrade: USER=root > installer[3604]: ./preupgrade: SCRIPT_NAME=preupgrade > installer[3604]: ./preupgrade: > __PARENT_INSTALL_SANDBOX=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp > installer[3604]: ./preupgrade: > SHARED_INSTALLER_TEMP=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-shared-tmp > installer[3604]: ./preupgrade: > INSTALLER_SECURE_TEMP=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp/Secure_Temp.1364844149 > installer[3604]: ./preupgrade: > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec > installer[3604]: ./preupgrade: > RECEIPT_PATH=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents/sda/iceberg/build/PowerAlertSA-12.04.0050.pkg/Contents/Resources > installer[3604]: ./preupgrade: PWD=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./preupgrade: > INSTALL_PKG_SESSION_ID=com.tripplite.poweralert.PowerAlertEngineSA.pkg > installer[3604]: ./preupgrade: LANG=en_US.UTF-8 > installer[3604]: ./preupgrade: > PACKAGE_PATH=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents/sda/iceberg/build/PowerAlertSA-12.04.0050.pkg > installer[3604]: ./preupgrade: SHLVL=1 > installer[3604]: ./preupgrade: HOME=/Users/xlunde > installer[3604]: ./preupgrade: COMMAND_LINE_INSTALL=1 > installer[3604]: ./preupgrade: _=/usr/bin/env > installer[3604]: ./preupgrade: ------------------------- > installer[3604]: ./postupgrade: -----POSTINSTALL---- > installer[3604]: ./postupgrade: > INSTALLER_TEMP=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./postupgrade: DSTVOLUME=/ > installer[3604]: ./postupgrade: > TMPDIR=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./postupgrade: DSTROOT=/ > installer[3604]: ./postupgrade: DYLD_NO_FIX_PREBINDING=YES > installer[3604]: ./postupgrade: USER=root > installer[3604]: ./postupgrade: SCRIPT_NAME=postupgrade > installer[3604]: ./postupgrade: > __PARENT_INSTALL_SANDBOX=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp > installer[3604]: ./postupgrade: > SHARED_INSTALLER_TEMP=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-shared-tmp > installer[3604]: ./postupgrade: > INSTALLER_SECURE_TEMP=/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp/Secure_Temp.2131041415 > installer[3604]: ./postupgrade: > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec > installer[3604]: ./postupgrade: > RECEIPT_PATH=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents/sda/iceberg/build/PowerAlertSA-12.04.0050.pkg/Contents/Resources > installer[3604]: ./postupgrade: PWD=/private/tmp/PKInstallSandbox.4vAbAd/tmp > installer[3604]: ./postupgrade: > INSTALL_PKG_SESSION_ID=com.tripplite.poweralert.PowerAlertEngineSA.pkg > installer[3604]: ./postupgrade: LANG=en_US.UTF-8 > installer[3604]: ./postupgrade: > PACKAGE_PATH=/Users/xlunde/code/proj/pa49x64/engine/leopard/installcomponents/sda/iceberg/build/PowerAlertSA-12.04.0050.pkg > installer[3604]: ./postupgrade: SHLVL=1 > installer[3604]: ./postupgrade: HOME=/Users/xlunde > installer[3604]: ./postupgrade: COMMAND_LINE_INSTALL=1 > installer[3604]: ./postupgrade: _=/usr/bin/env > installer[3604]: ./postupgrade: -------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Mar 16, 2010 at 11:32 AM, Xochitl Lunde > <Xochitl_Lunde(a)tripplite.com> wrote: >> XO: I do install the plist in /Library/LaunchAgents. The reason that I >> care >> is that if either of our programs is running when the installer runs, I >> have >> to stop the program before installing again. This doesn't work nicely if >> other users are logged in because I can't stop the agent for them also. > > Admittedly, this is an edge case, how many users would be using Fast > User Switching to have a second console user, but its still a case > that should be handled. > >> XO: It doesn't give me an extra user. What happens is that when the >> Installer GUI is used to install the package, the $USER environment >> variable >> is set as my user, 'xlunde'. If I use 'sudo' to run the installer on the >> command line, the $USER parameter is set to 'root' instead. Because my >> script checks for users logged in who are not $USER, I get the error. >> >> My post install scripts also try to start the launch agent for the $USER, >> so >> this might work weird or not at all if 'root' is the $USER. > > Yeah, that's what I get for opening my mouth/keyboard without testing > first. When sudo is invoked, it sets several variables as well, > including $SUDO_USER which should contain the username of the user who > invoked it. You may have to do an else if in your bash to handle > that. > > >> XO: I don't have ARD that I know of, and it doesn't look like it's free. >> This software is going to an external testing house later, so they'll have >> to test that. : / > > I could run a few test cases for you with ARD, if you wanted. Ping me > offlist. > > -nick > > > > > > _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Xochitl Lunde 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Importance: Sensitivity: _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Nick Peelman 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=O5gXeCaMeg1PKPVM7kdk8RJjge16yEml2R00T62/Yr0=; b=x/+2ROLLsyeFGxX1b3NcdCVw6i3zIkxZNZI17dd1EBdoDEEqrKcSn/Mb78IjGh3N+Q J/1txZhEYyikLvlYzJBDABX6glbErfOY1U7XI7PFznZBblRWeBvxK/XVJXFHWmKdlXIc bG5xWWbJQxlTIHCHXrjsyPYC3jzWPg+nrjKXI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AnO5BKnWeq7XVihC8iIhQt6uErl+4fxzbuxw5Ri5/DCfSq7oKcsIwn8YTt2KXLHcF4 EU9UzaZ/qoN23vtPbZFBfsJF1Hw6Xr68AFKQvXCeSlO91iGdvcuCGFZT6rjPmnUShfRF WE4eKqGjS+5qyJpsoEKbODXpqkilgQNNftyOA= On Tue, Mar 16, 2010 at 11:32 AM, Xochitl Lunde <Xochitl_Lunde(a)tripplite.com> wrote: > XO: I do install the plist in /Library/LaunchAgents. The reason that I care > is that if either of our programs is running when the installer runs, I have > to stop the program before installing again. This doesn't work nicely if > other users are logged in because I can't stop the agent for them also. Admittedly, this is an edge case, how many users would be using Fast User Switching to have a second console user, but its still a case that should be handled. > XO: It doesn't give me an extra user. What happens is that when the > Installer GUI is used to install the package, the $USER environment variable > is set as my user, 'xlunde'. If I use 'sudo' to run the installer on the > command line, the $USER parameter is set to 'root' instead. Because my > script checks for users logged in who are not $USER, I get the error. > > My post install scripts also try to start the launch agent for the $USER, so > this might work weird or not at all if 'root' is the $USER. Yeah, that's what I get for opening my mouth/keyboard without testing first. When sudo is invoked, it sets several variables as well, including $SUDO_USER which should contain the username of the user who invoked it. You may have to do an else if in your bash to handle that. > XO: I don't have ARD that I know of, and it doesn't look like it's free. > This software is going to an external testing house later, so they'll have > to test that. : / I could run a few test cases for you with ARD, if you wanted. Ping me offlist. -nick _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Xochitl Lunde 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com > Why aren't you just installing the launchd agent in /Library/ > LaunchAgents ? > This way you don't have to know or care who is currently logged in, > and it will work for all users (current and future) of the machine. XO: I do install the plist in /Library/LaunchAgents. The reason that I care is that if either of our programs is running when the installer runs, I have to stop the program before installing again. This doesn't work nicely if other users are logged in because I can't stop the agent for them also. > sudo shouldn't give you a second user via a "who" command. But a > Terminal window (or multiple terminal windows) will: > XO: It doesn't give me an extra user. What happens is that when the Installer GUI is used to install the package, the $USER environment variable is set as my user, 'xlunde'. If I use 'sudo' to run the installer on the command line, the $USER parameter is set to 'root' instead. Because my script checks for users logged in who are not $USER, I get the error. My post install scripts also try to start the launch agent for the $USER, so this might work weird or not at all if 'root' is the $USER. > When you run it from a command line what your script is seeing is the > console session and the tty session. When run via ARD, if no users > are logged in, that script should run fine (but I still suggest > testing it). XO: I don't have ARD that I know of, and it doesn't look like it's free. This software is going to an external testing house later, so they'll have to test that. : / > > Short of building an array based on the awk $1 of the who command, my > only other suggest would be to grep for "console" between your who and > your awk, ie: > > who | grep console | awk ' { print $1 } '. > > -nick > > -- > Nick Peelman > nick(a)peelman.us > > > > On Mon, Mar 15, 2010 at 5:37 PM, Xochitl Lunde > <Xochitl_Lunde(a)tripplite.com> wrote: > > Thanks to some of the earlier discussions here, I have a package which I > > feel works fantastically with my launchd items. Unfortunately, it now does > > not work for me on the command line, oops! > > > > xochitl-lundes-imac:installcomponents xlunde$ installer -pkg > > sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target /Volumes/SNOWLEOPARD > > Java Update version is '1'. > > installer: This package requires authentication to install. > > > > xochitl-lundes-imac:installcomponents xlunde$ sudo installer -pkg > > sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target /Volumes/SNOWLEOPARD > > xlunde is logged in! > > installer: Error - Too many users are logged in. PowerAlert cannot be > > installed correctly for all users when multiple users are logged in. > > > > ----------------------- > > Obviously, I did this to myself. > > > > for name in `who | awk {'print $1'}` > > do > > if [ ! $name = $USER ] ; then > > echo "${name} is logged in!" > > exit 112; > > fi > > done

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Nick Peelman 16 Mar '10

16 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=UbKlsxYsKMdGrfAuS9KRnHu4JkA+YXRsF0Dvjy/2Eqo=; b=DN2daiIFogtuuMKl7oS2TrXyy+jrsWWbFLEMKdJX9S3g9RYoxGsl7IWLSkeLoTP/XW uSsvEB9tsHdx87TpJ6fZ5I6sczW+JMTqWVDru2GUzNI7bdVpJLqgEJtT2GJ3WaiJYhpi vnD4bGtzzcObfqFIBTN3PP0kMQ+4UlbxD7OcY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=doFBDItQz3AUQUyjtGBipMWp1mUeWoOhbHYj5Q90zx8X/+KEJtUhiNZtMK0GU1HHsB 3oyrEEfRdCyIn/MhO7tLtAVP58RFkPlDxKS/BdE5gpe596ADtd/JSL87rIGvPzs/HoX+ MKcpoNjp/tiDIERuzbvuHBAtA9L+taEPfbhac= sudo shouldn't give you a second user via a "who" command. But a Terminal window (or multiple terminal windows) will: megrez:~ npeelman$ who npeelman console Mar 15 09:06 npeelman ttys000 Mar 16 10:40 megrez:~ npeelman$ sudo who Password: npeelman console Mar 15 09:06 npeelman ttys000 Mar 16 10:40 When you run it from a command line what your script is seeing is the console session and the tty session. When run via ARD, if no users are logged in, that script should run fine (but I still suggest testing it). Short of building an array based on the awk $1 of the who command, my only other suggest would be to grep for "console" between your who and your awk, ie: who | grep console | awk ' { print $1 } '. -nick -- Nick Peelman nick(a)peelman.us On Mon, Mar 15, 2010 at 5:37 PM, Xochitl Lunde <Xochitl_Lunde(a)tripplite.com> wrote: > Thanks to some of the earlier discussions here, I have a package which I > feel works fantastically with my launchd items. Unfortunately, it now does > not work for me on the command line, oops! > > xochitl-lundes-imac:installcomponents xlunde$ installer -pkg > sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target /Volumes/SNOWLEOPARD > Java Update version is '1'. > installer: This package requires authentication to install. > > xochitl-lundes-imac:installcomponents xlunde$ sudo installer -pkg > sda/iceberg/build/PowerAlertSA-12.04.0050.pkg -target /Volumes/SNOWLEOPARD > xlunde is logged in! > installer: Error - Too many users are logged in. PowerAlert cannot be > installed correctly for all users when multiple users are logged in. > > ----------------------- > Obviously, I did this to myself. > > for name in `who | awk {'print $1'}` > do > if [ ! $name = $USER ] ; then > echo "${name} is logged in!" > exit 112; > fi > done > > The multi-user check was based on some earlier discussion. Now when I run > the installer on the command line using 'sudo', I get a different $USER in > my environment. I know this will mess up my launchd agent later on in my > preinstall and postinstall. > > I'm a little stumped on what direction to think about this. A command line > install is required to not annoy the cheezeburgers out of anyone who > administrates multiple computers, right? Are we supposed to use 'sudo' for > packages that require admin privileges or is there a different way to do > this? Is it the right thing to go through my scripts add an 'if $USER == > root' for everything? > > Xo > > _______________________________________________ > 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: > http://lists.apple.com/mailman/options/installer-dev/nick%40peelman.us > > This email sent to nick(a)peelman.us > _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Struggles with PackageMaker and Iceberg scripts
by Xochitl Lunde 15 Mar '10

15 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Importance: Sensitivity: _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Build metapackages from the command line with PackageMaker 3
by Jeremy Reichman 15 Mar '10

15 Mar '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:subject:from:to:message-id:in-reply-to:mime-version:content-type:content-transfer-encoding; s=smtpout; bh=A0iRI3t6pKZw3eUAAqqb8BnOu/M=; b=Mt8a+/XzGCOud5/kCCK620hYLqCnuAMBdjRgqtz1oM8UotAe5kenUPZnYnxDDBQdKxctpzhpXtSjPexfFrJYzL4fm/UlygeUY88yWR16N4EoB8YIlmCyaNT+C6wDsSTXFZT7Vy3YQHaFqM3sXsNpQ7JtLbjmso0dpNYkV6f1tDk= Thread-index: AcrEWdIhPgz1W5wgIkGWh656dFToQA== Thread-topic: Build metapackages from the command line with PackageMaker 3 User-agent: Microsoft-Entourage/13.3.0.091002 > Actually I had a pmdoc that I tried to use on the command line and it still > gave me an error. I wasn't able to get it to build on the command line even > with the pmdoc. Maybe I didn't get the parameters quite right, but there > aren't that many parameters when building from a pmdoc. I think I've tried building a metapackage from the command line with a .pmdoc, and couldn't get that to work, either. However, the likely culprits are the third-party packages I'm trying to include in the metapackage -- they are old-style .mpkg bundles with .info and .list files. They lack Info.plist and other modern niceties. I also had problems trying to import these two architecture-specific installer packages into Iceberg. One almost imported, but I had added an Info.plist of my own creation into the bundle as an experiment. So, the only metapackages I've been able to build successfully from the command line under Snow Leopard are the same -- they have bypassed PackageMaker 3 entirely. These work swimmingly, but I wouldn't be surprised if pkgutil throws fits later. -- Jeremy _______________________________________________ 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0