Re: [Puppet Users] puppetlabs-lvm & inconsistency of pv devices
In regard to: [Puppet Users] puppetlabs-lvm & inconsistency of pv devices,...: As we're migrating from RHEL 7 over to RHEL 9, RedHat is stating that pv device order should not be expected to be consistent. LVM also no longer defaults to importing existing PVs that have been preserved from a previous install: https://access.redhat.com/solutions/6717161 So how are users specifying to create the pv on RedHat systems now? Really don't want to try and deal with UUID's, and would rather not have admins create the PV & volume group manually either. I've struggled with that question too, so I look forward to hearing what other sites are doing. I've also never been sure what the best practice is for where these type of host-specific resources should be in the overall class hierarchy. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/992c0f23-10d8-e386-fb31-c67b9477010d%40ndsu.edu.
[Puppet Users] puppet idiom to select particular module stream?
All-
RHEL 8 and RHEL 9 and their rebuilds and related distros inherited DNF
modularity from Fedora, as a kind of replacement for Software Collections
Library alternate package version.
I've been unable to find the correct puppet idiom to do the following:
1) ensure a particular module stream is enabled *before* installing
packages from that stream.
2) install the package(s).
I thought that this would work:
package { 'enable-nodejs18':
ensure => 'nodejs:18',
name=> 'nodejs',
provider=> 'dnfmodule',
enable_only => true,
}
package { 'nodejs':
ensure => installed,
require => Package['enable-nodejs18'],
}
But that doesn't work. I still get the base OS version of 'nodejs'
installed. The correct module stream isn't enabled (first). If we
manually (outside puppet) switch the client to the correct stream,
then the 2nd package resource does install the version we want.
Obviously, we want to control the one-time module stream selection in
puppet too.
Can anyone tell me what the correct idiom is to do what I'm trying to
accomplish?
Thanks!
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure /
Division of Information Technology/701-231-1076 (Voice)
North Dakota State University, Fargo, ND 58105-5164
--
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/e5efed0-5a8-de7a-ecc8-abe1835ec4a%40ndsu.edu.
Re: [Puppet Users] Can I store RPM's on the Puppet Server to install on agents ?
In regard to: Re: [Puppet Users] Can I store RPM's on the Puppet Server to...: I would not choose an Exec resource type as the method to install RPM packages from vendors, be it RPMs on a local filesystem or served by HTTPS-based repo. You can and have the ability to keep the OS Packages (RPM/DEB) on the PE host machine like you can store any files on the PE host. But I would not check-in the RPMs to be stored in the version control system repository where the Puppet code and Hiera lives. Instead the general wisdom is that Linux OS Packages (RPM or DEB) that are not in a proper repository, should then be placed into a proper package repository. This way it can be referred to as a Package resource type like any other normal installable package, in this case an RPM via YUM. +1 to everything James said. Creating a local repo for RPMs is very easy. If you have a Linux system that's running a web server, you're most of the way there already. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/78981746-8974-b2ea-51ee-3944b8d7e0a8%40ndsu.edu.
[Puppet Users] modules for NetworkManager
Hi All- How are people using puppet to manage their interfaces and routes with NetWorkManager? 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. 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? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/4b35fbd-a56a-e5ef-ed0-5a8de7aecc8%40ndsu.edu.
Re: [Puppet Users] RHEL 9 agent support?
In regard to: Re: [Puppet Users] RHEL 9 agent support?, Josh Cooper said...: Puppet 6 is released quarterly and support for RHEL9 will go out in the next 6.x release. In the meantime, you can try nightly builds from https://nightlies.puppet.com/yum/puppet6-nightly/el/9/x86_64 Thanks Josh! Much appreciated. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/835ec4a-548f-783-937f-4c3b4520eb7f%40ndsu.edu.
[Puppet Users] RHEL 9 agent support?
RHEL 9 has been out for a few weeks. I see OpenSource puppet agent 7 and puppet bolt packages for RHEL 9, but no OpenSource puppet agent 6 releases. Are there plans to package puppet agent 6 for RHEL 9? Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/924b35f-bda5-6ae5-efe-d05a8de7aec%40ndsu.edu.
Re: [Puppet Users] upgrading opensource from 5.5 to 6.x
In regard to: Re: [Puppet Users] upgrading opensource from 5.5 to 6.x,...: Hi Tim, Major difference between Puppet 5 and 6: - some types have been moved to separate git module repositories - puppet cert command has been moved to puppet server ca command (see also https://www.example42.com/2018/10/08/puppet6-ca-upgrading/ <https://www.example42.com/2018/10/08/puppet6-ca-upgrading/>) The Puppet doc has more information: https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-deprecations-x.0.0 <https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-deprecations-x.0.0> So this is far later than it should be, but I wanted to follow-up and thank you for your reply. After having been through the 3.8.x to 5.x upgrade, I thought I had to be missing something for the 5.x to 6.x upgrade. Turns out I wasn't, 5.x to 6.x was just a lot easier than 3.8.x to 5.x. Martin's info confirmed that I had found everything I needed. The Example42 blog post Martin linked was also very helpful in working around the CA changes. The upgrade went smoothly and we've been using 6.x for a few weeks now. Thanks again! Tim On 19. Mar 2020, at 00:09, Tim Mooney wrote: All- When I upgraded our opensource puppet environment from 3.8 to 5.x, there was a lot of good documentation that highlighted changes to file locations, deprecations, settings that needed to change, etc. There were many things to change or update to prepare for the upgrade, but nearly everything was spelled out pretty clearly. I'm contemplating updating our environment from 5.5 to the most recent 6.x release, and I'm not finding any upgrade documentation of a similar amount of detail. I understand that there are fewer changes and deprecations between 5.5 and 6.x than there were between 3.8 and 5.x, but there has to be more to it than just update the packages without making any changes to your config files, etc. For others that have been through the same upgrade recently, what docs did you follow, and were there any gotchas that weren't covered? Thanks! Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.GSO.2.21.2003181743460.7559%40dogbert.cc.ndsu.NoDak.edu. -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.GSO.2.22.394.2005131842070.4392%40dogbert.cc.ndsu.NoDak.edu.
[Puppet Users] upgrading opensource from 5.5 to 6.x
All- When I upgraded our opensource puppet environment from 3.8 to 5.x, there was a lot of good documentation that highlighted changes to file locations, deprecations, settings that needed to change, etc. There were many things to change or update to prepare for the upgrade, but nearly everything was spelled out pretty clearly. I'm contemplating updating our environment from 5.5 to the most recent 6.x release, and I'm not finding any upgrade documentation of a similar amount of detail. I understand that there are fewer changes and deprecations between 5.5 and 6.x than there were between 3.8 and 5.x, but there has to be more to it than just update the packages without making any changes to your config files, etc. For others that have been through the same upgrade recently, what docs did you follow, and were there any gotchas that weren't covered? Thanks! Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.GSO.2.21.2003181743460.7559%40dogbert.cc.ndsu.NoDak.edu.
Re: [Puppet Users] Re: managing users and grants with recent puppetlabs-mysql
In regard to: [Puppet Users] Re: managing users and grants with recent...: Despite it being labelled as private you should still be able to add additional user's in the same way, creating an additional mysql::grant for each assignment. Sorry I don't have more information. Thanks David. We haven't yet made any changes to our code that has been using mysql_database, mysql_user, and mysql_grant. Those all continue to work, so you're correct that we can still use them. We'll keep using them until suitable replacements appear, but that's more or less what I was trying to discover: what are the replacements for these resources that have transitioned to "private"? It just seems strange to me to mark something as private without first having an established replacement. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.20.1901231226530.2990%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] managing users and grants with recent puppetlabs-mysql
All- I'm using the open source Puppet 5.x platform, with puppetserver 5.3.6 and puppet-agent 5.5.8 on mostly RHEL 6 and 7 (and soon 8, I suppose). We're long-time users of puppetlabs-mysql, right now we're on the current latest (7.0.0). When we started with puppetlabs-mysql, we wrote our database management puppet classes to use puppetlabs-mysql's mysql_database, mysql_user and mysql_grant resources directly. Most of our code still does this. Recent versions of puppetlabs-mysql have marked those resources as @api private, though. There is now a mysql::db define that is part of the public API and kind of combines all three, but AFAICT it only allows managing one user for the defined database. Additional users or complicated grants seem to be beyond that define. I guess I'm confused about what the new recommended way is to manage users and grants with puppetlabs-mysql? I've searched these forums and the web, and other than an outdated and now incorrect hit on StackOverflow, I'm not finding information on what should replace *public* use of mysql_user and mysql_grant. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.20.1901221818570.1183%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] class parameters that depend on other parameters
In regard to: Re: [Puppet Users] class parameters that depend on other...: On Tuesday, June 12, 2018 at 3:14:45 PM UTC-5, Tim.Mooney wrote: Let's say you had *many* parameters that you wanted to set defaults for (but allow overrides on an individual basis) based on a single parameter. The simplest and most straightforward alternative I can think of is simply to reposition your classes. What I mean by that is instead of using a params class to set Puppet-level default parameter values, make the target class a wrapper that handles parameter defaults and adjustments, and passes them off to a private, internal class. Truly, the internal class part is optional, but it provides for a separation of concerns, and maps more cleanly onto your example. Thanks much John for your excellent reply! Between your suggestions and Henrik's, I have a much clearer picture of how I can modernize and hopefully simplify several of our home-grown modules and classes. The time you took to read and reply is greatly appreciated. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.20.1806131439180.10996%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] class parameters that depend on other parameters
In regard to: Re: [Puppet Users] class parameters that depend on other...: Hope one of those examples gives you some inspiration. They do. Thank you very much for taking the time to read and consider the wall of text and code I posted, and then come back with some insightful suggestions. The options you considered and then rejected, and the reasons why were also very useful to hear. Between you and John, I have lots of great suggestions that I now need to consider. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.20.1806131431230.10996%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] class parameters that depend on other parameters
In regard to: Re: [Puppet Users] class parameters that depend on other...:
On 2018-06-12 00:55, Tim Mooney wrote:
[snip some of my original context]
Here's an example:
modules/sandbox/manifests/init.pp:
#
# This module exists only to serve as a sandbox where we can experiment with
# puppet code.
#
class sandbox(
Enum['typeA', 'typeB', 'combined'] $server_type = 'combined',
String $service_name =
$::sandbox::params::service_name,
) inherits ::sandbox::params {
notice("sandbox initialized.\n")
notice("\$server_type = ${server_type}\n")
notice("\$service_name = ${service_name}\n")
}
modules/sandbox/manifests/params.pp:
#
# a 'sandbox' class for the params pattern.
#
class sandbox::params {
$_server_type_actual = $::sandbox::server_type
case $_server_type_actual {
'combined': {
$service_name = 'sandbox-typeA+typeB'
}
'typeA': {
$service_name = 'sandbox-typeA'
}
'typeB': {
$service_name = 'sandbox-typeB'
}
default: {
fail("\n\nsandbox::server_type must be one of: combined, typeA,
typeB\n")
}
}
}
Hopefully the *intent* is relatively clear: provide an intelligent default
value for $service_name based on what the value is for $server_type, but
allow our "intelligent default" value to be overridden. If
'sandbox::server_type' is set to 'typeB' in our hiera hierarchy, I want
the *default* value for 'sandbox::service_name' to become 'sandbox-typeB'.
If the person configuring the machine needs to override that too, they
should be able to, but setting just the first setting should provide
suitable defaults for the others.
[snip some of my original context]
For starters you do not really need a params.pp or inheritance. Simply
configure all parameters in hiera.
Then, you can produce the default value by calling a function. For example
like this:
function mymodule::default_from_a($x) {
if $x == 'type-A' {
'sandbox-typeA'
}
}
class example($a, $b = mymodule::default_from_a($a)) {
notice $a
notice $b
}
class {example: a => 'type-A' }
Thanks for your response Henrik! The function use is an interesting
approach that I would not have considered. It works well in the simple
example I presented and accomplishes what I was trying to do.
I'm not sure how I would scale this to something that's "real world" in
size, though.
Let's say you had *many* parameters that you wanted to set defaults for
(but allow overrides on an individual basis) based on a single parameter.
In my environment, the best example where we've used this is to support
the alternate versions of particular packages that are available for
RHEL (and respins) using Software Collections Library (SCL).
For example, on RHEL 6, the standard packages provide php 5.3.3 (plus
some backports and vendor "special sauce").
However, there are alternate versions available from SCL:
php54-php
php55-php
rh-php56-php
rh-php70-php
So to support various web application requirements, we have modules
that do stuff like (sorry for the lengthy code):
if $facts['os']['family'] == 'RedHat' {
if $facts['os']['release']['major'] == '5' {
#
# There's no easy httpd 2.4 option for RHEL 5, so barf
#
fail("\n\nRHEL 5 is not supported.\n\n")
} elsif $facts['os']['release']['major'] == '6' {
# PHP-related settings.
$php_variant = hiera('scl::php', 'php54')
if $php_variant == 'php54' or $php_variant == 'php55' {
# don't need to include the fpm package, as the phpfpm class gets it
$php_extra_packages = hiera('scl::php::extra_packages',
[
"${php_variant}-runtime",
$php_variant,
"${php_variant}-php-cli",
"${php_variant}-php-ldap",
"${php_variant}-php-mbstring",
"${php_variant}-php-pdo",
])
$php_fpm_package_name = "${php_variant}-php-fpm"
$php_fpm_service_name = $php_fpm_package_name
$php_fpm_pool_dir = "/opt/rh/${php_variant}/root/etc/php-fpm.d"
$php_fpm_pid_file =
"/opt/rh/${php_variant}/root/var/run/php-fpm/php-fpm.pid"
$php_config_dir = "/opt/rh/${php_variant}/root/etc"
} elsif $php_variant != 'UNDEF' {
#
# for version 5.6.x and later, the name may include rh- at the start
# and many of the paths have changed.
#
# don't need to include the fpm package, as the phpfpm class gets it
$php_extra_packages = hiera('scl::php::extra_packages',
[Puppet Users] class parameters that depend on other parameters
Hi All!
We've been long-time users of puppet (opensource). A lot of our
home-grown modules were written to use direct hiera() calls (and before
that extlookup()) for loading config. Because of prior limitations
with class parameters, we also mostly avoided parameterized classes and
class inheritance.
Since I converted my site from puppet 3.8.7 to puppetserver 5.x and
puppet-agent 5.3.x, and converted us from hiera 3.x to hiera 5.x, a lot
of the "old ways" we were doing things can and should be modernized. For
example, I'm embarking on a project to convert all deprecated direct
hiera() calls to use lookup() instead, but before I do that I can also
greatly reduce the number of direct lookup() calls by making better use
of automatic parameter loading for classes, where appropriate.
One area where I've never found a good solution is class parameters that
depend on the value of other class parameters, especially when we want to
provide reasonable defaults for both but we also want to allow overriding
one or both of the parameters.
Here's an example:
modules/sandbox/manifests/init.pp:
#
# This module exists only to serve as a sandbox where we can experiment with
# puppet code.
#
class sandbox(
Enum['typeA', 'typeB', 'combined'] $server_type = 'combined',
String $service_name =
$::sandbox::params::service_name,
) inherits ::sandbox::params {
notice("sandbox initialized.\n")
notice("\$server_type = ${server_type}\n")
notice("\$service_name = ${service_name}\n")
}
modules/sandbox/manifests/params.pp:
#
# a 'sandbox' class for the params pattern.
#
class sandbox::params {
$_server_type_actual = $::sandbox::server_type
case $_server_type_actual {
'combined': {
$service_name = 'sandbox-typeA+typeB'
}
'typeA': {
$service_name = 'sandbox-typeA'
}
'typeB': {
$service_name = 'sandbox-typeB'
}
default: {
fail("\n\nsandbox::server_type must be one of: combined, typeA, typeB\n")
}
}
}
Hopefully the *intent* is relatively clear: provide an intelligent default
value for $service_name based on what the value is for $server_type, but
allow our "intelligent default" value to be overridden. If
'sandbox::server_type' is set to 'typeB' in our hiera hierarchy, I want
the *default* value for 'sandbox::service_name' to become 'sandbox-typeB'.
If the person configuring the machine needs to override that too, they
should be able to, but setting just the first setting should provide
suitable defaults for the others.
This doesn't work, because there's a chicken-or-the-egg problem here.
Class sandbox inherits from sandbox::params to follow the "params
pattern", so settings in the parent class end up depending upon on
parameters to the child class.
Assuming I don't have any need to support old versions of puppet (anything
before 5.x), what's the current best practice for doing this?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.20.1806111713120.8924%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] debugging catalog issue for one client after upgrade
All- I'm using puppet (open source) 3.7.5 on our master (RHEL6.6, x86_64) and all clients (RHEL 5.x, RHEL 6.x, RHEL 7.x). I'm refreshing the hardware on our puppet master, and wanted to take the opportunity to switch the master to RHEL 7 (and therefore new Ruby and some ruby libraries). I'm sticking with puppet 3.7.5 during the hardware/OS refresh. I've been through upgrades on the puppet master before, and have found the Option 1: spin up a temporary master section of https://docs.puppetlabs.com/guides/install_puppet/upgrading.html to be very useful. After copying /etc/puppet (including our version-controlled modules) and /var/lib/puppet/ssl from the production RHEL 6 master to the replacement RHEL 7 master, and starting puppet on the new master as recommended: puppet master --no-daemonize --verbose I've gone through every one of our puppet clients and run puppet agent --test --noop # against current production puppet agent --test --noop --server new-master Both the old master and the new master return identical catalogs for every client ... except one. On one client, it appears that the *client* may be closing the connection very shortly after supplying facts to the new master. I've run both the new master and the client with --debug, and there's no obvious error messages or output that would indicate what the source of the problem is. The client only says: $ sudo puppet agent --test --noop --server new-server Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Broken pipe Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run This client happens to be our largest, as far as # of resources (about 1700, mostly because of a bunch of web proxy lines added to a httpd config file via a define() and concat). The old master takes a while to compile the catalog (so much so that I sometimes have to specify --configtimeout=300 on the client when communicating with the old master), but it does reliably compile and deliver the catalog. The communication between the client and the new master breaks very quickly (within a few seconds), so it's not the same timeout causing the issue. Any suggestions for how I proceed with debugging this issue? I can provide the output from --debug for both the new master and the client, if anyone is interested in looking through it. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: [Puppet Users] Re: workarounds for ruby segfaults on puppet master
In regard to: [Puppet Users] Re: workarounds for ruby segfaults on puppet...: Since RHEL 6.x has alternate versions of some packages (including ruby) available via its Software Collections Library (SCL), I'm tempted to try switching our puppet master to use the ruby193-* packages from SCL. A minor downside is that I won't be able to use the Puppet Labs packages anymore, at least on the master. Hi Tim, why is it that you wouldn't be able to use the packages on the master? I think you should be able to point your apache 'PassengerRuby' directive at the SCL ruby and be good to go. As John Julien already responded, unfortunately that won't work. When you use an updated package from the Software Collections Library, it's essentially installed under a separate installation root, outside of the /usr space. The Puppet Labs packages install their bits to e.g. /usr/lib/ruby/site_ruby/1.8/ but with the SCL packages, that directory isn't going to be anything that the SCL ruby would search. It's going to instead look for things installed in various places under its root, which is /opt/rh/ruby193/root/usr I don't know if the package root directory is different for CentOS, Scientific Linux, or other RHEL derivatives. Another alternative that I'd recommend is to use the new puppetserver package, which runs the master under JRuby and replaces the whole Apache+Passenger+MRI ruby part of the stack. We just got to 3.7.3, after running with 3.4.2 for about 9 months. I haven't yet had a chance to enable the future parser with our traditional stack, so I don't think we're quite ready to bite the bullet and go to puppetserver. It's in our future, to be sure, but it has been painful enough just getting the traditional stack upgraded. Thanks for your thoughts on this! Very much appreciated. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: [Puppet Users] Re: workarounds for ruby segfaults on puppet master
In regard to: [Puppet Users] Re: workarounds for ruby segfaults on puppet...: FWIW here's what I put in /etc/puppet/rack/config.ru that has resolved it for me: Thanks Trey! It was your original post about the issue that got me on a track that eventually got me a workaround. We're now on 3.7.3, and so far (fingers crossed) John's suggestion of just adding --profile, without any of the other options, has allowed us to avoid the problem. ARGV --confdir /etc/puppet ARGV --vardir /var/lib/puppet *ARGV --debug* *ARGV --trace* *ARGV --profile* ARGV --logdest /var/log/puppet/puppetmaster.log If I remove the lines the segfaults become a problem. I'm now on Puppet 3.6.2 and this is still an issue that requires the above work around. Just be sure if you use that work-around to update logrotate to clean out puppetmaster.log as that file will get very large very quickly. The --logdest portion I used to keep the logs out of syslog and so they could be cleaned up more easily using logrotate. Yeah, I was worried about log growth when using those options, but just --profile hasn't had any impact on our logs. If it turns out that we start having the segfaults again, I'll pursue your recommendation and add the remaining options that you're using. Thanks again! Tim On Wednesday, November 19, 2014 11:02:00 AM UTC-6, Tim.Mooney wrote: All- For those of you that are using puppet on RHEL 6.x (/CentOS/Oracle Linux/Scientific Linux/etc.) and have experienced ruby segfaults on your puppet master(s), what workaround or workarounds have you been using? We have been using puppet 3.4.2 (from Puppet Labs repos) for some time, with a RHEL 6.x puppetmaster under mod_passenger. RHEL 6.x currently has ruby 1.8.7 patchlevel 374 as its default ruby version. In the past couple weeks we've started to see a couple of different clients that are triggering segfaults in ruby on the master during a puppet agent run. Examples include: /usr/lib/ruby/site_ruby/1.8/puppet/util/profiler.rb:30: [BUG] Segmentation fault ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] /usr/lib/ruby/site_ruby/1.8/puppet/parser/type_loader.rb:110: [BUG] Segmentation fault ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] Web searches related to this issue turned up a thread from puppet-users earlier this year started by treydock: https://groups.google.com/forum/#!topic/puppet-users/qWN6j-eNiZ0 Unfortunately, I've tried a lot of the workarounds suggested in that thread, and none of them seem to reliably avoid the problem. - I tried back-porting the small patch from PUP-1592 to our 3.4.2 puppet master. No luck. - Yesterday, I bit the bullet and upgraded our entire puppet infrastructure from 3.4.2 to 3.7.3. We still see the same segfaults on the master, both under mod_passenger and when running the master in standalone mode for testing. Since RHEL 6.x has alternate versions of some packages (including ruby) available via its Software Collections Library (SCL), I'm tempted to try switching our puppet master to use the ruby193-* packages from SCL. A minor downside is that I won't be able to use the Puppet Labs packages anymore, at least on the master. The big concern I have relates to how advisable it is to use a different version of ruby on the master vs. all of the clients? Have other RHEL users tried this, with any success? Thanks, Tim -- Tim Mooney tim.m...@ndsu.edu javascript: Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: [Puppet Users] Re: workarounds for ruby segfaults on puppet master
In regard to: [Puppet Users] Re: workarounds for ruby segfaults on puppet...: For those of you that are using puppet on RHEL 6.x (/CentOS/Oracle Linux/Scientific Linux/etc.) and have experienced ruby segfaults on your puppet master(s), what workaround or workarounds have you been using? I found that adding the following to config.ru stops the problem. ARGV --profile I am presuming this is because the --profile option is incrementing the reference count to all the objects in memory for a single catalog compile and prevents the ruby GC bug from thinking something is no longer needed. Thanks John! I had seen that + other options, but I was pretty concerned about running our production master with the amount of logging it would generate. I'll give just --profile a try and see if the situation improves. Another option that will be crazy memory intensive is to disable GC in config.ru GC.disable This worked fine on our test machines, but the only way to make it sustainable in production is to set a really low PassengerMaxRequests. This wasn't a good option for us in production either, as it removed the performance gains of hiera file caching. If you don't have a lot of parameterized classes or your Puppet Masters have a lot of capacity, disabling GC and lowering PassengerMaxRequests might be an option, but I still think --profile is the better way to go. We don't have a lot of parameterized classes, but their use is definitely growing, especially as we start making more use of the best forge modules. GC.disable is a good fall-back idea for us, if the --profile option doesn't completely fix it. I found a bugzilla on the GC bug, don't have the number handy, but it basically said that GC in ruby 1.8.7 has a flawed design and this can't be fixed. So the only real way to avoid all the headaches this bug can cause is repackage to ruby193 or upgrade to Red Hat 7. Yeah, I had seen that one too: https://bugzilla.redhat.com/show_bug.cgi?id=843199 It was the it's so broken it can't be fixed that caused me to ask here. You have been extremely helpful! Thanks so much for the information you've provided! It very likely has saved me a lot of work. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
[Puppet Users] workarounds for ruby segfaults on puppet master
All- For those of you that are using puppet on RHEL 6.x (/CentOS/Oracle Linux/Scientific Linux/etc.) and have experienced ruby segfaults on your puppet master(s), what workaround or workarounds have you been using? We have been using puppet 3.4.2 (from Puppet Labs repos) for some time, with a RHEL 6.x puppetmaster under mod_passenger. RHEL 6.x currently has ruby 1.8.7 patchlevel 374 as its default ruby version. In the past couple weeks we've started to see a couple of different clients that are triggering segfaults in ruby on the master during a puppet agent run. Examples include: /usr/lib/ruby/site_ruby/1.8/puppet/util/profiler.rb:30: [BUG] Segmentation fault ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] /usr/lib/ruby/site_ruby/1.8/puppet/parser/type_loader.rb:110: [BUG] Segmentation fault ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] Web searches related to this issue turned up a thread from puppet-users earlier this year started by treydock: https://groups.google.com/forum/#!topic/puppet-users/qWN6j-eNiZ0 Unfortunately, I've tried a lot of the workarounds suggested in that thread, and none of them seem to reliably avoid the problem. - I tried back-porting the small patch from PUP-1592 to our 3.4.2 puppet master. No luck. - Yesterday, I bit the bullet and upgraded our entire puppet infrastructure from 3.4.2 to 3.7.3. We still see the same segfaults on the master, both under mod_passenger and when running the master in standalone mode for testing. Since RHEL 6.x has alternate versions of some packages (including ruby) available via its Software Collections Library (SCL), I'm tempted to try switching our puppet master to use the ruby193-* packages from SCL. A minor downside is that I won't be able to use the Puppet Labs packages anymore, at least on the master. The big concern I have relates to how advisable it is to use a different version of ruby on the master vs. all of the clients? Have other RHEL users tried this, with any success? Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1411191037010.18829%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: creating hashes from other hashes
In regard to: Re: [Puppet Users] Re: creating hashes from other hashes,...:
On 2014-07-11 23:43, Tim Mooney wrote:
In regard to: [Puppet Users] Re: creating hashes from other hashes,
Luke...:
Huh, at first glance that to me looks like a parser bug.
Not so much a bug as an unessesary constraint.
This is changed in Puppet 4.0 (and when using --parser future in late 3x
releases).
i.e. this then works:
apply --parser future -e '$x = hello notice({$x = world})'
Notice: Scope(Class[main]): {hello = world}
WARNING: string containing only a variable on line 39
WARNING: variable not enclosed in {} on line 39
Lint is simply complaining too much. There are several reasons for
interpolating a single variable either as $x, or ${x} - one such reason is
the constraint on hash keys, another is to force numeric to string conversion
- say $x = 2 + 3 which makes $x not be a string but an Integer, some functions
/ uses does not do well when they receive an Integer instead of a String, and
it must be transformed to a string, either via interpolation, or by calling
the printf function.
So, while you in general do not have to do single variable interpolation, link
is wrong in complaining about it everywhere.
You could perhaps trick it by doing ${$x} which is an interpolation of an
interpolation :-)
Yet another option is to call the printf function in the interpolation
expression.
Hope that helps explain why it does not work and how you can work around it
until Puppet 4.0.0 comes out.
Thanks Henrik! We're probably still a few weeks from upgrading to 3.7.x,
but when we do, getting our code ready for the future parser is also on
the list of things to do.
I had been planning on just temporarily disabling our entire pre-commit
hook, but since I've needed to use this in a couple of defines now, I did
end up going the route that Denmat suggested in a separate email, and just
used --no-only_variable_string-check with the other lint flags we're
passing to puppet-lint.
I appreciate your response and insight regarding this!
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.11.1411131109390.6400%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: creating hashes from other hashes
In regard to: [Puppet Users] Re: creating hashes from other hashes, Luke...:
Huh, at first glance that to me looks like a parser bug.
That's what I was thinking too.
Now that I think
more on it I seem to recall this coming up before. The $name of a Defined
Type is not of type String, and Puppet Hash keys are always strings,
according to the docs:
https://docs.puppetlabs.com/puppet/latest/reference/lang_datatypes.html#hashes
This code works, explicitly enclosing $name in a string:
Ok, thanks. Unfortunately, we have puppet-lint hooked into our pre-commit
hook, and puppet-lint objects to a variable that is enclosed in double
quotes for no reason:
WARNING: string containing only a variable on line 39
WARNING: variable not enclosed in {} on line 39
I even tried doing this, to get around puppet-lint:
$my_key = strip( ${name } )
$new_pool = {
$my_key = $fpm_pool,
}
Still no joy, as now the parser objects to $my_key. This really does
seem like a bug in the parser.
It looks like I'm going to have to temporarily disable our pre-commit
hook, and check in the code using $name.
Thanks again Luke, your insight on this is much appreciated!
Tim
On Thursday, November 6, 2014 10:04:00 PM UTC, Tim.Mooney wrote:
All-
We're using puppet (opensource) 3.4.2 master and clients. We've been
using puppet a few years, including create_resources, but this is my
first foray into creating complicated nested hashes.
I've boiled the problem I'm running into down to this example:
$ cat /tmp/foo.pp
class foo {
foo::bar { 'somevalue':
stuff = {
'one' = 'doesnt_matter',
'two' = 'doesnt_matter',
}
}
}
define foo::bar (
$stuff = {},
) {
#
# not valid: fails with a parser validation error on the key $name:
#
# Error: Could not parse for environment production: Syntax error at
# 'name';
# expected '}' at /tmp/foo.pp:21
#
$new_hash = {
$name = $stuff,
}
#
# this works, using a constant key
#
$new_hash = {
'a_constant' = $stuff,
}
}
This comes from a larger, more complicated example, but what I'm trying to
do is
- take a hash ($stuff) that has all the parameters I need
- create a new hash with a single key that's the $name/$title for the
define,
and a value that contains the hash $stuff that I was passed.
As you might guess, this is to make $new_hash suitable for passing
to create_resources.
Is there some other way to create a new hash, give it a single top-level
key that is a variable, and assign a separate (passed-in as a parameter)
hash as the value for that key? I would be fine with using stdlib::merge,
but I don't see any obvious way to accomplish this task with stdlib::merge
either.
Thanks,
Tim
--
Tim Mooney tim.m...@ndsu.edu
javascript:
Enterprise Computing Infrastructure 701-231-1076
(Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.11.1411071622310.23044%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] creating hashes from other hashes
All-
We're using puppet (opensource) 3.4.2 master and clients. We've been
using puppet a few years, including create_resources, but this is my
first foray into creating complicated nested hashes.
I've boiled the problem I'm running into down to this example:
$ cat /tmp/foo.pp
class foo {
foo::bar { 'somevalue':
stuff = {
'one' = 'doesnt_matter',
'two' = 'doesnt_matter',
}
}
}
define foo::bar (
$stuff = {},
) {
#
# not valid: fails with a parser validation error on the key $name:
#
# Error: Could not parse for environment production: Syntax error at
# 'name';
# expected '}' at /tmp/foo.pp:21
#
$new_hash = {
$name = $stuff,
}
#
# this works, using a constant key
#
$new_hash = {
'a_constant' = $stuff,
}
}
This comes from a larger, more complicated example, but what I'm trying to
do is
- take a hash ($stuff) that has all the parameters I need
- create a new hash with a single key that's the $name/$title for the define,
and a value that contains the hash $stuff that I was passed.
As you might guess, this is to make $new_hash suitable for passing
to create_resources.
Is there some other way to create a new hash, give it a single top-level
key that is a variable, and assign a separate (passed-in as a parameter)
hash as the value for that key? I would be fine with using stdlib::merge,
but I don't see any obvious way to accomplish this task with stdlib::merge
either.
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.11.1411061531150.12196%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] parameters for puppetlabs-apache module with RHEL SCL httpd24
All- I'm hoping there are at least a few people on the list that are successfully using the puppetlabs-apache module with the httpd24 packages from the Red Hat Software Collections Library, aka SCL. If you're one of those people, can you share what parameters you've had to override, or anything else you had to do to get puppetlabs-apache to work with the nonstandard package/service/file/path names in httpd24 from SCL? For those that aren't familiar with SCL, it's a collection of updated, alternate versions of some packages. It's provided by Red Hat for RHEL, and CentOS and potentially other RHEL-respins have it too. For backward compatibility, Red Hat won't do major upgrades to the httpd package from the 2.2.x version that shipped in RHEL 6.0, but they are now providing a parallel httpd24 package that installs in a different spot, has a different init script, etc. The default parameters in the puppetlabs-apache module assume the older 'httpd' package, /etc/httpd for the base dir, etc. I'm looking for what parameters people are passing to the apache class to get it to work with the httpd24 alternate. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1410031120580.7601%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] advice and best practices for environments
All-
I'm looking for some advice/wisdom/guidance about workflow and
configuration from sites that have been using environments for a while.
I'll happily take advice from anyone, but I'm especially interested in
tips from people that are using subversion as their VCS and are not
using an ENC.
The TL;DR list of questions I have is roughly:
- how are you controlling which nodes get assigned to which environments?
Templated puppet.conf and hiera()? Some other method?
- how are you using hiera with environments, especially in relation to
the environments limitations[1] page?
- what about custom puppet:/// mount points (outside of modules)? The
puppet doc overview of environments say that custom file paths are
not supported with environments[2], but that's not mentioned on
the limitations[1] page.
- do you use dynamic environments, and if so what's your subversion
workflow look like? The puppet docs call these Temporary Test
Environments [3]
[1] -
http://docs.puppetlabs.com/puppet/latest/reference/environments_limitations.html
[2] -
http://docs.puppetlabs.com/guides/environment.html?utm_campaign=docsutm_medium=blogutm_source=puppetlabs.comutm_content=environments
[3] -
http://docs.puppetlabs.com/puppet/latest/reference/environments_suggestions.html
Additional details on our environment:
We've been using puppet since 2.6.x, and are currently at 3.4.2. We're
looking to go to 3.6.x and also update our configuration for both
directory environments and the manifests dir, to be more prepared for
what 4.x will likely require.
We're not currently using any environments hangs head in shame/, so
the workflow and configuration needed for a non-git deployment has
me a little confused.
We don't use an ENC -- we have Puppet Dashboard, but use it rarely,
and only for reporting. As part of the move to 3.6.x, I would want to
switch us from site.pp with import nodes/*.pp to a manifests directory.
Our current /etc/puppet/hiera.yaml looks like:
---
:backends: - yaml
:hierarchy: - secure/fqdn/%{clientcert}
- fqdn/%{clientcert}
- secure/location/%{location}
- location/%{location}
- secure/common
- common
:yaml:
:datadir: /etc/puppet/hiera-data
%{location} is a custom fact associated with a particular datacenter.
We are using one custom puppet:/// file mount point (fileserver.conf):
[secure]
path /etc/puppet/secure/%H
allow *
Our modulepath in our current puppet.conf on the master looks like:
modulepath =
/etc/puppet/modules:/usr/share/puppet/modules:/etc/puppet/forge-modules
Any tips and advice people have regarding workflow with environments and
subversion would be greatly appreciated!
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.11.1406261426440.15804%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: RHEL7 facts missing
In regard to: Re: [Puppet Users] Re: RHEL7 facts missing, Bas Wildemann...: I think you may be right and I'm thinking about opening a ticket. AFAIK net-tools will be deprecated in future RHEL versions, so a solution is necessary. I discovered this issue independently last week, and opened a ticket before seeing Bas' email. https://tickets.puppetlabs.com/browse/FACT-597 Note that I linked that issue to the larger underlying issue, the deprecation of ifconfig and the need to use ip for things like ip address and network interfaces: https://tickets.puppetlabs.com/browse/FACT-184 Tim Op maandag 23 juni 2014 09:55:49 UTC+2 schreef Felix.Frank: Hi, if this is a crucial package for correct Facter operation, and it's not a hard dependency in the RHEL7 package, then this may be a bug. Would either of you look through the tickets at https://tickets.puppetlabs.com/ and open a new one if this is not being tracked already? Thanks, Felix On 06/21/2014 11:05 PM, Bas Wildemann wrote: Jelle, Installing net-tools package solved it. Thanks for your pointer! Op zaterdag 21 juni 2014 14:17:56 UTC+2 schreef Jelle B: Hi , Yes this is to be expected as RHEL 7 does away with some of the dependencies like ifconfig etc. You will have to install thoose after. For that you will also have to install some extra repos if I recall right. You will have to install bind-utils and net-tools for all to function normal again. Hope this helps. -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1406251735570.14208%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: selecting a command in a provider based on class variable?
In regard to: [Puppet Users] Re: selecting a command in a provider based on...: On Friday, April 11, 2014 7:15:05 PM UTC-5, Tim Mooney wrote: Hi All! The tl;dr version: Can anyone point me at an example of an existing provider that selects a particular command based not on a facter fact or whether a particular path exists, but instead on a variable from a puppet class? No, and that's a poor idea. Providers should not have visibility into or dependency on the class declaring the resource provided for. If your provider is for a custom type, however, then it seems to me that the natural approach would be to add a parameter (not a property) to the type. Providers can easily access the parameter values of a resource instance; in fact, that's the entire purpose of parameters that are not properties. If you are writing custom providers for built-in types, however, then the best I can come up with is to write different flavors of the provider (with different names) to cover the specific cases you care about. Thanks John! That idea occurred to me over the weekend and you've confirmed that it's a much better way to go. Much appreciated, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1404141351490.17447%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] selecting a command in a provider based on class variable?
Hi All! The tl;dr version: Can anyone point me at an example of an existing provider that selects a particular command based not on a facter fact or whether a particular path exists, but instead on a variable from a puppet class? The full version: We have puppet 3.4.2 on master and all agents, generally from the PuppetLabs packages for OpenSource puppet. Red Hat has begun providing alternate (updated) versions of some packages as part of its Software Collections Library, aka SCL. If you have a RHEL 6.5 system subscribed to the appropriate software collections channel, it's entirely possible to have something like this: $ rpm -q -f /usr/bin/mysql mysql-5.1.73-3.el6_5.x86_64 $ rpm -q -f /opt/rh/mysql55/root/usr/bin/mysql mysql55-mysql-5.5.36-1.1.el6.x86_64 For a provider that relies on the mysql command-line tool to accomplish certain tasks, it's no longer a great solution to just do commands :mysql = 'mysql' I also don't want to just have it always use the binary from /opt/rh/mysql55/root/usr/bin/mysql if it's present, since it's at least conceivable that one might need to use a particular version of the client when accessing a particular database. The best idea I've come up with is to have the provider decide which specific version of a command to use based on a variable that has already been set in the class, but I haven't found any examples of providers that do that. If anyone can point me at some prior art, I would greatly appreciate it. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1404111843100.17447%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] error testing puppet 3.x upgrade: You need rubygems to use Hiera
= inclusive,
uid= '709844',
password = hiera('ncsprime_password', '!!'),
}
Our /etc/puppet/hiera.yaml that I copied from our existing 2.7.14 master
to the promoted 3.4.2 temporary master is
---
:backends: - yaml
:hierarchy: - secure/fqdn/%{clientcert}
- fqdn/%{clientcert}
- secure/location/%{location}
- location/%{location}
- secure/common
- common
:yaml:
:datadir: /etc/puppet/hiera-data
I don't understand what I'm missing; I have the rubygems package installed
on both the promoted master and the client I'm trying to test with. I know
that hiera moved into the core at 3.x and that on my real master I will need
to uninstall the 'rubygem-hiera-puppet' package, but the client I promoted
to be the temporary master has never had that installed.
Google searches for this error just turn up the install rubygems response.
Brent Clark posted to this list in December with the same problem, but
there were no follow-up responses.
Any suggestions as to what the problem really is, because it's *not* that
I'm missing rubygems.
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.11.1401171651430.29424%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] error testing puppet 3.x upgrade: You need rubygems to use Hiera
In regard to: Re: [Puppet Users] error testing puppet 3.x upgrade: You need...: Any chance you have a symlink to /usr/lib/ruby/site_ruby/1.8/hiera/backend/ (or something similar) floating around in your /var/lib/puppet? This was a common way to get Hiera to work in Puppet 2.7 before the necessary glue was built into 3.x. If you do, remove it and restart. I checked, and there are no symlinks anywhere in /var/lib/puppet on the client that was promoted to be the test server: # cd /var/lib/puppet # find . -type l -print # find . -name 'site_ruby' -print # find . -name 'hiera' -print # find . -name 'backend' -print # find . -name '*.rb' -print # After I sent my message to the list last night, I also decided to try deleting everything (except the ssl directory) under /var/lib/puppet on the promoted client and then re-installing the puppet puppet-server packages, and that still didn't make any difference. I definitely appreciate the response and the suggestions for stuff to look for, but unfortunately it doesn't seem to be what's causing the issue. Tim On 1/8/2014 5:16 PM, Tim Mooney wrote: All- I've been struggling with this all afternoon, so it's time to ask for some help. The TL;DR version: On a 2.7.14 puppet client promoted to be a test 3.4.2 master, whenever a client connects I get: Warning: Puppet.features.rubygems? is deprecated. Require rubygems in your application's entry point if you need it. (at /usr/lib/ruby/site_ruby/1.8/puppet/util/feature.rb:17:in `add') Error: You need rubygems to use Hiera at /etc/puppet/manifests/users.pp:243 on node rh6client.example.com Error: You need rubygems to use Hiera at /etc/puppet/manifests/users.pp:243 on node rh6client.example.com Error: You need rubygems to use Hiera at /etc/puppet/manifests/users.pp:243 on node rh6client.example.com I have the RHEL-provided rubygems package installed (it gets installed automatically as a dependency of puppet 3.4.2 from Puppet Labs), so why the error? The full version: We're currently using puppet 2.7.14 with facter 1.5.9, both on master and on our clients. All of our clients are currently RHEL 5.x or RHEL 6.x, though we'll likely be adding other OSes once we're on Puppet 3.x. I'm beginning our testing of 3.4.x by following the documentation here: http://docs.puppetlabs.com/guides/upgrading.html I'm following the Option 1 route, promoting a client to be the master. The client I'm promoting is a fresh install of RHEL 6.5 with our puppet 2.7.14, and I have done a puppet apply on it to get all local config in place for a basic puppet client in our environment. I then copied all of /etc/puppet and /var/lib/puppet from our current master over to the client I wish to promote. To promote the client to be the test master, I uninstall our locally-built RPMs for facter puppet, then install the PuppetLabs EL6 rpms for facter-1.7.4-1.el6 hiera-1.3.0-1.el6 puppet-3.4.2-1.el6 puppet-server-3.4.2-1.el6 rubygem-json-1.5.5-1.el6 ruby-rgen-0.6.5-1.el6 That also auto-installed, for dependencies, Red Hat's packages for ruby-rdoc-1.8.7.352-13.el6.x86_64 ruby-irb-1.8.7.352-13.el6.x86_64 rubygems-1.3.7-5.el6.noarch I have updated the auth.conf to have allow_ip stanzas for the one custom file serving location we use. I start up the temporary puppet master: # puppet master --no-daemonize --verbose Notice: Starting Puppet master version 3.4.2 I then pick an existing client, rh6client.example.com, uninstall facter puppet, install the Puppet Labs facter puppet, which also pull in Puppet Labs' hiera rubygem-json, as well as the Red Hat ruby-rdoc, ruby-irb, and rubygems. I point the client at the temporary master and receive (on the client) the error: # puppet agent --server pm-tmp.example.com --test --noop Info: Retrieving plugin Info: Loading facts in /var/lib/puppet/lib/facter/printers.rb Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb Info: Loading facts in /var/lib/puppet/lib/facter/net_location.rb Info: Loading facts in /var/lib/puppet/lib/facter/biosversion.rb Info: Loading facts in /var/lib/puppet/lib/facter/net_info.rb Info: Loading facts in /var/lib/puppet/lib/facter/ipmi_product.rb Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb Info: Loading facts in /var/lib/puppet/lib/facter/pacemaker.rb Error: Could not retrieve catalog from remote server: Error 400 on SERVER: You need rubygems to use Hiera at /etc/puppet/manifests/users.pp:243 on node rh6client.example.com Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run On the temporary server, it has output a bunch of Info statements about processing for auth.conf, but follows that with: Info: Caching node for rh6client.example.com Info: Caching node for rh6client.example.com Warning: Puppet.features.rubygems? is deprecated. Require rubygems in your application's entry point if you need it. (at /usr/lib/ruby/site_ruby/1.8/puppet
[Puppet Users] error testing puppet 3.x upgrade: You need rubygems to use Hiera
missing; I have the rubygems package installed on both the promoted master and the client I'm trying to test with. I know that hiera moved into the core at 3.x and that on my real master I will need to uninstall the 'rubygem-hiera-puppet' package, but the client I promoted to be the temporary master has never had that installed. Google searches for this error just turn up the install rubygems response. Brent Clark posted to this list in December with the same problem, but there were no follow-up responses. Any suggestions as to what the problem really is, because it's *not* that I'm missing rubygems. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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/alpine.SOC.2.11.1401081910330.14091%40dogbert.cc.ndsu.NoDak.edu. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] passing an environment variable to a command in a provider
In regard to: Re: [Puppet Users] passing an environment variable to a...:
On Fri, Jun 28, 2013 at 2:03 PM, Tim Mooney tim.moo...@ndsu.edu wrote:
We have some custom types providers related to mysql (mysql_user,
mysql_grant, mysql_db) written by an admin that's no longer here. The
provider just uses the mysql command to run various commands, e.g:
Puppet::Type.type(:mysql_user)**.provide(:mysql) do
desc Provider for a mysql user
optional_commands :mysql = 'mysql'
mk_resource_methods
def create
debug mysql_user create
@property_hash[:ensure] = :present
mysql('mysql','-e',create user '%s' identified by '%s'; %
[@resource[:name].sub(@,'@'**),@resource[:password]])
end
def flush
debug in flush
mysql('mysql','-e','flush privileges;')
@property_hash.clear
end
# other stuff elided
end
For this particular provider/type to work, though, it requires that
you actually have root's environment, because it relies on reading some
config from /root/.my.cnf.
That means that on most of our hosts, doing
sudo puppet agent --test
works fine, but on hosts where we use our mysql module with the custom
types and provider, we can't do that. We instead have to
sudo su -
puppet agent --test
to make certain we've picked up root's environment, specifically HOME.
What I would like to do is augment the provider so that the mysql command
is always invoked with the environment augmented with HOME=/root or
(even better) HOME=roots_home_from_facter.
In Puppet 3, home environment can be passed something like:
has_command(:brew, 'brew') do
environment({ 'HOME' = ENV['HOME'] })
end
Thanks Nan. Even though I know better, I forgot to supply one bit of
info -- we're still running puppet 2.7.x and I'm not certain when we're
going to move to 3.2.x.
Is there a puppet 2.7.x equivalent?
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] passing an environment variable to a command in a provider
In regard to: Re: [Puppet Users] passing an environment variable to a...: On Jun 28, 2013 2:06 PM, Tim Mooney tim.moo...@ndsu.edu wrote: works fine, but on hosts where we use our mysql module with the custom types and provider, we can't do that. We instead have to sudo su - puppet agent --test An alternative and trivia in addition to what Nan said: You can use sudo -H to set $HOME, or sudo -i to get a full login environment like 'su -' gives. There are also sudoers config params that can make at least the former default, and probably the latter too. Thanks Wil. I knew about each of these, but I would rather fix the type/provider to work even with normal sudo usage, rather than requiring people to remember to use one of these. Yes, they could use aliases or shell functions, but I still think it's a better solution to make type/provider work for any case. Additionally, you can explicitly pass the path of the `my.cnf`, rather than relying on $HOME, I've thought about this too and I agree that it's even better. To do it right, though, I would want to make it use the root_home fact. That's one more thing I don't know how to do yet, though. It looks like http://docs.puppetlabs.com/guides/provider_development.html has a section on using facts in providers, so I'll do some experimenting and see if I can't muddle through. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] passing an environment variable to a command in a provider
All-
We have some custom types providers related to mysql (mysql_user,
mysql_grant, mysql_db) written by an admin that's no longer here. The
provider just uses the mysql command to run various commands, e.g:
Puppet::Type.type(:mysql_user).provide(:mysql) do
desc Provider for a mysql user
optional_commands :mysql = 'mysql'
mk_resource_methods
def create
debug mysql_user create
@property_hash[:ensure] = :present
mysql('mysql','-e',create user '%s' identified by '%s'; %
[@resource[:name].sub(@,'@'),@resource[:password]])
end
def flush
debug in flush
mysql('mysql','-e','flush privileges;')
@property_hash.clear
end
# other stuff elided
end
For this particular provider/type to work, though, it requires that
you actually have root's environment, because it relies on reading some
config from /root/.my.cnf.
That means that on most of our hosts, doing
sudo puppet agent --test
works fine, but on hosts where we use our mysql module with the custom
types and provider, we can't do that. We instead have to
sudo su -
puppet agent --test
to make certain we've picked up root's environment, specifically HOME.
What I would like to do is augment the provider so that the mysql command
is always invoked with the environment augmented with HOME=/root or
(even better) HOME=roots_home_from_facter.
I'm not certain how to pass an environment variable to an external command
that's invoked as part of a puppet provider, though, and the searches I've
done so far haven't turned up anything helpful.
Can anyone that's familiar with writing types and providers shed some
light on what I should be doing to augment this? I know this is as much
ruby ignorance as puppet ignorance, but I have to believe that there are
people here that can point me in the right direction.
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppetdb source install on Solaris. Agents complain about invalid encoding (UTF-8//IGNORE, UTF-8)
In regard to: Re: [Puppet Users] Puppetdb source install on Solaris. Agents...: It looks like the iconv library in the version of Ruby provided by the OpenIndiana repo may be too old, lack a required method or have an incompatible version of the method being used to transform the contents of the catalog. I don't think it's an issue with your ruby Iconv. root@atropos:~# ruby -r iconv -ve 'pp Iconv.list' ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-solaris2.11] -e:1: undefined method `list' for Iconv:Class (NoMethodError) I get the exact same error when I run Deepak's suggested command on RHEL 6, which includes ruby 1.8.7: $ ruby -e require 'iconv'; puts Iconv.list.sort -e:1: undefined method `list' for Iconv:Class (NoMethodError) If I run that on Solaris 10 with ruby 1.9.3 p327 compiled from source, I get: $ ruby -e require 'iconv'; puts Iconv.list.sort /local/lib/64/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be deprecated in the future, use String#encode instead. -e:1:in `list': list() function is unimplemented on this machine (NotImplementedError) from -e:1:in `main' (learning Ruby is still on my to-do list) Same for me, and it has presented a slight barrier to entry for becoming really comfortable with puppet. ruby -e require 'iconv'; puts Iconv.list.sort That should dump out the list of available encodings. That should help us at least more properly triangulate the issue. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] upgrading puppet
In regard to: [Puppet Users] upgrading puppet, Paolo said (at 2:08am on Nov...: I have an old puppet infrastructure that runs puppet 0.24.4 (client and server) and I was finally given the go ahead to upgrade (both client and server) :-) I have a few questions: 1. To which version should I upgrade puppet to? I was thinking of upgrading to the latest 2.6 version... I think the answer is, it depends. I personally would want to upgrade to puppet 3.0.x. Since you're going to go through the pain of upgrading anyway, it would be best to upgrade to what's current, so you avoid a separate upgrade from 2.6 or 2.7 to 3.x. Of course, there's always a chance that doing separate upgrades will be less work overall, but I'm skeptical about that in this case. The main gotcha is that 3.x introduces a number of incompatible, so it might require changes to some of your classes to upgrade to 3.x than it would to go to 2.6. It all depends on what features you've made use of and how your classes are written. If you don't decide to upgrade to 3.x, you should at least consider 2.7. I can't think of any compelling reason to choose 2.6 over 2.7, at this point. 2. Anyone knows of any pitfalls I should watch out for in upgrading from such an old version? Scoping with variable names and facts is probably the big one. Another one that we had to adjust is classes with a - in the name. That even breaks in some of the later 2.7 versions, though there's a setting in 2.7.20 that allows it to work again. My recommendation is that you install 3.0.x somewhere, install puppet-lint, and use puppet-lint and puppet parser validate on your manifests. Study the output from both, and adjust accordingly. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Managing ssh server's keys?
In regard to: Re: [Puppet Users] Managing ssh server's keys?, Matt...: Here is my fileserver.conf: [private] path /etc/puppet/private/%h allow * FWIW, we're handling ssh keys and other sensitive full-file content nearly identically, although we we chose /secure rather than /private and we're using %H (fqdn) rather than %h (short host name). Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] New to Puppet -- why the puppet user
In regard to: Re: [Puppet Users] New to Puppet -- why the puppet user,...: Because standard systems administration practice is to rarely if ever run anything at all as root. When it doesn't require root, that's absolutely true. This relates to the principle of least privilege. However, the puppet agent that runs on each puppet client requires the ability to make modifications to nearly everything about the client system, all in an effort to enforce the state that the puppet server has indicated that the client should be in. I suppose you could do that using something like sudo or Solaris RBAC, but you would end up granting so much access to the puppet agent that you would essentially be running it as root anyway. There's very little point going through that exercise for an agent that requires unfettered access to the client system. To answer the original question: there's a puppet user and group for the very few things that do *not* require root: specifically, the puppet master and components like Dashboard. They are, essentially, web applications, and don't require any special privileges, so the PuppetLabs folks wisely made them run as a non-privileged user ( group). Note that if your puppet master is a client of itself (or some other puppet master) then the puppet agent running there still needs to be run as root. The agent enforces the state, which requires administrative access. The master calculates the state, which doesn't. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Re: Seeking some Puppet advice for a newbie (specifically Virtualmin/CSF related)
In regard to: Re: [Puppet Users] Re: Seeking some Puppet advice for a...: On Tue, Nov 20, 2012 at 1:54 PM, Laurence Cope amitywebsoluti...@gmail.com wrote: you will need to create your own Yum repository, have Puppet configure yum to make use of that repo, then create a manifest that installs the package. Ah right... this bit helps a lot. never thought of creating an own repo, that makes sense now. so if its in a repo puppet can do it. I will look into that, and also request Virtualmin do it because I asked them about this on their forum, but they had no experience with Puppet. Makes sense for it to come from a repo they manage. I generally favour my own private yum repositories rather than upstream repositories for the following reasons: +1, for all the reasons Matt mentioned. Making your own repo may seem daunting, but it's not bad at all. If you have an internal server that's running http and has enough disk space to store your RPMs, you're already most of the way there. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Puppet - Postfix - How-To edit generic.db
In regard to: [Puppet Users] Puppet - Postfix - How-To edit generic.db,...:
New-ish to Puppet. I'm just getting beyond the basics, now.
Got a postfix module defined. But there is a wrinkle: the server needs to
send mail from root as r...@domain.com not r...@hostname.domain.com
So the big question is whether this config needs to be applied to *all*
the systems where you might run postfix, or whether it's specific to
one particular system or set of systems.
Because our service desk accepts tickets from servers BUT the counts as
'spam' anything NOT from domain.com.
This is easy with postfix:
edit /etc/postfix/generic - add r...@hostname.domain.com
hostn...@domain.com
You need to modify a file, so you'll want to have a file resource
defined somewhere. Are there other settings in that file you typically
customize? If so, you may want the source for the file to be a
template(). If not, there are other ways you might handle it.
So, the file resource is going to look something like
file { '/etc/postfix/generic':
ensure = file,
owner = 'some_user',
group = 'some_group',
mode = '0somethingsomethingsomething',
source = yet_to_be_determined,
notify = Exec['postmap-generic'],
}
The real question is what goes in the yet_to_be_determined area for
the source. It could be a template
source = template('postfix/generic.erb'),
or perhaps it's a list of files (first one that matches is used):
source = [
puppet:///modules/postfix/generic.${::fqdn},
'puppet:///modules/postfix/generic',
],
Determining how you pick the source for the file is going to be the
most difficult part of this, and it depends on how much customization
you need to do.
$ postmap /etc/postfix/generic
For that, you need an exec resource to execute your command after the file
is modified:
exec { 'postmap-generic':
cwd = '/etc/postfix',
path= '/bin:/usr/bin:/sbin:/usr/sbin',
command = 'postmap generic',
refreshonly = true,
notify = Service['postfix'],
}
restart service postfix
service { 'postfix':
ensure = running,
enable = true,
}
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: Apply multiple defines in sequence
In regard to: [Puppet Users] Re: Apply multiple defines in sequence, Erwin...:
Thanks again for you reply, but it seems like you don't fully understand
what I'm having problems with. So I'll try to clarify it a little more:
1. The current way of using two defines is working flawlessly. So I (at
least partly) understand the concepts surrounding those.
2. Because I have two types of machines: some with just sugar and some with
sugar and wordpress, I now use two defines that overlap in part (define1
contains all kinds of info about creating sugar db + unpacking tar, etc,
while define2 contains all the sugar info of define1 + stuff about creating
a wordpress db + unpacking wp tar, etc), this means editing two files when
I change something in the sugar define.
So have one additional parameter to your define,
sugar_with_wordpress = 'no'
and then in the body of your define, after you've done all the necessary
setup for sugar, that is always present, have
if $sugar_with_wordpress == 'yes' {
# wordpress-specific stuff here
}
I use yes/no strings instead of boolean true/false because you'll
eventually want to have those settings come from hiera, and as things
currently stand booleans from hiera are just a trap for the unwary.
I would actually do the wordpress stuff as a separate class, which has
its own wordpress::instance define, and then call that define from within
your sugar::instance define.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Install RPM package via puppet
In regard to: [Puppet Users] Install RPM package via puppet, Sixthmoon said...:
I have the package added to an internal yum repo. OS is Centos 5.4. Puppet
version is 2.6.2-1. The module is utilities. This is a working production
environment. (Person who set it no longer around) As a verification item to
note, I have added a custom fact to the utilities module and it correctly
being picked up by the test node.
I have added the following to init.pp
class utilities {
package { iftop:
ensure = present,
source =
'http://yum.repo.internal/misc/iftop-0.17-1.el5.rf.x86_64.rpm'
}
}
package { 'iftop':
ensure = present,
require = Yumrepo['your-repo-name-here'],
}
You should also have a
yumrepo {'your-repo-name-here':
baseurl =
'http://your.host.here/repo/CentOS/$releasever/$basearch/',
enabled = 1,
descr = 'whatever',
metadata_expire = '300',
}
somewhere in your catalog.
You've already done the parts that a lot of people seem to want to skip;
specifically packaging the software and creating a local repo with the
software in it. You just need to define your repo to puppet and then
use a very standard package resource to make it present.
Note the yumrepo resource type supports a lot more attributes, which you
may wish to investigate.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] RHEL 6 Protected multilib versions Requirment to have both 32 and 64 bit libs installed.
In regard to: [Puppet Users] RHEL 6 Protected multilib versions Requirment...:
(/Stage[main]/Libstdc/Package[libstdc++.i686]/ensure) change from absent to
present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install
libstdc++.i686' returned 1: Error: Protected multilib versions:
libstdc++-4.4.6-4.el6.i686 != libstdc++-4.4.6-3.el6.x86_64#012 You could
try using --skip-broken to work around the problem#012 You could try
running: rpm -Va --nofiles --nodigest
the .pp :
class libstdc {
Class[rhn]-Class[libstdc]
Are you really intending to have Class['rhn'] applied *before*
Class['libstdc'], because that's what your arrow chaining says. I would
assume you're trying to install both archs because RHN Satellite needs
both but doesn't have the 32 bit version as an explicit dependency.
If that's the case, you should swap what side of the - the two classes
are on.
package { libstdc++.i686:
ensure = installed,
}
package { libstdc++:
ensure = installed,
}
As John said, your best bet is to get the 32 bit version installed
because of a dependency of something else. It's frankly ridiculous
that Red Hat provides a product that doesn't do this correctly, but
we can work around that, even without having to try repackage RHN
Satellite.
This can be done very easily by creating a package that contains no files
at all, but lists other packages as requirements. The trick is to have
empty %prep/%build/%install/%files sections of your spec file, but list
either
- package names
- exact shared library SONAMES
- (as a last resort) full paths to a file or library
in the Requires: entries for the RPM. An example spec file you might
start with to build an RPM is included after my signature. You would
just need a RHEL box with the 'rpm-build' package installed, something
like
rpmbuild -ba -v rhn-satellite-32bit-deps.spec
and then you put that package in your local repo and have puppet
package { 'rhn-satellite-32bit-deps':
ensure = installed,
}
This virtual package then pulls in whatever dependencies you have listed.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Summary: pull in the 32 bit dependencies for RHN Satellite
Name: rhn-satellite-32bit-deps
Version: 1.0
Release: 1
Group: Local/Whatever
License: Copyright (C) your organization here
URL: http://yourcompany/whatever/you/want/here
Vendor: Your Company and possibly OU here
Distribution: Your distribution name here
#
# Preference #1: require package names, like make or kernel-headers
#
#Requires:
#
# If you need specific SONAME and arch for a library, that can be
# accomplished like this
#
# the 32 bit version
Requires: libstdc++.so.6
# the 64 bit version
#Requires: libstdc++.so.6()(64bit)
#
# Last resort, only use if others don't work: specify a full path to the file
# that some other RPM should be installing. This can generally be
# accomplished better by using a package name instead.
#
#Requires: /usr/bin/bash
%description
This package contains no files. It exists solely to specify other
packages that should be installed when this virtual package is installed.
%prep
# no software to extract and prepare for compilation
exit 0
%build
# nothing to build
exit 0
%install
# nothing to install
exit 0
%files
# no files contained in this RPM.
--
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.
Re: [Puppet Users] Have Class Only Perform Actions When There Is Work To Do (i.e. Making Them Idempotent)
In regard to: [Puppet Users] Have Class Only Perform Actions When There Is...:
Howdy. I feel like I am missing something really simply with regards to the
way that Puppet works and I am wondering if someone can point me in the
write direction.
I have written a class that downloads, uncompresses, compiles, and installs
Python from source. So far so good.
I would highly recommend you just package your custom python and install
it using a package management system, rather than doing what you're doing.
Depending on what host OS you're using, it's not too difficult, and it
works a lot better with puppet *and* you get all the benefits of having
the package installed through a more coherent means.
The problem is that it only needs to do
this once, when Python is not already in place (or some other custom
indicator of the Python version). I have my 3 calls to exec doing their
checks just fine, but my calls to wget::fetch and archive::untar both fire
during every apply. Specifically, archive::untar takes about 30 seconds to
run and I'd prefer it if it only ran conditionally.
What is the best way to make sure that this code:
wget::fetch { python-${version}:
source =
http://python.org/ftp/python/${version}/Python-${version}.tgz;,
destination = /tmp/Python-${version}.tgz,
}
archive::untar {/tmp/python-${version}:
source = /tmp/Python-${version}.tgz,
compression = 'gz',
rootdir = Python-${version},
require = Wget::Fetch[python-${version}],
}
As you're discovering, these kind of exec chains, where the first part
of the chain involves temporary files, don't really fit into the puppet
paradigm very well. About the best you can do is something like
exec { '/usr/local/sbin/install-python-if-necessary.sh':
source = 'http://your_module/install-python-if-necessary.sh',
creates = '/your/python/lib/dir',
}
and then bury all the fetch/extract/configure/compile/install logic
in the shell script, which puppet will make certain is always present
on the system. It will only execute it if /your/python/lib/dir is not
present.
But if you're going to build fetch/extract/configure/compile/install logic
into a shell script, you're probably 85% of the way to packaging the
software appropriately anyway.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Have Class Only Perform Actions When There Is Work To Do (i.e. Making Them Idempotent)
In regard to: Re: [Puppet Users] Have Class Only Perform Actions When There...:
On Friday, October 26, 2012 2:31:56 PM UTC-4, Tim Mooney wrote:
In regard to: [Puppet Users] Have Class Only Perform Actions When There
Is...:
I would highly recommend you just package your custom python and install
it using a package management system, rather than doing what you're doing.
Depending on what host OS you're using, it's not too difficult, and it
works a lot better with puppet *and* you get all the benefits of having
the package installed through a more coherent means.
As you're discovering, these kind of exec chains, where the first part
of the chain involves temporary files, don't really fit into the puppet
paradigm very well. About the best you can do is something like
exec { '/usr/local/sbin/install-python-if-necessary.sh':
source = '
http://your_module/install-python-if-necessary.sh',
creates = '/your/python/lib/dir',
}
and then bury all the fetch/extract/configure/compile/install logic
in the shell script, which puppet will make certain is always present
on the system. It will only execute it if /your/python/lib/dir is not
present.
But if you're going to build fetch/extract/configure/compile/install logic
into a shell script, you're probably 85% of the way to packaging the
software appropriately anyway.
Interesting. It sounds like you're actually advocating _for_ the bash
script approach.
Absolutely not. I think the package management system is definitely the
way to go. If you're bound and determined to not do it that way, and
you want to avoid having the pre-cursor exec's fire in your
fetch/extract/compile chain, then the shell script is really your
best option.
Otherwise, the wget fetch will fire any time that
/tmp/Python-${version}.tgz is not present. That won't be present if
your /tmp cleaner gets rid of it. Ditto for the extract step.
I'm assuming that none of these systems are multi-user systems, where you
might have less-than-trustworthy people with local access on the system.
If that's not the case, I definitely wouldn't be having the first step
of a multi-exec chain depend on a file in /tmp.
I wanted to avoid package management systems only because
they are way more complicated than a basic install of python requires:
wget python.tgz
tar -xzvf python.tgz
cd python
./configure --prefix=/install/path
make
make test
make install
I wanted to make (I have made?) a simple python class that accepts a
python version number, downloads it, and runs those steps, irrespective of
the base Linux flavor. I don't know much of anything about deb or rpm files
other than that they are more complicated than that; and I don't want to
have to package up and maintain several different python versions for
several different package managers.
You don't have to create your package from whole cloth, though. You
download the source format for the package management system, extract
the recipe file, make a couple of changes for your local install, and
then build the package.
In the case of an RPM, that means starting with the source RPM (.srpm) for
the python that comes from your CentOS/RHEL/RHEL-derived vendor. You
would extract the spec file (the recipe), tweak the %_prefix, the
Version, and probably not much else.
If you're still against packaging it, there's external repos you might
consider, to get packages that someone else has created. That might not
meet your needs, though.
Ultimately, use puppet however it works best for your organization. Just
be advised that some things fit better into the puppet paradigm than
others.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Puppet Oracle Database config management
In regard to: Re: [Puppet Users] Puppet Oracle Database config...:
Have you got any examples of the hiera config you're using?
As I said, it's pretty rough.
class oracledb::sysctl(
$use_amm = false,
$large_mem_pages = '0',
$hugetlb_gid = '1001',
) {
validate_bool($use_amm)
validate_string($large_mem_pages)
validate_string($hugetlb_gid)
if ( $use_amm and ($large_mem_pages != '0')) {
fail(\$use_amm must be false when \$large_mem_pages is not 0\n)
}
#
# The basic settings that should always be present. Can be overridden
# via hiera().
#
# sem, default is '250 32000 100 128'
sysctl::set{'kernel.sem':
value = hiera('oracle_sysctl_sem', '250 32000 100 128')
}
# shmmni
sysctl::set{'kernel.shmmni':
value = hiera('oracle_sysctl_shmmni', '4096'),
require = Sysctl::Set['kernel.sem'],
}
# file_max
sysctl::set{'fs.file-max':
value = hiera('oracle_sysctl_file_max', '6815744'),
require = Sysctl::Set['kernel.shmmni'],
}
sysctl::set{'fs.aio-max-nr':
value = hiera('oracle_sysclt_aio_max_nr', '1048576'),
require = Sysctl::Set['fs.file-max'],
}
# ip local port range.
sysctl::set{'net.ipv4.ip_local_port_range':
value = hiera('oracle_sysctl_ip_local_port_range', '9000 65500'),
require = Sysctl::Set['fs.aio-max-nr'],
}
# network buffer defaults
sysctl::set{'net.core.rmem_default':
value = hiera('oracle_sysctl_rmem_default', '262144'),
require = Sysctl::Set['net.ipv4.ip_local_port_range'],
}
sysctl::set{'net.core.rmem_max':
value = hiera('oracle_sysctl_rmem_max', '4194304'),
require = Sysctl::Set['net.core.rmem_default'],
}
sysctl::set{'net.core.wmem_default':
value = hiera('oracle_sysctl_wmem_default', '262144'),
require = Sysctl::Set['net.core.rmem_max'],
}
sysctl::set{'net.core.wmem_max':
value = hiera('oracle_sysctl_wmem_max', '1048576'),
require = Sysctl::Set['net.core.wmem_default'],
}
sysctl::set{'vm.swappiness':
value = hiera('oracle_sysctl_swappiness', '0'),
require = Sysctl::Set['net.core.wmem_max'],
}
#
# Only if AMM is false and $large_mem_pages 0 do we set these
#
if (!$use_amm and ($large_mem_pages 0)) {
sysctl::set{'vm.nr_hugepages': value = $large_mem_pages }
#1001 is the dba group which the oracle user belongs to
sysctl::set{'vm.hugetlb_shm_group': value = $hugetlb_gid }
}
}
We've talked about having the sysctl class also make certain that
/dev/shm is mounted and of the appropriate size if $use_amm is true, but
that hasn't been done yet.
All of the other setup (limits.conf, paths, user, groups) happens in
oracledb::serverbase, which doesn't use hiera and is more or less specific
to our environment.
Tim
--
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.
Re: [Puppet Users] Puppet Oracle Database config management
In regard to: [Puppet Users] Puppet Oracle Database config management,...: My next challenge is maintaining Oracle database specific configuration on the relevant hosts. This contains various elements, such as /etc/oratab, /etc/oranfstab (as we're using dNFS), various NFS mounts required for a given database, and a few other bits and pieces... Ideally, it would be a 1-to-1 relationship between a given host and a given DB. However that's unlikely in our env - We're more likely to have 1 or multiple databases on a given host, which all need to be maintained. My initial thoughts are to use something like hiera to maintain this configuration data. Is this my best approach? Any other suggestions? Anyone doing this for real? We're doing it, but not particularly well. We mostly configure the prereqs for Oracle -- packages, user group, limits.d entries, profile.d shell settings, sysctl, paths, etc. We use puppet's file shipping for tnsnames.ora. I don't think we're actually managing /etc/oratab; the first run of puppetizing our db servers left some content that we allow the DBA to change directly. I am using hiera for the sysctl settings, along with a bit of logic in the manifest for whether AMM is in use or hugepages. We too have multiple databases per host, which complicates things somewhat. If you come up with something you feel is even moderately elegant, consider sharing it on the forge. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Managing untemplatable configuration files
In regard to: [Puppet Users] Managing untemplatable configuration files,...: So, does it make sense to store files with host specific configuration in them on the puppet master? Files that are either unable to be turned into templates, or that I don't know enough about the application to make templates. Or is there a better way? It's not the best way, but if it gets you started on puppet and helps you get to the point where your infrastructure is in a known state, then it's worth doing. It's definitely better than not managing the file content, and remember that that too is an option; you can manage just the permissions and existence, without managing the content itself. Learning puppet is kind of like software development. Some day you'll look back on your 1.0 version and think what was I thinking?!, but even knowing that's going to happen, you shouldn't get caught up in paralysis by analysis at the start. It's good that you want to do things elegantly or correctly even starting out, but don't let the lack of a perfect solution keep you from making any progress at all. Start with the simple stuff, like file-shipping entire config files where necessary, but keep learning and keep refining. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Re: The free software tarballs are now difficult to find
In regard to: [Puppet Users] Re: The free software tarballs are now...: The Products - Puppet Open Source link on the main page takes you here: http://puppetlabs.com/puppet/puppet-open-source/ where we promote getting the source from GitHub rather than tarballs directly from us. The reasoning has generally been that if you want to use Puppet, the best way of consuming it is via packages, and if you want to get the source, the best way of consuming it is via Git. There are certainly some benefits to GitHub, but my recurring gripe is that most software that's hosted on GitHub no longer seems to follow any notion of versions or releases. This makes packaging and local version tracking a bit more tricky. I see that you PuppetLabs folks are continuing to do a good job of tagging release versions, though. That's great news, and I certainly hope it continues. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] One client out of 150 doesn't apply config changes
In regard to: [Puppet Users] One client out of 150 doesn't apply config...: I have one puppet client that suddenly stopped applying configuration changes during the. I'm running with -v to see errors - no errors are shown and the puppet run completes with: info: Caching catalog for system name info: Applying configuration version '1349982313' notice: Finished catalog run in 49.28 seconds Does it change if you also add '--no-noop' to the puppet apply command? Is it possible someone modified /etc/puppet.conf and added 'noop = true'? Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] anchor pattern and class containment status
In regard to: Re: [Puppet Users] anchor pattern and class containment...: On Wed, Oct 3, 2012 at 2:57 PM, Tim Mooney tim.moo...@ndsu.edu wrote: All- We're currently using puppet 2.7.14 on master and all clients. I thought I understood why 'anchor' is part of stdlib, but after re-reading both http://projects.puppetlabs.**com/projects/puppet/wiki/** Anchor_Patternhttp://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern and http://projects.puppetlabs.**com/issues/8040http://projects.puppetlabs.com/issues/8040 yesterday in preparation for trying to explain it to one of our team that's coming up to speed on puppet, now I'm not so certain I really understand. yep, its probably the most confusing part of Puppet :( :-) I think I would vote for create_resources() in that competition. Specifically, is it necessary to use the anchor pattern if your module only defines resources and doesn't require or include any other classes? you only have to use the anchor pattern when you need to depend on a class that has classes defined in it. The example below does not need the anchor pattern. Thanks Dan! The info from you John Ryan has been very helpful. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] anchor pattern and class containment status
In regard to: Re: [Puppet Users] anchor pattern and class containment...: On Wed, Oct 3, 2012 at 2:57 PM, Tim Mooney tim.moo...@ndsu.edu wrote: I thought I understood why 'anchor' is part of stdlib, but after re-reading both I suspect Dan John have covered this well enough for you but I wanted to point out a nice piece of the Puppet reference manual that covers this. http://docs.puppetlabs.com/puppet/2.7/reference/lang_containment.html#known-issues Thanks Ryan, and thanks especially for the rewritten reference. I haven't been through all of it yet, but the parts I've seen are excellent. It explains things better than I ever could. If it's still not clear enough, please consider filing a ticket against our docs for improvement: https://projects.puppetlabs.com/projects/puppet-docs I created https://projects.puppetlabs.com/issues/16783 which mentions what I think might be a bug in the second example on that page and also asks for a little clarification. Thanks again for the pointer to the docs! Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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] anchor pattern and class containment status
All-
We're currently using puppet 2.7.14 on master and all clients.
I thought I understood why 'anchor' is part of stdlib, but after
re-reading both
http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern
and
http://projects.puppetlabs.com/issues/8040
yesterday in preparation for trying to explain it to one of our team
that's coming up to speed on puppet, now I'm not so certain I really
understand.
Specifically, is it necessary to use the anchor pattern if your module
only defines resources and doesn't require or include any other classes?
For example, if I have
class benthic {
group { 'squarepants':
ensure = present,
gid= '9',
}
user { 'spongebob':
ensure = present,
uid= '9',
gid= 'squarepants',
home = '/home/pineapple',
}
package { 'starfish':
ensure = present,
}
file { '/etc/starfish.conf':
ensure = file,
owner = 'root',
group = 'squarepants',
mode= '0640',
source = 'puppet:///benthic/starfish.conf',
require = [
Package['starfish'],
User['spongebob'],
],
}
service { 'i_m_ready',
ensure = running,
enable = true,
require = Package['starfish'],
}
}
Given that class, do I need to use anchors to ensure that the
group/user/package/file/service resource graph is correctly attached to
(contained within) Class['benthic'], so that if some other module does
someresource { 'whatever':
...
require = Class['benthic'],
}
it just works, or, should I augment my class to also have
anchor { 'benthic::begin': }
anchor { 'benthic::end': }
Anchor['benthic::begin'] - Group['squarepants']
Service['i_m_ready'] - Anchor['benthic::end']
?
My resources within the class are using explicit require when necessary
and relying on puppet's automatic require logic in other places so
they are correctly ordered, but it's not clear from the pattern document
in the wiki or the ticket whether the issue is solely with nested
classes, or whether it's important to also use the pattern for standard
resources.
Also, the ticket was with respect to 2.6. I know this hasn't changed for
2.7, but is there anything in 3.0 that addresses the issue?
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Puppet module dependencies
In regard to: [Puppet Users] Puppet module dependencies, DRivard said (at...:
I am having difficulties understanding how to get 2 modules to install one
after the other.
I have in total 3 modules:
common # contains everything common to the master and slave
configuration
slave # contains what is specific to the slaves config
master # contains what is specific to the masters config
node 'myslave1'
{
class {
common:
database = 192.168.1.10,
before = Class[slave];
}
class {
slave:
}
}
I am trying to tell the slave module to run after the common module is
totally applied, but it doesn't work like I am expecting. In the common
module
I set some repository and execute an update on the newly added repository.
But what happen is that, some slave package tries to get installed before
the common module complete the configuration of the repositories.
How can I achieve my goal?
I'm going to guess that the issue is this
http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern
Pay particular attention to the paragraph between the first two code
blocks. That spells out why the 'before = Class[slave]' that you're
using isn't doing what you want.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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] nested modules and autoloading
All-
I'm using puppet 2.7.14. I've reviewed
http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html
but it doesn't seem to cover what I'm attempting.
Consider a module layout like this:
$ tree mymodule
mymodule
|-- Modulefile
|-- README
|-- manifests
| |-- init.pp
| |-- special_type
| | `-- prereqs.pp
| `-- special_type.pp
|-- spec
| `-- spec_helper.rb
`-- tests
`-- init.pp
4 directories, 7 files
$ egrep -v '^#|^$' mymodule/manifests/init.pp
class mymodule($type = hiera('mymodule_type', 'client')) {
case $type {
'client' : { }
'custom' : { }
'special_type' : { include mymodule::special_type }
default : { fail(Unknown mymodule_type=${mymodule_type}\n) }
}
}
The problem is the include mymodule::special_type. I've tried both
having
mymodule/manifests/special_type/init.pp
as well as just
mymodule/manifests/special_type.pp
In both cases, doing this in a node definition:
class { 'mymodule':
type = 'special_type',
}
results in
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could
not find class mymodule::special_type for host.ndsu.edu at
/etc/puppet/modules/mymodule/manifests/init.pp:41 on node host.ndsu.edu
Is it even possible to do what I'm attempting? I know that
http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html
discusses nested implementation modules, but there's only examples of
loading specific implementations, e.g.
include my_module::implementation::foo
rather than
include my_module::implementation
I know from plenty of first-hand experience that another reason why I
might see a could not find class whatever is if I have a typo in the
class name within the .pp file, but I've reviewed the classes involved
here and don't see any problems.
Any thoughts on whether it's possible to load the top level of a nested
class?
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] nested modules and autoloading
In regard to: Re: [Puppet Users] nested modules and autoloading, Martin...:
Hi Tim,
please check your class and file names.
The following is working:
modules/http/manifests/init.pp
class 'http' {
include http::config_file
}
modules/http/manifests/config_file.pp
class http::config_file {
file { '/tmp/http':
content = 'http',
}
}
Martin-
I found the problem, and it was something simple.
I was originally confused because I had expected that
include mymodule::special_type
should work if I had
modules/mymodule/manifests/special_type/init.pp
but it does not. When I tried
modules/mymodule/manifests/special_type.pp
and that didn't work, I thought there was a general problem with
nested classes that I wasn't understanding.
The actual problem was that I hadn't committed
modules/mymodule/manifests/special_type.pp to our VCS. :-| Oops.
Thanks,
Tim
On 28.09.2012, at 12:53, Tim Mooney wrote:
All-
I'm using puppet 2.7.14. I've reviewed
http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html
but it doesn't seem to cover what I'm attempting.
Consider a module layout like this:
$ tree mymodule
mymodule
|-- Modulefile
|-- README
|-- manifests
| |-- init.pp
| |-- special_type
| | `-- prereqs.pp
| `-- special_type.pp
|-- spec
| `-- spec_helper.rb
`-- tests
`-- init.pp
4 directories, 7 files
$ egrep -v '^#|^$' mymodule/manifests/init.pp class mymodule($type =
hiera('mymodule_type', 'client')) {
case $type {
'client' : { }
'custom' : { }
'special_type' : { include mymodule::special_type }
default : { fail(Unknown mymodule_type=${mymodule_type}\n) }
}
}
The problem is the include mymodule::special_type. I've tried both
having
mymodule/manifests/special_type/init.pp
as well as just
mymodule/manifests/special_type.pp
In both cases, doing this in a node definition:
class { 'mymodule':
type = 'special_type',
}
results in
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could
not find class mymodule::special_type for host.ndsu.edu at
/etc/puppet/modules/mymodule/manifests/init.pp:41 on node host.ndsu.edu
Is it even possible to do what I'm attempting? I know that
http://docs.puppetlabs.com/puppet/2.7/reference/modules_fundamentals.html
discusses nested implementation modules, but there's only examples of
loading specific implementations, e.g.
include my_module::implementation::foo
rather than
include my_module::implementation
I know from plenty of first-hand experience that another reason why I
might see a could not find class whatever is if I have a typo in the
class name within the .pp file, but I've reviewed the classes involved
here and don't see any problems.
Any thoughts on whether it's possible to load the top level of a nested
class?
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: Module critique
In regard to: Re: [Puppet Users] Re: Module critique, Bai Shen said (at...: I strongly recommend that you build a native package for SOLR, put it in a local repository, and ensure it installed via a Puppet Package resource. Recursive directory management will bite you, especially if there are many files or large ones, plus using packages is in general a major win. You can package up your custom SOLR configuration files along with, or manage just those via File resources as you are now doing; either is fine. I'll take a look at that. I'm not really familiar with how to build rpms yet. The tomcat one was built using a file I found online. With Tomcat WAR files its generally pretty easy. We're actually not packaging SOLR but I have packaged other WAR files and could provide an example that you could adapt to SOLR pretty easily. Our lead developer just finished a SOLR deploy with puppet about a month ago, I'll see if I can get permission to share his module for you to compare to. One thing he did that I didn't see on first inspection with your solr module was he has a define so that we can have multiple solr cores. Right now it's all just using file shipping, though. We looked at templating some of the config but decided that was more advanced than what we wanted for our first solr roll-out. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Puppet visudo/ sudoers help
In regard to: Re: [Puppet Users] Puppet visudo/ sudoers help, Tony Caffe...:
I understand but that is not what I asked for help. I would like some help
on making or writing the code needed to add users to visudo.
$ cat puppet/modules/sudo/manifests/config.pp
define sudo::config($content='', $source='') {
case $content {
'': {
file {/etc/sudoers.d/${name}:
ensure = file,
owner = 'root',
group = 'root',
mode = '0440',
source = $source,
}
}
default: {
file {/etc/sudoers.d/${name}:
ensure = file,
owner = 'root',
group = 'root',
mode= '0440',
content = $content,
}
}
}
}
# vim:sm:ts=2:expandtab
Example usage for source:
sudo::config{ 'networker-jukebox':
source = 'puppet:///networker/networker_jb_sudoers',
}
Example usage for contents:
sudo::config{ 'myuser':
content = myuser ALL = (ALL) ALL\n
}
Note that both RHEL 5.x and 6.x have a sudo that supports the include
mechanism, but only RHEL 6.x ships with an /etc/sudoers.d and an
/etc/sudoers that has the include /etc/sudoers.d/* pre-populated.
Since both flavors support it, we just have our sudo init.pp make sure
the directory is present and make certain that the /etc/sudoers has the
necessary include statement. From then on, it's just puppet dropping
files into /etc/sudoers.d via the sudo::config() define.
The bad part about our current implementation is that there's no syntax
checking for the contents/source, so a bad entry can sneak in and cause
sudo to completely not work until it's fixed. There are ways around this
but it's more complicated than we felt like getting for now.
If you need to support systems where sudo is old enough that include
isn't even an option, then I highly recommend you look at the concat
module, and build up your sudoers file from file fragments.
Another option for older sudo versions that don't support including
fragments is using file_line from puppetlabs-stdlib.
Tim
On Wednesday, August 29, 2012 1:34:35 PM UTC-7, Ygor wrote:
First suggestion:
Use a group name ( like wheel ) and declare the sudo privileges to the
group.
Then all you need do is add that group in the groups parameter for
puppet type user.
On Aug 29, 2012, at 11:31 AM, Tony Caffe wrote:
Hi,
I am trying to get puppet going on CentOS 6.3 and I got it installed and
running. I want to create good manifests for basic stuff. I know I will
learn more as I go but I am new to programming in general and puppet code.
I have puppet master install on 1 cloud server and a client test puppet on
another cloud server. I was able to run this code correctly. Now I want to
make it better.
Here is what I have so far for my Push to add users to my nodes.
site.pp: (I know its short lol)
node 'puppet-client' {
import classes/adduser.pp
}
adduser.pp located in /etc/puppet/manifests/classes/
define custom_user($passwd) {
user { ${name}:
ensure = present,
password = $passwd,
shell = /bin/bash,
managehome = true,
}
}
custom_user {
anthony:
passwd = 'Removed real hash here',
}
custom_user {
admin:
passwd = 'Hash for password gone',
}
custom_user {
luca:
passwd = 'My Password Hash Here',
}
So I am testing on a test-only server till I get the hang of it. So I
have many cloud servers and need to be able to add my admin users. I need
help now to modify /etc/sudoers or visudo and add these people to the doc
with ALL=(ALL) ALL
Please help me. I know I need to add a template and also a module of my
own. I mainly need help with code and learning to build off this for future
system changes. Please help me keep this simple and dumb-down lol. FYI -
After this I want to start on Apache and editing the config and setting up
new servers from an image. This is more practical and important to start
with.
Thanks all.
--
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/-/k7r-BpgI4s4J.
To post to this group, send email to puppet...@googlegroups.comjavascript:.
To unsubscribe from this group, send email to
puppet-users...@googlegroups.com javascript:.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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
Re: [Puppet Users] Getting all variable occurrences from Hiera
In regard to: Re: [Puppet Users] Getting all variable occurrences from...: On Wednesday, August 22, 2012 6:01:06 PM UTC-7, Tim Mooney wrote: If I need to open a separate ticket to get that kind of directional clarity, I would be happy to do so. A ticket specifically about this use-case would be awesome. Thanks, Tim! http://projects.puppetlabs.com/issues/16107 Sorry about how the config ended up in that ticket, I didn't realize how it was going to be wiki-fied. I can update the ticket with fixed formatting if necessary. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] package handling in puppet?
In regard to: Re: [Puppet Users] package handling in puppet?, lamour said...:
Another, less gross, way to do it is to do something like this:
if !defined(Package['perl']) {
package { 'perl':
ensure = installed,
}
}
I would instead do something more like
file { 'your-unpackaged-perl-script-here.pl':
ensure = file,
owner = 'whomever',
group = 'ditto',
mode= '0whatever-whatever-whatever',
require = Package['perl'],
source = 'puppet:///module_name/script-source-here.pl',
}
So, I guess I don't understand this. Does this require not cause a
collision?
The answer is, it depends. I didn't include everything I should have
in that example, because you *still* need to have a
package { 'perl': }
somewhere *and* that needs to be either included from some other class
or it needs to be established in the same manifest.
Does this require cause the resource to become defined?
No it does not, that still has to happen elsewhere.
Can
you require more than one package?
Yes, and you can have multiple different resources that require the
same resource, e.g.
package { 'cricket':
ensure = installed,
require = [
Yumrepo['ndsu'],
Package['httpd', 'pmacct'],
User['cricket'],
],
}
package { 'flow-utils':
ensure = installed,
require = [
User['cricket'],
Mount['/var/netflow'],
],
}
I'll have to go read the documentation
to learn more about what this does, even though I don't think this helps
me, because I can't see how I could realistically tie all of my package
definitions to files.
My example was really meant for the case where you have one-off scripts
that are *not* installed via the OS package management system. As I said
before, you generally want to let the OS package management system handle
the dependencies as much as possible.
One more thing: if you search the archives, I think you'll find that
although defined() has its uses, it seems like the general feeling is
that it's somewhat overused, and used in cases where it really was not
intended. Your use of defined() might be perfect, but I just tend to shy
away from defined(), probably because my knowledge of puppet doesn't make
me certain that I would use it in the appropriate cases.
Thanks for all of your advice. It's nice to get a bit of perspective from
people who are already using puppet in the wild.
I'm hoping that other more experienced puppet users will weigh in on this
too, as I certainly am not expert enough yet to have all the answers for
this particular area.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: Getting all variable occurrences from Hiera
In regard to: Re: [Puppet Users] Re: Getting all variable occurrences from...: I'll comment in the ticket as well, I see you have, and you've closed it out. In Tim Mooney's example, which I think is the usual case for hiera data, hiera doesn't have an enumeration of all the 'type: client' nodes, nor should it. What I'm asking for (or at least, about) is indeed somewhat different than what Alexander was asking for. I'm a little surprised at the quick dismissal. It seems reasonable to me that since at least YAML supports data structures *and* puppet supports hashes and arrays and nesting of same, one might choose to design the configuration namespace for a particular class to use an actual data structure in hiera. I've been watching the list very closely for several months for any official statement from Puppetlabs folks about best practices with hiera data, and your statement is really the first I've seen. What you've said has a pretty clear implication: don't use nested data structures in hiera, because they're not going to work in the way that I think most people would expect them to work -- you can't merge different sub-keys from different parts of your hierarchy. In other words, we shouldn't use something like this: ntp: type: 'client' servers: - 10.1.2.3 - 10.1.2.4 allow_query: - '10.1.0.0/255.255.0.0' - '10.2.0.0/255.255.0.0' - '10.3.0.0/255.255.0.0' - '2001:4930::/:::' We should instead use: ntp_type: 'client' ntp_servers: - 10.1.2.3 - 10.1.2.4 ntp_allow_query: - '10.1.0.0/255.255.0.0' - '10.2.0.0/255.255.0.0' - '10.3.0.0/255.255.0.0' - '2001:4930::/:::' You could pretty easily write a custom parser function to return the data structures you want. Perhaps if I was as adept in ruby as many of the Puppetlabs employees, that would be pretty easy, but unfortunately I'm not. I do appreciate the response! It's really nice to know the thoughts of the people that are the experts on this. It helps me to plan the direction for our environment. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Getting all variable occurrences from Hiera
In regard to: Re: [Puppet Users] Getting all variable occurrences from...: Now I really think we're talking about different things, because this data design seems quite reasonable and I agree that merging a various intermediate keys from a nested data structure ought to work. Indeed this seems like something that is back-end dependent, i.e. a different yaml backend could behave exactly this way behind the scenes when you request the 'ntp' hash for a node, without needing a different hiera_* function at all. Agreed. So I guess I should ask, Alexander did I misunderstand what you were asking about in #16003? My impression is that you understood #16003 correctly, and that the use-case I was asking about is in reality different. I hope Alexander chimes in to confirm or refute that, but I think we're asking about things that seem related but aren't. Keep in mind that I'm not saying I think hiera *must* work the way I've described, I'm just asserting that I can see people potentially thinking it would work that way and I can see some potential benefits to having it work that way. What I'm really asking for, more than anything, is a stance from the designers and architects saying either bad idea, don't do it or yeah, should work and we're not opposed to it. If I need to open a separate ticket to get that kind of directional clarity, I would be happy to do so. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Dynamic Lookup of facter variable.
In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable., Nigel...: It's one of those things that I wish I had known before I spent hours changing our modules in preparation for what I thought was going to be a requirement for puppet 3.x, but better late than never. :-) I appreciate the clarity you've provided on this. I do apologize for us messing up the deprecation warning. It's caused a lot of unnecessary churn for everyone, and it's frustrating for everyone involved :( puppet's a moving target, and I think that most people that follow the list understand that this kind of thing is going to happen on occasion, especially when a major release is in the works. I certainly do. The trick is going to be stamping out places where you must top-scope facts may have already crept into documentation or people's puppet idioms. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] package handling in puppet?
{
realize(Package['perl-Foo-Bar'])
}
That might be worth considering. We're not doing it that way, but
perhaps we should be.
So...what am I doing wrong? Does the puppet philosophy not really allow
for maintaining package lists in classes?
It does, but in my experience it should be done in a minimal fashion.
Specify the highest level dependency, and let the OS package management
system pull in the prereqs, rather than trying to repeat all of the same
relationships in your puppet classes.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] puppet-lint and 80 characters line limit?
In regard to: [Puppet Users] puppet-lint and 80 characters line limit?,...:
I'm getting lots of warning like this one from puppet-lint:
WARNING: line 67 has more than 80 characters
Now, I don't like warnings, so any idea how should I rewrite this line
for example, to void the warning?
package {'rpmforge-release':
ensure = '0.5.2-2.el6.rf',
provider = 'rpm',
source =
'http://apt.sw.be/redhat/el6/en/i386/rpmforge/RPMS/rpmforge-release-0.5.2-2.el6.rf.i686.rpm',
}
Is it possible to break links into two lines?
I asked the same question on May 21st, check the group archives for the
thread and some options. I believe the subject was linting manifests
with long lines.
My solution:
01:20 PM dogbert ~$ cat ~/.puppet-lintrc
--no-80chars-check
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Dynamic Lookup of facter variable.
In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable., Nigel...:
On Sun, Aug 19, 2012 at 8:00 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
Oh god that's ugly.
Yes it is, and it was an unwitting bug with the deprecation warning
that is resolved in later versions.
Facts were supposed to be able to be referenced as $factname without
throwing the deprecation warning in your release, it's been fixed in
later versions.
Can you expound on this, Nigel?
Are you saying that we do *not* need to reference facts as $::factname
in all our classes, not even in preparation for puppet 3.x? What if
we *are* referencing them that way, now?
Tim
On Sun, Aug 19, 2012 at 7:48 PM, Eric Shamow e...@puppetlabs.com wrote:
Facts exist at top scope, as indicated in the scoping doc several people have
referred you to on this list. Use $::ec2_instance_type
Sent from my iPad
On Aug 19, 2012, at 10:44 PM, Douglas Garstang doug.garst...@gmail.com wrote:
I don't get it...
if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
notice(NOT ALLOWED)
} else {
notice(ALLOWED)
}
2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
e/manifests/validate_server.pp:12 is deprecated. Support will be
removed in Puppet 2.8. Use a fully-qualified variable name (e.g., $
classname::variable) or parameterized classes.
Line 12 is the if statement. However, on the same client system...
[us1:i-16c5c050] root@testweb11:~# facter | grep ec2_instance_type
ec2_instance_type = m1.large
It's a facter variable. What's it complaining about?
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Dynamic Lookup of facter variable.
In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable., Nigel...: Facts were supposed to be able to be referenced as $factname without throwing the deprecation warning in your release, it's been fixed in later versions. Are you saying that we do *not* need to reference facts as $::factname in all our classes, not even in preparation for puppet 3.x? What if we *are* referencing them that way, now? There's no harm in going that extra mile and being explicit that you're looking at a top scope variable fact, rather than a local variable of the same name, so you can continue to reference them as $::factname if you would like to do so. Requiring that wasn't an original goal, as it was deemed too high a cost for the most common case to force that rather ugly syntax on everyone. It was a bug in the deprecation warning code. Does that help? It does help, thank you. It's one of those things that I wish I had known before I spent hours changing our modules in preparation for what I thought was going to be a requirement for puppet 3.x, but better late than never. :-) I appreciate the clarity you've provided on this. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Re: Getting all variable occurrences from Hiera
In regard to: [Puppet Users] Re: Getting all variable occurrences from...:
That yaml file should keep alle the specific params of that host. and
every other module should be able to take advantage of that information.
This is not only the case for dhcp, but for dns as well. and of course the
/etc/network/interfaces file of the host itself.
And to avoid needless redundancy of information, certain values should be
written into that file maximum once. so, the ipaddress for example must not
be written in some dns config yaml file as well. and in the hostname.yaml.
Should you decide to change the ipaddress, you definitely forget either the
bind or the dhcp config.
Certainly data duplication should be avoided, and that could be aided by
putting all information for each host into a single hash for that host.
Those per-host hashes could equally well (for this purpose) appear in
separate YAML files or all together as values in a larger hash in one YAML
file.
Agreed, for the original case.
However, the original suggestion matches closely with an issue I've run
into as well, which also had me thinking that something like hiera_all
(I was thinking it should be hiera_merge) would be needed.
Consider:
:hierarchy: - secure/fqdn/%{clientcert}
- fqdn/%{clientcert}
- secure/location/%{location}
- location/%{location}
- secure/common
- common
common.yaml:
---
ntp:
type: client
servers:
- 10.0.0.1
- 10.0.0.2
location/datacenter1.yaml:
ntp:
servers:
- 10.1.0.101
- 10.1.0.102
fqdn/clock1.example.com.yaml:
ntp:
type: server
Hopefully, the intent is relatively clear: the defaults for all systems
are to be an ntp client and to use ntp servers with the IP addresses from
the common.yaml, however everyone in location=datacenter1 should have
the list of servers overridden, and the one system with
fqdn=clock1.example.com should have its type=server.
As hiera currently works, I don't believe there's any way to merge these
types of nested data from multiple sources in the hierarchy. If I try
lookup ntp['type'] for any of the systems in location=datacenter1, it
will be empty, because type is not specified (duplicated) for the
location/datacenter1.yaml.
Because of this, what ends up happening is that you instead need to use
a flat namespace, so you design things like this
common.yaml:
ntp_type: client
ntp_servers:
- 10.0.0.1
- 10.0.0.2
location/datacenter1.yaml:
ntp_servers:
- 10.1.0.101
- 10.1.0.102
fqdn/clock1.example.com.yaml:
ntp_type: server
As I've said before on the list, this strikes me as a bit unnatural.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Override a file{} directive - is it possible?
In regard to: [Puppet Users] Override a file{} directive - is it possible?,...:
Maybe one of you can help with this. I have a class that's got a
file{} type directive in it. It populates /etc/security/limits.conf
with specific settings. I have a small handful of hosts where we want
to manage /etc/security/limits.conf manually. Is there a simple way
to tell puppet to exclude this file type just on those hosts, without
copying the entire class?
Is there a way that puppet can detect these particular hosts? For
example, is it true for all hosts that are in a particular datacenter,
or for which some class (or even user) is present?
I ask, because the way you would typically do what you're asking is to
either use facts about systems to trigger the don't manage
/etc/security/limits.conf logic, or to have your manifests key on
external configuration that you keep in something like extlookup(),
hiera(), or your ENC (external node classifier).
So, there are several ways to accomplish what you're looking for, but
which one is best depends on your needs and how you actually detect that
hostB shouldn't have limits.conf managed.
You don't say what version of puppet you're using, whether you're using
an ENC, or whether you're already using either extlookup() or hiera(),
so it's really difficult to suggest something that integrates well with
your current environment.
I can give you two examples from my environment, though.
We're using puppet 2.7.14 without an ENC (we have dashboard but don't
use it for ENC purposes), but we are using hiera. The absolute easiest
way (but likely *not* best) way to do this would be to do this with
a hiera setting like:
common.yaml:
---
manage_limits_conf: 'yes'
host1.example.com.yaml:
---
manage_limits_conf: 'no'
and then in your manifest that sets up limits.conf, just wrap with the
appropriate logic to check hiera() whether it should be managed or not.
A second example would be if you have a fact (probably a custom fact)
that could be used to determine the exact set of systems for which
limits.conf should not be managed. For example, we have a custom fact
(location) that returns the name of the datacenter a system is located in.
If you wanted all the systems in location=datacenter1 to not manage
limits.conf, then you could wrap your file{} resource in a conditional
that tests the fact.
Certainly vague answers to your question, but hopefully this gives you
something to go on. If it's not enough to go on, provide more information
about your environment. That will hopefully make it easier for someone to
suggest a method that works well for your environment.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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] how to resolve hostnames to IP addresses in templates
Environment: puppet 2.7.14 on both master and all clients. We're also
using puppetlabs-stdlib and hiera, if that matters.
I know this is really more of a ruby/erb question, but I've been searching
for a couple hours and haven't turned up anything relatively close to what
I'm trying to do, and I'm hoping someone here has had to do this and can
provide a suggestion for how to proceed.
I'm generating a configuration file from a template. The configuration
file will need to have IP addresses in it, but I would like to be able to
use either hostnames or IP adresses in the puppet config. This means
that I need to be able to resolve the hostnames and turn them into IP
addresses, probably in the template itself.
Basically, given something like this in puppet:
class foo::data {
$webfarm = {
http_servers = hiera('webfarm_http_servers', [
{
host = 'foo1.example.com',
port = '80',
},
{
host = 'foo2.example.com',
port = '80',
},
{
host = 'foo3.example.com',
port = '80',
},
]),
https_servers = hiera('webfarm_https_servers', [
{
host = 'foo1.example.com',
port = '443',
},
{
host = 'foo22.example.com',
port = '443',
},
{
host = 'foo99.example.com',
port = '443',
},
]),
}
}
I need my template to iterate over the http_servers and https_servers
arrays and resolve the values for the host key for each element.
Anyone have an example of how to do this in a template?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] how to resolve hostnames to IP addresses in templates
In regard to: Re: [Puppet Users] how to resolve hostnames to IP addresses...:
if you're using hiera, why not something like:
foo_data_webfarm_http_servers:
foo1.example.com: {
ip: '1.2.3.4',
port: '80',
}
foo2.example.com: {
ip: '2.3.4.5',
port: '80',
}
foo_data_webfarm_https_servers:
foo1.example.com: {
ip: '1.2.3.4',
port: '443',
}
foo2.example.com: {
ip: '2.3.4.5',
port: '443',
}
class foo::data {
include foo::params
file { 'foo.conf':
path = '/etc/foo.conf',
ensure = 'file',
content = template(foo_conf.erb),
mode = '0555',
}
class foo::params {
$webfarm_http_servers = hiera('foo_data_webfarm_http_servers', '')
$webfarm_https_servers = hiera('foo_data_webfarm_https_servers', '')
}
foo_conf.erb
% http_servers = scope.lookupvar('foo::params::webfarm_http_servers')
https_servers = scope.lookupvar('foo::params::webfarm_https_servers')
-%
#
# http servers
% http_servers.each_pair do |key, hash| -%
#%=key%
IPADDR= %=hash['ip'] %
PORT= %=hash['port'] %
% end%
#
# https servers
% https_servers.each_pair do |key, hash| -%
#%=key%
IPADDR= %=hash['ip'] %
PORT= %=hash['port'] %
% end%
% end%
Thanks for the fully-formed example Wolf. John's subsequent response
was spot-on as to why I would like to avoid duplicating the IPs in the
data structure. They won't change frequently, but at the same time,
I really don't want to have to manually duplicate and sync information
that's stored in our DNS.
I do have one follow-on question regarding your example, though.
Did you choose foo_data_webfarm_http_servers as the top level hiera
name for any particular reason, such as how hiera is going to work in
puppet 3 with parameterized classes?
I must admit that while I find hiera fantastic, I've really struggled
with how our complex data should be organized in hiera. I'm looking
forward to the hiera examples that Kelsey Hightower mentioned a couple
weeks ago on the list, but seeing examples like this in the interim is
really helpful and appreciated.
Tim
On Aug 9, 2012, at 3:38 PM, Tim Mooney tim.moo...@ndsu.edu
wrote:
Environment: puppet 2.7.14 on both master and all clients. We're also
using puppetlabs-stdlib and hiera, if that matters.
I know this is really more of a ruby/erb question, but I've been searching
for a couple hours and haven't turned up anything relatively close to what
I'm trying to do, and I'm hoping someone here has had to do this and can
provide a suggestion for how to proceed.
I'm generating a configuration file from a template. The configuration
file will need to have IP addresses in it, but I would like to be able to
use either hostnames or IP adresses in the puppet config. This means
that I need to be able to resolve the hostnames and turn them into IP
addresses, probably in the template itself.
Basically, given something like this in puppet:
class foo::data {
$webfarm = {
http_servers = hiera('webfarm_http_servers', [
{
host = 'foo1.example.com',
port = '80',
},
{
host = 'foo2.example.com',
port = '80',
},
{
host = 'foo3.example.com',
port = '80',
},
]),
https_servers = hiera('webfarm_https_servers', [
{
host = 'foo1.example.com',
port = '443',
},
{
host = 'foo22.example.com',
port = '443',
},
{
host = 'foo99.example.com',
port = '443',
},
]),
}
}
I need my template to iterate over the http_servers and https_servers
arrays and resolve the values for the host key for each element.
Anyone have an example of how to do this in a template?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North
Re: [Puppet Users] Re: how to resolve hostnames to IP addresses in templates
In regard to: [Puppet Users] Re: how to resolve hostnames to IP addresses...:
There's no way to do DNS lookups in a template with stock Puppet,
Thanks for confirming what my futile research seemed to be implying. :-)
but you can pretty easily write a custom function to do that for you. By
default, Resolv will use the settings in /etc/resolv.conf, so as long as
your nameservers are set up correctly on the puppetmaster, you shouldn't
run into any problems.
Try plopping something like this into
lib/puppet/parser/functions/get_ip_addr.rb in your module's directory:
a href=https://gist.github.com/3308273;https://gist.github.com/3308273/a
require 'resolv'
module Puppet::Parser::Functions
newfunction(:get_ip_addr, :type = :rvalue) do |args|
# Super sexy regex to match valid IPs
ip_addr_re =
/\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b/
hostname = args[0].strip
if hostname =~ ip_addr_re then return hostname end
begin
Resolv::DNS.open { |dns| return dns.getaddress hostname }
rescue Resolv::ResolvError
return ''
end
end
end
Then you can call it in your template file as ```scope.function_get_ip_addr```
and it will either return the IP address for a hostname, the unchanged IP
address for a valid IP address, and an empty string otherwise.
I'm not sure what your hiera() calls are supposed to return, but assuming
$webfarm ends up as a hash with keys http_servers and https_servers containing
an array of hashes with keys host and port, you could do something like this:
% webfarm = scope.lookupvar 'foo::data::webfarm' %
% webfarm['http_servers'].each do |server| %
%= scope.function_get_ip_addr server['host'] %:%= server['port'] %
% end %
Thank you for the excellent example! There are several things here that
I'm going to have to ponder for a while. I've seen scope.lookupvar before
but never personally had to use it, but the scope.function_functionname
is new to me.
Time to do some more reading and research, but what you've provided really
helps point me in the right direction.
Tim
On Thursday, August 9, 2012 1:38:14 PM UTC-7, Tim Mooney wrote:
Environment: puppet 2.7.14 on both master and all clients. We're also
using puppetlabs-stdlib and hiera, if that matters.
I know this is really more of a ruby/erb question, but I've been searching
for a couple hours and haven't turned up anything relatively close to what
I'm trying to do, and I'm hoping someone here has had to do this and can
provide a suggestion for how to proceed.
I'm generating a configuration file from a template. The configuration
file will need to have IP addresses in it, but I would like to be able to
use either hostnames or IP adresses in the puppet config. This means
that I need to be able to resolve the hostnames and turn them into IP
addresses, probably in the template itself.
Basically, given something like this in puppet:
class foo::data {
$webfarm = {
http_servers = hiera('webfarm_http_servers', [
{
host = 'foo1.example.com',
port = '80',
},
{
host = 'foo2.example.com',
port = '80',
},
{
host = 'foo3.example.com',
port = '80',
},
]),
https_servers = hiera('webfarm_https_servers', [
{
host = 'foo1.example.com',
port = '443',
},
{
host = 'foo22.example.com',
port = '443',
},
{
host = 'foo99.example.com',
port = '443',
},
]),
}
}
I need my template to iterate over the http_servers and https_servers
arrays and resolve the values for the host key for each element.
Anyone have an example of how to do this in a template?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
On Thursday, August 9, 2012 1:38:14 PM UTC-7, Tim Mooney wrote:
Environment: puppet 2.7.14 on both master and all clients. We're also
using puppetlabs-stdlib and hiera, if that matters.
I know this is really more of a ruby/erb question, but I've been searching
for a couple hours and haven't turned up anything relatively close to what
I'm trying to do, and I'm hoping someone here has had to do this and can
provide a suggestion for how to proceed.
I'm generating a configuration file from a template. The configuration
file will need to have IP addresses in it, but I would like to be able to
use either hostnames or IP adresses in the puppet config. This means
that I need to be able to resolve the hostnames and turn them into IP
addresses, probably in the template itself.
Basically, given something like this in puppet
Re: [Puppet Users] how to resolve hostnames to IP addresses in templates
In regard to: Re: [Puppet Users] how to resolve hostnames to IP addresses...: Did you choose foo_data_webfarm_http_servers as the top level hiera name for any particular reason, such as how hiera is going to work in puppet 3 with parameterized classes? I have no real knowledge of how that's going to work; I have been namespacing things based on what I felt made things very clear for people looking at the hiera values, and the templates. afaik there's no significant penalty for longish names, but it makes it a bit easier for me to ingest when looking through a gaggle of hiera parameters. Understood about the longish names and honestly that's what we're mostly doing with our hiera usage so far, but every time I look at my site's hiera setup, it strikes me as wrong, or at least not the best way. I've posted about this before, but when we converted from extlookup() to hiera(), we didn't really do any kind of data reorganization. As an example, we have things like nameserver_type: client primary_nameserver: 1.2.3.4 secondary_nameserver: 2.3.4.5 tertiary_nameserver: 3.4.5.6 All of that's fine, but since hiera supports structure, it strikes me as more elegant to do something like: nameserver: type: client addresses: - 1.2.3.4 - 2.3.4.5 - 3.4.5.6 etc. However, there are precious few examples of how to actually look up and reference nested data in hiera and the ones that do exist make it appear that it's much more complicated than just using the namespace via _ method that we're currently using. My hope is that some best practices and more examples with be part of some forthcoming documentation. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Re: A few questions about setting up Custom Facts
In regard to: Re: [Puppet Users] Re: A few questions about setting up...: I want to use puppetlabs-stdlib and /etc/facter/facts.d to create a set of local facts. Some of these facts come in variable quantities. I would like to stack these up into a delimited string. I can deal with that. On thing about your responses that puzzles me is the repeated mention of facts going from the agent to the master. What is that about, please ? I am looking at facts local to the agent. My understanding is that all the Magic Behind the Curtains about puppet happens on the agent. That part is at least partially incorrect. Catalog compilation happens on the master. This means that the master has to know all the facts for each client, so that it can correctly build the catalog. The client gathers the facts and ships them to the master, so the master can build a catalog and ship the final result back to the client for application. Note also that this means that all functions run on the master too. See: http://docs.puppetlabs.com/learning/agent_master_basic.html though I've actually seen better diagrams of the communication, that's the one I'm finding right now. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Could not evaluate: Could not retrieve information from environment production source(s) for one module, for other is ok
In regard to: [Puppet Users] Could not evaluate: Could not retrieve...:
class ntp {
if $is_virtual == 'false' {
package { 'ntp':
ensure = present,
}
service { 'ntp':
ensure = 'running',
enable = 'true',
hasrestart = 'true',
require= Package['ntp']
}
file { /etc/ntpd.conf:
owner = root,
group = root,
mode= 0644,
require = Package[ntp],
source =
puppet://$puppetserver/modules/ntp/files/etc/ntp.conf,
}
}
if $is_virtual == 'true' {
package { 'ntp':
ensure = purged,
}
}
}
Your indenting is a little strange, but I would start by using
notice/notify/fail or whatever you prefer to determine what is_virtual
actually is set to.
There was a thread about quoting and true/false a few months ago, search
the archives for that. I can't remember if the style guide was updated
with recommendations regarding quoting true/false, but that would also
be a place to look.
Try using yes/no (as strings) and checking for that in your class.
You may also want to run puppet-lint on your manifests, it's not perfect
but it will help catch a number of issues.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: The Puppet Way to handle slow resources? (newbie)
In regard to: [Puppet Users] Re: The Puppet Way to handle slow resources?...: Chris, I'll take a look at exported resources. I don't have a problem with MCollective per se, I just don't want to add a bunch of other software if there's a native puppet way to solve the problem. From what I've seen, Puppet itself isn't supposed to solve this problem, MCollective is. Agreed. My plan A right now is that when the slow-running service is up and running it will tell Puppet to run. I haven't really thought about how this would work for multiple instances of the slow-service, I'm pretty sure that's not a hard problem to solve though. I've only partially followed this thread so I don't know if someone else has already suggested this, but if the real issue is that the interaction between software, init script, and puppet isn't working correctly, then why not have puppet manage and use a wrapper init script? You keep the init script that came with the software, but instead of having puppet use that for start/stop/status, you write your own local-service or mycompany-service init script and have that script call the original script and augment the logic in start/stop/status/whatever to do whatever is needed to work correctly with puppet. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Re: groups dependencies at user creation
In regard to: [Puppet Users] Re: groups dependencies at user creation,...:
Thanks tim for answer me, The fact is $groups is an array, so when i
try something like this
--
Group[$groups] - User[$username]
user { $username:
comment = $email,
home= /home/$username,
shell = /bin/bash,
password = !!,
groups = $groups
}
--
I'd got :
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find resource 'Group[sudo]Group[admin]Group[deploy]'
for relationship on 'User[ppuser7]' on node casa
I was afraid that might be the case, but thought it was worth a try.
Does this work better:
$groups_as_array = split($groups, ',')
Groups[$groups_as_array] - User[$username]
? I have my doubts, but it's what I would try next.
Note that split() is part of the default set of functions that are part
of puppet. For more info on functions, see
http://docs.puppetlabs.com/references/stable/function.html
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] groups dependencies at user creation
In regard to: [Puppet Users] groups dependencies at user creation, eduardo...:
I'm trying to create new users members of some groups so it's need
to ensure they exist before user creation.
I have something like :
define updssh::add_user ( $email , $groups ) {
$username = $title
user { $username:
comment = $email,
home= /home/$username,
shell = /bin/bash,
password = !!,
groups = $groups
}
--
How to ensure groups dependencies at user creation ?.
If you were just talking about the user's default group, then it would
be one of the few cases where puppet establishes an ordering relation
for you automatically. In other words:
user { 'foo':
gid = 'bar',
}
automatically ensures that group 'bar' is present before user 'foo'.
I don't know if that same thing is true for supplemental groups, but if
it's not, I would first try using the - notation to establish ordering,
like this
Group[$groups] - User[$username]
Does that work for you?
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Nvidia driver install - condition for install
In regard to: [Puppet Users] Nvidia driver install - condition for install,...:
Hello all,
I'd like to use puppet to install an Nvidia driver on a local workstation.
I've written the following manifest for this puprpose:
class nvidia_driver {
# This will place the nvidia installer locally in /tmp. File is
pulled from puppet.
file { /tmp/NVIDIA-Linux-x86_64-295.53.run :
source =
puppet:///modules/nvidia_driver/NVIDIA-Linux-x86_64-295.53.run ,
ensure = present ,
}
# This will run the nvidia installer locally on the machine.
exec { /tmp/NVIDIA-Linux-x86_64-295.53.run -s -X --opengl-headers
--no-distro-scripts --force-tls-compat32=new : }
}
First, you probably want to set up an explicit ordering relation between
the file and the exec. Otherwise, you're relying on ordering that may
work, but only by chance.
Upon the initial run of the manifest on the target machine, everything
works great (although I do believe there is some room for improvement of
the code above; particularly on the exec portion) and the driver then gets
installed. The issue occurs on subsequent puppet runs on the same machine
and I'm getting the following error during my second puppet run from the
client:
err: /Stage[main]/Nvidia_driver/Exec[/tmp/NVIDIA-Linux-x86_64-295.53.run -s
-X --opengl-headers --no-distro-scripts --force-tls-compat32=new]/returns:
change from notrun to 0 failed: /tmp/NVIDIA-Linux-x86_64-295.53.run -s -X
--opengl-headers --no-distro-scripts --force-tls-compat32=new returned 1
instead of one of [0] at
/etc/puppet/modules/nvidia_driver/manifests/init.pp:12
It appears to me that the above error is occurring because the
nvidia_driver class is running on each subsequent run and since the driver
is already installed, I'm getting an exit status of 1 instead of 0, which
to my knowledge would be expected.
Right. The exec will fire every time. The way to fix this is to use
one of the attributes for exec. Most likely candidates are
unless = some command here
or
onlyif = some command here
Read the resource guide for exec and note that those two have opposite
senses.
Note that you probably *don't* want to use notify from the file and
refreshonly on the exec, because the file may get downloaded
semi-regularly (because it was cleaned from /tmp) but you don't want
the exec to fire every time the file is (re)downloaded.
The trick is finding the right command that can be used in the unless or
onlyif. That amounts to being able to determine, via some (potentially
compound) command, whether or not the driver is installed. So how do you
do that? Does it show up in an RPM list? Is there a /dev file that's
created? An area that exists in the /proc or /sys filesystem?
Let's pretend for the purposes of example that when the driver is loaded,
there's a /sys/device/class/graphics/nvidia directory that's created. If
that's the case, you could make your class look like
class nvidia_driver {
# This will place the nvidia installer locally in /tmp. File is
# pulled from puppet.
# if you have hiera, it would be even better to use it:
# $driver_version = hiera('nvidia_driver_version', 'fallback version here')
# might want to abstract the architecture too...
$driver_version = '295.53'
file { /tmp/NVIDIA-Linux-x86_64-${driver_version}.run :
source =
puppet:///modules/nvidia_driver/NVIDIA-Linux-x86_64-${driver_version}.run ,
ensure = present ,
}
# This will run the nvidia installer locally on the machine.
exec { 'install_nvidia_driver':
cmd= /tmp/NVIDIA-Linux-x86_64-${driver_version}.run -s -X --opengl-headers
--no-distro-scripts --force-tls-compat32=new,
unless = 'test -d /sys/device/class/graphics/nvidia',
}
File[/tmp/NVIDIA-Linux-x86_64-${driver_version}.run] -
Exec['install_nvidia_driver']
}
Be advised that's untested.
So, what I'd like to do is put some sort of condition that will look to see
if the driver is installed and if it is, the class nvidia_driver won't
run.
What I'm describing would still have the file resource fire every time
/tmp gets cleaned and you need to re-download the driver, but it wouldn't
cause the exec to happen unless then driver was detectable as not
available.
The real trick is detecting whether or not the driver is installed. Once
you figure out how to do that, the rest just falls into place.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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
Re: [Puppet Users] hiera questions
In regard to: Re: [Puppet Users] hiera questions, llow...@oreillyauto.com...:
On Thursday, June 28, 2012 2:04:09 PM UTC-5, R.I. Pienaar wrote:
- Original Message -
I would make facts on the nodes for these. Let say $role and $subrole
and then just use those in your hierarchy with %{role} and %{subrole}
thus allowing you to set variable for all those machines there.
That's simple enough, and the docs [1] for creating a custom fact are
mostly straightforward.
I would echo what others have said. Create some custom facts for
personalities or roles (and subroles, etc., if necessary) for your
systems, and have your hierarchy set to search based on those. We use:
:hierarchy: - secure/fqdn/%{clientcert}
- fqdn/%{clientcert}
- secure/location/%{location}
- location/%{location}
- secure/common
- common
Note that location is a custom fact for us, based on datacenter. You
could do something similar, just don't go crazy with the hierarchy levels.
The one thing I am unclear on, in the plugins in modules [2] document, it
says that if you are going to put your custom stuff in a module (such as in
their example, named 'custom') it says to follow the standard layout, and
that you have to have a manifests/init.pp.
If all that is actually in the thing is lib/facter/myfact.rb, what do I put
in the manifests/init.pp ? Is it enough for it to exist but be empty?
Yes it is.
You probably have some kind of base or our_site module already that
just does things like
include ntp
include admin_packages
include ssh
include syslog
etc. You could associate your custom fact(s) with that module by putting
them in the lib/facter directory for that module.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Hiera Tutorials
In regard to: [Puppet Users] Hiera Tutorials, Kelsey Hightower said (at...: I'm beginning the process of creating Hiera tutorials covering the following topics: *Beginner* - Getting Started with Hiera (drafthttps://github.com/kelseyhightower/hiera/blob/maint/1.0rc/add_getting_started_tutorial/docs/tutorials/getting_started.md ) - Understanding hierarchies, sources, and scope - Understanding answer resolution (array, priority, hash, resolution order, etc) - Hiera and Puppet - Using the parser functions and data bindings for parameterized classes *Advanced* - Hiera backends -- Creating new backends - Hiera parser functions -- Creating new hiera parser functions This is fantastic news Kelsey and I'm really looking forward to it. We've been using hiera with the community edition for about 6 months, and we're really happy with it, but we're really not using it to its full potential yet. One area where there's a dearth of documentation (and best practices recommendations) relates to how to namespace settings within hiera. What I mean is that when we converted from extlookup() to hiera, we took the easy route, so we now have stuff in hiera that looks like: nameserver_type: client nameserver_primary: XXX.YYY.ZZZ.AAA nameserver_secondary: XXX.YYY.ZZZ.BBB nameserver_tertiary: XXX.YYY.ZZZ.CCC Hiera would support something like nameserver: type: client servers: - XXX.YYY.ZZZ.AAA - XXX.YYY.ZZZ.BBB - XXX.YYY.ZZZ.CCC in other words, more complicated data structures. Both recommendations on whether or not that's a good idea *and* examples on how to successfully access the nested bits from within puppet would be appreciated. Advanced examples with create_resources() might also be useful. Thanks much, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] puppet node report
In regard to: [Puppet Users] puppet node report, hai wu said (at 3:04am on...: Is there a way to download latest node report log from puppet dashboard? There's a way to do just about anything, but before you write some complicated web screen-scraping code to get the report from the web interface of dashboard, consider just enabling additional report backends and instead pulling the data from there. There was a very good blog post about when puppet reports a few weeks ago, check it out for more information on other reporting backends that are available and how you might go about developing your own (perhaps one for a database). See http://puppetlabs.com/blog/when-puppet-reports-part-1/ Note also there's a part 2 that you'll want to check out. The most straightforward method would probably be to enable the yaml backend and just pull the data from there. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] can´t call custom fact
In regard to: [Puppet Users] can?t call custom fact, Spter said (at 6:46am...:
Both on puppetmaster and my node:
puppet.conf:
pluginsync = true
on my puppetmaster:
modules/system/manifest/init.pp:
file { /root/my_oc4j:
ensure = link,
target = /var/${::oc4j},
}
modules/system/lib/facter/oc4j.rb:
Facter.add(oc4j) do
ja
end
When i called on my node:
puppet agent --no-daemonize --onetime --ignorecache --verbose --noop
no error occurs, but the link looks like:
my_oc4j - /var/
So, when i modify the init.pp like:
file { /root/my_oc4j:
ensure = link,
target = /var/$oc4j,
}
The link looks like the same.
What does
facter --puppet oc4j
report? You may need to run that as root or via sudo to get your
custom facts.
If it doesn't output anything, then the problem is that facter isn't
getting the information you expect, so what it reports to the puppet
master is empty.
Next step would be to run
sudo puppet config print all | egrep fact
on the client in question. That should show a setting for factpath,
probably something like /var/lib/puppet/lib/facter.
Look in that directory. Does your oc4j.rb file exist in the directory?
If it does, then pluginsync is working correctly, but the code itself
isn't doing what you expect.
If it doesn't exist, then it's not getting synced down to the client(s)
correctly, so you'll need to debug why that is.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: advice on module/class refactoring for defines
In regard to: [Puppet Users] Re: advice on module/class refactoring for...: On May 24, 7:43 pm, Nan Liu n...@puppetlabs.com wrote: I would say include 'ldconfig' in define ldconfig::config, then the define is self contained, and you don't need remember include ldconfig everywhere. +1 That's all around the best available option. It's much nicer than the original version, even, because users don't have to separately include class 'ldconfig' before they can use the define. Agreed, that's something I was hoping to avoid. Thanks, Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] advice on module/class refactoring for defines
In regard to: Re: [Puppet Users] advice on module/class refactoring for...: Note the define for config() within the init.pp for ldconfig. That's now out of favor. Moving that define into it's own file in modules/ldconfig/manifests/config.pp is straightforward, but it leaves me with questions about where the exec should be. I would say include 'ldconfig' in define ldconfig::config, then the define is self contained, and you don't need remember include ldconfig everywhere. Thanks Nan. Not certain why that wasn't obvious to me before you pointed it out, but it's perfect. :-) Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] linting manifests with long lines
In regard to: Re: [Puppet Users] linting manifests with long lines, Nan Liu...: On Mon, May 21, 2012 at 11:55 AM, Tim Mooney tim.moo...@ndsu.edu wrote: All- I've been working through our local manifests with puppet-lint, trying to make certain we're as prepared as possible for puppet 3.x. I would like for our manifests to be warning-free. The class of warnings related to long lines has me questioning what the best practice is to avoid lines longer than 80 characters. You can use a variable to shorten it, but I don't know if that actually improves code clarity. As I suggested in my original email, in some cases it would be OK, but in many cases it wouldn't improve clarity and would cause other problems. There's some discussion about removing it from the recommendation: https://github.com/puppetlabs/puppet-docs/pull/68 Thanks for pointing that out. What I've ended up doing is just adding --no-80chars-check to my ~/.puppet-lintrc, to silence the warning. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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] advice on module/class refactoring for defines
All-
We have several modules that have defines within them that the style guide
(sections 11.1 11.4) and puppet-lint suggest should be in their own
file. I'm working on fixing them and have a question about how things
should be refactored.
A stripped down example:
The node:
node 'foo.bar.edu' {
include oracledb::instantclient
}
file modules/oracledb/manifests/instantclient.pp:
class oracledb::instantclient($version='11.1') {
include ldconfig
# other non-relevant stuff here
ldconfig::config { 'oracle-instantclient':
content = template('oracledb/instantclient.ld.conf.erb'),
}
}
file modules/ldconfig/manifests/init.pp:
class ldconfig {
exec { '/sbin/ldconfig':
refreshonly = true,
alias = 'ldconfig',
}
define config($content) {
file { /etc/ld.so.conf.d/${name}.conf:
ensure = file,
owner = 'root',
group = 'root',
mode= '0644',
content = $content,
notify = Exec['ldconfig'],
}
}
}
Note the define for config() within the init.pp for ldconfig. That's now
out of favor. Moving that define into it's own file in
modules/ldconfig/manifests/config.pp is straightforward, but it leaves
me with questions about where the exec should be.
- if I add a requires = Class['ldconfig'] to the file within the
config() define, I now have a circular dependency that puppet errors on.
- if I don't include the requires = Class['ldconfig'] but I'm careful
to keep the include ldconfig in every class that also uses
ldconfig::config, things work, but that seems like the wrong way to
do it, as it only works if I do both things, because of the implicit
dependency on the exec.
- I've tried moving the exec inside the define, like this:
file modules/ldconfig/manifests/config.pp:
define ldconfig::config($content) {
exec { '/sbin/ldconfig':
refreshonly = true,
alias = 'ldconfig',
}
file { /etc/ld.so.conf.d/${name}.conf:
ensure = file,
owner = 'root',
group = 'root',
mode= '0644',
content = $content,
notify = Exec['ldconfig'],
}
}
but that results in duplicate definitions of the exec:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Exec[/sbin/ldconfig] is already declared in file
/etc/puppet/modules/ldconfig/manifests/config.pp at line 6; cannot
redeclare at /etc/puppet/modules/ldconfig/manifests/config.pp:6 on node
foo.bar.edu
- I've considered giving the exec an alias that is unique per define,
e.g. something like
exec { '/sbin/ldconfig':
refreshonly = true,
alias = ldconfig-${name},
}
and then doing a 'notify = Exec[ldconfig-${name}]', but that too
seems pretty hackish, though it may be my fall-back position if
someone doesn't have a more elegant way to handle this.
Any thoughts on how this should be re-organized?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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] linting manifests with long lines
All-
I've been working through our local manifests with puppet-lint, trying
to make certain we're as prepared as possible for puppet 3.x. I would
like for our manifests to be warning-free. The class of warnings
related to long lines has me questioning what the best practice is to
avoid lines longer than 80 characters.
The two big offenders are URLs:
class foo {
yumrepo { 'some-repo':
baseurl =
'http://some-relatively-long-domain.com/some-path/centos$releasever/$basearch',
gpgcheck = '1',
descr= 'Some Yum Repository',
}
}
and obviously file resources:
class bar {
file {'/path/to/some/convenience/symlink':
ensure = file,
target =
'/path/to/some/unfortunately/extremely/deep/file/that/we/want/to/manage/with/puppet',
}
}
but even content can at times exceed 80 columns.
I know I could be creating variables to help with line length, a la:
class foo {
$url_base = 'http://some-relatively-long-domain.com'
$url_path = '/some/url/path'
yumrepo { 'some-repo':
baseurl = ${base_url}${url_path},
gpgcheck = '1',
descr= 'Some Yum Repository',
}
}
But that seems suboptimal, especially if there are things in the URL
(like $releasever/$basearch) that need to be preserved verbatim (they're
not puppet variables, they're for yum).
Is there a better way to break up long lines, perhaps a join function
I've missed that would allow me to do something like
class foo {
yumrepo { 'some-repo':
baseurl = join(
'',
'http://some-relatively-long-url.com',
'/some-path/centos$releasever/$basearch'
),
gpgcheck = '1',
descr= 'Some Yum Repository',
}
}
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] mixing source content (templates) in concat::fragment
In regard to: Re: [Puppet Users] mixing source content (templates) in...:
the file type in puppet does not provide a way to do this, so
unfortunately
the concat cant do it either - since its just relying on the file
type
Thanks R.I. (and thanks for concat). I guess I'll switch all of our
host-specific base fragments to be a templates, even when there's no
template code in them, and use
concat::fragment { 'firewall-base':
target = $firewall_config,
content = [
template(firewall/firewall-base.${::fqdn}.erb),
template('firewall/firewall-base'),
],
order = '01',
}
puppet does not support this either :)
what you'll get there is a concat of the 2 templates
Oh, that's quite disappointing. We'll need to completely rethink how
we're doing this.
Thanks again,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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] mixing source content (templates) in concat::fragment
All-
We're using puppet 2.7.11.
Our custom firewall module currently builds the RHEL
/etc/sysconfig/iptables (and ip6tables) from multiple fragments using
concat::fragment.
The base part of the firewall is constructed like this:
class firewall {
include concat::setup
$firewall_config = '/etc/sysconfig/iptables'
concat::fragment { firewall-base:
target = $firewall_config,
source = [
puppet:///modules/firewall/firewall-base.$fqdn,
puppet:///modules/firewall/firewall-base
],
order = '01',
}
concat::fragment {firewall-end:
target = $firewall_config,
content = COMMIT\n,
order = '99',
}
}
As you can see, we use source to look for a per-box custom firewall base
first, and then fall back to a stock firewall-base file fragment.
I want to modify this config so that the fall-back fragment comes from
a template, rather than a file fragment. The problem is that it appears
I can't do this:
concat::fragment { firewall-base:
target = $firewall_config,
source = [
puppet:///modules/firewall/firewall-base.$fqdn,
template('firewall/firewall-base.erb'),
],
order = '01',
}
When I try that, I get:
$sudo puppet agent --test --noop
info: Retrieving plugin
info: Loading facts in /var/lib/puppet/lib/facter/ipmi_product.rb
info: Loading facts in /var/lib/puppet/lib/facter/biosversion.rb
info: Loading facts in /var/lib/puppet/lib/facter/net_info.rb
info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
info: Loading facts in /var/lib/puppet/lib/facter/net_location.rb
info: Loading facts in /var/lib/puppet/lib/facter/pacemaker.rb
info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
info: Caching catalog for host.nodak.edu
err: Failed to apply catalog: Parameter source failed: Could not understand
source #
and then it spits out the file template.
Is there an easy way to mix, in one fragment, a source and a template,
as I'm trying to do?
It occurs to me that I could just pretend that all of our per-host
firewall-base.$fqdn files are instead templates, even if there's no
actual templating going on, and use something like:
concat::fragment { firewall-base:
target = $firewall_config,
content = [
template(firewall/firewall-base.$fqdn.erb),
template('firewall/firewall-base.erb'),
],
order = '01',
}
But that seems kind of hackish. Can anyone suggest a more elegant method,
or some syntax that I'm missing?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] mixing source content (templates) in concat::fragment
In regard to: Re: [Puppet Users] mixing source content (templates) in...:
All-
We're using puppet 2.7.11.
Our custom firewall module currently builds the RHEL
/etc/sysconfig/iptables (and ip6tables) from multiple fragments using
concat::fragment.
The base part of the firewall is constructed like this:
class firewall {
include concat::setup
$firewall_config = '/etc/sysconfig/iptables'
concat::fragment { firewall-base:
target = $firewall_config,
source = [
puppet:///modules/firewall/firewall-base.$fqdn,
puppet:///modules/firewall/firewall-base
],
order = '01',
}
concat::fragment {firewall-end:
target = $firewall_config,
content = COMMIT\n,
order = '99',
}
}
As you can see, we use source to look for a per-box custom firewall
base first, and then fall back to a stock firewall-base file fragment.
I want to modify this config so that the fall-back fragment comes
from a template, rather than a file fragment. The problem is that it
appears I can't do this:
the file type in puppet does not provide a way to do this, so unfortunately
the concat cant do it either - since its just relying on the file type
Thanks R.I. (and thanks for concat). I guess I'll switch all of our
host-specific base fragments to be a templates, even when there's no
template code in them, and use
concat::fragment { 'firewall-base':
target = $firewall_config,
content = [
template(firewall/firewall-base.${::fqdn}.erb),
template('firewall/firewall-base'),
],
order = '01',
}
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Optional values from Hiera (no default value)
In regard to: [Puppet Users] Optional values from Hiera (no default value),...:
Hello Puppet List,
I'm writing a module that should take an optional value and I want to
get it (amongst other places) from Hiera.
$repository = $::java_repository ? {
undef = hiera('java_repository')
default = $::java_repository,
}
hiera() can take a second argument which is the default you want to
supply if no data store provides a value. Before you ask, no, I don't
know where that's documented, but we've been using it for a while in
our puppet manifests and it has been mentioned on the list even today.
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types moving into Module
In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...: Todd, welcome and I feel your pain. Trust me, I pushed every way I could to use native packages as our module deliver mechanism. However we have some odd requirements that make things not work as well with RPM (or deb, or gems). Basically we need a mechanism to allow multiple versions installed into separate environments (paths on disk). You make a compelling argument for why this doesn't map well to native packaging tools. While it is possible to have multiple copies of an RPM installed simultaneously, it would be a kludge in this case. Something like pm2rpm and pm2deb is very likely something we'll need to make the lives of Puppet Users happy. Now that puppet has drug me into the ruby world, I've started down the path of RPM packaging of gems. gem2rpm helped me get started. Having something that works very similar to that would be a big help to those that are experienced with ruby gems. Whatever you choose, though, there needs to be a way for admins to query a client and find out - what puppet modules are installed - where each instance of the module is installed - what version is present in each instance Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Telly: Nagios types moving into Module
In regard to: Re: [Puppet Users] Telly: Nagios types moving into Module,...: If I wanted to use a secondary package management system, I could use gems or eggs or CPAN, but I don't. ;) +1. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Re: [Puppet Users] Need advice how to architect solution for /etc/resolv.conf
In regard to: [Puppet Users] Need advice how to architect solution for...: I'm having difficulty determining the best course of action how to implement /etc/resolv.conf on my RHEL5 hosts. Here's my requirements, IN ORDER OF PRECEDENCE: * All hosts, regardless of function, need /etc/resolv.conf * Dependiing upon which environment the host lives in (i.e. Facture $domain) this changes search paths and nameservers to use in /etc/resolv.conf * Any host defined as a 'DNS Server' should ignore environment specific settings and use nameserver of '127.0.0.1' * There are one or two one-off DNS servers that should have their own per-host settings which shall override all previous definitions. We're doing something like this, although I need to expand it to be a little bit smarter, but wouldn't setting something like --- named_type: client # or 'caching', 'secondary', 'primary' in your extdata/hiera/ENC and then using a selector in your class to pick which template to use for resolv.conf essentially solve all of this? The only things that need to change between these rules are the values of the search path and the list of nameservers. So I would like to use a single template for /etc/resolv.conf which simply plug in data available in variables accessible by the template You probably could do that, but I think the template will be more complicated this way. Selecting different templates based on what type of system it is makes the template simpler. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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.
Quoting 'true' and 'false' (was: Re: [Puppet Users] new user: need Conditional statement example within a file resource type)
In regard to: Re: [Puppet Users] new user: need Conditional statement...:
Obviously I had a syntax error here because case statement is not
happy within the resource.
That's why the documentation says to use a selector.
So, what's a recommended puppet way to do something like this? thx in
advance.
file {
somefile :
ensure = $hasfile ? {
true = present,
default = absent
},
source = puppet:///somefile,
owner = root,
}
Please note that true is not strictly equivalent to the bareword true
in the puppet language :)
Ah, perfect segue. I had been meaning to follow up to John Bollinger
when he earlier posted something similar that also had 'true' quoted.
I've been through the style guide and several other areas in the
documentation and I can't find any recommendations on whether it's better
to use bare
true
false
or whether it's better to quote them. This is specifically for use in
parameterized classes. For example:
foo.bar.edu.pp:
node 'foo.bar.edu' {
class {'rhel':
version = '5',
ipv6_enabled = true,
}
}
rhel/manifests/init.pp:
class rhel($version, $ipv6_enabled='default') {
include rhel::common
case $ipv6_enabled {
true: {
class {'network': ipv6 = true }
}
false: {
class {'network': ipv6 = false }
}
default: {
case $version {
'5': {
class {'network': ipv6 = false }
}
'6': {
class {'network': ipv6 = true }
}
default: { fail(only version 5 and 6 of rhel are currently supported)}
}
}
}
}
In other words, our default for RHEL 5 is ipv6 disabled, on RHEL 6 it's
ipv6 enabled, but the default can be overridden for either.
The problem is that we had to be very careful to make certain that we
didn't quote true or false in some places and leave them as barewords
elsewhere, or it just wouldn't work. Mixing quoted nonquoted gave us
unreliable and unexpected results.
This brings me back to the questions: where in the docs is this covered,
and what are the recommendations for whether we should (or shouldn't) be
quoting true false when passing them around into parameterized classes
and testing them in selectors?
Thanks much,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
Re: [Puppet Users] Re: hasstatus not working as expected
In regard to: [Puppet Users] Re: hasstatus not working as expected, Chad...: status) /sbin/iptables -L | /bin/egrep '^DROP+\s+all.*NEW\s?+$' /dev/ null I doubt this is the actual problem, but you could more portably and more correctly write that regex as '^DROP[[:space:]]+all.*NEW[[:space:]]*$' You don't need the + after the P, since you don't want to match things like DROP, and you don't need the ? or the + after NEW, since you're anchoring the end and there's therefore really no reason to use non-greedy matching. Your comment also mentions any amount of whitespace, which presumably includes 0 matches, hence the * instead of the +. Also, you should probably run (as you) env grep -i grep and see if something like GREP_OPTIONS is in your environment. # A string has to start with DROP then whitespace, then all, then anything, then NEW, then any amount of whitespace # For some reason iptables -L has a whitespace after NEW if [ $? = 0 ]; then echo iptables is running exit 0 else echo iptables is stopped exit 3 fi ;; ** Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- 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] augeas modify pam.d argument by relative position
All-
I've been using puppet (now 2.6.9) and augeas (now 0.7.2 + ruby-augeas 0.3.0)
for a few weeks and I'm a convert.
I'm trying to modify a particular argument to a particular entry in
the RHEL 6.1 /etc/pam.d/password-auth-ac file, and although I've come
up with a way that works, it's fragile. I'm hoping someone can suggest
a better way.
First, the line in question in /etc/pam.d/password-auth-ac is
authrequisite pam_succeed_if.so uid = 500 quiet
It's the third line in the auth section of that file. The problem
is that we have a few old-timers that have uids in the range 101-499, and
this line causes them problems on login via things like sshd.
In the past we would have scripted something in perl in our kickstart
%post script to switch that particular 500 to be 100.
Using this excellent past thread as a guide:
http://groups.google.com/group/puppet-users/browse_thread/thread/ab96038a5658ec98/cb0c0beb8cd5418b?lnk=gstq=augeas+%2Bpam#cb0c0beb8cd5418b
I can match the line in question in augtool with:
print /files/etc/pam.d/password-auth-ac/*[type = auth][module =
pam_succeed_if.so]
/files/etc/pam.d/password-auth-ac/3
/files/etc/pam.d/password-auth-ac/3/type = auth
/files/etc/pam.d/password-auth-ac/3/control = requisite
/files/etc/pam.d/password-auth-ac/3/module = pam_succeed_if.so
/files/etc/pam.d/password-auth-ac/3/argument[1] = uid
/files/etc/pam.d/password-auth-ac/3/argument[2] = =
/files/etc/pam.d/password-auth-ac/3/argument[3] = 500
/files/etc/pam.d/password-auth-ac/3/argument[4] = quiet
The problem is that 'uid', '=', and '500' are all separate arguments.
I can get puppet to apply my modification if I use an entry like this:
#
# RHEL 6 has a new PAM file that needs to have the nid for special
# users adjusted down from 500 to 100.
#
augeas { pam.d/password-auth-ac_uidfix:
context = '/files/etc/pam.d/password-auth-ac/*[type = auth][module =
pam_succeed_if.so]',
changes = [
set argument[3] 100,
],
onlyif = 'get argument[3] == 500'
}
But that only works if argument[1]=uid, argument[2]==, and
argument[3]=500. Ideally, my rule would find the position of uid in
the line, and then match only if position() + 2 = 500. I've tried
things like:
print /files/etc/pam.d/password-auth-ac/*[type = auth][module =
pam_succeed_if.so][argument[position()] = uid]
within augtool and that much works, but as soon as I try something like:
print /files/etc/pam.d/password-auth-ac/*[type = auth][module =
pam_succeed_if.so][argument[position()] = uid][argument[position() + 1] = =]
it fails to match.
Anyone have an idea how I can rewrite things so that the match isn't
dependent on the exact current order of arguments, and instead matches
relative to the position of a previous argument (uid) or pair of arguments
(uid and =)?
Any thoughts appreciated,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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.
