Re: [Puppet Users] Re: puppet apply stops with message "Killed"

[Felix Frank]

Not an explanation off the top of my hat, but seeing as none of this is
supposed to happen, let's start at the base. What version of Linux and
which vserver patch are you running?

On 04/29/2014 09:53 PM, Ádám Sándor wrote:
> 
> If someone can give an explanation I would be very happy to read it.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5360B120.7080204%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB / inventory service configuration problem

[Ken Barber]

I never got a response. Looked like a configuration issue to me, but
there was no follow up.

I'd suggest starting a new thread with more details about your issue,
versions/error messages/configuration files etc.

ken.

On Tue, Apr 29, 2014 at 10:55 PM, Michael Eatherly
 wrote:
> I'm having this issue as well. did we ever find an answer for this problem?
>
>
> On Monday, April 22, 2013 9:26:44 AM UTC-5, Ken Barber wrote:
>>
>> Lets take a look at the following files on your puppetmaster:
>>
>> /etc/puppet/puppet.conf
>> /etc/puppet/puppetdb.conf
>> /etc/puppet/routes.yaml
>> /etc/puppet/auth.conf
>>
>> On the dashboard:
>>
>> /usr/share/puppet-dashboard/config/settings.yml (at least thats the
>> normal path for our package on RHEL 6)
>>
>> And on your puppetdb server show me the contents of:
>>
>> /etc/puppetdb/conf.d/jetty.ini
>>
>> You can probably paste this into gist or pastie.
>>
>> Also you if you can provide the version of puppetdb &
>> puppetdb-terminus that might be useful. Usually I would recommend
>> running version 1.2.0 of both puppetdb & puppetdb-terminus and its
>> important to try and keep the version in-sync for both packages.
>>
>> As far as your log:
>>
>> 2013-04-20 18:11:32,909 WARN  [qtp1655388819-40] [io.nio]
>> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
>> connection?
>>
>> Does this occur at the same time as when you click the link inventory
>> services link on Puppet Dashboard?
>>
>> ken.
>>
>> On Sat, Apr 20, 2013 at 6:15 PM, David Gordon  wrote:
>> > Hi,
>> >
>> > I've just been configuring my new Puppet 3.1.1 / Dashboard setup with
>> > Passenger to use PuppetDB for the inventory service.  I configured it
>> > via
>> > the puppetdb forge module, and it all seems to be configured correctly
>> > as
>> > far as the docs describe.
>> >
>> > When I look at a node in the dashboard, under the inventory section, I
>> > just
>> > see:
>> >
>> > Could not retrieve facts from inventory service: 404 "Could not find
>> > facts
>> > myhost.domain.com "
>> >
>> >
>> > I've quoted the log excerpts from puppetdb.log and masterhttp.log below.
>> > It
>> > sounds ssl-related, or that it's using http instead of https - but don't
>> > really know how to work out what's wrong. Anyone got any pointers for
>> > trying
>> > to debug this?
>> >
>> > Thanks,
>> > Dave
>> >
>> > ---
>> >
>> > /var/log/puppetdb/puppetdb log:
>> >
>> > 2013-04-20 18:11:32,909 WARN  [qtp1655388819-40] [io.nio]
>> > javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
>> > connection?
>> >
>> > 2013-04-20 18:11:55,089 WARN  [qtp1655388819-39] [http.server] Use of
>> > unversioned APIs is deprecated; please use
>> > /v1/metrics/mbean/java.lang:type=Memory
>> >
>> > 2013-04-20 18:35:43,518 INFO  [command-proc-45] [puppetdb.command]
>> > [db173bb5-a2ea-486e-8dd2-46abf737f975] [replace facts]
>> > puppetmaster.domain.com
>> >
>> > 2013-04-20 18:35:48,999 INFO  [command-proc-45] [puppetdb.command]
>> > [b8cc3c17-7812-45f1-b833-452ff7bf9cf5] [replace catalog]
>> > puppetmaster.domain.com
>> >
>> > 2013-04-20 18:35:53,944 WARN  [qtp1655388819-39] [http.server] Use of
>> > unversioned APIs is deprecated; please use
>> > /v1/metrics/mbean/java.lang:type=Memory
>> >
>> >
>> >
>> > /var/log/puppet/masterhttp.log
>> >
>> > [2013-04-20 18:54:52] puppetmaster.domain.com - - [20/Apr/2013:18:54:51
>> > MEST] "GET /production/facts/myhost.domain.com? HTTP/1.1" 404 51
>> >
>> > [2013-04-20 18:54:52] - -> /production/facts/myhost.domain.com?
>> >
>> > --
>> > 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
>> > an
>> > email to puppet-users...@googlegroups.com.
>> > To post to this group, send email to puppet...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/b57a6b74-3826-4f1d-a836-362a4570283e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAE4bNTkeCN_scHdaKLqCnRnXHDQCSv16R_P23-n3kK5i37uO8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Begining

[syed ghouse]

Hi guys i am new to puppet and Fresher . I analysed the puppet and when i 
want to start installing the puppet on windows.I find very difficult to 
install and configure on windows. I have to connect the master and agent . 
Can you provide me with the simple tutorial or blog where can i learn the 
puppet quickly. The Puppet labs documentation is highly confusing because 
of the all platforms given common. Please any one Help. 



Thanks in Advance.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fb5268a9-9226-498c-9912-8c17ef7c28ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] "path" fact reordering

[Fabio Coatti]

Hi all,
I spotted a behaviour that I can't really understand (pupept 3.4.3).

Basicaly I have a setup with two masters balanced via apache reverse proxy.
On clients every time the agent is run a facts.yaml is updated, to be used
by mcollective.

running puppet agent with -t i can see that sometimes the "path" fact
changes, more specifically the path order is changed, see here:

   osversion: Debian-7
-  path: "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
+  path: "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
   physicalprocessorcount: "2"

This happens more or less randomly (i.e. only with some runs, not always)

What puzzles me is that I can't find a reason for this change. afaik the
configuration of path variable is not controlled by puppet. I'm suspecting
some connection with the use of two masters, but I can't really figure out
how this can matter...

Does someone can offer some hints, please? :)

Thanks.


-- 
Fabio

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CADpTngVgsWe%2BFnt4JVWKA4hsK1a4TaC6WD%2BVyNg-uBBWAdd3Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Error frim DataBinding 'hiera'

[Pierre-Emmanuel Dutang]

Hello,

I just updated my puppet to v3.5.1 and now I got an error when I run my 
puppet agent:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Error from DataBinding 'hiera' while looking up 'jboss::jbossversion': 
uninitialized constant Puppet::FileSystem::File on node puppet.local
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:194:in `is_http_200?'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:100:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:201:in `find'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:259:in 
`retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:327:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:326:in `thinmark'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:258:in 
`retrieve_new_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:69:in `retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:109:in 
`prepare_and_retrieve_catalog'
/usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:175:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:48:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:48:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:118:in `with_client'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:83:in `run_in_fork'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:44:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `call'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `controlled_run'
/usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:42:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:355:in `onetime'
/usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:321:in `run_command'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:479:in `plugin_hook'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:479:in `exit_on_fail'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/context.rb:51:in `override'
/usr/lib/ruby/site_ruby/1.8/puppet.rb:233:in `override'
/usr/lib/ruby/site_ruby/1.8/puppet/application.rb:362:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:137:in `run'
/usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:91:in `execute'
/usr/bin/puppet:4
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Does anybody already got this error???

Thanks

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/19c438f8-98f5-4e12-ba10-3d575130cd9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Creating scope object in Puppet v3.x

[KomodoDave]

So I guess no-one knows how to achieve this?


On Tuesday, 29 April 2014 13:26:20 UTC+1, KomodoDave wrote:
>
> Hi all,
>
> I wrote a neat little script for Puppet 2.x to test custom functions 
> without needing to do a Puppet run. This involved creating a Scope object 
> using `Puppet::Parser::Scope.new` then calling `send` to send a function 
> call to it.
>
> In Puppet 3 however, creating a Scope instance this way does not work. Now 
> a Compiler object is a required argument of the Scope constructor, and a 
> Node argument is a required argument of the Compiler constructor, and the 
> list goes on.
>
> Does anyone know how I can most simply create a Scope object like I did 
> before?
>
> Many thanks,
>
> Dave
>
> Notice:  This email is confidential and may contain copyright material of 
> Ocado Limited (the "Company"). Opinions and views expressed in this message 
> may not necessarily reflect the opinions and views of the Company.
>
> If you are not the intended recipient, please notify us immediately and 
> delete all copies of this message. Please note that it is your 
> responsibility to scan this message for viruses.
>
> Company reg. no. 3875000.
>
> Ocado Limited
> Titan Court
> 3 Bishops Square
> Hatfield Business Park
> Hatfield
> Herts
> AL10 9NE
>

-- 
Notice:  This email is confidential and may contain copyright material of 
Ocado Limited (the "Company"). Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the Company.

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses.

Company reg. no. 3875000.

Ocado Limited
Titan Court
3 Bishops Square
Hatfield Business Park
Hatfield
Herts
AL10 9NE

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3b007c68-5e67-4cfa-b4e1-d4ddea4b1429%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Error frim DataBinding 'hiera'

[José Luis Ledesma]

Have you reviewed the minimum system requirements?

http://docs.puppetlabs.com/puppet/latest/reference/system_requirements.html

Regards,
 El 30/04/2014 15:13, "Pierre-Emmanuel Dutang"  escribió:

> Hello,
>
> I just updated my puppet to v3.5.1 and now I got an error when I run my
> puppet agent:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Error from DataBinding 'hiera' while looking up 'jboss::jbossversion':
> uninitialized constant Puppet::FileSystem::File on node puppet.local
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:194:in `is_http_200?'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:100:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:201:in `find'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:259:in
> `retrieve_new_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:327:in `thinmark'
> /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:326:in `thinmark'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:258:in
> `retrieve_new_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:69:in `retrieve_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:109:in
> `prepare_and_retrieve_catalog'
> /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:175:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:48:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:48:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:118:in `with_client'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:45:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:83:in `run_in_fork'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:44:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `call'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `controlled_run'
> /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:42:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:355:in `onetime'
> /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:321:in
> `run_command'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:479:in `plugin_hook'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:479:in `exit_on_fail'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:372:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/context.rb:51:in `override'
> /usr/lib/ruby/site_ruby/1.8/puppet.rb:233:in `override'
> /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:362:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:137:in `run'
> /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:91:in `execute'
> /usr/bin/puppet:4
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> Does anybody already got this error???
>
> Thanks
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/19c438f8-98f5-4e12-ba10-3d575130cd9f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAF_B3deOvgoU-RUbp8GSxtz6q8-ryR7G8wui8X4BXBLGLxOzZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Begining

