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

Using environment variables in pkg install scripts
by soubhagya ranjan nayak 11 May '10

11 May '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:received:received:date:message-id :subject:from:to:content-type; bh=bVb9luawuQo89qQjOtyDjGIwxMiYnuBwsFBORZ+Zo4Y=; b=eDSJjDhJqkqJq6d405T0eNHkNyAGP7hpIP8g6qerLn14KNqtvwJ5/rIruJC3RpFA5W rUPIN7NEIVUv4qHKarJCd/iDDrHK3zGHQXpgleyiYhpl7Ocu1s2HMlwrK+scdGk9Jr3B ODDJU7i1/yl8bLBiYf3oLMSxBR35ewEjrsfMU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h+G3psppmQj1mi+2glhAHjQL6Sd0ZCForL+WYrRIUEoMnXcRCmqqD034pn5F1rSN11 P7EKovMErjmDXFJQmQs2N5sYsG/p68FJKIk9YzWmqVdGCZEeunEBdnVY92JQ+sY4187F aqjLJAPZMajuOnZ1gJGwW8HtNPwd/xPVpgikE= _______________________________________________ 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: Environment variable availability within post-install script
by Bill Coderre 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On May 10, 2010, at 1:49 PM, Tim Streater wrote: > On 10 May 2010 at 19:30, Bill Coderre <bc(a)apple.com> wrote: > >> Very important points. Here are some vague suggestions on how to cope: >> 1) Get rid of per-user things. >> >> Obvious, but: Don't have your installer create per-user preference files! Put >> "Shared" content in /Users/Shared/ or /Library/Applications Support/YourApp/ >> >> This should take care of most things for App developers. (Yes, this is >> different than Windows. Sorry, but you're going to have to cope with it.) > > Hmmm, my original question appears to have generated more responses than I expected, so I can see I'm going to have to bore people with an outline of what I'm up to. > > I retired a couple of years ago, and as an exercise have been recreating the features of Eudora that I happen to like. There's a couple of Eudora-replacement exercises going on but each is taking some time to come to fruition. Meanwhile, I thought I'd see whether it was possible to use Safari with some JavaScript to present an email client to the user, communicating via AJAX to a number of PHP scripts that talk to mail hosts and store data using SQLite. Where I'm at now is that it largely has the feature set I was planning for it. And we know there's anyway a desperate shortage of email clients for OS X (irony). > > At present my .webloc contains this URL: > > http://localhost/~tim/myApp/myApp.phtml?user=tim&datarootpath=/Users/ti… > > which indicates where the JavaScript/PHP is stored and also where the user's data wants to reside. The PHP scripts run as user _www (I couldn't figure out if it's possible to have Apache run them as user tim - but that's OT for here anyway) so there'll be some permissions problems I haven't resolved yet. But this is basically why I arrived at needing the user's shortname and home directory path in a per-user file created by the installer. In your case, you can probably stick to the "each user must run the installer if they want my app" plan for a while. Eventually, you probably should bundle up all your resources and make an "application" out of it. _______________________________________________ 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: Re: Environment variable availability within post-install script
by Tim Streater 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 10 May 2010 at 19:30, Bill Coderre <bc(a)apple.com> wrote: > Very important points. Here are some vague suggestions on how to cope: > 1) Get rid of per-user things. > > Obvious, but: Don't have your installer create per-user preference files! Put > "Shared" content in /Users/Shared/ or /Library/Applications Support/YourApp/ > > This should take care of most things for App developers. (Yes, this is > different than Windows. Sorry, but you're going to have to cope with it.) Hmmm, my original question appears to have generated more responses than I expected, so I can see I'm going to have to bore people with an outline of what I'm up to. I retired a couple of years ago, and as an exercise have been recreating the features of Eudora that I happen to like. There's a couple of Eudora-replacement exercises going on but each is taking some time to come to fruition. Meanwhile, I thought I'd see whether it was possible to use Safari with some JavaScript to present an email client to the user, communicating via AJAX to a number of PHP scripts that talk to mail hosts and store data using SQLite. Where I'm at now is that it largely has the feature set I was planning for it. And we know there's anyway a desperate shortage of email clients for OS X (irony). At present my .webloc contains this URL: http://localhost/~tim/myApp/myApp.phtml?user=tim&datarootpath=/Users/ti… which indicates where the JavaScript/PHP is stored and also where the user's data wants to reside. The PHP scripts run as user _www (I couldn't figure out if it's possible to have Apache run them as user tim - but that's OT for here anyway) so there'll be some permissions problems I haven't resolved yet. But this is basically why I arrived at needing the user's shortname and home directory path in a per-user file created by the installer. Cheers, _______________________________________________ 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: Environment variable availability within post-install script
by Greg Neagle 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On May 10, 2010, at 11:30 AM, Bill Coderre <bc(a)apple.com> wrote: > 2) To find all the users on this machine, /usr/bin/dscl is your friend. > > Go type man dscl. > > dscl . list /users > > (As stated, this doesn't cover users created after installation.) Nor does it find network users or external users. And if any of these users have FileVault-protected home directories and are not currently logged in, you will not be able to write to their home directories. -Greg _______________________________________________ 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: Environment variable availability within post-install script
by Bill Coderre 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On May 10, 2010, at 10:22 AM, Greg Neagle wrote: > Again, I urge installer writers to consider other scenarios that make this sort of thing problematic. > > Consider a company or school where the primary users do not have administrative rights: > > 1) An admin physically visits each machine, logs in with his/her admin account, and runs the installer. Your user-specific stuff is installed in the home for the admin account. The admin logs out and the primary user logs back in. How do they get your user-specific stuff? > > 2) The organization has remote deployment software that installs your software while no-one is logged in, or in the root context using /usr/sbin/installer. Assuming your scripts don't barf in this scenario, when a user later logs in, how do they get your user specific stuff? > > 3) The primary user leaves the company and a new user takes over the position and the machine, getting a new user account in the process. How do they get your user-specific stuff? > > There may be multiple users for a given machine - even in a home environment. How does a user other than the one that manually ran your installer get the user-specific stuff? > > Don't think you can just search for additional user folders under /Users and molest those as you install -- that won't cover new users added after the install; current users not-logged in whose home directories are protected with FileVault, or network users. > > If there are resources that must be copied to each user's home directory, consider using a LaunchAgent installed in /Library/LaunchAgents that checks for these resources and copies them from a cache at login. Or modify the application to do this upon launch. This way you cover all possible user account scenarios. This pushes the responsibility from the installer-writer to the software developer, which is where it belongs. (Of course if you have both roles, this makes little difference...) Very important points. Here are some vague suggestions on how to cope: 1) Get rid of per-user things. Obvious, but: Don't have your installer create per-user preference files! Put "Shared" content in /Users/Shared/ or /Library/Applications Support/YourApp/ This should take care of most things for App developers. (Yes, this is different than Windows. Sorry, but you're going to have to cope with it.) Extreme case: Some people make "restore CDs" that completely populate users. They MIGHT need to research "User Templates" which create stuff when a new user is created. In almost all cases, you don't need to do this, and should not. 2) To find all the users on this machine, /usr/bin/dscl is your friend. Go type man dscl. dscl . list /users (As stated, this doesn't cover users created after installation.) _______________________________________________ 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: Re: Environment variable availability within post-install script
by Tim Streater 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 10 May 2010 at 18:22, Greg Neagle <Greg.Neagle(a)disneyanimation.com> wrote: > Again, I urge installer writers to consider other scenarios that make this > sort of thing problematic. Greg, I take the points you're making and appreciate the issues you've raised. However, in my own situation, I should perhaps point out that this is an entirely new area for me. Until about a couple of weeks ago I'd not even heard of PackageMaker (although obviously I knew some sort of program like that must exist). I was just bumbling along thinking that when development of my app reached a certain point, I'd check out how I could install it. Well that certain point has arrived, so I'm diving into what for me are entirely new waters. > Consider a company or school where the primary users do not have > administrative rights: > > 1) An admin physically visits each machine, logs in with his/her admin > account, and runs the installer. Your user-specific stuff is installed in the > home for the admin account. The admin logs out and the primary user logs back > in. How do they get your user-specific stuff? Seems to me that if Smith is installing it as admin on behalf of Jones, then Smith has to signal this to the installer. Now, how does this usually work? I've only ever installed stuff for myself (or for "all users"). I'm not sure I've come across an installer that asks who you're installing the s/w for. At my present level of ignorance, I don't know how to put up a panel asking the person staring at the screen whether they're installing for (a) all users (b) a specific user - enter shortname, or (c) themself. And more particularly, how to save that information and make it available to a script later in the install process. > 2) The organization has remote deployment software that installs your software > while no-one is logged in, or in the root context using /usr/sbin/installer. > Assuming your scripts don't barf in this scenario, when a user later logs in, > how do they get your user specific stuff? > > 3) The primary user leaves the company and a new user takes over the position > and the machine, getting a new user account in the process. How do they get > your user-specific stuff? > > There may be multiple users for a given machine - even in a home environment. > How does a user other than the one that manually ran your installer get the > user-specific stuff? > > Don't think you can just search for additional user folders under /Users and > molest those as you install -- that won't cover new users added after the > install; current users not-logged in whose home directories are protected with > FileVault, or network users. > > If there are resources that must be copied to each user's home directory, > consider using a LaunchAgent installed in /Library/LaunchAgents that checks > for these resources and copies them from a cache at login. These are all scenarios I've not considered yet - first I'll be glad to get working a simple setup where the user logs in as themself and double-clicks the .pkg. > Or modify the application to do this upon launch. What I'm giving them is a .webloc file, which is what they'd need to launch the app. > This way you cover all possible user account scenarios. This pushes the > responsibility from the installer-writer to the software developer, which is > where it belongs. Well, I agree with this (to the extent possible). Thanks for your detailed list. Tim Streater _______________________________________________ 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: Environment variable availability within post-install script
by Greg Neagle 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Again, I urge installer writers to consider other scenarios that make this sort of thing problematic. Consider a company or school where the primary users do not have administrative rights: 1) An admin physically visits each machine, logs in with his/her admin account, and runs the installer. Your user-specific stuff is installed in the home for the admin account. The admin logs out and the primary user logs back in. How do they get your user-specific stuff? 2) The organization has remote deployment software that installs your software while no-one is logged in, or in the root context using /usr/sbin/installer. Assuming your scripts don't barf in this scenario, when a user later logs in, how do they get your user specific stuff? 3) The primary user leaves the company and a new user takes over the position and the machine, getting a new user account in the process. How do they get your user-specific stuff? There may be multiple users for a given machine - even in a home environment. How does a user other than the one that manually ran your installer get the user-specific stuff? Don't think you can just search for additional user folders under /Users and molest those as you install -- that won't cover new users added after the install; current users not-logged in whose home directories are protected with FileVault, or network users. If there are resources that must be copied to each user's home directory, consider using a LaunchAgent installed in /Library/LaunchAgents that checks for these resources and copies them from a cache at login. Or modify the application to do this upon launch. This way you cover all possible user account scenarios. This pushes the responsibility from the installer-writer to the software developer, which is where it belongs. (Of course if you have both roles, this makes little difference...) -Greg On May 10, 2010, at 9:56 AM, Tim Streater wrote: > On 10 May 2010 at 16:19, Christian Lindemer <lchristian(a)apple.com> wrote: > >> Wouldn't it be better to use $HOME instead of the user name? THis works >> if the user folder is in a non-standard location, e.g. a network home >> folder or a home on a secondary volume. > > Thanks, that's a useful improvement. > > _______________________________________________ > 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/greg.neagle%40disneyan… > > This email sent to greg.neagle(a)disneyanimation.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: Re: Environment variable availability within post-install script
by Tim Streater 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 10 May 2010 at 16:19, Christian Lindemer <lchristian(a)apple.com> wrote: > Wouldn't it be better to use $HOME instead of the user name? THis works > if the user folder is in a non-standard location, e.g. a network home > folder or a home on a secondary volume. Thanks, that's a useful improvement. _______________________________________________ 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: Environment variable availability within post-install script
by Christian Lindemer 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.15 Wouldn't it be better to use $HOME instead of the user name? THis works if the user folder is in a non-standard location, e.g. a network home folder or a home on a secondary volume. -Christian On Sun, May 9, 2010 5:14 pm, Iceberg-Dev wrote: > > On May 9, 2010, at 8:10 PM, Tim Streater wrote: > >> My post-install script (written in PHP) must write a file on the >> user's desktop, and so needs the user's shortname in order to >> construct the path. The script also modifies the apache config file >> and so needs admin priv. I appear to be able to give it that by >> ticking "Require admin authentication". >> >> In my PHP, I appear to be able to do: >> >> $user = getenv ("USER"); _______________________________________________ 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: RECEIPT_PATH in postflight giving incorrect path in 10.6
by Greg Neagle 10 May '10

10 May '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Since the resource are not copied on 10.6, just detect that you are running under 10.6 and do nothing in that case. -Greg On May 10, 2010, at 8:01 AM, Sachin Porwal wrote: > Hi, > > I am using an unflat 10.4 package for creating an deployment pkg. I need to place some custom resource and binary file in the Resources folder of that pkg. The binary & custom resources are supposed to be used in preinstall/preupgrade scripts. I found that in Mac OS 10.5, the resources are copied to RECEIPT_PATH (environment variable available to postflight script) but in 10.6, only .bom & info.plist are retained. > > The custom binary & resources are a bit heavy on space required. I would like to remove these custom components from '/Library/Receipts/' so that they do not consume unnecessary space on client system. I tried using RECEIPT_PATH in postflight and removing the custom components. I found that on 10.6 RECEIPT_PATH contains the path of the actual pkg location, so if i try to remove the custom components, it will corrupt the original installer pkg. > > Could somebody please help me identify the correct solution for this? > > Thanks, > Sachin > > > _______________________________________________ > 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/greg.neagle%40disneyan… > > This email sent to greg.neagle(a)disneyanimation.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