[Puppet Users] Re: Upgrading to Puppet 4 - what about the modules

[mobios]

>
> As i updated to puppet 4 i had to modify my modules to be puppet 4 ready.
>
 
   For example:

   All custom defines need to be in there own manifest and cant be included 
in other manifests. 

   Regards
   mobios

-- 
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/48dfcc0e-93ab-461a-b59e-9068d8f291fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Which version of Puppet am I using?

[Sans]

Dear all,

I was just trying to install Puppet v3.8.7 with PuppetDB v3.2.4: 

root@e115-s-pmaster-001:/# dpkg -s puppet|grep -i version
Version: 3.8.7-1puppetlabs1
Config-Version: 3.8.7-1puppetlabs1
#
root@e115-s-pmaster-001:/# dpkg -s puppetdb|grep -i version
Version: 3.2.4-1puppetlabs1

but puppet --version reports v4.10.0:

root@e115-s-pmaster-001:/# puppet --version
4.10.0

FYI, my initial/main issue started with configuration value for vardir and 
ssldir, as reported by puppet. Puppet should have used this (according to 
puppet.conf):

root@e115-s-pmaster-001:/# egrep '(vardir|ssldir)=' /etc/puppet/puppet.conf
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl 

but puppet reports a different location:

root@e115-s-pmaster-001:/# puppet config print vardir ssldir
vardir = /opt/puppetlabs/puppet/cache
ssldir = /etc/puppetlabs/puppet/ssl

But I have a feelings that the config mismatch got something to do with 
version mismatch as well. Anyone here to help?

-San 

-- 
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/cb19e886-f04a-4cc6-8734-562c985921a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Upgrading to Puppet 4 - what about the modules

[Rob Nelson]

Generally speaking, modules created for Puppet 3 are likely to work in
puppet 4 without changes. Of course, that's not to say that all will, you
will have to test and make sure yourself since the module author has not.

However, if a module on the forge does not support puppet 3 by now, that
may be a warning sign that development has stalled or the module has been
migrated to another namespace. You should attempt to discover if either are
the case, so you can plan accordingly - there's no guarantee a module
designed for Puppet 3 that is incidentally compatible with Puppet 4 will
also be compatible with future versions of puppet 5, and a lack of bug
fixes may be problematic as well. Something to explore, anyway.

On Wed, May 3, 2017 at 9:44 PM Ugo Bellavance  wrote:

> Hi,
>
> I'm currently running a puppet 3 server that serves about 20 puppet 3
> clients.  I use a number of modules, and most of them are not compatible
> with puppet 4.  There is at least one module that is not compatible with
> puppet 4. Is puppet 4 backwards compatible somehow or do we need to have
> all our modules puppet 4-ready before upgrading?
>
> Thanks,
>
> Ugo
>
> --
> 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/fc974974-b393-46d9-a5f2-4670ccd7d686%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Rob Nelson

-- 
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/CAC76iT_SKf9kHiz1cPg%3D9s3XkXHBNBeGaqdk%3Di4rAhnVKVERkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Upgrading to Puppet 4 - what about the modules

[Ugo Bellavance]

Hi,

I'm currently running a puppet 3 server that serves about 20 puppet 3 
clients.  I use a number of modules, and most of them are not compatible 
with puppet 4.  There is at least one module that is not compatible with 
puppet 4. Is puppet 4 backwards compatible somehow or do we need to have 
all our modules puppet 4-ready before upgrading?

Thanks,

Ugo

-- 
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/fc974974-b393-46d9-a5f2-4670ccd7d686%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppetlabs-inifile versus sudoers

[Warron French]

James, thanks for the reply.  I didn't actually receive this message in my 
Gmail mailbox for some reason.  I logged into groups.google.com and found 
that you had replied.

Anyway, now that I have read your input, I will mull it all over in my head.

Thanks again,
Warron

