Door
Onbekende gebruiker
op 14-11-2022 09:43
gewijzigd op 14-11-2022 12:53
4.469 views
Een kritiek productiesysteem draait Debian met PHP.
De security support van PHP 7 loopt af.
En de main respository voorziet niet in een update naar PHP 8.
Ik heb gehoord van deb.sury.org , maar gezien dat hier slechts 1 persoon achter zit, brengt dit een onverantwoord beveiligingsrisico met zich mee.
Eerst zelf compileren op een ander systeem lijkt me veel gedoe met overzetten, ik ken niet alle afhankelijkheden en moet garanties hebben dat dan alles wel goed werkt, en dat binnen 2 weken omdat daarna PHP 7 niet meer ondersteund wordt.
Het kritieke productiesysteem afsluiten brengt de bedrijfscontinuïteit in gevaar.
We lijken hier vast te lopen met Debian. Als ik naar andere Linux-distributies kijk, zoals CentOS, komt ook hier weer een third party packager aan te pas.
Is dit het einde van PHP voor onze productie-omgeving?
Of moeten we verplicht overgaan op een commerciële aanbieder van Long Term Support zoals Freexian?
Wat zou jij doen ?
>> en dat binnen 2 weken omdat daarna PHP 7 niet meer ondersteund wordt
Je PHP blijft gewoon werken, alleen volgen er geen beveiligingsupdates meer. Het is niet zo dat ineens niks meer werkt. Aangezien dat men niet zomaar ineens je server kan binnendringen, heb je wel iets langer de tijd dan die 2 weken.
Ik zou naast de huidige server een nieuwe (test)server opzetten met een frisse installatie en daar alles naar overzetten, terwijl je de huidige server laat draaien. Op de nieuwe server ga je dan testen of alles naar behoren werkt en zo niet aanpassingen doorvoeren. Als alles werkt kun je de switch maken naar de nieuwe server en de actuele databasegegevens (indien van toepassing) overzetten.
?Onbekende gebruiker
14-11-2022 11:35
Klinkt goed.
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
Als de main respository niet voorziet in een update naar PHP 8, dan kan je toch een aparte fork aanmaken om dit te fixxen? Of ligt de software niet in jullie beheer?
?Onbekende gebruiker
14-11-2022 15:27
Ivo P op 14/11/2022 12:47:39
[quote="Ad Fundum op 14/11/2022 11:35:12"]
Klinkt goed.
Welke software zou je op de testserver zetten, en waar haal je die vandaan?
Oké, maar als ik vanaf https://www.php.net/downloads.php PHP download, krijg ik geen voorgecompileerde code. Dus dan moet ik na het compileren PHP van de testserver overzetten naar de productieserver, want op de productieserver is geen build systeem aanwezig (met reden). Als ik naar https://www.php.net/manual/en/install.unix.php kom ik niet te weten hoe je de gecompileerde PHP verder kan distribueren naar andere servers. Als daar een document van zou zijn dan zou deze optie wel een mogelijkheid zijn.
[size=xsmall]Toevoeging op 14/11/2022 15:28:28:[/size]
Ivo P op 14/11/2022 12:47:39
[size=xsmall]Toevoeging op 14/11/2022 12:49:30:[/size]
Ik ken trouwens nog genoeg omgevingen die nog steeds op PHP 5.x draaien.
1 daarvan is dit jaar naar 7.0 bijgewerkt...
Maar net zoals je nog steeds je pc met windows 7 of 8 kunt opstarten, werkt PHP 7.4 voor volgende maand nog gewoon hoor.
Toch kan ik met dit verhaal niet onderbouwen waarom het veilig is om Windows 7 of 8 als "server" aan het internet te hangen, helaas.
[size=xsmall]Toevoeging op 14/11/2022 15:34:11:[/size]
- Ariën - op 14/11/2022 12:49:58
Als de main respository niet voorziet in een update naar PHP 8, dan kan je toch een aparte fork aanmaken om dit te fixxen? Of ligt de software niet in jullie beheer?
De software die we gebruiken moet aangepast om op PHP 8 te draaien, maar waar het hier om gaat is dat de main repository van Debian niet voorziet in PHP 8.
Ik heb nog op internet nagezocht wie er achter deb.sury.org zit. Deze Tsjech heeft een betrouwbare reputatie, maar opereert helemaal in zijn eentje. Hij kan dus in zijn eentje de updates bepalen van PHP 8, er is verder geen procesmatige garantie met iets als een twee-ogen-principe over wat hij op onze productieserver kan. Alleen al om die reden kan ik dat bijvoorbeeld vanuit de AVG-wetgeving niet verantwoorden naar de Autoriteit Persoonsgegevens.
Dat is heel jammer, omdat de oplossing die hij aanbiedt technisch veruit het gemakkelijkste werkt.
Het probleem dat ik heb zit hem in Step 2: Add Sury APT repository to Debian. Die repository wordt beheerd door 1 enkele Tsjech, en dat is een risico. In theorie kan zo iemand op elk gewenste moment een update uitbrengen met kwaadwillende code. Het zou mooier zijn als er verschillende mensen bij betrokken zouden zijn, met een proces van testen en goedkeuren.
Vergelijk het met het doen van financiële transacties namens een organisatie, dat is ook in meerdere stappen (opdracht plaatsen, goedkeuren en uitvoeren) en door verschillende mensen.
Als er nu iets mis gaat met die repository, en je moet een datalek uitleggen aan het AP, dan heb je geen goed verhaal als je moet zeggen: "ik heb een mede Europeaan op z'n blauwe ogen geloofd, en nu ligt de data van al m'n klanten op straat"
Ik heb het ook niet zo op die packages, maar dan om de reden dat je altijd moet wachten tot iemand dat gemaakt heeft.
Zelf download ik altijd de source om die vervolgens te compilen. Kost je wel eerst een middag om uit te zoeken welke onderdelen (mysql, xml, zip etc) je in je php nodig hebt, maar daarna kun je scripts-gewijs je php updaten (de minor versions bedoel ik dan: dus van 8.1.10 naar 8.1.11 of naar 8.1.14 etc)
Ik heb nooit helemaal begrepen waarom je php middels
apt-install php8 zou moeten installeren als dat betekent dat je soms maanden moet wachten voor zo iets in de distro van je Linux-versie beschikbaar is...
?Onbekende gebruiker
16-11-2022 09:14
gewijzigd op 16-11-2022 09:17
Oké, dus dan wordt het: zelf compileren, updates bijhouden, testen en overzetten naar productie.
Nu mis ik alleen nog informatie die nodig is voor de laatste stap.
Hoe kan ik PHP van het ene systeem overzet naar het andere, zonder opnieuw te compileren?
@Ozzie, nog bedankt voor de tip! Ik kan alleen niet even de productieserver verwisselen, dat zorgt voor veel downtime.
