Re: Payload ownership
Re: Payload ownership
- Subject: Re: Payload ownership
- From: Don Montalvo <email@hidden>
- Date: Fri, 5 Mar 2010 10:21:01 -0600
That's what happened to me. :) Since my development Mac was not bound to AD, my account had 504 as the UID. The target computer was bound to AD and the user account had a UID of something like 12312312123123 (just a guess) which is the UID assigned by AD.
If the pkg is set to force ownership to root:wheel everything should work fine. We standardize on root:wheel to avoid these kinds of UID issues, and since there is no consistent local account we can assign as owner:group of the pkg payload.
Don
On Mar 5, 2010, at 9:58 AM, sakshi wrote:
> The usernames are different on both machines. The UID on my machine is 501 whereas on the buggy machine it is 1133xxx693.
>
> I am confused by multiple things:
> 1. The PackageMaker UI works fine but the commandline does not.
> 2. The machine has two users, say, user1 and user2. The staging area contents list owner as user1 for all files and directories. The pmdoc UI shows the owner to be user1. When the pkg is built, the ownership varies from user1 to user2 to <unknown> for various files.
> 3. When I look at the contents pane in PackageMaker, the owner dropdown shows user1. While experimenting, I changed it to root. When I next viewed the dropdown, user1 was not even listed.
>
> I am not clear on how the ownership is decided at pkg creation time. Does it come from the contents.xml file lying in the pmdoc? Does it come via an actual parse of the staging area and therefore is decided at every run? To verify this I manually edited the contents.xml and changed all user1 instances to 1133xxx693. But even this did not work.
>
> Changing the payload ownership to root:admin is on my ToDo list but before that I want to get my concepts right. Would just changing the staging area and then resaving the pmdoc (to regenerate the contents.xml files) suffice?
>
> Thanks,
> Sakshi
>
> On Fri, Mar 5, 2010 at 8:46 PM, Don Montalvo <email@hidden> wrote:
> Hi Sakshi,
>
> Just curious, is the username exactly the same on both computers? I mean the short name (not John Doe, but johndoe or jdoe). Also, what is the UID on the account (on each machine)? We deal with managed environments, so the UID is consistent across all Macs (longish AD string). Lastly, is there a reason the payload can't simply be owned by root:wheel (the standard we use)? :)
>
> Don
>
> On Mar 5, 2010, at 5:54 AM, sakshi wrote:
>
> > Hi Don,
> >
> > The user:group do exist on the machine. In fact when I see the pmdoc on my machine, files are labeled root:admin and on the buggy machine (the staging area and) the pmdoc contents get set to the user's username:admin. I was under the impression that the staging area would define what does into the pmdoc and finally the pkg. This situation seems to differ from my opinion: the pmdoc gets set from the staging area but the pkg has a mind of its own.
> > Does the fact that packagemaker is being invoked from the commandline and not the UI have any impact?
> >
> > Thanks,
> > Sakshi
> >
> > On Fri, Mar 5, 2010 at 1:40 AM, Don Montalvo <email@hidden> wrote:
> > sakshi <email@hidden> wrote:
> >
> > > Hi,
> > >
> > > I am running into a very weird issue while building a pmdoc and need some
> > > help with my basics. I created a pmdoc using a staging folder on my machine.
> > > I shared it with the team to build and test on their machines. On one
> > > machine we are seeing weird behavior and some files end up getting created
> > > with an <unknown> owner. The pmdoc is being built through the commandline.
> > >
> > > All other files have a valid username associated with them, just these
> > > specific files are linked to <unknown>. I've verified the staging folder on
> > > that machine and it has the right permissions and owner. I opened that copy
> > > of the pmdoc in PackageMaker and it also has the expected owner. Somehow the
> > > final pkg differs. I used lsbom and verified that the pkg itself contains a
> > > 'corrupted' file.
> > >
> > > Any clues on where else I could look?
> > >
> > > Thanks!
> > > Sakshi
> >
> > Hi Sakshi,
> >
> > Sounds like the user:group defined in the pkg is not present on the target computer? For example, if you set user to "jdoe" who has UID of 504, but there is no UID 504 on the target computer, this can happen. It happened last week when I was testing a new pkg. Since it happened before, I recognized the problem. I changed the user:group to something that's on every computer. Then tested again and all went well.
> >
> > Don
> >
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden