Sun-Spots Digest, v7n16

William LeFebvre Sun-Spots-Request at Rice.edu
Sat Nov 19 00:07:15 AEST 1988


SUN-SPOTS DIGEST       Wednesday, 16 November 1988     Volume 7 : Issue 16

Today's Topics:
                              Administrivia
                      Re: Problems with dump on 4.0
                       Re: /var/spool/lpd/err files
           Re: Sun and ksh method needed to get shelltool info
                        Re: Silicon Graphics Tapes
                           Contool 2.0, patch 2
                      sysdiag and other virus risks
                     Gammontool Bug, Yes. Cheats? No.
                        Kudos to William LeFebvre

Send contributions to:  sun-spots at rice.edu
Send subscription add/delete requests to:  sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
    TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY".  They are also accessible
through the archive server:  mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.

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

Date:    Wed, 16 Nov 88 15:45:41 CST
From:    William LeFebvre <phil at Rice.edu>
Subject: Administrivia

My apologies for being so slow with the digests recently.  I have been
busy with two separate projects:  getting the software ready to let
comp.sys.sun go undigested, and testing out a new mail gateway by
running sun-spots mailings from it.  Hopefully, this will be the last (or
maybe second to last) digest to be posted to comp.sys.sun.  After this,
individual messages will be posted.  I have sludged through all the
backlogged requests to make sure that those wanting to keep the digested
format were added back to the main list.

Let me stress that those who receive Sun-Spots directly via mail or via
the Bitnet list server will see no change in the format.  This change will
only affect Netnews (readnews, rn, NNTP, etc.) readers.

I will post an introductory note to comp.sys.sun when the change takes
effect.

	William LeFebvre

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

Date:    Tue, 08 Nov 88 11:30:47 SET
From:    Danielle Heinzer <ESC1298 at ESOC.BITNET>
Subject: Re: Problems with dump on 4.0
Reference: v6n278

> The second problem is like this. I wrote two small dumps onto one
> tape. Itried to read the second one with:
> /usr/etc/restore ibfs 1750 /dev/rst0 2
> Restore then demands the second volume.

I had the same problem. I dumped two partitions onto one tape by doing the
following:

     /usr/etc/dump 0ucf /dev/nrst8 /dev/rsd0a
     /usr/etc/dump 0ucf /dev/nrst8 /dev/rsd0d
     mt -f /dev/rst8 offline

To read the table of contents of the second dump of the tape, I did:

     mt -f /dev/rst8 rew
     /usr/etc/restore tfs /dev/nrst8 2

Restore asked me for volume 2.  Entering :

     /usr/etc/restore tfs /dev/nrst8 3

gave me the good table of contents. But I don't know why !!

Danielle Heinzer
ESA Computer Department/Computer Services
European Space Operations Centre
Robert-Bosch-str. 5
6100 Darmstadt
West-Germany
Tel int : 49-6151-886540

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

Date:    Tue, 8 Nov 88 10:16:01 EST
From:    David Wiseman <magi%uwocsd.uwo.ca at cornellc.cit.cornell.edu>
Subject: Re: /var/spool/lpd/err files
Reference: v7n6

In SunSpots v7n6, bparent%sdcc7 at ucsd.edu (Brian Parent) suggested a rather
nice fix for the Transcript/lpd problem that caused the transcript filter
output to end up in an lpd bit bucket. It was very clever. Unfortunately,
on my system, it did not work.

It appears to me, from what Brian suggested, that pscomm is assumed to
know what to do with the JOBOUTPUT variable. Mine didn't. I don't know if
this is because it is an older or newer version of Transcript (I haven't
checked).

However, a small modification to his .options file (options to my
Transcript) will make it work. In fact, it should work for any version of
Transcript. Here it is:

        log=/var/spool/ps800/ps800-log
        err=/var/spool/ps800/err*
        it=/var/spool/ps800/filter_diags

        test -r $it  && cat $it >>$log
        test -r $err && rm -f $it && ln $err $it

The above code should be added to the end of the options file. Basically,
instead of relying on JOBOUTPUT, simply grab the err* file that lpd
creates.  I am, of course, assuming that /var/spool/ps800/err* will be
expanded by the shell. Note also that I am running SunOS 4.0: your log
files may differ.

