Re: [Puppet Users] Classes in templates
On 23 November 2010 19:27, Dan Bode d...@puppetlabs.com wrote: This is unfortunately true. It's possible that this may work in a future version. It's described by this ticket: http://projects.puppetlabs.com/issues/3049 Which you might want to add yourself as a watcher to, Alaric. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] browsing puppet file server
Hi all, I'm wondering if there is some way for browsing puppet file server. Sometimes I get the Could not retrieve information from source and I get crazy looking for typos in paths. If not, how do you check path sanity? Cheers, Arnau -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] file content
Hi all,
I have a problem when adding content to a file. I know this sound
basic, but I don't know what I'm doing wrong...
my server runs puppet-server-2.6.3-0.4.el5 and client
puppet-2.6.1-0.6.el5.
I firs defined a file like:
file { 'default_dns':
name= '/etc/resolv.conf',
content = search mydomain.com \nnameserver 192.168.1.1 \nnameserver
192.168.1.2; }
It returns the error:
You cannot specify more than one of content, source, target at ...
SO I tried the example from
http://docs.puppetlabs.com/references/stable/type.html#file like
$srt=search mydomain.com \nnameserver 192.168.1.1 \
\nnameserver192.168.1.2
file {
'default_ntp':
name= '/etc/ntp.conf',
content = $srt#
} }
*notice double { at the end, as the exmaple shows, alo tried with simple }
with , and ; after $srt
All my combinations produce and error. Double } syntax one (is doc wrong?) and
others same as above...
So, how may I specify file content?
TIA,
Arnau
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] file content
Hi, On Wed, Nov 24, 2010 at 5:02 PM, Arnau Bria arnaub...@pic.es wrote: SO I tried the example from http://docs.puppetlabs.com/references/stable/type.html#file like In that example, a define is being used, called resolve. There is no extra curly bracket, the formatting of the documentation looks a bit screwed. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] file content
Hi,
You probably have a File statement somewhere (like site.pp) which has a
default source or target attributes.
Ohad
On Wed, Nov 24, 2010 at 2:06 PM, Arnau Bria arnaub...@pic.es wrote:
On Wed, 24 Nov 2010 17:27:23 +0530
Mohit Chawla wrote:
Hi,
On Wed, Nov 24, 2010 at 5:02 PM, Arnau Bria arnaub...@pic.es wrote:
SO I tried the example from
http://docs.puppetlabs.com/references/stable/type.html#file like
In that example, a define is being used, called resolve. There is no
extra curly bracket, the formatting of the documentation looks a bit
screwed.
You're right.
anyway, without the define, that should be something like:
file { my_file:
content = my content,
}
and that produces an error in my code.
Thanks for your answer,
Cheers,
Arnau
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.compuppet-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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Initial data population
On Tue, Nov 23, 2010 at 6:41 PM, Daniel Pittman dan...@rimspace.net wrote:
Ashley Penney apen...@gmail.com writes:
As an example of the kind of thing we're talking about we use a product
called Sonatype Nexus that relies on a bunch of on disk data in
/srv/sonatype-nexus/. When installing the system for the first time (for
example, when the file{} containing the .war triggers) we would like it
to
automatically put down a copy of /srv/sonatype-nexus/. We obviously
don't
want this drifting out of sync with the production data which is where
the
issue is. How do other people handle this?
Package those data files yourself, if necessary including logic in the
package
to ensure that you don't overwrite valuable local changes. Then use puppet
to
ensure that package is either 'installed' or 'latest'.
I suppose this is possible, but awkward. An example of another application
is this horrible Java CMS that we use that writes numerous XML files of
random names all over the place during operation. There's cache
directories, it constantly rewrites various bits of configuration xml files,
it spews logs all over. Packaging something like that up in a way that is
functional is almost impossible. When we want to reinstall/clone that
server we just copy the entire directory and then run Puppet to change a few
key XML files. Something like that is difficult to package, and the files
that you would package change frequently due to patches and internal
development on top of the CMS.
Our options seem to be:
* Nightly/hourly backups of production data to some location where Puppet
can rsync/wget/shovel it out when needed.
* Some kind of process that real-time syncs directories to nfs storage.
* Erroring if the data is missing in some fashion when Puppet runs and
relying on
sysadmins to put it in place.
...or making it available as a puppet file server, and using puppet to put
it
in place.
In our experience that is almost unusable, speedwise.
We've talked through the options but they all have fairly significant
drawbacks. My personal favorite solution would be some kind of daemon
that
syncs data constantly and is capable of intelligently syncing the data
back
to the node if it goes missing. It could be potentially error prone but
it
represents the least bad choice.
You could potentially just use:
file { /example:
source = 'puppet:///module/example', replace = false
}
That will only put the file in place if it doesn't already exist.
Hmm, I always forget about replace = false. I wonder if it has the same
awful speed penalties. I think my issue with this is still the hassle of
constantly syncing the changing files back into Puppet. That's why I was
looking for some kind of semi or fully automated syncing mechanism for
something like this. It's mostly Java apps that are especially bad for
this. Most open source software sticks data into a database or at least a
single easily dealt with directory. Java explodes all over the place like
some kind of evil virus.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Initial data population
On Tue, Nov 23, 2010 at 2:30 PM, Patrick kc7...@gmail.com wrote: 1) So are the Puppet clients (Nexus servers) supposed to be modifying the data in /srv/sonatype-nexus like a database or is it used read-only like a file server? They modify data in that directory. I explained further in another email but we have several Java apps that do similar things, constantly changing/adding xml files and all kinds of logs and other stuff for running. 2) If you change the master copy of the data, can you wipe the data and recopy on each client or do you need to merge in changes? I think in most cases it would require a remerge. Generally speaking I'm only dealing with a single client using this data at a time so my concerns are more 'if the data is not there completely, automatically reprovision it with a copy as up to date as possible' rather than changing things. If there are specific file configuration files I need to change within the data then I handle that within Puppet like any other application. 3) How big is the biggest file in the data? What's the total size? Hmm, I'm not logged in to check at the moment but generally we're talking a maximum of 4G of data for one of these applications, and some closer to 1G. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Class inheritance
On Nov 23, 2:22 pm, Chris C mazzy...@gmail.com wrote:
I'm trying to establish a simple inheritance
Although people new to Puppet seem to like to try that, especially
when they have a programming background, it's usually not a very good
idea. For one thing, inheritance in Puppet doesn't work the way
newbies typically expect it to do. For another, it is frequently the
case that real-world systems don't fit neatly into the cubbyhole of a
single leaf node of the tree.
[...]
I have classes with defined files and services for each class of
systems.
Here is an example...
cat classes/all/class.pp
class all_hosts {
file { /etc/motd:
ensure = present,
mode = 644,
owner = root,
group = root,
checksum = md5,
source =
/net/puppetmaster/etc/puppet/manifests/files/all/motd
}
cat classes/redhat/all/class.pp
class all_linux {
file { /etc/motd:
ensure = present,
mode = 644,
owner = root,
group = root,
checksum = md5,
source =
/net/puppetmaster/etc/puppet/manifests/files/all/motd
}
cat site.pp
class all_hosts_redhat {
###
# CLASS DEFINITION
import classes/all/class.pp
import classes/redhat/all/class.pp
###
# NODE DEFINITIONS
node default {
include all_hosts
}
node /^prac6.akc.org/ {
include all_linux
}
I had a heck of a time getting around the Duplicate Definition
issue.
Shouldn't file { /etc/motd in prac override file { /etc/motd in
all_hosts?
No. For good reasons, Puppet forbids duplicate resource declarations
in the scope of any node (but see below).
When I do a puppetd --test the content of motd flip flops
between the two classes.
That's surprising, because
a) unless its hostname changes or your manifests change, each node
will get only one definition of File[/etc/motd], and besides,
b) both definitions you have shown point to the same file. (*)
(*) Filesystem paths are resolved on the client, and it looks like in
your case the file is remote, so you might be getting changes either
because a different remote filesystem is mounted at different times or
because the remote file is changing.
Maybe there is a better way to do this and I'm just missing something.
Yes, there are better ways. Here are several recommendations, with
varying degrees of specificity for your stated problem:
1) Organize your manifests into modules. It is never too early to do
this.
2) As a general rule, do not declare resources directly in node
definitions. Declare them only in classes or definitions. (This does
not appear currently to be an issue for you.)
3) Where you want Puppet to manage individual files (such as /etc/
motd), use its built-in file server. Refer clients to this by using a
source URL of the form puppet:///module/file.
4) If you don't need or want a stand-alone external file to serve,
especially if the contents rarely change, then consider using
content instead of source.
5) If you use node inheritance at all, keep your inheritance tree
extremely shallow. If find yourself using more than two levels then
either refactor your manifests or switch to an external node
classifier (or both).
6) Instead of multiple, similar classes for differing circumstances,
write single classes that use nodes' facts where necessary to tailor
resources to the target node.
7) Use classes instead of node groups to describe facilities or roles
that systems should have. Nodes that serve multiple roles or have
multiple unrelated features then simply include all the appropriate
classes.
8) If you have resources so general that it's otherwise difficult to
declare them in only one place, then create central, virtual
declarations for them, and realize them wherever needed. System
users are the canonical example of such resources.
9) Puppet does provide a feature for overriding resource definitions:
a subclass may override properties of resources declared by one of its
superclasses, using a special syntax. Leveraging this feature is the
*only* good reason for creating a subclass; for any other purpose it
is better to include another class than to inherit from it. Avoid
the temptation to overuse resource overrides, however.
10) For details on how to use any of the features I've mentioned
above, consult the Puppet documentation. In particular, these
documents may be helpful to you:
http://docs.puppetlabs.com/guides/language_tutorial.html,
http://docs.puppetlabs.com/guides/modules.html,
http://docs.puppetlabs.com/guides/file_serving.html. Perhaps also
http://docs.puppetlabs.com/guides/best_practices.html, though it's a
bit skeletal at the moment.
[Puppet Users] Parsing files at nodes
Hi, i want to check if the nodes are forwarding logs to a syslog server. At this moment i cant just push a new syslog.conf file to the nodes, so, i want to know if its possible to tell the nodes to parse the syslog.conf files and fail the run or something like that if a specific line is not found. Is this possible?, if it's possible, any hint? thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: file content
On Nov 24, 6:17 am, Ohad Levy ohadl...@gmail.com wrote: You probably have a File statement somewhere (like site.pp) which has a default source or target attributes. Right. And if you do then it is certainly wrong, because default source or target just does not make sense. If that's not it, then make sure you're not including another File resource with a different title but the same name property. 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: file content
On Nov 24, 6:17 am, Ohad Levy ohadl...@gmail.com wrote:
You probably have a File statement somewhere (like site.pp) which has a
default source or target attributes.
Or, it could be because you have written name = where you want
path =. Or you could omit both and simply title your resource with
the path, like so:
file { /etc/ntp.conf:
content = $src
}
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: file content
On Nov 24, 5:32 am, Arnau Bria arnaub...@pic.es wrote:
[...]
I tried the example
fromhttp://docs.puppetlabs.com/references/stable/type.html#filelike
$srt=search mydomain.com \nnameserver 192.168.1.1 \
\nnameserver192.168.1.2
file {
'default_ntp':
name= '/etc/ntp.conf',
content = $srt#
} }
*notice double { at the end, as the exmaple shows, alo tried with simple
} with , and ; after $srt
All my combinations produce and error. Double } syntax one (is doc wrong?)
and others same as above...
So, how may I specify file content?
The second } at the end of that resource declaration is wrong. A }
would appear in that location only if it was closing a surrounding
class, definition, or logic block.
I'm not sure you would need to do so, but you could try enclosing $src
in quotation marks, like so: $src. The property binding may
optionally be followed by a comma (,) or, because it's the last
property declared for the resource, by a semicolon (;). Thus, I might
write this:
file { /etc/ntp.conf:
content = $src
}
or this:
file { /etc/ntp.conf:
content = $src,
}
or this:
file { /etc/ntp.conf:
content = $src;
}
Also, I do recommend declaring the owner, group, and mode for the
file.
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Documenting an infrastructure with Puppet
Hello All,
I've been thinking recently about how one could use Puppet to aid in the
process of documenting infrastructure for other administrators, managers and so
forth.
Puppetdoc gets me somewhat close, since I can add content above my class
definitions and have that content associated with nodes. It seems to me though
that Puppetdoc's strength is in creating the relationships between classes and
nodes, not in the documenting of what occurs to a system.
Would it seem feasible to anyone if in the future puppetdoc would additionally
parse resources within a class and create some human-readable documentation
from them?
For example, let's suppose I have a class which has a file resource.
# This is the foo-file class that provides a file.
class foo-file {
file { '/etc/foo-file': ensure = present, }
}
Puppetdoc will currently (if I understand its capabilities right) associate the
commented line with the class when producing RDoc, text or whatever output.
What I'm envisioning is for it to also look at the file resource and output
something similar to The foo-file class ensures a file named /etc/foo-file is
present on the system. This could mean that simply by writing Puppet
manifests, puppetdoc would produce documentation describing exactly what a
class would implement on your machine.
Does this seem useful to anyone else but me? If we can get a discussion going
about this and there's interested, I'd be happy to write-up the feature request
with our consensus.
Thanks for reading, --Ryan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Class inheritance
Thanks for the reply!
I was able to get override to work correctly.
My classes are inheriting each other. prac inherits all_hosts_redhat which
inherits all_hosts.
I cleaned up some unnecessary duplicate checks like chmod and own.
I changed the definition to the overided file to File['/etc/motd'] {
I also set a variable at the top of the class so I can easily override
content source
ie...
class all_hosts_redhat inherits all_hosts {
$dir = redhat/all
#CONFIGURE MOTD
file { /etc/motd:
checksum = md5,
source = /net/puppetmaster/etc/puppet/manifests/files/$dir/motd
}
}
This gives me the option to have different motd's for different classes and
I no longer have the funny flip flopping of content in motd...
The tutorial at puppetlabs really helped to iron out the issues.
I have some comments. They are inline.
I had a heck of a time getting around the Duplicate Definition
issue.
Shouldn't file { /etc/motd in prac override file { /etc/motd in
all_hosts?
No. For good reasons, Puppet forbids duplicate resource declarations
in the scope of any node (but see below).
When I do a puppetd --test the content of motd flip flops
between the two classes.
That's surprising, because
a) unless its hostname changes or your manifests change, each node
will get only one definition of File[/etc/motd], and besides,
b) both definitions you have shown point to the same file. (*)
(*) Filesystem paths are resolved on the client, and it looks like in
your case the file is remote, so you might be getting changes either
because a different remote filesystem is mounted at different times or
because the remote file is changing.
Maybe I found a bug. Does Puppetlabs pay like Mozilla pays? ;)
Maybe there is a better way to do this and I'm just missing something.
Yes, there are better ways. Here are several recommendations, with
varying degrees of specificity for your stated problem:
1) Organize your manifests into modules. It is never too early to do
this.
What do you mean by this? I thought my manifest was modular?
2) As a general rule, do not declare resources directly in node
definitions. Declare them only in classes or definitions. (This does
not appear currently to be an issue for you.)
Only class includes are being added to my node definition
3) Where you want Puppet to manage individual files (such as /etc/
motd), use its built-in file server. Refer clients to this by using a
source URL of the form puppet:///module/file.
Is using the puppet fileserver high performance? I'm expecting to have
300-500 clients. These VM's just keep popping up like daisy's in my lawn.
4) If you don't need or want a stand-alone external file to serve,
especially if the contents rarely change, then consider using
content instead of source.
Hm. I think I will consider that. I have 60 some checks and doing md5sum's
seems heavy weight.
My intention is to use Puppet to manage the content of our public website.
Our website is extensive.
5) If you use node inheritance at all, keep your inheritance tree
extremely shallow. If find yourself using more than two levels then
either refactor your manifests or switch to an external node
classifier (or both).
I do want to use an external node classifier. I don't think I'm far enough
along yet.
I would like our Active Directory to hold manifest data. Unfortunately our
AD needs ALOT of cowbell at this time. That is going to be my winter
project.
6) Instead of multiple, similar classes for differing circumstances,
write single classes that use nodes' facts where necessary to tailor
resources to the target node.
7) Use classes instead of node groups to describe facilities or roles
that systems should have. Nodes that serve multiple roles or have
multiple unrelated features then simply include all the appropriate
classes.
8) If you have resources so general that it's otherwise difficult to
declare them in only one place, then create central, virtual
declarations for them, and realize them wherever needed. System
users are the canonical example of such resources.
I saw those features in the tutorial. I'm definitely going to go that
direction. I'm glad to get this first step to work.
My classes are already getting out of hand. It sure didn't take long.
9) Puppet does provide a feature for overriding resource definitions:
a subclass may override properties of resources declared by one of its
superclasses, using a special syntax. Leveraging this feature is the
*only* good reason for creating a subclass; for any other purpose it
is better to include another class than to inherit from it. Avoid
the temptation to overuse resource overrides, however.
10) For details on how to use any of the features I've mentioned
above, consult the Puppet documentation. In particular, these
documents may be helpful to you:
Re: [Puppet Users] Re: file content
On Wed, 24 Nov 2010 07:22:11 -0800 (PST)
jcbollinger jcbollinger wrote:
On Nov 24, 6:17 am, Ohad Levy ohadl...@gmail.com wrote:
Hi !
I'm getting a little crazy with this... I'll paste some code and see if
you see what's happening...
You probably have a File statement somewhere (like site.pp) which
has a default source or target attributes.
Nop, I'm not defining source/content default.
Right. And if you do then it is certainly wrong, because default
source or target just does not make sense.
Not my case, but maybe someone want to ensure that every file
defined at puppet has its content modified by source/content. So,
I could define a source/content with should be modified by
puppet in it... i go to client and I see some file with that contetn I
know it's not controlled as desired... anyway, as I said not my case...
My problem:
node 'default' {
include common_system_defaults
}
site.pp defines a default:
# grep File site.pp
File { ignore = .svn }
My class its own default:
class common_system_defaults {
File {
ensure = prsent,
mode= 644,
owner = root,
group = root,
}
[ ... and my files ... ]
file {
'default_dns':
name= '/etc/resolv.conf',
content = search mydomain nameserver XXX.XXX.XXX.XXX;
'default_ntp':
name= '/etc/ntp.conf',
content = 'server myserver.mydomain prefer server
myotherserver.mydomain';
}
# pwd
/etc/puppet/manifests
# grep -r content *|grep -v .svn
modules/common_defaults/manifests/init.pp: content =
search mydomain nameserver XXX.XXX.XXX.XXX;
modules/common_defaults/manifests/init.pp: content =
'server myserver.mydomain prefer server myotherserver.mydomain';
In resume, I want to modify resolv.conf and ntp.conf.
in my client:
# puppetd --test --server $server
info: Caching catalog for $client
err: Could not run Puppet configuration client: You cannot specify more than
one of content, source, target at
/etc/puppet/manifests/modules/common_defaults/manifests/init.pp:36
Line 36 i } of the above code...
where is content doubled?
If I commment default_ntp, the problems des not disappear:
file {
'default_dns':
name= '/etc/resolv.conf',
content = search mydomain nameserver XXX.XXX.XXX.XXX;
#'default_ntp':
# name= '/etc/ntp.conf',
# content = 'server myserver.mydomain prefer server
myotherserver.mydomain';
}
# puppetd --test --server $server
info: Caching catalog for $client
err: Could not run Puppet configuration client: You cannot specify more than
one of content, source, target at
/etc/puppet/manifests/modules/common_defaults/manifests/init.pp:36
If that's not it, then make sure you're not including another File
resource with a different title but the same name property.
If I comment content line, all works fine:
file { 'default_dns':
name= '/etc/resolv.conf',
# content = search pic.es nameserver 193.109.175.5
nameserver 193.109.172.144 nameserver 158.109.0.1 nameserver 84.88.0.5;
}
info: Applying configuration version '1290614540'
info: FileBucket adding /etc/resolv.conf as
{md5}6607f03347a11c61819976c8e28483bf
info: /Stage[main]/Common_system_defaults/File[default_dns]: Filebucketed
/etc/resolv.conf to puppet with sum 6607f03347a11c61819976c8e28483bf
notice: /Stage[main]/Common_system_defaults/File[default_dns]/ensure: ensure
changed 'file' to 'link'
notice: Finished catalog run in 0.37 seconds
So seems to me that no doubled name property defined...
Any help? I'm losing my patience with this
John
Cheers,
Arnau
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: file content
On Wed, 24 Nov 2010 07:39:09 -0800 (PST)
jcbollinger jcbollinger wrote:
On Nov 24, 6:17 am, Ohad Levy ohadl...@gmail.com wrote:
You probably have a File statement somewhere (like site.pp) which
has a default source or target attributes.
Or, it could be because you have written name = where you want
path =. Or you could omit both and simply title your resource with
the path, like so:
file { /etc/ntp.conf:
content = $src
}
file { '/etc/resolv.conf':
path= '/etc/resolv.conf',
content = whatever;
}
info: Caching catalog for services3.pic.es
err: Could not run Puppet configuration client: You cannot specify more than
one of content, source, target at
/etc/puppet/manifests/modules/common_defaults/manifests/init.pp:33
My prod environment works fine with
file { 'descr':
name= $path ;
}
Now, after your reply, I've checked type ref and I don't see name
anymore... :-S
John
Cheers,
Arnau
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Parsing files at nodes
On Wed, Nov 24, 2010 at 7:13 AM, Nicolas Arias nicoar...@gmail.com wrote: Hi, i want to check if the nodes are forwarding logs to a syslog server. At this moment i cant just push a new syslog.conf file to the nodes, so, i want to know if its possible to tell the nodes to parse the syslog.conf files and fail the run or something like that if a specific line is not found. Is this possible?, if it's possible, any hint? a) Use an exec resource to grep -q the relevant line. This will push the success/failure of the grep to the exit status, so the exec will fail if the line is missing. Put this in a class and make all the relevant resources require that class. or b) Push the search to the puppet pre-run command. # A command to run before every agent run. If this command returns a non-zero # return code, the entire Puppet run will fail. # The default value is ''. # prerun_command = thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] using define of different moule's manifest
hi all,
I had defined a module like this ..
modulea
-- ---manifest
-- ---myclassa.pp
# i have declared number
defines..like
define defile1
{
...
}
define defile2
{
...
}
=
moduleb
-- ---manifest
-- ---myclassb.pp
# where i want to use those
defines..of module modulea
=
can anyone tell me ..
How can I invoke defines of module modulea in module moduleb's
manifest ?
and
Plz give me link of document reference for most information .
--
Sanjiv Singh (iLabs)
Impetus Infotech India.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] What is Puppet capable of?
Hi all, I've been reading up on Puppet but there are a few things I am unsure of, and I'm hoping someone here can advise. As I understand it the idea behind Puppet is to describe how a machine should be configured in a single place, and then let Puppet handle the actual set up of the machine. How specific is this? For example, I use Exim as an e-mail MTA, with some custom config rules related to SpamAssassin. Do I describe all these in Puppet configuration files, so that Puppet can produce the correct Exim config file? I'm also about to migrate a server onto new hardware and I would like to upgrade the OS at the same time (change Linux distribution actually.) Would it be possible to configure Puppet on the old server, run it in debug mode to see what would be changed, then tweak the configuration until *nothing* would be changed (so that the Puppet config exactly matches the current server config) then apply that to the new server? Would this result in the new server being set up exactly the same as the old one, with the same software installed (albeit newer versions) and the same config set? Many thanks, Adam. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet Daemontools
Hi there,
I've been playing with puppet for a couple of weeks (So, I'm still quite a
newbie at it) and there is something I just can't seem to be able to fix.
I'm trying to have puppet manage daemontools service. Following the
documentation http://docs.puppetlabs.com/guides/types/service.html, I
added this in my puppet configuration:
class run_kuhmiho_service { service { puppet/$package:
http://localhost:8000/rev/e823d59610e4#l1.13 provider =
daemontools,http://localhost:8000/rev/e823d59610e4#l1.14ensure
= running,}
But, when the puppet tries to apply this configuration, I got : err: Could
not create puppet/ws-auth-0.1.0-SNAPSHOT: Parameter provider failed: Invalid
service provider 'daemontools'
Both puppetmaster and puppet are using a 0.25.x version of puppets and
support for 'daemontools' seems to have been added for those according to
the changelog. Any clues ? Did anyone on this list, tried and successfully
used daemontools with puppet ? Is this version good enoug or should I used
a more recent one ?
--
Romain PELISSE,
*The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it -- Terry Pratchett*
http://belaran.eu/
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Parsing files at nodes
Thanks Nigel!!, i will give it a try later! On Wed, Nov 24, 2010 at 1:41 PM, Nigel Kersten ni...@puppetlabs.com wrote: On Wed, Nov 24, 2010 at 7:13 AM, Nicolas Arias nicoar...@gmail.com wrote: Hi, i want to check if the nodes are forwarding logs to a syslog server. At this moment i cant just push a new syslog.conf file to the nodes, so, i want to know if its possible to tell the nodes to parse the syslog.conf files and fail the run or something like that if a specific line is not found. Is this possible?, if it's possible, any hint? a) Use an exec resource to grep -q the relevant line. This will push the success/failure of the grep to the exit status, so the exec will fail if the line is missing. Put this in a class and make all the relevant resources require that class. or b) Push the search to the puppet pre-run command. # A command to run before every agent run. If this command returns a non-zero # return code, the entire Puppet run will fail. # The default value is ''. # prerun_command = thanks -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] What is Puppet capable of?
On Nov 23, 2010, at 4:53 PM, Adam Nielsen wrote: Hi all, I've been reading up on Puppet but there are a few things I am unsure of, and I'm hoping someone here can advise. As I understand it the idea behind Puppet is to describe how a machine should be configured in a single place, and then let Puppet handle the actual set up of the machine. How specific is this? For example, I use Exim as an e-mail MTA, with some custom config rules related to SpamAssassin. Do I describe all these in Puppet configuration files, so that Puppet can produce the correct Exim config file? I'm also about to migrate a server onto new hardware and I would like to upgrade the OS at the same time (change Linux distribution actually.) Would it be possible to configure Puppet on the old server, run it in debug mode to see what would be changed, then tweak the configuration until *nothing* would be changed (so that the Puppet config exactly matches the current server config) then apply that to the new server? Would this result in the new server being set up exactly the same as the old one, with the same software installed (albeit newer versions) and the same config set? Nice idea, but not going to work. The problem is that an empty puppet config will also give you no changes. Doing this is a good idea, but you are almost sure to miss files that need to be changed that puppet is not changing because you didn't tell it to. As a simple example, suppose I need to change 3 files A, B, and C. When I first run puppet with an empty config, everything looks good because it tries to change nothing. Then I add A and B, but B has a mistake. I run puppet (with --noop) and puppet tells me it tried to change the file. I fix B and now I get no messages again, but I still don't realize that I missed C. In practice, there will often be a file you missed and you won't know until you try. Basically, I would try this, but expect that the new server will need a lot of runs with catalog treaking each time until it works. Once it works though, it makes disaster recovery much easier. (Although you still need a good backup plan for data.) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] The puppet model
Hello,
On 11/23/2010 12:34 PM, Dan Bode wrote:
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Internals
The model in puppet is implemented as a directed acyclic graph (DAG). The
vertices of the graph are resoures, the edges are the relationships (order
dependencies) between resources.
Resource types describe the desired state of a resource in terms of
properties.
ex: File has properties content, mode, owner, group
Types specify the description of a resource, which is abstracted from
providers that specify the implementation (how we query the current state,
how we synchronize)
ex: package { 'foo': ensure = installed} is a relevant description
regardless of the implementation of how we query the current state and how
we synchronize if it does not match the description. (could be apt, rpm,
yum)
Properties are attributes of resources that can be synchronized.
The synchronization process is as follows:
- query the real state of the property on the system
- compare to the desired state
- if they are not the same, then synchronize them
- if we have to sync resources, then create an event.
This description is actually concise and quite understandable. I would
suggest adding it to Puppet's documentation wiki, not too far away from
the extended knowledge section [1].
[1]: http://docs.puppetlabs.com/#extended-knowledge
--
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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] The puppet model
On Wed, Nov 24, 2010 at 10:46 AM, Gabriel Filion lelu...@gmail.com wrote:
Hello,
On 11/23/2010 12:34 PM, Dan Bode wrote:
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Internals
The model in puppet is implemented as a directed acyclic graph (DAG). The
vertices of the graph are resoures, the edges are the relationships (order
dependencies) between resources.
Resource types describe the desired state of a resource in terms of
properties.
ex: File has properties content, mode, owner, group
Types specify the description of a resource, which is abstracted from
providers that specify the implementation (how we query the current state,
how we synchronize)
ex: package { 'foo': ensure = installed} is a relevant description
regardless of the implementation of how we query the current state and how
we synchronize if it does not match the description. (could be apt, rpm,
yum)
Properties are attributes of resources that can be synchronized.
The synchronization process is as follows:
- query the real state of the property on the system
- compare to the desired state
- if they are not the same, then synchronize them
- if we have to sync resources, then create an event.
This description is actually concise and quite understandable. I would
suggest adding it to Puppet's documentation wiki, not too far away from
the extended knowledge section [1].
[1]: http://docs.puppetlabs.com/#extended-knowledge
Just wanted to point out that we accept patches for the documentation :)
I love Dan's description here, it is indeed concise and
understandable. Let's get it in the docs for sure.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: puppetdoc and wrong comparison
Has there been any update to this issue? Iam seeing the same thing in my environment. redhat el 5.5 2.6.18-194.11.3.el5 rhel - ruby-1.8.5-5.el5_4.8 epel - puppet-dashboard-1.0.4-1 epel - puppet-server-2.6.0-1 epel - puppet-2.6.0-1 Thanks, /Chris C -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: file content
On Wed, Nov 24, 2010 at 05:03:45PM +0100, Arnau Bria wrote:
On Wed, 24 Nov 2010 07:22:11 -0800 (PST)
jcbollinger jcbollinger wrote:
On Nov 24, 6:17 am, Ohad Levy ohadl...@gmail.com wrote:
Hi !
I'm getting a little crazy with this... I'll paste some code and see if
you see what's happening...
You probably have a File statement somewhere (like site.pp) which
has a default source or target attributes.
Nop, I'm not defining source/content default.
If I comment content line, all works fine:
file { 'default_dns':
name= '/etc/resolv.conf',
# content = search pic.es nameserver 193.109.175.5
nameserver 193.109.172.144 nameserver 158.109.0.1 nameserver 84.88.0.5;
}
info: Applying configuration version '1290614540'
info: FileBucket adding /etc/resolv.conf as
{md5}6607f03347a11c61819976c8e28483bf
info: /Stage[main]/Common_system_defaults/File[default_dns]: Filebucketed
/etc/resolv.conf to puppet with sum 6607f03347a11c61819976c8e28483bf
notice: /Stage[main]/Common_system_defaults/File[default_dns]/ensure: ensure
changed 'file' to 'link'
notice: Finished catalog run in 0.37 seconds
I dont think its working fine, when /etc/resolv.conf is now a link (ensure
changed 'file' to 'link'). At first
* don't use name. If anything, use path but I recommend just declaring
file {'/etc/resolv.conf': content = ...).
* If you still have strange results try to use an explicit ensure (you
should always specfy one anyways. So use ensure = 'file' to make sure
its a normal file
* If you still get strange results, test to set target = undef and
source = undef. If this helps, you have set a default somewhere.
But maybe there is just a missing bracket somewhere so puppet will try
to parse different resource definitions as one
-Stefan
pgpS88ksSKyMQ.pgp
Description: PGP signature
Re: [Puppet Users] What is Puppet capable of?
Patrick kc7...@gmail.com writes: On Nov 23, 2010, at 4:53 PM, Adam Nielsen wrote: I've been reading up on Puppet but there are a few things I am unsure of, and I'm hoping someone here can advise. As I understand it the idea behind Puppet is to describe how a machine should be configured in a single place, and then let Puppet handle the actual set up of the machine. How specific is this? It varies: puppet has a whole bunch of types and providers, which provide a high level way to interact with a bunch of system stuff. You can also get modules from the Puppet Forge that other folks have written to do the same, or write your own. However, you are likely to still end up doing some things through copy this file into this place commands inside puppet. (All in puppet, though - you don't need *another* system beside it.) For example, I use Exim as an e-mail MTA, with some custom config rules related to SpamAssassin. Do I describe all these in Puppet configuration files, so that Puppet can produce the correct Exim config file? I don't know of a good Exim provider, so you would probably end up with a combination of copying in config files in puppet, and using the regular service and package management types. I'm also about to migrate a server onto new hardware and I would like to upgrade the OS at the same time (change Linux distribution actually.) Would it be possible to configure Puppet on the old server, run it in debug mode to see what would be changed, then tweak the configuration until *nothing* would be changed (so that the Puppet config exactly matches the current server config) then apply that to the new server? Yes. It would be a huge amount of work, though, probably on the order of a couple of weeks per machine if you intend to capture the current state. Would this result in the new server being set up exactly the same as the old one, with the same software installed (albeit newer versions) and the same config set? Maybe: puppet only does what you tell it, so if you missed something (as Patrick says) you would end up with a broken system. I am a touch less dubious about the possibility of success than him, but agree that it is not the best way to do that. Nice idea, but not going to work. The problem is that an empty puppet config will also give you no changes. Doing this is a good idea, but you are almost sure to miss files that need to be changed that puppet is not changing because you didn't tell it to. [...] Basically, I would try this, but expect that the new server will need a lot of runs with catalog treaking each time until it works. Once it works though, it makes disaster recovery much easier. (Although you still need a good backup plan for data.) A much, much better approach is to work out what you want the server to do. Once you know that you can instruct puppet, and it will implement what you tell it to do. Then, once you are comfortable you can just replace the old server with the new one. I know it doesn't sound much different - but there is a huge amount of work in trying to replicate something, while it is usually much easier to sit down and document exactly what you want a machine to do. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] using define of different moule's manifest
On Wed, Nov 24, 2010 at 9:32 AM, sanjiv.singh
sanjiv.si...@impetus.co.in wrote:
hi all,
I had defined a module like this ..
modulea
-- ---manifest
-- ---myclassa.pp
# i have declared number
defines..like
define defile1
{
...
}
define defile2
{
...
}
=
moduleb
-- ---manifest
-- ---myclassb.pp
# where i want to use those
defines..of module modulea
=
can anyone tell me ..
How can I invoke defines of module modulea in module moduleb's
manifest ?
and
Plz give me link of document reference for most information .
You should instead use the autoloader to find the definitions.
Hopefully this example will help.
# File at $modulepath/mymodule/manifests/init.pp
class mymodule { ... }
# File at $modulepath/mymodule/manifests/mydefine.pp
define mymodule::mydefine(..) { ... }
# File anywhere else, outside the mymodule scope.
mymodule::mydefine { ... }
Does that make sense? Because your defined type is
mymodule::mydefine, the autoloader will look for that definition in
$modulepath/mymodule/manifests/mydefine.pp
--
Sanjiv Singh (iLabs)
Impetus Infotech India.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? -- Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Parsing files at nodes
On 24 November 2010 15:13, Nicolas Arias nicoar...@gmail.com wrote: Is this possible?, if it's possible, any hint? Custom fact that tells you where the syslog is going. Custom facts, in general, are your friend. :) -- Gary Law Email/Chat googletalk/messenger: gary@gmail.com iChat/jabber/AIM: gary@mac.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
On 24 November 2010 23:50, Nigel Kersten ni...@puppetlabs.com wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? That depends on the support model (for bug fixes) puppetlabs is prepared to support. I'd be inclined to support all recent client releases under a year old at a minimum. Longer for the real enterprisey conservative shops. Remember, a fair few places in the UK are still-running-IE-6 shops. My firm would be happy for a six month release/patch cycle, but we're not change averse. Others firms I've worked for are. Gary -- Gary Law Email/Chat googletalk/messenger: gary@gmail.com iChat/jabber/AIM: gary@mac.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
Gary Law gary...@garylaw.net writes: On 24 November 2010 23:50, Nigel Kersten ni...@puppetlabs.com wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? That depends on the support model (for bug fixes) puppetlabs is prepared to support. I'd be inclined to support all recent client releases under a year old at a minimum. Longer for the real enterprisey conservative shops. Remember, a fair few places in the UK are still-running-IE-6 shops. One of the bits of feedback I have had from various folks out in the wider world is that (right or wrong) they already feel that Puppet has a pretty fast upgrade cycle and a very poor backward compatibility story. My firm would be happy for a six month release/patch cycle, but we're not change averse. Others firms I've worked for are. *nod* I think that the Debian maintainers would be less than thrilled at support for the versions in Debian/stable being dropped totally, and users of Debian would be unthrilled with needing something out of backports to talk to their newer Puppet server. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
On Wed, Nov 24, 2010 at 4:35 PM, Daniel Pittman dan...@rimspace.net wrote: Gary Law gary...@garylaw.net writes: On 24 November 2010 23:50, Nigel Kersten ni...@puppetlabs.com wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? That depends on the support model (for bug fixes) puppetlabs is prepared to support. I'd be inclined to support all recent client releases under a year old at a minimum. Longer for the real enterprisey conservative shops. Remember, a fair few places in the UK are still-running-IE-6 shops. One of the bits of feedback I have had from various folks out in the wider world is that (right or wrong) they already feel that Puppet has a pretty fast upgrade cycle and a very poor backward compatibility story. My firm would be happy for a six month release/patch cycle, but we're not change averse. Others firms I've worked for are. *nod* I think that the Debian maintainers would be less than thrilled at support for the versions in Debian/stable being dropped totally, and users of Debian would be unthrilled with needing something out of backports to talk to their newer Puppet server. To clarify, I'm not saying we're dropping support for people running those versions, just dropping support for 2.7.x server to talk to 0.24.x clients and earlier. I believe we've always suggested keeping client and server versions close, with the server being upgraded before the clients. The people with Debian stable installs can continue to run the version of server and client that is available to them, same goes for any platform that only offers 0.24.x, 0.25.x or 2.6.x. I'm suggesting this for 2.7.x. Are people really likely to be running 2.7.x servers with 0.24.x clients? I think I would advise people that's not a particularly wonderful combination anyway, given how much code is shared between the server and the client. If you're packaging puppet servers to run 2.7.x, you've already done all the work to package puppet clients for 2.7.x. -- Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
I'd be in favor of only maintaining one rev behind for compatibility (2.7.x will support 2.6.x but not earlier). Cheers, Ryan On Nov 24, 2010, at 4:57 PM, Nigel Kersten wrote: On Wed, Nov 24, 2010 at 4:35 PM, Daniel Pittman dan...@rimspace.net wrote: Gary Law gary...@garylaw.net writes: On 24 November 2010 23:50, Nigel Kersten ni...@puppetlabs.com wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? That depends on the support model (for bug fixes) puppetlabs is prepared to support. I'd be inclined to support all recent client releases under a year old at a minimum. Longer for the real enterprisey conservative shops. Remember, a fair few places in the UK are still-running-IE-6 shops. One of the bits of feedback I have had from various folks out in the wider world is that (right or wrong) they already feel that Puppet has a pretty fast upgrade cycle and a very poor backward compatibility story. My firm would be happy for a six month release/patch cycle, but we're not change averse. Others firms I've worked for are. *nod* I think that the Debian maintainers would be less than thrilled at support for the versions in Debian/stable being dropped totally, and users of Debian would be unthrilled with needing something out of backports to talk to their newer Puppet server. To clarify, I'm not saying we're dropping support for people running those versions, just dropping support for 2.7.x server to talk to 0.24.x clients and earlier. I believe we've always suggested keeping client and server versions close, with the server being upgraded before the clients. The people with Debian stable installs can continue to run the version of server and client that is available to them, same goes for any platform that only offers 0.24.x, 0.25.x or 2.6.x. I'm suggesting this for 2.7.x. Are people really likely to be running 2.7.x servers with 0.24.x clients? I think I would advise people that's not a particularly wonderful combination anyway, given how much code is shared between the server and the client. If you're packaging puppet servers to run 2.7.x, you've already done all the work to package puppet clients for 2.7.x. -- Nigel Kersten - Puppet Labs - http://www.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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
Nigel Kersten ni...@puppetlabs.com writes: On Wed, Nov 24, 2010 at 4:35 PM, Daniel Pittman dan...@rimspace.net wrote: Gary Law gary...@garylaw.net writes: On 24 November 2010 23:50, Nigel Kersten ni...@puppetlabs.com wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? That depends on the support model (for bug fixes) puppetlabs is prepared to support. I'd be inclined to support all recent client releases under a year old at a minimum. Longer for the real enterprisey conservative shops. Remember, a fair few places in the UK are still-running-IE-6 shops. One of the bits of feedback I have had from various folks out in the wider world is that (right or wrong) they already feel that Puppet has a pretty fast upgrade cycle and a very poor backward compatibility story. My firm would be happy for a six month release/patch cycle, but we're not change averse. Others firms I've worked for are. *nod* I think that the Debian maintainers would be less than thrilled at support for the versions in Debian/stable being dropped totally, and users of Debian would be unthrilled with needing something out of backports to talk to their newer Puppet server. To clarify, I'm not saying we're dropping support for people running those versions, just dropping support for 2.7.x server to talk to 0.24.x clients and earlier. As long as that clarification is in the final announcement, folks should hopefully be a bit less unhappy about the change, indeed. :) [...] I'm suggesting this for 2.7.x. Are people really likely to be running 2.7.x servers with 0.24.x clients? Well, it would be convenient for me to be able to do that, because then my host rollout would be install the upstream package, and have puppet manage the process of self-updating to our own packages. Not essential, though, and: I think I would advise people that's not a particularly wonderful combination anyway, given how much code is shared between the server and the client. If you're packaging puppet servers to run 2.7.x, you've already done all the work to package puppet clients for 2.7.x. ...I tend to agree with this. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] vim syntax highlight link broken?
I'm trying to grab a syntax file for vim - but it appears this link is just a website served as plaintext. Can anyone else access this link and get a proper download link? http://www.puppetlabs.com/downloads/puppet/puppet.vim Cheers, Ston -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] vim syntax highlight link broken?
On Wed, Nov 24, 2010 at 5:08 PM, ston8r dri...@gmail.com wrote: I'm trying to grab a syntax file for vim - but it appears this link is just a website served as plaintext. Can anyone else access this link and get a proper download link? http://www.puppetlabs.com/downloads/puppet/puppet.vim https://github.com/puppetlabs/puppet/tree/master/ext/vim/ We should remove the one on 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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] facter fact catalog?
On 21 November 2010 15:55, Nick oinksoc...@letterboxes.org wrote: Hi, A problem I've run into during my first attempts at writing manifests, is knowing what possible facts are available, and for a given fact, what values my manifest might encounter. A classic one is the possible values of $operatingsystem, but it applies to all sorts of facts. Of course, I know that not all facts can be enumerated, but I had expected there be a catalog of common facts and their values somewhere, but there seems not to be. The Facter page [1] and API documentation [2] give rather scanty information about anything, yet alone list any values. Ultimately I've been forced to search out the source code and infer the values from that. This is a good point and certainly an area we can improve on. To that end I've filed https://projects.puppetlabs.com/issues/5394 Then there is the question of how consistent the list of facts and their values are from version to version of Puppet/Facter. That is even harder to discover from the source code. This will get better in the future (tm) but will involve breaking compatibility backwards as we currently have some ill-defined and overlapping facts that don't have a consistent world view and as such attempts to correct them in the past have caused sites to break - eg domainname. We do try to avoid regressions in facts, but this has grown quite hard in some areas and prevented clarification due to ambiguities. What a particular fact name means should be much more apparent, visible and documented. How do other people tackle this problem? For the most part you have a few options when first introducing puppet - run facter manually on your systems as part of a learning exercise, run in no-op mode for a bit and get to understand it's naming. In some cases sites have written custom facts to either override the supplied facts or complement them to give them the consistency you need. 2. http://www.puppetlabs.com/downloads/facter/apidocs/ I'm not sure how much value those API docs are at the moment as facts are littered alongside library routines and there isn't much of a coherent whole. Paul -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Facter: My vision -- crazy?
On 19 November 2010 01:54, Nathan n4th4nr...@gmail.com wrote: Hi, You guys may remember me as the dude at puppet camp who suggested in the facter meeting about having facts return unknown for example, or have a default set of facts. This, oddly to me, seemed to not go over well. Let me explain where I'm coming from and why I think the current state of facter is more or less broken. For what it's worth in future these things are better sent or CC'd to the dev list. I read the users list sporadically at best so if you want my attention dev would be better. Facter seems like an absolutely amazing idea that can potentially almost completely abstract the admin from the specifics of the OS. For me, it is not living up to this dream and in fact it seems that the powers that be inside of puppet labs are somewhat fighting this notion. Maybe I'm misreading this or we simply have a difference in opinion in how that could be achieved. I don't think anyone is against making Anyways, here's what I envision for facter: 1. The basic attributes of the machine you are interfacing with are always represented, and always in the same way. This means the things which are physically impossible to not have will ALWAYS be listed in facter's facts: things like: architecture, processor type, speed, etc, operating system, release versions, etc. Yes but we need to define what those things are, we've certainly seen some odd corner cases crop up from time to time with unusual systems (eg embedded systems). 2. All basic facts and perhaps some extended facts should return unknown if they are not able to be determined: this means there is something wrong with facter. Yes. If facter doesn't know something, then it's an incomplete fact. This is where we disagree - this migh When writing internal facts, if we can't determine a fact, we list it as 'unknown' because that is in fact the value. This promotes code sanity because you can always expect that there will be a value. This makes coding easier because you know the key will exist, though the value may be unknown. Why - the basic Facter structure is kinda hash like, it already has a concept of having a key, returning a spoof value for something doesn't feel right. 3. Using facter should mean you don't have to know almost anything about the system at all and can only use the same few facts over and over to always reliably determine the basic information about the system. This in fact seems like it would be the number one goal of facter, which kind of leaves me at a question of what exactly is the point of facter? Only to support puppet? I don't really get it if the point is not total abstraction. Let me give you a solid example of what I'm talking about: -To find out how many physical processors a box has, we use two facts: physicalprocessorcount and for osx our own fact: osx_physicalprocessorcount. There is a bug for deduping that stuff, and again a goal for 2.x -To find out what operating system we're on, we have to use two facts: operatingsystem and lsbdistid because some operating systems are reported differently than others. For example XenServer reports operatingsystem as RedHat and lsbdisid as XenServer. But lsbdistid doesn't exist on mac and so now I'm forced to use both. A mac isn't an LSB system it makes no sense. You filed a bug for XenServer, so that'll get fixed at some point. There are two problems here - there is no way facter can keep up with the prevalence of distros out there in a reasonable release cycle. Thus there will be always cases sites have to customize, the goal is to make that easy. -To get the architecture of a system I must use architecture and hardwaremodel, since hardwaremodel will spit out something like i686 on centos, but will give you i386 on mac, whereas architecture will give you the i386 for centos but doesn't exist on mac. This is to do with the problem of meaning - facts have evolved and not be designed and we do not necessarily have a consistent world view of what a particular fact means. This needs to be fixed for the core facts (tbd) and is one of the design goals of 2.0. My point is not to complain about all these things but to try to discuss the direction of facter. I got the impression that the main reason behind not adding a bit of intelligence to the facts in these cases was because of code base size, which again I may be mistaken about. No it's because it has grown organically, gets very little attention due to being principally community maintained and it not always being my highest priority. That should have been clear in the bugs Consistency is a goal, I just disagree with your concept of always return a value. Paul -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to
Re: [Puppet Users] Dependencies between custom facts
On 20 November 2010 16:42, Nigel Kersten ni...@puppetlabs.com wrote:
On Fri, Nov 19, 2010 at 12:56 PM, Steve Atwell satw...@google.com wrote:
I need to write a custom fact that depends on the value of another
custom fact in a different file. For example:
# foo.rb
Facter.add(foo) do
setcode do
[...]
end
end
# bar.rb
Facter.add(bar) do
setcode do
if (Facter.value(foo) == option1) then
[...]
else
[...]
end
end
end
Do I need to do anything to ensure that the foo fact is added before
the bar fact's block is evaluated? Or does puppet load all facts
before evaluating any of them?
Hi Steve, this will do the right thing, you don't have to ensure foo
is added first.
I'm not sure this is true in all cases, although quickly testing with
a fact/filename mismatch this does work.
It used to be in some cases you may have to force a loadfacts as mentioned in
http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts
Testing using irb shows the issue using a facts dir containing:
https://gist.github.com/714987
FACTERLIB=$(pwd)/facts irbirb(main):001:0 require 'facter'
= true
irb(main):002:0 Facter.value('bar')
= default
Paul
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on dropping 0.24.x client support in Puppet 2.7?
On Nov 24, 2010, at 3:50 PM, Nigel Kersten wrote: I mentioned this in an earlier thread, but here's a dedicated one. We made a big change between 0.24.x and 0.25.x where we moved from XMLRPC to REST. How do people feel about us dropping all XMLRPC support from 2.7.x, such that it only supported Puppet clients 0.25.x and higher? I don't need it, but at the very least, I think that doing that before Debian stable picks up 0.25.x is probably a terrible idea. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
