[Puppet Users] Re: [0.25.5] Default provider
Hi Patrick, On Oct 12, 10:34 pm, Patrick kc7...@gmail.com wrote: I think this means the plugin(the .rb files) are getting found or aren't all getting found. What's the complete local path to mysql_database.rb? Mine would be in: /etc/puppet/modules/whatever/lib/puppet/type/mysql_database.rb /etc/puppet/modules/whatever/lib/puppet/type/provider/mysql_database/mysql_ database.rb (Note that those are two different files.) I've got two different files too: /srv/puppet/generic/mysql/lib/puppet/type/mysql_database.rb /srv/puppet/generic/mysql/lib/puppet/provider/mysql_database/mysql.rb And I've noticed they get copied to the client, because they're in / var/lib/puppet/lib/puppet. I'm a bit at a loss... Any more things I should check? -- Kind regards, Tim -- 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] [0.25.5] Default provider
Hi all, To start, using puppet 0.25.5 on Debian Lenny with Ruby 1.8.7.72-3lenny1. I'm giving ruby a shot and am trying to build my own types for several applications and modify available types found on the 'net for our usage. However, I keep running into problems with the default provider it selects. Is there a document somewhere that describes how the default provider is selected? I am currently modifying the mysql types from the camptocamp repo[0] and trying to get it to work on Debian. I only modified the command so it would include --defaults-file=/etc/ mysql/debian.cnf. But when I try to use the type, I get: err: Could not run Puppet configuration client: Could not find a default provider for mysql_database So I tried adding the line: defaultfor :operatingsystem = :debian To the providers. But I'm still getting the message the it cannot find the default provider. I've been searching online for documentation on how to modify the type so it would know which provider to select, but although there are a lot of types findable, it's very hard to find specific documentation about the API used in types. Unless I'm missing something, then please point me to this API! Otherwise, I'd appreciate any clues on why my server cannot find the default provider. It only has this problem with types I added to modules. I'm a bit at a loss. [0] http://github.com/camptocamp/puppet-mysql/tree/master/lib/puppet -- Kind regards, Tim (tim|mac on irc) -- 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: Augeas in puppet behaves differently than augtool?
Hi Patrick, On 20 mei, 23:11, Patrick kc7...@gmail.com wrote: That's strange. Can you post a copy of the cron-apt config file? I'd like to play around with it and see if I get the same problem. I can, but it's so simple, I'm not even going to bother :) The default config file is everything commented out. That's it. So a file full of lines starting with # :) I made a lens that just uses the default Shellvars.lns without modifications except for the path. -- Kind regards, Tim -- 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: Augeas in puppet behaves differently than augtool?
Hi all, To expand on this, I tried it from the irb: t...@puppet-test.db:~/augeas/lenses$ sudo irb irb(main):001:0 require 'augeas' = true irb(main):002:0 Augeas::open do |aug| irb(main):003:1* aug.set(/files/etc/cron-apt/config/ MAILON,upgrade) irb(main):004:1 unless aug.save irb(main):005:2 raise IOError, Failed to save changes irb(main):006:2 end irb(main):007:1 end = nil irb(main):008:0 But the puppet recipe still goes wrong. Any ideas? -- Kind regards, Tim -- 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: Augeas in puppet behaves differently than augtool?
Hi all, Okay, I found it, but I cannot explain what's happening here. Hope someone else can. I was adding a load_patch with value /usr/local/share/augeas/lenses. When I add that, I get the error. If I leave it out, it works. However, I have no idea how Augeas knows that it should be searching / usr/local/share/augeas/lenses. For the record, load_path seemed to work as expected in 0.25.4. Not sure what changed it. -- Kind regards, Tim -- 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: Augeas in puppet behaves differently than augtool?
Hi all, Finally found my problem. Apparantly, the default shellvars.aug lens already includes the config to make it apply to /etc/cron-apt/config. When I added my cronapt.aug custom lens, there was a clash of two lenses telling augeas they were applicable on the same file. So, PEBKAC. Apologies for the noise. -- Kind regards, Tim -- 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] Augeas in puppet behaves differently than augtool?
Hi all,
I'm trying to do fairly simple stuff with augeas, like:
augeas { cronapt - mailon:
context = /files/etc/cron-apt/config,
changes = set MAILON upgrade,
onlyif = match MAILON != ['upgrade'],
}
This works if I try it from the commandline:
t...@puppet-test.db:~$ sudo augtool
augtool set /files/etc/cron-apt/config/MAILON update
augtool save
Saved 1 file(s)
augtool
However, when I try to do this from puppet, the whole files get
emptied out, only the one expected line get added (MAILON=upgrade) and
puppet reports and error:
debug: Augeas[dummy - cron-apt change mailon](provider=augeas):
Opening augeas with root /, lens path /usr/local/share/augeas/lenses:/
usr/share/augeas/lenses/dist, flags 0
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Augeas
version 0.7.0 is installed
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Will
attempt to save and only run if files changed
debug: Augeas[dummy - cron-apt change mailon](provider=augeas):
sending command 'set' with params [/files/etc/cron-apt/config/
MAILON, upgrade]
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Files
changed, should execute
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Closed
the augeas connection
debug: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron-
apt change mailon]/Augeas[dummy - cron-apt change mailon]: Changing
returns
debug: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron-
apt change mailon]/Augeas[dummy - cron-apt change mailon]: 1 change(s)
debug: Augeas[dummy - cron-apt change mailon](provider=augeas):
Opening augeas with root /, lens path /usr/local/share/augeas/lenses:/
usr/share/augeas/lenses/dist, flags 0
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Augeas
version 0.7.0 is installed
debug: Augeas[dummy - cron-apt change mailon](provider=augeas):
sending command 'set' with params [/files/etc/cron-apt/config/
MAILON, upgrade]
debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Closed
the augeas connection
err: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron-
apt change mailon]/Augeas[dummy - cron-apt change mailon]/returns:
change from need_to_run to 0 failed: Save failed with return code
false
notice: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron-
apt change mailon]/Line[Augeas change tracking for 'dummy - cron-apt
change mailon']/Exec[line Augeas change tracking for 'dummy - cron-apt
change mailon']: Dependency augeas[dummy - cron-apt change mailon] has
1 failures
warning: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy -
cron-apt change mailon]/Line[Augeas change tracking for 'dummy - cron-
apt change mailon']/Exec[line Augeas change tracking for 'dummy - cron-
apt change mailon']: Skipping because of failed dependencies
Is anyone able to shed some light on the issue? This is puppetmasterd
and puppet 0.25.5rc3, by the way. Using libaugeas-ruby1.8
0.3.0-1~bpo50+1 on Debian Lenny.
--
Kind regards,
Tim
--
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: Augeas in puppet behaves differently than augtool?
On 20 mei, 17:26, Patrick kc7...@gmail.com wrote: What are you trying to do with the onlyif? If that works in augtool, and that's what you want, just remove the onlyif. Without the onlyif, I'm still getting the error: debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Opening augeas with root /, lens path /usr/local/share/augeas/lenses:/ usr/share/augeas/lenses/dist, flags 0 debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Augeas version 0.7.0 is installed debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Will attempt to save and only run if files changed debug: Augeas[dummy - cron-apt change mailon](provider=augeas): sending command 'set' with params [/files/etc/cron-apt/config/ MAILON, upgrade] debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Files changed, should execute debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Closed the augeas connection debug: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron- apt change mailon]/Augeas[dummy - cron-apt change mailon]: Changing returns debug: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron- apt change mailon]/Augeas[dummy - cron-apt change mailon]: 1 change(s) debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Opening augeas with root /, lens path /usr/local/share/augeas/lenses:/ usr/share/augeas/lenses/dist, flags 0 debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Augeas version 0.7.0 is installed debug: Augeas[dummy - cron-apt change mailon](provider=augeas): sending command 'set' with params [/files/etc/cron-apt/config/ MAILON, upgrade] debug: Augeas[dummy - cron-apt change mailon](provider=augeas): Closed the augeas connection err: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron- apt change mailon]/Augeas[dummy - cron-apt change mailon]/returns: change from need_to_run to 0 failed: Save failed with return code false notice: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron- apt change mailon]/Line[Augeas change tracking for 'dummy - cron-apt change mailon']/Exec[line Augeas change tracking for 'dummy - cron-apt change mailon']: Dependency augeas[dummy - cron-apt change mailon] has 1 failures warning: //kbp_debian/Cronapt::Config[dummy]/Augeas::Apply[dummy - cron-apt change mailon]/Line[Augeas change tracking for 'dummy - cron- apt change mailon']/Exec[line Augeas change tracking for 'dummy - cron- apt change mailon']: Skipping because of failed dependencies I thought I needed the onlyif to prevent it from applying every run. -- Kind regards, Tim -- 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: hard to define
Hi Marcus,
On 16 mrt, 14:26, Marcus Moeller mmoel...@econet.ch wrote:
First of all I would like to know if it's possible to use variables
within the define statement, e.g.:
define $module_name::preseed_package
This would make the define much more flexible as I could then just
copy it over to the other modules if necessary.
Not directly, although I wrote about a way to create the same idea a
few months ago:
http://groups.google.com/group/puppet-users/browse_thread/thread/c37707bcedb2d0bd
I've been using this extensively and it seems to work just fine.
I wonder what's the best way to create this directory? Within the
init.pp of the specific module, e.g ?.:
I'd use the following:
if ! defined(File[/var/local/preseed]) {
file { /var/local/preseed:
owner = root, group = root, mode = 755,
ensure = directory,
}
}
Because ordering is not an issue here.
Hope this helps!
--
Kind regards,
Tim
--
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: How to conditionally include classes based on environment?
Hi there, On 23 feb, 10:19, ascodemus ascode...@gmail.com wrote: Q1) How can I include a class for a node depending on the status of the managed node? Example is it possible to do include a class based on existence of a file e.g. “/root/puppet/dl580” on the managed puppet- client node like: snip Nope, that's not possible, since the manifests are compiled on the puppetmaster and it therefore has no access to the filesystem of your client at that time. The usual solution for this is to create a fact for this. There are some examples here: http://reductivelabs.com/trac/puppet/wiki/AddingFacts Q2) Is it possible to pass information (e.g. string) i.e. an output of an “exec” execution on a puppet-client and store this information into a puppet variable? Take a look at the generate function: http://docs.reductivelabs.com/references/0.25.1rc2/function.html#generate I think that can do what you need. Q3) Well when I’m hacking with the FACTER-variables, I notice that if I’ve included new FACTER-variables within the /etc/init.d/puppet (or sourced from there from another file) this obviously requires puppet restart to make my own FACTERs available – is there any other method to make my own FACTERs available once set without need to restart the puppet client? I don't think adding facter variables to /etc/init.d/puppet is common practice, really. I'd prefer to create an actual fact. This can usually be done by very simple snippets of code, as seen on the page I pointed to as answer to your Q1. Hope this helps! -- Kind regards, Tim -- 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: Proper Augeas usage
Hi David,
Thanks for your reply, it cleared up some things!
On 22 feb, 20:35, David Lutterkort lut...@redhat.com wrote:
You want to restrict when to make those changes with the onlyif
paramater, something like
augeas { ...:
context = ...
changes = ...
onlyif = match *[ Pin = 'release' and Package = 'augeas-lenses']
size == 0
}
Ah, so I was wrong in thinking that augeas would treat these kind of
config blocks as one entity with different variables. That makes the
augeas type a little less useful than I thought, but I probably
should've figured that out when I was building the lenses I needed.
There's simply no $name equivalent in augeas. Thanks for making that
clear.
You'd need to add another augeas resource to cover that case, something
like
augeas { ...:
context = /files/etc/apt/preferences[Pin = 'release' and Package
= 'augeas-lenses'],
changes = set Pin-Priority 900,
onlyif = match * size == 0
}
Ok, so I'd be better off creating a type that adds these different
kinds of augeas resources with different checks for each variable part
of the resource.
If there's no augeas-
lenses definition available, it *segfaults*:
/usr/lib/ruby/1.8/augeas.rb:48: [BUG] Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
Aborted
When that happens, is libaugeas0 installed ?
Yes, very sure it is, because my augeas resource depends on
Package[libaugeas-ruby1.8], which depends on libaugeas0.
Thanks for the tips! I'll see what I can make of it. Even though it
requires more code, I still think augeas is a cleaner solution than
concatenated files (although I love your concatenated_file module,
DavidS!).
--
Kind regards,
Tim
--
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: Magazine article comparing CPU usage of Puppet vs. Cfengine
On 23 feb, 10:02, tobyriddell toby.ridd...@gmail.com wrote: From the results in the article, Puppet required between 10x and 56x more CPU seconds. Out of curiosity, which part of puppet is causing this load? If it's the puppetmaster, well then, that shouldn't be a big problem. I'd recommend a dedicated puppetmaster in most setups anyway. Or when puppet is actually applying a whole manifest instead of just checking if things are set correctly? I've looked at our trending and I don't see any noticeable additional load on the machines, at least. Unless of course I'm rebuilding the entire server. But I don't care about puppet load at such times. A little nuance for us non-subscribers to Usenix would be welcome :) -- Kind regards, Tim -- 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] Proper Augeas usage
Hi all,
I'm trying to work with augeas to add pinnings to my /etc/apt/
preferences file. But I'm not getting my head around it. If I do the
simplest I can think of:
augeas { Apt/preferences pinnings for augeas-lenses.:
context = /files/etc/apt/preferences,
changes = [set 00/Explanation 'We need these from
backports.',
set 00/Package augeas-lenses,
set 00/Pin release,
set 00/Pin/a lenny-backports,
set 00/Pin-Priority 999],
}
it adds the definition to the bottom of the file each time. If I
change the context into
context = match /files/etc/apt/preferences/*/Package augeas-
lenses,
it only works if there's already an augeas-lenses definition
available. In which working is a large word, because if the current
Pin-Priority is 900, it doesn't set it to 999. If there's no augeas-
lenses definition available, it *segfaults*:
/usr/lib/ruby/1.8/augeas.rb:48: [BUG] Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
Aborted
So I'm at a bit of a loss. What am I doing wrong and how should I be
handling these kind of situations?
For reference, I'm using augeas stuff from lenny-backports:
augeas-lenses 0.7.0-1~bpo50+1
augeas-tools 0.7.0-1~bpo50+1
libaugeas-ruby1.8 0.3.0-1~bpo50+1
libaugeas00.7.0-1~bpo50+1
--
Kind regards,
Tim
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Checking availability of exported resource
Hi all, Is there any way to check if a certain exported resource already exist, without collecting and realizing them first? I'd like to automatically create a @@nagios_servicegroup when it's mentioned in a define that creates my service checks. Simply doing if defined(Nagios_servicegroup['newname']) doesn't work, since it's not instantiated on the node. Any idea how to do this? Or isn't this a problem anyway, can I exported resources with the same name from different hosts? (Haven't tried that yet, just thought about it while typing.) -- Kind regards, Tim -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Checking availability of exported resource
Hi all, Ignore this, it's not needed. Should've tested it before I posted! On 16 feb, 12:30, Tim Stoop tim.st...@gmail.com wrote: Hi all, Is there any way to check if a certain exported resource already exist, without collecting and realizing them first? I'd like to automatically create a @@nagios_servicegroup when it's mentioned in a define that creates my service checks. Simply doing if defined(Nagios_servicegroup['newname']) doesn't work, since it's not instantiated on the node. Any idea how to do this? Or isn't this a problem anyway, can I exported resources with the same name from different hosts? (Haven't tried that yet, just thought about it while typing.) -- Kind regards, Tim -- 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: Can I get a list of affected hosts of a class change?
Hi Jim,
On 16 feb, 04:04, number4 lousche...@yahoo.com wrote:
I was wondering if anyone has
a
good way to find all the classes and/or hosts that are affected by a
change
in a given module.
Not sure if you consider this a 'good' way, but I have the following
function:
define register_class {
@@line { $fqdn uses the class $name:
file = /var/cache/puppet/classes/$name,
line = $fqdn,
tag = class-used-by,
}
}
And every class starts with:
class MyClass {
register_class { MyClass:; }
.. do stuff
}
On my data host, I do:
Line | tag == class-used-by |
Et voila, a file per class that describes which hosts use them. I
clean out the /var/cache/puppet directory every day via a cronjob,
just to keep the data more or less fresh, since if you remove a class
from a node, it doesn't get removed from the file.
Again, maybe someone else has a better solution, but this works for
me.
--
Kind regards,
Tim
--
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: Puppet 0.25.4 and Facter 1.5.7 debs available in debian unstable.
Hey,
On 10 feb, 01:57, Nigel Kersten nig...@google.com wrote:
$ rmadison -u debian {puppet,facter} | grep unstable
puppet | 0.25.4-1 | unstable | source, all
facter | 1.5.7-1 | unstable | source, all
I've been running these for a little while now (compiled from git) and
I just upgraded to the version in unstable on my Lenny machine.
However, I'm noticing some strangeness. I'm use storeconfigs in MySQL
and have rails and libmysql-ruby installed. It looks like the
puppetmaster is opening a new connection with the database every time
a client connects and leaves old connections open. This tends to pile
up, so I had reached my max_connections within a day.
Is this a Lenny problem, a problem in the package or a puppetmaster
problem? Also, is anyone else seeing this?
Please let me know if there's anything I can do to assist in debugging
this.
--
Kind regards,
Tim
--
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: How to disable file checksums?
Hi Brice, Thanks for your suggestion, but alas, it seems to default to mtime 'checksum' then. On 8 feb, 22:43, Brice Figureau brice-pup...@daysofwonder.com wrote: In 0.24.x I know it was possible to: checksum = undef Honestly, knowing how other parts work, I'd expect it to default to mtime checksum in 0.24.x too... Thanks for the suggestion, though. Any other thoughts? -- Kind regards, Tim -- 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: How to disable file checksums?
Hi Dan,
On 9 feb, 17:40, Dan Bode d...@reductivelabs.com wrote:
I am still missing the exact use case for this though.
I made a ticket out of it, #3170. If I have something like:
file { /tmp: mode = 1777 }
Every puppetd run gives me something like:
notice: //kbp_debian/File[/tmp]/checksum: checksum changed '{mtime}Mon
Feb 08 22:50:00 +0100 2010' to '{mtime}Tue Feb 09 21:11:06 +0100 2010'
If you have this for a lot of resources, it kind of clutters :) Since
I do not need checksumming for these resources, it would be nice if I
could simply disable checksumming.
--
Kind regards,
Tim
--
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] How to disable file checksums?
Hi all, The docs seem to indicate that it's possible to disable checksum checking for file resources: The default checksum parameter, *if checksums are enabled*, is md5. But I can't find how to disable them. I vaguely remember something like 'nosum', but it seems that's not valid. Any hints? -- Kind regards, Tim -- 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: How to disable file checksums?
Hi Dan, Thanks for the reply! On 8 feb, 21:58, Dan Bode d...@reductivelabs.com wrote: checksum attribute of the file resource. I dont know of a way to disable this, but you can pick something faster based on timestamps. I don't want faster, I want no checksumming :) We use puppet to set some sane defaults (like mode 1777 on /tmp) and I don't want to get messages about the checksum of /tmp changing every time. -- Kind regards, Tim -- 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] Wrapping built-in types with defined types, how to do it?
Hi all,
Due to some automation we want to set in place, I'd like to write my
own wrapper around several built-in types. Is there an easy way to
tell a defined type to allow all options that another type allows and
then some? What I'm looking for, really, is some equivalent to (sorry
Luke) Python's **kw argument. Is that currently possible? If not, how
would you view a feature request to that end?
If I need to name all options that my new defined type allows, so it
can pass them all on to the built-in type I'm writing the wrapper for,
what's the best way to define them in the definition? False or undef?
So like:
mypkg ($ensure = installed, $responsefile = false) { ... do stuff,
including calling package { $name: ensure = $ensure, responsefile =
$responsefile } }
Or:
mypkg ($ensure = installed, $responsefile = undef) { ... do stuff,
including calling package { $name: ensure = $ensure, responsefile =
$responsefile } }
I want to recreate package{}'s behaviour as closely as possible, of
course.
Thanks for any sort of advice in this!
--
Kind regards,
Tim Stoop (tim|macbook or tim|imac on IRC)
--
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] Generic modules to mask actual application-centric modules
Hi all, I've spent some time with Volcane today to try to solve the problem. It might have been solved and posted here, but I thought I'd share anyway, since I seem to remember other people asking for this. The problem -- When defining resources like websites, I do not want to know which webserver we're running. Defining sites should be webserver-agnostic. If I decide to switch from Apache to nginx, this should only impact specific Apache/nginx settings, not the creation of websites. (Consider a setup with 1000s of sites defined via puppet.) How we handled this until now -- We didn't, we decided to stay away from anything not Apache, except for some servers where we thought nginx was a better match. This is not a very practical situation, since we find that more and more reasons appear to switch to another webserver. Besides, this should be easy anyway. How I'm going to solve it from now on -- Using the search function from within a generic http class. The generic http includes a ::webserver class that it finds within the namespace that's defined in the search function. From there on, it calls predetermined functions to do what it needs to do. Switching from Apache to nginx amounts to changing one variable[0]. Please see the proof of concept I pasted here: http://pastie.org/737661 I hope this helps someone! Thanks again, Volcane, for your help with this. [0] Well, not quite, you'll have to make sure you disable the old webserver and stuff, but that can all be handled by puppet too, if you build the modules in a smart way. -- Kind regards, Tim (tim|imac or tim|macbook on IRC) -- 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.
