Re: [Puppet Users] facter identifies Oracle Linux 6.1 as 'RedHat'

2011-08-22 Thread Jim Bala
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

2010-04-14 Thread Jim Bala
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 ?

2010-04-15 Thread Jim Bala
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

2010-07-16 Thread Jim Bala
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

2010-07-17 Thread Jim Bala
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

2010-07-17 Thread Jim Bala
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

2010-07-19 Thread Jim Bala
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

2011-04-04 Thread Jim Bala
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.