Description of problem: Immediately after upgrading to the latest version of augeas-libs, my FC17 hosts started logging the following kind of errors: Jan 17 03:36:28 fc-17-i386-1 puppet-agent[634]: (/Stage[main]/Openssh::Config/Augeas[sshd_config]) Could not evaluate: unknown error - Failed to initialize Augeas Therefore, I believe that it's a ruby-augeas / augeas-libs compatibility problem. Maybe a rebuild is needed? Version-Release number of selected component (if applicable): [root@fc-17-i386-1]# rpm -qa | grep auge ruby-augeas-0.4.1-3.fc17.i686 augeas-libs-1.0.0-1.fc17.i686 How reproducible: Try running Puppet manifests that use augeas on a fully upgraded FC17 host. Additional info: I set the Severity to high, because this basically makes FC17 hosts unmanageable by Puppet.
Can you run "augtool" on a host - what error does it show? Do you have any Augeas lenses in your Puppet modules? Do you have any .aug files under /var/lib/puppet? Can you also list /usr/share/augeas/lenses/*.aug? (not dist)
Hi Dominic, Thanks for getting back to me... > Can you run "augtool" on a host - what error does it show? I don't have the augeas package installed on the hosts. Previously, it was not necessary. But I did install it manually on one of the hosts for you, and the tool loads just fine without giving any error message. So it appears to be a problem with Ruby bindings... > Can you also list /usr/share/augeas/lenses/*.aug? (not dist) [root@fc-17-i386-1 ~]# ls -als /usr/share/augeas/lenses/*.aug ls: cannot access /usr/share/augeas/lenses/*.aug: No such file or directory [root@fc-17-i386-1 ~]# ls -als /usr/share/augeas/lenses/dist/*.aug 4 -rw-r--r-- 1 root root 3550 Nov 2 16:20 /usr/share/augeas/lenses/dist/access.aug ... > Do you have any Augeas lenses in your Puppet modules? Do you have any .aug files under /var/lib/puppet? No. No: [root@fc-17-i386-1 ~]# ls -als /var/lib/puppet total 40 4 drwxr-xr-x. 9 puppet puppet 4096 Aug 19 20:57 . 4 drwxr-xr-x. 29 root root 4096 Nov 23 19:02 .. 4 -rw-r----- 1 root root 610 Jan 21 08:56 classes.txt 4 drwxr-x--- 4 root root 4096 Aug 19 21:01 clientbucket 4 drwxr-x--- 2 root root 4096 Aug 19 20:30 client_data 4 drwxr-x--- 3 root root 4096 Aug 19 20:57 client_yaml 4 drwxr-xr-x 2 root root 4096 Aug 19 20:30 facts 4 drwxr-xr-x 2 root root 4096 Aug 19 20:30 lib 4 drwxrwx--x 7 puppet root 4096 Aug 19 20:52 ssl 4 drwxr-xr-t 3 root root 4096 Jan 21 08:56 state
(In reply to comment #2) > > Do you have any Augeas lenses in your Puppet modules? Do you have any .aug files under /var/lib/puppet? > > No. No: > > [root@fc-17-i386-1 ~]# ls -als /var/lib/puppet > total 40 > 4 drwxr-xr-x. 9 puppet puppet 4096 Aug 19 20:57 . > 4 drwxr-xr-x. 29 root root 4096 Nov 23 19:02 .. > 4 -rw-r----- 1 root root 610 Jan 21 08:56 classes.txt > 4 drwxr-x--- 4 root root 4096 Aug 19 21:01 clientbucket > 4 drwxr-x--- 2 root root 4096 Aug 19 20:30 client_data > 4 drwxr-x--- 3 root root 4096 Aug 19 20:57 client_yaml > 4 drwxr-xr-x 2 root root 4096 Aug 19 20:30 facts > 4 drwxr-xr-x 2 root root 4096 Aug 19 20:30 lib > 4 drwxrwx--x 7 puppet root 4096 Aug 19 20:52 ssl > 4 drwxr-xr-t 3 root root 4096 Jan 21 08:56 state Could you check recursively under /var/lib/puppet/lib in particular please? I just want to rule out behaviour of the Puppet provider. Can you run this? ruby -raugeas -e 'puts Augeas.open("/", nil, 256).error'
> Could you check recursively under /var/lib/puppet/lib in particular please? I just want to rule out behaviour of the Puppet provider. Sure, no problem: [root@fc-17-i386-1 ~]# ls -als /var/lib/puppet/lib total 8 4 drwxr-xr-x 2 root root 4096 Aug 19 20:30 . 4 drwxr-xr-x. 9 puppet puppet 4096 Aug 19 20:57 .. [root@fc-17-i386-1 ~]# find /var/lib/puppet -name \*.aug > Can you run this? Hmmm... now this is strange, doesn't seem to show any error: [root@fc-17-i386-1 ~]# ruby -raugeas -e 'puts Augeas.open("/", nil, 256).error' {:code=>0, :message=>"No error"}
Just in case it helps, here is the manifest that fails: https://github.com/nest/anubis-puppet/blob/master/modules/augeas/manifests/init.pp I later use it like this: augeas::insert_comment { 'sshd_config': file => '/etc/ssh/sshd_config', require => Class['openssh::install'], }
Hm, I'm running out of ideas and see nothing wrong in the manifest. Have you restarted the Puppet agent since Augeas was upgraded (it's a low PID in your logs)? Does it go wrong with a `puppet agent --test` run? Are there any other rubies or Augeas gems installed that could be interfering? Puppet's --debug will report the Augeas version number.
Hi Dominic, > Have you restarted the Puppet agent since Augeas was upgraded (it's a low PID in your logs)? Shame on me, I didn't: [root@fc-17-i386-1 log]# ps aux | grep pupp root 634 0.1 1.4 136280 122664 ? Ssl Jan01 52:07 /usr/bin/ruby /usr/sbin/puppetd I've just rebooted this host and now everything seems to be working fine again... However, was I actually supposed to? I was thinking that unattended upgrades should be safe and whatever gets upgraded will notify the daemons as needed by issuing a condrestart. So, I guess either this is an INVALID or something should be done about restarting Puppet after augeas-libs upgrade? In any case, thank you very much for your invaluable help so far!
(In reply to comment #7) > However, was I actually supposed to? I was thinking that unattended upgrades > should be safe and whatever gets upgraded will notify the daemons as needed > by issuing a condrestart. > > So, I guess either this is an INVALID or something should be done about > restarting Puppet after augeas-libs upgrade? I think that would be a pragmatic idea. David? > In any case, thank you very much for your invaluable help so far! You're welcome.
The same thing is affecting all my EL5 servers, but not the EL6 ones strangely enough. Restarting the client puppet agents fixes the issue. The puppetmaster is EL5, but so far I haven't had to restart it.
(In reply to comment #9) > The same thing is affecting all my EL5 servers, but not the EL6 ones > strangely enough. Restarting the client puppet agents fixes the issue. The > puppetmaster is EL5, but so far I haven't had to restart it. EPEL6 doesn't provide Augeas as it's part of EL6 instead, so a new version hasn't been shipped (yet). The issue is there are incompatible changes in the lenses on disk from 0.9.0 to 1.0.0, so running 0.9.0 (which is still loaded in memory) against new 1.0.0 lenses on disk causes the initialisation failure. puppetmasters are unaffected as Augeas only runs in the agent.
I believe the right solution would be a trigger on the puppet package that causes a restart of puppetd whenever augeas is updated.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.