PHP CMS automatisch update systeem

[juggle]

Beste Tweakers,

Voor een zelf geschreven CMS in PHP ben ik op zoek naar een oplossing om automatisch updates door te voeren. Het CMS is ontwikkeld op een zelf geschreven PHP Framework (MVC model) met MySQL als database systeem. Het CMS wordt grotendeels zelf gehost maar staat ook op servers van klanten geinstalleerd. Het betreft dus geen centraal systeem.

Regelmatig voer ik updates door aan het CMS en de verschillende modules. Dit gebeurt nu nog handmatig, dat wil zeggen, ik FTP de files en update de database.

Ik ben nu aan het kijken naar oplossingen om dit proces automatisch te laten verlopen. Daarvoor heb ik naar verschillende opensource CMS systemen gekeken maar dit betreffen vooralsnog database update scripts en een handmatige upload van de bestanden. In mijn ogen toch nog een wat omslachtige situatie.

Ik zat zelf te denken om een centrale plek in te richten bij ons op een server waar ik speciale update pakketjes plaats + de laatste versie van het CMS. Vervolgens laat ik de verschillende instanties op deze locatie controleren of het CMS alle updates bevat. Dit kan door middel van een ftp verbinding en aantal update scripts vrij gemakkelijk worden afgehandeld. Voor het bijhouden van de versies zal ik dan een methode hanteren zoals besproken in dit topic

Ik heb het idee nu nog te globaal in mijn hoofd en er liggen nog wat vragen:

- Zijn er betere manieren om dit soort updates door te voeren (bijvoorbeeld CVS (geen ervaring mee)) ?
- Hoe foutgevoelig is het updaten van het CMS op de server van de klant met behulp van ftp in php ?
- Hoe richt je dit proces in als de update meer dan 1000 files zou bevatten ?
- Hoe zeer ga je tegen beperkingen van de server aanlopen (Bijvoorbeeld Safe Mode) ?

Al met al ben ik dus erg nieuwsgierig hoe mede tweakers dit hebben opgelost of ervaring hebben met dit soort systemen.

[Y0ur1]

Al gedacht aan subversion, en dan een svn update vanaf de server? Er vanuit gaande dat je shell xs hebt en dat je de svn client kunt runnen op je server. Bij ons op het werk werken we met drie branches, te weten trunk, testing, en stable. De server wordt geupdate bij een nieuwe stable versie en sommige klanten kiezen ervoor om te updaten vanaf trunk.

[RetroTycoon]

WordPress heeft ook een prettig update-systeem, dat een zip-bestand op afstand laat uploaden via ftp. Dat wordt voor je uitgepakt en je kunt weer door.

[MueR]

Ik denk dat het systeem wat Wordpress gebruikt het handigste voor je zal zijn. Dat vereist in ieder geval enige mate van input van de klant, zodat als het fout gaat, ze ook tegen je kunnen zeggen "we deden die update van je", in plaats van zomaar "hij is ineens stuk".

[juggle]

Shell access heb ik helaas niet voor servers die niet door ons worden beheerd. Dit vergt denk ik wel de meeste aanpassingen op de server en is misschien neit heel geschikt.

Het updatesysteem van Wordpress zal ik eens nader onderzoeken. Ik meende dat het updatesysteem niet in de wat oudere versies van Wordpress zat.

Zijn er nog andere manieren om dit principe toe te passen ?

[Cartman!]

Wat ik even snel verzin: een bestand neerprakken die een PUT request kan afhandelen. Stuur daar de zip naar naartoe en schrijf de zip weg, pak em uit en overschrijf de aangepaste files. Je kunt ook nog even een backup draaien en zippen bijv. zodat je een fallback zipje hebt mocht er iets stuk gaan. Zo omzeil je de stap dat de klant dit zelf moet doen.

Na t updaten kun je evt. wat geautomatiseerde tests doen om een en ander te valideren bijv.

[juggle]

Cool die PUT methode. Nog niet eerder van gehoord en volgens mij vrij onbekend. Als ik wat verder lees daarover begrijp ik wel dat de server de put methode moet ondersteunen. Ik wil eigenlijk wel een systeem hebben waarvoor zo weinig mogelijk server instellingen benodigd zijn.

Ik heb zelf nog even zitten brainstormen en mijn aanpak zal er nu als volgt uitzien:

Op het cms komt een update script. Dit script maakt mbv php een ftp verbinding met onze update server. Daar download deze een zip bestand met daarin een database update script. De zip file wordt uitgepakt in de root en overschrijft de benodigde bestanden. Daarna wordt het update script uitgevoerd op de database en een entry in de database aangemaakt dat de update is doorgevoerd. Bij fouten of voltooide installatie na het updaten genereert het framework een email bericht naar mijn support account. Zodoende blijf ik controle op het proces houden.

Met behulp van RSS notificeer ik de gebruiker op het dashboard van ons CMS dat er een update beschikbaar is. De klant kan dan zelf ervoor zorgen dat de update wordt doorgevoerd. De RSS kan dan gefilterd worden op updates zodat een klant ervoor kan kiezen bepaalde updates wel of niet door te voeren of later door te voeren.

Al met al lijkt mij dit een zeer mooi systeem en erg gebruiksvriendelijk. Iemand nog ervaring met een soortgelijk systeem of andere systemen ?

[ZpAz]

In de meeste gevallen wil je toch de gebruiker de keuze geven om up te daten, dus wanneer de gebruiker inlogt ofzo, even een externe rss uitlezen die teruggeeft de laatste versienummer, en de locatie van deze verzie (een zip ofzo).

