[comp.sys.sun] Sun-Spots Digest, v5n17

Sun-Spots-Request@RICE.EDU.UUCP (06/04/87)

SUN-SPOTS DIGEST           Thursday, 4 June 1987          Volume 5 : Issue 17

Today's Topics:
                              bug in make(1)
            OOPS IGNORE the "WARNING: about Sun SCSI shorting"
                            Re: mouse problems
                           Re: 'textedit' tool?
                           4.3 acucntrl for SUN
                   Re: query on dump to sun scsi tape?
           Re: taking system down for dumps other than level 0?
                 Re: Request for sendmail.cf (very long)
                 Make your workstation a bit more secure
                      Sun workstations for the home?
                          3rd party disk drives?
                          Color Hard Copy Units?
                        Clean version of dbxtool?
                      sun's ie connected to a DECOM?
                      3.0/3.2 .rhosts and 3.2 diag?
                        Function key programming?

------------------------------------------------------------------------

Date: Thu, 28 May 87 20:54:23 PDT
From: fritz@vlsi.caltech.edu (Fritz Nordby)
Subject: bug in make(1)

Under some conditions, make(1) sets the environment variable IFS to an empty 
string.  This almost guarantees that Bourne shell scripts invoked by make will 
die in bizarre ways.

To repeat, create an empty directory, cd there, and do:

% /bin/sh
$ cat >cc <<FOO
#!/bin/sh
echo \$#
set "\$@"
echo \$#
FOO
$ chmod +x cc
$ cat >makefile <<FOO
foo:    bar
        cc foo bar spam
FOO
$ >bar
$ PATH=:$PATH
$ IFS='         
'
$ # that's IFS='<space><tab><newline>'
$ export PATH IFS
$ cc foo bar spam
3
3
$ make
cc foo bar spam
3
1
$ ^D
% 

The error is the final 1; the
	set "$@"
in cc is expanded to
	set "foo" "bar" "spam"
which, after quote processing, becomes
	set foo bar spam
However, since IFS is an empty string, there are NO FIELD SEPERATORS, so
this sets one positional argument; namely, this is equivalent to
	set 'foo bar spam'
This results in the anomalous "1" output by cc when invoked by make.

The only quick fix I can think of is to have all my shell scripts set IFS
explicitly, and that's a massive kludge, not a fix.

		Fritz Nordby.	fritz@vlsi.caltech.edu	cit-vax!fritz

------------------------------

Date: Tue, 26 May 87 22:10:30 edt
From: cmcl2!seismo!decvax!savax!dove@hp-pcd.UUCP (Webster Dove)
Subject: OOPS IGNORE the "WARNING: about Sun SCSI shorting"

It seems some guys here took the SCSI apart and forgot to reinsert the
plastic shields that prevent the RF fingers from shorting the ribbon
cable at the outer connector.

My apologies for the mistaken information.

				Yr Hmbl Svt

				Web Dove

------------------------------

Date: Fri, 29 May 87 00:20:02 PDT
From: kevin@sun.com (Kevin Sheehan)
Subject: Re: mouse problems

	The problem is that the driver get into a state where it deletes
null characters from the stream.  Pulling the mouse causes the driver to
reset.  Is fixed.

------------------------------

Date: Fri, 29 May 87 09:36:25 PDT
From: ultra!wayne@ames (Wayne Hathaway)
Subject: Re: 'textedit' tool?

I too tried to get 'textedit' to insert a special character into a file (in 
my case a ^G, or BEL).  After fighting the documentation and experimenting 
for a while, I called the Sun Hotline.  While they were very friendly and 
responsive, the bottom line answer was "no way."  (I did find a way, by
using 'cat' to create a file with just a BEL in it and having 'textedit' 
"get from file" it into the appropriate place.)

My real solution?  Use the ^Q "quoted-insert" mechanism -- in GNU Emacs!

        Wayne Hathaway          ultra!wayne@ames.arpa
        Ultra Corporation
        2140 Bering Drive
        San Jose, CA 95131
        408-922-0100

------------------------------

Date: Fri, 29 May 87 18:33:01 EDT
From: budd@bu-cs.bu.edu (Philip Budne)
Subject: 4.3 acucntrl for SUN

As has been said, you shouldn't need acucntrl with the Sun ttyd0/ttym0 dualism.
However, I did it anyway, having had some trouble playing with the devices.

Is acucntrl public source?

	Phil Budne
	Boston University

------------------------------

Date: Sat, 30 May 87 15:52:56
From: H_Eidnes%vax.runit.unit.uninett@tor.nta.no (Havard Eidnes)
Subject: Re: query on dump to sun scsi tape?

In Sun-Spots v5n16 Michal Khaw writes:
> What flags and parameters (other than 'c') are recommended for doing dumps
> to sun3 scsi cartridge tapes?  Should I try to specify tape length, density,
> blocking, and if so, what values should I use?  Is /dev/rst0 or /dev/rst8
> preferable?

On our Suns, we have the tape drives that are both capable of handling
QUIC-11 and QUIC-24, the latter being higher density. If your tape drive
handles both of these, they are respectively /dev/rst0 and /dev/rst8.

We found that using only the "c" argument to dump didn't work very well.
Maybe it worked with the QUIC-11, 300ft tapes, but we use 450ft tapes and
QUIC-24. I use the following command to dump our file systems:

dump ${level}cunbsdf 126 450 10000 /dev/rst8 ${filesystem}

This almost fills up the entire tape. If you're afraid of writing too far,
you may reduce the density (10000) number.

Please note: The above information is something I found by experimenting.
I found the SUN documentation somewhat lacking in precision on this point.
I think I first got the 126 number from an installation instruction for
Sun-Unix 2.0. If some of these parameters should be changed, I'm just
happy to get to know the correct ones.
-------
E-Mail:	<h_eidnes%vax.runit.unit.uninett@nta-vax.arpa> (or @tor.nta.no)
H}vard Eidnes	(or TeXish: H\aa vard Eidnes)
Division of Computer Science, Norwegian Institute of Technology

------------------------------

Date: Sun, 31 May 87 03:00:38 EDT
From: dpz@aramis.rutgers.edu (David P. Zimmerman)
Subject: Re: taking system down for dumps other than level 0?

David,

We have 15+ Unix boxes that we do level 0s weekly and level 1s daily
on, while the machines are up multiuser.  A few are by necessity, one
being in a galaxy far far away on the other end of a T1 line, but most
are just because it is convenient to not have to take all of those
machines down.  We have no problems with backups on those live systems
and restores from those backups.  I wouldn't think that anything
besides an active file would be at risk, if even that.

						dpz

------------------------------

Date: 1 Jun 87 22:29:23 GMT
From: richl%penguin.uss.tek.com@relay.cs.net (Rick Lindsley)
Subject: Re: Request for sendmail.cf (very long)

> From: arnold%umn-cs-fsa@umn-cs.arpa (Doug Arnold)
> Subject: Request for sendmail.cf which works with subdomain style hostnames?
> 
> Can anyone provide a sendmail.cf file which works on a Sun host
> running 3.2 with a four part (subdomain style) hostname (like
> s1.ima.umn.edu)?  I want to be able to send and receive mail from
> machines on the local ethernet directly and on the internet via a (non
> Sun) mailhost which is on the local ethernet.  My request to Sun
> elicited the following response:  the supplied versions of
> sendmail.cf don't work for this type of hostname and require quite
> extensive modifications; such modifications have been successfully
> carried out, but they don't know by whom; why don't I send an appeal over
> Usenet.

Here is a config file which works. It is used on my workstation
(penguin.uss.tek.com). It too will need to be modified, but you should
find it easier to modify to your purposes, I think. It is fairly
stupid, in that it will send directly to all sites in my tertiary
domain, but forward everything else to a "smart" gateway. (See the
classes section.) You can make it smarter by enlarging Ruleset 0.

Sendmail experts may quibble over the choices of representation used
here and may also find some inexplicable chaff in places. This is
probably because this is just a smaller version of the version running
on tektronix, which is much more complex and much larger. We here at
Tek have between 15 and 20 subdomains (or 'tertiary domains', as I've
renamed them at points below), and this config file or something
similar to it works everywhere, whether a site is a gateway or simply a
leaf.

The rewriting rules have been rewritten (!) because while they may have
been all that Berkeley wanted, for us they were alternately
insufficient and overkill. Even non-complex sites may find some of the
newly rewritten rules useful.

Rick Lindsley
richl@penguin.uss.tek.com
...!tektronix!penguin.uss.tek.com!richl

###################################################
#   Macros                                        #
#       L top level domain name                   #
#       D second level domain name                #
#       I tertiary domain I am in                 #
#       F gateway to forward to                   #
#       U The name I wish to tack on my uucp mail #
#       V version number                          #
#       e how smtp should greet people            #
#       j my official hostname (host.domain)      #
#       n the name of the daemon (for errors)     #
#       l the format of the Unix style From_ line #
#       o the set of "operators" (component       #
#         seperators) in addresses                #
#       q default format of sender address        #
#                                                 #
###################################################

# the following steps around a sun sendmail bug
Dwpenguin

DLCOM
DDTEK
DIUSS
DFtektronix
DU$w
De$j Sendmail $v/$V ready at $b
Dj$?I$w.$I.$D.$L$|$w.$D.$L$.
DlFrom $g  $d
DnMAILER-DAEMON
Do.:%@!^=/[]
Dq$g$?x ($x)$.

DV6.19



###################################################
#   Classes                                       #
#       w known names for our local host          #
#       L top level domains which I am already    #
#         a part of                               #
#       R known smtp hosts within our subdomain   #
#       S known TEK domain hosts (for direct      #
#         sending)                                #
#       U names of our local uucp neighbors       #
#                                                 #
###################################################

# the last two provided for compatibility
CLCOM UUCP CSNET

FR/usr/tek/lib/mail/sendmail/uss.hosts

FS/usr/tek/lib/mail/sendmail/tek.hosts

# we have none
#FU/usr/lib/uucp/L.sys %[^ #]

Cwpenguin

###################################################
#   Options                                       #
#       A  alias file                             #
#       a  time to wait for alias file to finish  #
#          rebuilding                             #
#       B  substitute this character for blanks   #
#       c  it's ok to connect to expensive        #
#          mailers                                #
#       d  indicate the default delivery mode     #
#          (one of these)                         #
#          i  interactively                       #
#          b  background                          #
#          q  just queue the message              #
#       D  rebuild database if it is out of date  #
#       F  temp file mode                         #
#       g  default gid for mailers to run as      #
#       H  location of help file                  #
#       L  default log level                      #
#       N  default network name                   #
#       o  assume that space may be delimiting    #
#          names                                  #
#       Q  location of spool directory            #
#       r  time to wait before timing out on      #
#          mail transfers (violates protocols)    #
#       S  location of status file                #
#       s  be sure everything is queued before    #
#          starting transmission                  #
#       T  return mail after this amount of time  #
#       t  time zone names (only referred to when #
#          running V6)                            #
#       u  default uid for mailers to run under   #
#       W  Wizard's password (encrypted)          #
#       x  load average above which we queue      #
#          messages, rather than immediately      #
#          delivering them                        #
#       X  load average above which we refuse     #
#          connections                            #
#                                                 #
###################################################

OA/usr/lib/aliases
Oa10
OB.
Odb
OD
OF0600
Og1
OH/usr/lib/sendmail.hf
OL9
ON$D
Oo
OQ/usr/spool/mqueue
Or2h
OS/usr/lib/sendmail.st
Os
OT3d
OtPST,PDT
Ou1
OW*

Ox3
OX5


##### Ruleset 0 -- rewrite addresses
S0

# first make canonical
R$*<$*>$*		$1$2$3			defocus
R$+			$:$>3$1			make canonical
R$-<@>$*		$#local$:$1		handle special local cases
R@			$#local$:$n		handle <> form

# handle undomained hosts that we know about
R$*<@$=R>		$#smtp$@$2$:$1<@$2>		user@subhost
R$*<@$=S>		$#smtp$@$2$:$1<@$2>		user@tekhost
R$+<@$=U>		$#uucp$@$2$:$1@$2.UUCP		user@uucphost

#
# at this point, we have stuff<@name> or stuff<@name.domain>, with
# possible additional .domain's tacked on after the >. Some of the
# domains may be our own ... we must check for validity. A plain <@name>
# is something we don't know about, and we'll send it to the gateway.
#

# first check our local subdomain
R$*<@$=R>.$I.$D.$=L	$#smtp$@$2$:$1<@$2>.$I.$D.$3	user@subland
R$*<@$=R>.$I.$D		$#smtp$@$2$:$1<@$2>.$I.$D	user@subland
R$*<@$=R>.$I		$#smtp$@$2$:$1<@$2>.$I		user@subland
R$*<@$+.$I>.$D.$=L	$#error$:Host $2 not listed in $I subdomain
R$*<@$+.$I>.$D		$#error$:Host $2 not listed in $I subdomain
R$*<@$+.$I>		$#error$:Host $2 not listed in $I subdomain

# resolve names that belong in the other subdomains (one provided as an
# example)

# ICO
R$*<@$+.ICO>.$D.$=L	$#smtp$@vice$:$1<@$2.ICO>.$D.$3		user@icoland
R$*<@$+.ICO>.$D		$#smtp$@vice$:$1<@$2.ICO>.$D		user@icoland
R$*<@$+.ICO>		$#smtp$@vice$:$1<@$2.ICO>		user@icoland

# resolve names that belong in the TEK domain
R$*<@$=S>.$D.$=L	$#smtp$@$2$:$1<@$2>.$D.$3	user@tekhost
R$*<@$=S>.$D		$#smtp$@$2$:$1<@$2>.$D		user@tekhost

# resolve local UUCP links
R$+<@$=U.$+>.UUCP	$#uucp$@$2$:$1@$2.$3.UUCP	user@host.domain.UUCP
R$+<@$=U>.UUCP		$#uucp$@$2$:$1@$2.UUCP		user@host.UUCP

# other names, both domained and undomained, will be kicked upstairs
R$*<@$*>$*		$#smtp$@$F$:$1<@$2>$3		user@somewhere

# remaining names must be local (no brackets)
R$+			$#local$:$1			everything else



###################################################
#              Delivery Precedences               #
###################################################

Pfirst-class=0
Pspecial-delivery=100
Pbulk=-60
Pjunk=-100

###################################################
#                Trusted Users                    #
###################################################

Troot
Tdaemon
Tuucp
Tmmdf

###################################################
#             Format of Headers                   #
###################################################

H?P?Return-Path: <$g>
HReceived: $?sfrom $s $.by $j ($v/$V)
	id $i; $b
H?D?Resent-Date: $a
H?D?Date: $a
H?F?Resent-From: $q
H?F?From: $q
H?x?Full-Name: $x
HSubject:
H?M?Resent-Message-Id: <$t.$i@$j>
H?M?Message-Id: <$t.$i@$j>




###################################################
###################################################
##            Rewriting Rules                    ##
###################################################
###################################################

##### Ruleset 1 -- Sender Field Rewriting
S1

##### Ruleset 2 -- Recipient Field Rewriting
S2

##### Ruleset 3 -- Name Canonicalization
#			  -or-
#               Making Things Useful for Us
#
# final form when we leave this rule set will be simply
#	rest-of-addr<@site>
# to indicate where this message is going to next.  Local mail is indicated
# by a lack of angle brackets in the finished product.
#
S3

# handle "from:<>" special case
R<>			$@@				turn into magic token

# basic textual canonicalization -- note RFC733 heuristic here
# if there are angle brackets, they take precedence over anything
R$*<$*<$*<$+>$*>$*>$*	$4			3-level <> nesting
R$*<$*<$+>$*>$*		$3			2-level <> nesting
R$*<$+>$*		$2			basic RFC821/822 parsing
R$+ at $+		$1@$2			"at" -> "@" for RFC 822

# make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later
R@$+,$+			@$1:$2			change all "," to ":"

# take care of VMS-looking addresses -- we'll make them look uucp-ish
# because that's easiest. At the gateway into vms land they will be
# properly converted anyway.
R$+::$+			$1!$2

# localize and dispose of route-based addresses
R@$+:$+			$@$>5<@$1>:$2		handle <route-addr>

# more miscellaneous cleanup
R$+:$*;@$+		$@$1:$2;@$3		list syntax
R$+:$*;			$@$1:$2;		list syntax
R$+@$+			$:$1<@$2>		focus on host.domain
R$+<$+@$+>		$1$2<@$3>		look at rightmost host.domain
R$+<@$+>		$@$>5$1<@$2>		already done

# convert old-style addresses to a domain-based address
R$-:$+			$@$>5$2<@$1>		host:user
R$+^$+			$1!$2			convert ^ to !
R$-.$+!$+		$@$>5$3<@$1.$2>		host.domain!user
R$-!$+			$@$>5$2<@$1>		host!user
R$+%$+			$:$>6$1@$2		user%host
R$*@$*			$@$>5$1<@$2>		NOW we are ready to call 5

##### Ruleset 4 -- Final Field Rewriting
S4
R@			$@			handle <> error addr
R$*<@>$=R		$?I$1<@>$2.$I$|$1<@>$2$.
R$*<@$=R>		$?I$1<@$2.$I>$|$1<@$2>$.
R$*<$+>$*		$1$2$3			remove angle brackets
R@$+:@$+:$+		@$1,@$2:$3		<route-addr> canonical

# delete duplicate local names
R$+%$=w%$=w		$1%$3			u%host%host => u%host
R$+%$=w@$=w		$1@$3			u%host@host => u@host

##### Ruleset 5 -- exclude as many recognizable domains as possible, and
#                  ourselves as well. Only internal tertiary domains will
#                  remain within the <>s.
S5
R$*<@$+.$=L>$*		$:$1<@$2>.$3$4		exclude own top level domains
R$*<@$+.$D>$*		$:$1<@$2>.$D$3		exclude our own domain
R$*<@$=R.$I>$*		$:$1<@$2>.$I$3		exclude subdomain, if member

# now exclude the local site, if present
# we may easily have a case where the site name and the domain name are
# the same -- the next line checks to see if a "." is present
#
R$*<$*.$=w>$*		$@$1<$2.$3>$4		case of domain == site;leave it!
R$*<$*$=w>$*		$1<$2>$3$4		
R<@>:$*			$@$>3$1			retry after route strip
R$-<@>$*		$@$1<@>$2		must be local
R$*<@>$*		$@$>3$1			strip useless trash & retry

##### Ruleset 6 -- change rightmost % to @.   
S6
R$*%$*			$1@$2			First make them all @'s
R$*@$*@$*		$1%$2@$3		Undo all but the last.
R$*@$*			$@$1@$2			Put back the brackets.



##### Ruleset 10 -- Sender address rewriting for local and program mail
S10
R@			$n			errors to mailer-daemon

##### Ruleset 11 -- convert @s and %s to !s for uucp
S11
R$+			$:$>14$1
R$+			$:$U!$1			stick on our host name

##### Ruleset 12 -- convert @s and %s to !s for uucp

# some trickery going on here. The $: portion of the mailer (user to mail to)
# will also pass through here. We want to strip the destination host from
# that name, but we DON'T want to strip it from any other addresses. So
# in the $# mailer invocation in ruleset 0, we DON'T put angle brackets
# in the name. All
# other sites will have had angle brackets added because they passed through
# ruleset 3. The last three rules here strip out the destination site, add
# angle brackets, re-rewrite the address. In addition, a dummy domain,
# .XXXX is added because we don't want ANY @'s in this rewriting, whereas
# we've made a policy decision that if a properly formatted user@host
# spec comes through, we will leave it alone.

# another consideration: how to handle addresses like a!user<@b>. We may
# be handed this if the original path looked like "b!a!user". So we have
# a special set of rules for that case (ruleset 22).

S12
R$+<@$+>$*.UUCP		$1<@$2>$3		strip off .UUCP, if present
R$*.XXXX		$@$>14$1		process user field
R$-<@$+>$*		$@$1<@$2>$3		if properly domained, don't mess
R$+			$@$>14$1		finish processing

##### Ruleset 13 -- handle mixed @'s and !'s (@'s and %'s get precedence)
S13
R$+%$+<@$+>$*:::$+	$2<@$3>$4:::$1!$5
R$+<@$+>$*:::$+		$2$3!$1!$4

##### Ruleset 14 -- convert @s and %s to !s for uucp (!'s get precedence)
#		    it is possible we have the $: user specification from
#                   the mailer invocation (no angle brackets <>)
S14
R$+!$+%$+<@$+>$*	$@$>13$3<@$4>$5:::$1!$2
R$+!$+<@$+>$*		$@$3$4!$1!$2
R$+%$+<@$+>$*		$@$>13$2<@$3>$4:::$1
R$+<@$+>$*		$@$2$3!$1		handle user@host case (no %s)
R$*<@>$*		$@$1			local, or something

# must be the $: field
R$*@$+			$1			remove rightmost
R$+%$+			$:$>6$1%$2		get a new @site
R$+@$+			$>12$1<@$2>.XXXX	redo, with brackets this time

##### Ruleset 20 -- No-op rewriting
S20

###################################################
#              Mailer Descriptions                #
###################################################

Mlocal,	P=/bin/mail, F=rlsDFMmn, S=10, R=20, A=mail -d $u

Mprog,	P=/bin/sh,   F=lsDFMe,   S=10, R=20, A=sh -c $u

Muucp,	P=/usr/bin/uux, F=DFMhuU, S=11, R=12, M=100000,
	A=uux - -r -z -a$f -gB $h!rmail ($u)




Msmtp,	P=[IPC], F=mDFMueCX, S=17, R=20, A=IPC $h

##### Ruleset 17 -- Sender address rewriting for ethernet
#                   if it is in uucp ! format, let's just leave it that way ok?
S17
R$-!$+<@$+>$*		$:$>12$1!$2<@$3>$4	if in ! format, rewrite @s to !s
R$~w!$*			$w!$1!$2		.. prepend our name
R$=w!$*			$@$w!$2			... all done
R$*<@$+>$*		$@$1<@$2>$3		already ok
R$*<@>$+		$@$1<@>$2		also ok
R$+			$@$1<@>$w		tack on our hostname

------------------------------

Date: 1 Jun 87 22:09:39 GMT
From: richl%penguin.uss.tek.com@relay.cs.net (Rick Lindsley)
Subject: Make your workstation a bit more secure

One common problem is that as computers shrink, they are moving to
desktops, and as they move to desktops, they become increasingly
accessible. On my Sun, for instance, anybody who happens to walk by
machine could halt it, bring it up single user, and do whatever they
wanted to (which may not agree at all with what *I* wanted!).

That is, until now.

I offer this simple little program as a means of foiling these people.
Chkpass will verify a password from within a shell script, which means
you can now put something in /.profile to prompt for root's password.
Everytime the system comes up (or goes down) single user, someone must
now supply a root password. Or more accurately, just "a" password -- it
need not be root's. I've made it root on mine, but if you want to make
it something else, be my guest. Here's my /.profile, using chkpass from
/local:

stty erase ^H kill ^U
PATH=/etc:/usr/etc:/usr/ucb:/bin:/usr/bin:/local
export PATH TERM
if [ `tty` = /dev/console ]
then
    trap '' 2 3
    ok=no
    while [ $ok = no -a -f /local/chkpass ]
    do
	/local/chkpass root
	case $? in
	    0) ok=yes;;
	    1) echo Sorry;;
	    2) echo Something\'s wrong with passwd; I\'ll allow you this time.
		ok=yes ;;
	    3) echo chkpass improperly invoked\; allowing root for now....
		ok=yes;;
	    *) echo unknown error status from chkpass\; allowing root for now ...
		ok=yes;;
	esac
    done
    trap 2 3
fi

The sanity check for /dev/console requires that "tty" be somewhere on
the root disk, which it normally isn't. For my purposes, I put a copy
in /local with chkpass. You can do without this sanity check if you
wish; it just might make people supply the password twice in some
situations.

Of course, one must be very careful when messing with /.profile, so for
that reason the above code provides an "out" in many situations. See
the man page below for a description of the exit codes.

So far as I know, this method, though simple, is secure. Keyboard
generated interrupts are ignored during the password prompting by both
/.profile and chkpass. (/bin/sh can't ignore TSTP, but then if your
single-user shell is /bin/sh, it won't be generated either, so ....)
The beauty of it is you don't need to modify any existing utilities if
you don't want to (though one may argue init is the program that should
be doing this sort of thing.)

Suggested modifications are welcome, but one thing I like about this
program the way it is right now is it fits so nicely into shell scripts
as a general purpose tool.

Rick Lindsley
richl@penguin.uss.tek.com
...!tektronix!penguin.uss.tek.com!richl

