January 2011 - Installer-dev

Re: How to execute script as root, and then an another script on behalf of an ordinary user
by Karl Kuehn 06 Jan '11

06 Jan '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=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=yO7rLmPjKG7oohtu59iqYzAt1ZgQE34M+wRzMbvMwWM=; b=lH/lMo9pSvY10XUrDZ9exWg/0z7Nif2Pwyo6uhQ97UlC8Vu9il6DJ07yWC9VsZ9Gcy jUdG+XdwcmFgyjNhUhaKNEy6IFl24TfyDkI+x5JU5vjNDCs8ZM1rLtKuavThuPxnKVCk K1qTbcejPhwJ8RsPL2z7HNcd/i4k8nIqg+4wU= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hQzLpBbbArWLGeB9qeD4kESwiEqt7hmc85NLAbHwho3/ZNDy9mkIkkXGGi6EbniIbu 5+gV9gbPk/Npzt2IPdJg7yLgtyfZKVHBL5GVCQm7mxlZKt39XZiLUgO0E2WDEqm2O/L3 Tsiu5s68wuAWSLkLe2ebevO551nqNhHSNIzDw= On Jan 5, 2011, at 10:05 AM, eveningnick eveningnick wrote: >> This indicates that you are trying to use Apple's PackageMaker. While it is the Apple tool for this, there are better ones available for free. I would suggest using Iceberg or Packages (for "old style" and "flat file" packages respectively). > > Thanks, i'll take a look at that. > I just wanted to make it Apple-look-like so that installation process does not differ from any other installations users had made before, even though there's a lot of addtional work is done underneath. I think you are missing an important thing here. .pkg files are documents, not applications. PackageMaker is a program that creates these files, and Iceberg/Packages is another. The user experience is identical, and the installer program (Installer.app) does not differentiate .pkgs from one source or the other. [snip] >> Yes, there are lots. As a simple example: why are you assuming that there is only one person logged in, or that there is even one person logged in to the computer. Both cases are valid. > > I guess i will have to ps -x | grep loginwindow and execute "launchctl bsexec" for every instance of loginwindow? if there's no users logged > in, the loop will never be executed. Otherwise, it'll execute for every user who's logged in (well, just like in that example on that link). > >> We don't know exactly what you are trying to do, backing out a step or two might be a really good idea. There are a lot of people on this list that can probably better help you out if you give them the information they need to help you. > > It's an NKE Kext , which is autoloaded by a "starter"-daemon and whose status is displayed by an agent in a status bar. After installing, i want these daemon and agent to be launched immediately, without reboot. I understand the convince and elegance that you are going for, but it might not be worth it. I am a bit prejudiced in this area as I worked on InstaDMG for a long time, but you should be aware that there are cases where the volume that your package is being installed to is not the root volume, so loading Kexts automatically should only be done with great care (a similar argument for the toolbar). And there are just so many variables in this area that I am not sure that it is really worth doing. While it is brutal, and we should aim for better, I am with Greg on this one and I think that a reboot is the best option. -- Karl Kuehn larkost(a)softhome.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to execute script as root, and then an another script on behalf of an ordinary user
by Xochitl Lunde 05 Jan '11

05 Jan '11

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 > > Yes, there are lots. As a simple example: why are you assuming that there is > > only one person logged in, or that there is even one person loggedin to the > > computer. Both cases are valid. > > I guess i will have to ps -x | grep loginwindow and execute "launchctl > bsexec" for every instance of loginwindow? if there's no users logged > in, the loop will never be executed. Otherwise, it'll execute for > every user who's logged in (well, just like in that example on that > link). > > > We don't know exactly what you are trying to do, backing out a step or two > > might be a really good idea. There are a lot of people on this list that can > > probably better help you out if you give them the information they need to > > help you. > > It's an NKE Kext , which is autoloaded by a "starter"-daemon and whose > status is displayed by an agent in a status bar. After installing, i > want these daemon and agent to be launched immediately, without > reboot. FYI: Everything I'm going to say is only based on my experience working with my program's installation, NOT anything definitive on how launchctl *ought to* behave. My program starts a daemon and a GUI-user-only launch agent that displays any bad news from the daemon (i.e. "computer shutting down in 60 seconds, do you want to log out?"). An example of when there could be 0 users logged in is when you are installing with ARD. When working with launchctl from a script in a package, it's important to know who you are. The package can be installed through ARD, command line, or GUI and each scenario affects who you are when the script runs. You only get a $SUDO_USER environment variable in the IntallationCheck script (maybe VolumeCheck), you won't get it in preflight/postflight/etc. If you are installing a daemon, you will require authentication on your package. This should make the $USER in your scripts root. Good for starting / stopping a daemon, not good for starting an agent. I ended up guessing who was installing the package based on the contents of $HOME and the output of 'who'. # this is some of my unload code from preinstall/preupgrade, but the load code is about the same - i had to retype it so it might not be perfectly typed. # In the postinstall, I check if the plist file got installed before even trying to load the daemons and agents. if [ ! $USER = "root" ] ; then su $USER -c 'launchctl unload -w /Library/LaunchAgents/com.tripplite.myproject.myagent.plist ||: #don't hang else home_user=""; for user in `who | grep console | awk {'print $1'}` do user_in_home="`echo "${HOME}" | grep $user`" if [ -n "${user_in_home}" ] ; then home_user=$user fi done if [ -n "${home_user}" ] ; then echo "Stopping MyAgent for $home_user." su $home_user -c 'launchctl unload -w /Library/LaunchAgents/com.tripplite.myproject.myagent.plist ||: #don't hang fi fi By my experience, launchctl isn't going to let you switch user and load something for any user other than $USER or the user who started the package. It always errored out for me if I tried to launch an agent for a user that was fast user switched or any user that hadn't run the package. Granted, it's been since 10.6.3 since I've tried it. I get around this by not installing the package if too many GUI users are logged in, which might or might not be appropriate for you. Depends on how important it is for your agent to be running. It's not perfect, but it does increase the likelihood that I will not have some GUI users with agents running and some who did not get to launch the agent. There's a race condition because I can't prevent anyone from logging in from the time that I do the check to the time that I start the agent. # I do this in InstallationCheck so that I can present an error message from InstallationCheck.strings for name in `who | grep console | awk {'print $1'}` do if [ ! $name = $USER ] ; then if [ ! $name = $SUDO_USER ] ; then exit 112 ; # Return String 16 fi fi done What I can say about the correctness of this solution is that: 1. It works. It has been working fine for ARD, command line, and GUI installs, tested on 10.5.8 & 10.6.3 2. Nobody ever told me it was an unacceptable solution when I was discussing it on the list back around March. Hope this helps or was interesting.

1 0

Re: How to execute script as root, and then an another script on behalf of an ordinary user
by eveningnick eveningnick 05 Jan '11

05 Jan '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=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=l3TBWtY7iSrjpEgX/rBf2kDuatjdgohO4VUHAiPTkVg=; b=cVsVHIIiHgjCP3NaOtApAyJOgzdB+sAmfrvr1vxa+CFpnqRE46eXMDJiJ3y9XGj6bT K7MSkw2vimP/LpUXEq9gPMsKgRjtHEy1Q4WA6obryOzlweACVlrk+v8vk9JW6ATieX87 MKMaOgR5TwzzSg+MEM330czkvfHEKoN8+rcpE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w4SJfPEAK4fmgRSmU7i9/j/Yy8NvPUvY71iETliDB+VXakTKqYGbP67sV+ldOx87LY VsFth2ahe86B8Ff+JnGsVCZXgYSo6AirTjcPoaEv9LgcLqgblHBZoaS/AzMnGTYE5q7E 59zpF7zGNxZlFZpET6C6po3eMovn4FNIzqbcw= > This indicates that you are trying to use Apple's PackageMaker. While it is > the Apple tool for this, there are better ones available for free. I would > suggest using Iceberg or Packages (for "old style" and "flat file" packages > respectively). Thanks, i'll take a look at that. I just wanted to make it Apple-look-like so that installation process does not differ from any other installations users had made before, even though there's a lot of addtional work is done underneath. > But regardless you can always just select the root of the > filesystem as your target, and then put all of your payload in there. > There are a lot of problems going down the route you have chosen, and you > will get a lot of flack for doing it (Greg is one of the more vocal, so I > expect him to respond as well once he makes it to work today). The first > problem is that you have totally blown out any idea of system administrators > being able to use the package receipt system to audit their computers. Just > killed it dead. Since everything gets moved by a script there is no > automate-able way of auditing this. This also means that auto-delete systems > fail. This is bad. > You have also opened up the potential for you to mess up in the scripting in > so many ways... An example would be a system that does not properly use $3 > everywhere, so now can't be used in system image creation tools like > InstaDMG or System Image Utility. > By going off the normal path you have made yourself responsible to know > every single variation out there... is that really a burden you want to take > on? > I provide my own uninstaller, but your argumentation looks reasonable. Maybe you know any good documentation available about install makers, except Apple app distribution guidlines? > Yes, there are lots. As a simple example: why are you assuming that there is > only one person logged in, or that there is even one person logged in to the > computer. Both cases are valid. I guess i will have to ps -x | grep loginwindow and execute "launchctl bsexec" for every instance of loginwindow? if there's no users logged in, the loop will never be executed. Otherwise, it'll execute for every user who's logged in (well, just like in that example on that link). > We don't know exactly what you are trying to do, backing out a step or two > might be a really good idea. There are a lot of people on this list that can > probably better help you out if you give them the information they need to > help you. It's an NKE Kext , which is autoloaded by a "starter"-daemon and whose status is displayed by an agent in a status bar. After installing, i want these daemon and agent to be launched immediately, without reboot. _______________________________________________ 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: How to execute script as root, and then an another script on behalf of an ordinary user
by Greg Neagle 05 Jan '11

05 Jan '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jan 5, 2011, at 8:25 AM, Karl Kuehn wrote: > There are a lot of problems going down the route you have chosen, and you will get a lot of flack for doing it (Greg is one of the more vocal, so I expect him to respond as well once he makes it to work today). No, you pretty much covered 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: How to execute script as root, and then an another script on behalf of an ordinary user
by Karl Kuehn 05 Jan '11

05 Jan '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=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=R23+592r/Qzzb4KUmIq/9yPcSyTO2tHZf7jenhms+ro=; b=o/YJ2nPa9mH02kVrP2hVsFESeYt1UpUmb4M86eOLtrjVpD3Soz6U/4pDoTp0Jqy/T2 OiVb/D9a9n1Prp3reGQ6zgoqsgQAisd7VcuR5G2WASmgXo3P5ErubBbbo5DNpo3AIcWa 9576STpcdcc7NE1mEy+FMiwj7wZ0gXDQ4yY34= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=n8V9FlzTLrhb/1OinRGsdnKqXeP8AvHvrCnl0Ob5JIhLR4iEvl/KJdAGWzddNe/sj7 saWzVcSPuPHni0mtKpGoN7wYAdf8shlMPY+xOf2srEBJQAzrM3I7Zq74Nu/y1wAPAbG/ rF/wpB6gL7aSqZVrtrKJCBBpL+xL6ZKxqQf8o= _______________________________________________ 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: How to execute script as root, and then an another script on behalf of an ordinary user
by Greg Neagle 05 Jan '11

05 Jan '11

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: Iceberg Package installing into /tmp by default?
by Greg Neagle 05 Jan '11

05 Jan '11

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: How to execute script as root, and then an another script on behalf of an ordinary user
by eveningnick eveningnick 05 Jan '11

05 Jan '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=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KhqOLMqqtZHe6ZT9uiVz+qwVlt+aGN2zaE6u+pO3Bv8=; b=fA1iHrDJri1AMigUksbSXall62uS64qGwwVjnlp/Zdt0qh2DQt2gML2KuFQ9TIYeca NoXf+fb16Aap4JiFxOoJPwYkccIlzBYihz5hQNmGrKHBd37Ali2HFiGrHl19cw5XA4MX tLUrUSXJKshuZGORwKd82Sf/4/URTiRG+0hok= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RcMY4Pjh0FR4SP0h5otnZg8JqKAsS2MvUA0IRTrt0g3a1/UztuwyP/n9PfmdUPH7t1 c20QvcbnlFm/GXKOFyIkXlGerz0kiGCGypxidBRmjt0SopyqVEVQYkYRbU+tB4l9t5e9 TCguImKVj34golHHUtTol8O6rFcAqIbVH2Ycc= > Why aren't these simply part of the package payload? There are a lot of different places where i need to install files. it is /Library/LaunchAgents, /Library/LaunchDaemons, /Library/Application Support, /Library/PreferencePanes. It would require as many "PackageMaker targets" as locations. I don't know why but on my system it compiles too much time (with every new location), for strange reasons creates packages more than 400 Mb in size from time to time and the installing time is unacceptable. Maybe i don't know something (albeit i was following Apple's Application distribution guidelines), so i decided to have one target - in /tmp, and run a big postinstall script which does all the movements to the right directories, chmod's and chown's all the files, starts daemons/kexts and deletes that /tmp/TempDir file. Maybe i should have looked at console version of packagemaker? > This is difficult to do correctly in all instances. See http://stackoverflow.com/questions/1106638/starting-stopping-a-launchd-agen… Thanks a lot for the link! What do you mean by "all instances"? As far as i understand, i need to find a pid of some process that was launched by the current logged in user. Finder, for example. And then execute launchctl bsexec [finderPID] "/tmp/myloadscript". Or i am wrong? Are there any additional pitfalls? > > It may be easier to simply require a logout (or a reboot) after install; when the user logs back in the LaunchDaemon will be loaded. Yes, i was thinking about, but users don't like to reboot the system, at least me, i consider that as old past times. Of course if i am unable to do this without rebooting, i'd use your advice. Thank you again _______________________________________________ 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: Iceberg Package installing into /tmp by default?
by Per Olofsson 05 Jan '11

05 Jan '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AcuhWP7Bhx6OCEbIQlKMXE+JNNm+igKQHWNHACLSU4AAAbgugAABCy4AACG8kIA= Thread-topic: Iceberg Package installing into /tmp by default? 4 jan 2011 kl. 18.52 skrev Greg Neagle: > In most cases, this can be done without repackaging software. I'm a big fan of using vendor packages as-is whenever possible, and collecting your modifications or additions into a separate package (or packages) that you install after the vendor's package. This is generally easier, less error-prone, and makes troubleshooting easier. In the case of Office 2011, it's easy to customizethe official package using Distribution.dist: http://www.officeformachelp.com/office/administration/deployment/distributi… I'm actally a fan of (scripted, not manual) repackaging, but the Office packages are reasonably well behaved these days so there's little (if anything) to gain. PS: Nate Walck has a lot of good info on deploying Office 2011 as well, see: http://osxdeployment.com/wiki/Category:Office_2011 There are also his fixes for Office 2011 and the updates so you can deploy them with InstaDMG (but sadly not DeployStudio): http://www.afp548.com/forum/viewtopic.php?showtopic=28121 http://www.afp548.com/forum/viewtopic.php?showtopic=28022 -- 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

Re: How to execute script as root, and then an another script on behalf of an ordinary user
by Greg Neagle 05 Jan '11

05 Jan '11

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jan 4, 2011, at 4:00 PM, eveningnick eveningnick wrote: > hello > I have faced with a problem needing to execute 2 actions after > installation (i placed them as postinstall scripts). > Firstly, i need to install plist files into /Library/LaunchDaemons and > /Library/LaunchAgents Why aren't these simply part of the package payload? > (this can be done only from "root" script) > And then i need to start a daemon and an agent using launchctl > > The problem is that while daemon can be started (because post > installation script is running as root, i can execute launchctl load > -w /Library/LaunchDaemons/com.mydaemon), i can't start an agent. Agent > needs to be loaded and started by a user, not by a root - if a user > executes a command "sudo launchctl load -w > /Library/LaunchAgents/com.myagent", this agent will be loaded into > system domain - i.e. by a global launchd instance while i need to load > it using a per-session launchd instance. This is difficult to do correctly in all instances. See http://stackoverflow.com/questions/1106638/starting-stopping-a-launchd-agen… It may be easier to simply require a logout (or a reboot) after install; when the user logs back in the LaunchDaemon will be loaded. -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