By Wolf_22 on

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.

Edit: Provided clearer information.

⋅ Categories: Drupal 7.x

Comments

VM’s picture

VM commented

the question posed is better suited to the 'post installation' forum as it does not pertain to upgrading drupal. Please edit and move the post. Thank you.

Wolf_22’s picture

Wolf_22 commented

Thanks for the input, VM. Moving now...

Wolf_22’s picture

Wolf_22 commented

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.