August 2010 - Installer-dev

Re: How to create flat packages?
by Per Olofsson 18 Aug '10

18 Aug '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AQHLPnjEA+Om+ck/v0yOyFIGAzY2EJLmsX0A Thread-topic: How to create flat packages? 18 aug 2010 kl. 03.54 skrev Chris Wolf: > I am wondering - what command line options I need to pass to packagemaker to > create such a single-file package? packagemaker --target 1.5 >From the man page: "Specifies the minimum target operating system version. Defaults to 10.3. For 10.5, flat packages packages and metapackages will be built;" -- 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: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

How to create flat packages?
by Chris Wolf 18 Aug '10

18 Aug '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:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=fL+HelEnFDVT9o98Q5xmt0FMs/ySTM4ngGPJUqE2f90=; b=kW9AePqpslG/UkXcThP4u/a4qk1/lK3k4Mb9HhRF7DCUO1gYcQO5Lne8wDuPUpHytS uLvqpCZI9tuct97E6R0FYWuxAxLEtOBQcWj4XhebK7ff5BXK0oH+unFHyCQPMNvGSddN ISvSYB7so+YPfh1Gmd1Bo+6elgoHSXn/JX3Z0= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=qgckrjfBs4WvHTtBk9sKjw4zN+XPpLU+DaEjVXKC0lEMFewUpL7PoTlvsSv/RI2Qnk WKSBgEvfoa/9830MJMXdXOoy7vTHHi2y5VR5RygElD+JMeWXEFHufWq/0jgBtStqyVrB IcWtT01br0iDRc2sWeFNLkEoqAZNj9A1sO1Ow= User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 I notice that most packages, i.e. *.pkg are usually composed of a directory hierarchy, i.e. mypackage.pkg/Contents/MacOs, etc. ...and after these are installed, there is a similar copy placed in the /Library/Receipts directory. Recently, I installed a package (still with *.pkg extension) but it was a single file - not a directory hierarchy. After it was installed, instead of en entry in /Library/Receipts, there was an entry in /Library/Receipts/boms. I am wondering - what command line options I need to pass to packagemaker to create such a single-file package? The only things I could find by searching are the following, but nothing specifically on *how* to do it with packagemaker: http://lists.apple.com/archives/installer-dev/2008/Dec/msg00091.html http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… Thanks, Chris Wolf _______________________________________________ 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: Permissions checks when installing a daemon
by Monte Benaresh 17 Aug '10

17 Aug '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thanks very much, Bill. And thanks to Stephane for your input, as well. One thing I should mention is that I have found that the installer option to "Overwrite Directory Permissions" did not work when I tested it (we are using Iceberg 1.2.9 on 10.6.2, but I don't know where the bug lies), so we are resorting to fixing these issues in the preflight script for the daemon install. Bill, you bring up interesting issues around the idea of fixing the "/" directory owner, so now we have a dilemma that I will escalate to my manager. The thing is, it's an awful bad story when a problem like "/" having the wrong owner causes our whole install to fail, and the user doesn't know why (unless he knows to look at the log, where we emit useful information), and fixing permissions in DU won't help. We could put some instructions in our ReadMe to type some commands in Terminal... BTW, one of my contacts working on Disk Management will probably file the bug (Bill, you know who). We currently have decided to fix permissions anywhere in the path /Library/PrivilegedHelperTools/, and we would only touch the owner:group if owner is not "root," i.e., we don't check the group. My script currently sets ownership to root:wheel if the owner is not "root." Since we want to do this right, and we are running out of time, we are considering opening a DTS support incident. I appreciate everyone's contributions, but almost all of them have come with the caveat that "this is not a definitive answer." Thank you all, again. If we ask DTS, I will post their advice to the list. Monte On Aug 17, 2010, at 2:18 PM, Bill Coderre wrote: > > On Aug 13, 2010, at 5:37 PM, Monte Benaresh wrote: >> One of our installers installs a daemon to /Library/PrivilegedHelperTools/. I have written a bash script to enforce the security recommendations in TN2083, which says that this directory, and all of its parents, must have certain permissions and must be owned by "root" in order to prevent an unauthorized process from substituting their own daemon in place of ours. >> >> Our problem is, one of our Beta users has "/" owned by "_spotlight", and so we fail to >> install due to the security checks in our preflight script as alluded to above. Disk Utility does not repair this problem. > > Hi, Monte. I've been thinking about this off and on, so here's an informed opinion (ie. not an official rule, or even a tech note). > > It is very unusual to have / owned incorrectly. (I don't think I've ever heard of it.) I suggest filing a bug against Disk Utility, since you say it's not fixing it. > > Because this situation is very unusual, I've never seen an installer check for it, or attempt to fix it. Usually, permissions are managed by the file copying machinery used by Installer.app, and packages just allow the default behavior to happen. > >> We are concerned that this will be a support issue, so our questions are: >> >> 1. Can we securely allow "/" to be owned by other than "root"? > I don't know. I'm not a security expert. > >> 2. Is it permissible for us to change the owner of "/" to "root"? > Although I might be tempted to let myself be convinced to have your installer just fix the problem since it's clearcut and simple, I'm of the opinion that it's a bad idea, if only because the name of the app is "Installer" and not "Disk Utility." > > I'm a bit worried about unforeseen consequences, for one, and for another, I don't want people to get an idea that running some third-party installer will fix their problems. We still have people convinced that zapping the PRAM and rebuilding the desktop database is "routine maintenance." > > Third reason not to do anything: I think it's a really rare problem. It might be literally just this one user. And if it's not, I'd rather not have your installer masking a problem. > >> 3. If either /Library/ or Library/PrivilegedHelperTools/ is not owned by "root" is it >> permissible for us to change the owner to "root"? > > In the past, I have fixed permissions to subfolders of /Library, when clients have specific bugs with a clear cause. I would be asking, "So why can't the app fix the permissions itself?" > > I don't think I've changed /Library or /, but I can easily see an OS upgrade doing so. The usual case involves a policy change dictated by security issues. To make up an example, it might be OK to have a folder be root/admin/0775 on 10.5, but have it change to root/wheel/0755 on 10.6. > > > _______________________________________________ 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: Permissions checks when installing a daemon
by Bill Coderre 17 Aug '10

