FAQ
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

--
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-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Alan Evans at Jun 15, 2012 at 8:50 pm
    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

    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights wrote:
    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

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 15, 2012 at 9:00 pm
    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
    On Fri, Jun 15, 2012 at 1:50 PM, Alan Evans wrote:

    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

    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights wrote:
    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

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.

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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Alan Evans at Jun 15, 2012 at 9:20 pm
    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
    On Fri, Jun 15, 2012 at 5:00 PM, Guy Knights wrote:
    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

    On Fri, Jun 15, 2012 at 1:50 PM, Alan Evans wrote:

    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


    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights <guy@eastsidegamestudio.com>
    wrote:
    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

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


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

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 15, 2012 at 9:27 pm
    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.
    On Fri, Jun 15, 2012 at 2:20 PM, Alan Evans wrote:

    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
    On Fri, Jun 15, 2012 at 5:00 PM, Guy Knights wrote:
    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

    On Fri, Jun 15, 2012 at 1:50 PM, Alan Evans wrote:

    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


    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights <
    guy@eastsidegamestudio.com>
    wrote:
    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

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google
    Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


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

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

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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Alan Evans at Jun 15, 2012 at 9:40 pm
    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
    On Fri, Jun 15, 2012 at 5:27 PM, Guy Knights wrote:
    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.

    On Fri, Jun 15, 2012 at 2:20 PM, Alan Evans wrote:

    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

    On Fri, Jun 15, 2012 at 5:00 PM, Guy Knights <guy@eastsidegamestudio.com>
    wrote:
    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


    On Fri, Jun 15, 2012 at 1:50 PM, Alan Evans <alanwevans@gmail.com>
    wrote:
    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


    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights
    <guy@eastsidegamestudio.com>
    wrote:
    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

    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google
    Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


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

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


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

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 15, 2012 at 9:42 pm
    Ok, thanks for your help Alan. BTW, I forgot include our puppet version -
    it's 2.7.0.

    Cheers,
    Guy
    On Fri, Jun 15, 2012 at 2:40 PM, Alan Evans wrote:

    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
    On Fri, Jun 15, 2012 at 5:27 PM, Guy Knights wrote:
    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.

    On Fri, Jun 15, 2012 at 2:20 PM, Alan Evans wrote:

    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

    On Fri, Jun 15, 2012 at 5:00 PM, Guy Knights <
    guy@eastsidegamestudio.com>
    wrote:
    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


    On Fri, Jun 15, 2012 at 1:50 PM, Alan Evans <alanwevans@gmail.com>
    wrote:
    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


    On Fri, Jun 15, 2012 at 2:47 PM, Guy Knights
    <guy@eastsidegamestudio.com>
    wrote:
    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

    --
    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-users@googlegroups.com
    .
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    --
    You received this message because you are subscribed to the Google
    Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


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

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


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

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

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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Dominic Cleal at Jun 16, 2012 at 7:46 am

    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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 19, 2012 at 4:45 pm
    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
    On Saturday, June 16, 2012 12:45:54 AM UTC-7, Dominic Cleal wrote:
    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
    --
    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/-/AoTdf7vTU8IJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 19, 2012 at 8:01 pm
    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
    On Tuesday, June 19, 2012 9:45:21 AM UTC-7, Guy Knights wrote:

    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
    On Saturday, June 16, 2012 12:45:54 AM UTC-7, Dominic Cleal wrote:
    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
    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 19, 2012 at 8:03 pm
    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.
    On Tue, Jun 19, 2012 at 12:41 PM, Guy Knights wrote:

    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

    On Tuesday, June 19, 2012 9:45:21 AM UTC-7, Guy Knights wrote:

    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
    On Saturday, June 16, 2012 12:45:54 AM UTC-7, Dominic Cleal wrote:
    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<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
    --
    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-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.


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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 19, 2012 at 9:02 pm
    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:
    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
    --
    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/-/PKSqwJLEZGkJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Dominic Cleal at Jun 20, 2012 at 8:37 am

    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.

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


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Guy Knights at Jun 20, 2012 at 3:33 pm
    Oh ok, thanks Dominic. I'll give that a go.

    Regards,
    Guy
    On Wed, Jun 20, 2012 at 1:37 AM, Dominic Cleal wrote:
    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.

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


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

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

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 15, '12 at 6:47p
activeJun 20, '12 at 3:33p
posts14
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase