Re: [Puppet Users] Puppet on s390

[far4d]

You can get the package directly on packages.debian.org, e.g. 
https://packages.debian.org/stretch/puppet or 
https://packages.debian.org/stretch/facter. Additionally you can browse the 
source of the package on http://sources.debian.net/search/facter/

Debian offers a great visibility and transparency when it comes to 
packages/patch-tracking/source-code.

HTH

far4d

On Tuesday, May 5, 2015 at 3:53:23 PM UTC+2, Michael Weiner wrote:
>
> Rob
>
> Thank you. Do you know where I can get this source code? It doesn't appear 
> that I can download anything from the debian link.
>
> It seems to me the problem I had was with facter
>

-- 
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/0aa00a0c-f89a-404c-bdce-e901a44d7a2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Message from application: Permission denied - /etc/puppet/modules (Errno::EACCES)

[joe]

 

Hi All,

Brand new to puppet and am trying to get a simpler master server set up to 
test it out. I've been following the install guide 
at http://docs.puppetlabs.com/guides/install_puppet/install_el.html. This 
is on CentOS 7 on AWS. Everything goes fine, through the installation of 
passenger. When I start apache and fire up a browser, I get a generic error 
message in my browser and this shows up in the error_log. Any clues as to 
what the permissions issue is would be great. Originally, everything in 
/etc/puppet/ was owned by root. I changed it to puppet (which is the user 
that owns the config.ru file) and that didn't matter either. I'm at a loss 
a this point, so any help would be great.


[ 2015-05-10 21:09:09.6731 1455/7f09e7bc0700 App/Implementation.cpp:287 ]: 
Could not spawn process for application 
/usr/share/puppet/rack/puppetmasterd: An error occured while starting up 
the preloader.

  Error ID: a313ca62

  Error details saved to: /tmp/passenger-error-Lw6ZvE.html

  Message from application: Permission denied - /etc/puppet/modules 
(Errno::EACCES)

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:136:in `open'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:136:in `entries'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:136:in `block in 
module_directories'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:135:in `collect'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:135:in 
`module_directories'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:164:in 
`search_directories'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:94:in `files_to_load'

  /usr/share/ruby/vendor_ruby/puppet/util/autoload.rb:225:in `files_to_load'

  /usr/share/ruby/vendor_ruby/puppet/application.rb:229:in 
`available_application_names'

  /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:105:in 
`find_subcommand'

  /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:92:in `execute'

  config.ru:35:in `block in '

  /usr/local/share/gems/gems/rack-1.6.1/lib/rack/builder.rb:55:in 
`instance_eval'

  /usr/local/share/gems/gems/rack-1.6.1/lib/rack/builder.rb:55:in 
`initialize'

  config.ru:1:in `new'

  config.ru:1:in `'

  
/usr/local/share/gems/gems/passenger-5.0.7/helper-scripts/rack-preloader.rb:107:in
 
`eval'

  
/usr/local/share/gems/gems/passenger-5.0.7/helper-scripts/rack-preloader.rb:107:in
 
`preload_app'

  
/usr/local/share/gems/gems/passenger-5.0.7/helper-scripts/rack-preloader.rb:153:in
 
`'

  
/usr/local/share/gems/gems/passenger-5.0.7/helper-scripts/rack-preloader.rb:29:in
 
`'

  
/usr/local/share/gems/gems/passenger-5.0.7/helper-scripts/rack-preloader.rb:28:in
 
`'



[ 2015-05-10 21:09:09.6767 1455/7f09e209e700 
age/Hel/Req/CheckoutSession.cpp:252 ]: [Client 1-2] Cannot checkout session 
because a spawning error occurred. The identifier of the error is a313ca62. 
Please see earlier logs for details about the error.

Thanks!

Joe

-- 
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/ac934556-4b75-498e-9c8b-6662c2dc8931%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Multiple facts getting the same value

[jcbollinger]

On Friday, May 8, 2015 at 10:42:03 AM UTC-5, James Oden wrote:
>
> I created a custom fact file to generate home_$user entries for all 
> users on the system containing their respective home directories: 
>
>require 'etc' 
>
>while pwEnt = Etc.getpwent do 
>name = pwEnt.name 
>home = pwEnt.dir 
>var  = "home_#{name}" 
>Facter.add(var) do 
>setcode do 
>home 
>end 
>   end 
>end 
>Etc.endpwent 
>
> When I use it though every home_$user entry has the same value (the 
> home directory of the last user it processed).  I can add print 
> statements and see that the loop is getting the right information. 
> What am I doing wrong or not understanding? 
>
>

I think you're probably being tripped up by the fact that the setcode block 
is a closure.  As the name suggests, it is a block of *code* that is 
executed later, separately from the block that declares it.  But each of 
your facts's setcode blocks encloses a reference to *the same* home 
variable of the enclosing block, whose value you change at every iteration 
of the loop.  Thus all the facts present the same value: whichever should 
correspond to the last pwent considered.

The Facter API is designed around the idea that each fact will evaluate its 
value upon request.  Pre-defining specific facts to have specific values 
can be made to work, and it should then do what you expect for a run of 
standalone Facter, but it may surprise you in other contexts.  For example, 
if a long-running process -- say the agent running as a daemon -- loads 
Facter into itself, then all those facts are defined at that point.  If the 
plugin code does not change (thereby triggering the process to reload 
them), then the facts themselves will not change either, notwithstanding 
any changes to the underlying system.

The most natural way to approach the problem would be to define a single 
custom, structured fact whose value is a hash mapping user names to home 
directories.  That might look something like this:

require 'etc' 
 
Facter.add('homeDirs') do
   setcode do
  homeDirs = {}
  Etc.passwd { |pwEnt| homeDirs[pwEnt.name] = pwEnt.dir }
  homeDirs
   end 
end


Structured facts require Facter 2.0 or above, and Puppet (< 4.0) must be 
configured to not stringify facts.


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/ac17a41c-7d98-4c6c-896b-60d6b7fdb241%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to do Puppet type which autorequire an existing declaration of another type

[jcbollinger]

On Sunday, May 10, 2015 at 8:03:25 AM UTC-5, Martin Alfke wrote:
>
> Hi, 
>
> I am working on some types and providers for opennebula network 
> management. 
>
> I have one type already finished, which creates the network itself. 
> Each network can have multiple address ranges. 
>
> My idea so far: 
>
> onevnet { ’testnet’: 
>   ensure => present, 
>   … 
> } 
>
> onevnet_addressrange { ‘’: 
>   ensure  => present, 
>   onevnet => ‘testnet’, 
>   … 
> } 
>
> How can I enforce that onevent ‘testnet’ has to be declared? 
> I found auto require but that seems to be optional (or did I miss 
> something). 
>


Autorequire is about order-of-application dependencies between resources 
under Puppet management.  It is not about which resources *should be* under 
management in the first place.  For example, autorequire automatically 
causes a File's parent directory to be managed before the File itself, 
provided that the parent is under management.

You should consider structuring your type so that instances do not 
inherently depend on another resource being declared.  A hard dependency 
such as that is a good sign that your resource is not properly scoped.

If for some reason you must have a hard dependency, then the easiest route 
to take might be to specify that the plugin type is for your module's 
internal use only (though you cannot enforce that), and provide a defined 
type wrapper for public use.  The wrapper can declare a fixed, 
unconditional relationship with whatever other resources you like, and 
catalog building will fail if any of those resources is not declared.


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/d0ce5ac8-100a-42ed-90d5-ee5286c7aa7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Multiple facts getting the same value

[James Olin Oden]

That was exactly what was confusing me.   I had figured this out
shortly after sending the email...but I'm glad I didn't reply as I got
your structured facts answer which is good information to know.

Thanks...James

