You'll want to create the file using file{} and then add require =>
File['/path/to/file'] so that the file is created before Puppet tries
to modify it.
You can do that with less typing by using the -> operator. For example:
file { '/usr/share/X11/xorg.conf.d/glamor.conf':
ensure => file,
If you add a parameter to a define, it is important to provide a default
that lets current code work without being modified. If there is no
default, than any current user of the define will get an error. This is
how one makes changes but retains backwards compatibility.
I'm not sure I understand
Suppose I maintain a public module. I'd like to start using some
Puppet 4.x language features. This means that anyone that uses this
module can't use the new version of the module until they also adopt
Puppet 4.x.
What is the best way to address this?
Some ideas that have been tossed around inte
Thank you guys,
Well Tom yes that was what I was referring to.
The thing is like you've mentioned I just don't want keep repeating all the
variables on each manifest. Because as you could see from that code I have
provided you have a page called lets say Webhosting::Php::Spip and if I
create
This topic is quite actual and interesting also for me.
I think PuppetLabs is following the first approach, and that's what I'm
inclined to do.
If it's well documented, metadata is correctly configured and SemVer has
been explicitly followed, users should cope with it.
my2c
al
On Tuesday, June
On Tue, Jun 30, 2015 at 7:09 AM, Tom Limoncelli wrote:
> -- Increment the major version number and declare that 3.x users
> shouldn't upgrade to the new major version.
>
I would adhere to semver and expect users to understand what that means.
It's a well understood convention/standard and doing
On Monday, June 29, 2015 at 4:01:36 PM UTC-5, Aaron Lager wrote:
>
> So I started over from scratch, and now I get the following error on the
> agent:
> sudo puppet agent --test
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Error: Could not retrieve catalog fr
@John, thanks for your patients with me. I'm a total noob at this stuff.
Following the links you gave me, I came up with this: {name => 'foo', ip
=> '192.168.168.1'}
But the agent says:
Error 400 on SERVER: "{name => 'foo', ip => '192.168.168.1'}" is not a
Hash.
The image below from the P
Using a JSON validation tool, I massaged your sample into:
{ "hosts: : hostentries": "puppet.mybluebolt.com", "ip":
"10.150.28.8", "host_aliases": "puppet" }
But the agent still doesn't like it:
Error 400 on SERVER: can't convert String into Hash
argh!
On Tuesday, June 30, 2015 at
Answer from puppetlabs that works:
{"hostname.example.com":{"ip":"1.2.3.4","host_aliases":"an_alias"}}
yay!
On Tuesday, June 30, 2015 at 10:02:31 AM UTC-7, Aaron Lager wrote:
>
> Using a JSON validation tool, I massaged your sample into:
> { "hosts: : hostentries": "puppet.mybluebolt.com",
On Tue, Jun 30, 2015 at 7:51 AM Alessandro Franceschi wrote:
> This topic is quite actual and interesting also for me.
> I think PuppetLabs is following the first approach, and that's what I'm
> inclined to do.
>
Yep. The planned approach is to specify puppet 4.x (or whatever) in the
metadata.js
Hi Sebastian,
The sshauthorizedkey type will do what you need.
https://docs.puppetlabs.com/references/latest/type.html#sshauthorizedkey
On 29 June 2015 at 22:29, Sebastian Rettenberger
wrote:
> Hi,
>
> I am new to Puppet and I try to manage authorized_keys file on my servers
> with Puppet.
> Up
And final post, an example of two hosts:
{"hostname.example.com":{"ip":"1.2.3.4","host_aliases":"an_alias"},
"hostname2.example.com":{"ip":"1.2.3.5","host_aliases":"an_alias2"}}
On Tuesday, June 30, 2015 at 3:49:25 PM UTC-7, Aaron Lager wrote:
>
> Answer from puppetlabs that works:
> {"hostname.e
I'm looking for an individual with solid (open source) puppet skills. I
know the basics around puppet but have not worked with it beyond basic
support for quite a few years. I'm looking to buy a block of hours from
someone or a company offering these services. I have a few updates needed
to acc
We are using what you called option 3. The main reason to use option 3
instead of 1 was that this way we can have our "truth" under version
control.
El 29/06/15 a las 16:50, Nicola V escribió:
Hello,
We're considering to migrate away from node definitions to something
more future proof, with
15 matches
Mail list logo
