Saturday, November 16, 2013

SCO OpenServer 5.0.0


A while back I got SCO OpenServer 5.0.5 running in a VM from a old CD my Dad had lying around.

Buoyed by that success, I got him to dig a little deeper and he came up with an OpenServer 5.0.0 CD as well. 5.0.0 was the first OpenServer release, from way back in 1995. It was the follow-up to and major overhaul of their 3.2v4.2 release. It had a journaling filesytem, shared object libraries, Motif-based graphical desktop, graphical system administration tools, SMP support... Lots of good stuff. We loved it. I have gushed before about how much better OpenServer was than Linux at the time so I won't go into it again.


I configured VMware much like I'd done for 5.0.5. 128m of ram, an 8g drive (huge for 1995), a floppy drive, and I put the CD ROM on IDE 0:1.

The installation itself was a bit more challenging than 5.0.5. The first challenge was finding a boot disk. The 5.0.0 CD wasn't bootable. Not surprising. No CD from that era was. Neither drives nor BIOS even supported it then. The CD didn't even contain a directory with boot disk images though. Hmmm. What to do?

I seemed to remember that occasionally SCO would put out replacement boot disks and boot-loadable driver disks for various reasons, usually to make it possible to install on odd hardware....

To make a long story short... I dug around around on the Xinuos site and found oss444a which is a boot floppy image that adds support for installation from a cd attached to a non-primary alad (adaptec 2940) card. Fortunately it also happens to support IDE drives. I was able to boot with it and run the installer but at the very last phase, the installer couldn't create a kernel that was capable of booting from an IDE drive. Fortunately I also found oss451b, an updated, boot-loadable, IDE driver, and between the two, I got it to work.

It still wasn't trivial though. You've got to give it a boot string.

link defbootstr mem=1m-64m

The "link" part means "I'm going to provide a boot-loadable driver in a minute" and the rest means "reserve a block of contiguous memory for the installer's ramdisk."

After entering that and hitting return, the installer starts and prompts: "What packages do you need linked into the system, or q to quit?:"

The correct answer to this question is:


I found that in the release notes for oss451b. I believe "wd" means "Western Digital". If I remember correctly, SCO's generic IDE driver started off as a driver for Western Digital IDE chipsets. Or something like that.

The installer then has you switch disks back and forth like a game of musical chairs before finally running for real and asking you to identify the installation media device.

The correct answer is "SCSI CD ROM" even though VMware is emulating IDE drives. The Adapter Type is "wd". Apparently the wd driver looks SCSI to the OS. Each IDE channel appears as a separate SCSI Host Adapater and master/slave are mapped to SCSI ID's 0 and 1. So, for a CD attached to IDE 0:1, use Host Adapter 0, ID 1. Leave both LUN and BUS set to 0. It took me many tries to figure all that out.

The installer is fairly intuitive. License codes are required. I disabled Bad Tracking in the Hard Disk Setup. Otherwise it takes forever to format the disk. I had to specify the AMD PCNet-PCI Adapter manually and give it an IP address. DHCP is not supported. 5.0.0 doesn't support VESA graphics, so I left it with IBM VGA. The mouse to use is "Low Resolution Keyboard Mouse".

Eventually the installation can be left unattended.

openserver 5.0.0 - 1. installation

Unfortunately it doesn't boot properly after installation.

Well, it kind-of does. It boots to single user mode but then crashes and dies on the way to multi-user mode. If you poke around long enough, you'll discover that the license manager has a y2k bug that eventually causes it to exit and this wreaks such havoc on the rest of the system that it fails to boot.

The solution is remarkably simple. Boot to single-user mode. Set the date to a date prior to 2000...

date 1103005899

Run the license manager "scoadmin license" and re-license the OS, then set the date back to the current date and reboot.

Ta da!

openserver 5.0.0 - 2. scologin

Man that brings back memories.

So did the desktop.

openserver 5.0.0 - 3. desktop

There was a good bit of post-install tweaking to do.

I added a user for myself using useradd.

I'd configured the IP address during installation but DNS and a default route still needed to be configured.

As with 5.0.5, there's probably some file somewhere that the default route goes in but I've never been able to find it. We always edited /etc/tcp directly and added a line like:

/etc/route add default > /dev/null 2>&1

after this line:

/etc/route add 0 > /dev/null 2>&1

It appeared to work.

I created an /etc/resolv.conf too


...and rebooted to apply everything.

When the system came back up, I could ping and telnet in and out. All right!

Next, I installed the rs500d supplement. Every OpenServer release was eventually followed up with a release supplement. In the case of 5.0.0, there were eventually 4 follow-up supplements. rs500d is the latest and fixed lots of stuff.


It doesn't just patch the OS. I needed to install the Development System before applying the supplement or I'd just have to do it again later.

I set the date back using that same trick as before and ran the software manager:


The software manager is named "custom" as in "to customize your system" I suppose.

I selected Software->Install New->From osr500->SCSI CD-ROM Drive 0->SCO OpenServer Development System->Full and entered the license number, code and data. When the installation was complete I exited and reset the date.

To install the rs500d supplement, I ftp'ed the VOL files from, re-ran custom, selected Software->Patch Management->Apply Patch->From osr500->Media Images, entered the directory I downloaded the VOL's into, and selected Full. It complained about some verification errors which I selected Continue to get past, but otherwise appeared to install correctly. I've since looked into the verification errors. Something is apparently wrong with the file /etc/badtrk. It's not clear what the problem is exactly but I'll probably never use that program so I didn't worry about it.

I also disabled the graphical login as I would not likely be using it for a while:

scologin stop
scologin disable

Yes. Text.

openserver 5.0.0 - 4. text login
Remote Access

Remote access was next on my list. Telnet and ftp are enabled by default but that's just not good enough. It's ssh or nothing!

Actually, first I installed sudo.

During the late '90's and until the mid '00's, SCO put out "Skunkware" CD's containing open source software ported to OpenServer. They also put this same software on their "other" ftp site at: as tar or cpio archives containing "VOL-files" which can be installed using custom.

I downloaded sudo from there and installed it using custom. Unfortunately SCO's packaging of sudo doesn't work out of the box and required a few tweaks. sudo doesn't like it if /etc/sudoers is a symlink and it really doens't like it if /etc/sudoers isn't owned by root:root.

cp /etc/sudoers /etc/sudoers.file
rm /etc/sudoers
mv /etc/sudoers.file /etc/sudoers
chown root:root /etc/sudoers

After that, after adding /usr/local/bin to the PATH varaible in /etc/default/login and after adding a line for myself, I was able to sudo properly.

Back to remote access though...

openssl, prngd zlib and openssh are available from skunkware but after a little trial and error, I discoverd that the openssh that's available doesn't work on 5.0.0.

To resolve this, I installed openssl, prngd and zlib and also installed gcc-2.95.2p1, all from skunkware and then built openssh-3.4p1 from source:

./configure --prefix=/usr/local/openssh-3.4p1
sudo make install

Except for requiring gcc, it built without a hitch.

I enabled X11Forwarding, disabled UsePriviledgeSeparation in the sshd_config file, symlinked xauth...

mkdir /usr/X11R6
mkdir /usr/X11R6/bin
cd /usr/X11R6/bin
ln -s /opt/K/SCO/XServer/5.2.0p/usr/bin/X11/xauth xauth

(because apparently openssh specifically wants xauth to be in /usr/X11R6/bin)

...put together a quick init script at /etc/rc.d/init.d/sshd


case "$1" in
killall sshd
echo $"Usage: $0 {start|stop}"
exit 1

exit 0

...and enabled it to run at boot:

chmod 755 /etc/rc.d/init.d/sshd
cd /etc/rc2.d
ln -s ../init.d/sshd S98sshd

I also tweaked prngd a little. It leaves a lock file lying around that prevents it from running at boot if it isn't shut down cleanly. I added a workaround for that to /etc/init.d/RMTMPFILES

rm -f /usr/local/var/prngd/prngd.lock

Whew! Reboot.

Et voila: ssh.

I did do one more thing... The openssl package only provides static libraries. This causes problems for my Rudiments software. Since the openssh that I built linked those libraries in to itself statically, the libraries themselves are no longer required. I used custom to remove the package.

File Transfer

FTP was already enabled. The addition of openssh gave me scp and sftp, both client and server. I was in business. Almost. It's great to be able to upload and download files but it's not so great if you can't extract them.

OpenServer comes with compress/uncompress and tar but lacks gzip, bzip, zip, unzip and GNU tar. All of those are available from skunkware though, so I installed them.


Mosaic 2.4 comes with OpenServer but struggles with modern web sites. Netscape 3.04 runs but also struggles.

Netscape 4.5 should work but complains about missing AppDefaults and doesn't run. I'd swear I used to use it though. There's probably some solution, but it would struggle with modern web sites anyway.

Lynx and wget were available from skunkware and I installed them.

It's funny how consistent lynx is. It's pretty much always worked and still works. Even older versions still work with most web sites. I guess there's something to be said for minimalism.

On the server side, various versions of Apache are available from skunkware but only 1.2.5 installs cleanly on OSR 5.0.0.

All the associated documentation recommended installing some supplements though, so I also installed the net100, rs40b and oss449f supplements from SCO's ftp site using the same method that I used for rs500d. They also complained about verification errors and oss449f complained about not copying pppd. I guess those issues are OK though.

I configured apache to run on port 80 (it was set to 8080 by default) and set it up to start at boot.

cd /etc/rc2.d
ln -s ../etc/apache S98apache

It appeared to be configured to support cgi's by default and after starting it up, appeared to generally work as expected.


Yes, development. What I'm always really up to.

