On 26 Apr 2016 23:28, "Tim Dunphy" <bluethundr@xxxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
