Re: [Puppet Users] Re: check if user exist

2015-05-07 Thread Alfredo De Luca
Hi John.
I am aware that if I say userxx ensure is present will work but what I want
is the first time create the user aNd set a default password but then when
the user changes it own pass I just wanna check if is present and not
resetting the password.

/Alfredo
On 07/05/2015 11:32 PM, "jcbollinger"  wrote:

>
>
> On Thursday, May 7, 2015 at 5:17:22 AM UTC-5, Alfredo De Luca wrote:
>>
>> Hi all.
>> I am using puppet source with Hiera. I want to manage users but also I
>> want to check if an user exist before doing something else and create
>> it.
>>
>> I have a module prousers as follow:
>>
>> prousers/init.pp
>> class prousers {
>> create_resources(user, hiera_hash('pro_user'))
>> }
>>
>>
>> then from hiera
>>
>> common.yaml
>> pro_user:
>>   bla1:
>> ensure: 'present'
>> comment: 'bla bla 1'
>> managehome: 'true'
>> uid: '1579'
>>   bla2:
>> ensure: 'present'
>> comment: 'bla bla 2'
>> managehome: 'true'
>> uid: '1014'
>>
>>
>> How can I check in the prousers module if an user exist or other checks?
>>
>>
>
> If you want to condition parts of a node's catalog on whether a given user
> exists, then
>
>1. the condition must be based on the system's state *at the time of
>the catalog request* (not during catalog application), and
>2. you would accomplish it by writing a custom fact to probe that
>user's existence and provide that information to the master.
>
> HOWEVER, it's unclear whether that's really what you want.  If the
> objective is to check whether user 'pro_user' exists so that you can create
> him if he's not already present, then that's an ineffective way to use
> Puppet.  If the point is that any node having class prousers should have
> all the users specified in the Hiera data, then natural way to approach it
> is to simply declare all those users.  As with any other resource type,
> Puppet examines the current state of each declared user (including whether
> he exists at all), and performs exactly those actions needed to bring the
> node to the target state expressed in its catalog -- no more, no less.
>
> If you want to be sure that other resources are managed only after the
> users have been put in the desired state, then that is the purpose of
> resource relationships.
>
>
> John
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2348ab8f-a814-4593-894e-7e343e52018c%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/CAAWpFTEiYsaPZiMKw6bx3UnjoT-8-u5%2BbAUp-5-1oLE8euSc3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] marking last modified time in a template

2015-05-07 Thread Gabriel Filion
On 06/05/15 03:05 PM, Peter Berghold wrote:
> my first answer to this was to look at the file modification time.  For
> whatever reason they wanted to know if I could add a line saying
> something on the order of "Last Modified By Puppet:  ".  
> 
> I'm just going to tell them they're nuts.

you could probably use features from your vcs to get this done by making
it replace a certain tag with the commit date. that way it only changes
when you commit changes to the file.

-- 
Gabriel Filion

-- 
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/554C375B.3030109%40lelutin.ca.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [Puppet Users] puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread Josh Cooper
On Thursday, May 7, 2015, Johnson Earls  wrote:

> All of my systems get the puppet-agent package installed and enabled as
> part of kickstart.  The puppetserver package only later gets installed for
> servers that will be puppet servers.  Is this ordering really that
> unexpected?
>

That sounds like a great reason to open a ticket.

On Thursday, May 7, 2015 at 12:06:53 PM UTC-7, Josh Cooper wrote:
>>
>> In practice this happens rarely. Usually you install puppetserver, which
>> brings in puppet-agent as a dependency.
>> --
>> Josh Cooper
>> Developer, Puppet Labs
>>
>> *PuppetConf 2015  is coming to Portland,
>> Oregon! Join us October 5-9.*
>> *Register now to take advantage of the Early Adopter discount
>> 
>>  *
>> *—**save $349!*
>>
>
> - Johnson
>



>  --
> 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/c7c9d0c4-6ac2-4b65-8ca8-3bad470c69e2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Josh Cooper
Developer, Puppet Labs

*PuppetConf 2015  is coming to Portland,
Oregon! Join us October 5-9.*
*Register now to take advantage of the Early Adopter discount

*
*—**save $349!*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97um344LsbiCvRt36tVLFPaFMb%2BBs0JVZxxPy2qoBFEcyUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread Johnson Earls
All of my systems get the puppet-agent package installed and enabled as 
part of kickstart.  The puppetserver package only later gets installed for 
servers that will be puppet servers.  Is this ordering really that 
unexpected?

On Thursday, May 7, 2015 at 12:06:53 PM UTC-7, Josh Cooper wrote:
>
> In practice this happens rarely. Usually you install puppetserver, which 
> brings in puppet-agent as a dependency.
> -- 
> Josh Cooper
> Developer, Puppet Labs
>
> *PuppetConf 2015  is coming to Portland, 
> Oregon! Join us October 5-9.*
> *Register now to take advantage of the Early Adopter discount 
> 
>  *
> *—**save $349!*
>

- Johnson 

-- 
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/c7c9d0c4-6ac2-4b65-8ca8-3bad470c69e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Announce: PuppetDB 2.3.4 is now available!

2015-05-07 Thread Wyatt Alt
PuppetDB 2.3.4 - May 7, 2015

PuppetDB 2.3.4 Downloads



Available in native package format in the release repositories at:

http://yum.puppetlabs.com and http://apt.puppetlabs.com

For information on how to enable the Puppet Labs repos, see:

http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#open-source-repositories

Binary tarball: http://downloads.puppetlabs.com/puppetdb/

Source: http://github.com/puppetlabs/puppetdb

Please report feedback via the Puppet Labs tickets site, using an affected
PuppetDB version of 2.3.4: https://tickets.puppetlabs.com/browse/PDB

Documentation: http://docs.puppetlabs.com/puppetdb/2.3/

Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb

PuppetDB 2.3.4 Release Notes



PuppetDB 2.3.4 is a backwards-compatible bugfix release that addresses an
issue

that would prevent fact storage for nodes under certain circumstances.
Users experiencing recurring failures of the “replace facts” command due to
constraint violations on fact_value_id are encouraged to upgrade.

