January 2007 - Installer-dev

Problems with Metapackages in Panther.
by Dennet Menezes 18 Jan '07

18 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com User-agent: Microsoft-Entourage/10.1.6.040913.0 Hi, I have a Metapackage that contains individual packages with their own VolumeCheck scripts. These packages are assigned the attribute "Selected" in the Metapackage Info.plist. When I install this metapackage in Tiger the VolumeCheck scripts for all the packages are run and they get automatically enabled/disabled in the Customize panel in case the script for a package succeeds/fails. However this is not the case in Panther where in-spite of the VolumeCheck scripts failing (which is verified by installing the packages standalone) the metapackage goes on to allow installation for all the packages. Is there any way I can get the metapackage to validate my individual packages disabling the ones whose VolumeCheck script fails in Panther just as it does in Tiger? Dennet ----------------------------------------------- Robosoft Technologies - Come home to Technology _______________________________________________ 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: Problems with StartupItems
by Horst Hösel 18 Jan '07

18 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Am 18.01.2007 um 10:52 schrieb Filippo Ignozza: [snip] Hi Filippo, HTH, Horst Hösel VierZwo Software GmbH Rübezahlstr. 20 81739 München Tel.: (089) 66 029 960 Fax: (089) 66 029 969 Mail: hoesel.h(a)vierzwo.de _______________________________________________ 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 need to run an application at startup. I am having several difficulties so i tried as a first step to just run a script For this reason i create an installer who create in /Library/ StartupItems the following: make sure the folders and scripts are owned by root/wheel. Access rights should be -rw-r----- for the .plist, -rwxr-x--- for the script, and drwxr-xr-x for the folders. As a safety measure Mac OS X does not allow Startup Items (which run as root) that are changeable by non-privileged users . This email sent to site_archiver(a)lists.apple.com

1 0

Problems with StartupItems
by Filippo Ignozza 18 Jan '07

18 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Organization: Digital Video S.p.a. Priority: normal _______________________________________________ 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: Customized disk images
by John Daniel 12 Jan '07

12 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com John On Jan 12, 2007, at 12:29 AM, Andy Cedilnik wrote: Hello, I am trying to create disk image with all the necessary stuff programmatically. I need this because we make nightly installers for the users. Currently I create a directory and then I run: "/usr/bin/hdiutil" create -ov -format UDZO -srcfolder "/path/to/the/source/tree" "/path/to/the/disk/image.dmg" This works great. Now I would like to spice it up a little bit. An example is a disk image for the Firefox. This one has a nice background, the icon, and a license agreement. So, I can do most of this by hand using Finder. Now, is there any way to customize this from a shell script or a C++ program? Thank you. _______________________________________________ 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.… Andy, I use a shareware program called DropDMG from http://c-command.com/ dropdmg/. There is a fee program called FreeDMG at http:// www.kelleycomputing.net:16080/freedmg/, but I haven't tried it. -- ------------------------------------------- Andy Cedilnik _______________________________________________ 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/jdaniel% 40etresoft.com This email sent to jdaniel(a)etresoft.com This email sent to site_archiver(a)lists.apple.com

1 0

