[326] in NetBSD-Development
Re: Some notes on installation
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Dec 28 15:10:23 1994
To: yoav@MIT.EDU
Cc: ghudson@MIT.EDU, netbsd-dev@MIT.EDU
In-Reply-To: Your message of "Wed, 28 Dec 1994 10:28:18 EST."
<199412281528.KAA12466@lola-granola.MIT.EDU>
Date: Wed, 28 Dec 1994 15:10:22 -0500
From: Greg Hudson <ghudson@MIT.EDU>
Let me try one more time.
>> Let me repeat this one more time: the NetBSD system assumes that
>> /etc/master.passwd is the source form for passwords. The most obvious
> so? we make sure that it stays like the source form.
No, your scheme makes /etc/passwd.local the source form for password
information. If I want to change a password on the local machine with
your scheme, I need to edit /etc/passwd.local; however, any password
utility written for NetBSD will edit /etc/master.passwd and have their
changes invalidated on the next reactivate.
This is why the Athena scheme needs rethinking.
>> the passwd program edits /etc/master.passwd
> no greg.. the passwd program edits all four.
It edits /etc/master.passwd and regenerates the other three, which is
not the same as editing all four. At any rate, the relevant point is
that /usr/bin/passwd does NOT edit /etc/passwd.local, which under the
Athena scheme means it doesn't have any real effect.
> Whatever.. I'll try and get the /bin/login working, and then you
> tell me what seems to be missing.. I REALLY don't like breaking the
> athena concept and making logins more complex unless there is no
> alternative..
How does my scheme make logins more complex? On the contrary, I would
say that it makes password cleanup and maintenance simpler by
following the base operating system scheme. The only difference at
login time is using "*temp*" instead of "*" in automatically-generated
passwd fields.
I would like to get some other opinions on this. So far, the only
arguments against this scheme have been, "I don't understand what's
wrong with the old scheme," "This isn't the way Athena does it," and
an unsupported implication that my scheme is more complicated. If we
do adopt my scheme (and I would like to) and after we test it for a
while, I'm going to propose that Athena switch to it.
> smae way that the current athena login handles this.. nothing has
> changed, current login code already removes you from the passwd
> file, and all I do is remove you from that, plus the other three
> (which you were added to previously)
"Same way that the current athena login handles this" is "badly". The
Athena /bin/login removes you from the passwd file if it added you,
which creates this problem:
xterm 1 xterm 2
------- -------
Log into pesto
Log into pesto
Log out of pesto
pesto% whoami
whoami: cannot find username for UID 3622
Also, neither /bin/login nor xlogin cleans up the /etc/group file, so
they don't actually reduce very much clutter. I would much rather see
/bin/login and xlogin leave the passwd file alone on logouts, and let
reactivate clean it up.
(Incidentally, reactivate doesn't have to be the time when cleanup
occurs; you could pretty easily write a script that cleans up all
temporary password entries except for the ones who are in
/var/run/utmp, and have it run periodically. This would be important
for implementing my scheme on the dialups, but I'm not going to
implement it for NetBSD right now.)