The native development system can't compile my software but gcc can and the 2.95.2p1 that I had to install to get openssh working is definitely a modern enough version.

Bash, CVS, GNU make, readline, perl and php are available from skunkware and I installed them. Python is too but version 2.3.4 requires newer libraries than provided by 5.0.0. Version 1.5 and 1.5.2 are available but SQL Relay requires at least 2.1. Postgresql is available but it requires FSU-pthreads and linking against them causes runtime relocation errors for some reason. I've never been able to get it to work.

I had a few issues getting rudiments to compile. mkstemp is defined in the headers but not implemented in the libraries. sys/time.h isn't extern "C" wrapped. statvfs requires -D_SVID3 to be defined. And the biggest issue, which I randomly discovered the solution to... If you enable debug when compiling and then link your objects into a shared object library using -shared rather than -belf (which libtool insists on doing) then it will error out at link-time with reloaction errors. However, this only happens if you enable debug at compile time. Without -g during the compile, linking with -shared works fine. Weird.

At any rate, those issues were easy to solve and I had the sqlrelay client working soon.

$ uname -a
SCO_SV osr500 3.2 2 i386
$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.54
Connected to: fedora19:9000 as test

type help; for help.

0> select banner from sys.v_$version;
Oracle Database 12c Enterprise Edition Release - 64bit Production
PL/SQL Release - Production
CORE Production
TNS for Linux: Version - Production
NLSRTL Version - Production
Rows Returned : 5
Fields Returned : 5
System time : 0


Again though, the server side was useless without a database to talk to.

DOS Utilities

SCO has classically had fairly good integration with DOS and Windows, at least for the time. Even Xenix could run DOS under VPIX and provided various tools like doscp, dosformat, dosls, etc. to manage dos-formatted disks. 5.0.0 had similar integration. While playing with the dos disk tools, I discovered an issue though. The A drive is mapped to /dev/install which is buffered or something and attempts to access it fail. I had to update /etc/default/msdos and remap it from /dev/install to /dev/rfd0135ds18.


I vaguely remembered this issue from way back. I don't think it's a VMware problem.


SCO took VPIX to the next level with OpenServer 5.0.0. The installation CD came with software called SCO Merge and I had a demo/developemnt license for it. Merge came with DOS 6.22 pre-installed and could run Windows 3.1 or 3.11 on top of it.

I'm pretty sure Merge was the predecessor to Win4Lin. When Win4Lin came out, it supported Windows 95 but something about it reminded me of Merge. I think Merge 4 (which came with a later version of OpenServer) supported Windows 95 too but I'm not sure.

At any rate, I installed SCO Merge 3.1.1f from the CD similarly to how I installed the Development System above.

I almost bought a copy of Windows 3.1 off of eBay but my Dad came through with a set of images before I did. Apparently the one of the guys at his shop's Dad had an old set lying around. Dad's are great.

All attempts to install it failed until I realized that Merge was having the same issue with the floppy that the dosutils were having. I dug for a long time but couldn't find a config file with drive mappings in it. /etc/default/merge has parameters in it but there's nothing describing what else could go in that file. I also found the mrgconfig and mrgadmin programs which are somehow related to Merge configuration, but they were undocumented and obtuse.

Eventually I realized that the "dos" and "win" programs themselves took arguments, one of which would allow you to remap the A drive. I ended up eventually adding $HOME/bin to my PATH ahead of all other directories and creating "dos", "win" and "winsetup" programs in $HOME/bin with the following contents:


/bin/dos +aa:=/dev/rfd0135ds18


/bin/win +aa:=/dev/rfd0135ds18


/bin/winsetup +aa:=/dev/rfd0135ds18


I could now access the A drive properly and install windows.

I had to do this on the console though, so I renenabled the graphical login:

scologin enable

It took several attempts to install Windows before I discovered what all was necessary to get it to install properly. The key was that the Windows installer requires 4mb of RAM to run, there are separate DOS and Windows configurations , and it's the DOS configuration, not Windows that is used during installation.

The process:

  • log in to the graphical desktop
  • configure DOS to use 4mb
    • open Merge tools folder
    • run DOS & Windows Configuration
    • select DOS and click Modify
    • bump Standard Memory up to 4m
    • click Save
  • open a terminal window
  • install windows
    • run: winsetup
    • run: a:\setup
    • follow windows installation instructions for an Express Install, swapping floppies as necessary
    • when it asks about J:\DOS\EDIT.COM, select the default "MS-DOS Editor"
    • when it asks about J:\DOS\LP.EXE, select "Norton Line Printer"
    • skip the tutorial
    • at end select "Return to MS-DOS"
    • type quit to exit MS-DOS

During that process, I had to "zoom" the screen so Windows could take over completely. To be able to run Windows in an X Window, I installed the Merge Graphics Driver.

  • open a terminal window
  • run: win
  • select Zoom from the Window menu
  • run Windows Setup
  • Options -> Change System Settings -> Display -> Other display (Requires disk from OEM)...
  • DOS Merge Windows/X
  • OK, OK, Restart Windows


