[Puppet Users] Re: overriding packages in subclasses
Hi Russell,
I remember asking this a while ago and I don't think you can. In your
specific example, if it's pasted verbatim then you don't actually need
to inherit, as it doesn't look like your overriding any resources in
postgresql::base. Once something's declared, you can't undo it.
You could override Package[postgresql] and set it to ensure =
absent, but that's not the same as ignoring it - might do what you're
trying to achieve in this specific case though.
Lastly you could try work out some tricky way of using variables to
conditionally declare Package[postgresql] in postgresql::base, but
that opens up a world of variable scoping hurt, this is a terrible
example but shows the idea:
class postgresql::base {
if ($install_postgres_base) {
package {postgresql: ensure = present, }
}
}
class postgresql::rhe::v8-4 {
$install_postgres_base = 0
include postgresql::base
...
}
Maybe a better way would be to use variables for the names of your
packages, similar to the way the Exampl42 set of modules operate
(https://github.com/example42/puppet-modules). You avoid as much of
the variable scoping pain by declaring all variables in node
definitions before you include any classes:
node woof {
$need_postgres_8_4 = 1
include postgresql::base
}
class postgresql::base {
if ($need_postgres_8_4) {
$postgres_software = [ postgresql84, postgresql84-server ]
} else {
$postgres_software = postgresql
}
package { $postgres_software: ensure = present, }
}
Hope that helps,
-Luke
On Mar 2, 4:31 am, russell.fulton russell.ful...@gmail.com wrote:
I am having a fight with a postgressql nodule:
It defines:
class postgresql::base {
package {postgresql:
ensure = present,
notify = undef,
}
...
and later we have a class that inherits the base class:
class postgresql::rhe::v8-4 inherits postgresql::base {
$data_dir = $postgresql_data_dir ? {
= /var/lib/postgresql,
default = $postgresql_data_dir,
}
package {[
postgresql84,
postgresql84-server,
]:
ensure = present,
}
How can I get puppet to ignore the package definition in the 'base'
class?
This is on redhat -- postgresql installs 8.1.xxx and I want 8.4 --
puppet installs the two 84 packages and then bitches that it can not
install the straight postgresql because of conflicts (quite rightly).
Russell
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to remove a class from a node (using dashboard)
Puppet will not do anything you don't tell it to do. Try think of it
more along the lines of your modules and manifests describing how a
server should be and only how it should be. So if you don't tell it
NOT to be something, it's just going to ignore anything else that
exists on the system - this is why you haven't needed to tell Puppet
to install the packages kernel, and core-utils, it's not going to undo
anything that already exists that it doesn't know about otherwise
Puppet manifests would be massively redundant :)
A lot of people follow the convention of using an inherited class like
apache::disabled that shuts down everthing that the class apache does:
class apache {
package { httpd: ensure = present }
service { httpd: ensure = running }
}
class apache::disabled inherits apache {
Package[httpd] { ensure = absent }
Service[httpd] { ensure = stopped }
}
node never_be_a_web_server {
include apache::disabled
}
On Mar 2, 4:42 am, Luis Miguel Silva
luismiguelferreirasi...@gmail.com wrote:
Dear all,
I finally managed to load an extra module (apache) via dashboard but
i'm having trouble removing it?
My expectation was that, once i removed the class from the node
(stopped including it), Puppet would call some sort of deprovisioning
mechanism that would remove the class (so, in my case, when i stopped
including the apache class in my node, puppet would remove apache from
my node).
According to my tests, that did not happen (Apache is still up and running).
What are the best practices to remove a module when we no longer need it?
Thanks,
Luis
--
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] overriding packages in subclasses
On 02/03/11 04:31, russell.fulton wrote:
I am having a fight with a postgressql nodule:
It defines:
class postgresql::base {
package {postgresql:
ensure = present,
notify = undef,
}
...
and later we have a class that inherits the base class:
class postgresql::rhe::v8-4 inherits postgresql::base {
$data_dir = $postgresql_data_dir ? {
= /var/lib/postgresql,
default = $postgresql_data_dir,
}
package {[
postgresql84,
postgresql84-server,
]:
ensure = present,
}
How can I get puppet to ignore the package definition in the 'base'
class?
A slightly different tactic is to change the name of previously declared
package:
class postgresql::rhe::v8-4 inherits postgresql::base {
Package['postgresql'] {
name = 'postgresql84',
}
package { 'postgresql84-server':
ensure = present,
}
}
This way if you have any external classes putting a dependency on
Package['postgresql'] they don't get 'broken'.
Dan
This is on redhat -- postgresql installs 8.1.xxx and I want 8.4 --
puppet installs the two 84 packages and then bitches that it can not
install the straight postgresql because of conflicts (quite rightly).
Russell
--
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] Recommended way to install custom packages, and what does the Service type's manifest attribute do?
I am writing a module to configure a Nexus maven repository manager service on a centos5 host. As far as I'm aware, Nexus isn't available as an rpm, so there is a manual install step. I'm new to puppet so I tried getting it to copy a shell script over to the host to have it: - Extract the tar.gz - symlink the extracted foldername to nexus - symlink nexus/blah/init.d/nexus /etc/rc.d/init.d/nexus - add nexus to check config - enable nexus at boot - start nexus via service. The script works fine when run manually, but obviously puppet runs as the puppet user and getting puppet to exec it dissolved into permissions issues. So I was wondering, what is the recommend puppet way of handling installs of non packaged programs? I have similar problem with installing maven on the same box, but I imlemented it as a sequence of Exec steps, which causes much bloating of the puppet config... And what does the manifest attribute on a Service type do? Is symlinking the init script necessary or can I just specify the init script in the manifest attribute and have puppet work it's magic? Thanks, Oli -- 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: External node script flagging errors.
On Mar 1, 11:43 pm, Douglas Garstang doug.garst...@gmail.com wrote: What is the best way to have an external node script that encounters an error fail? What should it do? Should it return a non zero exit code to the OS? (of course, this doesn't seem to be documented anywhere). http://docs.puppetlabs.com/guides/external_nodes.html says: if you want a node to not be recognized, and to be treated as though it was not included in the configuration, your script should exit with a non-zero exit code cheers Jon -- 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] Nagios configuration arrays
Hi, A question for the devs. Will this: http://projects.puppetlabs.com/issues/4020 make it into a release any time soon? Best regards, Martijn. -- 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] Nagios configuration arrays
Sadly, signs point to no. On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nlwrote: Hi, A question for the devs. Will this: http://projects.puppetlabs.com/issues/4020 make it into a release any time soon? Best regards, Martijn. -- 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] Nagios configuration arrays
On 02-03-11 14:49, Brian Gallew wrote:
Sadly, signs point to no.
Too bad. But since I run a patched Puppetmaster anyway, I can do what I
want :-)
Unfortunately, it doesn't solve my problem.
I am trying to do the same thing as Gabriel Filion in this post:
http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
So, I have a nagios-target class, that defines a virtual resource:
@@nagios_host { $hostname:
use = generic-host,
address = $fqdn,
alias = $hostname,
ensure = present,
hostgroups = [],
}
and I would like to do something along the lines of this: in a different
class (not a subclass of nagios-target), for example in the class that
configures the MTA:
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
which results in this error:
Only subclasses can override parameters at ...
which sounds logical, but...
Is there any way to do what I want? I can't really think of anything,
since (variable) scoping will always be in my way, as far as I can see...
Best regards,
Martijn.
On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nl
mailto:mart...@iphion.nl wrote:
Hi,
A question for the devs. Will this:
http://projects.puppetlabs.com/issues/4020
make it into a release any time soon?
Best regards,
Martijn.
--
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
mailto:puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
mailto:puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Recommended way to install custom packages, and what does the Service type's manifest attribute do?
On Mar 2, 4:41 am, olizilla oli.ev...@gmail.com wrote:
I am writing a module to configure a Nexus maven repository manager service
on a centos5 host.
As far as I'm aware, Nexus isn't available as an rpm, so there is a manual
install step.
That no one else provides an RPM doesn't mean *you* cannot prepare
your own. If this is all that is necessary for a manual install:
I'm new to puppet so I tried getting it to copy a shell script over to the
host to have it:
- Extract the tar.gz
- symlink the extracted foldername to nexus
- symlink nexus/blah/init.d/nexus /etc/rc.d/init.d/nexus
- add nexus to check config
- enable nexus at boot
- start nexus via service.
then wrapping it in an RPM should be pretty easy. Then not only is
installing it simple, but you get all the management advantages
provided by the RPM system. Personally, I install software on my RPM-
based systems ONLY via RPMs, some of which I prepare myself for the
purpose.
I would omit the last step from the RPM, though, and maybe the last
two. Puppet can and should manage those aspects of the service for
you, and I think it highly inappropriate for RPMs to start services at
installation time.
The script works fine when run manually, but obviously puppet runs as the
puppet user and getting puppet to exec it dissolved into permissions issues.
However you approach the issue, something is dreadfully wrong here.
The Puppet agent needs to run with root privilege to do anything
useful (as you have discovered). Normally it runs as root. The
puppet *master* runs as a less-privileged user, typically named
puppet, but it should not be running your script. Before you do
anything else, you should make sure that the agent (i.e. puppetd) is
running with appropriate privileges.
So I was wondering, what is the recommend puppet way of handling installs of
non packaged programs?
My recommendation is to build your own package. I think several
others around here would agree. It is very much worth the effort. I
would also recommend that you put that RPM in your own yum repository
(they are easy to create), rather than trying to install directly from
an RPM file.
I have similar problem with installing maven on the same box, but I
imlemented it as a sequence of Exec steps, which causes much bloating of the
puppet config...
If you find that you can perform the work as a series of Execs, but
not by copying over and running a script of the same steps, then the
problem does not arise from the user that Puppet runs as. It might,
however, arise from one of these sources:
1) You attempt to execute the script as a program, but you did not
assign it execute permission via the File resource you use to copy
it. The File resource should probably specify mode = 700 (or 750, or
even 755).
2) You do not give the correct path to the script.
3) The script relies on environment variables that are absent or have
different values when Puppet runs the script.
4) The client is running SELinux in enforcing mode, and the script's
SELinux attributes do not allow the Puppet agent to run it. The File
resource's sel* properties can help with setting that up correctly.
And what does the manifest attribute on a Service type do? Is symlinking the
init script necessary or can I just specify the init script in the manifest
attribute and have puppet work it's magic?
I am pretty sure that the 'manifest' property is unrelated to
initscripts. In fact, I am confident that the Service resource will
fail utterly if the relevant initscript (or equivalent) is not already
present when the resource is applied. *Possibly* the command or
Puppet manifest named in the 'manifest' property could create the
initscript when necessary, but yuck! I think the 'manifest' property
is about performing additional client configuration prior to managing
the service itself (e.g. managing a file in /etc/sysconfig).
You should not need to create initscript symlinks. That is what
Service's 'enabled' property is about. You should, however, look at
http://projects.puppetlabs.com/issues/2712 for information about some
of Puppet's current limitations in that area.
In fact, Puppet does not know or care about initscripts or runlevel
symlinks specifically. It relies on the client-side tools to know
what to do with the service name you specify. On CentOS 5, that means
Puppet is going to be passing the service name to /sbin/chkconfig and /
sbin/service. Those tools expect an initscript having the given name
to be present in /etc[/rc.d]/init.d.
So, if you follow all of my advice, the relevant Puppet code might
look something like this:
# /etc/puppet/modules/my_module1/manifests/repositories.pp:
class my_module1::repositories {
yumrepo { my_packages:
baseurl = http://my_repo_server.my.com/repos/my_repo;,
descr= my_packages,
enabled = 1,
gpgcheck = 0; # 1 if you sign your packages
}
}
# /etc/puppet/modules/nexus/manifests/maven.pp:
class nexus::maven {
Re: [Puppet Users] Re: best way of handling source installs
I am managing a fairly small set of machines (network security monitors) and some of these packages are being installed on just two or three boxes so spending a lot of time building packages is simply not worth it. The apps are also updated fairly frequently and I need to stay on the bleeding edge :( I'm firmly of the opinion that time you invest now in automating package creation as much as possible will repay itself very quickly and be of immense value over time. I think this is even more important when you have a lot of churn. Simply being able to flip between versions of the packages quickly will surely save an awful lot of time. What he said - really. Three immediate benefits: - having the build process entirely scripted in the spec file ensures a consistent build process over time. - the first time you deploy a new version that explodes, rolling back to a set of known good binaries is utterly trivial to do in moments. - as sensitive boxes (security monitors) it's very useful to be able to easily verify the software binaries, using either the local rpm database or a copy of the original rpm. for a little extra, you can pgp sign your rpm files too. I'll throw out what is likely an unpopular opinion in this forum, which is that package-building is not *always* a win. Russell and I both use puppet to manage network security sensors which have some mildly unusual properties: 1) The packages being built are sometimes unusually complex to package, have poorly designed build processes, and small/closed user-communities. I have one package that builds kernel-modules and writes outside of the build-directory during make, and that nobody outside of the security community uses. Every shop has a few packages like this that would require a solid week of time to package properly, plus ongoing maintenance to track upstream changes. 2) Core libraries (specifically libpcap) often have to be rebuilt. 3) The number of boxes under management can be very small. I monitor a 50k node network with 3 boxes. 4) The software builds on these boxes are extremely stable. Nobody is flipping back and forth between versions on a regular basis. So (1) and (2) make the cost of packaging higher than most shops for security teams, and (2) and (3) make the benefits lower. I have been packaging my sensor software for about 18-months, and had high-hopes that it would eventually save me time but it's always worse than a source deployment by a large margin. I accept the overhead mostly because it improves my time-to-recover from a serious problem, and there are other benefits. It's time invested in maturity, not a time-savings, though. I use mock for my build process, and createrepo to manage the rpms. The infrastructure isn't actually bad at all. The time comes in writing and rewriting spec-files. You can sometimes poach work from CentOS of Fedora, but some sensor-software has simply never been packaged and you have to start from scratch. So Russell, the short of it is that Puppet doesn't provide much to help you manage source-installed software. You can apply puppet's features to other software-management tools to roll something yourself, you can package the software, or you can just keep building from source. The last option is likely to be the least time-consuming IMO. If you want details on my packaging setup, feel free to reach out to me offline. Cheers, Mike Lococo -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How to remove a class from a node (using dashboard)
Thanks Luke, that helps clarify things for me :o)
Luis Miguel Silva
On Mar 2, 2011, at 2:29 AM, luke.bigum luke.bi...@fasthosts.co.uk wrote:
Puppet will not do anything you don't tell it to do. Try think of it
more along the lines of your modules and manifests describing how a
server should be and only how it should be. So if you don't tell it
NOT to be something, it's just going to ignore anything else that
exists on the system - this is why you haven't needed to tell Puppet
to install the packages kernel, and core-utils, it's not going to undo
anything that already exists that it doesn't know about otherwise
Puppet manifests would be massively redundant :)
A lot of people follow the convention of using an inherited class like
apache::disabled that shuts down everthing that the class apache does:
class apache {
package { httpd: ensure = present }
service { httpd: ensure = running }
}
class apache::disabled inherits apache {
Package[httpd] { ensure = absent }
Service[httpd] { ensure = stopped }
}
node never_be_a_web_server {
include apache::disabled
}
On Mar 2, 4:42 am, Luis Miguel Silva
luismiguelferreirasi...@gmail.com wrote:
Dear all,
I finally managed to load an extra module (apache) via dashboard but
i'm having trouble removing it?
My expectation was that, once i removed the class from the node
(stopped including it), Puppet would call some sort of deprovisioning
mechanism that would remove the class (so, in my case, when i stopped
including the apache class in my node, puppet would remove apache from
my node).
According to my tests, that did not happen (Apache is still up and running).
What are the best practices to remove a module when we no longer need it?
Thanks,
Luis
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to remove a class from a node (using dashboard)
On Mar 2, 3:29 am, luke.bigum luke.bi...@fasthosts.co.uk wrote: Puppet will not do anything you don't tell it to do. Try think of it more along the lines of your modules and manifests describing how a server should be and only how it should be. That point deserves emphasis, for it is one of the keys to understanding Puppet and using it effectively. Many Puppet newbies think of Puppet as if it were a scripting engine with an obtuse syntax. This thought pattern is reflected by questions framed as How do I tell Puppet to _do_ XYZ? In fact, Puppet is a state management service with an instruction syntax geared specifically to that role. Questions framed as How do I tell Puppet that the node should (not) _be_/_have_ UVW? reflect a clearer understanding. My #1 rule of Puppet is Puppet is not a script engine. So if you don't tell it NOT to be something, it's just going to ignore anything else that exists on the system - this is why you haven't needed to tell Puppet to install the packages kernel, and core-utils, it's not going to undo anything that already exists that it doesn't know about otherwise Puppet manifests would be massively redundant :) Of course you *can* specify, for example, an exhaustive list of the packages that should be installed. If you do so, you can even tell Puppet that no unlisted packages should be present (see the Resources resource). Ditto for other resource types. Few people seem to adopt such a locked-down approach, however. My #2 rule of Puppet is Unmanaged means 'I don't care'. The corrolary is Say 'absent' when that's what you want. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Class inheritance (was Re: Nagios configuration arrays)
Hi,
After some reading and experimenting, I thought I had found the solution
to the problem below in class inheritance, but again... I'm stuck.
As said, I have class nagios-target, defined as listed below.
I now have this:
class mta inherits nagios-target {
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
}
This works; I get a Nagios host definition with the expected 'hostgroups'
setting.
Now I add a second class:
class snmp inherits nagios-target {
Nagios_host [$hostname] {
hostgroups + snmp-servers,
}
}
but now I get:
Error 400 on SERVER: Parameter 'hostgroups' is already set on
Nagios_host[martijn] at /etc/puppet/manifests/classes/mta.pp:43; cannot
redefine at /etc/puppet/manifests/classes/snmp.pp:4 on node martijn.
What part of overriding parameters and the '+' operator am I missing here?
Best regards,
Martijn.
On 02-03-11 15:55, Martijn Grendelman wrote:
On 02-03-11 14:49, Brian Gallew wrote:
Sadly, signs point to no.
Too bad. But since I run a patched Puppetmaster anyway, I can do what I
want :-)
Unfortunately, it doesn't solve my problem.
I am trying to do the same thing as Gabriel Filion in this post:
http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
So, I have a nagios-target class, that defines a virtual resource:
@@nagios_host { $hostname:
use = generic-host,
address = $fqdn,
alias = $hostname,
ensure = present,
hostgroups = [],
}
and I would like to do something along the lines of this: in a different
class (not a subclass of nagios-target), for example in the class that
configures the MTA:
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
which results in this error:
Only subclasses can override parameters at ...
which sounds logical, but...
Is there any way to do what I want? I can't really think of anything,
since (variable) scoping will always be in my way, as far as I can see...
Best regards,
Martijn.
On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nl
mailto:mart...@iphion.nl wrote:
Hi,
A question for the devs. Will this:
http://projects.puppetlabs.com/issues/4020
make it into a release any time soon?
Best regards,
Martijn.
--
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
mailto:puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
mailto:puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] err: Could not request certificate: Error 400 on SERVER: error too long
Hi, I recently upgraded my puppet master and clients from 2.6.2 to 2.6.4. Things were fine until today I tried introducing a new host to my master for the first time: client: [root@db-us1 ~]# rpm -qa puppet puppet-2.6.4-0.7.el5 [root@db-us1 ~]# puppetd -t -v warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session err: Could not request certificate: Error 400 on SERVER: header too long Exiting; failed to retrieve certificate and waitforcert is disabled [root@db-us1 ~]# master: #-(0) rpm -qa | grep puppet puppet-2.6.4-0.7.el5 puppet-server-2.6.4-0.7.el5 Mar 2 14:26:29 puppet puppet-master[21312]: header too long #-(0) puppetca -l err: Could not call list: header too long How can I fix this? -Naresh V. P.S.: The RPMs are from tmz's repo. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How to remove a class from a node (using dashboard)
Yeah, that's good to know. I figured that was the way it worked after i removed the class from the node and the service stood there BUT was assuming that it would go away (i.e. the class had a unprovisioning method of some sort) :o). Thanks a lot, Luis On Wed, Mar 2, 2011 at 8:29 AM, jcbollinger john.bollin...@stjude.org wrote: On Mar 2, 3:29 am, luke.bigum luke.bi...@fasthosts.co.uk wrote: Puppet will not do anything you don't tell it to do. Try think of it more along the lines of your modules and manifests describing how a server should be and only how it should be. That point deserves emphasis, for it is one of the keys to understanding Puppet and using it effectively. Many Puppet newbies think of Puppet as if it were a scripting engine with an obtuse syntax. This thought pattern is reflected by questions framed as How do I tell Puppet to _do_ XYZ? In fact, Puppet is a state management service with an instruction syntax geared specifically to that role. Questions framed as How do I tell Puppet that the node should (not) _be_/_have_ UVW? reflect a clearer understanding. My #1 rule of Puppet is Puppet is not a script engine. So if you don't tell it NOT to be something, it's just going to ignore anything else that exists on the system - this is why you haven't needed to tell Puppet to install the packages kernel, and core-utils, it's not going to undo anything that already exists that it doesn't know about otherwise Puppet manifests would be massively redundant :) Of course you *can* specify, for example, an exhaustive list of the packages that should be installed. If you do so, you can even tell Puppet that no unlisted packages should be present (see the Resources resource). Ditto for other resource types. Few people seem to adopt such a locked-down approach, however. My #2 rule of Puppet is Unmanaged means 'I don't care'. The corrolary is Say 'absent' when that's what you want. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- 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] Nagios configuration arrays
Dude, I struggled with that for more than 6 months, and the position of the
Puppet people was, you're doing it wrong. Since that didn't help my problem
I ended up doing it this way:
1) Create a new fact (see attached) that reports back to the master server on
what classes are defined on the client (during the last run!).
2) Create a new function (see attached) that will compute the correct set of
hostgroups from the class list
3) Create a new fact (see attached) that will determine if the client is a zone
server (e.g. global zone) or if it's a zone running on a server.
4) Use those to drive my Nagios configs.
Here's the relevant class fragment:
@@nagios_host {
$fqdn:
alias = $hostname,
address = $service_ipaddress,
max_check_attempts = 3,
contact_groups = unix,
hostgroups = $nagios_hostgroup_list,
icon_image_alt = $operatingsystem,
icon_image = $operatingsystem.png,
notifications_enabled = 1,
statusmap_image = $operatingsystem.gd2,
tag = inline_template(%=my_nagios_home.sub(' ','_')%), # Puppet
doesn't like tags with spaces?!?
notes_url = $cprt_globalzone ? {
global = https://${hostname}-a.${my_domain}/;,
default = undef,
},
parents = $cprt_globalzone ? {
= undef,
nil = undef,
global = undef,
default = ${cprt_globalzone}.${my_domain},
},
use = [ $productname ? {
Sun Fire X4140 = host-x4140-template,
default = host-generic-template },
host-pnp-template
],
}
On Mar 2, 2011, at 6:55 AM, Martijn Grendelman wrote:
On 02-03-11 14:49, Brian Gallew wrote:
Sadly, signs point to no.
Too bad. But since I run a patched Puppetmaster anyway, I can do what I
want :-)
Unfortunately, it doesn't solve my problem.
I am trying to do the same thing as Gabriel Filion in this post:
http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
So, I have a nagios-target class, that defines a virtual resource:
@@nagios_host { $hostname:
use = generic-host,
address = $fqdn,
alias = $hostname,
ensure = present,
hostgroups = [],
}
and I would like to do something along the lines of this: in a different
class (not a subclass of nagios-target), for example in the class that
configures the MTA:
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
which results in this error:
Only subclasses can override parameters at ...
which sounds logical, but...
Is there any way to do what I want? I can't really think of anything,
since (variable) scoping will always be in my way, as far as I can see...
Best regards,
Martijn.
On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nl
mailto:mart...@iphion.nl wrote:
Hi,
A question for the devs. Will this:
http://projects.puppetlabs.com/issues/4020
make it into a release any time soon?
Best regards,
Martijn.
--
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
mailto:puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
mailto:puppet-users%2bunsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Facter.add(:cprt_classes) do
setcode do
open('/var/lib/puppet/state/classes.txt').read().split().join(',') rescue
end
end
module Puppet::Parser::Functions
newfunction(:cprt_calculatehostgroups, :type = :rvalue) do |args|
classlist = lookupvar('cprt_classes').split(',') rescue []
pairs = [['role::service', 'service'],
['role::production', 'production'],
['role::development', 'development'],
['role::auction_server', 'auction'],
['role::scheduler_server', 'scheduler'],
['role::bind_server', 'bind'],
['role::build_server', 'build'],
['role::jump_start',
Re: [Puppet Users] Re: mysql module is not found
Hi guys,
Sorry my fault, I had a problem with the init.pp file but it is
looking ok now. I appreciate your time. :)
There was an error in the init.pp of the mysql module which I have
now fixed and mysql is installing and running splendidly!
--- /etc/my.cnf 2010-11-19 21:26:05.0 -0500
+++ /tmp/puppet-diffing.1803.0 2011-03-02 12:58:23.0 -0500
@@ -6,21 +6,10 @@
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
-# To allow mysqld to connect to a MySQL Cluster management daemon, uncomment
-# these lines and adjust the connectstring as needed.
-#ndbcluster
-#ndb-connectstring=nodeid=4;host=localhost:1186
+# Disabling symbolic-links is recommended to prevent assorted security risks;
+# to do so, uncomment this line:
+# symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
-
-[ndbd]
-# If you are running a MySQL Cluster storage daemon (ndbd) on this machine,
-# adjust its connection to the management daemon here.
-# Note: ndbd init script requires this to include nodeid!
-connect-string=nodeid=2;host=localhost:1186
-
-[ndb_mgm]
-# connection string for MySQL Cluster management tool
-connect-string=host=localhost:1186
info: Filebucket[/var/lib/puppet/clientbucket]: Adding
/etc/my.cnf(d83162f6dee4ca090c7b129026293998)
info: //mysql/File[/etc/my.cnf]: Filebucketed /etc/my.cnf to main with
sum d83162f6dee4ca090c7b129026293998
notice: //mysql/File[/etc/my.cnf]/content: content changed
'{md5}d83162f6dee4ca090c7b129026293998' to
'{md5}740258c758e3ef283d2fd5f862bc9e4c'
notice: //mysql/Service[mysqld]/ensure: ensure changed 'stopped' to 'running'
info: Creating state file /var/lib/puppet/state/state.yaml
notice: Finished catalog run in 34.22 seconds
Regards,
Tim
On Tue, Mar 1, 2011 at 5:34 PM, Atha Kouroussis akourous...@gmail.com wrote:
Hi Tim,
is there a mysql class in your modules/mysql/init.pp manifest?
Cheers,
Atha
On Tuesday, March 1, 2011 at 7:28 PM, Tim Dunphy wrote:
hello list! could someone please offer an opinion as to why the mysql
module I am attempting to include is not found?
## error
[root@pdb1 ~]# puppetd --test
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find class mysql at
/etc/puppet/manifests/nodes.pp:25 on node pdb1.acadaca.net
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
## nodes.pp
node 'pclient.acadaca.net' {
include basefiles
include baseapps
}}
node 'pclient2.acadaca.net' {
include basefiles
include baseapps
include mysql
}}
node 'pclient4.acadaca.net' {
include basefiles
include baseapps
}}
node 'mclient.acadaca.net'{
include basefiles
include baseapps
include webserver }
node 'pdb1.acadaca.net' {
include basefiles
include baseapps
include mysql
include ppostfix
}
node 'kromep1.acadaca.net' {
include basefiles
include bbaseapps
include webserver
}}
## mysql module exists
[root@puppet ~]# ls -l /etc/puppet/modules/mysql/manifests/init.pp
-rw-r--r-- 1 root root 396 Feb 28 18:03
/etc/puppet/modules/mysql/manifests/init.pp
thank you kindly in advance! :)
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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.
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] exec resource failing
hello list
I was hoping to get an opinion as to why the following error is
occurring with an exec resource I am attempting to use:
err: //centos/Exec[/usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]/returns: chan
ge from notrun to 0 failed: /usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt retur
ned 2 instead of one of [0] at /etc/puppet/manifests/os/centos.pp:9
## centos.pp
$keycmds = [/usr/bin/wget http://apt.sw.be/RPM-GPG-KEY.dag.txt;,
/bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]
exec { $keycmds:
cwd = /etc/pki/rpm-gpg/,
creates = /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt,
path = [/bin,/usr/bin]
}
thanks in advance!
tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] External node script flagging errors.
On Tue, 01 Mar 2011, Douglas Garstang wrote:
What is the best way to have an external node script that
encounters an error fail? What should it do? Should it return a
non zero exit code to the OS?
Yes. I am almost sure that works. If not, it's a bug.
Maybe it's caching something.
I think the external node classifier is not re-run if the
facts have not changed. There's a feature request to make
it run every time.
However, it would be nice to have the client error out in such
a way that I know there was a problem with the external node
script loading it's info. Anyone?
Something else I have done, and that might suit you, is let the
node classifier script return an almost-empty non-error result,
like this:
---
parameters:
error_message: Something is wrong
classes: []
Then the top-level site.pp can do something like this:
if $error_message {
fail(External node classifier says: $error_message)
}
--apb (Alan Barrett)
--
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] Nagios configuration arrays
Hello,
I finally abandoned the idea of having a group-based sane-looking Nagios
configuration with puppet, because there are too many weirdnesses in
Naginator. And unfortunately I can't really bring any help with patches
since I don't write any ruby..
There are some great nagios modules out there which you could use, or
from which you could borrow ideas. Generally speaking, I see that they
tend to define services for each host and attach them directly to hosts.
It's big and clunky, but at least it works..
For example, in an sshd module, you would have something like:
@@nagios_service { ${fqdn}_ssh:
check_command = check_ssh,
host_name = $fqdn,
}
The biggest problem I have right now is that purging nagios resources
doesn't seem to erase anything, so my config gets messed up from time to
time when nodes are taken out or things are moved around and I need to
manullay remove nagios config files and have puppet regenerate them :\
On 11-03-02 09:55 AM, Martijn Grendelman wrote:
On 02-03-11 14:49, Brian Gallew wrote:
Sadly, signs point to no.
Too bad. But since I run a patched Puppetmaster anyway, I can do what I
want :-)
Unfortunately, it doesn't solve my problem.
I am trying to do the same thing as Gabriel Filion in this post:
http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
So, I have a nagios-target class, that defines a virtual resource:
@@nagios_host { $hostname:
use = generic-host,
address = $fqdn,
alias = $hostname,
ensure = present,
hostgroups = [],
}
and I would like to do something along the lines of this: in a different
class (not a subclass of nagios-target), for example in the class that
configures the MTA:
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
which results in this error:
Only subclasses can override parameters at ...
which sounds logical, but...
Is there any way to do what I want? I can't really think of anything,
since (variable) scoping will always be in my way, as far as I can see...
On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nl
mailto:mart...@iphion.nl wrote:
Hi,
A question for the devs. Will this:
http://projects.puppetlabs.com/issues/4020
make it into a release any time soon?
--
Gabriel Filion
--
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: best way of handling source installs
On Wed, Mar 2, 2011 at 7:18 AM, Mike Lococo mikeloc...@gmail.com wrote: So Russell, the short of it is that Puppet doesn't provide much to help you manage source-installed software. You can apply puppet's features to other software-management tools to roll something yourself, you can package the software, or you can just keep building from source. The last option is likely to be the least time-consuming IMO. If you want details on my packaging setup, feel free to reach out to me offline. We've tossed around in the past the idea of a tarball package provider, which sounds like it might suit your needs? If we can come up with a reasonable rough heuristic to work out how to determine if a tarball package is installed, and whether it needs to be replaced by a newer version, I'm totally willing to hack this up, as it's really quite trivial code. -- 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] exec resource failing
-Original Message-
From: puppet-users@googlegroups.com
[mailto:puppet-users@googlegroups.com] On Behalf Of Tim Dunphy
Sent: Wednesday, March 02, 2011 11:17 AM
To: puppet-users@googlegroups.com
Subject: [Puppet Users] exec resource failing
hello list
I was hoping to get an opinion as to why the following error is
occurring with an exec resource I am attempting to use:
err: //centos/Exec[/usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]/returns: chan
ge from notrun to 0 failed: /usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt retur
ned 2 instead of one of [0] at /etc/puppet/manifests/os/centos.pp:9
Take a close look at what it's actually trying to run.
It would probably be a good idea to separate the two ideas out: get the
file using file source= first, and then import the key if it isn't
already in there.
## centos.pp
$keycmds = [/usr/bin/wget http://apt.sw.be/RPM-GPG-KEY.dag.txt;,
/bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]
exec { $keycmds:
cwd = /etc/pki/rpm-gpg/,
creates = /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt,
path = [/bin,/usr/bin]
}
thanks in advance!
tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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.
This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.
http://www.encana.com
--
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] Role-based access in Dashboard
Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. I'm sure there'll be disagreement; right now I'm just gathering requirements. Once we have feedback from multiple channels we'll work on prioritizing and creating a roadmap. Thanks! r -- Randall Hansen; Director of User Experience; rand...@puppetlabs.com -- 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] Nagios configuration arrays
I've found that Puppet/Naginator has the bad habit of occasionally breaking the
Nagios config. Here's how I worked around this:
1) When you collect your Nagios resource, store them all in a temporary
directory (in my case, ~nagios/var/tmp)
2) Purge that directory with a cron job every night (so deleted resources
disappear)
3) Create an exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on
~nagios/etc/nagios.cfg and changing directories appropriately.
4) Create an exec that pre-flights Nagios using the nagios-tmp.cfg (which
checks the tmp dir) and, if successful, sync the files over into the real
Nagios config directory.
It's a little clunky, but Nagios doesn't ever break anymore. Remember that
your pre-flight exec should require all the Nagios resources (so the files get
updated first), and should always run if the contents of the tmp dir vary at
all from the real target (diff is your friend here). Otherwise, the preflight
may fail once and then never run again until the next time you make a
substantive server change.
On Mar 2, 2011, at 10:34 AM, Gabriel Filion wrote:
Hello,
I finally abandoned the idea of having a group-based sane-looking Nagios
configuration with puppet, because there are too many weirdnesses in
Naginator. And unfortunately I can't really bring any help with patches
since I don't write any ruby..
There are some great nagios modules out there which you could use, or
from which you could borrow ideas. Generally speaking, I see that they
tend to define services for each host and attach them directly to hosts.
It's big and clunky, but at least it works..
For example, in an sshd module, you would have something like:
@@nagios_service { ${fqdn}_ssh:
check_command = check_ssh,
host_name = $fqdn,
}
The biggest problem I have right now is that purging nagios resources
doesn't seem to erase anything, so my config gets messed up from time to
time when nodes are taken out or things are moved around and I need to
manullay remove nagios config files and have puppet regenerate them :\
On 11-03-02 09:55 AM, Martijn Grendelman wrote:
On 02-03-11 14:49, Brian Gallew wrote:
Sadly, signs point to no.
Too bad. But since I run a patched Puppetmaster anyway, I can do what I
want :-)
Unfortunately, it doesn't solve my problem.
I am trying to do the same thing as Gabriel Filion in this post:
http://groups.google.com/group/puppet-users/browse_thread/thread/276e6e694520224d
So, I have a nagios-target class, that defines a virtual resource:
@@nagios_host { $hostname:
use = generic-host,
address = $fqdn,
alias = $hostname,
ensure = present,
hostgroups = [],
}
and I would like to do something along the lines of this: in a different
class (not a subclass of nagios-target), for example in the class that
configures the MTA:
Nagios_host [$hostname] {
hostgroups + mail-satellite-servers,
}
which results in this error:
Only subclasses can override parameters at ...
which sounds logical, but...
Is there any way to do what I want? I can't really think of anything,
since (variable) scoping will always be in my way, as far as I can see...
On Wed, Mar 2, 2011 at 5:15 AM, Martijn Grendelman mart...@iphion.nl
mailto:mart...@iphion.nl wrote:
Hi,
A question for the devs. Will this:
http://projects.puppetlabs.com/issues/4020
make it into a release any time soon?
--
Gabriel Filion
--
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] exec resource failing
Hello David,
I actually got the problem worked out this way:
exec { /usr/bin/wget http://apt.sw.be/RPM-GPG-KEY.dag.txt:
cwd = /etc/pki/rpm-gpg/,
creates = /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt,
path = /usr/bin
}
exec { /bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt:
cwd = /etc/pki/rpm-gpg,
require = Exec[/usr/bin/wget http://apt.sw.be/RPM-GPG-KEY.dag.txt;],
path = /bin
}
But I suppose I could try throwing a source attribute in there and
achieve the same effect.
Thank you for your input!
Tim
On Wed, Mar 2, 2011 at 1:54 PM, Kinzel, David david.kin...@encana.com wrote:
-Original Message-
From: puppet-users@googlegroups.com
[mailto:puppet-users@googlegroups.com] On Behalf Of Tim Dunphy
Sent: Wednesday, March 02, 2011 11:17 AM
To: puppet-users@googlegroups.com
Subject: [Puppet Users] exec resource failing
hello list
I was hoping to get an opinion as to why the following error is
occurring with an exec resource I am attempting to use:
err: //centos/Exec[/usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]/returns: chan
ge from notrun to 0 failed: /usr/bin/wget
http://apt.sw.be/RPM-GPG-KEY.dag.txt/bin/rpm --import
/etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt retur
ned 2 instead of one of [0] at /etc/puppet/manifests/os/centos.pp:9
Take a close look at what it's actually trying to run.
It would probably be a good idea to separate the two ideas out: get the
file using file source= first, and then import the key if it isn't
already in there.
## centos.pp
$keycmds = [/usr/bin/wget http://apt.sw.be/RPM-GPG-KEY.dag.txt;,
/bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt]
exec { $keycmds:
cwd = /etc/pki/rpm-gpg/,
creates = /etc/pki/rpm-gpg/RPM-GPG-KEY.dag.txt,
path = [/bin,/usr/bin]
}
thanks in advance!
tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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.
This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of
the intended recipient only. Any review, retransmission or dissemination of
this information by anyone other than the intended recipient is prohibited.
If you receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.
http://www.encana.com
--
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.
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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: overriding packages in subclasses
On Mar 2, 10:53 pm, Daniel Piddock dgp-g...@corefiling.co.uk wrote:
On 02/03/11 04:31, russell.fulton wrote:
I am having a fight with a postgressql nodule:
It defines:
class postgresql::base {
package {postgresql:
ensure = present,
notify = undef,
}
...
and later we have a class that inherits the base class:
class postgresql::rhe::v8-4 inherits postgresql::base {
$data_dir = $postgresql_data_dir ? {
= /var/lib/postgresql,
default = $postgresql_data_dir,
}
package {[
postgresql84,
postgresql84-server,
]:
ensure = present,
}
How can I get puppet to ignore the package definition in the 'base'
class?
A slightly different tactic is to change the name of previously declared
package:
class postgresql::rhe::v8-4 inherits postgresql::base {
Package['postgresql'] {
name = 'postgresql84',
}
package { 'postgresql84-server':
ensure = present,
}
}
This way if you have any external classes putting a dependency on
Package['postgresql'] they don't get 'broken'.
This worked nicely! I had tried this before but clearly bungled it
somehow.
Russell
--
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: Recommended way to install custom packages, and what does the Service type's manifest attribute do?
You sir, are a gent and a scholar! I had not even considered creating my own RPM's, assuming that such a thing was beyond the ken of a mere mortal. I shall be reading up on them tonight. Thanks for bringing the yumrepo type to my attention, I have been adding repos with yet more Exec's which I guess is symptomatic of being new around these puppets. Out of interest, I can't see an apt equivalent in the type reference docs, is that the case? Your diagnosis of the script issue was correct. It had nothing to do with the puppet user. It was an SELinux. Kicking it into permissive mode fixed it. I plan to get my head around RPM packaging and repositories anyway, as it sounds like the best route. I'm totally clear about what the manifest attribute is supposed to be used for, but it seems I don't need it. Thank you kindly for taking the time to provide such a clear answer. Oli -- 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] Role-based access in Dashboard
Hi Randal, Very high level but I would like to see the following: • to be able to create roles such as viewer, editor, administrator • these roles be ldap groups • to be able class or group hosts and assign them to a group of admins to watch - while excluding their ability to see certain hosts. • being able to link a host or hostgroup to a report or report group? (where depending on 'importance' of the host or group you could send alerts when changes occur or changes fail - but for other host just report normally). Thanks, Den On 03/03/2011, at 3:02, Randall Hansen rand...@puppetlabs.com wrote: Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. I'm sure there'll be disagreement; right now I'm just gathering requirements. Once we have feedback from multiple channels we'll work on prioritizing and creating a roadmap. Thanks! r -- Randall Hansen; Director of User Experience; rand...@puppetlabs.com -- 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: best way of handling source installs
on 10:54 Wed 02 Mar, Nigel Kersten (ni...@puppetlabs.com) wrote: On Wed, Mar 2, 2011 at 7:18 AM, Mike Lococo mikeloc...@gmail.com wrote: So Russell, the short of it is that Puppet doesn't provide much to help you manage source-installed software. You can apply puppet's features to other software-management tools to roll something yourself, you can package the software, or you can just keep building from source. The last option is likely to be the least time-consuming IMO. If you want details on my packaging setup, feel free to reach out to me offline. We've tossed around in the past the idea of a tarball package provider, which sounds like it might suit your needs? If we can come up with a reasonable rough heuristic to work out how to determine if a tarball package is installed, and whether it needs to be replaced by a newer version, I'm totally willing to hack this up, as it's really quite trivial code. While you're considering providers, another case we encounter fairly frequently are just general crap ISV or HW vendor-provided blob shell installers. Usually a self-unpacking shell script, which may itself include various internal packaging formats (tarballs, RPMs, etc.). Dell, VMWare, Oracle, and others. In the case of these, there's /ususally/ an unattended install options (generally driven by an options file), otherwise there are the various frustrations of EULA approvals, etc. I haven't put deep thought into a puppet solution, but the generalized method would be for the installer script / binary / ISO image, a configuration script (or arbitrary shell arguments and ancillary file list(s)), and some arbitrary post-installation test providing some level of assurance that what you wanted to have installed was actually installed. Real packaging tools make this so much more sensible to manage. Grumble. -- Dr. Ed Morbius, Chief Scientist /| Robot Wrangler / Staff Psychologist| When you seek unlimited power Krell Power Systems Unlimited| Go to Krell! -- 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: best way of handling source installs
Dr. Ed Morbius writes: While you're considering providers, another case we encounter fairly frequently are just general crap ISV or HW vendor-provided blob shell installers. Usually a self-unpacking shell script, which may itself include various internal packaging formats (tarballs, RPMs, etc.). Dell, VMWare, Oracle, and others. What we have done is to turn such blob installers into OS packages for installation via Puppet, rather than try to manage the direct installation of the blob installer via a convoluted set of execs and such. Overall it is still much easier to manage OS package installation, even with the overhead of having to create the custom package. So as one example, we get the blob into the Mock RPM build environment, unpack it, feed canned input to its configuration script, and then wrap up the finished file tree as an RPM, then get that RPM installed on the hosts that need it. I haven't put deep thought into a puppet solution, but the generalized method would be for the installer script / binary / ISO image, a configuration script (or arbitrary shell arguments and ancillary file list(s)), and some arbitrary post-installation test providing some level of assurance that what you wanted to have installed was actually installed. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? -- 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: Recommended way to install custom packages, and what does the Service type's manifest attribute do?
On Mar 2, 4:04 pm, olizilla oli.ev...@gmail.com wrote: You sir, are a gent and a scholar! At least one of the above. :-) I had not even considered creating my own RPM's, assuming that such a thing was beyond the ken of a mere mortal. I shall be reading up on them tonight. There is a learning curve assocated with RPM building, just like with anything else, but once you get the hang of it, it's not that hard. There is a fair amount of documentation arond the web. Among the better are IBM's 3-part article (start at http://www.ibm.com/developerworks/library/l-rpm1/) and Fedora's draft manual (http://docs.fedoraproject.org/en-US/ Fedora_Draft_Documentation/0.1/RPM_Guide/index.html). Don't overlook http://www.rpm.org/, but frankly, I don't find it as useful as some of the others. Thanks for bringing the yumrepo type to my attention, I have been adding repos with yet more Exec's which I guess is symptomatic of being new around these puppets. Out of interest, I can't see an apt equivalent in the type reference docs, is that the case? There is no apt analog of Yumrepo included in the standard distribution. I would not be surprised if there were one available from a third party, however. Check Puppetforge. Your diagnosis of the script issue was correct. It had nothing to do with the puppet user. It was an SELinux. Kicking it into permissive mode fixed it. Score! I plan to get my head around RPM packaging and repositories anyway, as it sounds like the best route. I certainly think so, and not just in a Puppet context. Without RPM it's not the installs that kill you, though having an RPM does make multiple installs much easier and more consistent. No, it's the uninstalls, the upgrades, the dependency management, the software inventory, It's just icing on the cake that RPMs are easy for software such as Puppet do deal with. I'm totally clear about what the manifest attribute is supposed to be used for, but it seems I don't need it. Thank you kindly for taking the time to provide such a clear answer. You're quite welcome. Cheers, John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: best way of handling source installs
on 15:20 Wed 02 Mar, Steven VanDevender (ste...@uoregon.edu) wrote: Dr. Ed Morbius writes: While you're considering providers, another case we encounter fairly frequently are just general crap ISV or HW vendor-provided blob shell installers. Usually a self-unpacking shell script, which may itself include various internal packaging formats (tarballs, RPMs, etc.). Dell, VMWare, Oracle, and others. What we have done is to turn such blob installers into OS packages for installation via Puppet, rather than try to manage the direct installation of the blob installer via a convoluted set of execs and such. Overall it is still much easier to manage OS package installation, even with the overhead of having to create the custom package. So as one example, we get the blob into the Mock RPM build environment, unpack it, feed canned input to its configuration script, and then wrap up the finished file tree as an RPM, then get that RPM installed on the hosts that need it. In the specific pathological case I'm thinking of (Dell's iSCSI management tools), the net end result is rather poorly defined and spans a significant chunk of the filesystem -- mostly under /opt/dell, but some stray (and largely undocumented) bits, mostly under /etc, with bits under /usr/src. I'd probably have to compare filesystem snapshots to identify these cleanly. I haven't put deep thought into a puppet solution, but the generalized method would be for the installer script / binary / ISO image, a configuration script (or arbitrary shell arguments and ancillary file list(s)), and some arbitrary post-installation test providing some level of assurance that what you wanted to have installed was actually installed. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? Because there's stuff that isn't packaged in RPM/DEB, and there aren't enough hours in the day. I'm not convinced this is a /good/ idea. It is, however, an idea. Figure folks can kick it around (or ignore it) and see what interest or other suggestions there are. -- Dr. Ed Morbius, Chief Scientist /| Robot Wrangler / Staff Psychologist| When you seek unlimited power Krell Power Systems Unlimited| Go to Krell! -- 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: best way of handling source installs
Dr. Ed Morbius writes: In the specific pathological case I'm thinking of (Dell's iSCSI management tools), the net end result is rather poorly defined and spans a significant chunk of the filesystem -- mostly under /opt/dell, but some stray (and largely undocumented) bits, mostly under /etc, with bits under /usr/src. I'd probably have to compare filesystem snapshots to identify these cleanly. At least the Mock RPM-building tool handles this for you; when building packages it uses a chrooted environment and tracks what files get put where so they can be rolled up into a package. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? Because there's stuff that isn't packaged in RPM/DEB, and there aren't enough hours in the day. I'm not convinced this is a /good/ idea. It is, however, an idea. Figure folks can kick it around (or ignore it) and see what interest or other suggestions there are. Seriously, package systems are designed to handle dependency management, *un*installation, and upgrading in ways that are extremely hard to deal with if you insist on doing traditional source-based (or your vendor insists on doing blob-based) installation methods. Yes, you have to create and learn how to use a package-building system, although you might be surprised how easy it is to build custom packages once you're over the initial effort of setting up the package build system. But you get far better and more consistent results if you do. It's an investment that will pay off in the future. -- 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] Role-based access in Dashboard
On 3/2/2011 2:02 PM, Randall Hansen wrote: Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. One general feature I've missed in other RBAC style systems is the ability to use external authentication either with or without external authorization. The reason why, is that centralized password management may or may not fall in the same organizational unit as management of a particular puppet server. So for example, let's say that dashboard is configured to use LDAP auth. In a place where all of IT is one big happy family, the same LDAP server might also return a list of roles to assign to a given user. In a more fragmented organization, however, whoever runs the central LDAP server may be unable or unwilling to delegate out control of the Dashboard role attributes to the puppet administrators, or possibly even to create the attributes in the first place. In this scenario, it would be far more useful to simply use LDAP to verify usernames and passwords, and then consult internal records to assign a list of roles. Not that I've pounded my head against products that didn't support this kind of split, or anything. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC -- 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] Role-based access in Dashboard
Beyond what Den pointed out, I would like to see either native (or good instructions) support for authenticating with X.509 PKI certificates. You would need to be able to specify: - The trusted CA chains - The CRL/OCSP/SCVP connections - What attribute/regex contains the username of the user - An internal username mapping back to the role of the user (which should be built in) This should be authoritative and passwords should be optional. Less important, but still nice, would be configuration instructions for Kerberos with GSSAPI. Also, if pulling from LDAP, I would like to avoid custom schemas if at all possible. It can be *really* hard to get Enterprise-type folks to add schemas to their servers. Thanks! Trevor On Wed, Mar 2, 2011 at 2:02 PM, Randall Hansen rand...@puppetlabs.com wrote: Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. I'm sure there'll be disagreement; right now I'm just gathering requirements. Once we have feedback from multiple channels we'll work on prioritizing and creating a roadmap. Thanks! r -- Randall Hansen; Director of User Experience; rand...@puppetlabs.com -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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: best way of handling source installs
on 15:38 Wed 02 Mar, Steven VanDevender (ste...@uoregon.edu) wrote: Dr. Ed Morbius writes: In the specific pathological case I'm thinking of (Dell's iSCSI management tools), the net end result is rather poorly defined and spans a significant chunk of the filesystem -- mostly under /opt/dell, but some stray (and largely undocumented) bits, mostly under /etc, with bits under /usr/src. I'd probably have to compare filesystem snapshots to identify these cleanly. At least the Mock RPM-building tool handles this for you; when building packages it uses a chrooted environment and tracks what files get put where so they can be rolled up into a package. That could be useful, though I'd have to play with it to see if the vendors' scripts would run as advertised within a chroot. The thing is, RPM or DEB packages already do those things for you, so why go to so much effort to duplicate that functionality outside your package system? Because there's stuff that isn't packaged in RPM/DEB, and there aren't enough hours in the day. I'm not convinced this is a /good/ idea. It is, however, an idea. Figure folks can kick it around (or ignore it) and see what interest or other suggestions there are. Seriously, package systems are designed to handle dependency management, *un*installation, and upgrading in ways that are extremely hard to deal with if you insist on doing traditional source-based (or your vendor insists on doing blob-based) installation methods. Please believe you've got absolutely *NO* convincing to do for me on any of those scores. Somewhat ironically, the Dell iSCSI shell blob contains within it several RPMs of varying spec-conformance. -- Dr. Ed Morbius, Chief Scientist /| Robot Wrangler / Staff Psychologist| When you seek unlimited power Krell Power Systems Unlimited| Go to Krell! -- 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] Role-based access in Dashboard
Randall, sorry for the offtopic response, but our team needs a write API before RBAC. WIthout it Dashboard is a non-starter in our shop. As for your RBAC question, I envision a time when, through dashboard, you will be able to handle complex provisioning workflows, being able to give people execution, view and write access to all workflows, nodes, classes, variables and tasks. Also to be able to separately manage GUI access vs API access, while not critical, might be useful. I imagine a group of operators who can mix and match classes to make new node types through the UI, but can't access the underlying code. (or some who can). Notification control would probably be something useful to RBAC. -Brian On Wed, Mar 2, 2011 at 2:02 PM, Randall Hansen rand...@puppetlabs.comwrote: Good people ~ Role-based access will be one of the next big features in Dashboard. If this is something that would help you, will you tell me the minimum features that you would consider useful? That is, the features without which RBAC would be useless to you. I'm sure there'll be disagreement; right now I'm just gathering requirements. Once we have feedback from multiple channels we'll work on prioritizing and creating a roadmap. Thanks! r -- Randall Hansen; Director of User Experience; rand...@puppetlabs.com -- 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. -- http://aws.amazon.com/solutions/solution-providers/brandorr/ -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet without FQDN (could not retrieve fact fqdn)
Hello, I am testing Puppet and I would like to use it without having to add a DNS entry. Is there a way around this, or am I required to rely on DNS? More specifically, the reason I ask is I am getting the following error when trying to invoke puppet --mkusers: # puppet master --mkusers warning: Could not retrieve fact fqdn Could not parse for environment production: Could not find file /root/ master.pp Same goes for: #sudo -u puppet puppet master --mkusers warning: Could not retrieve fact fqdn Could not parse for environment production: Could not find file /root/ master.pp Thanks, msacks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet without FQDN (could not retrieve fact fqdn)
On Wednesday, March 2, 2011 at 4:43 PM, msacks wrote: Hello, I am testing Puppet and I would like to use it without having to add a DNS entry. Is there a way around this, or am I required to rely on DNS? You can run Puppet like this: puppet master --certname=$(cat/etc/puppet/certname) puppet agent --certname=$(cat/etc/puppet/certname) to use the contents of an arbitrary file as the SSL certificate name instead of the fqdn fact. -- 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] apache vhosts in puppet
hello puppet list!!
I sincerely appreciate your help in the past and hope you don't mind
me bouncing this scenario off of you. I am attempting to define apache
vhosts with a puppet module but things are not going according to plan
at the moment
## error
[root@kromep1 ~]# puppetd --test
info: Caching catalog for kromep1.example.net
err: Could not run Puppet configuration client: Could not find
dependent Service[httpd] for
File[/etc/httpd/conf.d/web1.ops.example.com.conf] at
/etc/puppet/modules/apache/manifests/virtual_host.pp:11
## /etc/puppet/modules/apache/init.pp
class apache {
$packagelist = [httpd,webalizer,mod_ssl]
package { $packagelist:
ensure = installed
}
apache::apache_files {
/etc/httpd/conf/httpd.conf:
source = puppet:///apache/httpd.conf
}
service { httpd:
enable = true,
ensure = running,
hasrestart = true,
hasstatus = true,
require = Package[httpd]
}
}
## /etc/puppet/modules/apache/manifests/virtual_host.pp
define apache::virtual_host($ip, $ensure = enabled) {
$file = /etc/httpd/conf.d/$name.conf
$document_root = /var/www/html/$name
file { $file:
ensure = $ensure ? {
enabled = present,
disabled = absent },
content = template(apache/virtual_host.erb),
notify = Service[httpd]
}
file { $document_root:
ensure = $ensure ? {
enabled = directory,
disabled = absent },
require = File[$file]
}
}
# /etc/puppet/modules/apache/templates/virutal_host.erb
VirtualHost %= ip %
DocumentRoot %= document_root %
ServerName %= name %
/VirtualHost
## /etc/puppet/manifests/nodes.pp
node 'mclient.example.net' inherits webserver {
}
node 'kromep1.example.net' inherits mailserver {
apache::virtual_host { ext-kromep1.ops.example.com:
ip = 50.xx.xxx.255
}
apache::virtual_host { web1.ops.example.com:
ip = 50.xx.xxx.255
}
}
node 'kromep2.example.net' inherits webserver {
apache::virtual_host { web2.ops.example.com:
ip = 174.xx.xxx.60
}
}
node 'kromedb1.example.net' inherits dbserver {
}
I would like to take this opportunity to thank you again. the puppet
community has been amazing!! all help that has been rendered and any
that may be is sincerely appreciated!
tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] Role-based access in Dashboard
On 3/2/2011 7:42 PM, Randall Hansen wrote: On Mar 2, 2011, at 3:51 PM, Frank Sweetser wrote: In this scenario, it would be far more useful to simply use LDAP to verify usernames and passwords, and then consult internal records to assign a list of roles. This is a great use case, Frank. What do you mean by internal records in this context? Dashboard itself? Or another service at your site? Originally I was thinking of within Dashboard, though of course some sites might find it more useful to have it in some other service. Use a central RADIUS server for authentication, and then a departmental LDAP server for role assignment, or a few records within Dashboard for small sites (here, for example, we'd only have three or four Dashboard users to manage). In the more flexible products I've used, you basically define a list of AAA servers, which can typically be RADIUS, LDAP or something internal to the application (obviously other things like an RSA token would also be applicable). You then get to pick a server for authentication, and one for authorization, independently of each other. That way, sites can easily set things up however works best for them, usually based on political boundaries as much as technical ones. -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Senior Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet mkusers hangs (was Puppet without FQDN (could not retrieve fact fqdn))
So I bit the bullet and added the system to DNS. Now I am trying to generate the files automatically, but when I call puppet --mkusers now it doesn't seem to take any action. I checked the puppet logs but nothing has been logged or generated yet. On Wed, Mar 2, 2011 at 4:54 PM, Richard Crowley r...@rcrowley.org wrote: On Wednesday, March 2, 2011 at 4:43 PM, msacks wrote: Hello, I am testing Puppet and I would like to use it without having to add a DNS entry. Is there a way around this, or am I required to rely on DNS? You can run Puppet like this: puppet master --certname=$(cat/etc/puppet/certname) puppet agent --certname=$(cat/etc/puppet/certname) to use the contents of an arbitrary file as the SSL certificate name instead of the fqdn fact. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet mkusers error (was Puppet without FQDN (could not retrieve fact fqdn))
On Wed, Mar 2, 2011 at 5:24 PM, msacks ntw...@gmail.com wrote: So I bit the bullet and added the system to DNS. Now I am trying to generate the files automatically, but when I call puppet --mkusers now it doesn't seem to take any action. Facepalm, I mean # puppet master --mkusers Yields the following error: Could not parse for environment production: Could not find file /root/master.pp I checked the puppet logs but nothing has been logged or generated yet. On Wed, Mar 2, 2011 at 4:54 PM, Richard Crowley r...@rcrowley.org wrote: On Wednesday, March 2, 2011 at 4:43 PM, msacks wrote: Hello, I am testing Puppet and I would like to use it without having to add a DNS entry. Is there a way around this, or am I required to rely on DNS? You can run Puppet like this: puppet master --certname=$(cat/etc/puppet/certname) puppet agent --certname=$(cat/etc/puppet/certname) to use the contents of an arbitrary file as the SSL certificate name instead of the fqdn fact. -- 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] ANNOUNCE: Puppet 2.6.6 - Release Candidate 1 available!
This maintenance release fixes two issues with Puppet 2.6.5.
Bug #6418: Files with the source parameter set are automatically set to audit
The audit functionality was activated unexpectedly on file resources
that use the source parameter. This could cause spurrious notify
events. These notifications could trigger unintended refreshes of
subscribed resources.
Bug #6541: File type truncates target when filebucket can not retrieve hash
In the case where a file resource had content specified using an
invalid checksum (Eg: {md5}not-a-checksum) or the valid checksum of
a file not contained in the filebucket, the file would end up being
truncated. This is now properly reported as an error, instead of
zeroing out the file.
This release candidate is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.6.6rc1.tar.gz
See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
Report feedback via the Puppet Labs Redmine site:
http://projects.puppetlabs.com
Please select an affected version of 2.6.6rc1.
You can find the Release Notes for Puppet at:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
CHANGELOG
2.6.6rc1
7c2a980 (#6541) Fix content with checksum truncation bug
63e911f (#6418) Recursive files shouldn't be audited
--
Jacob Helwig
signature.asc
Description: Digital signature
Re: [Puppet Users] Puppet mkusers error (was Puppet without FQDN (could not retrieve fact fqdn))
msacks wrote: On Wed, Mar 2, 2011 at 5:24 PM, msacks ntw...@gmail.com wrote: So I bit the bullet and added the system to DNS. Now I am trying to generate the files automatically, but when I call puppet --mkusers now it doesn't seem to take any action. Facepalm, I mean # puppet master --mkusers What version are you running? The git-like sub commands came in 2.6.x and later? 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] Re: Propagating local config changes from a client to the puppetmaster
Still trying to sort out whether this use-case even makes sense, but what if I were to use Puppet to standardize development environments? It may be the case that someone makes a change or sets themselves up with a tool/configuration that allows them to work more efficiently. I can imagine a scenario where, after selling the benefit of these changes to a project lead, we'd want to push that change back to the puppet master so that every dev system would get them without developers having do it manually. Now everyone's on the same page and working with the same tools. Any thoughts? I like the Git idea, and might pursue that, but wondering if anyone has input :) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet mkusers hangs (was Puppet without FQDN (could not retrieve fact fqdn))
On Wed, Mar 2, 2011 at 5:24 PM, msacks ntw...@gmail.com wrote: So I bit the bullet and added the system to DNS. Now I am trying to generate the files automatically, but when I call puppet --mkusers now it doesn't seem to take any action. I checked the puppet logs but nothing has been logged or generated yet. Puppet is probably hanging because it's waiting for a manifest to be fed in on standard input. Do you mean to be executing puppet master --mkusers ? -Jeff -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] ANNOUNCE: Puppet 2.6.6 - Release Candidate 1 available!
Jacob Helwig wrote: This maintenance release fixes two issues with Puppet 2.6.5. To help with testing on Fedora or RHEL/CentOS, I've updated the yum repos at: http://tmz.fedorapeople.org/repo/puppet/ Packages for EL 4 - 6 and Fedora 13 - 15 are available for testing. Add the puppet.repo file from either the epel or fedora directories to /etc/yum.repos.d to enable. If you find problems with the packaging, please let me know. If you find other bugs, please file them in redmine: http://projects.puppetlabs.com/projects/puppet/issues -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ Ambition is a poor excuse for not having enough sense to be lazy. pgpbxDKTzYv8B.pgp Description: PGP signature
Re: [Puppet Users] apache vhosts in puppet
looks like you're not including the apache class, which has the definition
that puppet is complaining about.
On Wed, Mar 2, 2011 at 7:58 PM, Tim Dunphy bluethu...@gmail.com wrote:
hello puppet list!!
I sincerely appreciate your help in the past and hope you don't mind
me bouncing this scenario off of you. I am attempting to define apache
vhosts with a puppet module but things are not going according to plan
at the moment
## error
[root@kromep1 ~]# puppetd --test
info: Caching catalog for kromep1.example.net
err: Could not run Puppet configuration client: Could not find
dependent Service[httpd] for
File[/etc/httpd/conf.d/web1.ops.example.com.conf] at
/etc/puppet/modules/apache/manifests/virtual_host.pp:11
## /etc/puppet/modules/apache/init.pp
class apache {
$packagelist = [httpd,webalizer,mod_ssl]
package { $packagelist:
ensure = installed
}
apache::apache_files {
/etc/httpd/conf/httpd.conf:
source = puppet:///apache/httpd.conf
}
service { httpd:
enable = true,
ensure = running,
hasrestart = true,
hasstatus = true,
require = Package[httpd]
}
}
## /etc/puppet/modules/apache/manifests/virtual_host.pp
define apache::virtual_host($ip, $ensure = enabled) {
$file = /etc/httpd/conf.d/$name.conf
$document_root = /var/www/html/$name
file { $file:
ensure = $ensure ? {
enabled = present,
disabled = absent },
content = template(apache/virtual_host.erb),
notify = Service[httpd]
}
file { $document_root:
ensure = $ensure ? {
enabled = directory,
disabled = absent },
require = File[$file]
}
}
# /etc/puppet/modules/apache/templates/virutal_host.erb
VirtualHost %= ip %
DocumentRoot %= document_root %
ServerName %= name %
/VirtualHost
## /etc/puppet/manifests/nodes.pp
node 'mclient.example.net' inherits webserver {
}
node 'kromep1.example.net' inherits mailserver {
apache::virtual_host { ext-kromep1.ops.example.com:
ip = 50.xx.xxx.255
}
apache::virtual_host { web1.ops.example.com:
ip = 50.xx.xxx.255
}
}
node 'kromep2.example.net' inherits webserver {
apache::virtual_host { web2.ops.example.com:
ip = 174.xx.xxx.60
}
}
node 'kromedb1.example.net' inherits dbserver {
}
I would like to take this opportunity to thank you again. the puppet
community has been amazing!! all help that has been rendered and any
that may be is sincerely appreciated!
tim
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: err: Could not request certificate: Error 400 on SERVER: error too long
Hi again, A couple of quick updates: - I upgraded my server and client to 2.6.6-rc1 (again from tmz's repo) and the problem still persists. - I run the master behind nginx and via unicorn. Quick revert to WEBrick showed the same problem. -Naresh V. On 2 March 2011 21:17, Naresh V nares...@gmail.com wrote: Hi, I recently upgraded my puppet master and clients from 2.6.2 to 2.6.4. Things were fine until today I tried introducing a new host to my master for the first time: client: [root@db-us1 ~]# rpm -qa puppet puppet-2.6.4-0.7.el5 [root@db-us1 ~]# puppetd -t -v warning: peer certificate won't be verified in this SSL session warning: peer certificate won't be verified in this SSL session err: Could not request certificate: Error 400 on SERVER: header too long Exiting; failed to retrieve certificate and waitforcert is disabled [root@db-us1 ~]# master: #-(0) rpm -qa | grep puppet puppet-2.6.4-0.7.el5 puppet-server-2.6.4-0.7.el5 Mar 2 14:26:29 puppet puppet-master[21312]: header too long #-(0) puppetca -l err: Could not call list: header too long How can I fix this? -Naresh V. P.S.: The RPMs are from tmz's repo. -- 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: Propagating local config changes from a client to the puppetmaster
On Wednesday, March 2, 2011 at 5:52 PM, Patrick Connolly wrote: Still trying to sort out whether this use-case even makes sense, but what if I were to use Puppet to standardize development environments? It may be the case that someone makes a change or sets themselves up with a tool/configuration that allows them to work more efficiently. I can imagine a scenario where, after selling the benefit of these changes to a project lead, we'd want to push that change back to the puppet master so that every dev system would get them without developers having do it manually. Now everyone's on the same page and working with the same tools. Any thoughts? I like the Git idea, and might pursue that, but wondering if anyone has input :) I use DevStructure's (full disclosure: I'm the CTO) Blueprint tool to promote configurations from development to production. Blueprint figures out what I did to my development server and then I commit the Puppet code it generates to Git. http://devstructure.com/tutorial.html http://devstructure.github.com/blueprint/ -- 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] Nagios configuration arrays
On 03-03-11 08:04, Gabriel Filion wrote: On 11-03-02 02:27 PM, Brian Gallew wrote: I've found that Puppet/Naginator has the bad habit of occasionally breaking the Nagios config. Here's how I worked around this: 1) When you collect your Nagios resource, store them all in a temporary directory (in my case, ~nagios/var/tmp) 2) Purge that directory with a cron job every night (so deleted resources disappear) 3) Create an exec that creates a ~nagios/etc/nagios-tmp.cfg by running sed on ~nagios/etc/nagios.cfg and changing directories appropriately. 4) Create an exec that pre-flights Nagios using the nagios-tmp.cfg (which checks the tmp dir) and, if successful, sync the files over into the real Nagios config directory. It's a little clunky, but Nagios doesn't ever break anymore. Remember that your pre-flight exec should require all the Nagios resources (so the files get updated first), and should always run if the contents of the tmp dir vary at all from the real target (diff is your friend here). Otherwise, the preflight may fail once and then never run again until the next time you make a substantive server change. hmm, that's an interesting approach. it sounds like it requires a lot of exec magic but it does cover for the config breakages and also for purging resources. When I finally get some free time, I'll look into implementing that. Thanks for the hint. Nice! Currently, our Nagios config lives in a Git repository. Before pulling changes to /etc/nagios3 and restarting Nagios, we pull them to a temp dir, and with a nagios.conf with adapted paths, we test the config, just like you describe. This is all pretty much automated, so it's something I have been thinking about, how to implement that in Puppet. Step 3 in your description is -in our setup- unnecessary, we just keep the test-config in our repo as well. Thanks. Best regards, Martijn. -- 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.