17 Aug '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Aug 13, 2010, at 5:37 PM, Monte Benaresh wrote: > One of our installers installs a daemon to /Library/PrivilegedHelperTools/. I have written a bash script to enforce the security recommendations in TN2083, which says that this directory, and all of its parents, must have certain permissions and must be owned by "root" in order to prevent an unauthorized process from substituting their own daemon in place of ours. > > Our problem is, one of our Beta users has "/" owned by "_spotlight", and so we fail to > install due to the security checks in our preflight script as alluded to above. Disk Utility does not repair this problem. Hi, Monte. I've been thinking about this off and on, so here's an informed opinion (ie. not an official rule, or even a tech note). It is very unusual to have / owned incorrectly. (I don't think I've ever heard of it.) I suggest filing a bug against Disk Utility, since you say it's not fixing it. Because this situation is very unusual, I've never seen an installer check for it, or attempt to fix it. Usually, permissions are managed by the file copying machinery used by Installer.app, and packages just allow the default behavior to happen. > We are concerned that this will be a support issue, so our questions are: > > 1. Can we securely allow "/" to be owned by other than "root"? I don't know. I'm not a security expert. > 2. Is it permissible for us to change the owner of "/" to "root"? Although I might be tempted to let myself be convinced to have your installer just fix the problem since it's clearcut and simple, I'm of the opinion that it's a bad idea, if only because the name of the app is "Installer" and not "Disk Utility." I'm a bit worried about unforeseen consequences, for one, and for another, I don't want people to get an idea that running some third-party installer will fix their problems. We still have people convinced that zapping the PRAM and rebuilding the desktop database is "routine maintenance." Third reason not to do anything: I think it's a really rare problem. It might be literally just this one user. And if it's not, I'd rather not have your installer masking a problem. > 3. If either /Library/ or Library/PrivilegedHelperTools/ is not owned by "root" is it > permissible for us to change the owner to "root"? In the past, I have fixed permissions to subfolders of /Library, when clients have specific bugs with a clear cause. I would be asking, "So why can't the app fix the permissions itself?" I don't think I've changed /Library or /, but I can easily see an OS upgrade doing so. The usual case involves a policy change dictated by security issues. To make up an example, it might be OK to have a folder be root/admin/0775 on 10.5, but have it change to root/wheel/0755 on 10.6. _______________________________________________ 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: Cant replace the executable for auto upgradation when its executing
by Dan Sashko 17 Aug '10

17 Aug '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

1 0

Re: Cant replace the executable for auto upgradation when its executing
by Dan Sashko 17 Aug '10

17 Aug '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

1 0

Re: Re: Could not copy root to split forks
by Adam Mercer 17 Aug '10