On Friday, April 28, 2017 at 9:45:38 AM UTC-4, James Perry wrote:
>
> As I have very recently dug into modifying sudoers myself, you may want to 
> look at the saz/sudo module at Puppet Forge.   It allows you to do a lot of 
> different methods to create a sudoers file that fits the supported OS. 
>
> If you want to just do edits, you may want to look at the stdlib - 
> file_line type. There are examples for it that show sudoers specifically.  
>
> In my environment I am using the file_line with a matcher with a regular 
> expression to change the directory colors from dark blue to the lighter 
> blue.  
>
> class os_config::ls_dir_color ($dir_default_color = '01;34') {
>   # This is used to change the DIR color from dark blue to a brighter blue 
> to
>   # see it on a black background
>   # It will use the file_line
>   include stdlib
>
>   file_line { 'dir_colors':
> path=> '/etc/DIR_COLORS',
> line=> "DIR ${dir_default_color} # directory",
> match   => '^DIR\s*.*',
> replace => true,
>   }
>
> For sudoers you could do that to check if the line already exists to 
> remove it with ensure => absent or add it with ensure => present. Since I'm 
> using Foreman as a front-end to Puppet I use the smart parameters that I 
> can override on a host by host basis when needed.  Here is a pseudo code 
> snippet that may do something like what you want.
>
> class sudo::add_dba_perm ($ensure = 'present', $dba_perm_line = '%dba 
> ALL=ALL NOPASSWD: ALL') {
>   include stdlib
>
>   file_line { 'sudo_dba':
> path=> '/etc/sudoers',
> ensure => $ensure,
> line=> $dba_perm_line,
> match   => '^%dba\s*.*',
> replace => true,
>   }
>
> Now I haven't coded or tested the above, but theoretically something coded 
> along these lines should work. As I don't yet have a full grasp on doing 
> defines and create_resources, I have to stay basic in my coding. 
>
> Hope this helps. 
>
> On Wednesday, April 26, 2017 at 10:14:34 PM UTC-4, Warron French wrote:
>>
>> Does it make sense to use the puppetlabs-inifile module when trying to 
>> modify the /etc/sudoers file?
>>
>> From my observations, the /etc/sudoers file isn't exactly laid out in an 
>> ini-stylized configuration; like the /etc/smb.conf is.
>>
>> Comments welcomed.
>> --
>> Warron French
>>
>>

-- 
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/72e03cc1-b85e-418c-bbca-c2f58107c611%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Parameterized classes vs defined-types

[Lesley Kimmel]

I've [somewhat] recently started developing Puppet modules for use with 
Foreman and have gone through a couple iterations. At first I was 
developing a large, broadly-scoped module for a specific purpose. I soon 
found that in order to provide any amount of customizable behavior I would 
have to provide so many parameters that it was unwieldy.

Therefore, I moved into using much more purpose-specific modules (e.g. 
sshd, aide, chrony, etc). These modules provide a lot of flexibility but 
then you lose the centralized view of the things the configuration items 
for a specific application or workflow require. 

I recently came across some modules on the Forge that got me considering 
using modules with defined types exposing their functionality. I think this 
seems to be the ultimate way to do things because it allows the same 
flexibility as the purpose-specific module setup while essentially 
requiring you to have another module for your application or workflow which 
utilizes the defined types from all of your defined type augmented modules.

However, I would very much prefer an all or none solution. That is I don't 
want to have defined type modules for pieces of a workflow but have to 
directly configure parameters on other modules for other pieces of my 
workflow. Unfortunately, the module availability on the Forge seems to be 
about 50/50 at best (that is maybe half the modules are built with defined 
types). Also, the use of defined types, at least when dealing with config 
files, essentially means using either Augeas or Concat. For complex 
configuration files this can often be quite difficult (which I think is why 
many people default to templates). 

So, in order to use the defined type route it would seem that one needs to 
invest a lot of time in developing custom modules. It seems easier and not 
much worse to just settle for purpose-scecific parameterized modules. This 
has the side effect of giving a better centralized view of all the 
configurations applicable to a given process or library. 

I'm very interested in hearing about other peoples' experiences and 
recommendations. 

On Tuesday, August 23, 2011 at 1:00:04 PM UTC-5, Digant C Kasundra wrote:
>
> Out of curiosity, how are people using parameterized classes in a way that 
> is distinct from defined-types?
>
> -- 
> Digant C Kasundra >
> Infrastructure Systems Software Developer, ITS:IDG, Stanford University
>

-- 
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/a8333100-022b-4d65-806b-6cf028a50a6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] if / case loop syntax help

[Henrik Lindberg]

On 03/05/17 18:28, Samir Gahirwal wrote:

Thanks for your help Rob!

Yes even, I have second doubts about if statement, I will find some
other way to fix this conditional statement.



You probably want:

  if !($env == 'test' or $env == 'qa) {
 #
  }

i.e. "neither of", which you can also write as

  unless $env == 'test' or $env == 'qa' {
  }

Or do the reverse and move the logic you have in the "else" part to the 
if part and drop the "not".


i.e.

  if $env == 'test' or $env == 'qa {
# what you have in else body
  } else {
# what you now have in if body
  }

