As I have content marketers working regularly on Stage, and using Deploy regularly to push edits to Live, I upgraded Deploy to the latest greatest on my Dev environment for testing, and was trying to test deploying from the new version on Dev to to prior on Stage. Again, Dev is on 7.x-2.0-beta1 while Stage is still on 7.x-2.0-alpha3.
I get the following error on Dev with failure in deployment:
DeployAuthenticationException: Authentication error: 0 Error opening socket ssl://stage.myserver.com:443 in DeployAuthenticatorSession->deploy() (line 76 of /.../sites/all/modules/deploy/plugins/DeployAuthenticatorSession.inc).
I noticed that in DeployAuthenticatorSession there is this new bit of code in the Deploy function, which doesn't exist in alpha3, for fetching the context for the HTTP request (http://cgit.drupalcode.org/deploy/commit/?id=b68ce12).
Any pointers on this new bit, how it relates to the Deploy process, and whether the error is simply a mishmosh in Deploy module versions? I can't find a reference for it anywhere else.
Thanks!
Comments
Comment #2
capogeannis CreditAttribution: capogeannis as a volunteer commentedWent ahead and just upgraded the module in both environments - same error. Is there some new permission setting required on the server end for this beta1 version to not fail with that mentioned "Error opening socket ssl..." error?
Comment #3
capogeannis CreditAttribution: capogeannis as a volunteer commentedComment #4
capogeannis CreditAttribution: capogeannis as a volunteer commentedComment #5
capogeannis CreditAttribution: capogeannis as a volunteer commentedA bit more detail...
Turning on debugging in Deploy shows this error thrown:
I can see that the code change in the Deploy function now creates a context via stream_context_create explicitly setting ‘ssl’ as the protocol, which in my case throws the socket error during the communication attempt.
So in the end, the only difference is the inclusion of that ssl context into the options array:
I THINK the issue then is server side on the openssl settings ~ socket not opening because the SSL certification couldn’t be verified. Similar to:
https://www.drupal.org/node/1879970
http://tocacar.com/tag/sockets/
...but that's about all I've got ~ reaching.
Any info greatly appreciated if anyone has a pointer in this regard. Thanks.
Comment #6
Shiraz Dindarsame issue here with beta1. Did you end up finding a solution?
Comment #7
capogeannis CreditAttribution: capogeannis as a volunteer commentedSorry, was away on vacation. Nope, have not as of yet found a solution besides potentially commenting out the ssl context inclusions in the module - though I don't k now what the trickle down effect is on that, don't want to hack the module, and know it was included for a good reason.
I'd really like to know what I need to change on my architecture end for this to work. In the meantime, I have to hold off on upgrading the module.
Comment #8
dixon_What PHP version are you guys using? And are you using valid and signed SSL certificates or not?
I recall running into this issue as well during a recent PHP upgrade. And if I recall correctly a recent version of PHP 5.6 (I think) started being picky about valid SSL certificates. This could be the issue.
Comment #9
capogeannis CreditAttribution: capogeannis as a volunteer commentedGood point. I'll check with Op's here. Our architecture internally is pretty locked down - working with handcuffs on here. : )
I know they did do a PHP upgrade recently of these internal servers to PHP 5.4.42.
Not noticing any issues with the SSL, but I'll find out and report back.
Many thanks.
Comment #10
capogeannis CreditAttribution: capogeannis as a volunteer commentedLooks like our certs for the internal servers we develop on are self-signed, or something to that effect. Will be working with our guy here around mid January to look into that. Good chance that's it then? I'll update here after that.
Comment #11
bzaher CreditAttribution: bzaher commentedI ran into the same issue as well, and I can confirm that the deploy_verify_ssl variable is involved, shown in the second snippet in #5. Using the drush command
drush vset deploy_verify_ssl 0
solves the issue.I am using a self-signed certificate with PHP 5.5.9.
Looking at
'allow_self_signed' => !$verify_ssl,
, this code appears to be doing what it was intended to do. Setting deploy_verify_ssl to true prevents deployments using self-signed certs, and setting it to false allows them. Maybe there ought to be a UI setting to enable this?Comment #12
capogeannis CreditAttribution: capogeannis as a volunteer commentedThanks, bzaher. #11 variable settings fixes it for me ~ or rather than saying "fix", sets up my particular environment properly for this latest release. Would be good to include that in the docs somewhere.
Comment #13
capogeannis CreditAttribution: capogeannis as a volunteer commentedIssue turned out to be self-signed certs not jiving with the new deploy_verify_ssl variable defaulting to 1. Setting to 0 in DB manually in variables table or via drush noted in #11 properly sets up self-signed certs environments for this latest version.
Comment #14
Shiraz DindarThanks for your work on this, folks. Setting that var to 0 worked for me too.