[Puppet Users] Re: Cannot create authorized key and user in the same go?

[Peter Meier]

Hi

> class users {
> 
>   user { "ben" :
> ensure => present,
> uid => 1010,
> gid => "users",
> managehome => true,
> password => "blahblah"
>   }
> 
>  ssh_authorized_key { "ben-key":
>ensure => present,
>key=> "blahblah",
>type => "ssh-dss",
>user => "ben",
>  }
> 
> }
> 
> This doesn't work, not even in the 'run it twice' kind of way:
> Nov 11 23:49:04 mgmt puppetd[20300]: Could not create ben-key: user
> ben doesn't exist
> Nov 11 23:49:04 mgmt puppetd[20300]: Configuration could not be
> instantiated: user ben doesn't exist
> 
> Commenting out the key will create the user, and uncommenting it after
> user creation will create the key.  Am I missing something painfully
> obvious?


you have to specify relationship between these 2 resources. This means
that the ssh_authorized_key needs a require => User['ben']

cheers pete

--~--~-~--~~~---~--~~
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] facter inconsistent results

[Andrew Schulman]

Hi.  I'm running facter 1.5.1 in Ubuntu Jaunty.  facter is giving me
inconsistent results for the operatingsystem fact:

$ facter operatingsystem
Debian

$ facter | grep operatingsystem
operatingsystem => Ubuntu
operatingsystemrelease => 9.04

Is this a known problem?  Possibly fixed in a more recent release?  I
searched the list for it and didn't see any reports of this.

Thanks,
Andrew.

--~--~-~--~~~---~--~~
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] Recipes/Authorized_keys problem.

[Adam Steffes]

Hello. I am configuring my puppetmaster with the authorized_keys
management recipe from the recipes repository on the Puppet site. So
far, it does what it should *except* generate a keypair for new users,
and I'm unsure of how to proceed from here. Any suggestions would be
greatly appreciated.

I have used the recipe as-is from 
http://reductivelabs.com/trac/puppet/wiki/Recipes/Authorized_keys

 Adding one user ("newguy" in this example), my puppet client produces
the following debug output:

a...@platform2:~$ sudo puppetd --server platform2 --test --verbose --
debug --waitforcert 60
debug: Creating default schedules

debug: Creating default schedules
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Could not find
dependency File[/home/newguy/] for Exec[Building /home/newguy/.ssh/
authorized_keys] at /etc/puppet/manifests/definitions/sshkeygen:37

Which seems odd because the user's account and home directory do
exist. In this example, the puppet client and puppetmaster are the
same machine. I can reproduce the problem with a second machine as the
client, as well.

definitions/sshkeygen lines 31-37 contain:

exec { "Building $authorized_keys":
command   => "cp $public_key $authorized_keys",
creates   => $authorized_keys,
subscribe => File[$public_key],
require   => [ User[$name], File[$public_key], File["$
{homeroot}/$name/"], File["${homeroot}/$name/.ssh"] ],
}


--~--~-~--~~~---~--~~
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] Re: Cannot create authorized key and user in the same go?

[M F Haris]

Ben Lavender schrieb:
> Hi,
>
> I'm trying to create an authorized key and a user in one go and I'm
> not getting anywhere:
>
> class users {
>
>   user { "ben" :
> ensure => present,
> uid => 1010,
> gid => "users",
> managehome => true,
> password => "blahblah"
>   }
>
>  ssh_authorized_key { "ben-key":
>ensure => present,
>key=> "blahblah",
>type => "ssh-dss",
>user => "ben",
>  }
>
> }
>
> This doesn't work, not even in the 'run it twice' kind of way:
> Nov 11 23:49:04 mgmt puppetd[20300]: Could not create ben-key: user
> ben doesn't exist
> Nov 11 23:49:04 mgmt puppetd[20300]: Configuration could not be
> instantiated: user ben doesn't exist
>
> Commenting out the key will create the user, and uncommenting it after
> user creation will create the key.  Am I missing something painfully
> obvious?
>
> Puppet 24.8 on SUSE 11.  I've pared the configuration down to only
> this; nothing else is going on.
>
> Thanks,
> Ben
> >
>   
I tried following Recipe 
http://reductivelabs.com/trac/puppet/wiki/Recipes/Authorized_keys and 
its working;
I think first you need to create .ssh directory in the home directory of 
every user, then create the public key in this directory (say 
/home/ben/.ssh/id_rsa.pub) and then generate the ssh key.
try out the recipe and if it won't work then try to separate the AddUser 
process and GenerateKey process in separate functions.

--~--~-~--~~~---~--~~
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] Re: Recipes/Authorized_keys problem.

[Peter Meier]

> Which seems odd because the user's account and home directory do
> exist. In this example, the puppet client and puppetmaster are the
> same machine. I can reproduce the problem with a second machine as the
> client, as well.

do exists, means that you have an actual file-resource managing it? If
not then you should have one, otherwise you can't specify a relationship.

Are you using 0.25? Then you might also hit a current bug where traling
slashes are stripped of but not in relationships. So you might want to
change File["${homeroot}/$name/"], to File["${homeroot}/$name"],

cheers pete

--~--~-~--~~~---~--~~
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] Re: Recipes/Authorized_keys problem.

[Peter Meier]

> Are you using 0.25? Then you might also hit a current bug where traling
> slashes are stripped of but not in relationships. So you might want to
> change File["${homeroot}/$name/"], to File["${homeroot}/$name"],

ftr: http://projects.reductivelabs.com/issues/2675

cheers pete

--~--~-~--~~~---~--~~
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] Re: Cannot create authorized key and user in the same go?

[Arto Bendiken]

On Nov 12, 11:51 am, Ben Lavender  wrote:
>
> > you have to specify relationship between these 2 resources. This means
> > that the ssh_authorized_key needs a require => User['ben']
>
> This is not the issue; specifying the relationship manually does not
> solve the problem.  Further, the docs state that the require => User
> [$user] is implicit with the user argument.

Perhaps bug #2487 is relevant?

http://projects.reductivelabs.com/issues/2487

--
Arto Bendiken | http://ar.to/

--~--~-~--~~~---~--~~
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] Re: how to manage a service that enables a cron

[Arnau Bria]

Hi all,

I would not like to confuse people.

What I described in OT only happens to pakiti service and not to yum.
So I suppose it's a "service" specific problem. It has its own init
script but must behaves diff from standrd RH service.



Cheers,
Arnau

--~--~-~--~~~---~--~~
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] how to manage a service that enables a cron

[Thomas Bellman]

Arnau Bria wrote:

> # /etc/init.d/pakiti status
> nightly pakiti update is enabled
> # /etc/init.d/pakiti stop
> Disabling pakiti:  [  OK  ]
> # /etc/init.d/pakiti status
> nightly pakiti update is disabled

Now try this:

 # /etc/init.d/pakiti start
 # /etc/init.d/pakiti status; echo $?
 # /etc/init.d/pakiti stop
 # /etc/init.d/pakiti status; echo $?

The status command should return 0 when the service is "running",
but 3 when it is not.  Init scripts not doing so is a fairly common
problem.  The vast majority of the packages in RHEL and CentOS do
the right thing, and if you find one that doesn't, you can file a
bug report with RedHat about it.  Init scripts from other sources
are not always so well behaved though...


/Bellman

--~--~-~--~~~---~--~~
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] Managing 'services' (daemons) in AIX Client

[M F Haris]

Dear all,
I want to manage services in my AIX node. I mean i can start/stop 
service using
exec { command => "/etc/rc/blah-service start",} but i like this to be 
done by puppet itself with its type reference 'service'.

has anyone manage the services on AIX machine ??? if yes, please share it!

PS: All services in my AIX nodes are located to different runlevels 
(rc.something) .


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
-~--~~~~--~~--~--~---

[Puppet Users] Puppet Not Running chkconfig correctly.

[Thomas Bellman]

jcbollinger wrote:

> On Nov 10, 10:13 am, Thomas Bellman  wrote:
>> The problem is that 'chkconfig  on' does an implicit add of
>> the service; but it does a half-assed job, in that it only adds the
>> start links, not the kill links.  Thus, it is very easy to get into
>> the broken state by doing a 'chkconfig --del ', followed by
>> 'chkconfig  on'.  I get exactly that behaviour for e.g.
>> the puppetmaster service when I try.  I didn't expect that.

> Why did you have any particular expectation for that scenario at all,
> though?  I agree that chkconfig has some quality-of-implementation
> issues, but the bottom line is that it has no documented behavior for
> the scenario you describe.  If you want predictable, stable results
> then you should stick to the documented behaviors of your tools.

I expected it to either give me an error message about the service
needing to be --add:ed, or to do a proper --add itself.  I actually
expected it to give me an error message.

The problem is not that I knowingly did a 'chkconfig  on'
without a --add before; it is that I *forgot* to do a --add on a
homemade init script, or relied on Puppet to do it for me (which
it did in earlier versions), or I used Puppet to disable the service,
which earlier did a --del on the service, but now have decided to
enable it again when Puppet no longer does a --add.

It is too easy to get into this state without any indication that
something is amiss.  And it probably even works (i.e the service
gets up and running automatically again after the reboot) in the
majority of cases, so usually you don't see any symptoms either.
It's bad interface design.

> Following the principle of exercising only documented behavior, I
> think Puppet's "redhat" service provider should recognize only those
> services reported by chkconfig --list.  That would prevent Puppet from
> causing a misconfiguration by turning on a service not already managed
> by chkconfig.  If an ability to register a service with chkconfig is
> needed (not clear to me that it is), then that should be controlled by
> a separate parameter.

I would be fine with that.  As long as I get an error message when I
try to do something stupid, I'm content.  (And as long as it is OK to
try to *disable* a service that doesn't exist.)

However, I think it would be slightly better if Puppet did a chkconfig
--add on services you enable (and documented this!), since I can't think
of a situation where you don't want that behaviour, but plenty where you
*do* wan't to --add.  Sure, you can do the --add yourself with an exec,
but it is more convenient if the service type does it automatically.

> And for what it's worth, I never use chkconfig --del unless I'm
> removing the service from the system altogether.  If for some reason I
> need to leave a service on the system that must never automatically
> run, then I chkconfig --level 0123456  off.  YMMV.

Likewise.  Unless I use earlier versions of Puppet, which did a --del
when I asked it to disable the service.  But I *do* occasionally install
my own init scripts using a file resource.


/Bellman

--~--~-~--~~~---~--~~
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] Re: Puppet Not Running chkconfig correctly.

[jcbollinger]

On Nov 11, 12:18 pm, David Schmitt  wrote:
> As a debianista I obviously haven't touched chkconfig ever. But in the
> spirit of DWIM, I would expect a provider to do the magic to get (in
> this case) an init-script under the control of the chosen tool.

I'd be happier with that plan if the WIM were less ambiguous.  I'm
with Bellman in that I would have expected Puppet to issue an error in
such cases, so for me, that's part of WIM.  I'd be OK with Puppet auto-
registering the service with chkconfig, provided that there were a
switch to toggle that behavior.

Bellman's observation that Puppet's redhat provider changed from using
chkconfig's --add / --del modes to using its --on / --off modes makes
me want even more to see finer-grained runlevel control. The --add
mode, if it does anything, will configure the service to run in
whatever are its default runlevels (commonly 345, but sometimes 2345
and occasionally something else).  On the other hand, the --on mode
without specifying particular runlevels always sets the service to run
in levels 2345 (and ignores its run status for other levels).  Puppet
has no mechanism, with any Service provider, to manage in precisely
which runlevels a service will run.  This is bad, because there are
numerous services that should run in levels 345, but not in level 2.


John

--~--~-~--~~~---~--~~
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] Re: how to manage a service that enables a cron

[jcbollinger]

On Nov 11, 10:13 am, Arnau Bria  wrote:
> I'm just trying to control a service that does not run a process but
> enables a cron (like yum autoupdate or pakiti).

What Bellman said.  Puppet is limited in what it can do for you if
your initscipt's status command doesn't return an accurate status.

If you have a broken initscript and you can't fix it / get it fixed,
then there are alternatives:
1) Live with the error.  Puppet will try to "start" the service every
time it runs.  If afterward it double-checks that the service is
running (I'm uncertain whether it does) then it will report an error.
As long as nothing else has a declared dependency on the Service then
such an error can probably be ignored.

2) You may be able to configure the Service so that Puppet doesn't
manage whether or not it's running.  Try leaving out the "ensure"
parameter, and if that doesn't work then try setting it to undef
(ensure => undef).  The idea is that Puppet will manage the links in /
etc/rc*.d/, but it won't try to start (or stop) the service.

With that said, it would be far better to use a correct initscript .


John
--~--~-~--~~~---~--~~
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] Re: how to manage a service that enables a cron

[Arnau Bria]

Hi Thomas,

that's the problem

all status return code is 0...

Thanks, going to contact developer and see if he accepts a patch.

Cheers,
Arnau

--~--~-~--~~~---~--~~
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] Creating Multiple Users in IBM AIX

[M F Haris]

hi all,
I am trying to create a set of users on my AIX node and trying to get 
their authorized_keys which are already hosted on my server with name 
like, myuser_id_ds.pub. Currently i am managing 2 nodes (1. Suse 
Enterprise  2. AIX). I defined the 'source' file paths in 2 separate 
contexts in fileserver.conf;

[AIX]
path myfiles/users/ssh/
allow *.another.mydomain.com
[SLES]
   path myfiles/users/*keys*/ssh/
allow *.mydomain.com

but when I run puppet then it ended successfully on my SLES node but 
encountered failure on AIX node; with following err;

/* Could not describe _/AIX/_id_rsa.pub.rkramer: Fileserver module 'AIX' 
not mounted*/

in my code i have defined the 'source' with $filserver variable  as:

case $operatingsystem {
"AIX": { $fileserver = "AIX" }
default: { $fileserver = "SLES" }
}

file { "${home}/${username}/.ssh/authorized_keys":
source => "puppet:///$fileserver/$pub_key.${username}",

}

why AIX is not able to get the source path from my fileserver.conf while 
SLES is running absolutely fine? and how can I do it? I have to run 
similar configuration across different servers so I can only deal it 
with case statement.

looking forward for your help

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
-~--~~~~--~~--~--~---

[Puppet Users] Re: Behavior Driven Infrastructure

[Patrick Debois]

FYI: for those looking for examples and more discussions.

I've put my collection of infrastructure testing links online:
http://www.jedi.be/blog/2009/11/12/collection-of-test-driven-infrastructure-links/



--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[Christopher Webber]

We treat zones like normal nodes for the most part. There is a  
separate base class that is zone specific but otherwise we don't do  
things any differently.

-- cwebber

On Nov 12, 2009, at 8:28 AM, windowsrefund wrote:

>
> Getting past zone creation, I'm curious to know how people are
> managing zone-specifics like users, packages, and services.
>
> Looking forward to this thread...
>
> Adam
> >


--~--~-~--~~~---~--~~
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] Opensolaris: beyond zones

[windowsrefund]

Getting past zone creation, I'm curious to know how people are
managing zone-specifics like users, packages, and services.

Looking forward to this thread...

Adam
--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[windowsrefund]

On Nov 12, 11:32 am, Christopher Webber  wrote:
> We treat zones like normal nodes for the most part. There is a  
> separate base class that is zone specific but otherwise we don't do  
> things any differently.
>

So each zone runs a puppet client?
--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[windowsrefund]

On Nov 12, 11:32 am, Christopher Webber  wrote:
> We treat zones like normal nodes for the most part. There is a  
> separate base class that is zone specific but otherwise we don't do  
> things any differently.
>

So each zone runs a puppet client?
--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[Christopher Webber]

Yes.

-- cwebber

On Nov 12, 2009, at 8:55 AM, windowsrefund wrote:

>
>
>
> On Nov 12, 11:32 am, Christopher Webber  wrote:
>> We treat zones like normal nodes for the most part. There is a
>> separate base class that is zone specific but otherwise we don't do
>> things any differently.
>>
>
> So each zone runs a puppet client?
> >


--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[windowsrefund]

That's not an option for me as I'm already planning on managing a few
hundred physical nodes. Any other approaches out there?

Thanks,
Adam
--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[Akins, Brian]

On 11/12/09 12:10 PM, "windowsrefund"  wrote:

> That's not an option for me as I'm already planning on managing a few
> hundred physical nodes. Any other approaches out there?

We manage a few thousand.  We generally operate on "groups" (as defined in
our external nodes classifier) and never on individual nodes.  We are also
integrating puppet into various virtualization platforms, and just treat all
guests as "nodes."

-- 
Brian Akins


--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[windowsrefund]

Brian,

Can you be more specific? For example, how would you go about ensuring
that apache is running inside a non-global zone?
--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[Akins, Brian]

On 11/12/09 1:36 PM, "windowsrefund"  wrote:

