I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
There's plenty of controversy in the SCO community concerning Linux. Some see it as the death knell for SCO, others as a positive force, others as something in between. No matter what you think, you probably agree that learning something about it is important.
I've been trying to do just that. Honestly, it isn't easy: I am stuck in my ways, it ticks me off when things don't work the way I expect them to, and my real desire is just to stick my head in the sand and hope this all goes away. Realistically, that's not going to happen. So once again I have ventured into Linux-land.
The installation of RedHat 5.2 went smoothly. I had a supported graphics card, a supported network card, all SCSI drives and CDROM, so there was nothing to mess up. After a very short period of time, I was up and running.
The very first thing I wanted to do was configure a ppp connection to my ISP, but I immediately ran into problems: I could not access my modem. I suspected cable problems, so I swapped cables from a working system, but no luck. Finally I discovered that /dev/cua0 was actually pointing to what is normally COM2 on this box! Switching the cable to that finally allowed me to at least talk to the modem.
But I wasn't out of the woods yet. The RedHat installation guide told me to use "linuxconf" to configure ppp. Strangely, the Control-Panel application pops up in root's desktop, and very obviously Network Configuration was one of its options, but I ignored that and went with what the manual told me, and got absolutely nowhere. The wizard asked all the right questions, but when I clicked "connect", nothing would happen. Frustrated, I clicked on the Control Panel Network Configuration, which showed me that the ppp0 link was inactive. I activated it, and it immediately dialed, connected, and set the default route (I had selected that as an option in the configuration).
I found this difficult to believe, so I deliberately removed the ppp0 link and began again: sure enough, the "linuxconf" would not work, but the Control Panel did.
DNS configuration was equally confusing: I had specified my nameserver within the ppp configuration, but I noticed that didn't give me any control of search order. Looking again within linuxconf, I found Name Service, but when I used it, it complained about an invalid line in /etc/resolv.conf. I checked that, and understood the problem: there was an additional "nameserver" line but with no argument- just blank. I removed that manually, and then linuxconf was happier.
At this point, I had a working system that could access the Internet using Netscape Communicator 4.0.7. I wasn't too pleased with what it had taken to get there; it actually hadn't involved all that much time, but it made me wonder what I could trust and not trust. So, I started scouting around.
Near the top of the Control Panel is an Icon for setting System time. It made the appropriate disapproving warnings about "wreaking havoc" with my system if I actually should dare to do this, and warned me that I probably should immediately reboot when I proceeded to adjust the time anyway.
Within linuxconf, strangely seemingly part of the "logs" section, I found another tool which also let me adjust the time, this time without any warnings of impending doom. It's this kind of inconsistency that bugs me the most about Linux, but then again, I'm not the most consistent person in the world myself.
I decided next to look at printer configuration. I saw the icon in Control Panel, but I couldn't find anything in linuxconf, and when I checked the Install Manual, I found that it too told me to use Control Panel (right after a glowing paragraph that extolled the virtues of linuxconf). So, I clicked on the Printer Icon, and got warned that I couldn't print to Netware printers because I hadn't installed "ncpfs". That's OK, I don't have any Netware printers. What I have is a SCO 5.0.4 box set up to accept remote jobs, so that's what I wanted to print to. Nicely, after asking for the remote host and queue, it let me specify a filter, which brought up an impressive pick list of printer types, including my HP Laseret 6L. I also noted that it apparently was ready to apply Ghostscript without further effort on my part, though it did warn me that I might want to update to Ghostscript 4.0..3. It offered options to fix stair step, to send a formfeed at the end of the job, to control margins, and to specify any extra Ghostscript options I might need. So far, I was impressed.
It didn't last long. When I tried to print a test page, it told me that it couldn't connect because no demon was running. Indeed, that was seemed to be true: a ps -e | grep lpd returned nothing.
The Linux folk are chuckling now: I realized just a little later that the correct syntax for Linux would be "ps ax | grep lpd". The "ax" doesn't bother me; I can remember that. It's the dumb leaving off of the "-" that annoys me (it still works, it just complains and whines at you if you use the dash).
Warren Young <[email protected]> noted: Linux's ps now complains about the dash because eventually the dash will make it obey Unix98 command line options (yes, "ps -eaf" will work), but leaving the dash off will use "traditional" extended BSD arguments. You can turn off the warnings for PS by defining the environment variable I_WANT_A_BROKEN_PS. RTFManpage. So I started lpd manually, and it printed. Trying to figure out what went wrong here, I rebooted, and found (with ps ax) that lpd had started up just fine, and now the test pages printed without intervention on my part. Something a little screwy there, but at least it works.
I next tried to print a Postscript test page. The results weren't so great- the very top of the page was OK, but then it went to page after page of blanks. Actually, that could easily be my fault-I didn't check what interface I was using here, and I would definitely need to pass it through raw, so we won't complain about Linux yet. I decided to let that go for the moment and move on. I'm sure the problem is at the SCO end; I'll fix it later and try again.
So, I've got a working Internet connection, a printer connection that's at least OK for text, and a working local network. But oh that local network drives me crazy!
This is the result of netstat -rn:
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 10.1.36.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo
Note that the gateway for everything is 0.0.0.0. When the ppp connection comes up (having been told to use that for its default route), it looks like this:
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 188.8.131.52 0.0.0.0 255.255.255.255 UH 1500 0 0 ppp0 10.1.36.0 0.0.0.0 255.255.255.0 U 1500 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 3584 0 0 lo 0.0.0.0 184.108.40.206 0.0.0.0 UG 1500 0 0 ppp0
Isn't that bizarre? When I try to telnet to something on the internal network, it notes that there are two interfaces, and (fortunately) chooses the correct one. When I try to do a "route add 10.1.36.0 10.1.36.99" (the Linux machine's address) or to "127.0.0.1", it fails- possibly I haven't got the syntax for Linux quite right yet, we'll see.
Warren Young had some explanations for this, too: In the output of "route -n" or "netstat -nr", 0.0.0.0 in the Gateway column means "none set". If you leave off the -n switch, you see a * in this field, which means the same thing. No gateway means that the table entry is a direct route to the hosts matching the given pattern.
That's why the kernel "chooses the right interface": if you try to telnet to 10.1.36.42, the kernel notices that the 10.1.36.0 route table entry with a netmask of 255.255.255.0 matches it, so it sends the packet to interface eth0.
You don't need to add IP-address specific route table entries in order to get Linux routing to work. In my experience, Linux routing is much smarter and more flexible than Unixware routing, and apparently SCO Unix routing as well. That's not to say that one OS can do something that the other can't, but that the Linux routing commands are simpler to understand for a given task when compared with other systems' methods.
Your syntax for the "route add" command is indeed wrong. You want to say: "route add -net 10.1.36.0 netmask 255.255.255.0 dev eth0" to match the table entry that the Linux network subsystem adds for you. See the /etc/sysconfig/network-scripts directory for the scripts that handle this.
You may notice that the command above is more complex than the one you wanted to use. That's because of the odd netmask, which Linux wants you to provide because it realizes that while 10.x.x.x is a class A address, the default netmask for this class would mask off the other octets (1.36) you're providing, so it wants you to provide the nonstandard netmask -- it won't try to guess. For simple class A, B or C addresses, the route command will supply the appropriate netmask for you.
One nice thing about the Linux way of specifying routes is that it deals well with dynamic addresses, such as for DHCP or PPP. (Yes, a Linux box can be a DHCP client as well as a server!) This is because you bind routes to interfaces, not to the interface's IP address. The same thing applies to the kernel's packet filtering code: you can bind reject rules (for example) to the ppp0 interface before it even exists, and they will come into effect when that interface comes up. This makes a Linux box a good foundation for a firewall because there is no delay between the interface coming up and the reject rules going into effect.
I'm not sure I agree 100% with Warren's argument that Linux is doing a Good Thing here, but it's no big deal: if that's the way it wants to work, it's OK.
Another thing that mildly annoys me: you run startx on ALT-F1 but it actually runs on ALT-F7 -that is, if you switch away after starting X and then want to come back, it isn't on ALT-F1- it's ALT-F7. I can get used to it.
Warren corrects me: The X server attaches itself to the first _unused_ virtual console when it comes up. On a Red Hat box, there are six VCs set up by default, so the X server attaches to the seventh VC. This is useful because back on VC1, where you started X, you can see any messages that the X server emits.
By the way, Linux's "startx" script is not like SCO's- it doesn't look for more than the first display.
Well, that's enough Linux for today. Next time I'm going to install some of the Power Tools that came with the distribution, and we'll see if I can ever get to love this system.
© May 1999 Anthony Lawrence. All rights
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2011-05-01 Tony Lawrence
Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. (Mark Twain)