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.