The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #9862

puppet cannot run without puppet group on the system

Added by Jeff McCune about 3 years ago. Updated almost 2 years ago.

Status:ClosedStart date:10/03/2011
Priority:HighDue date:
Assignee:Andrew Parker% Done:

0%

Category:settings
Target version:3.1.0
Affected Puppet version:2.7.0 Branch:https://github.com/puppetlabs/puppet/pull/1344
Keywords:settings

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Overview

Working with Puppet 2.7.5 I notice that puppet apply fails to work properly if the user puppet is not present on the system. In previous versions of Puppet, puppet apply does not require the user puppet to be present.

This is a problem because puppet apply may be responsible for managing the user puppet itself. This presents a chicken and an egg problem if puppet apply is not able to properly manage the resources puppet itself needs.

Steps to reproduce

With 2.7.5:

root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop
notice: Finished catalog run in 0.74 seconds
err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet
err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet
root@pe-centos6:~# puppet --version
2.7.5
root@pe-centos6:~# facter --version
1.6.1

Expected Behavior

With 2.6.10 it works as expected:

root@pe-centos6:~# puppet --version
2.6.10
root@pe-centos6:~# facter --version
1.6.1
root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop
notice: Finished catalog run in 0.67 seconds
root@pe-centos6:~#

Additional Information

This bug appears to have been introduced in 2.7.0:

root@pe-centos6:~# facter --version
1.6.1
root@pe-centos6:~# puppet --version
2.7.0
root@pe-centos6:~# puppet apply --modulepath /vagrant/modules /vagrant/manifests/vmsetup.pp --noop
notice: Finished catalog run in 0.75 seconds
err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet
err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet

Also, I should note this problem exists in the default case. I have no customizations to puppet.conf at all:

root@pe-centos6:~# cat /etc/puppet/puppet.conf
cat: /etc/puppet/puppet.conf: No such file or directory

Trace

Here is the trace when running against 2.7.x (2.7.5-91-g2958b05)


notice: Finished catalog run in 1.04 seconds
/root/src/puppet/lib/puppet/type/file/group.rb:18:in `insync?'
/root/src/puppet/lib/puppet/type/file/group.rb:17:in `map!'
/root/src/puppet/lib/puppet/type/file/group.rb:17:in `insync?'
/root/src/puppet/lib/puppet/property.rb:162:in `safe_insync?'
/root/src/puppet/lib/puppet/transaction/resource_harness.rb:61:in `perform_changes'
/root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `each'
/root/src/puppet/lib/puppet/transaction/resource_harness.rb:60:in `perform_changes'
/root/src/puppet/lib/puppet/transaction/resource_harness.rb:133:in `evaluate'
/root/src/puppet/lib/puppet/transaction.rb:49:in `apply'
/root/src/puppet/lib/puppet/transaction.rb:84:in `eval_resource'
/root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate'
/root/src/puppet/lib/puppet/util.rb:459:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/root/src/puppet/lib/puppet/util.rb:458:in `thinmark'
/root/src/puppet/lib/puppet/transaction.rb:103:in `evaluate'
/root/src/puppet/lib/puppet/transaction.rb:311:in `traverse'
/root/src/puppet/lib/puppet/transaction.rb:99:in `evaluate'
/root/src/puppet/lib/puppet/resource/catalog.rb:141:in `apply'
/root/src/puppet/lib/puppet/util/settings.rb:629:in `use'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/root/src/puppet/lib/puppet/util/settings.rb:612:in `use'
/root/src/puppet/lib/puppet/indirector/report/processor.rb:10:in `initialize'
/root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `new'
/root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `make_terminus'
/root/src/puppet/lib/puppet/indirector/indirection.rb:124:in `terminus'
/root/src/puppet/lib/puppet/indirector/indirection.rb:303:in `prepare'
/root/src/puppet/lib/puppet/indirector/indirection.rb:263:in `save'
/root/src/puppet/lib/puppet/configurer.rb:174:in `send_report'
/root/src/puppet/lib/puppet/configurer.rb:168:in `run'
/root/src/puppet/lib/puppet/application/apply.rb:215:in `main'
/root/src/puppet/lib/puppet/application/apply.rb:135:in `run_command'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/application.rb:410:in `hook'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/application.rb:401:in `exit_on_fail'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/util/command_line.rb:69:in `execute'
/root/src/puppet/bin/puppet:4
err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet
/root/src/puppet/lib/puppet/util/settings.rb:633:in `use'
/root/src/puppet/lib/puppet/resource/catalog.rb:157:in `apply'
/root/src/puppet/lib/puppet/util/settings.rb:629:in `use'
/usr/lib/ruby/1.8/sync.rb:230:in `synchronize'
/root/src/puppet/lib/puppet/util/settings.rb:612:in `use'
/root/src/puppet/lib/puppet/indirector/report/processor.rb:10:in `initialize'
/root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `new'
/root/src/puppet/lib/puppet/indirector/indirection.rb:315:in `make_terminus'
/root/src/puppet/lib/puppet/indirector/indirection.rb:124:in `terminus'
/root/src/puppet/lib/puppet/indirector/indirection.rb:303:in `prepare'
/root/src/puppet/lib/puppet/indirector/indirection.rb:263:in `save'
/root/src/puppet/lib/puppet/configurer.rb:174:in `send_report'
/root/src/puppet/lib/puppet/configurer.rb:168:in `run'
/root/src/puppet/lib/puppet/application/apply.rb:215:in `main'
/root/src/puppet/lib/puppet/application/apply.rb:135:in `run_command'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/application.rb:410:in `hook'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/application.rb:401:in `exit_on_fail'
/root/src/puppet/lib/puppet/application.rb:306:in `run'
/root/src/puppet/lib/puppet/util/command_line.rb:69:in `execute'
/root/src/puppet/bin/puppet:4
err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet

Related issues

Related to Puppet - Bug #6256: /var/lib/puppet/rrd not created Closed 02/08/2011
Related to Puppet - Feature #5288: Change the default of report to true Closed 11/13/2010
Related to Puppet - Bug #17702: Puppet 3.0.1 for OS X fails when run as sudo Duplicate
Related to Puppet Documentation - Bug #18203: Puppet configuration documentation implies owner can be p... Closed
Related to Puppet - Bug #2460: ssl/private_keys ownership + Passenger Closed 07/29/2009
Related to Puppet - Bug #4167: File Permissions can not be overridden in the puppetd, pu... Closed 07/07/2010
Related to Puppet - Bug #4336: puppet requires puppet group on client Closed 07/22/2010
Related to Puppet - Bug #18796: Puppet fails to start if there is no suitable user and/or... Accepted
Blocks Puppet Acceptance - Bug #11918: Acceptance tests should not create puppet user and group ... Accepted 01/12/2012
Blocks Puppet Acceptance - Feature #5738: Run spec tests across supported platforms Accepted 12/30/2010

History

#1 Updated by Jeff McCune about 3 years ago

  • Description updated (diff)

#2 Updated by Nigel Kersten about 3 years ago

  • Status changed from Needs Decision to Needs More Information
  • Assignee changed from Nigel Kersten to Jeff McCune

Is there any chance you could do a git bisect to work out why we introduced this Jeff?

This isn’t desirable, but I’m a little concerned there’s a bigger picture I’m missing.

#3 Updated by T.J. Yang almost 3 years ago

I am encountering same issue in puppet-2.7.6.

/opt/puppetmaster276/bin/puppet master Could not prepare for execution: Got 6 failure(s) while initializing: Could not evaluate: Could not find group puppet; Could not evaluate: Could not find group puppet; Could not evaluate: Could not find group puppet; Could not evaluate: Could not find group puppet; Could not evaluate: Could not find group puppet; Could not evaluate: Could not find group puppet

Once I created puppet in /etc/{passwd,group.shardow}, then I can start up puppet master. I am not using “puppet”, in stead I am using “puppets”. How can change the puppet master account name ?

#4 Updated by Jeff McCune almost 3 years ago

  • Status changed from Needs More Information to Needs Decision
  • Assignee changed from Jeff McCune to Nigel Kersten

Bisection

Using git bisect between 2.6.9 and 2.7.0 it looks like this commit [1] introduced the bug when #5288 was merged in.

