Ivo

The structural lesson, which is the one worth taking away after the immediate scramble: this is an inventory problem, and you are solving it under time pressure because the inventory did not exist.

What makes the next one easier:

• Generate a software bill of materials for anything you build or deploy. Most build tools can emit a dependency list; store it with the artefact.
• Prefer distribution packages over vendor bundles where you have the choice, precisely so the package manager can answer questions like this one.
• Record what each server runs, at the application level, somewhere queryable. When the next advisory lands, the first question is always "where do we run this", and an hour of grep is a bad answer.

None of this helps today. All of it converts a two-day fire drill into a ten-minute query next time.

Whatever you do, resist the suggestion to permanently disable verification in the package manager configuration. It works, it is easy, and it converts a temporary problem into a machine that silently accepts any package from anyone forever.

If you must use an unverified fetch, use it for one file on one command line, not in a config file. The difference between those two is whether somebody finds it in three years.

The thing worth taking from this: end-of-life dates are published years in advance and are the most predictable outage you will ever have.

This one is preventable with a calendar entry. Every distribution publishes support windows; putting the date for every release you run into a shared calendar, with a reminder six months ahead, converts an emergency into a planned migration.

The same applies to the layer above — language runtimes, database majors, container base images. Almost every "it suddenly stopped working" incident of this shape was on somebody's public schedule long before it happened.

If you go the repoint-to-archive route, do it knowingly and put an expiry on it.

What that configuration means is: this machine will never receive another security update. That is acceptable for a few days while you plan a rebuild, and it is not acceptable as a steady state for anything reachable from a network you do not control.

Write the date in the repository file as a comment. It is the cheapest possible reminder and it has saved me from finding three-year-old "temporary" pins more than once.