Saturday, November 16, 2013

SCO OpenServer 5.0.0

Introduction

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.

Installation

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:

wd

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 192.168.123.254 > /dev/null 2>&1

after this line:

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

It appeared to work.

I created an /etc/resolv.conf too

domain firstworks.com
nameserver 192.168.123.37

...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.

However...

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:

custom

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 ftp://ftp.sco.com/pub/openserver5/rs500d, 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: ftp://ftp2.sco.com/pub/skunkware/osr5/vols 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
make
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

#!/bin/sh

case "$1" in
  start)
        /usr/local/openssh-3.4p1/sbin/sshd
        ;;
  stop)
        killall sshd
        ;;
  *)
        echo $"Usage: $0 {start|stop}"
        exit 1
esac

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.

Web

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.

Development

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;
BANNER
============================================================================
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production                                              
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
        Rows Returned   : 5
        Fields Returned : 5
        System time     : 0

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.

#A=/dev/install
A=/dev/rfd0135ds18

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

Merge

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/sh

/bin/dos +aa:=/dev/rfd0135ds18
#!/bin/sh

/bin/win +aa:=/dev/rfd0135ds18
#!/bin/sh

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

Score!

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)...
  • J:\MERGE\WINDOWS
  • DOS Merge Windows/X
  • OK, OK, Restart Windows

Bam!

openserver 5.0.0 - 5. merge

Merge.

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

XMERGE=vga
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.

Onward!

WABI

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

Then...

  • 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.

TODO

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.

Redhat 2.1

Introduction

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: http://cd.textfiles.com/infomagic/imagicldr199511/disk2/. 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 "textfiles.com" 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 cd.textfiles.com. Excellent.

Installation

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 http://cd.textfiles.com/infomagic/imagicldr199511/disk2/

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

mkdir bluesky-i386
mv cd.textfiles.com/infomagic/imagicldr199511/disk2/* bluesky-i386
rm -rf cd.textfiles.com
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.

Web

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
#include 

...and disabling color-style.

./configure --prefix=/usr/local/lynx-2.8.7 --disable-color-style
make
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.

id:5:initdefault:

...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.

Development

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 redhat21.firstworks.com 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;
BANNER
============================================================================
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production                                              
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
        Rows Returned   : 5
        Fields Returned : 5
        System time     : 2

0>

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

Conclusions

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.

Redhat 3.0.3

Introduction

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.

Installation

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.

/etc/sysconfig/network-scripts/ifcfg-eth0:

#!/bin/sh

#>>>Device type: ethernet

#>>>Variable declarations:
IPADDR=192.168.123.98
DEVICE=eth0
NETMASK=255.255.255.0
NETWORK=192.168.123.0
BROADCAST=192.168.123.255
GATEWAY=192.168.123.254
ONBOOT=yes
#>>>End variable declarations

/etc/sysconfig/network:

NETWORKING=yes
HOSTNAME=redhat303.firstworks.com

/etc/hosts:

127.0.0.1       localhost
192.168.123.98  redhat303 redhat303.firstworks.com

/etc/resolv.conf:

domain firstworks.com
search firstworks.com
nameserver 192.168.123.37

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
su
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
make
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:

#define V1_3_WILL_DO_THIS_FUNKY_STUFF

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
make
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

#!/bin/sh

case "$1" in
  start)
        /usr/local/openssh-2.9p2/sbin/sshd
        ;;
  stop)
        killall sshd
        ;;
  *)
        echo $"Usage: $0 {start|stop}"
        exit 1
esac

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.

Web

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
make
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.

Development

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 redhat303.firstworks.com 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;
BANNER
============================================================================
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production                                              
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
        Rows Returned   : 5
        Fields Returned : 5
        System time     : 1

0>

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, October 27, 2013

SCO OpenServer 5.0.5

Introduction

It seems like everybody hates SCO these days. But, there was a time... Way back, when they did good work, or at least work that enabled me to do good work. My understanding of SCO's history is a little fuzzy, but as I remember it, they spun off of Microsoft when Microsoft decided not to pursue Xenix. Either that or they bought Xenix from Microsoft. Something like that. Then they went on to develop a full fledged Unix for x86 and owned that market until Linux matured. In the mid-to-late 90's, Caldera began to challenge them with their Linux offering. SCO's technology lagged but they had a huge customer base. Eventually SCO proper got out of the OS business, changed their name to Tarantella and went on to continue development and support of their Tarantella platform. Caldera basically bought their customer base and ended up with their OS development business in the deal. Then leadership changed at Caldera. Caldera renamed themselves The SCO Group to capitalize on the name equity and began suing people left and right. That didn't go so well for them and I'm not exactly sure what happened next. They either renamed themselves Xinuos or Xinuos bought them, or something.

At any rate, before all of the politics, when I was a kid, my Dad used to run companies off of a PC, SCO Xenix (and later Unix), a Computone Intelliport (or later Intelliserver), and several dozen Wyse terminals. When I grew up, I wrote more software for those systems than I can even begin to remember.

Those were the days.

For a while, SCO Unix was pretty awesome too. When OpenServer came out in the early 90's, it had shared object libraries, a journaling filesystem, a Motif-based graphical desktop, graphical system administration tools, drivers written by the hardware vendors themselves and back-compatibility all the way to Xenix 286. Linux was still using coff binaries, libc4, ext2, athena widgets and you had to be really careful what hardware you tried to run it on. For a while, you could buy a single-user development version of OpenServer for like $100 too. I continued to use SCO, basically until the Linux distros started including ext3 and Gnome.

Between development versions and swag from old companies, my Dad and I ended up with several versions of SCO Unix and Xenix and software that ran on them. We used them for a while but for years now, the CD's and license keys have been sitting in boxes, collecting dust. He recently dug through all that though and came up with a copy of OpenServer 5.0.5, circa 1999.

5.0.4 and 5.0.5 were both very popular versions of OpenServer. Earlier versions were buggy and though later versions added DHCP and USB support, those features just weren't all that important on the server. Later versions suffered from competition with UnixWare, Solaris x86 and Linux too, and from general anti-SCO sentiment.

Installation

The first challenge with any of these older OS'es is finding an emulator that will actually boot them. Fortunately SCO OSR 5 is semi-supported by VMware. For a while, it was even one of the OS'es you could select from the OS list during installation.

I used an 8g disk and 128m of RAM, which I believe were the defaults and selected Other from the OS list.

The CD wasn't bootable though. Instead I had to mount it, find the boot disk image at images/boot/install.img and copy it out. The bootloader loaded fine but there is a trick to getting it the installer to actually run. I'm not sure where I found the trick, but I had it in some notes from the last OSR 5.0.5 install I did, umpteen years ago. Basically it needs a contiguous block of at least 32M of RAM, probably to load a ramdisk into.

The magic bootstring:

defbootstr mem=1m-64m

That actually allocates 63m of contiguous RAM. I might have gotten away with a 1m-33m parameter but 1m-64m was in my notes, so I used that.

OSR 5.0.5 - 1 boot

Apparently (according to my old notes), 8g drives are supported by default but if you want to use a drive larger than 8g then you have to add a biosgeom=(cylinders,heads,sectors) flag as well. cylinders=(#ofgig*1024*1024/63/255*2)-5. So, for a 30g disk, (30*1024*1024/63/255*2)-5=3911. You'd use:

defbootstr mem=1m-64m biosgeom=(3911,255,63)

Ha, I actually remember having to upgrade the bios in many of my old computers to support disks larger than 8g.

Anyway, after supplying the proper boot string, the installer started up.

I always thought the installer was attractive, as text-based installers go anyway.

It is a little quirky. You use arrows to move around, enter to accept an options and space to change an option. The cdrom drive isn't auto-detected, you have to specify whether it's on the primary or secondary bus and whether it's the master or slave. The "System name" prompt wants the host name. You can mostly accept the defaults.

One thing I always did though is turn off Bad Tracking, otherwise the installer will scan the drive and look for bad sectors. This takes eons and isn't necessary. Another quirk in the installer though... After turning Bad Tracking off, the installer still reports that its still on. It's not. There's just a bug in the installer.

OpenServer 5.0.5 doesn't support DHCP so you have to give it an IP address. It does support the emulated PCNet card though.

For video and graphics, use VESA SVGA (the default).

Oddly, the mouse is not configured by default and must be set to "Low Resolution Keyboard Mouse".

After all that, and otherwise accepting defaults, the installer will run unattended.

OSR 5.0.5 - 2 install

And when it's done, after a reboot, you get a fairly attractive graphical login.

OSR 5.0.5 - 3 first login

At one of the companies I used to work for, we named our servers after scientists. We'd swap that SCO logo for a photo of them and set the background to something appropriate as well. It was loads of fun.

Logging in revealed the Motif-based desktop.

OSR 5.0.5 - 4 desktop

State of the art for when it was released in 1995. Actually, I that's when I first saw it, in OpenServer 5.0.0. SCO released their OpenDesktop product back in 1990. It's possible that it came with the same desktop. I'm not sure.

A Post-Install Tweaks

Post-installation, as usual, I had to tweak a few things.

First, I created a user for myself with:

useradd -m

Next, I disabled the graphical login and I wouldn't be needing it in the future.

scologin stop scologin disable

Then I finished the network setup. The installer prompts for an IP address, netmask, hostname and domain name but fails to prompt for a gateway and DNS information.

Setting up DNS is straightforward. Create /etc/resolv.conf with something like:

domain firstworks.com nameserver 192.168.123.37

Adding a gateway is less straightforward. I remember from setting up 5.0.2 (Internet FastStart) that there is some file, somewhere in the system, that if you put the IP address of the gateway in it, it will automatically be set at boot. It's not in an intuitive place though and I had an impossible time finding it. For all I know, it only worked on 5.0.2. What we always did was edit /etc/tcp and look for a line like:

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

Then add a line after it like:

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

So that's what I did. After a reboot, I had networking.

I also fixed the man page system.

A little digressive background on the OpenServer man page system...

In OpenServer, man pages are actually served by a small http server called scohttpd. In theory, this is a really cool idea.

First, you can read the man pages by pointing a browser at port 457 and drilling down. However, if you want to crash a modern browser, go ahead and try that. The man pages are compressed with the "compress" format (which predates gzip) and apparently modern browsers think they can handle that and then die trying.

Second, you could install all the man pages on a "man server" and point the other systems at it using the MANPORT and MANSERVER environment variables rather than having to install man pages on every system in the network. In the late 90's this would have saved an appreciable amount of disk space. SCO software packages are even structured to make this possible. SCO never promoted doing this though, for some reason, and sadly, the feature went largely unused.

The man system has a bug though. The scohttpd server runs early in the boot process and some time later in the boot process, the socket files that it uses get deleted.

A quick fix is to edit /etc/rc and append:

/etc/scohttp stop /etc/scohttp start

...and reboot.

OSR 5.0.5 - 5 text login

Woohoo! Text login and working man pages.

Next, I installed the SCO OpenServer Development System and SCO Optimizing C Compiler from the distribution CD.

SCO's package manager is an interactive program called "custom". As in, to "customize" your system.

It, along with the rest of the system-administration tools, is written in TCL and, depending on whether you're running in a graphical environment or not, displays a graphical or text-based UI. The UI's look very similar and function identically. I was always impresssed with that technology.

To install the dev tools, I ran custom and selected Software->Install New->From osr505 (the name of my system)->CD-ROM Drive 0. I unselected Microsoft Client Software, selected SCO OpenServer Development System and SCO Optimizing C Compiler and selected Install.

If I may digress again...

Another very cool feature of OpenServer is the "From osr505" option that I mentioned above. CD-ROM drives in the late 90's were still really, really slow. If you had a software package installed on another system in the network, instead of installing from a CD on the local machine, you could tell custom to install it from another machine, across the network. The packages were structured to keep the original copy of config files too, so if you did a network install from another machine, you wouldn't get a modified version of the config files. With fast internet, apt-get, yum and friends, this approach is obsolete these days, but in the 90's, it was awesome.

Every OpenServer release was followed up with a bunch of patches and ultimately a release supplement roll up. Sometimes there were several consecutive Release Supplements. Patches and Release Supplements are all listed at http://www.sco.com/support/ftplists/osr5list.html and available directly at ftp://ftp.sco.com/pub/openserver5/. I installed RS505A, which patched the OS and the Development System.

SCO packages are quirky. They are typically distrbuted as a tar or cpio file containing a set of files named VOL.000.000, VOL.001.000, VOL.002.000, etc. which are themselves, cpio files containing the software. To install them, you must extract the file, tell custom to install "Media Images" and point it at the directory containing the VOL files. I think there is a non-interactive way to use custom, but I never figured it out. I don't think there's any way to get it to dig into a tar or cpio file though. So, package installation has always been a manually intensive process.

I didn't at this point, but if you attempt an OpenServer installation, I recommend installing the oss646b supplement as well, to save yourself lots of headaches later. Ironically, it's missing from the list of supplements, but it's absolutely critical if you want to use gcc rather than the native C compiler. It's available at ftp://ftp.sco.com/pub/openserver5/oss646b/.

Remote Access

Telnet and ftp are the only built-in way to access an OSR 5.0.5 machine but ssh is available via "Skunkware".

Over the years, SCO downloaded, patched, compiled and made installable packages for a bunch of open source software. They called this project Skunkware, an allusion to Lockheed Skunkworks, I guess. These packages are available at ftp://ftp2.sco.com/pub/skunkware and they put out "Skunkware" CD's too. Apparently they'd been doing this since the Xenix days, but I'm not sure how they distributed the software back then.

Skunkware packages for OSR5 in particular are available at ftp://ftp2.sco.com/pub/skunkware/osr5/vols. The openssh package is among them.

Actually, I had to install zlib, prngd and openssh. I also had to tweak /etc/init.d/RMTMPFILES and add:

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

Otherwise prngd would leave a lock file lying around and wouldn't restart after a reboot.

I tried to get X11 forwarding working. In /usr/local/etc/sshd_config, I uncommented and set:

X11Forwarding yes

I eventually discovered that the path to xauth was hardcoded into the program too, at /usr/X11R6/bin, which doesn't exist on OSR5 as OSR5's X Windows is based on X11R5, not X11R6.

I made the appropriate directories and added a symlink:

mkdir /usr/X11R6
mkdir /usr/X11R6/bin
cd /usr/X11R6/bin
ln -s /opt/K/SCO/XServer/5.2.2a/usr/bin/X11/xauth xauth

Unfortunately, X11 forwarding still failed with "X11 connection rejected because of wrong authentication." I still haven't figured it out. It's possible that xauth from X11R5 just isn't compatible with modern X. X11R6 is available for OSR5. Maybe I'll try that some day.

What's up with that crazy path to xauth?

Another fairly innovative thing that SCO did with the OpenServer series is install literally everything under /opt and /var/opt and create symlinks from the files there into /bin, /lib, /usr/bin, /usr/lib, /etc and so forth.

Internally, their package manager would just extract a new package into /opt and /var/opt and run the "fixmog" program to update the links.

Patch management was easy for the installer too. The patch was installed under /opt and /var/opt and making the patch available just involved updating the links. Rolling the patch back was simple too. Remove the patch, update the links.

The real power of this approach though, SCO never promoted. You could install software on one machine, NFS-export the directories for that package under /opt and /var/opt, mount them on another machine and run fixmog on that machine. The software was then immediately available on the other machine without having to fiddle with PATH's or LD_LIBRARY_PATH's. We did this a lot. It was quirky though, in that the packages showed in custom as having been installed locally, and if you didn't know they were NFS-distributed and deleted one, it would delete it from the app server. Maybe I can see why SCO never promoted NFS-exporting their software.

The whole links-everywhere thing seemed like a good idea, but it turned out to be confusing as hell. The output of "ls -l" had a gazillion symlinks to long paths and looked terribly cluttered. Just running "l" appended a @ to the filename if it was a link, which was also confusing. I think there were issues with scripts that ran ls -l or l as well. In the end, the dpkg/rpm approach was superior.

But I digress...

With OpenSSH installed, I could ssh into the VM. Yay, no more working on the console.

I could also scp and sftp.

Compression

Sadly, OSR505 comes with compress/uncompress but doesn't come with gzip, bzip2, zip or unzip and its tar program lacks the ability to uncompress on the fly. Fortunately GNU tar and the rest of those programs are available via Skunkware as well.

Web

OSR505 comes with Netscape Communicator 4.05 which had a laughably difficult time rendering anything. I was able to install lynx and wget from Skunkware. Maybe someday I'll work on getting a semi-modern graphical browser working.

On the server side, 5.0.5 comes with the Netscape FastTrack Server. I bet you didn't even know Netscape made a web server. They did. I used it for years and years.

If you run a "ps -efa | grep http" on a running OSR505 system, it will reveal a confusing array of web servers, actually:

    root   544     1  0   Oct-18       ?    00:00:00 /var/scohttp/scohttpd -d /var/scohttp
  nouser   467   466  0   Oct-18       ?    00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
    root   411     1  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
    root   413   411  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
    root   415   413  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
  nouser   420     1  0   Oct-18       ?    00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config
    root   466     1  0   Oct-18       ?    00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
  nouser   421   420  0   Oct-18       ?    00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config

What the heck?

The ns-httpd processes are the Netscape FastTrack server - the web-server proper. The scohttpd server is for serving man pages. The ns-admin servers run a web-based configuration interface for the Netscape FastTrack server. The ncsa_httpd process runs a web-based configuration interface for configuring networking and other things on the local system (very quirky). If you enable secure httpd on the FastTrack server, a second set of FastTrack servers will start up and a second set of servers will start up for administering it. Gazillions of web servers on an OSR5 system. They used them for everything.

I aimed a browser at the various servers to verify that they were working but I didn't play with them other than that. Maybe later.

Development

Yes. This is what I'm always really up to.

The native compiler had a hilariously difficult time making sense of my software. Maybe one day I'll tweak it to work with the native toolchain, but I figured I'd have an easier time with gcc.

In retrospect, it might have been easier to modify my software.

Several different versions of gcc are available via Skunkware and one via a "GNU Tools Supplement" available at ftp://ftp.sco.com/pub/openserver6/opensrc/gnutools-5.0.7Kj. None of them worked. This seemed strange because I know confidently that I used gcc for years on various OSR 5.0.X platforms.

It took hours and hours of installing, uninstalling, patching and rolling back to figure out how to get everything working but here's a summary of the challenges and solutions:

  • The linker ld, as shipped by default and updated by RS505A doesn't support -static or -R options but libtool insists that it does.
    • The -static issue expresses itself with lots of "relocations remaining" errors at link time.
    • Actually ld does support -R but it means something totally different than libtool thinks it does, it's not the rpath.
  • oss499a adds -static support (or somehow works around it) but occasionally "relocations remaining" errors persist.
  • oss646b fixes all of these issues but causes the Skunkware gcc's to error out at link time with a _fini error.
  • The gcc from gnutools fixes the _fini error.
  • So, you have to use oss646b and gcc from gnutools, there's no other reliable option.

I didn't install all of gnutools, only GCC. Some of the other packages are duplicates (or newer versions of) tools I'd already installed and some of them require a different package called gwxlibs. In fact, during intallation it warns about:

Some of the selected software depends on other software that is not currently installed on your system.

...but it's safe to ignore the warning if you're just installing gcc.

I also installed perl, python, php4, pth (a portable pthreads package required by python), readline, bash, cvs and gmake from Skunkware. I'd swear that Java 1.1.3 was once available for OSR5 too, and there are even allusions to this on the SCO site but I can't find it anywhere anymore.

I tried installing openssl and postgresql from Skunkware but as it turns out, openssl only provides static libraries and postgresql requires the FSU-pthreads package which causes relocation errors at runtime.

I could probably build openssl from source and maybe postgresql too, against pth, but I'll save that for another day.

After all that, and a few tweaks to my code, I was eventually able to build and install everything. The SQL Relay installation was a little anticlimactic because I didn't have any database software installed to run the server against, but the client ran fine.

$ uname -a
SCO_SV osr505 3.2 5.0.5 i386
$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.53
        Connected to: fedora19:9000 as test

        type help; for help.

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

0>

Ironically I originally developed the precursor to SQL Relay on an SCO OpenServer system to run against Oracle 7. These days I don't have a copy of Oracle 7 and even if I did, I long removed support for it. OpenServer has been relegated to client-only status.

Oh well, times change.

Quirks

Aside from the quirks I mentioned above, I ran into a slew of other oddities while fiddling with OSR505. Some can be attributed to its age, others to SCO's commitment to back-compatibility. Others, I'm just not sure about.

  • 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.
  • On the command line, hit delete instead of ctrl-C.
  • Home directories are created under /usr.
  • 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 ~.
  • The package manager automatically selects the first package. So, if you want to uninstall something, you have to make sure to unselect the first package or it will get uninstalled too.

And, the quirk that confounds automated remote scripting over ssh:

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`

TODO

I had a lot of fun installing OSR505 and it was a nice walk down memory lane, but I haven't yet gotten to do everything I wanted to.

It would be cool to:

Get the webserver working and serving CGI's.

Find Java and get my java code working with it.

Get xauth working, maybe by installing X11R6.

Get postgresql working, maybe by building from source.

Get my software to compile with the native toolchain and optimizing compiler.

SCO supported IPX/SPX and NetBEUI, had an Advanced File and Print Server that predated SAMBA and had a Volution Messaging server that was compatible with older versions of Exchange Server. I think all of that is on the install CD. It'd be neat to get all of that working.

Earlier versions of OSR5 came with Wabi and Merge. Wabi means Windows ABI and was an environment similar to Wine that allowed you to run Windows 3.1 apps on SCO. It even came with a graphical desktop similar to 3.1. It was dog slow in the 90's but might run OK now if I can find it. Merge was the predecessor to Win4Lin. Basically Win4Lin was a port of Merge to Linux. The Merge that came with OSR only supported Windows 3.1 though, I think. It'd be cool to locate that software and play with it.

My Dad has floppies for Microsoft Basic for Xenix, Microsoft Word for Xenix, Foxplus and maybe even Foxpro for Unix. It'd be fun to intall those and play around with them. We wrote so much code in Basic and Fox, you can't begin to imagine.

Get Oracle 7 working again. We once had the installation CD's for 7.4.3 and 7.4.4. I might be able to dig them up.

Ahhh, some day... Some day.

Saturday, October 19, 2013

NetBSD - 6.1.2 x86

NetBSD 6.1.2 apparently came out sometime recently when I wasn't looking. I have probably a half dozen NetBSD installations running in various emulators, but my primary NetBSD development environment is x86. I'll get around to upgrading the others in due time, but the x86 VM can't wait. It can't!

Installation

As with most OS'es these days, you can either download a DVD image with everything on it and install from that, or you can do a netinstall over FTP or HTTP or something. I usually go with the netinstall unless I'm installing some really old version that's hard to find, and I went with the netinstall in this case too.

I downloaded the boot iso from: ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.2/i386/installation/cdrom/boot.iso, aimed VMware at it and began the installation.

VMware always wants to know what kind of OS you're using but never gives you a NetBSD option. Other -> FreeBSD has always seemed close enough and I went with it again this time. I wonder exactly what the difference between that and Other -> Other would be though. I know you get IDE disks with FreeBSD and it defaults to 20g rather than 8g but there's probably something else too. Maybe I'll look into that some day.

Other settings... 8G disk, bridged Network Adapter, 800 x 600 display, 256M of RAM. I also removed the Floppy, USB and Sound Card.

NetBSD runs in a lot of emulators so I've probably done more NetBSD installations than anything else. The installation process always seems pretty straightforward to me. Just follow the prompts.

I selected Full Installation, Use Entire Disk, Use Existing Partition Sizes and installed from FTP. I also declined IPv6 autoconfiguration.

Pretty soon, I was in business.

I've always liked how the installer shows you the full ftp session output.

NetBSD 6.1.2 i386 - 1 install

The downloads are getting quicker every year. I'm always surprised how quickly an entire distro comes down.

As of 6.1, I think, but maybe 6.0, after the sets are installed there's a menu that lets you configure the network, timezone, root password, etc. You can bypass all of it if you like but I usually go down the list, configuring each thing.

It's important to "Enable installation of binary packages" and "Enable sshd" but I chose not to enable ntpd, ntbdate or mdnsd.

I also got a little concerned when pkgsrc stalled out at the end but it eventually finished so I guess everything is OK there.

When the installation is over the installer drops you back at the main menu.

Reboot!

Success!

NetBSD 6.1.2 i386 - 2 first login

Post-Install Tweaks

I don't usually like poking around as root, so the first thing I do with a new system, unless I was able to do it during the installation, is create a user for myself.

NetBSD has the standard useradd/userdel commands.

useradd -m -G wheel dmuse passwd dmuse

The -m creates a home directory and the -G wheel adds the user to the wheel group, making it possible to su. On linux and some other platforms those options aren't necessary but it I believe it is on all of the BSD's. useradd doesn't prompt for a password so that's important to run afterward.

The next thing I usually do is make it possible to sudo without a password. Unfortunately sudo isn't installed by default but fortunately, NetBSD supports pkgin, and by virtue of selecting the "Enable installation of binary packages" option during the installation, I can install sudo easily.

pkgin install sudo

pkgin is great. It's similar to apt-get and yum. You can list available packages, search for packages, install them over the internet (with dependency resolution) etc.

It even has a feature that I'm not sure how to do (or if you can) with apt-get and yum. If you manually install a package and it drags in dependent packages, but then you uninstall the main package, the dependent packages are orphaned. It would be great to uninstall them as well but who keeps track of all the dependent packages that got installed along with the one you meant to install? Pkgin does. Those packages are marked auto-removable, as nothing else depends on them. You can run "pkgin autoremove" and it will remove all auto-removable (orphaned) packages. Awesome.

There is a significant quirk though. It appears that if you install a meta-package (ie. a package that doesn't install anything, only has dependencies that cause other packages to be installed) then the dependencies themselves get marked as having been installed directly and can't be removed automatically. This is particularly frustrating when you install something large like the Gnome desktop and then attempting to remove it, expecting autoremove to do most of the work for you.

But I digress.

I was in the middle of configuring sudo...

NetBSD puts its packages in /usr/pkg so the sudoers file is in /usr/pkg/etc. I appended to it:

dmuse ALL=(ALL) NOPASSWD: ALL

All right, no more logging in as root.

I enabled sshd during installation. xauth was installed as well. X11 Forwarding wasn't enabled by default though, so I enabled it by editing /etc/ssh/sshd_config and setting:

X11Forwarding yes

then restarting ssh

/etc/rc.d/ssh restart

After that I copied my entire .ssh directory from another VM and was able to ssh into the NetBSD VM without a password.

All right, no more logging in on the console.

ssh, scp, sftp and ftp all appeared to be present. tar, gzip, bzip2 and unzip appeared to be present as well. zip was conspicuously absent but quickly installed:

sudo pkgin install zip

Web

On the client side, I like to have firefox, lynx and wget available and apache on the server side. None were installed but all were available. "pkgin search firefox" and "pkgin search apache" revealed several options for each but it looked like "firefox" and "apache" would install the latest version.

sudo pkgin install firefox lynx wget apache

The apache config file appeared to be /usr/pkg/etc/httpd/httpd.conf with DocumentRoot /usr/pkg/share/httpd/htdocs.

I enabled cgi's.

LoadModule cgid_module lib/httpd/mod_cgid.so
...
AddHandler cgi-script .cgi
...
Options Indexes FollowSymLinks ExecCGI
...
DirectoryIndex index.html index.cgi

Apache for NetBSD comes with an example init script but it's not installed by default. I installed it...

sudo cp /usr/pkg/share/examples/rc.d/apache /etc/rc.d

...and enabled it by adding the appropriate line to /etc/rc.conf

apache=YES

Then started apache. Would my test program work?

#!/bin/sh

echo "Content-type: text/plain"
echo
echo
echo
/usr/bin/env

Yes!

Excellent. Moving on.

Graphical Desktop

What kind of graphical desktop could I get working? A few pkgin searches revealed Gnome 2 and 3, KDE 3 and 4 and XFCE 4 but no obvious metapackage stood out for any of them.

After a little digging on the web I found the pkgsrc meta-packages list for 6.1.2 at ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/6.1.2/meta-pkgs/. It looks like "gnome-platform" will get me Gnome 2, "kde" will get me KDE 3 and "xfce4" will get me XFCE 4.

Well, as it turns out, gnome-platform doesn't get you all of Gnome 2. To get it, you have to manually install tons of individual packages and it's difficult to figure out which. Worse, if you get started and want to bail, pkgin autoremove doesn't work help because gnome-platform is a meta-package.

XFCE 4 looked like a better choice...

sudo pkgin install xfce4

The list of dependencies looked more realistic.

I created my .xinitrc...

/usr/pkg/bin/xfce4-session

... switched back to the console and ran ...

startx

Voila!

NetBSD 6.1.2 i386 - 3 xfce

I love their little mouse logo.

All right, what about a graphical login? XFCE doesn't have its own and they recommend using gdm, lightdm, slim or lxdm. Of that list, pkgin only knows aboug gdm. Maybe plain old xdm would work. It was already installed.

I created an .xsession file with:

/usr/pkg/bin/xfce4-session

appended...

xdm=YES

to /etc/rc.conf and rebooted.

Well, it wasn't pretty, but it worked:

NetBSD 6.1.2 i386 - 4 xdm

And logging in got me an XFCE session too.

What about the web browser...

I clicked on "Web Browser" and it ran "Nightly" but "Nightly" looked a lot like Firefox. I checked the Preferred Applications settings in XFCE and they were set to use Firefox as the web browser. Indeed, running firefox from the command line in a terminal ran "Nightly" as well. Does "Nightly" mean "nightly build of Firefox"?

At any rate, I aimed it at my trails site and it worked as expected. The fonts were a little big, but zooming out by 1 took care of that.

NetBSD 6.1.2 i386 - 5 browser

Productivity

Were there any productivity apps available? It appeared so. pkgin could see LibreOffice 3 and 4, OpenOffice 3.1, KOffice, fengoffice and various other packages.

sudo pkgin install libreoffice4-bin

LibreOffice had some interesting dependencies like suse_base, suse_x11, suse_libtiff, etc. NetBSD supports binary emulation. Maybe LibreOffice was just a linux app with the necessary support packages.

pkg_info -L suse_base sure made it look like it was. Everything was stored under /usr/pkg/emul/linux. Interesting.

I had to run it from the command line using "soffice" and it complained about a non-existent java vm and threw a bunch of dbus/gconf errros but in the end, it worked:

NetBSD 6.1.2 i386 - 6 libreoffice

Impressive sir!

AbiWord and GNUmeric were also available and appeared to be native NetBSD apps.

sudo pkgin install abiword abiword-plugins gnumeric

They integrated better too, showing up in the XFCE menu after installation and appearing as the default .doc handler for Firefox (or Nightly).

NetBSD 6.1.2 i386 - 7 abiword

Development

All right, enough of that. I'm ulimately setting up this VM to test my software on.

Some packages that I needed appeared to already be installed: gcc/g++, pcre, openssl, apr, perl, sqlite, cvs

But even more needed to be:

sudo pkgin install readline php ruby tcl erlang openjdk7 mysql-client postgresql92-client unixodbc freetds gmake vim-gtk2

I copied my .cvsrc and .vimrc from another VM and some build scripts too, checked out my source code and ran the main build script.

Everything built.

To test it I had to add /usr/local/firstworks/bin to my PATH and /usr/local/firstworks/lib to my LD_LIBRARY_PATH. The BSD's in general are difficult to set system-wide paths on because the .profile scripts override anything you set in /etc/profile so I just added them to my .profile instead of setting them system-wide.

After that, I could run the sqlrelay server against the different databases that I was able to build support for. sqlrsh could connect just fine to the instance on my linux host connected to oracle.

NetBSD 6.1.2 i386 - 8 sqlrsh

Everything appeared to work as expected.

Clean Up

I don't need X Windows for most of what I do so I disabled xdm in /etc/rc.conf

xdm=NO

and rebooted. During the reboot I reduced the VM's memory configuration to 128M. That's always been plenty in the past.

Quirks

I did run into some interesting quirks.

Shell aliases need to go in a particular location in ~/.shrc rather than in ~/.profile directly or it causes all kinds of problems. I don't remember that from 6.1.1 but maybe it was an issue in that release too.

XFCE itself doesn't appear to read ~/.profile and its terminals don't either. On top of that, the shell doesn't understand ". .profile" or "source .profile". To get my PATH settings, I had to run a terminal, then run bash and manually source my .profile. I'm sure there's some way to fix that but it was very confusing.

There's also a swap partition issue. No swap partition was created by the default installation options but the system was configured to save core (in case of a kernel panic) to the nonexistent swap partition. /etc/rc.d/swap2 complains that there isn't one too. It's possible to add a swap file by running:

dd if=/dev/zero of=/swap bs=1m count=256
chmod 600 /swap
swapctl -a -p 1 /swap

and adding to /etc/fstab:

/swap none swap sw,priority=1 0 0

but the kernel can't dump to that so it's only a half fix. Very strange. I'll have to keep that in mind for next time.