[Felix Frank]

Hi,

the PuppetLabs documentation is the best resource, though. If this won't
help you up to speed, I doubt you will find an online tutorial that will
do a better job of that. You may want to purchase training directly from
PuppetLabs then.

I recommend giving the tutorials another try.

For the overall basics, you can start at:
http://docs.puppetlabs.com/learning/

>From there, there is this handy link:
http://docs.puppetlabs.com/windows/

Generally, it will be helpful for you to answer these questions for
yourself:
* On what platform will the master run?
* On what platform(s) will the agent run?

Then skip all documentation that deals with platforms that are not on
the list.

HTH,
Felix

On 04/30/2014 08:04 AM, syed ghouse wrote:
> Hi guys i am new to puppet and Fresher . I analysed the puppet and when
> i want to start installing the puppet on windows.I find very difficult
> to install and configure on windows. I have to connect the master and
> agent . Can you provide me with the simple tutorial or blog where can i
> learn the puppet quickly. The Puppet labs documentation is highly
> confusing because of the all platforms given common. Please any one Help. 

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5360FA0F.6070209%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet apply stops with message "Killed"

[jcbollinger]

On Tuesday, April 29, 2014 2:53:18 PM UTC-5, Ádám Sándor wrote:
>
> I managed to solve the problem :) First we added more memory to the 
> machine. With 1GB of memory the script ran further but still failed. In 
> this case it became apparent that it's doing something with file 
> permissions. It was setting group 70 (don't even know what kind of group 
> that is) to some scripts it was supposed to copy for execution. It was 
> doing this very slowly - tens of seconds for each file - and eating more 
> and more memory in the process, until it reached 1GB and the vserver killed 
> it.
>
>

When you say you fixed the problem, do you mean that the new failure occurs 
while applying a different resource?

 

> The fix was very simple, but I'm still intrigued as to what went wrong, 
> especially since it was such a hard-to-debug issue. I changed this resource:
> file { 'migration-scripts':
> path => $scriptPath,
> ensure => directory,
> source => 'puppet:///modules/ks/migration',
> recurse => true,
> owner => 'root'
>   }
>
> to this:
> file { 'migration-scripts':
> path => $scriptPath,
> ensure => directory,
> source => 'puppet:///modules/ks/migration',
> recurse => true
>   } 
>
> If someone can give an explanation I would be very happy to read it. Also 
> because I only got 1GB of memory on the server temporarily and I'm 
> suspecting another similar problem in my manifest since with 512GB memory 
> the execution didn't get to the part where I now spotted the group 
> permission setting.
>
>

As Felix said, this is not generally expected or documented behavior.  The 
best we can do is guess, and we're working with incomplete information when 
it comes to that.  I observe, however, that recursive File resources can be 
a source of trouble.  They do work, but they require memory on the agent 
proportional to the total number of files, plus a bit.  Also, if your 
recursive File is following links ('links' parameter) then it is possible 
to give it a logically infinite directory tree to attempt to sync.  You 
don't specify 'links' in your example, and I don't recall offhand what the 
default behavior is in that regard, but it's something to watch out for.

In addition, File resources in general are expensive when the managed 
content is large and you use the default checksum algorithm.  The choice of 
algorithm is a trade-off between expense of the test and likelihood of a 
wrong result, and Puppet defaults to the least likelihood of a wrong result.

If you are managing large collections of files or file collections having 
large aggregate size, then you would be better off avoiding recursive File 
resources.  The usual recommendation is to bundle up the files into a 
package (e.g. an RPM or DEB), put that in a local repository, and manage it 
via a Package resource.

As for the group assigned to newly-created files, it is probably the 
(numeric) group the source files have on the master.  If you don't specify 
a group for a source'd file, and that file does not initially exist on the 
target node, then the group assigned to it at creation time is the one the 
source file has.  Similarly for the file owner.  If that's indeed what you 
are seeing then that aspect of the observed behavior is as expected.  (In 
contrast, if you don't specify the group (or owner), and the file does 
already exist, then Puppet does not modify its group (or owner).)

I cannot explain why declining to manage the file owner makes a significant 
difference in memory consumption, but it's reasonable to suppose that the 
large memory consumption is a factor in the poor performance.  The 
'physical' memory assigned to your virtual machine is not necessarily 
matched with real physical memory on the underlying vserver host.  
Therefore, processes in the VM that consume a lot of memory may cause a lot 
of page faults on the host, with the attending performance impact.  The 
negative performance effects of such page faulting might even be magnified 
in the VM.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/569c0062-4372-4428-a865-51e0d587b127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Creating scope object in Puppet v3.x

[Henrik Lindberg]

On 2014-30-04 15:19, KomodoDave wrote:

So I guess no-one knows how to achieve this?




Suggest that you write rspec tests for your custom functions.
Just mimic what is done for the built in functions.
As an example of a simple function - look at 
spec/unit/parser/functions/sprintf_spec.rb


- henrik


On Tuesday, 29 April 2014 13:26:20 UTC+1, KomodoDave wrote:

Hi all,

I wrote a neat little script for Puppet 2.x to test custom functions
without needing to do a Puppet run. This involved creating a Scope
object using `Puppet::Parser::Scope.new` then calling `send` to send
a function call to it.

In Puppet 3 however, creating a Scope instance this way does not
work. Now a Compiler object is a required argument of the Scope
constructor, and a Node argument is a required argument of the
Compiler constructor, and the list goes on.

Does anyone know how I can most simply create a Scope object like I
did before?

Many thanks,

Dave

Notice:  This email is confidential and may contain copyright
material of Ocado Limited (the "Company"). Opinions and views
expressed in this message may not necessarily reflect the opinions
and views of the Company.

If you are not the intended recipient, please notify us immediately
and delete all copies of this message. Please note that it is your
responsibility to scan this message for viruses.

Company reg. no. 3875000.

Ocado Limited
Titan Court
3 Bishops Square
Hatfield Business Park
Hatfield
Herts
AL10 9NE


Notice:  This email is confidential and may contain copyright material
of Ocado Limited (the "Company"). Opinions and views expressed in this
message may not necessarily reflect the opinions and views of the Company.

If you are not the intended recipient, please notify us immediately and
delete all copies of this message.. Please note that it is your
responsibility to scan this message for viruses.

Company reg. no. 3875000.

Ocado Limited
Titan Court
3 Bishops Square
Hatfield Business Park
Hatfield
Herts
AL10 9NE

--
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
an email to puppet-users+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/3b007c68-5e67-4cfa-b4e1-d4ddea4b1429%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ljr02t%245r2%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources

[jcbollinger]

On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote:
>
> Hi John,
>
> Thanks so much for your feedback. It's extremely useful for me at this 
> stage of my education in the Puppet DSL.
>
> Here is the Puppet Users group thread where R.I. Pienaar said that he felt 
> that using create_resources() was bad: 
> https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ
>


For the record, then, R.I. said "I dont tend to use create_resources as I 
consider it about as bad as eval() :) ".  I hardly find that an emphatic 
and categorical  condemnation.  In fact, I think that lines up relatively 
well with my own position on the matter, expressed earlier in this thread.
 


> Responses to comments:
>
> 2. As far as I can see, I'm using class inheritance solely to make sure 
> that class parameters are available to the main and sub classes. Maybe you 
> are seeing that I'm using inheritance where it's not yet strictly needed? 
> I'll have to look more closely at my code and fix any instances of 
> inheritance where it's unnecessary. Thanks.
>
>
I think I was looking primarily at class kvm::virtnet.  It is not 
parameterized itself and it does not contain any resource parameter 
overrides, so it cannot have any need to inherit from class kvm.  Moreover, 
class kvm is parameterized, so *nobody* should inherit from it.  It looks 
like you may be inheriting simply to avoid prefixing class kvm's variables 
with 'kvm::' where you reference them, but that's poor form even when you 
do use inheritance.

If you are concerned about a possibility that class kvm::virtnet will be 
evaluated before class kvm, so that the references to kvm's variables are 
not resolved correctly, then 'include' class kvm instead of inheriting from 
it.  But that's dangerous and nearly pointless.  It is dangerous because if 
class kvm is declared via a parameterized-style declaration, and class 
kvm::virtnet really is evaluated first, then catalog compilation will fail 
-- as it would also do under the same circumstances with classes as you 
present.  It is nearly pointless because if you can rely on class kvm being 
evaluated first so that catalog compilation succeeds, then class 
kvm::virtnet doesn't need to inherit, include, or do anything else along 
those lines to work properly.

The caveat is that if class kvm is declared via 'include' or (I think) 
hiera_include(), and class kvm::virtnet is also independently declared, 
then it is possible for class kvm::virtnet to be evaluated first without 
the catalog compiler crashing later.  One possible approach to that problem 
is basically just to say "don't do that".  If class kvm::virtnet is 
intended only for internal use by the module, as appears may be the case, 
then document that clearly and be done with it.  None of this is an issue 
with respect to class kvm::virtnet being declared by class kvm, by the way; 
if that's the only declaration of class kvm::virtnet then class kvm is 
certain to be evaluated first.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources

[R.I.Pienaar]

- Original Message -
> From: "jcbollinger" 
> To: puppet-users@googlegroups.com
> Sent: Wednesday, April 30, 2014 3:15:03 PM
> Subject: [Puppet Users] Re: Looking for a better way to use hiera hashes than 
> create_resources
> 
> 
> 
> On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote:
> >
> > Hi John,
> >
> > Thanks so much for your feedback. It's extremely useful for me at this
> > stage of my education in the Puppet DSL.
> >
> > Here is the Puppet Users group thread where R.I. Pienaar said that he felt
> > that using create_resources() was bad:
> > https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ
> >
> 
> 
> For the record, then, R.I. said "I dont tend to use create_resources as I
> consider it about as bad as eval() :) ".  I hardly find that an emphatic
> and categorical  condemnation.  In fact, I think that lines up relatively
> well with my own position on the matter, expressed earlier in this thread.

And I still think that, unfortunately there are often few other options.

Today you should just suck it up and use the future parser and loop the data
though, it seems to be speedy enough and relatively stable, syntax has been
locked down etc.

I've not followed this thread too closely but I'd hope the f.parser iterating
your hashes/arrays should do all you need.  If not it's probably worth 
highlighting
those.

ie. the closer to reality the f.parser becomes the less you should be using
create_resources.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1444896807.322.1398867543907.JavaMail.zimbra%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources

[Alex Scoble]

Hi John,

Thanks for the info.

By the way, I started using the inherit pattern with params because of the
myriad of Splunk modules out there that do it, including this one from
Puppet Labs https://github.com/puppetlabs/puppetlabs-splunk

I understand why the pattern is used, it makes it a bit easier to deal with
variables, particularly with hiera. I also understand what you are saying.
This is the sort of thing that can drive one nuts, heh. It would be nice if
there was only one way to do things and the one way was also the right way,
but such nirvana is hard to find.

Thanks,

Alex


On Wed, Apr 30, 2014 at 7:15 AM, jcbollinger wrote:

>
>
> On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote:
>>
>> Hi John,
>>
>> Thanks so much for your feedback. It's extremely useful for me at this
>> stage of my education in the Puppet DSL.
>>
>> Here is the Puppet Users group thread where R.I. Pienaar said that he
>> felt that using create_resources() was bad: https://groups.google.
>> com/forum/?fromgroups#!searchin/puppet-users/create_
>> resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ
>>
>
>
> For the record, then, R.I. said "I dont tend to use create_resources as I
> consider it about as bad as eval() :) ".  I hardly find that an emphatic
> and categorical  condemnation.  In fact, I think that lines up relatively
> well with my own position on the matter, expressed earlier in this thread.
>
>
>
>> Responses to comments:
>>
>> 2. As far as I can see, I'm using class inheritance solely to make sure
>> that class parameters are available to the main and sub classes. Maybe you
>> are seeing that I'm using inheritance where it's not yet strictly needed?
>> I'll have to look more closely at my code and fix any instances of
>> inheritance where it's unnecessary. Thanks.
>>
>>
> I think I was looking primarily at class kvm::virtnet.  It is not
> parameterized itself and it does not contain any resource parameter
> overrides, so it cannot have any need to inherit from class kvm.  Moreover,
> class kvm is parameterized, so *nobody* should inherit from it.  It looks
> like you may be inheriting simply to avoid prefixing class kvm's variables
> with 'kvm::' where you reference them, but that's poor form even when you
> do use inheritance.
>
> If you are concerned about a possibility that class kvm::virtnet will be
> evaluated before class kvm, so that the references to kvm's variables are
> not resolved correctly, then 'include' class kvm instead of inheriting from
> it.  But that's dangerous and nearly pointless.  It is dangerous because if
> class kvm is declared via a parameterized-style declaration, and class
> kvm::virtnet really is evaluated first, then catalog compilation will fail
> -- as it would also do under the same circumstances with classes as you
> present.  It is nearly pointless because if you can rely on class kvm being
> evaluated first so that catalog compilation succeeds, then class
> kvm::virtnet doesn't need to inherit, include, or do anything else along
> those lines to work properly.
>
> The caveat is that if class kvm is declared via 'include' or (I think)
> hiera_include(), and class kvm::virtnet is also independently declared,
> then it is possible for class kvm::virtnet to be evaluated first without
> the catalog compiler crashing later.  One possible approach to that problem
> is basically just to say "don't do that".  If class kvm::virtnet is
> intended only for internal use by the module, as appears may be the case,
> then document that clearly and be done with it.  None of this is an issue
> with respect to class kvm::virtnet being declared by class kvm, by the way;
> if that's the only declaration of class kvm::virtnet then class kvm is
> certain to be evaluated first.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/35a23857-cc2c-445e-adb0-aa8ce404e760%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAETmVfTQ-SNAksDYGpDEbZs_7wA0ka--z_%2Bc6v49fc5qHZwSaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources

[Alex Scoble]

Thanks, R.I.Pienaar,

I sometimes wonder how the moving target that is the Puppet DSL slows
adoption of the product.

I'll keep an eye on the future parser. Hopefully, it's in PE soon. Of
course, then I'll need to wait until someone creates a useful module that
shows how to use the pattern. I'm not quite smart enough (or knowledgeable
enough yet) to create a new pattern on my own.

Thanks,

Alex


On Wed, Apr 30, 2014 at 7:19 AM, R.I.Pienaar  wrote:

>
>
> - Original Message -
> > From: "jcbollinger" 
> > To: puppet-users@googlegroups.com
> > Sent: Wednesday, April 30, 2014 3:15:03 PM
> > Subject: [Puppet Users] Re: Looking for a better way to use hiera hashes
> than create_resources
> >
> >
> >
> > On Tuesday, April 29, 2014 11:37:02 AM UTC-5, Alex Scoble wrote:
> > >
> > > Hi John,
> > >
> > > Thanks so much for your feedback. It's extremely useful for me at this
> > > stage of my education in the Puppet DSL.
> > >
> > > Here is the Puppet Users group thread where R.I. Pienaar said that he
> felt
> > > that using create_resources() was bad:
> > >
> https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/create_resources$20pienaar/puppet-users/lxYDKf7dgc0/TppS_7BFB9IJ
> > >
> >
> >
> > For the record, then, R.I. said "I dont tend to use create_resources as I
> > consider it about as bad as eval() :) ".  I hardly find that an emphatic
> > and categorical  condemnation.  In fact, I think that lines up relatively
> > well with my own position on the matter, expressed earlier in this
> thread.
>
> And I still think that, unfortunately there are often few other options.
>
> Today you should just suck it up and use the future parser and loop the
> data
> though, it seems to be speedy enough and relatively stable, syntax has been
> locked down etc.
>
> I've not followed this thread too closely but I'd hope the f.parser
> iterating
> your hashes/arrays should do all you need.  If not it's probably worth
> highlighting
> those.
>
> ie. the closer to reality the f.parser becomes the less you should be using
> create_resources.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/QNZyd4ipB0U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/1444896807.322.1398867543907.JavaMail.zimbra%40devco.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAETmVfRzC-Wd6vOzohynFj125X3Lp8b-L1p45J0yfTQsnCkCZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Best practice for creating resources out of Hiera?

[jcbollinger]

On Sunday, April 27, 2014 8:25:18 AM UTC-5, John Morton wrote:
>
> I made a module called resource_factory:
>
> https://forge.puppetlabs.com/jaydub/resource_factory
>
> It has two parts. One is the resource_factory class, the other is the 
> defined_resource_factory resource type. They both do the same kind of thing 
> — wrap around create_resources with a hiera look up on some key. The 
> difference is that the class creates defined_resource_factory instances by 
> default, and those instances are where you put the resource types and hiera 
> keys for the stuff you really want to create. Everything's configured in 
> hiera without a lot of site specific classes.
>
> Question is: have I just reinvented the wheel on some existing best 
> practice, and if so, how are the grown ups creating resources out of Hiera?
>
>