.TH CHKPASS 1 "April 23, 1987"
.SH NAME
chkpass \- get a password from within a shell script
.SH SYNOPSIS
\fBchkpass\fP \fIuser\fR [prompt]
.SH DESCRIPTION
Chkpass prompts for a password on /dev/tty (via \fIgetpass(3)\fR) and
verifies it with the entry for \fIuser\fR in /etc/passwd.
.LP
If the password field in /etc/passwd is null, then chkpass will not
ask for a password, and is essentially a no-op.
.LP
The second argument, the prompt, is optional. If it contains white space
or characters special to the shell, it will need to be quoted.
.SH EXAMPLES
.nf
.in +0.5i
% chkpass richl
Password:
%
.sp 2
% chkpass richl "Gimme key:"
Gimme key:
%
.fi
.SH "EXIT CODES"
An exit code of 0 indicates a correct password, or no password necessary.
.sp
An exit code of 1 indicates an incorrect password.
.sp
An exit code of 2, as well as a message to stderr, indicates the user was
not listed in /etc/passwd.
.sp
An exit code of 3 indicates chkpass was invoked without the requisite
\fIuser\fR argument, and provokes a usage message.
.SH FILES
/etc/passwd
.SH "SEE ALSO"
getpass(3)
.SH AUTHOR
Rick Lindsley, Unix Systems Support, Tektronix

#include <stdio.h>
#include <signal.h>
#include <pwd.h>

/*
 * chkpass --	prompt for a password and check that it is correct.
 *		The first argument is required, and is the user name
 *		to check against. The second is optional, and is the
 *		prompt desired. Keyboard generated signals are ignored,
 *		thus this can safely be used from shell scripts.
 */

main(argc,argv)
int argc;
char **argv;

{
    register struct passwd *pw;
    register char *pass, *encrypted;
    char *getpass(), *crypt();

    (void) signal (SIGINT,SIG_IGN);
    (void) signal (SIGQUIT,SIG_IGN);
    (void) signal (SIGTSTP, SIG_IGN);
    if (argc != 2 && argc != 3) {
	fprintf(stderr,"usage: chkpass username [prompt]\n");
	exit(3);
	}
    if ((pw = getpwnam(argv[1])) == NULL) {
	fprintf(stderr,"chkpass: can't find user \"%s\" in /etc/passwd\n",
	    argv[1]);
	exit(2);
	}
    if (pw->pw_passwd && strcmp(pw->pw_passwd, "")) {
	pass = getpass(argc == 2 ? "Password:" : argv[2]);
	encrypted = crypt(pass, pw->pw_passwd);
	if (strcmp(encrypted, pw->pw_passwd))
	    exit(1);
	else
	    exit(0);
	}
    else
	exit(0);
}

------------------------------

Date: Thu, 28 May 87 15:34:27 CDT
From: hood@themis.rice.edu (Robert Hood)
Subject: Sun workstations for the home?

Suppose one wanted to have a workstation with a disk drive but not connected
to an Ethernet (at home) that needed to share files with a remote network
(at work).  The machine at home would be connected to the network with a
dedicated phone line (perhaps 9600 baud.)

In particular, I want to be able to edit program source files, compile them,
and then run the executable--both at work and at home.  (There are 105000 *lines* of source code and the executable is over 3 megabytes.)

Is there any software that would help manage this?  Ideally, one could
imagine some variant of NFS that allowed multiple copies of a file to exist
on different servers (and kept them consistent).  Failing that, is there
some reasonably painless way to transmit updates to source files back and forth?
(It would be nice to just transmit differences between files, but I might be
willing to settle for entire file.)

Has anybody else run into similar problems, and if so, what solutions have
been used?

Robert Hood
hood@rice.edu

------------------------------

Date: Thu 28 May 87 14:01:55-PST
From: SPRINGER@star1.stanford.edu (George Springer)
Subject: 3rd party disk drives?

	Earlier this year we got a standalone Sun-3/160 with a Fujitsu 2322
130Mbyte SMD drive and a Xylogics 450 controller. We're running short of
disk space faster than expected so we're in the market for another drive that
could be hooked up to this controller without conflict with the 1st drive.

	As is usual in academic situations, money is tight. On the other hand,
our expertise with this stuff is very limited - we don't want to have to
write our own device drivers.

	So if you can suggest a drive model that we should investigate
and/or a place to buy them that offer good prices, we would greatly appreciate
it.

	Thank you for your help

------------------------------

Date: 29 May 87 12:42:38 GMT
From: mrs@philabs.philips.com (Mark R. Simpson)
Subject: Color Hard Copy Units?