On Mon, May 11, 2015 at 10:01 AM, jcbollinger  wrote:
>
>
> On Friday, May 8, 2015 at 10:42:03 AM UTC-5, James Oden wrote:
>>
>> I created a custom fact file to generate home_$user entries for all
>> users on the system containing their respective home directories:
>>
>>require 'etc'
>>
>>while pwEnt = Etc.getpwent do
>>name = pwEnt.name
>>home = pwEnt.dir
>>var  = "home_#{name}"
>>Facter.add(var) do
>>setcode do
>>home
>>end
>>   end
>>end
>>Etc.endpwent
>>
>> When I use it though every home_$user entry has the same value (the
>> home directory of the last user it processed).  I can add print
>> statements and see that the loop is getting the right information.
>> What am I doing wrong or not understanding?
>>
>
>
> I think you're probably being tripped up by the fact that the setcode block
> is a closure.  As the name suggests, it is a block of code that is executed
> later, separately from the block that declares it.  But each of your facts's
> setcode blocks encloses a reference to the same home variable of the
> enclosing block, whose value you change at every iteration of the loop.
> Thus all the facts present the same value: whichever should correspond to
> the last pwent considered.
>
> The Facter API is designed around the idea that each fact will evaluate its
> value upon request.  Pre-defining specific facts to have specific values can
> be made to work, and it should then do what you expect for a run of
> standalone Facter, but it may surprise you in other contexts.  For example,
> if a long-running process -- say the agent running as a daemon -- loads
> Facter into itself, then all those facts are defined at that point.  If the
> plugin code does not change (thereby triggering the process to reload them),
> then the facts themselves will not change either, notwithstanding any
> changes to the underlying system.
>
> The most natural way to approach the problem would be to define a single
> custom, structured fact whose value is a hash mapping user names to home
> directories.  That might look something like this:
>
> require 'etc'
>
> Facter.add('homeDirs') do
>setcode do
>   homeDirs = {}
>   Etc.passwd { |pwEnt| homeDirs[pwEnt.name] = pwEnt.dir }
>   homeDirs
>end
> end
>
>
> Structured facts require Facter 2.0 or above, and Puppet (< 4.0) must be
> configured to not stringify facts.
>
>
> 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/ac17a41c-7d98-4c6c-896b-60d6b7fdb241%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/CAPWHxfJx%3D6kdhBnaCq%2BkLHD3R_BSY_2%2BMjNkkCT_jOLJAa3_wA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to do Puppet type which autorequire an existing declaration of another type

[Martin Alfke]

Hi John,

many thanks for your explanation.
I will stay with auto require to allow managing resource B without the need for 
having the depending A resource declared within puppet too.

Best,

Martin


On 11 May 2015, at 16:17, jcbollinger  wrote:

> 
> 
> On Sunday, May 10, 2015 at 8:03:25 AM UTC-5, Martin Alfke wrote:
> Hi, 
> 
> I am working on some types and providers for opennebula network management. 
> 
> I have one type already finished, which creates the network itself. 
> Each network can have multiple address ranges. 
> 
> My idea so far: 
> 
> onevnet { ’testnet’: 
>   ensure => present, 
>   … 
> } 
> 
> onevnet_addressrange { ‘’: 
>   ensure  => present, 
>   onevnet => ‘testnet’, 
>   … 
> } 
> 
> How can I enforce that onevent ‘testnet’ has to be declared? 
> I found auto require but that seems to be optional (or did I miss something). 
> 
> 
> Autorequire is about order-of-application dependencies between resources 
> under Puppet management.  It is not about which resources should be under 
> management in the first place.  For example, autorequire automatically causes 
> a File's parent directory to be managed before the File itself, provided that 
> the parent is under management.
> 
> You should consider structuring your type so that instances do not inherently 
> depend on another resource being declared.  A hard dependency such as that is 
> a good sign that your resource is not properly scoped.
> 
> If for some reason you must have a hard dependency, then the easiest route to 
> take might be to specify that the plugin type is for your module's internal 
> use only (though you cannot enforce that), and provide a defined type wrapper 
> for public use.  The wrapper can declare a fixed, unconditional relationship 
> with whatever other resources you like, and catalog building will fail if any 
> of those resources is not declared.
> 
> 
> 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/d0ce5ac8-100a-42ed-90d5-ee5286c7aa7c%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/7963F5C4-3520-4D4A-B96C-A5B1178A96EB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Load balancing Puppet Server

[Joao Morais]

Hello list.

I'm using open source Puppet 3.7.4 with Puppet Server 1.0.2 and I'm 
evaluating how to load balance two or more Puppet Servers, specially about 
centralizing the CA. Is the doc 
http://docs.puppetlabs.com/guides/scaling_multiple_masters.html up to date 
and is it the way to go? If so, is there a way to "Proxy Certificate Traffic 
"
 
on Puppet Server just like I'd do with Apache's mod_proxy?

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/b6bc2fe6-3df1-4db3-a9fb-537f5be893d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Message from application: Permission denied - /etc/puppet/modules (Errno::EACCES)

[Gabriel Filion]

Hey there,

On 10/05/15 10:15 PM, j...@poweriep.com wrote:
>   Message from application: Permission denied - /etc/puppet/modules
> (Errno::EACCES)

make sure to also verify permissions on /etc/puppet itself. If the
puppet user can't traverse the directory then the process won't be able
to open up the modules subdir.

to help out with permissions errors, what you can usually do is to
switch to that user and try listing directories/accessing files:

# su -s /bin/bash - puppet
> ls /etc/puppet/modules
> ls -ld /etc/puppet

hth

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


signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Puppet for VM on Windows 7 - confused!

[Rob Reynolds]

Hi Karen,

On Sat, May 9, 2015 at 12:53 AM, Karen Ellrick 
wrote:

> Having already used Puppet a bit by way of a pre-packaged ZIP file created
> by the PuPHPet online tool, I decided to try building a simpler VM without
> the tool. I have VirtualBox and Vagrant already installed and happy. What
> do I do next? I'm getting too many seemingly conflicting instructions.
>
> This looked like a nice simple starting point:
> https://github.com/miccheng/vagrant-lamp-centos63 It had three git
> commands, after which I should have been able to run vagrant and have a
> basic LAMP box.
>
> But the repo said it was deprecated and replaced by this:
> https://github.com/sgphpug/Vagrant-LAMP-CentOS64 Okay, fine. But the
> newer one has completely different instructions for installation - gem
> install of puppet and librarian-puppet, some dependency stuff, etc. I was
> pleasantly surprised to discover that I do have Ruby installed (I had no
> idea - this is an ordinary Windows PC), so I opened a command prompt, cd'ed
> to a logical spot (in case that would matter), and tried the first command: 
> gem
> install puppet. After about a half hour, with some complaints about not
> being able to convert some things to UTF-8, it was still trying to do
> who-knows-what. I looked in several likely spots for some hint that files
> related to Puppet were being saved somewhere, but couldn't find anything. I
> have no idea where it was installing anything.
>
> While it still ran in the background, I went back to Google and looked for
> more info about installing Puppet on Windows. I found this page:
> https://docs.puppetlabs.com/guides/install_puppet/install_windows.html#automated-installation
> That describes a completely different sort of thing from Ruby gems, a more
> typical Windows-ish installation. But the Pre-Install Tasks
>  page
> talked of a puppet master that must be on a *nix machine somewhere. It
> said: "*Your puppet master(s) should be robust dedicated servers that can
> handle the amount of agents they'll need to serve.*" Hmm, I don't have
> one of those, but perhaps it will be all right. After all, I had no trouble
> with the PuPHPet boxes.
>

I believe you are referring to this[1]. This is merely meant to state that
Windows only has an agent available in a Master/Agent scenario.

[1]
http://docs.puppetlabs.com/guides/install_puppet/pre_install.html#choose-your-puppet-master-servers


> So I halted the gem-based task (which still hadn't finished!), downloaded
> the 64-bit msi file, and ran it. It said: "*This will install Puppet
> (64-bit) 3.7.5 and configure the system to fetch configurations every half
> hour. This version of Puppet (64-bit) will work with puppet masters running
> Puppet 3.0 or higher.*" Hmph! Not only do I not have a puppet master or a
> place to put one, but I don't want something running constantly on my PC
> that tries to go to some server every half hour for who knows what. The
> pre-install page also mentioned Standalone Puppet
> 
> that doesn't use a master, but it didn't give any hints about how to do
> that.
>

The MSI is the primary means of installing Puppet on Windows. If you want a
standalone Puppet, you just want to pass PUPPET_AGENT_STARTUP_MODE=Disabled
to the MSI installer - see Automated Installation[2] and MSI Properties[3].
I see that you found the automated installation section already but perhaps
we should draw out more that you can run the standalone puppet by setting
that property to disabled in the actual installer.

[2]
http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#automated-installation
[3]
http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties



>
> The sweet little zip file from PuPHPet did not require any Ruby gems, msi
> installations, or master servers. Apparently that's yet a third way to run
> Puppet (perhaps similar to the deprecated Centod63 repo that didn't require
> anything beyond VirtualBox and vagrant).
>

FWIW, the MSI does come with a vendored ruby gems, so you can get past at
least Ruby gems and master servers. Unfortunately I haven't gotten you past
the need for the MSI though. :)


>
> So, why am I so confused, and could someone clear my head?
>
> --
> 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/7caa94e7-3f57-48e6-aa27-86c700484c9d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Dev

Re: [Puppet Users] Puppet for VM on Windows 7 - confused!

[Rob Reynolds]

On Mon, May 11, 2015 at 3:22 PM, Rob Reynolds  wrote:

> Hi Karen,
>
> On Sat, May 9, 2015 at 12:53 AM, Karen Ellrick 
> wrote:
>
>> Having already used Puppet a bit by way of a pre-packaged ZIP file
>> created by the PuPHPet online tool, I decided to try building a simpler VM
>> without the tool. I have VirtualBox and Vagrant already installed and
>> happy. What do I do next? I'm getting too many seemingly conflicting
>> instructions.
>>
>> This looked like a nice simple starting point:
>> https://github.com/miccheng/vagrant-lamp-centos63 It had three git
>> commands, after which I should have been able to run vagrant and have a
>> basic LAMP box.
>>
>> But the repo said it was deprecated and replaced by this:
>> https://github.com/sgphpug/Vagrant-LAMP-CentOS64 Okay, fine. But the
>> newer one has completely different instructions for installation - gem
>> install of puppet and librarian-puppet, some dependency stuff, etc. I was
>> pleasantly surprised to discover that I do have Ruby installed (I had no
>> idea - this is an ordinary Windows PC), so I opened a command prompt, cd'ed
>> to a logical spot (in case that would matter), and tried the first command: 
>> gem
>> install puppet. After about a half hour, with some complaints about not
>> being able to convert some things to UTF-8, it was still trying to do
>> who-knows-what. I looked in several likely spots for some hint that files
>> related to Puppet were being saved somewhere, but couldn't find anything. I
>> have no idea where it was installing anything.
>>
>> While it still ran in the background, I went back to Google and looked
>> for more info about installing Puppet on Windows. I found this page:
>> https://docs.puppetlabs.com/guides/install_puppet/install_windows.html#automated-installation
>> That describes a completely different sort of thing from Ruby gems, a more
>> typical Windows-ish installation. But the Pre-Install Tasks
>> 
>> page talked of a puppet master that must be on a *nix machine somewhere. It
>> said: "*Your puppet master(s) should be robust dedicated servers that
>> can handle the amount of agents they'll need to serve.*" Hmm, I don't
>> have one of those, but perhaps it will be all right. After all, I had no
>> trouble with the PuPHPet boxes.
>>
>
> I believe you are referring to this[1]. This is merely meant to state that
> Windows only has an agent available in a Master/Agent scenario.
>
> [1]
> http://docs.puppetlabs.com/guides/install_puppet/pre_install.html#choose-your-puppet-master-servers
>
>
>> So I halted the gem-based task (which still hadn't finished!), downloaded
>> the 64-bit msi file, and ran it. It said: "*This will install Puppet
>> (64-bit) 3.7.5 and configure the system to fetch configurations every half
>> hour. This version of Puppet (64-bit) will work with puppet masters running
>> Puppet 3.0 or higher.*" Hmph! Not only do I not have a puppet master or
>> a place to put one, but I don't want something running constantly on my PC
>> that tries to go to some server every half hour for who knows what. The
>> pre-install page also mentioned Standalone Puppet
>> 
>> that doesn't use a master, but it didn't give any hints about how to do
>> that.
>>
>
> The MSI is the primary means of installing Puppet on Windows. If you want
> a standalone Puppet, you just want to pass
> PUPPET_AGENT_STARTUP_MODE=Disabled to the MSI installer - see Automated
> Installation[2] and MSI Properties[3]. I see that you found the automated
> installation section already but perhaps we should draw out more that you
> can run the standalone puppet by setting that property to disabled in the
> actual installer.
>

I followed up with PUP-4554[1] to address possible confusion for the MSI
installer.

[1] https://tickets.puppetlabs.com/browse/PUP-4554


>
> [2]
> http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#automated-installation
> [3]
> http://docs.puppetlabs.com/guides/install_puppet/install_windows.html#msi-properties
>
>
>
>>
>> The sweet little zip file from PuPHPet did not require any Ruby gems, msi
>> installations, or master servers. Apparently that's yet a third way to run
>> Puppet (perhaps similar to the deprecated Centod63 repo that didn't require
>> anything beyond VirtualBox and vagrant).
>>
>
> FWIW, the MSI does come with a vendored ruby gems, so you can get past at
> least Ruby gems and master servers. Unfortunately I haven't gotten you past
> the need for the MSI though. :)
>
>
>>
>> So, why am I so confused, and could someone clear my head?
>>
>> --
>> 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.go

[Puppet Users] Puppet learning VM commands not working

[Gus Ko]

After successfully launching the CentOS VM and logging in, I got to the # 
prompt.  But when I type 'puppet resource service' or just the word puppet 
I get a command not found.  If I type whereis puppet I get puppet:


-- 
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/009f5708-a7d3-4ad0-9e47-97cd0942b056%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet on s390

[Rob Browning]

far4d  writes:

> You can get the package directly on packages.debian.org, e.g. 
> https://packages.debian.org/stretch/puppet or 
> https://packages.debian.org/stretch/facter. Additionally you can browse the 
> source of the package on http://sources.debian.net/search/facter/
>
> Debian offers a great visibility and transparency when it comes to 
> packages/patch-tracking/source-code.

And if you happen to be on a Debian system, you should be able to get an
unpacked source tree like this:

  apt-get source puppet

or 

  apt-get source puppet/stretch

if you want a particular version, assuming you have the relevant deb-src
entries in /etc/apt/sources.list.

--
Rob Browning

-- 
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/87wq0e4riw.fsf%40yaga.corp.puppetlabs.net.
For more options, visit https://groups.google.com/d/optout.

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

[Eric Sorenson]

The canonical way to do this is like this:

http://serverfault.com/questions/350230/how-can-i-have-puppet-only-set-password-when-creating-a-user

There's an open feature request 
here: https://tickets.puppetlabs.com/browse/PUP-1331

Feel free to add yourself as a watcher and add a comment describing your 
use case, those help bugs bubble up to the top.


On Friday, May 8, 2015 at 6:11:22 AM UTC-7, jcbollinger wrote:
>
>
>
> On Thursday, May 7, 2015 at 11:22:43 PM UTC-5, Alfredo De Luca wrote:
>>
>> 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.
>>
>
> Then as I said, create and use a custom fact to evaluate the user's 
> existence prior to the catalog request.  Also, consider configuring agents 
> to not apply cached catalogs.
>
> You could perhaps create a custom provider for the User type, too, to 
> perform the evaluation at the time of application.  That could work to 
> achieve the behavior you describe, but it will probably produce anomolies 
> in the form of reported updates to the affected user(s) that in fact change 
> nothing.
>
>
> 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/4de5b415-4c14-4eae-9c29-42cdd929e00d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Message from application: Permission denied - /etc/puppet/modules (Errno::EACCES)

[Joe Koenig]

On Monday, May 11, 2015 at 11:24:02 AM UTC-5, Gabriel Filion wrote:
>
> Hey there, 
>
> On 10/05/15 10:15 PM, j...@poweriep.com  wrote: 
> >   Message from application: Permission denied - /etc/puppet/modules 
> > (Errno::EACCES) 
>
> make sure to also verify permissions on /etc/puppet itself. If the 
> puppet user can't traverse the directory then the process won't be able 
> to open up the modules subdir. 
>
> to help out with permissions errors, what you can usually do is to 
> switch to that user and try listing directories/accessing files: 
>
> # su -s /bin/bash - puppet 
> > ls /etc/puppet/modules 
> > ls -ld /etc/puppet 
>

Great, thank you. That got me past that hangup. However, now, when I try to 
load it up in my browser, it just spins for a while and then tells me it 
timed out. Nothing is in my /var/log/messages or any of the Apache 
logs...so...not sure where to start on that...Anyone have any thoughts? 

-- 
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/853c53d0-d4b8-49c6-9315-f385f7d76033%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Environments change after upgrading to 3.7.5

[Jim Miller]

I do have one update to this.  The issue seems to be the modulepath, and 
what comes after the ':'
modulepath = $confdir/environments/dev/modules:
$confdir/environments/dev/site/modules

Puppet is not finding catalogs/modules after the ':'

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find class mywebsite::profiles::web::site_web_dev for 
. on node 



Again, 

Any suggestions would be _greatly_ appreciated.



Thanks,
Jim



On Friday, May 8, 2015 at 2:23:27 PM UTC-5, Jim Miller wrote:
>
> Hi all,
>
> Just upgraded from 3.4.something to 3.7.5 and it seems how we were doing 
> environments is depreciated.  I've followed a couple of docs* for how to do 
> this but seem to be missing something. Nodes can't seem to find modules.  
> For now it's not a big deal because it's just a warning but I'd like to 
> address the issue.
>
> *http://docs.puppetlabs.com/puppet/latest/reference/environments.html 
> (and linked docs)
>
> Here's the old config values in /etc/puppet/puppet.conf for environments:
>
> [main]
> 
> 
> modulepath = /etc/puppet/modules
> ...
> ...
> ...
> environment = production
> confdir = /etc/puppet
>
> [production]
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> [test]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> [development]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
>
> PROPOSED:
> [main]
> 
> 
> # modulepath = /etc/puppet/modules
> environmentpath = $confdir/environments
> default_manifest = /etc/puppet/manifests/site.pp
> ...
> ...
> ...
> # environment = production
> confdir = /etc/puppet
>
> # [production]
> # manifest = $confdir/manifests/site.pp
> # modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> # [test]
> #manifest = $confdir/manifests/non-prod_site.pp
> #modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> # [development]
> # manifest = $confdir/manifests/non-prod_site.pp
> # modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Environments.conf
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Environments.conf for production:
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/puppet/environments/production/site
>
> Environments.conf for testing:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> Environments.conf for dev:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Nodes .pp settings for each environment
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> $puppet_env = "production"
>
> $puppet_env = "test"
>
> $puppet_env = "development"
>
>
>
>

