Re: [Puppet Users] Code coverage for puppet resources

[Chris Denneen]

Looks like there are few issues open like these:

https://github.com/rodjek/rspec-puppet/issues/285

https://github.com/rodjek/rspec-puppet/issues/158

If anyone knows a way in Rakefile to exclude from coverage I'd be greatful. 

-- 
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/0498fd9f-abec-44de-aaac-e7d2076730dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] FreeBSD 8.x: Warning: Found multiple default providers for package: pkgng, freebsd; using pkgng

[Dan Mahoney]

Hey there,

Puppet 3.8.1 under FreeBSD 8.x (yes, I know it's EOL).

I'm seeing the following warning when my manifest runs:

Warning: Found multiple default providers for package: pkgng, freebsd; 
using pkgng


I've set a provider in site.pp (and verified that that portion of the 
manifest has been loading):


if $::operatingsystem == 'FreeBSD' {
  Package { provider => 'pkgng' }
}

But the warning persists.  It's defaulting to use the provider that I 
want, so this is totally harmless.  Clearly, setting that provider doesn't 
stop the warning that there's multiple *default* ones.


Is there any way, within my manifest (not the code) to say "ignore the 
FreeBSD provider" (which uses classic FreeBSD packages), which are at this 
point totally unsupported.


I've seen several other reported bugs involving this error, some of which 
cause debian package managers to show up under FreeBSD -- so I guess 
whenever I'm seeing this, it's a bug?


-Dan Mahoney

--


Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

[Puppet Users] puppet-agent package on FreeBSD

[Dan Mahoney]

All,

I keep seeing updates about a new release of a standalone puppet agent.

Other than small file size and a possible reduced dependency set, is there 
any useful point in porting it to FreeBSD?


Right now, on FreeBSD, pkg shows the following subset of things for a "pkg 
search puppet" (there are other things that aren't relevant, like a Nagios 
plugin and the like):


puppet37-3.7.5_1   Configuration management framework written 
in Ruby
puppet38-3.8.4_1   Configuration management framework written 
in Ruby
puppet4-4.4.1  Configuration management framework written 
in Ruby

puppetdb-2.3.8_1   PuppetDB storeconfigs backend
puppetdb-terminus-2.3.4_1  PuppetDB storeconfigs backend terminus 
module
puppetdb-terminus4-4.0.0   PuppetDB storeconfigs backend terminus 
module

puppetdb4-4.0.0PuppetDB storeconfigs backend
puppetserver-2.2.1 Puppet Server running in the JVM

None of these version numbers seem to align with the things I see being 
announced here -- do the packages being built here basically include the 
agent?


We have lots of nodes where we don't need a full puppet server, but I 
don't know how much code that would actually save.  (Disk is cheap)


-Dan

--


Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

Re: [Puppet Users] Removing unmanaged path /etc/puppetlabs/code/environments/ - r10k

[Michael Watters]

I actually take the opposite approach.  Modules from the forge go in a 
directory named "forge_modules" and r10k will leave anything located in 
modules alone.

 From r10k.yaml:

forge 'http://forge.puppetlabs.com'
moduledir 'forge_modules'



On Friday, June 17, 2016 at 5:28:42 PM UTC-4, Rob Nelson wrote:
>
> r10k will deploy the modules listed in the Puppetfile into the modules 
> directory. If you need some local (to the controlrepo) modules that are not 
> deployed from the Puppetfile, the recommendation is to add them to a 
> directory called site, dist, or similar, and create a file called 
> environment.conf that says:
>
> modulepath = site:modules:$basemodulepath
>
> This allows the contents of the site directory (within the repo), modules 
> (populated by r10k) and the $basemodulepath (set via puppet.conf or 
> defaults, oftentimes unused) to all be valid module locations without r10k 
> or other automation stepping all over it. 
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Fri, Jun 17, 2016 at 4:56 PM, Ali  
> wrote:
>
>>
>> r10k deployment is failing, if  my repo paths has  "modules"  in it .   
>> if I change modules to any other word or even module it works fine .  In 
>> order to correctly map environment on my puppet master I need r10k to map 
>> repo as /etc/puppetlabs/code/environments/production [branch name ] / 
>> modules/ modulename .  Trying to figure out where is conflict any help will 
>> be appreciated . 
>>
>> *repo server :*
>>
>> [gitcodereposerver coderepo]# ls -la
>> total 16
>> drwxr-x--- 4 root root 4096 Jun 17 16:35 .
>> drwxr-x--- 7 root root 4096 Jun 15 15:43 ..
>> drwxr-x--- 8 root root 4096 Jun 17 16:35 .git
>> drwxr-x--- 3 root root 4096 Jun 17 16:35 modules
>>
>>
>> gitcodereposerver coderepo]# git branch -v
>>   development ad420ad test
>> * production  ad420ad test
>>
>>
>>
>> *puppet master:* 
>>
>>
>>
>> puppetmaster r10k]# cat r10k.yaml
>> ---
>> sources:
>>   main:
>> remote: 'root@gitcodereposerver:/home/pupp/coderepo'
>> basedir: '/etc/puppetlabs/code/environments'
>>
>>
>>  puppetmaster]#r10k deploy environment -pv
>> INFO -> Deploying environment /etc/puppetlabs/code/environments/
>> development
>> INFO -> Environment development is now at 
>> a20646d68ed3259e3ae6eeda6c31dfca9f9ab9f0
>> INFO -> Deploying environment /etc/puppetlabs/code/environments/
>> production
>> INFO -> Environment production is now at 
>> c73bcc40b41373d87908093035be58e60fc2ea29
>> INFO -> Removing unmanaged path /etc/puppetlabs/code/environments/
>> production/modules/compliance
>>
>>
>> no compliance folder under modules  as shown below .
>>
>> puppetmaster environments]# ls
>> development  production
>> [ environments]# cd production/
>> [ production]# ls
>> modules
>> [ production]# cd modules/
>> [modules]# ls
>>
>>
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/f0b9c4e2-a90a-4b3e-ab75-094592e457d0%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/2f81ed5f-f975-47b9-9781-81eaf2149a13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Removing unmanaged path /etc/puppetlabs/code/environments/ - r10k

[Rob Nelson]

r10k will deploy the modules listed in the Puppetfile into the modules
directory. If you need some local (to the controlrepo) modules that are not
deployed from the Puppetfile, the recommendation is to add them to a
directory called site, dist, or similar, and create a file called
environment.conf that says:

modulepath = site:modules:$basemodulepath

This allows the contents of the site directory (within the repo), modules
(populated by r10k) and the $basemodulepath (set via puppet.conf or
defaults, oftentimes unused) to all be valid module locations without r10k
or other automation stepping all over it.


Rob Nelson
rnels...@gmail.com

On Fri, Jun 17, 2016 at 4:56 PM, Ali  wrote:

>
> r10k deployment is failing, if  my repo paths has  "modules"  in it .   if
> I change modules to any other word or even module it works fine .  In order
> to correctly map environment on my puppet master I need r10k to map repo as
> /etc/puppetlabs/code/environments/production [branch name ] / modules/
> modulename .  Trying to figure out where is conflict any help will be
> appreciated .
>
> *repo server :*
>
> [gitcodereposerver coderepo]# ls -la
> total 16
> drwxr-x--- 4 root root 4096 Jun 17 16:35 .
> drwxr-x--- 7 root root 4096 Jun 15 15:43 ..
> drwxr-x--- 8 root root 4096 Jun 17 16:35 .git
> drwxr-x--- 3 root root 4096 Jun 17 16:35 modules
>
>
> gitcodereposerver coderepo]# git branch -v
>   development ad420ad test
> * production  ad420ad test
>
>
>
> *puppet master:*
>
>
>
> puppetmaster r10k]# cat r10k.yaml
> ---
> sources:
>   main:
> remote: 'root@gitcodereposerver:/home/pupp/coderepo'
> basedir: '/etc/puppetlabs/code/environments'
>
>
>  puppetmaster]#r10k deploy environment -pv
> INFO -> Deploying environment /etc/puppetlabs/code/environments/
> development
> INFO -> Environment development is now at
> a20646d68ed3259e3ae6eeda6c31dfca9f9ab9f0
> INFO -> Deploying environment /etc/puppetlabs/code/environments/
> production
> INFO -> Environment production is now at
> c73bcc40b41373d87908093035be58e60fc2ea29
> INFO -> Removing unmanaged path /etc/puppetlabs/code/environments/
> production/modules/compliance
>
>
> no compliance folder under modules  as shown below .
>
> puppetmaster environments]# ls
> development  production
> [ environments]# cd production/
> [ production]# ls
> modules
> [ production]# cd modules/
> [modules]# ls
>
>
>
> 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/f0b9c4e2-a90a-4b3e-ab75-094592e457d0%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/CAC76iT8Ljh1dZmGdvSW3_NSMyu_5aKGm4KvR7M1CRDRh1D%3DB%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Removing unmanaged path /etc/puppetlabs/code/environments/ - r10k

[Ali]

r10k deployment is failing, if  my repo paths has  "modules"  in it .   if 
I change modules to any other word or even module it works fine .  In order 
to correctly map environment on my puppet master I need r10k to map repo as 
/etc/puppetlabs/code/environments/production [branch name ] / modules/ 
modulename .  Trying to figure out where is conflict any help will be 
appreciated . 

*repo server :*

[gitcodereposerver coderepo]# ls -la
total 16
drwxr-x--- 4 root root 4096 Jun 17 16:35 .
drwxr-x--- 7 root root 4096 Jun 15 15:43 ..
drwxr-x--- 8 root root 4096 Jun 17 16:35 .git
drwxr-x--- 3 root root 4096 Jun 17 16:35 modules


gitcodereposerver coderepo]# git branch -v
  development ad420ad test
* production  ad420ad test



*puppet master:* 



puppetmaster r10k]# cat r10k.yaml
---
sources:
  main:
remote: 'root@gitcodereposerver:/home/pupp/coderepo'
basedir: '/etc/puppetlabs/code/environments'


 puppetmaster]#r10k deploy environment -pv
INFO -> Deploying environment /etc/puppetlabs/code/environments/
development
INFO -> Environment development is now at 
a20646d68ed3259e3ae6eeda6c31dfca9f9ab9f0
INFO -> Deploying environment /etc/puppetlabs/code/environments/
production
INFO -> Environment production is now at 
c73bcc40b41373d87908093035be58e60fc2ea29
INFO -> Removing unmanaged path /etc/puppetlabs/code/environments/
production/modules/compliance


no compliance folder under modules  as shown below .

puppetmaster environments]# ls
development  production
[ environments]# cd production/
[ production]# ls
modules
[ production]# cd modules/
[modules]# ls



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/f0b9c4e2-a90a-4b3e-ab75-094592e457d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet only partially applying configuration

[Rob Reynolds]

On Tue, Jun 7, 2016 at 12:15 PM, Andrew  wrote:

> I have encountered a problem when running puppet on Windows. My
> environment is as follows:
>
> Puppet master:
> CentOS 6.5
> puppetserver 2.3.1
>
> Client:
> Windows 2012 R2
> Puppet 3.8.7
>
> What happens:
>
> I provision a machine with razor and wait for the first Puppet run to
> complete. After puppet is finished, most resources from the manifests have
> been applied, but not all. I have looked in the local catalog, and the
> unapplied resources are present in the catalog. I can let Puppet run
> automatically as many times as I wish, and the resources will not be
> applied. However, if I open PowerShell or cmd and run "puppet agent -t" the
> remaining resources get applied as I would expect. There are some Puppet
> errors in the Windows event viewer, but they are not errors for the
> unapplied resources, and I do not do anything to address these errors
> before I run Puppet manually, so they seem unrelated.
>


It would be good to get what you can provide for examples of things not
applied and what the output of --debug --trace --verbose into a log (minus
any sensitive data of course).

Some general things to consider:


   - The Puppet service by default runs under SYSTEM, and puppet agent -t
   is running under the context of the user.
   - The Puppet service is running with administrative permissions by
   default. You should also be running cmd.exe/PowerShell in an administrative
   (elevated) shell.




>
> Any help would be greatly appreciated.
>
> --
> 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/7658784c-5e04-4eb3-8c8c-e10d02de613e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet


PuppetConf 2016 , October 17-21, San Diego,
California
*Early Birds save $350*

-
Register by June 30th

-- 
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/CAMJiBK6adBP9S6%3DgGeK1%2BnKqcaz-w8doCg1hqRBb1HHOu8K99A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] clean msi installs on windows -- removing .msi file after

[Rob Reynolds]

You could set up a file resource with  ensure => absent and set up a
relationship[1] to ensure it is checked after the MSI install. Another
thing you would also look at with respect to Windows software management is
Chocolatey[2][3].


[1]
https://docs.puppet.com/puppet/latest/reference/lang_relationships.html#syntax-relationship-metaparameters
[2] https://chocolatey.org/docs/getting-started#what-are-chocolatey-packages
[3] https://forge.puppet.com/puppetlabs/chocolatey

On Tue, May 17, 2016 at 3:43 PM, KC Johnson  wrote:

> I'm new to  puppet, trying to find a way to do MSI installs but ensure the
> installer file is removed afterwards. Any tricks on this?
>
> --
> 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/c06e4f27-2f0b-46c0-b11f-1dc7bfd98e12%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet


PuppetConf 2016 , October 17-21, San Diego,
California
*Early Birds save $350*

-
Register by June 30th

-- 
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/CAMJiBK4NYnOHZYed-Tb8PQ2UeHGuXOsJwhUs-_s%2B9zNDf9bdaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: [Puppet Users] Basic syntax and learning problems

[Edward Ned Harvey (puppet)]

> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Peter Bukowinski
> 
> Fortunately, facter has separate facts for most items in the os fact hash.
> Keep in mind you can see all the facts available to your client by running
> ‘sudo facter -p’

Thanks. That was very helpful.  :-)

 
> The easiest way to install files into a particular user’s home directory (if 
> the
> path to that directory is consistent across all your machines) is to create a
> package that does it for you. Then you can use puppet to ensure that the
> package is installed without it having to worry about the particulars.

Hmmm... If the directory is consistent across all the machines, I can just 
hard-code the path into puppet. For now, that's what I've done, but I look 
forward to learning a better way (or look forward to upgrading our environment, 
so I can hopefully use $facts in the future. But I'm not entirely sure $facts 
would contain the info I want anyway).

Thanks for your 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/BY1PR0401MB125571B74961B1959417E235DC570%40BY1PR0401MB1255.namprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: [Puppet-dev] Re: Modules Triage Time Change

[Hunter Haugen]

>> For those of you in APAC, we apologize for the still-inconvenient time
>> slot. Feel free to reply here with ideas!
>>
>>
>  I just talked to Hunter on IRC. Maybe we can flip flop the times of the
> meeting. For example 9:00UTC and the next week 17:00UTC. This would allow
> us a kind of US meeting and a Europe Meeting. The amount of contributors
> grows, especially in Europe. Maybe this will allow more people to join.
>

The 9:00UTC would be convenient for APAC & EMEA, and 17:00UTC for EMEA &
Americas. I think that would cover all interested parties, and even give a
few options to some.

-- 
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/CAJaQvGB%3DrZkA1%3D%2BUmtaLFAB7ebJBuapp%2B1rUD_LXqbieei4PNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Basic syntax and learning problems

[Peter Bukowinski]

>> On Jun 17, 2016, at 9:50 AM, Edward Ned Harvey (puppet) 
>>  wrote:
>> 
>> From: puppet-users@googlegroups.com [mailto:puppet-
>> us...@googlegroups.com] On Behalf Of Peter Bukowinski
>> 
>> Hi Edward,
>> 
>> With puppet 3.7, all facts are "stringified" by default, meaning hashes are
>> flattened to strings. If you've got facter 2.0 or greater, you can change 
>> this
>> behavior do you can access hash keys individually.
> 
> Thanks very much for the help. Unfortunately, I'm learning, and working, in 
> an environment with several hundred machines in production using puppet. I 
> can't really expect to upgrade or reconfigure the environment. All I'm trying 
> to do is ensure some ssh files exist in a particular user's home directory, 
> so I thought I would use $facts to determine if the user exists, and get 
> their home directory path, and create the files in there.
> 
> Is there a way to parse the $os string into a hash, so I can access its 
> members? (Besides wanting to access users' home directories, it would also be 
> useful to just get the OS major number, for a different purpose.) I tried 
> parsejson(), but it doesn't like the => instead of :, and it didn't seem 
> right to substitute : for =>. I figured there *should* be a way to parse the 
> string the right way.
> 
> If not via $facts, how else would puppet put some files into a user's home 
> directory?

Fortunately, facter has separate facts for most items in the os fact hash. Keep 
in mind you can see all the facts available to your client by running ‘sudo 
facter -p’. Here are the facts you can use to directly access some of the facts 
in the os hash.

# facter os
{"name"=>"Ubuntu", "family"=>"Debian", "release"=>{"major"=>"13.10", 
"full"=>"13.10"}, "lsb"=>{"distcodename"=>"saucy", "distid"=>"Ubuntu", 
"distdescription"=>"Ubuntu 13.10", "distrelease"=>"13.10", 
"majdistrelease"=>"13.10”}}

# facter osfamily
Debian

# facter lsbmajdistrelease
13.10

# facter lsbdistcodename
saucy


The easiest way to install files into a particular user’s home directory (if 
the path to that directory is consistent across all your machines) is to create 
a package that does it for you. Then you can use puppet to ensure that the 
package is installed without it having to worry about the particulars.

-- 
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/55109213-7A87-4BA1-8705-137BA3F0D072%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How to have a Puppet module install a particular version of something (docker, for instance)

[David Karr]

I'm stepping through "Puppet for Containerization 
".
  
The very first exercise fails to start up the docker service, apparently 
because of an invalid command-line option ("-d") sent to docker in the 
systemd service description.  This is being done by the "garethr/docker" 
Puppet module from the forge. I determined that this was happening because 
the exercise was specifying a somewhat older version of the module, and 
simply changing the Puppetfile to use the newer version fixed the problem.  
Apparently this option used to be valid in an older version of docker, but 
had since been removed.

It occurred to me that this situation likely happened because the Puppet 
module was written a while ago, and it likely just specified to install the 
latest version of docker.

What I'd like to understand, at least in the scope of this particular 
module (https://github.com/garethr/garethr-docker), and perhaps in general, 
what exactly is a "best practice" for specifying an exact version of a 
dependency to install, as I likely wouldn't have seen this error if the 
module installed a specific version of Docker that this was known to work 
with.

I did search through the code of the module, but although seeing that 
perhaps 
https://github.com/garethr/garethr-docker/blob/f1f701c5d4845c6dbb85d817d99a4cf9b0c2edae/manifests/params.pp
 
is where this might go, I didn't see a clear answer for how this might have 
been changed to do that.

Just so it's clear, I'm not suggesting that this change should be made in 
this particular module, but if I did have a module that had to work with a 
particular version of one or more dependencies, understanding how this 
module would be changed to effect that might be a good guide in the future.

-- 
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/dbac3102-c2ec-4d26-8f71-7a51e992eeac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Modules Triage Time Change

['Tim Meusel' via Puppet Users]

Am Donnerstag, 26. Mai 2016 18:31:35 UTC+2 schrieb Hunter Haugen:
>
> Hello,
>
> tl;dr Puppet Modules Community Triage meeting is moving to 17:00-18:00 UTC
>
> This is a quick note that in the last Puppet Modules Community Triage 
> meeting we discussed a change in the specified time that the meeting 
> happens.
>
> For those of you who are curious about what the triage meeting is, every 
> Thursday at 10:00 Pacific Time the Puppet modules team get on a public 
> video chat (https://bluejeans.com/280736660/) and go over any tickets or 
> pull requests or any other module-related questions you might have. So want 
> to chat about any of the puppetlabs (or even voxpupuli) modules, then come 
> join us today!
>
> So the current time that the meeting happens is 10:00 Pacific Time. The 
> meeting is a fairly international meeting so we want to move it to UTC and 
> given time slots of either 16:00-17:00 or 17:00-18:00 we chose the 
> 17:00-18:00 slot. This means it's still the SAME TIME until daylight 
> savings ends at which point it will be 9:00 PST... see why timezones suck?
>
> For those of you in APAC, we apologize for the still-inconvenient time 
> slot. Feel free to reply here with ideas!
>
> Cheers,
> -Hunter
>

 I just talked to Hunter on IRC. Maybe we can flip flop the times of the 
meeting. For example 9:00UTC and the next week 17:00UTC. This would allow 
us a kind of US meeting and a Europe Meeting. The amount of contributors 
grows, especially in Europe. Maybe this will allow more people to join.

-- 
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/9b356595-131b-40b3-aaa3-ba371e6ecb96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [Puppet Users] Basic syntax and learning problems

[Edward Ned Harvey (puppet)]

> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Peter Bukowinski
> 
> Hi Edward,
> 
> With puppet 3.7, all facts are "stringified" by default, meaning hashes are
> flattened to strings. If you've got facter 2.0 or greater, you can change this
> behavior do you can access hash keys individually.

Thanks very much for the help. Unfortunately, I'm learning, and working, in an 
environment with several hundred machines in production using puppet. I can't 
really expect to upgrade or reconfigure the environment. All I'm trying to do 
is ensure some ssh files exist in a particular user's home directory, so I 
thought I would use $facts to determine if the user exists, and get their home 
directory path, and create the files in there.

Is there a way to parse the $os string into a hash, so I can access its 
members? (Besides wanting to access users' home directories, it would also be 
useful to just get the OS major number, for a different purpose.) I tried 
parsejson(), but it doesn't like the => instead of :, and it didn't seem right 
to substitute : for =>. I figured there *should* be a way to parse the string 
the right way.

If not via $facts, how else would puppet put some files into a user's home 
directory?

-- 
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/BY1PR0401MB1255B6B060E898E3A5B23A8DDC570%40BY1PR0401MB1255.namprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Code coverage for puppet resources

[Chris Denneen]

Well for example if i use your puppet-module-skeleton... create a module 
that uses the rspec-puppet-facts for centos 5,6,7.
include ::selinux (jfryman/selinux)
in coverage report it shows the following missing:

 Package[policycoreutils-devel]

 Package[policycoreutils-python]

 Package[policycoreutils]


first is for 7, second for 6, and third for 5 major releases.

While I can test for these in my _spec test I'd rather only be testing that 
class_selinux is included and any parameters I might be using against it. 
or maybe even the selinux::module or selinux::boolean resources that I 
might be setting... 


should hopefully be a pretty simple test to reproduce but it's definitely 
not excluding those resources if that's what that merge was intended for.



On Friday, June 17, 2016 at 11:37:40 AM UTC-4, garethr wrote:
>
> On 17 June 2016 at 15:24, Chris Denneen  
> wrote: 
> > Gareth, 
> > 
> > I know this thread is old but do you have a way in the Rakefile to 
> exclude 
> > the dependent modules? 
> > For example dependent modules that include different package resources 
> based 
> > on OSfamily and version are something that module controls and tests I 
> just 
> > need to make sure that the module is included in my catalog and any 
> defined 
> > types used in my module get tested. (dependentmodule::resource['foo']) 
> > I've seen some other posts hacking rspec coverage.rb which probably 
> isn't 
> > good (https://github.com/rodjek/rspec-puppet/issues/364). 
> > I've noticed the filtered?(resource) in rspec-puppet just documented of 
> how 
> > to implement. 
> > Hopefully you can help here. 
> > 
>
> I _think_ the coverage support now does this by default? 
>
> Anything from fixtures should now be ignored. 
> https://github.com/rodjek/rspec-puppet/pull/258 
>
> Other folks have made a whole bunch of improvements to the coverage 
> support in rspec-puppet since I added it. 
>
> Gareth 
>
> > Thanks 
> > 
> > On Friday, February 7, 2014 at 5:54:06 AM UTC-5, garethr wrote: 
> >> 
> >> On 7 February 2014 02:51, gh  wrote: 
> >> > On 1/26/14 7:50 AM, Gareth Rushgrove wrote: 
> >> >> For anyone else who likes writing tests for their puppet manifests, 
> >> >> I've just added basic code coverage to rspec-puppet: 
> >> >> 
> >> >> A blog post here about how to use it: 
> >> >> 
> >> >> 
> >> >> 
> http://www.morethanseven.net/2014/01/25/code-coverage-for-puppet-modules/ 
> >> >> 
> >> >> I'd be interested in any feedback on how to improve or add to this. 
> >> >> 
> >> >> Cheers 
> >> >> 
> >> >> Gareth 
> >> >> 
> >> > 
> >> > Gareth, 
> >> > 
> >> > Great blog post. I tried this on a module with 100% coverage and 
> notice 
> >> > that it reports back 50% coverage. After some poking around, found 
> that 
> >> > it is checking code in spec/fixtures/, the stdlib module actually. 
> There 
> >> > seems to be an open issue[1] regarding the inability to exclude 
> things. 
> >> > Curious if you found a work around for testing your code and not the 
> >> > modules pulled in from .fixtures.yml. 
> >> > 
> >> 
> >> Currently the rspec-puppet coverage stuff does check coverage across 
> >> all resources, including those from dependent modules. For example 
> >> this module depends on the puppetlabs/apt module - 
> >> https://travis-ci.org/garethr/garethr-nginx/jobs/18133670#L113 
> >> 
> >> I purposefully didn't add too much configuration to the first pass of 
> >> the code, but it would be simple to add some options to ignore 
> >> specific modules (I think). I thought I'd wait to see if anyone found 
> >> it useful first. 
> >> 
> >> Gareth 
> >> 
> >> > [1] - https://github.com/lemurheavy/coveralls-public/issues/184 
> >> > 
> >> > BR, 
> >> > -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...@googlegroups.com. 
> >> > To view this discussion on the web visit 
> >> > 
> https://groups.google.com/d/msgid/puppet-users/52F44A2E.3070903%40garretthoneycutt.com.
>  
>
> >> > For more options, visit https://groups.google.com/groups/opt_out. 
> >> 
> >> 
> >> 
> >> -- 
> >> Gareth Rushgrove 
> >> @garethr 
> >> 
> >> devopsweekly.com 
> >> morethanseven.net 
> >> garethrushgrove.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 view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/2d63d692-f837-42da-a44e-c5b73dbfa015%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Gareth Rushgrove 
> @garethr 
>
> devopsweekly.com 
> morethanseven.net 
> garethrushgrove.com 
>

-- 

Re: [Puppet Users] Basic syntax and learning problems

[Peter Bukowinski]

Hi Edward,

With puppet 3.7, all facts are "stringified" by default, meaning hashes are 
flattened to strings. If you've got facter 2.0 or greater, you can change this 
behavior do you can access hash keys individually.

https://docs.puppet.com/puppet/3.7/reference/lang_facts_and_builtin_vars.html#data-types

Be sure to also read the next section below the one I linked for some gotchas. 
Also, if you want to access $facts as a hash, make sure to set he option notes 
here:

https://docs.puppet.com/puppet/3.7/reference/lang_facts_and_builtin_vars.html#the-factsfactname-hash

-- Peter (from phone)

> On Jun 17, 2016, at 8:42 AM, Edward Ned Harvey (puppet) 
>  wrote:
> 
> Running puppet 3.7.4
> 
> I am new to puppet, and learning the syntax. For learning, I open up two 
> terminals, where I "vi foo.pp" in one terminal, and I "puppet apply foo.pp" 
> on the other terminal.
> 
> Using this:
> node default {
>notify{"syntax1":
>message => $facts['osfamily']
>}
> }
> 
> I got this result:
> Error: facts is not a hash or array when accessing it with osfamily at 
> /root/foo.pp:3 on node...
> 
> So then, using this:
> node default {
>notify{"syntax1":
>message => $facts
>}
> }
> 
> I get this result:
> Notice: /Stage[main]/Main/Node[default]/Notify[syntax1]/message: defined 
> 'message' as 'syntax1'
> 
> Question 1: Why can't I access $facts?
> 
> So I wondered if maybe facts weren't available because I'm running "puppet 
> apply" instead of "puppet agent -t" but when I look here:
> https://docs.puppet.com/puppet/3.7/reference/lang_facts_and_builtin_vars.html
> 
> They say "Before requesting a catalog (or compiling one with puppet apply), 
> Puppet will collect system information with Facter. Puppet receives this 
> information as facts..."
> 
> So I would expect $facts to be available.
> 
> Using this:
> node default {
>notify{"syntax1":
>message => $os
>}
> }
> 
> I get this result:
> Notice: /Stage[main]/Main/Node[default]/Notify[syntax1]/message: defined 
> 'message' as '{"name"=>"RedHat", "family"=>"RedHat", 
> "release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2"}}'
> 
> So it seems, yes, at least *some* facts are available.
> 
> Using this:
> node default {
>notify{"syntax1":
>message => $os['name']
>}
> }
> 
> I get this:
> Error: os is not a hash or array when accessing it with name at 
> /root/foo.pp:3 on node ...
> 
> Question #2: What's wrong with my syntax to access the OS name? I would 
> expect to be able to access $os['release']['major'] to get the result "7"
> 
> -- 
> 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/BY1PR0401MB1255B576DD0E2274E7825A2EDC570%40BY1PR0401MB1255.namprd04.prod.outlook.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/3405DEFF-AE12-4A4F-9620-A8BDCF74997F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Basic syntax and learning problems

[Edward Ned Harvey (puppet)]

Running puppet 3.7.4

I am new to puppet, and learning the syntax. For learning, I open up two 
terminals, where I "vi foo.pp" in one terminal, and I "puppet apply foo.pp" on 
the other terminal.
 
Using this:
node default {
notify{"syntax1":
message => $facts['osfamily']
}
}

I got this result:
Error: facts is not a hash or array when accessing it with osfamily at 
/root/foo.pp:3 on node...

So then, using this:
node default {
notify{"syntax1":
message => $facts
}
}

I get this result:
Notice: /Stage[main]/Main/Node[default]/Notify[syntax1]/message: defined 
'message' as 'syntax1'

Question 1: Why can't I access $facts?

So I wondered if maybe facts weren't available because I'm running "puppet 
apply" instead of "puppet agent -t" but when I look here:
https://docs.puppet.com/puppet/3.7/reference/lang_facts_and_builtin_vars.html

They say "Before requesting a catalog (or compiling one with puppet apply), 
Puppet will collect system information with Facter. Puppet receives this 
information as facts..."

So I would expect $facts to be available.

Using this:
node default {
notify{"syntax1":
message => $os
}
}

I get this result:
Notice: /Stage[main]/Main/Node[default]/Notify[syntax1]/message: defined 
'message' as '{"name"=>"RedHat", "family"=>"RedHat", "release"=>{"major"=>"7", 
"minor"=>"2", "full"=>"7.2"}}'

So it seems, yes, at least *some* facts are available.

Using this:
node default {
notify{"syntax1":
message => $os['name']
}
}

I get this:
Error: os is not a hash or array when accessing it with name at /root/foo.pp:3 
on node ...

Question #2: What's wrong with my syntax to access the OS name? I would expect 
to be able to access $os['release']['major'] to get the result "7"

-- 
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/BY1PR0401MB1255B576DD0E2274E7825A2EDC570%40BY1PR0401MB1255.namprd04.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Code coverage for puppet resources

[Gareth Rushgrove]

On 17 June 2016 at 15:24, Chris Denneen  wrote:
> Gareth,
>
> I know this thread is old but do you have a way in the Rakefile to exclude
> the dependent modules?
> For example dependent modules that include different package resources based
> on OSfamily and version are something that module controls and tests I just
> need to make sure that the module is included in my catalog and any defined
> types used in my module get tested. (dependentmodule::resource['foo'])
> I've seen some other posts hacking rspec coverage.rb which probably isn't
> good (https://github.com/rodjek/rspec-puppet/issues/364).
> I've noticed the filtered?(resource) in rspec-puppet just documented of how
> to implement.
> Hopefully you can help here.
>

I _think_ the coverage support now does this by default?

Anything from fixtures should now be ignored.
https://github.com/rodjek/rspec-puppet/pull/258

Other folks have made a whole bunch of improvements to the coverage
support in rspec-puppet since I added it.

Gareth

> Thanks
>
> On Friday, February 7, 2014 at 5:54:06 AM UTC-5, garethr wrote:
>>
>> On 7 February 2014 02:51, gh  wrote:
>> > On 1/26/14 7:50 AM, Gareth Rushgrove wrote:
>> >> For anyone else who likes writing tests for their puppet manifests,
>> >> I've just added basic code coverage to rspec-puppet:
>> >>
>> >> A blog post here about how to use it:
>> >>
>> >>
>> >> http://www.morethanseven.net/2014/01/25/code-coverage-for-puppet-modules/
>> >>
>> >> I'd be interested in any feedback on how to improve or add to this.
>> >>
>> >> Cheers
>> >>
>> >> Gareth
>> >>
>> >
>> > Gareth,
>> >
>> > Great blog post. I tried this on a module with 100% coverage and notice
>> > that it reports back 50% coverage. After some poking around, found that
>> > it is checking code in spec/fixtures/, the stdlib module actually. There
>> > seems to be an open issue[1] regarding the inability to exclude things.
>> > Curious if you found a work around for testing your code and not the
>> > modules pulled in from .fixtures.yml.
>> >
>>
>> Currently the rspec-puppet coverage stuff does check coverage across
>> all resources, including those from dependent modules. For example
>> this module depends on the puppetlabs/apt module -
>> https://travis-ci.org/garethr/garethr-nginx/jobs/18133670#L113
>>
>> I purposefully didn't add too much configuration to the first pass of
>> the code, but it would be simple to add some options to ignore
>> specific modules (I think). I thought I'd wait to see if anyone found
>> it useful first.
>>
>> Gareth
>>
>> > [1] - https://github.com/lemurheavy/coveralls-public/issues/184
>> >
>> > BR,
>> > -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...@googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/puppet-users/52F44A2E.3070903%40garretthoneycutt.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> Gareth Rushgrove
>> @garethr
>>
>> devopsweekly.com
>> morethanseven.net
>> garethrushgrove.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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2d63d692-f837-42da-a44e-c5b73dbfa015%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAFi_6yKS57JXfBCxKm8Bi%2BWUgyTU3xWch%2BM_eoec-WAUapFkjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Code coverage for puppet resources

[Chris Denneen]

Gareth,

I know this thread is old but do you have a way in the Rakefile to exclude 
the dependent modules?
For example dependent modules that include different package resources 
based on OSfamily and version are something that module controls and tests 
I just need to make sure that the module is included in my catalog and any 
defined types used in my module get tested. 
(dependentmodule::resource['foo'])
I've seen some other posts hacking rspec coverage.rb which probably isn't 
good (https://github.com/rodjek/rspec-puppet/issues/364).
I've noticed the filtered?(resource) in rspec-puppet just documented of how 
to implement.
Hopefully you can help here.

Thanks

On Friday, February 7, 2014 at 5:54:06 AM UTC-5, garethr wrote:
>
> On 7 February 2014 02:51, gh  
> wrote: 
> > On 1/26/14 7:50 AM, Gareth Rushgrove wrote: 
> >> For anyone else who likes writing tests for their puppet manifests, 
> >> I've just added basic code coverage to rspec-puppet: 
> >> 
> >> A blog post here about how to use it: 
> >> 
> >> 
> http://www.morethanseven.net/2014/01/25/code-coverage-for-puppet-modules/ 
> >> 
> >> I'd be interested in any feedback on how to improve or add to this. 
> >> 
> >> Cheers 
> >> 
> >> Gareth 
> >> 
> > 
> > Gareth, 
> > 
> > Great blog post. I tried this on a module with 100% coverage and notice 
> > that it reports back 50% coverage. After some poking around, found that 
> > it is checking code in spec/fixtures/, the stdlib module actually. There 
> > seems to be an open issue[1] regarding the inability to exclude things. 
> > Curious if you found a work around for testing your code and not the 
> > modules pulled in from .fixtures.yml. 
> > 
>
> Currently the rspec-puppet coverage stuff does check coverage across 
> all resources, including those from dependent modules. For example 
> this module depends on the puppetlabs/apt module - 
> https://travis-ci.org/garethr/garethr-nginx/jobs/18133670#L113 
>
> I purposefully didn't add too much configuration to the first pass of 
> the code, but it would be simple to add some options to ignore 
> specific modules (I think). I thought I'd wait to see if anyone found 
> it useful first. 
>
> Gareth 
>
> > [1] - https://github.com/lemurheavy/coveralls-public/issues/184 
> > 
> > BR, 
> > -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...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/52F44A2E.3070903%40garretthoneycutt.com.
>  
>
> > For more options, visit https://groups.google.com/groups/opt_out. 
>
>
>
> -- 
> Gareth Rushgrove 
> @garethr 
>
> devopsweekly.com 
> morethanseven.net 
> garethrushgrove.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2d63d692-f837-42da-a44e-c5b73dbfa015%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: check if the package is installed and compare the version

[puppetstan]

Ithank you

I understand, I do not use puppet as he would really


Le vendredi 17 juin 2016 11:23:45 UTC+2, puppetstan a écrit :
>
> Hi,
>
>
> I'm not an expert on puppet and I have some syntax problems
>
>
> I would check if the package is installed and compare the version of the 
> package with the version I would like to see installed
>
>
> IF the package is installed with the correct version DO NOTHING
>
> BUT if it is not installed or installed but not the correct version, 
> uninstall it and download the right package with the right version and 
> install
>
>
> I started to do something that is not terrible and I would like your help 
> to answer my problem
>
>
> thank you very much in advance
>
>
> here is the beginning of what I've done
>
>
> if package { 'xyz' ensure=> '1.2'}
> do nothing
>
> else {
> exec => rpm -e xyp-packagebadversion
>
>
> file { "/tmp/xyz-packagegoodversion":
>ensure => 'present',
>source => "puppet:///modules/package/xyz-packagegoodversion"
> }
> package { "xyz":
> ensure => '1.2',
> provider => 'rpm',
> source => "/tmp/xyz-packagegoodversion"
> }
>
>

-- 
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/8a17c930-e7c6-4a8d-b6b1-908be5645fdb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue copying files if package exists

[Helmut Schneider]

Rob Nelson wrote:

> Modeling state can be tricky. It's pretty easy for a human to
> understand conditionals like "If a package is installed, install a
> file," but for state modeling, resources are best defined as either
> managed or unmanaged, not somewhere in between. It's important to
> keep this in mind when modeling state. You can always, of course,
> "beat" the computer and figure out a workaround, but you're losing
> out on the strengths of the CM tool you have chosen.

I think I found a way around without losing the strengths:

if "$sshdPackage" in hiera_array ('packages', []) {
  do_something
}

This at least fits for me. I also tried to tag packages:

define install_packages ($package = $title) {
  [...]
  tag "Hello"

  if tagged("Hello") {
notify { "TAGGED 'Hello'": }
  }
}

This works within the define but not outside

class fail2ban {
  if tagged("Hello") {
notify { "TAGGED 'Hello'": }
  }
}

does not output anything allthough install_packges is involved.

-- 
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/xn0k7cvqc53aszx000%40news.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] check if the package is installed and compare the version

[Gareth Rushgrove]

HI Stanislas

On 17 June 2016 at 10:23, puppetstan  wrote:
> Hi,
>
>
> I'm not an expert on puppet and I have some syntax problems
>
>
> I would check if the package is installed and compare the version of the
> package with the version I would like to see installed
>
>
> IF the package is installed with the correct version DO NOTHING
>
> BUT if it is not installed or installed but not the correct version,
> uninstall it and download the right package with the right version and
> install
>

Puppet as a language is declarative, rather than imperative. So the
package resource actually does exactly what you describe here.

package { "xyz":
  ensure => '1.2',
}

The above would, if it finds xyz installed at version 1.2 do nothing.
If it's not installed, or installed at a previous version, it will
update the package to the specified version.

Gareth

>
> I started to do something that is not terrible and I would like your help to
> answer my problem
>
>
> thank you very much in advance
>
>
> here is the beginning of what I've done
>
>
> if package { 'xyz' ensure=> '1.2'}
> do nothing
>
> else {
> exec => rpm -e xyp-packagebadversion
>
>
> file { "/tmp/xyz-packagegoodversion":
>ensure => 'present',
>source => "puppet:///modules/package/xyz-packagegoodversion"
>
> }
>
> package { "xyz":
> ensure => '1.2',
> provider => 'rpm',
> source => "/tmp/xyz-packagegoodversion"
> }
>
> --
> 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/4835a155-1a2c-4857-b0a4-090dd1a28657%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAFi_6y%2Bndr33VBAXcK4nnZZTcyn3orV%3DsLZB8F4tv%3DNFFA9mow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] check if the package is installed and compare the version

[puppetstan]

Hi,


I'm not an expert on puppet and I have some syntax problems


I would check if the package is installed and compare the version of the 
package with the version I would like to see installed


IF the package is installed with the correct version DO NOTHING

BUT if it is not installed or installed but not the correct version, 
uninstall it and download the right package with the right version and 
install


I started to do something that is not terrible and I would like your help 
to answer my problem


thank you very much in advance


here is the beginning of what I've done


if package { 'xyz' ensure=> '1.2'}
do nothing

else {
exec => rpm -e xyp-packagebadversion


file { "/tmp/xyz-packagegoodversion":
   ensure => 'present',
   source => "puppet:///modules/package/xyz-packagegoodversion"
}
package { "xyz":
ensure => '1.2',
provider => 'rpm',
source => "/tmp/xyz-packagegoodversion"
}

-- 
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/4835a155-1a2c-4857-b0a4-090dd1a28657%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble creating a release RPM from puppetlabs/puppet source repo

[Andrew]

Matt, take the src rpm that suits your needs.

`mkdir -p rpm/{RPMS/x86_64,RPMS/noarch,SRPMS,SPECS,SOURCES,BUILD,BUILDROOT}`
rpmbuild --rebuild puppet[whatever].srpm

hit ctrl-c before it finishes. This will leave the .spec file and the 
source tarball in the SPECS and SOURCES dirs respectively.

cd SPECS
edit the puppet.spec file to suit (remove ruby-rgen, add rubygems-rgen, 
whatever)

rpmbuild -bb puppet.spec
# watch magic happen.

fish the built rpm files out of RPMS/noarch dir

Although I think it's kinda silly exercise from a secutiry pov, because the 
security nazis dont understand the code anyway ...
I do hear what you are saying about having to go thru this exercise.

Cheers,
Andrew.


On Monday, 13 June 2016 22:45:12 UTC+10, Matt Larson wrote:

> Eric et al,
>
> Thanks again for your help with this!  I realize how crazy it may seem to 
> want to rebuild from source.  My company has become so paranoid of open 
> source software due to recent events, that the infosec team now requires us 
> to vet (as if that's feasible) FOSS source code before bringing in.  Since 
> starting this post, however, I was able to convince the team to bring in 
> the PC1 repo.
>
> As someone else has suggested to me, I will have to revisit with Vanagon 
> and/or the src RPM in the future.   I would like to know how to build these 
> though, so I'll revisit one day for sure. 
>
> Cheers,
> Matt
>
> On Thursday, June 9, 2016 at 3:55:49 PM UTC-4, Eric Sorenson wrote:
>>
>> Matt, I would like to understand this better and help you adopt Puppet 
>> into your environment.
>>
>> This is not a rhetorical question, but it might sound like one: Do you 
>> rebuild your linux distribution from source RPMs? Because that is very 
>> similar to what the AIO Puppet agent bundle is: a mini distribution with 
>> the dependencies ending up in one artifact.
>>
>> People outside Puppet can (and have) successfully rebuilt AIO, and there 
>> are also sucessful packaging efforts that take JUST the Puppet 4 source and 
>> build a standalone RPM from it in the manner of the puppet 3 packages:
>>
>> puppet-4.2.1-3.fc24.src.rpm 
>> 
>>
>> But our recommendation is to use the all-in-one obviously; it's what's 
>> tested extensively and what ships in puppet enterprise. 
>>
>> --eric
>>
>> On Wednesday, June 8, 2016 at 2:01:43 AM UTC-7, Matt Larson wrote:
>>>
>>> Sorry for not getting back soon, Dan.
>>>
>>> Good question.
>>>
>>> I work for a draconian company that only allows installing FOSS after 
>>> our infosec team has vetted the source code and then built from source; an 
>>> impossible hand-waving exercise, I know... but it is what it is.
>>>
>>> On Friday, June 3, 2016 at 2:51:10 PM UTC-4, LinuxDan wrote:

 First Silly Question: Why ?
 What do you need to do that cannot be done with the RPM's from a 
 Puppetlabs repo ?

 Dan White | d_e_...@icloud.com
 
 “Sometimes I think the surest sign that intelligent life exists elsewhere 
 in the universe is that none of it has tried to contact us.”  (Bill 
 Waterson: Calvin & Hobbes)


 On Jun 03, 2016, at 02:44 PM, Matt Larson  wrote:


 I'm trying to create an RPM from source on a stock RHEL6-based 
 (CentOS6) instance, but I'm seeing errors.  I also posted in 
 https://ask.puppet.com/question/26388/trouble-creating-a-release-rpm-from-puppetlabspuppet-source-repo/
  

 The output actually gets pretty far along, but stops at with this 
 error: "install: cannot stat ext/redhat/puppet.conf: no such file or 
 directory". If I fix that problem by manually editing the SPEC file, I 
 just 
 get more errors, so clearly there is no need to go down a rabbit hole 
 since 
 this must work for someone else, right?

 I'm also posted in 
 https://ask.puppet.com/question/26388/trouble-creating-a-release-rpm-from-puppetlabspuppet-source-repo/

 Ideas?

 Thanks in Advance,
 Matt


 -- 
 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 view this discussion on the web visit 
 https://groups.google.com/d/msgid/puppet-users/8d532582-be4b-4e58-813e-0e3519043a3f%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