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:
- 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.
- 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:
- Keep current with bugfixes.
- Compile and package the upgraded software.
- Verify that it is stable, does not behave differently than the previous version and generally doesn't break anything in your system.
- Verify that the upgrade procedure itself works.
- Distribute to the field.
- 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.
