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>