Re: [Puppet Users] Puppet for RHEL 9 - when will it be available?

[Nacho Barrientos]

Hi,

Yasmin Rajabi  writes:

> Hello!
>
> We are currently working on the rhel 9 beta agent, hoping to have that in
> the nightlies soon. Centos stream support is tentative for early next
> year.

For info we've already got local builds of 7.x for CentOS Stream
9. Early stages, though. [0] might be of your interest.

[0] https://github.com/puppetlabs/vanagon/pull/722

--
 bye
 Nacho
 http://cern.ch/nacho

-- 
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/87o85s255r.fsf%40cern.ch.

Re: [Puppet Users] Removal of CentOS 8 Support

[Nacho Barrientos]

Aidan Nathanson  writes:

> Hi Nacho,

Hi Aidan,

>
> Thanks for reaching out! We are looking into adding support for CentOS 
> Stream 8 on the agent side only. Let us know if you have additional 
> questions!

Thanks for your reply. For us it'd be particularity problematic not
having support on the server side, may I ask why are you only looking
into adding support on the agent side? The fact that CentOS 8 goes away
but the natural successor is not considered is somewhat surprising.

Also, what are your feelings about CentOS Stream 9?

Thanks a bunch.

-- 
 bye
 Nacho
 http://cern.ch/nacho

-- 
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/874k9tuhg2.fsf%40mom.cern.ch.

Re: [Puppet Users] Removal of CentOS 8 Support

[Nacho Barrientos]

Hi,

Peter Meier  writes:

> Hi All,
>
>> This is an announcement that we’ll be removing support for CentOS 8
>> in February 2022 because CentOS 8 is EOLed from the vendor in
>> December 2021. For a list of other supported operating systems for
>> your primary server, see the supported operating systems 
>> docs.
>
> Are you going to add CentOS Stream 8, Alma Linux 8 and Rocky Linux 8 ?

It's good to see that there will be nightly builds for Rocky and Alma.

Regarding CentOS Stream 8, we'd be also interested in learning what your
feelings are about compatibility for the server and the agent.

Thanks.

--
 bye
 Nacho
 http://cern.ch/nacho

-- 
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/871r55kxam.fsf%40cern.ch.

[Puppet Users] jRuby9k in production, any feedback?

[Nacho Barrientos]

Hi all,

We're currently preparing the upgrade to Puppet5 of a big installation 
which is currently using Puppet 4.9/Hiera 5/Puppetserver 2.7/Java7 
master-side.


To compensate for the performance hit in terms of catalog compilation 
time that Puppet5/Puppetserver5/Java8 is bringing to us (20-30% slower), 
we're pondering moving at the same time from jRuby 1.7.27 to jRuby9k 
(9.1.16.0) which according to our preliminary measurements is faster.


When putting the numbers on the table, we can see that the time gained 
from upgrading jRuby is more or less the same we're losing from "the 
other side" so it sounds like a low-effort thing to do to maintain the 
API response time stable. In principle, of course :)


Does anybody have any real world experience with jRuby9k [0] in 
production (in Puppet context) and the willingness to share it with us? 
Not just about performance but we're also interested in knowing about 
common pitfalls and things to take into account.


[0] 
https://puppet.com/docs/puppetserver/5.0/configuration.html#configuring-the-jruby-version


Thanks.

--
 bye
 Nacho
 http://cern.ch/nacho

--
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/3c0dc6b1-b234-7944-b358-28e3c4eb9d2a%40cern.ch.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Notify: log only the message itself at 'notice' level

[Nacho Barrientos]

Hi all,

When using the Notify resource type, is there any way to hide the log 
message that is produced by the definition itself and only keep the 
actual message string on the output generated by Puppet agent?


In this example:

Notice: hello 



Notice: /Stage[main]/Foo::Bar/Notify[baz]/message: defined 'message' as 
'hello'


The idea would be to tell Puppet somehow to only print the following:

Notice: hello

We've tried passing audit = [] as an attribute to the resource 
declaration but it didn't produce any effect log-wise. Also we changed 
the loglevel to 'debug' at resource level and it hid both.


We're (still) using Puppet 3.4.3.

Any ideas? :)

--
 bye
 Nacho

--
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/547C60B7.9070104%40cern.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Notify: log only the message itself at 'notice' level

[Nacho Barrientos]

On 01/12/14 16:25, Spencer Krum wrote:

Maybe you could use the notice() or warn() functions?



Those would log server-side, wouldn't they? I want to see it on the 
client console and on the Puppet report :)


--
 bye
 Nacho
 http://cern.ch/nacho

--
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/547D7119.8090802%40cern.ch.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Restrict file creation in the masters

[Nacho Barrientos Arias]

Hi,

On Wed, Jan 16, 2013 at 10:05 PM, jcbollinger john.bollin...@stjude.orgwrote:


 Mostly.  The master normally runs as an unprivileged user, so file and
 directory access controls apply to it.  If you run SELinux in enforcing
 mode then SELinux policy applies no matter what user the master runs as.
 There are a couple of places to which the master needs to write (its log,
 its cache, ...), but appropriate access controls will prevent it from
 writing elsewhere (its config file, module directories, unrelated system
 directories, etc.).


Thanks for replying.

That's what we're kinda trying to do now but it's not just a matter of
limiting what the Puppet master can write I'm afraid. It's also important
what it can read.

We're using the Hiera GPG backend and the secret part of the key is stored
in the masters and must to be readable by the 'puppet' user so secrets can
be decrypted at catalog compilation time. Everyone could use a custom
function to read the key and put it in a place where it can be fetched
afterwards.

Dunno, looks like my concern is going beyond of my original question a bit.
I'm probably implicitly asking now if there's any way to totally disable
remote code execution.

About fine-grained ACLs on the writable directories, I still can think of
some cases where users might end up doing malicious things, for instance
erasing all the log files or even the facts cache living in
/var/lib/puppet/yaml/facts.

Nacho

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Restrict file creation in the masters

[Nacho Barrientos]

Hi,

Maybe I'm missing something obvious because my question sounds very naive 
to me. Anyway, here I go:

Is it possible to prevent module developers from writing files in the 
master via custom Puppet functions[0]? 

At least in my environment[1] I can come up with several malicious things 
that users could end up doing. For instance, the modules directory that the 
master uses to generate the catalogs is writable by the same user that runs 
the Puppet daemon so every module developer could overwrite someone else's 
work.

I'm running Puppet 2.7.18.

[0] http://docs.puppetlabs.com/guides/custom_functions.html
[1] Access to Puppet masters is restricted to a few but we have many 
unrelated people using them and writing their own manifests to configure 
their services.

Thanks!
N

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/-4AitY-Ntq8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.