% git show b753d836c5ea18333a1199b20b5c495f562f2af4
commit b753d836c5ea18333a1199b20b5c495f562f2af4
Author: James Turnbull 
Date:   Sun Nov 14 09:16:59 2010 +1100

    Fixed #5288 - Changed report default to true

diff --git a/lib/puppet/defaults.rb b/lib/puppet/defaults.rb
index 7ae5538..50c5d8c 100644
--- a/lib/puppet/defaults.rb
+++ b/lib/puppet/defaults.rb
@@ -116,7 +116,7 @@ module Puppet
     :catalog_terminus => ["compiler", "Where to get node catalogs.  This is useful to change if, for instance,
       you'd like to pre-compile catalogs and store them in memcached or some other easily-accessed store."],
     :facts_terminus => {
-      :default => Puppet.application_name.to_s == "master" ? 'yaml' : 'facter', 
+      :default => Puppet.application_name.to_s == "master" ? 'yaml' : 'facter',
       :desc => "The node facts terminus.",
       :hook => proc do |value|
         require 'puppet/node/facts'
@@ -599,7 +599,7 @@ module Puppet
     :inventory_port => ["$masterport",
       "The port to communicate with the inventory_server."
     ],
-    :report => [false,
+    :report => [true,
       "Whether to send reports after every transaction."
     ],
     :graph => [false, "Whether to create dot graph files for the different

[1] https://github.com/puppetlabs/puppet/commit/b753d836c5ea18333a1199b20b5c495f562f2af4

While this explains the change in behavior we’re seeing from 2.6.9 to 2.7.0 and beyond, I don’t think it actually explains the root cause of the error itself.

-Jeff

#5 Updated by Nigel Kersten almost 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Priority changed from Normal to High

This is not desirable behavior at all. apply needs to work without those users being present.

#6 Updated by Josh Cooper almost 3 years ago

I ran into this also. I was able to work around by using puppet apply manifest.pp --no-report

The root cause is that puppet is trying to send a report, and the report processor uses the :metrics section which defines a rrddir file resource with owner and group set to service

  setdefaults(:metrics,
    :rrddir => {:default => "$vardir/rrd",
      :mode => 0750,
      :owner => "service",
      :group => "service",
      :desc => "The directory where RRD database files are stored.
        Directories for each reporting host will be created under
        this directory."
    },

which puppet compiles into:

File[/var/lib/puppet/rrd] {
  :backup=>false, 
  :group=>"puppet", 
  :loglevel=>:debug, 
  :owner=>"root", 
  :links=>:follow, 
  :mode=>"750", 
  :ensure=>:directory, 
  :path=>"/var/lib/puppet/rrd"}
},

Strangely the owner is root but the group is puppet, and that’s the part that fails

#7 Updated by Nigel Kersten almost 3 years ago

Gah. We really do need to fix this, but I’m not sure what the best option is.

  • don’t send reports when running in apply mode.
  • don’t send reports when running in any mode and the required user/group don’t exist
  • fix the system user/group to work better. (/me waves hands)
  • ???

#8 Updated by Jeff McCune almost 3 years ago

On Tue, Dec 27, 2011 at 3:01 PM, tickets@puppetlabs.com wrote:

Issue #9862 has been updated by Nigel Kersten.

Gah. We really do need to fix this, but I’m not sure what the best option is.

don’t send reports when running in apply mode. don’t send reports when running in any mode and the required user/group don’t exist fix the system user/group to work better. (/me waves hands) ???

My proposal: when running apply use a different report dir than agent and just manage it as the EUID and EGID of the process.

#9 Updated by Josh Cooper almost 3 years ago

I think this bug is mis-labeled. AFAIK, it occurs when the puppet group is missing, but not the puppet user.

$ sudo env PATH=$PATH RUBYLIB=$RUBYLIB puppet apply -e 'notice "foo"'
notice: Scope(Class[main]): foo
notice: Finished catalog run in 0.02 seconds
err: /File[/var/lib/puppet/rrd]: Could not evaluate: Could not find group puppet
err: Could not send report: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet

But when I add the group, it works:

$ sudo groupadd puppet
$ id puppet
id: puppet: No such user
$ sudo env PATH=$PATH RUBYLIB=$RUBYLIB puppet apply -e 'notice "foo"'
notice: Scope(Class[main]): foo
notice: Finished catalog run in 0.02 seconds

And that is significant, because puppet does correctly map the “service” owner to the current user (root), but does not do the same with the “service” group. In other words, this might just be a simple bug.

#10 Updated by Jeff McCune almost 3 years ago

  • Subject changed from puppet 2.7 cannot run without puppet user on the system to puppet 2.7 cannot run without puppet group on the system

#11 Updated by Jeff McCune about 2 years ago

  • Target version changed from 2.7.x to 3.0.1
  • Keywords set to settings

Bit in 3.0.0

Eric, I was bit by this working with 3.0.x today. More settings catalog happy fun times.

Andy has an interesting question… Why did it work to create the group puppet, but not the user named jefftest?

root@puppetmaster:~# puppet resource user jeff
user { 'jeff':
  ensure           => 'present',
  gid              => '1000',
  groups           => ['adm', 'dip', 'video', 'plugdev'],
  home             => '/home/jeff',
  password         => '!',
  password_max_age => '99999',
  password_min_age => '0',
  shell            => '/bin/bash',
  uid              => '1000',
}
root@puppetmaster:~# puppet resource user jefftest ensure=present
Error: Could not set 'directory' on ensure: Could not find group puppet
Error: Could not set 'directory' on ensure: Could not find group puppet
Wrapped exception:
Could not find group puppet
Error: /File[/var/lib/puppet/log]/ensure: change from absent to directory failed: Could not set 'directory' on ensure: Could not find group puppet
Error: Could not run: Got 3 failure(s) while initializing: Could not set 'directory' on ensure: Could not find group puppet; Could not set 'directory' on ensure: Could not find group puppet
Wrapped exception:
Could not find group puppet; change from absent to directory failed: Could not set 'directory' on ensure: Could not find group puppet
root@puppetmaster:~# puppet resource group puppet ensure=present
/Group[puppet]/ensure: created
group { 'puppet':
  ensure => 'present',
}
root@puppetmaster:~# puppet resource user puppet ensure=present gid=puppet
/User[puppet]/ensure: created
user { 'puppet':
  ensure => 'present',
  gid    => '1002',
}
root@puppetmaster:~# puppet resource user jefftest ensure=present
/User[jefftest]/ensure: created
user { 'jefftest':
  ensure => 'present',
}

#12 Updated by Jeff McCune about 2 years ago

  • Target version changed from 3.0.1 to 3.0.x

#13 Updated by Jeff McCune about 2 years ago

  • Subject changed from puppet 2.7 cannot run without puppet group on the system to puppet cannot run without puppet group on the system

#14 Updated by Johan Haals almost 2 years ago

I’m currently unable to upgrade my clients from 2.7.18 to 3.0.1 Clients are OS X 10.8 Mountain Lion.

Everything works if I create this group before upgrading.

#15 Updated by Trung Hoang almost 2 years ago

Can’t use puppet to add the group, commonly found in veewee templates.

# init.pp
group { "puppet":
    ensure => "present", 
}

Output:

Error: /File[/var/lib/puppet/log]: Could not evaluate: Could not find group puppet
Error: Got 1 failure(s) while initializing: Could not evaluate: Could not find group puppet

#16 Updated by eric sorenson almost 2 years ago

A couple of points / questions for clarification from the OP and watchers:

  • In 2.7, this error doesn’t actually prevent puppet from running, as far as I can tell (and everyone’s log output supports this) — it occurs after the catalog is finished, when puppet is trying to save logs / state / graphs. Is that correct, in your experience?

  • in 3, the verification of the environment happens before the catalog application, so failures early on do prevent catalogs from applying. johan, is that the problem which is preventing you from upgrading, or is there something beyond that I’m missing?

#17 Updated by Johan Haals almost 2 years ago

Eric: Existing nodes: The group puppet must be present before upgrading, when that’s done, everything works.

New Nodes: I have to run a pre installation script that creates the puppet group before applying the puppet package.

#18 Updated by Björn Albers almost 2 years ago

The —no-report workaround doesn’t work around anymore on Puppet 3. Hmm…

#19 Updated by eric sorenson almost 2 years ago

  • Assignee set to Andrew Parker
  • Target version changed from 3.0.x to 3.1.0

Targeting this for 3.1.0 (late Dec/early Jan) — it needs developer investigation. There are reasonable workarounds but it’s been around for a while so please let’s not kick it any further down the line without understanding the root cause.

#20 Updated by Anonymous almost 2 years ago

I’ve run into this issue after upgrading to puppet 3.0.1 on Solaris and spent the morning trying to figure out why this is happening.

In lib/puppet/defaults.rb we’ve got –

  define_settings(:master,
    :user => {
      :default    => "puppet",
      :desc       => "The user puppet master should run as.",
    },
    :group => {
      :default    => "puppet",
      :desc       => "The group puppet master should run as.",
    },

This is where the code’s picking up the missing group ‘puppet’ from. To prove this we can change this default group setting to ‘foo’ and puppet will fail to find group ‘foo’ instead –

# puppet agent -t
Error: /File[/var/log/puppet]: Could not evaluate: Could not find group foo
Error: Could not prepare for execution: Got 1 failure(s) while initializing: Could not evaluate: Could not find group foo

Or we can comment the default group out altogether and puppet runs without a problem.

Meanwhile, puppet doesn’t care what I set the default user to. It’s evidently figuring out that the process is running as root and that’s all that matters.

Next I see in lib/puppet/defaults.rb we have –

    :mkusers => {
        :default  => false,
        :type     => :boolean,
        :desc     => "Whether to create the necessary user and group that puppet agent will run as.",
    },

If I change this setting to ‘true’ then puppet also runs fine and happily creates both the puppet user and group for me.

Thus I’m led to this piece of code in lib/puppet/settings/file_setting.rb that looks suspicious to me –

  def group=(value)
    unless AllowedGroups.include?(value)
      identifying_fields = [desc,name,default].compact.join(': ')
      raise SettingError, "Internal error: The :group setting for #{identifying_fields} must be 'service', not '#{value}'"
    end
    @group = value
  end

  def group
    return unless @group
    @settings[:group]
  end

  def owner=(value)
    unless AllowedOwners.include?(value)
      identifying_fields = [desc,name,default].compact.join(': ')
      raise SettingError, "Internal error: The :owner setting for #{identifying_fields} must be either 'root' or 'service', not '#{value}'"
    end
    @owner = value
  end

  def owner
    return unless @owner
    return "root" if @owner == "root" or ! use_service_user?
    @settings[:user]
  end

  def use_service_user?
    @settings[:mkusers] or @settings.service_user_available?
  end

My gut feeling is that a hack has been implemented for the user root but not the group root.

I apply the following patch –

# diff -u /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.1/lib/puppet/settings/file_setting.rb.orig /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.1/lib/puppet/settings/file_setting.rb
--- /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.1/lib/puppet/settings/file_setting.rb.orig     Tue Dec 18 12:03:24 2012
+++ /usr/local/lib/ruby/gems/1.8/gems/puppet-3.0.1/lib/puppet/settings/file_setting.rb  Tue Dec 18 11:47:29 2012
@@ -24,6 +24,7 @@

   def group
     return unless @group
+    return "root" if ! use_service_user?  # alex
     @settings[:group]
   end

And this fixes it – although not the ideal solution I suppose.

The method use_service_user? calls service_user_available? from lib/puppet/settings.rb –

  def service_user_available?
    return @service_user_available if defined?(@service_user_available)

    return @service_user_available = false unless user_name = self[:user]

    user = Puppet::Type.type(:user).new :name => self[:user], :audit => :ensure

    @service_user_available = user.exists?
  end

So it looks like some of the corresponding methods for the service group just weren’t implemented.

I am still new to ruby and I don’t fully understand what the method service_user_available? is doing. If someone can explain that to me I can probably submit a patch.

#21 Updated by Anonymous almost 2 years ago

Perhaps the reason the service group methods weren’t implemented is due to complications arising from the fact that the default group for the user ‘root’ isn’t always the group ‘root’. On AIX root’s default group is ‘system’. Later on I’ll try to reproduce this on AIX after I upgrade an AIX box.

#22 Updated by Andrew Parker almost 2 years ago

I’ve been looking into why there is a difference between how users are handled versus groups. It looks like they started to diverge with the work to fix #2460 where commit a49915ad928e01aa1a5505ae52125fac6f4f2744 added a check for the service user being available, but not a corresponding check for the group.

There was also a change made in commit 70af43f915110b806dc156fd09c3aa8ec7b0fe0d that allowed the group to be specified as “root”. That was supposedly part of the fix for #4167.

#23 Updated by Andrew Parker almost 2 years ago

An interesting side effect of the current logic implemented in the file setting type is that even if the group is set to be root on the setting it will still actually try to set it to the service group. This differs substantially from the behavior of the user property and I don’t think it was intentional.

#24 Updated by Andrew Parker almost 2 years ago

I’ve cleaned up the tests to make the functionality around choosing the owner and group clearer to myself. The result can be seen at https://github.com/zaphod42/puppet/blob/4bf2095fd68f9387a273c4ae8a62dea727a1691f/spec/unit/settings/file_setting_spec.rb#L31.

Those tests make clear that the group behaves substantially differently from the owner.

  1. setting the group to root is no different from setting the group to service
  2. group does not take into account Puppet[:mkusers] or whether the group actually exists on the system

Alex has a valid concern that not all systems use the same group for the root user. We could leave behavior 1 as is, but I don’t think that having that difference in behavior between user and group would be very user-friendly (no pun intended). Behavior 2 is the root of this issue and so fixing that is the minimum needed.

I hacked around while investigating this and came up with a similar patch to Alex for the group.

Since the behavior for a group of root doesn’t seem to be intentional, I’m not sure of the right course of action for that. I can leave it as is for now, but if I do that I think setting group to root should be deprecated.

#25 Updated by Andrew Parker almost 2 years ago

Previously (in 2009) owner and group had been allowed to be anything. Commit 06fcece75ef52168a73013eba2b8bfc50cf71c97 removed that functionality. The docs imply that you can still set owner, and maybe group, to things that are not root or service in the example given at http://docs.puppetlabs.com/guides/configuring.html.

#26 Updated by Andrew Parker almost 2 years ago

  • Branch set to https://github.com/zaphod42/puppet/tree/issue/master/9862-cannot-run-without-puppet-group

I’ve got this working on a branch. I still need to put together an acceptance test for this so that we don’t regress on it, but I think what I’ve put together on that branch should work.

There is more cleanup that I’d like to do, but it would take me into the settings, which has been the subject of a constant discussion for a rewrite so I’ll hold off on that for now.

#27 Updated by Anonymous almost 2 years ago

I’m still concerned about AIX – file_settings.rb has

  Allowed = %w{root service}
...
  def assert_allowed_value(parameter, value)
    if not Allowed.include?(value)
      raise SettingError, "The #{parameter} parameter for the setting '#{name}' must be either 'root' or 'service', not '#{value}'"
    end
  end

I haven’t tested it but isn’t that going to break on AIX where the process will run as user root and group system?

#28 Updated by Anonymous almost 2 years ago

Also any chance this patch could go out in 3.0.x? I’m really hoping I don’t have to create a group puppet on my whole fleet just to work around this. :)

#29 Updated by Andrew Parker almost 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch changed from https://github.com/zaphod42/puppet/tree/issue/master/9862-cannot-run-without-puppet-group to https://github.com/puppetlabs/puppet/pull/1344

Alex, I think this should work on AIX since I chose to leave the group unmanaged if the wanted group doesn’t exist and puppet isn’t going to try making the user/group. This differs from how the owner is managed, which would try to set it to ‘root’ in this scenario. If the group is explicitly set to ‘root’, then it will try to set it to ‘root’, but none of the default permissions try to do that.

I don’t think there is going to be another 3.0.x release since 3.1.0 should be just a few weeks away.

#30 Updated by Anonymous almost 2 years ago

I see, of course… And I’ve also confirmed the patch works fine on my AIX 6.1 test host.

#31 Updated by Andrew Parker almost 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release

#32 Updated by Matthaus Owens almost 2 years ago

  • Status changed from Merged - Pending Release to Closed

Released in Puppet 3.1.0-rc1

Also available in: Atom PDF