I think you've reinvented MS Word.  I mean, it looks slick and featureful, 
but the old DOS "edit" program was all I needed or wanted for many tasks.  
It's not as over-the-top as the Enterprise Rules Engine (but thanks, Felix, 
for that reference :-)), but create_resources() is not such a central 
feature of Puppet that dolling it up or wrapping it in additional layers of 
abstraction is a big benefit for most folks.

The grown ups *avoid* modeling resources (as such) in their hiera data.  
Resources are best modeled in Puppet DSL -- that's what it's for.  External 
data are better expressed in more raw form; that makes them easier to 
understand and use.  At times, the natural form of the data lends itself to 
use with create_resources(), or can easily be made to do.  Occasionally, 
intentionally structuring external data for use with create_resources() is 
the best way to approach a problem.  At these times, create_resources() 
already provides a reasonable interface.

If the module serves you well then great.  Thanks for sharing it, and I 
hope others find it useful, too.  Personally, though, I have no use 
whatever for such a thing.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/13a75525-a310-46b3-9831-3f73c66bbcc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Use the virtual resources and hiera to create the environent specific group os users

[Sans]

Hi all,

I have users module, which I don't control but include in my manifest to 
setup user(s) on my system. This is something I have in one of the .pp 
files:

class users::productupport {
> @group { 'productsupport':
> gid => '1553',
> }
> @produser { 'jake_s':
> user=> 'jake_s',
> uid => '5001',
> group   => 'productsupport',
> comment => 'Jake Sully',
> .
> }
> @produser { 'nina_g':
> 
> }
>

and in my manifest, I realize that information like this: 

sudoers::snippet {
> 'productsupport':
> group   => 'productsupport',
> rights  => ['ALL'];
>  }
> Users::Produser <| group == productsupport |>
>


I have four environments and not all  user-group are required on all the 
environment. How can I do the from hiera? I'm planing to have this in my 
hiera files:

*test.yaml:*
> user_group:
>   - productsupport
>   - mondev
>
> *stage.yaml:*
> user_group:
>   - productsupport
>   - idreport
>
>

but then I cannot figure out how I can use user_group to create the group 
of users. Any help/pointer?
Just one thing to note: changing anything in the users module not really an 
option for me but I'm open to any suggestion(s) if it makes thing even 
better. 

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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d19ad979-a9ea-4b78-9d3b-34e366275bd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Enable puppet agent by default

[jcbollinger]

On Tuesday, April 29, 2014 10:15:35 AM UTC-5, Christopher Wood wrote:
>
>
> Can't hosts already stagger their agent checkin times by using per-host 
> runinterval settings? 
>
>

No.  Different agents with different runintervals will still all hit the 
server at nearly the same time when they are started together, and they 
will do so again periodically thereafter (just not every run).  Moreover, 
it's nasty to use a policy knob such as runinterval to address a technical 
issue such as avoiding a thundering herd effect.

Puppet does have the 'splay' and 'splaylimit' configuration settings as a 
possible solution, however.  If you can accept some variation in the 
interval between one agent run and the next then those are pretty 
effective, albeit non-deterministic.

 

> At some point, sure, agents may not be the best path forward but I don't 
> see when I'd reach that point. 
>
>

I'm uncertain whether by "agents" you mean running the agent as a service, 
or whether you mean using the agent at all (as opposed to using "puppet 
apply").  Garrett was not suggesting the latter; he was suggesting using 
cron to schedule runs of the agent in non-daemon mode.  You can also 
schedule runs of "puppet apply" that way, but that's a whole different ball 
game.

There is a lot to be said for scheduling the agent via cron.  In addition 
to possible applications in load leveling, it can make Puppet more 
resilient.  For example, I was recently working on the provider of a custom 
type, and I managed to let a broken version escape to some of my systems, 
where it crashed the agent daemon.  I had to manually restart the daemons 
on those systems.  If I were launching Puppet from cron then the Puppet 
runs would still have failed, but the next runs, when a fixed version of 
the provider was available, would have gone fine without any manual 
intervention.

In addition, where Puppet manages its own configuration, launching it via 
cron is much cleaner.  Not necessary, as I understand it, but cleaner and 
therefore less open to unexpected behavior.  In the past, people have 
launched Puppet that way also to avoid creeping memory usage, though I 
think those memory problems are solved in any recent Puppet.

On the other hand, the system service infrastructure is a bit more natural 
and simpler to use than is cron.  Nevertheless, for my own site I have 
vague plans to switch from running Puppet as its own service to launching 
it via cron, at some indefinite point in the future.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c0aa9f0c-7730-481e-b026-8ac80df43a5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet apply stops with message "Killed"

[Len Rugen]

Did puppet hit a ulimit?


On Wed, Apr 30, 2014 at 8:44 AM, jcbollinger wrote:

>
>
> On Tuesday, April 29, 2014 2:53:18 PM UTC-5, Ádám Sándor wrote:
>>
>> I managed to solve the problem :) First we added more memory to the
>> machine. With 1GB of memory the script ran further but still failed. In
>> this case it became apparent that it's doing something with file
>> permissions. It was setting group 70 (don't even know what kind of group
>> that is) to some scripts it was supposed to copy for execution. It was
>> doing this very slowly - tens of seconds for each file - and eating more
>> and more memory in the process, until it reached 1GB and the vserver killed
>> it.
>>
>>
>
> When you say you fixed the problem, do you mean that the new failure
> occurs while applying a different resource?
>
>
>
>> The fix was very simple, but I'm still intrigued as to what went wrong,
>> especially since it was such a hard-to-debug issue. I changed this resource:
>> file { 'migration-scripts':
>> path => $scriptPath,
>> ensure => directory,
>> source => 'puppet:///modules/ks/migration',
>> recurse => true,
>> owner => 'root'
>>   }
>>
>> to this:
>> file { 'migration-scripts':
>> path => $scriptPath,
>> ensure => directory,
>> source => 'puppet:///modules/ks/migration',
>> recurse => true
>>   }
>>
>> If someone can give an explanation I would be very happy to read it. Also
>> because I only got 1GB of memory on the server temporarily and I'm
>> suspecting another similar problem in my manifest since with 512GB memory
>> the execution didn't get to the part where I now spotted the group
>> permission setting.
>>
>>
>
> As Felix said, this is not generally expected or documented behavior.  The
> best we can do is guess, and we're working with incomplete information when
> it comes to that.  I observe, however, that recursive File resources can be
> a source of trouble.  They do work, but they require memory on the agent
> proportional to the total number of files, plus a bit.  Also, if your
> recursive File is following links ('links' parameter) then it is possible
> to give it a logically infinite directory tree to attempt to sync.  You
> don't specify 'links' in your example, and I don't recall offhand what the
> default behavior is in that regard, but it's something to watch out for.
>
> In addition, File resources in general are expensive when the managed
> content is large and you use the default checksum algorithm.  The choice of
> algorithm is a trade-off between expense of the test and likelihood of a
> wrong result, and Puppet defaults to the least likelihood of a wrong result.
>
> If you are managing large collections of files or file collections having
> large aggregate size, then you would be better off avoiding recursive File
> resources.  The usual recommendation is to bundle up the files into a
> package (e.g. an RPM or DEB), put that in a local repository, and manage it
> via a Package resource.
>
> As for the group assigned to newly-created files, it is probably the
> (numeric) group the source files have on the master.  If you don't specify
> a group for a source'd file, and that file does not initially exist on the
> target node, then the group assigned to it at creation time is the one the
> source file has.  Similarly for the file owner.  If that's indeed what you
> are seeing then that aspect of the observed behavior is as expected.  (In
> contrast, if you don't specify the group (or owner), and the file does
> already exist, then Puppet does not modify its group (or owner).)
>
> I cannot explain why declining to manage the file owner makes a
> significant difference in memory consumption, but it's reasonable to
> suppose that the large memory consumption is a factor in the poor
> performance.  The 'physical' memory assigned to your virtual machine is not
> necessarily matched with real physical memory on the underlying vserver
> host.  Therefore, processes in the VM that consume a lot of memory may
> cause a lot of page faults on the host, with the attending performance
> impact.  The negative performance effects of such page faulting might even
> be magnified in the VM.
>
>
> John
>
>  --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/569c0062-4372-4428-a865-51e0d587b127%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+u

Re: [Puppet Users] Re: Puppet and Windows ACLs (Access Control Lists)

[Rob Reynolds]

On Tue, Apr 29, 2014 at 5:45 PM, Joaquin Menchaca wrote:

> What is most important to me is to have the ability to set ACLS on
> existing resources, such as file, service, and registry (and other
> objects).
>

We are starting with file, once we have that solid, we'll accept other
target types -
https://github.com/puppetlabs/puppetlabs-acl#acl-access-control-list

Can you read over that and see if you believe that we should do anything
more complex with SDDLs?


>
> For now, it would be an immediate boon to apply the, oh so ugly, SDDL for
> a given resource, like a service.  Later, we can have an SDDL builder, that
> has some comfortable readable language, ala subinacle styled ACEs, that
> builds the SDDL that will be applied to the attribute level.  This can be
> similar to how ERB is used in the content("stuff").
>
> I think if you take this approach, you avoid gross complexity of trying to
> merge how Windows works and how Puppet works, and avoid feature-scope
> creep.  It also gives the opportunity to add immediate value to existing
> puppet, and and more robust features later.
>
> If a particular resource that needs an ACL applied, such as certificate
> store or active directory OU, one needs to implement an actual resource for
> that type in PuppetForce.  If you have ACL resource modifying various
> objects, it will get overly complex, and you are just re-implementing the
> wheel as far as existing resources already, and you are breaking the whole
> model.  You'll be doing an anti-pattern for Puppet, and making a lot of
> future hurt, especially from the crowd that may bicker that Puppet should
> work like Windows...
>
> By having an attribute for the SDDL, one can manage resources in the scope
> of how puppet currently managers resources, rather than having two cross
> scopes from opposing models of maintaining resources.
>
> Also, if there is a utility function, like like ERB's content(" "), then
> sys admins around the world will rejoice, as they no longer have to do
> nasties like this below:
>
> sc sdset 
> "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"
>
> cacl c:\tools /s
> "D:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)"
>
> setprinter \\"Print_Server_Name"\printer1 3
> pSecurityDescriptor="O:BAG:DUD:(A;;LCSWSDRCWDWO;;;BA)(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2604)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;CIIO;RC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;OIIO;RPWPSDRCWDWO;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;LCSWSDRCWDWO;;;PU)(A;OIIO;RPWPSDRCWDWO;;;PU)"
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/aa39f4f3-a1aa-405f-8307-3c4f08fba2de%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet Labs

*Join us at **PuppetConf 2014 **, September 23-24 in
San Francisco*
*Register by May 30th to take advantage of the Early Adopter discount
 **--**save $349!*

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAMJiBK4_CdvktQkQgHXL3RYNT55a3Ch%2B1FixumVApZkWCYx4pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Enable puppet agent by default

[José Luis Ledesma]

There is another option, mcollective.

Using cron is somewhat manual, and you have to determine whenever to run
puppet to avoid a thundering herd effect.

Mcollective lets you use the

Mco puppet runall 

Where the concurrency sets how many agents run at the same time.

It is resielent as cron is, and also you have a central point of puppet
agents management, instead of (semi) manually set cron entries.

Regards
El 30/04/2014 17:21, "jcbollinger"  escribió:

>
>
> On Tuesday, April 29, 2014 10:15:35 AM UTC-5, Christopher Wood wrote:
>>
>>
>> Can't hosts already stagger their agent checkin times by using per-host
>> runinterval settings?
>>
>>
>
> No.  Different agents with different runintervals will still all hit the
> server at nearly the same time when they are started together, and they
> will do so again periodically thereafter (just not every run).  Moreover,
> it's nasty to use a policy knob such as runinterval to address a technical
> issue such as avoiding a thundering herd effect.
>
> Puppet does have the 'splay' and 'splaylimit' configuration settings as a
> possible solution, however.  If you can accept some variation in the
> interval between one agent run and the next then those are pretty
> effective, albeit non-deterministic.
>
>
>
>> At some point, sure, agents may not be the best path forward but I don't
>> see when I'd reach that point.
>>
>>
>
> I'm uncertain whether by "agents" you mean running the agent as a service,
> or whether you mean using the agent at all (as opposed to using "puppet
> apply").  Garrett was not suggesting the latter; he was suggesting using
> cron to schedule runs of the agent in non-daemon mode.  You can also
> schedule runs of "puppet apply" that way, but that's a whole different ball
> game.
>
> There is a lot to be said for scheduling the agent via cron.  In addition
> to possible applications in load leveling, it can make Puppet more
> resilient.  For example, I was recently working on the provider of a custom
> type, and I managed to let a broken version escape to some of my systems,
> where it crashed the agent daemon.  I had to manually restart the daemons
> on those systems.  If I were launching Puppet from cron then the Puppet
> runs would still have failed, but the next runs, when a fixed version of
> the provider was available, would have gone fine without any manual
> intervention.
>
> In addition, where Puppet manages its own configuration, launching it via
> cron is much cleaner.  Not necessary, as I understand it, but cleaner and
> therefore less open to unexpected behavior.  In the past, people have
> launched Puppet that way also to avoid creeping memory usage, though I
> think those memory problems are solved in any recent Puppet.
>
> On the other hand, the system service infrastructure is a bit more natural
> and simpler to use than is cron.  Nevertheless, for my own site I have
> vague plans to switch from running Puppet as its own service to launching
> it via cron, at some indefinite point in the future.
>
>
> John
>
>  --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/c0aa9f0c-7730-481e-b026-8ac80df43a5f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAF_B3deYrqpYqn0sd5OHx-TeHRTWNv01gK--gNpvqC-Ff2W4OQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Custom fact displays with brackets and double quotes, eg [""]

[Ryan Anderson]

I have a ruby custom fact that when queried with 'facter -p mysite' 
displays as expected (eg TX), but if I do 'facter -p | grep mysite' it 
shows up like ["MN"]. It will show up this wrong way when it goes to 
puppetdb (whose data I view with puppetboard).

This custom fact only behaves this way on one platform, AIX with 
ruby 2.0.0p353. The built-in facts do not have this same issue. Any ideas 
on how to fix this? The ruby fact code is something like:

Facter.add("mysite") do
setcode do
case Facter.value(:ipaddress)
when /^10\.1\.91\.|^10\.1\.92\.|^10\.1\.93\./
"TX"
when /^13\.1\.1\.|^13\.1\.2\./
"CA"
end
end
end

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/be893da1-8c15-4b52-b829-93bae51504ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Enable puppet agent by default

[Garrett Honeycutt]

On 4/30/14, 12:49 PM, José Luis Ledesma wrote:
> There is another option, mcollective.
> 
> Using cron is somewhat manual, and you have to determine whenever to run
> puppet to avoid a thundering herd effect.
> 
> Mcollective lets you use the
> 
> Mco puppet runall 
> 
> Where the concurrency sets how many agents run at the same time.
> 
> It is resielent as cron is, and also you have a central point of puppet
> agents management, instead of (semi) manually set cron entries.
> 
> Regards

Hi,

TL;DR: you can totally use cron and not have to think about scheduling
your agents.


MCollective is great for doing ad-hoc runs. If you want puppet to run at
a regular interval, then you would need to run the agent as a service or
with cron or run mcollective with either of those two things which would
achieve the same end.

Using cron is not at all manual and you do not have to determine when to
run your agents to avoid thundering herd. A common way to do this is to
use fqdn_rand(). Here's an example[1] of my implementation of this.

MCollective is not as resilient as cron if your system looses network
connectivity or has a lot of latency such as satellite connections,
though that is likely not an issue for most folks. It does give you a
central point of management for your agents which can be awesome. Some
folks run puppet only in noop mode and only do enforcing runs on demand
with MCollective, though that depends on your change management needs.

[1] -
https://github.com/ghoneycutt/puppet-module-puppet/blob/master/manifests/agent.pp#L110-111

BR,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/53613E27.6070409%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] variable scoping and templates

[drs]

I am new to puppet and am trying to figure out variable scoping. I have a 
test module that I am using for this and it looks like this:

manifiests/init.pp:

class test {
  include test::params

  file { 'testfile' :
path   => "/tmp/testfile",
content => template("test/testfile.erb"),
  }
}

manifests/params.pp:

class test::params {
  $p1 = hiera('param1')
  $p2 = hiera('param2')
}

templates/testfile.erb:

this is the first parameter:  <%= @p1 %>
this is the second parameter:  <%= @p2 %>

global.yaml:

---
  param1: "this is the first one"
  param2: "this is the second one"

Based on what I am seeing in the ProPuppet book (the discussion of the 
puppet module in Chap. 2, pp69-70), this should work. However, the values 
are not being inserted in the template. In order to get them in, I have to 
add something like this to the init.pp manifest:

  $a = $::test::params::p1
  $b = $::test::params::p2

and reference @a and @b in the template.

So the question is: Am I missing something or is there an error in the 
ProPuppet example?

If I need to add the $a = …. and $b=… lines to the init.pp, what, if any is 
the advantage to having a params.pp manifest. I could just put the hiera() 
calls in init.pp.

thanks for your patience.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/abcf9bb6-b3a2-483d-8655-3b6a6eed8196%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] variable scoping and templates

[Matthew Burgess]

We just ran into this too recently. From my investigation it looks like the
syntax you quote above is for referencing Hiera values in Puppet manifests.
For erb templates we ended up using scope.function_hiera () although I
wonder now whether a scope.lookupvar () call would a) be better and b) be
better as it's more generic?

Matt
On 30 Apr 2014 19:48, "drs"  wrote:

