Re: [Puppet Users] Help with hiera.yaml config
Hi Patrick, On 10/08/15 17:10, Patrick G. wrote: parameters: sudoroles: 'root_users' sudoroles: 'dba_users' That reads to me like you've overwritten the first sudoroles value with the second entry. If you want both, it would need to be e.g. an array: parameters: sudoroles: - 'root_users' - 'dba_users' ... with relevant logic in the module to handle an array. HTH, Greg. -- 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/55C94F97.4020405%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Status of Data in modules
Hi Fraser, On 02/04/15 19:56, Fraser Goffin wrote: Here's a simple example that works for me :- --snip-- Wonderful, thank you. Using your work plus https://github.com/zipkid/puppet3-hiera_data_in_module/tree/master/modules/test, I've got it working. I _think_ my only problem was that I was using a define - behaviour is different to classes. I wonder if that is on purpose. Greg. -- 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/552353D9.5040801%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Status of Data in modules
I've been trying to use the module_data module, but cannot get it to bring in values. Is there a worked example somewhere, including site.pp and hiera.yaml? https://github.com/zipkid/puppet3-hiera_data_in_module hasn't helped - I get the class defaults from init.pp, not the data from the yaml files. Cheers, Greg. -- 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/551117E8.6010702%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] User management
On 22/08/14 02:45, Garrett Honeycutt wrote: Here[1] is the code that I use to manage local users. You could use it for your scenario by placing users in different levels in Hiera and keying off the profile. Thanks, I'll give that idea a try and see if it works out any better for this setup. Cheers, Greg. -- 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/54041FCD.4040905%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] User management
How do people manage users? I'm slowly marching toward LDAP (someone
recently suggested FreeIPA, not sure if it's relevant), but trying to
stave it off for the time being. I've read a few blogs and posts on the
topic, but nothing clear comes out - except that if one gets too
complicated, one should move to a proper user management system!
I have a 'util::user' class to create individual users, and a
'users($profile)' class which uses 'util::user' to create sets of users
and groups.
If a group exists for a machine, then users who are assigned to that
group should be in it. Otherwise, they're not put in that group (because
that would give an error). I achieve this in 'users' with this code:
case $profile {
'profile1': {
$_management = 'management'
$_dataentry = 'dataentry'
$_users_grp = 'users'
$_accounts = 'accounts'
}
'profile2': {
}
'profile3': {
$_rel_m = 'releasemasters'
}
default: {
fail(Unsupported users profile ${profile})
}
then users are created with e.g.
util::user 'username' ...
groups = [$_users_grp, $_rel_m, $_dataentry]
and the util::user class strips out any undefs or blanks.
It all works quite nicely, but I'd like to clean up this last portion of
it with a nicer way of saying if the group exists (or is defined by
Puppet to exist) on this machine, and the user is to be put in this
group, then put the user in this group on this machine.
Any suggestions?
TIA,
Greg.
PS: I discovered tags the other day, and now use that in 'users' to
instantiate the right users and groups for a machine based on $profile.
Clean and easy to follow.
--
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/53F56B48.2030301%40calorieking.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Using Puppet to roll out Windows Updates
On 12/06/14 02:55, Brian Mathis wrote: Once you're operating in a Windows world, your life will be far better by doing things the Windows Way instead of resisting it. Unless it yields a natural path toward Windows machines and services proliferating despite you (perhaps) not wanting that. If you've a Samba domain controller and only enough Windows machines to satisfy actual need, then finding other methods can be quite useful. Incidentally, you typically wouldn't use Puppet to handle OS updates either (apt-get upgrade, yum update), which is the same thing, so it's not even a case of a Windows-specific thing. Related, but not directly on topic: We're getting good mileage out of Puppet performing our 'freebsd-update cron' for the core of our OS, and I'm currently implementing a system based on poudriere to build our packages, so that they can be maintained on nodes by Puppet. I never really thought I'd say it, but the more control I take over our FreeBSD infrastructure, the more I hope to be able to use it instead of GNU/Linux for a long time to come. Greg. -- 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/53990CEA.9090206%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: fail on first error. don't continue doing stuff
On 19/04/14 03:05, Alexander Gray II wrote: I wanted puppet to stop immediately on error so that I could manually go through Augeas and sniff around, but since puppet does a million-and-one things after the error, and it's unreproducible after puppet runs. I sometimes want that behaviour, but haven't found it. When I'm really keen to narrow down what's happening, I change the node (or role) definition and remove most of what it does, trying to get a 'full' Puppet run to still result in the failure but without a lot of what else is going on. -- 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/5355C77F.8050607%40calorieking.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Environments; function error
On 14/08/13 13:29, Gregory Orange wrote: We have two environments: production (containing one module) and experimental (two modules, one the same name as the module in production). All of our other modules are in the main module directory. Agent runs complete fine in the production environment, but not when switched to experimental. Error: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Unknown function sprintf at /usr/local/etc/puppet/modules/config/manifests/init.pp:54 on node hostname.network I guess from the silence here and on IRC that I'm on my own. It might be time for me to refactor to abandon environments all together, since they only play a relatively small part in our setup, useful though it is. -- 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] Environments; function error
Hi all, We have two environments: production (containing one module) and experimental (two modules, one the same name as the module in production). All of our other modules are in the main module directory. Agent runs complete fine in the production environment, but not when switched to experimental. Error: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Unknown function sprintf at /usr/local/etc/puppet/modules/config/manifests/init.pp:54 on node hostname.network I figured that perhaps the modulepath wasn't right, but it turns out sprintf is a core function: http://docs.puppetlabs.com/references/latest/function.html#sprintf Nothing in any of our modules implements or overrides sprintf, and sprintf is used in modules in the main module directory (i.e. by runs in both environments). May I have some help troubleshooting this problem? Thanks, Greg. -- 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] Managing classes of machines
Hi everyone, We've got a fairly small set of machines (perhaps 30) soon to be managed with puppet. We're looking for a good way to define which machines get which packages, and how those packages are configured on certain sets of machines. e.g. Apache on devel and production-webserver machines, but not on producation-db machines. Apache should be configured differently on devel machines compared to production-webserver machines. I've read a couple of conflicting opinions on this from mailing list archives (I think) pages on the puppetlabs website, and the Pro Puppet book, so I'm ignoring it all for the moment and asking for opinions here. TIA, Greg. -- Gregory Orange System Administrator CalorieKing Wellness Solutions Incorporated http://www.calorieking.com/ -- 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 provider for FreeBSD
On 29/06/12 14:38, Gregory Orange wrote: I've settled upon portupgrade as the best provider, since I can use it to build from the NFS mounted /usr/ports tree. Now I am experiencing a quirk when a package is to be newly installed: 'ensure = installed' or 'ensure = present' results in the package being installed as expected. http://pastebin.com/sdH8F7p1 'ensure = latest' yields no change. For the sample package net/rsync: http://pastebin.com/HsEaGDRa The key difference being on line 4 of the paste: installed: portinstall latest: pkg_info pkg_info is _not_ going to install the packages! Assistance on the IRC channel and references to two bugs indicate that ensure = latest doesn't work on FreeBSD. So I'll investigate some sort of uninstall-reinstall process when I want to push out upgrades. http://projects.puppetlabs.com/issues/show/14845 http://projects.puppetlabs.com/issues/show/5951 -- 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] freebsd ports config, cache distfiles
On 28/06/12 13:51, Gregory Orange wrote:
I have /usr/ports mounted via NFS from the puppet server.
1. For more complicated packages, a config dialogue comes up (i.e. cd
/usr/ports/category/port; make config). How do I automatically configure
that, with settings to my choosing?
I suppose I could push out the relevant /var/db/ports/port/options file
- is that recommended, or is there something better?
I have successfully depended upon a latest version of the options file
for my packages in testing, within the same package's class (sample
below[1]). I think this is sufficient for now, although it might get
curly when a single puppet package results in multiple FreeBSD
ports/package installations.
2. /usr/ports/distfiles/ doesn't always have the package files
available, especially if the given package isn't installed on the
server. This causes installation to fail. How should I go about
instructing the puppet server to cache those files? To do it manually:
cd /usr/ports/category/port; make fetch
Of course I don't want to do it manually!
I'm not sure I can expect puppet to perform the FreeBSD ports distfiles
management I want here, so I'll look into some script-based automation
that can pull down the distfiles as neeeded.
Cheers,
Greg.
[1]
class samplePackage {
package { 'category/samplePackage':
ensure = installed,
require = Package[ category/samplePackage-options ]
}
package { 'category/samplePackage-options':
ensure = latest,
require = File[ /var/db/ports/samplePackage/options ]
}
file { /var/db/ports/samplePackage: ensure = directory }
file { /var/db/ports/samplePackage/options:
ensure = file,
source = puppet:///modules/samplePackage/options
}
}
--
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 provider for FreeBSD
On 29/06/12 02:18, R. Tyler Croy wrote: On Thu, 28 Jun 2012, Gregory Orange wrote: Are there providers documented somewhere? I'm not sure where to The different package resource providers and their differences documented here: http://docs.puppetlabs.com/references/latest/type.html#package Great, thank you. I've settled upon portupgrade as the best provider, since I can use it to build from the NFS mounted /usr/ports tree. Now I am experiencing a quirk when a package is to be newly installed: 'ensure = installed' or 'ensure = present' results in the package being installed as expected. http://pastebin.com/sdH8F7p1 'ensure = latest' yields no change. For the sample package net/rsync: http://pastebin.com/HsEaGDRa The key difference being on line 4 of the paste: installed: portinstall latest: pkg_info pkg_info is _not_ going to install the packages! Can anyone help me with this? Cheers, Greg. -- 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] freebsd ports config, cache distfiles
Hi everyone, first post. I've got Puppet installed on a FreeBSD 8.3 client server from the guides, and deploying simple packages from the default node and a node which inherits it. I have /usr/ports mounted via NFS from the puppet server. I have two queries now: 1. For more complicated packages, a config dialogue comes up (i.e. cd /usr/ports/category/port; make config). How do I automatically configure that, with settings to my choosing? I suppose I could push out the relevant /var/db/ports/port/options file - is that recommended, or is there something better? 2. /usr/ports/distfiles/ doesn't always have the package files available, especially if the given package isn't installed on the server. This causes installation to fail. How should I go about instructing the puppet server to cache those files? To do it manually: cd /usr/ports/category/port; make fetch Of course I don't want to do it manually! Cheers, Greg. -- 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.