> Can you be more specific? For example, how would you go about ensuring
> that apache is running inside a non-global zone?

The same as we do on any node. Service ensure running.

-- 
Brian Akins


--~--~-~--~~~---~--~~
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] Re: Recipes/Authorized_keys problem.

[Adam Steffes]

On Nov 12, 2:35 am, Peter Meier  wrote:
> > Which seems odd because the user's account and home directory do
> > exist. In this example, the puppet client and puppetmaster are the
> > same machine. I can reproduce the problem with a second machine as the
> > client, as well.
>
> do exists, means that you have an actual file-resource managing it? If
> not then you should have one, otherwise you can't specify a relationship.

Hi, Pete. Thank you for your help. I believe the line in definitions/
account manages the /home/username/.ssh/authorized_keys structure. It
looks like this (unmodified from the recipe posted to the Puppet
recipes page):

file {
"${homeroot}/$name":
ensure  => directory,
owner   => $home_owner,
group   => $home_group,
mode=> 750,
require => User[$name];
"${homeroot}/$name/.ssh":
ensure  => directory,
owner   => $home_owner,
group   => $home_group,
mode=> 700,
require => File["${homeroot}/$name"];
"${homeroot}/$name/.ssh/authorized_keys":
ensure  => present,
owner   => "root",
group   => "root",
mode=> 644,
require => File["${homeroot}/$name/.ssh"];
"${homeroot}/$name/.ssh/authorized_keys2":
ensure  => "${homeroot}/$name/.ssh/authorized_keys",
require => File["${homeroot}/$name/.ssh/authorized_keys"],
}

> Are you using 0.25? Then you might also hit a current bug where traling
> slashes are stripped of but not in relationships. So you might want to
> change File["${homeroot}/$name/"], to File["${homeroot}/$name"],

I am using puppet 0.24.8 as packaged with Ubuntu 9.10. I did try
playing with the trailing slash prior to emailing the list and it
didn't seem to matter (and I guess it shouldn't if the bug was in
0.25.)

  -Adam

--~--~-~--~~~---~--~~
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] Re: Opensolaris: beyond zones

[windowsrefund]

Brian,

OK so you're also running a puppet client on each virtual node.

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[Russ Allbery]

Andrew Schulman  writes:

> Hi.  I'm running facter 1.5.1 in Ubuntu Jaunty.  facter is giving me
> inconsistent results for the operatingsystem fact:

> $ facter operatingsystem
> Debian

> $ facter | grep operatingsystem
> operatingsystem => Ubuntu
> operatingsystemrelease => 9.04

> Is this a known problem?  Possibly fixed in a more recent release?  I
> searched the list for it and didn't see any reports of this.

This sort of thing is a common problem with facter caused by the fact that
facter doesn't load all plugins unless you run it without options.  I
think there may have been some subsequent work to improve this, but I'm
not sure.

-- 
Russ Allbery (r...@stanford.edu) 

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[Nigel Kersten]

On Thu, Nov 12, 2009 at 11:29 AM, Russ Allbery  wrote:

>
> Andrew Schulman  writes:
>
> > Hi.  I'm running facter 1.5.1 in Ubuntu Jaunty.  facter is giving me
> > inconsistent results for the operatingsystem fact:
>
> > $ facter operatingsystem
> > Debian
>
> > $ facter | grep operatingsystem
> > operatingsystem => Ubuntu
> > operatingsystemrelease => 9.04
>
> > Is this a known problem?  Possibly fixed in a more recent release?  I
> > searched the list for it and didn't see any reports of this.
>
> This sort of thing is a common problem with facter caused by the fact that
> facter doesn't load all plugins unless you run it without options.  I
> think there may have been some subsequent work to improve this, but I'm
> not sure.
>

Ugh. This is particularly sucky, and I vote this fact needs to be fixed for
this irrespective of the plugin loading issue.

The problem is:

if Facter.value(:lsbdistid) == "Ubuntu"
   "Ubuntu"
elsif FileTest.exists?("/etc/debian_version")
"Debian"

the first invocation doesn't fill lsbdistid, so it falls through to Debian
when /etc/debian_version exists on Ubuntu.


>
> --
> Russ Allbery (r...@stanford.edu) 
>
> >
>


-- 
nigel

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[Russ Allbery]

Nigel Kersten  writes:

> Ugh. This is particularly sucky, and I vote this fact needs to be fixed
> for this irrespective of the plugin loading issue.

> The problem is:

> if Facter.value(:lsbdistid) == "Ubuntu"
>"Ubuntu"
> elsif FileTest.exists?("/etc/debian_version")
> "Debian"

> the first invocation doesn't fill lsbdistid, so it falls through to
> Debian when /etc/debian_version exists on Ubuntu.

Inside Puppet, this works fine, since Puppet always loads all plugins.  It
really only affects the command-line invocation (although I don't know
what happens if you use facter in a different Ruby program).

-- 
Russ Allbery (r...@stanford.edu) 

--~--~-~--~~~---~--~~
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] Re: conditional restart of service

[Jason Lavoie]

On 10/29, Peter Meier wrote:
> > I'm trying to have a exec dependency on a service object that would keep
> > it from being restarted if the exec fails.  Unfortunately, the service
> > gets refreshed regardless whenever the exec is run, failure or not.
[...]
> 
> don't set the command to refreshonly. this will trigger the exec only if
> it get triggered by someone else otherwise the resource counts as
> successful.

That doesn't seem to help.  Here's a simpler test manifest:

service { dep:
hasstatus => true, status => "/bin/true status",
start => "/bin/true start", stop => "/bin/true stop",
subscribe => File["/tmp/dep"],
require => Exec["check-dep"],
}

exec { "check-dep":
command => "exit 1",
path => "/bin",
subscribe => File["/tmp/dep"],
}

