Onderwerp: Corrupte Micro update Plesk (indien auto updates aanstaat)

Parallels zoveelste blunder, de automatische Micro update van afgelopen nacht breekt de Plesk omgeving en websites zijn onbereikbaar:

New files of configuration for Apache web server were not built due to errors in configuration templates: Syntax error on line 31 of /etc/httpd/conf.d/php.conf: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration . The detailed error message was e-mailed to you, so please check the e-mail, fix the errors, and click here to retry generating broken configuration or click here to retry generating of all configurations.

welke MU is dit?

Vandaar ook nooit auto updates gebruiken op dit soort systemen.

Oorspronkelijk geplaatst door NixDevs.com

Vandaar ook nooit auto updates gebruiken op dit soort systemen.

Nu dat deden wij dus ook niet tot vorig jaar, toen er vele Plesk omgevingen waren gehacked door het niet automatisch uitvoeren van de security patch in de Microupdates en wereldwijd vele Plesk omgevingen waren gehacked!

Wel een heel gemakkelijke opmerking die je hier weg zet......

Wat ik van onze technici begreep is dat blijkbaar sinds Plesk 11 de Microupdates van Plesk ook bijvoorbeeld de PHP update van de Atomic repositories automatisch uitvoert....de Atomic PHP is blijkbaar corrupt en breekt deze. Vraag is wel waarom de Plesk Microupdates dergelijke updates (Atomic) uitvoert?

Iemand al een oplossing?

Oplossing: gewoon geen automatische updates op productiesystemen draaien zonder test

ik heb eea gechecked, maar op verschillende plesk servers (met de laatste updates) niets aan het handje...
Weet je zeker dat het niet iets local is, wat breekt?

Daarnaast zijn er hier een hoop 'klok/klepels'. Plesk heeft tegenwoordig een redelijk geavanceerd auto update systeem, waarbij de default instelling is dat (micro)updates pas automatisch worden gedownload als deze door duizenden pre-release testers succesvol is bevonden. En deze autoupdate instelling kan je ook gewoon uitzetten.

Klopt beter om de Microupdates uit te zetten....zoals hiervoor het geval was :-((

Blijft het feit staan dat er een Microupdate PHP update van de Atomic repositories automatisch uit gevoert wordt....de Atomic PHP is blijkbaar corrupt en breekt deze. Vraag is wel waarom de Plesk Microupdates dergelijke updates (Atomic) uitvoert en dat dit vanaf Plesk 11 actief is geworden.

Hier geen probleem met de laatste updates...

Plesk doet keurig een yum update all om het OS up2date te houden en geeft ook keurig een melding wanneer je een 3rd party repo hebt toegevoegd.
Maar dan nog, ook hier Atomic repos geactiveerd en Atomic heeft niets te zoeken in /etc/httpd/conf.d/php.conf (dat is immers een Plesk eigen locatie)
De oorzaak lijkt me dan daar ook niet liggen

Oorspronkelijk geplaatst door systemdeveloper

Oplossing: gewoon geen automatische updates op productiesystemen draaien zonder test

Exactly. Updates moeten goed getest worden voordat ze worden geinstalleerd.

Oorspronkelijk geplaatst door NixDevs.com

Exactly. Updates moeten goed getest worden voordat ze worden geinstalleerd.

Yups, zolang ik zelf nog altijd nu en dan tegen een situatie oploop van 'wtf... ben ik soms de eerste die dat installeert?!?!', installeer ik updates altijd eerst op een testbakkie.
En buiten dat klik ik over het algemeen bij een productie bak ook nog even de 'red-mij-met-een-snapshot' knopje aan voordat ik ga 'kloten'

Oorspronkelijk geplaatst door systemdeveloper

Yups, zolang ik zelf nog altijd nu en dan tegen een situatie oploop van 'wtf... ben ik soms de eerste die dat installeert?!?!', installeer ik updates altijd eerst op een testbakkie.
En buiten dat klik ik over het algemeen bij een productie bak ook nog even de 'red-mij-met-een-snapshot' knopje aan voordat ik ga 'kloten'

Zal dus inhouden dat je de Plesk Microupdates moet uitzetten, juist dat Parallels het advies geeft deze juist actief te houden en dat je anders van die zaken krijgt als enige tijd geleden dat Plesk eigenaren de Microupdates hadden uitgezet en een groot deel van de Plesk omgevingen was gehacked........