Sun-Spots-Request@Rice.edu (William LeFebvre) (11/18/88)
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@rice.edu Send subscription add/delete requests to: sun-spots-request@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@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@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@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@cornellc.cit.cornell.edu> Subject: Re: /var/spool/lpd/err files Reference: v7n6 In SunSpots v7n6, bparent%sdcc7@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@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@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@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@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@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@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@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@math.ucla.edu> UCLA Department of Mathematics ------------------------------ Date: Tue, 8 Nov 88 14:00:49 EST From: rjohnson@aecmail.prime.com (Bob Johnson {x6152}) Subject: Gammontool Bug, Yes. Cheats? No. In response to nvuxr!cmc3@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@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@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@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 ***********************