file { "/tmp/dep":
content => "foo",
}

Shouldn't the "Skipping because of failed dependencies" in the output
below be absolute?  Why is puppet still refreshing the Service[dep]
(in the very next log line)?  Am I misunderstanding how the dependencies
should work?

-j


$ puppet --version
0.24.8
$ puppet --debug dep.pp 
[...]
debug: //Service[dep]/require: requires Exec[check-dep]
debug: //Service[dep]/subscribe: subscribes to File[/tmp/dep]
debug: //Exec[check-dep]/subscribe: subscribes to File[/tmp/dep]
debug: //File[/tmp/dep]: File does not exist
debug: //File[/tmp/dep]/checksum: Initializing checksum hash
debug: //File[/tmp/dep]: Changing content
debug: //File[/tmp/dep]: 1 change(s)
debug: //File[/tmp/dep]: Creating checksum {md5}acbd18db4cc2f85cedef654fccc4a4d8
notice: //File[/tmp/dep]/content: defined 'content' as 
'{md5}acbd18db4cc2f85cedef654fccc4a4d8'
info: //File[/tmp/dep]: Scheduling refresh of Service[dep]
info: //File[/tmp/dep]: Scheduling refresh of Exec[check-dep]
debug: //Exec[check-dep]: Changing returns
debug: //Exec[check-dep]: 1 change(s)
debug: //Exec[check-dep]: Executing 'exit 1'
debug: Executing 'exit 1'
err: //Exec[check-dep]/returns: change from notrun to 0 failed: exit 1 returned 
1 instead of 0 at /home/jlavoie/dep.pp:12
notice: //Exec[check-dep]: Triggering 'refresh' from 1 dependencies
debug: //Exec[check-dep]: Executing 'exit 1'
debug: Executing 'exit 1'
err: //Exec[check-dep]: Failed to call refresh on Exec[check-dep]: exit 1 
returned 1 instead of 0 at /home/jlavoie/dep.pp:12
notice: //Service[dep]: Dependency exec[exit 1] has 1 failures
warning: //Service[dep]: Skipping because of failed dependencies
notice: //Service[dep]: Triggering 'refresh' from 1 dependencies
debug: Service[dep](provider=debian): Executing '/bin/true status'
debug: Service[dep](provider=debian): Executing '/bin/true stop'
debug: Service[dep](provider=debian): Executing '/bin/true start'
debug: Finishing transaction -606555348 with 2 changes


-- 
Jason Lavoie
Ratvarre sbe uver
ja...@oasys.net

--~--~-~--~~~---~--~~
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] Re: Managing 'services' (daemons) in AIX Client

[jcbollinger]

On Nov 12, 7:32 am, M F Haris  wrote:
> I want to manage services in my AIX node. I mean i can start/stop
> service using
> exec { command => "/etc/rc/blah-service start",} but i like this to be
> done by puppet itself with its type reference 'service'.
>
> has anyone manage the services on AIX machine ??? if yes, please share it!
>
> PS: All services in my AIX nodes are located to different runlevels
> (rc.something) .

Puppet's Service resource is the right place to look among the built-
in resource types.  Have you tried it?  I haven't any AIX-specific
experience, but Puppet should be able to provide some level of
management.  You could start with something like this:

service { "blah-service":
enable => true,
ensure => "running",
path => "/etc/rc",  # might not be necessary
}

Some or all of these additional properties might be useful: hasstatus,
hasrestart, status, pattern.  There are other knobs you could tweak,
too, but I recommend starting simple.

--~--~-~--~~~---~--~~
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] Re: Crunchies (non-technical email follows)

[Ryan Dooley]

I can get behind that.  Nominated :)


On Nov 12, 2009, at 12:52 AM, Michael T. Halligan wrote:

> 
> I just nominated Reductive Labs for a Crunchie in the "Best Enterprise 
> Startup" category, if only because it's the kind of ridiculous SF startup 
> popularity game that I think would annoy Luke, but in a fun way. Everybody 
> should do it.  It can be done a thttp://crunchies2009.techcrunch.com/vote/
> 
> 
> 
> > 


--~--~-~--~~~---~--~~
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] master/slave

[mcnabb]

I would like to set up two puppetmaster servers, one slaving off the
other.  Can anyone point me towards some documentation for setting it
up?  I've looked, but haven't had any luck finding anything.

--~--~-~--~~~---~--~~
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] Re: autoloader

[Eric Sorenson]

Here are the two go-to points for me:

http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation

http://www.devco.net/archives/2009/09/28/simple_puppet_module_structure.php

-=Eric

On Nov 10, 2009, at 4:38 PM, Allan Marcus wrote:

> 
> CAn someone point me to some documentation on the autoloader? I'm  
> trying to understand the relationship between class name, files names  
> and the import command.
> 
> ---
> Thanks,
> 
> Allan Marcus
> 505-667-5666
> 
> 
> 
> 
> > 


--~--~-~--~~~---~--~~
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] Win32 interest in London

[Paul Nasrat]

I'm looking for people and organisations I can work with in the London
area who can provide tangible problems, alpha test and give feedback
on puppet win32 support in the forthcoming months.

Ideallly you have a heterogenous setup and some specific problems to
solve, and potentially happy to have me occasionally debug things in
your setup.

If you're interested let me know.

Paul

--~--~-~--~~~---~--~~
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] Distinguishing between SLES 10 SP2 and SLES 10 SP3

[Matt Delves]

Hey All,
I'm wondering if there is an easy way to distinguish between SP2 and SP3 on a 
SLES 10 installation.

Thanks,
Matt Delves


--~--~-~--~~~---~--~~
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] Re: Multiple environments

[Scott]

