From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Mon, 16 Aug 93 16:00:55 EDT Subject: Linux-Misc Digest #4 Linux-Misc Digest #4, Volume #1 Mon, 16 Aug 93 16:00:55 EDT Contents: revised SLIP instructions (Charles Hedrick) Re: term and txconn (ANSWER) (Charles Stephens (guest - exp 9/1/93)) Re: [ANNOUNCE] Emacs 19.18 binaries on ftp.cdrom.com (Warner Losh) [Q] compile and SLS 1.03 (Wei-Jou Chen) Comments on the MCC Interim Release (Daniel Quinlan) Re: NetBSD's ash as /bin/sh substitute on Linux (Arjan de Vet) Re: INN1.4 under Linux - WOW !!!!!! (Arjan de Vet) The Daily Posting - what to do with it ? (Ian Jackson) ---------------------------------------------------------------------------- From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: revised SLIP instructions Date: 16 Aug 93 18:23:29 GMT Here's a revision of my SLIP instructions, for pl12 These are instructions for configuration SLIP, for 0.99pl10 through pl12 with the net2 utilities. At the end there is a list of common problems and solutions. sohail@trixie (Sohail M. Parekh) writes: >a) Do I need to upgrade my GCC and LIBC. Since I have SLS 1.0 I think > I have gcc 2.3.3 and libc.4.3.. Is this needed for 0.99p10 or NET-2 > or both ??? I compiled pl10 with libc4.3.3 and gcc 2.3.3, and pl11 and pl12 with libc 4.4.1 and gcc 2.4.3 with no trouble. However there have been some reports of problems with these versions, so Linux recommends using gcc 2.4.3 for pl10 and pl11, and 2.4.5 with pl12. >b) Is their any easy config guide for NET-2 ? I down load the binaries > (base+ext+std) from tsx-11 and base has alot symbolic links pointing > to /conf/xxxx which does not exist ??? This depends upon the programs you want to use. For the set I use (which is just the more common ones), all I seem to need is hosts, host.conf, and resolv.conf. The rest of them are files for specific services or specific options of services, which you may not need in a simple SLIP environment. (E.g. exports is for running an NFS server, not very likely over SLIP.) The way I have it set up is with the following files on /etc: hosts: a single line listing my host only (seems to be needed by dip): 128.6.200.2 foo.rutgers.edu foo Obviously you'll use your own IP address and host name. You give the IP address, the full hostname, and the abbreviation (i.e. just the part up to the first dot). In the case of SLIP, it's possible that you won't know your IP address until you dial. Often it is assigned dynamically at that point. In that case, the hostname will be different each time also. You can consider using a fake hostname, e.g. your own name. The hostname you use won't matter unless you use services that cause you to pass a hostname to the other end, e.g. mail, news, and the Berkeley r commands. For simple telnet and ftp it doesn't matter. (I always call my machine hedrick.rutgers.edu, but I'm not using any fancy services.) If you need to use services that depend upon a hostname, you'll need to arrange a real entry in your host table. Talk to your network managers. host.conf: one line specifying the order in which to use the hosts file and the resolver. I suggest order hosts bind resolv.conf: your domain and nameserver. For Rutgers this would be domain rutgers.edu nameserver 128.6.4.4 The domain is what you want to be tacked onto the end of host names you type if you don't say otherwise. E.g. if domain is set to rutgers.edu, and you say "telnet foo", you'll get foo.rutgers.edu. You can of course always specify a full name and override that default. The nameserver is the address of a machine that will provide name service for you. You'll want to pick the nearest name server to the system you dial into. Your systems support staff should be able to help you here. One approach would be to look at /etc/resolv.conf on a system at your site. You should be able to use whatever nameserver is listed there. 128.6.4.4 will actually work from elsewhere, but it's considered unfriendly to do name lookups across the network. (I'd say it's OK to use for testing purposes, but you should find a server at your site.) >c) If and when I have 0.99p10 + upgraded gcc (if needed) + NET-2 running, > how do I get SLIP up and running (boy I am greedy!). >I have noticed alot postings about problems with configuring NET-2 and a few >that indicate that they got passed that, but none that says how do you >configure NET-2. So any help will be much appreciated. Thanx in advance. If you have the three files I mention set up, I think all you need to do is 1) dial using kermit or some other program. Get SLIP turned on. (I can't help with that. It depends upon the system you're using.) 2) if it assigns different addresses each time, edit /etc/hosts to get the right address 3) run dip. E.g. dip -t remote 1.2.3.4 port tty65 speed 19200 mode SLIP Instead of 1.2.3.4, use the IP address of the system you have dialed. Not the address it assigns for your machine, but the address of the terminal server or Unix box that is running SLIP for you. for tty65 use the name of the tty line on your machine (probably something like ttys0) for 19200 use whatever speed your modem is set for 4) dip will exit. "ps agx" should show that it is still running. Now /etc/route add default gw 1.2.3.4 /usr/etc/inetd where 1.2.3.4 is the same address you used above. Run inetd only if you want incoming services. For initial testing, I wouldn't use it. 5) now try some tests, e.g. ping 1.2.3.4 or telnet 1.2.3.4 Now try it with a hostname ping foo or telnet foo ================= Here's a list of common problems and solutions: 1) connections open, but no data flows. For this problem to apply, it must apply for all destination hosts, and no data must flow at all. - probably your system and the SLIP router disagree about the setting of header compression. Note that 0.99pl10 as originally issued does not have header compression. There is a patch that I put on athos.rutgers.edu. If you put it in, you always have header compression. I had hoped that in 0.99pl11 it would be under the control of an option in ifconfig, but pl11 and pl12 are shipped with compression always on. - to fix this, you must change the setting on either your system or the SLIP router. The ideal situation is to enable header compression on both. If you have 0.99pl10, you can enable compression by applying the patches in athos.rutgers.edu:/pub/linux/slhc.tar. In later versions I believe header compression is on by default. If you can't enable compression on the SLIP router, then you have to disable it on Linux. With the initial 0.99pl10, it is disabled. If you applied my patch, it enables header compression. To disable it: look in slip.c for the routine sl_encaps. remove the line that calls sl_compress. That should be all that's needed. - in 0.99pl11, header compression is on by default. to disable it, look in slip.c for the routine sl_encaps. remove the line that calls sl_compress. That should be all that's needed. - in 0.99pl12, header compression is on by default. to disable it, look in .../linux/net/inet/CONFIG for the definition of SLIP_OPTS. Remove -DSL_COMPRESSED, and rebuild the kernel. (Make sure that slip.o gets rebuilt. If not, remove slip.o to force it.) - note that header compression makes a major difference to responsiveness of the system. I would not be interested in SLIP without header compression. Echo delay is just too painful. You might want to consider kermit or term if your SLIP router doesn't understand header compression. (On the other hand, header compression is widely available, so I'd think you should be able to enable it on the SLIP router.) 2) connnections open, data flows, but wherever I try to send more than a few lines of output, the connection hangs. - this is probably an MTU problem. Probably the host you are talking to is sending 1500-byte packets, and the SLIP router is set to something smaller. (Berkeley SLIP defaults to 1006.) In that case, the SLIP router will fragment the packets. Linux TCP/IP can't reassemble fragments. - In dip, specify a smaller MTU. I believe 512 should be safe. I normally use 192. This is probably counter-intuitive. Since the problem is with accepting large packets, you'd probably think the solution would be to raise Linux's MTU to 1500 so you can accept a full 1500 byte packet. The problem is actually an interaction between the Linux system and the SLIP router. It isn't that Linux is incapable of handling large packets, but that the SLIP router isn't, and is fragmenting them. What you need to do is make sure that neither end sends packets large enough that they need to be fragmented. When a TCP connection opens, the two ends tell each other what the maximum packet size they want is. They then use the minimum of those. So by setting the Linux MTU to 512 or 192, Linux will tell the other end to use a small packet. Thus fragmentation won't happen. Another approach would be to increase the MTU on the SLIP router, so it doesn't fragment the packet. In many cases this may not be practical. 3) Things work erratically. Connections open, but eventually hang. Timeouts shown in netstat -o are long. Typically you'll have more trouble with hosts on the Internet than with local hosts. - the TCP code in 0.99pl10 is buggy. It doesn't compute retransmission times correctly. Sometimes it will get into a state where it never retransmits. I believe this is fixed in 0.99pl11, but I can't say for sure, as I haven't use it. (It's possible that pl11 fixes this and introduces a different bug.) - if you have unmodified 0.99pl10, apply the patches in athos.rutgers.edu:/pub/linux/slhc.tar. Aside from compressed SLIP, this has a number of fixes to TCP/IP. Note however that if you apply these fixes as is, you're enabling header compression. If this causes problems (see (1)), you may need to disable header compression. - these patches are already present in pl11 and pl12, so I have no advice if you are running one of those. pl12 has some timer fixes compared with pl11, so I'd probably advise you to try moving to pl12. 4) I'm not sure what the exact symptoms for this one would be, but they might be similar to 2 or 3. I.e. some things would work, but there would be erratic failures or hangs. - flow control must be set up properly between the computer and modem. Thus is true at both ends. (Of course flow control is only one possible problem in modem setup. You also need to make sure that the modem and line speeds match, etc.) In general if you're using a simple v.32 modem, you may be able to do without flow control. However if your modem does error control, compression or speed-matching, then you'll need to talk to it at a higher speed than the data is actually transferred at, and depend upon flow control to throttle the data. At any rate, the modem and computer must agree. - the only flow control that is practical for SLIP is hardware flow control. Flow control using ^S/^Q (XOFF/XON) is not practical. The most common kind of hardware flow control is RTS/CTS, so called because it uses the RTS and CTS lines to handle flow control. The version of "dip" I have seems to set RTS/CTS flow control all the time (which is certainly appropriate). In that case, you'd want to make sure that the modem used with your Linux system has RTS/CTS flow control enabled. 5) I get "no route to host" or "network unreachable", or something similar. - probably you don't have a default route. by default dip sets up a route to the SLIP router, but nothing else. - try "netstat -n -r". Here is the correct display under pl12: Kernel routing table Destination net/address Gateway address Flags RefCnt Use Iface default 128.6.4.54 UGN 0 8055 sl0 128.6.4.54 * UH 0 1 sl0 You should have a host route (flags includes "H") to the slip server you're connected to, and a default route with "G" in the flags field listing that as the gateway. - If the default route is missing, you need to do /etc/route add default net A.B.C.D, where A.B.C.D is the address of your SLIP router. (This should be the address shows as "point-to-point addr" if you do /etc/ifconfig sl0.) The default netmask also seems wierd, but in a typical SLIP setup it shouldn't matter. - If the host route is missing, I don't have a fix. It should be set up by dip. ------------------------------ From: cfs@mathcs.emory.edu (Charles Stephens (guest - exp 9/1/93)) Subject: Re: term and txconn (ANSWER) Date: 16 Aug 1993 18:52:52 GMT Bill Reynolds (bill@yossarian.ucsd.edu) wrote: : I run term. : I connect My home machine via modem to my school machine. : I would like to run an X program on my HOME machine, to display on a : machine that is not my school machine. : Any suggestions? [Long discussion deleted] That's way too complex. Txconn, which comes with the term package does all of that for you. Running txconn the the remote machine is all that there is to it. Txconn does all the rerouting for you so there is no need to go through what you propose. I have been running things this way for quite a while with zero problems. -- Charles Stephens Member of S.P.A.B.A.F.: cfs@mathcs.emory.edu Society of People Against Barney And Friends "Cuteness kills, and Barney is cute, go figure!" DISCLAIMER: I am a guest a Emory's Math and CS Dept., all opinions expressed, except those quoted by others, are my own, and not those of said organization. ------------------------------ From: imp@boulder.parcplace.com (Warner Losh) Subject: Re: [ANNOUNCE] Emacs 19.18 binaries on ftp.cdrom.com Date: Mon, 16 Aug 1993 16:30:52 GMT In article <24ncmo$4uq@usenet.INS.CWRU.Edu> bf703@cleveland.Freenet.Edu (Patrick J. Volkerding) writes: >Under Slackware 1.00 or 1.01, or SLS 1.03, you should be able to install >the 'E' series with the command: sysinstall -special E ^^^^^^^^ -series The sysinstall help screen is wrong here. Having gone through this with the "o" series of disks, I am quite sure that -series is needed and -special will not work. At least as of SLS 1.02, maybe it changed in 1.03. Warner -- Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder I've almost finished my brute force solution to subtlety. ------------------------------ From: u7824501@cc.nctu.edu.tw (Wei-Jou Chen) Subject: [Q] compile and SLS 1.03 Date: Mon, 16 Aug 1993 19:47:53 GMT Hello! Why I can't 'make' make-3.68 and time-1.4 smoothly after 'configure' in the utilites ? I am running SLS 1.03 with gcc2.4.5 and lib4.4.1. And I also met gcc internal fatal error when octave-0.74. Thanks in advance. Jou ------------------------------ From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) Crossposted-To: comp.os.linux Subject: Comments on the MCC Interim Release Date: 13 Aug 93 03:43:30 Reply-To: quinlan@spectrum.cs.bucknell.edu First, a little background: Just about every piece of Linux documentation I have ever read (most of it, including the new guides) such as The Linux FAQ and The INFO-SHEET mentions SLS again and again. So, the first time I installed Linux, I went with SLS 1.02 (note: I haven't installed X because I don't need it). SLS was buggy, and I mailed Peter MacDonald a number of bug reports concerning: file permissions, binary repeats, missing descriptions in the install procedure, old versions of gzip, tar, emacs, everything. I don't know what the effect of mailing them all since I never heard back, but when 1.03 came out all of these problems were supposedly fixed and when I helped a friend install with 1.03 it was the same thing as before . . . buggy, cryptic installation, lousy documentation, I could go on for hours, but I'll spare you (I'm certain you've all seen the amount of posts on c.o.l. about bugs and SLS 1.03). Anyway, next time when I re-installed (to update gcc and libc) (with 1.03), there was a problem and it would not work for some reason. So, I decided to try out MCC. For people who have tired of this long post I'll make it plain and simple so you can go on. ** MCC is a wonderful installation package. ** MCC makes sense, it really does. Let's compare SLS and MCC a little: task/item SLS 1.03 MCC 0.99-p10+ ======================================================================== breakdown of by disk (i.e. a1-4, by package (user puts files installation b1-7, each composed on disks in similar manner files of tgz files having to SLS, but each tgz file is unrelated files put a package like emacs, or gcc.) together.) documentation a 2 page faq a formated (TeX, dvi, ps, ascii) a sheet on DOWNLOADING installation guide that goes into several other pages depth and covers _every_ aspect ownership of main FAQ of installation and starting (no extra information up a Linux system. there though...) ownership of yes no the main Linux there were 66 lines there were only 15 FAQ with "SLS" appearing note: does this really belong in the main FAQ when it is in the install docs? installation read the documentation in addition to the documentation, procedure and sparse comments this is a dummy-proof and mistake- not totally automated, proof procedure that asks before but almost there in it does and confirms along the the new version. way as you install with LONG paragraph-sized comments. size in disks (A through C which 8 disks (this is including the corresponds to MCC) extra packages) 14 disks time & speed 2 to 2.5 hours 1 to 1.5 hours (after putting it on disk) popularity undeserving, the low, but higher among more de-facto standard??? experienced users. who makes it? Softlanding Software Manchester Computing Center (sp?) age of old. Emacs-18.59 new. Emacs-19.15 software gzip 1.0.x gzip 1.2.3 old tar 1.1 recent on just about everything ======================================================================== I'll put it like this, if you have any amount of experience with Unix or even a good amount of experience with computers in general, use the MCC installation, it is a blessing. If you don't and you feel that you can do SLS easier, install it, play with Linux for a week or two, and THEN install MCC. You'll be happier if you do. Please don't flame me. I've installed Linux a (small) number of times on several systems and I doubt that I'll touch SLS again. I truly wish that the Linux community would give the MCC-interim package the spotlight that it deserves (and perhaps a piece of the FAQ the size of SLS's chunk!). The only drawback to using MCC is that it lacks a X-windows installation. If you doubt that you can handle installing X on your own, maybe SLS is for you. Then again, maybe not. Dan followups directed to comp.os.linux.misc (where they belong) -- [ Daniel Quinlan | Computer Science Engineer `95 ] [ quinlan@spectrum.cs.bucknell.edu | Bucknell University ] ------------------------------ From: devet@wsinis08.info.win.tue.nl (Arjan de Vet) Crossposted-To: comp.unix.shell Subject: Re: NetBSD's ash as /bin/sh substitute on Linux Date: 13 Aug 1993 10:51:35 +0200 [note: comp.os.linux -> comp.os.linux.misc] In article , Oleg Kibirev wrote: >In article <24bucm$43@adv.win.tue.nl> devet@adv.win.tue.nl (Arjan de Vet) >writes: > It has however some serious bug (I think): many shell scripts from INN and > smail use commands in backquotes (`date`). When running these scripts from > the command line, they work fine, but when run from crond they hang at the > first `...` command, consuming 100% CPU time. This is also the case for > /etc/rc scripts. I started using debugging traces but haven't been able > yet to find the problem. > >Apparently this happens only under Linux: > [script deleted] I'm at the university know so I cannot test it but I said that commands in backquotes only gave troubles when running from crond or init, not from the command line. Somebody suggested it had something to do with controlling tty's. Arjan -- Arjan de Vet -*-*-*-*-*-*-*-*-*-*-*-*-*-*- Eindhoven University of Technology Internet : devet@win.tue.nl -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- the Netherlands X.400 : c=nl;admd=400net;prmd=surf;o=tue;ou=win;s=devet -*-*-*-*-*-*-*-*-* ------------------------------ From: devet@wsinis08.info.win.tue.nl (Arjan de Vet) Crossposted-To: news.software.nntp Subject: Re: INN1.4 under Linux - WOW !!!!!! Date: 13 Aug 1993 11:06:35 +0200 In article <24ekeh$155@victrola.wa.com>, Vince Skahan wrote: >I got Arjan's INN1.4 to run under Linux (thanks for the tar file and >recent updated postings on it) and it's *INCREDIBLE*. > >I have trn3.1 and tin1.2p1 set up to use the INN overview database >and you can't imagine how fast posting and processing of incoming >news happens, even when compared to the C-news Performance Release. > >That thing absolutely screams !!!! INN 1.4 is IMHO the state of the art package for processing news, even for small systems like mine (UUCP only, 40Mb news spool). The built-in overview support is also very good and extremely easy to add. >Anyway, I'll be adding some words regarding INN to the UUCP-NEWS-MAIL-FAQ >regarding what little pain it was to install (given Arjan's fine >instructions...). That would be very nice. I now feel even more urged to update my `INN 1.4 for Linux' package with some patches for bash 1.12. The only problem with using INN on Linux is the absence of a real Bourne shell. I'm now looking into the NetBSD ash shell, but that one has some problems under Linux too. Arjan -- Arjan de Vet (home) Eindhoven University of Technology, the Netherlands (work) ------------------------------ Crossposted-To: comp.os.linux From: ijackson@nyx.cs.du.edu (Ian Jackson) Subject: The Daily Posting - what to do with it ? Date: Fri, 13 Aug 1993 00:37:27 GMT Now that the group has split the daily posting I have been sending out for the past n months needs reconsideration. My position at the moment is as follows, but I'd like some feedback here (comp.os.linux.misc) and discussion on this. In the meantime I've turned the daily off. 1. I don't expect that col.development and col.misc will need a daily. I hope not, anyway. If they do we can cross that bridge later. 2. col.help is almost certain to need one - pretty much along the same lines as the current one, I should imagine. Should I wait to see what develops or start posting immediately ? 3. c.o.l probably needs a regular posting reminding people to switch to the new groups. Matt - are you handling that, or shall I crib from your announcements in cola and add another line to my crontab ? 4. The Supersedes line. About two weeks ago I stopped putting a Supersedes line in the daily, as I got the impression that a significant number of people were subscribing to c.o.l, reading the first few (hundred!) articles in the backlog, and then giving up and posting. Many newsreaders (especially primitive ones which are more likely to make them give up quickly) will show the articles (more-or-less) in order, and thus they never see the daily. Is this happening ? If it is, is it worth the extra disk space (3K * expiry time) and time skipping (if you don't have a killfile) ? 5. I really don't know what to do about col.admin. I argued and voted against it because I felt it was too ill-defined; unfortunately the situation being what it was any group on the CFV was almost certain to pass. If someone can come up with a clear, short rule that I can write down which a poster can use to determine whether col.misc, .admin or .help is the right group I'd be interested to hear their ideas. 6. Remember that the daily has to be kept short. It's already a bit on the long side; I don't want to add more material - on the contrary, I'd like to remove some. I don't know what, though :-). All comments and advice - here, or by email - gratefully received. Followups redirected out of comp.os.linux - at last there is a newsgroup where this discussion won't get swamped. -- Ian Jackson (urgent email: iwj10@phx.cam.ac.uk) 35 Molewood Close, Cambridge, CB4 3SR, England; phone: +44 223 327029 PGP2 public key on request; fingerprint = 5906F687 BD03ACAD 0D8E602E FCF37657 ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Misc Digest ******************************