> I am new to puppet and am trying to figure out variable scoping. I have a
> test module that I am using for this and it looks like this:
>
> manifiests/init.pp:
>
> class test {
>   include test::params
>
>   file { 'testfile' :
> path   => "/tmp/testfile",
> content => template("test/testfile.erb"),
>   }
> }
>
> manifests/params.pp:
>
> class test::params {
>   $p1 = hiera('param1')
>   $p2 = hiera('param2')
> }
>
> templates/testfile.erb:
>
> this is the first parameter:  <%= @p1 %>
> this is the second parameter:  <%= @p2 %>
>
> global.yaml:
>
> ---
>   param1: "this is the first one"
>   param2: "this is the second one"
>
> Based on what I am seeing in the ProPuppet book (the discussion of the
> puppet module in Chap. 2, pp69-70), this should work. However, the values
> are not being inserted in the template. In order to get them in, I have to
> add something like this to the init.pp manifest:
>
>   $a = $::test::params::p1
>   $b = $::test::params::p2
>
> and reference @a and @b in the template.
>
> So the question is: Am I missing something or is there an error in the
> ProPuppet example?
>
> If I need to add the $a = …. and $b=… lines to the init.pp, what, if any
> is the advantage to having a params.pp manifest. I could just put the
> hiera() calls in init.pp.
>
> thanks for your patience.
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/abcf9bb6-b3a2-483d-8655-3b6a6eed8196%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAKUTv3KZS9NQKEhOcM_WYBrX1w%3DiO2j0gChwN7ok%3DX-w4cw0TQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: variable scoping and templates

[Alex Scoble]

As far as I know, the only reason you would use params.pp is if you have 
sane defaults you want to pass to variables. When you do, you use:

class test inherits test::params {
}

for your init.pp. You don't use an include statement as far as I know.

However, because you aren't defining sane defaults, you don't need the 
params.pp.

Instead just make your test/manifests/init.pp look like:

class test {

  $p1 = hiera('param1')
  $p2 = hiera('param2')

  file { 'testfile' :
path   => "/tmp/testfile",
content => template("test/testfile.erb"),
  }

}

Hope that helps.

--Alex

On Wednesday, April 30, 2014 11:31:03 AM UTC-7, drs wrote:
>
> I am new to puppet and am trying to figure out variable scoping. I have a 
> test module that I am using for this and it looks like this:
>
> manifiests/init.pp:
>
> class test {
>   include test::params
>
>   file { 'testfile' :
> path   => "/tmp/testfile",
> content => template("test/testfile.erb"),
>   }
> }
>
> manifests/params.pp:
>
> class test::params {
>   $p1 = hiera('param1')
>   $p2 = hiera('param2')
> }
>
> templates/testfile.erb:
>
> this is the first parameter:  <%= @p1 %>
> this is the second parameter:  <%= @p2 %>
>
> global.yaml:
>
> ---
>   param1: "this is the first one"
>   param2: "this is the second one"
>
> Based on what I am seeing in the ProPuppet book (the discussion of the 
> puppet module in Chap. 2, pp69-70), this should work. However, the values 
> are not being inserted in the template. In order to get them in, I have to 
> add something like this to the init.pp manifest:
>
>   $a = $::test::params::p1
>   $b = $::test::params::p2
>
> and reference @a and @b in the template.
>
> So the question is: Am I missing something or is there an error in the 
> ProPuppet example?
>
> If I need to add the $a = …. and $b=… lines to the init.pp, what, if any 
> is the advantage to having a params.pp manifest. I could just put the 
> hiera() calls in init.pp.
>
> thanks for your patience.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/935d68a3-64cb-4f51-8fe4-a6282f4260dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: variable scoping and templates

[Alex Scoble]

By the way, if you are using Puppet 3.0.0 or newer you shouldn't need the 
hiera() function at all.

Just call out your variables like so:

class test (
  $a,
  $b,
) {

  file { 'testfile' :
path   => "/tmp/testfile",
content => template("test/testfile.erb"),
  }

}

In your hiera yaml it would look like (assuming you've set up your site.pp 
to allow for calling classes within hiera):

---
classes:
  - test
test::a:'foo'
test::b:'bar'

Hope this helps,

Alex

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/44799bde-64bb-44af-a6f8-772307f0151c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Looking for a better way to use hiera hashes than create_resources

[jcbollinger]

On Wednesday, April 30, 2014 9:23:49 AM UTC-5, Alex Scoble wrote:
>
> Hi John,
>
> Thanks for the info.
>
> By the way, I started using the inherit pattern with params because of the 
> myriad of Splunk modules out there that do it, including this one from 
> Puppet Labs https://github.com/puppetlabs/puppetlabs-splunk
>


Where that PL module uses class inheritance, it is for one or both of the 
two reasons I gave earlier.

Some of the classes inherit class splunk::params in order to use variables 
of that class as default values in their own parameter lists.  Inheriting 
splunk::params ensures that that class has already been evaluated when the 
child class is evaluated.  Where the child classes in fact refer to 
variables from splunk::params, they do so via their qualified names.

The classes in the 'platform' subpackage inherit splunk::virtual.  They do 
so in order to override parameters of resources declared by 
splunk::virtual.  As far as I can tell, they do not refer to any of 
splunk::virtual's class variables via unqualifed names.

So actually, that module provides a pretty good example and model of 
several of my above points about class inheritance.  It does have a few 
flaws, though -- most notably, it parameterizes class splunk::params that 
is intended to be inherited.  Notwithstanding my practical arguments, the 
language reference explicitly forbids inheriting from parameterized 
classes,
 
so the PL crew really should know better.

 

>
> I understand why the pattern is used, it makes it a bit easier to deal 
> with variables, particularly with hiera.
>


If that's what you're gleaning from the PL module then no, it seems that 
you don't understand why the pattern is used (there).

 

> I also understand what you are saying. This is the sort of thing that can 
> drive one nuts, heh. It would be nice if there was only one way to do 
> things and the one way was also the right way, but such nirvana is hard to 
> find.
>
>

I do not claim to be keeper of the One True Way, but I am fairly well 
informed about this community's current opinions about best practices for 
Puppet manifest code (and at times I have disagreed with aspects of them).  
You will certainly code things as you think most appropriate, but you 
should make the best-informed decisions you can about how that actually 
is.  Myself, I am not much swayed by the "Somebody else is doing it" 
rationale.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c7094feb-af21-4afd-9f14-a4df10c87636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Setting quotes using augeas type

[Kenton Brede]

I'm using the phpvars lens for a cacti file, trying to set the password.

The file entry should look like:
$database_password = "testpass";

I can successfully set and save the password with quotes, while using
augtool:
augtool> set /files/usr/share/cacti/include/config.php/$database_password
"\"testpass\""

But when using the augeas type with the following:
changes => 'set \$database_password "\"test\""',

The file entry looks like:
$database_password = \"test\";

I've tried a bunch of escape iterations and quoting options.  So far I've
not been able to get this to work properly.

Is there some way I can get this to print the variable with quotes, using
puppet/augeas?
Thanks,

-- 
Kent Brede

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2BnSE3_EfyMBoV%2BP8EKeLWsEbRSdVVWH50p_-eK854QEDEn%2BNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: variable scoping and templates

[jcbollinger]

On Wednesday, April 30, 2014 1:31:03 PM UTC-5, drs wrote:
>
> I am new to puppet and am trying to figure out variable scoping. I have a 
> test module that I am using for this and it looks like this:
>
> manifiests/init.pp:
>
> class test {
>   include test::params
>
>   file { 'testfile' :
> path   => "/tmp/testfile",
> content => template("test/testfile.erb"),
>   }
> }
>
> manifests/params.pp:
>
> class test::params {
>   $p1 = hiera('param1')
>   $p2 = hiera('param2')
> }
>
> templates/testfile.erb:
>
> this is the first parameter:  <%= @p1 %>
> this is the second parameter:  <%= @p2 %>
>
> global.yaml:
>
> ---
>   param1: "this is the first one"
>   param2: "this is the second one"
>
> Based on what I am seeing in the ProPuppet book (the discussion of the 
> puppet module in Chap. 2, pp69-70), this should work. However, the values 
> are not being inserted in the template. In order to get them in, I have to 
> add something like this to the init.pp manifest:
>
>   $a = $::test::params::p1
>   $b = $::test::params::p2
>
> and reference @a and @b in the template.
>
> So the question is: Am I missing something or is there an error in the 
> ProPuppet example?
>


I am not looking at *Pro Puppet*, but probably you are missing something: 
templates can refer directly to only global variables and the local 
variables of the class where the template is evaluated.  When one class 
declares another, such as via 'include', the other class's variables do not 
become local to the including class (see also below).  For a template to 
reference variables of some other class than the one currently evaluating 
it, it must use scope.lookupvar('qualified::name::of::desired::variable').

Note 1: Although declaring another class does not make its variables local, 
inheriting from another class does effectively do so.  But use class 
inheritance for that purpose.

Note 2: Do not misunderstand the 'include' function.  It "includes" the 
named class in the target node's catalog.  It does *not* include or 
interpolate the class or any part of it into the class where the 'include' 
statement appears.

 

>
> If I need to add the $a = …. and $b=… lines to the init.pp, what, if any 
> is the advantage to having a params.pp manifest. I could just put the 
> hiera() calls in init.pp.
>
>

The common understanding of the purpose of ::params class is to serve as a 
data repository, typically of hard-coded, module-specific data.  Such data 
most often serve as default values for class variables, including class 
parameters, and sometimes serve as general well-known values of the 
module's domain.  (To safely use a ::params class for parameter defaults, 
the parameterized class must inherit from the ::params class.) There has 
also been a growing tendency to put default data computations into such a 
class, though there is some doubt about the wisdom of that approach.

And you can indeed just put hiera() calls into one of your module's other 
classes instead, or allow puppet to make such calls automatically to select 
class parameter values.  For data ultimately coming from hiera, that's 
precisely what I would do.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4a5b685a-fd46-46fb-bfba-1cc3cf227463%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: variable scoping and templates

[jcbollinger]

On Wednesday, April 30, 2014 4:55:03 PM UTC-5, jcbollinger wrote:
>
>
> Note 1: Although declaring another class does not make its variables 
> local, inheriting from another class does effectively do so.  But use class 
> inheritance for that purpose.
>


Critical correction: But DO NOT use class inheritance for that purpose.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52d2f16f-a9a5-457d-a0e5-2bc683b1d818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] variable scoping and templates

[jcbollinger]

On Wednesday, April 30, 2014 2:43:07 PM UTC-5, Matthew Burgess wrote:
>
> We just ran into this too recently. From my investigation it looks like 
> the syntax you quote above is for referencing Hiera values in Puppet 
> manifests.
>

Nope, absolutely not.  Templates have visibility into hiera only via the 
hiera() Puppet function and its kin.

 

> For erb templates we ended up using scope.function_hiera () although I 
> wonder now whether a scope.lookupvar () call would a) be better and b) be 
> better as it's more generic?
>

scope.lookupvar() doesn't do the same thing that scope.function_hiera() 
does.  The former looks up a qualified or unqualified Puppet variable (e.g. 
a class variable).  The latter invokes Puppet's hiera() function to query 
hiera for data associated with the specified key.  Under some circumstances 
they will return the same value for the same input; under those 
circumstances, scope.lookupvar() is better because it is cheaper.  If you 
cannot rely on the template being evaluated under those circumstances, 
however, then you should choose whichever function does the job you 
actually want.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/194dab71-b4bb-4259-b1ab-925d619de0d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: variable scoping and templates

[jcbollinger]

On Wednesday, April 30, 2014 3:02:14 PM UTC-5, Alex Scoble wrote:
>
> By the way, if you are using Puppet 3.0.0 or newer you shouldn't need the 
> hiera() function at all.
>


Not so fast.  Automatic data binding does remove any *need* for writing 
explicit hiera() calls (provided you are willing to structure your hiera 
keys in a suitable way), but the implication that you in fact *shouldn't*use 
explicit hiera() calls is not nearly so well established.  Also, if you 
want the special hierarchy-transcending behavior of hiera_hash() or 
hiera_array() (which, admittedly, are not hiera() itself) then you can only 
get it via the appropriate function calls.


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/caf5ac4a-23c2-4ad1-9b94-17d9bb30c0e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Use the virtual resources and hiera to create the environent specific group os users

[jcbollinger]