Is anyone using multiple environments?  Can someone at least tell me
what they did to get it working?

Thanks,
Scott

On Nov 12, 6:53 am, Scott  wrote:
> So I'm trying to get multiple environments to work with puppet 0.25.1
> on ubuntu 8.04 and no matter what I do, puppet just completely ignores
> any environment setting.  There's really next to no information in
> terms of configuration on the multiple environments documentation page
> (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments)
> other than saying that the following section should be in my
> puppet.conf file:
>
> [main]
>     manifest   = /usr/share/puppet/site.pp
>     modulepath = /usr/share/puppet/modules
>
> [development]
>     manifest   = /usr/share/puppet/development/site.pp
>     modulepath = /usr/share/puppet/development/modules
>
> There are other references on web pages and groups to an
> "environments" setting under "puppetmasterd" as well as having a
> default "environment" setting in "main" for the clients but I've tried
> all of that and nothing works.  There's also no reference at all to
> any environment in debugging mode when I run "puppetd --test --
> environment=test -d".  Am I missing something?
>
> Here's a copy of my puppet.conf file:
>
> [main]
>     vardir = /var/lib/puppet
>     manifest = /etc/puppet/manifests/site.pp
>     modulepath = /etc/puppet/modules
>     pluginsync = true
>     storeconfigs = true
>     #
>     dbadapter = mysql
>     dbuser = puppet
>     dbpassword = 
>     dbserver = mysql.example.com
>
> [puppetmasterd]
>     certname=puppet.example.com
>
> [testing]
>     manifest=/etc/puppet-testing/manifests/site.pp
>     modulepath=/etc/puppet-testing/modules
>
> [production]
>     manifest=/etc/puppet/manifests/site.pp
>     modulepath=/etc/puppet/modules
>
> Cheers,
> Scott
--~--~-~--~~~---~--~~
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] Re: Multiple environments

[Luke Schierer]

I just had to set the environment variable in the puppet.conf file before 
starting the puppetd daemon.  Then in each class I use that variable to 
determine what happens, for example

file { "smtpd.conf":
owner   => root,
group   => root,
mode=> 600,
source  => $environment ? {
preproduction   => "puppet:///",
test=> "",
production  => "",
},
}

or in other classes, I have if/else blocks based on the $environment variable.  
I am in the 0.24.8 version that EPEL has though, not 0.25.x

Luke

On Nov 12, 2009, at 19:30 EST, Scott wrote:

> 
> Is anyone using multiple environments?  Can someone at least tell me
> what they did to get it working?
> 
> Thanks,
> Scott
> 
> On Nov 12, 6:53 am, Scott  wrote:
>> So I'm trying to get multiple environments to work with puppet 0.25.1
>> on ubuntu 8.04 and no matter what I do, puppet just completely ignores
>> any environment setting.  There's really next to no information in
>> terms of configuration on the multiple environments documentation page
>> (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments)
>> other than saying that the following section should be in my
>> puppet.conf file:
>> 
>> [main]
>> manifest   = /usr/share/puppet/site.pp
>> modulepath = /usr/share/puppet/modules
>> 
>> [development]
>> manifest   = /usr/share/puppet/development/site.pp
>> modulepath = /usr/share/puppet/development/modules
>> 
>> There are other references on web pages and groups to an
>> "environments" setting under "puppetmasterd" as well as having a
>> default "environment" setting in "main" for the clients but I've tried
>> all of that and nothing works.  There's also no reference at all to
>> any environment in debugging mode when I run "puppetd --test --
>> environment=test -d".  Am I missing something?
>> 
>> Here's a copy of my puppet.conf file:
>> 
>> [main]
>> vardir = /var/lib/puppet
>> manifest = /etc/puppet/manifests/site.pp
>> modulepath = /etc/puppet/modules
>> pluginsync = true
>> storeconfigs = true
>> #
>> dbadapter = mysql
>> dbuser = puppet
>> dbpassword = 
>> dbserver = mysql.example.com
>> 
>> [puppetmasterd]
>> certname=puppet.example.com
>> 
>> [testing]
>> manifest=/etc/puppet-testing/manifests/site.pp
>> modulepath=/etc/puppet-testing/modules
>> 
>> [production]
>> manifest=/etc/puppet/manifests/site.pp
>> modulepath=/etc/puppet/modules
>> 
>> Cheers,
>> Scott
> > 


--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[lance dillon]

On Thu, Nov 12, 2009 at 2:36 PM, Russ Allbery  wrote:

>
> Nigel Kersten  writes:
>
> > Ugh. This is particularly sucky, and I vote this fact needs to be fixed
> > for this irrespective of the plugin loading issue.
>
> > The problem is:
>
> > if Facter.value(:lsbdistid) == "Ubuntu"
> >"Ubuntu"
> > elsif FileTest.exists?("/etc/debian_version")
> > "Debian"
>
> > the first invocation doesn't fill lsbdistid, so it falls through to
> > Debian when /etc/debian_version exists on Ubuntu.
>
> Inside Puppet, this works fine, since Puppet always loads all plugins.  It
> really only affects the command-line invocation (although I don't know
> what happens if you use facter in a different Ruby program).
>
>
This looks like more of a result of using grep.

If you call facter with operatingsystem, you are asking for just the
operating system.  If you call facter without any arguments, it gives you
everything, then you are grepping for anything that contains the continuous
stream of letters "operatingsystem", whether or not it is a separate word or
not.  That would happen with any program, facter or not.

--~--~-~--~~~---~--~~
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] Re: Distinguishing between SLES 10 SP2 and SLES 10 SP3

[Michael T. Halligan]

It might be in /etc/suse-release if Facter isn't already picking it up

On Nov 12, 2009, at 2:27 PM, Matt Delves wrote:

> 
> Hey All,
> I'm wondering if there is an easy way to distinguish between SP2 and SP3 on a 
> SLES 10 installation.
> 
> Thanks,
> Matt Delves
> 
> 
> > 


--~--~-~--~~~---~--~~
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] Re: Multiple environments

[Pete Emerson]

Scott,

Multiple environments is working for me under puppet 0.25.1.

I'm not sure what's wrong, but I wonder if having a manifest and
modulepath entry in the [main] part of your puppet.conf is overriding
any sections below. My puppet.conf does not have a manifest or
modulepath entry in [main].

Pete

On Wed, Nov 11, 2009 at 9:53 PM, Scott  wrote:
>
> So I'm trying to get multiple environments to work with puppet 0.25.1
> on ubuntu 8.04 and no matter what I do, puppet just completely ignores
> any environment setting.  There's really next to no information in
> terms of configuration on the multiple environments documentation page
> (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments)
> other than saying that the following section should be in my
> puppet.conf file:
>
> [main]
>    manifest   = /usr/share/puppet/site.pp
>    modulepath = /usr/share/puppet/modules
>
> [development]
>    manifest   = /usr/share/puppet/development/site.pp
>    modulepath = /usr/share/puppet/development/modules
>
> There are other references on web pages and groups to an
> "environments" setting under "puppetmasterd" as well as having a
> default "environment" setting in "main" for the clients but I've tried
> all of that and nothing works.  There's also no reference at all to
> any environment in debugging mode when I run "puppetd --test --
> environment=test -d".  Am I missing something?
>
> Here's a copy of my puppet.conf file:
>
> [main]
>    vardir = /var/lib/puppet
>    manifest = /etc/puppet/manifests/site.pp
>    modulepath = /etc/puppet/modules
>    pluginsync = true
>    storeconfigs = true
>    #
>    dbadapter = mysql
>    dbuser = puppet
>    dbpassword = 
>    dbserver = mysql.example.com
>
> [puppetmasterd]
>    certname=puppet.example.com
>
> [testing]
>    manifest=/etc/puppet-testing/manifests/site.pp
>    modulepath=/etc/puppet-testing/modules
>
> [production]
>    manifest=/etc/puppet/manifests/site.pp
>    modulepath=/etc/puppet/modules
>
>
> Cheers,
> Scott
> >
>

--~--~-~--~~~---~--~~
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] Re: Managing upgrading of puppet recipes

[Pete Emerson]

Here's the solution I wound up using. I created a puppet.conf.erb
template file and had puppet create the puppet.conf file dynamically.

The critical pieces (I only wanted directories starting with v, like
v01, v02, et cetera):

<%
dirs = Dir.entries("/etc/puppet/manifests").sort
-%>

[main]
...
[puppetmasterd]
...
[puppetd]
...

<% for dir in dirs -%>
<% if File.directory?("/etc/puppet/manifests/" + dir) and dir
!= '.' and dir != '..' and dir =~ /^v/ -%>

[<%= dir %>]
manifest = /etc/puppet/manifests/<%= dir %>/site.pp

<% end -%>
<% end -%>

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[Nigel Kersten]

On Thu, Nov 12, 2009 at 4:48 PM, lance dillon  wrote:

>
>
> On Thu, Nov 12, 2009 at 2:36 PM, Russ Allbery  wrote:
>
>>
>> Nigel Kersten  writes:
>>
>> > Ugh. This is particularly sucky, and I vote this fact needs to be fixed
>> > for this irrespective of the plugin loading issue.
>>
>> > The problem is:
>>
>> > if Facter.value(:lsbdistid) == "Ubuntu"
>> >"Ubuntu"
>> > elsif FileTest.exists?("/etc/debian_version")
>> > "Debian"
>>
>> > the first invocation doesn't fill lsbdistid, so it falls through to
>> > Debian when /etc/debian_version exists on Ubuntu.
>>
>> Inside Puppet, this works fine, since Puppet always loads all plugins.  It
>> really only affects the command-line invocation (although I don't know
>> what happens if you use facter in a different Ruby program).
>>
>>
> This looks like more of a result of using grep.
>
> If you call facter with operatingsystem, you are asking for just the
> operating system.  If you call facter without any arguments, it gives you
> everything, then you are grepping for anything that contains the continuous
> stream of letters "operatingsystem", whether or not it is a separate word or
> not.  That would happen with any program, facter or not.
>

This has nothing to do with grep.

facter should report a single consistent value for 'operatingsystem' when
invoked in either of these ways.

It's certainly related to the bigger facter issue of not loading all facts
when you simply ask for one, but the fact (no pun intended) stands that this
should be fixed regardless of the state of that issue.

Andrew, have you put a bug report in about this?


>
> >
>


-- 
nigel

--~--~-~--~~~---~--~~
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] Re: Multiple environments

[Scott]

Pete,

I only put the "modulepath" and "manifest" entries in the "main"
section in an attempt to get environments to work.

So your configuration is working with just a separate section like
[testing] in my puppet.conf?  No "environments" entry in
[puppetmasterd] and just "modulepath" and "manifest" entries?  Or
anything else I might have missed?

Scott


