Re: How do we know ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/01/2019 15:06, Richard wrote:


Date: Thursday, January 17, 2019 14:53:10 +0000
From: Lester Caine <lester@xxxxxxxxxxx>

With distros disabling PHP7.0 and as a result PHP7.2 upgrades being
applied despite ( I thought ) being locked out, I THEN find
problems even with the PHP7.0 machines with thumbnails not being
generated from the pdf uploads. The original problem was
letsencrypt stopping updating the certs and complaining about
python files not being available! Luckily this was before they
expired, but not the first time it's background process has stopped
working and I have lost sites.

Just how do we set things up so that WE control just what is
updated and what is not? I know it's a distro problem, but I
suspect the solution has to be NOT loading PHP, Nginx and Firebird
from the distribution at all? Yet we are reliant on secondary
software load by the distribution. The PDF problem turned out to be
a change to how 'convert' using ImageMagick actually decides if it
is going to handle a file format - the change stopped it READING
the file. I don't even remember updating that machine since it
worked on Monday!

I've now got to go through all the sites and fix 'count()',
'each()' and random complaints about 'numbers' so I can stop hiding
the deprecated messages but I had to switch off all errors just to
get the machine live again and my machines have always run with
errors being displayed as THAT helps when things do go wrong! None
of these give me anything but a waste of even more time :( Just
when did it become necessary to add typing everywhere to stop new
messages?

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 :(

--
Lester Caine - G8HFL
-----------------------------
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux