Sun-Spots-Request@RICE.EDU (William LeFebvre) (02/07/88)
SUN-SPOTS DIGEST Friday, 5 February 1988 Volume 6 : Issue 11 Today's Topics: Re: Adding a node to a server-based system (2) Re: Maximum disk space limitation? Re: Two ND servers on one cable Re: Problems (bug) with SunOS 3.4 Re: ping bug Re: FIG (was: MacDraw and/or Macpaint for Sun) new version of tcpdump available FBIOGTYPE ioctl bug and Sun video enable/disable program 3.2 vs. 3.4 `time' command Calentool doesn't know about leap years Bug in C compiler Problems with Suns Sun monitor behaving strangely? 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 stored on "titan.rice.edu". For volume X, issue Y, "get sun-spots/vXnY". They are also accessible through the archive server: mail the word "help" to "archive-server@rice.edu". ---------------------------------------------------------------------- Date: Sat, 23 Jan 88 15:28:50 GMT From: James Davenport <jhd%maths.bath.ac.uk@nss.cs.ucl.ac.uk> Subject: Re: Adding a node to a server-based system (1) I wondered when some-one was going to ask this question. SUN's official answer is indeed that you have to install again, and re-run through setup. We have (twice) added new discless nodes - Here's what we did. Time 1 (I was fairly green then). Let SUN do it, which means that they do indeed run setup, and all the discs get trashed etc. HOWEVER, we unplugged the user file store first, so that setup didn't know it was there. After it had finished trashing and re-building the system disc, we restored such bits of the system as we needed from out backups, merged the old and new fstabs (a touch tricky here: you want the new fstab + the entries for the user file store from the old one), do a /etc/mount -a, and we were back without having to restore the user file store (though I had taken a backup before - I wasn't that green!). My SUN engineer was quite happy with this process - I recommend it as a good compromise. Time 2 0) Back everything up. 1) Add entries for the new machine to /etc/hosts, /etc/ethers, any mailers you have, your yellow pages domains, /etc/exports etc., and rebuild yellow pages. 2) SUN engineer arrives and installs the hardware. You then kick him out of the seat, and he stands around for the rest of the exercise, disclaiming all responsibility (and taking notes, if he's any good). 3) Decide where to put the / (nd0) and swap (nd1) partition for the new machine. This will probably involve making another partition smaller. WARNING: as already mentioned on this net, you can't start a disc with a swap partition - it will trash the disc label. This is a step you should think through carefully, and preferably when you do your initial installs (hence SUN's view that you should reserve the partitions initially) - it's a lot easier to add disc space than it is to lose it. Although not explicitly mentioned, I believe that all these boundaries should be on cylinder boundaries. [ go single-user on your server] 4) Use diag to re-label the disc. The details depend on what disc you have, and what you're doing to it. My SUN engineer was actually quite helpful over this stage of it. What you'll be doing is changing the start/end places of the partitions you are stealing the disc space off. These should NOT be /, /pub and preferably not /usr [I didn't change /usr, so won't pretend I did. That would make life more complex]. 5) Change /etc/nd.local to add the two new nd partitions. When we added "borodin", the two lines we added were: user borodin 0 /dev/xy0c 326960 16080 3 user borodin 1 /dev/xy0c 343040 65660 -1 meaning that 16080 blocks on /dev/xy0c starting at block 326960 would be /dev/ndl3 for the server, and /dev/nd0 for borodin, and 65660 blocks starting at 343040 would be /dev/nd1 for borodin (its swap space). Then re-run nd. 6) use /etc/mkfs to make the new / filing system (/dev/ndl3 in my case) for the new client (unfortunately /etc/newfs won't make nd partitions - sigh). The "size" parameter quoted to mkfs is the 16080 (or equivalent) from the previous step. 7) use a back-to-back dump/restore pair to copy an existing nd client's root partition onto the new one. Choose the existing client most like the new one. It helps if no-one is logged on to this machine at the time. 8) Sanitise the newly created partition. The minimum change is: a) hostname in etc/rc.boot (else chaos!) You should also: b) delete private/usr/spool entries (else the documents will print twice) c) tidy up private/usr/spool/mail; d) check over things like private/usr/lib/crontab; e) check over dev. 9) use newfs to re-make the partitions that you trashed while stealing space for the new clients. Then restore the data (there was room, wasn't there?). A) Place a symbolic link in /tftpboot on the server from "hex address in capitals of client, e.g. CAE1001F" to "ndboot.sun3.pub1" (or whatever). Incidentally, if you don't like the idea of all your discless machines running the same kernel, this directory is the place to hack. But that's another story. [ go multi-user, but gingerly] Restart the old client, then try the new one. This process took me about 45 minutes in all - a great saving over setup. But I had thought about it for several days before hand. James Davenport jhd@uk.ac.bath.maths ------------------------------ Date: Mon, 25 Jan 88 00:37:42 EST From: mcgrew@topaz.rutgers.edu (Charles) Subject: Re: Adding a node to a server-based system (2) You didn't necessarily screw up. If there is space on the disk (or disks) for new clients to go on (a spare partition, or whatever), all you need to do is edit your /etc/nd.local to set aside root and swap space there - it doesn't have to be next to or near the other client (see 'adding a client' in the administrator's manual for how to initialize the client space). (The man page for nd will help, a little.) If you haven't got space on the disk set aside for this, then your job is messier. You'll have to backup a partition, run diag and alter the parttition table (to set aside the space for the client's root and swap), remake the file system for the file system you snarfed and restore it (do all this single user, of course). Then adjust nd.local and set up the client as 'normal'. (Hints: use /usr/etc/setup.files/copy_client, and then mount the ndlX partition as /mnt, cd /mnt/dev, and MAKEDEV std nd0 ndp0 win0 win1 win2 pty0 pty1 pty2 bwtwo plus any other devices you need, have a look at /dev/MAKEDEV for this.) Its gory, but this will save you having to completely rerunning setup and restoring all partitions. In general, when we get a new server (we've got 8 or so now), we decide up front how many clients we want on it (usually 10), and set aside the space, regardless of what clients we have at hand at the time. Having extra client partitions around comes in very handy when a server goes seriously bad - we can boot the bad server as a client, mount its disks and work on them with a complete unix environment at hand. Hope this helps, Charles ------------------------------ Date: Fri, 22 Jan 88 15:19:28 EST From: mnetor!utzoo!henry@uunet.uu.net Subject: Re: Maximum disk space limitation? > Sun specifications list the 3/260 as only being able to handle 1 gigabyte > of disk space, and a 3/280 at 2 gigabytes... What's the limitation here? My guess would be that these are either the largest configurations that Sun thought worth supporting, or the largest that would fit in the box with the disk drives Sun prefers. This is yet another case of a problem that constantly angers me in Sun configuration documentation: no attempt is made to explain the reasons behind the rules, which means you cannot tell whether what you want is (a) impossible, (b) awkward, (c) beyond what Sun is willing to support, (d) infeasible with the hardware available when the manual was written, or merely (e) something Sun never thought about. I recognize the usefulness of cookbook rules for the unsophisticated users (although most of *them* probably find the Sun manuals unreadable anyway!), but personally I thoroughly dislike the Mama-knows-best attitude that excludes any mention of the principles behind the rules. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Sat, 23 Jan 88 21:58:52 EST From: allegra!phri!roy@ucbvax.berkeley.edu (Roy Smith) Subject: Re: Two ND servers on one cable We've got 2 3/160's and 13 3/50's being ND served from 2 3/180's, roughly half the clients on each server. We don't see any particular problem. We're typically running at about 20% capacity on the wire (as shown by traffic), with maybe a couple of collisions per second max. You must have some other problem. Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 ------------------------------ Date: Fri, 22 Jan 88 19:36:45 EST From: hirai@swarthmore.edu (Eiji "A.G." Hirai) Subject: Re: Problems (bug) with SunOS 3.4 I use an alias in my .cshrc to "wipe" away those annoying pseudo-tty's. Don't use it on nodes that still have "real" users on them though, or else their valid utmp entry gets wiped too. alias wipe 'rsh \!* "(echo -n > /etc/utmp)"' -a.g. hirai swarthmore college [[ In most cases, that's a little too severe. --wnl ]] ------------------------------ Date: Fri, 22 Jan 88 14:28:31 PST From: Brent Chapman <capmkt!brent@cogsci.berkeley.edu> Subject: Re: ping bug >We have noticed the same behavior. It seems that if more that one PING is >outstanding, that is, if more than one ICMP ECHO packet has been >transmitted without receiving the corresponding ECHO REPLY packet, then >when one ECHO REPLY does arrive, it satisfies all outstanding ECHOs and >ping erroneously reports all systems as 'alive'. In the documentation accompanying the 3.5 release, there is mention that a ping bug similar to this has been fixed; your bug sounds like a slightly different manifestation of what was fixed, so your bug is probably gone as well. SunOS 3.5 is not being automaticly shipped to all service-contract customers; it is being shipped with all new systems, and will be shipped to any service- contract site that requests it. I haven't installed mine yet (it just came in this morning), so I can't tell you much more than what's in the accompanying documentation. -Brent Brent Chapman Capital Market Technology, Inc. Senior Programmer/Analyst 1995 University Ave., Suite 390 {lll-tis,ucbvax!cogsci}!capmkt!brent Berkeley, CA 94704 capmkt!brent@{tis.llnl.gov,cogsci.berkeley.edu} Phone: 415/540-6400 ------------------------------ From csrobe@icase.arpa Fri Jan 29 14:56:58 1988 Date: Fri, 29 Jan 88 15:56:43 EST From: csrobe@icase.arpa (Charles S. Roberson) To: sun-spots@rice.edu Subject: Re: FIG (was: MacDraw and/or Macpaint for Sun) After I saw wnl's pointer to fig, I decided to check it out for myself. We took a look at it and it is definitely much better than Graphedit! It moves easily and has a nice interface. However there are a few facilities that we would like to use that it doesn't have. Namely: Multiple fonts Stacking objects Filling/Shading Line thickness Rotating text Before we, perhaps, attempt to add any of them, has anyone made any extensions to fig? Fig is, by far, the best MacClone software I have seen yet, (well, MacClone is probably a bit strong, but it does have all the basic ideas of MacDraw), however, without the above abilities, we are not sure if it is good enough to replace our *old* Mac and MacDraft/MacDraw. The version of fig that I ftp'd was 1.3 and dated 1985. cheers, -c Chip Roberson ARPANET: csrobe@icase.arpa 1105 London Company Way BITNET: $csrobe@wmmvs.bitnet Williamsburg, VA 23185 UUCP: ...!uunet!pyrdc!gmu90x!wmcs!csrobe [[ The author is Supoj Sutanthavibul <supoj@sally.utexas.edu>. He told me that he is working on a new version which will hopefully be available in a few weeks. I don't know how responsive he is to new ideas, but you might want to try suggesting a few anyway. --wnl ]] ------------------------------ Date: Sun, 24 Jan 88 19:36:27 PST From: Van Jacobson <van@lbl-csam.arpa> Subject: new version of tcpdump available There's a new version of tcpdump (v1.17) available for anonymous ftp from internet host lbl-rtsg.arpa (128.3.254.68), compressed tar file tcpdump.tar.Z. There are no major changes but several bug fixes and a couple of new flags. In addition to the tcpdump update, a couple of new trace analysis awk scripts have been added. This version was compiled -fswitch so it should work on Sun-3s without a 68881. And no, the source still isn't available (but will be soon I hope). - Van ------------------------------ Date: Fri, 22 Jan 88 19:04:23 EST From: dupuy@columbia.edu (Alexander Dupuy) Subject: FBIOGTYPE ioctl bug and Sun video enable/disable program Here's a little program which you can use to turn a Sun video display on and off. It's especially useful if you ran screenblank, but it died or is behaving erratically. You can also use it to find out the type of a framebuffer. Unfortunately, the FBIOGTYPE ioctl in SunOS 3.4 (and maybe others - it doesn't seem to be used by any programs at all) has a bug which causes it not to return the fb_type field, and as a result, the other fields are all off by one in the structure. I worked around this, and screen attempts to intuit the framebuffer type from its size and number of colormap entries. Since I don't have any Sun-1 or Sun-4 color displays, it doesn't guess those right (yet). I am cc'ing a copy of this to sun!bugs as a bug report for the FBIOGTYPE ioctl, and am placing this in the public domain. If Sun wants to include this minor program in any future releases, they are free to do so. @alex arpanet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy [[ Available in the archives as "sun-source/screen.shar". It can be retrieved via anonymous FTP from the host "titan.rice.edu" or via the archive server with "send sun-source screen.shar". For more information about the archive server, send a mail message containing the word "help" to the address "archive-server@rice.edu". --wnl ]] ------------------------------ Date: Fri, 22 Jan 88 11:08:51 PST From: telesoft!souza@sdcsvax.ucsd.edu (Steve Souza @eldest) Subject: 3.2 vs. 3.4 `time' command In some timing tests recently done on Sun3s running 3.2 and 3.4 we've found large discrepancies in the "average shared memory" and "unshared data space" statistics reported by the C-shell `time' command. In summary, it appears that the memory usage reported by the 3.4 version of `time' is much larger that the amount reported by the 3.2 version for execution of the same program under similar conditions. The difference has been anywhere from 2 to 10 times greater for version 3.4. Here are the results of some typical Unix commands: __________ "ps aux" 3.2: 0.7u 4.1s 0:06 76% 6+9k 20+1io 0pf+0w 3.4: 0.9u 1.6s 0:04 58% 48+72k 35+3io 0pf+0w "nroff -man /usr/man/man1/csh.1" 3.2: 67.2u 0.9s 1:16 88% 2+9k 40+46io 0pf+0w 3.4: 69.0u 3.0s 1:45 68% 16+72k 41+47io 0pf+0w "cc -O test.c" 3.2: 0.8u 1.5s 0:06 36% 4+4k 130+38io 26pf+0w 3.4: 0.9u 1.1s 0:06 31% 32+32k 107+43io 5pf+0w __________ The machines involved were both Sun3 160s with 16MB of memory. Why these numbers differ so drastically? The only clue we found was a note about a bug fix in 3.4 for the memory device driver ("Release 3.4 Manual for the Sun Workstation", p111). Assuming the method of stat calculation in csh has remained the same between releases, do any of you "in-the-know" kernel hackers out there know of any changes? Other ideas? Many thanks, Steve Souza sdcsvax!telesoft!souza, telesoft!souza@sdcsvax TELESOFT Inc., San Diego, CA (619)457-2700 x277 ------------------------------ Date: Fri, 22 Jan 88 16:01:26 CST From: "Patrick M. Landry" <pml%pmlsun@USL.CSNET> Subject: Calentool doesn't know about leap years I have a copy of calentool off of the 1987 SUG tape but it has a problem. It doesn't know about leap years. Two questions: 1. Has anyone fixed calentool? 2. Does anyone have an alternative? Thanks ---patrick--- pml@usl.usl.edu ut-sally!usl!pml ------------------------------ Date: Fri, 22 Jan 88 10:07:18 EST From: im4u!rutgers!rochester!srs!matt@ut-sally.UUCP Subject: Bug in C compiler We have had a bug in our main signal analysis tool for well over a year. Occasionally, and apparently w/o any regularity, one of the graphs (a raster display of FFTs of an input signal) would produce what looked like garbage, but tended to follow the basic trend of the input data. Recompiling the tool sometimes changed the frequency of occurance and with the latest changes, it tended to occur quite often. Well, I have finally tracked it down to a compiler problem and this bug will bother us no more... Release: Sun OS 3.2 Systems: Sun3, Sun2 Comment: The following program outputs (erroneously) 0xff00 for the second call to screwit(). Basically, the compiler fails to clear the upper half of "d7" before adding it into "a". "a" can be a signed or unsigned short. If "a" is an int (long), it appears to work correctly. #include <stdio.h> main() { register short d7; unsigned char b = 0; d7 = 0x00ff; screwit(&b); d7 = 0xffff; screwit(&b); } screwit(b) register unsigned char *b; { register unsigned char d7; register unsigned short a = 0; d7 = *b; a += (unsigned short) d7; printf("C: 0x%04x\n", a); } UUCP: {allegra,rutgers,ames}!rochester!srs!matt Matt Goheen "First the pants, THEN the shoes." S.R. Systems ------------------------------ Date: 22 Jan 88 10:53:30 GMT From: unido!tb@uunet.uu.net (Tb) Subject: Problems with Suns Hi everybody, We have some problems with our SUNs, perhaps someone outhere can help us : 1. Since we upgraded to SunOS3.4, our SUNs only use 512 Byte tcp-packets. This was not the case under SunOS3.2. Is there any reason for that ? If not how can it be fixed ? 2. We never managed to get talk and ftp running on diskless clients. Normally those exit with "bind:cannot assign requested adress". Strange enough ftp SOMETIMES (don't know exactly when) works. 3. We recently bought a 3/280 with a Rimfire hard-disk-controller. Though the documentation stated that the SUN setup program should work with the Rimfire controller, we didn't manage to get it running (though we made the appropriate changes to setup.config setuphardware.file). Did anyone outhere got setup running with the Rimfire controller ? If so, what where the changes you made to the setup files ? 4. How can I get eye and this Mandelbrot graphic demo from SUN. (As I'm in Europe I'm not able to ftp this from somewhere. Mail is to expansive, so the only remainder would be a tape or bitnet-mail. Can anyone help ?) Any help would be greatly appreciated. Thanx in advance Torsten Beyer Michael Kuschke Torsten Beyer uucp : ...uunet!unido!tb University of Dortmund tb@unido.uucp -IRB- P.O.Box 500500 bitnet : tb@unido.bitnet D-4600 Dortmund 50 West-Germany ------------------------------ Date: 22 Jan 88 17:42:01 GMT From: lj@spdcc.com (Len Jacobs) Subject: Sun monitor behaving strangely? Does anyone have any experience with a Sun 3 monitor behaving strangely, waving and acting as though the tube may be on its last legs? Any comments would be appreciated. Thanks Len Jacobs {harvard,linus,ihnp4}!spdcc!lj ------------------------------ End of SUN-Spots Digest ***********************