Add --no-check-certificate to wget call about puppet-wordpress HOT 14 OPEN

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.

from puppet-wordpress.

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

from puppet-wordpress.

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

But @klynton's solution worked for me.

from puppet-wordpress.

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.

from puppet-wordpress.

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

from puppet-wordpress.

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)

from puppet-wordpress.

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

from puppet-wordpress.

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

Have you tried that @cvquesty ?

from puppet-wordpress.

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.

from puppet-wordpress.

@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.

from puppet-wordpress.

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

from puppet-wordpress.

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 :-)

from puppet-wordpress.

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.

from puppet-wordpress.

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.

from puppet-wordpress.