-- 
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/4620c1ca-2ffb-4021-aeaf-424f4aff5b83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Message from application: Permission denied - /etc/puppet/modules (Errno::EACCES)

[Gabriel Filion]

On 11/05/15 08:51 PM, Joe Koenig wrote:
> On Monday, May 11, 2015 at 11:24:02 AM UTC-5, Gabriel Filion wrote:
> On 10/05/15 10:15 PM, j...@poweriep.com  wrote:
> >   Message from application: Permission denied - /etc/puppet/modules
> > (Errno::EACCES)

> # su -s /bin/bash - puppet
> > ls /etc/puppet/modules
> > ls -ld /etc/puppet
> 
> Great, thank you. That got me past that hangup. However, now, when I try
> to load it up in my browser, it just spins for a while and then tells me
> it timed out. Nothing is in my /var/log/messages or any of the Apache
> logs...so...not sure where to start on that...Anyone have any thoughts? 

I'm not sure exactly what you're loading up in your browser.. If I
didn't put my finger on it below, tell us which URL you're loading up
(or better, exactly what you're trying to do to achieve a test)

If you're trying to access a puppet URI like
https://puppetmaster:8140/.../ then the master is probably waiting for
you to send a client TLS certificate to authenticate yourself. This is
how the puppet master ensures that only client that it knows of are
trying to get information out of it.

To test out that puppet is working right, I'd recommend rather to try
running a puppet agent run from the master server as a client to the
puppet master on the same server (e.g. configure /etc/puppet/puppet.conf
to specify master host, create a node in your manifests for the puppet
master host that does something simple like a notify{ 'some text': }
then run puppet agent -t). Since the puppet master will use the same TLS
cert as a client then as server, the cert will be already valid.

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

[Puppet Users] Re: Puppet Environments change after upgrading to 3.7.5

[Jim Miller]

Still wrestling with this.  Puppet is now seeing 'part' of the module paths 
but not all of them, one thing I had to change was using an absolute path 
and not '$confdir' and it's not using the correct site.pp file 
"non-prod_site.pp"

[ ~ ]# puppet config print --environment test |grep env
environment_timeout = 0
modulepath = /etc/puppet/environments/test/modules
:/etc/puppet/modules:/usr/share/puppet/modules
environment = test
environmentpath = /etc/puppet/environments
disable_per_environment_manifest = false

[ ~ ]# puppet config print --environment test |grep mani
manifest = /etc/puppet/manifests/site.pp
default_manifest = /etc/puppet/manifests/site.pp
genmanifest = false
manifestdir = /etc/puppet/manifests
disable_per_environment_manifest = false

[TEST] - environments.conf
[ ~ ]# cat /etc/puppet/environments/environments.conf
-
 # manifest = $confdir/manifests/non-prod_site.pp
 manifest = /etc/puppet/manifests/non-prod_site.pp
 # modulepath = 
$confdir/environments/test/modules:$confdir/environments/test/site/modules
 modulepath = 
/etc/puppet/environments/test/site/modules:/etc/puppet/environments/test/modules

Again, thank you for all advice.

--Jim


Hi all,
>
> Just upgraded from 3.4.something to 3.7.5 and it seems how we were doing 
> environments is depreciated.  I've followed a couple of docs* for how to do 
> this but seem to be missing something. Nodes can't seem to find modules.  
> For now it's not a big deal because it's just a warning but I'd like to 
> address the issue.
>
> *http://docs.puppetlabs.com/puppet/latest/reference/environments.html 
> (and linked docs)
>
> Here's the old config values in /etc/puppet/puppet.conf for environments:
>
> [main]
> 
> 
> modulepath = /etc/puppet/modules
> ...
> ...
> ...
> environment = production
> confdir = /etc/puppet
>
> [production]
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> [test]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> [development]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
>
> PROPOSED:
> [main]
> 
> 
> # modulepath = /etc/puppet/modules
> environmentpath = $confdir/environments
> default_manifest = /etc/puppet/manifests/site.pp
> ...
> ...
> ...
> # environment = production
> confdir = /etc/puppet
>
> # [production]
> # manifest = $confdir/manifests/site.pp
> # modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> # [test]
> #manifest = $confdir/manifests/non-prod_site.pp
> #modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> # [development]
> # manifest = $confdir/manifests/non-prod_site.pp
> # modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Environments.conf
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Environments.conf for production:
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/puppet/environments/production/site
>
> Environments.conf for testing:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> Environments.conf for dev:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Nodes .pp settings for each environment
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> $puppet_env = "production"
>
> $puppet_env = "test"
>
> $puppet_env = "development"
>
>
>
>

-- 
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/7548d542-a0c1-4978-8604-d89908b79a68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Environments change after upgrading to 3.7.5

[Jim Miller]

And finally when I add back to puppet.conf my environment, everything is 
found correctly:

 [test]
manifest = $confdir/manifests/non-prod_site.pp
modulepath = 
$confdir/environments/test/modules:$confdir/environments/test/site/modules
 


[ ~ ]# puppet config print --environment test |grep mani
Warning: Sections other than main, master, agent, user are deprecated in 
puppet.conf. Please use the directory environments feature to specify 
environments. (See 
http://docs.puppetlabs.com/puppet/latest/reference/environments.html)
   (at /usr/lib/ruby/site_ruby/1.8/puppet/settings/config_file.rb:82:in 
`unique_sections_in')
manifest = /etc/puppet/manifests/non-prod_site.pp
default_manifest = ./manifests
genmanifest = false
manifestdir = /etc/puppet/manifests
disable_per_environment_manifest = false

[ ~ ]# puppet config print --environment test |grep env
Warning: Sections other than main, master, agent, user are deprecated in 
puppet.conf. Please use the directory environments feature to specify 
environments. (See 
http://docs.puppetlabs.com/puppet/latest/reference/environments.html)
   (at /usr/lib/ruby/site_ruby/1.8/puppet/settings/config_file.rb:82:in 
`unique_sections_in')
environment_timeout = 0
modulepath = /etc/puppet/environments/test/modules:
/etc/puppet/environments/test/site/modules
environment = test
environmentpath = /etc/puppet/environments
disable_per_environment_manifest = false


On Friday, May 8, 2015 at 2:23:27 PM UTC-5, Jim Miller wrote:
>
> Hi all,
>
> Just upgraded from 3.4.something to 3.7.5 and it seems how we were doing 
> environments is depreciated.  I've followed a couple of docs* for how to do 
> this but seem to be missing something. Nodes can't seem to find modules.  
> For now it's not a big deal because it's just a warning but I'd like to 
> address the issue.
>
> *http://docs.puppetlabs.com/puppet/latest/reference/environments.html 
> (and linked docs)
>
> Here's the old config values in /etc/puppet/puppet.conf for environments:
>
> [main]
> 
> 
> modulepath = /etc/puppet/modules
> ...
> ...
> ...
> environment = production
> confdir = /etc/puppet
>
> [production]
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> [test]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> [development]
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
>
> PROPOSED:
> [main]
> 
> 
> # modulepath = /etc/puppet/modules
> environmentpath = $confdir/environments
> default_manifest = /etc/puppet/manifests/site.pp
> ...
> ...
> ...
> # environment = production
> confdir = /etc/puppet
>
> # [production]
> # manifest = $confdir/manifests/site.pp
> # modulepath = 
> $confdir/environments/production/modules:$confdir/environments/test/site/modules
>
> # [test]
> #manifest = $confdir/manifests/non-prod_site.pp
> #modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> # [development]
> # manifest = $confdir/manifests/non-prod_site.pp
> # modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Environments.conf
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Environments.conf for production:
> manifest = $confdir/manifests/site.pp
> modulepath = 
> $confdir/environments/production/modules:$confdir/puppet/environments/production/site
>
> Environments.conf for testing:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/test/modules:$confdir/environments/test/site/modules
>
> Environments.conf for dev:
> manifest = $confdir/manifests/non-prod_site.pp
> modulepath = 
> $confdir/environments/dev/modules:$confdir/environments/dev/site/modules
>
>
> Nodes .pp settings for each environment
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> $puppet_env = "production"
>
> $puppet_env = "test"
>
> $puppet_env = "development"
>
>
>
>

-- 
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/5efa4de7-d243-4ee9-96d5-4d31e8cff885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.