php-composer.yml: install ability with/without validating certificate

[DavidHume-ArtefactualSystems]

If need to include validate_certs: no can do by ansible variable atom_php_composer_validate_certs: "no"

[hakamine]

@DavidHume-ArtefactualSystems : I was wondering if the failure is related/similar to e.g. composer/composer#5685 , composer/composer#7317 (curl failing to retrieve https://composer.github.io/installer.sig ) The workaround mentioned in these issues is
to install the ca-certificates package. Is the failure occurring on old versions of ubuntu ?

[DavidHume-ArtefactualSystems]

@DavidHume-ArtefactualSystems : I was wondering if the failure is related/similar to e.g. composer/composer#5685 , composer/composer#7317 (curl failing to retrieve https://composer.github.io/installer.sig ) The workaround mentioned in these issues is
to install the ca-certificates package. Is the failure occurring on old versions of ubuntu ?

Thanks @hakamine - I thought I checked out that aspect. This is happening when I deploy to new RBCM servers when on their VPN (I take it you haven't run into similar with SFU, CVA). The ca-certificates presence and version seems to be okay

$ ssh -F ~/dhumeWork/git-repos/deployment/envs/rbcm/ssh.config -A rbcmu18atomprodweb "egrep VERSION\= /etc/os-release ; sudo apt list ca-certificates -a --installed"
VERSION="18.04.5 LTS (Bionic Beaver)"

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
ca-certificates/bionic-updates,bionic-security,now 20210119~18.04.1 all [installed,automatic]
ca-certificates/bionic 20180409 all

seems to compare favourably to atomeurope-nginx, where we don't have a problem deploying

$ ssh artefactual@atomeurope-nginx "egrep VERSION\= /etc/os-release ; sudo apt list ca-certificates -a --installed"
VERSION="18.04.5 LTS (Bionic Beaver)"

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Listing...
ca-certificates/bionic-updates,bionic-security,now 20210119~18.04.1 all [installed]
ca-certificates/bionic 20180409 all

[hakamine]

LGTM (but I have not been able to test)

[DavidHume-ArtefactualSystems]

@hakamine @mamedin

Thanks Hector.

It is interesting - not quite the same problem as the composer issues you listed, but ran similar test as mentioned there and first few lines suggest validating certificates present

$ curl -sv https://composer.github.io/installer.sig
*   Trying 185.199.111.153...
* TCP_NODELAY set
* Connected to composer.github.io (185.199.111.153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs

      (( etc. ))

plus Miguel did a wget test proving could reach installer.sig... and yet when I initially deployed to new RBCM machines,

TASK [artefactual.atom : Get Composer installer signature.] ********

fails with

"msg": "Failed to validate the SSL certificate for composer.github.io:443. Make sure your managed systems have a v alid CA certificate installed. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tl s/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible. The exception msg was: [SSL: CERTIFICATE_VERIFY_FAILED] certif icate verify failed (_ssl.c:727)."

hence my thought to make validate_certs=False configurable. ¯_(ツ)_/¯

[DavidHume-ArtefactualSystems]

LGTM (but I have not been able to test)

Hi @hakamine , @mamedin - so I did try a test while deploying RBCM's new public server, failed right away because the syntax was wrong in that context.

However, while the new syntax (see the new "Files changed") did run, for atom_php_composer_validate_certs defined, got a failure on the subsequent task

TASK [artefactual.atom : Download Composer installer.] ***************************************************************************************************************************************************** task path: /home/dhume/dhumeWork/git-repos/deployment/envs/rbcm/roles/artefactual.atom/tasks/php-composer.yml:23 Friday 24 September 2021 13:37:29 -0700 (0:00:00.034) 0:02:15.877 ****** fatal: [rbcmu18atompubweb]: FAILED! => { "msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'content'\n\nThe error appears to be in '/home/dhume/dhumeWork/git-repos/deployment/envs/rbcm/roles/artefactual.atom/tasks/php-composer.yml': line 23, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Download Composer installer.\n ^ here\n" }

whereas when the new variable is undefined, proceeded as normal (same as current role).

Unlike my deploy to RbcmU18AtomProdWeb, the deploy to RbcmU18AtomPubWeb didn't NEED validate_certs: "no" , so carried on. Still think this option is a good idea, but will have to come back to it.