On Thursday, January 17, 2019 9:26:43 AM CST Lester Caine wrote: > > The proper approach is to have a testing environment that matches > > your production one(s). Do updates there, fully test, and then > > proceed as indicated. Never apply updates to a production site > > without full testing and certainly never let a production site > > "auto-update". > > > > Also, unless there are security issues or you *absolutely* need a new > > feature, production sites rarely need bleeding edge. > > That sums the problem up! I don't WANT bleeding edge. I actually think > it may be better to drop back to PHP5.6 since I KNOW that will not be > updated by the distro, but when key functions such as certbot stop > working ON a production machine because IT insists on applying security > updates OVER what the distro provides? As the subject says "How do we > know" what to do when something that was working last week and is > critical to the machine stops working without explanation! What is more > annoying here is that the other two production machines which were in > theory identical are working fine so I have the option to move sites but > what is to say they will not be broken next certs renew cycle :( It sounds like the problem is your IT department blindly upgrading things on prod, not anything to do with PHP. They could just as easily break Nginx that way. Go yell at your IT team, because they're not doing proper testing. "Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in." "Everyone has a testing server. Some people are lucky enough to have a separate production server, too." --@stahnma (https://twitter.com/stahnma/ status/634849376343429120) --Larry Garfield
Attachment:
signature.asc
Description: This is a digitally signed message part.