For more information and upgrade advice, consult the detailed release notes
here:

https://docs.puppetlabs.com/puppetdb/2.3/release_notes.html

Contributors



Andrew Roetker, Deepak Giridharagopal, Ken Barber, Melissa Stone, Rob
Browning,

Wyatt Alt

Changelog

-

Andrew Roetker (3):

 a8eede4 (PDB-1412) Update rspec dependency from 2.x to 3.x

 71875d5 Revert "(PDB-1412) Update rspec dependency from 2.x to 3.x"

 7d43528 (PDB-1485) Deprecate url-prefix setting

Deepak Giridharagopal (1):

 c3370dc (PDB-1428) Suppress version-check INFO logging

Ken Barber (3):

 6b322eb (maint) Bump to latest pristmatic/schema

 131ccbf (maint) Bump to latest trapperkeeper/jetty9/kitchensink

 209d31c (docs) Fix path to puppet terminus for source based installs

Melissa Stone (2):

 5f0fbf0 Remove Fedora 19 from build targets

 858fd9d (maint) Remove lucid from build targets

Rob Browning (3):

 df69e5a (PDB-1431) Remove PE packages from el-7 AMI

 797cff7 (PDB-1448) Test swapping path values in a replace

 cbc6048 (PDB-1448) GC values that swap paths correctly

Wyatt Alt (6):

 74e4c7a (maint) add upgrading from v3 document to stable branch

 350ba80 Update configure.markdown

 8e7b5c3 Update facts.markdown

 3199533 (maint) make facts response streaming

 2621541 (PDB-1494) Update release notes for 2.3.4.
 f33b28e (PDB-1479) deprecate event counts and aggregate event counts

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


[Puppet Users] Re: parsejson truncating output (i think)

2015-05-07 Thread Allen Myers
well, nevermind. It's now today, and I've not changed the server, the 
client, the shell script, nor the manifest, yet it's
magically working today!

my blind trust in the reliability of computers and software has been 
shattered. I'll never
be the same again. ;^)

- Allen

On Thursday, May 7, 2015 at 11:45:30 AM UTC-7, Allen Myers wrote:
>
> and one more piece of info: The puppet server is configured using 
> Passenger+apache. When I run
>
> puppet agent --test
>
>
> on a client system, parsejson fails by truncating the hash output.
>
> But if I just run 'puppet apply ...' on the puppet server, as in
>
> puppet apply create-users.pp
>
>
> which contains
>
> $myusers = parsejson (generate ('/bin/sh', '-c', 
> '/var/lib/puppet/lib/create-user-hash.sh'))
> notice ($myusers)
>
>  
> it works perfectly.
>
> - Allen 
>
>  
>
>
> On Wednesday, May 6, 2015 at 12:47:10 PM UTC-7, Allen Myers wrote:
>>
>> Hi,
>>
>> I've got the following statements in my manifest:
>>
>> $myusers_json = generate ('/bin/sh', '-c', '/path/to/my/script.sh')
>> notice ($myusers_json)
>> $myusers = parsejson ($myusers_json)
>> notice ($myusers)
>>
>>
>> My script generates a list of users in JSON and I've verified that the 
>> output format from 'notice ($myusers_json)' is correct using jsonlint.com
>> .
>> However, the output of 'notice ($myusers)' is always limited to 1985 
>> bytes. It's just truncating the output. I know it's not just a short-coming
>> of the 'notice' function because when I call
>>
>> create_resources(user, $myusers)
>>
>>
>> if fails with the error 
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on 
>> SERVER: expected ',' or '}' in object at '"user1" : {  "'! at 
>> /etc/puppet/environments/mgmt/manifests/01-all-nodes.pp:24 on node 
>> pupper-server1
>>
>>
>> If I modify script.sh so that the result is less than a certain length 
>> (depends on the number of fields and how many ':' get converted to '=>'), it
>> works just fine. But the final output in puppet has format is being 
>> limited to 1985 bytes.
>>
>> Any fix or work-around for this?
>>
>> Thanks!
>>
>> - Allen
>>
>

-- 
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/8f9b58d0-4dc5-4691-8fe7-69b11ba11d48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

2015-05-07 Thread jcf

> On May 1, 2015, at 08:14, jcbollinger  wrote:
> 
> On Thursday, April 30, 2015 at 11:32:43 AM UTC-5, Michael Stanhke wrote:
> Rather than reply and quote lots of points, I'll just bring up a few things 
> which could help clarify our goals. I'm sure not everybody will agree or love 
> all of them, we know there are compromises here but attempted to make choices 
> with the user's benefit and ease of use in mind. 
> 
> * The package is called puppet-agent because Puppet is more than the tool 
> puppet at this point. It's an ecosystem. It's a suite of tools working 
> together to manage infrastructure and applications. The agent is the word 
> that means "all the stuff you need to run an endpoint in this ecosystem."
> 
> This conversation serves as evidence that that's not a universally accepted 
> meaning for the word "agent", and I'd be surprised to find that more people 
> interpreted "puppet-agent" that way than interpreted plain "puppet" that way. 
>  Surely it's natural to interpret "puppet-agent" as something more specific 
> than "puppet", and decidedly unnatural to interpret "puppet-agent" as more 
> general.

Correct. 

> 
> * We wanted to get away from our users having to carry the cognitive load of 
> understanding each component we have, what it does and what versions work 
> well together or have conflicts, what dependencies are required, and where do 
> I get those? 
> 
> Those are worthy goals.  Unfortunately, the present scheme isn't there yet.  
> Witness, for example, the misunderstanding about whether the "puppetserver" 
> package is needed or wanted for running a master.

The fact that component naming and versioning has suffered horribly is part of 
why we are here today, yes.

> Moreover, the effort to lighten the cognitive load has produced an 
> undesirable opacity to what is installed and why, and ultimately a cognitive 
> dissonance for people who probe that, or who have already shouldered the 
> cognitive load (i.e. many existing users).  That is essentially where this 
> thread started, even if we've only now begun throwing around the word 
> "cognitive”.

