Wouldn't it be great if...

Release Monitor gave you another option to 'Download to Server' which downloaded the new version module to the server. Release Monitor, or another module, could then unpack the tarball, back up the old module in a module backup folder, and put the new module in the correct place.

This would be a great time saver in those really mundane daily tasks of a typical drupal dev. With a bit of help from drupal.org, module could also provide a list of all available modules (installed or not), and the site admin could select which ones to download and install -- another great timesaver. With a bit more help from drupal.org, site devels could even download the modules to their site from a simple form & link on drupal.org/project/PROJECT_NAME pages! :)

How's that for efficiency? Release Monitor probably isn't the right place for all of these features, but it might be a good starting point to discuss and think about them...

Comments

meba’s picture

meba commented

This has been discussed many times ago and it is not as simple as it seems, because security issues...

Bevan’s picture

Bevan commented

Are the security issues such that it would make a bad SoC project?

douggreen’s picture

douggreen commented

Thanks for the suggestion! I'll leave the thread open for more discussion, but as of today, I'm not inclined to implement it. The auto-download and install is interesting, but problematic, and of little value to my personal work habits and client installs.

I think that the more critical next step is to make releasemonitor less CVS and more project aware and to get these changes into project.module and Drupal 6 core. I'm not sure if I'll have time to do this, but it is in my personal battle plan for Drupal 6. When this gets implemented, it will probably include a command line update to replace the current CVS practice.

Here are a couple of relavent discussions:

The security problems I see are:

  1. The delay associated with having to manually find and download patches actually helps insure that a malicious update isn't spread too quickly.
  2. We must insure that there is no DNS/IP spoofing when calling home to drupal.org.
  3. We don't want to touch drupal.org too often, creating DoS attacks, by downloading updates that don't actually get installed
  4. I see the advantage to a button to download directly to the server, but think that installation should almost always involve manual intervention.

All of these are solvable, but it comes down to priorities and time.

Bevan’s picture

Bevan commented

I wasn't aware this had already been discussed. Just to let you know I've added this idea to the current draft list of google SoC proposals for drupal: http://drupal.org/node/119997

I'm sure there are other security issues that we haven't thought of too.... I wonder if this is a fairy tale idea?

jacauc’s picture

jacauc commented

Module installer already exists: http://drupal.org/project/module_installer

douggreen’s picture

douggreen commented
Status: Active » Closed (won't fix)

I'd be happy to work with a SoC person on this and/or work with the new module_installer developer. But as I've already stated, there are some security concerns and I'm not sure that these have been properly addressed by module_installer.

seancharles’s picture

seancharles commented

http://drupal.org/node/127861

Any use ? I'd love to help make Drupal 5 easier to use!