wp_owner/wp_group concat issue about puppet-wordpress HOT 13 CLOSED

If you are using puppetlabs-apache, then you want to set docroot_owner and/or docroot_group, and maybe docroot_mode.

from puppet-wordpress.

I see. Thanks @mc0e I will give that a try :)

from puppet-wordpress.

I have the exact same issue

EDIT: Using the latest concat causes the bug, using concat 1.0.0 fixes it.

from puppet-wordpress.

Looking in class wordpress::app, I see default user being set for 'Exec' resources. A little further down I see a 'Change ownership' exec which can't possibly run as non root. That looks important, but is not the current problem. It seems the current problem is because the exec resources within the concat class are affected by this declaration.

I'm running puppet 2.7. I think that's the last version to use the old scoping rules, and I would not be surprised if this issue is only present in puppet version ≤ 2.7 ?

from puppet-wordpress.

The issue with the Exec resources passing through to concat still seems to be an issue on puppet 3.7.0 and concat 1.1.0.

from puppet-wordpress.

I can confirm that this looks to be a bug in the concat module rather then this wordpress one.

Please see puppetlabs/puppetlabs-concat#231 for more information

from puppet-wordpress.

I'm experiencing this same issue with concat 1.1.1 and Puppet 3.7.1

from puppet-wordpress.

The problem is not with concat, or with puppet. Overriding defaults for core resource types like Exec and File is bound to have repercussions. I don't think the author understood that such declarations have global scope in some versions of puppet.

Note that since the File resource type's defaults are changed to use "owner => $wp_owner", there's a serious security problem here for affected systems.

jbouse can you confirm that yours is really the same problem? Are you seeing files owned by wp_owner appearing amongst concat's fragments in /var/lib/puppet/concat ?

from puppet-wordpress.

@mc0e , Yes the issue is identical. I had the puppetlabs/apache module and I was using mikegleasonjr/wordpress 0.7.3. Apache file fragments were owned by root:root and processed fine while the Wordpress file fragments were owned by www-data:www-data which is what wp_owner and wp_group were set to respectively. I had originally created an issue on his module and he mentioned that I should bring over here.

from puppet-wordpress.

Yeah, I'm having this issue as well. #46 seems to fix it for me.

from puppet-wordpress.

PR #46 causes a problem on RHEL 7. I have removed the "user" and "group" attributes to 3 exec commands, and that has allowed me to use wp_group => 'wordpress' and wp_owner => 'wordpress' successfully.

Index: app.pp
===================================================================
--- app.pp  (revision 103173)
+++ app.pp  (revision 103195)
@@ -68,20 +68,14 @@
     command => "wget ${install_url}/wordpress-${version}.tar.gz",
     creates => "${install_dir}/wordpress-${version}.tar.gz",
     require => File[$install_dir],
-    user    => $wp_owner,
-    group   => $wp_group,
   }
   -> exec { "Extract wordpress ${install_dir}":
     command => "tar zxvf ./wordpress-${version}.tar.gz --strip-components=1",
     creates => "${install_dir}/index.php",
-    user    => $wp_owner,
-    group   => $wp_group,
   }
   ~> exec { "Change ownership ${install_dir}":
     command     => "chown -R ${wp_owner}:${wp_group} ${install_dir}",
     refreshonly => true,
-    user        => $wp_owner,
-    group       => $wp_group,
   }

   ## Configure wordpress

from puppet-wordpress.

@felipe1982: I wouldn't remove the ownership on those execs. Look at the permissions on ${install_dir} and make sure that's writable by $wp_owner:$wp_group

from puppet-wordpress.

I think apache::vhost is creating the directory $install_dir as root:root so wordpress::instance::app cannot modify it, so my wget is failing right away when user/group are set in that exec. Unsetting them allows root to run wget, which allows it to run, then untar, then chown successfully.

from puppet-wordpress.