End-of-Life Components - the Acedia of Information Technology
Table of Contents
by:
Lari Huttunen
As the year is drawing to an end and we are about to complete yet another revolution around the sun, I think it is fitting to talk about time and its relation to obsolescence. In other words, I want to talk about one of the most systemic forms of public exposure, which is temporal exposure. More specifically, I want to talk about IT systems living past their end-of-life due to acedia, complexity or dependency failures – or the combination thereof.
Laziness breaks strength; prolonged idleness weakens energy. - Pieter Brueghel the Elder (1558).
OOPSIE, Outrageously Odd Problems and Security Issues Examined #
I head a small research team dubbed OOPSIE, whose main task is to automate the tracking of vulnerabilities and exposures with a heavy emphasis on exposures. Earlier, I have written about our research into obsolescence using a trichotomy:
- the good (supported)
- the bad (unsupported)
- and the ugly (obsolete).
This division is not something that is largely recognized, but any sysadmin will be able to relate to it in their daily line of work. Time is relentless and balancing between supported and unsupported is an active battle, whereas letting something turn obsolete is a sign of giving up.
To date, the obsolescence topics I have covered on this blog relate to the following products:
- jQuery (2022-09-13)
- Wordpress (2022-10-11)
- PHP (2022-12-13)
- Woocommerce (2023-07-11).
A New Type Emerges into the Data Harmonization Ontology #
Each of the four write-ups above, covered a specific point of view into obsolescence, but it is only of late we have come up with a term for it, end-of-life component. This functional type is now included into the Data Harmonization Ontology under the Public Exposure category to mark a specific subset of exposure present on the Internet today.
Consequently, running an EOL component can jeopardize a whole system or a service, even if the rest of the system is kept up-to-date. More of often than not however, the EOL component is an indicator of a larger problem. For example, running an unsupported version of a Linux distribution will most likely mean that the components in it are also unsupported because of how dependencies are laid out for a specific major version.
In time, the house of cards will crumble unless you keep abreast with time and changes through clear life cycle management, which is what Tuomas Haarala wrote about earlier on in his post on IT Asset Management.
Shodan Starts Tracking Obsolescence #
A couple of months ago, we noticed that Shodan had started tagging obsolescence with the EOL tag. Even if their definition of an EOL product is a bit incomplete, the tagging itself can help delve into the topic in greater detail.
At present, the total number of EOL components on Shodan is roughly 11 million IPs and represents a wide range of things from operating systems to database backends and open source platforms such as Grafana or Jenkins. The top three countries USA, China and Germany host approximately half of the EOL components, which is not surprising as they represent a significant portion of the Internet infrastructure in general.
Finland has a relatively large number of EOL components (85k) compared to the size of our human population, but that largely is due to Hetzner Online GmbH operating a data center in Helsinki (71k EOL components). In fact, this is the reason why you should not draw too far reaching conclusions based on geolocation alone.
Deployment Planning to the Rescue #
Noting down human laziness and technological complexity as the root causes for obsolescence is easy enough, but what can we actually do to not end up in the situation in the first place?
As a form of software life cycle management, deployment planning can be used either bottom up or top down to help with this equation. In practice, if you would like to offer web service on a Linux server you would need to pick a Linux distribution with a three to five year cycle and synchronize it in with the life cycle of the needed service level components and libraries.
In an ideal case, your operating system and packaged components span far enough to cover the intended life cycle. Unfortunately, timelines alone are not enough since the difficult point in time will be the migration to a newer platform before the components reach an unsupported stage.
Simple things such as not using complex data models which ship with relational databases go a long way, as well as choosing projects whose programming language dependencies do not provide a blocker for the eventual migration.
The sad thing about today’s technology stacks seems to be the ever shortening time span from the support perspective. Many times containerization may help, but it is not a panacea to all problems, since even the host operating system running docker for example has its own end-of-life.
Some Light at the End of the Tunnel #
A great project for understanding obsolescence in practice is called endoflife.date. It can help you with the deployment planning phase at least to the extent that you can amass all the lego blocks to build your castle. If you are buying a commercial solution, asking for an SBOM, software bill of materials, will not hurt.
Even if Pieter Bruegel the elder knew nothing of information technology, his art does encapsulate many things about us humans and the laziness and apathy with which we meet complexity or repetitive tasks such as IT administration or maintenance in general.
Credits #
- The hero image of this write-up is courtesy of Wikimedia commons and Pieter Bruegel the elder.