17 Aug '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:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=osqfkhKhWRxo3Yz64UTMr+I9jNY0u1gcmAOIWi7EGAQ=; b=fJC8HHb4UlcJkALr0d/eKICX4i+Mo6hOC2AFzgCB3dwi8UC2ff2BSndcuol6EYKn6a Brued1rVFdYYoLUF4QeMTraRdJIUoepD25QH1Qe1iDTe8vyw11S4w7QI+rO3VHs5zfhi gkXhMqKnyFo/1P6QHeWR50JdjGRsg9rTUz14U= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Rkv7105xouxA7y4Yq9NoGSTRugd0+OcsD+ymmWps1CsSHW7kkjrEFURf+q1uAeVKAy o20k4ncly4RYJwVc0IIeaUUEvVVDGmHAh2Nxsqz8eOdzN9rx29KpTeeUiH0wZsN+yNoC BTV41dleVva8tnoUeqkvRkW/R/TCDzXaRx2NI= On Tue, Aug 17, 2010 at 15:08, Tim Streater <timstreater(a)waitrose.com> wrote: > Have you tried doing the build again and again? In my experience, this problem is intermittent. I could get the build (eventually) to proceed just by trying it again and again. It failed, I clicked Build. Sometimes it took three or four goes. Other times I had no problem, or it just kept failing until I restarted PackageMaker and tried again. I'm not having the problem at the moment. I've done nothing specific to fix it, that I'm aware of, but I happen to have rejigged my app so it's possible I'm no longer triggering it. I've tried several times and it always fails. If I go back to a previous version then it builds fine so something has changed that is causing this. All I've changed is that a new directory structure has been added to one of the packages, permissions have been set appropriately. It would be nice if PackageMaker gave a more detailed error to why its failing... Cheers Adam _______________________________________________ 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: Cant replace the executable for auto upgradation when its executing
by Bill Coderre 17 Aug '10

17 Aug '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Aug 17, 2010, at 1:31 PM, Bill Cheeseman wrote: > On Aug 17, 2010, at 2:39 PM, Bill Coderre wrote: >> There are two common solutions: >> 1) If it's an application, present an error to the user. This IS the standard behavior, but is not in Installer.app at this time. I know it sounds lame, but it's really the best choice, because the user might have unsaved changes, etc, etc. > > I just got the "Quit Application" preinstall action in PackageMaker 3.0.4 to work (by using the application's bundle identifier; using it's name didn't work, with or without the .app extension). What happens is that, as the installation operation reaches the end, the applications quit (or are killed). So at least PackageMaker can do this much. Are you saying that we shouldn't take advantage of this feature because it's dangerous? It is safe to rely on this action, assuming the application is safe to kill. If you wrote the app in question, you already know. (And if you're wrong, you can fix it quickly.) What I was meaning to say, before, is this: "If you don't feel confident in killing the app, it's AOK to put up an error message instead." _______________________________________________ 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: Cant replace the executable for auto upgradation when its executing
by Bill Cheeseman 17 Aug '10

17 Aug '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:subject:mime-version :content-type:from:x-priority:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZeXeAzrCoc6oeKJ0i0NnBVUt8InGZA3lG0mIqmyaq1g=; b=vJ3CIu1Dkj4Laq8abPuqWRFog/80vuHTcpjk3t2MAcYFJ8H3Atnol/4Vj3FEDG99GR f6Y0wH5qCI8EylZJ79lmoqbT5nOdzBuBSgcqGpah2szpUl3mJgfSnlWhkpmYV/dWaihN 1rW1KGncRSYriROb5oCvoWdpxEDwbNoBdWfHQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=Mx5sX1UGxnDqpRpyfKMvaqJxrYPUZ+71lB+6kr2ggmkwjukxd0FZsOas9ZVcDlGfC4 MM30maXbsNTgmk0FLQaHAuzg8SDfdIjybSBzripBUrlTZJlAwdjAejk8OXNKR3Q4IUSg HsTlgq8ZVO76oV1YooIUtrQ76EXqO4ReUqgac= On Aug 17, 2010, at 2:39 PM, Bill Coderre wrote: > There are two common solutions: > 1) If it's an application, present an error to the user. This IS the standard behavior, but is not in Installer.app at this time. I know it sounds lame, but it's really the best choice, because the user might have unsaved changes, etc, etc. I just got the "Quit Application" preinstall action in PackageMaker 3.0.4 to work (by using the application's bundle identifier; using it's name didn't work, with or without the .app extension). What happens is that, as the installation operation reaches the end, the applications quit (or are killed). So at least PackageMaker can do this much. Are you saying that we shouldn't take advantage of this feature because it's dangerous? -- Bill Cheeseman - bill(a)cheeseman.name _______________________________________________ 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: Could not copy root to split forks
by Tim Streater 17 Aug '10

17 Aug '10

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 17 Aug 2010 at 20:39, Adam Mercer <ramercer(a)gmail.com> wrote: > On Tue, Aug 17, 2010 at 14:31, Cates jr, Christopher <chc004(a)shsu.edu> wrote: >> Try looking in the install.log in the console. ï¿½It should have more details >> that will help pin down where the problem is occuring. > > Theres nothing in install.log, I imagine because the installer is > failing to build and it never gets run hence nothing is logged from > the installer. Have you tried doing the build again and again? In my experience, this problem is intermittent. I could get the build (eventually) to proceed just by trying it again and again. It failed, I clicked Build. Sometimes it took three or four goes. Other times I had no problem, or it just kept failing until I restarted PackageMaker and tried again. I'm not having the problem at the moment. I've done nothing specific to fix it, that I'm aware of, but I happen to have rejigged my app so it's possible I'm no longer triggering it. 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