2009/10/08 by Bill Mohrhardt
I am working on building a Linux box to replace our old SCO Openserver machine, and I had a spare Digi host card and concentrator, so I needed to install & configure those. Red Hat Enterprise Linux 5 was not listed, so I called Tech Support to ask which version I should try. The tech said to try dgap-1.3-15.src.rpm, the most recent beta version of dgap from Digi's website. He said that if I wanted support I would have to pay $75, as the PCI host card whose serial # I gave to him had its warranty expire in 2004. Fine, I proceeded on my own, as usual.
Now, given that I installed RHEL 5.3 from rpms, and did not
compile my own kernel, I figured that I would be missing some packages,
but it turned into a major pain. First of all, Digi's instructions
require rpmbuild, so thanks to pbone.net, I got
rpm-build-188.8.131.52-9.el5.i386.rpm, and that installed nicely. Then, the
dgap source said that it needed elfutils, so I eventually found the
elfutils matching my version on RHEL5 elfutils-0.137-3.el5.i386.rpm.
Oddly, when I checked rpm -qa | grep elfutils, my RHEL5 had
elfutils-libelf-0.137-3.el5 and elfutils-libs-0.137-3.el5, but not just
the plain elfutils.... Whatever, that rpm'ed fine. But then, the dgap
install got most of the way finished, and complained that it needed
curses (funny, I had already been providing some of those!). When I
checked my rpms, I had ncurses but not curses. I tried setting curses as
a symlink to the most recent ncurses library but that did not work. I
Googled around, and one linux site said that I needed the ncurses-devel
package, but when I downloaded and tried to rpm that one, it said that
it needed some other libraries, so I decided to go home at that point.
The next day, I Googled around some more, and one site said that when downloading ncurses-devel, you must make sure to get the same version as your ncurses. My RHEL5 had ncurses-5.5-24.20060715, and again pbone.net had the matching rpm for that, so I downloaded and rpm'ed, and that went through no problem. With the ncurses-devel library in place, the rpmbuild --rebuild dgap-1.3-15.src.rpm actually worked! So now I had the dgap rpm and again the rpm command installed that. Now, I try mpi to configure the card, and the menus get to the point where I choose the type of card (Digi C/X), and then seems to hang. Now I did a ps -ef | grep pts/1 to see if it was a process gone awry, but there was no CPU usage on that port, and there was a long command listed as a process that appeared to be the next question that the mpi menu was trying to ask. After some muttering, I figured that it must be trying to do some graphics that would not display on the telnet session, so I killed it and executed it from the console. That did the trick. I then did the chkconfig --add dgap to add it to the boot-up list.
Then I was able to connect an old Wyse 160 monochrome terminal (yes, I still have one), and I set the baud rate with ditty ttya12 speed 57600. Then I sent echo 'Hello' > /dev/ttya12, and the polite greeting appeared on the terminal. Then I added a12:2345:respawn/sbin/agetty -L ttya12 57600 wy60 to /etc/inittab. To get it to re-execute with the changes, I then did telinit q. A login prompt appeared on the wyse terminal, and I started testing the application programs.
We still use the PCI-card-based Digis, as we have 5 active C/CON 16 concentrators at one location (linked via several pairs of Digi Fiber Modules), and another 2 at our other site. The nice thing about dumb terminals is that they just work, with no maintenance, and nobody messing around on the Internet. We don't use the monochrome Wyse units anymore, we use Spotline terminals that take any colour monitor and keyboard.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Bill Mohrhardt
© 2009-11-07 Bill Mohrhardt