That is much easier to read.



On Wednesday, May 3, 2017 at 6:21:52 AM UTC-7, Rob Nelson wrote:

I think some characters got gobbled during pasting or by Google
Groups; it looks like the parameter block to your type is missing
the start/finish. But that's syntax, I'm sure you've got it right or
can fix any typos yourself.

The suggestion I have is about a common anti-pattern: Don't Repeat
Yourself (DRY). You have two exec resource declarations, only of
which is instantiated, with the same parameter list for both. The
only difference is interpolation of the password, which is set
inside the control flow. Moving the exec instantiation *after* the
conditional blocks helps with maintenance in the long term, but also
makes it easier for someone to read your code later (including
future you!) and see that the end result is a single resource. That
would look something like this:

||
|
|
define certificate-generator (


You cannot use hyphens ('-') in names. Change to use underscore for 
example "certificate_generator".


Best,
- henrik


  user =>root,
  group=>root,
) {
  if($env !='test'or$env !='qa'){
case$::target_cert_type {
  'type1':{
$password ='123'
  }
  'type2':{
$password ='345'
  }
  default:{
fail("No password defined")
  }
}
  }
  else{
case$::target_cert_type {
  'type1':{
$password ='567'
  }
  'type2':{
$password ='789'
  }
  default:{
fail("No password defined ")
  }
}
||  }

  # Single exec resource here with variable inputs determined above
||  exec{"certificate-generator":
command =>'sh certgen.sh',
path=>'/bin/bash',
logoutput =>true,
onlyif => "test ! -f ${cert_basedir}/${host}.jks"
source =>"puppet:///modules/mymodule/certgen/certgen.sh $password"
  }
}
|
|

I still have a concern about your if statements, though. If `env` is
`prod`, it obviously matches for ||if($env !='test'or$env !='qa')||.
But if `env` is `qa`, it STILL matches because ||$env !='test'
|| is true and it never reaches the ||$env !='qa'|| comparison. And
if it's `test`, it still matches because after failing the first
test, it passes the second test. The `else` condition is never
reached that I can see. Changing that to an AND match, or using
equality and swapping the if/else blocks, appears closer to the
described desired state.



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/oedi86%24i02%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet online user study - config file manipulations

[Bernhard Denner]

Hello Puppet community,

As part of my master thesis, I've developed a module [1] 
(puppet-libelektra) to partially modify configuration files of different 
formats on a key value basis, similar to "ini_setting" or "augeas". Behind 
the scenes I'm using the Elektra configuration library [2].

To evaluate the usability of this module compared to other Puppet file 
manipulation methods, I have designed a software experiment. 
This experiment consist of 4 different programming tasks and gives you a 
good opportunity to directly compare the usability of resource types such 
as 'file', 'host', 'ini_setting', 'augeas' or 'kdbkey' (the new one) in 
different scenarios.

The experiment is designed to allow you a participation from your own 
machine (requires Linux with Docker).

All you need to do is: follow the instructions found on 
https://github.com/BernhardDenner/puppet-userstudy-controller

I would be very happy if you participate in this study.
If you need help or have any questions do not hesitate to send me an email. 

The results of this study will help us to improve the puppet-libelektra 
module.

Thanks,
Bernhard Denner

[1] https://github.com/ElektraInitiative/puppet-libelektra
[2] https://www.libelektra.org

-- 
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/33963334-4fe1-45d0-9806-a86ae5998d09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] if / case loop syntax help

[Samir Gahirwal]

Thanks for your help Rob! 

Yes even, I have second doubts about if statement, I will find some other 
way to fix this conditional statement. 


On Wednesday, May 3, 2017 at 6:21:52 AM UTC-7, Rob Nelson wrote:
>
> I think some characters got gobbled during pasting or by Google Groups; it 
> looks like the parameter block to your type is missing the start/finish. 
> But that's syntax, I'm sure you've got it right or can fix any typos 
> yourself.
>
> The suggestion I have is about a common anti-pattern: Don't Repeat 
> Yourself (DRY). You have two exec resource declarations, only of which is 
> instantiated, with the same parameter list for both. The only difference is 
> interpolation of the password, which is set inside the control flow. Moving 
> the exec instantiation *after* the conditional blocks helps with 
> maintenance in the long term, but also makes it easier for someone to read 
> your code later (including future you!) and see that the end result is a 
> single resource. That would look something like this:
>
> define certificate-generator (
>   user => root,
>   group => root,
> ) {
>   if ( $env != 'test' or $env != 'qa') {
> case $::target_cert_type {
>   'type1': {
> $password = '123'
>   }
>   'type2': {
> $password = '345'
>   }
>   default: {
> fail("No password defined")
>   }
> }
>   }
>   else {
> case $::target_cert_type {
>   'type1': {
> $password = '567'
>   }
>   'type2': {
> $password = '789'
>   }
>   default: {
> fail("No password defined ")
>   }
> }
>   }
>
>   # Single exec resource here with variable inputs determined above
>   exec { "certificate-generator":
> command => 'sh certgen.sh',
> path=> '/bin/bash',
> logoutput => true,
> onlyif =>  "test ! -f ${cert_basedir}/${host}.jks"
> source => "puppet:///modules/mymodule/certgen/certgen.sh $password"
>   }
> }
>
> I still have a concern about your if statements, though. If `env` is 
> `prod`, it obviously matches for if ( $env != 'test' or $env != 'qa'). 
> But if `env` is `qa`, it STILL matches because $env != 'test'
> is true and it never reaches the $env != 'qa' comparison. And if it's 
> `test`, it still matches because after failing the first test, it passes 
> the second test. The `else` condition is never reached that I can see. 
> Changing that to an AND match, or using equality and swapping the if/else 
> blocks, appears closer to the described desired state.
>

-- 
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/b207bbc1-8ca7-4fce-886e-96edc7230557%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] lvm module help

[dkoleary]

Hey, all;

I'm having some trouble getting the lvm module to work the way I think it 
should based on my probable erroneous reading of the documentation.

I would like to ensure a logical volume of 2gs is created in vg00 which has 
plenty of free space to handle the lv creation.  I've been using this link 
as the guide:  

https://github.com/puppetlabs/puppetlabs-lvm

I'm using the puppetforge lvm module.

Hiera data looks like:

---
lvm::volume_groups:
  vg00:
createonly: true
physical_volumes:
  /dev/sda2:
unless_vg: 'vg00'
logical_volumes:
  audit:
size: 2G

I get this error when running on a test box:

# puppet agent -t
Notice: Local environment: 'production' doesn't match server specified node 
environment 'dkoleary', switching agent to 'dkoleary'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Evaluation Error: Error while evaluating a Resource Statement, 
Lvm::Volume_group[vg00]: has no parameter named 'createonly' on node 
myhost.mydomain.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

If i comment the hiera data and specify the parameters directly in the 
class, it works:

# == Class: lvm
#
  
class lvm { 


  physical_volume { '/dev/sda2':
ensure=> present,
unless_vg => 'vg00',
  } 


  volume_group { 'vg00':
ensure   => present,
physical_volumes => '/dev/sda2',
createonly   => true,
  } 


  logical_volume { 'audit':
ensure   => present,
size => '2G',
volume_group => 'vg00',
  } 
} 
#==
# original init.pp code
#==
# class lvm (
#   $package_ensure = 'installed',
#   $manage_pkg = undef,
#   $volume_groups  = {},
# ) {
#
#   if $manage_pkg {
# package { 'lvm2':
#   ensure   => $package_ensure
# }
#   } 
#
#   validate_hash($volume_groups)
#
#   create_resources('lvm::volume_group', $volume_groups)
# }   
#==

results in:

# puppet agent -t
Notice: Local environment: 'production' doesn't match server specified node 
environment 'dkoleary', switching agent to 'dkoleary'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for cl1vproegit1395.multiplan.com
Info: Applying configuration version '149382'
[[ Misc der'mo snipped]]
Notice: /Stage[main]/Lvm/Logical_volume[audit]/ensure: created

Notice: Applied catalog in 94.15 seconds


# lvs vg00 |grep audit
  auditvg00 -wi-a- 2.00g   

I'd appreciate any hints/tips/suggestions on what I might be doing wrong.

Thanks for your time.

Doug O'Leary




-- 
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/0d36fdbf-bbe5-4191-8da8-6da283f7e47d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet facter utf-8 error

[mobios]

  Thank for your reply Rob

I checked on the the puppetserver the file encoding
>
   
file windows_firewallrules.rb 

   and the encoding was ASCII text.

 It seems the encoding is in right format :(
   

-- 
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/00ac28e4-7bff-4491-8737-7db0491f446c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] if / case loop syntax help

[Rob Nelson]

I think some characters got gobbled during pasting or by Google Groups; it 
looks like the parameter block to your type is missing the start/finish. 
But that's syntax, I'm sure you've got it right or can fix any typos 
yourself.

The suggestion I have is about a common anti-pattern: Don't Repeat Yourself 
(DRY). You have two exec resource declarations, only of which is 
instantiated, with the same parameter list for both. The only difference is 
interpolation of the password, which is set inside the control flow. Moving 
the exec instantiation *after* the conditional blocks helps with 
maintenance in the long term, but also makes it easier for someone to read 
your code later (including future you!) and see that the end result is a 
single resource. That would look something like this:

define certificate-generator (
  user => root,
  group => root,
) {
  if ( $env != 'test' or $env != 'qa') {
case $::target_cert_type {
  'type1': {
$password = '123'
  }
  'type2': {
$password = '345'
  }
  default: {
fail("No password defined")
  }
}
  }
  else {
case $::target_cert_type {
  'type1': {
$password = '567'
  }
  'type2': {
$password = '789'
  }
  default: {
fail("No password defined ")
  }
}
  }

  # Single exec resource here with variable inputs determined above
  exec { "certificate-generator":
command => 'sh certgen.sh',
path=> '/bin/bash',
logoutput => true,
onlyif =>  "test ! -f ${cert_basedir}/${host}.jks"
source => "puppet:///modules/mymodule/certgen/certgen.sh $password"
  }
}

I still have a concern about your if statements, though. If `env` is 
`prod`, it obviously matches for if ( $env != 'test' or $env != 'qa'). But 
if `env` is `qa`, it STILL matches because $env != 'test'
is true and it never reaches the $env != 'qa' comparison. And if it's 
`test`, it still matches because after failing the first test, it passes 
the second test. The `else` condition is never reached that I can see. 
Changing that to an AND match, or using equality and swapping the if/else 
blocks, appears closer to the described desired state.

-- 
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/dfcd053a-bf94-4572-b65d-280a31f26cf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet facter utf-8 error

[Rob Nelson]

Is there a chance the encoding on the file containing the custom fact
itself is not UTF8? It won't matter if the output is UTF-8 if Puppet can't
parse it to apply the code inside it. `file ` usually starts with
`ASCII` or `UTF-8 Unicode` if it's in the proper format.


Rob Nelson
rnels...@gmail.com

On Wed, May 3, 2017 at 7:37 AM, mobios  wrote:

> Hello Puppet User,
>
>
> Infos:
> Puppet-client-version = 3.8.4
> facter= 2.4.4
>
> Puppetserver = 4.10.0
>
>
> I wrote a fact to discover all firewallrules on a windows machine.
> Factname is windows_firewallrules.rb and returnvalue is a nested hash.
>
>
> if i execute following command.
>
> facter -p windows_firewallrules
>
> I can see all firewallrules correctly. But if i execute
>
> puppet agent -tdv
>
>
> I get a  error and the puppetrun stops.
>
> Errormessage:
> invalid byte sequence in UTF-8
>
>
> I found out the issue is caused from my windows_firewallrules fact.
> I have already set the encoding fix to UTF-8.
>
>
> for example:
>
> name.encode!('UTF-8', :invalid => :replace)
> key.encode!('UTF-8', :invalid => :replace)
> value.encode!('UTF-8', :invalid => :replace)
>
> windows_firewallrules[name][key] = value
>
>
>
>
> Strangely if i iterate through my nested hash (windows_firewallrules)
> i cant see anythink wrong.
>
>
> for example:
> windows_firewallrules.each do |k1, v1|
>   if k1.encoding.to_s != 'UTF-8'
> puts k1.encoding
>   end
>
>   v1.each do |k2, v2|
>   if k2.encoding.to_s != 'UTF-8'
> puts k2.encoding
>   end
>
>   if v2.encoding.to_s != 'UTF-8'
> puts v2.encoding
>   end
>  end
> end
>
>
>
> Has anyone a idea ?
>
> Best regards
> mobios
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> 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/6b8f9821-2d9e-4538-a3cc-4134b83daa10%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/CAC76iT9mVz_BDDvKRnOb52wV_d_ZhGajuVJ8VT9FieSEZDG%2BZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet facter utf-8 error

[mobios]

Hello Puppet User,


Infos:
Puppet-client-version = 3.8.4
facter= 2.4.4

Puppetserver = 4.10.0


I wrote a fact to discover all firewallrules on a windows machine.
Factname is windows_firewallrules.rb and returnvalue is a nested hash.


if i execute following command.

facter -p windows_firewallrules

I can see all firewallrules correctly. But if i execute 

puppet agent -tdv


I get a  error and the puppetrun stops.

Errormessage:
invalid byte sequence in UTF-8 


I found out the issue is caused from my windows_firewallrules fact.
I have already set the encoding fix to UTF-8.


for example:

name.encode!('UTF-8', :invalid => :replace)
key.encode!('UTF-8', :invalid => :replace)
value.encode!('UTF-8', :invalid => :replace)

windows_firewallrules[name][key] = value




Strangely if i iterate through my nested hash (windows_firewallrules) 
i cant see anythink wrong.


for example:
windows_firewallrules.each do |k1, v1|
  if k1.encoding.to_s != 'UTF-8'
puts k1.encoding
  end

  v1.each do |k2, v2|
  if k2.encoding.to_s != 'UTF-8'
puts k2.encoding
  end

  if v2.encoding.to_s != 'UTF-8'
puts v2.encoding
  end
 end
end



Has anyone a idea ?

Best regards
mobios






 






-- 
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/6b8f9821-2d9e-4538-a3cc-4134b83daa10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.