[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.
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 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.
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 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.
[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.
[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 > ✆ 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.