I  am  interested  in any comments, suggestions, or recommendations about
equipment for producing color hard copy from a color  workstation.   The
color  images  will  range from simple 4/8/16-color business plots (like
those produced by  DISSPLA  or  CricketGraph)  up  to  realistic  shaded
images.   However,  the most common images will be from Solid Modelling/
Finite Element Analysis type programs  on  a  color  SUN  3/260  (8  bit
planes).

It would be nice if the color hard copy unit could be used by  different
types  of  workstations  (we  have  SUNs, APOLLOs, an IRIS and a PIXAR).
Furthermore, since all our computers are connected by a LAN, a unit that
connects to a local ethernet(TCP/IP) would be a plus.

Some specific units I have heard of are:
 
   1) Shinko CHC-65
   2) Tektronix 4692
   3) Seiko CH-5300
   4) Color Versatec

If you have experience with any of these products  or  others you
believe deserve mentioning, please e-mail me your comments and
I will post a summary to the net.

Possible considerations are:

  1) cost
  2) copy quality (e.g. number of colors, how closely colors match those
     displayed on the screen, etc.)
  3) paper sizes it supports (A,A4, etc.)
  4) how it operates. For example, do images need to be displayed
     to be copied? Is it connected directly to the RGB lines?
  5) print mechanism. Is it a camera, an electrostatic plotter, ink jet
     plotter?


Thanks in advance,

Mark Simpson
Philips Laboratories
Briarcliff Manor, NY 10510
(914) 945-6163  


P.S.:

Recently, there was a similar request posted to the net,  but  I  never
saw the summary.

------------------------------

Date: 31 May 87 01:34:04 GMT
From: ucsbcsl!bertrand@seismo.css.gov (Bertrand Meyer)
Subject: Clean version of dbxtool?

	Our version of dbxtool on the Sun-3 has the unpleasant tendency
to die without warning or possible recovery. Does anyone have a clean
version?

Bertrand Meyer, Interactive Software Engineering
270 Storke Road, Suite 7 - Tel (805) 685-1006
Goleta, CA 93117

------------------------------

Date: Thu, 28 May 87 22:42:12 EDT
From: schoff@nic.nyser.net (Martin Lee Schoffstall)
Subject: sun's ie connected to a DECOM?

I would like to attach my sun3/260 ethernet interface (ie) to a DEC DECOM.
I tried to do this awhile ago for fun with little success, NOW I find
it is necessary.  I believe that the problem is the heartbeat.  Has anyone
solved this problem for the decom (by modifying the ie driver) or for
any of the other ethernet in a broadband situations?

marty schoffstall

------------------------------

Date: Sat, 30 May 87 0:18:20 EDT
From: scs%lokkur%itivax.uucp@eecs.umich.edu (Steve Simmons)
Subject: 3.0/3.2 .rhosts and 3.2 diag?

  We have noticed an interesting and frustrating bug in the
treatment of the .rhosts files on Suns under 3.0 and 3.2.  If
there is trailing whitespace on the id mentioned, it is treated
as part of the id and hence the id no longer works.  Eg, the
following line in /.rhosts on system "fred"
  "admin root"
will let root@admin rlogin immediately, but the line
  "admin root "
will refuse the connection.

Also, we have been using CDC-9771 drives with our Sun-2 and Sun-3 systems
for some time now, and had reasonable luck.  When converting to 3.2,
it seems like any time we touch the disk with 'diag' the disk shortly
thereafter becomes corrupt.  Sometimes labels are lost, sometimes
boot blocks are destroyed, etc, etc.  We have one major suspect in
that some things changed between 3.0 and 3.2 'diag'.  For one thing,
3.2 asks for some block size and interleave data which 3.0 did not.
Does anyone out there know what defaults the 3.0 systems used, so
we can put in the "hopefully" right answers while bringing up diag?
If we diag and partition under 3.0, then load and setup with 3.2,
things seem to go fine.  Wierder and wierder...


Many thanks,
  Steve Simmons

------------------------------

Date: Sat, 30 May 87 19:20:13 PDT
From: weitek!sci!daver@sun.com (Dave Rickel)
Subject: Function key programming?

This is probably old hat, but does someone know how to program the
function keys (F1-F9)?  I want to turn off F1--it's too close to the
escape key.

decwrl!sci!daver

------------------------------

End of SUN-Spots Digest
***********************