[development] RFC: letting modules phone home to check for new releases

[Sammy Spets]

You're saying I called it automatic, when I didn't!

We're talking about the same thing. My example is a way to ensure the
update procedure is legitimately run by the admin user and thus can use
the webserver process uid to replace files (which is necessary for the
files to be usable by Drupal). It's an example and not a suggestion or a
"do it this way".

Aside from all that there is a need to reduce downtime of a site. 
Putting the site into maintenance mode and then downloading the
replacement modules increases the downtime. Would be nice if the
solution ends up with a way to download updated modules before going
into maintenance mode.

So an addendum to Derek's workflow:

1) download updated modules into a temporary filesystem location
2) put site into system maintenance mode
3) backup DB and filesystem
4) run some "upgrade.php" script that unpacks the modules into place
5) run update.php
6) test to make sure life is good
7) leave system maintenance mode and return to live operation.

Cheers,

-- 
Sammy Spets
Synerger Pty Ltd
http://synerger.com

On 21-Nov-06 18:11, Derek Wright wrote:
> 
> On Nov 21, 2006, at 5:54 PM, Sammy Spets wrote:
> 
> >The file must be manually created prior to the upgrade though a way  
> >to generate the file is provided.
> 
> you lost me. ;)  if the admin has to manually type in the random key  
> to allow the "automatic" update to do its thing, what's the point of  
> calling it "automatic" and giving the website filesystem write access  
> to clobber itself?
> 
> why not just say "human intervention is REQUIRED"?
> 
> 1) put site into system maintenance mode
> 2) backup DB and filesystem
> 3) run some "fetch_latest.php" script that knows all your installed  
> modules, downloads the updated tarballs, unpacks them into place, etc
> 4) run update.php
> 5) test to make sure life is good
> 6) leave system maintenance mode and return to live operation.
> 
> i'm happy to see steps #2 and #3 as automated as possible, but #3  
> should definitely run as the high-privileged admin's uid, not the uid  
> of the webserver process itself.
> 
> anything less would be uncivilized... ;)
> 
> -derek
> 
>