Customized disk images
by Andy Cedilnik 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Hello, I am trying to create disk image with all the necessary stuff programmatically. I need this because we make nightly installers for the users. Currently I create a directory and then I run: "/usr/bin/hdiutil" create -ov -format UDZO -srcfolder "/path/to/the/source/tree" "/path/to/the/disk/image.dmg" This works great. Now I would like to spice it up a little bit. An example is a disk image for the Firefox. This one has a nice background, the icon, and a license agreement. So, I can do most of this by hand using Finder. Now, is there any way to customize this from a shell script or a C++ program? Thank you. -- ------------------------------------------- Andy Cedilnik _______________________________________________ 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: Installer packages asking for authentication in user's home directory
by Michael Watson 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com -- mikey On 09 Jan, 2007, at 18:55, Luke Bellandi wrote: Hi Michael, Please file a bugreport at http://bugreport.apple.com. Thanks, Luke On Jan 9, 2007, at 3:19 PM, Michael Watson wrote: 0. Create a new user who does not have write access to /Applications. 1. Create a new single package project and save it to disk. 5. Build the package and run it from the Finder under the new user. 9. Build the package and run it from the Finder under the new user. See this: http://lists.apple.com/archives/installer-dev/2006/Feb/msg00035.html -- m-s On 09 Jan, 2007, at 17:36, Luke Bellandi wrote: _______________________________________________ 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.… No problem. Thanks for taking the time to read through my tangled mess. :-) I'm not splitting anything across domains. Users are allowed to choose where to install programs, and Installer.app doesn't seem to allow for flexible installer packages that let the user choose the installation directory, without forcing an authentication prompt regardless of destination permissions. Open Package Maker and follow these steps to replicate the issue I am having: 2. Create your "component" payload directory on disk and add a dummy text file to it. 3. In the Contents tab of the Package Maker project, set the root to the component dir. 4. In the Configuration tab, give the package a default location of /Applications, as this is pretty standard for installed apps. Notice that if you change the setting for Authentication to "None", it will be reverted to "Adminstrator" when you change tabs, press the tab key, build the project, or save the project. The logic here is clear, because setting the default location of your user folder will automatically change the Authentication value to "None", but continue reading to see how this logic ends up causing problems. For now, leave the settings here defined as /Applications and "Administrator". 6. Attempt to install the payload into the default location of / Applications. You will be prompted for authentication. So far, so good. If you enter your auth info, the package installs properly. 7. Relaunch the installer package and this time, choose your home folder instead of using the default location. You will be prompted for authentication. ***Installer.app does not look at whether or not you have write access to the chosen folder; it only checks to see what you set up in Package Maker.*** 8. Back to the Package Maker project. Change the Authentication value to "None". 10. Attempt to install the payload into your home folder, instead of the default location of /Applications. ***The payload will be installed without an authentication prompt.*** 11. Relaunch the installer package and this time, use the default location of /Applications for the installation directory. ***You will NOT be prompted for authentication, and the installation will (obviously) fail.*** Surely there is a way to correct this behaviour. Appropriate behaviour should be: 1. With "Adminstrator" authentication defined, authentication is always demanded of the user. 2. With "None" authentication defined, authentication is demanded of the user when the destination directory's permissions require elevated privilege, but not demanded otherwise. >> Another apparent limitation of the package system (though I haven't >> tried it to make sure), is that in order to support the application's >> default installation of into /Applications, I'd need to make the >> permissions be root:admin 1775. However, if I'm in the "user" case, >> where the user isn't an admin and doesn't plan on installing the >> application for all users, I'd not be able to make the permissions be >> root:admin even if I wanted to (which I don't, I'd rather it just be the >> user's uid and gid). Furthermore, it seems like it's just a static >> setting that a package requires admin authentication or not. Is this the >> case, or am I missing something? > See above, if the user installs in their home directory (this is a special case) > it will not authenticate and install the package as the user. The problem is, of course, that this reply appears to be incorrect. Installer.app /will/ ask the user to authenticate, regardless of the user's permission to write to the chosen directory. No. The installer either installs all files as the user (when authentication is none), or applies the ownership of all of the files from when they were packaged (when authentication is admin or root). There's no support for a hybrid case, except by using scripts as you say. Generally it makes more sense to try to stick to one domain. What are you installing that requires pieces to be installed in both the user *and* the system domain? - Luke This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer packages asking for authentication in user's home directory
by Luke Bellandi 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com Hi Michael, Please file a bugreport at http://bugreport.apple.com. Thanks, Luke On Jan 9, 2007, at 3:19 PM, Michael Watson wrote: 0. Create a new user who does not have write access to /Applications. 1. Create a new single package project and save it to disk. 5. Build the package and run it from the Finder under the new user. 9. Build the package and run it from the Finder under the new user. See this: http://lists.apple.com/archives/installer-dev/2006/Feb/msg00035.html -- m-s On 09 Jan, 2007, at 17:36, Luke Bellandi wrote: _______________________________________________ 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'm not splitting anything across domains. Users are allowed to choose where to install programs, and Installer.app doesn't seem to allow for flexible installer packages that let the user choose the installation directory, without forcing an authentication prompt regardless of destination permissions. Open Package Maker and follow these steps to replicate the issue I am having: 2. Create your "component" payload directory on disk and add a dummy text file to it. 3. In the Contents tab of the Package Maker project, set the root to the component dir. 4. In the Configuration tab, give the package a default location of / Applications, as this is pretty standard for installed apps. Notice that if you change the setting for Authentication to "None", it will be reverted to "Adminstrator" when you change tabs, press the tab key, build the project, or save the project. The logic here is clear, because setting the default location of your user folder will automatically change the Authentication value to "None", but continue reading to see how this logic ends up causing problems. For now, leave the settings here defined as /Applications and "Administrator". 6. Attempt to install the payload into the default location of / Applications. You will be prompted for authentication. So far, so good. If you enter your auth info, the package installs properly. 7. Relaunch the installer package and this time, choose your home folder instead of using the default location. You will be prompted for authentication. ***Installer.app does not look at whether or not you have write access to the chosen folder; it only checks to see what you set up in Package Maker.*** 8. Back to the Package Maker project. Change the Authentication value to "None". 10. Attempt to install the payload into your home folder, instead of the default location of /Applications. ***The payload will be installed without an authentication prompt.*** 11. Relaunch the installer package and this time, use the default location of /Applications for the installation directory. ***You will NOT be prompted for authentication, and the installation will (obviously) fail.*** Surely there is a way to correct this behaviour. Appropriate behaviour should be: 1. With "Adminstrator" authentication defined, authentication is always demanded of the user. 2. With "None" authentication defined, authentication is demanded of the user when the destination directory's permissions require elevated privilege, but not demanded otherwise. >> Another apparent limitation of the package system (though I haven't >> tried it to make sure), is that in order to support the application's >> default installation of into /Applications, I'd need to make the >> permissions be root:admin 1775. However, if I'm in the "user" case, >> where the user isn't an admin and doesn't plan on installing the >> application for all users, I'd not be able to make the permissions be >> root:admin even if I wanted to (which I don't, I'd rather it just be the >> user's uid and gid). Furthermore, it seems like it's just a static >> setting that a package requires admin authentication or not. Is this the >> case, or am I missing something? > See above, if the user installs in their home directory (this is a special case) > it will not authenticate and install the package as the user. The problem is, of course, that this reply appears to be incorrect. Installer.app /will/ ask the user to authenticate, regardless of the user's permission to write to the chosen directory. No. The installer either installs all files as the user (when authentication is none), or applies the ownership of all of the files from when they were packaged (when authentication is admin or root). There's no support for a hybrid case, except by using scripts as you say. Generally it makes more sense to try to stick to one domain. What are you installing that requires pieces to be installed in both the user *and* the system domain? - Luke This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer packages asking for authentication in user's home directory
by Michael Watson 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com To clarify this: On 09 Jan, 2007, at 18:19, Michael Watson wrote: -- m-s _______________________________________________ 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.… 10. Attempt to install the payload into your home folder, instead of the default location of /Applications. ***The payload will be installed without an authentication prompt.*** This is the behaviour one would expect in this step. I simply ***highlighted*** it to point out the result of the operation. :-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer packages asking for authentication in user's home directory
by Michael Watson 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com 0. Create a new user who does not have write access to /Applications. 1. Create a new single package project and save it to disk. 5. Build the package and run it from the Finder under the new user. 9. Build the package and run it from the Finder under the new user. See this: http://lists.apple.com/archives/installer-dev/2006/Feb/msg00035.html -- m-s On 09 Jan, 2007, at 17:36, Luke Bellandi wrote: _______________________________________________ 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'm not splitting anything across domains. Users are allowed to choose where to install programs, and Installer.app doesn't seem to allow for flexible installer packages that let the user choose the installation directory, without forcing an authentication prompt regardless of destination permissions. Open Package Maker and follow these steps to replicate the issue I am having: 2. Create your "component" payload directory on disk and add a dummy text file to it. 3. In the Contents tab of the Package Maker project, set the root to the component dir. 4. In the Configuration tab, give the package a default location of / Applications, as this is pretty standard for installed apps. Notice that if you change the setting for Authentication to "None", it will be reverted to "Adminstrator" when you change tabs, press the tab key, build the project, or save the project. The logic here is clear, because setting the default location of your user folder will automatically change the Authentication value to "None", but continue reading to see how this logic ends up causing problems. For now, leave the settings here defined as /Applications and "Administrator". 6. Attempt to install the payload into the default location of / Applications. You will be prompted for authentication. So far, so good. If you enter your auth info, the package installs properly. 7. Relaunch the installer package and this time, choose your home folder instead of using the default location. You will be prompted for authentication. ***Installer.app does not look at whether or not you have write access to the chosen folder; it only checks to see what you set up in Package Maker.*** 8. Back to the Package Maker project. Change the Authentication value to "None". 10. Attempt to install the payload into your home folder, instead of the default location of /Applications. ***The payload will be installed without an authentication prompt.*** 11. Relaunch the installer package and this time, use the default location of /Applications for the installation directory. ***You will NOT be prompted for authentication, and the installation will (obviously) fail.*** Surely there is a way to correct this behaviour. Appropriate behaviour should be: 1. With "Adminstrator" authentication defined, authentication is always demanded of the user. 2. With "None" authentication defined, authentication is demanded of the user when the destination directory's permissions require elevated privilege, but not demanded otherwise. >> Another apparent limitation of the package system (though I haven't >> tried it to make sure), is that in order to support the application's >> default installation of into /Applications, I'd need to make the >> permissions be root:admin 1775. However, if I'm in the "user" case, >> where the user isn't an admin and doesn't plan on installing the >> application for all users, I'd not be able to make the permissions be >> root:admin even if I wanted to (which I don't, I'd rather it just be the >> user's uid and gid). Furthermore, it seems like it's just a static >> setting that a package requires admin authentication or not. Is this the >> case, or am I missing something? > See above, if the user installs in their home directory (this is a special case) > it will not authenticate and install the package as the user. The problem is, of course, that this reply appears to be incorrect. Installer.app /will/ ask the user to authenticate, regardless of the user's permission to write to the chosen directory. No. The installer either installs all files as the user (when authentication is none), or applies the ownership of all of the files from when they were packaged (when authentication is admin or root). There's no support for a hybrid case, except by using scripts as you say. Generally it makes more sense to try to stick to one domain. What are you installing that requires pieces to be installed in both the user *and* the system domain? - Luke This email sent to site_archiver(a)lists.apple.com

1 0

Re: Installer packages asking for authentication in user's home directory
by Luke Bellandi 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Installer-dev(a)lists.apple.com Hi Michael, On Jan 8, 2007, at 1:57 PM, Michael Watson wrote: - Luke -- Michael Watson _______________________________________________ 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/luke%40apple.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.… Using Package Maker 2.1.1 under Tiger, I seem to be unable to build an installer package that will allow a user to install into his or her home directory without authenticating. (That is, without pre/ post-install workarounds.) It appears that Package Maker doesn't actually make use of, say, something like NSFileManager to determine whether or not a user has write access to an area, and then prompt if necessary for authentication. It's using its own internal rule set, which just doesn't seem to be very smart: 1. I have to choose a default installation directory. 2. If I choose "Administrator" or "root" for the authentication option, the user is prompted to authenticate even for places he or she has write access. Unacceptable. 3. If I choose "none" for the authentication option, the user is not prompted for authentication under any circumstance, and thus cannot choose to install to those places that would normally trigger an authentication prompt. Is there a way to solve this, aside from pre/post-install workarounds? No. The installer either installs all files as the user (when authentication is none), or applies the ownership of all of the files from when they were packaged (when authentication is admin or root). There's no support for a hybrid case, except by using scripts as you say. Generally it makes more sense to try to stick to one domain. What are you installing that requires pieces to be installed in both the user *and* the system domain? This email sent to luke(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0