July 2008 - Installer-dev - lists.apple.com

Re: Odd question relating to preinstall scripts and administrator access
by Cameron Pulsford 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com realUserName=`users | grep -v root` cd /Users/$realUserName/Desktop echo $realUserName > username.txt On Jul 31, 2008, at 5:18 PM, Scott Russell wrote: Ah, forgive me (and thanks for the correction, Stephane), Best wishes, Scott -- Dr. Scott Russell IT Support Engineer/Consultant Arts & Letters Computing, Distributed Support Services, Office of Information Technologies, University of Notre Dame Instructor of Horn, University of Notre Dame and Saint Mary's College Assistant Horn, South Bend Symphony Orchestra 234 Decio Hall 574-631-7021 ScottRussell(a)nd.edu http://www.nd.edu/~srussel2/ On Jul 31, 2008, at 1:54 PM, Cameron Pulsford wrote: I tried modifying my script like this... realUserName=`echo $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.… Yes that is a typo, a very bad one at that too, it should have read unload. Also, this is exclusively for 10.5. Doing an ls -l on a correctly installed file yields "$USER wheel". I did a little more experimenting, I tried this just to see if it is even picking up the right user. and no file ever shows up, however, other parts of the script are getting run. So I am not sure what is going on AT ALL. This is very baffling. It's not the $USER part that's failing, it's the actual running of the line. I suppose if I read the entire message before i replied ... So have you verified who really owns the installed LaunchAgent? Is it possible that it's owned by someone other than ${USER}? Is it possible that if ${USER} doesn't own it that ${USER} can't unload it? Grasping as I try to help ... (I assume that the typo "unlead" is only for our benefit and that's not in your live code.) So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/ LaunchAgents" and then the installer fails. Just to test I made a new package that just did some bogus stuff that didn't need administrator access, and I had it run the same prelaunch script and it worked great. Sorry if this is confusing but essentially I need a script to run without super user privileges but the component thats getting installed after the prelaunch script does. Any ideas? _______________________________________________ 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/scottrussell%40nd.edu This email sent to scottrussell(a)nd.edu This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Scott Russell 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com Ah, forgive me (and thanks for the correction, Stephane), Best wishes, Scott -- Dr. Scott Russell IT Support Engineer/Consultant Arts & Letters Computing, Distributed Support Services, Office of Information Technologies, University of Notre Dame Instructor of Horn, University of Notre Dame and Saint Mary's College Assistant Horn, South Bend Symphony Orchestra 234 Decio Hall 574-631-7021 ScottRussell(a)nd.edu http://www.nd.edu/~srussel2/ On Jul 31, 2008, at 1:54 PM, Cameron Pulsford wrote: I tried modifying my script like this... realUserName=`echo $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.… It's not the $USER part that's failing, it's the actual running of the line. I suppose if I read the entire message before i replied ... So have you verified who really owns the installed LaunchAgent? Is it possible that it's owned by someone other than ${USER}? Is it possible that if ${USER} doesn't own it that ${USER} can't unload it? Grasping as I try to help ... (I assume that the typo "unlead" is only for our benefit and that's not in your live code.) So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/ xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/ LaunchAgents" and then the installer fails. Just to test I made a new package that just did some bogus stuff that didn't need administrator access, and I had it run the same prelaunch script and it worked great. Sorry if this is confusing but essentially I need a script to run without super user privileges but the component thats getting installed after the prelaunch script does. Any ideas? _______________________________________________ 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/scottrussell%40nd.edu This email sent to scottrussell(a)nd.edu This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Cameron Pulsford 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com Ok, so I just tried a combination of both answers but still to no avail. su $actualUserName -c launchctl unload ..... Thanks for all the help so far! On Jul 31, 2008, at 4:27 PM, Scott Russell wrote: Hello Cameron, Best wishes, Scott -- Dr. Scott Russell IT Support Engineer/Consultant Arts & Letters Computing, Distributed Support Services, Office of Information Technologies, University of Notre Dame Instructor of Horn, University of Notre Dame and Saint Mary's College Assistant Horn, South Bend Symphony Orchestra 234 Decio Hall 574-631-7021 ScottRussell(a)nd.edu http://www.nd.edu/~srussel2/ On Jul 31, 2008, at 1:54 PM, Cameron Pulsford wrote: I tried modifying my script like this... realUserName=`echo $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.… I tried `who | grep console | awk {'print$1'}` and I tried `users | grep -v root` (I know only one user will be logged in besides root so this is safe) and then I also fixed the launchctl line to read Alright, so really I want this script to execute before anything else, are there any other ways to do it? I'm looking at the Preinstall Actions which are sort of promising. The only thing that kind of works though is "Open File" which does successfully open the file, but it actually literally opens it. Terminal pops up and runs the script, which isn't exactly the best user experience. Also, since it's just opening the file, it opens it and then immediately starts installing, instead of waiting for the script to be done. There is also a close action, but since the previous command is just open, instead of run, the moment terminal opens, it gets closed before the script can even start. So the only option is to close terminal after the installer is finished. Is there anyway I can add a dummy thing to install that doesn't actually put anything anywhere and just runs the preflight script? when you do "$USER" in a postflight script that has root privs, you'll get "root" back as the $USER. You can get around this in various ways. Pperhaps `who | grep console | awk {'print $1'}` would work for you? I'd like to see a more elegant solution myself if anyone has a better one to offer. So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/ LaunchAgents" and then the installer fails. Just to test I made a new package that just did some bogus stuff that didn't need administrator access, and I had it run the same prelaunch script and it worked great. Sorry if this is confusing but essentially I need a script to run without super user privileges but the component thats getting installed after the prelaunch script does. Any ideas? _______________________________________________ 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/scottrussell%40nd.edu This email sent to scottrussell(a)nd.edu This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Scott Russell 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Best wishes, Scott -- Dr. Scott Russell IT Support Engineer/Consultant Arts & Letters Computing, Distributed Support Services, Office of Information Technologies, University of Notre Dame Instructor of Horn, University of Notre Dame and Saint Mary's College Assistant Horn, South Bend Symphony Orchestra 234 Decio Hall 574-631-7021 ScottRussell(a)nd.edu http://www.nd.edu/~srussel2/ On Jul 31, 2008, at 4:47 PM, Stéphane Sudre wrote: On Jul 31, 2008, at 10:27 PM, Scott Russell wrote: Hello Cameron, On the contrary, you get the currently logged 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.… Really? I'll stand corrected. I haven't done this in a while but based on Cameron's e-mail, it sounded like he was getting not the user name he was expecting. I seemed to remember (perhaps incorrectly) that $USER would return root in those conditions and that would be the source of his problems. At any rate, my convoluted "who" solution should still return the value he's looking for. *shrug* when you do "$USER" in a postflight script that has root privs, you'll get "root" back as the $USER. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Stéphane Sudre 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jul 31, 2008, at 10:27 PM, Scott Russell wrote: Hello Cameron, On the contrary, you get the currently logged 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.… when you do "$USER" in a postflight script that has root privs, you'll get "root" back as the $USER. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Scott Russell 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com Hello Cameron, Best wishes, Scott -- Dr. Scott Russell IT Support Engineer/Consultant Arts & Letters Computing, Distributed Support Services, Office of Information Technologies, University of Notre Dame Instructor of Horn, University of Notre Dame and Saint Mary's College Assistant Horn, South Bend Symphony Orchestra 234 Decio Hall 574-631-7021 ScottRussell(a)nd.edu http://www.nd.edu/~srussel2/ On Jul 31, 2008, at 1:54 PM, Cameron Pulsford wrote: I tried modifying my script like this... realUserName=`echo $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.… when you do "$USER" in a postflight script that has root privs, you'll get "root" back as the $USER. You can get around this in various ways. Pperhaps `who | grep console | awk {'print $1'}` would work for you? I'd like to see a more elegant solution myself if anyone has a better one to offer. So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/ xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/ LaunchAgents" and then the installer fails. Just to test I made a new package that just did some bogus stuff that didn't need administrator access, and I had it run the same prelaunch script and it worked great. Sorry if this is confusing but essentially I need a script to run without super user privileges but the component thats getting installed after the prelaunch script does. Any ideas? _______________________________________________ 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/scottrussell%40nd.edu This email sent to scottrussell(a)nd.edu This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd question relating to preinstall scripts and administrator access
by Stéphane Sudre 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jul 31, 2008, at 7:54 PM, Cameron Pulsford wrote: I tried modifying my script like this... realUserName=`echo $USER` Does it work with: ? _______________________________________________ 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.… So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist Is this a typo in the post or you used a green argument in the script too? su $USER -c launchctl unload $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/ LaunchAgents" and then the installer fails. On which OS version? The marriage of Agents and 10.4 has never been a happy one. This email sent to site_archiver(a)lists.apple.com

