Re: [Puppet Users] Going to publish custom modules : Request for comments
On 15 May 2011 20:27, Matthias Saou
th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net wrote:
Dan Bode d...@puppetlabs.com wrote:
I have an implementation question:
1. Why are you doing the chkconfig exec:
exec { chkconfig ${title} on:
notify = Service[xinetd],
path = [ /sbin, /bin ],
onlyif = chkconfig --list ${title} | egrep -q 'off$',
}
why doesnt:
service { $title:
enable = 'true'
}
work for this?
Fair question. I'm guessing that I assumed initially that the xinetd
sub-services wouldn't work with the puppet provider. I'm now guessing
that I should do some testing again and simplify this accordingly.
Isn't the difference that IF the service doesn't exist then it won't fail,
whereas the standard service enable definition will need to service to
exist? Unless I'm missing something in the bigger picture, this is an area,
only doing stuff if the files are there to have stuff done upon them, where
puppet seems to fall short.
Thanks
Chris
--
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] Stopping two services at once
Is there a way to stop and disable two services in one declaration?
Currently I have this:
# Stop sendmail
service { sendmail:
ensure = stopped,
enable = false,
}
# Stop exim
service { exim:
ensure = stopped,
enable = false,
}
Is it possible to format that like this?:
service { disabledemail:
name = ['sendmail', 'exim'],
ensure = stopped,
enable = false,
}
Thanks,
Jonathan
--
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless VPN Team
IT Services
University of Bristol
--
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] Re: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
On May 14, 8:52 am, Simon J Mudd sjm...@pobox.com wrote: sjm...@pobox.com (Simon J Mudd) writes: john.bollin...@stjude.org (jcbollinger) writes: In fact, Puppet Labs's own recently updated style guide recommends against using extlookup(), though that position is controversial. I found the URL:http://docs.puppetlabs.com/guides/style_guide.html The extlookup() Function Modules should avoid the use of extlookup() in favor of ENCs or other alternatives. The statement is clear, but it would be nice to know the reasoning. That is if there's a problem with extlookup() then it would be good to know what it is. This may have been discussed elsewhere but it shouldn't be necessary to have to go and search for this. In the end I did.http://groups.google.com/group/puppet-users/browse_thread/thread/34e4... It is a good read. Now you know what I meant when I called Puppet Labs's style recommendation controversial. Personally, I remain unpersuaded that the recommended style is a good technical choice for most people, but I will not rehash the arguments that you have just read. However, from the discussion a few things strike me: 1. the use of parameterised classes is recommended heavily. I've just found out about this new feature inspite of using puppet for a long time. Hence many recipes that I'm using are not paremeterised and I have a large number of similar classes. This is certainly worth fixing but is quite a painful transition to make given the number of systems in use and the chance of creating heavy breakage during that change. So if you haven't used parameterised classes much that's the first thing that needs looking at. If you have a complex set of manifests that do not use parameterized classes, then I think it much safer to coalesce similar classes with the help of extlookup() than by attempting to switch to parameterized classes. There are a couple of important ways (other than parameterization itself) by which parameterized classes differ from non-parameterized ones, and the more complex your current manifests, the more likely these are to bite you if you parameterize existing classes. Note, however, that it is the use of extlookup() *as an alternative to class parameterization* that the style guide recommends against. Do not take it as a blanket recommendation against using the feature. Note also that another part of the Style Guide's approach is that classes should avoid including other classes. Although it may not be immediately obvious, that goes hand-in-hand with extensive use of parameterized classes. Do take that into consideration as you evaluate the Style Guide's recommendations. [...] if you already have working recipes perhaps and aren't using an ENC [, extlookup] gives you a way to clearly remove the conditional logic the recipes currently have. It's then a smaller step up to using an ENC if you want to go that way. For those that don't it still becomes reasonably clear where the configuration is parameterised and how/why that's done, so it's still a more flexible approach. I agree. Furthermore, I maintain that if you are not using an ENC, then parameterized classes offer few advantages to offset their disadvantages. Therefore, if you are not already using an ENC and do not want to switch to one right now, then extlookup() is the best generally available way to externalize your configuration's data. John -- 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] Stopping two services at once
On Mon, May 16, 2011 at 7:16 AM, Jonathan Gazeley
jonathan.gaze...@bristol.ac.uk wrote:
Is it possible to format that like this?:
service { disabledemail:
name = ['sendmail', 'exim'],
ensure = stopped,
enable = false,
}
I think you mean
service {[ 'sendmail', 'exim']:
ensure = stopped,
enable = false,
}
--
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] Stopping two services at once
On Mon, May 16, 2011 at 12:16:53PM +0100, Jonathan Gazeley wrote:
Is there a way to stop and disable two services in one declaration?
Currently I have this:
# Stop sendmail
service { sendmail:
ensure = stopped,
enable = false,
}
# Stop exim
service { exim:
ensure = stopped,
enable = false,
}
Is it possible to format that like this?:
service { disabledemail:
name = ['sendmail', 'exim'],
ensure = stopped,
enable = false,
}
Are you trying to have simultaneous stoppage or just save typing? You
can achiev the latter by
service { [ 'sendmail', 'exim' ]:
ensure = stopped,
enable = false,
}
--
Bruce
What would Edward Woodward do?
--
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] Should puppet manage its own client configs?
Hi Chris, We have configured puppet to manage its own puppet.conf on clients, and to ensure that puppetd is running on all hosts. However it does not manage puppet.conf on the puppetmaster, so if we accidentally mess up the config, we won't break the puppetmaster. The hostname of the puppetmaster is hard-coded, in our case. Can anyone think of a better way of identifying the puppetmaster, so our manifests will run anywhere, if we decide to make a different machine the puppetmaster? Cheers, Jonathan Jonathan Gazeley Systems Support Specialist ResNet | Wireless VPN Team IT Services University of Bristol On 05/16/2011 05:09 PM, Chris Phillips wrote: Hi, Is there a general feel on whether puppet should look after its own client configuration files and service status? I'd not foresee problems about a service ensure enabled for puppetd and a file object for the puppet.conf but clearly wouldn't want to risk locking ourselves out of the clients from a bad config file being sent down etc. Thanks Chris -- 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. -- 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] Should puppet manage its own client configs?
On Mon, May 16, 2011 at 3:14 PM, Jonathan Gazeley
jonathan.gaze...@bristol.ac.uk wrote:
The hostname of the puppetmaster is hard-coded, in our case. Can anyone
think of a better way of identifying the puppetmaster, so our manifests will
run anywhere, if we decide to make a different machine the puppetmaster?
I just refer to the puppetmaster as 'puppet' everywhere and drop an
entry in /etc/hosts for it. Then if I wanted to migrate off a server,
I would just hardcode away $servername and $serverip on the old
puppetmaster to point to the new one, and copy the certs over.
node default {
case $fqdn {
/puppetmaster/: {
host { puppet:
host_aliases = [ localhost.localdomain, puppet ],
ip = 127.0.0.1,
name = localhost,
}
}
default: {
host { puppet:
host_aliases = $servername,
ip = $serverip,
name = puppet,
}
}
}
}
--
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] Uninstalling the puppet source?
I'm installing puppet from git per instructions in another thread. The instructions given at http://docs.puppetlabs.com/guides/installation.html for installing puppet from source lead to it dumping things all over my Ruby, which I really wasn't expecting and doesn't work well with our environment. (1) How do I uninstall it? (2) How do I turn the git source into a gem? Thanks. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which this parrot is dead is ti poi spitaki cu morsi, but this sentence is false is na nei. My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: I'm installing puppet from git per instructions in another thread. The instructions given at http://docs.puppetlabs.com/guides/installation.html for installing puppet from source lead to it dumping things all over my Ruby, which I really wasn't expecting and doesn't work well with our environment. (1) How do I uninstall it? (2) How do I turn the git source into a gem? Figured (2) out; still wondering about the other. I have all the install output, so I can just rm everything, but I'm assuming there's something cleaner than that? -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which this parrot is dead is ti poi spitaki cu morsi, but this sentence is false is na nei. My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:50, Robin Lee Powell rlpow...@digitalkingdom.org wrote: On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: I'm installing puppet from git per instructions in another thread. The instructions given at http://docs.puppetlabs.com/guides/installation.html for installing puppet from source lead to it dumping things all over my Ruby, which I really wasn't expecting and doesn't work well with our environment. (1) How do I uninstall it? Sadly, the Ruby install tools don't provide any useful mechanism for this. For better or worse, we just use those, rather than building something else on top. (...although if someone identified a mechanism that we could just pick up and use that would solve this we would totally integrate it.) (2) How do I turn the git source into a gem? Figured (2) out; still wondering about the other. I have all the install output, so I can just rm everything, but I'm assuming there's something cleaner than that? Not that I am aware of. Good for you, saving the output, too. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman dan...@puppetlabs.com ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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] Should puppet manage its own client configs?
On 16 May 2011 20:14, Jonathan Gazeley jonathan.gaze...@bristol.ac.ukwrote: Hi Chris, We have configured puppet to manage its own puppet.conf on clients, and to ensure that puppetd is running on all hosts. However it does not manage puppet.conf on the puppetmaster, so if we accidentally mess up the config, we won't break the puppetmaster. This seems a logical thing to do to me, I'll want to be able to turn on archive_files sometimes, that's one angle I'm keen on. Would be useful to separate the server and client config files though really, then it wouldn't be irresponsible to manage the client side of the master server separately. The hostname of the puppetmaster is hard-coded, in our case. Can anyone think of a better way of identifying the puppetmaster, so our manifests will run anywhere, if we decide to make a different machine the puppetmaster? Well yeah, just make puppet a cname and set the certificate name used on the master part of puppet.conf correctly. for this side of things, the client config is totally default, and it just goes to puppet via DNS, works perfectly, and I can easily rebuild a server an point the puppet cname to hit it. zero config on that side. Cheers Chris -- 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] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:54:02PM -0700, Daniel Pittman wrote: On Mon, May 16, 2011 at 12:50, Robin Lee Powell rlpow...@digitalkingdom.org wrote: On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: (2) How do I turn the git source into a gem? Figured (2) out; still wondering about the other. I have all the install output, so I can just rm everything, but I'm assuming there's something cleaner than that? Not that I am aware of. Good for you, saving the output, too. Oh, I didn't, it's just that my .screenrc defaults to 50K lines of backscroll. :D -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which this parrot is dead is ti poi spitaki cu morsi, but this sentence is false is na nei. My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Puppet fails first run
Hey all...new to puppet, but desperately pushing it on everyone I see
around me :)...
I'm running into a relatively minor issue that keeps puppet from
properly completing its first run. Subsequent runs do not have these
issues, and I'm confused why. It appears to be looking for a different
repo's file... First run will create our local.repo file, but log an
error on a totally different file that causes subsequent yumrepos to
be skipped:
CentOS log:
notice //puppet-test-c64//File[RPM-GPG-KEY-xxx]/ensure defined content
as '{md5}b954c7d56ed699642484d8f2a82f4338'
notice //puppet-test-c64//Stage[pre]/Repo/Exec[yum_xxx_gpg]/returns
executed successfully
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/descr
descr changed '' to 'CentOS-$releasever - Local'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/baseurl
baseurl changed '' to 'http://reposerver/centos$releasever-$basearch/
RPMS.local/'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/enabled
enabled changed '' to '1'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/gpgcheck
gpgcheck changed '' to '1'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/gpgkey
gpgkey changed '' to 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-xxx'
err //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo] Could not
evaluate: No such file or directory - /etc/yum.repos.d/addons.repo
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
Plus] Dependency Yumrepo[local.repo] has failures: true
warning //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
Plus] Skipping because of failed dependencies
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
addons] Dependency Yumrepo[local.repo] has failures: true
warning //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
addons] Skipping because of failed dependencies
I'm running puppet 2.6.6, and the problem is happening in the 'pre'
runstage defined in site.pp as such:
# Run Stages
stage {
'pre': before = Stage['main'];
}
class {
'repo': stage = 'pre';
}
---
Class 'repo' includes mostly yumrepo declarations to use our local
repositories (and execs to import keys). The local-only repo
(local.repo) should be created first, then all other repos. Class
'repo' is defined as such:
class repo {
package { ['yum','rpm']:
ensure = present,
}
package { 'yum-priorities':
ensure = present,
require = Yumrepo['local.repo'],
}
# Download and import Stern GPG RPM key
file { '/etc/yum.repos.d/':
ensure = directory,
}
file { 'RPM-GPG-KEY-xxx':
ensure = present,
path= '/etc/pki/rpm-gpg/RPM-GPG-KEY-xxx',
owner = 'root',
group = 'root',
mode= '0644',
require = Package['rpm'],
source = puppet://$servername/repo/RPM-GPG-KEY-xxx,
}
exec { 'yum_xxx_gpg':
command = '/bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-xxx',
unless = '/bin/rpm -qi gpg-pubkey-xxx',
require = [ File['RPM-GPG-KEY-xxx'],Package['rpm'] ],
}
case $operatingsystem {
centos: {
yumrepo {
'CentOS-Base.repo-base':
name = 'base',
baseurl= 'http://reposerver/centos$releasever-$basearch/
RPMS.os/',
enabled= '1',
descr = 'CentOS-$releasever - Base',
gpgcheck = '1',
gpgkey = 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist = 'absent',
require= Yumrepo['local.repo'],
notify = Exec['yum_clean_all'];
'CentOS-Base.repo-updates':
name = 'updates',
baseurl= 'http://reposerver/centos$releasever-$basearch/
RPMS.updates/',
enabled= '1',
descr = 'CentOS-$releasever - Updates',
gpgcheck = '1',
gpgkey = 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist = 'absent',
require= Yumrepo['local.repo'],
notify = Exec['yum_clean_all'];
'CentOS-Base.repo-addons':
name = 'addons',
baseurl= 'http://reposerver/centos$releasever-$basearch/
RPMS.addons/',
enabled= '1',
descr = 'CentOS-$releasever - Addons',
gpgcheck = '1',
gpgkey = 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist = 'absent',
require= Yumrepo['local.repo'],
notify = Exec['yum_clean_all'];
'CentOS-Base.repo-extras':
name = 'extras',
baseurl= 'http://reposerver/centos$releasever-$basearch/
RPMS.extras/',
enabled= '1',
descr = 'CentOS-$releasever - Extras',
gpgcheck = '1',
gpgkey = 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist = 'absent',
require= Yumrepo['local.repo'],
notify = Exec['yum_clean_all'];
'CentOS-Base.repo-Plus':
name =
[Puppet Users] apt-pinning puppet package management
Hello!
I have question about Debian package management with puppet. I'm
wondering is there sane way to make puppet respects packages pinning?
i.e., if I have several repos for one package, let's say it is nginx
which can be found in lenny lenny-backports repos. I've created
pinning file like:
Package: nginx
Pin: release a=lenny-backports
Pin-Priority: 600
So, if i have nginx installed from repository lenny , 'apt-get
install nginx' will update (if version is newer of course) nginx from
lenny-backports .
When I run puppet, it just ignores package available in pins, I guess
it thinks package already installed. Package is described like:
$packagelist = [ nginx ]
package { $packagelist:
ensure = installed,
}
Using latest is not the cure, because it will look only on version
(as i understand) and not on pins. I've found
https://github.com/evolvingweb/puppet-apt/blob/master/manifests/force.pp
which looks like something I need, but may be I'm missing something
and there is proper way to do this.
My puppet versions:
root@kappa2:~# dpkg -l|grep puppet
ii puppet 2.6.2-4~bpo50+1
Centralized configuration management - agent
ii puppet-common 2.6.2-4~bpo50+1
Centralized configuration management
root@kappa2:~# puppetd --version
2.6.2
OS - Debian Lenny amd64, puppet from backports.
P.S. Please, CC me on reply.
--
Best regards,
[COOLCOLD-RIPN]
--
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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
john.bollin...@stjude.org (jcbollinger) writes:
On May 14, 8:52 am, Simon J Mudd sjm...@pobox.com wrote:
However, from the discussion a few things strike me:
1. the use of parameterised classes is recommended heavily. I've just
found out about this new feature inspite of using puppet for a long
time. Hence many recipes that I'm using are not paremeterised and I
have a large number of similar classes. This is certainly worth fixing
but is quite a painful transition to make given the number of systems
in use and the chance of creating heavy breakage during that change.
So if you haven't used parameterised classes much that's the first
thing that needs looking at.
If you have a complex set of manifests that do not use parameterized
classes, then I think it much safer to coalesce similar classes with
the help of extlookup() than by attempting to switch to parameterized
classes.
Perhaps. To some extend my non-parameterised classes are _very_ similar
in many ways except for various parameters (creation of logical volumes
and filesystems, version of mysql to use, creation of certain cron jobs
for importing informtation into a configuration database, and other crons
for doing standard jobs, etc) Most of the completely common stuff
has been taken out. However, using extlookup() doesn't really work for
me right now for a simple reason I haven't yet mentioned. I'd further
like to have a lookup_by_key() function [let's say similar to the extlookup()
one provided now] but also a lookup_by_regexp() function where I can match
groups of boxes, in my case mainly based on regexps of their hostnames
rather than on specific $hostname, or $domain, etc Without that
I need to add more entries to match by lots of hostnames, which doesn't
work.
So I'd like something like
$mount_point = lookup_by_regexp( 'mount_point', $hostname, 'regexp_file', '' )
# parameters: lookup_item, lookup_value, regexp file to lookup, default
$lvsize = lookup_by_regexp( 'lvsize', $hostname, 'regexp_file', '' )
class db_lvconfig { db_lvconfig: mount_point = $mount_point, lvsize = $lvsize
} # note: other default parameters not shown like: owner, group, mode, vgname,
lvname
and have in the .csv file something like
mount_point,/dbservera/,/mount_point/for/servera
mount_point,/dbserverb/,/mount_point/for/serverb
mount_point,/dbserverc/,/mount_point/for/serverc
lvsize,/dbservera/,100G
lvsize,/dbserverb/,200G
lvsize,/dbserverc/,300G
Then if $hostname = 'dbservera-001'
it would get $lvsize = '100G', and $mount_point = '/mount_point/for/servera'
If I have 10 dbservera-xxx boxes then this keeps the config simple and the
.csv files much smaller.
There are a couple of important ways (other than
parameterization itself) by which parameterized classes differ from
non-parameterized ones, and the more complex your current manifests,
the more likely these are to bite you if you parameterize existing
classes.
Perhaps. for most of my cases I don't think that's the case. I'm
slowly adjusting the configuration of several classes to use
parameterised classes but even these still work nicely with
extlookup() alternatives such as the currently unimplemented
lookup_by_key() or lookup_by_regexp() alternatives I'm thinking of
using.
Note, however, that it is the use of extlookup() *as an alternative to
class parameterization* that the style guide recommends against. Do
not take it as a blanket recommendation against using the feature.
I'm not. You need to have a very considered mindset to build
_everything_ top down using an ENC and classes or globalvariables. If
using global variables as heavily as puppet seem to imply then ensuing
that you have a clear naming policy for this is quite important to
avoid unexpected name clashes (or mistakes) which might go unnoticed.
So I'd certainly like to see real world examples of complete
configurations to be fully convinced this works well. Perhaps after
moving a configuration to use extlookup() type mechanisms it then
becomes easier to make a further step up to get to the ENCs style
Puppetlabs reccommends. However, with system configuration being a
continual ongoing process I tend to think that a 100% ENC-only style
build using only parameterised classes is going to be a hard thing to
achieve in practice. And the global variables just don't convince me
yet. Perhaps I still have to see the light.
Note also that another part of the Style Guide's approach is that
classes should avoid including other classes. Although it may not be
immediately obvious, that goes hand-in-hand with extensive use of
parameterized classes. Do take that into consideration as you
evaluate the Style Guide's recommendations.
Hm.. well building bigger blocks from smaller ones tends to be a good
practice to follow, so this recommendation seems counterintuitive.
I'll have to lookup the section and see if they explain why, but guess
it's because the intention is you build your server in
Re: [Puppet Users] Re: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
- Original Message - john.bollin...@stjude.org (jcbollinger) writes: Perhaps. To some extend my non-parameterised classes are _very_ similar in many ways except for various parameters (creation of logical volumes and filesystems, version of mysql to use, creation of certain cron jobs for importing informtation into a configuration database, and other crons for doing standard jobs, etc) Most of the completely common stuff has been taken out. However, using extlookup() doesn't really work for me right now for a simple reason I haven't yet mentioned. I'd further like to have a lookup_by_key() function [let's say similar to the extlookup() one provided now] but also a lookup_by_regexp() function where I can match groups of boxes, in my case mainly based on regexps of their hostnames rather than on specific $hostname, or $domain, etc Without that I need to add more entries to match by lots of hostnames, which doesn't work. I think you're really trying to just avoid thinking in the puppet way instead trying to force some previous ideas on how things should work on it rather than figure out how it works. For example, you could just define a fact on your machines that indicate what role they have - perhaps based on your regex hostnames - and then use that in extlookup to select csv file to use. That would achieve your goal and it would be the puppet way of solving it. Puppetlabs reccommends. However, with system configuration being a continual ongoing process I tend to think that a 100% ENC-only style build using only parameterised classes is going to be a hard thing to achieve in practice. And the global variables just don't convince me yet. Perhaps I still have to see the light. ENCs can (now) pass parameters to param classes. So you dont have to do it all with global vars. Note also that another part of the Style Guide's approach is that classes should avoid including other classes. Although it may not be immediately obvious, that goes hand-in-hand with extensive use of parameterized classes. Do take that into consideration as you evaluate the Style Guide's recommendations. Hm.. well building bigger blocks from smaller ones tends to be a good practice to follow, so this recommendation seems counterintuitive. I'll have to lookup the section and see if they explain why, but guess it's because the intention is you build your server in terms of smallish components. +1, I think this is mostly down to the bad design in param classes - they really do not promote the use of many small classes that creates a larger module. Making modules harder to read and making dependencies harder to specify. -- 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] Should puppet manage its own client configs?
On Mon, May 16, 2011 at 4:08 PM, Chris Phillips ch...@untrepid.com wrote: Why the distinction between the two? What's wrong with using a LAN IP on the puppetmaster machine as well? To me that's much clearer that misusing loopback. I seem to recall doing that to allow a newly provisioned puppetmaster to bootstrap itself using puppet (instead of puppetd) and $servername and $serverip are not available for that initial run. -- 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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
Hi John, john.bollin...@stjude.org (jcbollinger) writes: ... Let's not cast things in terms of correctness, except insomuch as whether they reliably produce the desired effect on clients. Indeed. As always there is more than one way to solve a problem. Depending on what you're trying to do with Puppet, however, it is certainly true that some approaches to structuring your manifests will make them easier to write and maintain than will others. Personally, when writing specializations into my manifests, I find it useful to keep in mind the question of *why* a particular host or group of hosts is different from others. I have yet to run into an answer that didn't fall into one of these categories, or a combination of them: 1) It has a functional role that some other systems do not In my case 90% of the differences are functional differences, often expressed as part of the hostname. 2) Its network environment requires differences from some other systems. There may be some minor differences here but they are the exceptions rather than the rule. 3) It's just special I have a few of these too. It has worked well for me so far to model roles via (unparameterized) classes, assigned to nodes via their node declarations. That leaves only one level between common and node-specific where I might need to customize data. Yes, I have db_server::type_a and db_server::type_b, ... (That intermediate level could in principal be parameterized by network domain, but in my case it is by subnet.) Most of my nodes do not require per-node customization, so I don't end up with many data files for extlookup. In my case one db_server is pretty much similar to another one. Things vary such as mysql version to use (normally pretty constant), partitions to mount and their location(s), cron jobs to setup. All of these are lower level classes which are almost the same except for a few parameters. I also started with non-parameterised classes so created a large number of nearly duplicate classes and now I'm beginning to parameterise some of these the total number of classes should drop much more easily. Of course if I can lookup the parameters from a data source (extlookup or similar) then I can pretty much make many classes identical: all they do is pickup the required parameters and apply them. Moreover, I disagree with several of the opinions and conclusions in your post: 1) You write: The extlookup() functionality only allows [... specifying implicitly ...] where to look for this value. That is false. Extlookup does provide for configuration of a standard set of CSV files to search (which can be parameterized by nodes' facts), but the function also has an optional parameter to specify a specific file to be searched first on any given invocation. Perhaps coming from a database background, I'd like to mirror what seems more _natural_ and having values spread around over potentially a large number of files seems non-intuitive. If extlookup use would indeed require you to maintain a large number of separate files then that might be a good reason to find something better, but in all likelihood you can avoid that, or else structure it in a sane way. Consider also: When you work with a database, do you normally focus on how it maps data to the host filesystem? Focus no. Again as mentioned I try to simplify the structure by normalising it. Here I see I want to lookup a parameter ( say partition size ) from somewhere and I need to find it for a server called $hostname. If I can't find a parameter for $hostname, I may be happy if I find the same parameter for $domain, or if not I may be happy with some default value. _My_ preference is to look that up in one place. Also as mentioned in a different message, doing this lookup via a regexp might nicely enable me to keep the list of entries short. Given the diverse data parameterization you described, if you created a database for your configuration data, would you really organize everything into a single table? (And what would be its key?) yes: CREATE TABLE lookup_table ( config_item VARCHAR(200) NOT NULL, lookup_value VARCHAR(200) NOT NULL, return_value VARCHAR(200) NOT NULL PRIMARY KEY ( config_item, lookup_value ) ) SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'myhostname001' provides a fast lookup of the value. If that fails you can do SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'example.com' for a more generic response. If that fails you can do: SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'DEFAULT' Yes, I'm fully aware this could be normalised better but given the limited number of entries it's trivial to understand, trivial to maintain fast to access. The 3 SELECTs could be optimised into a _single_ more complex SELECT adding
Re: [Puppet Users] Re: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
r...@devco.net (R.I.Pienaar) writes: - Original Message - john.bollin...@stjude.org (jcbollinger) writes: Perhaps. To some extend my non-parameterised classes are _very_ similar in many ways except for various parameters (creation of logical volumes and filesystems, version of mysql to use, creation of certain cron jobs for importing informtation into a configuration database, and other crons for doing standard jobs, etc) Most of the completely common stuff has been taken out. However, using extlookup() doesn't really work for me right now for a simple reason I haven't yet mentioned. I'd further like to have a lookup_by_key() function [let's say similar to the extlookup() one provided now] but also a lookup_by_regexp() function where I can match groups of boxes, in my case mainly based on regexps of their hostnames rather than on specific $hostname, or $domain, etc Without that I need to add more entries to match by lots of hostnames, which doesn't work. I think you're really trying to just avoid thinking in the puppet way instead trying to force some previous ideas on how things should work on it rather than figure out how it works. For example, you could just define a fact on your machines that indicate what role they have - perhaps based on your regex hostnames - and then use that in extlookup to select csv file to use. That would achieve your goal and it would be the puppet way of solving it. Currently I build nodes.pp from an external source and that provides the node with it's basic class (and hence role). So that's not needed. One of the irritating things I see when we discuss puppet is the inevitable I can't describe my complete problem as it's [confidential] my site specific, so you can't have a full understanding of what I'm doing or why I'm doing it wrong, or provide me a precise, clear explanation of how better to solve my original problem. We talk in generics and that means we never fully understand each other. I guess the reasons are obvious but it's probably frustrating to us all. Nevertheless this thread I started has helped me clarify several things so I appreciate the time you've spent discussing them with me. Simon -- 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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
- Original Message - r...@devco.net (R.I.Pienaar) writes: - Original Message - john.bollin...@stjude.org (jcbollinger) writes: Perhaps. To some extend my non-parameterised classes are _very_ similar in many ways except for various parameters (creation of logical volumes and filesystems, version of mysql to use, creation of certain cron jobs for importing informtation into a configuration database, and other crons for doing standard jobs, etc) Most of the completely common stuff has been taken out. However, using extlookup() doesn't really work for me right now for a simple reason I haven't yet mentioned. I'd further like to have a lookup_by_key() function [let's say similar to the extlookup() one provided now] but also a lookup_by_regexp() function where I can match groups of boxes, in my case mainly based on regexps of their hostnames rather than on specific $hostname, or $domain, etc Without that I need to add more entries to match by lots of hostnames, which doesn't work. I think you're really trying to just avoid thinking in the puppet way instead trying to force some previous ideas on how things should work on it rather than figure out how it works. For example, you could just define a fact on your machines that indicate what role they have - perhaps based on your regex hostnames - and then use that in extlookup to select csv file to use. That would achieve your goal and it would be the puppet way of solving it. Currently I build nodes.pp from an external source and that provides the node with it's basic class (and hence role). So that's not needed. so if you just set a variable in the node scope you can use those in extlookup as I described - much simpler than writing an entire new type of function. And combine this with the optional paramter to extlookup that let you specify a search-first file and you get additional key/dimension you wish. Still, just write the functions you need - sounds like you know exactly what you want and its quite specific so just impliment it :) If its good and all, you can share it on forge.puppetlabs.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.
[Puppet Users] Plugins don't work the way I think they do?
Hi all,
I'm trying to configure a set of network interfaces, so I downloaded the
puppet-network module from the module forge. I enabled plugin sync per
http://docs.puppetlabs.com/guides/plugins_in_modules.htm and added the
module to my module path, but I'm getting an 'invalid resource type' error
indicating that the custom type included in the module isn't found. Can you
help me figure out what I've missed?
Puppet:
puppet --version
2.6.6
The error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid
resource type network_config at
/usr/share/puppet/environments/testing/modules/cluster/manifests/testcluster1.pp:35
The call:
class cluster::testcluster1 ($system_ip, $cluster_ip) {
include network
network_config { bond0:
type= Bonding,
bonding_module_opts = mode=6 miimon=100,
bootproto = none,
onboot = yes,
netmask = 255.255.255.0,
ipaddr = $system_ip,
}
network_config { eth0: master = bond0, slave = yes }
network_config { eth1: master = bond0, slave = yes }
} # class cluster::testcluster1
The module:
tree -fi network
network
network/COPYING
network/README.markdown
network/files
network/files/network-restart.rb
network/lib
network/lib/puppet
network/lib/puppet/provider
network/lib/puppet/provider/network_config
network/lib/puppet/provider/network_config/interfaces.rb
network/lib/puppet/provider/network_config/network_scripts.rb
network/lib/puppet/provider/network_interface
network/lib/puppet/provider/network_interface/ip.rb
network/lib/puppet/type
network/lib/puppet/type/network_config.rb
network/lib/puppet/type/network_interface.rb
network/manifests
network/manifests/init.pp
network/manifests/init.pp.example
network/spec
network/spec/unit
network/spec/unit/puppet
network/spec/unit/puppet/provider
network/spec/unit/puppet/provider/network_config
network/spec/unit/puppet/provider/network_config/network_scripts.rb
network/spec/unit/puppet/provider/network_interface
network/spec/unit/puppet/provider/network_interface/ip.rb
--
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] Fun with hashes and ERB
multipaths {
% devices.each do |key,value| -%
multipath {
wwid%= value %
alias %= key %
}
% end -%
}
On Tue, May 17, 2011 at 2:29 AM, Aaron Grewell aaron.grew...@gmail.comwrote:
Hi all,
I'm trying to figure out the intersection of hashes and ERB. I don't know
Ruby, so I put this together from examples available online and predictably
it generates an ERB syntax error. Can you point me in the right direction?
### Call:
class {'multipath':
devices = {
oradata01 = 360050768018280d1f8000193,
oradata02 = 360050768018280d1f8000194,
oradata03 = 360050768018280d1f8000195,
}
}
### Class:
class multipath ($devices) {
package { device-mapper-multipath: }
file { /etc/multipath.conf:
mode= 644,
content = template(multipath/multipath.conf.erb),
notify = Service[multipathd],
require = Package[device-mapper-multipath],
} # file
service { multipathd:
ensure = running,
enable = true,
require = Package[device-mapper-multipath],
} # service
} # class mapper
### Template (multipath.conf.erb):
defaults {
polling_interval30
failbackimmediate
no_path_retry 5
rr_min_io 100
path_checkertur
user_friendly_names yes
}
devices {
device {
vendor IBM
product 2145
path_grouping_policygroup_by_prio
prio_callout/sbin/mpath_prio_alua /dev/%n
}
}
multipaths {
% devices.each do |alias,wwid| -%
multipath {
wwid%= wwid %
alias %= alias %
}
% end -%
}
--
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.
--
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] Abstracting filebucket source?
I have two puppet configurations, one for the office and one for production. We have some directories in common (both for files and for classes) using SVN externals. So the format is like: puppet-common * files * classes puppet-prod * files * files/common - puppet-common/files * manifests * manifests/classes * manifests/common - puppet-common/classes puppet-office * files * files/common - puppet-common/files * manifests * manifests/classes * manifests/common - puppet-common/classes However, I'm now running into a situation where I want to have a file installed in the home directory of a user created in one of the common classes. I can define the source to match the puppet URL of one of the servers, but I'd rather dynamically generate that so it works on both environments. How can I reference the puppetmaster dynamically from inside the manifests? Thanks! -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community -- 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.
