[Puppet Users] No Augeas 1.14.1 with Puppet Agent 7.27.0?

[Dietrich, Stefan]

Hello,

the release notes for Puppet Agent 7.27.0 mention an update of the bundled 
Augeas to 1.14.1
However the packages still include Augeas 1.13.0 [1]:

[~]# rpm -q puppet-agent
puppet-agent-7.27.0-1.el8.x86_64
[~]# /opt/puppetlabs/puppet/bin/augtool --version
augtool 1.13.0 
Copyright (C) 2007-2016 David Lutterkort

Is this just a mistake in the release notes?

Regards,
Stefan


[1] 
https://github.com/puppetlabs/puppet-runtime/blob/202310120/configs/projects/agent-runtime-7.x.rb#L15

-- 
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/698807775.7733126.1699605052968.JavaMail.zimbra%40desy.de.

Re: [Puppet Users] modules for NetworkManager

[Dietrich, Stefan]

Hello,

> With the advent of RHEL 9, Red Hat has removed the ability to define
> network config using the old flat file method.  It had been deprecated
> for a couple of major versions, but it's fully removed in RHEL 9.
> NetworkManager is the only option now.

according to the documentation, the old flat file method of ifcfg is still 
available.
However the default has been switched from ifcfg to NetworkManager format:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/considerations_in_adopting_rhel_9/index#ref_networkmanager-networking_assembly_networking

> I've looked on the Forge and I haven't found a popular, supported module
> for managing network config via NetworkManager.  Is there a consensus
> favorite that I've missed?  If not, what are people doing to manage
> the network on RHEL 9?

Same here, I have not yet really decided how to handle this.
Either continue to use the old ifcfg format, write a simple module for handling 
NM or use netplan.
For netplan there is a module available on Forge. This would also allow to have 
a unified configuration across Ubuntu, Debian and EL-family.

Regards,
Stefan

--

Stefan DietrichDeutsches Elektronen-Synchrotron (IT-Systems)
Ein Forschungszentrum der Helmholtz-Gemeinschaft
Notkestr. 85
phone:  +49-40-8998-4696   22607 Hamburg
e-mail: stefan.dietr...@desy.de  Germany


-- 
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/900872767.7516476.1658903012515.JavaMail.zimbra%40desy.de.

Re: [Puppet Users] Raspberry Pi Agents

[Dietrich, Stefan]

Hello Michael,

oh, another Puppet on Pi user :)

Any specific reason to drop the pl-build-tools for Debian 9 [1] ?
I have recently build Puppet Agent 1.10.10 for Debian 8/9 on armhf as 
well...and for RHEL 7 on ppc64 (big endian).
I still found it easier to build the pl-build-tools packages than removing all 
the references?

[1] 
https://github.com/stahnma/puppet-agent/commit/02faa1ab51f74ddb827ca1c3f5da5c3ab9c17a20
 (assuming, this is your repo?)

Regards,
Stefan

- Original Message -
> From: "Michael Stahnke" 
> To: puppet-users@googlegroups.com
> Sent: Monday, March 12, 2018 7:35:16 PM
> Subject: [Puppet Users] Raspberry Pi Agents

> In my spare time, I build out puppet-agents for Raspberry pis, because I
> like pain and ARM boards.
> 
> I finally got Debian Stretch Working for armhf.
> 
> Debian 9
> http://unsupported.s3.amazonaws.com/puppet-agent_5.
> 4.0.412.g8f7446e2-1stretch_armhf.deb
> 
> Debian 8
> http://unsupported.s3.amazonaws.com/puppet-agent_5.
> 4.0.412.ga221b36c-1jessie_armhf.deb
> 
> 
> As the URI implies, unsupported :) I don't always get a chance to update
> them. Feel free to point anybody at them though.
> 
> --
> 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/CAMto7LJz6-0J9--ZUCt1TtnUyuXs5%2BrBs-BD26Y6srKyokhFOg%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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/375713217.6064768.1520931010180.JavaMail.zimbra%40desy.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Multiple Upgrades required for PuppetDB 2.3.x -> 4.4.1 and 5.x requirement?

[Dietrich, Stefan]

Hello Wyat,

thanks for the link. The PostgreSQL version is not an issue, this has been 
upgraded to 9.6 recently.
The ticket assumes everything will be done online while the Puppet masters are 
running etc.

Actually, I would just do it with a maintenance window and take all puppet 
masters offline.
Than upgrade PuppetDB through the versions from above, update the termini on 
the masters and start everything again.
As the PDB HTTP API completely breaks between 2.x and 3.x, there will be an 
interruption anyway for users.

