Keeping old software alive, handling libraries.
Posted by imsorrykun@reddit | linux | View on Reddit | 19 comments
I have some how become the defacto Linux systems / application specialist at my organization over the last decade. Mostly managing 12 workstations and two servers. This is due to my specialty in a medical diagnostic lab (MEG).
The "state of the art" clinical software to analyze our data was initially developed for HP Unix and ported to linux in the early 2000s, last update was 2008 for RHEL 5. Now to my question.
There are a few ( a lot ) of libraries that are not longer supported. I do have the packages and source code, but I wonder what the best method is to install these libraries on modern systems that won't create conflicts with other libraries. Should I add them to their own directory in the 32bit system libraries folder or in another location. Writing wrappers I don't think will be very practical since the software has a little over 100 binaries. How would you manage this, currently I solve for what I can address from the distribution's repositories then compile the rest into an i686 library directory.
Itchy_Bandicoot6119@reddit
Create a docker container?
imsorrykun@reddit (OP)
Tried and failed, I can get a few utilities to work but the main application binaries have a lot of hard coded paths and checks for the other binaries. Also the license probe looks for hardware.
Some of the suite is also dependent on a few environment variables to pass data to other applications in the suite.
ForceBlade@reddit
So you have no idea what you’re doing
Business_Reindeer910@reddit
These should all be fixable.. a docker container is just a fancy chroot after all
YOu can probably pass the devices and make them accessible to the container too to fix the hardware probe issue.
imsorrykun@reddit (OP)
Yeah, I definitely didn't give it a full go at docker and maybe should revisit it. The big issue I was running into was the software has this hook hand off to share memory segments to pass data. It's a way I guess the original team was trying to keep memory down.
When I got one application launched in docker and tried to load the other application that takes data from the first, it would just crash.
DownvoteEvangelist@reddit
Did you launch them both in the same container? I would package whole solution as a single container..
scaptal@reddit
Unless I'm mistaken you can setup and link your containers file system.
So if something needs to be in /sbin/foo/script.sh but is actually in ./foo/script.sh you can link them together (don't know the full command from the top of my head, but know it's possible and relatively easy
Business_Reindeer910@reddit
You should be able to figure that out and solve it. Although the VM solution would likely end up being the easiest if perhaps unnecessarily resource intensive.
imsorrykun@reddit (OP)
I think I may revisit the Docker container idea and see if I can get the applications to play nice. It would solve so many issues.
The VM might work, but I don't trust the users to not run into a self inflicted issue and bug me about it. Maybe if I made a Citrix vm or hosted a centralized VM on a system they can't physically touch.
I got the software working on a POP!_OS 22 LTS virtual box, and may use that as a clone.
The data pipeline needs a lot of screen realistate to view and model the data, so I may need to use X11 forwarding to get it how they like it.
barmolen@reddit
I was about to say the exact same thing.
namtabmai@reddit
Containerising is one option, but I have encountered issues past a certain point with some legacy libraries.
I'd also consider just throwing them in a VM using their last supported OS versions then tying down the internet access to those Cams naturally.
bunkermunken@reddit
You can put them in a separate directory and use LD_LIBRARY_PATH in the environment before executing the binaries
ObjectiveJellyfish36@reddit
IMO, these old programs should go to
/opt.But to test if they run at all on a modern system, I'd extract all files from a pre-built package, point the
LD_LIBRARY_PATHenvironment variable to where the i386 libs are, and try to run it.Drwankingstein@reddit
The best way to keep old software alive is to program and compile for windows and use wine xD
Business_Reindeer910@reddit
whether you wrap it in a container or don't, you should definitely vendor them alongside the application somehow.
imsorrykun@reddit (OP)
I like to think of them as my job security lol. I was thinking of adding them to a lib folder inside the software directory and loading them from the user profile. That way any issues It will be isolated to just the account.
Business_Reindeer910@reddit
Do you already know they run on modern distros unmodified. You might be forced to put them in a container no matter what happens, depending on what they do (or don't).
imsorrykun@reddit (OP)
Not all day installing. Most of it is trying to trick the license file into thinking it found the mac address in the format it wants and creating some virtual hardware / configurations. ... oddly enough the hardest bit was getting the X11 fonts to load correctly in the software. Still not 100% sure how I finally got that working. It has a very old X11 style sheet that references a few others across the install directory and system.
imsorrykun@reddit (OP)
I get them to run eventually on modern systems. Just takes full day to install and build for the distribution. Toyed with the idea of installing the software on an older distribution as a VM and create launchers to load them with X11 forwarding.
I will not have an issue using it this way. The users somehow end up issues even with basic ussage. Like network goes down, so they power off the gateway system... and forgot the password to decrypt the boot drive...
I want to solution to be relatively idiot/bullet proof lol.