Add --no-check-certificate to wget call

[atxulo]

Now that wordpress 4.0 is out i've a new issue, caused by an incorrect certificate at wordpress.org

Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: --2014-09-22 13:11:40-- http://wordpress.org/wordpress-4.0.tar.gz
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Resolving wordpress.org... 66.155.40.249, 66.155.40.250
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Connecting to wordpress.org|66.155.40.249|:80... connected.
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: HTTP request sent, awaiting response... 302 Moved Temporarily
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Location: https://wordpress.org/wordpress-4.0.tar.gz [following]
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: --2014-09-22 13:11:40-- https://wordpress.org/wordpress-4.0.tar.gz
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Connecting to wordpress.org|66.155.40.249|:443... connected.
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: ERROR: certificate common name "*.wordpress.org" doesn't match requested host name "wordpress.org".
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: To connect to wordpress.org insecurely, use '--no-check-certificate'.
Error: wget http://wordpress.org/wordpress-4.0.tar.gz returned 5 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: change from notrun to 0 failed: wget http://wordpress.org/wordpress-4.0.tar.gz returned 5 instead of one of [0]
Notice: /Stage[main]/Wordpress::App/Exec[Extract wordpress]: Dependency Exec[Download wordpress] has failures: true

Althougth it's not a puppet error (it's a wordpress.org configuration error which should be solved) this could be easily avoided adding '--no-check-certificate' to the wget call (in app.pp):

command => "wget --no-check-certificate ${install_url}/wordpress-${version}.tar.gz",

[treydock]

Just FYI - I ran into this on CentOS 6.4. I updated my host to 6.5 and the error went away. It's likely due to them using an updated certificate (SHA-2 noise?).

It's worth noting that the acceptance tests fail due to this issue.

[klynton]

@EnekoGB I've run into this issue as well. I fixed it by adding a 'www.' to the domain.

[F3TTT]

I'm seeing this on CentOS6.5 as well:

Error: wget http://wordpress.org/wordpress-3.8.tar.gz returned 5 instead of one of [0]

But @klynton's solution worked for me.

[atxulo]

The CN of the cert is *.wordpress.org so i't looks like is a wget problem (i'm using RHEL 6; see https://www.drupal.org/node/2145537) more than a problem with the recipe, but perhaps the '--no-check-certificate' option could be parametrized. @hunner, what do you think?

curl -v https://wordpress.org | more
...
* Server certificate:
*        subject: OU=Domain Control Validated; CN=*.wordpress.org
*        start date: 2014-12-06 00:13:18 GMT
*        expire date: 2017-12-15 20:11:21 GMT
*        subjectAltName: wordpress.org matched
*        issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*        SSL certificate verify ok.

[F3TTT]

I thought I had bypassed it but I was wrong.

my wget was at 1.12-18.el6.x86_64. Updated it to 1.12-5.el6_6.1.x86_64 and now it seems fine. Thanks @EnekoGB

[cvquesty]

I'm getting a "returned 3 instead of 0" and I'm on the same version of wget as F3TTT and have fully updated my CentOS6 installation.

Also attempted to add the www. to the domain, and still am receiving the same error (3)

[cvquesty]

Is there a way to set severity? This errors I'm experiencing means the module is completely unusable.

[F3TTT]

It seems like @EnekoGB has a solution that is different as of October 13th: #77

Have you tried that @cvquesty ?

[cvquesty]

I have indeed.

Interesting note, though... if I do:

class { 'wordpress':
wp_owner => 'user',
wp_group => 'group',
db_user => 'user',
db_password => 'password',
}

The download completes and everything installs into the defaults of /opt/wordpress and sets up a database known as wordpress.

Curiously, this works, and the place of the previous error (the download) does not throw an error.

When I begin to add options and run the following:

class { 'wordpress':
  wp_owner    => 'owner',
  wp_group    => 'group',
  db_user     => 'user',
  db_name     => 'name',
  db_password => 'password',
  install_dir => '/var/www/html/dirname',
}

I start getting the error on the download portion:

Error: wget http://wordpress.org/wordpress-3.8.tar.gz returned 3 instead of one of [0]
Error: /Stage[main]/Wordpress/Wordpress::Instance[/var/www/html/www.REDACTED.com]/Wordpress::Instance::App[/var/www/html/www.REDACTED.com]/Exec[Download wordpress http://wordpress.org/wordpress-3.8.tar.gz to /var/www/html/www.REDACTED.com]/returns: change from notrun to 0 failed: wget http://wordpress.org/wordpress-3.8.tar.gz returned 3 instead of one of [0]

I got curious, however, when the immediately preceding errors looked like this:

Notice: /Stage[main]/Wordpress/Wordpress::Instance[/var/www/html/www.REDACTED.com]/Wordpress::Instance::App[/var/www/html/www.REDACTED.com]/Exec[Download wordpress http://wordpress.org/wordpress-3.8.tar.gz to /var/www/html/www.REDACTED.com]/returns: HTTP request sent, awaiting response... 200 OK
Notice: /Stage[main]/Wordpress/Wordpress::Instance[/var/www/html/www.REDACTED.com]/Wordpress::Instance::App[/var/www/html/www.REDACTED.com]/Exec[Download wordpress http://wordpress.org/wordpress-3.8.tar.gz to /var/www/html/www.REDACTED.com]/returns: Length: 5863402 (5.6M) [application/octet-stream]
Notice: /Stage[main]/Wordpress/Wordpress::Instance[/var/www/html/www.REDACTED.com]/Wordpress::Instance::App[/var/www/html/www.REDACTED.com]/Exec[Download wordpress http://wordpress.org/wordpress-3.8.tar.gz to /var/www/html/www.REDACTED.com]/returns: wordpress-3.8.tar.gz: Permission denied

So... it can't download the package to the directory it's destined for as per the class call I made above. So I look up further, and for some reason, the module is changing the permissions to root before it ever attempts the call:

Notice: /Stage[main]/Profiles::REDACTED/Apache::Vhost[www.REDACTED.com]/File[/var/www/html/www.REDACTED.com]/owner: owner changed 'apache' to 'root'
Notice: /Stage[main]/Profiles::REDACTED/Apache::Vhost[www.REDACTED.com]/File[/var/www/html/www.REDACTED.com]/group: group changed 'apache' to 'root'

So, even if I set the directory to be owned by Apache to begin with, it automagically changes it to "root" instead and then I get the permissions failure for the download itself.

Best part? Doesn't do any of this taking the defaults, and only when passing parameters in does it start to have issues.

And "yes"... I'm running "puppet agent -t" as "root" with SELinux off.

[atxulo]

@cvquesty can you see if there's a log message like this in your logs?

"Warning: cannot manage the permissions of /var/www/html/dirname, as another resource (perhaps apache::vhost?) is managing it.

Looking at the source code, the folder should be owned by $wp_owner unless another puppet module is managing it

  File {
    owner  => $wp_owner,
    group  => $wp_group,
    mode   => '0644',
  }

  ...

  ## Installation directory
  if ! defined(File[$install_dir]) {
    file { $install_dir:
      ensure  => directory,
      recurse => true,
    }
  } else {
    notice("Warning: cannot manage the permissions of ${install_dir}, as another resource (perhaps apache::vhost?) is managing it.")
  }

I can't think of another reason for this folder being owned by root.

[cvquesty]

Even better... yes, it's being managed by puppetlabs/apache, but as I am sure you're aware, the default user/group in that module is apache:apache, so that's not it. sigh

I'll check into all the other modules I'm using, but generally speaking... I can't imagine a single module that would go into /var/www/html in any capacity and start owning things by root

[atxulo]

You should be able to see in the logs of the server, in the puppet console,
which module is changing these folder's permissions, unless there is an
exec, a script or something similar,even something outside puppet (i'm
thinking of cron scripts, altought i suppose you have checked it).

Perhaps your best bet is to disable modules being assigned to the server to
detect which module is changing the permissions.

Good luck :-)

[cvquesty]

Ok, yeah... so get this. If you don't EXPLICITLY define a docroot_owner and docroot_group in the puppetlabs/apache module, it goes through and defaults the whole darned thing to "root".

I'm doing an apply now to see if the permissions resolves the return code of 3. Stand by.

[cvquesty]

Ok... that appears to be the answer. If your destination docroot is not owned properly when the Wordpress module is applied, you can get any number of strange returns, but once your destination can be written to, Wordpress installs as expected.