Re: [Puppet Users] File updates dumped to Messages File
On Feb 22, 2011, at 4:29 PM, Douglas Garstang wrote: > Here's a weird one. I have a 2.6 server and a 0.24.8 client, and when I run > the puppet client, any files that are being updated by puppet, are having > their entire contents dumped to /var/log/messages. What's up with that? > > Doug You sure it's not just a diff of what changed? If so, take a look at the "show_diff" option. -- 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: auth.conf & namespaceauth.conf : which files belong on the master , and c
so even more wierdness I moved the auth.conf and the namespaceauth.conf files on the puppetmaster, restarted the puppetmaster daemon in debug mode.and... no error...not a single one -- puppetclients connect just fine, and puppetrun works correctly... I must be missing something here since the docs are saying at least one of these files are needed on the puppetmaster. On Feb 22, 7:20 pm, tu2bg...@gmail.com wrote: > From the docs: > > auth.conf > > rest_authconfig = $confdir/auth.conf > > The auth.conf doesn't exist by default, but Puppet has some default > settings that will be put in place if you don't create an auth.conf. You'll > see these settings if you run your puppetmaster in debug mode and then > connect with a client. > --- > namespaceauth.conf > > authconfig = $confdir/namespaceauth.conf > > This file controls the http connections to the puppet agent. It is > necessary to start the puppet agent with the listen true option. > > There's an example namespaceauth.conf file in the puppet source in > conf/namespaceauth.conf. > > > auth.conf: controls access to puppetmaster - lives on puppetmaster > > namespaceauth.conf: bit harder to discern from doco and the link to the > example returns 404. (points to old reductivelabs > github)https://github.com/puppetlabs/puppet/blob/master/conf/namespaceauth.conf > > # This is an example namespaceauth.conf file, > # which you'll need if you want to start a client > # in --listen mode. > [fileserver] > allow *.domain.com > > [puppetmaster] > allow *.domain.com > > [puppetrunner] > allow culain.domain.com > > [puppetbucket] > allow *.domain.com > > [puppetreports] > allow *.domain.com > > [resource] > allow server.domain.com > > That would be on the client from my reading but I haven't implemented this > at all. > > On , Douglas Garstang wrote: > > > On Tue, Feb 22, 2011 at 2:58 PM, Jed jedbl...@gmail.com> wrote: > > Thanks Denmat... > > I've seen the page already, but its so vague... > > it doesnt mention anywhere what files belong where... > > I gather auth.conf would need to be on the puppetmaster... > > however, from what it says about namespaceauth.conf, it seems that > > needs to live on the puppet client machines > > not sure > > On Feb 22, 4:58 pm, Denmat tu2bg...@gmail.com> wrote: > > > I think only on master. This might help you > > further.http://docs.puppetlabs.com/guides/security.html > > > > On 23/02/2011, at 8:29, Jed jedbl...@gmail.com> wrote: > > > > > I'm trying to wrap my head around these files... > > > > > do both of them need to reside on the client and master? > > > > > are there any docs that describe these files and what all the option/ > > > > sections are and what they do? > > > > > Thanks all > > Yeah, it is horribly confusing isn't it. Glad it's not just me that can't > > quite work it out. > > Doug > > -- > > 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.
Re: [Puppet Users] Puppet module to regularly change passwords and update SecretServer
Very interested! I am in the midst of rolling out a brand new collection of
servers, all Linux. This couldn't be more timely.
Thanks,
Dave Augustus
On Feb 22, 2011, at 6:20 PM, "Steve Shipway" wrote:
> I've created a Puppet module which will check a specified user for password
> age, and if it is older than a specified amount, then it will first generate
> a random password, change the user's password to this, and will then update
> (or create) the stored password as held in the Secret Server application (via
> the SecretServer API) -- see http://www.thycotic.com/ . This means that we
> don't need to allow SecretServer to log in remotely as root to do the job
> itself, and we can receive notification (via Puppet reports) when this has
> been done.
>
>
>
> So far this only works for Linux but it should be simple to make it work for
> other OS.
>
>
>
> Usage is:
>
> password { 'user': age=>30, username=>'user' }
>
>
>
> with both parameters optional. We will use this to autorotate passwords on
> non-user accounts (root, oracle) since account expiry causes crontabs to stop
> working and we cannot lock the accounts or disable expiry due to
> functionality and security requirements.
>
>
>
> Is anyone already using SecretServer interested in testing a copy? There
> are a couple of caveats with it but things are looking good so far.
>
>
>
> Steve
>
>
>
>
>
> Steve Shipway
>
> st...@steveshipway.org
>
> Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows
> Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios and
> MRTG; and other Open Source projects.
>
> Web: http://www.steveshipway.org/software
>
> P Please consider the environment before printing this e-mail
>
>
>
>
>
> --
> 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.
Re: [Puppet Users] File updates dumped to Messages File
On Tue, Feb 22, 2011 at 7:29 PM, Douglas Garstang wrote: > Here's a weird one. I have a 2.6 server and a 0.24.8 client, and when I run > the puppet client, any files that are being updated by puppet, are having > their entire contents dumped to /var/log/messages. What's up with that? > Doug Have you tried upgrading the client to 2.6 as well? Does the problem still occur? -Jeff -- 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] Quick note: Moved the language tutorial.
Hi, all; docs guy here. On account of the language tutorial not... actually... being a tutorial, I've moved it to http://docs.puppetlabs.com/guides/language_guide.html. There's a 302 in place, but since it's probably one of the more used pages, I thought it'd be worth a quick mention anyway. (And yeah, I know the link on the index is still wrong; it'll be fixed in the next content push.) -- 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: Could not request certificate: undefined method `closed?' for nil:NilClass'
Thank you, Felix. I will try. On 2月22日, 午前12:49, Felix Frank wrote: > On 02/21/2011 05:39 AM, 暁華 管 wrote: > > > Hi, > > > I installed puppet 0.25.4 on ubuntu 10.04. It was ok until puppet > > client and server were intalled. But when I tried to execute the > > following command, the error, "Could not request certificate: > > undefined method `closed?' for nil:NilClass'", occurred. > > > sudo puppetd --test --verbose --server SERVER_NAME > > > Could anyone adivse me? > > > Thanks. > > Hi, > > have you tried the --waitforcert parameter? > > Also, I'll take the liberty and paste Patrick's default reply to this > problem: > > This error is a bug that is fixes in later versions of puppet. It > means, something went wrong (this might be your fault) and the cleanup > code failed (this part isn't your fault). > > More information at:http://projects.puppetlabs.com/issues/3101 > > Regards, > Felix -- 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.
Re: [Puppet Users] Re: auth.conf & namespaceauth.conf : which files belong on the master , and c
On Tue, Feb 22, 2011 at 5:09 PM, Jed wrote: > ok so I did sometesting.. > > > apparently, this is how it breaks down so far... > > -PUPPET CLIENT- > namespaceauth.conf: you need this or else it dies on startup > auth.conf : you do not need this normally, however if you want to do a > 'puppetrun' from the master->client, this files needs to be present > and you need to have your puppet master listed in the proper sections > (ie. /run), also regarding 'puppetrun' command, you need the > [puppetrunner] section defined in the namespaceauth.conf file on the > puppetclient - in that section you need to list your puppetmaster FQDN/ > IP. > > -PUPPET MASTER- > namespaceauth.conf: not sure if this is need on the puppet master, > i'll remove it and test. > auth.conf: well...this is needed as per the documents. > > this is where it gets fun [/s] > > i have a custom spec/rpm built for the puppetmaster/puppetclient, all > this happens in once shot (from source its configured/compiled/built > and then broken out into a server/client rpm package) -- not a big > deal. > > however, the million dollar question iswill the options for the > puppet master and the puppet client (in either file , auth.conf or > namespaceauth.conf) conflict? since i would like to use a global > version of both files and dist. to the puppetmaster and all > puppetclients. Furthermore, it sort of needs to happen like that, > since i have a puppetmaster, but on that master the puppet client will > be installed so the master can manage itself -- needless to say, the > puppetmaster and the puppetclient (on the same machine/instance) store > the same config/file/names in the same directory(/etc/puppet) > > I'm sure it fairly trivial once you know what it is that's trivial ;-) > > the puppet docs are just horrible (I hated Cfengine, but dammit, there > documentation was anal retentive) > > for instance... the docs say "ohhh you have an 'auth' section in the > auth.conf file and here are the 8 different values (yes, > no ...etc)however, nowhere, anywhere at all in blogs/sites/wiki > and even Turbulls puppet book does it say WHAT THE HELL THOSE OPTIONS > MEAN/DO/DONT DO. > > ok ok..now i'm venting -- sorry, but its been a long 3-day weekend of > trying to get puppet up and running on a last minute time-frame cause > i work for a bunch of monkeys(errr managers) with their heads in their > #(#*$* > > I feel your pain... -- 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: auth.conf & namespaceauth.conf : which files belong on the master , and c
ok so I did sometesting.. apparently, this is how it breaks down so far... -PUPPET CLIENT- namespaceauth.conf: you need this or else it dies on startup auth.conf : you do not need this normally, however if you want to do a 'puppetrun' from the master->client, this files needs to be present and you need to have your puppet master listed in the proper sections (ie. /run), also regarding 'puppetrun' command, you need the [puppetrunner] section defined in the namespaceauth.conf file on the puppetclient - in that section you need to list your puppetmaster FQDN/ IP. -PUPPET MASTER- namespaceauth.conf: not sure if this is need on the puppet master, i'll remove it and test. auth.conf: well...this is needed as per the documents. this is where it gets fun [/s] i have a custom spec/rpm built for the puppetmaster/puppetclient, all this happens in once shot (from source its configured/compiled/built and then broken out into a server/client rpm package) -- not a big deal. however, the million dollar question iswill the options for the puppet master and the puppet client (in either file , auth.conf or namespaceauth.conf) conflict? since i would like to use a global version of both files and dist. to the puppetmaster and all puppetclients. Furthermore, it sort of needs to happen like that, since i have a puppetmaster, but on that master the puppet client will be installed so the master can manage itself -- needless to say, the puppetmaster and the puppetclient (on the same machine/instance) store the same config/file/names in the same directory(/etc/puppet) I'm sure it fairly trivial once you know what it is that's trivial ;-) the puppet docs are just horrible (I hated Cfengine, but dammit, there documentation was anal retentive) for instance... the docs say "ohhh you have an 'auth' section in the auth.conf file and here are the 8 different values (yes, no ...etc)however, nowhere, anywhere at all in blogs/sites/wiki and even Turbulls puppet book does it say WHAT THE HELL THOSE OPTIONS MEAN/DO/DONT DO. ok ok..now i'm venting -- sorry, but its been a long 3-day weekend of trying to get puppet up and running on a last minute time-frame cause i work for a bunch of monkeys(errr managers) with their heads in their #(#*$* On Feb 22, 7:20 pm, tu2bg...@gmail.com wrote: > From the docs: > > auth.conf > > rest_authconfig = $confdir/auth.conf > > The auth.conf doesn't exist by default, but Puppet has some default > settings that will be put in place if you don't create an auth.conf. You'll > see these settings if you run your puppetmaster in debug mode and then > connect with a client. > --- > namespaceauth.conf > > authconfig = $confdir/namespaceauth.conf > > This file controls the http connections to the puppet agent. It is > necessary to start the puppet agent with the listen true option. > > There's an example namespaceauth.conf file in the puppet source in > conf/namespaceauth.conf. > > > auth.conf: controls access to puppetmaster - lives on puppetmaster > > namespaceauth.conf: bit harder to discern from doco and the link to the > example returns 404. (points to old reductivelabs > github)https://github.com/puppetlabs/puppet/blob/master/conf/namespaceauth.conf > > # This is an example namespaceauth.conf file, > # which you'll need if you want to start a client > # in --listen mode. > [fileserver] > allow *.domain.com > > [puppetmaster] > allow *.domain.com > > [puppetrunner] > allow culain.domain.com > > [puppetbucket] > allow *.domain.com > > [puppetreports] > allow *.domain.com > > [resource] > allow server.domain.com > > That would be on the client from my reading but I haven't implemented this > at all. > > On , Douglas Garstang wrote: > > > On Tue, Feb 22, 2011 at 2:58 PM, Jed jedbl...@gmail.com> wrote: > > Thanks Denmat... > > I've seen the page already, but its so vague... > > it doesnt mention anywhere what files belong where... > > I gather auth.conf would need to be on the puppetmaster... > > however, from what it says about namespaceauth.conf, it seems that > > needs to live on the puppet client machines > > not sure > > On Feb 22, 4:58 pm, Denmat tu2bg...@gmail.com> wrote: > > > I think only on master. This might help you > > further.http://docs.puppetlabs.com/guides/security.html > > > > On 23/02/2011, at 8:29, Jed jedbl...@gmail.com> wrote: > > > > > I'm trying to wrap my head around these files... > > > > > do both of them need to reside on the client and master? > > > > > are there any docs that describe these files and what all the option/ > > > > sections are and what they do? > > > > > Thanks all > > Yeah, it is horribly confusing isn't it. Glad it's not just me that can't > > quite work it out. > > Doug > > -- > > 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@go
[Puppet Users] File updates dumped to Messages File
Here's a weird one. I have a 2.6 server and a 0.24.8 client, and when I run the puppet client, any files that are being updated by puppet, are having their entire contents dumped to /var/log/messages. What's up with that? Doug -- 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] RHEL5 and RHEL6 wiith Puppet
I've just started to test existing Puppet modules with RHEL6. It seems that several things have changed slightly, breaking the old RHEL5-tested modules and requiring addition configuration to be added. 1. The syslod has changed to rsyslog, and the config files have altered. This is the largest change. 2. The snmpd has changed the location of its var file and so SNMPv3 user creation doesn't work the same. 3. The use of UDEV for all devices now requires us to have some special rules added on our virtual (vmware) guests, so that device names are not persistent -- we need to exclude vmware network devices from UDEV else they will be renamed if the MAC address changes. Has anyone else spotted any other changes requiring alteration to the Puppet manifests and modules? Steve _ Steve Shipway st...@steveshipway.org Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios and MRTG; and other Open Source projects. Web: http://www.steveshipway.org/software P Please consider the environment before printing this e-mail -- 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 module to regularly change passwords and update SecretServer
I've created a Puppet module which will check a specified user for password
age, and if it is older than a specified amount, then it will first generate
a random password, change the user's password to this, and will then update
(or create) the stored password as held in the Secret Server application
(via the SecretServer API) -- see http://www.thycotic.com/ . This means
that we don't need to allow SecretServer to log in remotely as root to do
the job itself, and we can receive notification (via Puppet reports) when
this has been done.
So far this only works for Linux but it should be simple to make it work for
other OS.
Usage is:
password { 'user': age=>30, username=>'user' }
with both parameters optional. We will use this to autorotate passwords on
non-user accounts (root, oracle) since account expiry causes crontabs to
stop working and we cannot lock the accounts or disable expiry due to
functionality and security requirements.
Is anyone already using SecretServer interested in testing a copy? There
are a couple of caveats with it but things are looking good so far.
Steve
_
Steve Shipway
st...@steveshipway.org
Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows
Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios
and MRTG; and other Open Source projects.
Web: http://www.steveshipway.org/software
P Please consider the environment before printing this e-mail
--
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.
Re: Re: [Puppet Users] Re: auth.conf & namespaceauth.conf : which files belong on the master , and c
From the docs: auth.conf rest_authconfig = $confdir/auth.conf The auth.conf doesn't exist by default, but Puppet has some default settings that will be put in place if you don't create an auth.conf. You'll see these settings if you run your puppetmaster in debug mode and then connect with a client. --- namespaceauth.conf authconfig = $confdir/namespaceauth.conf This file controls the http connections to the puppet agent. It is necessary to start the puppet agent with the listen true option. There's an example namespaceauth.conf file in the puppet source in conf/namespaceauth.conf. auth.conf: controls access to puppetmaster - lives on puppetmaster namespaceauth.conf: bit harder to discern from doco and the link to the example returns 404. (points to old reductivelabs github) https://github.com/puppetlabs/puppet/blob/master/conf/namespaceauth.conf # This is an example namespaceauth.conf file, # which you'll need if you want to start a client # in --listen mode. [fileserver] allow *.domain.com [puppetmaster] allow *.domain.com [puppetrunner] allow culain.domain.com [puppetbucket] allow *.domain.com [puppetreports] allow *.domain.com [resource] allow server.domain.com That would be on the client from my reading but I haven't implemented this at all. On , Douglas Garstang wrote: On Tue, Feb 22, 2011 at 2:58 PM, Jed jedbl...@gmail.com> wrote: Thanks Denmat... I've seen the page already, but its so vague... it doesnt mention anywhere what files belong where... I gather auth.conf would need to be on the puppetmaster... however, from what it says about namespaceauth.conf, it seems that needs to live on the puppet client machines not sure On Feb 22, 4:58 pm, Denmat tu2bg...@gmail.com> wrote: > I think only on master. This might help you further.http://docs.puppetlabs.com/guides/security.html > > On 23/02/2011, at 8:29, Jed jedbl...@gmail.com> wrote: > > > I'm trying to wrap my head around these files... > > > do both of them need to reside on the client and master? > > > are there any docs that describe these files and what all the option/ > > sections are and what they do? > > > Thanks all Yeah, it is horribly confusing isn't it. Glad it's not just me that can't quite work it out. Doug -- 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.
Re: [Puppet Users] Re: auth.conf & namespaceauth.conf : which files belong on the master , and client?
On Tue, Feb 22, 2011 at 2:58 PM, Jed wrote: > Thanks Denmat... > > I've seen the page already, but its so vague... > > it doesnt mention anywhere what files belong where... > > I gather auth.conf would need to be on the puppetmaster... > > however, from what it says about namespaceauth.conf, it seems that > needs to live on the puppet client machines > > not sure > > On Feb 22, 4:58 pm, Denmat wrote: > > I think only on master. This might help you further. > http://docs.puppetlabs.com/guides/security.html > > > > On 23/02/2011, at 8:29, Jed wrote: > > > > > I'm trying to wrap my head around these files... > > > > > do both of them need to reside on the client and master? > > > > > are there any docs that describe these files and what all the option/ > > > sections are and what they do? > > > > > Thanks all > Yeah, it is horribly confusing isn't it. Glad it's not just me that can't quite work it out. Doug -- 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: When running puppetd the cert goes straight up to revoked?
Yep Same version 2.6.4 It looks like the client crl.pem was causing this somehow. I just emptied the file and it looks like its working fine. Thx On Feb 22, 2:01 pm, Denmat wrote: > Are client and master at same version? What version are you using? > > On 23/02/2011, at 8:40, Roberto Bouza wrote: > > > > > I've removed /var/lib/puppet and /etc/puppet/ssl multiple times > > (removing the cert from the puppetmaster as well) with no luck. > > > The times are in sync... > > > Is really strange. > > > On Feb 22, 12:27 pm, Denmat wrote: > >> Hi, > >> Not sure on this but it looks like puppet is having issues reading> > >> /var/lib/puppet/lib > > >> Other things with SSL issues is to make sure your clocks are up to date, > >> that you're using the right cert name if needed and DNS working correctly. > > >> Hope it helps. > > >> Den > > >> On 23/02/2011, at 6:53, Roberto Bouza wrote: > > >>> This is the first time is happening... and It happens consecutively > >>> with all the hosts. > > >>> Fresh kickstarted host (never set up before the name so its not on the > >>> revocation list), I just run puppetd -tv (we have autosign on), I just > >>> get the output below: > > >>> [root@server182 puppet]# puppetd -tv > >>> info: Creating a new SSL key for server182.domain.com > >>> warning: peer certificate won't be verified in this SSL session > >>> info: Caching certificate for ca > >>> warning: peer certificate won't be verified in this SSL session > >>> warning: peer certificate won't be verified in this SSL session > >>> info: Creating a new SSL certificate request for server182.domain.com > >>> info: Certificate Request fingerprint (md5): 7A: > >>> 41:F8:1E:E4:46:21:95:BC:95:D1:D6:C8:1D:88:9F > >>> warning: peer certificate won't be verified in this SSL session > >>> warning: peer certificate won't be verified in this SSL session > >>> info: Caching certificate for server182.domain.com > >>> info: Retrieving plugin > >>> err: /File[/var/lib/puppet/lib]: Failed to generate additional > >>> resources using 'eval_generate': sslv3 alert certificate revoked > >>> err: /File[/var/lib/puppet/lib]: Could not evaluate: sslv3 alert > >>> certificate revoked Could not retrieve file metadata for > >>> puppet://puppet/plugins: > >>> sslv3 alert certificate revoked > >>> info: Creating state file /var/lib/puppet/state/state.yaml > >>> err: Could not retrieve catalog from remote server: sslv3 alert > >>> certificate revoked > >>> warning: Not using cache on failed catalog > >>> err: Could not retrieve catalog; skipping run > > >>> On the server I get: > > >>> server182.domain.com (81:41:53:FC:9F:27:EE:46:20:E9:C6:98:59:DF:0A:06) > >>> (certificate revoked) > > >>> Something to notice is that the server gets it's IP from the DHCP > >>> server, then when puppetized the IP gets changed to the one published > >>> on DNS. But the DNS entry is already there so I don't know if the > >>> puppetmaster check the IP based on the name and since it's different > >>> it has this behavior. > > >>> Any help will be appreciated. > > >>> Thx. > > >>> -- > >>> 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 > >>> athttp://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 > > athttp://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] Re: auth.conf & namespaceauth.conf : which files belong on the master , and client?
Thanks Denmat... I've seen the page already, but its so vague... it doesnt mention anywhere what files belong where... I gather auth.conf would need to be on the puppetmaster... however, from what it says about namespaceauth.conf, it seems that needs to live on the puppet client machines not sure On Feb 22, 4:58 pm, Denmat wrote: > I think only on master. This might help you > further.http://docs.puppetlabs.com/guides/security.html > > On 23/02/2011, at 8:29, Jed wrote: > > > I'm trying to wrap my head around these files... > > > do both of them need to reside on the client and master? > > > are there any docs that describe these files and what all the option/ > > sections are and what they do? > > > Thanks all > > > -- > > 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 > > athttp://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] Puppet 2.6 and extlookup... and environments
I just incorporated environments into my puppet...
On the server...
[main]
...
[pax]
manifest = /etc/puppet/env/pax_prod/manifests/site.pp
modulepath = /etc/puppet/env/pax_prod/modules
[fre]
manifest = /etc/puppet/env/fre_prod/manifests/site.pp
modulepath = /etc/puppet/env/fre_prod/modules
[agent]
...
and I changed the environment to be pax_prod on the client accordingly.
However, when puppet encounters this:
$ns_primary = extlookup("ns_primary", "", "default_${domain}")
it doesn't give $ns_primary a value. The file was previously in the
directory /etc/puppet/manifests/extdata, but now with the environments it's
been moved to /etc/puppet/env/pax_prod/manifests/extdata.
Do I have to do anything special?
Doug.
--
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.
Re: [Puppet Users] Problem with module
On Tue, Feb 22, 2011 at 10:42:34AM -0500, Ashley Penney wrote:
> Hi,
>
> I'm having a problem with a module that works on my production servers, but
> is giving me grief when ran from scratch. When I run the client I get:
>
> [root@hlsdevcms1 puppet]# puppetd -tv
> info: Retrieving plugin
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Caching catalog for hlsdevcms1.law.harvard.edu
> err: Could not run Puppet configuration client: Could not find user rhythmyx
>
> I have tried everything I can think of to add more and more require =>
> statements into the two .pp's that comprise the module but it refuses to
> find the user. I have run puppetmasterd in debug mode and the client in
> debug mode to no avail, neither gives me any more information on why this
> would fail. I've checked in the local yaml on the client and the rhythmyx
> stuff appears in there, including the comment statement in the user{}, so
> it's definitely in the catalog.
>
> The init.pp (apologises for what a mess this is, but I've been messing with
> it trying to get it working):
>
*snip*
You shouldnt need any of these requires. If you've say something like
user {'foo': gid => 'bar'} the user automatically requires the group. If
you specify file {'foo': owner => 'foo'} the file automatically requires
the user and so on. One thing that is a little suspicious is that you
define a file default File { owner => ..., require => ...}. Maybe heres
the error (also I did a test and setting the default owner to a not
existant user works on my machine)
So what I would do is
- does it work with a dummy class?
- Do you need the user in some of your custom facts? Because the facts
will run before the actual puppet run.
If that doesnt help try to reduce your example to the bare minimum where
the error occurs. If you have anything special in your puppet.conf post
it. And the actual debug output could help to.
-Stefan
(I took the freedom to reformat)
> ##
> ## Install rhythmyx.
> ##
>
> class rhythmyx {
> include rhythmyx::install
> if defined(Class["splunk4::client"]) {
> concat::fragment{"splunk4-rx":
> target => "/opt/splunk/etc/system/local/inputs.conf",
> content => "[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled =
> false\nsourcetype = rhythmyx\nindex = rhythmyx\n_blacklist =
> rx_lib.*\\.log\n",
> }
> }
>
> ##
> ## Users/Groups
> ##
> user { "rhythmyx":
> ensure => "present",
> uid=> 5000,
> gid=> 5000,
> comment=> "rhythmyx user",
> home => "/opt/rhythmyx",
> shell => '/bin/bash',
> managehome => true,
> require=> Group['rhythmyx'],
> }
> group { "rhythmyx":
> ensure => "present",
> gid=> "5000",
> }
>
> service { "RhythmyxD":
> ensure => "running",
> hasrestart => "false",
> hasstatus => "false",
> pattern=> "RhythmyxServer.exe",
> start => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
> /opt/rhythmyx/Rhythmyx/",
> stop => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
> /opt/rhythmyx/Rhythmyx && sleep 45",
> require => Exec["rx-permissions-rhythmyx"],
> }
>
> ##
> ## Crons
> ##
>
> file
> {"/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode=> "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> file
> {"/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode=> "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> ##
> ## Backups
> ##
>
> tidy {"/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war":
> age => '90d',
> matches => '*.log',
> recurse => 'true',
> }
>
> tidy { "/tmp/rxtemp.rhythmyx":
> age => '2d',
> matches => '*.tmp',
> recurse => 'true',
> }
>
> cron { "Rhythmyx restart":
> command => "/etc/init.d/RhythmyxD restart",
> ensure => "present",
> user=> "root",
> minute => "00",
> hour=> "03",
> weekday => "3",
> }
>
> }
>
> The install.pp:
>
> ##
> ## Install rhythmyx
> ##
>
> class rhythmyx::install {
>
> $url = extlookup("url")
> $rxsqlserver = extlookup("rxsqlserver")
>
> #package { 'compat-libgcc-296': ensure => present }
> #package { 'compat-libstdc++-296': ensure => present }
> #package { 'compat-gli
[Puppet Users] Re: Diff-style patches
You can use a file resource to copy a diff to a temp/diff area that
notifies an exec that does the diff as you have mentioned. This means
the diff would only get downloaded once, and the patch only applied if
the diff changes.
So roughly:
file {"/var/lib/diffpatches/foo.patch":
source => "puppet:///modules/foo/foo.patch",
notify => Exec["apply-foo-patch"],
}
exec {"apply-foo-patch":
command => "patch -d /path/to/patch -p1 < /var/lib/diffpatches/
foo.patch",
refreshonly => true,
}
You could wrap this sucker in a define and make it a re-usable
function if you wanted to as well so you can re-use it. You may also
want to add an 'onlyif' section to the exec with the patch command in
a dry-run perhaps?
Other ideas would include concatenating multiple files:
http://forge.puppetlabs.com/ripienaar/concat
https://github.com/puppet-modules/puppet-concat
And there are various regexp based patterns for deleting lines and
search and replace:
http://projects.puppetlabs.com/projects/1/wiki/Simple_Text_Patterns
Normally I don't diverge much from concat or managing the file in a
template myself to be honest. The vendor may add new configuration
items, but I generally want to be aware of this anyway if I'm
upgrading a package :-).
ken.
On Feb 22, 7:55 pm, Kent wrote:
> Hi All,
>
> For most of the config files we manage via our Puppet setup, we either
> serve flat files or use templates and dashboard parameters and Facts
> to dynamically create the config file. However, in some cases we are
> not comfortable with either of these methods due to the possibility of
> small but numerous variances across different versions of operating
> systems. Also there is always the worry that a package update from the
> OS vendor will make changes you did not forsee. Managing the file
> with a File resource or template in Puppet would stomp out these
> vendor changes.
>
> Currently in such cases, we use diff-style patches and use the 'patch'
> command in our RPMs to apply custom changes to Red Hat's baseline
> file. This is flexible and fairly safe. However we've been
> transitioning from using custom RPMs in a Kickstarted environment, to
> bootstrapping our systems using Kickstart and then using Puppet
> wherever possible. I'd like to manage even these tricky files with
> Puppet, but I'm not sure the best way to handle it.
>
> I don't want to use a File resource or templates, as we do for most
> everything else. I considered augeas and have played around with it a
> bit, but in so many cases it is clumsy and a little dangerous, i.e.
> items in config files are often referenced by file line number or some
> other possibly-volatile key. This uncertainty with augeas sorta
> defeats the whole purpose of avoiding File and templates. Line numbers
> can change from one version of the file to the next, and if I hardcode
> changes to specific line numbers, that seems like a recipe for
> incorrect config files in the future.
>
> Anyone have a good idea for how to apply Diff-style patches using
> Puppet? I was thinking a File and an Exec could get it done, the
> former being the patch file, the latter being a command to patch the
> file. But in this case, how to keep from download the patch file on
> every Puppet run, whether or not we use it?
>
> Hope I've been clear on my questioning, and thanks in advance!
>
> -Kent
--
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.
Re: [Puppet Users] Re: When running puppetd the cert goes straight up to revoked?
Are client and master at same version? What version are you using? On 23/02/2011, at 8:40, Roberto Bouza wrote: > I've removed /var/lib/puppet and /etc/puppet/ssl multiple times > (removing the cert from the puppetmaster as well) with no luck. > > The times are in sync... > > Is really strange. > > On Feb 22, 12:27 pm, Denmat wrote: >> Hi, >> Not sure on this but it looks like puppet is having issues reading> >> /var/lib/puppet/lib >> >> Other things with SSL issues is to make sure your clocks are up to date, >> that you're using the right cert name if needed and DNS working correctly. >> >> Hope it helps. >> >> Den >> >> On 23/02/2011, at 6:53, Roberto Bouza wrote: >> >> >> >>> This is the first time is happening... and It happens consecutively >>> with all the hosts. >> >>> Fresh kickstarted host (never set up before the name so its not on the >>> revocation list), I just run puppetd -tv (we have autosign on), I just >>> get the output below: >> >>> [root@server182 puppet]# puppetd -tv >>> info: Creating a new SSL key for server182.domain.com >>> warning: peer certificate won't be verified in this SSL session >>> info: Caching certificate for ca >>> warning: peer certificate won't be verified in this SSL session >>> warning: peer certificate won't be verified in this SSL session >>> info: Creating a new SSL certificate request for server182.domain.com >>> info: Certificate Request fingerprint (md5): 7A: >>> 41:F8:1E:E4:46:21:95:BC:95:D1:D6:C8:1D:88:9F >>> warning: peer certificate won't be verified in this SSL session >>> warning: peer certificate won't be verified in this SSL session >>> info: Caching certificate for server182.domain.com >>> info: Retrieving plugin >>> err: /File[/var/lib/puppet/lib]: Failed to generate additional >>> resources using 'eval_generate': sslv3 alert certificate revoked >>> err: /File[/var/lib/puppet/lib]: Could not evaluate: sslv3 alert >>> certificate revoked Could not retrieve file metadata for >>> puppet://puppet/plugins: >>> sslv3 alert certificate revoked >>> info: Creating state file /var/lib/puppet/state/state.yaml >>> err: Could not retrieve catalog from remote server: sslv3 alert >>> certificate revoked >>> warning: Not using cache on failed catalog >>> err: Could not retrieve catalog; skipping run >> >>> On the server I get: >> >>> server182.domain.com (81:41:53:FC:9F:27:EE:46:20:E9:C6:98:59:DF:0A:06) >>> (certificate revoked) >> >>> Something to notice is that the server gets it's IP from the DHCP >>> server, then when puppetized the IP gets changed to the one published >>> on DNS. But the DNS entry is already there so I don't know if the >>> puppetmaster check the IP based on the name and since it's different >>> it has this behavior. >> >>> Any help will be appreciated. >> >>> Thx. >> >>> -- >>> 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 >>> athttp://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. > -- 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.
Re: [Puppet Users] auth.conf & namespaceauth.conf : which files belong on the master , and client?
I think only on master. This might help you further. http://docs.puppetlabs.com/guides/security.html On 23/02/2011, at 8:29, Jed wrote: > I'm trying to wrap my head around these files... > > do both of them need to reside on the client and master? > > are there any docs that describe these files and what all the option/ > sections are and what they do? > > Thanks all > > -- > 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] Re: When running puppetd the cert goes straight up to revoked?
I've removed /var/lib/puppet and /etc/puppet/ssl multiple times (removing the cert from the puppetmaster as well) with no luck. The times are in sync... Is really strange. On Feb 22, 12:27 pm, Denmat wrote: > Hi, > Not sure on this but it looks like puppet is having issues reading> > /var/lib/puppet/lib > > Other things with SSL issues is to make sure your clocks are up to date, that > you're using the right cert name if needed and DNS working correctly. > > Hope it helps. > > Den > > On 23/02/2011, at 6:53, Roberto Bouza wrote: > > > > > This is the first time is happening... and It happens consecutively > > with all the hosts. > > > Fresh kickstarted host (never set up before the name so its not on the > > revocation list), I just run puppetd -tv (we have autosign on), I just > > get the output below: > > > [root@server182 puppet]# puppetd -tv > > info: Creating a new SSL key for server182.domain.com > > warning: peer certificate won't be verified in this SSL session > > info: Caching certificate for ca > > warning: peer certificate won't be verified in this SSL session > > warning: peer certificate won't be verified in this SSL session > > info: Creating a new SSL certificate request for server182.domain.com > > info: Certificate Request fingerprint (md5): 7A: > > 41:F8:1E:E4:46:21:95:BC:95:D1:D6:C8:1D:88:9F > > warning: peer certificate won't be verified in this SSL session > > warning: peer certificate won't be verified in this SSL session > > info: Caching certificate for server182.domain.com > > info: Retrieving plugin > > err: /File[/var/lib/puppet/lib]: Failed to generate additional > > resources using 'eval_generate': sslv3 alert certificate revoked > > err: /File[/var/lib/puppet/lib]: Could not evaluate: sslv3 alert > > certificate revoked Could not retrieve file metadata for > > puppet://puppet/plugins: > > sslv3 alert certificate revoked > > info: Creating state file /var/lib/puppet/state/state.yaml > > err: Could not retrieve catalog from remote server: sslv3 alert > > certificate revoked > > warning: Not using cache on failed catalog > > err: Could not retrieve catalog; skipping run > > > On the server I get: > > > server182.domain.com (81:41:53:FC:9F:27:EE:46:20:E9:C6:98:59:DF:0A:06) > > (certificate revoked) > > > Something to notice is that the server gets it's IP from the DHCP > > server, then when puppetized the IP gets changed to the one published > > on DNS. But the DNS entry is already there so I don't know if the > > puppetmaster check the IP based on the name and since it's different > > it has this behavior. > > > Any help will be appreciated. > > > Thx. > > > -- > > 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 > > athttp://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] auth.conf & namespaceauth.conf : which files belong on the master , and client?
I'm trying to wrap my head around these files... do both of them need to reside on the client and master? are there any docs that describe these files and what all the option/ sections are and what they do? Thanks all -- 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.
Re: [Puppet Users] Problem with module
I am running 2.6 and can do this if needed. What would the parent class be
in this example, the 'rhythmyx' class that the user{} entry is in? This is
just included from foreman so I'm not sure there really is a "parent" as
such. I have a user class for actual people that I could use if I had to.
Still, this seems crazy. If there is a reference to a user in resources it
should check the rest of the yaml to see if that user is being created and
create it without erroring. I might file this via the enterprise support
because I think this is a bug, but I'm interested in other opinions before I
do so.
Thanks,
On Tue, Feb 22, 2011 at 3:10 PM, Denmat wrote:
> Hi
> The way I've got around this is to realize the user in the parent class or
> to create a 'user' class and put in a
> { class name: stage => pre}
> to guarantee it is created first.
>
> That's using stages in 2.6 though. Not sure what you're running.
>
> Den
>
>
> On 23/02/2011, at 2:42, Ashley Penney wrote:
>
> Hi,
>
> I'm having a problem with a module that works on my production servers, but
> is giving me grief when ran from scratch. When I run the client I get:
>
> [root@hlsdevcms1 puppet]# puppetd -tv
> info: Retrieving plugin
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Caching catalog for
> hlsdevcms1.law.harvard.edu
> err: Could not run Puppet configuration client: Could not find user
> rhythmyx
>
> I have tried everything I can think of to add more and more require =>
> statements into the two .pp's that comprise the module but it refuses to
> find the user. I have run puppetmasterd in debug mode and the client in
> debug mode to no avail, neither gives me any more information on why this
> would fail. I've checked in the local yaml on the client and the rhythmyx
> stuff appears in there, including the comment statement in the user{}, so
> it's definitely in the catalog.
>
> The init.pp (apologises for what a mess this is, but I've been messing with
> it trying to get it working):
>
> ##
> ## Install rhythmyx.
> ##
>
> class rhythmyx {
>
> include rhythmyx::install
>
> if defined(Class["splunk4::client"]) {
> concat::fragment{"splunk4-rx":
> target =>
> "/opt/splunk/etc/system/local/inputs.conf",
> content =>
> "[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled = false\nsourcetype
> = rhythmyx\nindex = rhythmyx\n_blacklist = rx_lib.*\\.log\n",
> }
> }
>
> ##
> ## Users/Groups
> ##
> user { "rhythmyx":
> ensure => "present",
> uid => 5000,
> gid => 5000,
> comment => "rhythmyx user",
> home => "/opt/rhythmyx",
> shell => '/bin/bash',
> managehome => true,
> require => Group['rhythmyx'],
> }
>
> group { "rhythmyx":
> ensure => "present",
> gid => "5000",
> }
>
> service { "RhythmyxD":
> ensure => "running",
> hasrestart => "false",
> hasstatus => "false",
> pattern => "RhythmyxServer.exe",
> start => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
> /opt/rhythmyx/Rhythmyx/",
> stop => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
> /opt/rhythmyx/Rhythmyx && sleep 45",
> require => Exec["rx-permissions-rhythmyx"],
> }
>
> ##
> ## Crons
> ##
>
> file {
> "/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode => "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> file {
> "/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode => "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> ##
> ## Backups
> ##
>
> tidy {
> "/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war":
> age => '90d',
> matches => '*.log',
> recurse => 'true',
> }
>
> tidy { "/tm
Re: [Puppet Users] Problem with module
Hi
The way I've got around this is to realize the user in the parent class or to
create a 'user' class and put in a
{ class name: stage => pre}
to guarantee it is created first.
That's using stages in 2.6 though. Not sure what you're running.
Den
On 23/02/2011, at 2:42, Ashley Penney wrote:
> Hi,
>
> I'm having a problem with a module that works on my production servers, but
> is giving me grief when ran from scratch. When I run the client I get:
>
> [root@hlsdevcms1 puppet]# puppetd -tv
> info: Retrieving plugin
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Loading facts in apache-ports
> info: Loading facts in location
> info: Loading facts in dell
> info: Loading facts in convera
> info: Caching catalog for hlsdevcms1.law.harvard.edu
> err: Could not run Puppet configuration client: Could not find user rhythmyx
>
> I have tried everything I can think of to add more and more require =>
> statements into the two .pp's that comprise the module but it refuses to find
> the user. I have run puppetmasterd in debug mode and the client in debug
> mode to no avail, neither gives me any more information on why this would
> fail. I've checked in the local yaml on the client and the rhythmyx stuff
> appears in there, including the comment statement in the user{}, so it's
> definitely in the catalog.
>
> The init.pp (apologises for what a mess this is, but I've been messing with
> it trying to get it working):
>
> ##
> ## Install rhythmyx.
> ##
>
> class rhythmyx {
>
> include rhythmyx::install
>
> if defined(Class["splunk4::client"]) {
> concat::fragment{"splunk4-rx":
> target =>
> "/opt/splunk/etc/system/local/inputs.conf",
> content =>
> "[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled = false\nsourcetype =
> rhythmyx\nindex = rhythmyx\n_blacklist = rx_lib.*\\.log\n",
> }
> }
>
> ##
> ## Users/Groups
> ##
> user { "rhythmyx":
> ensure => "present",
> uid => 5000,
> gid => 5000,
> comment => "rhythmyx user",
> home => "/opt/rhythmyx",
> shell => '/bin/bash',
> managehome => true,
> require => Group['rhythmyx'],
> }
>
> group { "rhythmyx":
> ensure => "present",
> gid => "5000",
> }
>
> service { "RhythmyxD":
> ensure => "running",
> hasrestart => "false",
> hasstatus => "false",
> pattern => "RhythmyxServer.exe",
> start => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
> /opt/rhythmyx/Rhythmyx/",
> stop => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
> /opt/rhythmyx/Rhythmyx && sleep 45",
> require => Exec["rx-permissions-rhythmyx"],
> }
>
> ##
> ## Crons
> ##
>
> file {
> "/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode => "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> file {
> "/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh":
> ensure => "present",
> source =>
> "puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh",
> owner => "rhythmyx",
> group => "rhythmyx",
> mode => "755",
> require => [ User["rhythmyx"], Group["rhythmyx"] ],
> }
>
> ##
> ## Backups
> ##
>
> tidy {
> "/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war":
> age => '90d',
> matches => '*.log',
> recurse => 'true',
> }
>
> tidy { "/tmp/rxtemp.rhythmyx":
> age => '2d',
> matches => '*.tmp',
> recurse => 'true',
> }
>
> cron { "Rhythmyx restart":
> command => "/etc/init.d/RhythmyxD restart",
> ensure => "present",
> user=> "root",
> minute => "00",
> hour=> "03",
> weekday => "3",
> }
>
> }
>
> The install.pp:
>
> ##
> ## Install rhythmyx
> ##
>
> class rhythmyx::install {
>
> $url = extlookup("url")
> $rxsqlserver = extlookup("rxsqlserver")
>
> #package { 'compat-libgcc-296': ensure => present }
> #package {
Re: [Puppet Users] When running puppetd the cert goes straight up to revoked?
Hi, Not sure on this but it looks like puppet is having issues reading > /var/lib/puppet/lib Other things with SSL issues is to make sure your clocks are up to date, that you're using the right cert name if needed and DNS working correctly. Hope it helps. Den On 23/02/2011, at 6:53, Roberto Bouza wrote: > This is the first time is happening... and It happens consecutively > with all the hosts. > > Fresh kickstarted host (never set up before the name so its not on the > revocation list), I just run puppetd -tv (we have autosign on), I just > get the output below: > > [root@server182 puppet]# puppetd -tv > info: Creating a new SSL key for server182.domain.com > warning: peer certificate won't be verified in this SSL session > info: Caching certificate for ca > warning: peer certificate won't be verified in this SSL session > warning: peer certificate won't be verified in this SSL session > info: Creating a new SSL certificate request for server182.domain.com > info: Certificate Request fingerprint (md5): 7A: > 41:F8:1E:E4:46:21:95:BC:95:D1:D6:C8:1D:88:9F > warning: peer certificate won't be verified in this SSL session > warning: peer certificate won't be verified in this SSL session > info: Caching certificate for server182.domain.com > info: Retrieving plugin > err: /File[/var/lib/puppet/lib]: Failed to generate additional > resources using 'eval_generate': sslv3 alert certificate revoked > err: /File[/var/lib/puppet/lib]: Could not evaluate: sslv3 alert > certificate revoked Could not retrieve file metadata for > puppet://puppet/plugins: > sslv3 alert certificate revoked > info: Creating state file /var/lib/puppet/state/state.yaml > err: Could not retrieve catalog from remote server: sslv3 alert > certificate revoked > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run > > On the server I get: > > server182.domain.com (81:41:53:FC:9F:27:EE:46:20:E9:C6:98:59:DF:0A:06) > (certificate revoked) > > Something to notice is that the server gets it's IP from the DHCP > server, then when puppetized the IP gets changed to the one published > on DNS. But the DNS entry is already there so I don't know if the > puppetmaster check the IP based on the name and since it's different > it has this behavior. > > Any help will be appreciated. > > Thx. > > -- > 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.
Re: [Puppet Users] provisioning bare metal (best practices)
Hi I use Cobbler for provisioning and it can handle dhcp and dns if you want. It is a bit light on debian support but I run mainly RH severs. The other that is mentioned already, foreman, maybe better as an integrated solution. On 23/02/2011, at 7:05, Russell Jackson wrote: > On 02/22/2011 10:14 AM, James A. Peltier wrote: >> >> >> - Original Message - | I thought about DHCP for static >> addresses. I'd need the MAC for each | machine >> >> This is not necessarily true. If you configure the client to send a >> requested hostname it will not require you to register the MAC >> address, although, as per the usual this is a security risk since >> anyone on the network could pose as a machine if they knew that was >> the setup. ;) >> > > Only if you have a flat network. A host can't get an address for a > subnet they're not in. > > -- > Russell A Jackson > Network Analyst > California State University, Bakersfield > > -- > 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.
Re: [Puppet Users] provisioning bare metal (best practices)
On 02/22/2011 10:14 AM, James A. Peltier wrote: > > > - Original Message - | I thought about DHCP for static > addresses. I'd need the MAC for each | machine > > This is not necessarily true. If you configure the client to send a > requested hostname it will not require you to register the MAC > address, although, as per the usual this is a security risk since > anyone on the network could pose as a machine if they knew that was > the setup. ;) > Only if you have a flat network. A host can't get an address for a subnet they're not in. -- Russell A Jackson Network Analyst California State University, Bakersfield -- 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] Diff-style patches
Hi All, For most of the config files we manage via our Puppet setup, we either serve flat files or use templates and dashboard parameters and Facts to dynamically create the config file. However, in some cases we are not comfortable with either of these methods due to the possibility of small but numerous variances across different versions of operating systems. Also there is always the worry that a package update from the OS vendor will make changes you did not forsee. Managing the file with a File resource or template in Puppet would stomp out these vendor changes. Currently in such cases, we use diff-style patches and use the 'patch' command in our RPMs to apply custom changes to Red Hat's baseline file. This is flexible and fairly safe. However we've been transitioning from using custom RPMs in a Kickstarted environment, to bootstrapping our systems using Kickstart and then using Puppet wherever possible. I'd like to manage even these tricky files with Puppet, but I'm not sure the best way to handle it. I don't want to use a File resource or templates, as we do for most everything else. I considered augeas and have played around with it a bit, but in so many cases it is clumsy and a little dangerous, i.e. items in config files are often referenced by file line number or some other possibly-volatile key. This uncertainty with augeas sorta defeats the whole purpose of avoiding File and templates. Line numbers can change from one version of the file to the next, and if I hardcode changes to specific line numbers, that seems like a recipe for incorrect config files in the future. Anyone have a good idea for how to apply Diff-style patches using Puppet? I was thinking a File and an Exec could get it done, the former being the patch file, the latter being a command to patch the file. But in this case, how to keep from download the patch file on every Puppet run, whether or not we use it? Hope I've been clear on my questioning, and thanks in advance! -Kent -- 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] When running puppetd the cert goes straight up to revoked?
This is the first time is happening... and It happens consecutively with all the hosts. Fresh kickstarted host (never set up before the name so its not on the revocation list), I just run puppetd -tv (we have autosign on), I just get the output below: [root@server182 puppet]# puppetd -tv info: Creating a new SSL key for server182.domain.com warning: peer certificate won't be verified in this SSL session info: Caching certificate for ca warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Creating a new SSL certificate request for server182.domain.com info: Certificate Request fingerprint (md5): 7A: 41:F8:1E:E4:46:21:95:BC:95:D1:D6:C8:1D:88:9F warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session info: Caching certificate for server182.domain.com info: Retrieving plugin err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': sslv3 alert certificate revoked err: /File[/var/lib/puppet/lib]: Could not evaluate: sslv3 alert certificate revoked Could not retrieve file metadata for puppet://puppet/plugins: sslv3 alert certificate revoked info: Creating state file /var/lib/puppet/state/state.yaml err: Could not retrieve catalog from remote server: sslv3 alert certificate revoked warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run On the server I get: server182.domain.com (81:41:53:FC:9F:27:EE:46:20:E9:C6:98:59:DF:0A:06) (certificate revoked) Something to notice is that the server gets it's IP from the DHCP server, then when puppetized the IP gets changed to the one published on DNS. But the DNS entry is already there so I don't know if the puppetmaster check the IP based on the name and since it's different it has this behavior. Any help will be appreciated. Thx. -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
James A. Peltier wrote: This is not necessarily true. If you configure the client to send a requested hostname it will not require you to register the MAC address, although, as per the usual this is a security risk since anyone on the network could pose as a machine if they knew that was the setup. ;) Not that that is any different from when using the MAC address to key your DHCP server, since that is just as easily faked. Or when using static IP addresses configured directly on the machines themselves. If you are afraid someone will pose as another machine by "stealing" their IP address, then you need physical security on your network. /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.
Re: [Puppet Users] provisioning bare metal (best practices)
- Original Message - | I thought about DHCP for static addresses. I'd need the MAC for each | machine This is not necessarily true. If you configure the client to send a requested hostname it will not require you to register the MAC address, although, as per the usual this is a security risk since anyone on the network could pose as a machine if they knew that was the setup. ;) -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices http://blogs.sfu.ca/people/jpeltier -- 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.
Re: [Puppet Users] Could not request certificate: undefined method `closed?' for nil:NilClass'
On Feb 22, 2011, at 9:09 AM, Paul Willis wrote: > On 21 Feb 2011, at 15:49, Felix Frank wrote: > >> On 02/21/2011 05:39 AM, 暁華 管 wrote: >>> Hi, >>> >>> I installed puppet 0.25.4 on ubuntu 10.04. It was ok until puppet >>> client and server were intalled. But when I tried to execute the >>> following command, the error, "Could not request certificate: >>> undefined method `closed?' for nil:NilClass'", occurred. >>> >>> sudo puppetd --test --verbose --server SERVER_NAME >>> >>> Could anyone adivse me? >>> >>> Thanks. >>> >> >> Hi, >> >> have you tried the --waitforcert parameter? >> >> Also, I'll take the liberty and paste Patrick's default reply to this >> problem: >> >> This error is a bug that is fixes in later versions of puppet. It >> means, something went wrong (this might be your fault) and the cleanup >> code failed (this part isn't your fault). >> >> More information at: >> http://projects.puppetlabs.com/issues/3101 >> >> Regards, >> Felix > > While Patrick's default reply is perfectly true and upgrading will probably > fix this it isn't helpful if for some reason you need to run standard 10.04 > LTS packages from the main repository and are therefore stuck on Puppet 0.25.4 > > When I had the same error I found that it was a problem with my client > finding the master. > > I assume SERVER_NAME is the server's fqdn similar to myserver.domain.com ? > Can you ping SERVER_NAME from the client? > Is there a firewall between the client and server, if so is port 8140 open? > (assuming you are using the default) > > Try with --waitforcert as Felix suggests with... > > sudo puppetd --server myserver.domain.com --waitforcert 60 --test The problem is, that error message can mean almost anything is wrong. Until we get the real error message, all we can do is stumble in the dark. At the bottom of the bugtracker page is a workaround. You can change the puppet monkey_patches.rb file on your install and that will cause you to get the right error messages. The diff is located at http://projects.puppetlabs.com/projects/puppet/repository/revisions/ae0b0bf23e418e8c6665e9dc135148b78bdbd913/diff/lib/puppet/util/monkey_patches.rb The file you need to change is at /usr/lib/ruby/1.8/puppet/util/monkey_patches.rb -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
Oh, great timing!
I'm working on pretty much the same question. I have used FAI and
Opsware, and homebrewed scripts to do provisioning in the past. I have
never been all that happy with any of them, and am taking another look
at the problem to try to get to as simple and portable a solution as
possible.
I am planning to ask the list to criticize the classes that implement
the various bits. (Is this the right list for that?) I would like the
classes to be 'state of the art'. My own competence with puppet leans
heavily towards 'exec { "some script I wrote": }' and I would like to
get past that.
I intend to create a completely worked out example that addresses
installing to
VirtualBox VMs and real hardware.
The programs I will use are:
dnsmasq for DNS, DHCP, and BOOTP
apache as file server (preseed.cfg, kickstart.cfg, random scripts)
apt-cacher-ng for local apt-proxy
gpxe, undionly.kpxe, pxeboot.0 for booting
redhat kickstart and debian preseed capable kernel/initrd for
install
And the slightly clever bit:
wget or curl to throw triggers into log files
swatch on the logs to trigger state changes, including signing
certs
puppet for configuration beyond the basic install
So how is this a simplification?
1. dnsmasq is much better suited to provisioning than
the combination of named, dhcpd, and tftpd (IMHO)
2. no giant frameworks in sight
3. each component is familiar.
4. modular, none of the components know or care about
the others so they can be versioned or replaced without
problems.
The thinking behind this is:
1. dnsmasqd provides mac/ip/hostname assignments
dnsmasqd configured by puppet class
after provisioning these will show up as facts
2. boot config provides OS and Disk partitions
boot configuration configured by puppet classes
after provisioning these will also show up as facts
3. puppet takes over after the first reboot
puppet bootstrapping set up during install (%post or
last.sh)
puppet style can be nodeless, masterless, whatever
4. flipping a symlink (manually or through a frontend)
configures a client install for the next time it boots.
On 02/22/2011 10:47 AM, David Kavanagh wrote:
I'm about to start playing with Kickstart. I never really had to
provision bare servers beyond a normal OS install, so I need something
to use along with Puppet. Is there a general consensus on what the
best option is?
I'd need to set up the node with IP/hostname/role. (I have a custom
fact for role). I figured I'd simply ssh in to write the role file,
but if I'd rather not use dhcp, I suppose I'll need to get the network
interface configured in another way. What do folks generally do here?
David
--
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.
Re: [Puppet Users] Could not request certificate: undefined method `closed?' for nil:NilClass'
On 21 Feb 2011, at 15:49, Felix Frank wrote: > On 02/21/2011 05:39 AM, 暁華 管 wrote: >> Hi, >> >> I installed puppet 0.25.4 on ubuntu 10.04. It was ok until puppet >> client and server were intalled. But when I tried to execute the >> following command, the error, "Could not request certificate: >> undefined method `closed?' for nil:NilClass'", occurred. >> >> sudo puppetd --test --verbose --server SERVER_NAME >> >> Could anyone adivse me? >> >> Thanks. >> > > Hi, > > have you tried the --waitforcert parameter? > > Also, I'll take the liberty and paste Patrick's default reply to this > problem: > > This error is a bug that is fixes in later versions of puppet. It > means, something went wrong (this might be your fault) and the cleanup > code failed (this part isn't your fault). > > More information at: > http://projects.puppetlabs.com/issues/3101 > > Regards, > Felix While Patrick's default reply is perfectly true and upgrading will probably fix this it isn't helpful if for some reason you need to run standard 10.04 LTS packages from the main repository and are therefore stuck on Puppet 0.25.4 When I had the same error I found that it was a problem with my client finding the master. I assume SERVER_NAME is the server's fqdn similar to myserver.domain.com ? Can you ping SERVER_NAME from the client? Is there a firewall between the client and server, if so is port 8140 open? (assuming you are using the default) Try with --waitforcert as Felix suggests with... sudo puppetd --server myserver.domain.com --waitforcert 60 --test Cheers 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] Question about puppet dashboard LDAP authentication and authroziation
Hi I am very new to puppet, I have been reading online docs at http://docs.puppetlabs.com/, but I couldn't find the answer to my following question. Please let me know the URL if I missed it. >From R1 link, looks like we can put LDAP authentication when accessing the dashboard URL. The question is does dashboard support LDAP authorization ? ie, different users has different privilege to access certain view. Ex. web admin user can only see web server class. R1: http://www.puppetlabs.com/wp-content/uploads/2010/04/Screen-shot-2010-04-26-at-9.57.22-AM. Regards tj -- T.J. Yang -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
I thought about DHCP for static addresses. I'd need the MAC for each machine though. For now, I'm worrying about plugging some media or doing network boot on machines by hand. I suppose I'll need to do something on the host to indicate what the machine role will be. In any case, I could simply use a small pool of dynamic addresses as temporary addresses, and ping for machines in that range from the server, then let the user know there's a new machine waiting and to designate a purpose (role). Then, assign static address and restart it in it's new location, letting puppet finish provisioning. I'll have a look at Foreman. Need to think about my use case, which probably isn't so uncommon. David On Tue, Feb 22, 2011 at 11:42 AM, Brian Gallew wrote: > Never forget the DHCP does NOT necessarily mean "dynamic addresses". > Depending upon your corporate culture, it may be perfectly acceptable for > DHCP to hand out statically assigned addresses to your hosts. This would > allow your build process to be easy, and you can have the host never DHCP > again after it's up and running (until you rebuild it!). > > > On Feb 22, 2011, at 8:15 AM, Jonathan Gazeley wrote: > > > We have a small pool of DHCP IP addresses for use only in the build > process. This is our process: > > > > 1. We boot the servers from PXE network boot > > > > 2. They get one of the temporary IPs > > > > 3. They start a CentOS network install using a kickstart file with the > bare minimum of packages selected, including puppet > > > > 4. The last stage of the kickstart is to set puppet running > > > > 5. At this stage, human intervention is required to authorise the new > machine in puppetca. I'm aware that it is possible to have this step done > automatically, but it can be a security risk. > > > > 6. Once the server is authorised in puppet, it receives a basic "common" > config from puppet, which gives it the proper static IP that it should have, > disables DHCP, sets the hostname, sets up NTP, etc. > > > > 7. From now on, it's dead easy to use puppet to install and configure > everything else. > > > > Cheers, > > Jonathan > > > > > > Jonathan Gazeley > > Systems Support Specialist > > ResNet | Wireless & VPN Team > > IT Services > > University of Bristol > > > > > > On 22/02/11 15:47, David Kavanagh wrote: > >> I'm about to start playing with Kickstart. I never really had to > >> provision bare servers beyond a normal OS install, so I need something > >> to use along with Puppet. Is there a general consensus on what the best > >> option is? > >> I'd need to set up the node with IP/hostname/role. (I have a custom fact > >> for role). I figured I'd simply ssh in to write the role file, but if > >> I'd rather not use dhcp, I suppose I'll need to get the network > >> interface configured in another way. What do folks generally do here? > >> > >> David > >> > >> -- > >> 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. > > > > -- > 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.
Re: [Puppet Users] provisioning bare metal (best practices)
Never forget the DHCP does NOT necessarily mean "dynamic addresses". Depending upon your corporate culture, it may be perfectly acceptable for DHCP to hand out statically assigned addresses to your hosts. This would allow your build process to be easy, and you can have the host never DHCP again after it's up and running (until you rebuild it!). On Feb 22, 2011, at 8:15 AM, Jonathan Gazeley wrote: > We have a small pool of DHCP IP addresses for use only in the build process. > This is our process: > > 1. We boot the servers from PXE network boot > > 2. They get one of the temporary IPs > > 3. They start a CentOS network install using a kickstart file with the bare > minimum of packages selected, including puppet > > 4. The last stage of the kickstart is to set puppet running > > 5. At this stage, human intervention is required to authorise the new machine > in puppetca. I'm aware that it is possible to have this step done > automatically, but it can be a security risk. > > 6. Once the server is authorised in puppet, it receives a basic "common" > config from puppet, which gives it the proper static IP that it should have, > disables DHCP, sets the hostname, sets up NTP, etc. > > 7. From now on, it's dead easy to use puppet to install and configure > everything else. > > Cheers, > Jonathan > > > Jonathan Gazeley > Systems Support Specialist > ResNet | Wireless & VPN Team > IT Services > University of Bristol > > > On 22/02/11 15:47, David Kavanagh wrote: >> I'm about to start playing with Kickstart. I never really had to >> provision bare servers beyond a normal OS install, so I need something >> to use along with Puppet. Is there a general consensus on what the best >> option is? >> I'd need to set up the node with IP/hostname/role. (I have a custom fact >> for role). I figured I'd simply ssh in to write the role file, but if >> I'd rather not use dhcp, I suppose I'll need to get the network >> interface configured in another way. What do folks generally do here? >> >> David >> >> -- >> 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. > -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
Foreman could come in handy. -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
We have a small pool of DHCP IP addresses for use only in the build process. This is our process: 1. We boot the servers from PXE network boot 2. They get one of the temporary IPs 3. They start a CentOS network install using a kickstart file with the bare minimum of packages selected, including puppet 4. The last stage of the kickstart is to set puppet running 5. At this stage, human intervention is required to authorise the new machine in puppetca. I'm aware that it is possible to have this step done automatically, but it can be a security risk. 6. Once the server is authorised in puppet, it receives a basic "common" config from puppet, which gives it the proper static IP that it should have, disables DHCP, sets the hostname, sets up NTP, etc. 7. From now on, it's dead easy to use puppet to install and configure everything else. Cheers, Jonathan Jonathan Gazeley Systems Support Specialist ResNet | Wireless & VPN Team IT Services University of Bristol On 22/02/11 15:47, David Kavanagh wrote: I'm about to start playing with Kickstart. I never really had to provision bare servers beyond a normal OS install, so I need something to use along with Puppet. Is there a general consensus on what the best option is? I'd need to set up the node with IP/hostname/role. (I have a custom fact for role). I figured I'd simply ssh in to write the role file, but if I'd rather not use dhcp, I suppose I'll need to get the network interface configured in another way. What do folks generally do here? David -- 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] Re: error: Could not intern from pson: source did not contain any PSON!
addtional info... ruby 1.8.7 p299 built from source rubygem 1.5.7 latest facter version centos 5.5 (latest yum update) On Feb 22, 8:19 am, Jed wrote: > anyone know what the heck this can be ...is it indeed a bug ? --- > i;ve seen some history that is was a bug on the 0.24/5 platforms ... > but my server and my client are from 2.6.4 (they were built from the > same source at the same time, using RPM SPECs) > > Feb 22 07:20:44 puppetclient01 puppet-agent[13954]: triggered run > Feb 22 07:20:49 puppetclient01 puppet-agent[13954]: Finished catalog > run in 4.26 seconds > Feb 22 07:22:35 puppetclient01 puppet-agent[13954]: Finished catalog > run in 3.28 seconds > Feb 22 07:32:40 puppetclient01 puppet-agent[13954]: Finished catalog > run in 3.07 seconds > Feb 22 07:42:44 puppetclient01 puppet-agent[13954]: Finished catalog > run in 3.11 seconds > Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Could not retrieve > catalog from remote server: Could not intern from pson: source did not > contain any PSON! > Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Using cached > catalog > Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Could not retrieve > catalog; skipping run > Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Could not retrieve > catalog from remote server: Could not intern from pson: source did not > contain any PSON! > Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Using cached > catalog > Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Could not retrieve > catalog; skipping run > Feb 22 08:12:49 puppetclient01 puppet-agent[13954]: Finished catalog > run in 3.23 seconds > > On Jan 4, 6:29 pm, joe wrote: > > > I have the same intermittent error, but both the client and server are > > on 2.6.4. Is there any other reason this could happen? > > > On Dec 6 2010, 3:51 pm, "russell.fulton" > > wrote: > > > > > This can happen when your client's major version is larger than your > > > > server's major version. Is that possable? > > > > Indeed! > > > > Thanks -- clients on 2.5 server on 2.6... -- 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.
Re: [Puppet Users] provisioning bare metal (best practices)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why not use DHCP? This is what it's for. The general standard that I've seen is DHCP + KS + modification scripts/puppet/whatever Trevor On 02/22/2011 10:47 AM, David Kavanagh wrote: > I'm about to start playing with Kickstart. I never really had to provision > bare servers beyond a normal OS install, so I need something to use along > with Puppet. Is there a general consensus on what the best option is? > I'd need to set up the node with IP/hostname/role. (I have a custom fact for > role). I figured I'd simply ssh in to write the role file, but if I'd > rather not use dhcp, I suppose I'll need to get the network interface > configured in another way. What do folks generally do here? > > David > > -- > 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. - -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaug...@onyxpoint.com phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNY96DAAoJECNCGV1OLcyp6FoH/1LoCtKepX82ACa2MsAPeUOB hp+72RZUq6cfUgdiN3JlJWYMqZr2whFmzyPLeqbvNLdRcg2QMdNL5l6lQ5d3Tbt9 q/C4GXJRKTLGUAWBxRu/ij9gAx3ZL9zaUi6CJ411ftSZuRjjRGYc7v0eo6R0 gXfthQJB8E/jWEFeWhOAhSrfyiLn9uHg8ZjRPz3M3povVBHtk76s1hLMssQbPDsI SsRcnO016n3dOTul4PcLAPati2pKo32+Md67wI/cqiq+ZOnVXbq925Q0KVbLdyYn L6faHGe9s1GcrLsH1IDvbFpjMxQiBzXT00uDOsZ7ici4BPYoJoSCxfHM5V6/I7k= =esai -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] provisioning bare metal (best practices)
I'm about to start playing with Kickstart. I never really had to provision bare servers beyond a normal OS install, so I need something to use along with Puppet. Is there a general consensus on what the best option is? I'd need to set up the node with IP/hostname/role. (I have a custom fact for role). I figured I'd simply ssh in to write the role file, but if I'd rather not use dhcp, I suppose I'll need to get the network interface configured in another way. What do folks generally do here? David -- 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] Problem with module
Hi,
I'm having a problem with a module that works on my production servers, but
is giving me grief when ran from scratch. When I run the client I get:
[root@hlsdevcms1 puppet]# puppetd -tv
info: Retrieving plugin
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Loading facts in apache-ports
info: Loading facts in location
info: Loading facts in dell
info: Loading facts in convera
info: Caching catalog for hlsdevcms1.law.harvard.edu
err: Could not run Puppet configuration client: Could not find user rhythmyx
I have tried everything I can think of to add more and more require =>
statements into the two .pp's that comprise the module but it refuses to
find the user. I have run puppetmasterd in debug mode and the client in
debug mode to no avail, neither gives me any more information on why this
would fail. I've checked in the local yaml on the client and the rhythmyx
stuff appears in there, including the comment statement in the user{}, so
it's definitely in the catalog.
The init.pp (apologises for what a mess this is, but I've been messing with
it trying to get it working):
##
## Install rhythmyx.
##
class rhythmyx {
include rhythmyx::install
if defined(Class["splunk4::client"]) {
concat::fragment{"splunk4-rx":
target =>
"/opt/splunk/etc/system/local/inputs.conf",
content =>
"[monitor:///opt/rhythmyx/Rhythmyx/.../*.log]\ndisabled = false\nsourcetype
= rhythmyx\nindex = rhythmyx\n_blacklist = rx_lib.*\\.log\n",
}
}
##
## Users/Groups
##
user { "rhythmyx":
ensure => "present",
uid => 5000,
gid => 5000,
comment => "rhythmyx user",
home => "/opt/rhythmyx",
shell => '/bin/bash',
managehome => true,
require => Group['rhythmyx'],
}
group { "rhythmyx":
ensure => "present",
gid => "5000",
}
service { "RhythmyxD":
ensure => "running",
hasrestart => "false",
hasstatus => "false",
pattern => "RhythmyxServer.exe",
start => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon start
/opt/rhythmyx/Rhythmyx/",
stop => "/opt/rhythmyx/Rhythmyx/bin/RhythmyxDaemon stop
/opt/rhythmyx/Rhythmyx && sleep 45",
require => Exec["rx-permissions-rhythmyx"],
}
##
## Crons
##
file {
"/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationFullEdition.sh":
ensure => "present",
source =>
"puppet:///modules/rhythmyx/hls_ScheduledPublicationFullEdition.sh",
owner => "rhythmyx",
group => "rhythmyx",
mode => "755",
require => [ User["rhythmyx"], Group["rhythmyx"] ],
}
file {
"/opt/rhythmyx/Rhythmyx/AppServer/bin/hls_ScheduledPublicationIncrementalEdition.sh":
ensure => "present",
source =>
"puppet:///modules/rhythmyx/hls_ScheduledPublicationIncrementalEdition.sh",
owner => "rhythmyx",
group => "rhythmyx",
mode => "755",
require => [ User["rhythmyx"], Group["rhythmyx"] ],
}
##
## Backups
##
tidy {
"/opt/rhythmyx/Rhythmyx/AppServer/server/rx/deploy/publogs.war":
age => '90d',
matches => '*.log',
recurse => 'true',
}
tidy { "/tmp/rxtemp.rhythmyx":
age => '2d',
matches => '*.tmp',
recurse => 'true',
}
cron { "Rhythmyx restart":
command => "/etc/init.d/RhythmyxD restart",
ensure => "present",
user=> "root",
minute => "00",
hour=> "03",
weekday => "3",
}
}
The install.pp:
##
## Install rhythmyx
##
class rhythmyx::install {
$url = extlookup("url")
$rxsqlserver = extlookup("rxsqlserver")
#package { 'compat-libgcc-296': ensure => present }
#package { 'compat-libstdc++-296': ensure => present }
#package { 'compat-glibc': ensure => present }
File { owner => rhythmyx, group => rhythmyx, mode => 755, require =>
User["rhythmyx"], }
file { "/opt/rhythmyx/":
ensure => "directory",
require => [ User["rhythmyx"], Group["rhythmyx"] ],
}
exec { "rx-permissions-rhythmyx":
command => "chown -R rhythmyx:rhythmyx /opt/rhythmyx",
cwd => "/opt/",
require => [ File['/opt/rhythmyx'], User['rhythmyx'] ],
}
file { "/etc/init.d/RhythmyxD":
ensu
Re: [Puppet Users] Re: How to add ubuntu ppa
On Feb 22, 2011, at 10:09 AM, Nigel Kersten wrote: > On Tue, Feb 22, 2011 at 12:08 AM, Rawler wrote: >> What about keys? > > Run an exec that adds the key. How would you normally solve this ? Indeed, this is what I have done previously. The other option is to use a File resource for the keys as well which is rather easy method if your deployment shares a set of repositories. -Mark > >> >> On Jan 14, 12:11 am, Nigel Kersten wrote: >>> On Thu, Jan 13, 2011 at 2:07 PM, Kevin Beckford wrote: Now, I noticed the yumrepo, but this is of little use today, I need to add an ubuntu ppa ( a few really ) to my installation. How would this be done? Is there a provider that can do this? I searched for one, and saw an answer dating from 09, but surely things have changed since then? >>> >>> Given how simple the text file format for a PPA is, I tend to do this >>> with a simple define that wraps a File resource, and then ensure >>> apt-get update is called after the PPA is defined. >>> >>> >>> >>> >>> >>> >>> >>> >>> -- 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. >> >> > > -- > 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.
Re: [Puppet Users] Re: How to add ubuntu ppa
On Tue, Feb 22, 2011 at 12:08 AM, Rawler wrote: > What about keys? Run an exec that adds the key. How would you normally solve this ? > > On Jan 14, 12:11 am, Nigel Kersten wrote: >> On Thu, Jan 13, 2011 at 2:07 PM, Kevin Beckford wrote: >> > Now, I noticed the yumrepo, but this is of little use today, I need to add >> > an ubuntu ppa ( a few really ) to my installation. How would this be done? >> > Is there a provider that can do this? >> > I searched for one, and saw an answer dating from 09, but surely things >> > have >> > changed since then? >> >> Given how simple the text file format for a PPA is, I tend to do this >> with a simple define that wraps a File resource, and then ensure >> apt-get update is called after the PPA is defined. >> >> >> >> >> >> >> >> >> >> > -- >> > 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. > > -- 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 add ubuntu ppa
What about keys? On Jan 14, 12:11 am, Nigel Kersten wrote: > On Thu, Jan 13, 2011 at 2:07 PM, Kevin Beckford wrote: > > Now, I noticed the yumrepo, but this is of little use today, I need to add > > an ubuntu ppa ( a few really ) to my installation. How would this be done? > > Is there a provider that can do this? > > I searched for one, and saw an answer dating from 09, but surely things have > > changed since then? > > Given how simple the text file format for a PPA is, I tend to do this > with a simple define that wraps a File resource, and then ensure > apt-get update is called after the PPA is defined. > > > > > > > > > > > -- > > 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] Re: error: Could not intern from pson: source did not contain any PSON!
anyone know what the heck this can be ...is it indeed a bug ? --- i;ve seen some history that is was a bug on the 0.24/5 platforms ... but my server and my client are from 2.6.4 (they were built from the same source at the same time, using RPM SPECs) Feb 22 07:20:44 puppetclient01 puppet-agent[13954]: triggered run Feb 22 07:20:49 puppetclient01 puppet-agent[13954]: Finished catalog run in 4.26 seconds Feb 22 07:22:35 puppetclient01 puppet-agent[13954]: Finished catalog run in 3.28 seconds Feb 22 07:32:40 puppetclient01 puppet-agent[13954]: Finished catalog run in 3.07 seconds Feb 22 07:42:44 puppetclient01 puppet-agent[13954]: Finished catalog run in 3.11 seconds Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Could not retrieve catalog from remote server: Could not intern from pson: source did not contain any PSON! Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Using cached catalog Feb 22 07:52:45 puppetclient01 puppet-agent[13954]: Could not retrieve catalog; skipping run Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Could not retrieve catalog from remote server: Could not intern from pson: source did not contain any PSON! Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Using cached catalog Feb 22 08:02:45 puppetclient01 puppet-agent[13954]: Could not retrieve catalog; skipping run Feb 22 08:12:49 puppetclient01 puppet-agent[13954]: Finished catalog run in 3.23 seconds On Jan 4, 6:29 pm, joe wrote: > I have the same intermittent error, but both the client and server are > on 2.6.4. Is there any other reason this could happen? > > On Dec 6 2010, 3:51 pm, "russell.fulton" > wrote: > > > > This can happen when your client's major version is larger than your > > > server's major version. Is that possable? > > > Indeed! > > > Thanks -- clients on 2.5 server on 2.6... -- 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.
Re: [Puppet Users] a rule being run every invocation despite no change
On Mon, 21 Feb 2011, Felix Frank wrote:
>
>
> On 02/19/2011 10:23 AM, Patrick wrote:
> > If so, you probably need to change the syntax in your define. I'm hoping
> > there's a syntax that tells puppet to join 2 arrays.
>
> If the provider in question fails to flatten the array properly, you're
> in trouble (this is true for the groups parameter of the user provider,
> for 0.25.5 at least).
>
> This is interesting and helpful:
> http://weblog.etherized.com/posts/175
Yeah, was trying originally to work out how to apply that. I don't know
whether this is the prettiest, but it works:
define append_aliases($other_aliases) {
$host_aliases += $other_aliases
host {
"$name.aao.gov.au":
ensure=> $ensure,
ip=> $ip,
host_aliases => $host_aliases,
}
}
define hostentry($ip, $hostaliases = [], $ensure = present) {
host {
$name:
ensure => absent,
}
$host_aliases = [ $name ]
append_aliases {
$name:
other_aliases => $hostaliases,
}
}
My original struggle was in working out how to initialise $host_aliases
in the caller to just $name, then appending the rest of the aliases.
Doing it the other way around was easy - I was just struggling with the
syntax and scoping. I would have liked to be able to reuse the parameter
name $host_aliases, but far too much juggling to get it around in the
right order to have host_aliases appended back onto something that ends up
being called host_aliases again.
--
Tim Connors
--
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.
Re: [Puppet Users] header too long (OpenSSL::X509::CRLError) ?
On 02/21/2011 06:21 PM, vincent wrote: > I have removed the ca_crl.pem puppet master has create a new one > but some hosts are not working now: > > host1 OK : > # puppetd -tv > info: Caching catalog for host1.bc > info: Applying configuration version '1298308566' > notice: Finished catalog run in 0.06 seconds > > host2: > # puppetd -tv > err: Could not retrieve catalog from remote server: hostname not match > with the server certificate > warning: Not using cache on failed catalog > err: Could not retrieve catalog; skipping run Does host2 have a server= setting in its puppet.conf? -- 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.
Re: [Puppet Users] Re: Error 400 on SERVER: Could not intern from yaml: can't convert Symbol into String
On Feb 22, 2011, at 12:06 AM, donavan wrote: > On Feb 15, 5:21 pm, Patrick wrote: >> Does anyone have a guess if this bug is in the client, the master, or >> dashboard? My report value is "reports = http, store".If the error was >> originally from dashboard, would the master have failed to save the file >> because the order matters? > > I've seen this previously. I ended up noticing this in interactive > tests, and when some clients would go "stale". Looking at debug the > error was only with storing the report on the server, the client was > fine otherwise. I only use "reports = http", so I;m not sure if you'd > have the "store" copy. > > Didn't look in much detail as, IIRC, it was fixed shortly after I > noticed. I think it was recently fixed in one of the 2.6.x minor > releases, 2.6.4 maybe?. Looking at changelog would be a good starting > place to narrow it down more. > > Depending on how you run the master (webrick, passenger, etc) you > should have a better error message there. Unfortunately some of the > error logs arent time stamped so it requires guesstimation. Alright. Thanks. Knowing it's probably fixed makes me feel better about it. -- 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: Error 400 on SERVER: Could not intern from yaml: can't convert Symbol into String
On Feb 15, 5:21 pm, Patrick wrote: > Does anyone have a guess if this bug is in the client, the master, or > dashboard? My report value is "reports = http, store". If the error was > originally from dashboard, would the master have failed to save the file > because the order matters? I've seen this previously. I ended up noticing this in interactive tests, and when some clients would go "stale". Looking at debug the error was only with storing the report on the server, the client was fine otherwise. I only use "reports = http", so I;m not sure if you'd have the "store" copy. Didn't look in much detail as, IIRC, it was fixed shortly after I noticed. I think it was recently fixed in one of the 2.6.x minor releases, 2.6.4 maybe?. Looking at changelog would be a good starting place to narrow it down more. Depending on how you run the master (webrick, passenger, etc) you should have a better error message there. Unfortunately some of the error logs arent time stamped so it requires guesstimation. -- 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.
