Php updating tool

[Verwijderd]

Beste tweakers,

Ik ben momenteel bezig met een CMS te bouwen. Deze moet zo gemaakt worden dat ik van afstand het kan updaten met de nieuwste bugfixen.

Mijn vraag is aan jullie hoe ik php automatisch nieuwe bestanden download en deze vervangt met de oude. Zou dit bijvoorbeeld met samenhang van xml en curl_init moeten gebeuren? Ik zou graag de mogelijkheden willen horen hoe ik dit het beste kan doen. Omdat ik hier geen ervaring mee heb vraag ik het hier zodat ik me hier meer op kan verdiepen en ook meteen weet waar ik zal moeten beginnen.

Ik vraag dit expliciet hier omdat ik het niet kan verwoorden via google enz.

Alvast bedankt voor het reageren!

Groetjes,

Robert

[Manuel]

RobIII heeft zelfs het antwoord al gegeven: RobIII in "PHP update system"

[storeman]

Heb heb zelf verschillende methoden geprobeerd:

- Het CMS kan een zip ophalen en deze uitpakken
- Een PHP script verzend alle hashes naar de update-server. De update server vergelijkt alle hashes en stuurt alle gewijzigde bestanden terug
- Op het moment gebruik ik een CMD command om het te updaten vanaf een SVN server (export), werkt eenvoudig en doeltreffend.

[Gamebuster]

Alhoewel ik hier geen ervaring mee heb zou ik het als volgt toepassen:

Een update server en een update client maken.

De update server heeft een database met alle bestanden van iedere versie en de daarbij behoren MD5 hashes.
De update client gaat alle clientside bestanden langs en maakt een MD5 hash daarvan. Vervolgens stuurt deze updater alle MD5 hashes naar de update server met een request voor de update.

De update kijkt op basis van de MD5 hashes van de files van de client welke versie deze heeft en stuurt een pakket (een .zip archief o.i.d.) met nieuwe bestanden terug. De update client pakt dit zip archief uit en vervangt alle bestaande bestanden.

Op deze manier heb je dus een setup waarbij de bestanden automatisch updaten. Eventueel kan je dit uitbreiden om ook de database om te zetten naar de updates, door bijv. een extra script mee te sturen in het zip archief die eenmalig wordt uitgevoerd.

edit:
storeman hierboven was me voor.

edit 2:
lol, dubbeltopic. Volhoudertje

[ Voor 4% gewijzigd door Gamebuster op 19-09-2010 18:30 ]

[Verwijderd]

Manuel schreef op zondag 19 september 2010 @ 18:26:
RobIII heeft zelfs het antwoord al gegeven: RobIII in "PHP update system"

Ja dat zal misschien wel, maar het is belachelijk wat het besluit daarna is om het meteen te sluiten. Ik kan weinig met "eventjes zipje maken en sturen naar php bestand". Dat is gewoon een reactie om ervan af te komen. Dus ik vraag het nog maar, omdat het ook moeilijk is om een topic open te laten staan.

[Gamebuster]

Verwijderd schreef op zondag 19 september 2010 @ 18:29:
[...]


Ja dat zal misschien wel, maar het is belachelijk wat het besluit daarna is om het meteen te sluiten. Ik kan weinig met "eventjes zipje maken en sturen naar php bestand". Dat is gewoon een reactie om ervan af te komen. Dus ik vraag het nog maar, omdat het ook moeilijk is om een topic open te laten staan.

Waarom vraag je ons niet gewoon meteen het hele script te maken?

Zoek op google hoe je zipje maakt in PHP. Zoek op google hoe je bestanden stuurt. Zo zoek je per stap op hoe je alles moet doen en heb je uiteindelijk iets dat werkt.

Overigens wordt het denk niet gewaardeerd een topic te heropenen zonder toestemming wanneer exact hetzelfde topic 2 dagen eerder gesloten wordt.

[ Voor 16% gewijzigd door Gamebuster op 19-09-2010 18:33 ]

[Verwijderd]

storeman schreef op zondag 19 september 2010 @ 18:26:
Heb heb zelf verschillende methoden geprobeerd:

- Het CMS kan een zip ophalen en deze uitpakken
- Een PHP script verzend alle hashes naar de update-server. De update server vergelijkt alle hashes en stuurt alle gewijzigde bestanden terug
- Op het moment gebruik ik een CMD command om het te updaten vanaf een SVN server (export), werkt eenvoudig en doeltreffend.

Op mijn oude stage plek deden ze het als volgt:
Een user klikt op updaten. Deze vraagt een xml aan bij het desbetreffende cms welk versienummer het is en vergelijkt deze met het nieuwste nummer. Wanneer het versienummer ouder is dan de nieuwe zal deze een zip doorsturen die het cms extract en neerzet, waar nodig is. Maar hoe doen je deze goed extracten zonder dat je fouten in je script krijgen. Moet je bijvoorbeeld bepaalde permissions geven (777)??

[Gamebuster]

Verwijderd schreef op zondag 19 september 2010 @ 18:33:
[...]


Op mijn oude stage plek deden ze het als volgt:
Een user klikt op updaten. Deze vraagt een xml aan bij het desbetreffende cms welk versienummer het is en vergelijkt deze met het nieuwste nummer. Wanneer het versienummer ouder is dan de nieuwe zal deze een zip doorsturen die het cms extract en neerzet, waar nodig is. Maar hoe doen je deze goed extracten zonder dat je fouten in je script krijgen. Moet je bijvoorbeeld bepaalde permissions geven (777)??

Extract zip archive:
http://www.php.net/manual/en/ref.zip.php
http://www.php.net/manual/en/class.ziparchive.php

Verder kan je inderdaad gewoon 0777 permissions instellen. Ik weet niet precies hoe dat zit met de eventuele beveiligingsproblemen, maar met 0777 weet je in ieder geval zeker dat je scripts altijd werken

Permissions kan je instellen met de functie chmod:
http://nl.php.net/manual/en/function.chmod.php

[CodeCaster]

Verwijderd schreef op zondag 19 september 2010 @ 18:33:
[...]
Maar hoe doen je deze goed extracten zonder dat je fouten in je script krijgen.

Kijk, dit bedoelde RobIII dus waarschijnlijk. Specifieke vragen. Niet "hoe kan ik websites updaten", want daar zijn zeven miljoen miljard mogelijkheden voor.

Als je de voor- en nadelen van verschillende mogelijkheden wil bespreken kan dat beter in Software Engineering & Architecture. Graag zelfs, dat soort discussies zijn het leukste om te lezen en aan bij te dragen.

Als je tegen vreemde fouten aanloopt, zoek die dan op, en als je er dán niet uitkomt kun je hier in programming een topic aanmaken. Je hoeft echt niet iedereen read, write en execute-rechten op een zip-bestand te geven om dat uit te kunnen pakken.

[Verwijderd]

CodeCaster schreef op zondag 19 september 2010 @ 18:40:
[...]

Kijk, dit bedoelde RobIII dus waarschijnlijk. Specifieke vragen. Niet "hoe kan ik websites updaten", want daar zijn zeven miljoen miljard mogelijkheden voor.

Als je de voor- en nadelen van verschillende mogelijkheden wil bespreken kan dat beter in Software Engineering & Architecture. Graag zelfs, dat soort discussies zijn het leukste om te lezen en aan bij te dragen.

Als je tegen vreemde fouten aanloopt, zoek die dan op, en als je er dán niet uitkomt kun je hier in programming een topic aanmaken. Je hoeft echt niet iedereen read, write en execute-rechten op een zip-bestand te geven om dat uit te kunnen pakken.

Als ik dit zo lees vraag ik me af waarom dit dan een forum genoemd word. Ik ga ten eerste niet zomaar 50 posts lezen totdat ik iets gevonden heb. Dan lijkt dit forum meer op een FAQ toch? En ik vroeg me gewoon af hoe ik moest beginnen en wat mijn mogelijkheden daarvoor zijn.

[CodeCaster]

Verwijderd schreef op zondag 19 september 2010 @ 18:52:
[...]


Als ik dit zo lees vraag ik me af waarom dit dan een forum genoemd word. Ik ga ten eerste niet zomaar 50 posts lezen totdat ik iets gevonden heb.

Waarom verwacht je van mensen dat ze eerdere reply's kopiëren naar jouw topic als jij niet eens moeite in wil steken deze al gegeven antwoorden zelf op te zoeken?

Ah.

[ Voor 8% gewijzigd door CodeCaster op 19-09-2010 18:57 ]

[ReenL]

Schrijfrechten op de file is 2, leesrechten 4, 666 werkt dus ook altijd, afhankelijk van je server instellingen werkt 600 of 660 ook.
(De missende 111 betekend uitvoer rechten, die heeft apache nooit nodig op php scripts)

De vraag is of je dat wilt. Als er een foutje in je phpscript zit, zou de hacker die bestanden ook kunnen wegschrijven.

Veiliger zou zijn een cronjob instellen die elke dag de versie controleerd en eventueel een svn up doet, maar dat is natuurlijk wel weer lastiger in te stellen.

[MueR]

Verwijderd schreef op zondag 19 september 2010 @ 18:29:
Ja dat zal misschien wel, maar het is belachelijk wat het besluit daarna is om het meteen te sluiten.

Leesvoer:
[list]• Je topic is dicht en het is onterecht? Lees hier!
• Wij Tweakers doen elkaar altijd de groeten (nogmaals)
• De Quickstart
• Programming FAQ - Het FAQ/Beleid topic