Well, Red hat now takes two CD's to install. No more leaving it alone, I guess. Unless, of course, you have two CD drives, because the installation now apparently supports that (I don't have a machine to test that with).
I installed this on a clone (Intralink 2000) Intel box with a Pentium III 600 Mhz, 128 MB ram, 10.2 GB Fujitsu IDE drive and two 3c905C nics. The install went smoothly in graphical mode, but it didn't see one of the 3Com cards. After finishing the install, I noticed that one of the cards wasn't seated well, so I reseated it and powered back up.
I thought it was odd that kudzu didn't notice the new (reseated, but new to it) hardware, but I just added it in to /etc/modules.conf- noting that /etc/conf.modules, which was a horrifically dumb name to start with, no longer exists- gee, I would have left it as a link to modules.conf, but that's OK. I rebooted, and the card was recognized, but then something really strange happened: I had been installing this machine in my living room because there was just too much going on in my office. But now that it was up and running, I brought it there to plug into my network to test. To my complete surprise, this boot brought up Kudzu happily proclaiming that it had found a new 3Com card! OK.. sure.. go ahead and migrate the existing configuration.. huh?
Well, whatever. It came up fine, and although ultimately this will be a firewall providing NAT to its own clients, for the moment it is a client on the SCO machines NAT list while I complete its configuration.
The first order of business would be to go out to RedHat and get new software. However, an included pamphlet said "Before you do anything else.." and told me about this new Red Hat Network, which seemingly replaces the Update Agent I would have normally gone right to. Well, OK, I'll play along: I clicked on the RHN icon and registered myself and the machine as instructed. That part was fine, but finishing the registration left me hanging out in the cold. What was I supposed to do now? Tiny print in the RHN pamphlet told me to go to http://www.redhat.com/network, so I did, and that brought me to nice screen that showed me all the errata, security advisories and bug-fixes that applied to my system. Great, but I couldn't see anyway to just get it all at once; it seemed to require me to select each package individually. While that didn't seem like much fun, I figured I'd give it a try, but quickly found myself stymied- the subsequent pages presented me with three choices: download now, queue for the Update agent, and download later- but darned if I could make any of those work, so I said the heck with it and went straight to the Update Agent, which promply downloaded and installed 77 megabytes of stuff.
Strangely, after this, I went back to the RHN webpage, and found that everything except queueing now worked (I had de-selected a few packages in the Update Manager just so I could check this)! OK, so maybe I needed updates before I could get updates, or maybe I did something wrong, but no matter what, I don't see the point: why use that when the Update Manager seems to be a whole lot easier? I must be missing something.
Oh well, onward and upward. The back of the Red Hat 7 box bragged about the inclusion of a graphical firewall configuration tool, and as this machine ultimately will be providing such services, I wanted to take a look at that. It was easy to find (too easy): "Firewall-config" is listed right there in the System list. Boy, what a disappointment. Yes, this is a graphical configuration tool- but all it does is let you type in ipchains rules- it doesn't do any default configuration, doesn't help you select services to block or anything like that. There's far better stuff available in the web, and frankly if you know ipchains well enough to use this as is, you'd probably find it quicker just to type the stuff in like you always have.
However- that's probably not what they meant, because further down is Lokkit, which *is* the the kind of "what do you want to do" tool I was expecting. It's unfortunate that "Firewall-config" is in the menu at all; unless someone knows what Lokkit is (or had read the Release Notes, of course), they could easily miss this. I'll be updating this review with more information on that later on.
That tool also pointed out a gaffe on Red Hat's part. They've changed the locations of a number of directories, including /usr/doc, which is now /usr/share/doc. The Firewall Tool has a Help button which points at the old location, so of course it fails- you'd think Red Hat would have left in symbolic links for these changes! Anyway, the things changed are:
Since none of these have symlinks to the old locations, you might think someone at Red Hat had too much dealing with SCO and hates such things, but no, actually some new symlinks have been added:
Some of the other new stuff (certainly not complete):
The boot screen can now be graphical- it's pretty, I guess. There's supposedly some limited USB support: I didn't have any USB devices so can't say.
One major change is to inetd: there's no inetd.conf anymore. Instead, it's xinetd.conf and the xinetd.d directory- this is not just a cosmetic change; you'll want to read the xinetd man page carefully.
Sar is included. While it is not as inclusive as SCO's version, it certainly is good to see it, and I hope it develops more power.
OpenSSH is included now- that's a good thing for sure.
The lpr has been replaced by LPRng- this is a better lpr, with some Sys V'ish emulation features- you'll want to look into this more deeply; see .
The default "ls" alias still messes up your screen with those incredibly dumb color changes that mess you up if you've telnetted from a SCO console. A quick fix for telnet is to CTRL-] and type
!setcolor -nTo kill it, type:
alias ls='ls --color=never'
but that doesn't help with vi and man and who knows what else- I wish I knew a way to just turn all this off at once. A TERM setting like "wy50" will shut off color, but of course it messes you up in other ways.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2009-11-07 Tony Lawrence
Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. (Edsger W. Dijkstra)