Isn’t Puppet a tool for carrying this cognitive load itself? Once I’ve defined 
an exact package version to be installed somewhere, based on research and 
testing, I generally “forget about” the meta details until something goes wrong 
that forces me to remember/re-learn these details because these sorts of 
Religious Wars about Versioning as well as cross-entity version tracking means 
that “nothing” has the same version on my system as it advertised on the tin. 
That the very toolset that helps me manage such things has suddenly succumbed 
to the very pox it helps me manage is as ironic as a Park Slope haircut.

> There is a vast gulf between "it's unnecessary to know" and "it's difficult 
> to determine or understand”.

^^ That right there.

> * The bits inside the agent should be able to be more of a single user 
> experience.  A key message for this point was when the head of technical docs 
> said "Nobody wakes up in the morning and says 'I want to hiera today'".  We 
> want the user experience to be easy to manage and work with. That doesn't 
> mean that if somebody wants to get into the bits/packages/projects/source 
> they shouldn't be able to -- we just don't want that to be a requirement. 
> 
> 
> 
> The head of technical docs was wrong, at least in the sense of the implied 
> comparison to "I want to puppet today".  People can and do use Hiera as a 
> standalone tool, and some do care about which version is in use at their 
> site.  Likewise for some of the other components.  It's true, however, that 
> the "puppet" tool is the headliner in this story.  That's why it was a poor 
> idea to put anything else's version number on the AIO package.  

No one — and by this I actually mean “not a single living soul upon the Earth” 
— has ever woken up and said “I *want* to memorize the versioning scheme of the 
toolkit I use to do my job, across ${number} of different components today” 
unless they were studying for a certification, test, etc. People *have* woken 
up and said “I want to use ${toolkit_that_I_do_my_job_with} today”, even if 
that was not what they called the toolkit. With that said, the principle that 
the Hiera version number should be subordinate to the Puppet version number _on 
some level_ is not an unreasonable one, and happens to be the answer I advocate 
for personally. I do agree that the AIO/${installer} version should always 
correspond to the release of the nominal headlining product.

> * Version numbers - they are hard. We restarted at 1.0 because it was a new 
> thing. Eric and I were talking yesterday and maybe it would have made more 
> sense to put it at 4; however because of the argument that he made earlier in 
> the thread, there are cases where that could create other types of confusion.
> 
> 
> I don't think that reflects a firm grasp of the nature of the problem.  The 
> issue is tha

Re: [Puppet Users] puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread Josh Cooper
On Thu, May 7, 2015 at 11:23 AM, jcf  wrote:

>
> On May 6, 2015, at 22:32, Josh Cooper  wrote:
>
> On Wed, May 6, 2015 at 7:29 AM, Johnson Earls 
> wrote:
>
>> never mind.  puppet agent ignores the user/group config settings, so
>> those should be kept at puppet, and ${::settings::user} /
>> ${::settings::group} should not be  used to configure agent-related options
>> (such as file ownership).
>>
>
> The `puppet` user and group are really server-side settings, to specify a
> less privileged account to run the webrick/passenger/puppetserver process
> as.
>
>
> So, maybe there should be a test to see if the user even exists before
> mass-chown’ing directories?
>

The file and directories I'm talking about are internal to puppet, e.g.
ssldir. When managing them, puppet already takes into account whether the
`puppet` user exists or not.

> To confuse things, `puppet` packages (rpm/deb) have always created the
> `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we
> have fixed this, so the puppet-agent package does not create a `puppet`
> user or group. Only the puppetserver package does that.
>
>
> So there is at least a dependency/ordering problem, at most an unchecked
> firehose turned on to change permissions, and this should be considered a
> bug. Also, this is playing pretty fast and loose with idempotence if this
> can’t be configured around.
>

The behavior of how puppet manages its internal files has not changed for a
long, long time. The only part that is different is which package creates
the `puppet` user and group.

What's the specific issue you're concerned about?

On Tuesday, May 5, 2015 at 10:40:00 PM UTC-7, Johnson Earls wrote:
>>>
>>> I'm running into a frustrating issue, and I'm wondering if I'm just not
>>> doing something right.
>>>
>>> My understanding is that the puppet agent has to run with the config
>>> "user" and "group" set to "root" so that it can make changes to the system.
>>> The puppet server, on the other hand, runs as user and group "puppet".
>>>
>>> However, every time the puppet agent activates, it changes the ownership
>>> of *most* of the subdirectories and files within the
>>> /etc/puppetlabs/puppet/ssl directory to root, which then prevents the
>>> puppet server from either starting up or being able to sign certificates.
>>>
>>
> In Puppet 4, you can get into this state if you install puppet-agent, and
> run it at least once. Since the `puppet` user won't exist, the agent will
> set permissions to `root:root:750` for file/directory-related settings like
> `privatekeydir`.
>
>
> Ouch. This violates the “principle of least surprise” at least two
> different ways.
>

If the `puppet` user doesn't exist, we use secure defaults.

> If you then install puppetserver, it will create the `puppet` user, start
> the server as that user, and fail to start, because the puppet user can't
> read `privatekeydir`, etc. However, as soon as you run `puppet agent` (or
> `apply`) on the master, it will restore the permissions to `puppet:puppet`
> and the puppetserver will start successfully.
>
>
> So, if I started the components in the wrong order once, it now takes an
> extra run to sort everything out, and doesn’t log it well enough to be
> deciphered? Double-ouch.
>

In practice this happens rarely. Usually you install puppetserver, which
brings in puppet-agent as a dependency.

But if you do run into this issue, I recommend filing a ticket and even
submitting a PR to update the puppetserver install logic.

>
>>> Am I misunderstanding how these two processes work and interact?
>>>
>>> Should the puppet agent run with the config user/group set to "puppet",
>>> even though puppet won't have permission to make most of the changes on the
>>> system?
>>> Or should the puppet server run as root?
>>>
>>>
>> --
>> 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/3955db48-4062-460c-a8a4-0df405277afb%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Josh Cooper
> Developer, Puppet Labs
>
> *PuppetConf 2015  is coming to Portland,
> Oregon! Join us October 5-9.*
> *Register now to take advantage of the Early Adopter discount
> 
>  *
> *—**save $349!*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
>

Re: [Puppet Users] Re: puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread Josh Cooper
On Thu, May 7, 2015 at 6:19 AM, jcbollinger 
wrote:

>
>
> On Thursday, May 7, 2015 at 12:32:59 AM UTC-5, Josh Cooper wrote:
>>
>>
>>
>> On Wed, May 6, 2015 at 7:29 AM, Johnson Earls 
>> wrote:
>>
>>> never mind.  puppet agent ignores the user/group config settings, so
>>> those should be kept at puppet, and ${::settings::user} /
>>> ${::settings::group} should not be  used to configure agent-related options
>>> (such as file ownership).
>>>
>>
>> The `puppet` user and group are really server-side settings, to specify a
>> less privileged account to run the webrick/passenger/puppetserver process
>> as.
>>
>>
>
> Right.
>
>
>
>> To confuse things, `puppet` packages (rpm/deb) have always created the
>> `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we
>> have fixed this, so the puppet-agent package does not create a `puppet`
>> user or group. Only the puppetserver package does that.
>>
>
>
> So the new package naming confuses even PL itself?
>
> I mean, in our recent discussion of the new package naming and versioning
> , Eric
> and Michael asserted that the "puppet-agent" package is the basic Puppet
> infrastructure package, with which one can run the agent, the traditional
> rack-based master, and everything else from Puppet's Ruby stack.  They
> claim the "puppetserver" package is *optional*.  I completely believe
> that's the *intention*, but in that case the "puppet-agent" package
> should be the one responsible for the "puppet" user and group.
>

