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 (b...@broadley.org): >> >>>> 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 >> vox-tech@lists.lugod.org >> http://lists.lugod.org/mailman/listinfo/vox-tech > > _______________________________________________ > vox-tech mailing list > vox-tech@lists.lugod.org > http://lists.lugod.org/mailman/listinfo/vox-tech _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