On Nov 13, 2:22 am, Pete Emerson  wrote:
> Scott,
>
> Multiple environments is working for me under puppet 0.25.1.
>
> I'm not sure what's wrong, but I wonder if having a manifest and
> modulepath entry in the [main] part of your puppet.conf is overriding
> any sections below. My puppet.conf does not have a manifest or
> modulepath entry in [main].
>
> Pete
>
> On Wed, Nov 11, 2009 at 9:53 PM, Scott  wrote:
>
> > So I'm trying to get multiple environments to work with puppet 0.25.1
> > on ubuntu 8.04 and no matter what I do, puppet just completely ignores
> > any environment setting.  There's really next to no information in
> > terms of configuration on the multiple environments documentation page
> > (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments)
> > other than saying that the following section should be in my
> > puppet.conf file:
>
> > [main]
> >    manifest   = /usr/share/puppet/site.pp
> >    modulepath = /usr/share/puppet/modules
>
> > [development]
> >    manifest   = /usr/share/puppet/development/site.pp
> >    modulepath = /usr/share/puppet/development/modules
>
> > There are other references on web pages and groups to an
> > "environments" setting under "puppetmasterd" as well as having a
> > default "environment" setting in "main" for the clients but I've tried
> > all of that and nothing works.  There's also no reference at all to
> > any environment in debugging mode when I run "puppetd --test --
> > environment=test -d".  Am I missing something?
>
> > Here's a copy of my puppet.conf file:
>
> > [main]
> >    vardir = /var/lib/puppet
> >    manifest = /etc/puppet/manifests/site.pp
> >    modulepath = /etc/puppet/modules
> >    pluginsync = true
> >    storeconfigs = true
> >    #
> >    dbadapter = mysql
> >    dbuser = puppet
> >    dbpassword = 
> >    dbserver = mysql.example.com
>
> > [puppetmasterd]
> >    certname=puppet.example.com
>
> > [testing]
> >    manifest=/etc/puppet-testing/manifests/site.pp
> >    modulepath=/etc/puppet-testing/modules
>
> > [production]
> >    manifest=/etc/puppet/manifests/site.pp
> >    modulepath=/etc/puppet/modules
>
> > Cheers,
> > Scott
>
>
--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[Andrew Schulman]

> This has nothing to do with grep.
>
> facter should report a single consistent value for 'operatingsystem' when
> invoked in either of these ways.

Agreed.

> Andrew, have you put a bug report in about this?

No, I wanted to check first if I was missing something.  I'll file a
bug report about it.

And, it does occur within puppet-- that's how I noticed it.  I have

case $operatingsystem {
debian: {
$diffutils = ['diffutils', 'diffutils-doc']
}
ubuntu: {
$diffutils = ['diff', 'diff-doc']
}
}

and found that I was getting diffutils (the debian case) on Ubuntu.

Thanks,
Andrew.

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[James Turnbull]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Schulman wrote:
>> This has nothing to do with grep.
>>
>> facter should report a single consistent value for 'operatingsystem' when
>> invoked in either of these ways.
> 

Maybe I am jumping in too late but do you have lsb installed on that
host (lsb-base package from memory I think)?  Because if you don't
then Facter won't return Ubuntu.

Not that we shouldn't refactor that fact but unfortunately Ubuntu is
not an easy system to identify unlike some others.

https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/19353
http://www.debianadmin.com/find-your-debian-or-ubuntu-linux-version-you-are-running.html

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBSvzbbSFa/lDkFHAyAQKTegf/XWD9Hz6MJ31adRiVqH9+sMle1+9tJGHT
b1PrYuafDi+OUXQDMMKksWnxZXx1S63ymW+/ix44i6TU8AOl1ClsCyahL1FdKPER
MP176Ls5zxv4E2F8d04EqsI/BGuT4eBpOhsvldoeWjoN/tx614qat3XSAb0R0srZ
4WJe/c9VJLgOM/HQfHN+OHJXwP7Gj1a4jLhuFy/LAEAr2hjg0np/tLVnRdziDHZg
Lxl4NpzZFH30F/9LC/0v4lpgMyfNlf66tvaLt5Bc/nQa58+plroADeCmSCIvJP65
CrSh7EBzmxGeb2LamQw/HlR1K7C5JA224/1pjkwJbxAuwR2ycRH6BA==
=lmcP
-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-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] Re: facter inconsistent results

[Russ Allbery]

James Turnbull  writes:
> Andrew Schulman wrote:

>>> This has nothing to do with grep.

>>> facter should report a single consistent value for 'operatingsystem' when
>>> invoked in either of these ways.

> Maybe I am jumping in too late but do you have lsb installed on that
> host (lsb-base package from memory I think)?  Because if you don't
> then Facter won't return Ubuntu.

Yeah, I bet that's more likely than my explanation, given that it's also
not working inside Puppet (which doesn't have the plugin problem).
Although that doesn't explain why running facter with grep works

-- 
Russ Allbery (r...@stanford.edu) 

--~--~-~--~~~---~--~~
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] Re: facter inconsistent results

[James Turnbull]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery wrote:
> 
> Yeah, I bet that's more likely than my explanation, given that it's also
> not working inside Puppet (which doesn't have the plugin problem).
> Although that doesn't explain why running facter with grep works
> 

Ah missed that - weird.  That and the Puppet run suggests something
broader is going on.

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBSvzpwSFa/lDkFHAyAQIfPAf/cEA3vvbhQiQzu1CONBrpVwnrcKTELMO9
pet4PFm5pcXAxQp1ZJoQMhTa39hOj1d2CtMmtajYea3++XPLX0+uUNphGAS+iKkr
eESl6vJJHCE5iq4irHaowhrwq5r3GqsktuIwTYcfOqRby+llbRfJtR1YDJVKuOKp
QjfRlYwXfUaLCZsV0necG9/TzFHSR1DLW5wPJKcQONAzLPXWNfzzWWHElgHIGoZF
JnNw1JoMKMkvI4x6cj+FcI17RPPbigopq0BK2MovqM+Plsln/y0d3HO2d73GX3wi
1ahueEtJ6xNK70CyEBW1MjpqXCBOA0Yx0gizmWz5f8gs3RZ0ddJOIw==
=QUgc
-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-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
-~--~~~~--~~--~--~---