Xref: utzoo comp.unix.admin:130 comp.unix.shell:185
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!rutgers!njin!princeton!mccc!pjh
From: pjh@mccc.uucp (Pete Holsberg)
Newsgroups: comp.unix.admin,comp.unix.shell
Subject: Re: Logging a User Off
Message-ID: <1990Sep15.002036.17056@mccc.uucp>
Date: 15 Sep 90 00:20:36 GMT
References: <1990Sep11.173008.274@mccc.uucp> <544@fciva.FRANKLIN.COM>
Reply-To: pjh@mccc.edu (Pete Holsberg)
Organization: The College On The Other Side Of Route One
Lines: 33

In article <544@fciva.FRANKLIN.COM> dag@fciva.UUCP (Daniel A. Graifer) writes:
=In article<1990Sep11.173008.274@mccc.uucp> pjh@mccc.uucp (Pete Holsberg) writes:
=>For reasons that are beyond the scope of this question, all new logins
=>on one of my systems (3B2.400 SVR3.1) get no initial password.  I've
=>written a little script that I put into /etc/profile.  It examines the
=>password field of /etc/passwd for the user logging in and runs the
=>passwd program if the password field is empty.  
=>...
=>Pete
=
=Most of the responses I've seen have concentrated on bombing out a login.  In
=fact, at some point, AT&T added a mechanism to do exactly what you want.  My
=version of AT&T unix (Prime Sys V 3.1 r2) permits 'aging' of passwds (which
=are actually stored in the /etc/shadow file).

	Unfortunately, AT&T SVR3.1.2 doesn't have shadow passwords,
	and login thinks that ",.." in the password field of /etc/passwd
	is a password!

=I see you are on a SV machine, so you should check the passwd(1M) entry for
=the -s (status), -l (lock), -x (expire days), -n(minimum days), and -f (force
=change at next login) options.  

	I am, but your SV is better than my SV!  I do not have passwd(1M).

Thanks, anyway!

Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91