December 2011 - Installer-dev

RE: Launch a System Agent from an Installer script
by Xochitl Lunde 13 Dec '11

13 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AQHMt8glBhV90hwj/E2yqU9CamkOxpXWjkgAgAA+JICAAyFUHw== Thread-topic: Launch a System Agent from an Installer script I believe I handle these issues in the PowerAlertSA installer for Mac. Maybe I didn't do everything or anything perfectly, but I do address all of the cases that you are talking about. PowerAlert has a system daemon and a user agent, as well as a Java UI, so I think the installation scripts in PowerAlert could help you out: http://www.tripplite.com/en/products/poweralert-software.cfm As far as I know, you should be able to right click on the package inside the DMG and choose "Show Package Contents". Then inside of Contents/Resources you can see how I coded the InstallationCheck script as well as the preinstall, postinstall, etc. (Open with -> Xcode.app) I believe you can look at any package like this and compare similar software installation scripts to what you are doing if the scripts are not compiled. Basically, I don't let the product install if more than one user is logged in. Then I handle stopping the agent and daemons before upgrading. I tested these scripts a lot using Leopard and Snow Leopard, including using ARD with no users logged in. I have tested the installer on Lion, but not with ARD. (On Lion it errors sort of uninformatively if Java is not installed but otherwise the installation is fine. ._. ) Another thing you have to handle is the command line install. If the user has to authenticate, then he will be installing your package using sudo on the command line - and you only get the SUDO_USER environment variable in one of the early scripts (InstallationCheck?). These scripts should handle that as well. You can use 'su' to change users so that you can start your user agent as that user. If you look at the PowerAlert scripts, the agent which is the user agent is called PowerAlertUserNotify, so you'll want to look at its behavior the most. The '|| :' at the end of the 'su' lines is a trick from this list to make 'su' not hang. You'll see that I had to do quite a bit of extra work to figure out what user to start the agent for. One thing that can really help you determine what is going on during debugging is to have your scripts write their environment variables and any other info to a file (not for release of course). You can then open the file and see what the heck environment variables you are really getting when doing ARD installs, command line installs, GUI installs, etc. I was surprised to see what a variety of environment variables my scripts would get during 1 install. Hope this helps. X. ________________________________________ From: installer-dev-bounces+xochitl_lunde=tripplite.com(a)lists.apple.com [installer-dev-bounces+xochitl_lunde=tripplite.com(a)lists.apple.com] on behalf of Colin Cornaby [colin.cornaby(a)mac.com] Sent: Sunday, December 11, 2011 4:00 AM To: Installer-Dev mailing-list Subject: Re: Launch a System Agent from an Installer script Be careful here, because you can make the sort of mistakes that drove me insane when I worked in IT and had to use these installers. Keep in mind that if the application is installed via remote desktop no user at all is logged in, and I may have pushed the installer to the machine as an entirely different user that could even be a network account. Sent from my iPhone On Dec 10, 2011, at 10:18 PM, Eli Bach2 <ebach2(a)gmail.com> wrote: > > On Dec 10, 2011, at 10:45 PM, Nick wrote: > >> The systems are Snow Leopard and Lion, it also would be great if I >> could do that on Leopard. > > What do you expect to happen if: > > -more than one user is logged in > -nobody is logged in > -your agent is already running in any/all user contexts > > Eli > > _______________________________________________ > 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/colin.cornaby%40mac.com > > This email sent to colin.cornaby(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: http://lists.apple.com/mailman/options/installer-dev/xochitl_lunde%40trippl… This email sent to xochitl_lunde(a)tripplite.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

1 0

Re: Lion permissions problem in /Library/Application Support
by Howard Moon 13 Dec '11

13 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Dec 13, 2011, at 8:15 AM, Per Olofsson wrote: > 13 dec 2011 kl. 16:49 skrev Howard Moon: > >> Hi all, >> >> we've got AudioUnit plug-ins that write files that need to be accessible by all users, and have always put them in /Library/Application Support/Antares/..., but in Lion, our plug-ins are not able to write under Application Support unless the user first changes the permissions to allow Admin to have Read/Write access to that folder. >> >> Is there a way our Iceberg-based installers can modify the permissions on that folder? Or, is there a new location under Lion for all-user application files? (And if so, how would our plug-ins know they were running under Lion and be able to access the "correct" location?) > > > I've always thought that /Users/Shared is the correct location for shared user files (as the name implies :). It's writeable by all, but the sticky bit is set so users can only rename or delete their own files. > > -- One would think that /Users/Shared might be the place, but this is from Apple's "File System Programming Guide: File System Basics" document: > The Library directory is where applications and other code modules store their custom data files. Regardless of whether you are writing code for iOS or Mac OS X, understanding the structure of the Library directory is important. You use this directory to store data files, caches, resources, preferences, and even user data in some specific situations. > ... > /Library (Mac OS X only)—Applications that share resources between users store those resources in this version of the Librarydirectory. > ... > Application Support: > Use this directory to store all application data files except those associated with the user’s documents. For example, you might use this directory to store application-created data files, configuration files, templates, or other fixed or modifiable resources that are managed by the application. An application might use this directory to store a modifiable copy of resources contained initially in the application’s bundle. A game might use this directory to store new levels purchased by the user and downloaded from a server. > All content in this directory should be placed in a custom subdirectory whose name is that of your application’s bundle identifier or your company. Since these files we're writing are data files, not documents that the user can edit (at least in the normal sense), we've always stored the files there ever since the introduction of OS X. It has always worked perfectly until Lion. Changing to another location such as /Users/Shared would make things very difficult for users who update their systems and have the files currently under /Library/Application Support/Antares. But if our app can't *create* the Antares folder, then we've got a support problem! Thanks, Howard _______________________________________________ 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: Lion permissions problem in /Library/Application Support
by Per Olofsson 13 Dec '11

13 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AQHMua7Jgx+dqviB+UudEbKWuqOtIJXZ4MEA Thread-topic: Lion permissions problem in /Library/Application Support 13 dec 2011 kl. 16:49 skrev Howard Moon: > Hi all, > > we've got AudioUnit plug-ins that write files that need to be accessible by all users, and have always put them in /Library/Application Support/Antares/..., but in Lion, our plug-ins are not able to write under Application Support unless the user first changes the permissions to allow Admin to have Read/Write access to that folder. > > Is there a way our Iceberg-based installers can modify the permissions on that folder? Or, is there a new location under Lion for all-user application files? (And if so, how would our plug-ins know they were running under Lion and be able to access the "correct" location?) I've always thought that /Users/Shared is the correct location for shared user files (as the name implies :). It's writeable by all, but the sticky bit is set so users can only rename or delete their own files. -- Per Olofsson System Administrator, IT-services, 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Lion permissions problem in /Library/Application Support
by Howard Moon 13 Dec '11

13 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hi all, we've got AudioUnit plug-ins that write files that need to be accessible by all users, and have always put them in /Library/Application Support/Antares/..., but in Lion, our plug-ins are not able to write under Application Support unless the user first changes the permissions to allow Admin to have Read/Write access to that folder. Is there a way our Iceberg-based installers can modify the permissions on that folder? Or, is there a new location under Lion for all-user application files? (And if so, how would our plug-ins know they were running under Lion and be able to access the "correct" location?) Thanks, Howard _______________________________________________ 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: Launch a System Agent from an Installer script
by Colin Cornaby 11 Dec '11

11 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Be careful here, because you can make the sort of mistakes that drove me insane when I worked in IT and had to use these installers. Keep in mind that if the application is installed via remote desktop no user at all is logged in, and I may have pushed the installer to the machine as an entirely different user that could even be a network account. Sent from my iPhone On Dec 10, 2011, at 10:18 PM, Eli Bach2 <ebach2(a)gmail.com> wrote: > > On Dec 10, 2011, at 10:45 PM, Nick wrote: > >> The systems are Snow Leopard and Lion, it also would be great if I >> could do that on Leopard. > > What do you expect to happen if: > > -more than one user is logged in > -nobody is logged in > -your agent is already running in any/all user contexts > > Eli > > _______________________________________________ > 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/colin.cornaby%40mac.com > > This email sent to colin.cornaby(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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Launch a System Agent from an Installer script
by Bill Coderre 11 Dec '11

11 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Dec 10, 2011, at 10:18 PM, Eli Bach2 wrote: > On Dec 10, 2011, at 10:45 PM, Nick wrote: >> The systems are Snow Leopard and Lion, it also would be great if I >> could do that on Leopard. > > What do you expect to happen if: > > -more than one user is logged in > -nobody is logged in > -your agent is already running in any/all user contexts Nick, pay attention to what Eli says. It's important. Also, the installer stuffs the short user name of the user that double-clicked your installer in the environment variable USER. So you can do something like su $USER -c "launchctl <whatever" But, what if you want to do it for all users on the system? The pretty-good solution is to walk through /Users and find all the real users, and do the above for each. The better solution is to do the above, AND also deal with $USER. (Because the logged-in user might have a network home directory). ANOTHER solution is to ask dscl (dscl . list /users) -- but most of the users on that list are not the kind that sit at the console. None of these handles the case of users created after the installation runs. Yeah, it's not as easy as it sounds. Best of luck, and don't go creating daemons that eat all my computer up. bc _______________________________________________ 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: Launch a System Agent from an Installer script
by Eli Bach2 11 Dec '11

11 Dec '11

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=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=6VAUDw2z5NmcGlhjn3zfCrnA+r9kC8TfWAhv731uRM4=; b=gJcgY79DRStHeccij0ng/qb6Pz6CFQB0v66s1T4DpirhqV6bdhnmZvuy0W5SQyfC4Z yx4Ro2gFn/k13BTPHpur1FtSDtRgz9kZJvtC3GZVvu7VAw9ZvxVfLb/G2SLyTku+Hvb5 lp29REk9fD10TFz2TLP8GGgSXgDlsa6vDV6bQ= On Dec 10, 2011, at 10:45 PM, Nick wrote: > The systems are Snow Leopard and Lion, it also would be great if I > could do that on Leopard. What do you expect to happen if: -more than one user is logged in -nobody is logged in -your agent is already running in any/all user contexts Eli _______________________________________________ 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

Launch a System Agent from an Installer script
by Nick 11 Dec '11

11 Dec '11

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=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Owxp9EqHybR9HMrj8Q0avYAdA1RPDJzNeDDCHIVPdnU=; b=XmSzi4HT4lnM/Ej412Kj9drbM4abz1XYH6hFW/0eYT0Rj/3MYH3zt31V40VzeS9nu8 B8kKRpd0w/M2M9Ck8FwlTZif9UgsNX5k3Y39wlbUnLnSJVue4e3e3kU2tA8qQETnsH50 Icph4PspUC36I1L9SLC2dX76Dd6Or3CF6g4u4= Hello I am writing a background application, that has to be installed first using Installer (created using PackageMaker or Packages) and then the installer should launch the agent for the first time. The application is a user mode agent, that just shows its icon in Status Bar. The problem is I can't launch this agent in the right "context". Installer's PostInstall script is executed with the root privileges, and if i execute there "launchctl /Library/LaunchAgents/com.nick.mycoolapp.plist", i get the agent started in the "root context", not in the current user's context.. Some applications (like Dropbox) install an icon there (i am not sure if dropbox is an agent, however it autostarts when the system starts and places its icon on the Status Bar). Can I somehow get the right context, and execute the script on behalf of the currently logged in user? Is there any way to "lower" privileges? The systems are Snow Leopard and Lion, it also would be great if I could do that on Leopard. Thank you! P.s. where should one send questions related to launchd? It seems that launchd-dev mailing list has been dropped. _______________________________________________ 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: package javascript reference?
by Bill Coderre 07 Dec '11

07 Dec '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Installer JavaScript Reference is back. For some reason, I cannot find it using the search -- I'll see if anyone can fix that. In the mean time, it's at this location: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Refere… It is also at this location: http://tinyurl.com/installerjavascriptreference Note: At some point, the tinyurl will break, and cannot easily be fixed. Please also bear in mind: 1) The document is not very useful if you are shipping apps in the Mac App Store. 2) The document could use an update. I'll keep plugging away at it in the next few months. On Dec 2, 2011, at 9:57 PM, Bill Coderre wrote: > I'm not understanding what it is that you want to test and report an error about, that you can't do it in the distribution, and must do it in the preflight. > > If you give me more information about what specifically you want to test, I'll try to suggest an answer. > > As for the missing JavaScript document, I'll look into why it went missing. > > > On Dec 2, 2011, at 7:11 AM, Andy O'Meara wrote: >> Hey Stephane, long time! :) As always, you're a kind and generous help here on installer-dev. >> >> With some google sleuthing, I found a host copy of the now-removed javascript installer docs: >> >> http://www.filibeto.org/unix/macos/lib/dev/documentation/DeveloperTools/Ref… >> >> As you said, it lists to message method of any kind, which is really quite sad since a message/confirm dialog box isn't a security issue. Around once a year the OS X installer subsystem always seems to want to push me to an early, frustration-induced grave ugh. So basically the only way to display an installer message is to authenticate and then run a shell script -- sigh. >> >> A workaround is to insert my checks in preflight, but I can't get the returned preflight error code to cause the appropriate string error message to appear (instead the generic default message always appears: "The installer encountered an error that caused the installation to fail…"). Anyone know if there's a way to get your own message in there? >> >> Thanks, >> Andy >> >> >> >> On Dec 2, 2011, at 3:44 AM, Stephane Sudre wrote: >> >>> The complete answer: >>> >>> The Installer JavaScript Reference guide has been removed from the ADC >>> web site many months ago. There's no reason why (maybe someone was >>> absolutely hating it). >>> >>> Anyway, it's possible to find it in previous old Xcode distributions >>> and you can not display a message box with the APIs. You need to use >>> an external tool to do this. >>> >>> On Fri, Dec 2, 2011 at 6:10 AM, Andy O'Meara >>> <andrew.omeara(a)soundspectrum.com> wrote: >>>> >>>> Hey gents, >>>> >>>> I've been trying to get docs on the full list of javascript commands available from inside a package .dist file despite my best googling efforts. I'm trying to display a message box with an ok and cancel button, so if anyone has any leads it would be very appreciated. Perhaps there's a good link that goes into an available command reference? >>>> >>>> Thanks in advance, >>>> Andy _______________________________________________ >>>> 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/dev.iceberg%40gmail.com >>>> >>>> This email sent to dev.iceberg(a)gmail.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/bc%40apple.com >> >> This email sent to bc(a)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/bc%40apple.com > > This email sent to bc(a)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

1 0

Re: package javascript reference?
by Stephane Sudre 05 Dec '11

05 Dec '11

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=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mjQCudHMCJ64P/04UPLF/tfCg7K57PHFejGkOFdwNNk=; b=Rx2NsEobvq5K2wvQDWPGthDOgqfpM7uoFg3yyGQvuOHSnep1/ro3sWQZEc270of5hk TWO3Xpii6v35+gLHOrF8cRY467ErMSkv/kwTA3Zde0n/0MWH8qOENyPimFDb/vCnZv7c 99K9GMwafym8rmfhLYD16abBpVI5AhwGL6yN0= On Sun, Dec 4, 2011 at 7:55 PM, Andy O'Meara <andrew.omeara(a)soundspectrum.com> wrote: > > On Dec 2, 2011, at 11:57 PM, Bill Coderre wrote: > >> I'm not understanding what it is that you want to test and report an error about, that you can't do it in the distribution, and must do it in the preflight. > > > > It's first worth mentioning how we've decided to do things now that we're using a .dist-style pkg (where InstallationCheck is now ignored). The short version is that we've moved what was in InstallationCheck to preflight. An obstacle has been that none(!) of the OSes have a mechanism that translates the returned error code into a string that the installer displays (such as how InstallationCheck did business). This to me, is a VERY simple, risk-free enhancement that would add a LOT of value to the OS X installer subsystem and makes no sense that it's not there. I mean, really. As it stands, the preflight has no way to communicate with the user unless it puts up its own message box. Anyway, so we made a C-style command line util that prints out the pid and bundle identifier for each running process. This allows our installation check to look for certain bundle identifiers and tell the user installation can't proceed by simply searching though the printed buffer. Some pseudocode: > > loop: > textBuf = `$1/blah/install_util PrintRunningProcesses` > if textBuf contains 'com.company.foo': > result = `$1/blah/showmsg_util "dammit, quit foo or cancel"` > if result == 'cancel': > exit 1234 > else: > break > loopend > > Of course system.applications.fromIdentifier() could replace the above but in practice it can be cumbersome/annoying for the user to have to exit the installer, remember what application to quit (our customers are whitebelt users), and then rerun the installer. It's ideal to use a 'confirm' type message window (ie. an OK and Cancel button saying to quit the following and press OK or cancel installation) in a loop with calls to system.applications.fromIdentifier(). As it stands now, it can only be checked once so the user can get only the message and then have to restart the installer. I get though that the reason Apple didn't want this is for the command line invocation be airtight. So the next best solution would be to allow a new message type other than Fatal (such as 'FatalOrRetry'), which would put a 'Retry' or similarly titled button in the message window that the installer shows. Pressing it would cause the installation check function to be reexecuted, effectively allowing a loop to occur but be within the package installer's control. If in command line mode, FatalOrRetry would simply internally map to Fatal. This seems to be a solution that make a lot of sense, make a lot of people happy, and preserve full safety/termination guarantees of command line execution. It would allow a package that installs everything into the user's dir that needs to do the above not need to have admin permission. Thoughts? Think I should file a radar? I would guess the issue is related to the state of the choices not being refreshed as often as you would expect them to. I filed a bug report sometimes ago about the state not being refreshed when you click Go Back from this pane and then click Continue. It's always a good idea to file a bug report (even though it can take quite a long time to get a bug fixed in the system - for instance the one with the Restart… button of the Startup Disk Pref Pane that has been there since at least 2002). > While we're talking about this stuff, is there a undocumented way to tell the PackageMaker UI to not overwrite my.result.title and my.result.message when it generates it top level javascript install check function? As it is now, if you have a javascript set my.result.title and my.result.message, they get wiped out because the packagemaker's make process always takes what was put in the UI edit fields and overwrites them in its installation check wrapper javascript proc. We make our pkg/dist by command line, so if we did start using javascript, we'd have too script the editing of the .dist file to remove the lines that overwrite the title and message. It's safer to write your own InstallationCheck JavaScript script and not rely on PackageMaker as it would anyway produce non optimized code like this: a = true & b; _______________________________________________ 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