11 ms·

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,

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)

dcminter 4y ago
Will it all blow up in 2038? Do you have a plan (to kill it, upgrade it, or retire) if so? :)
- PreInternet01 4y ago
  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 4y ago
    Rewind the system clock by 100 years and add 100 years to the data output :) It should buy you another 100 years.
    - mattpallissard 4y ago
      This is the way. Just make sure the hypervisor isn't jumping the clock forward.
jolmg 4y ago
> 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-sco-openserver-5-0-5-and-higher/ 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 4y ago
  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 4y ago
    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 4y ago
      Using ancient ciphers and kex algos can end up being just as secure as telnet.
      - jolmg 4y ago
        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.
SirLJ 4y ago
Wow, I had the same setup with Compaq Proliant in another galaxy long time ago...
kkielhofner 4y ago
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!
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
29athrowaway 4y ago
Why?
- PreInternet01 4y ago
  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.
  - quickthrower2 4y ago
    Surely only legacy data? No new data going into it?
  - deleted 4y ago
    [deleted]
  - jolmg 4y ago
    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`.
justsomehnguy 4y ago
> with an AD-authenticating-HTTPS-to-Telnet bridge Apache Guacamole supports AD auth and (surprisingly) telnet.
mgarfias 4y ago
Man, that brings back memories. When I kept a tile store/distributor running on SCO with their whack ass Keymark darabase. Good times
agumonkey 4y ago
That's an interesting account of evolutionary biology.
bitwize 4y ago
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.
zozbot234 4y ago
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.

dcminter 4y ago

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

PreInternet01 4y ago
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 4y ago
  Rewind the system clock by 100 years and add 100 years to the data output :) It should buy you another 100 years.
  - mattpallissard 4y ago
    This is the way. Just make sure the hypervisor isn't jumping the clock forward.

jolmg 4y ago

> 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-sco-openserver-5-0-5-and-higher/ 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 4y ago
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 4y ago
  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 4y ago
    Using ancient ciphers and kex algos can end up being just as secure as telnet.
    - jolmg 4y ago
      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.

SirLJ 4y ago

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

kkielhofner 4y ago

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!

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]

29athrowaway 4y ago

Why?

PreInternet01 4y ago
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.
- quickthrower2 4y ago
  Surely only legacy data? No new data going into it?
- deleted 4y ago
  [deleted]
- jolmg 4y ago
  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`.

justsomehnguy 4y ago

> with an AD-authenticating-HTTPS-to-Telnet bridge Apache Guacamole supports AD auth and (surprisingly) telnet.

mgarfias 4y ago

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

agumonkey 4y ago

That's an interesting account of evolutionary biology.

bitwize 4y ago

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.

zozbot234 4y ago

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.