On 2010-06-11 21:20, Christopher Johnston wrote:
Thomas I don't see your GIT repo, looks to be offline.
I don't see any problems when I check now. A git clone of
http://www.nsc.liu.se/~bellman/nsc-puppet-utils.git works
fine for me. (Note, however, that you can't point a normal
web browser
I went to download this and it returned a 404. Is it still available somewhere?
-- cwebber
On Jun 4, 2010, at 4:59 PM, Marcus, Allan B wrote:
Here's a white paper you may be interested in.
The Los Alamos National Laboratory (LANL) had a need for central
configuration management of
You can find it here: http://is.gd/cOYhE
Cheers--
Charles
On Mon, Jun 14, 2010 at 10:43 AM, Christopher Webber
kgbbelm...@gmail.comwrote:
I went to download this and it returned a 404. Is it still available
somewhere?
-- cwebber
On Jun 4, 2010, at 4:59 PM, Marcus, Allan B wrote:
Hi dbs,
Hi Matthew,
Thanks a lot for your detailed answers!
Jens
On Jun 14, 3:39 pm, Matthew Marlowe m...@deploylinux.net wrote:
Not at all, Puppet with vmware guest platforms is fantastic.
+1
More to the point, puppet seems best at allowing rapid scale out of
applications via
I've got a generic user java that owns Java applications. Due to
circumstances beyond my control, I cannot dictate a change here, so I need
to make Puppet work with the infrastructure on hand. The big problem,
though, is that java's home directory varies with the application that's
being run.
There are a bunch of workarounds for this though.
A lot of the time you can get away with just a shell provider and type
for manifest validation, as the client will get the right one synced
down for use in actual resource application.
I thought I understood what you were suggesting, but
I'm getting this on my client:
Jun 14 15:21:26 s_...@app09.fr.xxx.com puppetd[24751]: Could not
retrieve catalog: stack level too deep on node app09.fr.twofish.com
Jun 14 15:21:26 s_...@app09.fr.xxx.com puppetd[24751]: Not using cache
on failed catalog
Since running puppetd in debug gives no
On Jun 14, 1:14 pm, Brian Gallew g...@gallew.org wrote:
class jboss {
include users
User[java]{home = /home/app1
realize(User[java])}
where java is declared in
class users {
@user{java: uid=500, gid=501}
}
Brian,
I'm still in .24.8 land, so some of this is WAG.
For your stated
On Mon, Jun 14, 2010 at 2:36 PM, Ben Beuchler ins...@gmail.com wrote:
There are a bunch of workarounds for this though.
A lot of the time you can get away with just a shell provider and type
for manifest validation, as the client will get the right one synced
down for use in actual resource
On Jun 12, 1:09 pm, Gabriel Filion lelu...@gmail.com wrote:
I tested giving a list of strings to the hostgroups attribute to the
nagios_host resource but it only considers the first element of the list.
Something like this?:
nagios_host {
$fqdn:
address = $ipaddress,
hostgroups = [group1,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In a word... What the hell? This was previously working and I'm at a
loss as to why including ONE class in my external node manifest is
yielding a stack too deep error.
I doubt that this is related to your manifests. Can you run your server
and
Thanks. I'll try that when I get in to the office tomorrow.
On Mon, Jun 14, 2010 at 4:00 PM, donavan dona...@desinc.net wrote:
On Jun 14, 1:14 pm, Brian Gallew g...@gallew.org wrote:
class jboss {
include users
User[java]{home = /home/app1
realize(User[java])}
where java is
Peter Meier wrote:
In a word... What the hell? This was previously working and I'm at a
loss as to why including ONE class in my external node manifest is
yielding a stack too deep error.
I doubt that this is related to your manifests. Can you run your server
and client with --verbose and
13 matches
Mail list logo
