[Puppet Users] Using variable for user password hash causes password updated each run.

[James Perry]

I have been asked to set password for a user so it is unique on every 
single host we support. I have a script that generates the password and I 
had pulled it in via a generate call. The scripts takes in two of facter 
values to be used to aid in generating the password. 

$myvar = generate("/bin/sh","myscript.sh"."value1","value2")
user { 'bob':
 password => "${myvar}",
 }


This value is coming in as expected. When I pass it to the password => block 
it gets set as expected. Cool, but then it isn't. 

Each time puppet runs for the host, it keeps changing the user's password 
hash even though the hash from the script is the same as that on the host. 
Even that could be acceptable, except, these hosts are audited for password 
changes. Root being shown as updated every puppet run fails the audit. 

When I define it as a static hash aka '$1$salt$ab12k3oa01ksf01810' it 
doesn't keep resetting the password

Notice: Local environment: 'production' doesn't match server specified node 
environment 'passfix', switching agent to 'passfix'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for tlistmrrh511.myhost.net
Info: Applying configuration version '1539886469'
*Notice: /Stage[main]/Users::mypassword/User[bob]/password: created 
password*
Notice: Applied catalog in 4.52 seconds
[root@tlistmrrh511 ~]#
[root@tlistmrrh511 ~]# puppet agent -tv
Notice: Local environment: 'production' doesn't match server specified node 
environment 'passfix', switching agent to 'passfix'.
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for tlistmrrh511.myhost.net
Info: Applying configuration version '1539886484'
*Notice: /Stage[main]/Users::myassword/User[bob]/password: created password*
Notice: Applied catalog in 4.36 seconds

I have tried a number of ways to get this work inside puppet without using 
exec. Searching on this came up with creating custom facts to get the hash 
or hierra, which we don't use, to do this step. Having user hashes 
available as a fact won't pass an audit either. Basically this all needs to 
happen on the Puppet master and be pushed to all clients.

It seems that Puppet has a way to compare the old has with the new one when 
the hash is put between ' ', but I'm passing in a var.

I don't see any indication of why it is failing the comparrison. I have 
even set passwd => generate(... and it behaves the same way. 

What am I doing wrong here? It is quite frustrating.  

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/4bc322cd-c3bc-44fa-9c6a-1ccd6a778b81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: interpolation of puppet fact, with quotes, into erb template

[James Perry]

Did you try assigning the @domain_suffix to a local variable in the 
embedded Ruby and see if that would permit it to do as you want? 

On Friday, August 18, 2017 at 8:02:59 PM UTC-4, John wrote:
>
>  i have this bit of code here
>
><% @microservices.sort.each do |service,val| -%>
>   upstream <%= service %> {
> server <% val['endpoint']['{domain_suffix}'] = "@domain_suffix" 
> -%> resolve;
>   }
>   <% end -%>
>
> i'm trying to do a string replacement of the @domain_suffix puppet fact, 
> however ruby requires quotes around this value. however, with the quotes, 
> that value cannot be rendered in the template.
>
> i'm sure ruby can do this another way however i don't know it very well.
>

-- 
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/7c717cd1-a3d0-4efb-914d-ae0b54a4cba3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Patch Automation By Puppet

[James Perry]

It really depends on the OS and how you want to handle it. 
 
Puppet already has the package (
https://docs.puppet.com/puppet/latest/type.html#package) with the option 
*ensure 
=> latest,* that will keep the package at the most recent patches available 
in repos defined on the hosts. 

If you want to patch everything your manifest can be as simple as an 
*   exec{ 'yum -y update':*
*path => ['/usr/bin', '/usr/sbin',},*
*   }*

It really depends on what you want to accomplish. 

Providing you have the puppetlabs/stdlib module installed you can use 
*strftime* to pull in the current date/time to assign to a variable. If you 
use a smart class parameter,  *class x ( $somevar="something", ) { puppet 
block }*, you can change override the smart class variable to be the date / 
time you the current date/time must exceed to run your patching. Even more 
complex setups would have it so that you have *$window_start *and
* $window_stop* variables to control when Puppet will even consider 
patching. 

Basically it will all come down to the OS you are used, the patching 
commands (yum, dpkg, zypper) required to handle the process. 

The best way to get this worked out is to figure out exactly how your 
process will go, what depends on what and then pseudo code it to follow the 
login through.  Then start looking to see what Puppet can do for you 
natively and what you will have to do via exec, custom facts or defines. 


-- 
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/2bebcb7b-5aa0-4e02-a396-e55e9674080b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Need to put iterative value in a file

[James Perry]

Have you looked into the sshkey type already built into Puppet at 
https://docs.puppet.com/puppet/4.10/types/sshkey.html?  

Another option or possible combination would be to look at file_line 
 function in 
Puppet's stdlib package. Using that you can append a line to an existing 
file or replace a line based on a regex matcher. 

Below is an example I did to fix the LS color for a directory from dark 
blue to a lighter blue.

file_line { 'dir_colors':
  path=> '/etc/DIR_COLORS',
  line=> "DIR ${dir_default_color}   # directory",
  match   => '^DIR\s*.*',
  replace => true,
}



Maybe this would better allow you to do what you want. If Puppet is 
managing the file then that file{} block will be auto-required before the 
file_line block(s) are run. 

You could hack it to be in your for loop or make a define that took in the 
file name, key to add the lines you want. 

Possibly something along these lines (note I didn't test this worked 
perfectly). You will have to provide the full path to the file for the 
$ssh_file parameter.

define ssh::builder (
  String $ssh_file,
  String $ssh_key,
  $ensure => present,
) {
  file_line { "${ssh_key}":
line   => "${ssh_key}",
path   => "${ssh_file}",
ensure => $ensure,
  }
}


You would call it with ssh::builder { "${ssh_key_from_loop}": 
   ensure => 'present',
   ssh_file => '/full/path/to/file',
   ssh_key => "${ssh_key_from_loop}",
}

The reason I used ssh_key for the title in both cases was because that will 
be unique, which puppet requires. Now it only assumes a single file. 

Now if you want to create ssh keys per user, then you would want to use the 
sshkey and ssh_authorized_key types to make this easier. In the ssh_key you 
can specify a target file. I haven't tried to see if it handles writing 
more than one key to the same file or not. You might want to test that 
first because if that works it would seriously make your code a lot 
simpler. 
   

-- 
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/5af2ffda-f5d2-47a7-bccb-ddf8047d02f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Have Puppet remove a user when the associated class which created it is removed

[James Perry]

As I keep tweaking our Puppet/Foreman setup, I was wondering if it was 
somehow possible to auto-magically remove uses when the associated class is 
removed from the server.  All of our Puppet code is under source code 
management and requires a full change approval process to implement. 

I thought of doing custom facts and then checking them against all user 
classes, but that seemed like it would use a ton of overhead.  

Another idea was to do a define that had a default of absent for a user and 
then pass "present" as a parameter to have the user created, but that 
seemed like it would still need some "magic" that most likely end up 
getting really deep in coding to ensure that the user didn't get pulled off 
a box where it needed to exist. 

I'm not sure this is even possible other than how I have done it in the 
past where I created 2 users classes. One that adds it and another that 
removed it. The process is a bit clunky but it does work. 

Anyone had any success making something like this work? 

-- 
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/fffa2024-aeed-472e-af80-9798d7278949%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Way to dynamically build a hash / array using wrapper class

[James Perry]

So as I began working through sudo setups I found a unexpected problem I'm 
trying to find the *proper* way to correct the first time instead of having 
to hack code to make it work for now.

In particular we have multiple cases were the same Cmnd_alias is used with 
different settings. I know the correct way to fix it is to make sure there 
are no duplicated alias blocks in the sudoers file. 

What came to mind was to see if there was a way to use some *neato* Puppet 
magic to collect the name of each users::*user* class when sudo entries are 
defined. By the time the user's sudo blocks are defined there will be an 
array I can iterate through to build a list of all sudoers lines from all 
users::*user* classes to use with Puppet's stdlib to end up having only the 
unique settings in the users::*user*::*sudo_lines* variable / array remain 
to be fed to the sudo::conf function.  This will ensure no duplicate blocks 
across /etc/sudoers and /etc/sudoers.d/* files.  

Can this even be done progamatically in Puppet given that it would be very 
difficult to ensure all user classes had run to build the big list of sudo 
lines. 

The goal here is for this to run pretty much automatically either via 
reading in a list of users via a paramater file and build it that way or 
something similar. 

Still being a Puppet coding newbie, I wanted to ask out to see if anyone 
has done something similar. 

   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/31986796-0597-4f62-8d82-78ce952ca6e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: err: Could not request certificate: unknown message digest algorithm

[James Perry]

Looking at the help for the Puppet Agent (puppet agent --help), it seems 
that the supportable message digests depend on what your version of OpenSSL 
installed. 

* --digest:
  Change the certificate fingerprinting digest algorithm. The default is
  SHA256. Valid values depends on the version of OpenSSL installed, but
  will likely contain MD5, MD2, SHA1 and SHA256.

That said, with the Puppet agent version 4.9+, I tried to force it to break 
by specifying a bogus algorithm of MD6 and md6, but didn't get the message 
you showed. 

Now it does seem that they are showing in the help that it is uppercase, so 
it may be as simple as specifying MD5 versus md5 as you show in your post.

I just migrated almost 200 servers to Puppet 4 and none of them seemed to 
have any issues with certificates other than I had to completely remove the 
old version of Puppet we had and install fresh since the Puppet 4 agent has 
all apps / packages it requires contained within the package.

On Thursday, April 27, 2017 at 12:16:50 PM UTC-4, wattsharr...@gmail.com 
wrote:
>
> has anyone seen the following error:
> err: Could not request certificate: unknown message digest algorithm
>
> i have tried :
> puppet agent --digest md5 -t
>
> and am i currently attempting to upgrade to a newer version of puppet.
>
>
> any suggestions would be appreciated.
>
> EZ
>

-- 
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/b6364843-e505-4ef4-8321-e3b5bb3ff4e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] theforeman\foreman module?

[James Perry]

This may sound stupid, or even idiotic, but have you tried running the 
foreman-installer --noop --verbose to see what it shows?  I have found that 
when I patch my Linux servers that HTTP and other configs get completely 
messed up. Running the foreman-installer pulls the details from the answers 
file and reconfigures the setups accordingly.  It has become my first 
troubleshooting step when things aren't working. 

Seeing that your foreman2 box still shows the SSL certs for foreman1, but 
your answers file has the foreman2 certs defined, running the installer in 
noop with verbose will show you what would have changed to see if this 
would make the modifications you need to get the proxy working. 

On Wednesday, April 26, 2017 at 2:18:43 PM UTC-4, Jason McMahan wrote:
>
> Thank you for the quick response Dominic,
> When i look under settings
>
> foreman1 = (the original working) 
> SSL CA file /etc/puppetlabs/puppet/ssl/certs/ca.pemSSL CA 
> file that Foreman will use to communicate with its proxies
> SSL certificate /etc/puppetlabs/puppet/ssl/certs/foreman1.com.pem 
>SSL Certificate path that Foreman would use to communicate with its 
> proxies
> SSL client cert env SSL_CLIENT_CERTEnvironment variable 
> containing a client's SSL certificate
> SSL client DN env SSL_CLIENT_S_DNEnvironment variable 
> containing the subject DN from a client SSL certificate
> SSL client verify env SSL_CLIENT_VERIFYEnvironment variable 
> containing the verification status of a client SSL certificate
> SSL private key /etc/puppetlabs/puppet/ssl/private_keys/foreman1.com.pem   
>  SSL Private Key file that Foreman will use to communicate with its 
> proxies
>
> foreman2:
> SSL CA file /etc/puppetlabs/puppet/ssl/certs/ca.pem   
>   SSL CA file that Foreman will use to communicate with its 
> proxies
> SSL certificate /etc/puppetlabs/puppet/ssl/certs/foreman1.com.pem 
> SSL Certificate path that Foreman would use to communicate with its 
> proxies
> SSL client cert env SSL_CLIENT_CERT   
>   Environment variable containing a client's SSL 
> certificate
> SSL client DN env SSL_CLIENT_S_DN 
> Environment variable containing the subject DN from 
> a client SSL certificate
> SSL client verify env SSL_CLIENT_VERIFY   
>   Environment variable containing the verification 
> status of a client SSL certificate
> SSL private key /etc/puppetlabs/puppet/ssl/private_keys/foreman1.com.pem   
>   SSL Private Key file that Foreman will use to communicate with its 
> proxies
>
>
> When i look in the settings.yaml
> foreman1:
> :ssl_certificate: /etc/puppetlabs/puppet/ssl/certs/foreman1.com.pem
> :ssl_ca_file: /etc/puppetlabs/puppet/ssl/certs/ca.pem
> :ssl_priv_key: /etc/puppetlabs/puppet/ssl/private_keys/foreman1.com.pem
>
> foreman2:
> :ssl_certificate: /etc/puppetlabs/puppet/ssl/certs/foreman2.com.pem
> :ssl_ca_file: /etc/puppetlabs/puppet/ssl/certs/ca.pem
> :ssl_priv_key: /etc/puppetlabs/puppet/ssl/private_keys/foreman2.com.pem
>
>
> On Wednesday, April 26, 2017 at 6:00:06 AM UTC-5, Dominic Cleal wrote:
>>
>> On 25/04/17 18:34, Jason McMahan wrote: 
>> > Has anyone else used the foreman puppet module to create a new formean 
>> host? 
>> > We used the module, created the host, and manually added it to our f5 
>> > but odd things show up. 
>> > 
>> > If i go to https://foreman.com (load balancer) go to infrastructure > 
>> > smart proxy > click on puppetca host and look at certificates 1 out of 
>> 2 
>> > times it is fine. 
>> > If i go to https://foreman1.com (our original formean server that is 
>> > also the certificate authority) ever proxy looks fine, life is happy. 
>> > 
>> > If i go to https://foreman2.com (the new foreman we created with the 
>> > theforeman module logon is fine, hosts report ok but when i go to smart 
>> > proxy it shows red and give the error 
>> > 
>> > *Error: *Unable to communicate with the proxy: Permission denied @ 
>> > rb_sysopen - /etc/puppetlabs/puppet/ssl/private_keys/foreman2.com.pem 
>> > and Please check the proxy is configured and running on the host. 
>>
>> The certificate used by Foreman to communicate with its smart proxies is 
>> set by the ssl_* settings under Administer > Settings > Auth. 
>>
>> theforeman/puppet configures this via /etc/foreman/settings.yaml, and 
>> it's controlled by the "client_ssl_ca", "client_ssl_cert", and 
>> "client_ssl_key" parameters on the "foreman" class 
>> (
>> http://www.puppetmodule.info/modules/theforeman-foreman/puppet_classes/foreman).
>>  
>>
>>
>> Check what values are appropriate for your smart proxy instance, perhaps 
>> compare against your existing Foreman server, then set these parameters 
>> to the same values. 
>>
>> -- 
>> Dominic Cleal 
>> 

[Puppet Users] Re: puppetlabs-inifile versus sudoers

[James Perry]

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/95299141-786a-449d-a51d-dadfcedba7d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: How to dynamically change sudoers

[James Perry]

Thanks. I will look at that as we move forward.  

To your NFS issue, that was one of the design decisions we made. I have 3 
GIT repos (Dev, Stage, Prod). The Stage and Prod are on the same server. On 
dev I have every OS we support connected to it to run through all code 
before we push to Stage.  With Foreman it is easy enough to move a host 
from PROD to Stage and then test the changes. We move hosts to Stage so we 
test across the board. Once all testing details are clean and the team  / 
customer approves, we do a change to push into PROD. 

Our old setup was on a single environment with Puppet 0.25 and a monolithic 
build. We had a lot of admins hacking the code with no version management. 
many with no understanding of puppet or even checking their syntax. 

As for Foreman we chose it to keep the first level admins from actually 
messing with code / configs. They trashed a lot of setups when we let them 
do that on the old config. 

On Wednesday, April 26, 2017 at 11:54:24 AM UTC-4, Rob Nelson wrote:
>
>
> On Wed, Apr 26, 2017 at 10:45 AM James Perry <jjpe...@gmail.com 
> > wrote:
>
>> Since all of our Puppet code is in a source code repo and requires a 
>> change control to push to PROD, I don;t want to have to manually create a 
>> per host entry, either via the* case* statement or a *node.yaml* file as 
>> that requires a full regression test and verification before it moves to 
>> PROD. 
>>
>> Via Foreman I can add puppet classes for *userX *and *userQ* to a 
>> specific server. As long as *sudo::sudoers::userX *and *sudo::sudoers::userQ 
>> *are defined in the Puppet code, then no change to modify code or custom 
>> hiera yaml files is required. This takes the sudo setups from having to be 
>> done per node in code to a point and click for the team that handles the 
>> tickets for the host definitions in Foreman. 
>>
>
> This is a complete aside to sudo, but I think your controls here do not 
> operate as you expect them to. Foreman, like hiera, is just separating your 
> data from your code, which is great. But changing data in either system can 
> have adverse effects in production. For example, I once changed the value 
> for an nfs exports list from an array to a string. That ... did not go 
> well! If only an integration test had been used to catch that, I could have 
> avoided a small outage and a remediation change. 
>
> Personally, I prefer hiera to foreman or the PE Console classifier because 
> it's integrated with version control of the control repo and into my test 
> setup. But the point is, we use the same controls on data as code because 
> they have similar potentials for impacts in production. You may want to 
> revisit your controls, even if it's just to acknowledge the risk. 
>
>> -- 
> 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/7531f867-71b2-4782-b0fe-46c363d806b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to dynamically change sudoers

[James Perry]

I guess I should have running a Foreman / Puppet setup, so I am trying to 
keep from having to go creating .yaml files as well as editing things 
like site.pp and other files. 

The object I am trying to accomplish is on the KISS principal.

So for example my sudoers.erb has an array block for *sudoers_extra_lines* that 
adds a block for a specific user. It is kludgy. I have a case on hostname 
and it then sets the associated sudo_extra_lines to the 
sudo::sudo_lines::.  I have also done an array on this to have *userX 
*and *userQ*. 

Since all of our Puppet code is in a source code repo and requires a change 
control to push to PROD, I don;t want to have to manually create a per host 
entry, either via the* case* statement or a *node.yaml* file as that 
requires a full regression test and verification before it moves to PROD. 

Via Foreman I can add puppet classes for *userX *and *userQ* to a specific 
server. As long as *sudo::sudoers::userX *and *sudo::sudoers::userQ *are 
defined in the Puppet code, then no change to modify code or custom hiera 
yaml files is required. This takes the sudo setups from having to be done 
per node in code to a point and click for the team that handles the tickets 
for the host definitions in Foreman. 

I'm not a Puppet coding expert, or even consider I can admit to doing more 
than basic hacking of other's code.

John's suggestions on a template is similar to what I have now, but 
requires a way to dynamically build the needed arrays. 

Rob's details on the way to do it via yaml are equally beneficial.

Unfortunately something isn't clicking for me somewhere to bridge the gap 
between the Puppet Docs and how to make this work. 

If anyone has a better reference for non-expert Puppet programmers to 
better dumb this down it 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/2fdb8247-8e3e-4bdf-8efb-e720289226f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to dynamically change sudoers

[James Perry]

What I seem to be missing is do you have subsequent classes called 
sudo::user_alias and sudo::user_priv? I get the Hiera yaml file setup, not 
how to use them selectively to have them added to the sudoers file. 

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/70b783e8-3256-4813-b332-d0e3b0813206%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to dynamically change sudoers

[James Perry]

Thanks. That is probably definitely easier than what I planned to try to
hack into place.

On Apr 23, 2017 16:45, "Rob Nelson" <rnels...@gmail.com> wrote:

> James,
>
> Sure, I've whipped up a gist for this in the past at
> https://gist.github.com/rnelson0/f40719c787639a94d81e23340c5d063b. By
> setting a deep merge on the key profile::base::linux::sudo_confs, I can
> add to its hash value wherever I want in my hierarchy and a new sudoers.d
> configuration snippet is added to the target system. All nodes receive the
> sysadmin snippet, anything with the `infrastructure` role receives both the
> sysadmin and the infrastructure snippet. That is all you need to get
> started with saz/sudo, but I'm sure there's other functionality if you need
> it.
>
>
> Rob Nelson
> rnels...@gmail.com
>
> On Fri, Apr 21, 2017 at 1:33 PM, James Perry <jjperr...@gmail.com> wrote:
>
>> Thanks. I looked at saz/sudo, but at least they I did it, it didn't for
>> my needs. We have a wide range of hosts that would have oracle, dba and
>> tomcat sudo rules. On another it would only have dba rules.
>>
>> I didn't quite get how I would have it setup the sudo::conf blocks to do
>> what I would need. For example one host would have classes that define a
>> content block for dba sudo permissions. Another for oracle's permissions,
>> etc. Based on the classes assigned to the node I would want to have it make
>> the required files with the needed content.
>>
>> Besides the examples in the README.md for the saz/sudo module, could post
>> some code that would do something similar to what I need using the saz/sudo
>> module? It is highly likely I'm just not interpreting the doc correctly.
>>
>> Thanks!
>>
>>
>> On Friday, April 21, 2017 at 12:19:43 PM UTC-4, Rob Nelson wrote:
>>>
>>> Check out saz/sudo (https://forge.puppet.com/saz/sudo). By default it
>>> manages /etc/sudoers.d with `sudo::conf` instances and purges
>>> /etc/sudoers.d of anything it didn't create, but if something else is
>>> managing files in that directory you can set `sudo::purge: false` so they
>>> can share nicely.
>>>
>>>
>>> Rob Nelson
>>> rnel...@gmail.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/ms
>> gid/puppet-users/a45ccc0a-eed8-41ea-b2d9-6789e64edc51%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-users/a45ccc0a-eed8-41ea-b2d9-6789e64edc51%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/zP9zSqbF84M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/CAC76iT__BRv5K6bupusZ7DS5KGMZ0g-JpL_
> 7xjqhb3zOxU7HpQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAC76iT__BRv5K6bupusZ7DS5KGMZ0g-JpL_7xjqhb3zOxU7HpQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/CAOU0SJQma-bPWoSQ5oOomEE0-QvCSpOghkGAOM7wT7S8Rk%3DQgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to dynamically change sudoers

[James Perry]

I will look into that John, thanks.  I haven't gotten to the Yaml level 
yet, but we already have a temple we use now that is standard across the OS 
we support. We then add in lines accordingly.  

I had some luck with the sudo::config setup, so I may try to merge the two. 
With having a class per user I can't re-define the sudo class in each so I 
had to do an include instead. It might do what I need. Your template does 
give me some ideas though to better tweak my own. 

-- 
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/14010778-76fb-4d82-8254-8f32f8d946d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to dynamically change sudoers

[James Perry]

BTW. I am running Foreman 1.14.3 and Puppet 4. All class assignments to 
nodes are done via Foreman versus the site.pp. 

On Friday, April 21, 2017 at 1:33:38 PM UTC-4, James Perry wrote:
>
> Thanks. I looked at saz/sudo, but at least they I did it, it didn't for my 
> needs. We have a wide range of hosts that would have oracle, dba and tomcat 
> sudo rules. On another it would only have dba rules.  
>
> I didn't quite get how I would have it setup the sudo::conf blocks to do 
> what I would need. For example one host would have classes that define a 
> content block for dba sudo permissions. Another for oracle's permissions, 
> etc. Based on the classes assigned to the node I would want to have it make 
> the required files with the needed content. 
>
> Besides the examples in the README.md for the saz/sudo module, could post 
> some code that would do something similar to what I need using the saz/sudo 
> module? It is highly likely I'm just not interpreting the doc correctly.
>
> Thanks!
>
>
> On Friday, April 21, 2017 at 12:19:43 PM UTC-4, Rob Nelson wrote:
>>
>> Check out saz/sudo (https://forge.puppet.com/saz/sudo). By default it 
>> manages /etc/sudoers.d with `sudo::conf` instances and purges 
>> /etc/sudoers.d of anything it didn't create, but if something else is 
>> managing files in that directory you can set `sudo::purge: false` so they 
>> can share nicely.
>>
>>
>> Rob Nelson
>> rnel...@gmail.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/c9574bad-0e8b-41d3-844b-96c463c94ed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to dynamically change sudoers

[James Perry]

Thanks. I looked at saz/sudo, but at least they I did it, it didn't for my 
needs. We have a wide range of hosts that would have oracle, dba and tomcat 
sudo rules. On another it would only have dba rules.  

I didn't quite get how I would have it setup the sudo::conf blocks to do 
what I would need. For example one host would have classes that define a 
content block for dba sudo permissions. Another for oracle's permissions, 
etc. Based on the classes assigned to the node I would want to have it make 
the required files with the needed content. 

Besides the examples in the README.md for the saz/sudo module, could post 
some code that would do something similar to what I need using the saz/sudo 
module? It is highly likely I'm just not interpreting the doc correctly.

Thanks!


On Friday, April 21, 2017 at 12:19:43 PM UTC-4, Rob Nelson wrote:
>
> Check out saz/sudo (https://forge.puppet.com/saz/sudo). By default it 
> manages /etc/sudoers.d with `sudo::conf` instances and purges 
> /etc/sudoers.d of anything it didn't create, but if something else is 
> managing files in that directory you can set `sudo::purge: false` so they 
> can share nicely.
>
>
> Rob Nelson
> rnel...@gmail.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/a45ccc0a-eed8-41ea-b2d9-6789e64edc51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to copy and install 3 different files from puppet master to 3 different locations

[James Perry]

I'm no expert by far, but since I have been doing a lot of reading lately 
for an issue I am trying to resolve, would it make sense to do a define 
block for this? Looking at 
https://docs.puppet.com/puppet/4.9/lang_defined_types.html it seems this 
*may* work for you with some tweaking / testing. *I'm not sure I have all 
of the syntax right*.

something of the order below might work. 

define profile::ma ($envfile = "", $envsource = "") {
  if $envfile == "" {
$envtarget = '/tmp/filename.sh'
  } else {
$envtarget = $envfile
  }
  if $envsource == "" {
$env_path = "files/filenames.sh"
  }
  else {
$env_path = $envsource
  }

  file { $envtarget:
ensure  => 'present',
replace => 'no',
source  => "puppet:///module/${env_path}",
mode => '0755',
notify => Exec['install']
  }
  
  exec {'install': 
command => "${envtarget} -i",
onlyif => '/usr/bin/test ! -e /etc/filetocheck',
  }
}

** Note there isn't any handling of "filetocheck" in this snippet, but you 
can add it. 

In your code block for the file you would have something like:

class env_a ($env_file = "/tmp/filename.sh", 
  $env_source = "files/env_a_file.sh"
  ){
   profile::ma{ 'profilea':
  envfile => $env_file,
  envsource => $env_source,
  } 
}

class env_b ($env_file = "/tmp/filename.sh", 
  $env_source = "files/env_b_file.sh"
  ){
   profile::ma{ 'profilea':
  envfile => $env_file,
  envsource => $env_source,
  } 
}

I put in smart parameters for the settings since I use foreman and find I 
will sometimes need to override a setting value from time to time when 
something breaks and I need a fix before being able to get the new code 
through change control. 

Now I haven't tested it but it does follow from the linked example above it 
appears that it *should* work. There probably also a way to dynamically 
setup the settings based on the defined environment, but that is beyond me 
right now. 

-- 
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/82430a1d-f044-4a37-964d-096fd61c4490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How to dynamically change sudoers

[James Perry]

I'm at an impasse. 

Due to changing requirements we have different local service accounts being 
added 'ad hoc' to various servers. Each needs their own set of sudoers 
lines.  When moving from Puppet 0.25 to Puppet 4 I had to kludge something 
together in a hurry. It works, but not well. 

I looked at defining classes for each set of lines that needed to be added 
and have it create a separate file for that class in /etc/sudoers.d/.  Due 
to SOX compliance we can't have any sudo permissions defined for accounts 
not on the server. So if i remove the class that creates 
/etc/sudoers.d/foo, the /etc/sudoers.d/foo file still remains. If I try to 
clean out all non-needed files, I either have to do:
  1. Remove all files, but that causes Puppet to always recreate the files.
  2. Create some way to remove a file based on knowing if the class is 
defined for this node, which forum posts show as problematic. 

I did see the Puppet-concat module, but haven't had the time to really dig 
into it to see if the would solve the problem. In this case it would be 
modifying / creating the main sudoers file, which is fine. 

Another option would be to use something like file_line to make sure a 
specific line(s) are in the sudoers file after the initial template creates 
our default /etc/sudoers file. 

Has anyone solved this type of issue?  I know there are ways to do it, but 
I really want to do it right and forget it. Wen we need a new sudo setup 
for a new account, we create the required class and the rest is "magic" 
based on the classes defined for that node. 

In the mean time I will be doing more deep Google dives and serious RTFM. 

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/db9fabde-a539-4e8a-97b7-b160387df942%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Language Style Guide update

[James Perry]

Are the any open source or free replacements for Geppetto?   RubyMine is 
like $200/year, which is outside of an IT budget of $0/year for tools. 

On Friday, January 13, 2017 at 5:03:48 AM UTC-5, Henrik Lindberg wrote:
>
> On 13/01/17 08:38, Peter Faller wrote: 
> > Has the Gepetto auto-formatter been updated (or will it be updated) to 
> > match the style guide? Or is there another way of automatically 
> > formatting manifests to match the style guide? 
> > 
>
> Geppetto is pretty much up to date on the style guide as there are no 
> fundamental changes to the formatting in terms of indentation and 
> spacing. It is however somewhat behind on the language support as it has 
> no understanding of the type system and some other recent additions. 
> Geppetto is no longer maintained by Puppet as announced quite a long 
> time ago. 
>
> An IDE that has recently updated their support for Puppet is RubyMine. 
> It is well worth taking a look at. Don't know what kind of formatting 
> they offer though. 
>
> Best, 
> - henrik 
>
>
> > 
> > -- 
> > 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/d36a42d7-d46e-4cc5-b198-8b7b396031e3%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/puppet-users/d36a42d7-d46e-4cc5-b198-8b7b396031e3%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > 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/f0649350-e4df-4bf1-aa13-3f69978e6848%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to read in file into array of hashes to use build start script template

[James Perry]

I am looking to see if I can make this work with a define or have to resort 
to an each loop.  Still hacking away to see what I can find. With the each 
I can still loop through to try to get to the goal of having a key/value 
pair to pass on to a template only if the current client matches one of the 
host names in scope. 

Worst case I will just go ahead to split the variables up accordingly per 
client and hard code in the module / parms file. 

My goal was to have it so we could just use the CSV file we were given to 
dynamically build the data. But it may be less costly (from a CPU cycle 
level) to just go back to the good old days :) 

On Sunday, January 22, 2017 at 10:56:46 PM UTC-5, John Gelnaw wrote:
>
> On Friday, January 20, 2017 at 12:28:02 PM UTC-5, James Perry wrote:
>>
>> Thanks.
>>
>> The reason I have a CSV is that is what is provided from the users out of 
>> their own private database where they keep this data. I have to take the 
>> detail as it is given. Now I can manually process the data to be how I 
>> think I want, but I'm trying to keep this as simple as possible for the 
>> other team members (KISS principal).  
>>
>> For the custom ENC, the new environment is Foreman over top of Puppet. 
>>  Can I use a Puppet ENC when Foreman is setup to do that itself? 
>>
>
> I have a very complex ENC myself, so the idea of merging the Foreman ENC 
> with my own ENC appeals to me-- Ultimately, they're both just spitting out 
> YAML.
>
> My current line of attack is to have my ENC (configured already within 
> puppet) call the Foreman node.rb script, merge the two data structures and 
> output the resulting YAML, but the migration to puppet 4.x has priority at 
> the moment.
>
>

-- 
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/2c504b24-599a-4251-bcbf-25c8fbf75377%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to read in file into array of hashes to use build start script template

[James Perry]

Thanks.

The reason I have a CSV is that is what is provided from the users out of 
their own private database where they keep this data. I have to take the 
detail as it is given. Now I can manually process the data to be how I 
think I want, but I'm trying to keep this as simple as possible for the 
other team members (KISS principal).  

For the custom ENC, the new environment is Foreman over top of Puppet.  Can 
I use a Puppet ENC when Foreman is setup to do that itself? 

With respect to a custom function, what would there be a performance impact 
by having to have Ruby run that block? 

-- 
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/550dd25e-2038-48ec-b36d-4b923df8f425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to read in file into array of hashes to use build start script template

[James Perry]

Thanks for the code. 

What I am trying to find is the correct way to use what Puppet has already 
defined in the code base to handle processing everything into a hash of 
key/value pairs inside of the class, if possible. 

It seems that it should be able to do it, I am just looking at it wrong. 

-- 
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/ace1a764-6d94-4bfb-bfb5-84f40d498cfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How to read in file into array of hashes to use build start script template

[James Perry]

After spending most of they day digging around and researching, I find 
Puppet's immutable variables are keeping me from properly handling what I'm 
trying to do, so I want to see if anyone else has some suggestions on how 
to handle was I need to accomplish.

Goal: Ingest a CSV file provided by a user and generate a start / stop 
script, dynamically, for every server in scope, based on CSV file. 

CSV Format: 
SERVER,start command 

Example. 
SERVERA, /usr/local/bin/prog start databasea
SERVERA, /usr/local/bin/prog start databaseb
SERVER1, /usr/local/bin/prog start database123


The basic design I had in mind for the manifest is to: 
1. Read in the file as provided,
2. Convert , to downcase(A) => B
3. if $hostname == A 
   $my_server_script_lines = $my_hash[A][B]
   file { 
 ... 
 content => template("basic_start_script"),
 }

4. Create a template that runs through the $my_server_script_lines to  put 
each start line under start) and under stop) after doing a substr 
replacement of start for stop in B. 

Code so far
include stdlib
$my_data = file("/home/me/database.csv")
$my_subst = downcase(split($my_data2,'[,\n]'))
$my_hash = hash($my_subst)

notice ($my_hash[SERVERA])

$ puppet apply --verbose test.pp
Info: Loading facts
*Notice: Scope(Class[main]): '/usr/local/bin/prog start databaseb'*
Notice: Compiled catalog for myhost.net in environment production in 0.16 
seconds
Info: Applying configuration version '1484340247'
Notice: Applied catalog in 0.03 seconds

Here are the values of the variables as it processes through

$my_data = "SERVERA,/usr/local/bin/prog start databasea
SERVERA,/usr/local/bin/prog start databaseb
SERVERB,/usr/local/bin/prog start database123"

$my_subst = [servera, '/usr/local/bin/prog start databasea' , servera, 
'/usr/local/bin/prog start databaseb' , serverb, '/usr/local/bin/prog start 
database123' ]
 
$my_hash = {servera => '/usr/local/bin/prog start databaseb' , serverb => 
'/usr/local/bin/prog start database123' }

So I already know why the hash conversion dropped the "start databasea" for 
the servera key, what I can't seem to figure out is how to have it convert 
into a array of value pairs for a specific key.   

   { servera => ['/usr/local/bin/prog start 
databasea', '/usr/local/bin/prog start databaseb'], serverb => 
['/usr/local/bin/prog start database123'] }

I tried various iterations of .each to try to create and fill the array 
pointed to by the hash, but Puppet doesn't permit that as it would be 
changing an already assigned variable / hash. 

I was able use the $my_subst variable in an erb template to create the 
start/stop lines.  It worked ok for the 3 line example above, but when I 
got to dozens of servers / start lines being applied to hundreds of servers 
on each check-in it soon killed the CPU in my master server as it ran 
through a loop checking if $hostname == servername. 

Is it possible to have Puppet handle parsing the data in $my_substr, or 
even right from the raw file data to do the following? 
   1. Run through incoming data to fill start command array.   
['/usr/local/bin/prog 
start databasea', '/usr/local/bin/prog start databaseb']
   2. Assign that to the array of key-pairs.  { servera => 
['/usr/local/bin/prog start databasea', '/usr/local/bin/prog start 
databaseb'], serverb => ['/usr/local/bin/prog start database123'] }

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/4fa9b2d3-103c-413f-9be2-1f84a16c115e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Upgrading from 0.25.1 to 3.7.4

[James Perry]

I have been tasked to upgrade puppet 0.25.1 to 3.7.4.  There has been a lot 
of past admins tweaking this puppet server and most of the existing modules 
are all ad-hoc creations. I want to ensure I do not miss any expected 
dependencies, but I also do not have months to manually traverse the entire 
Puppet site.pp file by hand.

Is there some tool, script or puppet command that will show me a quick 
digestion for each node as to what modules it includes and inherits? 

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/1971bf52-6c44-4b96-80fb-72c9dc096355%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Setting validproperties fields in provider modules

[James Perry]

The HPUX code I am trying to modify is already in the existing Puppet 
code base at 
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/user/hpux.rb. 



The functionality I am trying to use is to set the value of a specific 
property so that I can specify the commands to run depending on which 
password aging scheme is required on a specific HPUX OS version and 
setup. Some are trusted computing, some use a version of the shadow 
password and others just a plain old password file.


The module I found the functionality I want to extend is based on the 
snippet of code starting at line 11 of 
https://github.com/adrienthebo/puppet-filemapper/blob/master/lib/puppetx/filemapper.rb.


Unfortunately I am unable to seem to get it to work and thus I am at a 
loss. I really need to be able to ensure that the proper expiry setups 
are in place for HPUX because while I managed to get the password 
functionality into the main stream code base, it is not likewise 
resetting the password expiration for another 90 days and thus the 
account gets locked out.


On 4/15/2014 7:16 AM, Felix Frank wrote:

On 04/14/2014 06:37 PM, Jim Perry wrote:

Not yet. I don't have it working and I was asking how to get our data
for troubleshooting it first.

I see, well, this is unfortunate - debugging this (or even comparing it
to working code) will be nigh impossible without looking at your
concrete status.

I'd like to ask you to rethink at least sharing an anonymized version on
a paste service or gist.

Thanks in advance,
Felix



--
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/534DD8BD.9060604%40gmail.com.
For more options, visit https://groups.google.com/d/optout.