wp_owner/wp_group concat issue

[abuxton]

Hi
when using the
wp_owner
wp_group
variables in the class definition the following error occurs with concat module intergration

## Configure wordpress
  class { 'wordpress':
    install_dir => '/var/www/wordpress',
    db_name     => 'wordpress',
    db_host     => 'localhost',
    db_user     => 'wordpress',
    db_password => 'wordpress',
    wp_owner    => 'wordpress',
    wp_group    => 'wordpress',
  }

Error: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]/returns: change from notrun to 0 failed: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]: Failed to call refresh: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0] 

removing the 2 wp_ vars works around the issue..

[mikegleasonjr]

I have the exact same issue

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

[mc0e]

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 ?

[hyclak]

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.

[GeoffWilliams]

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

[jbouse]

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

[mc0e]

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 ?

[jbouse]

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

[jantman]

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

[felipe1982]

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

[mc0e]

@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

[felipe1982]

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.

[mc0e]

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

[felipe1982]

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