openserver 5.0.0 - 5. merge


For some final tweaks, I added the following to my .profile so I could run merge to a remote DISPLAY:

export XMERGE

Merge is a little quirky because it just puts stuff directly in your home directory. I ended up with .exe and .sys and .bat files in there and a windows directory. It was kind of messy. I think I'd have preferred for those things to be under a Merge directory or something.

Merge was novel to play with but I couldn't really get much to run. I used Mac's and SCO Unix back in the windows 3.1 days and I'm not really well versed in how to set up networking in Windows 3.1 or whether Merge even supports it for that matter. I could download software to the VM and install it using the shared filesytem, but that was about it.

Eh... Fuel for future articles.



In addition to Merge, SCO appeared to be hedging their mid-90's Windows integration aspirations with WABI. WABI means Windows ABI. Apparently Sun developed it to run Windows apps on their Sparc platforms and SCO bought it from them or something. It's basically a primitive Wine-like environment plus a program manager.

I installed it from the CD as described above for Merge and the Development System.

WABI also required a Windows installation. My guess is that it implements enough of the 3.1 kernel to enable native Windows DLL's to run on top if it but doesn't reimplement the DLL's like Wine does. Hard to say though.

WABI didn't appear to have any trouble with the floppy drive like Merge and the dosutils had, and before long I had it up and running.

openserver 5.0.0 - 6. wabi

When I first ran WABI, it complained that it was already installed and that I was attempting to install it again. It was, but I was not. Weird. I just hit cancel and the next time I ran it everything ran fine.

WABI had a few strange requirements though. It only runs in 1, 4 or 8 bit color mode so I had to run it on the console. I couldn't redirect it to a remote display without setting the machine running the remote display to 256 colors. It also uses a private colormap, so when you go into the main WABI window, the rest of the screen goes crazy and when you exit the WABI window, the WABI window goes crazy. Hah. It's been so long since I've seen that, I forgot all about it.

I couldn't get much of anything to install or run but I didn't try super hard either. I do remember way back trying to run Netscape under WABI. It ran but took eons to load anything. That was on a 486 though. With modern computing horsepower behind it, I ought to be able to get it to run something.

Again, fuel for future articles.

Virtual Disk Manager

The Virtual Disk Manager is nowhere near as photogenic as WABI or Merge. But, it was also on the installation CD, and I had a license for it, so I installed it and played around with it.

Basically, it provides Software RAID, Striping and Disk Concatenation and a fancy GUI for configuring all of that. You can also use it to set up mirroring of the root and swap partitions.

Using it was very straightforward. I installed it from the CD using custom like I did for the Development System, Merge and WABI. Then I shut down the VM, added 2 more IDE drives and started the VM back up.

Before the Virtual Disk Manager can use the drives, Unix has to know about them. I logged into the graphical desktop as root and ran:

  • System Administration
  • Hardware/Kernel Manager
  • Hard Disk
  • Configure Driver


  • Add a hard disk to IDE controller
  • Use entire disk for Unix

I skipped creating divisions and ran that second part a second time to add the other disk. I don't think so but I may have had to reboot at that point. I don't remember and don't have it in my notes.

Once Unix was aware of the new disks, the Virtual Disk Manager could use them.

The general process is to run the UI by opening System Administration -> Filesystems -> Virtual Disk Manager. Then selecting Disk -> New.

At that point, you can select disk operation you want to do. If you have enough drives, you can create RAID's of level 5, 4, 53 and 10. With only two drives, you can stripe data across drives, mirror drives or concatenate drives into one virtual drive. Virtual drives are made up of "pieces". After selecting an option, you pick the drive that you want to allocate to each "piece". The drives will be available as /dev/dsk/1s1 and /dev/dsk/2s1. If you mirror drives then it will make you wait while it restores parity between them. After that, it lets you pick the filesystem type that you want to format the virtual drive with, it formats it, and then you're done.

The virtual disk is available as /dev/dsk/vdisk3 or similar and can be mounted like any other partition.

Drive Concatenation might allow you to add more disks later and extend an existing partition. I didn't try that but it occurred to me later to try it.

There's also an operation named "Simple" that doesn't appear to do anything other than map a single disk to a virtual disk. I'm not sure what it's good for.

You can also mirror the root and swap devices using the Boot -> Mirror Root option. I tried this. It's straightforward. It configures a few things, relinks the kenel and upon reboot, mirrors the root drive in the background, as evidenced by the furiously blinking hard drive light and slower-than-usual system response. You can unmirror it too but this also requires a reboot. I didn't try simulating a disk failure but that would be fun to do.

There's also a Database option that was kind of cryptic. I think it lets you store metadata about the virtual disk configuration in a raw partition as opposed to a file in one of the filesystems. This could be useful for recovery. I remember having to manually rebuilt the LVM metadata once on a Linux machine after it was lost in a root partition failure. No fun.