1 0

Odd question relating to preinstall scripts and administrator access
by Cameron Pulsford 31 Jul '08

31 Jul '08

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com I tried modifying my script like this... realUserName=`echo $USER` So I seem to have the opposite problem most people have... I am installing something that needs administrator access but I need to run a preinstall script that not only doesn't need these rights, it can't have these rights. I need to run a script that does stuff with "launchctl unload" and when that is given root access it defaults to root, even if the explicit path you give it to unload is ~/Library/xxx for example. That's at least what I have gathered after some research. When I run the script from the terminal it works, but when I run "sudo thescript" it doesn't work. sudo -u $realUserName launchctl unlead $HOME/Library/LaunchAgents/ com.racepoint.*.plist and in the console I still get the same error message "launchctl: Dubious ownership on file (skipping) /Users/xxx/Library/LaunchAgents" and then the installer fails. Just to test I made a new package that just did some bogus stuff that didn't need administrator access, and I had it run the same prelaunch script and it worked great. Sorry if this is confusing but essentially I need a script to run without super user privileges but the component thats getting installed after the prelaunch script does. Any ideas? _______________________________________________ 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: installation with system restart in 10.4, but not in 10.5
by Peelman Nick 30 Jul '08

30 Jul '08

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:from:to :in-reply-to:content-type:mime-version:subject:date:references :x-mailer; bh=s30/faEoZybgJIDc8K23xw0IOCm0fDfgVaArgVEMwe8=; b=d9lT7JRVVi+f2tTT2hwf8r8W3WxLHZvGKcmZEiUYPnE0+nRhuZaj7eiFvkCB1XYC/0 gpYbAQmF3Icmn3kUr3ITcpCZiu6J5xMAFmTMQiSaUsTTjPDQbe6dHii/SRBsRpNmPBNy EgLJ1uU5y1H658al0gEsYsLpzBvyq9IZu96fM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:mime-version:subject :date:references:x-mailer; b=arBsWoxdF1MPRxGvykssogs9FI0f5GE03EU5bJsWSeE93yrjiW4xr2m9SjKEeXDQMd EjXgUHuaA0ZEpmUCl7xofDhaBTvBGng+MGhn76PLiCKdVjwXXCm1Iw4dlE6dPIeSi58t zWmUZLPFVeGKmFQhFXcdVYkOVoGvvQBG0lsp0= -nick -- Nick Peelman peelman(a)gmail.com On Jul 30, 2008, at 18:46, Stéphane Sudre wrote: On Jul 30, 2008, at 8:48 AM, Guoliang Li wrote: Create a metapackage with 2 packages: - Package A: your package that does not require restart. My $0.02 _______________________________________________ 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/peelman%40gmail.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 I did something similar when repackaging Adobe Reader 8, since it was not universal. Built a package for PPC and one for Intel, each with an InstallationCheck (i can't remember now if i used the script or just a package requirement from the GUI) and then put them into a Meta. The proper one got installed, the spare got ignored, everything was peachy. "Duct tape is like the force. It has a light side, a dark side, and it holds the universe together...." hi, my package need to be installed with system restart in 10.4, but not in 10.5, can someone give me a solution for this kind of issue? Thanks. Best wishes. AndrewLi I have a stupid solution for this one if you can use a metapackage instead of just a package. - Package B: another package that requires restart and installs nothing. In Package B, use an InstallationCheck script that will return 64 if the OS is Mac OS X 10.5 or later, 0 otherwise. It might be useful to also add a postflight script to delete this package receipt after installation (or remove it from the sqlite3 receipts data base on Leopard using the tool and option mentioned in a recent post (this will prevent this package from being discarded because it's already installed ). Depending on whether you use a distribution script or a good old metapackage, you might be able to hide the fact that it's a metapackage to the user or you can set Package B to be required. This email sent to peelman(a)gmail.com smime.p7s

1 0

Re: installation with system restart in 10.4, but not in 10.5
by Stéphane Sudre 30 Jul '08

30 Jul '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jul 30, 2008, at 8:48 AM, Guoliang Li wrote: Create a metapackage with 2 packages: - Package A: your package that does not require restart. - Package B: another package that requires restart and installs nothing. My $0.02 _______________________________________________ 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.… hi, my package need to be installed with system restart in 10.4, but not in 10.5, can someone give me a solution for this kind of issue? Thanks. Best wishes. AndrewLi I have a stupid solution for this one if you can use a metapackage instead of just a package. In Package B, use an InstallationCheck script that will return 64 if the OS is Mac OS X 10.5 or later, 0 otherwise. It might be useful to also add a postflight script to delete this package receipt after installation (or remove it from the sqlite3 receipts data base on Leopard using the tool and option mentioned in a recent post (this will prevent this package from being discarded because it's already installed ). Depending on whether you use a distribution script or a good old metapackage, you might be able to hide the fact that it's a metapackage to the user or you can set Package B to be required. This email sent to site_archiver(a)lists.apple.com

1 0