Support » Alpha/Beta/RC » Plugin update fail w/ libssh2; succeed w/ SFTP-support plugin active

  • Resolved dlmeyer

    (@dlmeyer)


    The current betas/RC versions fail install core updates correctly but fail on plugin updates when libssh2 support is being used. When the “SSH SFTP update support” plugin is activated, the plugin updates complete normally.

    This is for a test site operated on the same host-systems where multiple WP sites (versions 4.2.x) are operating successfully without the SFTP-plugin support, and successfully autoupdating plugins. In fact, the test-site I’m seeing this behavior on worked fine through the 4.2-Beta cycle. This problem was introduced in the 4.3-Alpha/Beta cycle…

Viewing 15 replies - 1 through 15 (of 15 total)
  • Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Advisor and Activist

    Can you check what version of libssh2 you’re using?

    Thread Starter dlmeyer

    (@dlmeyer)

    Our systems have libssh2-1.4.3-8.el5.remi.1 packages installed. This should be the 1.4.3 version of libssh2.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Advisor and Activist

    This is likely because your curl SSL libs are out of date. There’s a libssl in curl that most of us patched for Poodle and other stuff, but that doesn’t mean we did everything. Since we’re httpsing more things in 4.3, that makes a bit of logical sense.

    Thread Starter dlmeyer

    (@dlmeyer)

    Ummm… We’re talking the SSH-filesystem support here, not HTTPS/SSL…

    The same code and configuration works just fine when the “SSH SFTP update support” plugin is installed and activated, but reports filesystem permission errors when using the default WordPress SSH routines that rely on libssh2. And this works just fine in WP 4.2.x. (And was broken rather spectacularly throughout 4.1.x series…) This sounds like a regression to me.

    I would think any use of/reliance on curl would be separate from the SSH/SFTP filesystem functionality…

    Thread Starter dlmeyer

    (@dlmeyer)

    And besides… these are running on fully patched systems. Perhaps not bleeding edge, but WP should not be requiring “Bleeding Edge” support services.

    Dion Hulse

    (@dd32)

    Meta Developer

    Hey @dlmeyer,
    Can you post the exact error message you’re getting?

    In 4.3, ssh was changed to use the pwd() function rather than calling exec(‘pwd’) for compatibility with configurations which don’t allow shell access (ie. A chrooted environment).

    Imho, the plugin should be the preferred route for ssh upgrades, as it implements the ssh protocols in pure php rather than relying upon the extension (which in my past experience, breaks often with php/libssh updates).

    It’s unlikely any introduced bug here will be fixed in 4.3 unless you’re able to provide exact details of what broke and how.

    Thread Starter dlmeyer

    (@dlmeyer)

    The message I receive when attempting to update a plugin (Ithemes) follows:

    Updating plugin: iThemes Security
      Downloading update from https://downloads.wordpress.org/plugin/better-wp-security.4.9.0.zip...
      Unpacking the update...
      Installing the latest version...
      Removing the old version of the plugin...
      The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions. core, lang, lib, index.php, history.txt, readme.txt, better-wp-security.php, core/content, core/css, core/img, core/js, core/lib, core/modules, core/class-itsec-lockout.php, core/class-itsec-lib.php, core/class-ithemes-sync-verb-itsec-get-
    ...

    Interestingly, today’s core version failed with a [copy_failed_ziparchive] error… but this may be spurious. We’ll see if it repeats.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Advisor and Activist

    Stupid question…. You did try with all plugins off, right? Standard debugging for WP?

    Thread Starter dlmeyer

    (@dlmeyer)

    RC2-33615 eventually installed OK when retried.

    However, attempts to install plugins now seem to stop responding during the installation — all browser output just stops, and just sits there. Meanwhile, I can watch the sftp-logs roll as files are being written, then a slew of “opendir” with a “//” in the path, then nothing for 60 seconds, then the SFTP session is closed.

    Now looks like the upgrade process is dying…

    I’ve verified that I can successfully add/install a new plugin (Hello Dolly) manually, and can also successfully delete it.

    I was able to deactivate and delete the plugin that needed updating. However, an attempt to install it never completed in the browser, yet the SFTP logs showed the installation progressing through cleanup of the subdir under ‘wp-content/upgrade/’… The installation page sat for 10 minutes before I gave up on it — Returning to the plugins page showed the plugin installed and ready to activate. Activating it was successful.

    So, I now have a fully updated beta site, but problems are still happening during plugin updates & some installs.

    Thread Starter dlmeyer

    (@dlmeyer)

    Actually, no — I’m not disabling all the plugins. This is supposed to be auto-updating. And it’s not. That’s what I’m testing, and reporting results.

    And it’s kind of hard to run the nightlies and auto-updates if I deactivate the Beta Tester and Update Control plugins…

    Thread Starter dlmeyer

    (@dlmeyer)

    @dion: If “the plugin” is the “preferred route”, then why is it a plugin? It should be incorporated and managed with the core code.

    I’ve been supporting WP-based sites with web-updates through SSH channels since WP 3.4 or so.

    In WP 4.1.x, that support was broken spectacularly. I was forced to install the “SSH SFTP Update support” plugin (a kludge, in my eyes…) for my clients to re-enable web/auto-updates.

    Whatever the problem was, was fixed during the 4.2 beta series. Auto-updates magically started working again… (And I noticed this on the very site I’m working with here.) This held through the 4.2.x series.

    Now, while normal function was OK during 4.2, they had to update the SSH SFTP plugin for compatibility with 4.2. There were bad releases of this, and that broke the sites that were still using it from 4.1.x, upsetting clients. I had to disable that plugin to work through it.

    Now, the basic support using libssh2 is broken again in a different (less spectacular) fashion here in 4.3 beta/RC series.

    In my experience, I cannot see the “SSH SFTP update support” plugin as a reliable alternative, either. (Especially when managed and tested separately from core…)

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Advisor and Activist

    Actually, no — I’m not disabling all the plugins. This is supposed to be auto-updating. And it’s not. That’s what I’m testing, and reporting results.

    Ah you missed my point 🙂 What if it’s one of your currently active plugins that are breaking it? That’s why we always tell people to re-test with all plugins off and using the default theme. Narrow down and be absolutely sure it’s not something derpy we did. (It’s almost always something I did…)

    Dion Hulse

    (@dd32)

    Meta Developer

    @dlmeyer My apologies, I didn’t see the replies until today.

    The only change between 4.2.0 and trunk (4.3 betas) is this:
    https://core.trac.wordpress.org/changeset?old_path=%2Ftags%2F4.2%2Fsrc%2Fwp-admin%2Fincludes%2Fclass-wp-filesystem-ssh2.php&old=33619&new_path=%2Ftrunk%2Fsrc%2Fwp-admin%2Fincludes%2Fclass-wp-filesystem-ssh2.php&new=33619&sfp_email=&sfph_mail=

    Replacing the usage of $this->run_command('pwd') with ssh2_sftp_realpath( $this->sftp_link, '.' ); – If that was broken, you’d get a “Cannot locate folder wp-content” or similar error.
    The fact you’re getting file permission errors sounds like it’s literal file permission errors, or something else has changed in your configuration.

    In my experience, I cannot see the “SSH SFTP update support” plugin as a reliable alternative, either. (Especially when managed and tested separately from core…)

    I think you need to reevaluate that, although the plugin isn’t developed by the WordPress Developers, it works and is arguably better than the SSH Extension support WordPress offers. It’s not going to be merged into core though as it’s dependencies are a bit too much for WordPress.
    I’d personally prefer to move the SSH Extension support to a plugin (which may or may not happen) instead, it’s functionality that over 95% of the WordPress users do not use.

    Dion Hulse

    (@dd32)

    Meta Developer

    Further investigation points to the problem here being that WP_Filesystem_SSH2::is_writable() is returning false for these files, due to https://core.trac.wordpress.org/changeset/32854

    Unfortunately I’m not sure why that would be the case, but I suspect it’s due to the way PHP is interpreting the file permissions on the files. @dlmeyer if you’re able to do any digging as to why that would be the case, it’d be appreciated.

    I’m seeing the same thing on 4.3 on my sites now. There was a bug in “SSH SFTP update support” plugin for a while, so I moved away from that, just tried installing it again and that fixes this issue again.

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Plugin update fail w/ libssh2; succeed w/ SFTP-support plugin active’ is closed to new replies.