How to handle automatic updates?

[G.Schuster]

Hi folks,

I'm currently thinking about an update system that does nearly everything without the interaction of the user.
Therefore I thought about an update server that holds my files to which the scripts can connect.
No problem so far.
Where I see a problem is when it comes to the patching process.
Would you just copy the complete files over the old ones or would you try to patch them only with the changes?
Second option would save very, very much bandwidth - frist one would be much easier to implement.

I would prefer real automation, meaning I upload the complete files, the script creates the patch files and makes them available to the scripts runing on clients hosts.
I looked at xdiff for PHP but at the moment am not able to install it for testing - does it support the creation of patch files that can later be merged into the old files?
Any other ideas/suggestions on this?

Thanks in advance!

[kyberfabrikken]

Is using SVN out of the question? You can simply checkout the repository at the production server, then run an svn update once in a while.

[G.Schuster]

Yes, it's out of question - sadly.
It needs to be a pure PHP solution to integrate it in an application framework with a licensing system.
Some apss will work offline and therefore I want to provide the patch files on CD to apply them locally.

[stereofrog]

But the update server is under your control? Can you install svn on it? If yes, you can do svn diff on the update server and send a patch to the client. The client must only know its revision number and be able to patch itself (not a problem on most unixes, but even if you'd need to write your own "patch" in php it's considerably simpler than diff).

[jplush76]

I've done this same thing in my previous company. We had a central "downloads" server that held the versions of our applications. At startup or a defined period of time the app would make a soap request with the current version # (you can use rest or adhoc) to the update server, if the versions were different it would respond to the request with an update needed notice.

The app would then make another request to the download API on the server, suck down the zip file containing the patches and MD5'd it against the response's hash so we know we had the right file and in tact. So now we have our new patch file sitting in a temp directory. Simply unzip it in php and start replacing the files. The files should unzip to the same structure as your app or you'd need to have some file to location mapping structure to read in.

It's still being used to this day flawlessly for patching files. It could be done in the background or making the user accept the upgrade.

[G.Schuster]

@jplush: That's the easy way that I will go if I can't find a solution for really patching files in parts, not in whole as it is when just copying them.

@stereofrog:
Yes, the updateserver will be under my control - but I want to avoid SVN.
Writing my own "patch" routine that receives a command like "replace line X in file Y with 'print Hello world'" is exactly what I'm looking for - but I have no idea where to start searching for infos on such a patch structure.
The only thing my frist searches came up with was xdiff ( http://www.php.net/xdiff )
That sounded reasonable to me becaus it can generate a diff and merge 2 versions of a file.
What do you think about it - should it be possible? Or has anybody had some experiences with it?

[Jasper Bekkers]

The patch systems sounds great at first but can become unreliable whey you've applied patch after patch after patch. It might be better to just send a gzipped version of the changed files or the complete package. And there are a couple of other scenarios I haven't heard, how are you going to handle clients that want to downgrade after the update because it broke there online webshop. Obviously they can't wait for a new release. And how are you going to handle database changes? How are you going to handle modifications made by the client?

[stereofrog]

Yes, the updateserver will be under my control - but I want to avoid SVN.

why?

Writing my own "patch" routine that receives a command like "replace line X in file Y with 'print Hello world'" is exactly what I'm looking for - but I have no idea where to start searching for infos on such a patch structure.

google for "unified diff" might be a good starting point.

[Dr Livingston]

Don't reinvent the wheel

[G.Schuster]

For the unreliability I could probably build a "patch counter" - every X patches it should copy the complete file.

>how are you going to handle clients that want to downgrade after the update
Downgrading seems to work the same way with xdiff, you only need to specify the patched file, the patch and XDIFF_PATCH_REVERSE

>And how are you going to handle database changes?
Database changes will be specified in a XML file that is executed by my script.
For reversion I think I'll write something that builds an "undo query" from tghe parsed XML.

>How are you going to handle modifications made by the client?
This is a point I'm not clear about.
But I think in the main scenarios there won't be any due to the fact the most scripts are encoded.
For other files I think I'm going to give a warning and explaining what has to be changed.

@stereo
>why?
Because it, as far es I can see, doesn't support _this_ kind of automation that I need.

>google for "unified diff"
Thanks, that will keep me reading some hours.

@Dr. L
Well - if there's nothing that really suits my needs I'll have to optimize the wheel.
If I missunderstood your broad hint and you have a complete wheel let me know & see.

[ultimazer1]

Hey guys,

I posted a thread about exactly the same issue a few days ago in the general php forums:
http://www.sitepoint.com/forums/showthread.php?t=484257


@jplush76:
How would transfer the zip file from your update server? Using FTP functions (because these functions are sometimes disabled by providers)? This would mean writing your ftp login data (für the update server) in your php code in plain text which might not be a good idea.
Otherwise, the way you described your solution is just what such an update function should look like.

Cheers, Florian

[Czaries]

@jplush76:
How would transfer the zip file from your update server? Using FTP functions (because these functions are sometimes disabled by providers)? This would mean writing your ftp login data (für the update server) in your php code in plain text which might not be a good idea.

You wouldn't have to use any FTP functions - you can retrieve the file with an HTTP request and download it to the local server. If you used FTP, you would have to setup a completely separate FTP on a different account or subdomain that would hold only the finished package downloads. You could even put the files in the server's anonymous read-only FTP account and you wouldn't have to worry about login details at all. There are many ways that this can be perfectly okay and safe to do

[Czaries]

Yes, it's out of question - sadly.
It needs to be a pure PHP solution to integrate it in an application framework with a licensing system.

So I think the issue here (with why you can't use SVN) is that you need to check their license first to make sure they are allowed to get the updated files? Is that correct?

[G.Schuster]

Yes, that's it.
But that's the smaller problem, my main problem is the patching itself.
But I'll give xdiff a try, if it doesn't work as expected I'll use complete files.
For the communication I'm going to use SOAP because it suites perfect for license checking and other things that have to be done before an update can be run.

[kyberfabrikken]

So I think the issue here (with why you can't use SVN) is that you need to check their license first to make sure they are allowed to get the updated files? Is that correct?

Yes, that's it.

In that case, can't you give each customer a login to the repository server, and then revoke the login when the license expires? Or do customers license a certain number of revisions?

[G.Schuster]

It's a very fine graned licensing system, some buy only module A while some buy B,C and D etc.
There's no way around many, many different repository setups and because of this PHP is the more practical solution.

[mr.vain]

I have the same problems and while searching on "unified diff php" i found phppatcher. http://sourceforge.net/projects/phppatcher
But it seems, that there is no good os-library out there, for such proposes. Anyone working on such a thing?

XDiff is not a solution for me, because the client webservers usally don't have that diff extension loaded to merge the diffs.

I'm currently looking into some Boards and how they applied their automatic updating. Like simplemachines or woltlabboard. So this is a link to Documentation of the Patching-System of WoltlabBoard / Woltlab Community Board. Maybe that inspires on building a update-package handler. http://wcfdoc.chr-fritz.de/com.woltl...ionPlugin.html