[CentOS] Apache/PHP Installation - opinions

[Andreas Benzler]

Another way i choose is install what i need in opt a php cli and configure
apache. What is the different? I drive php 5.3, 5.6 side by side. It always
depends of your needs.

How configure this stuff on my virtual host? ISP-Config
make it easy for me. 

Can be a solution for you. RPM isn’t that bad and  hold
the configuration in a spec file is handy. You can take a name for a package like php-7 and
 will be never overwritten by an update. There are many ways to track down
problems. It’s up to you. 

> Am 27.04.2016 um 09:30 schrieb James Hogarth <james.hogarth at gmail.com>:
> 
> On 26 Apr 2016 23:28, "Tim Dunphy" <bluethundr at gmail.com <mailto: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.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org <mailto:CentOS at centos.org>
> https://lists.centos.org/mailman/listinfo/centos <https://lists.centos.org/mailman/listinfo/centos>