ALINK="#FF0000" >

"Linux Gazette...making Linux just a little more fun!"


The Answer Guy


By James T. Dennis, jimd@starshine.org
Starshine Technical Services, http://www.starshine.org/


Contents:


 SATAN URL Correction

From: Richard White, whiter@digex.net
In the Linux Journal #14, you made reference to ftp.cs.perdue.edu...(grin) Doesn't exist. I think that it was supposed to be ftp.cs.purdue.edu.

-- Richard D. White, Business Connectivity Technical Support

 Yes! That was, of course, a typo. But other than that -- did you find the info useful?

 Yes. Very. I've just downloaded SATAN and a few of the other security tools. I work in customer service for leased lines and I occasionally assist customers in configuring their firewalls. Learning what holes there are and how to plug them is very worthwhile knowledge.

 Have you tried cops (Dan Farmer's earlier host based auditing package) or Tiger (Texas A&M University)?

Have you gotten tripwire running? I (and most of the rest of the Linux community that's tried it) had a little trouble with Tripwire. I had fussed it into submission a number of months ago -- forgotten about it. Then recently I had to fetch and build a new copy.

I encountered the same problems building it -- and the same problems with the README.linux I found myself muttering that someone -- anyone -- ought to prepare a proper set of patches that allow the Linux user to just compile the thing with minimal effort.

Now I'm not a programmer (although I do "play one on the 'net") so I really didn't feel qualified to do this. However I never have been able to inspire or manage much of a volunteer effort in others so I did it myself.

Creating a set of patches involved teaching myself how to use CVS (version control system). I'm thinking of writing up an article on using CVS to track local changes in downloaded source trees and cutting diffs so you can share the work you do with others on the net.

Naturally I'd use tripwire as one example -- probably pgp as another. I'm also planning on importing my kernel sources into CVS.

If your interested you could get my patch and let me know if it works. It's about 150 lines of text that seems to work for me using Larry Wall's standard 'patch' program.

-- Jim


 EDI On Linux

From: Adam Morrisom, adam@morrison.iserv.net
I have just got management to permit me to install our first Linux box, right next to our not-so-mighty RS/6000. So far it has operated flawlessly (which is exactly what I expected). And suddenly Linux is a possible solution for jst about every problem we have (they loved the price tag). Now I have to implement EDI, and I was wondering if any software is available for Linux, I haven't been able to find anything, on the software map, sunsite or any where else. Any pointers or people to contact would be greatly appreciated.

Adam,

 You certainly put in an good entry in Jim's "Stump the techie" contest.

I've heard of EDI (electronic data interchange) and vaguely recalled that it is a data format specification for electronic commerce (mostly in the mainframe world where X.25 predominates over TCP/IP).

However I haven't heard of any projects or products being available specifically for Linux.

Here's a few web pages that I did dig up that might help:

I hope these help. Basically it looks like there are not "shrinkwrap" or "off-the-shelf" EDI packages for any platform. Good luck.

One approach you may take is to contact the publishers or authors of your existing EDI applications and see if they can do the port for you.

-- Jim


 zmodem

Help answer guy! I cannot download from the net! Here's the story: - I run linux v2.0.0. I am using minicom v1.71. I have NOT touched my file transfer protocols since I installed, so they would be the default configs.

 I hate debugging serial line problems.

Here's the basic litany for solving modem problems:

What happens at lower speeds? What IRQ is this serial line using? What sort of UART is installed? What are the flow control settings? Does the cable have conductors for all of the flow control signals? How is the modem configured (hardware and init strings)?

minicom 1.71 is pretty old. I have 1.75 here -- and there may be even newer versions up on sunsite.

Incidentally -- you should probably upgrade to Linux kernel version 2.0.29 or so.

Your problem may not be related to either of these factors -- but it won't hurt to upgrade.

The first thing I'd check is Minicom's configuration for init strings and flow control. Try an init string of:

 
	AT&C1&D2

... (which I remember from years of supporting PCAnywhere as well as seeing it in my current configuration). These set the modem's behavior for the DCD (device carrier detect) and flow control. I don't remember which is which and what the other numbers do -- look them up in your modem's manual if you're curious).

Then make sure that minicom's "Serial port setup" specifies "Hardware Flow Control" is "on."

When having problems with serial lines and modems I find it handy to get the digital equivalent of a "second opinion." -- Do you run any other comm software on this system (pppd, uucp/cu, mgetty -- dial-in, seyon)? Do those work reliably when transferring data (putting the line under load)?

I'd suggest getting a copy of C-Kermit from Columbia University kermit.columbia.edu . No offense to Miguel van Smoorenburg but minicom was having problems on my system, too. C-Kermit is doesn't have any of the full screen, ncurses "feel" to it but does a good solid job of talking to the modem. It's scripting capabilities are also far more advanced than minicom's 'runscript' -- and has features that would be to force 'minicom' to do through an 'expect' script (for example).

Do you have another account on another system (BBS or ISP)? Do your file transfers work O.K. to or from there? The problem may be with your ISP rather than at your end.

What if you try a different protocol -- such as kermit? Kermit is often characterized as "slow" compared to zmodem -- but this is largely because it's default is tuned for the very noisy, unreliable connections that were common when it was created (almost 20 years ago).

After checking with another comm. program I'd look a little lower. Using the commands:

 
	stty -a < /dev/modem

... and

 
	setserial -a /dev/modem

(both of these assuming you have a "modem" link to the appropriate /dev/ttyS* entry on your system).

Make sure that your stty reports crtscts (for the flow control). Then make sure that the cable between your computer and your modem has all those pins connected.

Double check that you don't have an IRQ conflict. These are insidious in that they may not show up until the port is under load.

In addition check to see that you have a high speed UART (16550AFN) on that port.

Next I'd check the modem's configuration. You can see some of that with AT&V (which on many Hayes modems dumps the configuration date and S-register values to your terminal). Look at the Init strings that you are using in Minicom and look in the modem manual for recommended init strings for similar software.

After checking all of that I'd shutdown and boot up in DOS (if you don't have a copy of DOS you can consider downloading a copy of Caldera's OpenDOS. I'm not sure what the licensing terms will be -- but I did read that we're all invited to play with it for 90 days). Along with a copy of DOS you also need a Telix, Qmodem, Procomm, or other comm. package. There are many of these in shareware -- Telix is my personal favorite.

(Note: I am not advocating use of these packages without respect to their licenses. If you choose to continue to use Telix or OpenDOS -- even for the occasional troubleshooting session; please read and abide by their licensing and registration. Yes, I have fully legal copies of Telix (DOS and Windows)).

In any event I like to check from plain old DOS since the old real mode program loader is so minimal. You could try building a Linux kernel with no support for TCP/IP and stripping out all of the device drivers except the serial and console support and booting that in single user mode ... and that still isn't close.

The idea is to see if any of your other devices or hardware features are conflicting.

 i am a best internet shell account, i believe iris but i don't know the version.

 I'm guessing that you mean that your account is at best.com and that they are running Irix (SGI). (Which is interesting -- since I would have guessed Sun/Solaris for them -- but what do I know).

Note: Irix and Solaris are not known for sterling serial line support. They are currently geared for ethernet TCP/IP support -- on the assumption that most sites will use terminal servers (small dedicate devices that convert serial connections to telnet sessions). Consequently I've heard that the copies of rz/sz that ship with these should routinely be replace with newer sources from the 'net.

 i have a usrobotics sportster 28.8 modem

 Internal or external?

Personally I don't like the Sportster series. Their Courier's are nice (but spendy). I currently use a Practical Peripherals -- but my next modem will probably be a Zyxel.

 I typesz <filename> things go along fine until about 40k than i will get a couple of different error messages:

 
	 BAD CRC:0
sometimes followed by another attempt at downloading (usually only a bit or two) than the same error OR
 
 	GARBAGE COUNT EXCEEDED:0
followed by a time-out.

AARRGH! what the heck is going on? u can email me privately if you would prefer, as this is probably a totally common problem and i am just not looking in the right place!

My guess would that you don't have a high speed UART. Or that your flow control isn't properly set.

The reason I guess this is that 40K is a reasonable amound of data for the modem to get and buffer while you system does a context switch. The buffer overruns (in a 16450 -- older, low-speed UART) could easily be fatal to the transfer in the first context switch.

With the 16550 UART -- the UART has a 16 byte FIFO buffer. That's enough for the UART to change the state on the handshaking lines (lowering the CTR -- clear to receive -- line) and enough still store the incoming data while the other system responds (stops sending).

At 28.8Kbps coming into a 16450's (one byte!) buffer the sender will have tossed a lot of bits out before getting the message (that your system is dropping them all on the floor).

I am copying this to the Linux Gazette *because* it is a common problem. Most of us in the real world use modem -- we don't have T1's or ISDN/ethernet bridges (actually I do have a Tracell WebRamp but I'm not using it yet). So we are still stuck fighting with these problems.

I'm hoping that USB (IEEE 1394 "Firewire") actually takes off in the next year. It's been hanging in the wings, timidly for about two years now and it's LONG overdue.

Has anyone out there run a USB board under Linux?

For those who are lost about "Firewire" refer to:

If you have any Linux news on this topic -- mail it to tag@lists.linuxgazette.net.

--Jim


 Running the Internet with Linux

From:Ricardo Romero rromero@netfriendly.com

Hi, my name is Ricardo Ribeiro Romero and i live in Brazil, i try to run INTERNET from linux but this not run, you may help-me?

Tks,
Romero, Ricardo

 At the risk of seeming unfriendly, Romero, I'd have to suggest that you might want to look for a local consultant or computer specialist to help you.

Questions to a publication -- particularly a free publication which is entirely supported by the volunteer efforts of the writers and the generous sponsorship of SSC have to be fairly specific and of reasonably broad interest.

Any reasonable distribution of Linux includes all of the utilities you need to connect to the Internet as a client and all of the utilities that most people would ever want to be a service provider.

It is not clear from your message whether you are trying to set your system up as a server/provider or as a client or both.

There are several good books that go into broad coverage of Networking with Linux (which is largely the same as networking under other forms of Unix). My personal favorite would be the Linux Documentation Project's Network Administrator's Guide (LDP NAG for short). This is available electronically (as text, postscript, TeX, or HTML) and is probably on any set of CD's that you'd buy. You can also purchase a professionally bound and printed copy from O'Reilly & Associates (among others).

Along with that O'Reilly also publishes a book called something like: "Getting Connecting: Establishing a Presence on the Internet" (That would be the "Pig" book) by Kevin Dowd). If you're trying to set yourself up as an ISP or if your want to have a dedicated connection to the net (say for your office) than this is probably what you want.

Personally I recommend that most small business and private people avoid "dedicated" or "permanent/full-time" connections to the 'net. It's much less expensive to configure UUCP for mail and news -- and look at virtual hosting and/or co-location for serving up web pages and other services. This can be supplemented with demand dialed PPP (using scripts or diald) to provide the web access -- over a modem or via ISDN.

One of the big benefits of ISDN is the lower latency. A modem connection takes about 30 seconds to 1 minute to dial, ring, connect, and negotiate. ISDN can do that in about 3 seconds. You'll be much less reluctant to hang up and quit hogging your ISP's phone line if you know that you can get back in about 3 seconds.

In addition to the lower expense running your site as a disconnected network relieves you of quite a bit of the security concerns associated with a full time net connection. Sure -- your PPP link is inherently bi-directional (people can connect back to your through it and attempt to exploit the same services that they my attack on a fully connected site). However you'll be there to notice any additional load or any anomalies -- and your whole site is considerably less attractive to crackers anyway.

(People who connect their Linux systems to the 'net via PPP really should take a 1 hr course on securing their hosts. Maybe I'll crank out an article on that sometime). Romero,

Back to your question. Please try reading up about these connections and/or consider hiring a local consultant. I don't know anything about the phonesystems in Brazil -- and I get a little sketchy about ISP's if I get more than about 200 miles inland from the Pacific Coast.

--Jim


 Respawning too Fast

From: Igor Markov imarkov@math.ucla.edu My question is about the infamous "Resapawning too fast" message from init. This message appears in my /var/log/messages every 5 minutes (of course!) for xdm I'm just guessing that this is for "The Answer Guy" init: Id "x" respawning too fast: disabled for 5 minutes However, xdm is running (I see it in ps output and I don't have problems using it).

 You don't show the appropriate lines from your your /etc/inittab but they should look something like:

# Run xdm in runlevel 5 (and 4 for me) x:45:respawn:/usr/bin/X11/xdm -nodaemon

(Note: I run xdm in 4 and 5 which unusual -- but 4 is my custom default -- with 12 VCs, xdm in VC13 -- accessed by the right alt-key + F1 -- and syslog output on VC 15, VC14 is used for stray open commands or to redirect pesky output from backgrounded processes).

My guess would be that you don't have the -nodaemon switch on yours. (Try adding it).

If I'm mistaken than the troubleshooting will be more involved. Check with the vendor for your distribution of Linux and see if they have some patches.

Red Hat users may want to look at: http://www.redhat.com/support/docs/errata.html

... to see what's been fixed since your CD was burned.

Also you may want to look in your xdm-config file (/etc/X11/xdm/xdm-config -- if you're lucky -- otherwise it could be in .... /usr/X11R6/....????).

The best introduction to xdm I've ever found was in _The_Shell_Hacker's_Guide_to_X_and_Motif_ from John Wiley & Sons.

 It seems that init tries to spawn a second xdm. I couldn't confirm or reject this hypothesis... (egrep xdm /etc/* /etc/*/* did not show anything promising) Thank you

 Respawning too fast indicates that the program is exiting (pretty much immediately) and that init figures that there must be some bad problem. For example if getty is respawning it may be that it's attempt to grab the serial line is failing (like there is no serial driver configured in your kernel and you forgot to load the module -- or something like that).

If xdm is loading and forking off a daemon (it's default) then this will look like an exit/failure to init. The -nodaemon will force xdm to run from the console in which init started it (not try to "background" itself as it would do if you ran it from a command line).

The fact that your copy is working suggests this -- but when you log out of your xdm session you might have to way upto five minutes for init to decide to try xdm again (unless your xdm logout configuration is doing the respawning or something weird).

--Jim


 Problems with Keyboard Mapping

From: Gilbert R. Payson g.payson@edina.xnc.com
Hello. I have three (okay, four) linux machines in Germany. My problem is this: In Xwindows, my keyboard mapping is almost perfect. But, there are a few problems:

@ doesn't work. It brings me to the last edited line (like an up-arrow) How can I fix this?

thanx! -gil

 I think you want to look at the xmodmap command. You'll also want to look at the following HOW-TO documents:

--Jim


 Modem Speed

From:Scott Atwood atwood@cs.stanford.edu
I'd like to make a comment regarding a question from "The Answer Guy" column in issue 13 of Linux Gazette about combining modems to increase speed. This question reflects a common misconception of equating bandwidth with speed. Latency is a much more important measure of percieved speed, especially in interactive applications, such as telnet sessions, and web browsing. Combining modems will increase bandwidth, but latency will remain unaffected. For a more complete treatment of this subject, see: http://rescomp.stanford.edu/~cheshire/rants/Latency.html
an essay by Stuart Cheshire, author of Bolo.

 I finally got around to reading your article. It was very interesting.

I thought I had warned the reader that doubling his bandwidth would only help on large, bulk transfers -- but perhaps I overlooked it.

--Jim


 Duplicating a Linux Installed Hard Disk

I have installed slackware on my PC and I'm completely satisfied. I want to duplicate my linux installed hard disk : Can I use my 1st hard disk as a source and copy all of its contents to a 2nd blank linux-formated hard disk? If I put this 2nd disk into another PC, it will boot Linux normally?

 You can just use the 'dd' ("disk dump" or "data dump") command on the raw devices. This will work if the two drives are identical with no bad sectors.

Many years ago I'd have said you were an idiot to even consider it. Now I'd recommend against in much milder language.

The difference is that modern drives -- IDE and SCSI are capable of autotranslation (so the BIOS and often the Unix/Linux disk drivers don't need to know the true geometry of the disk. Most drives these days also have spare sectors on every track -- during a low level format spares are mapped into use for any bad sector on a particular track. Using this scheme (which is normally completely transparent to the host machine -- it's all in the drive's electronics) it is rare to see any bad sectors on a drive (until all the spares for a given track are used up).

So it is technical feasible to do this.

However I'd say that you're much safer to spend a little more time and "do it right."

Use fdisk to partition the new drive (presumably to set its partitions to match those on your first drive. You can do this without downing the system. I personally prefer to follow the advice and reboot after writing a new partition table -- but that's probably a force of habit from too many years of DOS and OS/2.

Then do amke2fs -c /dev/hdbX (where X is the partition number) for each of these new partitions.

Then do a:

  
		mount /dev/hdbX /mnt/tmp
		find . -mount | cpio -pvum  /mnt/tmp

... to each of them.

Now your are almost done. The only problem is that your lilo boot map (on your existing drive) probably doesn't match the lilo configuration on the new one.

The most reliable way of dealing with that is to take the new drive to the new system -- boot from a rescue floppy using the root=/dev/hdaX command line parameters (on the lilo prompt line from the rescue floppy) and edit the /etc/lilo.conf. Then run lilo and reboot.

That's all there is to it. That's about seven steps (with 3 of them being repeated for each filesystem on the drive(s). The amount of time this takes is dwarfed by the actual task of opening your case and getting the jumpers on the new drive working right (which is far worse for IDE than most SCSI in my experience).

Why is this better? Well it deals with bad blocks and small difference in geometry. It also ensures that the new copy is defragmented. Other than that -- it just "feels" like a better way.

--Jim


 Using the Linux Box as a Firewall

From: Tim Gray timgray@lambdanet.com
Hi, I have a small problem that might affect others out there.. I am trying to get my linux box to act as a "firewall" of sorts for my wife's Windows 95 computer. (I haven't been able to get her to switch yet) I installed ne2000 compatable boards in each, ran cable, installed everything as per per linux network administrators guide. The problem I have is getting Packets destined for internet to go out the modem line when it's not connected. I need a way to have linux automatically fire up my dial-up connection when it sees that the remote computers want to use it. and possibly kill the connection after a period of non use.

Thank you. Tim

 This arrangement is referred to a a "Proxy" server -- which is only a component of certain firewall architectures.

Specifically you appear to be trying to set up a "dial on demand Masquerading proxy host." (if I understand you correctly).

The first tool you need for this is called 'diald' -- (the 'dial daemon').

The most recent version that I know of is at:

ftp://sunsite.unc.edu/pub/Linux/system/network/serial/

... and is named:

 
		 diald-0.16.tar.gz

I just set this up (literally while this draft was loaded in my mailer). It was suprisingly easy.

Just edited the make file (just to change the LIBDIR, BINDIR, etc directories to point at /usr/local/...) did a make and a make install. Then I created a file named /etc/diald.conf with just the 'lock' directive in it. I did this so I can more readily support multiple diald configurations -- as I'll explain presently:

I created a /etc/diald/ directory and put in a file like:

 
device /dev/modem
connect "chat -f /etc/ppp/connect"
speed 38400
modem
defaultroute
crtscts
redial-timeout 120
connect-timeout 120
mode ppp
dynamic
local 192.168.1.1
remote 192.168.1.2
include /usr/lib/diald/standard.filter

Obviously yours will differ in a few spots. the -f parameter to your connect line should point to whatever chat script you use manually. You might change the device line -- although I highly recommend that you consistently configure all of your packages to use /dev/modem (which is just a symlink to the real serical device on my system).

I currently have diald, pppd (manual), uucp, kermit, minicom, and mgetty all sharing this modem and properly using the same lock files throughout.

The local and remote addresses are apparently arbitrary -- I use addresses that are listed in RFC1918 (nee 1597) which reserves several sets of addresses which the IANA/InterNIC promise not to give out to "real" internet sites.

Then added the following two lines to my /etc/rc.local:

 
		modprobe slip
		/usr/local/sbin/diald -f /etc/diald/rahul

(Where the rahul file is the one I've listed above and refers to one of my PPP providers).

Once you have your system reliably dialing your provider on demand -- the next step is to get routing working from your wife's system to the internet.

I would recommend bringing up the ppp connection manually and doing all the routing/masquerading/proxying configuration and testing with the line "nailed" up.

--Jim


Previous "Answer Guy" Columns

Answer Guy #1, January 1997
Answer Guy #2, February 1997
Answer Guy #3, March 1997


Copyright © 1997, James T. Dennis
Published in Issue 16 of the Linux Gazette April 1997


[ TABLE OF 
CONTENTS ] [ FRONT PAGE ]  Back  Next