Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bionet!ames!pacbell!rtech!cpsc6a!wrdso!hoffman
From: hoffman@wrdso.ATT.DSO (Paul Hoffman)
Newsgroups: comp.unix.i386
Subject: Re: Shadow passwords
Summary: Run "/usr/bin/pwconv" to synch passwd & shadow
Message-ID: <185@wrdso.ATT.DSO>
Date: 27 Dec 89 19:07:29 GMT
References: <6637@pbhyf.PacBell.COM>
Distribution: usa
Organization: AT&T Data Services, Pleasanton CA USA
Lines: 27

In article <6637@pbhyf.PacBell.COM>, jdp@PacBell.COM (Jerry D. Pierce) writes:
> couple of questions in regards to shadow passwording...I pretty much keep 
> the password file in UID (numeric) order by directly editting... 
> I am more than a little leery to try this.  
> I also remember reading awhile back in the AT&T release notes for a
> 3B2/700 I was upgrading, something about "shadow passwording is not 
> compatible with all applications, the general symptom is you will 
> not be able to log into the machine."  Or something similar.  Anyone
> had any problems??

See if you have a command "/usr/bin/pwconv".  On Sys V Rel 3.2.1 & 3.2.2 this
will rebuild your shadow file to match your password file.  The documentation
warns against directly editing /etc/passwd, but then tells you if you do to
rerun /etc/pwconv to ensure there is no incompatibility between the two.
I have been doing this for over a year w/ no trouble.

Re: incompatibility:  The only thing which broke when I converted to running
/etc/shadow was remote login authorization over a fiber interface to a 
DATAKIT VCS node.  Newer interface software on the 3B solved that.  (I didn't
care much anyway...the users could still get in through the login prompt over
the fiber...They just could not map themselves directly into their login on
this system automatically.)

If you decide against shadow, the command "/usr/bin/pwunconv" goes back to 
having encrypted password info in /etc/passwd.

Paul Hoffman