The Virtual Disk Manager was really easy to use. It's almost unfortunate that we never used it. We never needed to though. We always had hardware RAIDs.

Quirks and Oddities

SCO Unix is full of quirks and oddities. Here are just a few:

  • At boot there are options for entering single-user mode and setting the date/time. There are timeouts for both prompts. However, hitting enter at the initial boot prompt disables the timeouts and makes it sit on the prompt to enter single-user mode forever.
  • There is no "halt" command.
  • Use the delete key rather than ctrl-C on the command line.
  • Home directories are created under /usr rather than /home.
  • Root's home directory is /
  • There is no "which" command
  • PATH is set in /etc/default/login for console logins but ssh appears to hardcode its own PATH before running .profile
  • /usr/bin/X11 isn't in the PATH by default
  • ./ is in the PATH
  • The shell doesn't know about ~ but it does know about $HOME
  • X is X11R5

And the most annoying one... The .profile runs a tset command that guesses your terminal type and then prompts you for whether it was correct or not. This makes ssh'ing remote commands a pain because you have to hit return manually to accept the terminal type. Without this command, the TERM type appears to generally get set correctly. Just comment it out in the .profile:

#eval `tset -m scoansi:${TERM:-scoansi} -m :\?${TERM:-scoansi} -r -s -Q`

But I'm not here to judge. A lot of those quirks wouldn't seem so quirky to someone who grew up on Unix. They're just different from what we see today.


I've got plenty more playing around to do with this system. I'd like to get some software running under Merge and WABI. My Dad probably has some older Xenix and 3.2v4.2 software somewhere that should run on it. I'd like to get my software to build using the native toolchain. It'd be great to get a database of some kind running and run the SQL Relay server components on it.

Plenty more to do. Plenty more.

Retrocomputing with Redhat 2.1


Not long after getting Redhat 3.0.3 running, I dug around on a bit, looking for 2.1. It turns out, if you google it and search through 10 or 12 pages of the results, you'll find a forum discussion where someone indicates that it can be obtained at: Ha ha!

Oddly, there's no wikipedia entry on InfoMagic. In the 80's and 90's, they and similar organizations, downloaded everything they could from BBS's and the fledgling internet, put it on CD and sold it cheap. Even with a decent modem, it was often more convenient to get software on CD from InfoMagic than to download the software yourself. As the "" website says, "Who knew that the companies looking for a quick buck through the late 1980's and early 1990's with "Shovelware" CDs would become the unwitting archivists of the BBS age? No one did, but here we are, looking back, muttering thanks to these souless con artists as we plunder the very data they themselves took from a time now past." Yeah, yeah. I'm not taking sides.

At any rate, apparently InfoMagic put out a CD with Redhat Linux 2.1 on it at some point and now it's archived at Excellent.


Creating something installable from the files available at that URL was a bit of a challenge, but I was up to it.

I downloaded...

wget -np -l 0 -r

...moved things around and removed the "value-add" software and other cruft...

mkdir bluesky-i386
mv* bluesky-i386
rm -rf
cd bluesky-i386
rm -rf libs demos Networking JE
rm -rf rr_moved ls_lr_2
rm -f `find . -name TRANS.TBL`
rm -f `find . -name index.html`
cd ..

...fixed permissions...

cd bluesky-i386
for file in `file \`find .\` | grep executable | cut -f1 -d":"`; do chmod u+x $file; chmod g+x $file; done
cd ..

...and created an iso image.

mkisofs -J -r -R -v -T -o bluesky-i386.iso bluesky-i386

I read somewhere that the codename for 2.1 was "bluesky" so I called the image bluesky-i386.iso. In case you were wondering.

The installation was nearly identical to Redhat 3.0.3. I copied out the boot0012.img and ramdisks. VMware was a no-go, so I installed in QEMU...

redhat 2.1 - 1. install

...and converted the resulting image to a VMware disk, which ran just fine.

redhat 2.1 - 2. First Login

The only issue I had was that during install, creation of a swap device failed. It apparently put the swap configuration in the /etc/fstab, but the partition wasn't properly formatted. So, post-install I had to manually format it.

mkswap /dev/hda 133024

This gave a warning. Apparently that number wasn't exactly right, but it still appeared to work.

Post install, I did the standard set of housecleaning tasks. I added a user for myself, disabled services I didn't plan on using and fiddled around with X windows.

X Windows gave me as much trouble under 2.1 as it did under 3.0.3.

SVGA was constrained to 320x200.

redhat 2.1 - 3. SVGA

VGA kind-of worked but looked weird.

redhat 2.1 - 4. VGA

Mono was ok.

redhat 2.1 - 5. Mono

See my 3.0.3 notes for getting it working. The process is nearly identical. The only difference is that mounting the CD is a little trickier under 2.1. There's no /mnt/cdrom or fstab entry, so you have to do a little more work:

mkdir /mnt/cdrom
mount /dev/hdc /mnt/cdrom

Manual network configuration was identical to 3.0.3 except that I used a different hostname and IP address.

Remote Access

Getting remote access working was very similar to 3.0.3. I had to build openssl-0.9.6c, zlib-1.2.8 and openssh-2.9p2 from source. I even had to add the V1_3_WILL_DO_THIS_FUNKY_STUFF line. But there were some subtle differences.

openssl required a "no-threads" option:

./Configure linux-elf no-dso no-threads

openssh didn't require the "--without-random" option.

CPPFLAGS="-I/usr/local/zlib-1.2.8/include" LDFLAGS="-L/usr/local/zlib-1.2.8/lib" ./configure --host=i686-pc-linux-elf --prefix=/usr/local/openssh-2.9p2 --without-shadow

zlib was the same.

Enabling the sshd server was identical.


As with 3.0.3, 2.1 came with the Arena browser, but it struggled even harder than the version that 3.0.3 came with. I'm not sure it even supported HTTP 1.1.

I was able to get the same versions of Mosaic and Netscape running. 2.7b5 and 3.04 respectively:

redhat 2.1 - 5. Mosaic redhat 2.1 - 6. Netscape

I did get lynx-2.8.7 to build from source by tweaking src/LYCurses.h and moving the chtype definition above the #ifdef:

typedef unsigned long chtype
#ifdef USE_SLANG

...and disabling color-style.

./configure --prefix=/usr/local/lynx-2.8.7 --disable-color-style
sudo make install

I built wget-1.5.3 without issue too.

On the server side, apache-0.8.14 was available, enabled by default and straightforward to configure.

More X Tweaking

After getting all that running, I tweaked X Windows some more. Enabling xdm was as simple as setting the runlevel to 5 in /etc/inittab.


...and rebooting.

redhat 2.1 - 6. xdm

Not exactly beautiful, but it worked.

I also ran an X server under Cygwin on my Windows machine and ran an entire X session to it. This made it possible to see what the session was kind-of supposed to look like.

redhat 2.1 - 7. remote X session

Again, not exactly beautiful, but if I remember correctly, in those days everybody had .fvwmrc files that they'd been fine-tuning for years. Nobody used the default desktop except maybe on SGI machines.


Playing with X windows is fun, but the end goal for me is to get my software running and put the VM in my build farm.

Redhat 2.1 comes with gcc-2.7.0 - sufficient to build my stuff. Perl 5.001m and 4.036 are also available, as is Python 1.2 and TCL 6.4, all too old for me.

As on 3.0.3, I had to build cvs-1.11.23 and make-3.82 from source. Though 2.1 comes with both, the CVS it comes with doesn't know how to use sshd and the make that it comes with doesn't understand some of my Makefile directives.

The only quirky issues I ran into while building my code were in Rudiments. No surprise there. Since Rudiments is the abstraction layer that all the rest of my software is built on, it's supposed to be the place where all the issues crop up. Apparently RTLD_GLOBAL isn't defined at all on Redhat 2.1, the dlsym() function takes a char * argument rather than const char *, and netinet/tcp.h isn't extern "C" wrapped. All easy to work around.

Before long I could access Oracle via SQL Relay.

[dmuse@redhat21 dmuse]$ uname -a
Linux 1.2.13 #1 Mon Oct 23 21:56:50 EDT 1995 i686
[dmuse@redhat21 dmuse]$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.54
Connected to: fedora19:9000 as test

type help; for help.

0> select banner from sys.v_$version;
Oracle Database 12c Enterprise Edition Release - 64bit Production
PL/SQL Release - Production
CORE Production
TNS for Linux: Version - Production
NLSRTL Version - Production
Rows Returned : 5
Fields Returned : 5
System time : 2


But nobody even considered running a database on Linux of this vintage so the server components were hopelessly useless.


2.1 is very similar to 3.0.3. The installers were almost identical. The X sessions were the same. They were both elf and libc5-based. They both used kernel 1.2.13. 3.0.3 came out less than a year after 2.1 with some important but subtle improvements. I read somewhere that 3.0.3 almost came out as 2.2 but somebody decided it would be better to name it 3.X. It would seem that there is some validity to that, or if not, I could see how someone might imagine it to have been true.

Retrocomputing with Redhat 3.0.3


A while back, apparently longer ago than I thought until I looked at the dates on the screenshots, I got a hold of a Redhat 3.0.3 CD and gave it a try.

For a while now, I've been trying to get a collection going of the final Redhat releases for each version. Ie. 1.1, 2.1, 3.0.3, 4.2, etc. 5.2 and up aren't too hard to find on the web but anything older than that is. You've got to get creative. Back in the mid to late 90's, various publishers produced books with names like "Linux Unleashed" that came with CD's in the back. As it turns out, one of them came with Redhat 3.0.3 and it's still available on Amazon for like a dollar.

