[PreInternet01]

Yup. SCO OpenServer 5.0.something, for some partner's accounting department. Neither the OS nor the application software have been updated since the late 1990s, but if it works, it works, I guess... (to be honest: the application software is only used to run reports in response to requests from the legal department, but apparently still can't be shut down -- I ask once a year, next upcoming 'query date' in my agenda is March 2023).

This used to run on a Compaq Proliant server (huge noisy Intel 486 tower) until the end of the millennium or so, then was converted into a VM. First on VMware, then on Hyper-V, where it has been running comfortably on various hardware (Intel Dell PowerEdge, AMD SuperServer) since.

Access is the biggest issue, as the OS only supports telnet, and serial access. So ever since this has been converted to a VM, it runs on a dedicated VLAN (666, just to make sure nobody ever misunderstands the true evil underneath...), with an AD-authenticating-HTTPS-to-Telnet bridge (coded up in Visual Basic.NET using some long-long-deprecated libraries) connecting it to the outside world.

That VB.NET kludge was recently upgraded to .NET 6, in order to get TLS 1.2 support. This was surprisingly uneventful, and I'm pretty sure this abomination gets to live another decade or so.

Ah, yes, a career in IT... Always on the forefront of cutting-edge tech...

(Later edit to, like, actually answer the question: licensing costs are nonexistent: SCO is gone anyway, and we don't require any support/updates. Migrating to Linux might be an option, but is most likely going to be hugely painful, and the existing VM scenario Just Works for everyone involved. Security and such is not a real issue: only a handful of internal users have highly-restricted access via a proxy)

[kkielhofner]

This takes me back! This was roughly 25 years ago so I’ll do my best to remember.

My first job in high school was at a company with the entire business running on SCO Unix. I want to say OpenServer 3, maybe? It was essentially a terminal server with dozens of Wyse 60 terminals attached.

Anyway, as a Linux enthusiast I promptly setup a RedHat 7 install on some old hardware they had lying around. IIRC correctly it was a low-end Pentium but it could handle a PCI 100mbit ethernet card just fine.

Anyway, the goal was to get data to/from the SCO system to something with a TCP/IP stack (RedHat machine) so it could go somewhere - samba shares on the rapidly growing ethernet network, maybe even the internet!

We ended up using UUCP over serial, scripting, and cron jobs to push/pull from directories on each side. The RedHat machine was promptly connected to a 56k modem to do dial on demand and IP masquerading for the ethernet network and uploads of specifically formatted files from the SCO system via FTP to vendors and partners.

Fun times!

[jolmg]

> Access is the biggest issue, as the OS only supports telnet, and serial access.

OpenSSH works on it. This page has links to precompiled packages:

https://scosales.com/knowledge-base/how-to-install-ssh-for-s...

links:

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/openssh-3.4p1-VOLS.tar

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/prngd-0.9.23-VOLS.tar

ftp://ftp2.sco.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tar

Probably better to grab the sources and compile them yourself if you can, though.

> Migrating to Linux might be an option, but is most likely going to be hugely painful.

Probably. At least it sounds like you only have a few users for it, so getting them to adapt to a change of software might be easier.

[silverwasthere]

Maintaining access to a 20 year old ssh server will not be trivial. A modern client would usually fail to agree on encryption protocols in my experience.

[jolmg]

It's pretty trivial. Some things are disabled by default, but still available on the latest versions of clients. For the OpenSSH client, it will tell you what specifically the client and server failed to agree on, and you can just add the option to enable on the client one of the ciphers, kex algos, or whatever that the server accepts. I've had no trouble with neither the latest version of the OpenSSH client nor Putty to connect to such servers.

[thwarted]

Using ancient ciphers and kex algos can end up being just as secure as telnet.

[jolmg]

I mean, if they can compile the latest version of sshd to run on SCO OSr5, that's great! If they can't because it's no longer compatible or whatever, are you saying they may as well stay with telnet? Obviously, not using legacy software is best, but it's not like people can just snap their fingers. Software needs to be ported, people need to be trained, etc. Work and time is needed. In the meantime, using sshd seems like an easy upgrade.

On "ancient", the ciphers and kex algos used by the OSr5 sshd above were deprecated like 4 years ago. I'd like to think that among the select group of probably-not-technical people that have access, it's not exactly the same bar of technical ability to inspect the contents of a plaintext connection as that to inspect the contents of an encrypted connection that uses ciphers and kex algos deprecated a few years ago.

[nibbleshifter]

> A modern client would usually fail to agree on encryption protocols in my experience.

I run into this issue frequently. Usually its a "client soft disabled, alter config", but sometimes... Just sometimes its "spin up an old VM to use its ssh client".

[sitkack]

You SSH to sibling VM running under the same VMM, connect the serial port of the SSHVM to the application VM, clear text only runs over that virtual serial connection traveling through the VMM.

[kkielhofner]

Considering the other options you can add the deprecated ciphers and key exchange mechanisms with a few lines for the host in your SSH client config on the newer system.

[dcminter]

Will it all blow up in 2038? Do you have a plan (to kill it, upgrade it, or retire) if so? :)

