This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
heck. Watch through our hidden camera, ladies and gentlemen,
as this one-line addition to the syslog output generates hundreds
of thousands of lines of email in response, all from people
decrying the evils of electronic noise pollution! :-)
What this change does, simply speaking, is syslog it every time
someone changes their local password. I need this at a local ISP to
tell whether people are reacting to expires in a timely fashion or
not. To disable it, uncomment -DLOGGING in the Makefile.
If your users change their passwords so often as to fill your logfile,
then you may also have another administrative problem to deal with.
option to pwd_mkdb and adding this option to utilities invoking it.
Further, the filling of both the secure and insecure databases has been
merged into one loop giving also a performance improvemnet.
Note that I did *not* change the adduser command. I don't read perl
(it is a write only language anyway).
The change will drastically improve performance for passwd and
friends with large passwd files. Vipw's performance won't change.
In order to do that some kind of diff should be made between the
old and new master.passwd and depending the amount of changes, an
incremental or complete update of the databases should be agreed
upon.
Changing a local passwd will now keep the encryption type that
was originally used to encrypt the password, so folks adding DES
to their systems will not be irritated/confused by having MD5'ed
passwords in their master.passwd. Coming later is an option to
allow the user to choose the encryption type.
2) Fix a bunch of compiler warnings announced by turning on -Wall.
I did not get them all, that will come a bit later.
The #ifdef NEWSALT code doesn't NULL terminate the salt string..
We dont appear to use this code anymore, but it shouldn't hurt
Submitted by: Laurence Lopez <lopez@mv.mv.com>
correctly whether a user is local or NIS (or both, or neither). If you
have a user that exists locally but not in NIS, passwd(1) could get
confused and try to submit the password change to NIS. (Fortunately,
yppasswdd is smart enough to spot the error and reject the change.)
Bug reported by: Charles Owens <owensc@enc.edu>
Change things slightly so this message says "local" or "YP" as needed
so we can use it for both NIS and local password changes without
confusing people.