It actually ended up costing me about $10 before I was done though. The book's just a dollar but shipping cost about $4 and the first one I ordered was missing the CD. The second one took almost a month to arrive at my house too. I had almost forgotten about it when it finally did and it was a nice surprise.


I usually try to get OS'es running in VMware but old linux boot disks don't usually like VMware. 3.0.3 was no different. LILO hung at LI. Qemu worked better though and I was able to get a complete install going.

I did this by loopback-mounting the CD, copying out the images/1213/boot0012.img disk image, along with images/ramdisk1.img and images/ramdisk2.img and running everything like:

qemu-img create redhat\ 3.0.3.img 2g
qemu-system-i386 -fda boot0012.img -hda redhat\ 3.0.3.img -cdrom picasso-i386.iso -boot a -curses

The installation was pretty straightforward. I had to swap floppies when prompted. It had that authentic '90's feel. There were a few quirky things. I had to configure X to use the VGA16 server and a "ps2-bus" mouse. Also, I don't remember exactly what happened now but after trying to set up networking over and over I eventually just gave up and told it not to configure the nework, other than to set the hostname. Otherwise the install went smoothly.

After making sure it booted, I converted the qemu disk to a vmware disk...

qemu-img convert redhat\ 3.0.3.img -O vmdk redhat\ 3.0.3.vmdk

...and migrated it over to VMware where it booted just fine.

redhat 3.0.3 - 1. first login

I guess VMware's floppy emulation isn't good enough for old linux. I've had that same issue a few times. The kernel can't boot from a floppy but the same kernel can boot just fine from the hard disk.

At any rate, once I got it running, I did some housekeeping - I added a user for myself and configured the network manually.



#>>>Device type: ethernet

#>>>Variable declarations:
#>>>End variable declarations



/etc/hosts: localhost redhat303



I disabled some services I wans't planning on using, like ancient SAMBA, NFS and the INN server. Anyone remember newsgroups? I'm waiting to run into a distro with a gopher server.

I also fiddled with X. Like other old distros, X is hard to get working well in VMware with Redhat 3.0.3. If you try to use SVGA, the video card is identified as "Generic SVGA" and resolution is constrained to 320x200.

redhat 3.0.3 - 2. svga

Hilariously unusable.

VGA16 is a little better but the color scheme is wild.

redhat 3.0.3 - 3. vga16

For whatever reason, Mono always seems to be the most usable to me.

redhat 3.0.3 - 4. Mono

X configuration was very quirky. I had to install the SVGA and Mono servers from the distro CD, even though I told the installer to install everything.

mount /mnt/cdrom
cd /mnt/cdrom/RedHat/RPMS
rpm -i XFree86-SVGA-*
rpm -i XFree86-Mono-*

Xconfigurator is quirky too. It doesn't give you the option to select the Mono server at all, it creates an XF86Config file with a Microsoft mouse, independent of whether you select that mouse type or not, and it crashes out near the end. It does create a semi-workable XF86Config though, under /etc/X11, and if you don't mind manually linking the appropriate X server to /etc/X11/X...

ln -s /usr/X11R6/bin/XF86_Mono /etc/X11/X

...then it is possible to get something working.

Remote Access

I wasn't actually all that interested in getting X working though, I really wanted to see if I could get my software working on the system and add it to my build farm.

For that, I needed to get remote access working.

Actually, before that even, I needed to get sudo working. Redhat 3.0.3 is too old to come with sudo, but version 1.6.9p23 compiled just fine from source as long as I configured it not to try to use pam, which Redhat 3.0.3 is also too old to come with.

./configure --prefix=/usr/local/sudo-1.6.9p23 --without-pam
make install

Getting ssh working was a little challenging. Again, 3.0.3 predates ssh, ssl and even a new enough version of zlib to build openssl.

openssl-0.9.6c can be built with a little coaxing.

./Configure linux-elf no-dso
make EX_LIBS=
sudo make install EX_LIBS=

That EX_LIBS= goofiness is because even though no-dso is specified, the build process still tries to link in -ldl. In the Makefile, EX_LIBS=-ldl is set. Manually overriding it on the command line works around the issue.

zlib is straightforward.

./configure --prefix=/usr/local/zlib-1.2.8
sudo make install

openssl-2.9p2 can also be coaxed into building.

You have to edit includes.h and somewhere near the top, before the #includes, add:


I'm not kidding, that's what you have to add. Feel free not to and track down why yourself. It's entertaining.

The actual build is somewhat straightforward other than having to tell it where to find zlib.

CPPFLAGS="-I/usr/local/zlib-1.2.8/include" LDFLAGS="-L/usr/local/zlib-1.2.8/lib" ./configure --host=i686-pc-linux-elf --prefix=/usr/local/openssh-2.9p2 --without-shadow --without-random
sudo make install

3.0.3 doesn't support shadow passwords, and the --without-random flag is there because, though /dev/urandom exists, it doesn't work. The configure script finds it though, and tries to use it unless you tell it not to.