Finally, it should be pointed out that the captured filter messages will
not show up in the log file until the next job prints. This is better than
not showing up at all.

magi    David Wiseman, Network Manager
        Department of Computer Science
        The University of Western Ontario
        London Ontario Canada N6A 5B7

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

Date:    Mon, 7 Nov 88 17:42:30 GMT
From:    mmm at inf.rl.ac.uk (Mark M. Martin)
Subject: Re: Sun and ksh method needed to get shelltool info
Reference: v7n5
Organization: Rutherford Appleton Laboratory, Didcot. UK.

In Sun-Spots Digest, v7n5 n8emr!lwv at sun.com (Larry W. Virden) writes
> I have a set of aliases to talk to the shelltool, but do not know how to
> write the report aliases/functions properly
> 	stty raw -echo; echo "$ESC[11t\c" >/dev/tty ;read -r resp;stty echo -raw

I use good old dd.  Here is an excerpt from a /bin/sh script using it:
(note you mustn't type while the interrogation is going on.)

reportlabel=${esc}'[21t'	#  returns $label<label>$endtext
reporticonlabel=${esc}'[20t'	#  returns $iconlabel<label>$endtext
reportificonic=${esc}'[11t'	#  returns $open or $close
reportposition=${esc}'[13t'	#  returns $move<numy>numsep<numx>endnum
reportpixsize=${esc}'[14t'	#  returns $pixsize<numw>numsep<numh>endnum
reportcharsize=${esc}'[18t'	#  returns $charsize<numh>numsep<numw>endnum

		case $1 in
		iconlabel\?)	report=$reporticonlabel
				pattern='s/^...\(.*\)..$/\1/';;
		label\?)	report=$reportlabel
				pattern='s/^...\(.*\)..$/\1/';;
		move\?)		report=$reportposition
				pattern='s/^....\(.*\);\(.*\)t$/\2 \1/';;
		close\?)	report=$reportificonic
				pattern='s/.*1.*/false/
					s/.*2.*/true/';;
		open\?)		report=$reportificonic
				pattern='s/.*2.*/false/
					s/.*1.*/true/';;
		pixsize\?)	report=$reportpixsize
				pattern='s/^....\(.*\);\(.*\)t$/\2 \1/';;
		charsize\?)	report=$reportcharsize
				pattern='s/^....\(.*\);\(.*\)t$/\2 \1/';;
		*)		echo "$0: $1 not known. give no args for usage"
				exit 1;;
		esac
		stty raw >/dev/tty
		echo -n "$report" >/dev/tty
		ch=`dd </dev/tty count=1 2>/dev/null`
		stty cooked >/dev/tty
		echo "$ch" | sed "$pattern"

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

Date:    Tue, 08 Nov 88 13:20:12 SET
From:    Danielle Heinzer <ESC1298 at ESOC.BITNET>
Subject: Re: Silicon Graphics Tapes
Reference: v7n1

> We have some software on a cartridge tape that was written on
> Silicon Graphics Workstation... We would like to read it on a
> Sun 3/60.

We have the following intructions from Silicon Graphics:

To write the tape on the Silicon Graphics, enter:

     find * -print : cpio -oBcv : dd bs=5120 of=/dev/tape

To read the tape on the Sun, enter:

     dd conv=swab bs=5120 if=/dev/rst8 : cpio -iBcdv

Danielle Heinzer
ESA Computer Department/Computer Services
European Space Operations Centre
Robert-Bosch-str. 5
6100 Darmstadt
West-Germany
Tel int : 49-6151-886540

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

Date:    Thu, 20 Oct 88 09:47:41 EDT
From:    Chuck Musciano <chuck at trantor.harris-atd.com>
Subject: Contool 2.0, patch 2

Patch 1 for contool introduced an annoying "feature" of duplicating
internal error messages in the console when contool was started from the
.suntools file.  This patch fixes the bug.

Chuck Musciano
Advanced Technology Department
Harris Corporation
(407) 727-6131
ARPA: chuck at trantor.harris-atd.com

