Disclaimer
Intro
Installation
PCMCIA Ethernet
up2date
Modem
802.11b wireless Ethernet
ntpd
Mozilla
External USB hard disk
General opinions
Update December 13, 2001
Tried installing Mandrake
Update December 28, 2001
Link to external USB hard disk driver
Update January 6, 2001
Fix for having to start the dialer as root
(All the sections are on this page)
The information here is based on my personal experience (or occasionally the experience of someone else who is credited). I hope that it's useful but I don't guarantee that it is correct or that it will be useful to you. If you find something unclear, misleading, or wrong or you have other suggestions for improvements, please mail me at matt@mondoinfo.com.
A while ago I installed Red Hat Linux 7.1 on my Thinkpad 240X for use as my daily laptop and I've come to like it very much. That was actually my second experience with Linux on a Thinkpad. Previously, I had used Red Hat 6.1 on a Thinkpad 240 (a plain 240, no X) and that worked well too. I got the 240X because it was so darned cheap at eCost.com that I decided that it would be a good idea to have a backup. Since then I've used the old 240 to try out various things that I didn't want to try out on the machine I use every day. Among the things I've tried is installing FreeBSD, an OS that I like very much and routinely use on servers. Alas, it didn't work right on the 240. A warm boot (after starting Windows, for example) would work fine but a cold boot would result in a hang partway through the boot process.
When Red Hat released version 7.2 of their Linux distribution, I decided to install it on the 240 and see how I liked it.
The installation itself was straightforward: I created PCMCIA boot floppies according to Red Hat's instructions, plugged in a cheap Addonics PCMCIA CD drive, and let the installer do the default laptop installation. The installer for 7.2 gives a little more information about what it plans to do than the installer for 7.1 did and I think that's an improvement. During the installation, I opened ports in the local firewall for sshd and ntpd (22 and 123). It turns out that sshd isn't installed by the default laptop installation (reasonably enough) but it was easy to get the openssh-server RPM file from the first installation CD and install it by hand.
Booting and launching X were uneventful and the Nautilus file manager is certainly pretty. It's too bad that Eazel is no longer in business but that folks can maintain and distribute their code certainly shows one of the virtues of open-source development.
Getting networking up was a little more of a challenge. The kernel recognized my 3Com 3CXE589ET PCMCIA Ethernet card without trouble (two happy beeps on boot and no problems reported in /var/log/messages) but /sbin/ifconfig showed that no eth0 device had been configured. The Network Configuration program (you can type neat in a shell window or run it with its icon in the System Settings folder under Nautilus's friendly Start Here folder) didn't show any way to configure a PCMCIA Ethernet card, nor did the Internet Configuration Wizard. I poked around in the various GUI tools and in the docs but didn't find any useful information. If there's a way to do it with Red Hat's tools, it's not obvious.
So I checked the configuration on my 240X and decided to use that handy system administration tool, vi. In /etc/sysconfig/network-scripts, I created a file ifcfg-eth0 containing:
DEVICE=eth0
USRCTL=no
ONBOOT=yes
BOOTPROTO=dhcp
and rebooted. Networking came up correctly. After that, I ran neat and it printed some messages about finding the file ifcfg-eth0 and copying it here and there. neat still showed nothing under the hardware tab but an eth0 device under the devices tab. I had tried adding it there earlier but all that was available in the device type popup was a wireless device. That's still the case even now that the eth0 device is listed. Go figure. Under Red Hat 7.1, netcfg worked fine so at least in this case the new snazzier GUI tools represent a step backward.
Once I had networking working properly, I wanted to make sure that the new system was fully patched. Since I bought Red Hat 7.2 rather than downloading it, I ran rhn_register to register it and get my free 30 days of painless updates using up2date.
As an aside, I like up2date. It seems that Red Hat stays on top of bugs and security holes pretty well and installing improved versions painlessly with a few clicks is just great if you ask me. I've been a sysadmin for some time and have patched systems in a bunch of different ways and I think that up2date is about the nicest way of doing it that I've come across. I was a little concerned about letting it update the C library and (especially) the kernel (updating the kernel requires up2date version 2.5.4 or later, run up2date --version to check) but by now up2date has updated the C library four times and the kernel five times for me, each time without any problems. That being said, I think that Red Hat's pricing sucks. US$20 per month for the service is excessive. I think the service is valuable and I'll cheerfully pay for it. Indeed, I bought the OS rather than downloading it because I'm glad to pay Red Hat for what they do. But US$20 per month for up2date is too much and 30 days for free is too little when you've paid them the better part of US$100 for an OS that you could have downloaded.
In addition, it seems that as things stand right now, the 30 days for free offer doesn't work right. The registration process went fine but the new "entitlement" didn't appear when I went to http://rhn.redhat.com and clicked on Entitlements. I've informed them of the problem and they'll probably fix it shortly.
But all that is moot as things stand. You get one "entitlement" (i.e. a machine that up2date will work on) for creating an account and as far as I can tell, that entitlement lasts forever. And here's the thing: you can switch that entitlement around among machines as much as you want. So keeping two machines patched with one entitlement is just a matter of clicking around a bit at http://rhn.redhat.com.
Red Hat presumably doesn't intend for one to keep an unlimited number of systems patched using up2date for free forever. But I have no compunctions about keeping my two systems updated that way until their pricing gets a little more reasonable.
In any case, there were a bunch of updates despite the release being less than a week old and up2date applied them all painlessly.
Next on my list was getting my handy Zoom 2975L modem to work. (There may be a way to get the 240's internal Linmodem to work but I already have the Zoom PCMCIA modem so I haven't been motivated to try.) Configuring it was easy enough with the GUI tools but getting it to dial was more interesting. If you start RH PPP Dialer from the Start (sorry, foot) menu, it opens a window but doesn't let you dial and doesn't tell you why it won't. You need to start it as root even if you've checked the "Allow all users to enable and disable the device" checkbox in the GUI configuration tool. The easiest thing is to su in a shell window and start it as rp3. Kind of makes it pointless to put the thing in the menu I think.
But a bigger deal than that in my opinion, is that if you don't store your password in the configuration, the dialer sits forever saying "Waiting to connect". A look at /var/log/messages makes it clear that wvdial (the chat program responsible for logging in) has noticed that there isn't a password in its configuration file and exited, but the GUI window doesn't seem to notice. A look at wvdial's man page shows that there is no provision for prompting the user for a password. And a look at /etc/wvdial.conf shows the password there. It's not a really big security risk but I still think it's pretty lame. There should be a provision for prompting the user for the password. A look at my Red Hat 7.1 installation shows that it's the same there. I don't know why I didn't object to it then, but I should have.
Next up was my Agere (formerly Lucent)
Orinoco
Silver wireless Ethernet card. Remembering that the
Network Configuration GUI tool (/usr/bin/neat) previously only wanted
to let me add a wireless device, I clicked over there to see if it would
work for this purpose. It didn't. Clicking to add a device, it now gave
me the choice of adding a wireless device or a modem. I chose to add a
wireless device and made the obvious configuration choices. Then neat complained
that I wanted this device to use eth0, the same interface that my PCMCIA
Ethernet card uses. Well, yes, I do.
It might well be just fine to have the wireless card use eth1 or some such but I expect that that would cause some problems down the road and there's no reason that that the two cards shouldn't use the same interface. Since I want the card to use eth0, I quit neat without saving changes and went back and looked at the card's configuration under 7.1 and made the same changes to /etc/pcmcia/wireless.opts that work there. And all was well, almost.
Ethernet worked fine but DNS didn't, even using my (wireful) 3Com Ethernet card. A few minutes' poking around showed that /etc/resolv.conf was empty and a few more minutes poking around showed that that was because the DHCP client, /sbin/dhcpcd, was being run with the -R option which prevents it from rewriting resolv.conf with the addresses of the DNS servers that the DHCP server provides. A few more minutes' poking around showed that that was because /etc/sysconfig/networking/devices had the line PEERDNS=no in it. I don't know what PEERDNS is supposed to mean and I don't know just when that got added to the file but I do know that I want to use the DNS servers that the DHCP server specifies so I commented that line out and then everything did work correctly.
I like to keep the clocks on all my machines synchronized using ntpd. There are reasons that that's kind of pointless on a laptop but I like to do it anyway. Weirdly, I didn't find an option to turn ntpd on in the Service Configuration GUI tool and found it instead in the Date/Time Properties GUI tool. It seems that since I turned it on there, it then appeared in the Service Configuration tool.
First, it's necessary to fix the firewall rules to allow UDP packets through. That's even if you specified that port 123 should be open when you did the installation because the installation only allows TCP packets through on ports you open. So the line in /etc/sysconfig/ipchains that allows port 123 through needed to become:
-A input -s 0/0 -d 0/0 123 -p udp -j ACCEPT
You may want to restrict the source IPs and maybe the destination IPs.
But there's another problem: ntpd is started far too early in the boot process to work with a PCMCIA network card. Here's an extract from the log at boot time:
Oct 30 21:42:43 example ntpd[773]: ntpd 4.1.0 Wed Sep 5 06:54:30
EDT 2001 (1)
Oct 30 21:42:43 example ntpd: ntpd startup succeeded
[about 25 lines]
Oct 30 21:42:46 example cardmgr[837]: executing: 'modprobe 3c589_cs'
Oct 30 21:42:47 example cardmgr[837]: executing: './network start
eth0'
And it seems that if ntpd doesn't see a network interface when it comes up, it doesn't go looking for one again later. After booting, I got:
$ ntpq
ntpq> pe
remote
refid st t ...
===================================== ...
LOCAL(0) LOCAL(0)
10 l ...
But if I restarted ntpd, it would find the proper time server:
# /etc/rc.d/init.d/ntpd restart
Shutting down ntpd:
[ OK ]
Starting ntpd:
[ OK ]
# ntpq
ntpq> pe
remote
refid st t ...
================================= ...
LOCAL(0) LOCAL(0)
10 l ...
tick.example.co 0.0.0.0
16 u ...
I can't begin to guess why Red Had decided that ntpd should be started so early in the boot process. In any case, starting it at the right time is simple. First I turned off ntpd using the Service Configuration GUI tool and then I added this to the bottom of /etc/rc.d/rc.local:
echo -n "Synchronizing with time server... "
/usr/sbin/ntpdate -s -b tick.example.com
echo
echo -n "Starting ntpd... "
/usr/sbin/ntpd
echo
Of course, you also need to put the right values in /etc/ntp.conf but that's pretty straightforward. Without the comments, mine looks like this:
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
server tick.example.com
driftfile /etc/ntp/drift
authenticate no
The 240's APM implementation seems to be slightly less sophisticated than the 240X's. That's good for my purposes because it's not necessary to turn all the APM stuff off to allow ntpd to stay synchronized.
Mozilla is the default Web browser under Red Hat 7.2. It runs a bit like a pig on this small box. Happily, there's Opera. I like open source software but I also find that there's a lot to like about Opera.
I was hoping to be able to use a Buslink external USB hard disk with the machine. It seems like a reasonably attractive backup strategy: for the price of two 2GB Jaz platters, you get 20GB of removable (in the sense of unpluggable) storage, albeit in a rather larger box. Alas, there doesn't seem to be any easy way to make it work under Red Hat 7.2. Rats.
There's nothing in Red Hat 7.2 to make me switch my daily laptop from 7.1. Nautilus is pretty but I doubt that I have a use for it and the GUI configuration tools seem to be at best half-baked. I imagine that they work fine if you're configuring a vanilla machine but configuring a vanilla machine has never been all that difficult. It's the unusual and obscure stuff where you could use some help.
Previous versions of Red Hat were configured in ways that geeks like me like just fine: you'd find the right text file to edit and add the correct values as the code or the examples in the comments directed. You could use an occasional simple GUI tool (netcfg, printtool) if you felt like it. In version 7.2, they seem to have raised the bar on themselves: they want non-geeks to be able to configure the OS. I'm sure that they'll get there but they haven't yet. And alas, in trying to make things easier for non-geeks, they seem to have made configuring the machine a bigger nuisance for geeks. I hope that they fix that too.
Update December 13, 2001
Tried installing Mandrake
For no particularly good reason, I've always used Red Hat distributions of Linux. Since version 4.2, I think. And while I've always liked the Red Hat distributions pretty well, various folks whose opinions I respect have suggested to me that other distributions may be better. So I decided to try out Mandrake on my Thinkpad 240 and ordered a set of CDs for version 8.1. I could have downloaded it all but I think that downloading an entire distribution is a nuisance. For US$30 delivered, I was happy to pay Mandrake for the CDs.
My credit card was charged on November 11 for the order I had placed a day or two earlier. In the last few days of November, I hadn't yet received the CDs and so I mailed Mandrake's US customer service address to ask if I would be receiving them soon. The next day Mandrake spammed me with a "newsletter" that I hadn't asked for. I then sent them another email suggesting that an answer to my question about the status of my order would be more welcome than spam. Another day later, I called them and the nice person I spoke with assured me that my order was "in process" and explained that some of the delay was a result of their having recently moved their US warehouse. I suggested that they might want to keep their customers up to date on the status of their orders and that I hadn't received a reply to my email of a few days earlier. She said that there was only one person to answer all US customer service email. I tried to explain that an automated email about my order's status would have saved her answering my phone call and would no doubt save that lonely person from having to answer so much email. She didn't seem to understand what I was getting at and didn't think that it would be useful to bring my suggestion up with other folks in her company. On November 30, I got a reply to my first email assuring me that my order was in process. I received the CDs on December 7.
I wasn't in any particular rush to get the disks but I will say that charging my credit card three weeks before sending the goods is not likely to make me a happy customer. But even more than that, Mandrake appears to be a technology company that doesn't want to use simple technology to save themselves work and make their customers happy. If they can send out spam automatically, they ought to be able to send out order status information automatically.
In any case, I finally had the CDs and decided that trying out Mandrake would be a fun weekend project. I had a look at the docs and created a PCMCIA boot floppy according to the instructions. (It's much like Red Hat in this respect.) Unfortunately, the resulting boot floppy wouldn't recognize either of my PCMCIA CD-ROMs (one from Addonics and the other from IBM). I found that a bit odd since Red Hat's PCMCIA boot floppy recognizes both of them just fine. I looked around for some additional documentation and fiddled around with the installer's options a bit but I confess that I didn't spend a long time working on the problem.
I found that the boot CD did recognize my PCMCIA Ethernet card. So I sighed a bit and decided to do the installation across the network. Starting it up was easy. I picked a nearby mirror and in short order the installation was trundling along.
Some ten or fifteen minutes later when the installation was 1% done or so, the installer reported that there were "problems" downloading a particular file and asked if it should proceed without it. How in the heck am I supposed to be able to answer that question? It might have been that the mirror was corrupt or it might have been that the file had been updated and a better version would be downloaded some time later in the installation. But the installer provided no clue about the likely explanation.
I started the installation over again (possibly foolishly using the same mirror) and got the same error at the same spot. This time I told it to continue and got the same error on different files twice more before aborting it again.
At that stage, I gave up. I don't doubt that with enough work, I could have gotten the installation to work. Perhaps there's a parameter that would have made the installation kernel recognize one of my PCMCIA CD-ROMs. Perhaps another mirror would have had all the files intact. And I almost certainly could have published the installation CD on a local FTP server and installed from the local network. But I wanted to try out Mandrake to see if it was better for my purposes than Red Hat and if the installation on my Thinkpad was going to cause me that much aggravation and make me go to that much work, it's not better for my purposes than Red Hat is.
Update December 28, 2001
Link to external USB hard disk driver
Ernst Sichtermann kindly wrote to point out the driver for the Buslink external USB disk at http://bravin.home.cern.ch/bravin/usbide.html. He says that it works well for him.
Update January 5, 2002
Fix for having to start the dialer as root
Jason Goodman of the University of Chicago kindly wrote with a fix for having to start Red Hat's PPP dialer as root:
I found the answer to this problem a few moments ago: you need toIt may be that that's also done by one of Red Hat's updates since I don't recall doing that and the file on my disk has read permission for everyone.
chmod +r /etc/sysconfig/network-scripts/ifcfg-ppp0
Back to home