Our back-end servers (Redhat 5,6 mostly) are very outdated, and are not connected to the Internet for security reasons.

I'm looking for the best strategy to update them, without connecting them to the Internet.

  • 1
    What OS are you talking about? If you're using Windows you could deploy a WSUS server which will essentially act as a proxy to download the updates. – DKNUCKLES Apr 10 '14 at 13:21
  • @DKNUCKLES done. Linux servers, mostly they are RedHat v5 and v6. – eez0 Apr 10 '14 at 14:09
  • Well, first it depends on what Linux/version you want them to have in the end. Then it depends on whether you have any constraints on libraries/versions. If you don't, save your data, get some DVD of your favorite Linux and do a fresh installation. RedHat 5 and 6 are so old I'm not sure you can upgrade to CentOS or Fedora. Too much has changed along the way. IIRC RedHat 7 was the first with a 2.4 kernel in its standard installation. – Bananguin Apr 10 '14 at 20:46
  • With apt-based distributions, the solution would be something like apt-zip or apt-offline. You might want to search for a yum analog of these. – Gilles 'SO- stop being evil' Apr 10 '14 at 22:08

Updating an offline machine means finding a way to present the updates to that machine (this will most probably involve an external hard disk or USB stick, to move the files from online machines to the offline systems).

In generic strategy terms, you have the choice between the three following solutions:

  1. Put the systems briefly online, behind some well-configured firewalls which will let download requests pass, but no more.

  2. Download all relevant update packages, and transport them (with an offline medium, such as a USB stick) to the machine to upgrade.

  3. Don't upgrade: the systems are offline, so they don't need security updates.

The first one is easier, but (arguably) the second is safer. In the case of RedHat systems, this is normally a matter of creating a local repository; a lot of information can be found online with some simple Google requests. See for instance the RedHat documentation itself.

The third strategy (do nothing) is the easiest to implement, but requires some thinking. Basically, you first have to carefully decide with yourself whether an update is actually mandated. There is no such thing as "outdated" in general. If you need some newer functionality, or newer software to accommodate newer hardware parts, then of course some update will be needed. However, this is still a question which deserves some thorough thinking.


It is very hard to answer your question because it mostly is "how do I fix a broken state" ? The answer depends a lot on the specifics of your installation and requirements.

However, recovering will start with fixing the real problem first: making sure you either can (and will) patch your servers in the future or making sure you will not need to.

For that, you need to identify the reason why you're not patching. It can be resources (you don't have the time to test and deploy patches), requirements (you're depending on an application that require a specific version of your platform) or simply bad planning (you have never properly tested your updates and were "burned" by a bad update once, leading to a "no patch" strategy).

After you have identified the cause of your problem, you should design a fix. It usually implies designing a testing strategy, improving documentation and processes and allocating resources.

Once that is done, "how to patch" should have been solved already. One of the simplest way to migrate from the current state to a new state where patches are applied it to reinstall the servers (safely) and migrate the application. if you have prepared the documentation, it should be a rather simple step (although if you need high availability, it might be delicate to implement).

Finally, there is the special case when you decide that you actually don't need to (or can't) patch. In this case, simply document properly your situation (including relevant statements from decision makers).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.