After all that, I enabled X11Forwarding in the sshd_config, wrote a quick little init script at /etc/rc.d/init.d/sshd


case "$1" in
killall sshd
echo $"Usage: $0 {start|stop}"
exit 1

exit 0

...enabled it to run at boot...

chmod 755 /etc/rc.d/init.d/sshd
cd /etc/rc.d/rc3.d
ln -s ../init.d/sshd S90sshd

...and started it up.

/etc/rc.d/init.d/sshd start

Worked like a charm. xauth was installed with the main installation so X forwarding worked fine too.

Woohoo! I could ssh in.


Redhat 3.0.3 comes with the Arena web browser, which struggled with modern web sites, to say the least. Mosaic 2.7b5 and Netscape 3.04 also run but struggle as well. Netscape was neat though. Back then it had an integrated Mail and News reader and an HTML editor. I'd forgotten about all of that. It was fun to play around with it.

I tried getting a semi-modern version of lynx to build but it turned into a monumental undertaking. 3.0.3 has ncurses, but doesn't have version 5 or 6 which are the only versions lynx supports. I couldn't figure out how to make it ignore curses outright either. Weird.

I did get wget-1.5.3 to build:

./configure --prefix=/usr/local/wget-1.5.3
sudo make install

On the server side, Apache 1.0.3 was installed. It was old enough to still have an srm.conf file, but the configuration hasn't changed too much over the years and I had a quick and easy time getting it to work and even to serve CGI's.


Redhat 3.0.3 comes with gcc 2.7.2 which is modern enough to build my software. Perl 5.001m, Perl 4.036, Python 1.3 and TCL 7.4 are on there too, but they're all too old to be supported.

It came with CVS 1.7 too but it was too old to know how to use ssh. Make 3.71 was too old to understand some of the directives in my Makefiles. I had to build cvs-1.11.23 and make-3.82 from source but there were no issues doing so.

My software built and ran but I had to make a few tweaks to Rudiments. It appears that the various getXXXbyYYY_r functions (like gethostbyname_r) are defined in the header files but not implemented in the C library. Rudiments' configure script detected them by doing a test compile and was able to build the library, but later on apps linked against it failed with unresolved symbol errors. Grrrr. I updated Rudiments' configure script to do a test link rather than just compile and it successfully detected that the functions were missing.

I've had to do similar to get Rudiments to build on other platforms.

Fortunately, that's all that was required and I was able to get the SQL Relay client software working.

[dmuse@redhat303 dmuse]$ uname -a
Linux 1.2.13 #1 Sun Feb 11 01:26:41 EST 1996 i686
[dmuse@redhat303 dmuse]$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.54
Connected to: fedora19:9000 as test

type help; for help.

0> select banner from sys.v_$version;
Oracle Database 12c Enterprise Edition Release - 64bit Production
PL/SQL Release - Production
CORE Production
TNS for Linux: Version - Production
NLSRTL Version - Production
Rows Returned : 5
Fields Returned : 5
System time : 1


Unfortunately, 3.0.3 is too old to come with any databases. No MySQL, no PostgreSQL, no SQLite even, so I couldn't run the server-side components. Maybe later I'll shoehorn a database onto it. For now, it's just neat to see it running at all.

Sunday, November 10, 2013

Consulting and Development Services

Just a reminder...

Consulting, Support and Integration Services for SQL Relay or other firstworks technologies are available and General Consulting and Software Development Services are also available.
  • I have expertise in:
    • C/C++ on Linux/Unix
    • Embedded Linux systems
    • Database-Driven Applications
    • System and platform migration
    • Systems and applications for small businesses
  • And experience with:
    • Java, PHP, Python, C#, Visual Basic and other languages.
    • Windows and Mac OS X
So how can I help you?
  • Need help converting your existing apps to use SQL Relay?
  • Need help developing new apps that use SQL Relay?
  • Need a feature that SQL Relay doesn't currently provide?
  • Need SQL Relay to run on a new platform?
I'm your guy.
  • Need a custom app for your small business?
  • Need a legacy app migrated to a modern platform?
  • Need to squeeze some life out of an old app or older Unix platform?
  • Need to integrate some odd set of dissimilar applications?
  • Need help with an Embedded Linux app?
I've done plenty of that, all of that, for clients all over the world.  I might be your guy.

Send me an email or give me a ring.  For contact info, click here.

Wednesday, November 6, 2013

.1 Updates

Hmm, it appears that I was a little too hasty in that last release of Rudiments and SQL Relay.

It turns out there were some documentation errors and they didn't build successfully on every platform in my build farm.  Most significantly though, there was an error in one of the Makefiles that cased a "make clean" to abort partway through the build.  This could cause problems for automated build systems.

So, .1 updates of Rudiments and SQL Relay are now out - 0.44.1 and 0.53.1 respectively.