This is a tough question, and I hope I describe it correctly. We utilize Ubuntu as the OS for a proprietary network appliance on various networks. There are several hundred of them in existence right now. They are about 50/50 on Hardy LTS or Lucid LTS. All run Samba, which is where our story really begins ...

Samba has had many critical bug fixes released in the last few years, and are now on version 3.6.0. The Lucid packages database only goes up to 3.4.7, which has several major vulnerabilities that have been patched in 3.5.x versions.

What is the best way to maintain the Samba version on these units in the field? I want to avoid having to replace them, which can be expensive; I want to try to avoid running command line upgrades to the distro (i.e., from Hardy to Lucid) since we don't have physical access to all the units and the upgrades would all be done remotely.

We have a server to run a custom Ubuntu package repository, but I have fears that it will break Hardy. Thoughts on a best practice for this? Step 1, come up with a long term plan to keep the distro's on the latest LTS releases, but after that, how do we get the latest version on the LTS releases when the LTS doesn't have it ...


The normal policy of various server-oriented distributions, is to keep fixed the version number and backport important updates to that version. Important updates being defined as security/stability fixes. The whole point of the "long-term support" is to provide users with two things:

  1. Feature stability. Latest and greatest is wonderful, unless you have to change config of all your production machines right now, because the new version behaves differently/has changed config/input/output format.
  2. Stability and security. Because users cannot upgrade to the newer package version (see 1.), the distribution maintainers backport important changes to the supported version. The effort needed for this backporting is one of main reasons, that only some versions of some distributions are being maintained for extended periods of time.

Therefore, I think, your problem is reduced to upgrading your boxes to the latest of what's in the distribution, provided that both of them are still being maintained. You may also check in the release notes of the packages, that the security bugs have been patched in the upgraded versions. They ought to be, but it's nice to have proof in writing.

If any of the distribution that you use is already out of support, you are back to square 1. In that case, the safest, an in my opinion best overall, option would be to upgrade the boxes to a supported distribution. Painful and expensive, I know, but security and stability is what customers pay for. Even internal customers. If you will not get resources for the required upgrade, I'd get that in writing (i.e. e-mail) from your manager and backup, and archive multiple copies of it for the time when one of the machines will crash/get hacked due to the lack of the upgrade. Prudent self-preservation policy.

Of course, you can create custom packages (possibly with dependencies), and ship them to the field for upgrades, but you'd have to:

  1. Keep current with bugfixes.
  2. Compile and package the upgraded software.
  3. Verify that it is stable, does not behave differently than the previous version and generally doesn't break anything in your system.
  4. Verify that the upgrade procedure itself works.
  5. Distribute to the field.
  6. Goto 1.

This is possible, but requires a lot of time and effort, pretty much defies the point of using a LTS disribution. Another thing: Samba isn't the only potential problem. What about kernel/glibc/other essential packages?

However you cut it, you'll need some infrastructure for upgrading the boxes. The easiest (but not always feasible, I know) thing would be to use the one set up by the distribution maintainers.


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.