Posted by Tarraccas on August 2, 2011 at 7:00am
3 followers
Jump to:
| Project: | Drupal.org Project applications |
| Component: | module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Simple module that updates the Drupal core installation to the latest version.
Comments
#1
I don't think this is really a good solution to the problem.
1. It simply untars the files rather than using any sort of local sftp/ssh/ftp connection - this encourages unsafe file/directory permissions - see http://drupal.org/node/244924
2. There is no rollback mechanism in case the update fails half way through so it can leave sites broken
3. I don't see a batch mechanism, on an overloaded server this could just time out, right?
4. It doesn't use an out-of-channel method to confirm the md5 of the file making it vulnerable to dns poisoning attacks
From a general quality perspective:
It needs a README.txt
The comments don't follow capitalization/sentence requirements
There is an XML representation of version information that the update module uses that would be a bit cleaner/more reliable than parsing the HTML of the Drupal project page.
#2
Needs work for at least the second parts. I hope you will consider the first parts and whether this is a task you really can dedicate yourself to solving before making this a full project becuase those other issues also need to be solved.
This is potentially a super-valuable module, but only if done properly.
#3
1. The module downloads and untars the Drupal archive the same way I do on servers via SSH to update Drupal installations. The only directory it may have a problem with seems to be sites/default, the settings.php file is not contained within the Drupal archive so is not updated and it remains read-only.
2. This module is designed to do one thing: update Drupal with one mouse click. Other modules exist to handle backups and rollbacks. I prefer Backup Migrate. It's assumed that a site admin will have the wherewithal to take necessary precautions, including putting the site into maintenance mode. If this module fails to update Drupal automatically it will typically throw an exception. If the exception cannot be remedied via the option provided with the module then it's easy enough to manually update the Drupal installation files. In development, it did update only part of the files prior to throwing an exception and the installation, while incomplete, remained functional. This may not always be the case but it's always easily fixed by doing what we already do now to update Drupal without such an auto update utility.
3. An update could potentially timeout, yes. See #2 above.
4. There is potential for dns poisoning attacks, yes. There is no more authentication than occurs by one manually browsing to drupal.org and downloading the latest Drupal archive.
5. What is suggested content for the README.txt file?
6. /* comments */ or // comments require sentence capitalization?
7. The latest major versions of Drupal are always posted to the Drupal project page and they've followed the same pattern for years. It's easy enough to update one regular expression to match a new pattern and to update these changes via the update module, assuming that a) this module remained relevant at that point and b) that it continued to use the same admittedly crude update mechanisms. I assume that if the Drupal project could be updated via the core update module that it would be (and it should be - auto update is a fundamental component of just about all modern software). This module merely emulates and automates the steps one manually takes to update Drupal.
Your method suggestions are taken into consideration and if anyone else wishes to contribute to making them happen (or, better yet, pushing this functionality to the core) they are more than welcome to help make it so as I, understandably, have commitments to my clients first and foremost and this module is just a tool to make meeting those obligations easier given the rapid Drupal update cycle. To that end, I believe it could be useful to many others as well and, seeing as this is open source, I'm open to a team effort in order to meet more than just my own expectations. Regardless, this basic functionality MUST exist in Drupal and be simple to use one way or another.
#4
Except that you are logged in as you running it as your user and your unix groups while the server is running it as the webserver user with the webserver groups.
I'm skipping over a lot because the above point is pretty fundamental.
5. See http://drupal.org/node/447604
6. Yes.
#5
Users and group permissions are understood. It is assumed that Drupal has write permission to it's own installation which it must in order to function. If that is not the case then the simple method this module employs may not work and that will be made evident relatively quickly.
The current state of development reflects a minimal amount of resources spent in order to achieve it's stated objective, which it does thanks in large part to the Archiver functions built into Drupal 7. If and when it proves necessary that the functionality of this module utilize the batch and authorize APIs and that the functionality this module provides continues to remain relevant then that will be done. I fully and reasonably expect this functionality to become part of the Drupal core as there is no reason for it not to. I briefly considered hacking/patching the update module itself to provide for the Drupal project but this module proved to be a faster, more easily maintainable solution in the interim.
#6
This is just not true nor recommended. In my first comment I posted http://drupal.org/node/244924 - please read it.
#7
No activity in several months. Reopen and set the status to "needs review" if you are still pursuing this application.