Mike Gerdts wrote:
> On Sun, Mar 9, 2008 at 6:31 PM, Sarah Jelinek <Sarah.Jelinek at sun.com>
> wrote:
>
>> At this point in time, the user does exist in the passwd file in the
>> alternate root. Not sure why they would need to exist in the passwd file
>> on the livecd for this? I certainly could do this calling chown(). I can
>>
>
> Because when chown(1M) processes its user argument, it calls
> getpwnam(user). It then calls chown(file, pw->pw_uid, <gid>). For
> getpwnam(3C) to succeed, it then uses the name services as defined in
> /etc/nsswitch.conf. I would expect that the live cd would use only
> the files name service for passwd and as such, an entry for "jack" in
> the live cd's /etc/passwd would be required for getpwnam("jack") to
> succeed. I think this is the case - but it seems to be working by
> accident rather than by design.
>
Hi Mike,
Ah.. ok, I see what you are driving at. It is the case that it calls
getpwnam("jack") or whomever the user adds. At this point in time though
the user has been added to the ramdisk /etc/passwd and /etc/shadow
files. So, this succeeds. In the livecd environment / is mounted
read/write so we can modify the files in ramdisk, then we copy them over
to the target which is /a/etc/... In the old installer we have symlinks
from /etc/passwd and friends to files in /tmp/root/etc/... so that we
can write these as well. The miniroot in the old installer is not
mounted read/write. If you look at the /etc/passwd file in / when livecd
is booted jack is in there as well. He happens to be pre-added to the
files from building the livecd but the microroot is unpacked and mounted
on /, so he appears there as well. That's why this works.
We have to keep the environment when installing much the same as a live
solaris system, since as noted by Bart in a previous email, many of our
utilities are not alternate root aware.
>> also user the defined uid and gid values. If this ever changes in that
>> these are no longer defines but values input by the users during install
>> this will have to be modified.
>>
>
> True enough. I suspect at some time there will be someone that says
> "why does every machine have a user named jack?" and no matter what
> approach is used a change will be needed. Or is this creating a user
> that is specified by the person performing the installation?
>
>
This is creating a user that is specified by the person performing the
installation. So, in the case of jack, well if that is changed we can
remove him, but if a user specifies a account name and password then we
still have to add them.
I will change this to call chown() with the UID and GID as we do with
the created users home directory. To keep this consistent.
thanks for your comments and time,
sarah
****