We will be releasing updated passenger packages compatible with
puppet-agent "soon"[1]. These packages also create the `puppet` user and
group, like puppetserver.

That leaves webrick. I agree, there is currently an inconsistency --
webrick functionality is provided by the puppet-agent package, but the
package does not create the `puppet` user and group. However, you are free
to create the accounts (using `puppet apply` even!), or specify an
alternate account using Puppet's `user` and `group` settings.

That said, webrick is deprecated and will be removed in Puppet 5[2].

Josh

[1] https://tickets.puppetlabs.com/browse/PUP-4452
[2] https://groups.google.com/d/topic/puppet-dev/RHa2tMPRTx4/discussion

-- 
Josh Cooper
Developer, Puppet Labs

*PuppetConf 2015  is coming to Portland,
Oregon! Join us October 5-9.*
*Register now to take advantage of the Early Adopter discount

*
*—**save $349!*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97um6D8pRJOX_y8Kn0sEqGfPJ47J4H5WHjEM_6bac4%2BaMCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: parsejson truncating output (i think)

2015-05-07 Thread Allen Myers
and one more piece of info: The puppet server is configured using 
Passenger+apache. When I run

puppet agent --test


on a client system, parsejson fails by truncating the hash output.

But if I just run 'puppet apply ...' on the puppet server, as in

puppet apply create-users.pp


which contains

$myusers = parsejson (generate ('/bin/sh', '-c', 
'/var/lib/puppet/lib/create-user-hash.sh'))
notice ($myusers)

 
it works perfectly.

- Allen 

 


On Wednesday, May 6, 2015 at 12:47:10 PM UTC-7, Allen Myers wrote:
>
> Hi,
>
> I've got the following statements in my manifest:
>
> $myusers_json = generate ('/bin/sh', '-c', '/path/to/my/script.sh')
> notice ($myusers_json)
> $myusers = parsejson ($myusers_json)
> notice ($myusers)
>
>
> My script generates a list of users in JSON and I've verified that the 
> output format from 'notice ($myusers_json)' is correct using jsonlint.com.
> However, the output of 'notice ($myusers)' is always limited to 1985 
> bytes. It's just truncating the output. I know it's not just a short-coming
> of the 'notice' function because when I call
>
> create_resources(user, $myusers)
>
>
> if fails with the error 
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> expected ',' or '}' in object at '"user1" : {  "'! at 
> /etc/puppet/environments/mgmt/manifests/01-all-nodes.pp:24 on node 
> pupper-server1
>
>
> If I modify script.sh so that the result is less than a certain length 
> (depends on the number of fields and how many ':' get converted to '=>'), it
> works just fine. But the final output in puppet has format is being 
> limited to 1985 bytes.
>
> Any fix or work-around for this?
>
> Thanks!
>
> - Allen
>

-- 
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/e7024387-0934-47e3-917a-f67f7c16269b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: parsejson truncating output (i think)

2015-05-07 Thread Allen Myers
No one has replied yet, but just to fill in the environment details:

server: Linux ip-X-X-X-X 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 
22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
puppet:puppet --version 3.7.4   (open source)

thanks!

- Allen

On Wednesday, May 6, 2015 at 12:47:10 PM UTC-7, Allen Myers wrote:
>
> Hi,
>
> I've got the following statements in my manifest:
>
> $myusers_json = generate ('/bin/sh', '-c', '/path/to/my/script.sh')
> notice ($myusers_json)
> $myusers = parsejson ($myusers_json)
> notice ($myusers)
>
>
> My script generates a list of users in JSON and I've verified that the 
> output format from 'notice ($myusers_json)' is correct using jsonlint.com.
> However, the output of 'notice ($myusers)' is always limited to 1985 
> bytes. It's just truncating the output. I know it's not just a short-coming
> of the 'notice' function because when I call
>
> create_resources(user, $myusers)
>
>
> if fails with the error 
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> expected ',' or '}' in object at '"user1" : {  "'! at 
> /etc/puppet/environments/mgmt/manifests/01-all-nodes.pp:24 on node 
> pupper-server1
>
>
> If I modify script.sh so that the result is less than a certain length 
> (depends on the number of fields and how many ':' get converted to '=>'), it
> works just fine. But the final output in puppet has format is being 
> limited to 1985 bytes.
>
> Any fix or work-around for this?
>
> Thanks!
>
> - Allen
>

-- 
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/2ec95a9e-66f8-4bcb-ac9a-123796e331e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread jcf

> On May 6, 2015, at 22:32, Josh Cooper  wrote:
> 
> On Wed, May 6, 2015 at 7:29 AM, Johnson Earls  > wrote:
> never mind.  puppet agent ignores the user/group config settings, so those 
> should be kept at puppet, and ${::settings::user} / ${::settings::group} 
> should not be  used to configure agent-related options (such as file 
> ownership).
> 
> The `puppet` user and group are really server-side settings, to specify a 
> less privileged account to run the webrick/passenger/puppetserver process as.

So, maybe there should be a test to see if the user even exists before 
mass-chown’ing directories?

> To confuse things, `puppet` packages (rpm/deb) have always created the 
> `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we 
> have fixed this, so the puppet-agent package does not create a `puppet` user 
> or group. Only the puppetserver package does that.

So there is at least a dependency/ordering problem, at most an unchecked 
firehose turned on to change permissions, and this should be considered a bug. 
Also, this is playing pretty fast and loose with idempotence if this can’t be 
configured around.

> On Tuesday, May 5, 2015 at 10:40:00 PM UTC-7, Johnson Earls wrote:
> I'm running into a frustrating issue, and I'm wondering if I'm just not doing 
> something right.
> 
> My understanding is that the puppet agent has to run with the config "user" 
> and "group" set to "root" so that it can make changes to the system.
> The puppet server, on the other hand, runs as user and group "puppet".
> 
> However, every time the puppet agent activates, it changes the ownership of 
> most of the subdirectories and files within the /etc/puppetlabs/puppet/ssl 
> directory to root, which then prevents the puppet server from either starting 
> up or being able to sign certificates.
> 
> In Puppet 4, you can get into this state if you install puppet-agent, and run 
> it at least once. Since the `puppet` user won't exist, the agent will set 
> permissions to `root:root:750` for file/directory-related settings like 
> `privatekeydir`.

Ouch. This violates the “principle of least surprise” at least two different 
ways.

> If you then install puppetserver, it will create the `puppet` user, start the 
> server as that user, and fail to start, because the puppet user can't read 
> `privatekeydir`, etc. However, as soon as you run `puppet agent` (or `apply`) 
> on the master, it will restore the permissions to `puppet:puppet` and the 
> puppetserver will start successfully.

So, if I started the components in the wrong order once, it now takes an extra 
run to sort everything out, and doesn’t log it well enough to be deciphered? 
Double-ouch.

> 
> Am I misunderstanding how these two processes work and interact?
> 
> Should the puppet agent run with the config user/group set to "puppet", even 
> though puppet won't have permission to make most of the changes on the system?
> Or should the puppet server run as root?
> 
> 
> -- 
> 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/3955db48-4062-460c-a8a4-0df405277afb%40googlegroups.com
>  
> .
> 
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> Josh Cooper
> Developer, Puppet Labs
> 
> PuppetConf 2015  is coming to Portland, Oregon! 
> Join us October 5-9.
> Register now to take advantage of the Early Adopter discount 
> 
>  —save $349!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unqBLmMMfqE%2BJQ_R8MguFntxD%3DHxynM0uuY-O9py-s%2B4Q%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googl

[Puppet Users] Puppetboard Alternate port on Apache

2015-05-07 Thread Mark
I recently set up puppetboard to monitor all the nodes in my puppet 
environment. I set it up via apache using mod_wsgi. On port 80 it works 
just fine, however I found a conflict there that requires me to move 
puppetboard to a different port. It doesn't seem to matter what port I pick 
any port other than 80 causes the browser to hang and eventually come back 
withERR_CONNECTION_TIMED_OUT

I know the port is open because I can telnet into it. So I'm wondering if 
there is something that needs to be set within mod_wsgi. Anyone have ideas 
on what I'm missing here? 

Thanks,
mjr

-- 
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/f85c20aa-c66c-4a76-9573-61f861f61bb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: Distro puppet on Ubuntu Vivid broken; any plans for Puppetlabs to release their own packages?

2015-05-07 Thread Victor Danilchenko
OK, I filed a bug PUP-4540 . 
The short of it is, apparenlty Puppet apparently incorrectly detects *some 
*services 
(like mysql and cups) as Upstart services, and tries to manage them using 
the Upstart commands (/sbin/{start,stop,restart,reload,status}) -- but 
detects other services (e.g. apache2) normally, and manages them correctly, 
using the old-style init commands ('service mysql restart' and somesuch).

This is the case on Ubuntu Vivid and the stock Puppet that ships with it, 
3.7.2. Ubuntu Trusty works fine.

-- 
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/549a4b56-503b-47f7-bac9-740e9688590f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] help to push multiple ssh key to client machine

2015-05-07 Thread Christopher Wood
On Thu, May 07, 2015 at 08:50:12AM -0700, Mohan L wrote:
>Dear All,
>I am new to Puppet. Recently started l learning it.
>I need to push multiple ssh keys for client machine, 
>Here is what I have written:
>Hiera:
># cat hiera.yaml | grep -v ^#
>---
>:backends:
>  - yaml
>:hierarchy:
>  - global
>:yaml:
>  :datadir: /etc/puppet/hieradata
> 
># cat /etc/puppet/hieradata/global.yaml
># hash with keys in the hiera structure. The hash is merged with
>hiera_hash lookup
>sshkeys::keys:
>  sg-vm-agent-004:
>    user: 'ubuntu'
>    type: 'ssh-rsa'
>    key:
>
> 'B3NzaC1yc2EDAQABAAABAQDJzdGydf2tdZYCkBRGx/SnlVKW+9q3Mqtf9vCrs0SaSkwDK4Q36hS40IVgmri2mjKeWFr5p92OgYY1hjZk4LLUAbVV8ItmPLqvmfrkOEwDCzmkbrUVa4BTKePWG0hOGAVYSQkS+1vhsTFhtznJMxsjRVwj8tO3s0fSnaXcovs9d4LwXhRbcDjzrAVRkk2d5/lSbjc/T4ZJ6oMKcGCxq02etJMoSBBQsEfRP/vULqKjoxJ96kb3Y43tU7gRzcVkXAyNqpXie8fD/FopoVi/uHIqkzotkOwztUYNt6C5LwV/W4ds5x3Zl7Jo4kqup2FOCs4oXSC3WxJI5FJ9WuPMtK1r'
># cat site.pp
>$keys_hash = hiera_hash('sshkeys::keys',undef)
>$username=$keys_hash[$hostname]['user']
>sshkeys::key { "$hostname":
>    key_name => "$hostname",
>    user     => "$username",
>}
>How to push multiply ssh keys to client?

For puppet <4, look into create_resources and defined types.

https://docs.puppetlabs.com/puppet/3.7/reference/lang_defined_types.html

http://docs.puppetlabs.com/references/3.stable/function.html#createresources

For puppet 4, it's probably easier to loop over the hash keys. I haven't used 
this yet.

https://docs.puppetlabs.com/puppet/latest/reference/future_lang_iteration.html

>thanks for your time
> 
>--
>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 [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/d9125204-7e05-472c-8029-1cb6f0a1c476%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/d9125204-7e05-472c-8029-1cb6f0a1c476%40googlegroups.com?utm_medium=email&utm_source=footer
>3. 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/20150507172651.GA8304%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] help to push multiple ssh key to client machine

2015-05-07 Thread Mohan L
Dear All,

I am new to Puppet. Recently started l learning it.

I need to push multiple ssh keys for client machine, 

Here is what I have written:

Hiera:

# cat hiera.yaml | grep -v ^#
---
:backends:
  - yaml
:hierarchy:
  - global

:yaml:
  :datadir: /etc/puppet/hieradata
 
# cat /etc/puppet/hieradata/global.yaml

# hash with keys in the hiera structure. The hash is merged with hiera_hash 
lookup
sshkeys::keys:
  sg-vm-agent-004:
user: 'ubuntu'
type: 'ssh-rsa'
key: 
'B3NzaC1yc2EDAQABAAABAQDJzdGydf2tdZYCkBRGx/SnlVKW+9q3Mqtf9vCrs0SaSkwDK4Q36hS40IVgmri2mjKeWFr5p92OgYY1hjZk4LLUAbVV8ItmPLqvmfrkOEwDCzmkbrUVa4BTKePWG0hOGAVYSQkS+1vhsTFhtznJMxsjRVwj8tO3s0fSnaXcovs9d4LwXhRbcDjzrAVRkk2d5/lSbjc/T4ZJ6oMKcGCxq02etJMoSBBQsEfRP/vULqKjoxJ96kb3Y43tU7gRzcVkXAyNqpXie8fD/FopoVi/uHIqkzotkOwztUYNt6C5LwV/W4ds5x3Zl7Jo4kqup2FOCs4oXSC3WxJI5FJ9WuPMtK1r'


# cat site.pp

$keys_hash = hiera_hash('sshkeys::keys',undef)

$username=$keys_hash[$hostname]['user']

sshkeys::key { "$hostname":
key_name => "$hostname",
user => "$username",
}

How to push multiply ssh keys to client?

thanks for your time

-- 
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/d9125204-7e05-472c-8029-1cb6f0a1c476%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] client certificate issue

2015-05-07 Thread Karel
Hi,

I have a problem with a certificate on some servers.

C:\Program Files\Puppet Labs\Puppet Enterprise\bin>puppet agent -t
Error: Could not request certificate: The certificate retrieved from the 
master does not match the agent's private key.
Certificate fingerprint: 93:85:FC:CF:32:19:43:33:75:43:B0:43:D3:60:4C:69
To fix this, remove the certificate from both the master and the agent and 
then start a puppet run, which will automatically regenerate a certficate.
On the master:
puppet cert clean ..

I would need to know if it is possible to track this issue from Puppet 
Master side. Is this communication logged somewhere to log files on Puppet 
Master servers?
I need to know a list of clients that have the problem with the cert.

Thanks,
Karel

-- 
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/03c55bc1-4ba4-422d-aba5-2b66274e30ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: check if user exist

2015-05-07 Thread jcbollinger


On Thursday, May 7, 2015 at 5:17:22 AM UTC-5, Alfredo De Luca wrote:
>
> Hi all. 
> I am using puppet source with Hiera. I want to manage users but also I 
> want to check if an user exist before doing something else and create 
> it. 
>
> I have a module prousers as follow: 
>
> prousers/init.pp 
> class prousers { 
> create_resources(user, hiera_hash('pro_user')) 
> } 
>
>
> then from hiera 
>
> common.yaml 
> pro_user: 
>   bla1: 
> ensure: 'present' 
> comment: 'bla bla 1' 
> managehome: 'true' 
> uid: '1579' 
>   bla2: 
> ensure: 'present' 
> comment: 'bla bla 2' 
> managehome: 'true' 
> uid: '1014' 
>
>
> How can I check in the prousers module if an user exist or other checks? 
>
>

If you want to condition parts of a node's catalog on whether a given user 
exists, then

   1. the condition must be based on the system's state *at the time of the 
   catalog request* (not during catalog application), and
   2. you would accomplish it by writing a custom fact to probe that user's 
   existence and provide that information to the master.

HOWEVER, it's unclear whether that's really what you want.  If the 
objective is to check whether user 'pro_user' exists so that you can create 
him if he's not already present, then that's an ineffective way to use 
Puppet.  If the point is that any node having class prousers should have 
all the users specified in the Hiera data, then natural way to approach it 
is to simply declare all those users.  As with any other resource type, 
Puppet examines the current state of each declared user (including whether 
he exists at all), and performs exactly those actions needed to bring the 
node to the target state expressed in its catalog -- no more, no less.

If you want to be sure that other resources are managed only after the 
users have been put in the desired state, then that is the purpose of 
resource relationships.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2348ab8f-a814-4593-894e-7e343e52018c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Re: puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

2015-05-07 Thread jcbollinger


On Thursday, May 7, 2015 at 12:32:59 AM UTC-5, Josh Cooper wrote:
>
>
>
> On Wed, May 6, 2015 at 7:29 AM, Johnson Earls  > wrote:
>
>> never mind.  puppet agent ignores the user/group config settings, so 
>> those should be kept at puppet, and ${::settings::user} / 
>> ${::settings::group} should not be  used to configure agent-related options 
>> (such as file ownership).
>>
>
> The `puppet` user and group are really server-side settings, to specify a 
> less privileged account to run the webrick/passenger/puppetserver process 
> as.
>
>

Right.

 

> To confuse things, `puppet` packages (rpm/deb) have always created the 
> `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we 
> have fixed this, so the puppet-agent package does not create a `puppet` 
> user or group. Only the puppetserver package does that.
>


