Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This may be a canonical question, and it may simply be a function of my inexperience, but I'm curious to know if there are best practices aimed at avoiding dependency hell when you find yourself in an environment with limited access to common, open repositories.

In our specific case, our struggle is working within the context of a large corporation with security policies that severely diminish the ability to access outside repos for packages when installing various software.

How do you balance security with the need for access to public repos? Is there a way to limit the dependance on external repos without making the installation of Linux software impossible? What kind of arguments can be made for the security and reliability of yum or apt-get repos?

A broad question I know - I hope it's appropriate here - but I'm very curious to see what other people's experience in this area has been.

share|improve this question
up vote 3 down vote accepted

You avoid dependency hell (and a whole raft of other things) better when you limit the number of external repositories you use. Since you can't guarantee the quality, long-term availablility, and timeliness of the contents of those repositories, it is a very poor move to rely on their contents (and continued existence).

As a concrete example, I've previous seen examples where semi-official third-party repositories of packages for a stable Linux distribution had packages come and go over time. This caused a great deal of trouble, because we might build up a few machines at one time, which all got the same version of a critical package. Some time later, when we went to build more machines, the version we had specified was no longer available (superceded by a newer, shinier version) and we had to test everything again to make sure the newer package still worked properly.

This isn't the worst possibility. What if we didn't test the new package, and it had a critical bug in it? Bummer. Of course, the version we choose may turn out to have a security flaw in it, but that's OK, because as responsible packagers we keep an eye on upstream security announcements and ensure that any vulnerabilities are patched appropriately.

The cautious administrator only installs packages onto his/her systems from two places:

  • The distribution's official repositories (appropriately cryptographically verified for authenticity, of course), where the policies and practices of the manner in which packages are added and removed is known and complies with your own risk management assessment; and
  • An internally managed package repository or repositories (again, cryptographically verified).

The contents of that internal repository set can be populated by several different means:

  • Download packages from external, third-part repositories, verify their utility and stability in a testing environment, and then add them to the repo.
  • If you are moderately paranoid, you rebuild the source packages from the above repos, then test and add.
  • If you're properly paranoid, you shut yourself in a small room without any computers or electronic equipment whatsoever.
share|improve this answer
This is a great perspective womble. The idea of having too many repositories is a great consideration. I guess I was curious about situations when you have no access to even official repos, like RedHat's. In our case, we're limited to what I suppose is the next logical solution - an internally managed repo. Unfortunately, ours seems to be quite limited and very dated, though I guess that's an issue for the repo managers. – Univ426 Jul 10 '12 at 17:18
Yes, it is. Tough if you've got crap internal repos, at least, there's a better chance of making a case and having the repos improved than you do if you're trying to get some third-party repo to work. As far as not having direct access to the official repos, well, that's easy: an internal mirror. If that isn't possible, then it's easy to make a strong case that that is an unworkable situation because of lack of timely security updates. – womble Jul 10 '12 at 17:29
@JohnK I am in the same boat as you. If you try to do a yum install of something it will fail because the version we are using is newer than what the repo has to offer...for instance "devel" packages. Its a nightmare, and the fix is install a newer version of RHEL.... – JMeterX Jul 10 '12 at 17:44
@womble the saddest part about it...I am not installing packages by hand. As an example our package for HTTPD that comes installed on our system is version 2.2.3-65.el5_8. If I want to say install httpd-devel I stare at 2.2.3-31.el5 so I am forced to downgrade httpd. Further you then get packages for instance apr, apr-util, db4, etc. all of which are incorrect versions against the repo. – JMeterX Jul 10 '12 at 18:08
Whoever's building those systems needs their fingers broken. For the good of the Internet. – womble Jul 10 '12 at 18:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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