Re: [Puppet Users] Re: New Puppet report processors...
(possible double-post) James, This is all wonderfully helpful and I just spent a little while writing up a Zenoss processor to send an event on failure using XMLRPC::Client, modeled directly after your puppet-zendesk module, replacing the HTTParty guts with XMLRPC guts. I've encountered a problem though (and we can refer to puppet-zendesk code): When I stuff a fail() into a manifest and run, it fails, sends a report to the PM, and the PM logs this: Report zenoss failed: undefined method `status' for # The line in question is from zendesk.rb:25 if self.status == 'failed' ... end So, it's breaking there, but when I replace self.status with "var" and var = 'failed', bypassing the if, the rest of the code works and the event appears in zenoss. I'm running 2.6.4 on the master & client. pluginsync is true on both, and reports = zenoss only on the master for this test. Why is self.status not working in this case? -- 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: New Puppet report processors...
Thanks for the help off-list, James.
here's the stub I'm using to check if the log is error-ful, inside of
process():
def process
failure = false
#iterate through each log object and look for failures
self.logs.each do |log|
if log.level.to_s == 'err' || 'alert' || 'emerg' || 'crit'
failure = true
end
end
if failure
Puppet.debug "Creating Zenoss event for failed run on #{self.host}."
###
This definitely costs a few more cycles than with 2.6.5+.
I'll publish the rest of the Zenoss processor on github tomorrow or Friday.
-Don
On Wed, Jun 8, 2011 at 5:23 PM, James Turnbull wrote:
> Don wrote:
> >
> > I'm running 2.6.4 on the master & client. pluginsync is true on both,
> > and reports = zenoss only on the master for this test.
> >
> > Why is self.status not working in this case?
> >
>
> The issue is that status is only available in the V2 report format in
> Puppet 2.6.5 and onwards. Before this you need to check for "err" tags
> to find failed runs.
>
> Regards
>
> James Turnbull
>
> --
> James Turnbull
> Puppet Labs
> 1-503-734-8571
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-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: New Puppet report processors...
Ok, here's the report processor to send events to Zenoss, based off
James' Zendesk module.
https://github.com/donjohnson/puppet-zenoss
-Don
Release Engineer / Toolsmith, VerticalResponse
On Wed, Jun 8, 2011 at 6:09 PM, Don wrote:
> Thanks for the help off-list, James.
>
> here's the stub I'm using to check if the log is error-ful, inside of
> process():
>
> def process
>
> failure = false
>
> #iterate through each log object and look for failures
> self.logs.each do |log|
> if log.level.to_s == 'err' || 'alert' || 'emerg' || 'crit'
> failure = true
> end
> end
>
> if failure
> Puppet.debug "Creating Zenoss event for failed run on #{self.host}."
> ###
>
> This definitely costs a few more cycles than with 2.6.5+.
>
> I'll publish the rest of the Zenoss processor on github tomorrow or Friday.
>
> -Don
>
> On Wed, Jun 8, 2011 at 5:23 PM, James Turnbull wrote:
>>
>> Don wrote:
>> >
>> > I'm running 2.6.4 on the master & client. pluginsync is true on both,
>> > and reports = zenoss only on the master for this test.
>> >
>> > Why is self.status not working in this case?
>> >
>>
>> The issue is that status is only available in the V2 report format in
>> Puppet 2.6.5 and onwards. Before this you need to check for "err" tags
>> to find failed runs.
>>
>> Regards
>>
>> James Turnbull
>>
>> --
>> James Turnbull
>> Puppet Labs
>> 1-503-734-8571
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-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] Server Hierarchies and other configuration questions
I apologize if this has been asked before but if it has- my google technique has failed me. If anyone can point me at the right docs I'm happy to dive right in. While I'm not having any problems with Puppet, I am having some trouble understanding the best practices. Specifically: I have a basenode defined. I also have several different collections of servers and workstations. I've created a class called prodservers, a class called devservers and a class called workstations- each one inherits basenode and is then inherited by specific nodes. Should I be doing this in a class? If so what is the best place to store these class definitions- right now I am using manifests/classes/ workstation.pp and server.pp. Should this be done in a module instead? Putting specific configuration settings in a module (even if it is a module called "workstation" just feels wrong. http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice specifically says: "Stop using the manifests area to house classes, definitions, etc. Instead, use module exclusively to manage almost every single class, definition, template, file, etc." That would seem to run counter to the way I've done things. What am I missing? I'd like the admin that comes after me to be able to make sense of this deployment. Another question: The sample templates.pp in the best practices page defines a baseclass and then several types of servers. In what case would you define a baseclass instead of a basenode that you inherit? If you have different classes of servers then templates.pp can easily get unwieldy. I'm using templates.pp and just including my server and workstation specific classes. Is there a more sensible way to organize this? Lastly: Was there a technical reason to split out /services/ and /clients/ from the rest of the modules? It seems somewhat arbitrary and makes configuring certain services a little less intuitive (for example: NTP which is included on all servers, but has a different configuration on the NTP master). What's the best practice here? Do people create a subclass that overrides and disables the generic NTP config and substitutes a server config? What's the best way to define a "::disabled" class? The best practices gives openssh::disabled as an example but I'm having trouble understanding how that would work if the openssh class was already added to the generic server class, but needed to be disabled on a specific system. My apologies for the length of the email- I've been having a lot of fun writing recipes for puppet but these questions have been stopping me from going all out with my deployment. I'd like to get it right (or as close as possible) the first time. Thanks, -Don --~--~-~--~~~---~--~~ 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: Server Hierarchies and other configuration questions
> My own ntp module[1] only knows two kinds of ntp hosts: servers and
> clients. The former connect to each other and external sources, while
> the latter only connect to the local servers. The distinction is easily
> done: those nodes which have set $ntp_servers are those which connect to
> these external servers and thus _are_ servers. All others are clients.
I did this too initially- but I consider NTP an "enterprise" service
and was
going to put it in /services/ but then I would end up with two NTP
modules-
one for NTP servers in /services and one for NTP clients. That seems
really
hackish.
> You can include classes that inherit from classes that are already
> included and this will "patch up" the resources. The following is legal
> and will result in a disabled openssh service on the node "strange":
>
> class openssh {
> service { openssh: ensure => running, enable => true }
> class disabled inherits openssh {
> Service[openssh] { ensure => stopped, enable => false }
> }
> }
>
> node fine {
> include openssh
> }
>
> node strange inherits fine {
> include openssh::disabled
> }
I understand how this would work for a service like ssh- but what
about in the case of something
like NTP? In that case I would have:
class ntp {
file { "/etc/ntp.conf":
source => "puppet:///ntp/ntpclient.conf",
require => Package["ntp"]
}
}
class s_ntp { # in /services
file { "/etc/ntp.conf":
source => "puppet:///s_ntp/ntpserver.conf",
require => Package["ntp"]
}
}
node basenode {
include ntp
}
node xyz inherits basenode {
}
Now if I do this for my NTP master:
node ntpmaster inherits basenode {
include s_ntp
}
I'm going to have two NTP files. Is there a way to excude the earlier
definition of NTP so I'm not trying to have it update the same file
twice?
Is there a more sensible way of doing this that I'm not thinking of?
Should I just avoid /services because I clearly don't understand what
it's
for?
-Don
--~--~-~--~~~---~--~~
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] Server Hierarchies Part Two (Puppet's Revenge)
Let me apologize in advance for being dense.
When I manage systems- I organize them into hierarchies.
All my systems share certain global bits in common- NTP servers or the
root domain name for example.
All the systems within a given site or environment share other bits in
common- LDAP servers, a sub domain, default routes, etc. Specific
sites may even override some of the global settings- for example a
local NTP server for a mission critical site.
Then I have servers within those sites that once again might override
the more general site or global settings. The NTP master for a site is
not going to use itself as a server- it should use a higher precision
clock from somewhere else. There may be a special ldap base for the
research department, etc.
I can find no good way in puppet to create these sorts of hierarchies.
If I defined base nodes and try to inherit values- puppet is
declarative so later values do not get imported.
If I define classes for global, then site, then system and try to do
something like:
node ntpserver {
$ntp_master = "accurate.example.com"
include site::nyresearch
include site::global
}
None of the values set in nyresearch will be available to classes in
global because of scoping rules.
How are folks making this work? Have I completely missed a totally
awesome feature or language keyword somewhere along the line? Are
there fun tricks with inheritance that I am missing?
Explanations or links to good docs would be greatly appreciate.
If I'm trying to go about this all wrong and someone can explain the
error of my ways, that too would be appreciated.
-Don
--~--~-~--~~~---~--~~
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: Server Hierarchies and other configuration questions
> This were template files com in really handy. Instead of having two > ntp .conf files you use one ntp_conf.erb that has a case switch. If I put a case statement in the .erb file then I've tied the template to a specific host or set of hosts. I'd rather pass in the variables to the template and keep the logic outside the template. This is sort of what I've done. I end up with a template file that accepts things like the master servers as an array, as well as the ACL's and so on. It populates just fine with the variables I specify. I specify a null set of ACL's for the clients, and different masters and such for the servers. In the end we come back to the same sort of problem though- It's not possible to override values, and so we define everything backwards. That, plus the scoping rules, makes it (to me at least) very difficult to build a nice clean organizational structure. -Don --~--~-~--~~~---~--~~ 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: Server Hierarchies Part Two (Puppet's Revenge)
> One possibility would be to include site::global within
> site::nyresearch. Then the class would receive all variables.
Wow, how did I miss that? That may very well solve a bunch of my
problems- it's not as transparent as I would prefer (you can't see at
a glance what resources a node references) but it has got to be better
than what I'm dealing with now. Thanks for the feedback.
> $global_ntp
> $nyresearch_ntp
> $local_ntp
>
> and use a custom function to make a site specific lookup in the ntp class:
>
> $ntp_master = site_value("ntp")
I considered doing that but it just feels like a lot of work for
something I think should just be part of the language.
Thanks for all the good tips everyone.
-Don
--~--~-~--~~~---~--~~
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: Server Hierarchies Part Two (Puppet's Revenge)
> Wow, how did I miss that? That may very well solve a bunch of my
> problems- it's not as transparent as I would prefer (you can't see at
> a glance what resources a node references) but it has got to be better
> than what I'm dealing with now. Thanks for the feedback.
Nope spoke too soon. Scoping screws this up.
For example:
class zones::global {
$ntp_servers = ['ntp01.example.com',
'ntp02.example.com']
$ntp_acls = ['']
include ntp
}
class zones::nyc {
$ntp_servers = ['ntp01.othersite.com',
'ntp02.othersite.com']
include zones::global
}
node host1.example.com {
include zones::nylrc
}
The variables in global are available to NYC but the variables I have
overridden in NYC are not available to global. In the end,
host1.example.com ends up with ntp01.example.com as it's NTP server
instead of ntp01.othersite.com because of scoping.
Am I crazy for thinking this sort of hierarchical structure would be
amazingly useful and is basically impossible with puppet?
Is there some reason I am missing that would make the above a terrible
idea?
Without the above sort of hierarchy I'm going to end up with a jumble
of logic statements and node descriptions that could otherwise be made
incredibly simple.
What am I missing?
-Don
--~--~-~--~~~---~--~~
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: Server Hierarchies and other configuration questions
> Here I am seeing a thought process barrier. You do not have to tye a
> template case to _servers_ by name. The idea is to tye the template
> case to _roles_.
Great- I have a "role" called NTP master. The NTP master in datacenter
A uses a different stratum 1 clock than the master in Datacenter B.
The NTP client in office A uses different masters than clients in
office B. Building a hundred cases into my template file to cover all
the variations is completely unmanageable. I want to be able to set
defaults for certain zones and then be able to override them. Puppet
seems to be _completely_ against that philosophy.
I also do not like the idea of mixing a module definition (which
covers things like required packages and services) with specific
settings like server names (even if the server name is part of a case
statement in the template). My templates are all _completely_ generic.
I can use them in any site by altering the variables I pass in.
(I have used $ldap_server as a variable to determine whether or not to
include the slapd.conf and openldap-servers packages- but that doesn't
obviate the need to be able to set values for the variables I need to
pass into the templates).
> That way it does not matter what the server name is
> or where it is. If it is defined as have having a ntp server role then
> it gets that configuration.
Of course it matters where the server is. Different sites have
different reference clocks, different masters, different ACL's.
The "role" is fine for defining what packages to include,
I need "zones" which allow me to specify default settings for the
packages in those roles! Without that I either need to split my
specific settings up into dozens of modules and try to manage them
that way (which is silly given that there is bound to be overlap
between settings and one of the first rules of normalization is to
avoid duplication) or establish a completely flat node hierarchy which
will also include lots of duplication.
> One of the strengths I have found in
> templates is that you can but the logic in the template.
This means that to change something like an ACL, which might be the
same across several different services, you now need to change it in
several templates, or several node definitions. That can not be
considered a good way to do things.
I feel like the right way to do this is simple:
I define zones (or sites or environments or whatever). Each has
certain values set and subsequent includes override previous ones.
For example:
class zone::global {
$ldap_base = "dc=example,dc=com"
$ldap_servers = ['ldap01.example.com', 'ldap02.example.com']
$ntp_servers = ['ntp01.example.com',
'ntp02.example.com']
$ntp_acls = ['']
$my_domain = "example.com"
}
class zones::nyc {
$ldap_base = "dc=nyc,dc=example,dc=com"
$ldap_servers = ['ldap01.nyc.example.com', 'ldap02.nyc.example.com']
$my_domain = "nyc.example.com"
}
class: roles::general {
include ldap
include ntp
include resolver
}
class roles::ldapserver {
$ldap_server = true
include roles::webserver
}
node www02.example.com {
$ldap_servers = ['ldaptest1.nyc.example.com',
'ldaptest2.example.com']
include zones::global
include roles::general
include roles::webserver
}
node host1.nyc.example.com {
$ldap_servertype = "slave"
include zones::global
include zones::nyc
include roles::general
include roles::ldapserver
}
In the last node example I defined roles::ldapserver. That role
specifies the packages to be installed for an ldap server, as well as
the server type. It still includes the ldap base ldap module, but with
some additional packages and possibly with some additional default
values passed in.
That allows me to keep all my settings (roles, zones, etc.) in /etc/
puppet/manifests and my modules in /etc/puppet/modules thus preserving
a division between settings and implementation.
It also lets me see, at a glance, what I am including and what I'm
excluding. I don't need to look into a specific module template to see
what settings may or may not be enabled. It's right there in the
manifests directory where I am already working. It also means I can
share modules much more easily.
Am I nuts in thinking that this is a better organizational style? The
puppet books talks about workarounds for some of these problems.
Should we be working around these issues or do they need to be
"fixed"?
Perhaps there is a serious implication for the language that I've
completely missed- if so- please let me know.
-Don
--~--~-~--~~~---~--~~
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: Server Hierarchies and other configuration questions
Ack- sorry I got my examples backwards- The overrides should have come
after the included classes like so:
> node www02.example.com {
> include zones::global
>
> include roles::general
> include roles::webserver
>
> $ldap_servers = ['ldaptest1.nyc.example.com',
> 'ldaptest2.example.com']
>
> }
>
> node host1.nyc.example.com {
> include zones::global
> include zones::nyc
>
> include roles::general
> include roles::ldapserver
>
> $ldap_servertype = "slave"
> }
Sorry for the confusion (and the previous absurdly long email).
-Don
--~--~-~--~~~---~--~~
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: Server Hierarchies and other configuration questions
> Long yes, but it did help define your issue. I think the first layout > would be a more correct one, and from my experience should work, I > think. Have you tried doing zones::global and zones::nyc as inherits? > When you then redefine the variables in the node definition they > should override the settings in the inheritance. Inheritance puts > things in the parent scope and includes puts variables in the child > scope I thought variables you inherited would already be set and thus unchangeable. I'm testing this now but it seems to work. Thanks for the insight. All the docs I've seen suggest using node inheritance to manage "roles" but it seems to me that we should be using classes to manage roles and inheritance to handle variables. It's not as clean because you can't see at a glance what variables a node is inheriting (because you can only inherit one other node and thus have to build a node tree- but at least this seems to work. I'm going to go test this now and see if I can get it to do everything I want. It definitely looks like progress. > > This means that to change something like an ACL, which might be the > > same across several different services, you now need to change it in > > several templates, or several node definitions. That can not be > > considered a good way to do things. > This type of situation where you have the same thing defined across > several nodes is in theory best handled by virtual resources. I have > encountered similar issues and that is the advice I got. I am still > working on making that change so am not sure who much use my > explaining virtual resources will be. Virtual resources could work, but it seems overly complex for what i'm trying to do. It's not so much that I'm trying to define the same object across multiple resources, but more a specific variable. Having to create a virtual resource and then instantiate it every time I add a new ACL seems to be a lot more trouble than just setting my ACL variable appropriately. > As a general thought, looking at the complexity you have, are you > using external node definitions? From what I have read on the list and > about you site that looks like it would be extremely useful to you and > possible something using stored configs could help resolve your > issues. I already run LDAP but haven't moved my nodes into it yet. I don't want to go to all that trouble until I'm sure I can resolve some of these hierarchy issues. Just moving the values into ldap won't help unless I start writing all sort of functions in puppet to query resources and configure them appropriately. Again- that's way more trouble than I'm willing to deal with. At that point I might as well invest the time and effort to learn Chef as it seems to have native support for overrides. I just wish I knew why puppet was designed in the way it was sometimes. Scoping makes sense in a lot of languages, but here it just seems to get in the way. Ditto for the declarative nature of the language. -Don --~--~-~--~~~---~--~~ 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: Server Hierarchies Part Two (Puppet's Revenge)
> In James Turnbull's book there's a good discussion on the variable
> scoping issue (excellent book btw, a must have). He offered a
I have it, and while a good book, I don't think my problems are with
understanding the issues- I just want puppet to do things it can't.
> $ntp_servers = ['ntp01.example.com',
> 'ntp02.example.com']
>
> class zones::global {
> $ntp_acls = ['']
> include ntp
> }
See- now you're defining a role (ntp) and settings ($ntp_acls) for
that role all in the same place. I wanted to use zones to define
various settings and then just keep overriding them. If I include
classes then the scoping rules prevent the variables in my zone class
from being seen by my role class so that doesn't work either.
What I've started doing is to use inheritance to build a variable
tree:
node global {
ntp_servers = ['']
}
node zonenyc inherits global {
$ntp_servers = ['10..1.1.10']
}
node client inherits zonenyc {
include roles::general
}
node ntpmaster inherits zonenyc {
$ntp_servers = ['pool.ntp.org']
include roles::general
include roles::ntpmaster
}
It's not nearly as clean as I would like, but at least I can override
variables and accomplish most of what I want to do.
-Don
--~--~-~--~~~---~--~~
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: Override configuration defined in inherited node?
> couple of nodes that need a different configuration. So what I need to do on
> these particular nodes are, as far as I know, one of these things:
> 1) Find a way to override the NTP configuration defined in the base node
> 2) Make sure they don't inherit the base node, so that I can define a
> different NTP configuration here
I literally just asked this same question and the solution is less
than stellar.
Node inheritance is useful for variables and overriding. Classes are
useful for specifying system roles.
In more concrete terms this is what I do:
class roles::general {
include ntp
include ldap
}
class roles::ntpserver {
include ntp::master
}
node zone-global {
ntp_servers = ['']
}
node zone-nyc inherits zone-global {
$ntp_servers = ['10..1.1.10']
}
node client inherits zone-nyc {
include roles::general
}
node ntpmaster inherits zonenyc {
$ntp_servers = ['pool.ntp.org']
include roles::general
include roles::ntpmaster
}
This isn't nearly as clean as it could be if some of the variable and
scoping rules were different, but for now it has sufficed to clean up
my puppet config dramatically.
-Don
--~--~-~--~~~---~--~~
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: Override configuration defined in inherited node?
Sigh- typo'd again.
That should have read:
> class roles::ntpmaster {
> include ntp::master
> }
-Don
--~--~-~--~~~---~--~~
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: New Puppet report processors...
James, This is all wonderfully helpful and I just spent a little time writing up a Zenoss processor to send an event on failure using XMLRPC::Client, modeled directly after your puppet-zendesk module, replacing the HTTParty guts with XMLRPC guts. I've encountered a problem though (and we can refer to puppet-zendesk code): When I stuff a fail() into a manifest and run, it fails, sends a report to the PM, and the PM logs this: Report zenoss failed: undefined method `status' for # The line in question is from zendesk.rb:25 if self.status == 'failed' ... end So, it's breaking there, but when I replace self.status with "var" and var = 'failed', bypassing the if, the rest of the code works and the event appears in zenoss. I'm running 2.6.4 on the master & client. pluginsync is true on both, and reports = zenoss only on the master for this test. Why is self.status not working for me? On May 31, 8:09 am, James Turnbull wrote: > Hi all > > On my TODO list for about a year now has been a tutorial on how easy it > is to write Puppet report processors and how much more you can do with > them than just email/log/store Puppet report data. Rather than write a > whole tutorial I decided to create a whole series of examples of report > processors that should: > > a) Provide some immediate solutions that you can deploy right now, and > > b) Provide good examples of things you can do with report processing > that you can take, fork and modify. > > All of them are released under the Apache 2.0 license. > > In that spirit I've created ten new report processors: > > 1. Reports failed runs to an IRC channel > -https://github.com/jamtur01/puppet-irc > > 2. Reports failed runs and logs to PagerDuty > -https://github.com/jamtur01/puppet-pagerduty > > 3. Reports failed runs to Jabber/XMPP -https://github.com/jamtur01/puppet-xmpp > > 4. Reports failed runs to Twitter -https://github.com/jamtur01/puppet-twitter > > 5. Reports failed runs and logs to Campfire > -https://github.com/jamtur01/puppet-campfire > > 6. Reports failed runs to Twilio -https://github.com/jamtur01/puppet-twilio > > 7. Reports failed runs to Boxcar -https://github.com/jamtur01/puppet-boxcar > > 8. Reports failed runs to HipChat -https://github.com/jamtur01/puppet-hipchat > > 9. Sends metrics to a Ganglia server via gmetric > -https://github.com/jamtur01/puppet-ganglia > > 10. Reports failed runs to Growl -https://github.com/jamtur01/puppet-growl > > Comments, feedback, testing and ideas for other integrations all welcomed. > > Regards > > James > > -- > James Turnbull > Puppet Labs > 1-503-734-8571 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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] alternate hostnames, keys, and certs
I'd like to extend my use of puppet to manage my desktop/notebook macs.
As others have noted, the hostname of the mobile machines tends to change
frequently, so basing the node name (in my site.pp) and the corresponding cert
and private key names seems to be an issue.
I seem to recall somewhat talking about this at Puppet Camp last week…..
Generally my signing strategy is always to generate new certs and private keys
on the puppetmaster, and install them on the client machine as part of the
initial install (hopefully automated).
Can I generate a cert based on the macaddress of the new machine?
I tried this, and puppetca --generate made the certs and key without
complaining.
Presumably I can install these on my client machine.
If so, would I then run puppetd with a the --fqdn argument, and give the mac
address there?
And what would the name of this machine be in a node specification in the
manifest?
I put
node '00:1f:5b:f8:23:f8' { }
in my manifest, and it was very unhappy.
Any advice about how I can accomplish what I am trying to do?
Thanks,
Don
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] alternate hostnames, keys, and certs
A bit of followup here:
I changed my approach to build a more acceptable certname that would be
acceptable as a hostname, using code like this:
MACADDR=`facter macaddress_en0 | tr "[:upper:]" "[:lower:]" | sed 's/://g' `
MACADDRHOSTNAME="macaddr-${MACADDR}"
This results in something like this:
macaddr-001f5bf823f8
I generated the private key and signed cert on my puppetmaster, copied to a
client, and on the client, I did something like this:
puppetd --hostprivkey=/etc/puppet/ssl/private_keys/macaddr-001f5bf823f8.pem
--hostcert=/etc/puppet/ssl/certs/macaddr-001f5bf823f8.pem
--certname=macaddr-001f5bf823f8
So, things seem to be working the way I want now. Thanks to everyone for their
advice, particularly Nigel and Patrick.
Now that I have this working, I am thinking I would prefer to use this method
for all my machines. In my environment, any machine may have different host
names over the course of its useful life, including servers.
The FQDN is just another configurable state. Why have the puppet cert related
to the FQDN? When new hardware arrives, log it in my configuration management
DB by one its MAC addresses,
drive generation of puppet cert on that, and blast/install/configure away.
This seems like a significant improvement to me.
Don
On Oct 15, 2010, at 1:48 PM, Nigel Kersten wrote:
> On Fri, Oct 15, 2010 at 11:57 AM, Nigel Kersten wrote:
>> On Thu, Oct 14, 2010 at 10:23 PM, Don Jackson
>> wrote:
>>>
>>> I'd like to extend my use of puppet to manage my desktop/notebook macs.
>>>
>>> As others have noted, the hostname of the mobile machines tends to change
>>> frequently, so basing the node name (in my site.pp) and the corresponding
>>> cert and private key names seems to be an issue.
>>>
>>> I seem to recall somewhat talking about this at Puppet Camp last week…..
>>>
>>> Generally my signing strategy is always to generate new certs and private
>>> keys on the puppetmaster, and install them on the client machine as part of
>>> the initial install (hopefully automated).
>>>
>>> Can I generate a cert based on the macaddress of the new machine?
>>
>> You're better off using UUIDs in my opinion.
>>
>> man uuidgen
>
> I should have also mentioned that for Mac clients, there's a system
> hardware UUID that persists across reinstalls, and that may be useful.
>
> system_profiler SPHardwareDataType
>
> or
>
> facter sp_platform_uuid
>
> This is the same UUID used to composite ByHost preferences on OS X,
> and any recent vintage Mac should have it.
>
>>
>>
>>> I tried this, and puppetca --generate made the certs and key without
>>> complaining.
>>>
>>> Presumably I can install these on my client machine.
>>>
>>> If so, would I then run puppetd with a the --fqdn argument, and give the
>>> mac address there?
>>
>> no, you want to use 'certname', not fqdn.
>>
>>
>>
>>>
>>> And what would the name of this machine be in a node specification in the
>>> manifest?
>>>
>>> I put
>>>node '00:1f:5b:f8:23:f8' { }
>>>
>>> in my manifest, and it was very unhappy.
>>>
>>> Any advice about how I can accomplish what I am trying to do?
>>>
>>> Thanks,
>>>
>>> Don
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-us...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>>
>>
>>
>>
>> --
>> nigel
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] darwinports package provider under MacOS X
I am attempting to use install some macports packages via puppet:
My manifest looks like this:
$macportsineed = [ 'ncftp', 'git-core' ]
package { $macportsineed :
ensure => 'installed',
provider => 'darwinport',
}
Here is the message I get from puppetd:
debug: Puppet::Type::Package::ProviderDarwinport: Executing
'/opt/local/bin/port upgrade git-core'
err: //Node[macaddr-c8bcc8937cf9]/Package[git-core]/ensure: change from absent
to present failed: Execution of '/opt/local/bin/port upgrade git-core' returned
1: Error: git-core is not installed
To report a bug, see
debug: Puppet::Type::Package::ProviderDarwinport: Executing
'/opt/local/bin/port upgrade ncftp'
err: //Node[macaddr-c8bcc8937cf9]/Package[ncftp]/ensure: change from absent to
present failed: Execution of '/opt/local/bin/port upgrade ncftp' returned 1:
Error: ncftp is not installed
To report a bug, see
What am I doing wrong?
I am using puppetd --version
2.6.1
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] iteration question
So here is a scenario: I have a directory: ./foo ./foo/file1 ./foo/file2 ./foo/file3 … ./foo/fileN I populate this directory on a configured machine via a recursive file resource. What I would like to do is create a symlink from the parent directory to each filen in the foo subdirectory? Is there some easy way to get puppet to do that? Basically I would like to iterate thru ln -s ./foo/filen ./filen Short of writing a shell script, downloading it, and Exec'ing 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] iteration question
On Dec 3, 2010, at 12:56 PM, Patrick wrote: > Why not sync the files directly to that directory? There are other files in the parent directory that are not managed by puppet. And the names of the files are dynamic enough that it would be painful to explicity manage each file in the puppet manifest. So, what I prefer to do, is tell puppet: Create a directory, and fill it with all contents of a comparable directory on the puppet file server. And then create links from the parent directory into this managed subdirectory. > On Dec 3, 2010, at 12:48 PM, Don Jackson wrote: > >> >> So here is a scenario: >> >> I have a directory: >> >> ./foo >> ./foo/file1 >> ./foo/file2 >> ./foo/file3 >> … >> ./foo/fileN >> >> I populate this directory on a configured machine via a recursive file >> resource. >> >> What I would like to do is create a symlink from the parent directory to >> each filen in the foo subdirectory? >> >> Is there some easy way to get puppet to do that? >> >> Basically I would like to iterate thru >> >> ln -s ./foo/filen ./filen >> >> Short of writing a shell script, downloading it, and Exec'ing 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-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] having trouble with puppet 0.25.5 on openbsd 4.8 on amd64
My manifest includes this snippet
class app_client_openbsd {
$app_client_pkgs_obsd = [ 'glib2-2.24.1p2', 'gtar-1.23p1' ]
package { "${app_client_pkgs_obsd}":
ensure => 'installed',
source =>
"http://${installserver}/openbsd/${operatingsystemrelease}/packages/${hardwaremodel}/${name}.tgz";,
}
This doesn't work.
debug: Puppet::Type::Package::ProviderOpenbsd: Executing '/usr/sbin/pkg_info
glib2-2.24.1p2gtar-1.23p1'
debug: /app_client_openbsd/Package[glib2-2.24.1p2gtar-1.23p1]: Changing ensure
debug: //app_client_openbsd/Package[glib2-2.24.1p2gtar-1.23p1]: 1 change(s)
debug: Puppet::Type::Package::ProviderOpenbsd: Executing '/usr/sbin/pkg_add
http://svr.example.net/openbsd/4.8/packages/amd64/app_client_openbsd.tgz'
notice: //app_client_openbsd/Package[glib2-2.24.1p2gtar-1.23p1]/ensure: created
So why do the two strings of the two package names get smushed together instead
of being run separately?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Recent (unfun) experience with cron resource on Solaris 10 with puppet 0.25.5
I was attempting to set up some cron jobs via puppet. I was trying to get cron to mail the output of the cron jobs to a specific user, so I was attempting to set mailto=u...@example.com, via the environment => specifier. Puppet did as it was told. Unfortunately, I guess that Solaris 10 does not support setting of environment variables in crontab files (directly), so when puppet attempted to install the generated crontab, the "crontab install command" failed, and without an error or warning. It took some painful hand experimentation to figure out the problem. Also, FYI, I guess Solaris 10 doesn't support the MAILTO env variable anyway, so that is my problem. I changed my manifest, and all is working now, but a) wanted to document this on the mailing list in case someone else goes down this path b) this might be a bug in the solaris10 cron implementation of puppet…. Don -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Serving files while ignoring some (e.g. .svn)
I make user of the puppet fileserving capability to serve up configs and smaller executables I need on my deployed servers. Sometimes I populate directories to be served on the puppetmaster via subversion. When I recursively populate this kind of directory via puppet, it brings over the .svn directory, etc, which is not what I want. How can I configure either the puppet file server, or modify my manifest, to prevent pulling over the .svn directory also? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Port 8139 needs to be open between machine running puppetrun and a client puppetd machine, correct?
Hello, I am attempting to get my machines configured properly so I can use puppetrun on my puppetmaster to get clients to update themselves during my development/testing of new recipes. I understand about listen = true in the puppetd.conf file, and I also have learned about the namespaceauth.conf file, where I put stuff like: [puppetrunner] allow puppet.mydomain.com This was all I needed to get machines on the same LAN as my puppetmaster to work, but it didn't work across firewalls to machines in a colo. >From router/firewall logs, it appears that the puppetmaster needs to connect >to port 8139 of the machine running puppetd. I wasn't able to find this clearly documented, hence this email. Regards, Don -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: puppet for switches
On May 5, 2010, at 9:02 AM, seph wrote: > Geoff Crompton writes: > >> This might be a crazy idea, but it just popped into my head, and I >> wanted to know if it's possible. Perhaps not possible right now, but >> possible in a theoretical sense. >> >> Is it possible that puppet could be modified to be used to manage >> switches that have a command line based interface? > > I think there's a lot of value in configuration management system for > network stuff. Though I don't think puppet is a good fit. Puppet has > lots of types that don't really make sense in that context. > > http://www.netomata.com is the most recent thing I've seen in this > space. I'm not sure how far along they are. I am currently using the ncg, from Netomata to manage my switches/routers. Its's great, I recommend 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Problem with dashboard using live report aggregation
I am having all the problems that the following two threads reported. Like tomholl reported, I was finally able to get reporting to work by copying the puppet_dashboard.rb file into the directory site_ruby/1.8/puppet/reports And when I had previously attempted to specify libdir to be a colon separated path, puppetmasterd died/crashed. I am running puppet version 25.5 on OpenBSD (4.6) (Yes, I built new packages from the tip of OpenBSD port tree), and dashboard 1.0.0 I would definitely appreciate any advice as to what I am doing wrong…. Don On Dec 17, 2009, at 10:04 AM, tomholl wrote: > am still having some trouble getting this to work as per the > README.markdown instructions. > > I was able to get it working by copying the puppet_dashboard.rb into / > usr/lib/ruby/site_ruby/1.8/puppet/reports > > Setting the $libdir in puppet.conf seemed to work but I still kept > getting "No report named 'puppet_dashboard' " errors after each > successful catalog compile. > > The reason I think the $libdir was getting set is that the output of > 'puppetd --configprint libdir' and 'puppetmasterd --configprint > libdir' is /opt/puppetdashboard/lib/puppet (where I put my test > install) > > Since I kept getting errors about not finding the report I ran > 'puppetmasterd --configprint reports' and got an output of store. > Once I found where the store file was and copied the > puppet_dashboard.rb file into that location (/usr/lib/ruby/site_ruby/ > 1.8/puppet/reports) everything worked. > > So what am I missing? Why did I have to copy the report file over to / > usr/lib/ruby/site_ruby/1.8/puppet/reports if my $libdir was set > properly? On Jun 16, 2010, at 5:02 AM, Jon Choate wrote: > I am seeing similar issues. In my puppet.conf I set > > reports = store, puppet_dashboard > and libpath = /var/puppet/lib:$RAILS_ROOT/lib/puppet > > (RAILS_ROOT being /opt/puppet-dashboard where I installed puppet dashboard) > Using a combined path like this does not seem to work for libpath. It views > the entire string as one path. Is this by design? > > I then set libpath to just $RAILS_ROOT/lib/puppet > > With these settings I still get the message that it can't find the report > named 'puppet_dashboard'. I even tried linking the .rb files for the > puppet_dashboard report to /var/puppet/lib and use the default libpath but > that did not seem to help either. > > Any idea? > > On Mon, May 31, 2010 at 9:35 AM, christian wrote: > Hey, > > I'm exploring puppet-dashboard right now and I want to get the live > aggregation running. > But somehow I'm already failing at the puppet.conf entries ;) > > The Dashboard readme says: > ### Live report aggregation > To enable report aggregation in Puppet Dashboard, the file `lib/puppet/ > puppet_dashboard.rb` must be available in Puppet's lib path. The > easiest way to do this is to add `RAILS_ROOT/lib/puppet` to `$libdir` > in your `puppet.conf`, where `RAILS_ROOT` is the directory containing > this README. Then ensure that your puppetmasterd runs with the option > `--reports puppet_dashboard`. > > So how do I "add" that line? > > If I try something like $libdir = $vardir/lib;/usr/local/puppet- > dashboard/lib/puppet or : or , or "blank" instead of ; I always get > this error message from the clients: > "Could not prepare for execution: Got 1 failure(s) while initializing: > change from absent to directory failed: Cannot create /var/lib/puppet/ > lib,/usr/local/puppet-dashboard/lib/puppet; parent directory /var/lib/ > puppet/lib,/usr/local/puppet-dashboard/lib does not exist" > > I'm using Pupet 0.25.4 on Open Suse 11.1 and Dashboard 1.0.0 > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Problem with dashboard using live report aggregation
On Jun 21, 2010, at 1:02 AM, christian wrote: > > Btw, how is the time created that the dashboard for the reports shows? > All our servers run on CEST but the dashboard seems to use the WAT > timezone (CEST -2 hours). The timestamps that appear in the report > files are all correct. Yes, I have this problem also. Not optimal! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] question about package provider on Solaris
Hello,
Here is how I am trying to make sure sudo is installed on my solaris boxes:
package {'sudo':
ensure => 'installed',
provider => 'blastwave',
adminfile => '/usr/local/etc/adminfile',
}
The package is installed, but every time puppetd executes, I get this:
notice: //base_server/Package[sudo]/ensure: created
It seems like the package provider is not seeing that sudo is already
installed….
How can I fix that?
Both my puppetmaster and puppetd are 0.25.5
Thanks,
Don
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] question about package provider on Solaris
On Jul 13, 2010, at 5:20 PM, Jeff McCune wrote: > On Tue, Jul 13, 2010 at 5:00 PM, Don Jackson > wrote: >> It seems like the package provider is not seeing that sudo is already >> installed…. >> How can I fix that? >> >> Both my puppetmaster and puppetd are 0.25.5 > > Blastwave uses aliases for the "standard" sun formatted package names > as a convenience. Try adding the parameter name => "CSWsudo", to the > resource declaration which is the actual non-aliased name of the > blastwave sudo package if I remember correctly. Yes, that worked great. Thank you, 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] question about package provider on Solaris
On Jul 13, 2010, at 5:20 PM, Jeff McCune wrote:
> On Tue, Jul 13, 2010 at 5:00 PM, Don Jackson
> wrote:
>> It seems like the package provider is not seeing that sudo is already
>> installed….
>> How can I fix that?
>>
>> Both my puppetmaster and puppetd are 0.25.5
>
> Blastwave uses aliases for the "standard" sun formatted package names
> as a convenience. Try adding the parameter name => "CSWsudo", to the
> resource declaration which is the actual non-aliased name of the
> blastwave sudo package if I remember correctly.
I spoke too soon, this is not working for me.
Here is the error message I get:
err: //base_server/Package[sudo]/ensure: change from absent to present failed:
Execution of '/opt/csw/bin/pkg-get -f install CSWsudo' returned 1: ERROR:
CSWsudo unrecognized
Perhaps you need to run pkg-get -U
And here is the revised source:
package {'sudo':
name => 'CSWsudo',
ensure => 'installed',
provider => 'blastwave',
adminfile => '/usr/local/etc/adminfile',
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] checking if a user exists
Hi Folks,
Ive been trying to figure this out on Puppet 2.5.5 but just upgraded
to 2.6
I have this in a module to make sure zabbix is installed, configured
and running:
class zabbix_agentd
{
user { "zabbix":
name =>
'zabbix',
ensure =>
present,
comment=> "Zabbix Monitoring
System",
home => "/var/lib/
zabbix",
managehome =>
false,
shell => "/sbin/
nologin",
uid=>
"109",
}
. rest of class.
This works great on puppet clients that do not have the user zabbix,
but on clients that already have zabbix I get error such as
err: //zabbix_agentd/User[zabbix]/uid: change from 489 to 109 failed:
Could not set uid on user[zabbix]: Execution of '/usr/sbin/usermod -u
109 zabbix' returned 8: usermod: user zabbix is currently logged in
So it seems that I need some way of testing for user zabbix on the
clients, but I can't figure out how. This seems such a basic and
easy thing to do that I surprised that I have not already found the
answer.
Thanks for any suggestions.
Don
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: checking if a user exists
> If you don’t care about keeping the UID consistent, then yeah, remove that
> line as suggested.
Thanks for the suggestions. ALthought it might be nice, I don't really
care about keeping the UID consistent, but they should be system UIDs
(<500).
We have several boxes with zabbix installed via distro rpms and others
that are running old distros that do not have up-to-date rpms. For
both types I want puppet update to or install an in-house compiled
zabbix-agentd package. It seems that fixing the current UIDs by hand
would work.
I kept thinking of this little problem last night after I submitted
the original post. I thought a custom fact might work and came up
with this little snippit.
# /zabbix_agentd/lib/facter
Facter.add(:zabbix_user)
do
confine :kernel
=> :linux
setcode
do
%x{grep zabbix /etc/passwd |cut -f1 -
d:}.chomp
end
end
Then in the manifest
if $zabbix_user != "zabbix" {
user
{ "zabbix":
name => 'zabbix',
.
}
}
This worked in the tests I ran.
Thanks again for your feedback
Don
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] startup questions
Hello, I am a puppet newbie, I recently purchased & read "Pulling Strings", etc. I'm trying to install and configure puppetd on new machines built by my automated host installation system. I'm getting a fatal error when puppetd starts up after the system boot, here is the result of puppetd --debug # puppetd --debug debug: Creating default schedules debug: Failed to load library 'shadow' for feature 'libshadow' debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/etc/ puppet/ssl]: Autorequiring File[/etc/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/certs/svn01.clark-communications.com.pem]: Autorequiring File[/etc/puppet/ssl/certs] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/private_keys]: Autorequiring File[/etc/puppet/ssl] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/lib]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/log]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/private]: Autorequiring File[/etc/puppet/ssl] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/plugins]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/certs]: Autorequiring File[/etc/puppet/ssl] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/private_keys/svn01.clark-communications.com.pem]: Autorequiring File[/etc/puppet/ssl/private_keys] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/run]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ puppet/ssl/public_keys]: Autorequiring File[/etc/puppet/ssl] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/facts]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ puppet/state]: Autorequiring File[/var/puppet] debug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/etc/ puppet/puppet.conf]: Autorequiring File[/etc/puppet] debug: Finishing transaction 4441590840 with 0 changes /usr/local/lib/ruby/site_ruby/1.8/puppet/network/http_pool.rb:50:in `add_file': system lib (OpenSSL::X509::StoreError) from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:50:in `cert_setup' from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:100:in `http_instance' from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/xmlrpc/ client.rb:123:in `initialize' from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/ client.rb:94:in `new' from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/ client.rb:94:in `initialize' from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/client/ master.rb:207:in `initialize' from /usr/local/bin/puppetd:322:in `new' from /usr/local/bin/puppetd:322 This client is puppetd version 0.24.4 running on OpenBSD 4.4/amd64, the only thing in the conf file is 1 line that points puppetd at the puppetmaster server. I created the cert and private key on another box, using puppetca version 0.22.4, (running OpenBSD 4.3/amd64), and this is also the machine that runs puppetmasterd My installation system creates /etc/puppet/ssh/private_keys and ./ certs, downloads the pre-generated .pem files, and gives everything the following permissions: # ls -lR total 16 drwxr-xr-x 2 root _puppet 512 Nov 17 15:01 certs drwxr-x--- 2 root _puppet 512 Nov 17 15:04 private drwxr-x--- 2 root _puppet 512 Nov 17 15:01 private_keys drwxr-xr-x 2 root _puppet 512 Nov 17 15:04 public_keys ./certs: total 4 -rw-r--r-- 1 root _puppet 887 Nov 17 15:01 svn01.clark- communications.com.pem ./private: ./private_keys: total 4 -rw--- 1 root _puppet 887 Nov 17 15:01 svn01.clark- communications.com.pem ./public_keys: What am I doing wrong? Any advice appreciated... Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Incomplete documentation regarding master-side client cert generation?
Hello, I previously sent the email below describing a problem I was having with generating the certs on the master, and distributing them to the client right after OS installation. Further research and testing shows that in addition to transferring the private key and the cert to the new client, you also must transfer the cert for the ca. Many thanks to the blog posting at: http://watzmann.net/blog/index.php/2006/08/07/using_pregenerated_certs_with_puppet Which made this more clear. I believe that the following paragraph from the wiki is at best not clear about this, if not downright incomplete: Master-Side Client Certificate Generation It's possible to generate certificates for clients on the master side, by using puppetca --generate ; this will also sign the newly generated certificate. You might want to do this if you want to automate the conversion of non-Puppet managed servers to Puppet. You can run a script that copies the generated client keys to the right place on the client, installs Puppet and then runs puppetd to get the client's configuration. This would allow you to "Puppetize" a server with a single command. When you run puppetca --generate three files are generated - $signeddir/hostname.pem,$certdir/ hostname.pem and $privatekeydir/hostname.pem. You need to copy the private key and certificate to the corresponding directories on the client side. The client public key will be extracted from its certificate and put into $publickeydir when puppetd is run. The defaults for these directories should be subdirectories under /etc/ puppet/ssl/ with self-explanatory names, look there to find the generated files. http://www.reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity I propose that the above paragraph be augmented to include the requirement that the ca.pem be transfered from the master to the client... Best regards, Don Begin forwarded message: > From: Don Jackson > Date: November 17, 2008 3:55:02 PM PST > To: puppet-users@googlegroups.com > Subject: [Puppet Users] startup questions > Reply-To: puppet-users@googlegroups.com > > > Hello, > > I am a puppet newbie, I recently purchased & read "Pulling Strings", > etc. > > I'm trying to install and configure puppetd on new machines built by > my automated host installation system. > > I'm getting a fatal error when puppetd starts up after the system > boot, here is the result of puppetd --debug > > # puppetd --debug > debug: Creating default schedules > debug: Failed to load library 'shadow' for feature 'libshadow' > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/etc/ > puppet/ssl]: Autorequiring File[/etc/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/certs/svn01.clark-communications.com.pem]: Autorequiring > File[/etc/puppet/ssl/certs] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/private_keys]: Autorequiring File[/etc/puppet/ssl] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/lib]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/log]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/private]: Autorequiring File[/etc/puppet/ssl] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/plugins]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/certs]: Autorequiring File[/etc/puppet/ssl] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/private_keys/svn01.clark-communications.com.pem]: > Autorequiring File[/etc/puppet/ssl/private_keys] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/run]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[ssl]/File[/etc/ > puppet/ssl/public_keys]: Autorequiring File[/etc/puppet/ssl] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/facts]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[main]/File[/var/ > puppet/state]: Autorequiring File[/var/puppet] > debug: /Settings[/etc/puppet/puppet.conf]/Settings[puppetd]/File[/etc/ > puppet/puppet.conf]: Autorequiring File[/etc/puppet] > debug: Finishing transaction 4441590840 with 0 changes > /usr/local/lib/ruby/site_ruby/1.8/puppet/network/http_pool.rb:50:in > `add_file': system lib (OpenSSL::X509::StoreError) > from /usr/local/lib/ruby/site_ruby/1.8/puppet/network/ > http_pool.rb:50:in `cert_setup' > from /usr/local/lib/ruby/site_ruby/1.8/
[Puppet Users] Re: Incomplete documentation regarding master-side client cert generation?
OK, I added this info to this paragraph in the wiki. On Nov 21, 2008, at 2:46 PM, James Turnbull wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Don Jackson wrote: >> I believe that the following paragraph from the wiki is at best not >> clear about this, if not downright incomplete: >> >>Master-Side Client Certificate Generation >>It's possible to generate certificates for clients on the master >>side, by using puppetca --generate ; this will also sign >>the newly generated certificate. You might want to do this if you >>want to automate the conversion of non-Puppet managed servers to >>Puppet. You can run a script that copies the generated client keys >>to the right place on the client, installs Puppet and then >>runs puppetd to get the client's configuration. This would allow >> you >>to "Puppetize" a server with a single command. When you run >> puppetca >>--generate three files are generated >>- $signeddir/hostname.pem,$certdir/hostname.pem and >> $privatekeydir/hostname.pem. >>You need to copy the private key and certificate to the >>corresponding directories on the client side. The client public >> key >>will be extracted from its certificate and put >>into $publickeydir when puppetd is run. The defaults for these >>directories should be subdirectories under /etc/puppet/ssl/ with >>self-explanatory names, look there to find the generated files. >> >> >> http://www.reductivelabs.com/trac/puppet/wiki/CertificatesAndSecurity >> >> I propose that the above paragraph be augmented to include the >> requirement that the ca.pem be transfered from the master to the >> client... >> > > Don > > The wiki is open. Please feel free to update the section. > > Regards > > James Turnbull > > - -- > Author of: > * Pulling Strings with Puppet > (http://www.amazon.com/gp/product/1590599780/) > * Pro Nagios 2.0 > (http://www.amazon.com/gp/product/1590596099/) > * Hardening Linux > (http://www.amazon.com/gp/product/159059/) > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJJzpU9hTGvAxC30ARAjPpAJ4nZoN/pPnbCy9dB4GGd7DL6rl6PgCeOO9b > Ut1d5xJA+vezkkVe2+OIaOk= > =XyCF > -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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Did puppetca/puppetmasterd get changed to support a cname, if so when?
I would like to add a cname of puppet to the machine that runs puppetmasterd, and have point my puppetds at that, but ran into the same problem that others had a while back, namely: err: Could not retrieve catalog: Certificates were not trusted: hostname was not match with the server certificate I browsed the archives, and found this problem was discovered, and one potential solution proposed: > If my reading of post_connection_check > in /usr/lib/ruby/1.8/openssl/ssl.rb is correct, it should be > possible to > fix this by adding 'subjectAltName' extensions to the server cert. > Changes are definitely needed in the way that the puppetmaster > generates > the server cert. Did this fix ever happen, and if so, in which version of puppet? Right now, my puppetmasterd is v 0.22.4, so that is pretty old... Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] how to move certs from one puppetmaster to another, and new server has different hostname?
Hi, I've learned how to generate client certs on the master, and distribute them to the client machine as part of the OS install process, and added my learnings to the wiki, see: startup questions - Puppet Users | Google Groups and Certificates And Security - puppet - Trac Now, I need to figure out how to build a new puppetmaster, and transfer all the certs from the previous puppetmaster to the new one. The server that the new puppetmaster runs on will have a different hostname than the old puppetmaster server. Is this possible? How can I prevent the first puppetmaster from encoding its hostname in the certs? I just want the puppetmaster and clients to think they are talking to [EMAIL PROTECTED], and I'll make sure there is a CNAME in my DNS so that this resolves to whatever machine is running the puppetmaster. What are the important files to transfer in /etc/puppet/ca ? FYI, I am using version 0.24.4 Any advice appreciated Don --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Facter - the future - your input needed
> 2. Additional output formats - JSON, XML? (winces) - Facter already > outputs in YAML. I'd vote for adding an optional output format to easily support shell scripts: Here is the shell compatible output of another tool I use: set -A os_version_major "4" set -A os_version_minor "4" set -A packages "subversion-1.4.4p0" "screen-4.0.3p1" "rsync-3.0.3" "nut-2.2.1p0" "wget-1.11.3" "ncftp-3.2.1" "bash-3.2.39" "amanda- client-2.4.5.1" It is very useful to be able to call out from a shell script, get this kind of result back, and all the data returned is now available via environment variables. Given that Facter already supports a way of feeding environment variables INTO facter, eg: Also, Facter will search through your environment for any variables whose names start with ‘FACTER_’ (case insensitive) and automatically add those facts. Perhaps the right thing to do is prepend FACTER_ to all the fact names for the shell output format. I also think JSON would be very nice to have, although at present I don't have any code that would immediately use it. Don --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Facter - the future - your input needed
On Feb 21, 2009, at 7:06 PM, AJ Christensen wrote: > My 2c on the matter is that JSON is the fastest, most portable, and > supports all of the big boy data structures. I'd vote for JSON also. --~--~-~--~~~---~--~~ 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] Starting a (SMF) service on Solaris with Puppet
munications.com]/Service[postfix]: 1 change(s) debug: Service[postfix](provider=smf): Executing 'true' debug: Puppet::Type::Service::ProviderSmf: Executing '/usr/bin/svcs -l postfix' debug: Service[postfix](provider=smf): Executing 'true' notice: //Node[solaristest.clark-communications.com]/Service[postfix]/ ensure: ensure changed 'stopped' to 'running' debug: Finishing transaction 74115530 with 1 changes debug: Storing state debug: Stored state in 0.02 seconds notice: Finished catalog run in 1.16 seconds But after the puppetd run, postfix is NOT running on the machine. Any advice appreciated. Don --~--~-~--~~~---~--~~ 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: Starting a (SMF) service on Solaris with Puppet
On May 6, 2009, at 6:47 PM, Jim Pirzyk wrote:
> I believe you do not need
>
> start => true
>
> you may need to set the name though:
>
> name => 'svc:/network/postfix:default'
>
> unless 'svcadm enable postfix' works as is (I do not have postfix on
> my servers, but I can do 'svcadm enable smtp'
>
> The enable => true means to execute the 'svcadm enable $name'
I implemented both your suggestions, and it worked!
Thank you!
Don
>>
>> Hello,
>>
>> I am a puppet newbie, I got a puppetmaster running on my network, and
>> puppetd is installed and run on new servers.
>>
>> I am trying to get puppet to start postfix on a Solaris server.
>>
>> The postfix package was previously installed (via jumpstart).
>>
>> When the system first comes up, if I type
>>
>> svcadm enable svc:/network/postfix:default
>>
>> then postfix starts and runs fine. But I want puppet to do that for
>> me automatically.
>>
>> Here is what I put in my manifest file:
>>
>> file { "password":
>>name => "/etc/passwd",
>>owner => "root",
>>group => $operatingsystem ? {
>> OpenBSD => "wheel",
>> Solaris => "sys",
>>},
>>mode => 644,
>> }
>>
>> node 'solaristest.clark-communications.com' {
>> service { "postfix":
>> enable => "true",
>> start => "true",
>> ensure => "running",
>> }
>> }
>>
>> But that doesn't seem to work, here is what puppetd says:
>>
>> /opt/csw/bin/puppetd --no-daemonize --debug
>> debug: Creating default schedules
>> debug: Failed to load library 'shadow' for feature 'libshadow'
>> debug: Failed to load library 'ldap' for feature 'ldap'
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/public_keys]: Autorequiring File[/etc/opt/csw/
>> puppet/ssl]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
>> File[/var/opt/csw/puppet/lib]: Autorequiring File[/var/opt/csw/
>> puppet]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
>> File[/etc/opt/csw/puppet/ssl]: Autorequiring File[/etc/opt/csw/
>> puppet]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/private_keys/solaristest.clark-
>> communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
>> private_keys]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/certs]: Autorequiring File[/etc/opt/csw/
>> puppet/
>> ssl]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
>> File[/var/opt/csw/puppet/state/classes.txt]: Autorequiring File[/var/
>> opt/csw/puppet/state]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/private]: Autorequiring File[/etc/opt/csw/
>> puppet/ssl]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/private_keys]: Autorequiring File[/etc/opt/
>> csw/
>> puppet/ssl]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
>> File[/var/opt/csw/puppet/state/state.yaml]: Autorequiring File[/var/
>> opt/csw/puppet/state]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
>> File[/var/opt/csw/puppet/state]: Autorequiring File[/var/opt/csw/
>> puppet]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
>> File[/var/opt/csw/puppet/log]: Autorequiring File[/var/opt/csw/
>> puppet]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/certs/solaristest.clark-
>> communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/
>> certs]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/
>> File[/var/opt/csw/puppet/run]: Autorequiring File[/var/opt/csw/
>> puppet]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/
>> File[/
>> etc/opt/csw/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/opt/
>> csw/
>> puppet/ssl/certs]
>> debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/
>> File[/
[Puppet Users] file serving question
I have a somewhat basic question about file serving: Once you specify the puppet://server/module Can that path continue from there? Eg, if my fileserver.conf file is: [myconfigfiles] path /export/home/configs allow * Can my clients do something like this? source => "puppet:///myconfigfiles/foo/bar.txt Meaning go get foo/bar.txt from the module myconfigfiles Or is the source directive restricted to just getting files directly (not in a subdirectory) of the specified path? Don --~--~-~--~~~---~--~~ 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] problems with puppetd on some of my solaris machines
I am having troubles with getting puppetd running on some of my Solaris10 update 7 (05/2009) boxes. I use Jumpstart to build my servers, so the installation is repeatable, consistent, and automated, so it is especially confusing that some boxes work, and others don't. I can ssh into both of these machines, so the host certs should be OK. As part of my installation, I download the ca.pem file for the puppetmaster, and the private key for the machine. The private keys were generated on the puppetmaster machine, which runs puppetversion => 0.24.4 on OpenBSD. Any ideas about what I am doing wrong, and/or things I could do to debug this problem? Thanks, Don Machine that doesn't work: = debug: Creating default schedules debug: Failed to load library 'shadow' for feature 'libshadow' debug: Failed to load library 'ldap' for feature 'ldap' debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/run]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/etc/opt/csw/puppet/ssl]: Autorequiring File[/etc/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs]: Autorequiring File[/etc/opt/csw/puppet/ ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs/nastest.clark-communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/certs] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/state]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/public_keys]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private_keys]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/lib]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/log]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private_keys/nastest.clark- communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/ private_keys] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/opt/csw/ puppet/ssl/certs] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/ File[/etc/opt/csw/puppet/puppet.conf]: Autorequiring File[/etc/opt/csw/ puppet] debug: Finishing transaction 69323770 with 0 changes /opt/csw/lib/ruby/site_ruby/1.8/puppet/sslcertificates/support.rb: 36:in `read_cert': Could not read hostcert: header too long (Puppet::SSLCertificates::Support::InvalidCertificate) from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:34:in `read_cert' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:47:in `cert_setup' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:101:in `http_instance' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/xmlrpc/ client.rb:186:in `initialize' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client.rb: 94:in `new' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client.rb: 94:in `initialize' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client/ master.rb:198:in `initialize' from /opt/csw/bin/puppetd:328:in `new' from /opt/csw/bin/puppetd:328 # /opt/csw/bin/facter facterversion => 1.5.4 kernel => SunOS kernelrelease => 5.10 kernelversion => Generic_139556-08 operatingsystem => Solaris operatingsystemrelease => 5.10 puppetversion => 0.24.8 rubysitedir => /opt/csw/lib/ruby/site_ruby/1.8 rubyversion => 1.8.7 Machine that works: # /opt/csw/bin/facter facterversion => 1.5.4 kernel => SunOS kernelrelease => 5.10 kernelversion => Generic_139556-08 operatingsystem => Solaris operatingsystemrelease => 5.10 puppetversion => 0.24.8 rubysitedir => /opt/csw/lib/ruby/site_ruby/1.8 rubyversion => 1.8.7 --~--~-~--~~~---~--~~ 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] SOLVED: problems with puppetd on some of my solaris machines
Apparently I wasn't generating new client certs/private_keys correctly somehow. I've attempted to capture that knowledge in a shell script, so that part of the procedure is repeatable/consistent/correct... Apologies for the noise to the list... :-( Don I am having troubles with getting puppetd running on some of my Solaris10 update 7 (05/2009) boxes. I use Jumpstart to build my servers, so the installation is repeatable, consistent, and automated, so it is especially confusing that some boxes work, and others don't. I can ssh into both of these machines, so the host certs should be OK. As part of my installation, I download the ca.pem file for the puppetmaster, and the private key for the machine. The private keys were generated on the puppetmaster machine, which runs puppetversion => 0.24.4 on OpenBSD. Any ideas about what I am doing wrong, and/or things I could do to debug this problem? Thanks, Don Machine that doesn't work: = debug: Creating default schedules debug: Failed to load library 'shadow' for feature 'libshadow' debug: Failed to load library 'ldap' for feature 'ldap' debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/run]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/etc/opt/csw/puppet/ssl]: Autorequiring File[/etc/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs]: Autorequiring File[/etc/opt/csw/puppet/ ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs/nastest.clark-communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/certs] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/state]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/public_keys]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private_keys]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private]: Autorequiring File[/etc/opt/csw/ puppet/ssl] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/lib]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[main]/ File[/var/opt/csw/puppet/log]: Autorequiring File[/var/opt/csw/puppet] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/private_keys/nastest.clark- communications.com.pem]: Autorequiring File[/etc/opt/csw/puppet/ssl/ private_keys] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[ssl]/File[/ etc/opt/csw/puppet/ssl/certs/ca.pem]: Autorequiring File[/etc/opt/csw/ puppet/ssl/certs] debug: /Settings[/etc//opt/csw/puppet/puppet.conf]/Settings[puppetd]/ File[/etc/opt/csw/puppet/puppet.conf]: Autorequiring File[/etc/opt/csw/ puppet] debug: Finishing transaction 69323770 with 0 changes /opt/csw/lib/ruby/site_ruby/1.8/puppet/sslcertificates/support.rb: 36:in `read_cert': Could not read hostcert: header too long (Puppet::SSLCertificates::Support::InvalidCertificate) from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:34:in `read_cert' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:47:in `cert_setup' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/ http_pool.rb:101:in `http_instance' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/xmlrpc/ client.rb:186:in `initialize' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client.rb: 94:in `new' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client.rb: 94:in `initialize' from /opt/csw/lib/ruby/site_ruby/1.8/puppet/network/client/ master.rb:198:in `initialize' from /opt/csw/bin/puppetd:328:in `new' from /opt/csw/bin/puppetd:328 # /opt/csw/bin/facter facterversion => 1.5.4 kernel => SunOS kernelrelease => 5.10 kernelversion => Generic_139556-08 operatingsystem => Solaris operatingsystemrelease => 5.10 puppetversion => 0.24.8 rubysitedir => /opt/csw/lib/ruby/site_ruby/1.8 rubyversion => 1.8.7 Machine that works: # /opt/csw/bin/facter facterversion => 1.5.4 kernel => SunOS kernelrelease => 5.10 kernelversion => Generic_139556-08 operatingsystem => Solaris operatingsystemrelease => 5.10 puppetversion => 0.24.8 rubysitedir => /opt/csw/lib/ruby/site_ruby/1.8 rubyversion => 1.8.7 --~--~-~--~~~---~--~~ You received this message
[Puppet Users] Re: Could not request certificate: Error 405 on SERVER
Hello, I followed the instructions on puppetlabs to install puppet 3.2.1 and Passenger on RedHat 6.4 x86_64. http://docs.puppetlabs.com/guides/installation.html http://docs.puppetlabs.com/guides/passenger.html I also installed puppet 3.2.1 on a RedHat 5.6 as the client. I finally got puppet agent to successfully retrieve the catalog from the master and apply it when using WEBrick. But when using apache and Passenger 4.05 and got the same 405 error above. I saw your post and downgraded to Passenger 3.0.21 per your instructions, but I still have the same 405 error. client > puppet agent --test --verbose --server vm1415701.bwi40g.vzbi.caas Info: Creating a new SSL certificate request for vm1340701.bwi40g.vzbi.caas Info: Certificate Request fingerprint (SHA256): 31:AE:B8:AC:F5:01:D3:C7:5B:83:7C:3A:9E:87:AC:5C:24:C7:E3:E0:89:63:0D:B4:0E:AD:E5:9B:95:F5:52:E5 Error: Could not request certificate: Error 405 on SERVER: 405 Method Not Allowed Method Not Allowed The requested method PUT is not allowed for the URL /production/certificate_request/vm1340701.bwi40g.vzbi.caas. Apache/2.2.15 (Red Hat) Server at vm1415701.bwi40g.vzbi.caas Port 8140 Exiting; failed to retrieve certificate and waitforcert is disabled The Apache logs have these entries: error: [Thu Jun 13 18:10:41 2013] [notice] Apache/2.2.15 (Unix) DAV/2 Phusion_Passenger/3.0.21 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- resuming normal operations [Thu Jun 13 18:10:59 2013] [error] [client 10.105.80.149] File does not exist: /usr/share/puppet/rack/puppetmasterd/public/production/certificate [Thu Jun 13 18:10:59 2013] [error] [client 10.105.80.149] File does not exist: /usr/share/puppet/rack/puppetmasterd/public/production/certificate_request access: [13/Jun/2013:18:10:59 -0400] "GET /production/certificate/ca? HTTP/1.1" 404 318 "-" "-" [13/Jun/2013:18:10:59 -0400] "GET /production/certificate_request/vm1340701.bwi40g.vzbi.caas? HTTP/1.1" 404 350 "-" "-" [13/Jun/2013:18:10:59 -0400] "PUT /production/certificate_request/vm1340701.bwi40g.vzbi.caas HTTP/1.1" 405 373 "-" "-" Any ideas on what to do next? Thanks, Don On Friday, May 31, 2013 5:05:20 PM UTC-4, Jonathan wrote: > > I found a solution for this...use an older version of Passenger, > specifically Passenger 3.0.21 > > To do this I uninstalled the Passenger gem: > gem uninstall passenger > > Then installed the older version: > gem install passenger --version 3.0.21 > > Then rebuilt libraries: > passenger-install-apache2-module > > On Thursday, May 30, 2013 2:19:47 PM UTC-7, Jonathan wrote: >> >> Hi all, >> >> I have experience using puppet, however I am new to setting puppet up as >> it was already done for me in past environments. I am running into an >> issue while trying to set puppet up for the first time on RHEL 6.4. I was >> hoping y'all might be able to help me! >> >> I get the following error from the puppet client's /var/log/messages log: >> >> May 30 07:06:30 pclient puppet-agent[1458]: Creating a new SSL >> certificate request for pclient >> May 30 07:06:30 pclient puppet-agent[1458]: Certificate Request >> fingerprint (SHA256): >> 62:1A:83:7D:DA:8B:A5:4B:14:D8:85:CF:D2:87:72:FA:88:9C:F5:88:46:28:3D:59:10:99:30:D8:50:9D:7A:2E >> May 30 07:06:30 pclient puppet-agent[1458]: Could not request >> certificate: Error 405 on SERVER: > 2.0//EN"> >> May 30 07:06:30 pclient puppet-agent[1458]: >> May 30 07:06:30 pclient puppet-agent[1458]: 405 Method Not >> Allowed >> May 30 07:06:30 pclient puppet-agent[1458]: >> May 30 07:06:30 pclient puppet-agent[1458]: Method Not Allowed >> May 30 07:06:30 pclient puppet-agent[1458]: The requested method PUT >> is not allowed for the URL /production/certificate_request/pclient. >> <...truncated...> >> >> On the puppet master I get stuff like this in the apache logs: >> [Thu May 30 07:05:45 2013] [error] [client 192.168.223.129] File does not >> exist: /usr/share/puppet/rack/puppetmasterd/public/production/node >> [Thu May 30 07:05:45 2013] [error] [client 192.168.223.129] File does not >> exist: /usr/share/puppet/rack/puppetmasterd/public/production/file_metadatas >> [Thu May 30 07:05:45 2013] [error] [client 192.168.223.129] File does not >> exist: /usr/share/puppet/rack/puppetmasterd/public/production/file_metadata >> [Thu May 30 07:05:45 2013] [error] [client 192.168.223.129] File does not >> exist: /usr/share/puppet/rack/puppetmasterd/public/production/catalog >> [Thu May 30 07:06:31 2013] [error] [client 192.168.223.131] File does not >> exist: /usr/share/puppet/rack/puppetmasterd/public/production/certificate >
[Puppet Users] Re: Augeas question a
Here's a patch to make puppet do integer comparison instead of string comparison if both strings are valid integers: --- OLD/site_ruby/1.8/puppet/provider/augeas/augeas.rb 2013-09-19 14:09:52.0 -0400 +++ NEW/site_ruby/1.8/puppet/provider/augeas/augeas.rb 2013-09-19 16:23:48.0 -0400 @@ -164,6 +164,10 @@ end end + def is_numeric?(s) +s.to_s.match(/\A[+-]?\d+?(\.\d+)?\Z/) == nil ? false : true + end + # Used by the need_to_run? method to process get filters. Returns # true if there is a match, false if otherwise # Assumes a syntax of get /files/path [COMPARATOR] value @@ -179,10 +183,14 @@ #check the value in augeas result = @aug.get(path) || '' -case comparator -when "!=" + +if comparator == "<" and is_numeric?(result) and is_numeric?(arg) + return_value = result.to_s.to_f < arg.to_s.to_f +elsif comparator == ">" and is_numeric?(result) and is_numeric?(arg) + return_value = result.to_s.to_f > arg.to_s.to_f +elsif comparator == "!=" return_value = (result != arg) -when "=~" +elsif comparator == "=~" regex = Regexp.new(arg) return_value = (result =~ regex) else -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Problem with facter/puppet on smartos
Trying to get puppet & factor working on SmartOS. Installed first from pkgsrc, then upgraded puppet via gem. Puppet itself seems to run OK (but haven't applied a manifest yet...) Facter fails: # facter Error: invalid byte sequence in UTF-8 # facter --debug Not an EC2 host Error: invalid byte sequence in UTF-8 # facter --version 1.7.3 # puppet --version 3.2.3 # uname -a SunOS 00-50-45-5f-13-ce 5.11 joyent_20131102T215831Z i86pc i386 i86pc Any help/advice would be greatly appreciated! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/02C9FF5C-228A-4F64-98D2-5571B361837C%40clark-communications.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: puppet module search using an HTTP proxy
I tried two of the proposed fixes in github, but neither of them worked. I came up with the following workaround (kludge) that happens to work because our proxy caches the authentication for a little while. Maybe it will help someone out there who is brought here by the magic Google machine: Stuff your proxy password in a variable so it doesn't get saved in shell history: read pw *type password and hit enter*Now use wget to get the proxy to authenticate you. Obviously, adjust user, proxy url, and port for your environment: export http_proxy=http://yourproxy.yourdomain.com:8080 export https_proxy=http://yourproxy.yourdomain.com:8080 wget --proxy-user=linprox --proxy-password=$pw http://google.com wget --no-check-certificate --proxy-user=yourproxyuser --proxy-password=$pw https://google.com Then you can do puppet module search and puppet module install until your cached credentials expire. FWIW -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/31572075-e596-4a6b-b1e6-d14803c412cb%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet Dashboard port
Good morning Everyone. I have been struggling to change the default port for Dashboard access from port 3000 to use SSL port 443. My Dashboard version is 1.2.34 if I am not mistaken. My OS is RHEL 6.4, Puppet Master 3.42-1 Any directions would be great. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/521a1a3f-7ec4-424d-860a-d54704d19019%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet Dashboard port
Thanks so much for the link, but I am testing the opensource version of Puppet. A lot of the directory structure is much different. On Thursday, June 5, 2014 10:27:56 AM UTC-4, Don Dorman wrote: > > Good morning Everyone. > > I have been struggling to change the default port for Dashboard access > from port 3000 to use SSL port 443. My Dashboard version is 1.2.34 if I > am not mistaken. > > My OS is RHEL 6.4, Puppet Master 3.42-1 > > Any directions would be great. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/85a2e004-f502-4c73-a74e-8226d111d730%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet Dashboard port
I almost have it figured out, and of course I will share the information On Thursday, June 5, 2014 11:55:35 AM UTC-4, Kwame Bahena wrote: > > Ah, > > Can you please then share your config and the steps you are following? > > > Cheers! > > > On Thu, Jun 5, 2014 at 10:15 AM, Don Dorman > wrote: > >> Thanks so much for the link, but I am testing the opensource version of >> Puppet. A lot of the directory structure is much different. >> >> >> >> On Thursday, June 5, 2014 10:27:56 AM UTC-4, Don Dorman wrote: >>> >>> Good morning Everyone. >>> >>> I have been struggling to change the default port for Dashboard access >>> from port 3000 to use SSL port 443. My Dashboard version is 1.2.34 if I >>> am not mistaken. >>> >>> My OS is RHEL 6.4, Puppet Master 3.42-1 >>> >>> Any directions would be great. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-users...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/85a2e004-f502-4c73-a74e-8226d111d730%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-users/85a2e004-f502-4c73-a74e-8226d111d730%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ceedf7c7-e0d9-4b93-afe8-3e32fe826d99%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Puppet Dashboard port
You will find this works great. http://devsops.blogspot.ca/2013/04/installing-puppet-dashboard.html On Thursday, June 5, 2014 2:15:48 PM UTC-4, Don Dorman wrote: > > I almost have it figured out, and of course I will share the information > > On Thursday, June 5, 2014 11:55:35 AM UTC-4, Kwame Bahena wrote: >> >> Ah, >> >> Can you please then share your config and the steps you are following? >> >> >> Cheers! >> >> >> On Thu, Jun 5, 2014 at 10:15 AM, Don Dorman wrote: >> >>> Thanks so much for the link, but I am testing the opensource version of >>> Puppet. A lot of the directory structure is much different. >>> >>> >>> >>> On Thursday, June 5, 2014 10:27:56 AM UTC-4, Don Dorman wrote: >>>> >>>> Good morning Everyone. >>>> >>>> I have been struggling to change the default port for Dashboard access >>>> from port 3000 to use SSL port 443. My Dashboard version is 1.2.34 if >>>> I >>>> am not mistaken. >>>> >>>> My OS is RHEL 6.4, Puppet Master 3.42-1 >>>> >>>> Any directions would be great. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to puppet-users...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-users/85a2e004-f502-4c73-a74e-8226d111d730%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/puppet-users/85a2e004-f502-4c73-a74e-8226d111d730%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/19cafabe-0cd5-4d2f-b853-7b9ad852aad4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] SSL
My environment has been working up until mid last week. just doing a puppet agent --test gives me these results... has anyone ran across this. [root@DC01SLE0005 ~]# puppet agent --test Warning: Unable to fetch my node definition, but the agent run will continue: Warning: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked Info: Retrieving plugin Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked Error: /File[/var/lib/puppet/lib]: Could not evaluate: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked Could not retrieve file metadata for puppet://puppet.ds.gc.ca/plugins: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Error: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Error: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert certificate revoked -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a180f269-de1d-4fbc-aa23-a26c8eaf588f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] NIC Module
Good morning everyone. I am looking to create a puppet 3.2.4 modules to scan all available IP routes across a lot os servers, and to save the information to a report. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7c016c0c-f3de-4159-8eea-4c0ca402691e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Upgrade
Has anyone found documentation on upgrading Puppet 3.4.3 to Puppet 3.6.2. running on RHEL 6.4 I have found some documents, but nothing simple and clearly defined. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0a20e707-1a52-465f-8476-dc2cd07fe252%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Upgrade
Thanks for the very prompt respo0nse. So respectively on the Puppet Master I have copied Puppet 3.6.2 to /var/data/Puppet. I have the RHEL 6.4.iso mounted to /mnt So I am guessing to upgrade the Master it should be as simple as yum upgrade puppet-server-3.6.2-1.el6.noarch.rpm and yum upgrade puppetdb-2.0.0-1.el6.noarch.rpm and the obvious yum upgrade puppet-3.6.2-1.el6.noarch.rpm On Tuesday, 20 January 2015 07:46:57 UTC-5, Dirk Heinrichs wrote: > > Am 20.01.2015 um 13:39 schrieb Don Dorman: > > Has anyone found documentation on upgrading Puppet 3.4.3 to Puppet > 3.6.2. running on RHEL 6.4 > > > First update the server, then agent nodes. You can use Puppet to update > the agents (I've written myself a small module to do that). > > I have found some documents, but nothing simple and clearly defined. > > > Server: yum upgrade > Agents: > Manual: yum upgrade > Automatic: Use (custom) puppet module, maybe with a version parameter. > Then to update, just increase the version number and wait for the next > automatic agent run. > > Feel free to ask for my module ;). > > HTH... > > Dirk > -- > > *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions > *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach > *Tel*: +49 2226 159 (Ansage) 1149 > *Email*: d...@recommind.com > *Skype*: dirk.heinrichs.recommind > www.recommind.com > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9ba58bad-16a7-4ef9-9e21-a8572a54cff5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Upgrade
I would love to take a look at your module. On Tuesday, 20 January 2015 07:46:57 UTC-5, Dirk Heinrichs wrote: > > Am 20.01.2015 um 13:39 schrieb Don Dorman: > > Has anyone found documentation on upgrading Puppet 3.4.3 to Puppet > 3.6.2. running on RHEL 6.4 > > > First update the server, then agent nodes. You can use Puppet to update > the agents (I've written myself a small module to do that). > > I have found some documents, but nothing simple and clearly defined. > > > Server: yum upgrade > Agents: > Manual: yum upgrade > Automatic: Use (custom) puppet module, maybe with a version parameter. > Then to update, just increase the version number and wait for the next > automatic agent run. > > Feel free to ask for my module ;). > > HTH... > > Dirk > -- > > *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions > *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach > *Tel*: +49 2226 159 (Ansage) 1149 > *Email*: d...@recommind.com > *Skype*: dirk.heinrichs.recommind > www.recommind.com > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/685943ff-1e13-46ae-9eb9-c37950fbad65%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
