Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran ([email protected]): > Thanks Rick. > > This is why I have such great respect for the members of this list. > You have such valuable experiences that you are willing to share. I > regret that I have had the experience of server issues occurring at > bad times (right after talking about our product at a trade event), > but thus far none have been PHP or MySQL related, so I very much > appreciate the insights of others. Looking over my notes about tightening PHP security (direct link http://linuxmafia.com/faq/Security/php.html), I see something I might consider writing more about (in that piece): I talk about several prototype files Debian provided for /etc/php5/apache2/php.ini , specifically: /usr/share/doc/php5-common/examples/php.ini-paranoid /usr/share/doc/php5-common/examples/php.ini-recommended The thing is, the distribution-provided /etc/php5/apache2/php.ini file stated in header comment lines... well, let me just quote it: ;;; ; About this file ; ;;; ; PHP comes packaged with two INI files. One that is recommended to be used ; in production environments and one that is recommended to be used in ; development environments. ; php.ini-production contains settings which hold security, performance and ; best practices at its core. But please be aware, these settings may break ; compatibility with older or less security conscience applications. We ; recommending using the production ini in production and testing environments. ; php.ini-development is very similar to its production variant, except it's ; much more verbose when it comes to errors. We recommending using the ; development version only in development environments as errors shown to ; application users can inadvertently leak otherwise secure information. So, thing is, I could swear that the _default_ php.ini Debian installed to /etc/php5/apache2/php.ini was the _development_ variant -- because when I got around to looking through it and locking it down, I was a bit shocked at the high default security exposure. It was exactly as I was working through that file, commenting out dangerous and unneeded optional interpreter features, that I wrote my modest hardening guide (more as notes for my own benefit than with any intent to publish). That experience was one of my first signs that something was not right with PHP and its security posture. It might be my imagination, but I think part of what's happening is that only lip service is normally given to enabling only the language functionality actually necessary; that many developers of PHP developed applications blithely expect deploying sites to have the kitchen-sink set of language functions available and their code mysteriously fails if you don't. So, deploying sites are passively led into bad habits and bad defaults. And, for example, picture a world where the developers gravitate towards php.ini-development and sysadmins towards php.ini-production. What's going to happen as a natural tendency? You know developers; they'll happily use the features in front of them, which then will ratchet up the need for those in deployment. Not good. It's a bad sign when the development default environment includes bad security and the attitude is 'be unsafe only while developing code and we'll fix it all up later'. A brief clarification: The incursion that happened just as I got on an ocean cruise this past February happened _despite_ all the security tightening, on account of yet another grave flaw in the core mod_php code. (I cannot tell you which flaw because I elected to just disable the thing rather than work further on it.) ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Somehow with a painfully thin straw of ssh bandwidth and only one hour of high-latency, low-reliability Internet access each evening, I was able to kludge together a lockout of the kiddies within a couple of days and before they were able to compile an exploit kit. When I reached Sydney, one of the first things I did from my hotel room was rip out the last bits of public-facing PHP exposure so I'd never have to worry about that again. BTW, anyone in this situation should immediately install mosh . It's pretty amazingly better, can even fall over between multiple network connections. Or install it now just in case you have to tether to a marginal cellular/wan connection. Blurb from https://mosh.mit.edu/: Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links. Mosh is free software, available for GNU/Linux, FreeBSD, Solaris, Mac OS X, and Android. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Thanks Rick. This is why I have such great respect for the members of this list. You have such valuable experiences that you are willing to share. I regret that I have had the experience of server issues occurring at bad times (right after talking about our product at a trade event), but thus far none have been PHP or MySQL related, so I very much appreciate the insights of others. Thanks again, Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/2/2016 18:46, Rick Moen wrote: Quoting Dr. Larry Ozeran ([email protected]): Rick, thanks again for your insights. You are most welcome. You are, of course, correct that we would not redesign our software without a significant and deep assessment of benefits and costs (money, time, resources, etc.). Most of the PHP, MySQL, and related code has been developed in house. I probably coded 10-15% myself. The intent of my comment was simply to indicate that we do not blindly accept that there is no better option than what we are doing. If there are strong arguments to support considering making a switch, I would not exclude that possibility without reviewing the pros and cons simply because we have a large legacy investment. I consider your response (below) to fall into the 'cons' (to switching) category and will definitely compare your PHP security recommendations against what we currently are and are not doing. I am very glad to be of help -- and certainly was trying to be at pains to avoid advising anyone to merely redesign, especially without knowledge of the particulars. My own disaffection with PHP was markedly increased when I boarded a cruise ship with my wife from San Francisco to Sydney, and right on the day of my departure my logcheck reports started indicating a serious attempt to break security on my server via (what turned out to be) mod_php -- exactly at a time when I had just boarded an ocean vessel with only satellite Internet at very high prices. Somehow with a painfully thin straw of ssh bandwidth and only one hour of high-latency, low-reliability Internet access each evening, I was able to kludge together a lockout of the kiddies within a couple of days and before they were able to compile an exploit kit. When I reached Sydney, one of the first things I did from my hotel room was rip out the last bits of public-facing PHP exposure so I'd never have to worry about that again. My _own_ view is that PHP is entirely too much like the scenario Marcus Ranum described in his rather caustic 'What Sun Tsu Would Say' essay, i.e., as Ranum phrases it, 'If patching hasn't been working, why are we still doing it?' I stopped needing to apply the PHP patch du jour by no longer exposing it to public networks. But whatever works for you is of course great. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran ([email protected]): > Rick, thanks again for your insights. You are most welcome. > You are, of course, correct that we would not redesign our software > without a significant and deep assessment of benefits and costs > (money, time, resources, etc.). Most of the PHP, MySQL, and related > code has been developed in house. I probably coded 10-15% myself. > The intent of my comment was simply to indicate that we do not > blindly accept that there is no better option than what we are > doing. If there are strong arguments to support considering making a > switch, I would not exclude that possibility without reviewing the > pros and cons simply because we have a large legacy investment. I > consider your response (below) to fall into the 'cons' (to > switching) category and will definitely compare your PHP security > recommendations against what we currently are and are not doing. I am very glad to be of help -- and certainly was trying to be at pains to avoid advising anyone to merely redesign, especially without knowledge of the particulars. My own disaffection with PHP was markedly increased when I boarded a cruise ship with my wife from San Francisco to Sydney, and right on the day of my departure my logcheck reports started indicating a serious attempt to break security on my server via (what turned out to be) mod_php -- exactly at a time when I had just boarded an ocean vessel with only satellite Internet at very high prices. Somehow with a painfully thin straw of ssh bandwidth and only one hour of high-latency, low-reliability Internet access each evening, I was able to kludge together a lockout of the kiddies within a couple of days and before they were able to compile an exploit kit. When I reached Sydney, one of the first things I did from my hotel room was rip out the last bits of public-facing PHP exposure so I'd never have to worry about that again. My _own_ view is that PHP is entirely too much like the scenario Marcus Ranum described in his rather caustic 'What Sun Tsu Would Say' essay, i.e., as Ranum phrases it, 'If patching hasn't been working, why are we still doing it?' I stopped needing to apply the PHP patch du jour by no longer exposing it to public networks. But whatever works for you is of course great. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Thanks Alex. I have heard about Docker but no one on our team has experience with it. I will look into it. Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/2/2016 07:35, Alex Mandel wrote: This might be a a good use case for a Docker container, which is essentially all the components you need but not messing with your system libraries and dependencies. If you're open to other options, python+ django/pyramid/ or flask, + postgres/,mysql, sqlite. Or Ruby + Rails + Database. Those are 2 very common alternatives to PHP based stuff. Enjoy, Alex On 06/02/2016 05:39 AM, Dr. Larry Ozeran wrote: Thanks Rick. Good information is always appreciated. Since we are serving data that can change every few minutes, we can't move to static pages. Since we are providing that data to users from multiple originating sources, we pretty much have to be internet-facing. We have put security procedures in place, but I know that security is more an ongoing process than an endpoint and there is always more that will need to be done. If there is a better way to meet the needs of users other than MySQL+PHP, I am always open to new ideas. Thanks, Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/2/2016 00:41, Rick Moen wrote: Quoting Bill Broadley ([email protected]): Does anyone know any downsides to using the webtatic PHP packages on CentOS 6? I've seen many machines with ugly configurations related to cpanel, custom php installs (sometimes more than one), and fragile very hard to reproduce apache configurations. Although I guess I shouldn't complain, they get hacked and I get consulting. (Sadly, this won't answer Dr. Ozeran's question, either:) I've lately come to the conclusion, from many years as a Linux server admin, that PHP is tolerable on a Unix machine _provided_ it isn't ever exposed to public networks, because the ongoing security nightmare is otherwise not justifiable. I mean, yes if management is paying you to do it and the money's good, but if you're the boss, say 'Hell no.' So, e.g., every Web page on my linuxmafia.com server that used to be dymanically assembled by the PHP interpreter at Apache page-load time are (more recently) instead built on-disk in advance using automake or a cron script. Fortunately, none of those pages needed to _actually_ be dynamic; it was just coder laziness that chose that implementation. For example, the coder who helped me convert BALE (http://linuxmafia.com/bale/) from its original mid-1990s static HTML incarnation to PHP + MySQL set it up so every page load assembles the page anew, from several PHP fragments plus the results of a MySQL query (furnishing the events rows). When I realised the underlying reality of this being static data changing only once on the 1st of each month, I converted it into a static HTML page generated by a cron job in /etc/cron.monthly/ , and then Apache serves up just that static file. Whole huge categories of security threat have completely away for good, when I ditched runtime PHP. If I had any Web applications that actually relied on the PHP interpreter at load time, I'd try really hard to ditch them. It really is IMO that bad. And I say that because, so to speak, Ranum is my guru: http://www.ranum.com/security/computer_security/editorials/master-tzu/ That having been said: Dr. Ozeran, I know of nothing against the Webtatic repo's PHP packages. It seems like a competent external repo for CentOS/RHEL, though I have no relevant experience. Hope that helps! ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Rick, thanks again for your insights. You are, of course, correct that we would not redesign our software without a significant and deep assessment of benefits and costs (money, time, resources, etc.). Most of the PHP, MySQL, and related code has been developed in house. I probably coded 10-15% myself. The intent of my comment was simply to indicate that we do not blindly accept that there is no better option than what we are doing. If there are strong arguments to support considering making a switch, I would not exclude that possibility without reviewing the pros and cons simply because we have a large legacy investment. I consider your response (below) to fall into the 'cons' (to switching) category and will definitely compare your PHP security recommendations against what we currently are and are not doing. Thanks, Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/2/2016 07:02, Rick Moen wrote: Quoting Dr. Larry Ozeran ([email protected]): Since we are serving data that can change every few minutes, we can't move to static pages. Since we are providing that data to users from multiple originating sources, we pretty much have to be internet-facing. We have put security procedures in place, but I know that security is more an ongoing process than an endpoint and there is always more that will need to be done. If there is a better way to meet the needs of users other than MySQL+PHP, I am always open to new ideas. Meaning no criticism, I notice in looking upthread (http://lists.lugod.org/pipermail/vox-tech/2016-May/017013.html) that you mention only that your use-case involves PHP-served pages, but not what drives that particular choice of software. Sometimes, a local site uses PHP because it runs developed software resting on the PHP interpreter, e.g. Wordpress, MediaWiki, etc. Other times, that choice resulted from 'Data for each page must be pulled on a per-visit basis from MySQL, therefore some HTTP-invoked process must do a SQL query and assemble page contents and we happened to use PHP to do that because our Web guy knew how to do that.' And I'm sure there are other scenarios -- but dynamic is not synomyous with PHP in any event. Irrespective of how you arrived at that choice, obviously you would not lightly decide to rearchitect. A number of guides to tigthening PHP security to reduce risk exist and may be useful. My own modest effort, last updated when PHP5 was new, is here: 'PHP Security' on http://linuxmafia.com/kb/Web/ . ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
This might be a a good use case for a Docker container, which is essentially all the components you need but not messing with your system libraries and dependencies. If you're open to other options, python+ django/pyramid/ or flask, + postgres/,mysql, sqlite. Or Ruby + Rails + Database. Those are 2 very common alternatives to PHP based stuff. Enjoy, Alex On 06/02/2016 05:39 AM, Dr. Larry Ozeran wrote: > Thanks Rick. Good information is always appreciated. > > Since we are serving data that can change every few minutes, we can't > move to static pages. Since we are providing that data to users from > multiple originating sources, we pretty much have to be internet-facing. > We have put security procedures in place, but I know that security is > more an ongoing process than an endpoint and there is always more that > will need to be done. If there is a better way to meet the needs of > users other than MySQL+PHP, I am always open to new ideas. > > Thanks, > > Dr. Larry Ozeran > President, Clinical Informatics, Inc. > (530) 671-9244 > > On 6/2/2016 00:41, Rick Moen wrote: >> Quoting Bill Broadley ([email protected]): >> Does anyone know any downsides to using the webtatic PHP packages on CentOS 6? >>> I've seen many machines with ugly configurations related to cpanel, >>> custom php installs (sometimes more than one), and fragile very hard >>> to reproduce apache configurations. >>> >>> Although I guess I shouldn't complain, they get hacked and I get >>> consulting. >> (Sadly, this won't answer Dr. Ozeran's question, either:) >> >> I've lately come to the conclusion, from many years as a Linux server >> admin, that PHP is tolerable on a Unix machine _provided_ it isn't ever >> exposed to public networks, because the ongoing security nightmare is >> otherwise not justifiable. I mean, yes if management is paying you to >> do it and the money's good, but if you're the boss, say 'Hell no.' >> >> So, e.g., every Web page on my linuxmafia.com server that used to be >> dymanically assembled by the PHP interpreter at Apache page-load time >> are (more recently) instead built on-disk in advance using automake or a >> cron script. Fortunately, none of those pages needed to _actually_ be >> dynamic; it was just coder laziness that chose that implementation. >> >> For example, the coder who helped me convert BALE >> (http://linuxmafia.com/bale/) from its original mid-1990s static HTML >> incarnation to PHP + MySQL set it up so every page load assembles the >> page anew, from several PHP fragments plus the results of a MySQL query >> (furnishing the events rows). When I realised the underlying reality of >> this being static data changing only once on the 1st of each month, I >> converted it into a static HTML page generated by a cron job in >> /etc/cron.monthly/ , and then Apache serves up just that static file. >> >> Whole huge categories of security threat have completely away for good, >> when I ditched runtime PHP. >> >> If I had any Web applications that actually relied on the PHP >> interpreter at load time, I'd try really hard to ditch them. It really >> is IMO that bad. >> >> And I say that because, so to speak, Ranum is my guru: >> http://www.ranum.com/security/computer_security/editorials/master-tzu/ >> >> That having been said: Dr. Ozeran, I know of nothing against the >> Webtatic repo's PHP packages. It seems like a competent external repo >> for CentOS/RHEL, though I have no relevant experience. Hope that helps! >> >> >> ___ >> vox-tech mailing list >> [email protected] >> http://lists.lugod.org/mailman/listinfo/vox-tech > > ___ > vox-tech mailing list > [email protected] > http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Dr. Larry Ozeran ([email protected]): > Since we are serving data that can change every few minutes, we > can't move to static pages. Since we are providing that data to > users from multiple originating sources, we pretty much have to be > internet-facing. We have put security procedures in place, but I > know that security is more an ongoing process than an endpoint and > there is always more that will need to be done. If there is a better > way to meet the needs of users other than MySQL+PHP, I am always > open to new ideas. Meaning no criticism, I notice in looking upthread (http://lists.lugod.org/pipermail/vox-tech/2016-May/017013.html) that you mention only that your use-case involves PHP-served pages, but not what drives that particular choice of software. Sometimes, a local site uses PHP because it runs developed software resting on the PHP interpreter, e.g. Wordpress, MediaWiki, etc. Other times, that choice resulted from 'Data for each page must be pulled on a per-visit basis from MySQL, therefore some HTTP-invoked process must do a SQL query and assemble page contents and we happened to use PHP to do that because our Web guy knew how to do that.' And I'm sure there are other scenarios -- but dynamic is not synomyous with PHP in any event. Irrespective of how you arrived at that choice, obviously you would not lightly decide to rearchitect. A number of guides to tigthening PHP security to reduce risk exist and may be useful. My own modest effort, last updated when PHP5 was new, is here: 'PHP Security' on http://linuxmafia.com/kb/Web/ . ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Thanks Rick. Good information is always appreciated. Since we are serving data that can change every few minutes, we can't move to static pages. Since we are providing that data to users from multiple originating sources, we pretty much have to be internet-facing. We have put security procedures in place, but I know that security is more an ongoing process than an endpoint and there is always more that will need to be done. If there is a better way to meet the needs of users other than MySQL+PHP, I am always open to new ideas. Thanks, Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/2/2016 00:41, Rick Moen wrote: Quoting Bill Broadley ([email protected]): Does anyone know any downsides to using the webtatic PHP packages on CentOS 6? I've seen many machines with ugly configurations related to cpanel, custom php installs (sometimes more than one), and fragile very hard to reproduce apache configurations. Although I guess I shouldn't complain, they get hacked and I get consulting. (Sadly, this won't answer Dr. Ozeran's question, either:) I've lately come to the conclusion, from many years as a Linux server admin, that PHP is tolerable on a Unix machine _provided_ it isn't ever exposed to public networks, because the ongoing security nightmare is otherwise not justifiable. I mean, yes if management is paying you to do it and the money's good, but if you're the boss, say 'Hell no.' So, e.g., every Web page on my linuxmafia.com server that used to be dymanically assembled by the PHP interpreter at Apache page-load time are (more recently) instead built on-disk in advance using automake or a cron script. Fortunately, none of those pages needed to _actually_ be dynamic; it was just coder laziness that chose that implementation. For example, the coder who helped me convert BALE (http://linuxmafia.com/bale/) from its original mid-1990s static HTML incarnation to PHP + MySQL set it up so every page load assembles the page anew, from several PHP fragments plus the results of a MySQL query (furnishing the events rows). When I realised the underlying reality of this being static data changing only once on the 1st of each month, I converted it into a static HTML page generated by a cron job in /etc/cron.monthly/ , and then Apache serves up just that static file. Whole huge categories of security threat have completely away for good, when I ditched runtime PHP. If I had any Web applications that actually relied on the PHP interpreter at load time, I'd try really hard to ditch them. It really is IMO that bad. And I say that because, so to speak, Ranum is my guru: http://www.ranum.com/security/computer_security/editorials/master-tzu/ That having been said: Dr. Ozeran, I know of nothing against the Webtatic repo's PHP packages. It seems like a competent external repo for CentOS/RHEL, though I have no relevant experience. Hope that helps! ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Quoting Bill Broadley ([email protected]): > >Does anyone know any downsides to using the webtatic PHP packages on > >CentOS 6? > > I've seen many machines with ugly configurations related to cpanel, > custom php installs (sometimes more than one), and fragile very hard > to reproduce apache configurations. > > Although I guess I shouldn't complain, they get hacked and I get consulting. (Sadly, this won't answer Dr. Ozeran's question, either:) I've lately come to the conclusion, from many years as a Linux server admin, that PHP is tolerable on a Unix machine _provided_ it isn't ever exposed to public networks, because the ongoing security nightmare is otherwise not justifiable. I mean, yes if management is paying you to do it and the money's good, but if you're the boss, say 'Hell no.' So, e.g., every Web page on my linuxmafia.com server that used to be dymanically assembled by the PHP interpreter at Apache page-load time are (more recently) instead built on-disk in advance using automake or a cron script. Fortunately, none of those pages needed to _actually_ be dynamic; it was just coder laziness that chose that implementation. For example, the coder who helped me convert BALE (http://linuxmafia.com/bale/) from its original mid-1990s static HTML incarnation to PHP + MySQL set it up so every page load assembles the page anew, from several PHP fragments plus the results of a MySQL query (furnishing the events rows). When I realised the underlying reality of this being static data changing only once on the 1st of each month, I converted it into a static HTML page generated by a cron job in /etc/cron.monthly/ , and then Apache serves up just that static file. Whole huge categories of security threat have completely away for good, when I ditched runtime PHP. If I had any Web applications that actually relied on the PHP interpreter at load time, I'd try really hard to ditch them. It really is IMO that bad. And I say that because, so to speak, Ranum is my guru: http://www.ranum.com/security/computer_security/editorials/master-tzu/ That having been said: Dr. Ozeran, I know of nothing against the Webtatic repo's PHP packages. It seems like a competent external repo for CentOS/RHEL, though I have no relevant experience. Hope that helps! ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
Thanks Bill. That's helpful. It is a physical server. You have given me several things to consider. Dr. Larry Ozeran President, Clinical Informatics, Inc. (530) 671-9244 On 6/1/2016 21:51, Bill Broadley wrote: On 05/18/2016 08:58 PM, Dr. Larry Ozeran wrote: I am Googled out (repeatedly finding the same sites) and the impressive expertise on this list gives me high hopes that someone here has an answer or a reference. I have found many sites talking about how to upgrade from PHP 5.4 (which appears to be the last CentOS 6 supported version of PHP) to later versions using webtatic. [https://webtatic.com/packages/php55/] What I have been unable to learn are the risks of doing so. Does anyone know any downsides to using the webtatic PHP packages on CentOS 6? I've seen many machines with ugly configurations related to cpanel, custom php installs (sometimes more than one), and fragile very hard to reproduce apache configurations. Although I guess I shouldn't complain, they get hacked and I get consulting. The main problem being that OS packages are upgraded regularly, if you build it yourself you really should be tracking the patches/upgrades for anything you compile your self daily or at least weekly. In most environment that just isn't practical. Normally I'd just recommend upgrading the OS when a major package is too old. Sadly upgrading to CentOS 7 doesn't get you newer than PHP 5.4.16. Pretty sad that CentOS 7 has a PHP from 2012. Ubuntu 14.04 LTS includes 5.5. Ubuntu 16.04 LTS include PHP 7.0.4. So supporting a custom PHP or doing a major OS switch to a Debian (or derivative) could be a difficult decision. I do suggest a full backup before you do anything, it could be quite painful if things go awry. You didn't mention if it was a virtual server or physical. If virtual it could be a fairly quick experiment to try any of your options without breaking the original. Sorry, no easy answer from me. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] Risks of upgrading past CentOS 6 supported PHP 5.4?
On 05/18/2016 08:58 PM, Dr. Larry Ozeran wrote: I am Googled out (repeatedly finding the same sites) and the impressive expertise on this list gives me high hopes that someone here has an answer or a reference. I have found many sites talking about how to upgrade from PHP 5.4 (which appears to be the last CentOS 6 supported version of PHP) to later versions using webtatic. [https://webtatic.com/packages/php55/] What I have been unable to learn are the risks of doing so. Does anyone know any downsides to using the webtatic PHP packages on CentOS 6? I've seen many machines with ugly configurations related to cpanel, custom php installs (sometimes more than one), and fragile very hard to reproduce apache configurations. Although I guess I shouldn't complain, they get hacked and I get consulting. The main problem being that OS packages are upgraded regularly, if you build it yourself you really should be tracking the patches/upgrades for anything you compile your self daily or at least weekly. In most environment that just isn't practical. Normally I'd just recommend upgrading the OS when a major package is too old. Sadly upgrading to CentOS 7 doesn't get you newer than PHP 5.4.16. Pretty sad that CentOS 7 has a PHP from 2012. Ubuntu 14.04 LTS includes 5.5. Ubuntu 16.04 LTS include PHP 7.0.4. So supporting a custom PHP or doing a major OS switch to a Debian (or derivative) could be a difficult decision. I do suggest a full backup before you do anything, it could be quite painful if things go awry. You didn't mention if it was a virtual server or physical. If virtual it could be a fairly quick experiment to try any of your options without breaking the original. Sorry, no easy answer from me. ___ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
