We still have a SPARC IPX in production, hosting an antiquated database. The hard drive sounds like grinding metal. I've been trying to get rid of it for years. I succeeded once, but it was brought back from the dead. This thing has been running with the original parts since 1993 to 2026, minus ~1 year of downtime.

Nobody has the root password anymore, but fortunately, it's vulnerable to at least seven remote root sunrpc exploits. We "log in" by running a Python script that pops a root shell.

No, I am not kidding.

Edit: Checked out records: purchased and brought online in 1993.

Edit 2: In response to "why don't you just change the password?". When I asked, I was told they "can't" because they'd "lose access to the database". I didn't ask them to elaborate, because it would have opened a whole new can of horror worms, but I removed it from the Internet (it's on a non-routable, weakly "air gapped" network now).

▲ shrubble 2 hours ago | parent | next [-]

QEMU has a SPARC CPU emulator; it might be possible to run the operating system and database in a VM on regular x86-64 hardware.

	▲	greatquux 2 minutes ago \| parent [-]
		You absolutely can run 32bit Solaris in qemu SPARC emulation. 64bit is not there yet unfortunately. But definitely dd this and get it virtualized!

▲ EvanAnderson 13 minutes ago | parent | prev | next [-]

A BlueSCSI[0] might be an interesting thing to add if you want to alleviate the hard disk sound.

[0] https://bluescsi.com/

▲ ThrowawayR2 an hour ago | parent | prev | next [-]

Out of morbid curiosity, is there a recovery plan for when it inevitably experiences a hardware failure?

	▲	jeffrallen 21 minutes ago \| parent [-]
		Buy parts from RS and fix it, silly.

▲ linksnapzz 2 hours ago | parent | prev | next [-]

This box needs an official retirement ceremony when the database is migrated.

▲ jdboyd 3 hours ago | parent | prev | next [-]

If you get a root shell once, why not change the root password then?

▲ codejake 3 hours ago | parent [-]

Great, obvious question!

The answer I got: "we can't. We'll lose access to the database". I did not ask for elaboration, but it is not routable to/from the Internet.

▲ adrianmonk 2 hours ago | parent | next [-]

You can just add a second line to /etc/passwd with a different username but the same numerical uid. Like this:

    altroot:x:0:0:Alternative Root User:/:/bin/sh

Then, of course, run (as root) "passwd altroot" to set a password.

We used to do this all the time for users who needed root access to their own workstation. It allowed us to avoid telling them the common root password used on all the machines in the organization.

In your case, doing this might be beneficial in case there is a network problem because you'll have a way to log in as root locally.

	▲	bink an hour ago \| parent [-]
		Back in the day we would've just added our IP to the .rhosts file and no password would be required at all! It does have me thinking about what versions of SSH would run on such an old OS. I'm sure there were versions available at one time... and since it's vulnerable to remote exploit anyways the version wouldn't really matter.

▲ orthogonal_cube 2 hours ago | parent | prev [-]

Seems as though the process of changing the password on their end may not be as straightforward. Or they’re just worried that misconfiguring it may prevent them from getting connected again.

In any case, as long as it’s not directly routable to the internet and there’s a plan to phase it out, probably nothing to get worked up about.

I hope the sound of the drive isn’t particularly bothersome. It’s rather impressive to still be working.

▲ gknoy 3 hours ago | parent | prev | next [-]

> We "log in" by running a Python script that pops a root shell.

I'm surprised that when you do this, you can't then set the root password. (Also, holy cow. What a durable machine.)

▲ numpad0 an hour ago | parent | prev [-]

dump that disk asap!!!!!