RE: Building /etc/passwd from setup.exe

["John Morrison" <john dot r dot morrison at ntlworld dot com>]

> From: Pierre A. Humblet
>
> Domain users have had recurrent troubles with /etc/passwd.
> Here is why, and a proposed remedy.
>
> TODAY
> The currently released setup.exe verifies if /etc/passwd exists.
> If it doesn't, setup creates the file /etc/postinstall/passwd-grp.bat
> which contains
> ********
> bin\mkpasswd -l > etc\passwd
> ********
> That file gets executed during postinstall, creating a passwd file
> with only local users.
>
> There is also a package "base-passwd" with one file,
> /etc/postinstall/passwd-grp.sh

<snip>I'm sure everyone can open the file if they are
interested</snip>

> That file has no effect if it runs after passwd-grp.bat, because
> then the passwd file already exists. I have observed that order,
> I don't know if it's deterministic.
>
> So that's why domain users are not included, and why they are included
> if they delete /etc/passwd and rerun /etc/postinstall/passwd-grp.sh.done
> after setup, as has been suggested on the list.
>
> SOON
> On 2002-11-26, setup has been modified and doesn't create passwd-grp.bat
> anymore. Consequently passwd-grp.sh will have an effect if passwd doesn't
> exist initially. However that will create another set of problems:

Glad you commented at the time this was up for debate...

> 1) If the cases of $USERDOMAIN and `hostname` differ, local users will
>    execute mkpasswd -d

I asked around and nobody came up with a time when $USERDOMAIN and
hostname differed with a local user logged on.

> 2) Domain users will not execute mkgroup -l nor mkpasswd -l, so they will
>    be missing the local groups (Users, ...) and future logins of local
>    users will see HOME = / .

I kind of assumed that domain users *stay* domain users.  If they switch
then they should have the intelligence(?) to add local users to the
appropriate files.  I was more concerned with domain users never being
added to the passwd/group files and the problems there.

> 3) mkpasswd -d will contact the PDC, which may or may not
> succeed, and which
>    has been reported to take hours to complete. That's dangerous in a
>    postinstall script.

It is *however nobody came forward with anything better*!!!

> SUGGESTION
> It seems desirable to
> - have local users and groups always appear in /etc/passwd and /etc/group

Why?  I never log on locally when running on a network domain...

> - avoid contacting the PDC in postinstall scripts

Which totally messes up domain users no?

> - insure that the user running setup.exe is always included in /etc/passwd

Didn't know I could.

> Thus I suggest adding a switch --current (-c) to mkpasswd and to change
> passwd-grp.sh to

Doesn't exist atm, wasn't a solution I could do.  I still disagree.
Adding the domain users at work is a mear second or so.  Those networks
where it is bigger than that, I'm afraid I can't offer any suggestions
(well, not on a public list! ;)

> *******
> #!/bin/sh
> if [ ! -e /etc/passwd ] ; then
>   /bin/mkpasswd -l -c > /etc/passwd
> fi
> if [ ! -e /etc/group ] ; then
>   /bin/mkgroup -l > /etc/group
> fi
> *******
> The -c switch would produce a line about the current user if he is a
> domain user, without contacting the PDC (using only internal info).
>
> That arrangement will guarantee that the user installing Cygwin
> will always
> have a sane passwd file. Domain users may have group "unknown",

so add a -c to mkgroup too...

> but this has
> no negative side effects. This will cover most cases.
>
> Of course, to perfect the environment, domain users should also run
> "mkgroup -l -d" while they are connected to the PDC, and run
> "mkpasswd -l -d" if they need to know about other domain users.
> They can do that at their leisure.

BUT THEY DON'T UNDERSTAND THIS!  The whole idea was so
*anyone* can install cygwin - local OR domain user and get what
they expect.

> Comments? Suggestions? I volunteer to add "-c".

I think the -c is not a bad idea.  I'll go with the majority
about the domain stuff, but I think it should be there.  Question:
have you a known situation where $USERDOMAIN != hostname and
you weren't logged into a domain?

J.