[Puppet Users] Puppet load 100%
Hello, maybe this is a bug. But if puppetd cannot find host puppet ( default hostname ) it will try to get certificate and load goes automatically to 100%. I am starting puppetd with parameter -w 0 and this is in my syslog: Feb 16 10:49:54 myhostname puppetd[2853]: Could not find server puppet: getaddrinfo: Name or service not known Feb 16 10:49:54 myhostname puppetd[2853]: Could not request certificate: Certificate retrieval failed: Could not find server puppet Does anybody know how to get rid of this? Thank you for your answers. Andrej --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet load 100%
Your puppet client is tryng to contact a server named "puppet". Find out where it is using puppet as the server name in the configs and replace it with the hostname of your puppetmaster and you should be set. -Jason On Feb 16, 2009, at 3:08 AM, Andy wrote: > > Hello, > > maybe this is a bug. But if puppetd cannot find host puppet ( default > hostname ) it will try to get certificate and load goes automatically > to 100%. I am starting puppetd with parameter -w 0 and this is in my > syslog: > > Feb 16 10:49:54 myhostname puppetd[2853]: Could not find server > puppet: getaddrinfo: Name or service not known > Feb 16 10:49:54 myhostname puppetd[2853]: Could not request > certificate: Certificate retrieval failed: Could not find server > puppet > > Does anybody know how to get rid of this? > > Thank you for your answers. > > Andrej > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Could not find dependency Exec[...]
Hi all,
I've got a problem and I can't figure out why. Here is the error
message
warning: Not using cache on failed catalog
warning: Configuration could not be instantiated: Could not find
dependency Exec[modprobebonding] for File[/etc/sysconfig/network-
scripts/ifcfg-bond0] at /file/xy.
And below is my setting.
Any idea are welcome.
Cheers,
Martial
class network {
# Setup a bond interface
define bond(
$ipaddress,
$netmask,
$network,
$ensure,
$options) {
$interface = $name
$onboot = $ensure ? {
up => "yes",
down => "no"
}
file { "/etc/sysconfig/network-scripts/ifcfg-
$interface":
owner=> root,
group=> root,
mode=> 644,
content => template("network/sysconfig/network-
scripts/bond-ifcfg.$interface.erb"),
ensure => present,
alias => "ifcfg-$interface",
require => Exec["modprobebonding"]
}
}
define interface(
...
...
{
exec { "modprobe bonding":
cwd => "/var/tmp",
path=> "/usr/bin:/usr/sbin:/bin:/sbin",
onlyif => "lsmod |grep bonding",
alias=> modprobebonding
}
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Wellington's puppet meeting?
Hi there, Does any one present on this list live around wellington NZ? Martial --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Could not find dependency Exec[...]
On Mon, Feb 16, 2009 at 3:31 PM, babatoko wrote:
> Could not find dependency Exec[modprobebonding]
> ...
> exec { "modprobe bonding":
You'll want to avoid using spaces as the names/titles of classes,
files, exec statements, etc. etc.
--
Jake Paulus
jakepau...@gmail.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Schedule oddity
And nope, it doesn't: Feb 17 04:29:03 wrath puppetd[20155]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 04:46:51 wrath puppetd[20449]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 06:26:32 wrath puppetd[21618]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Feb 17 09:15:18 wrath puppetd[23987]: [ID 702911 daemon.warning] Configuration could not be instantiated: Could not find schedule nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 Does anyone actually use scheduling in Puppet? Hell, at this point, is anyone other than me even reading this? Matt Matt McLeod wrote: > > This one was my own fault for not noticing the patched source > tarballs. Switched to Ruby 1.8.7-p72 and this goes away. > > Now to see if it helps with the schedule problem. > > Matt McLeod wrote: > > > > In an effort to figure out what might be causing the scheduling > > problem I tried doing a fresh install: > > > > r...@wrath ~# ruby --version > > ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-solaris2.10] > > r...@wrath ~# puppet --version > > 0.24.7 > > r...@wrath ~# facter --version > > 1.5.3 > > r...@wrath ~# uname -a > > SunOS wrath 5.10 Generic_138889-03 i86pc i386 i86pc > > > > And now there's a new and exciting problem. It seems that puppetd > > is no longer able to execute external commands (e.g., svcs, crontab). > > The debug output looks like it's running the right stuff, e.g.: > > > > debug: Puppet::Type::Service::ProviderSmf: Executing '/usr/bin/svcs -l sma' > > wrong number of arguments (2 for 1) > > warning: Service[sma](provider=smf): Could not get status on service sma > > > > But clearly whatever in Ruby is returning this "wrong number of arguments > > (2 for 1)" error is blocking the execution of svcs (and crontab). > > > > The only bright spot is that the schedule issue doesn't *seem* to > > be recurring, but that's not very useful if puppetd can't actually > > run anything. > > > > I was previously using: > > > > ruby 1.8.7 (2008-04-26 patchlevel 5000) [i386-solaris2.10] > > > > which was the current pre-release when I originally did the Puppet > > installs. I used that because the stable release broke Puppet in > > some other exciting way I can no longer recall... > > > > Matt > > > > -- > > * Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ * > > --- People can do the work, so machines have time to think --- > > > > > > > -- > * Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ * > --- People can do the work, so machines have time to think --- > > > -- * Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ * --- People can do the work, so machines have time to think --- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Question on recursively managing permissions
I've got a directory (a webapps directory for a Java app server) that
I'd like to ensure all of the contents are world readable. As puppet
is not really suitable for application deployment, I'd like to manage
the permissions of this directory and all of it's contents. Something
like:
find . -type d -exec chmod 755 \{\}
find . -type f -exec chmod 644 \{\}
Is there an easy way to accomplish this in puppet, or am I barking up
the wrong tree?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] ANNOUNCE: Facter 1.5.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new Facter release is available - 1.5.4. This is a maintenance release that will be the last of the 1.5.x branch. It combines a number of fixes, a new fact - physicalprocessorcount, and support for flavours of Oracle Linux. Full list of changes include: * Fixed #1966 - Added physicalprocessorcount fact * Fixed #1761 - changes to Solaris facts: operatingsystemrelease == kernel release (which is uname -r) kernelrelease == uname -r kernelversion == uname -v * Added support for Oracle VM Server to operatingsystem and operatingsystemrelease * Added support for Oracle Enterprise Linux to operatingsystem and operatingsystemrelease * Fixed #1927 - Failing facts don't kill Facter * Fixed #1850 - Facter updates for Ruby 1.9 * Fixed #1926 - IPAddr to_s issue * Fixed Ubuntu operatingsystem identification * Fixed generic uptime fact * Fixed #1924 - Fixed lo / lo:0 local interface matching The most critical behavioural change is now a failing fact shouldn't kill Facter but rather return an error message and generate nil. You can get the new release in a tarball or Gem at: http://reductivelabs.com/downloads/facter/facter-1.5.4.tgz http://reductivelabs.com/downloads/gems/facter-1.5.4.gem Or at: http://projects.reductivelabs.com/projects/facter/files http://rubyforge.org/projects/facter/ Please report any issues to: http://projects.reductivelabs.com/projects/facter/issues/new The next release of Facter (as yet unnumbered) will be a significant refactor (excuse the alliterative almost pun). You can read about some of the details in recent posts on the puppet-dev list. Thanks James Turnbull -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmaGgcACgkQ9hTGvAxC30AW9QCfQ83zTZ2LHEqAFecWX33S0O2M JJQAn1boiHVX3izcpzRuvQIKDULkJ/0P =MyNi -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: puppetmaster error
On Feb 7, 2009, at 11:35 AM, peter wrote: > > hello, > I installed puppet-server package for centos 5.2. > > when I tried to start it, it now gets the error: > Starting puppetmaster: Certificate retrieval failed: Invalid pattern > install > [FAILED] > > how to fix it? I've never seen or heard of that; I expect if you look on your server, in syslog, you'll see more useful information. Maybe run the server with --trace? -- The great tragedy of Science - the slaying of a beautiful hypothesis by an ugly fact. --Thomas H. Huxley - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: something wrong with mongrel?
On Feb 10, 2009, at 5:34 AM, Arnau Bria wrote: > > Hi all, > > I've followed http://reductivelabs.com/trac/puppet/wiki/UsingMongrel > for configuring my puppet with mongrel. > > Al seems to work fine, except that, after a reinstall of 40 nodes > atone > time, I got many kind of errors like: > > - > err: Could not request certificate: Certificate retrieval failed: .tmp > file already exists for /var/lib/puppet/ssl/ca/serial; Aborting locked > write. Check the .tmp file and delete if appropriate This looks like contention between multiple processes for that serial file, which shouldn't happen very often although is reasonable once and a while. > > - > info: Creating a new certificate request for td029.pic.es > info: Creating a new SSL key > at /var/lib/puppet/ssl/private_keys/td029.pic.es.pem notice: Got > signed > certificate err: Connection timeout calling puppetmaster.getconfig: > execution expired err: Could not retrieve catalog: Connection Timeout > warning: Not using cache on failed catalog Not sure on this one; I've seen it, but usually it's actually a timeout issue. Maybe your server is waiting on a lock for that serial file? -- If you would be a real seeker after truth, it is necessary that at least once in your life you doubt, as far as possible, all things. -- Rene Descartes - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Lock file /var/lib/puppet/state/puppetdlock
On Feb 10, 2009, at 4:25 AM, Keith Edmunds wrote: > > I'm just starting a roll out of Puppet and I'm seeing a problem on > maybe > 25% of client nodes. The symptoms are that the clients stop > updating. In > the Puppetmaster log, I'm seeing things like: > > Feb 9 20:10:23 vs4 puppetmasterd[17942]: Compiled catalog for in > 0.05 seconds > Feb 9 20:40:41 vs4 puppetmasterd[17942]: Compiled catalog for in > 0.05 seconds > Feb 9 21:11:16 vs4 puppetmasterd[17942]: Compiled catalog for in > 1.83 seconds > Feb 9 21:41:37 vs4 puppetmasterd[17942]: Compiled catalog for in > 0.91 seconds > > These are all for the same client; everything appears normal until > 21:41, > then no more checks from the client (it's now 10:17 on Feb 10). > > On the client, I tried running puppetd manually: > > # puppetd -t > notice: Lock file /var/lib/puppet/state/puppetdlock exists; skipping > catalog run > > A look at the lock file: > > # ls -l /var/lib/puppet/state/puppetdlock > -rw-r--r-- 1 root root 5 2009-02-09 22:11 /var/lib/puppet/state/ > puppetdlock > > ...shows that it was probably created at the next run after the last > one > logged on the Puppetmaster (above). > > Looking at the lock file: > > # echo $(cat /var/lib/puppet/state/puppetdlock) > 32400 > # ps -fp 32400 > UIDPID PPID C STIME TTY TIME CMD > root 32400 1 0 Feb06 ?00:01:41 ruby /usr/sbin/ > puppetd -w 5 > > ...shows that the puppetd is still running. > > Why would the lock file be created and not subsequently deleted? > > If it helps, it is likely that the Puppetmaster was very busy at that > time, but even so I would expect the client to deal with that > graciously. > > Maybe related, maybe not: I can't stop puppetd in the usual way: > > # /etc/init.d/puppet stop > Stopping puppet configuration management tool. > # ps -fp 32400 > UIDPID PPID C STIME TTY TIME CMD > root 32400 1 0 Feb06 ?00:01:41 ruby /usr/sbin/ > puppetd -w 5 > > If I 'kill -9' the puppetd process, remove the /var/run/puppetd.pid > file > and remove the lock file, I can restart puppetd and it runs OK for a > while, but eventually the puppetdlock file causes this problem again. > > Versions: 0.24.5-3, the Debian Lenny package compiled for Debian Etch. > > Grateful for any suggestions / pointers / etc. I haven't seen this for absolute ages, so whatever used to cause it is unlikely to be the problem now. Is there maybe a signal being sent to puppetd? If not, any chance you can get a stack trace from the clients?You'd have to leave a client running in the foreground with stdout redirected. Otherwise I've no idea, because you're the first to run into it that I know of. Note that you should be able to run 'puppetd --enable' to remove that stale lock file. -- One of the keys to happiness is a bad memory. -- Rita Mae Brown - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Has anyone tried Puppet under Ruby 1.9?
On Feb 12, 2009, at 4:43 AM, Trevor Vaughan wrote: > > The speed benefits of Ruby 1.9 are amazing overall and I was wondering > if Puppet, as it stands, is deliberately compatible. > > I've tried digging through the mailing lists and might just be missing > it, if so, I apologize for the oversight. josb has provided a 1.9 compatibility patch, but we stupidly have not merged it in yet. It'll be in 0.25, though. -- Be wary of the man who urges an action in which he himself incurs no risk. -- Joaquin Setanti - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Exported resources not exporting?
On Feb 14, 2009, at 8:16 PM, Eric Gerlach wrote: > > I'm having a bit of an odd problem with exported resources. It > seems like if > an resource is already in the stored configs database, then a host > checks in an > exports that resource, then it doesn't get exported. > > Deleting storedconfigs.sqlite seems to fix the problem when the > hosts next > check in. This isn't related to the recent bugs in exported > resources, because > I built new puppet packages from the 0.24.x branch. > > For example: > > Before: > sqlite> select * from resources where restype='Ether'; > 451|00:50:56:b6:61:47|Ether|1|6||46|2009-02-14 14:12:37|2009-02-14 > 14:12:37 > 457|00:50:56:b4:02:94|Ether|3|6||46|2009-02-14 14:25:00|2009-02-14 > 14:25:00 > 460|00:50:56:b4:4c:f6|Ether|2|6||46|2009-02-14 14:32:31|2009-02-14 > 14:32:31 > > > After: > sqlite> select * from resources where restype='Ether'; > 130|00:50:56:b6:61:47|Ether|1|6|t|41|2009-02-14 19:25:02|2009-02-14 > 19:24:59 > 235|00:50:56:b4:4c:f6|Ether|2|6|t|41|2009-02-14 19:25:42|2009-02-14 > 19:25:40 > 244|00:50:56:b6:61:47|Ether|2|2||41|2009-02-14 19:25:42|2009-02-14 > 19:25:40 > 366|00:50:56:b4:02:94|Ether|3|6|t|41|2009-02-14 19:32:56|2009-02-14 > 19:32:54 > 404|00:50:56:b4:02:94|Ether|2|2||41|2009-02-14 19:35:38|2009-02-14 > 19:35:38 > > I know I'm showing a custom type, but it happened with the Host type > as well. > That time, I thought it was something I did, so I didn't capture it. > > Has anyone seen anything like this? Any ideas where I could start > debugging? You're sure you've tried this against the most recent HEAD of 0.24.x? I certainly hope this isn't a different problem, and it sounds just like the same issue. -- A gentleman is a man who can play the accordion but doesn't. --Unknown - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Schedule oddity
On Feb 16, 2009, at 5:39 PM, Matt McLeod wrote: > > And nope, it doesn't: > > Feb 17 04:29:03 wrath puppetd[20155]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 04:46:51 wrath puppetd[20449]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 06:26:32 wrath puppetd[21618]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > Feb 17 09:15:18 wrath puppetd[23987]: [ID 702911 daemon.warning] > Configuration could not be instantiated: Could not find schedule > nightly at /staging/puppet/common/modules/deadly/manifests/init.pp:15 > > Does anyone actually use scheduling in Puppet? Hell, at this point, > is anyone other than me even reading this? /me kind of catches up on list mail... I've not seen this before, and I just verified that finding a schedule shouldn't be at all related to the order in which resources get instantiated on the client or anything silly like that. This is just happening on a single node? I haven't seen this before, but I have to admit that I don't think schedules get used much, so this could be a long-running problem that no one's run into. -- If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you. -- Don Marquis - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Schedule oddity
Luke Kanies wrote:
> I've not seen this before, and I just verified that finding a schedule
> shouldn't be at all related to the order in which resources get
> instantiated on the client or anything silly like that.
>
> This is just happening on a single node?
It's happened on the two nodes I'm testing with, but they're both
running the same Puppet+etc stack.
I've just built a fresh stack for SPARC and am testing that at the
moment. The problem has cropped up there yet but it's only been
running a few hours and it's been intermittent on the first two nodes.
I've just rolled out a much simpler test case:
schedule {testsched:
period=>daily,
range=>"14 - 22",
repeat=>1
}
file{"/tmp/puppet-test.foo":
ensure=>directory,
schedule=>testsched
}
to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
to see how that goes. It'd be just my luck that some oddity in our
Sol10/x86 build environment tickles something in Ruby the wrong way...
Will come back with more info tomorrow once it's been running for
24 hours with the simplified test case.
Matt
--
* Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Question on recursively managing permissions
file {
"/top/level/dir":
owner => user,
group => usergroup,
ensure => directory,
mode => "0664", #whatever
recurse => true;
}
something like that may work
If that doesn't then you should be able to use an exec of your find
commands and onlyif mtime/md5 of the dir tree but that may take a
while.
I'm not near a computer so I can't personally test either of these.
-Jason
On Feb 16, 2009, at 4:13 PM, Jon Stanley wrote:
>
> I've got a directory (a webapps directory for a Java app server) that
> I'd like to ensure all of the contents are world readable. As puppet
> is not really suitable for application deployment, I'd like to manage
> the permissions of this directory and all of it's contents. Something
> like:
>
> find . -type d -exec chmod 755 \{\}
> find . -type f -exec chmod 644 \{\}
>
> Is there an easy way to accomplish this in puppet, or am I barking up
> the wrong tree?
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Schedule oddity
I Have scheduling working quite well for many different OS's.
I'm using something like that ina class inhertied by all machines.
class host-base::schedule {
# maintance schedule, run only once a day, between 2-4
schedule { maint:
range => "2 - 4",
period => daily,
repeat => 1
}
}
do you the define the schedule inside a class or a node definition?
cheers,
Ohad
On Tue, Feb 17, 2009 at 12:51 PM, Matt McLeod wrote:
>
> Luke Kanies wrote:
> > I've not seen this before, and I just verified that finding a schedule
> > shouldn't be at all related to the order in which resources get
> > instantiated on the client or anything silly like that.
> >
> > This is just happening on a single node?
>
> It's happened on the two nodes I'm testing with, but they're both
> running the same Puppet+etc stack.
>
> I've just built a fresh stack for SPARC and am testing that at the
> moment. The problem has cropped up there yet but it's only been
> running a few hours and it's been intermittent on the first two nodes.
>
> I've just rolled out a much simpler test case:
>
>schedule {testsched:
>period=>daily,
>range=>"14 - 22",
>repeat=>1
>}
>file{"/tmp/puppet-test.foo":
>ensure=>directory,
>schedule=>testsched
>}
>
> to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
> to see how that goes. It'd be just my luck that some oddity in our
> Sol10/x86 build environment tickles something in Ruby the wrong way...
>
> Will come back with more info tomorrow once it's been running for
> 24 hours with the simplified test case.
>
> Matt
>
> --
> * Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ *
> --- People can do the work, so machines have time to think ---
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Schedule oddity
The one that's failing is defined in a module which is included
by the node definition. It is, essentially:
schedule {blah: ...}
define {blahpkg: ..., schedule=>blah}
class blahclass {
blahpkg{somepackage}
}
in the module 'blahclass' and then in the node defintion file:
node somenode inherits stuff {
include blahclass
}
So the schedule is defined outside the class, and is referred to
by the define called by the class, and all specified in the same
module's init.pp.
I posted the full version earlier.
The simplified test-case which hasn't failed yet but it's only been
a few hours is defined directly in the node definition. If that
works I'll try moving it into a module and see what happens then.
Matt
Ohad Levy wrote:
> I Have scheduling working quite well for many different OS's.
>
> I'm using something like that ina class inhertied by all machines.
> class host-base::schedule {
> # maintance schedule, run only once a day, between 2-4
> schedule { maint:
> range => "2 - 4",
> period => daily,
> repeat => 1
> }
> }
>
> do you the define the schedule inside a class or a node definition?
>
> cheers,
> Ohad
>
> On Tue, Feb 17, 2009 at 12:51 PM, Matt McLeod wrote:
>
> >
> > Luke Kanies wrote:
> > > I've not seen this before, and I just verified that finding a schedule
> > > shouldn't be at all related to the order in which resources get
> > > instantiated on the client or anything silly like that.
> > >
> > > This is just happening on a single node?
> >
> > It's happened on the two nodes I'm testing with, but they're both
> > running the same Puppet+etc stack.
> >
> > I've just built a fresh stack for SPARC and am testing that at the
> > moment. The problem has cropped up there yet but it's only been
> > running a few hours and it's been intermittent on the first two nodes.
> >
> > I've just rolled out a much simpler test case:
> >
> >schedule {testsched:
> >period=>daily,
> >range=>"14 - 22",
> >repeat=>1
> >}
> >file{"/tmp/puppet-test.foo":
> >ensure=>directory,
> >schedule=>testsched
> >}
> >
> > to a couple of machines (Solaris 10/x86, Solaris 8/SPARC, CentOS)
> > to see how that goes. It'd be just my luck that some oddity in our
> > Sol10/x86 build environment tickles something in Ruby the wrong way...
> >
> > Will come back with more info tomorrow once it's been running for
> > 24 hours with the simplified test case.
> >
> > Matt
> >
> > --
> > * Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ *
> > --- People can do the work, so machines have time to think ---
> >
> > >
> >
>
> >
--
* Matt McLeod | mail: m...@boggle.org | blog: http://abortrephrase.com/ *
--- People can do the work, so machines have time to think ---
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
