My site has functionality that requires SSH2 functions to control remote cloud servers that are created in response to a varying workload. I have tried installing using yum on the new server but apparently there's a conflict with the php 5.6.6 installation or something:

$ sudo yum install php-pecl-ssh2.x86_64
[sudo] password for sneakyimp: 
Resolving Dependencies
--> Running transaction check
---> Package php-pecl-ssh2.x86_64 0:0.12-1.el7 will be installed
--> Processing Dependency: php(zend-abi) = 20100525-64 for package: php-pecl-ssh2-0.12-1.el7.x86_64
--> Processing Dependency: php(api) = 20100412-64 for package: php-pecl-ssh2-0.12-1.el7.x86_64
--> Running transaction check
---> Package php-common.x86_64 0:5.4.16-23.el7_0.3 will be installed
--> Processing Conflict: php56u-common-5.6.6-1.ius.centos7.x86_64 conflicts php-common < 5.6
--> Processing Conflict: php56u-gmp-5.6.6-1.ius.centos7.x86_64 conflicts php-gmp < 5.6
--> Finished Dependency Resolution
Error: php56u-gmp conflicts with php-common-5.4.16-23.el7_0.3.x86_64
Error: php56u-common conflicts with php-common-5.4.16-23.el7_0.3.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Can anyone suggest an approach to resolving this problem? It seems pretty sketchy to me that I would have php56 installed but php-common-5.4.16-23.el7_0.3.x86_64 is also installed on the same machine.

    Thanks for your response.

    I've tried searching the package repository for any package like that but the search results return nothing:

    yum search php56 | grep -i ssh
    yum search ssh | grep -i php56
    $ yum search php56-php-pecl-ssh2
    Warning: No matches found for: php56-php-pecl-ssh2
    No matches found
    [jadams@valunite-dev controllers]$ yum search php56u-php-pecl-ssh2
    Warning: No matches found for: php56u-php-pecl-ssh2
    No matches found
    
      NogDog;11045745 wrote:

      This article uses a slightly different approach that might be worth a look: http://safesrv.net/getting-started/installing-php-ssh2/

      Hmmmmm. That looks interesting, and would probably work. I'm tempted to install it via PECL:

      pecl install -f ssh2

      However, I wonder how tricky it is to get security updates installed? The advantage of using a package installer is that the package maintainers take care to deploy security patches and bug fixes and such.

        I installed SSH2 on our Centos servers at work maybe a year ago, but don't remember having any version problems then. I did have a similar issue as you had but with a couple different extensions recently, but was able to resolve it by prefixing the applicable PHP version, thus my first thoughts here. Maybe there's a way to upgrade that php-common thingy from 5.4 to 5.6 first?

          NogDog;11045777 wrote:

          I installed SSH2 on our Centos servers at work maybe a year ago, but don't remember having any version problems then.

          The issue is apparently due to the fact that someone upgraded the default CentOS 7 PHP release (5.4.x) to PHP 5.6.6. I'm not sure how they did this exactly, but it I think CentOS offers a package for it. Apparently this is the source of the issue: that no one has bothered to make sure ssh2 works with PHP 5.6.6 for CentOS. IMHO, PHP 5.4.x is way too old nowadays. Apparently it's supposed to reach end-of-life around September. I know CentOS plans to patch it beyond that, but still....OLD.

          NogDog;11045777 wrote:

          I did have a similar issue as you had but with a couple different extensions recently, but was able to resolve it by prefixing the applicable PHP version, thus my first thoughts here. Maybe there's a way to upgrade that php-common thingy from 5.4 to 5.6 first?

          I think upgrading php-common is the way to go. I'm thinking I might foist that off on the hosting company's guys. They're the ones who installed php 5.6.6.

            sneakyimp;11045785 wrote:

            IMHO, PHP 5.4.x is way too old nowadays. Apparently it's supposed to reach end-of-life around September. I know CentOS plans to patch it beyond that, but still....OLD.

            I know some repositories still have 5.3 as the default install! It came out in 2009 for the record.

              Derokorian;11045791 wrote:

              I know some repositories still have 5.3 as the default install! It came out in 2009 for the record.

              I know linux is complex and all, but that's ridiculous. I have an old version of Ubuntu and it has 5.3 but they somehow manage to keep it limping along with new features. I think this may have something to do with compatibility. I.e., I think linux distros like to keep the same minor version of PHP for the lifetime of their *nix distro.

                sneakyimp;11045795 wrote:

                I know linux is complex and all, but that's ridiculous. I have an old version of Ubuntu and it has 5.3 but they somehow manage to keep it limping along with new features. I think this may have something to do with compatibility. I.e., I think linux distros like to keep the same minor version of PHP for the lifetime of their *nix distro.

                And there's no reason for that, 5.6 works just fine on Ubuntu 10.04 (when compiled manually, since its not in Aptitude). Also, look at the full version number in that distro, tell me if the fix version is actually up to the last version of 5.3 that was released (hint: its probably not)

                  William Palfreman wrote:

                  [link]When I find myself with system trouble,
                  Lib incompatibilities,
                  There are words of wisdom, BSD.
                  And in my hour of darkness, there is only one CVS tree
                  /usr/src, make update --- BSD.

                  BSD, BSD, BSD, BSD,
                  Whisper words of wisdom,
                  "BSD."

                  And for the broken NT servers, leaking kernel memory,
                  There will be an answer, installing BSD
                  For though there is GNU Parted, resizing Linux directories,
                  You just need one disklabel for BSD.

                  BSD, BSD, BSD, BSD,
                  Whisper words of wisdom,
                  "BSD."

                  And when the comms room's darkened, LEDs still shine their light on me,
                  uptime(1) > 2 years on BSD.
                  I wake up to the sound of servers, coolers humming merrily,
                  Crunching starry wisdom, with SETI ...

                  BSD, BSD, BSD yeah BSD
                  Solaris is no answer, not a BSD
                  BSD, BSD, BSD yeah BSD
                  Whisper words of wisdom,
                  "BSD..."

                  Somewhat altered for phrasing, but no less genius,

                  😉

                    5 days later
                    dalecosp;11045825 wrote:

                    Somewhat altered for phrasing, but no less genius,

                    😉

                    :glare:
                    I think you've posted this before. I'm curious how BSD manages the never-ending march of progress of php versions and the shifting incompatibilities of libraries and so on.

                    So I'm faced it seems with either a manual install via PECL or compile-from-scratch OR I need to find some way to update these conflicting libraries:

                    --> Processing Conflict: php56u-common-5.6.6-1.ius.centos7.x86_64 conflicts php-common < 5.6
                    --> Processing Conflict: php56u-gmp-5.6.6-1.ius.centos7.x86_64 conflicts php-gmp < 5.6

                    Any thoughts? The reason I like to use these package installers is because I just lack the know-how to keep track of the millions of dependencies so I figure I'd better leave it up to the pros.

                      OK the rackspace tech support guys have taken care of this. Issue not solved but I'm closing it down anyway.

                        Write a Reply...