So the new package naming confuses even PL itself?

I mean, in our recent discussion of the new package naming and versioning 
, Eric 
and Michael asserted that the "puppet-agent" package is the basic Puppet 
infrastructure package, with which one can run the agent, the traditional 
rack-based master, and everything else from Puppet's Ruby stack.  They 
claim the "puppetserver" package is *optional*.  I completely believe 
that's the *intention*, but in that case the "puppet-agent" package should 
be the one responsible for the "puppet" user and group.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6127f5ca-a620-4e92-ab11-9fd8ea41c7d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppet exported resources dramatic performance

2015-05-07 Thread Ken Barber
> I know this has been discussed several times, but I did not find the
> information/fix I’m looking for, so here I go…
>
> I have a farm of ~370 servers.
>
> I have a single puppet master (12 physical cores, lots of RAM) on which I
> deployed puppet 3.7.5 this week (not using r10k, that’s on our huge todo
> list).
>
> I am running on Scientific Linux 6.2 (RHEL like) + Passenger + Foreman as
> ENC.
>
> More than puppet 3.7.5, I deployed the saz/ssh (2.5.0) module (required by
> the openstack modules), which in turns by default enables puppet exported
> resources collection for the ssh keys.
>
>
>
> Since I was using a local hack with the generate function to achieve the
> same goal, I let the ssh keys collection in place… and it worked OK until I
> deployed that in production .
>
> I then faced huge Passenger overloads, and nearly all puppet runs failed
> until I raised the PassengerMaxPoolSize to 200 instead of 12 (yes…).
>
>
>
> I have found out that enabling/disabling the SSH keys collection on  a
> specific host causes the compilation time to jump from 17s to 53s or even
> more.
>
>
>
> I have tried querying the puppetdb for those specific Sshkey resources using
> curl and to my surprise, this was quite quick.
>
> I am currently profiling the puppet master and will send that data to
> puppetlabs if that’s still usefull to them (see :
> https://puppetlabs.com/blog/tune-puppet-performance-profiler), but I would
> like to know if someone would understand what’s wrong with that use of
> exported resources ?

I think this direction is best, I would set up master profiling and
submit it to this thread for analysis (or take a look yourself, this
might be enough to figure it out). The PDB terminus has profiling
hooks which will also show the times it takes to perform queries as
they happen. However, like its been stated in other parts of the this
thread, it might not be the collection query at all, but an aspect of
the catalog compilation. We just can't presume until we see the
profile.

Also comparison between 'quiet' load and 'heavy' load is a good thing,
your delays in compilation could be due to lots of running threads,
keeping your profiling separate means you can compare catalog
compilation times on a single node much easier, and alleviates other
noise caused by 'general load'.

Also, if you haven't done so already - the new Clojure based puppet
server will potentially give you perf gains over the passenger
mechanism, I would definitely consider experimenting with it, if you
haven't already.

ken.

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


[Puppet Users] Deprecation of HSQLDB for PuppetDB

2015-05-07 Thread Ken Barber
Hi all,

As a representative of the PuppetDB engineering team, I wanted to let
you all know we are deprecating support for HSQLDB (HyperSQL DataBase)
in the next major release of PuppetDB (version 3.0). We will drop
support in the major release after that (version 4.0).

Note: For those customers using Puppet Enterprise, this email should
not apply to you, since we have never supported HSQLDB there. However,
if you have any questions about this feel free to ask me or open a
support case.

Since PuppetDB was released in 2012 we've supported HSQLDB as an
alternative database store, for both development and smaller use
cases. The intention (and the reality) was that HSQLDB was never
really intended for middle to large production use-cases. Over the
years we've often struggled to maintain support, given its substantial
limitations as compared to PostgreSQL.

Largely this has been fine, but as time goes on and we push the
platform further, HSQLDB’s more limited capabilities have forced us to
make decisions that favor the lowest common denominator. Sometimes
this wasn't a major problem, other times it has slowed development,
and forced us to limit the features, performance, and design for
everyone.

For example:

* For queries that include child data (i.e. catalogs containing
resources) we have an excellent PostgreSQL solution using JSON
aggregation functions in 3.0, but HSQLDB simply can't support this
case efficiently, and so we are forced to perform multiple queries
instead.
* JSONB based storage offers substantial promise for our
document-style data, but since HSQLDB doesn’t support it, we haven't
been able to seriously pursue the benefits.
* Common Table Expressions could simplify and improve the performance
of some of our queries, and although HSQLDB has CTE’s, they're weak
enough that we've had to avoid using them.
* HSQLDB lacks some basic operational functions, like online backups
and online querying (for debugging purposes). Instead you must stop
the service entirely before proceeding.
* Performance tuning for HSQLDB  is more difficult, since it doesn't
have a powerful query optimizer and since it’s more difficult to to
execute explain plans. We've hit various cases where we've had to
completely redesign the way we construct a query because HSQLDB’s
optimizer couldn't handle the work.

Our general opinion is that instead of compromising our overall
solution and making choices for a more ‘development’ or ‘smaller scale
only’ focused solution, we want to remove that from the equation and
to only support the more production-ready case, which is PostgreSQL
today.

What does this mean to you all? Well we'll start shipping deprecation
messages in the next major release, and the default setup will become
PostgreSQL for new installs.

For the more studious of you all, we recommend not waiting for this,
and migrating as soon as possible. However don't worry, HSQLDB will
still continue to work for the lifetime of the next major release.

For those wanting to migrate, we have supplied tooling and
documentation so that you can export your database from a HSQLDB based
system to something using PostgreSQL:

http://docs.puppetlabs.com/puppetdb/2.3/migrate.html#exporting-data-from-an-existing-puppetdb-database

For PostgreSQL setup, the PGDG team have made it super simple with
their new package repos to get the latest and greatest PostgreSQL on
most popular distributions:

https://wiki.postgresql.org/wiki/YUM_Installation
https://wiki.postgresql.org/wiki/Apt

In addition we supply a Puppet module designed for this purpose which
we highly recommend, that has had contributions from a large number of
good people over the years:

https://forge.puppetlabs.com/puppetlabs/postgresql

And for those of you who are already using our PuppetDB module,
consult the documentation on how to change your configuration to use
PostgreSQL:

https://forge.puppetlabs.com/puppetlabs/puppetdb

In any case, know that this decision hasn’t been made lightly, and
we’ve been weighing it for some time. About a year ago we had almost
45% of our reported users using HSQLDB, but this number is now less
than 20%. So while we understand that people may have legitimate
reasons for using HSQLDB, we don't feel that given the substantial
disadvantages, there’s sufficient justification to maintain support,
when doing so negatively affects the majority of users.

Of course, it goes without saying that if you have any questions or
trouble migrating to PostgreSQL, the puppet-users mailing list and the
#puppet IRC channel are watched by a number of us in the PuppetDB team
(not to mention, by other avid community users who are also helpful),
so we can help where necessary with any problems.

Regards

Ken Barber
PuppetDB Team
Puppet Labs Inc.

-- 
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.c

[Puppet Users] check if user exist

2015-05-07 Thread Alfredo De Luca
Hi all.
I am using puppet source with Hiera. I want to manage users but also I
want to check if an user exist before doing something else and create
it.

I have a module prousers as follow:

prousers/init.pp
class prousers {
create_resources(user, hiera_hash('pro_user'))
}


then from hiera

common.yaml
pro_user:
  bla1:
ensure: 'present'
comment: 'bla bla 1'
managehome: 'true'
uid: '1579'
  bla2:
ensure: 'present'
comment: 'bla bla 2'
managehome: 'true'
uid: '1014'


How can I check in the prousers module if an user exist or other checks?

Any info would be appreciated.

Regards

-- 
Alfredo

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


RE: [Puppet Users] puppet exported resources dramatic performance

2015-05-07 Thread SCHAER Frederic
Hi Michael,

To be honnest, I’m looking at how I/we can move to a multi-master setup, but 
that means both multi-master, but also moving to something like R10K (I chose 
the monolithic deployment 2 or 3 years ago…), but also making sure the puppet 
fileserver is shared, and that’s something that I fear will take me time. Plus 
: I don’t have many exported resources, just SSH (public) keys and a few 
OMD/Nagios checks – I can’t believe this is normal that just deploying the SSH 
(exported) keys hammers so much on the puppet master(s)…
As I say, I do not feel I’m not doing huge puppetdb things ?

Regards

De : puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] De la 
part de Michael Pawlak
Envoyé : mercredi 6 mai 2015 18:56
À : puppet-users@googlegroups.com
Objet : Re: [Puppet Users] puppet exported resources dramatic performance

