Oooh, shiny. Hadn't seen that one before. Thanks Dirk.
Of course, it's also available from the more canonical
https://forge.puppetlabs.com/basti1302/wait_for
Cheers
On 06/04/2014 08:19 AM, Dirk Heinrichs wrote:
>> Short of writing a new function called "go for a cup of tea" feeding
>> it the req
Did you try using the package resource over the exec resource? I install .NET
4.0 using the package resource and it works just fine on Windows 2008 R2
Enterprise & Standard, though I haven’t tried on Data Center but I’m not sure
how different it would be. I’ve done something similar with .net
Hi,
On 06/02/2014 05:48 PM, mike wrote:
> 1. ¿How to specifying a sudoers file?
from what I understand, the Hiera data you posted would actually use
/etc/sudoers.d/user. The resource title defines the file name.
> 2. ¿How to add new group "myGroup"?
The sudo module does not concern itself with
FWIW, I use /var/lib/puppet/state/state.yaml for monitoring wether the
agent is working successfully, and from experience, it will reflect even
the case of "works but uses cached catalogs" as a problem.
HTH,
Felix
On 06/03/2014 09:27 PM, Steve Kilduff wrote:
> Hi, Yes you got it. With puppet agen
Hi!
I try to set a user password. I do :
vagrant@db:~$ sudo puppet apply -e "user { 'martin': name => 'martin',
ensure => 'present', password =>
'$6$salt$RheJLXa4oI89Bob98PelI2w1l7.StNxtasDd0hBJbGUrSahnzsSf3rZ8.CoT9CoTNd/6qyaieI7lunITBZaRP1'}"
Notice: Compiled catalog for db in environment prod
Hi,
Put the user declaration in a file, or use ' instead of " ( then you'll
have to escape all ' )
The problem is that you are using ", so the shell is interpreting $6 and
$salt as empty variables.
Regards
El 04/06/2014 15:31, "Martin Supiot" escribió:
> Hi!
>
> I try to set a user password. I
Hi,
I would like to have mounts entries and mount points created using
create_resources from the same hiera data.
I am thinking to describe directories like this:
---
my::mounts:
/dir1:
device: server1:/share1
options: rw,soft,noatime
owner: user1
mode: 0644
/dir2:
devic
Hi,
On 06/04/2014 03:32 PM, Vadym Chepkov wrote:
> File[ensure=>directory] -> Mount[type=nfs,ensure=>mounted]
>
> Is this possible or I have to maintain two sets of data?
no, that is fine. The 'puppet magic' you are looking for is a defined
type that accepts all the parameters you want to declar
Hi,
I am trying to run shell script through non root user in puppet facts.
Here is my code.
* $cat cis_rhel6_check.rbrequire 'facter'*
*Facter.add("cis_rhel6_check") do setcode do %x[ sh
/tmp/cis_rhel6_check.sh ] endend*
the shell script is in
*drwxrwxrwt. 178 root root tmp*
On Wednesday, June 4, 2014 9:52:44 AM UTC-4, Felix.Frank wrote:
>
> Hi,
>
> On 06/04/2014 03:32 PM, Vadym Chepkov wrote:
> > File[ensure=>directory] -> Mount[type=nfs,ensure=>mounted]
> >
> > Is this possible or I have to maintain two sets of data?
>
> no, that is fine. The 'puppet magic' yo
Vadym,
This is not currently possible (but is a VERY wanted feature going back
years). Most of us just use an Exec.
Trevor
On Wed, Jun 4, 2014 at 11:34 AM, Vadym Chepkov wrote:
>
>
> On Wednesday, June 4, 2014 9:52:44 AM UTC-4, Felix.Frank wrote:
>>
>> Hi,
>>
>> On 06/04/2014 03:32 PM, Vadym
I am trying to write unit tests of my puppet modules. In my
profiles::logstash::install, I disambiguate the call to
/etc/puppet/modules/logstash by using ::logstash in my class definition
like so:
class profiles::logstash::install() {
$ensure = $profiles::logstash::enable ? {true => present,
On 6/4/14, 2:30 PM, Brian Wilkins wrote:
> I am trying to write unit tests of my puppet modules. In my
> profiles::logstash::install, I disambiguate the call to
> /etc/puppet/modules/logstash by using ::logstash in my class definition
> like so:
>
> class profiles::logstash::install() {
> $ensur
I think you missed the part where it is complaining about line 10 in my
profiles::logstash::install module
class { '::logstash':
Removing ::logstash from the spec file has the same complaint.
Brian
On Wednesday, June 4, 2014 3:11:14 PM UTC-4, Garrett Honeycutt wrote:
>
> On 6/4/14, 2:30 PM, B
On Wed, Jun 4, 2014 at 4:33 AM, Jim Ficarra wrote:
> Did you try using the package resource over the exec resource? I
> install .NET 4.0 using the package resource and it works just fine on
> Windows 2008 R2 Enterprise & Standard, though I haven’t tried on Data
> Center but I’m not sure how di
On 6/4/14, 3:13 PM, Brian Wilkins wrote:
> I think you missed the part where it is complaining about line 10 in my
> profiles::logstash::install module
>
> class { '::logstash':
>
> Removing ::logstash from the spec file has the same complaint.
>
> Brian
>
> On Wednesday, June 4, 2014 3:11:14 P
It is needed to disambiguate from profiles::logstash and just logstash
classes. If I remove it, then it will complain that logstash is already
loaded when it tries to load profiles::logstash.
On Wednesday, June 4, 2014 3:52:01 PM UTC-4, Garrett Honeycutt wrote:
>
> On 6/4/14, 3:13 PM, Brian Wilk
Hi Henrik,
In 3.5 the new evaluator was added and it is on by default when using
> --parser future. If you want to turn it off you can use --evaluator
> current in addition to --parser future)
>
> If it works under --evaluator current but not under --evaluator future,
> we like to hear about i
Hi,
the scoping of the class is indeed needed, but i believe that is a
parser issue.
I did the test wit class { '::vim': version => '7.4' }
on my master with puppet master --compile i got following :
{
"metadata": {
"api_version": 1
},
"data": {
"classes": [
"settings",
What's the best way to do inherited roles for servers?
chef seems to excel at this whereas in Puppet it is wordy (at best).
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
What do you mean by "inherited roles"?
R.
On 4 June 2014 23:02, Stuart Cracraft wrote:
>
> What's the best way to do inherited roles for servers?
>
> chef seems to excel at this whereas in Puppet it is wordy (at best).
>
> --
> You received this message because you are subscribed to the Googl
http://blog.brattyredhead.com/blog/2011/11/19/puppet-for-chef-users-part-2-when-is-a-node-a/
may help. Perhaps the choice of words was wrong. The issue is how a node
inherits multiple roles.
I would assume from basic class syntax one could just do a::b::c etc to pull
stuff in from
subclassing
On 06/05/2014 01:28 AM, Stuart Cracraft wrote:
> I would assume from basic class syntax one could just do a::b::c etc
> to pull stuff in from
> subclassing and roll it up to the equivalent of chef roles.
Hi,
I suggest that you would be Doing It Wrong then.
The author of the blogpost you linked h
The recommended puppet approach is the role/profile/module pattern.
Here's the blog post that defined this:
http://www.craigdunn.org/2012/05/239/
R.
On 5 June 2014 00:40, Felix Frank wrote:
> On 06/05/2014 01:28 AM, Stuart Cracraft wrote:
> > I would assume from basic class syntax one could
Thanks Johan. It turns out that I had to set my path's explicitly in my
spec_helper.rb. For some reason, the automatically created spec_helper.rb
created by rspec-puppet-init did not create a usuable file. My tests are
running successfully now.
Brian
On Wednesday, June 4, 2014 5:05:05 PM UTC-4
Hi Brian,
I've found having my spec test print out a catalog is a good way to build out a
suite of tests
context 'when the do_stuff param has the value of hell_yeah' do
let (:facts) {{'osfamily' => 'RainbowOS }}
let (:params) {{'do_stuff' => 'hell_yeah'}}
It 'print a catalog for spec buil
26 matches
Mail list logo
