[Puppet Users] Resource file copy files recurse in existing directory with existing files

[Andreas Dvorak]

Hi,

I have a file resource that brings files in the diretory 
/usr/local/nagios/libexec from source1 and I have a second resource file 
that should bring file in that same directory but from an other source.
But the result is that only the files from   file { 
/usr/local/nagios/libexec: do exit in the directory. I tried remote and 
true. The resource file { /usr/local/nagios/libexec: deletes all the 
files in the directory  /usr/local/nagios/libexec that came with file { 
/usr/local/nagios:
Can somebody please help me?

   file { /usr/local/nagios:
  ensure = directory,
  owner = nagios,
  group = nagios,
  mode = 755,
  source = $source,
  recurse = true,
  require = User ['nagios'],
  schedule = nagios_client-schedule,
   }

   file { /usr/local/nagios/libexec:
  ensure = directory,
  owner = nagios,
  group = nagios,
  mode = 755,
  source = 
puppet:///extra_files/basisapplikationen/monitoring/nagios/client/custom-plugins,
  recurse = remote,
  require = File ['/usr/local/nagios'],
  schedule = nagios_client-schedule,
   }

Best regards
Andreas

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Ignore a failed dependency

[jcbollinger]

On Friday, October 18, 2013 8:07:32 PM UTC-5, Bryan Traywick wrote:

 I have a general question and a specific question that are related.

 The general question: Is it possible to have the dependencies (commands 
 that require) of a command execute even if the command fails? Meaning 
 create a sort of soft dependency where I would like the command to be 
 performed but if it fails execute the things that depend on it anyway.

 Specifically: I have an 'Exec' that runs 'apt-get update'. Several 
 commands 'require' this 'Exec' (e.g. ensuring that a package is installed). 
 However, after an initial provisioning it's not absolutely necessary that 
 'apt-get update' gets run since those packages will be installed already. 
 The 'apt-get update' is failing occasionally due to a slightly unreliable 
 apt repo. I'd like all of the dependent tasks to execute after the 'apt-get 
 update', but still execute even if it fails. Ideally I would like to be 
 able to have an attribute on an 'Exec' (or really any puppet type) that 
 says that it may fail and to just display a warning. As far as I can tell, 
 such a attribute doesn't exist.

 My current thought is to set up a dummy Exec that just runs 'true', but 
 have it notify another Exec that performs the real 'apt-get update'. 
 Something like this (untested):

 exec { apt-get update:
   command = true,
   notify = Exec[real apt-get update]
 }
 
 exec { real apt-get update:
   command = apt-get update
 }

 Will this approach work in the way I intend? Commands that want a soft 
 dependency on apt-get update will `require = Exec[apt-get update]` 
 which will always succeed but as a side effect perform the real apt-get 
 update command. Will the `notify` cause real apt-get update to be 
 performed during every deploy? And will the dependency/ordering graph be 
 built such that real apt-get update gets executed before any of the other 
 commands that `require = Exec[apt-get update]`?

 This also brings up a third question that I thought of while formulating 
 my thoughts for this question: Why are dependency and ordering linked in 
 puppet? It seems to me that ideally there should be a way to specify that 
 command A is performed before command B without making command B depend on 
 command A. For example:

 exec { apt-get update:
   command = true
 }
 exec { real apt-get update:
   command = apt-get update,
   before = Exec[apt-get update]
 }

 I should be able to use before or after to specify ordering and 
 require to specify dependence. If I'm missing something fundamental here 
 about dependencies and ordering (or if I am fighting the paradigm) I'd 
 appreciate the enlightenment.



Puppet will not apply a resource if it depends on another one that fails.  
That is a necessary interpretation of depends on.  If the question even 
arises then the solution is either:

   1. The dependency is artificial, and can safely be removed, or
   2. The dependency must not fail.

You evidently have a variation on (2).  Your problem is that you are 
characterizing the dependency wrongly: it is apparently not that apt-get 
update must run before your resource; rather it is that an *attempt* must 
be made to run that command first.  There are at least two reasonably clear 
ways to express that in Puppet:

exec { 'Attempt apt-get update':
  command = '/path/to/apt-get update || /bin/true',
  provider = 'shell'
}

OR

exec { 'Attempt apt-get update':
  command = '/bin/true',
  unless = '/path/to/apt-get update',
}

Either way, you don't need separate Execs.


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Ignore a failed dependency

[jcbollinger]

On Friday, October 18, 2013 8:07:32 PM UTC-5, Bryan Traywick wrote:

 This also brings up a third question that I thought of while formulating 
 my thoughts for this question: Why are dependency and ordering linked in 
 puppet? It seems to me that ideally there should be a way to specify that 
 command A is performed before command B without making command B depend on 
 command A.



Puppet is not about commands, it is about resources and their state.  An 
application-order dependency expresses the concept that correctly applying 
resource B depends on resource A being in its intended target state.  Thus, 
it follows that resource A must be applied before resource B, *and* that if 
resource A is not applied successfully then resource B cannot be applied 
successfully, either.  Exec resources fit a bit loosely into this model, 
but they do fit, with two states: not run and run.

On the other hand, if applying resource B successfully does not depend on 
the state of resource A, then the relative order in which they are applied 
does not matter.  You can provide an ordering relationship anyway, but 
doing so asserts a false dependency, and you have no room for complaint 
when Puppet behaves as if it were a true one.


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Resource file copy files recurse in existing directory with existing files

[jcbollinger]

On Monday, October 21, 2013 2:37:10 AM UTC-5, Andreas Dvorak wrote:

 Hi,

 I have a file resource that brings files in the diretory 
 /usr/local/nagios/libexec from source1 and I have a second resource file 
 that should bring file in that same directory but from an other source.
 But the result is that only the files from   file { 
 /usr/local/nagios/libexec: do exit in the directory. I tried remote and 
 true. The resource file { /usr/local/nagios/libexec: deletes all the 
 files in the directory  /usr/local/nagios/libexec that came with file { 
 /usr/local/nagios:
 Can somebody please help me?



That sounds like the behavior that would be expected with purge = true.  
I didn't think that was the default, but perhaps you have a resource 
default override in scope.  If you want to purge unmanaged files, then it 
is sufficient to enable purging for only File['/usr/local/nagios']; 
enabling it also for File['/usr/local/nagios/libexec'] (or any other 
subdirectory) will have the result you describe, because the latter 
resource is applied independently of the former.

Overall, it is unwise to manage the same physical resource via more than 
one Puppet logical resources, which is what you are doing with directory 
/usr/local/nagios/libexec.  If you can come up with an alternative approach 
to avoid that problem then you would be better off.


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Resource file copy files recurse in existing directory with existing files

[Andreas Dvorak]

Hi John,

I add purge = false in the file /usr/local/nagios/libexec but it did not 
change anythink.

I need to find out if I can put the files in an other directory.

Thank you
Andreas

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] how to pass the value to custom function?

[Sans]

Dear all,

I'm trying this thing for a while but can't figure out what am I doing 
wrong. 
Here is my sample function (which is similar to the original one, except 
for the hash, which is generated dynamically in the original one):

module Puppet::Parser::Functions
 newfunction(:am_running_oss, :type = :rvalue ) do |args|

 oss = {:linux=[Slackware, RedHat, Caldera],
:mac=[Jaguar, Lion, Tiger, Kodiak],
:win=[Chicago, Daytona, Longhorn]}
 
 cls = args[0] 
 
 if oss.key?(cls)
 return oss[cls][0]
 else
 return 'undefined'
 end
 end
 end


and then in my module's init.pp, I have this:


$h= am_running_oss($::am_os_type)
 notify { =*=*= amRunningOS |:| ${h} =*=*=*=*=*=*=*=: }



(am_os_type is a fact, that returns *win*, *mac* or *linux* based on the 
node type)

I was expecting to see *Jaguar* as the return value but I get 
*undefined*instead. What am I doing wrong? Is there anything still am I missing 
in 
terms of passing the *args* to the  function? Cheers!!

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] FreeBSD / Puppet 3.3.1 problem

[Sean Kelly]

I just upgraded my Puppet master from 3.1 to 3.3.1. It is running via 
Passenger on FreeBSD.In manifests/default.pp, I have:
Package {
provider = portupgrade,
}

This used to work just fine, but is now throwing errors. On the clients, I 
see:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Invalid parameter provider at 
/usr/local/etc/puppet/env/production/modules/portupgrade/manifests/init.pp:10 
on node client
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

On the server, I can get more interesting errors with `puppet master 
--compile`:
smkelly@server:~$ sudo puppet master --compile client
Error: Could not autoload puppet/provider/package/freebsd: undefined method 
`intern' for Puppet::Util::Package:Module
Error: Could not autoload puppet/type/package: Could not autoload 
puppet/provider/package/freebsd: undefined method `intern' for 
Puppet::Util::Package:Module
Error: Could not autoload puppet/type/package: Could not autoload 
puppet/provider/package/freebsd: undefined method `intern' for 
Puppet::Util::Package:Module on node client
Error: Could not autoload puppet/type/package: Could not autoload 
puppet/provider/package/freebsd: undefined method `intern' for 
Puppet::Util::Package:Module on node client
Could not autoload puppet/type/package: Could not autoload 
puppet/provider/package/freebsd: undefined method `intern' for 
Puppet::Util::Package:Module on node client

Any ideas? My ruby force is weak.  Also, I need to manually set the 
provider to portupgrade, as without it it tries to use the pkg_* tools 
which I do not want.

Versions:
puppet-3.3.1
rubygem-facter-1.6.18_2
Master OS: FreeBSD 9.0-RELEASE
Client OS: FreeBSD 9.1-RELEASE-p3

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Puppet dashboard stuck pending jobs

[Julien Nephtali]

I found the solution to my problem here:
http://projects.puppetlabs.com/issues/18411

ALTER TABLE delayed_job_failures MODIFY details BLOB;

that resolved the error.

On Friday, October 11, 2013 7:07:02 AM UTC-4, cko wrote:

 That fixed the problem for me. Thanks.

 On Friday, September 6, 2013 10:21:12 PM UTC+2, Psyber wrote:

 I ran into this as a result of the output of failed deps on a yum 
 install and had a couple jobs that just wouldn't go away. After fixing 
 the condition creating the error I used  /usr/bin/rake jobs:clear to 
 clear out the delayed_job queue and everything was back to normal. 



-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet dashboard stuck pending jobs - MySql Error: Incorrect string value

[Julien Nephtali]

I found the solution to my problem here:
http://projects.puppetlabs.com/issues/18411

ALTER TABLE delayed_job_failures MODIFY details BLOB;

that resolved the error for me.

On Friday, October 4, 2013 7:46:03 AM UTC-4, Julien Nephtali wrote:


 Hi have add issues with stuck pending jobs on my puppet dashboard.

 Here is the error message from my delayed_job.log file in 
 /usr/share/puppet-dashboard/log directory.

 Report.create_from_yaml_file failed with ActiveRecord::StatementInvalid: 
 Mysql::Error: Incorrect string value: '\x96 $bas...' for column 'details' 
 at row 1: INSERT INTO `delayed_job_failures`

 As anyone encountered this error before ?




-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet 3.2: add element to array

[Sergey Arlashin]

Hi!
Is it possible to add a new element to an array inside puppet manifest ? 
Something like ruby's array.push('new_element') ?

--
Best regards,
Sergey Arlashin

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Windows 8.1 Puppet Crashing

[Jason Bray]

I am using the start command prompt with puppet command. I was able to 
verify this happening on both a physical machine and on a vm. 

However, after my initial question, we obtained and installed the release 
version of windows 8.1 and this seems to no longer be an issue. Perhaps 
something funky was happening with Windows 8.1 preview. 

Thanks for your time. 

Jason

On Friday, October 18, 2013 1:24:24 PM UTC-4, Rob Reynolds wrote:

 That is interesting. It appears that the log output is not showing up on 
 your console. What console are you using? Can you verify this is happening 
 on more than one machine?


 On Fri, Oct 18, 2013 at 7:27 AM, Jason Bray jbray...@gmail.comjavascript:
  wrote:

 Well, that is exactly the issue. It doesn't appear to crash in a visible 
 way, there is simply no output for any command I give it. Although, every 
 once in a while, it appears to work normally and shows output as expected. 
 90% of the time, the command hangs for a second or two then returns me to 
 the command prompt with no output whatsoever.

 For example 

 C:\Scratch puppet apply test.pp --debug --verbose --trace

 C:\Scratch


 Actually to make it even weirder, I think I might have been wrong about 
 it crashing. For example when I run a simple manifest, 

 file { 'C:\Scratch\foo.txt':
   ensure = present,
   content = 'bar,
 }

 The command prompt looks like this:

 C:\Scratch puppet apply test.pp --debug --verbose --trace

 C:\Scratch

 However, when I do a dir, I see that the file has indeed been created.


 On Thursday, October 17, 2013 3:48:41 PM UTC-4, Rob Reynolds wrote:

 Jason,
  Sorry, I meant applying a catalog or running something that causes 
 puppet to crash in a visible way. Apologies for the miscommunication.


 On Thu, Oct 17, 2013 at 12:58 PM, Jason Bray jbray...@gmail.com wrote:

  Of course, sorry. 

 Puppet 3.3.1 installed from an MSI, I believe the ruby version is 
 1.9.2, but I'm not 100% on that.

 As for the output, literally it has no output at all.

 For example 

 C:\Scratch puppet help --verbose --debug --trace

 C:\Scratch 

 With only a moment's delay between the two.
  
 -- 
 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-usershttp://groups.google.com/group/puppet-users
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




 -- 
 Rob Reynolds
 Developer, Puppet Labs

 Join us at PuppetConf 2014, September 23-24 in San Francisco
  
  -- 
 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 javascript:.
 To post to this group, send email to puppet...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/puppet-users.
 For more options, visit https://groups.google.com/groups/opt_out.




 -- 
 Rob Reynolds
 Developer, Puppet Labs

 Join us at PuppetConf 2014, September 23-24 in San Francisco
  

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Python 2.7.5 installation with puppet incomplete?

[Jason Bray]

So I downloaded the python 2.7.5 msi from their website: 
http://www.python.org/download/releases/2.7.5/ and installing it manually 
works exactly as one would expect. However, it seems that the puppet 
installation of it does some weird things. My manifest is simple:

package ('Python 2.7.5': 
  ensure = present,
  source = \\file\share\python-2.7.5.msi,
  provider = 'windows',
}

and it certainly runs the install and creates the folders and files I would 
expect. However, it does not appear in the 'Programs and Features' panel 
and cannot be uninstalled by changing ensure to 'absent'. 

Looking at a machine that installed it manually and a machine that 
installed through puppet, one of the things that stood out to me is that 
many of the registry keys found when I search for Python in regedit on the 
manual installation don't show up on the puppet installed version. 

I'm not sure where to start looking.

Thanks for the help!

Jason Bray

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Python 2.7.5 installation with puppet incomplete?

[Jason Bray]

Apologies, this appears to be an issue with python's msi and not with 
puppet.

On Monday, October 21, 2013 4:01:43 PM UTC-4, Jason Bray wrote:

 So I downloaded the python 2.7.5 msi from their website: 
 http://www.python.org/download/releases/2.7.5/ and installing it manually 
 works exactly as one would expect. However, it seems that the puppet 
 installation of it does some weird things. My manifest is simple:

 package ('Python 2.7.5': 
   ensure = present,
   source = \\file\share\python-2.7.5.msi,
   provider = 'windows',
 }

 and it certainly runs the install and creates the folders and files I 
 would expect. However, it does not appear in the 'Programs and Features' 
 panel and cannot be uninstalled by changing ensure to 'absent'. 

 Looking at a machine that installed it manually and a machine that 
 installed through puppet, one of the things that stood out to me is that 
 many of the registry keys found when I search for Python in regedit on the 
 manual installation don't show up on the puppet installed version. 

 I'm not sure where to start looking.

 Thanks for the help!

 Jason Bray


-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet master --compile: extra output?

[John Simpson]

Greetings.

I'm running Puppet 3.3.1. On the server, when I run a command like this:

# puppet master --compile hostname  hostname.json

... the resulting JSON file has an extra line at the top containing:

Notice: Compiled catalog for (hostname) in environment production in 1.09 
secconds

Is there a way to tell it NOT to generate this line? Google is telling me 
nothing useful, and I have trouble believing I'm the first person to notice 
this.

--
John Simpson j...@voalte.com
Unix System/VM Developer and Engineering Operations, Voalte

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] What Do You Test

[Kurt Wall]

Hi everyone,

We are working on enhancing our internal testing so we can improve the 
overall quality of Puppet releases. For example, I am one of two QA 
engineers assigned full-time to testing Puppet's FOSS stack. I'm seeking 
your input and experience to help us identify what we're missing and what 
we can improve. We have an extensive test suite, but there's always room 
for more testing and for better testing.

When a new version of Puppet is released, what do you try out before you 
deploy the it in a production setting? What sorts of behaviors do you test 
before you unleash a new release on unsuspecting machines and users? To 
express it differently, what has bitten you in the past when deploying a 
Puppet release? What makes you wary when installing a new release of Puppet?

Thanks!

Kurt

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: What Do You Test

[Daniele Sluijters]

Hey,

Usually there's about million things that can go wrong but ever since 3.x 
I've really had no issue whatsoever with upgrading releases. This was quite 
a bit different from 2.6/2.7 and I think really speaks to the work the QA 
folks at Puppet Labs are trying to do.

That being said, most issues we had actually stemmed from our own code 
base. Things you know you shouldn't have done but did tend to bite you in 
the ass when you least expect it. I've been able to avoid any major issues 
since 3.x by simply having a sane, fairly well tested, code base. Also a 
good tip, don't patch custom things into Puppet or Hiera etc, that will 
break, eventually.

-- 
Daniele Sluijters

On Monday, 21 October 2013 20:54:13 UTC+2, Kurt Wall wrote:

 Hi everyone,

 We are working on enhancing our internal testing so we can improve the 
 overall quality of Puppet releases. For example, I am one of two QA 
 engineers assigned full-time to testing Puppet's FOSS stack. I'm seeking 
 your input and experience to help us identify what we're missing and what 
 we can improve. We have an extensive test suite, but there's always room 
 for more testing and for better testing.

 When a new version of Puppet is released, what do you try out before you 
 deploy the it in a production setting? What sorts of behaviors do you test 
 before you unleash a new release on unsuspecting machines and users? To 
 express it differently, what has bitten you in the past when deploying a 
 Puppet release? What makes you wary when installing a new release of Puppet?

 Thanks!

 Kurt


-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet 3.2: add element to array

[Daniele Sluijters]

HI,

It should be possible to do something like this:

$users = [a,b,c]
$users += [d,e]

Or, $users = [[a,b,c] [d,e]] etc.

Perhaps a better question, what is it you're trying to do, exactly, that 
you need this?

-- 
Daniele Sluijters

On Monday, 21 October 2013 20:21:18 UTC+2, Sergey Arlashin wrote:

 Hi! 
 Is it possible to add a new element to an array inside puppet manifest ? 
 Something like ruby's array.push('new_element') ? 

 -- 
 Best regards, 
 Sergey Arlashin

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet check ntpd change

[Tony Caffe]

Hi All,

 I am using vms on gogrid and rackspace completely. I am decent but still 
learning puppet. The biggest problem with vms, especially where I cant 
control the Host is ntp time and date sync to be good.

 Here is my config to sync ntp. Please dont tailor my code just help me fix 
the problem. This code works 99% of the servers its on except for 2 centos 
5 machines.

class base {
class { 'timezone':
timezone = 'PST8PDT',
ensure = present,
autoupgrade = true,
}
package { 'ntp':
ensure = installed,
}
service { 'ntpd':
  ensure = running,
  enable = true,
  hasstatus = true,
  hasrestart = true,
}
}

node default {
include base
}


Now when I run puppet agent on these 2 specific vms, it looks fine and 
completes, updates whatever. Well when you run command: *date* it doesnt 
fix the date as it should. I was wondering, is there a way to have puppet 
check that *date* command displays the correct time for that timezone. My 
timezone is Los Angeles/ PDT/ PST.

 I want puppet when completing the run to verify that the time is what PST 
timezone should be and if not, to alert me or something so I know. We have 
had it work a few times but of course, stupid vms fail to keep the time 
perfect. This is why I would like the check. If not worth doing or possible 
in Puppet, any Nagios plugins good for this that you have set up before? or 
any other solution?

 FYI, *class timezone* is a template I got for ntp and seems to update 
tzdata.

Thanks in advance,

Tony.

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Status of Data in modules

[Eric Sorenson]

Another round of thanks for the replies to this thread. I apologize that 
almost as soon as I posted it, I got pulled off onto another project and 
wasn't able to follow up until now. Replies inline below, and there are 
probably a couple more coming to different branches (damn I miss Usenet 
threading!)

John Bollinger wrote:
  We agree on most of what you said, but it doesn't seem very responsive 
 to 
  the comments to which they ostensibly reply.  I am in no way arguing 
  against the idea of the data in modules subsystem.  It is a fantastic 
 idea, 
  and long past due.  I *am* concerned, however, about the new approach 
 Eric 
  proposed.  I suggested a more general approach than (my understanding 
 of) 
  the one he described, one not tied specifically to ::params classes. 
  Inasmuch as you disfavor ::params classes, I would think that you would 
  find much to like about my counterproposal.  Indeed, I think my proposal 
 is 
  very much like the original prototype you floated.


John I didn't see a more detailed description of what you're proposing; is 
this section (quoted from upthread) what you're referring to?

Do I understand correctly that you set out to get rid of the ::params class 
 pattern, but now you favor an approach that depends on that pattern?  


Heh, well when you put it that way...
 

 Why is that better than being more general: enable an implicit 
 lowest-priority hierarchy level for values of form 'modulename::variable', 
 drawing on data from per-module data files such as 
 modules/modulename/data.yaml?


If I understand this correctly this is slightly different (and probably 
inadequate from RI's standpoint), because it just adds another 'category' 
(in the ARM-9 sense) to the end of each lookup, and what RI and others 
propose is to have another _complete hiera invocation_ inside the module 
owning a class parameter's namespace the end of each unsuccessful 
site-hiera lookup. Separate hiera.yaml config file with its own hierarchy 
defined, and a tree of data files. (params.pp does this by letting 
old-school puppet DSL logic determine your hierarchy)

I also talked to a user today who wants data from modules (by doing hash 
key merge on a parameter's class::subclass::varname) from *any* module in 
the modulepath to contribute, say, sudoers rules to the sudo module from 
other site-written modules that require particular sudoers stanzas. So I'm 
trying to consider how to pull all of this together without making a O(n^n) 
complexity explosion.
 


 RI replied:
 Your comments are good and addressed in later replies, especially related 
 to 
 data mangling.  This is a common problem in all languages, data almost 
 never 
 arrives in the final form and all programming languages have patterns for 
 retrieving data, validating and mangling it.  We just need to introduce 
 similar patterns.   


This is really interesting, and not something that's come up so far 
AFAIK. It ties in somewhat to https://projects.puppetlabs.com/issues/20199 
 , needing a way to indicate the data type of something that's looked up 
implicitly with data bindings, but introduces another layer around 
retrieving and modifying data as it flows back towards puppet, which I 
hadn't considered.  That is what the code-in-data people are asking for, 
like https://github.com/puppetlabs/hiera/pull/152 that ended up with 
arbitrary puppet functions inside hiera curly brace expansion.  Would love 
thoughts on how to do that in a generally useful, lightweight way.
 

 I, obviously, share your concern with the current round of proposals. 
  Data 
 in module querying only params.pp is literally the worst possible 
 suggestion 
 one can make in this regard.  It would be a massive step backward. Might 
 as 
 well just go ahead and unmerge hiera if the goal is to not learn anything 
 from 
 its design and incredibly wide adoption. 


Oh surely there's way worse suggestions out there  :)
 

  I do think it is a mistake to focus on eliminating all need for ::params 
  classes as a goal of the initiative, however.  Likely *most* need for 
 them 
  can be redirected to a relatively simple data-in-modules subsystem, and 
  that would be well, but the initiative does not fail if some need for 
 the 
  ::params class pattern remains. 

 

 yeah, as per the other replies - eliminate *storing data* in params.pp but 
 validate/mangle in something like params.pp.  That is in the event that 
 no-one delivers a layer of data validation around data bindings and hiera. 


So it doesn't seem helpful to get data-bindings integration via puppet 
code, even as a first step?

I definitely agree hiera data in general needs a way to do validation, but 
the semantics you described of requiring an integer between 10 and 20 
would be additional complexity on top of Henrik's type system. (That work 
was foundational BTW, not specific to the data-in-modules binder as you 
said up-thread, so it can be reused independently of ARM-9)

--eric0

-- 

Re: [Puppet Users] request for /proc/cpuinfo examples from aix, hpux, kfreebsd, non-x86 linux

[Joshua Hoblitt]

It's been a week and I haven't gotten a single response.  Does anyone
actually use those platforms? :)

-Josh

--
On 10/13/2013 02:41 PM, Joshua Hoblitt wrote:
 Hi Folks,

 I'm looking at tidying up the way /proc/cpuinfo is parsed in facter and
 the in tree fixture examples for any kernel other than linux i386/amd64
 are pretty sparse.  This is makes refactoring hairy as there are regexps
 and other assumptions baked into the code for these formats without any
 comments or test coverage. Examples for these platforms [which appear
 to] support cpuinfo would be immensely helpful:

 * aix
 * hpux
 * kfreebsd
 * linux
 - parisc
 - hppa
 - ia64
 - ppc64
 - arm
 - sparc

 My PR to migrate the existing in tree examples to
 facter/spec/fixtures/cpuinfo/ was recently merged and I believe
 everything under that path is a Linux example.  I'd like to move all of
 those examples again to ../cpuinfo/linux and start introducing examples
 for other kernels under facter/spec/fixtures/cpuinfo/kernel/.

 Thanks,

 -Josh

 --


-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.