Keeping old software alive, handling libraries.
Posted by imsorrykun@reddit | linux | View on Reddit | 50 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.
nintendiator2@reddit
Just create a
schrootof the OS version in which they were supported? It's how I kept playing those old Loki ports for a good while. That would make running the software quite transparent and given you an environment that, other than for the kernel, would be "just like then". And you absolutely avoid having to import incompatibilities into the modern system.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.mamigove@reddit
If it doesn't work with docker, I would make sure to have a special user and group for this well delimited in the system.
imsorrykun@reddit (OP)
This is close to currently how I handle it. The software is installed to /opt/, and I have tried LD_LIBRARY_PATH. Occasionally I would have issues with other software reseting the LD_LIBRARY_PATH, so I added an entry into ld.so.conf to the depreciated library folder.
ObjectiveJellyfish36@reddit
You could also investigate modifying the binary's
RPATHwith tools likechrpathorpatchelf. Then it wouldn't be necessary to tweakLD_LIBRARY_PATHorld.so.conf.tes_kitty@reddit
Simplest way is to write a wrapper script that sets LD_LIBRARY_PATH the way you need it and then starts the software inside the script. Once you quit, that setting disappears and can't mess up other software.
Or you can do it on the command line:
LD_LIBRARY_PATH=/location/of/your/libs your_old_software
imsorrykun@reddit (OP)
This may be the best way to handle the issue. I could make a launcher script that loads a simple GUI with buttons for each application, while pointing the LD_LIBRARY_PATH variable to the location of the defunct libraries. For the command line tools, I can just wait and see if any errors come up.
tes_kitty@reddit
Up to you, just make sure to use 'export LD_LIBRARY_PATH=...' in the script so the setting gets forwarded to whatever you start from there.
Drwankingstein@reddit
The best way to keep old software alive is to program and compile for windows and use wine xD
brimston3-@reddit
win32/wine is unironically the most binary-stable UI framework on linux. After that is Java.
Morphized@reddit
You can also statically-compile things if the source is available
natermer@reddit
I would look at just building or copying the libraries into a specific directory and then use a shell script to setup the user's environment.
You should be able to control the paths that the software looks for libraries with things like "LD_LIBRARY_PATH".
Then I would distribute it all as a big tarball that gets dumped into some directory in /opt
Ullebe1@reddit
Is it a GUI application? Then Flatpak it. If not, then Dockerize it.
After that it will run on basically any modern system and will continue to do so for the foreseeable future.
tes_kitty@reddit
Will then need an installed docker or flatpack support system though.
Using LD_LIBRARY_PATH to tell it where to find the old libs and a wrapper script is much more lightweight.
Ullebe1@reddit
That's true.
Setting it up with LD_LIBRARY_PATH and wrapper scripts might be simpler in the beginning, but it doesn't scale as well as containers if you want to deploy it to new machines or to upgrade the current machines to a newer distro versions, which might need new fixes for the scripts. With OCI containers or Flatpaks this is a totally standard operation. Might still want some wrapper scripts or aliases to make launching the CLI tools nice and easy, but they can be simplified a lot since the heavy lifting is done by the runtime.
And for the runtimes: basically every desktop distro but Ubuntu comes with Flatpak already. And running OCI containers is trivial on almost any distro, be it with Docker or Podman, I believe it's even possible with systemd-nspawn if using those two is not an option for some reason.
tes_kitty@reddit
Then you add those. Containers come with their own problems. Like filesystem access. Especially CLI tools are quite often only useful if they can access all of the filesystem.
Which is usually also kind of heavy and eating lots of space.
Running Ubuntu 22.04.x here, no flatpak installed and snap gets ignored since it sucks. Switched Firefox from snap to native install since the snap didn't work right and had screwed up fonts and mouse pointer.
Ullebe1@reddit
To each their own. I'd much rather throw a little bit of storage for a container runtime at the problem than time for fixing shell scripts.
File system access is the sore point if you need them to access arbitrary paths in the file system. If you just need them to be able to access a file in the CWD then it is trivial to mount that in in the wrapper script. So I guess it depends on the exact requirements of the tools used.
Exactly, Ubuntu is basically the lone holdout in supporting Flatpaks OOTB. So on almost any other desktop distro it will just work, and for Ubuntu it is as simple as installing the
flatpakpackage, which is trivial to add to the initial setup if desktops are cattle rather than pets.I'm also not a fan of Snaps, but I think Flatpak rocks.
tes_kitty@reddit
Which is the typical use case for most CLI tools. Even a Webbrowser needs to be able to access more than just $HOME. It also needs to be able to start external programs (to display PDF for example, the built in PDF viewer usually sucks in some way).
For me containers mean replacing one complexity with another.
Ullebe1@reddit
Yeah, the value proposition is much different when managing an individual machine rather than a fleet of machines. I wouldn't expect anyone to do a single machine as cattle, but when the number rises the complexity of them being cattle becomes worth it in time saved.
Personally I use the opportunity of a new system to start fresh and I then copy things over from the old ones as I need them - though I of course keep all my old $HOME partitions around so I can actually do this.
tes_kitty@reddit
You could also do what others do... Put your old $HOME into a folder 'home_old' in your new $HOME every time you move. And when you need something, you move it from there to your current $HOME. After a while you can then do 'cd home_old/home_old/home_old/... :) There is an xkcd for that too: https://xkcd.com/1360/
> I wouldn't expect anyone to do a single machine as cattle
Yes, because for a single machine the effort to keep that always up to date exceeds the effort for the pet approach. Changes when it's multiple systems.
imsorrykun@reddit (OP)
I think this is the way, or adding it to the ld.so.conf file.
tes_kitty@reddit
I wouldn't add it to the ld.so.conf file since that would make those libraries available to all software. Which could be kind of bad if those old versions contain exploitable bugs.
You want to limit the use of old libraries to just the software that won't run with up to date versions.
imsorrykun@reddit (OP)
About 10 applications have GUI, and the rest are either called by the gui application or are command line utilities.
person1873@reddit
If you have the source code, I would recompile these binaries to be statically linked, that way the libraries are baked into the package and are no longer separate.
I would probably wrap them up as an AppImage for simple cross-system compatibility.
mrlinkwii@reddit
create either flatpaks or appimages
Zaphoidx@reddit
Potentially radical idea, but if you have the source (and make sure you create a backup), could you try and port the libraries to modern systems?
That’s a suggestion without any consideration for how complex the various programs are, but it could honestly be a fun (or not) background exercise
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.
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..
imsorrykun@reddit (OP)
Lauch both from the same container with X11 forwarding. The crashes happened when loading external data in the parent application and transfering the segment to the child application. I may want to revisit this option later on since it would probably be the easiest to support long term.
DownvoteEvangelist@reddit
I don't think there's anything in the way containers are designed that should stop 2 processes from talking through shared memory in the same container... If you have source and time, it should be fixable...
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.
cyber-punky@reddit
Does the hardware you require need a kernel module ?
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
ForceBlade@reddit
So you have no idea what you’re doing
barmolen@reddit
I was about to say the exact same thing.
skittle-brau@reddit
I’d be inclined to throw it all into a VM. It’ll be easy to keep it backed up too.
imsorrykun@reddit (OP)
Thinking of that as well. Throw it all into a headless VM that loads on startup and make launchers to load the X11 applications on the host system.
centosdude@reddit
Maybe you could have one wrapper script that takes an argument that is one of the 100 binaries to run wrapped? There are tricks you can use to even get old loki games from 1999 to run on modern Linux systems like fedora and still keep the system stable. export LD_LIBRARY_PATH=$COMPATDIR
EternalFlame117343@reddit
Turn it into a snap
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
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.