On Thu, 2019-01-17 at 17:50 +0000, Lester Caine wrote: > On 17/01/2019 17:04, Larry Garfield wrote: > > 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. > > Nobody here but me so 'I' would be the one who did everything ... In > this particular case I was quite happy that PHP7.0 package was locked > along with Firebird and Nginx ... also that Apache was blocked. > APPARENTLY that will only work while the older repos are still available > so I need to work out how to stop using the package manager and keep > manual control of the versions installed. Currently keeping the content > up to date takes a higher priority than any need to update the stack at > all! There is no spare time to 'test' when one is firefighting all the time. > > > "Everybody has a testing environment. Some people are lucky enough enough to > > have a totally separate environment to run production in." > > I've several machines working in the background and there is a > development machine but that is of little use while Letsencrypt do their > own updates to the production machines when updating the current certs! > I STILL can't get the new site certs set up at all on that machine so > taking control of the PHP version is a little academic anyway, but I > think I still need to roll back to 7.0 with Firebird2.5 as is working on > the other production machines. > I may be a bit naive here, and certainly off topic, but I have the same situation as Lester and I don't understand why the site certificate should care what versions of the application software are running, or even if a particular package is present. I have several versions of PHP running on my only server, which is both test and prod, and also two versions of Apache, and the site certificate (not from LetsEncrypt) is installed as a separate task every year. I always install application software from source and NOT from the distro because I don't want surprises and I want control so I can test before going live. John