[PreInternet01]

That is an excellent question, one I should investigate using a VM clone one of these days. The accounting data is frozen in time, so it should not be affected, but if the system starts refusing logons or just crashing, that would not be great (and I'm pretty sure the SCO licensing management thingy would fall over, as that was a previous source of, eh, entertainment).

The plan is definitely to retire the system Real Soon Now, but with the subjects of the underlying data springing new generations with new lawyers, ensuring some kind of Y2K38 compliance might be wise...

[orangepurple]

Rewind the system clock by 100 years and add 100 years to the data output :)

It should buy you another 100 years.

[mattpallissard]

This is the way. Just make sure the hypervisor isn't jumping the clock forward.

[justsomehnguy]

> with an AD-authenticating-HTTPS-to-Telnet bridge

Apache Guacamole supports AD auth and (surprisingly) telnet.

[zozbot234]

Looks like OpenServer 5 is still being marketed by UnXis/Xinuos, so you might be on the hook for any ongoing licensing costs. They released the latest update in 2018.

[bitwize]

Hey, you took the tools you had and combined them into something new to solve a problem. That's literally what technology is, even if it isn't sexy.

[agumonkey]

That's an interesting account of evolutionary biology.

[SirLJ]

Wow, I had the same setup with Compaq Proliant in another galaxy long time ago...

[mgarfias]

Man, that brings back memories. When I kept a tile store/distributor running on SCO with their whack ass Keymark darabase.

Good times

[29athrowaway]

Why?

[PreInternet01]

Fair question, although the basic answer should be obvious: the users still need access to the data! So, the question becomes more like "why not upgrade", or more specifically "why not migrate the data to something that is not so shockingly obsolete", since it's probably clear that there is no real upgrade path here (both SCO and the vendor of the accounting system are long gone).

Usually with systems of this vintage, "just dump all the data to Excel or PDF and get it over with" is a good option, but in this case both the volume (with the requirement to run queries on it) and the limited options available for export (the system can only print predefined reports, and they don't contain everything required for filtering) prohibit that.

So, next stop would usually be "reverse engineer the application data format and convert it", but the unholy collection of binary files used by the accounting software here has defied analysis: it's not Btrieve or MS-ISAM (popular semi-database formats for COBOL and BASIC apps of the time), and decompiling the binaries only yielded some generated-by-another-set-of-tools braindamage that didn't clarify anything either.

The choice then became spending huge amounts of money, or wallpapering over the tirefire and keeping it running. Unsurprisingly, the outcome was the latter, which is perfectly OK in this case, as the system is not exactly load-bearing, and actually sort of fun to maintain.

[jolmg]

It's not Informix-4GL, is it? If it is, the DB should be available via `dbaccess`. If you don't have that executable to verify, I imagine the binary files are probably of extensions `.4ge` and `.frm`. Then, the DB is likely a directory with the extension `.dbs`, that has a pair of files per table with the extensions `.dat` and `.idx`.

[PreInternet01]

No, it's definitely not Informix, Progress, Magic, or anything else commercially available that I'm aware of, although it does have all the "sure, let's disaggregate a single record across 26 files" hallmarks of a "4G" tool. But there was a lot of vendor-specific crud around at the time...

[mkl]

Since you're accessing it via telnet, could you just scrape the screen? Then you could have a script that pages through the data, copying it out a screenfull at a time.

[29athrowaway]

Maybe it's a multi-step migration.

From the highly obsolete format, to a stepping stone in-between which can be converted to a modern format.

[treadmill]

With the constraints described by OP, converting to a stepping stone would still require you to fully reverse engineere the binary format.

[quickthrower2]

Surely only legacy data? No new data going into it?