On Wednesday, April 30, 2014 10:06:18 AM UTC-5, Sans wrote:
>
> Hi all,
>
> I have users module, which I don't control but include in my manifest to 
> setup user(s) on my system. This is something I have in one of the .pp 
> files:
>
> class users::productupport {
>> @group { 'productsupport':
>> gid => '1553',
>> }
>> @produser { 'jake_s':
>> user=> 'jake_s',
>> uid => '5001',
>> group   => 'productsupport',
>> comment => 'Jake Sully',
>> .
>> }
>> @produser { 'nina_g':
>> 
>> }
>>
>
>

For that to be much use, there needs somewhere to be a class that declares 
that one and all its siblings.  Maybe it's class 'users':

modules/users/manifests/init.pp:

class users {
  include 'users::idreport'
  include 'users::mondev'
  include 'users::productsupport'
  ...
}

 

> and in my manifest, I realize that information like this: 
>
> sudoers::snippet {
>> 'productsupport':
>> group   => 'productsupport',
>> rights  => ['ALL'];
>>  }
>> Users::Produser <| group == productsupport |>
>>
>
>
> I have four environments and not all  user-group are required on all the 
> environment. How can I do the from hiera? I'm planing to have this in my 
> hiera files:
>
> *test.yaml:*
>> user_group:
>>   - productsupport
>>   - mondev
>>
>> *stage.yaml:*
>> user_group:
>>   - productsupport
>>   - idreport
>>
>>
>
> but then I cannot figure out how I can use user_group to create the group 
> of users. Any help/pointer?
> Just one thing to note: changing anything in the users module not really 
> an option for me but I'm open to any suggestion(s) if it makes thing even 
> better. 
>
>

Put your snippet into a defined type, maybe "mymodule::group", and use the 
array of group names from hiera to declare the appropriate instances of 
that type.


somewhere.pp:

$my_groups = hiera('user_group')
mymodule::group { $my_groups: }


modules/mymodule/manifests/group.pp:

define mymodule::group {
  include 'users'
  sudoers::snippet { $title:
group => $title,
rights => ['ALL']
  }
  Users::Produser<| group == $title |>
}


John

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a0528009-e0e4-4e7d-8cc8-b6b64e24033f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Use the virtual resources and hiera to create the environent specific group os users

[Garrett Honeycutt]

On 4/30/14, 11:06 AM, Sans wrote:
> Hi all,
> 
> I have users module, which I don't control but include in my manifest to
> setup user(s) on my system. This is something I have in one of the .pp
> files:
> 
> class users::productupport {
> @group { 'productsupport':
> gid => '1553',
> }
> @produser { 'jake_s':
> user=> 'jake_s',
> uid => '5001',
> group   => 'productsupport',
> comment => 'Jake Sully',
> .
> }
> @produser { 'nina_g':
> 
> }
> 
> 
> and in my manifest, I realize that information like this:
> 
> sudoers::snippet {
> 'productsupport':
> group   => 'productsupport',
> rights  => ['ALL'];
>  }
> Users::Produser <| group == productsupport |>
> 
> 
> 
> I have four environments and not all  user-group are required on all the
> environment. How can I do the from hiera? I'm planing to have this in my
> hiera files:
> 
> /*test.yaml:*/
> user_group:
>   - productsupport
>   - mondev
> 
> /*stage.yaml:*/
> user_group:
>   - productsupport
>   - idreport
> 
> 
> 
> but then I cannot figure out how I can use user_group to create the
> group of users. Any help/pointer?
> Just one thing to note: changing anything in the users module not really
> an option for me but I'm open to any suggestion(s) if it makes thing
> even better.
> 
> Best!

Hi Sans,

I have code available[1] that does exactly this. You could put a level
in hiera.yaml such as

  - environments/%{environment}

and then in each file (environments/stage.yaml and
environments/test.yaml) put the users that should be realized.

Though coding aside, from a sysadmin standpoint why you are doing this
seems quite odd. I would recommend realizing all the users in all
environments, which is effectively what happens when you use a directory
service, and then lock down which users can access the system depending
on the environment. If you go that route, check out my pam module[2].
Instead of describing users in different levels of hiera, you would
describe them all in one level of hiera and at the environment level you
would put what groups are allowed to login.

[1] - https://github.com/ghoneycutt/puppet-module-common#commonmkuser-define

[2] - https://github.com/ghoneycutt/puppet-module-pam/#allowed_users

BR,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/536183CB.6030105%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Problem with custom facts and hiera (solved)

[Garrett Honeycutt]

On Tuesday, March 11, 2014 7:44:58 AM UTC-4, Dirk Heinrichs wrote:
>
>  Am 11.03.2014 10:17, schrieb Dirk Heinrichs:
>
>  To do this, I've placed a simple text file "custom_facts.txt" into 
> C:\ProgramData\PuppetLabs\facter\facts.d with content
>
> [facts]
> role = PuppetDev
>
>
> Got it to work by removing the blanks:
>
> role=PuppetDev
>
> Bye...
>
> Dirk
> -- 
>
> *Dirk Heinrichs*, Senior Systems Engineer, Engineering Solutions
> *Recommind GmbH*, Von-Liebig-Straße 1, 53359 Rheinbach
> *Tel*: +49 2226 159 (Ansage) 1149
> *Email*: d...@recommind.com 
> *Skype*: dirk.heinrichs.recommind
> www.recommind.com
>



Hi,

I ran into a similar issue and wanted to post the fix here for others. To 
create the text file I used

  echo key=value > file.txt

After looking in /var/lib/puppet/yaml/facts/.yaml, I found that 
there was trailing whitespace as I had 'key=value '. To fix, I edited in 
notepad to remove the trailing whitespace.

Hope this saves someone else some time :>
-g

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/57fafb9b-bd9c-46dc-a9a8-598721c0909f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Database and user not created (Puppetlabs mysql module)

[Pete Brown]

On 29 April 2014 04:12, Piotr Usewicz  wrote:
> I think you have to enable pluginssync option in the [main] section in
> puppet.conf

I am pretty sure pluginsync is on by default in recent versions of puppet.
So unless you have disabled it it should work.


> On Wednesday, 11 April 2012 14:12:03 UTC+1, Moteo wrote:
>>
>> Hi Luca,
>>
>> sadly I left "nice puppet" way for a while for Mysql management and
>> did everything manuallly :(
>>
>> Best regards
>> M.
>>
>> 2012/3/28 Luca Spiller :
>> > Moteo, did you get this issue resolved?
>> >
>> > I've used the Puppetlabs MySql module in the past, but I'm now getting
>> > these
>> > issues setting up a new machine with Ubuntu 11.10. I've used the same
>> > Puppet
>> > scripts on other Ubuntu 11.10 machines previously with no issues.
>> >
>> > On Thursday, 15 March 2012 10:51:04 UTC, Moteo wrote:
>> >>
>> >> I will try this module.
>> >>
>> >> Thank You Adam.
>> >>
>> >> 2012/3/14 Adam Heinz :
>> >> > I don't know anything about that particular module, but I have been
>> >> > using github.com/camptocamp/puppet-mysql for over a year without much
>> >> > trouble.
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "Puppet Users" group.
>> >> > To post to this group, send email to puppet...@googlegroups.com.
>> >> > To unsubscribe from this group, send email to
>> >> > puppet-users...@googlegroups.com.
>> >> > For more options, visit this group at
>> >> > http://groups.google.com/group/puppet-users?hl=en.
>> >> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Puppet Users" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/puppet-users/-/ZwavJYd6jwMJ.
>> >
>> > To post to this group, send email to puppet...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-users...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/puppet-users?hl=en.
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/d3af5373-21c2-4ee5-a3d3-8e6ab74a6c4e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJ8DPF6cDNOM5sMUO%3DhyA5g1PdUy5cv1N_FPY%2BRAi7PzDf3ugg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: variable scoping and templates

[Alex Scoble]

Heh, John,

I said shouldn't need, not shouldn't use.

Thanks,

Alex


On Wed, Apr 30, 2014 at 3:12 PM, jcbollinger wrote:

>
>
> On Wednesday, April 30, 2014 3:02:14 PM UTC-5, Alex Scoble wrote:
>>
>> By the way, if you are using Puppet 3.0.0 or newer you shouldn't need the
>> hiera() function at all.
>>
>
>
> Not so fast.  Automatic data binding does remove any *need* for writing
> explicit hiera() calls (provided you are willing to structure your hiera
> keys in a suitable way), but the implication that you in fact *shouldn't*use 
> explicit hiera() calls is not nearly so well established.  Also, if you
> want the special hierarchy-transcending behavior of hiera_hash() or
> hiera_array() (which, admittedly, are not hiera() itself) then you can only
> get it via the appropriate function calls.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/jZGsQ97oljs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/caf5ac4a-23c2-4ad1-9b94-17d9bb30c0e4%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAETmVfSy_7SpD7QwdHY-USuqMxL2%2BmMObpu%3DggRGfxPBYQdzyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] "path" fact reordering

[Pete Brown]

Have you looked at how the shell variable is generated on each server?
My guess would be it is different on each one.

It may pay to manage it so it is the same on both masters.

On 30 April 2014 19:17, Fabio Coatti  wrote:
> Hi all,
> I spotted a behaviour that I can't really understand (pupept 3.4.3).
>
> Basicaly I have a setup with two masters balanced via apache reverse proxy.
> On clients every time the agent is run a facts.yaml is updated, to be used
> by mcollective.
>
> running puppet agent with -t i can see that sometimes the "path" fact
> changes, more specifically the path order is changed, see here:
>
>osversion: Debian-7
> -  path: "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
> +  path: "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
>physicalprocessorcount: "2"
>
> This happens more or less randomly (i.e. only with some runs, not always)
>
> What puzzles me is that I can't find a reason for this change. afaik the
> configuration of path variable is not controlled by puppet. I'm suspecting
> some connection with the use of two masters, but I can't really figure out
> how this can matter...
>
> Does someone can offer some hints, please? :)
>
> Thanks.
>
>
> --
> Fabio
>
> --
> 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 an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CADpTngVgsWe%2BFnt4JVWKA4hsK1a4TaC6WD%2BVyNg-uBBWAdd3Wg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJ8DPF7scx3azmcqPOewiKHz_N9cYQA3kkVwjtGsO3aaO1wPeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: New Puppet Master install not creating packages when adding Class

[Dan Aspinall]

Apologies for the delay in responding - been on leave.

That is exactly the problem so thank you so much.  I didn't know that you
had to add the class to the node as well.  I thought from the main console
screen was sufficient.

Thanks again!



On Fri, Apr 11, 2014 at 11:52 PM, jcbollinger wrote:

>
>
> On Thursday, April 10, 2014 6:50:55 PM UTC-5, aspo73 wrote:
>>
>> Hi John.
>> It does look as though I've set up the master to manage itself OK, as I'm
>> seeing my host listed here:
>> http://snag.gy/sWpfy.jpg
>> Is this what I should expect?
>> I also include the class showing as added here:
>> http://snag.gy/E94QL.jpg
>> I can't see any way within the Class menu to force assignment of that
>> pe_repo::platform::el_5_x86_64 class either to the master node, or to
>> another node, other than the way I've already use to simply add it.
>> Thanks very much for your help so far.
>>
>>
>
> I think what you have done is add the class 'pe_repo::platform::el_5_x86_
> 64' to the list of those *available* for assignment to nodes.  The number
> 0 to the right of it is the number of nodes to which this class has been
> assigned, I believe.  You should be able to verify that by clicking on the
> class name in that "Classes" panel to bring up its detail page -- one of
> the details reported is to which nodes the class has been assigned.
>
> Your computers don't all have the same configuration requirements, and
> probably some have conflicting requirements.  Puppet allows you to model
> all those possibly-conflicting configurations via modules, classes, and
> data, but just because Puppet *knows how* to configure nodes in a
> particular way doesn't mean it *should* configure them that way.  You
> need to fill in the blanks by telling it what configuration to apply to
> each node (or group of similar nodes):
> http://docs.puppetlabs.com/pe/latest/console_classes_groups.html#assigning-classes-and-groups-to-nodes.
> In particular, you may want to look at
> http://docs.puppetlabs.com/pe/latest/console_classes_groups.html#editing-classes-on-nodes
> .
>
> tl;dr: go to the Nodes section of the console, select the master node
> (should be the only one at this point), and edit it to add the desired
> class to its class list.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/_oGm3XIoD7Y/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/9a78af8e-972f-45cb-86b9-9ecfdb1a331d%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2BB_6GaPred7YMYK7%3DBUS8sDPTwEP4ZgnoHTmLCcUnsQT-5r%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet mount and ascii code

[Choon Ming Goh]

Hi all, 

I'm trying to mount a Windows file share on the Linux system. Changing 
names are not possible as per client's policy. I'm trying with the code 
below but presented with errors:

class nas_storage ($username, $password, $domain, $naslocation) { 

#replace the \ with / and whitespace with ascii 040 as fstab does not 
accepts these characters
$nasmount = regsubst(regsubst($naslocation, ' ', '040', 'G'), '\\', 
'/', 'G')

file { '/root/.smb_cred':
  ensure  => file,
  content => 
"username=${username}\npassword=${password}\ndomain=${domain}"
}

mount { 'mount NAS storage':
  ensure  => 'mounted',
  device  => $nasmount,
  fstype  => 'cifs',
  target  => '/mnt',
  options => "auto,credentials=/root/.smb_cred",
}
}

Error: Parameter name failed on Mount[mount NAS storage]: name must not 
contain whitespace: mount NAS storage at 
/etc/puppetlabs/puppet/modules/nas_storage/manifests/init.pp:37
Wrapped exception:
name must not contain whitespace: mount NAS storage

It says that whitespaces are not accepted but in /etc/fstab they do accept 
the \040 as a whitespace replacement. Can anyone enlighten me?

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d62071e2-847e-4725-b0fd-4ed5356b0f75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet mount and ascii code

[Choon Ming Goh]

But when I do a puppet resource mount /mnt -e with the code below, it just 
works. Why would it failed in a puppet agent run but not in a puppet 
resource command?

mount { '/mnt':
  ensure => 'mounted',
  fstype => 'cifs',
  device => '//10.200.206.83/Installation\040Media',
  options=> 'credentials=/root/.smb_cred',
}



On Thursday, May 1, 2014 10:31:46 AM UTC+4, Choon Ming Goh wrote:
>
> Hi all, 
>
> I'm trying to mount a Windows file share on the Linux system. Changing 
> names are not possible as per client's policy. I'm trying with the code 
> below but presented with errors:
>
> class nas_storage ($username, $password, $domain, $naslocation) { 
>
> #replace the \ with / and whitespace with ascii 040 as fstab does not 
> accepts these characters
> $nasmount = regsubst(regsubst($naslocation, ' ', '040', 'G'), '\\', 
> '/', 'G')
> 
> file { '/root/.smb_cred':
>   ensure  => file,
>   content => 
> "username=${username}\npassword=${password}\ndomain=${domain}"
> }
> 
> mount { 'mount NAS storage':
>   ensure  => 'mounted',
>   device  => $nasmount,
>   fstype  => 'cifs',
>   target  => '/mnt',
>   options => "auto,credentials=/root/.smb_cred",
> }
> }
>
> Error: Parameter name failed on Mount[mount NAS storage]: name must not 
> contain whitespace: mount NAS storage at 
> /etc/puppetlabs/puppet/modules/nas_storage/manifests/init.pp:37
> Wrapped exception:
> name must not contain whitespace: mount NAS storage
>
> It says that whitespaces are not accepted but in /etc/fstab they do accept 
> the \040 as a whitespace replacement. Can anyone enlighten me?
>
>

-- 
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 an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/11f29dd8-29cc-4e82-8fd1-60b2b9082be4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.