On 26 Apr 2016 23:28, "Tim Dunphy" <bluethundr at gmail.com> wrote: > > Hey guys, > > I tend to work on small production environments for a large enterprise. > > Never more than 15 web servers for most sites. > > But most are only 3 to 5 web servers. Depends on the needs of the > client.I actually like to install Apache and PHP from source and by > hand. Although I know that's considered sacrilege in some shops. > > I do this because on RH flavored systems like CentOS the versions of > Apache, php and most other software are a little behind the curve in > terms of versions. > > And that's intentionally so! Because the versions that usually go into > the various repos are tested and vetted thoroughly before going into > the repos. > > I like to use the latest, stable versions of apache and php for my > clients without having to create a custom RPM every time a new version > comes out. > > So what I'd like to know is it better in your opinion to install from > repos than to install by source as a best practice? Is it always > better to use puppet, chef, ansible etc even if the environment is > small? I'm sure this is a matter preference, but I would like to know > what your preferences are. > Unless you are explicitly tracking upstream and religiously providing builds as upstream release them taking upstream sources and building from them is a disservice to your customers. This goes doubly for just installing from source without making packages as then it's impossible to audit the system for what is installed or properly clean up after it. You need to be aware that it's not only about "vetting" but rather that auditing for a CVE becomes as simple as rpm -q --changelog | grep CVE ... Security updates from RH don't alter functional behaviour reducing the need for regression testing. Unless you have a very specific requirement for a very bleeding edge feature it's fundamentally a terrible idea to move away from the distribution packages in something as exposed as a webserver ... And when you do you absolutely need to have the mechanisms in place to efficiently and swiftly build and deploy new versions, and deal with any fallout yourself. Finally keep in mind the CentOS project can only viably support what we ship and not $random source. When you do need help and head to #centos on irc or report something on the mailing list keep that in mind. As for CM? Doesn't take any significant effort or time to knock together a playbook to cover what you did by hand. Doesn't need to be high quality and distro agnostic ready for galaxy (or forge or whatever chef does) but it does mean you have "documentation in code" of how that system is without having to maintain info on how to rebuild it anyway. And assume every system may need a rebuild at some point - having CM in place makes that trivial rather than "oh what was the special thing on this one" scenarios.