Augeas resources not being saved

[Guy Knights]

I've recently configured a couple of augeas resources, one for a php.ini file and one for sudoers, however neither set of changes is being saved. I have no idea why. The sudoers resource is here:

   augeas { 'set_sudoers':
     context    => '/files/etc/sudoers/spec[user="%sudo"]',
     changes    => 'set /host_group/command/tag NOPASSWD',
   }

I've tested the above using augtool ('set /files/etc/sudoers/spec[user="%sudo"]/host_group/command/tag NOPASSWD', followed by 'save') and it works fine. It seems like puppet isn't saving the change.

Here's the one for php.ini that is also not working:

   augeas { 'set_php_errorlog':
      notify    => Service['php5-fpm'],
      require   => Package['php5-fpm'],
      context   => '/files/etc/php5/fpm/php.ini',
      changes   => [
        "set /PHP/error_log /var/log/php/php.log",
      ],
   }

Does anyone have any idea why these aren't being saved?

Thanks,
Guy

[Alan Evans]

Guy,

Check the debug output of the agent. puppetd --debug or puppet agent
--debug (I think)

Or try running the same set with augtool from the command line.

# augtool --noload
augtool> set /files/etc/php5/fpm/php.ini/PHP/error_log /var/log/php/php.log
augtool> print /augeas//error

See what the output of /augeas//error is.

I suspect augeas doesn't have a lens that knows about
/etc/php5/fpm/php.ini file.

You might have to change your augeas type to something like:

augeas { 'set_php_errorlog':
notify => Service['php5-fpm'],
require => Package['php5-fpm'],

lens => 'IniFile.lns',
incl => '/etc/php5/fpm/php.ini',

context => '/files/etc/php5/fpm/php.ini',
changes => [
"set /PHP/error_log /var/log/php/php.log",
],
}

Some relevant links.
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Augeas
http://augeas.net/docs/references/lenses/files/inifile-aug.html

Regards,
-Alan

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/nVj8fzqwEp8J.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

[Guy Knights]

Yeah, I tried --debug in my puppet command and it didn't give me any errors. In my original message i did say I tried doing the set from augtool and it worked, but I just tried it again with augtool --noload and it can't find anything to do with the sudoers file. It's like it's not reading the file...or something, I'm not overly familiar with how augeas does stuff behind the scenes.

In my augeas lenses folder on the server I have both php.aug and sudoers.aug, and like I said, when I run augtool without --noload I can access these config files and change items perfectly fine.

Thanks,
Guy

--
Guy Knights
Systems Administrator
Eastside Games
www.eastsidegamestudio.com
g...@eastsidegamestudio.com

[Alan Evans]

Guy,

The way augeas works is each lens has filters for which files it
should include and exclude. The --noload switch tells augtool not to
automatically load the lenses in /usr/share/augeas/ so it does not see
these filters. You then have to manually load a lens and tell it
which files to parse.

The PHP lens on my machine for example includes the following files by default.

augtool> print /augeas/load/PHP/incl
/augeas/load/PHP/incl[1] = "/usr/local/zend/etc/conf.d/*.ini"
/augeas/load/PHP/incl[2] = "/usr/local/zend/etc/php.ini"
/augeas/load/PHP/incl[3] = "/etc/php.d/*.ini"
/augeas/load/PHP/incl[4] = "/etc/php.ini"
/augeas/load/PHP/incl[5] = "/etc/php*/*/*.ini"

What version of puppet are you using? There is a patch in newer
versions that prints the output of /augeas//error when --debug is used
but if you are like me and stuck on an older version you won't get get
/augeas//error.

Instead of using context can you try using a fully qualified set
statement? I did find a case where context failed me.

augeas { 'set_php_errorlog':
notify => Service['php5-fpm'],
require => Package['php5-fpm'],

changes => [
"set /files/etc/php5/fpm/php.ini/PHP/error_log /var/log/php/php.log",
],
}

-Alan

[Guy Knights]

Ok, thanks for the info. Are you implying that the puppet augeas resource type acts in '--noload' mode, then?

