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?

HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
Faisal
  • 225
  • 1
  • 2
  • 6
  • 1
    tmux is a development tool? Anyway, it's in EPEL, go get it. – Michael Hampton Oct 29 '14 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 '14 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 '14 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 '14 at 16:11

2 Answers2

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.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • Not to mention, minor version differences between libraries on two different systems can wreck havoc on the build process. – Nathan C Oct 29 '14 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.
HBruijn
  • 72,524
  • 21
  • 127
  • 192