My main concern were the database migrations run by PuppetDB during the 
upgrade, which seems not to be an issue (despite the ancient version).

Regards,
Stefan

- Original Message -
> From: "Wyatt Alt" <wy...@puppet.com>
> To: puppet-users@googlegroups.com
> Cc: "Stefan Dietrich" <stefan.dietr...@desy.de>
> Sent: Wednesday, December 6, 2017 12:29:24 AM
> Subject: Re: [Puppet Users] Multiple Upgrades required for PuppetDB 2.3.x -> 
> 4.4.1 and 5.x requirement?

> On 12/05/2017 01:57 PM, Dietrich, Stefan wrote:
>> Hello,
>>
>> in order to finish our Puppet 4.x migration (and than Puppet 5.x, yay), 
>> PuppetDB
>> has to be upgraded as well.
>>
>> If I read the upgrade docs correctly, a direct upgrade from PuppetDB 2.3.x is
>> not supported [1].
>> So in order to do this, an upgrade to the latest version for each major 
>> release
>> is required:
>>
>> 2.3.x -> 3.2.4 -> 4.4.1 (-> 5.1.3 once we go to Puppet 5)
>>
>> Is this correct?
> It's a bit more complicated than that, unfortunately. The docs aren't
> completely correct on this, and the best source of info is probably this
> ticket: https://tickets.puppetlabs.com/browse/DOCUMENT-719
> 
> In the comments I've outlined the upgrade path, which I just tested. The
> key thing to watch out for is to make sure you upgrade puppetdb before
> the puppetdb terminus, and ensure everything is working before moving
> the terminus and puppet server to version 5. Note also that there's a
> postgres bump, so it may make sense to get that out of the way first.
>>
>> Additionally, the release notes of PuppetDB 5 mention a hard dependency on
>> Puppet Agent 5.x [2]
>> So for PuppetDB 5 _all_ agents have to be at 5.x first?
>> Or is it sufficient to have Puppet Agent 5.x on Puppetserver/PuppetDB hosts?
> I had no issues running a 4.x agent against a 5.x puppetserver/puppetdb.
> The puppetdb upgrade will pull in a 5.x agent on the puppetdb host itself.
> 
> Wyatt

-- 
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/909694123.4836530.1512545125711.JavaMail.zimbra%40desy.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Multiple Upgrades required for PuppetDB 2.3.x -> 4.4.1 and 5.x requirement?

[Dietrich, Stefan]

Hello,

in order to finish our Puppet 4.x migration (and than Puppet 5.x, yay), 
PuppetDB has to be upgraded as well.

If I read the upgrade docs correctly, a direct upgrade from PuppetDB 2.3.x is 
not supported [1].
So in order to do this, an upgrade to the latest version for each major release 
is required:

2.3.x -> 3.2.4 -> 4.4.1 (-> 5.1.3 once we go to Puppet 5)

Is this correct?

Additionally, the release notes of PuppetDB 5 mention a hard dependency on 
Puppet Agent 5.x [2]
So for PuppetDB 5 _all_ agents have to be at 5.x first?
Or is it sufficient to have Puppet Agent 5.x on Puppetserver/PuppetDB hosts?
As we use Puppet also to manage desktop installations, upgrading all agent 
packages takes some time.

Regards,
Stefan

[1] https://puppet.com/docs/puppetdb/5.1/versioning_policy.html#upgrades
[2] https://puppet.com/docs/puppetdb/5.1/release_notes.html#section-3

--

Stefan DietrichDeutsches Elektronen-Synchrotron (IT-Systems)
Ein Forschungszentrum der Helmholtz-Gemeinschaft
Notkestr. 85
   22607 Hamburg
e-mail: stefan.dietr...@desy.de  Germany


-- 
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/1861687451.4807472.1512511050220.JavaMail.zimbra%40desy.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet Server dying with high number of JRuby instances

[Dietrich, Stefan]

Hello,

we tried to today to migrate our Puppet Masters from Apache/Passenger to Puppet 
Server 1.1.1.
However, Puppet Server just dies with error messages as soon as we increase the 
number of JRuby instances to 24 and a JVM heapsize of  16GB.

During startup of Puppet Server, it starts to spawn the JRuby instances one 
after another and around ~8 instances an exception is logged:
2015-08-25 10:25:05,676 INFO  [puppet-server] Puppet Puppet settings 
initialized; run mode: master
2015-08-25 10:25:06,254 INFO  [p.s.j.jruby-puppet-agents] Finished creating 
JRubyPuppet instance 7 of 32
2015-08-25 10:25:08,567 ERROR [p.t.internal] shutdown-on-error triggered 
because of exception!
java.lang.IllegalStateException: There was a problem adding a JRubyPuppet 
instance to the pool.
Caused by: org.jruby.embed.EvalFailedException: (LoadError) load error: 
jopenssl/load -- java.lang.NoClassDefFoundError: 
org/jruby/ext/openssl/NetscapeSPKI
at 
org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:132) 
~[puppet-server-release.jar:na]
at 
org.jruby.embed.ScriptingContainer.runUnit(ScriptingContainer.java:1341) 
~[puppet-server-release.jar:na]

The full log file is available in this Gist [1].
The log file is from the initial setup with max-active-instances set to 32 and 
a JVM heap size of 48gb.
We had a working setup with 16GB Heap and 16 instances. Sometimes 24 worked as 
well, but not always.
However, 16 instances will be too small to handle all the Puppet agents.
Increasing the timeout in /etc/sysconfig/puppetserver did not help either.

We use rather beefy HW for our 3x Puppet Masters (2x Dell R715, 1x R815), for 
Apache/Passenger this scaled nicely.

The OS on the Puppet Masters is Scientific Linux 6.6 (RHEL 6.6 clone) and 
OpenJDK 8 is used.
We tried the Oracle JRE as well, but this did not change anything.
HTTPS is terminated at our F5 Loadbalancer, which forwards the traffic 
unencrypted to Puppet Server.

Any help would be appreciated!

[1] https://gist.github.com/stdietrich/5a5b8f9b1dc2445c3ec7

Regards,
Stefan

--

Stefan DietrichDeutsches Elektronen-Synchrotron (IT-Systems)
Ein Forschungszentrum der Helmholtz-Gemeinschaft
Notkestr. 85
phone:  +49-40-8998-4696   22607 Hamburg
e-mail: stefan.dietr...@desy.de  Germany


-- 
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/835874101.2643357.1440500729152.JavaMail.zimbra%40desy.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 3.8.2 available

[Dietrich, Stefan]

Hi,

there seems to be no package for Debian 8 (Jessie) on apt.puppetlabs.com.
Neither in the jessie dist tree nor testing, where Puppet 3.8.1 for jessie 
could be found previously.

Is this a mistake or will they be added later?

Regards,
Stefan

- Original Message -
 From: Kylo Ginsberg k...@puppetlabs.com
 To: puppet-users@googlegroups.com
 Sent: Friday, August 7, 2015 2:52:45 AM
 Subject: [Puppet Users] Puppet 3.8.2 available

 Puppet 3.8.2 is a bug fix release (with future parser changes) in the Puppet
 3.8 series.
 
 The main focus of this release is to make sure the 3.8 future parser is
 forward-compatible with the Puppet language as of Puppet 4.2. It also add
 some new reserved keywords (if using the future parser) and it fixes
 several bugs.
 
 Check out the release notes for more information:
 
 https://docs.puppetlabs.com/puppet/3.8/reference/release_notes.html#puppet-382
 
 You can see the full list of changes on the release's JIRA page:
 
 https://tickets.puppetlabs.com/jira/secure/ReleaseNote.jspa?projectId=10102version=13415
 
 
 If you're installing Puppet for the first time, follow the Installation
 Guide: https://docs.puppetlabs.com/guides/install_puppet/pre_install.html
 
 --
 Kylo Ginsberg | k...@puppetlabs.com | irc: kylo | twitter: @kylog
 
 *PuppetConf 2015 http://2015.puppetconf.com/ is coming to Portland,
 Oregon! Join us October 5-9.*
 *Register now to take advantage of the Early Bird discount
 https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyBird
 *
 *—**save $249!*
 
 --
 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/CALsUZFHf%3D3q4%3DF3BzrKHo-q6Phu4p%2BABMyNyYuaevRZCjf444Q%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...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1215246560.1310163.1439133750209.JavaMail.zimbra%40desy.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet under passenger constantly crashing

[Dietrich, Stefan]

+1 here.
We see this problem kind of problem on Puppet 3.4.3 and Scientific Linux
6.5.

Only the files causing the segfault are different from your case:
/usr/lib/ruby/site_ruby/1.8/puppet/util/autoload.rb:88: [BUG]
Segmentation fault
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

/usr/lib/ruby/site_ruby/1.8/puppet/file_system/file.rb:152: [BUG]
Segmentation fault
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

/usr/lib/ruby/site_ruby/1.8/puppet/file_system/file.rb:152: [BUG]
rb_gc_mark(): unknown data type 0x38(0xf90be90) non object
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

I am able to reproduce this issue with our manifests on a fresh
installation from scratch.

So far, only Ubuntu agents trigger this segfault on the master.
I found some workarounds:
- Backporting the patch from PUP-1592
- Upgrading to Puppet 3.6.x
- Removing a specific ordering from the manifests

I was even able to reproduce this on Puppet 3.6.2, if I _remove_ the
patch from PUP-1592.

So, I think this is an ruby 1.8.7 issue and the mentioned patch only
makes it harder to run into this issue.

Regards,
Stefan 

On Do, 2014-06-12 at 08:47 -0500, Trey Dockendorf wrote:
 Sort of.  The normal Puppet+Passenger configuration still crashes, but
 for some odd reason if I add the following to the Puppet config.ru
 (after the --confdir and --vardir lines) the crashes stop...
 
 ARGV  --debug
 ARGV  --trace
 ARGV  --profile
 ARGV  --logdest  /var/log/puppet/puppetmaster.log
 
 I made those changes to try and debug the problem with help on IRC
 some time ago, and while the actual problem couldn't be found, those
 options kept Passenger from crashing when running Puppet.  The full
 config is at the end [1].
 
 I have an almost identical Puppetmaster setup for a different
 infrastructure, using same versions and same Puppet modules
 (theforeman), that does not exhibit this behavior.  My hunch is that
 this problematic Puppetmaster is suffering from configuration drift.
 It was setup by hand a long time ago with various Rubygems installed
 manually that are likely conflicting.  The system is now fully managed
 but there are still some Rubygems installed that are not managed and
 I've not taken the time to clean it up, but rather will eventually
 rebuild this VM.
 
 - Trey
 
 [1]:
 ### Next part of the file is managed by a different template ###
 ## Module:   'puppet'
 # a config.ru, for use with every rack-compatible webserver.
 # SSL needs to be handled outside this, though.
 
 # if puppet is not in your RUBYLIB:
 # $LOAD_PATH.unshift('/opt/puppet/lib')
 
 $0 = master
 
 # if you want debugging:
 # ARGV  --debug
 
 ARGV  --rack
 
 # Rack applications typically don't start as root.  Set --confdir and --vardir
 # to prevent reading configuration from ~puppet/.puppet/puppet.conf and 
 writing
 # to ~puppet/.puppet
 ARGV  --confdir  /etc/puppet
 ARGV  --vardir   /var/lib/puppet
 ARGV  --debug
 ARGV  --trace
 ARGV  --profile
 ARGV  --logdest  /var/log/puppet/puppetmaster.log
 
 # NOTE: it's unfortunate that we have to use the CommandLine class
 #  here to launch the app, but it contains some initialization logic
 #  (such as triggering the parsing of the config file) that is very
 #  important.  We should do something less nasty here when we've
 #  gotten our API and settings initialization logic cleaned up.
 #
 # Also note that the $0 = master line up near the top here is
 #  the magic that allows the CommandLine class to know that it's
 #  supposed to be running master.
 #
 # --cprice 2012-05-22
 
 require 'puppet/util/command_line'
 # we're usually running inside a Rack::Builder.new {} block,
 # therefore we need to call run *here*.
 run Puppet::Util::CommandLine.new.execute
 
 On Tue, Jun 10, 2014 at 6:59 AM, paul.gomersbach p.gomersb...@gmail.com 
 wrote:
  Hi Treydock,
 
  Did you ever resolve this problem?
 
  Thanks!
 
  Op dinsdag 25 maart 2014 23:24:17 UTC+1 schreef treydock:
 
  As an update, I tried running 'puppet master --no-daemonize --debug' and
  am seeing a segmentation fault running outside of passenger/apache...
 
  /usr/lib/ruby/site_ruby/1.8/puppet/parser/scope.rb:555: [BUG] Segmentation
  fault
  ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
 
  another run
 
  /usr/lib/ruby/1.8/pathname.rb:287: [BUG] rb_gc_mark(): unknown data type
  0x10(0x935ce90) non object
  ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
 
  This only seems occur most frequently when I run puppet agent --test
  from the puppet master server.  Remote clients do not seem to crash puppet
  master as frequently.
 
  On Tuesday, March 25, 2014 4:30:27 PM UTC-5, treydock wrote:
 
  I recently moved from manually configured Puppetmaster under passenger to
  fully managed using theforeman/puppet module.  Now I am experiencing
  constant crashes (every few minutes) of the passenger process that runs 
  the
  puppetmaster.
 
  Host is CentOS 6.5 running Puppet 3.4.3.
 
  This is the entry I see in