Daarna als de gebruiker kiest om up te daten, deze zip ophalen en automatisch uitpakken.

Als je wilt pushen kan je iets van een standaard upload script gebruiken bij de klant (welke zipjes accepteerd en uitpakt) waar je wel eerst moet inloggen (waarvan jij als beheerder uiteraard de gegevens van weet.) En dan via php op je eigen server een script draaien welke automatisch voor alle klanten dit script aanroept en het zipje versturen.

Dit kan je bijvoorbeeld doen met Zend_Http_Client, of Curl ofzo.

[RobertMe]

Sidenote: als je gaat updaten moet je rekening houden met dependencies, je kunt niet zomaar midden in een update proces bv. de bestanden van je database klasse veranderen terwijl je onder het updaten gebruikt maakt van die klasse. Of dat je een deel van je framwork update, en je hebt nog een oude module die niet werkt op dat nieuwe framework, of, of...

Ik zelf zou het ook zo maken dat je systeem bv. iedere X dagen/weken checkt of er een nieuwe versie is, en de eigenaar daarvan een notify geeft, en dat ie altijd nog zelf toestemming geeft dat er geupdate moet/kan worden. Als je een automatische update doet en de eigenaar weet daar niks van, en die update mislukt, kan de site zomaar uren/dagen offline zijn, omdat niemand weet dat de automatische update is mislukt.

[juggle]

@Robert dependencies zijn inderdaad belangrijk. Het update script zal een xml gaan raadplegen bij ons op de server en deze data vergelijken met voorgaande updates die worden bijgehouden in de database.
Ik kan in die zelfde xml dan ook de dependencies aangeven.

Overigens zal dagen eruit liggen van een site niet zo snel voorkomen. Door het uitgebreide foutrapport wat mijn framework mailt bij een error zijn fouten vaak al hersteld voordat de klant belt :-)

[RobertMe]

Door het uitgebreide foutrapport wat mijn framework mailt

En als er nu net iets mis gaat tijdens het updaten van je framework en daardoor kan de mail niet verstuurd worden? (het updaten van de mailklasse mislukt) Zijn toch allemaal dingen waar je rekening mee moet houden. Of je moet al iets maken waarmee het CMS zich aanmeld bij een systeem/server van jouw van, ik ga nu updaten, en als het klaar is met updaten dat het zich weer afmeld, en dat je dan een script laat draaien wat ieder uur kijkt of een update al meer dan een uur bezig is (dan zal wel iets mis zijn).

[Cartman!]

juggle schreef op woensdag 29 april 2009 @ 16:05:
Cool die PUT methode. Nog niet eerder van gehoord en volgens mij vrij onbekend. Als ik wat verder lees daarover begrijp ik wel dat de server de put methode moet ondersteunen. Ik wil eigenlijk wel een systeem hebben waarvoor zo weinig mogelijk server instellingen benodigd zijn.

Volgens mij werkt dit op elke normale server, is gewoon onderdeel van de HTTP1.1 standaard. Net zoals GET en POST heb je ook nog enkele andere zoals HEAD, PUT en DELETE. Kunnen erg handig zijn

[juggle]

@Cartman! Volgens dit artikel http://bitworking.org/news/PUT_SaferOrDangerous ook een artikel in de apache documentatie http://hc.apache.org/httpclient-3.x/methods/put.html wijst erop dat PUT niet standaard ondersteund wordt.

De informatie is soms wat gedateerd maar ik denk ivm security issues niet dat PUT evenals DELETE overal toegestaan is.

Desondanks zou dit een hele goede methode zijn om automatisch updates te verwerken. Maar gezien de limitaties geen waardige optie naar mijns inziens.

[sanzut]

Volgens mij is de FTP module standaard niet overal geactiveerd. Mogelijk zou je daardoor uit moeten wijken naar file_get_contents oid, en die dan daarna saven via fwrite.

[Cartman!]

Je kunt in php gewoon iets doen als:

PHP:

if('PUT' == $_SERVER['REQUEST_METHOD'])
{
$data = file_get_contents('php://input');
}

Blijkbaar hebben servers waar ik dit gebruikt heb dan allemaal PUT beschikbaar. Die request moet nog steeds afgehandeld worden door iets dus waarom een PUT of DELETE zomaar kwaad zou kunnen vat ik niet helemaal. In je script die een dergelijke request afhandelt dien je natuurlijk de userinput te valideren...

[T_E_O]

Of je het nou via een PUT of een POST naar binnen werkt maakt denk ik weinig uit als je beide door je PHP-script af laat handelen.

Wat wellicht nog leuk is om op te nemen is 'n methode om de herkomst van zo'n update-bestand te verifiëren mbv. een public/private key pair. Voor onze applicatie wordt bij ieder update-bestand op 'n lokale machine met behulp van de private key een handtekening geplaatst. Nadat bij de klant het bestand is binnengehaald wordt met de hardcoded public key gecontroleerd of de handtekening met onze private key gemaakt is.

Op die manier voorkomen we dat 'n gekraakte webserver gevolgen kan hebben voor de installaties van onze software bij de diverse klanten. Nou hebben onze klanten ook wat gevoeliger informatie in dit pakket zitten dan in het gemiddelde CMS en zijn ze er ook wat meer van afhankelijk, maar gezien de kleine hoeveelheid code kan het best de moeite zijn om iets dergelijks te implementeren.