I tried doing the fully qualified set statement but it still does nothing, unfortunately.

[Alan Evans]

From what I understand if you use the 'lens' attribute on the augeas
resource type the augeas ruby library does essentially the same thing
as --noload for augtool. Otherwise (unless its been fixed) every time
you use the augeas resource it opens the augeas-ruby library which
parses all lenses augeas knows about. This can add a significant
amount of overhead to a catalog run. Just run 'augtool' and 'augtool
--noload' to see the difference in start up time.

If debug isn't giving you anything meaningful, using a fully qualified
path instead of context and you can run the set statement in augtool
just fine I am frankly out of ideas for the moment...

Lets see if someone else chimes in on this one and I'll give it a bit
more thought.

Regards,
-ALan

[Guy Knights]

Ok, thanks for your help Alan. BTW, I forgot include our puppet version - it's 2.7.0.

Cheers,
Guy

[Dominic Cleal]

On 15/06/12 22:42, Guy Knights wrote:
> Ok, thanks for your help Alan. BTW, I forgot include our puppet version
> - it's 2.7.0.

Which version of Augeas are you using? There's a bug if you're using
Augeas 0.10.0 with any version of Puppet before 2.7.10 where it won't
save the resource. You'll need to upgrade Puppet, or downgrade Augeas
to 0.9.0.

http://projects.puppetlabs.com/issues/11414

I think you were saying that Puppet didn't print any errors? This bug
manifests as that, but shows the resource "executing" every time.

If that's not it, could you please pastebin the logging of the whole
resource when debug was enabled?

--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113

[Guy Knights]

That looks like the issue then. We're using augeas 0.10 (default with ubuntu 10.04) and puppet 2.7.3. I'll look at upgrading puppet and see how that goes.

Thanks all,
Guy

[Guy Knights]

Hi again,

I attempted to upgrade puppet from the office Puppet apt repository today, previously it had been installed from source. I just installed the package over the top, thinking it would overwrite the existing files. However, when I run puppet --version it still spits out 2.7.3. I looked at /usr/lib/ruby/1.8/puppet.rb and it lists PUPPETVERSION as '2.7.16'.

Any idea what the problem is here? I tried completely removing (purging) the package then reinstalling via apt but it still says 2.7.3 when I run puppet --version.

Thanks,
Guy

[Guy Knights]

Sorry, never mind this. I discovered that the source version of puppet was install in /usr/local/libs/site_ruby while the repository version appears to have been installed in /usr/lib/ruby1.8.

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4sWdC37-jRkJ.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Guy Knights]

I can now confirm that Dominic was correct. I'm upgraded to puppet 2.7.16 now and the augeas resources are working. One thing I can also confirm is that Alan's observation about the context not working and to use the full path in the set command was also correct, at least for the sudoers config change I made. However, the other augeas resource I had that was making changes to /etc/ssh/ssh_config worked using the context setting, so I don't know what the problem is there.

In any case, thanks for your help everyone.

Cheers,

Guy

On Saturday, June 16, 2012 12:45:54 AM UTC-7, Dominic Cleal wrote:

[Dominic Cleal]

On 19/06/12 22:02, Guy Knights wrote:
> I can now confirm that Dominic was correct. I'm upgraded to puppet
> 2.7.16 now and the augeas resources are working. One thing I can also
> confirm is that Alan's observation about the context not working and to
> use the full path in the set command was also correct, at least for the
> sudoers config change I made. However, the other augeas resource I had
> that was making changes to /etc/ssh/ssh_config worked using the context
> setting, so I don't know what the problem is there.

Is it this resource from one of your original posts?

augeas { 'set_sudoers':
context => '/files/etc/sudoers/spec[user="%sudo"]',
changes => 'set /host_group/command/tag NOPASSWD',
}

The issue here is the "/" before "host_group". Because the / is there,
it believes this is an absolute path rather than being underneath the
context. Remove the leading / and the context will be applied.

[Guy Knights]

Oh ok, thanks Dominic. I'll give that a go.

Regards,
Guy

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.