Drupal 7.x and the Update Manager for Module Updates

I work with 2 web hosts: my own personal web host and one where I work.

  • The Drupal installation from my personal web host has no problems with the Update Manager at all and makes updating modules a breeze. It runs fine without being prompted to enter any FTP connection settings on the authorize.php page. It installs everything without needing to access the server directly with something like an FTP/SFTP/SSH client.

  • The Drupal installation from my work, however, forces me to enter FTP details on the Update Manager screen, which will never work since FTP isn’t even enabled on that system (in a lazy effort to increase security). Ironically, “FTP” is showing as the only option in the Update Manager.

Yes, I can log directly into the system via WinSCP or some other FTP/SFTP/SSH client to do updates to modules, etc. but why would I want to do that when I should be able to use the Drupal UI to handle this? Besides, doing things “manually” like that only increases the margin of error, which I would prefer to avoid whenever possible.

The system at work currently uses PHP 5.4.16. The current SSH implementation on the system appears to be libssh2/1.4.3 (I found this via phpinfo().) From what I understand from this tutorial, SSH can be used as an option in the Update Manager by enabling libssh2 but since the server already has that enabled, I’m not sure why SSH isn’t showing as an option in the Update Manager unless it has to be a version higher than 1.4.3?

Any insights into this would be appreciated. Thanks in advance.

My guess is a permissions issue. If the web server’s user isn’t the owner of the folders it’s trying to write to, the permissions are set up to not allow it to directly write to them; so it asks you for FTP access to circumvent the problem. If you make the server (www-data or apache or w/e it is for your server) the (recursive) owner of the /sites directory, that’d probably work.

Something like:

sudo chown  -R www-data:www-data /var/www/drupal/sites

Or whatever your file path / user / etc is.

Disclaimer though, especially if this is a live production site, I have no idea what your permissions structure is. You’d need to be sure that the user you login as or ftp in as for other things is in a group with access to those files as well, etc… in other words, know what you’re doing before you make blanket permissions changes :smiley:

Anyway, TL;DR it’s likely a permissions issue.

My guess is a permissions issue.

What makes you guess that? Is there any way I can track down which specific folders would cause an issue like this if it is a permissions issue?

What makes you guess that?

I’ve seen the issue before, myself in Drupal 7 (and an identical issue with WordPress just last week, too, on a side project), and read support posts and such of similar cases, and they were all permissions issues? Drupal, by default, will attempt to do the operation itself, and then present the FTP option if it can’t, so you’re pretty limited on causes of that behavior, as far as I know.

Is there any way I can track down which specific folders would cause an issue like this if it is a permissions issue?

You’d want to check permissions on the wherever you are storing your modules. In the project I’m on right now, that’s /sites/all/modules/contrib - or any of the folders in that chain. Obviously on your project that might be different, but you’re looking at the directories in the file path to where you store contributed modules. Check to see who is the owner, and which group, and what the permission levels are. I’d start with those. I’d have to research whether Drupal needs access to any other folders beyond the ones it is dumping modules into.

I’m currently keeping contributed modules in /net/web/foobartest/sites/all/modules. Looking at the group and ownership of that location, I see that it’s associated with the “users” group and is owned by “wolf22” (my account on the system). The sys admin prefers to use ACLs in the system for juggling permissions in situations like this (for obvious reasons), so I tried to fix all of this with the following setfacl commands:

setfacl -R -m d:u:wolf22:rwx,u:wolf22:rwx,d:u:apache:rwx,u:apache:rwx /net/web/foobartest/sites/foobartest.blah.com

setfacl -R -m d:u:wolf22:rwx,u:wolf22:rwx,d:u:apache:rwx,u:apache:rwx /net/web/foobartest/sites/all/modules

setfacl -R -m d:u:wolf22:rwx,u:wolf22:rwx,d:u:apache:rwx,u:apache:rwx /net/web/foobartest/sites/default

I tried re-running the Update Manager after each setfacl, and every time I tried, it still wouldn’t work and continued to give me the FTP settings screen each time (which it shouldn’t do).

(Based on what I see with getfacl, it looks like apache has rwx on all the above…)

Doing more research…

Okay, so I figured it out… It was all about ownership. :smile:

The initial admin/modules/update page shed some light on all this. By looking at that page, you can see the words, “Updating modules and themes requires” and how it’s appended to a variable. A static part of a conditional string… So, taking this part of the string and using GREP to find where it gets printed, I eventually stepped into the core module found at modules/update/update.manager.inc. The specific string itself exists inside of logic that only gets tripped if either nothing exists in the $available_backends array or else if update_manager_local_transfers_allowed() returned a true evaluation (which is where this whole thing was breaking down to begin with).

Inside that function is the following code:

function update_manager_local_transfers_allowed() {
  // Compare the owner of a webserver-created temporary file to the owner of
  // the configuration directory to determine if local transfers will be
  // allowed.
  $temporary_file = drupal_tempnam('temporary://', 'update_');
  $local_transfers_allowed = fileowner($temporary_file) === fileowner(conf_path());

  // Clean up. If this fails, we can ignore it (since this is just a temporary
  // file anyway).
  @drupal_unlink($temporary_file);

  return $local_transfers_allowed;
}

…and this is where everything began to make sense.

The evaluation between fileowner($temporary_file) and fileowner(conf_path()) (or Linux User IDs) led me to another walk down to my sys admin’s office to request an ownership change of the individual site directories from what was my username to instead be “apache.” After he did this, everything worked as expected.

It isn’t very safe to be installing modules directly on the production server without first testing locally. In fact it is VERY DANGEROUS given all the magic in Drupal.

A distinction can be made between production server and production instance:wink:

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.