Re: [Puppet Users] facter identifies Oracle Linux 6.1 as 'RedHat'
OEL 6.1 now has these 'release' files: $ ll /etc/*release* -rw-r--r--. 1 root root 32 May 22 20:15 /etc/oracle-release -rw-r--r--. 1 root root 55 May 22 20:15 /etc/redhat-release lrwxrwxrwx. 1 root root 14 Jul 22 16:36 /etc/system-release -> oracle-release -rw-r--r--. 1 root root 45 May 22 20:15 /etc/system-release-cpe Contents (notice the disappearance of 'Enterprise', making it 'OL' now): $ cat /etc/*release* Oracle Linux Server release 6.1 Red Hat Enterprise Linux Server release 6.1 (Santiago) Oracle Linux Server release 6.1 cpe:/o:oracle:oracle_linux:6server:ga:server -Jim On Aug 22, 2011, at 7:32 PM, Nan Liu wrote: > On Mon, Aug 22, 2011 at 3:58 PM, Jeffrey wrote: >> Noticed today that facter-1.6.0 is reporting Oracle Linux 6.1 as >> "RedHat". Needless to say, this will cause logic errors in manifests >> trying to distinguish these two OSes. Anyone have a good idea for a >> work-around? >> >> # facter | egrep oper >> operatingsystem => RedHat >> operatingsystemrelease => 6.1 >> >> # cat /etc/issue >> Oracle Linux Server release 6.1 >> Kernel \r on an \m >> >> # facter -version >> 1.6.0 > > Don't have access to OEL 6.1, however the facter code seems really > straightforward: > > 40 elsif FileTest.exists?("/etc/enterprise-release") > 41 if FileTest.exists?("/etc/ovs-release") > 42 "OVS" > 43 else > 44 "OEL" > 45 end > > I'm presuming that's no longer available on 6.1? If facter is > detecting RedHat, it's finding the file /etc/redhat-release, what's > the content of that file? > > Thanks, > > Nan > > -- > 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] require inside define
If I understand the docs correctly, the 'require' inside this define should be satisfied before 'User' is evaluated. Except that's not what's happening; instead, 'User' is being evaluated first and then the require is being satisfied. Am I missing/misunderstanding something about how this should work? Context: Using ssh::auth, when a user account is to be made 'absent' one needs to delete the ssh key-pair before the user account is deleted, else the ssh::auth commands fail due to unknown user. ssh::auth requires the user be realized first, so I've intentionally removed 'ensure' from the users.pp file in order to manipulate that attribute separately. (All users are virtual, as well.) The idea here is to cause the ssh::auth 'delete' commands to happen first, then realize the user with ensure explicitly set to 'absent' (whereas before it was implicitly set to 'present'). There's more detail I could provide but first I just wanted to see if I'm misunderstanding the order of evaluation I should expect. -Jim site.pp: define nukeuser ($ensure = 'absent') { require users::admin::absent User <| title == $title |> { ensure => 'absent' } } class file: class users::admin::absent inherits users::virtual::admin { # Removes private/public key pair from puppet client machines. sshclientuser { [$sshusers_disable]: ensure => 'absent' } # clientdisable sshserveruser { [$sshusers_disable]: ensure => 'absent' } # serverdisable } $sshusers_disable = [ 'bob', 'alice' ] -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to bring about serialization in puppet ?
On Apr 15, 2010, at 1:30 AM, Mayank wrote: > Hi, >I'm trying to manage some hosts using a single puppetmaster. I > don't know why but puppet on clients seems to be executing the recipes > hosted on puppetmaster in a random order which is breaking apart > dependencies and resulting in a failed run of puppet for first time. > If I do multiple run of puppet thru puppetd --test, everything gets > installed and configured properly. However it's very rare that on > first run I can see puppet managing the configuration and installation > without fail. > Is there any way I can bring about serial execution of puppet > recipes. What I mean by serial execution is that suppose I've a > site.pp with following content: > > package {"ruby-devel": ensure=>latest} > package {"rubygems": ensure=>latest} > exec {"install-mysql-gem": > command=>'gem install mysql', > path=>"/bin:/usr/bin:/usr/sbin:/sbin", > require=>[ Package["ruby-devel"], Package["rubygems"]] > } > > Now in many cases puppet tries to execute Exec["install-mysql-gem"] > before Package["ruby-devel"] or Package["rubygems"] or both. > > Is there a way that I can ensure that puppet renders the file in order > the script is written ? > > BTW I'm using CentOS 5.4 with puppet-server-0.24.5-1.el5 and > puppet-0.24.5-1.el5. > > Regards, > Mayank I posted about this exact thing yesterday (Subj: require inside define), only you actually got replies. :) In my case, it seems as though there's something deep in the heart of Puppet that always causes 'realize'd resources (User, in this case) to be promoted to the top of the task list. The User line gets eval'd before everything else regardless of how many 'require's I put in front of it. One difference, though, is that I'm using 0.25.4 from the EPEL repo. -Jim -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] 2.6.0rc3 ssh_authorized_users/parsed.rb
Hi all, Full path: /usr/lib/ruby/site_ruby/1.8/puppet/provider/ssh_authorized_key/parsed.rb Two problems: 1) Even if filebucketing is disabled, this (still) tries to backup authorized_keys to /var/lib/puppet/clientbucket/[...]; no other modules are doing filebucketing when it's disabled but they (correctly) do when it is enabled. 2) The filebucketing is (still) being done with euid set to the user that owns the authorized_keys file, which means it fails since a normal user could never write to /var/lib/puppet. I don't know enough ruby to be more detailed than that. The original line 64 in the file above is: Puppet::Util::SUIDManager.asuser(@resource.should(:user)) { super } The equivalent line didn't work in 0.25.4 or 0.25.5 and it still doesn't work in 2.6.0rc3 (RHEL5.5, rpm from tmz.fedoraproject.org). If I replace line 64 with the following line, it all works nicely. Of course, the real problem is that it shouldn't be trying to filebucket in the first place when that feature is disabled. The only reason I turned off filebucket at all was to try to get this working and, well, it continued to try to filebucket, rather annoyingly. :) Puppet::Util::SUIDManager.asuser('root') { super } Am I perhaps doing something wrong or do one or both of these appear to be a genuine bug(s)? -Jim Here's the stack trace from puppetd -d output (filebucket is currently enabled; the output doesn't change when filebucket is disabled): notice: /Stage[main]//Sshuser[someuser]/Ssh::Auth::key[someu...@here.com]/ssh_auth_key_server[someu...@here.com]/ssh_authorized_key[someu...@here.com]/ensure: created debug: Flushing ssh_authorized_key provider target /home/someuser/.ssh/authorized_keys info: FileBucket got a duplicate file /home/someuser/.ssh/authorized_keys ({md5}d41d8cd98f00b204e9800998ecf8427e) err: /Stage[main]//Sshuser[someuser]/Ssh::Auth::key[someu...@here.com]/ssh_auth_key_server[someu...@here.com]/ssh_authorized_key[someu...@here.com]: Could not evaluate: Could not back up /home/someuser/.ssh/authorized_keys: Permission denied - /var/lib/puppet/clientbucket/d/4/1/d/8/c/d/9/d41d8cd98f00b204e9800998ecf8427e/paths notice: /Stage[main]//Sshuser[otheruser]/Ssh::Auth::key[otheru...@here.com]/ssh_auth_key_server[otheru...@here.com]/ssh_authorized_key[otheru...@here.com]/ensure: created debug: Flushing ssh_authorized_key provider target /home/someuser/.ssh/authorized_keys /usr/lib/ruby/1.8/fileutils.rb:1404:in `stat' /usr/lib/ruby/1.8/fileutils.rb:1404:in `fu_same?' /usr/lib/ruby/1.8/fileutils.rb:1378:in `fu_each_src_dest' /usr/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest0' /usr/lib/ruby/1.8/fileutils.rb:1377:in `fu_each_src_dest' /usr/lib/ruby/1.8/fileutils.rb:382:in `cp' /usr/lib/ruby/site_ruby/1.8/puppet/util/filetype.rb:109:in `write' /usr/lib/ruby/site_ruby/1.8/puppet/util/filetype.rb:56:in `real_write' /usr/lib/ruby/site_ruby/1.8/puppet/util/filetype.rb:56:in `write' /usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:95:in `flush_target' /usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:69:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:67:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:67:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/provider/parsedfile.rb:339:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/provider/ssh_authorized_key/parsed.rb:64:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/util/suidmanager.rb:62:in `asuser' /usr/lib/ruby/site_ruby/1.8/puppet/provider/ssh_authorized_key/parsed.rb:64:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:628:in `flush' /usr/lib/ruby/site_ruby/1.8/puppet/transaction/resource_harness.rb:93:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:49:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:114:in `eval_children_and_apply_resource' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:92:in `eval_resource' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:143:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:414:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:413:in `thinmark' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:142:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:135:in `each' /usr/lib/ruby/site_ruby/1.8/puppet/transaction.rb:135:in `evaluate' /usr/lib/ruby/site_ruby/1.8/puppet/resource/catalog.rb:144:in `apply' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:152:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:175:in `benchmark' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/1.8/benchmark.rb:307:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:174:in `benchmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:151:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:21:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:39:in `run' /usr/l
Re: [Puppet Users] 2.6.0rc3 ssh_authorized_users/parsed.rb
Done. http://projects.puppetlabs.com/issues/4266 http://projects.puppetlabs.com/issues/4267 Also: for those that've never gone through this process before (such as me), could use a hint somewhere on the bugtracker (at least on the "Issues" page) that you need to register to create a new issue. Since the "New Issue" link doesn't show up at all until you've registered and signed in, it's not obvious at all that's what needs to be done. That said, it's possible I missed the hint, though I did look around pretty thoroughly. -Jim On Jul 16, 2010, at 10:21 PM, Peter Meier wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > >> Am I perhaps doing something wrong or do one or both of these appear >> to be a genuine bug(s)? > > I would say these are 2 bugs, can you file the reports? Thanks. > > cheers pete > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxBPfIACgkQbwltcAfKi3/mnwCeMJib4/HZk2KBpUHyC7EhRDIe > WGIAnjnb6KxbMtnCCZXhmfh8WcTzOWbV > =Hljb > -END PGP SIGNATURE- > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] 2.6.0rc3 ssh_authorized_users/parsed.rb
At least to me, the optimal placement would be under the "New Issue" tab, which is always there regardless of login status. If you aren't logged in, it says, "Please login or register for an account to create a new issue." Just seems counterintuitive to hide the tab/link. -Jim On Jul 17, 2010, at 2:08 PM, James Turnbull wrote: > Jim Bala wrote: >> Also: for those that've never gone through this process before (such >> as me), could use a hint somewhere on the bugtracker (at least on the >> "Issues" page) that you need to register to create a new issue. >> Since the "New Issue" link doesn't show up at all until you've >> registered and signed in, it's not obvious at all that's what needs >> to be done. That said, it's possible I missed the hint, though I did >> look around pretty thoroughly. >> > > It's mentioned on the bottom of the home page but I can how it might > have been missed. I will call it out more clearly. > > Regards > > James Turnbull > > -- > Puppet Labs - http://www.puppetlabs.com > C: 503-734-8571 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] facter fails to recognize OEL/OVS in operatingsystemrelease.rb
For the benefit of those running OEL (Oracle Enterprise Linux) or OVS, be aware that under 2.6.0rc4 facter doesn't properly recognize OEL in /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb. A diff for a fix is below; probably not the best fix but if you need it work now, this'll do it for you. I've already filed a bug: http://projects.puppetlabs.com/issues/4289 -Jim *** /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb.orig 2010-07-19 12:34:26.0 -0700 --- /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb 2010-07-19 12:33:25.0 -0700 *** *** 1,5 Facter.add(:operatingsystemrelease) do ! confine :operatingsystem => %w{CentOS Fedora oel ovs RedHat} setcode do case Facter.value(:operatingsystem) when "CentOS", "RedHat" --- 1,5 Facter.add(:operatingsystemrelease) do ! confine :operatingsystem => %w{CentOS Fedora oel OEL ovs OVS RedHat} setcode do case Facter.value(:operatingsystem) when "CentOS", "RedHat" *** *** 8,15 --- 8,19 releasefile = "/etc/fedora-release" when "oel" releasefile = "/etc/enterprise-release" + when "OEL" + releasefile = "/etc/enterprise-release" when "ovs" releasefile = "/etc/ovs-release" + when "OVS" + releasefile = "/etc/ovs-release" end File::open(releasefile, "r") do |f| line = f.readline.chomp -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] ssh_authorized_key and the .ssh directory
Overrides like this work for me: User <| title == $title |> { password => '*LK*', shell => "/bin/false" } You could try: Ssh_authorized_key <| title == nagios |> { require => [ Group["nagios"], User["nagios"], ], } However, I showed this syntax to Jeff McCune and he said something to the effect of, "Huh, *that's* interesting." So, you know... your mileage may vary. :) -Jim On Mon, Apr 4, 2011 at 12:52 PM, Forrie wrote: > I've been working with a file of virtual users that I want to > "realize" on certain hosts. For one of these, I need an > authorized_keys file. After experimenting with the resource > ssh_authorized_key, I thought I could create a dependency relationship > like this: > > Ssh_authorized_key <| title == nagios |> -> Group <| title == > nagios |> -> User <| title == nagios |> > > which doesn't work. The logic being that there's no sense in > manifesting the ssh_authorized_key unless the dependencies of the > group and user are present. > > What am I doing wrong? > > I can realize the ssh_authorized_key separately, but it stands on its > own and will likely fail if the aforementioned dependencies disappear. > > I also noticed that it creates the .ssh directory owned by "username" > and group "root" -- but I don't see a directive to manage that. > > Can someone clarify how to best accomplish this? > > > Thanks. > > -- > 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.