[[ The shar file is only 3498 bytes, so I am going to include it here.  I
will also place a copy in the archives.  --wnl ]]

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  patch
# Wrapped by chuck at melmac on Thu Oct 20 09:39:16 1988
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'patch' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'patch'\"
else
echo shar: Extracting \"'patch'\" \(2542 characters\)
sed "s/^X//" >'patch' <<'END_OF_FILE'
X*** contool.c.orig	Thu Oct 20 09:30:11 1988
X--- contool.c	Thu Oct 20 09:38:54 1988
X***************
X*** 61,67 ****
X  
X  /*************** End of site dependencies ******************************/
X  
X! #define		TOOL_LABEL		"<< Console Tool 2.0a >>"
X  
X  #define		MAX_FILTERS		64
X  
X--- 61,67 ----
X  
X  /*************** End of site dependencies ******************************/
X  
X! #define		TOOL_LABEL		"<< Console Tool 2.0b >>"
X  
X  #define		MAX_FILTERS		64
X  
X***************
X*** 174,179 ****
X--- 174,191 ----
X  /************************************************************************/
X  
X  /************************************************************************/
X+ static	internal_message(a, b, c, d, e, f)
X+ 
X+ int	a, b, c, d, e, f;
X+ 
X+ {	char	buf[512];
X+ 
X+ 	sprintf(buf, a, b, c, d, e, f);
X+ 	time_stamp();
X+ 	do_insertion(buf, strlen(buf));
X+ }
X+ 
X+ /************************************************************************/
X  static	internal_error(a, b, c, d, e, f)
X  
X  int	a, b, c, d, e, f;
X***************
X*** 183,189 ****
X  	sprintf(buf, a, b, c, d, e, f);
X  	time_stamp();
X  	fprintf(stderr, buf);
X- 	do_insertion(buf, strlen(buf));
X  }
X  
X  /************************************************************************/
X--- 195,200 ----
X***************
X*** 206,212 ****
X  
X  {	char	*msg;
X  
X- 	internal_error("*** %s: ", program);
X  	switch (val) {
X  	   case 11 : msg = "range endpoint too large";
X  	   case 16 : msg = "bad number";
X--- 217,222 ----
X***************
X*** 222,228 ****
X  	   case 50 : msg = "regular expression overflow";
X  	   default : msg = "regular expression compilation error";
X  	   }
X! 	internal_error("%s in %s\n", msg, string);
X  }
X  
X  /************************************************************************/
X--- 232,238 ----
X  	   case 50 : msg = "regular expression overflow";
X  	   default : msg = "regular expression compilation error";
X  	   }
X! 	internal_error("*** %s: %s in '%s'\n", program, msg, string);
X  }
X  
X  /************************************************************************/
X***************
X*** 288,294 ****
X  	         internal_error("*** %s: invalid contool filter:\n\t%s\n", program, buf);
X  	      }
X  	   fclose(f);
X! 	   internal_error("*** filters loaded from %s\n", filter_path);
X  	   load_time = sb.st_mtime;
X  	   }
X  	else
X--- 298,304 ----
X  	         internal_error("*** %s: invalid contool filter:\n\t%s\n", program, buf);
X  	      }
X  	   fclose(f);
X! 	   internal_message("*** filters loaded from %s\n", filter_path);
X  	   load_time = sb.st_mtime;
X  	   }
X  	else
END_OF_FILE
if test 2542 -ne `wc -c <'patch'`; then
    echo shar: \"'patch'\" unpacked with wrong size!
fi
# end of 'patch'
fi
echo shar: End of shell archive.
exit 0

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

Date:    Tue, 08 Nov 88 10:53:00 PST
From:    jimc at math.ucla.edu
Subject: sysdiag and other virus risks

I urge anyone who has written any commercial or public domain software to
review it now for security problems, before the next "copy-cat" virus
comes along, and vendors and bulletin boards should make a special effort
to distribute fixes that are produced.  The 11/3 virus showed how
dangerous is a forked shell from a set-UID program, or a daemon process,
or any communications program.  Of course this is not the only class of
security problem.  The manual pages of seemingly innocuous programs like
Mail and vi should include a statement that "if this program is made
set-UID (or whatever), a substantial security hole may be created", the
problem then being described.  