Frederic,
Based on the size of your farm, you may want to start thinking about either 
load balancing your puppet master (nginx, ha proxy, SRV records, etc.) or 
possibly decentralizing your puppet deployments (masterless). Remember that all 
manifest compilations take place on the puppet master and not the clients. This 
means all collected resources, for all 350+ hosts must funnel through your 
puppet master, which then has to update the storedconfigs in puppetdb. This can 
be a significant amount of load for the puppet master, considering the size of 
your deployment.
So, if performance is a concern/issue with you, look into other methods of 
spreading the work load or decentralizing to get the performance you desire.


Michael Pawlak
Web Systems Administrator | Colovore LLC
E: m...@colovore.com
C: 408.316.2154
 
[http://s3.amazonaws.com/crunchbase_prod_assets/assets/images/resized/0028/6576/286576v1-max-250x250.png]
 

On Wed, May 6, 2015 at 8:00 AM, SCHAER Frederic 
mailto:frederic.sch...@cea.fr>> wrote:
Hi Puppet users,

I know this has been discussed several times, but I did not find the 
information/fix I’m looking for, so here I go…
I have a farm of ~370 servers.
I have a single puppet master (12 physical cores, lots of RAM) on which I 
deployed puppet 3.7.5 this week (not using r10k, that’s on our huge todo list).
I am running on Scientific Linux 6.2 (RHEL like) + Passenger + Foreman as ENC.
More than puppet 3.7.5, I deployed the saz/ssh (2.5.0) module (required by the 
openstack modules), which in turns by default enables puppet exported resources 
collection for the ssh keys.

Since I was using a local hack with the generate function to achieve the same 
goal, I let the ssh keys collection in place… and it worked OK until I deployed 
that in production .
I then faced huge Passenger overloads, and nearly all puppet runs failed until 
I raised the PassengerMaxPoolSize to 200 instead of 12 (yes…).

I have found out that enabling/disabling the SSH keys collection on  a specific 
host causes the compilation time to jump from 17s to 53s or even more.

I have tried querying the puppetdb for those specific Sshkey resources using 
curl and to my surprise, this was quite quick.
I am currently profiling the puppet master and will send that data to 
puppetlabs if that’s still usefull to them (see : 
https://puppetlabs.com/blog/tune-puppet-performance-profiler), but I would like 
to know if someone would understand what’s wrong with that use of exported 
resources ?

I’m not putting tons of things in there, so I can’t understand how this can 
have such a huge impact on my “relatively” sized cluster..
Any known workaround other than adding more puppet masters ? (I know it might 
be possible to query the puppetdb directly from a template, but I do not own 
the saz/ssh module, so that would be some work to create a pull request just to 
work around… well, a “basic” feature)
My last resort would be to disable the use of exported resources for the ssh 
keys and revert to my hack, but I can’t do that for my monitoring anyway, and 
that would surely also benefit from a fix…

I don’t know if I could use the puppet server (not master) easily with foreman, 
maybe that’d be something to try too…

Thanks for any hint && Regards !
Frederic  Schaer
--
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/CAB586860327CB498EF79903967FEA231747172E%40E-EXDAGE-A0.extra.cea.fr.
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 receivi