[Puppet Users] Re: Module repository organization
Thanks for the discussion and suggestions, I'll have some reading to look forwards to it appears. In particular I'll look into Job Builder since that seems like it could slot into what we're building now with minimal effort(we're a little short on time at the moment). We're using R10k currently but without any granularity to speak of, the problem in general is that our module collection is a mix of things from the forge, some modified and some not, and we have quite a few home built modules as well, so granular control at a module level is a bit complicated. Regards Johan -- 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/e0144873-8039-4fcb-862d-3f332b5ea624%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Module repository organization
Hello, I'm just wondering how people with a decent collection of modules are organizing their modules and repositories? We currently have one big repository with everything in it, and three branches, basically stuff moves alpha - beta - production. This is nice and simple in a way, but has some obvious and not so obvious downsides. For one updating a module means going to the next branch and doing a checkout of that specific module from the previous branch so as to not just yank in every change made in the previous branch. This along with having just one big commit history for everything makes the git history pretty much useless. And we're now in the process of implementing Jenkins for CI, the lack of granularity is making this a bit of a headache(though this could very well be because we're complete newbies at Jenkins ;) . For example having a post-receive hook triggering a build in Jenkins, with one big repo this will trigger rebuilds of every module since they all subscribe to the same repo even though they're separate jobs. So, how are you people who have actually done this for a while managed this little problem? Separate repos per module? Something else we haven't thought of? Regards Johan -- 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/83ae6a7a-b372-408a-b143-8f00f8fdcafb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [Puppet Users] Re: Inheritance and parameterized classes
You are about to blow your foot off, or at least your little toe. You
cannot include a parameterized class twice, not even with the same
parameters, and certainly not with different parameters. That will
scuttle catalog compilation for node nfsserver.
If you abandon class parameterization then you can do this with class
inheritance, but the two do not work well together. The class
inheritance approach might look something like this:
class nfs {
include nfs::params, nfs::install, nfs::config, nfs::service
}
class nfs::service::enabled inherits nfs::service {
# Override Service['nfs'] to ensure it enabled and running
}
node basenode {
include nfs
...
}
node nfsserver inherits basenode {
include nfs::service::enabled
}
That looks good to me, easy to understand, which makes me feel stupid for not
thinking about it myself.
Alternatively, you can make basenode not include class nfs, leaving
the choice of class parameters to the more specific node types, but
then every one of them must include class nfs itself.
Or you could use external data, such as obtained via extlookup() or
hiera, to define whether nodes should be enabled as NFS servers. That
would not only allow you to dispense with class nfs's parameters, but
probably you could also drop node nfsserver.
Extlookup has been on my todo-list for a while, I just figured I'd try to get a
better feel for the basics before I go there.
In general (says me), you should avoid defining class parameters whose
purpose is to tweak the *meaning* of the class, such as your $client
and $server parameters. That sort of purpose is better served by
providing distinct classes. As a rule of thumb, do not define class
parameters whose values are not intended to end up as [part of]
resource property values. (That's supposing you have already decided
to ignore my maxim #1 of Puppet class parameterization: don't do it.)
I haven't really decided anything yet, I'm certainly not set on using
parameterized classes, I'm mostly trying to find the Right Way to do things.
Using external data to tweak the meaning of a class is at least better
than using parameters for the same purpose. It causes the same kind
of ambiguation of the class's meaning, but at least it doesn't
introduce the practical limitations that come with class
parameterization.
John
Thanks for the input, I'll see if I can make the first way you suggested
working, seems easy enough. :)
Oh and sorry for the mail formatting...Outlook...
Regards
Johan
--
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] Inheritance and parameterized classes
Hi.
I've been reading up on inheritance, parameterized classes and whatnot, and
basically wish to see whether I'm thinking right or if I'm just confused(more
than usual).
I'll use a trivial NFS module as an example since it should cover the basic
questions and has some interesting dependencies.
I have Debian and RedHat(including Scientific Linux, but I'll treat those the
same as RH) boxes, our standard setup disables NFS on these, the occasional box
might have it enabled.
On Debian an NFS server depends on three services, nfs-common,
nfs-kernel-server and portmap. The client depends on nfs-common and portmap.
On Redhat the server depends on nfs and rpcbind, the client on rpcbind. (I'll
note that this is to the best of my knowledge so far since RH didn't bother
documenting NFS particularly well for RHEL 6.x).
The goal is the usual(I would guess), a basic node config that has a baseline
of hardening, ideally I would use this for every other node unless I'm doing
something really different(say setting up a server with intentionally bad
hardening for testing purposes or something).
Nodes would then override this as needed.
I can think of a couple of ways to do this, but having read some of the
conversations on parameterized classes it seems like this is the way forward
and preferred by Puppetlabs. Basically I want to follow best practices and make
sure I make my setup as futureproof as I reasonably can.
I'm on 2.6.x right now but the less I have to rewrite when the time for 2.8 or
even 3.0 comes, the happier I'll be obviously. :)
So what I'm thinking is something like so for nodes:
nodes.pp
node basenode {
include nfs ( server=no, client=no )
...
}
node somebox inherits basenode {
...
}
node nfsserver inherits basenode {
include nfs ( server=yes )
...
}
The NFS module would look something like:
init.pp
class nfs::params {
OS detection and such.
}
class nfs::install {
install packages as needed, skip entirely pretty much if both server and
client are no.
}
class nfs::config {
configure as needed
}
class nfs::service {
start/stop services based on server/client=yes/no.
}
class nfs ( $server, $client ) {
include nfs::params, nfs::install, nfs::config, nfs::service
}
Does this make sense or am I about to blown my foot off?
Regards
Johan
--
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] Redhat and Scientific Linux
Hello. We're running a mix of Redhat and SL, for the same reasons I would guess many others do, which is to say it saves us money on misc servers where support contracts, ISV/IHV certification and so forth aren't needed. I'm curious about how others handle this with regards to Facter and OS detection in manifests? Do you simply add cases for $operatingsystem = Scientific? Regards Johan -- 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: Redhat and Scientific Linux
That's exactly how I use the facter facts, my classes aren't terribly complex,
most of my usage is in the subtle differences, service names, file locations,
etc.
SL is like CentOS, pretty much a respin sans the Redhat trademarks and such.
For my current purposes it's exactly the same which is the reason I'm asking.
Regards
Johan
From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on behalf
of Luke Bigum [luke.bi...@lmax.com]
Sent: 14 October 2011 10:05
To: Puppet Users
Subject: [Puppet Users] Re: Redhat and Scientific Linux
It depends on the complexity of your classes.
For a lot of the time you can use variables for the difference between
operating systems and then use conditional logic to populate those
variables, like:
$pkg = $operatingsystem ? {
'RedHat' = woof,
'Fedora' = meow,
}
package { $pkg: }
I've never used Scientific Linux though so I don't know how much it
differs from Red Hat. If you have to start doing very different things
between OS versions, some people prefer to conditionally include sub
classes that are geared towards an individual OS:
class stuff {
if ($operatingsystem == 'Fedora') {
include stuff::fedora
} elsif ($operatingsystem == 'RedHat') {
include stuff::redhat
}
} else {
fail(The OS ${operatingsystem} is not supported by the 'stuff'
class.)
}
}
On Oct 14, 7:16 am, Johan Sunnerstig johan.sunners...@auriga.se
wrote:
Hello.
We're running a mix of Redhat and SL, for the same reasons I would guess many
others do, which is to say it saves us money on misc servers where support
contracts, ISV/IHV certification and so forth aren't needed.
I'm curious about how others handle this with regards to Facter and OS
detection in manifests? Do you simply add cases for $operatingsystem =
Scientific?
Regards
Johan
--
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] Re: Redhat and Scientific Linux
That sounds promising. I'm currently using the EPEL repository to install Puppet, and they're at 1.6.0. I guess I'll have to decide what's less trouble, installing Puppet some other way or rewriting a bunch of manifests. :) Thanks Johan From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on behalf of Steve Traylen [steve.tray...@cern.ch] Sent: 14 October 2011 10:19 To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] Re: Redhat and Scientific Linux On Fri, Oct 14, 2011 at 10:05 AM, Luke Bigum luke.bi...@lmax.com wrote: We're running a mix of Redhat and SL, for the same reasons I would guess many others do, which is to say it saves us money on misc servers where support contracts, ISV/IHV certification and so forth aren't needed. I'm curious about how others handle this with regards to Facter and OS detection in manifests? Do you simply add cases for $operatingsystem = Scientific? The recently released facter contains a new fact $osfamily Facter 1.6.2. available ##New fact: (6792) Added osfamily fact. Added osfamily fact to determine if a given operating system is a derivative of a common operating system. this is equal to redhat for redhat, centos, sl, slc, slf, sld, ... -- Steve Traylen -- 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] The Debian service provider issue
Hello people. Regarding the issue with Debian 6 and enable/disable of services, I was wondering how people have worked around this while it's being worked out? For reference, http://projects.puppetlabs.com/issues/7296 Do you simply make sure the services are turned off when puppet runs and disregard the enable/disable functionality for now? Or run smart exec's? Or something else I haven't thought about? Any input on how others have worked with this would be much appreciated. Regards Johan -- 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 and Debian 6 services
...because a whole bunch of init scripts on Debian didn't provide a
functional 'status' method, which meant that puppet would fail in a
whole other exciting way. :(
So I guess the best way to solve it on my end would be to simply specify
hasstatus and such per service I guess?
We already have a bug report about this, and the problem is that we
can't just tell users of stable to stick with older version of puppet
– so the Debian provider needs to support both r5 and r6, which means
detecting the availability of the 'disable' option and using it when
possible.
Given we are under some release pressure at the moment ourselves you
can move this along by providing concrete information about how we can
determine if 'disable' is supported, ideally without mistaking failed
to disable for can't disable.
Patches also happily accepted, of course. :)
Aside from being a pretty horrible programmer, I also know next to nothing
about Ruby. :)
That said, the only things I can think of off the top of my head are
ugly(checking for the enable/disable syntax line, checking /etc/debian_version,
etc).
I guess the least ugly thing I can think of is to check the sys-rc version
with something like dpkg-query -W -f='${Version}\n' sysv-rc, seems like
enable/disable was included in 2.87, Deb5 runs 2.86 and Deb6 runs 2.88.
Then again, with the subversions that's gonna be annoying unless you cut it off
at 4 characters, and that's ugly.
Ah well, like I said, I'm a pretty horrible programmer. :)
You seem to pretty much have it nailed down; the only other
consideration is that puppet is often backported in Debian, and we do
expect to support non-Debian packages and custom backports (more or
less) in the code.
Any idea how people in general are dealing with this on Deb6 boxes?
I guess a pair of enable/disable parameters with custom commands to enable or
disable service would solve it in a way.
Then again I can just use an exec for that myself.
Regards,
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
Thanks for the reply, much appreciated.
Oh and sorry for the horrible formatting, I'm stuck in Outlook Web Access hell.
--
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 and Debian 6 services
I'm trying to make puppet disable and stop some services on a bunch of Debian boxes, but I'm running into some problems. The puppet server is running 2.6.4, downloaded from puppetlabs.com, the Deb5 clients do as well, while the Deb6 clients use 2.6.2 as shipped in the Deb6 repos(though I did try 2.6.4 on one Deb6 box just to rule that out, no difference). Debian 5/Lenny: Things mostly work fine here, the exception being nfs-common which won't be shutdown. I assume this is because puppet runs ps -ef to try to find the process rather than using the init script. I can work around this by providing more parameters for the nfs-common service in the manifest, but I'm still curious why Puppet won't just use the init script when the service provider is Debian? Debian 6/Squeeze: Same thing with stopping nfs-common here. Disabling services doesn't work at all though. puppet agent -t -d says it's running f.e /usr/sbin/update-rc.d -f nfs-common remove, this command works fine if I run it on the command line, so I really have no idea why it doesn't work. Though unless I'm missing something a saner way to disable services would be to run update-rc.d $service disable in Debian 6, though I suppose maybe this simply isn't implemented yet since Squeeze isn't released yet? If so, does anyone know if this is in the works for say 2.6.5? On that note I've noticed that puppet will claim to run the same update-rc.d command under Debian 5 while it really doesn't seem to, since under Deb5 it will actually change the S links to K links, whereas update-rc.d -f $service remove will remove the rcX.d symlinks alltogether. Anyways, I guess in the end what I would really like is some clarification on how this all works under Debian so I will know what to expect. I did find some bugs filed against older puppet versions running on Debian, but nothing against 2.6. Thanks. Johan -- 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] User management
Hi people.
After some reading, I think I have some sort of coherent thought about how to
handle users and groups, being a first time Puppet user though I figured I'd
ask for some criticism before I go ahead.
I'll use the /modules/user module as per the BP-doc, and store all the users
and groups in one file/class.
Then I'll have two(for now at least) classes in separate files, basically these
will be admins and non-admins, and node classes will then inherit these as
needed(I expect most nodes will only need the admins and possibly some
application accounts).
Somethingl like so(no I'm not trying to write real puppet code, just a brief
description, so I know this won't work as is ;-) :
virtual.pp
class user::virtual
# Groups first for the sake of order
@group admin...
@group notadmin...
...
# Users now
@user {user1: gid = admin ...}
@user {user2: gid = notadmin ...}
...
admins.pp
class user::admins inherits user::virtual
realize ( Group[admin], User[user1] )
nonadmins.pp
class user::notadmins inherits user::virtual
realize ( Group[notadmin, User[user2] )
And the base node class will include the user::admin class, and so forth.
As for application accounts and such, I figured I'd stick these in classes of
their own in one manifest(say appusers.pp or some such).
Basically what I'm asking, does this seem sane to more experienced people, or
am I setting myself up for pain?
Regards
Johan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@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.