Remote maintenance aids are a particular problem.  It is hard to get
untrained customer personnel to record useful debugging data, and perhaps
even impossible for a skilled programmer (as with Sendmail).  Yet the loss
from this one virus easily outweighs all the gains from Sendmail remote
diagnosis, and if a commercial product had been involved, such as one of
the add-on TCP-IP packages popular on VMS, the sales of that product and
others from that vendor would have gone through the floor.  A possible
solution is to routinely distribute two versions of the software, one for
normal use with the debug commands patched out and one with the full
remote maintenance capability, to be installed if the vendor needs to work
on the system. 

In this regard, the Sun distributed /etc/passwd has no password and full
root access for the "sysdiag" account.  Alert system adminstrators plug
this hole immediately (on each workstation individually) on installing any
Sun release.  When Sun has needed to work on the systems here, I have
simply applied a real password and phoned it in to the support person. 

James F. Carter <jimc at math.ucla.edu>   UCLA Department of Mathematics

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

Date:    Tue, 8 Nov 88 14:00:49 EST
From:    rjohnson at aecmail.prime.com (Bob Johnson {x6152})
Subject: Gammontool Bug, Yes. Cheats? No.

In response to nvuxr!cmc3 at bellcore.bellcore.com (c.m.chase), if a player
has taken any checkers off the board, then the player cannot be gammoned
or backgammoned.  I first noticed this bug a year or two ago.  I had
gotten into a backgame and managed to hit one of its last checkers.  While
I was closing out my board, I recycled a blot to hit a second checker.  I
closed it out, then took off all my checkers while it still had a blot in
my inner table.  I was happy, yet disturbed, to be awarded a BACKGAMMON on
a 64 cube!  I had about 10,000 points to its 3000 points when our system
administrator took the game off the system.  (Mostly, I took advantage of
its poor handling of the cube.  For example, it takes the cube if you have
one checker on the ace and it has 5 on the ace point!)

One thing I've noticed though many years of actual play is that it is more
difficult to recognize your opponent's unfortunate rolls than it is to
notice your opponent's fortunate rolls.  I am not convinced that it
cheats, but there is a way to tell.  Stop at a particular board position;
carefully analyze all 36 possible dice rolls and classify them as good,
bad, or indifferent; see which type of roll actually occurs.  Repeat this
process many times.  You might use positions where you or the computer
HAVE TO hit in order to win the game.

BTW, you might note how long it takes to play doubles, like 1-1.  I
calculated there can be as many as 10,000 ways to play 1-1 (worst case),
but relatively few with non-doubles and with a few points blocked.  People
are able to quickly concern themselve with the 3 or so ways which have any
relevance.

 	From: Robert D. Johnson      Computervision Corp.
 	Work: (617)275-1800x6152     a division of PR1ME Inc.
 	Home: (508)263-4769
 	Email: rjohnson at aecmail.Prime.Com

[[ I know it probably doesn't really cheat.  I just like to cover up my
own atrocious playing skills by blaming it on the computer.  --wnl ]]

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

Date:    Tue, 08 Nov 88 09:22:01 PST
From:    Alan Stebbens <aks%nowhere at hub.ucsb.edu>
Subject: Kudos to William LeFebvre

In case no one has  done this recently,  I  think  *all* of us who
have benefitted in any way from reading Sun Spots, should heartily
congratulate and   thank  William LeFebvre for his   time, effort,
thoughtfulness and diligence in  maintaining the mailing list.  It
is a *lot* of work, and he probably doesn't  get paid for it, and,
his own benefit is probably neither the motivation nor the reward.

Just to let you know that the  effort is appreciated; you  do good
work!

Alan Stebbens        <aks at hub.ucsb.edu>             (805) 961-3221
     Center for Computational Sciences and Engineering (CCSE)
          University of California, Santa Barbara (UCSB)
           3111 Engineering I, Santa Barbara, CA 93106

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

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



More information about the Comp.sys.sun mailing list