1

I want to install some software on production CentOS box which are not available from repository (like tmux etc). I can download the source and compile it locally, but for doing that I'll need development tools (gcc etc) on a production box. Is it a good idea to install development tools on production box?

Improve this question
4
  • 1
    tmux is a development tool? Anyway, it's in EPEL, go get it.
    – Michael Hampton
    Oct 29, 2014 at 20:10
  • 1
    Providing dev/prod are the same distro and build (and it really should be), you can just compile it on your development box and copy the resulting program over. Programs don't have to be compiled on the machine they're running on.
    – Nathan C
    Oct 29, 2014 at 20:12
  • @krisFR thanks for the comment. I used tmux as an example here, but, I was generally asking about tools which are needed on production server but are not available in the official repo.
    – Faisal
    Oct 30, 2014 at 16:07
  • @MichaelHampton I don't think tmux is useful for development only. I am not an admin, but, I think tmux should come in handy for admins on production box as well.
    – Faisal
    Oct 30, 2014 at 16:11

2 Answers 2

Reset to default
5

I am anti-development tool on production machines. I've taken flak from people who say this goes against some nebulous "Unix philosophy", but I take the stance that:

  • Having "excess" software on a machine equates to more "moving parts" and greater odds of failure

  • Development tools being available for you means they're available for attackers who might gain unauthorized access to your machine

  • Compiling things from scratch on production machines runs counter to a rigorous change control process, to my mind.

I believe the "tax" to spend the time to build packaged binaries for programs that you'd otherwise need to compile is worth the hassle. I think it promotes good change control practices, too.

Improve this answer
1
  • Not to mention, minor version differences between libraries on two different systems can wreck havoc on the build process.
    – Nathan C
    Oct 29, 2014 at 20:25
2

The primary risks from an operational/security aspect of having development tools on production systems is that simply put

  • the more software that is installed the larger the attack surface and the more you need to maintain
  • most people who deploy software from source don't maintain it after successful initial deployment
  • most software maintenance and reporting tools on Linux are oriented towards packages and don't report very well on software deployed from source, tying in with the above. Often you won't know you're at risk from outdated software.

In order :

  1. use packages from well maintained repositories, let a maintainer worry about following mailing lists, CVE announcements, bug track, building and testing packages etc,
  2. build your own packages and do the above yourself. Build on a dev or build system, test and do release management in UAT before deployment in production.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .