From Fedora Project Wiki

(→‎IRC Log of the Class: added session log)
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 3: Line 3:
==== IRC Log of the Class ====
==== IRC Log of the Class ====


<!-- The easiest way to add the log is to indent it two spaces for each lineKeep the lines around 80 chars -->
{|
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so this session is about configuration management, which does *not* include the soft side of configuration management for a change
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
| colspan="2" | *Bugz_ is
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | we're *not* going to talk about procedural issues, but keep it on the technical side
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i'd like to invite you all to take a look at http://www.kanarip.com/courses/puppet/puppet.pdf
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | which is a nice reader i wrote for a one-day workshop i'm giving on this topic, and that is commercially available
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | community people like us however *do not have to pay*
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | sounds great, huh? ;-)
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | yes
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | :)
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #854685" | delhage
| style="color: #854685" | from Delft eh?
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so, a little something on configuration management first, then a sneak peak at the installation  of puppet, and a quick howto on writing your "manifest" as they call the puppet configuration syntax
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | delhage, Utrecht
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #854685" | delhage
| style="color: #854685" | ok
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so, what is it we would want to do with configuration management in the technical sense of the words
|| [[#t23:04:12|23:04]]
|- id="t23:04:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | we all know that the more systems we need to maintain, the harder it becomes to keep some extend of consistency between different systems
|| [[#t23:04:12|23:04]]
|- id="t23:05:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | some organizations use scripts from an NFS share, or use an SVN tree with scripts periodically updated and execute scripts
|| [[#t23:05:14|23:05]]
|- id="t23:05:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | does that sound familiar to anyone?
|| [[#t23:05:14|23:05]]
|- id="t23:05:14"
| colspan="2" | *erinlea80 nods
|| [[#t23:05:14|23:05]]
|- id="t23:05:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so what happens in these cases is:
|| [[#t23:05:14|23:05]]
|- id="t23:05:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 1) your scripts tend to get very large
|| [[#t23:05:14|23:05]]
|- id="t23:05:50"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | describing every unique situation, every exemption, every update, for every operating system, distribution, distribution version, makes the script less maintainable
|| [[#t23:05:50|23:05]]
|- id="t23:06:10"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 2) your scripts are executed at arbitrary intervals
|| [[#t23:06:10|23:06]]
|- id="t23:06:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | either a cronjob, on boot, may or may not fail, and you cannot make the changes you want pronto
|| [[#t23:06:34|23:06]]
|- id="t23:06:58"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 3) your scripts replace configuration and reconfigure stuff without actual changes being applied
|| [[#t23:06:58|23:06]]
|- id="t23:07:18"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | either of these 3 things cries out for a configuration management like...
|| [[#t23:07:18|23:07]]
|- id="t23:07:26"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | Puppet (or CFEngine)
|| [[#t23:07:26|23:07]]
|- id="t23:07:32"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | anyone heard of CFEngine before?
|| [[#t23:07:32|23:07]]
|- id="t23:07:37"
! style="background-color: #854685" | delhage
| style="color: #854685" | yup
|| [[#t23:07:37|23:07]]
|- id="t23:07:39"
! style="background-color: #488888" | jds2001
| style="color: #488888" | however cfengine is fail
|| [[#t23:07:39|23:07]]
|- id="t23:07:43"
! style="background-color: #488888" | jds2001
| style="color: #488888" | we use it :)
|| [[#t23:07:43|23:07]]
|- id="t23:07:51"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | jds2001, you're in the right spot ;-)
|| [[#t23:07:51|23:07]]
|- id="t23:08:09"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | what CFEngine does is very accurately describe the configuration state a system has to be in
|| [[#t23:08:09|23:08]]
|- id="t23:08:32"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it does it so accurately, in fact, that it ends up being a very low-level tool
|| [[#t23:08:32|23:08]]
|- id="t23:08:36"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | to give you an example;
|| [[#t23:08:36|23:08]]
|- id="t23:09:22"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | in CFEngine, to install a package called foo, you will have to manually assign a package provider to each operating system, distribution or distribution version, and then use that provider to install the package
|| [[#t23:09:22|23:09]]
|- id="t23:09:43"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | in addition, you would need to change the name for each OS, distro and distribution version
|| [[#t23:09:43|23:09]]
|- id="t23:10:01"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | lots to type, lots to care about, while in fact all you care about is that the package is installed
|| [[#t23:10:01|23:10]]
|- id="t23:10:18"
| colspan="2" | *kanarip introduces... the high-level abstraction of Puppet
|| [[#t23:10:18|23:10]]
|- id="t23:10:36"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | no matter what the operating system, distribution or distribution may be, Puppet speaks the local language
|| [[#t23:10:36|23:10]]
|- id="t23:11:13"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it'll figure out on it's own whether to use yum, up2date, dpkg, apt, PackageKit, alien, smart, rpm or what-package-manager-have-you
|| [[#t23:11:13|23:11]]
|- id="t23:11:30"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | this way, ensuring that package foo is installed on a system becomes:
|| [[#t23:11:30|23:11]]
|- id="t23:11:35"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | package { "foo":
|| [[#t23:11:35|23:11]]
|- id="t23:11:40"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" |    ensure =&gt; installed
|| [[#t23:11:40|23:11]]
|- id="t23:11:41"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | }
|| [[#t23:11:41|23:11]]
|- id="t23:11:44"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | and you're done
|| [[#t23:11:44|23:11]]
|- id="t23:11:58"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | jds2001, can you confirm that is easier then CFEngine please? ;-)
|| [[#t23:11:58|23:11]]
|- id="t23:12:06"
! style="background-color: #488888" | jds2001
| style="color: #488888" | yes :)
|| [[#t23:12:06|23:12]]
|- id="t23:12:11"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | thanks ;-)
|| [[#t23:12:11|23:12]]
|- id="t23:12:19"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so, how does puppet work?
|| [[#t23:12:19|23:12]]
|- id="t23:13:15"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | given these abstracted "system resources" such as packages, services, cronjobs, users, ..., this and that and more, puppet uses so-called "types" you can use in a configuration "manifest" to describe what state a managed system should be in
|| [[#t23:13:15|23:13]]
|- id="t23:13:29"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | here's a list of types: http://reductivelabs.com/trac/puppet/wiki/TypeReference
|| [[#t23:13:29|23:13]]
|- id="t23:14:56"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | now let me describe to you what a working setup looks like;
|| [[#t23:14:56|23:14]]
|- id="t23:15:15"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | there is a single server, called the puppetmaster
|| [[#t23:15:15|23:15]]
|- id="t23:15:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | personally i think the puppeteer would have been a more appropriate name, but puppetmaster it is
|| [[#t23:15:34|23:15]]
|- id="t23:15:56"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the managed system is called a "puppet" - whos strings you can pull using the puppetmaster
|| [[#t23:15:56|23:15]]
|- id="t23:16:20"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the puppet, or managed system, polls the puppetmaster at a default interval of every 30 minutes
|| [[#t23:16:20|23:16]]
|- id="t23:17:08"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the puppetmaster, having *all* the configuration for *all* nodes in an environment, will parse *all* it's manifests, and send to the puppet a set of resources to be managed on that specific node
|| [[#t23:17:08|23:17]]
|- id="t23:17:09"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | Q: do they all pull at once? or is it staggered?
|| [[#t23:17:09|23:17]]
|- id="t23:17:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nirik, it depends on the time at which the puppet starts counting
|| [[#t23:17:34|23:17]]
|- id="t23:17:56"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it has a default 1 minute randomization i believe
|| [[#t23:17:56|23:17]]
|- id="t23:18:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | but it'll poll at least once every 30.9 minutes, if that makes sense ;-)
|| [[#t23:18:34|23:18]]
|- id="t23:18:52"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | why does it do that?
|| [[#t23:18:52|23:18]]
|- id="t23:19:21"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | to check if there's any changes to the configuration for the node
|| [[#t23:19:21|23:19]]
|- id="t23:19:21"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | if yo have changes on the master can you just tell it to push them?
|| [[#t23:19:21|23:19]]
|- id="t23:19:40"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | ok thanks
|| [[#t23:19:40|23:19]]
|- id="t23:20:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | if you change anything, you let the master pick it up and at most 59 later the puppet will have picked up on the changes
|| [[#t23:20:38|23:20]]
|- id="t23:20:51"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | that is, if you are using the default interval of 30 minutes
|| [[#t23:20:51|23:20]]
|- id="t23:21:10"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | sorry, should have said: at most 30.9 minutes after you apply changes, puppet will have picked up the changes
|| [[#t23:21:10|23:21]]
|- id="t23:21:33"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so here's how the puppetmaster distinguishes configuration to be applied to one node: http://git.puppetmanaged.org/?p=domain-kanarip.com;a=blob;f=puppet/manifests/nodes/anakin.kanarip.com.pp
|| [[#t23:21:33|23:21]]
|- id="t23:21:46"
! style="background-color: #4b904b" | daMaestro
| style="color: #4b904b" | is there any way to push changes? or is it all pull operations?
|| [[#t23:21:46|23:21]]
|- id="t23:21:56"
! style="background-color: #4b904b" | daMaestro
| style="color: #4b904b" | (in the case of needing an isolated DMZ/VLAN)
|| [[#t23:21:56|23:21]]
|- id="t23:22:09"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the puppetmaster will load that file and know that anakin.kanarip.com which is an actual system is to be configured accordingly
|| [[#t23:22:09|23:22]]
|- id="t23:22:32"
! style="background-color: #4d4d93" | neverho0d
| style="color: #4d4d93" | is there way to stop propagating changes?
|| [[#t23:22:32|23:22]]
|- id="t23:22:40"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | evry 30 minutes sounds like overhead
|| [[#t23:22:40|23:22]]
|- id="t23:22:41"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | daMaestro, puppet provides a utility called puppetrun which tells the client or clients to do a puppet run
|| [[#t23:22:41|23:22]]
|- id="t23:22:59"
! style="background-color: #4b904b" | daMaestro
| style="color: #4b904b" | kanarip, yet this is still a pull?
|| [[#t23:22:59|23:22]]
|- id="t23:23:02"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | neverho0d, yes;
|| [[#t23:23:02|23:23]]
|- id="t23:23:13"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 1) stage your changes in environments
|| [[#t23:23:13|23:23]]
|- id="t23:23:14"
! style="background-color: #4d4d93" | neverho0d
| style="color: #4d4d93" | kanarip: ok
|| [[#t23:23:14|23:23]]
|- id="t23:23:17"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 2) stop the puppetmaster
|| [[#t23:23:17|23:23]]
|- id="t23:23:23"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 3) stop the puppet client daemon
|| [[#t23:23:23|23:23]]
|- id="t23:23:30"
| colspan="2" | *daMaestro attempts to not interrupt anymore
|| [[#t23:23:30|23:23]]
|- id="t23:23:37"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 4) let the puppetmaster not pull from a SCM to load new configuration
|| [[#t23:23:37|23:23]]
|- id="t23:23:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | daMaestro, the puppet client will perform a pull from the puppetmaster, yes
|| [[#t23:23:52|23:23]]
|- id="t23:24:03"
! style="background-color: #4b904b" | daMaestro
| style="color: #4b904b" | k
|| [[#t23:24:03|23:24]]
|- id="t23:24:28"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | any other questions so far?
|| [[#t23:24:28|23:24]]
|- id="t23:24:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i'd like to dive into modules, if that's ok?
|| [[#t23:24:38|23:24]]
|- id="t23:24:45"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | any utilities to automate data/config collections on pre-existing servers?
|| [[#t23:24:45|23:24]]
|- id="t23:24:53"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | or is it all by hand?
|| [[#t23:24:53|23:24]]
|- id="t23:25:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | erinlea80, it's very complex to harvest data and then roll it out but i guess a certain scale justifies putting in such effort
|| [[#t23:25:38|23:25]]
|- id="t23:25:56"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the harvesting would only happen once is what i'm concerned with
|| [[#t23:25:56|23:25]]
|- id="t23:26:00"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | agreed -- was wondering what the options are.
|| [[#t23:26:00|23:26]]
|- id="t23:26:13"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so here's a sample module for puppet: http://git.puppetmanaged.org/?p=sudo;a=tree
|| [[#t23:26:13|23:26]]
|- id="t23:26:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | a module is a collection of the manifest: manifests/init.pp, the files used by that module (in files/), any templates used by the module (in templates/), and more
|| [[#t23:26:52|23:26]]
|- id="t23:27:06"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation for a reference
|| [[#t23:27:06|23:27]]
|- id="t23:27:25"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | and of course there's something mentioned in http://www.kanarip.com/courses/puppet/puppet.pdf as well
|| [[#t23:27:25|23:27]]
|- id="t23:27:55"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | what makes modules so great is a couple of things;
|| [[#t23:27:55|23:27]]
|- id="t23:28:13"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 1) i can share it with you and you can just start using it
|| [[#t23:28:13|23:28]]
|- id="t23:28:45"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 2) you can customize it and still pull changes from an upstream SCM like the GIT repository I just pointed you to and send me/upstream patches
|| [[#t23:28:45|23:28]]
|- id="t23:28:55"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 3) modules allow "staging"
|| [[#t23:28:55|23:28]]
|- id="t23:29:03"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i guess the next topic is "staging" ;-)
|| [[#t23:29:03|23:29]]
|- id="t23:29:25"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 4) modules keep your files, manifests, templates and plugins organized
|| [[#t23:29:25|23:29]]
|- id="t23:29:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | believe me when I say puppet configuration trees can become a mess if you start managing more and more with puppet, and not use modules
|| [[#t23:29:52|23:29]]
|- id="t23:29:58"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | == Staging ==
|| [[#t23:29:58|23:29]]
|- id="t23:30:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | What I mean by staging is simply this; stage your changes from a development environment, possibly via a testing environment onto your production environment
|| [[#t23:30:38|23:30]]
|- id="t23:31:26"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | you can develop all you want in your development environment, make syntax errors, rm -rf / sorta speak, and never nuke that business critical application server you have running
|| [[#t23:31:26|23:31]]
|- id="t23:32:08"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | then once you're satisfied, you may move the changes into the testing or production environment
|| [[#t23:32:08|23:32]]
|- id="t23:32:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | does that make sense?
|| [[#t23:32:12|23:32]]
|- id="t23:32:21"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | oh yeah
|| [[#t23:32:21|23:32]]
|- id="t23:32:24"
! style="background-color: #4d4d93" | neverho0d
| style="color: #4d4d93" | sure
|| [[#t23:32:24|23:32]]
|- id="t23:32:24"
! style="background-color: #488888" | jds2001
| style="color: #488888" | yes, but how does one do this in practice?
|| [[#t23:32:24|23:32]]
|- id="t23:32:26"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | awesome
|| [[#t23:32:26|23:32]]
|- id="t23:32:26"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | mmmm yes
|| [[#t23:32:26|23:32]]
|- id="t23:32:42"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | and does it require a unique environment for each corresponding production environment?
|| [[#t23:32:42|23:32]]
|- id="t23:32:43"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i can recommend anyone getting his feet wet in using environments
|| [[#t23:32:43|23:32]]
|- id="t23:32:48"
| colspan="2" | *nirik has some questions, but can save them for the end as well.
|| [[#t23:32:48|23:32]]
|- id="t23:32:49"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | unique test environ.
|| [[#t23:32:49|23:32]]
|- id="t23:32:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | jds2001, here's a practical example;
|| [[#t23:32:52|23:32]]
|- id="t23:33:27"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | all the repositories you see on http://git.puppetmanaged.org/ have a development, a testing, and a production branch
|| [[#t23:33:27|23:33]]
|- id="t23:34:10"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | what i do when i'm satisfied with my developments, is I change the working branch to testing, and git pull development
|| [[#t23:34:10|23:34]]
|- id="t23:34:40"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | then when i push, the puppetmaster runs a puppet that is configured so that it will pull the changes from the GIT repo
|| [[#t23:34:40|23:34]]
|- id="t23:34:57"
! style="background-color: #488888" | jds2001
| style="color: #488888" | then you have post-receive hooks to put them someplace?
|| [[#t23:34:57|23:34]]
|- id="t23:35:05"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://git.puppetmanaged.org/?p=domain-puppetmanaged.org;a=blob;f=puppet/manifests/nodes/master.puppetmanaged.org.pp as a reference
|| [[#t23:35:05|23:35]]
|- id="t23:35:28"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | jds2001, no, the puppetmaster in my case runs a puppet that has ^^ configuration applied to itself
|| [[#t23:35:28|23:35]]
|- id="t23:36:10"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | a post-hook making the puppetmaster pull in the changes is a viable solution too; the Fedora Project does such
|| [[#t23:36:10|23:36]]
|- id="t23:36:25"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | however, in my situation, the puppetmaster and the SCM are not on the same machine
|| [[#t23:36:25|23:36]]
|- id="t23:37:08"
! style="background-color: #488888" | jds2001
| style="color: #488888" | ok, makes sense
|| [[#t23:37:08|23:37]]
|- id="t23:37:12"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | kk
|| [[#t23:37:12|23:37]]
|- id="t23:37:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://www.kanarip.com/courses/puppet/puppet.odp is a presentation slide-deck BTW, that goes along with the .pdf i've already linked
|| [[#t23:37:14|23:37]]
|- id="t23:37:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | note that what you see on puppetmanaged.org is heavily dependent on the other modules available from puppetmanaged.org
|| [[#t23:37:38|23:37]]
|- id="t23:38:43"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so... what do you think about setting it up?
|| [[#t23:38:43|23:38]]
|- id="t23:39:15"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | lets do it?
|| [[#t23:39:15|23:39]]
|- id="t23:39:24"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | there you go ;-)
|| [[#t23:39:24|23:39]]
|- id="t23:39:37"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | let me refer to the documentation i shared earlier because it's a lot to type
|| [[#t23:39:37|23:39]]
|- id="t23:39:49"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://www.kanarip.com/courses/PuppetWorkshop-SettingUpPuppet.html
|| [[#t23:39:49|23:39]]
|- id="t23:40:21"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it's a yum install puppet-server to install it on any Fedora system
|| [[#t23:40:21|23:40]]
|- id="t23:40:36"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | for Red Hat and CentOS, you'll need EPEL configured
|| [[#t23:40:36|23:40]]
|- id="t23:40:43"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://fedoraproject.org/wiki/EPEL
|| [[#t23:40:43|23:40]]
|- id="t23:40:56"
| colspan="2" | *erinlea80 nods
|| [[#t23:40:56|23:40]]
|- id="t23:41:26"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | for anyone who's wondering about what EPEL is... I maintain or co-maintain the entire Ruby stack to puppet in that repository ;-)
|| [[#t23:41:26|23:41]]
|- id="t23:41:49"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | and that brings me to one more nifty feature of puppet;
|| [[#t23:41:49|23:41]]
|- id="t23:42:08"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | but first... facts!
|| [[#t23:42:08|23:42]]
|- id="t23:42:17"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | facts are... well... facts...
|| [[#t23:42:17|23:42]]
|- id="t23:42:33"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | little information about the current state of a client
|| [[#t23:42:33|23:42]]
|- id="t23:43:02"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it includes the kernel version, number of network interfaces, the architecture, operating system name, operating system version, and lots more
|| [[#t23:43:02|23:43]]
|- id="t23:43:16"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | yum install facter and run "facter" on your machine to check it out
|| [[#t23:43:16|23:43]]
|- id="t23:43:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | these are all "variables" you can use in your puppet manifests
|| [[#t23:43:38|23:43]]
|- id="t23:44:09"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | given a small amount of RAM for example, you may want to apply a snippet similar to: package { "firefox": ensure =&gt; absent }
|| [[#t23:44:09|23:44]]
|- id="t23:44:35"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | anyway, what i really wanted to say rather then to give a rant on firefox's memory consumption is this;
|| [[#t23:44:35|23:44]]
|- id="t23:44:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | facts, types and providers, these things that make puppet do smart things...
|| [[#t23:44:52|23:44]]
|- id="t23:45:01"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | facts for information about the client...
|| [[#t23:45:01|23:45]]
|- id="t23:45:09"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | do we have a sample facter output?
|| [[#t23:45:09|23:45]]
|- id="t23:45:21"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i could fpaste you some
|| [[#t23:45:21|23:45]]
|- id="t23:45:35"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | that would be great :)
|| [[#t23:45:35|23:45]]
|- id="t23:45:53"
! style="background-color: #9b519b" | zcat
| style="color: #9b519b" | kanarip, is facter supposed to spit out "virtual =&gt; vmware_server" if detected?
|| [[#t23:45:53|23:45]]
|- id="t23:45:56"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | creating new ones doesnt look that easy
|| [[#t23:45:56|23:45]]
|- id="t23:46:10"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | http://fpaste.org/paste/15
|| [[#t23:46:10|23:46]]
|- id="t23:46:41"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | but theres good documentation on create types fact etc
|| [[#t23:46:41|23:46]]
|- id="t23:46:45"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | types to define resources to be managed on the puppet...
|| [[#t23:46:45|23:46]]
|- id="t23:47:00"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | thanks
|| [[#t23:47:00|23:47]]
|- id="t23:47:03"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | and providers to make puppet speak the local language...
|| [[#t23:47:03|23:47]]
|- id="t23:47:14"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | the great thing is... you can write your own for all of these
|| [[#t23:47:14|23:47]]
|- id="t23:47:53"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it does require ruby knowledge, but then again... there's sample recipes on reductivelabs.com for...for example zcat, a vmware custom fact ;-)
|| [[#t23:47:53|23:47]]
|- id="t23:47:59"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | see, i was getting there ;-)
|| [[#t23:47:59|23:47]]
|- id="t23:48:22"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | actually i think the custom fact is called "this is a vmware machine" and "whether it has vm-tools installed"
|| [[#t23:48:22|23:48]]
|- id="t23:48:59"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | one more thing i really, really need to stress out to you
|| [[#t23:48:59|23:48]]
|- id="t23:49:17"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | all communication between the puppet and it's puppetmaster is *secure*
|| [[#t23:49:17|23:49]]
|- id="t23:49:45"
| colspan="2" | *nirik has one of his questions answered. ;)
|| [[#t23:49:45|23:49]]
|- id="t23:50:02"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | that being said, the security is based on the puppetmaster running the Certificate Authority, the client generating a certificate and putting in a request with the puppetmaster to get a signed copy of that certificate
|| [[#t23:50:02|23:50]]
|- id="t23:50:05"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | can communication be tunneled over ssh if necessary? (firewall restrictions, etc.)
|| [[#t23:50:05|23:50]]
|- id="t23:50:11"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | but the puppets have root access obviously?
|| [[#t23:50:11|23:50]]
|- id="t23:50:18"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | and the master
|| [[#t23:50:18|23:50]]
|- id="t23:50:22"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | erinlea80, you can make the puppetmaster run on any port you want
|| [[#t23:50:22|23:50]]
|- id="t23:50:43"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | erinlea80, may i point out "autossh" with which you can create tunnels to communicate over if you wish
|| [[#t23:50:43|23:50]]
|- id="t23:50:49"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | ty :)
|| [[#t23:50:49|23:50]]
|- id="t23:51:01"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | domg472_, the puppet client daemon runs with root privileges, yes
|| [[#t23:51:01|23:51]]
|- id="t23:51:16"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | has anyone tested this with selinux?
|| [[#t23:51:16|23:51]]
|- id="t23:51:16"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | domg472_, the master runs with under the puppet user
|| [[#t23:51:16|23:51]]
|- id="t23:51:51"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | ok thanks
|| [[#t23:51:51|23:51]]
|- id="t23:52:20"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | domg472_, i have, and i can tell you it requires a custom selinux policy in which you basically describe the puppet daemon can do this and that and more
|| [[#t23:52:20|23:52]]
|- id="t23:52:31"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | in my case, the puppet daemon can do anything it likes
|| [[#t23:52:31|23:52]]
|- id="t23:52:45"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | youd need custom modules i bet
|| [[#t23:52:45|23:52]]
|- id="t23:52:58"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | interesting
|| [[#t23:52:58|23:52]]
|- id="t23:53:21"
! style="background-color: #539e9e" | sdodson
| style="color: #539e9e" | There are also a few minor bugs which I think have been fixed recently where puppet creates files without the proper contexts.
|| [[#t23:53:21|23:53]]
|- id="t23:53:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | selinux is being integrated better into puppet as we speak
|| [[#t23:53:34|23:53]]
|- id="t23:53:39"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | great
|| [[#t23:53:39|23:53]]
|- id="t23:53:49"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | it's a big issue, i concur
|| [[#t23:53:49|23:53]]
|- id="t23:53:54"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | Q: if I enable, for example httpd in a manifest, and 2 hours later comment it out, does the puppet uninstall/disable httpd or ignore it from then on?
|| [[#t23:53:54|23:53]]
|- id="t23:54:17"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, puppet only applies changes
|| [[#t23:54:17|23:54]]
|- id="t23:54:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, so it only enforces what you describe needs to happen
|| [[#t23:54:34|23:54]]
|- id="t23:54:46"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | if you say package httpd should be installed at one point
|| [[#t23:54:46|23:54]]
|- id="t23:54:46"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | so I'd have to explicity turn it off, if that's what I meant?
|| [[#t23:54:46|23:54]]
|- id="t23:55:20"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | and then comment that out... no other machine is going to care whether the package should be installed, but it's not going to be removed on puppet's behalf
|| [[#t23:55:20|23:55]]
|- id="t23:55:26"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, yes
|| [[#t23:55:26|23:55]]
|- id="t23:55:37"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | I dig, thanks
|| [[#t23:55:37|23:55]]
|- id="t23:56:00"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, same goes for the service type; ensure =&gt; running, enable =&gt; true would need to become ensure =&gt; stopped, enable =&gt; false
|| [[#t23:56:00|23:56]]
|- id="t23:56:10"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | precisely
|| [[#t23:56:10|23:56]]
|- id="t23:56:22"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | I can just see myself not remembering that...
|| [[#t23:56:22|23:56]]
|- id="t23:56:33"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | so, another thing on the topic; what do you think happens if the puppet daemon cannot contact the puppetmaster?
|| [[#t23:56:33|23:56]]
|- id="t23:56:34"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | and commenting it out instead
|| [[#t23:56:34|23:56]]
|- id="t23:56:56"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | does it do them in order in the manifest? ie, make sure to stop before ensure
|| [[#t23:56:56|23:56]]
|- id="t23:57:08"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, there's some discussion going on about supporting an "exclude" statement like we do "include webserver" now
|| [[#t23:57:08|23:57]]
|- id="t23:57:18"
! style="background-color: #97974f" | nuonguy
| style="color: #97974f" | nice
|| [[#t23:57:18|23:57]]
|- id="t23:57:24"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nuonguy, and then flipping all the false's into true's and so forth
|| [[#t23:57:24|23:57]]
|- id="t23:57:37"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nirik, good point!
|| [[#t23:57:37|23:57]]
|- id="t23:57:41"
! style="background-color: #539e9e" | sdodson
| style="color: #539e9e" | Could create a baseline that ensures none of that is installed/running then include webserver for only your webservers which would override those baselines?
|| [[#t23:57:41|23:57]]
|- id="t23:57:46"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | puppet allows ordering the resources;
|| [[#t23:57:46|23:57]]
|- id="t23:57:52"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | let me look you up an example
|| [[#t23:57:52|23:57]]
|- id="t23:58:55"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | why was ruby chosen as the language for writing types etc?
|| [[#t23:58:55|23:58]]
|- id="t23:59:05"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | why not bash?
|| [[#t23:59:05|23:59]]
|- id="t23:59:42"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | here's a yp manifest: http://fpaste.org/paste/16
|| [[#t23:59:42|23:59]]
|- id="t00:00:21"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | domg472_, i'm not sure i'm not one of the core developers, but i can try and answer it if you promise not to quote me on it ;-)
|| [[#t00:00:21|00:00]]
|- id="t00:00:32"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | hah ok
|| [[#t00:00:32|00:00]]
|- id="t00:00:40"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | i think most sysadmins know bash
|| [[#t00:00:40|00:00]]
|- id="t00:00:49"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nirik, you can see how "require =&gt; (...)" in that yp manifest causes one resource to be dependent on another
|| [[#t00:00:49|00:00]]
|- id="t00:00:59"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | and they will need to write custom types probably
|| [[#t00:00:59|00:00]]
|- id="t00:01:51"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | domg472_, i think bash is what you use to do a quick thing, clean and simple.  I think ruby allows a framework to be built, reusing snippets of code you've already written in a different place. I think ruby is more modular then is bash
|| [[#t00:01:51|00:01]]
|- id="t00:02:06"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | ok thanks
|| [[#t00:02:06|00:02]]
|- id="t00:02:16"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | you could write a website in bash but you won't, right?
|| [[#t00:02:16|00:02]]
|- id="t00:02:21"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | i guess ill be learning ruby then
|| [[#t00:02:21|00:02]]
|- id="t00:02:23"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | true
|| [[#t00:02:23|00:02]]
|- id="t00:02:33"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | but these are simplate admin tasks
|| [[#t00:02:33|00:02]]
|- id="t00:02:40"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | simple
|| [[#t00:02:40|00:02]]
|- id="t00:02:42"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | not saying you should choose php to do it BTW ;-)
|| [[#t00:02:42|00:02]]
|- id="t00:02:56"
| colspan="2" | *nirik notes we are over time, but this is also the last class today.
|| [[#t00:02:56|00:02]]
|- id="t00:03:18"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | in puppet terms; distribute the bash scripts amongst the clients that need it using the file type, and exec that script
|| [[#t00:03:18|00:03]]
|- id="t00:03:24"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | I had one last question: how do you decide what should be in a module? whats the logical boundry there?
|| [[#t00:03:24|00:03]]
|- id="t00:03:36"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | anything you;
|| [[#t00:03:36|00:03]]
|- id="t00:03:42"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | ah right, thanks kanarip
|| [[#t00:03:42|00:03]]
|- id="t00:03:47"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 1) pull from an upstream source
|| [[#t00:03:47|00:03]]
|- id="t00:04:00"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 2) need to share (with the general public)
|| [[#t00:04:00|00:04]]
|- id="t00:04:11"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 3) want to stage
|| [[#t00:04:11|00:04]]
|- id="t00:04:33"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | so it doesn't need to be a specific service or anything? just whatever you want to put in one?
|| [[#t00:04:33|00:04]]
|- id="t00:04:38"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | 4) that is a concise set of files, manifests, etc.
|| [[#t00:04:38|00:04]]
|- id="t00:04:57"
! style="background-color: #539e9e" | sdodson
| style="color: #539e9e" | They're advising people to get away from writing classes and move towards modules.
|| [[#t00:04:57|00:04]]
|- id="t00:05:04"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nirik, you're almost right, a module called everything-else doesn't make sense ;-)
|| [[#t00:05:04|00:05]]
|- id="t00:05:12"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | sdodson, yes, very much so
|| [[#t00:05:12|00:05]]
|- id="t00:05:51"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | nirik, a module webserver makes sense; keeping it close and concise within a module is way easier then dispersing it all over the place
|| [[#t00:05:51|00:05]]
|- id="t00:06:12"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | ok, makes sense.
|| [[#t00:06:12|00:06]]
|- id="t00:06:27"
! style="background-color: #a25555" | tmz
| style="color: #a25555" | domg472_: regarding why ruby was used to write puppet, here's a short interview with Luke Kanies (primary puppet author), where he touches on that choice:
|| [[#t00:06:27|00:06]]
|- id="t00:06:31"
! style="background-color: #a25555" | tmz
| style="color: #a25555" | http://on-ruby.blogspot.com/2008/02/puppet-interview-with-luke-kanies.html
|| [[#t00:06:31|00:06]]
|- id="t00:06:40"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | thanks
|| [[#t00:06:40|00:06]]
|- id="t00:06:46"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | what i tend to recommend to customers is also, to keep the systems they manage as consistent as possible
|| [[#t00:06:46|00:06]]
|- id="t00:07:20"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | being able to determine the exceptions to the rule you've layed down saves you a lot of time in determining what the cause might be for a specific issue
|| [[#t00:07:20|00:07]]
|- id="t00:08:11"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | shall we wrap up and let kanarip get some sleep?
|| [[#t00:08:11|00:08]]
|- id="t00:08:17"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | ;-)
|| [[#t00:08:17|00:08]]
|- id="t00:08:23"
! style="background-color: #4b904b" | daMaestro
| style="color: #4b904b" | no, no sleep for kanarip !
|| [[#t00:08:23|00:08]]
|- id="t00:08:34"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | thank you all for your interest, and thank you for attending
|| [[#t00:08:34|00:08]]
|- id="t00:08:37"
| colspan="2" | *daMaestro /dcc kanarip latte
|| [[#t00:08:37|00:08]]
|- id="t00:08:38"
! style="background-color: #488888" | jds2001
| style="color: #488888" | he must stay up all night!
|| [[#t00:08:38|00:08]]
|- id="t00:08:41"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | thanks so much for the session kanarip !
|| [[#t00:08:41|00:08]]
|- id="t00:08:42"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | thanks kanarip!
|| [[#t00:08:42|00:08]]
|- id="t00:08:46"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | thanks again
|| [[#t00:08:46|00:08]]
|- id="t00:08:47"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | :)
|| [[#t00:08:47|00:08]]
|- id="t00:08:49"
! style="background-color: #57a657" | iondrip
| style="color: #57a657" | thanks
|| [[#t00:08:49|00:08]]
|- id="t00:08:53"
! style="background-color: #407a40" | kanarip
| style="color: #407a40" | i hope you find a lot of use in the pdf/html/odp i've given you ;-)
|| [[#t00:08:53|00:08]]
|- id="t00:08:57"
! style="background-color: #4d4d93" | neverho0d
| style="color: #4d4d93" | kanarip: thanks
|| [[#t00:08:57|00:08]]
|- id="t00:09:04"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | thanks everyone for coming...
|| [[#t00:09:04|00:09]]
|- id="t00:09:08"
! style="background-color: #5959a9" | Bugz_
| style="color: #5959a9" | kanarip: Thanks
|| [[#t00:09:08|00:09]]
|- id="t00:09:15"
! style="background-color: #818144" | erinlea80
| style="color: #818144" | :)
|| [[#t00:09:15|00:09]]
|- id="t00:09:31"
! style="background-color: #42427e" | domg472_
| style="color: #42427e" | thanks for hosting
|| [[#t00:09:31|00:09]]
|- id="t00:09:57"
! style="background-color: #adad5b" | SSlater
| style="color: #adad5b" | Thanks
|| [[#t00:09:57|00:09]]
|}


Generated by irclog2html.py 2.7 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!


  Nov 09 18:04:12 <kanarip> so this session is about configuration management, which does *not*
  include the soft side of configuration management for a change
  Nov 09 18:04:12 * Bugz_ is
  Nov 09 18:04:12 <kanarip> we're *not* going to talk about procedural issues, but keep it on the
  technical side
  Nov 09 18:04:12 <kanarip> i'd like to invite you all to take a look at
  http://www.kanarip.com/courses/puppet/puppet.pdf
  Nov 09 18:04:12 <kanarip> which is a nice reader i wrote for a one-day workshop i'm giving on this topic,
  and that is commercially available
  Nov 09 18:04:12 <kanarip> community people like us however *do not have to pay*
  Nov 09 18:04:12 <kanarip> sounds great, huh? ;-)
  Nov 09 18:04:12 <domg472_> yes
  Nov 09 18:04:12 <erinlea80> :)
  Nov 09 18:04:12 <delhage> from Delft eh?
  Nov 09 18:04:12 <kanarip> so, a little something on configuration management first, then a sneak peak
  at the installation  of puppet, and a quick howto on writing your "manifest" as they call the puppet
  configuration syntax
  Nov 09 18:04:12 <kanarip> delhage, Utrecht
  Nov 09 18:04:12 <delhage> ok
  Nov 09 18:04:12 <kanarip> so, what is it we would want to do with configuration management in the technical
  sense of the words
  Nov 09 18:04:12 <kanarip> we all know that the more systems we need to maintain, the harder it becomes to
  keep some extend of consistency between different systems
  Nov 09 18:05:14 <kanarip> some organizations use scripts from an NFS share, or use an SVN tree with scripts
  that is periodically updated and execute scripts
  Nov 09 18:05:14 <kanarip> does that sound familiar to anyone?
  Nov 09 18:05:14 * erinlea80 nods
  Nov 09 18:05:14 <kanarip> so what happens in these cases is:
  Nov 09 18:05:14 <kanarip> 1) your scripts tend to get very large
  Nov 09 18:05:50 <kanarip> describing every unique situation, every exemption, every update, for every
  operating system, distribution, distribution version, makes the script less maintainable
  Nov 09 18:06:10 <kanarip> 2) your scripts are executed at arbitrary intervals
  Nov 09 18:06:34 <kanarip> either a cronjob, on boot, may or may not fail, and you cannot make the changes
  you want pronto
  Nov 09 18:06:58 <kanarip> 3) your scripts replace configuration and reconfigure stuff without actual changes
  being applied
  Nov 09 18:07:18 <kanarip> either of these 3 things cries out for a configuration management like...
  Nov 09 18:07:26 <kanarip> Puppet (or CFEngine)
  Nov 09 18:07:32 <kanarip> anyone heard of CFEngine before?
  Nov 09 18:07:37 <delhage> yup
  Nov 09 18:07:39 <jds2001> however cfengine is fail
  Nov 09 18:07:43 <jds2001> we use it :)
  Nov 09 18:07:51 <kanarip> jds2001, you're in the right spot ;-)
  Nov 09 18:08:09 <kanarip> what CFEngine does is very accurately describe the configuration state a system
  has to be in
  Nov 09 18:08:32 <kanarip> it does it so accurately, in fact, that it ends up being a very low-level tool
  Nov 09 18:08:36 <kanarip> to give you an example;
  Nov 09 18:09:22 <kanarip> in CFEngine, to install a package called foo, you will have to manually assign a
  package provider to each operating system, distribution or distribution version, and then use that provider to
  install the package
  Nov 09 18:09:43 <kanarip> in addition, you would need to change the name for each OS, distro and
  distribution version
  Nov 09 18:10:01 <kanarip> lots to type, lots to care about, while in fact all you care about is that the
  package is installed
  Nov 09 18:10:18 * kanarip introduces... the high-level abstraction of Puppet
  Nov 09 18:10:36 <kanarip> no matter what the operating system, distribution or distribution may be, Puppet
  speaks the local language
  Nov 09 18:11:13 <kanarip> it'll figure out on it's own whether to use yum, up2date, dpkg, apt, PackageKit,
  alien, smart, rpm or what-package-manager-have-you
  Nov 09 18:11:30 <kanarip> this way, ensuring that package foo is installed on a system becomes:
  Nov 09 18:11:35 <kanarip> package { "foo":
  Nov 09 18:11:40 <kanarip>     ensure => installed
  Nov 09 18:11:41 <kanarip> }
  Nov 09 18:11:44 <kanarip> and you're done
  Nov 09 18:11:58 <kanarip> jds2001, can you confirm that is easier then CFEngine please? ;-)
  Nov 09 18:12:06 <jds2001> yes :)
  Nov 09 18:12:11 <kanarip> thanks ;-)
  Nov 09 18:12:19 <kanarip> so, how does puppet work?
  Nov 09 18:13:15 <kanarip> given these abstracted "system resources" such as packages, services, cronjobs,
  users, ..., this and that and more, puppet uses so-called "types" you can use in a configuration "manifest"
  to describe what state a managed system should be in
  Nov 09 18:13:29 <kanarip> here's a list of types: http://reductivelabs.com/trac/puppet/wiki/TypeReference
  Nov 09 18:14:56 <kanarip> now let me describe to you what a working setup looks like;
  Nov 09 18:15:15 <kanarip> there is a single server, called the puppetmaster
  Nov 09 18:15:34 <kanarip> personally i think the puppeteer would have been a more appropriate name, but
  puppetmaster it is
  Nov 09 18:15:56 <kanarip> the managed system is called a "puppet" - whos strings you can pull using the
  puppetmaster
  Nov 09 18:16:20 <kanarip> the puppet, or managed system, polls the puppetmaster at a default interval of
  every 30 minutes
  Nov 09 18:17:08 <kanarip> the puppetmaster, having *all* the configuration for *all* nodes in an environment,
  will parse
  *all* it's manifests, and send to the puppet a set of resources to be managed on that specific node
  Nov 09 18:17:09 <nirik> Q: do they all pull at once? or is it staggered?
  Nov 09 18:17:34 <kanarip> nirik, it depends on the time at which the puppet starts counting
  Nov 09 18:17:56 <kanarip> it has a default 1 minute randomization i believe
  Nov 09 18:18:34 <kanarip> but it'll poll at least once every 30.9 minutes, if that makes sense ;-)
  Nov 09 18:18:52 <domg472_> why does it do that?
  Nov 09 18:19:21 <kanarip> to check if there's any changes to the configuration for the node
  Nov 09 18:19:21 <domg472_> if yo have changes on the master can you just tell it to push them?
  Nov 09 18:19:40 <domg472_> ok thanks
  Nov 09 18:20:38 <kanarip> if you change anything, you let the master pick it up and at most 59
  minutes later the puppet will have picked up on the changes
  Nov 09 18:20:51 <kanarip> that is, if you are using the default interval of 30 minutes
  Nov 09 18:21:10 <kanarip> sorry, should have said: at most 30.9 minutes after you apply changes,
  the puppet will have picked up the changes
  Nov 09 18:21:33 <kanarip> so here's how the puppetmaster distinguishes configuration to be applied to one
  node: http://git.puppetmanaged.org/?p=domain-kanarip.com;a=blob;f=puppet/manifests/nodes/anakin.kanarip.com.pp
  Nov 09 18:21:46 <daMaestro> is there any way to push changes? or is it all pull operations?
  Nov 09 18:21:56 <daMaestro> (in the case of needing an isolated DMZ/VLAN)
  Nov 09 18:22:09 <kanarip> the puppetmaster will load that file and know that anakin.kanarip.com which is an
  actual system is to be configured accordingly
  Nov 09 18:22:32 <neverho0d> is there way to stop propagating changes?
  Nov 09 18:22:40 <domg472_> evry 30 minutes sounds like overhead
  Nov 09 18:22:41 <kanarip> daMaestro, puppet provides a utility called puppetrun which tells the client or
  clients to do a puppet run
  Nov 09 18:22:59 <daMaestro> kanarip, yet this is still a pull?
  Nov 09 18:23:02 <kanarip> neverho0d, yes;
  Nov 09 18:23:13 <kanarip> 1) stage your changes in environments
  Nov 09 18:23:14 <neverho0d> kanarip: ok
  Nov 09 18:23:17 <kanarip> 2) stop the puppetmaster
  Nov 09 18:23:23 <kanarip> 3) stop the puppet client daemon
  Nov 09 18:23:30 * daMaestro attempts to not interrupt anymore
  Nov 09 18:23:37 <kanarip> 4) let the puppetmaster not pull from a SCM to load new configuration
  Nov 09 18:23:52 <kanarip> daMaestro, the puppet client will perform a pull from the puppetmaster, yes
  Nov 09 18:24:03 <daMaestro> k
  Nov 09 18:24:28 <kanarip> any other questions so far?
  Nov 09 18:24:38 <kanarip> i'd like to dive into modules, if that's ok?
  Nov 09 18:24:45 <erinlea80> any utilities to automate data/config collections on pre-existing servers?
  Nov 09 18:24:53 <erinlea80> or is it all by hand?
  Nov 09 18:25:38 <kanarip> erinlea80, it's very complex to harvest data and then roll it out but i guess a
  certain scale justifies putting in such effort
  Nov 09 18:25:56 <kanarip> the harvesting would only happen once is what i'm concerned with
  Nov 09 18:26:00 <erinlea80> agreed -- was wondering what the options are.
  Nov 09 18:26:13 <kanarip> so here's a sample module for puppet: http://git.puppetmanaged.org/?p=sudo;a=tree
  Nov 09 18:26:52 <kanarip> a module is a collection of the manifest: manifests/init.pp, the files used by
  that module (in files/), any templates used by the module (in templates/), and more
  Nov 09 18:27:06 <kanarip> http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation for a reference
  Nov 09 18:27:25 <kanarip> and of course there's something mentioned in
  http://www.kanarip.com/courses/puppet/puppet.pdf as well
  Nov 09 18:27:55 <kanarip> what makes modules so great is a couple of things;
  Nov 09 18:28:13 <kanarip> 1) i can share it with you and you can just start using it
  Nov 09 18:28:45 <kanarip> 2) you can customize it and still pull changes from an upstream SCM like the GIT
  repository I just pointed you to and send me/upstream patches
  Nov 09 18:28:55 <kanarip> 3) modules allow "staging"
  Nov 09 18:29:03 <kanarip> i guess the next topic is "staging" ;-)
  Nov 09 18:29:25 <kanarip> 4) modules keep your files, manifests, templates and plugins organized
  Nov 09 18:29:52 <kanarip> believe me when I say puppet configuration trees can become a mess if you start
  managing more and more with puppet, and not use modules
  Nov 09 18:29:58 <kanarip> == Staging ==
  Nov 09 18:30:38 <kanarip> What I mean by staging is simply this; stage your changes from a development
  environment, possibly via a testing environment onto your production environment
  Nov 09 18:31:26 <kanarip> you can develop all you want in your development environment, make syntax errors,
  rm -rf / sorta speak, and never nuke that business critical application server you have running
  Nov 09 18:32:08 <kanarip> then once you're satisfied, you may move the changes into the testing or
  production environment
  Nov 09 18:32:12 <kanarip> does that make sense?
  Nov 09 18:32:21 <nuonguy> oh yeah
  Nov 09 18:32:24 <neverho0d> sure
  Nov 09 18:32:24 <jds2001> yes, but how does one do this in practice?
  Nov 09 18:32:26 <kanarip> awesome
  Nov 09 18:32:26 <erinlea80> mmmm yes
  Nov 09 18:32:42 <erinlea80> and does it require a unique environment for each corresponding production
  environment?
  Nov 09 18:32:43 <kanarip> i can recommend anyone getting his feet wet in using environments
  Nov 09 18:32:48 * nirik has some questions, but can save them for the end as well.
  Nov 09 18:32:49 <erinlea80> unique test environ.
  Nov 09 18:32:52 <kanarip> jds2001, here's a practical example;
  Nov 09 18:33:27 <kanarip> all the repositories you see on http://git.puppetmanaged.org/ have a development,
  a testing, and a production branch
  Nov 09 18:34:10 <kanarip> what i do when i'm satisfied with my developments, is I change the working branch
  to testing, and git pull development
  Nov 09 18:34:40 <kanarip> then when i push, the puppetmaster runs a puppet that is configured so that it
  will pull the changes from the GIT repo
  Nov 09 18:34:57 <jds2001> then you have post-receive hooks to put them someplace?
  Nov 09 18:35:05 <kanarip> http://git.puppetmanaged.org/?p=domain-puppetmanaged.org;a=blob;f=puppet/manifests/nodes/master.puppetmanaged.org.pp
  as a reference
  Nov 09 18:35:28 <kanarip> jds2001, no, the puppetmaster in my case runs a puppet that has ^^ configuration
  applied to itself
  Nov 09 18:36:10 <kanarip> a post-hook making the puppetmaster pull in the changes is a viable solution too;
  the Fedora Project does such
  Nov 09 18:36:25 <kanarip> however, in my situation, the puppetmaster and the SCM are not on the same machine
  Nov 09 18:37:08 <jds2001> ok, makes sense
  Nov 09 18:37:12 <erinlea80> kk
  Nov 09 18:37:14 <kanarip> http://www.kanarip.com/courses/puppet/puppet.odp is a presentation slide-deck BTW,
  that goes along with the .pdf i've already linked
  Nov 09 18:37:38 <kanarip> note that what you see on puppetmanaged.org is heavily dependent on the other
  modules available from puppetmanaged.org
  Nov 09 18:38:43 <kanarip> so... what do you think about setting it up?
  Nov 09 18:39:15 <erinlea80> lets do it?
  Nov 09 18:39:24 <kanarip> there you go ;-)
  Nov 09 18:39:37 <kanarip> let me refer to the documentation i shared earlier because it's a lot to type
  Nov 09 18:39:49 <kanarip> http://www.kanarip.com/courses/PuppetWorkshop-SettingUpPuppet.html
  Nov 09 18:40:21 <kanarip> it's a yum install puppet-server to install it on any Fedora system
  Nov 09 18:40:36 <kanarip> for Red Hat and CentOS, you'll need EPEL configured
  Nov 09 18:40:43 <kanarip> http://fedoraproject.org/wiki/EPEL
  Nov 09 18:40:56 * erinlea80 nods
  Nov 09 18:41:26 <kanarip> for anyone who's wondering about what EPEL is... I maintain or co-maintain the
  entire Ruby stack to puppet in that repository ;-)
  Nov 09 18:41:49 <kanarip> and that brings me to one more nifty feature of puppet;
  Nov 09 18:42:08 <kanarip> but first... facts!
  Nov 09 18:42:17 <kanarip> facts are... well... facts...
  Nov 09 18:42:33 <kanarip> little information about the current state of a client
  Nov 09 18:43:02 <kanarip> it includes the kernel version, number of network interfaces, the architecture,
  operating system name, operating system version, and lots more
  Nov 09 18:43:16 <kanarip> yum install facter and run "facter" on your machine to check it out
  Nov 09 18:43:38 <kanarip> these are all "variables" you can use in your puppet manifests
  Nov 09 18:44:09 <kanarip> given a small amount of RAM for example, you may want to apply a snippet similar
  to: package { "firefox": ensure => absent }
  Nov 09 18:44:35 <kanarip> anyway, what i really wanted to say rather then to give a rant on firefox's memory
  consumption is this;
  Nov 09 18:44:52 <kanarip> facts, types and providers, these things that make puppet do smart things...
  Nov 09 18:45:01 <kanarip> facts for information about the client...
  Nov 09 18:45:09 <erinlea80> do we have a sample facter output?
  Nov 09 18:45:21 <kanarip> i could fpaste you some
  Nov 09 18:45:35 <erinlea80> that would be great :)
  Nov 09 18:45:53 <zcat> kanarip, is facter supposed to spit out "virtual => vmware_server" if detected?
  Nov 09 18:45:56 <domg472_> creating new ones doesnt look that easy
  Nov 09 18:46:10 <kanarip> http://fpaste.org/paste/15
  Nov 09 18:46:41 <domg472_> but theres good documentation on create types fact etc
  Nov 09 18:46:45 <kanarip> types to define resources to be managed on the puppet...
  Nov 09 18:47:00 <erinlea80> thanks
  Nov 09 18:47:03 <kanarip> and providers to make puppet speak the local language...
  Nov 09 18:47:14 <kanarip> the great thing is... you can write your own for all of these
  Nov 09 18:47:53 <kanarip> it does require ruby knowledge, but then again... there's sample recipes on
  reductivelabs.com for...for example zcat, a vmware custom fact ;-)
  Nov 09 18:47:59 <kanarip> see, i was getting there ;-)
  Nov 09 18:48:22 <kanarip> actually i think the custom fact is called "this is a vmware machine" and
  "whether it has vm-tools installed"
  Nov 09 18:48:59 <kanarip> one more thing i really, really need to stress out to you
  Nov 09 18:49:17 <kanarip> all communication between the puppet and it's puppetmaster is *secure*
  Nov 09 18:49:45 * nirik has one of his questions answered. ;)
  Nov 09 18:50:02 <kanarip> that being said, the security is based on the puppetmaster running the
  Certificate Authority, the client generating a certificate and putting in a request with the puppetmaster
  to get a signed copy of that certificate
  Nov 09 18:50:05 <erinlea80> can communication be tunneled over ssh if necessary? (firewall restrictions, etc.)
  Nov 09 18:50:11 <domg472_> but the puppets have root access obviously?
  Nov 09 18:50:18 <domg472_> and the master
  Nov 09 18:50:22 <kanarip> erinlea80, you can make the puppetmaster run on any port you want
  Nov 09 18:50:43 <kanarip> erinlea80, may i point out "autossh" with which you can create tunnels to
  communicate over if you wish
  Nov 09 18:50:49 <erinlea80> ty :)
  Nov 09 18:51:01 <kanarip> domg472_, the puppet client daemon runs with root privileges, yes
  Nov 09 18:51:16 <domg472_> has anyone tested this with selinux?
  Nov 09 18:51:16 <kanarip> domg472_, the master runs with under the puppet user
  Nov 09 18:51:51 <domg472_> ok thanks
  Nov 09 18:52:20 <kanarip> domg472_, i have, and i can tell you it requires a custom selinux policy in
  which you basically describe the puppet daemon can do this and that and more
  Nov 09 18:52:31 <kanarip> in my case, the puppet daemon can do anything it likes
  Nov 09 18:52:45 <domg472_> youd need custom modules i bet
  Nov 09 18:52:58 <domg472_> interesting
  Nov 09 18:53:21 <sdodson> There are also a few minor bugs which I think have been fixed recently where
  puppet creates files without the proper contexts.
  Nov 09 18:53:34 <kanarip> selinux is being integrated better into puppet as we speak
  Nov 09 18:53:39 <domg472_> great
  Nov 09 18:53:49 <kanarip> it's a big issue, i concur
  Nov 09 18:53:54 <nuonguy> Q: if I enable, for example httpd in a manifest, and 2 hours later comment it out,
  does the puppet uninstall/disable httpd or ignore it from then on?
  Nov 09 18:54:17 <kanarip> nuonguy, puppet only applies changes
  Nov 09 18:54:34 <kanarip> nuonguy, so it only enforces what you describe needs to happen
  Nov 09 18:54:46 <kanarip> if you say package httpd should be installed at one point
  Nov 09 18:54:46 <nuonguy> so I'd have to explicity turn it off, if that's what I meant?
  Nov 09 18:55:20 <kanarip> and then comment that out... no other machine is going to care whether the package
  should be installed, but it's not going to be removed on puppet's behalf
  Nov 09 18:55:26 <kanarip> nuonguy, yes
  Nov 09 18:55:37 <nuonguy> I dig, thanks
  Nov 09 18:56:00 <kanarip> nuonguy, same goes for the service type; ensure => running, enable => true would
  need to become ensure => stopped, enable => false
  Nov 09 18:56:10 <nuonguy> precisely
  Nov 09 18:56:22 <nuonguy> I can just see myself not remembering that...
  Nov 09 18:56:33 <kanarip> so, another thing on the topic; what do you think happens if the puppet daemon
  cannot contact the puppetmaster?
  Nov 09 18:56:34 <nuonguy> and commenting it out instead
  Nov 09 18:56:56 <nirik> does it do them in order in the manifest? ie, make sure to stop before ensure
  absent?
  Nov 09 18:57:08 <kanarip> nuonguy, there's some discussion going on about supporting an "exclude" statement
  like we do "include webserver" now
  Nov 09 18:57:18 <nuonguy> nice
  Nov 09 18:57:24 <kanarip> nuonguy, and then flipping all the false's into true's and so forth
  Nov 09 18:57:37 <kanarip> nirik, good point!
  Nov 09 18:57:41 <sdodson> Could create a baseline that ensures none of that is installed/running then
  include webserver for only your webservers which would override those baselines?
  Nov 09 18:57:46 <kanarip> puppet allows ordering the resources;
  Nov 09 18:57:52 <kanarip> let me look you up an example
  Nov 09 18:58:55 <domg472_> why was ruby chosen as the language for writing types etc?
  Nov 09 18:59:05 <domg472_> why not bash?
  Nov 09 18:59:42 <kanarip> here's a yp manifest: http://fpaste.org/paste/16
  Nov 09 19:00:21 <kanarip> domg472_, i'm not sure i'm not one of the core developers, but i can try and
  answer it if you promise not to quote me on it ;-)
  Nov 09 19:00:32 <domg472_> hah ok
  Nov 09 19:00:40 <domg472_> i think most sysadmins know bash
  Nov 09 19:00:49 <kanarip> nirik, you can see how "require => (...)" in that yp manifest causes one resource
  to be dependent on another
  Nov 09 19:00:59 <domg472_> and they will need to write custom types probably
  Nov 09 19:01:51 <kanarip> domg472_, i think bash is what you use to do a quick thing, clean and simple.
  I think ruby allows a framework to be built, reusing snippets of code you've already written in a different
  place. I think ruby is more modular then is bash
  Nov 09 19:02:06 <domg472_> ok thanks
  Nov 09 19:02:16 <kanarip> you could write a website in bash but you won't, right?
  Nov 09 19:02:21 <domg472_> i guess ill be learning ruby then
  Nov 09 19:02:23 <domg472_> true
  Nov 09 19:02:33 <domg472_> but these are simplate admin tasks
  Nov 09 19:02:40 <domg472_> simple
  Nov 09 19:02:42 <kanarip> not saying you should choose php to do it BTW ;-)
  Nov 09 19:02:56 * nirik notes we are over time, but this is also the last class today.
  Nov 09 19:03:18 <kanarip> in puppet terms; distribute the bash scripts amongst the clients that need it
  using the file type, and exec that script
  Nov 09 19:03:24 <nirik> I had one last question: how do you decide what should be in a module? whats the
  logical boundry there?
  Nov 09 19:03:36 <kanarip> anything you;
  Nov 09 19:03:42 <domg472_> ah right, thanks kanarip
  Nov 09 19:03:47 <kanarip> 1) pull from an upstream source
  Nov 09 19:04:00 <kanarip> 2) need to share (with the general public)
  Nov 09 19:04:11 <kanarip> 3) want to stage
  Nov 09 19:04:33 <nirik> so it doesn't need to be a specific service or anything? just whatever you want
  to put in one?
  Nov 09 19:04:38 <kanarip> 4) that is a concise set of files, manifests, etc.
  Nov 09 19:04:57 <sdodson> They're advising people to get away from writing classes and move towards modules.
  Nov 09 19:05:04 <kanarip> nirik, you're almost right, a module called everything-else doesn't make sense ;-)
  Nov 09 19:05:12 <kanarip> sdodson, yes, very much so
  Nov 09 19:05:51 <kanarip> nirik, a module webserver makes sense; keeping it close and concise within a
  module is way easier then dispersing it all over the place
  Nov 09 19:06:12 <nirik> ok, makes sense.
  Nov 09 19:06:27 <tmz> domg472_: regarding why ruby was used to write puppet, here's a short interview with
  Luke Kanies (primary puppet author),  where he touches on that choice:
  Nov 09 19:06:31 <tmz> http://on-ruby.blogspot.com/2008/02/puppet-interview-with-luke-kanies.html
  Nov 09 19:06:40 <domg472_> thanks
  Nov 09 19:06:46 <kanarip> what i tend to recommend to customers is also, to keep the systems they manage as
  consistent as possible
  Nov 09 19:07:20 <kanarip> being able to determine the exceptions to the rule you've layed down saves you a
  lot of time in determining what the cause might be for a specific issue
  Nov 09 19:08:11 <nirik> shall we wrap up and let kanarip get some sleep?
  Nov 09 19:08:17 <kanarip> ;-)
  Nov 09 19:08:23 <daMaestro> no, no sleep for kanarip !
  Nov 09 19:08:34 <kanarip> thank you all for your interest, and thank you for attending
  Nov 09 19:08:37 * daMaestro /dcc kanarip latte
  Nov 09 19:08:38 <jds2001> he must stay up all night!
  Nov 09 19:08:41 <nirik> thanks so much for the session kanarip !
  Nov 09 19:08:42 <erinlea80> thanks kanarip!
  Nov 09 19:08:46 <domg472_> thanks again
  Nov 09 19:08:47 <erinlea80> :)
  Nov 09 19:08:49 <iondrip> thanks
  Nov 09 19:08:53 <kanarip> i hope you find a lot of use in the pdf/html/odp i've given you ;-)
  Nov 09 19:08:57 <neverho0d> kanarip: thanks
  Nov 09 19:09:04 <nirik> thanks everyone for coming...
  Nov 09 19:09:08 <Bugz_> kanarip: Thanks
  Nov 09 19:09:15 <erinlea80> :)
  Nov 09 19:09:31 <domg472_> thanks for hosting
  Nov 09 19:09:57 <SSlater> Thanks


[[Category:Classroom]]
[[Category:Classroom|Puppet]]

Latest revision as of 18:14, 7 December 2008

Fedora Classroom - Configuration Management using Puppet - Jeroen van Meeuwen - Sunday, November 9, 2008

IRC Log of the Class

kanarip so this session is about configuration management, which does *not* include the soft side of configuration management for a change 23:04
*Bugz_ is 23:04
kanarip we're *not* going to talk about procedural issues, but keep it on the technical side 23:04
kanarip i'd like to invite you all to take a look at http://www.kanarip.com/courses/puppet/puppet.pdf 23:04
kanarip which is a nice reader i wrote for a one-day workshop i'm giving on this topic, and that is commercially available 23:04
kanarip community people like us however *do not have to pay* 23:04
kanarip sounds great, huh? ;-) 23:04
domg472_ yes 23:04
erinlea80 :) 23:04
delhage from Delft eh? 23:04
kanarip so, a little something on configuration management first, then a sneak peak at the installation of puppet, and a quick howto on writing your "manifest" as they call the puppet configuration syntax 23:04
kanarip delhage, Utrecht 23:04
delhage ok 23:04
kanarip so, what is it we would want to do with configuration management in the technical sense of the words 23:04
kanarip we all know that the more systems we need to maintain, the harder it becomes to keep some extend of consistency between different systems 23:04
kanarip some organizations use scripts from an NFS share, or use an SVN tree with scripts periodically updated and execute scripts 23:05
kanarip does that sound familiar to anyone? 23:05
*erinlea80 nods 23:05
kanarip so what happens in these cases is: 23:05
kanarip 1) your scripts tend to get very large 23:05
kanarip describing every unique situation, every exemption, every update, for every operating system, distribution, distribution version, makes the script less maintainable 23:05
kanarip 2) your scripts are executed at arbitrary intervals 23:06
kanarip either a cronjob, on boot, may or may not fail, and you cannot make the changes you want pronto 23:06
kanarip 3) your scripts replace configuration and reconfigure stuff without actual changes being applied 23:06
kanarip either of these 3 things cries out for a configuration management like... 23:07
kanarip Puppet (or CFEngine) 23:07
kanarip anyone heard of CFEngine before? 23:07
delhage yup 23:07
jds2001 however cfengine is fail 23:07
jds2001 we use it :) 23:07
kanarip jds2001, you're in the right spot ;-) 23:07
kanarip what CFEngine does is very accurately describe the configuration state a system has to be in 23:08
kanarip it does it so accurately, in fact, that it ends up being a very low-level tool 23:08
kanarip to give you an example; 23:08
kanarip in CFEngine, to install a package called foo, you will have to manually assign a package provider to each operating system, distribution or distribution version, and then use that provider to install the package 23:09
kanarip in addition, you would need to change the name for each OS, distro and distribution version 23:09
kanarip lots to type, lots to care about, while in fact all you care about is that the package is installed 23:10
*kanarip introduces... the high-level abstraction of Puppet 23:10
kanarip no matter what the operating system, distribution or distribution may be, Puppet speaks the local language 23:10
kanarip it'll figure out on it's own whether to use yum, up2date, dpkg, apt, PackageKit, alien, smart, rpm or what-package-manager-have-you 23:11
kanarip this way, ensuring that package foo is installed on a system becomes: 23:11
kanarip package { "foo": 23:11
kanarip ensure => installed 23:11
kanarip } 23:11
kanarip and you're done 23:11
kanarip jds2001, can you confirm that is easier then CFEngine please? ;-) 23:11
jds2001 yes :) 23:12
kanarip thanks ;-) 23:12
kanarip so, how does puppet work? 23:12
kanarip given these abstracted "system resources" such as packages, services, cronjobs, users, ..., this and that and more, puppet uses so-called "types" you can use in a configuration "manifest" to describe what state a managed system should be in 23:13
kanarip here's a list of types: http://reductivelabs.com/trac/puppet/wiki/TypeReference 23:13
kanarip now let me describe to you what a working setup looks like; 23:14
kanarip there is a single server, called the puppetmaster 23:15
kanarip personally i think the puppeteer would have been a more appropriate name, but puppetmaster it is 23:15
kanarip the managed system is called a "puppet" - whos strings you can pull using the puppetmaster 23:15
kanarip the puppet, or managed system, polls the puppetmaster at a default interval of every 30 minutes 23:16
kanarip the puppetmaster, having *all* the configuration for *all* nodes in an environment, will parse *all* it's manifests, and send to the puppet a set of resources to be managed on that specific node 23:17
nirik Q: do they all pull at once? or is it staggered? 23:17
kanarip nirik, it depends on the time at which the puppet starts counting 23:17
kanarip it has a default 1 minute randomization i believe 23:17
kanarip but it'll poll at least once every 30.9 minutes, if that makes sense ;-) 23:18
domg472_ why does it do that? 23:18
kanarip to check if there's any changes to the configuration for the node 23:19
domg472_ if yo have changes on the master can you just tell it to push them? 23:19
domg472_ ok thanks 23:19
kanarip if you change anything, you let the master pick it up and at most 59 later the puppet will have picked up on the changes 23:20
kanarip that is, if you are using the default interval of 30 minutes 23:20
kanarip sorry, should have said: at most 30.9 minutes after you apply changes, puppet will have picked up the changes 23:21
kanarip so here's how the puppetmaster distinguishes configuration to be applied to one node: http://git.puppetmanaged.org/?p=domain-kanarip.com;a=blob;f=puppet/manifests/nodes/anakin.kanarip.com.pp 23:21
daMaestro is there any way to push changes? or is it all pull operations? 23:21
daMaestro (in the case of needing an isolated DMZ/VLAN) 23:21
kanarip the puppetmaster will load that file and know that anakin.kanarip.com which is an actual system is to be configured accordingly 23:22
neverho0d is there way to stop propagating changes? 23:22
domg472_ evry 30 minutes sounds like overhead 23:22
kanarip daMaestro, puppet provides a utility called puppetrun which tells the client or clients to do a puppet run 23:22
daMaestro kanarip, yet this is still a pull? 23:22
kanarip neverho0d, yes; 23:23
kanarip 1) stage your changes in environments 23:23
neverho0d kanarip: ok 23:23
kanarip 2) stop the puppetmaster 23:23
kanarip 3) stop the puppet client daemon 23:23
*daMaestro attempts to not interrupt anymore 23:23
kanarip 4) let the puppetmaster not pull from a SCM to load new configuration 23:23
kanarip daMaestro, the puppet client will perform a pull from the puppetmaster, yes 23:23
daMaestro k 23:24
kanarip any other questions so far? 23:24
kanarip i'd like to dive into modules, if that's ok? 23:24
erinlea80 any utilities to automate data/config collections on pre-existing servers? 23:24
erinlea80 or is it all by hand? 23:24
kanarip erinlea80, it's very complex to harvest data and then roll it out but i guess a certain scale justifies putting in such effort 23:25
kanarip the harvesting would only happen once is what i'm concerned with 23:25
erinlea80 agreed -- was wondering what the options are. 23:26
kanarip so here's a sample module for puppet: http://git.puppetmanaged.org/?p=sudo;a=tree 23:26
kanarip a module is a collection of the manifest: manifests/init.pp, the files used by that module (in files/), any templates used by the module (in templates/), and more 23:26
kanarip http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation for a reference 23:27
kanarip and of course there's something mentioned in http://www.kanarip.com/courses/puppet/puppet.pdf as well 23:27
kanarip what makes modules so great is a couple of things; 23:27
kanarip 1) i can share it with you and you can just start using it 23:28
kanarip 2) you can customize it and still pull changes from an upstream SCM like the GIT repository I just pointed you to and send me/upstream patches 23:28
kanarip 3) modules allow "staging" 23:28
kanarip i guess the next topic is "staging" ;-) 23:29
kanarip 4) modules keep your files, manifests, templates and plugins organized 23:29
kanarip believe me when I say puppet configuration trees can become a mess if you start managing more and more with puppet, and not use modules 23:29
kanarip == Staging == 23:29
kanarip What I mean by staging is simply this; stage your changes from a development environment, possibly via a testing environment onto your production environment 23:30
kanarip you can develop all you want in your development environment, make syntax errors, rm -rf / sorta speak, and never nuke that business critical application server you have running 23:31
kanarip then once you're satisfied, you may move the changes into the testing or production environment 23:32
kanarip does that make sense? 23:32
nuonguy oh yeah 23:32
neverho0d sure 23:32
jds2001 yes, but how does one do this in practice? 23:32
kanarip awesome 23:32
erinlea80 mmmm yes 23:32
erinlea80 and does it require a unique environment for each corresponding production environment? 23:32
kanarip i can recommend anyone getting his feet wet in using environments 23:32
*nirik has some questions, but can save them for the end as well. 23:32
erinlea80 unique test environ. 23:32
kanarip jds2001, here's a practical example; 23:32
kanarip all the repositories you see on http://git.puppetmanaged.org/ have a development, a testing, and a production branch 23:33
kanarip what i do when i'm satisfied with my developments, is I change the working branch to testing, and git pull development 23:34
kanarip then when i push, the puppetmaster runs a puppet that is configured so that it will pull the changes from the GIT repo 23:34
jds2001 then you have post-receive hooks to put them someplace? 23:34
kanarip http://git.puppetmanaged.org/?p=domain-puppetmanaged.org;a=blob;f=puppet/manifests/nodes/master.puppetmanaged.org.pp as a reference 23:35
kanarip jds2001, no, the puppetmaster in my case runs a puppet that has ^^ configuration applied to itself 23:35
kanarip a post-hook making the puppetmaster pull in the changes is a viable solution too; the Fedora Project does such 23:36
kanarip however, in my situation, the puppetmaster and the SCM are not on the same machine 23:36
jds2001 ok, makes sense 23:37
erinlea80 kk 23:37
kanarip http://www.kanarip.com/courses/puppet/puppet.odp is a presentation slide-deck BTW, that goes along with the .pdf i've already linked 23:37
kanarip note that what you see on puppetmanaged.org is heavily dependent on the other modules available from puppetmanaged.org 23:37
kanarip so... what do you think about setting it up? 23:38
erinlea80 lets do it? 23:39
kanarip there you go ;-) 23:39
kanarip let me refer to the documentation i shared earlier because it's a lot to type 23:39
kanarip http://www.kanarip.com/courses/PuppetWorkshop-SettingUpPuppet.html 23:39
kanarip it's a yum install puppet-server to install it on any Fedora system 23:40
kanarip for Red Hat and CentOS, you'll need EPEL configured 23:40
kanarip http://fedoraproject.org/wiki/EPEL 23:40
*erinlea80 nods 23:40
kanarip for anyone who's wondering about what EPEL is... I maintain or co-maintain the entire Ruby stack to puppet in that repository ;-) 23:41
kanarip and that brings me to one more nifty feature of puppet; 23:41
kanarip but first... facts! 23:42
kanarip facts are... well... facts... 23:42
kanarip little information about the current state of a client 23:42
kanarip it includes the kernel version, number of network interfaces, the architecture, operating system name, operating system version, and lots more 23:43
kanarip yum install facter and run "facter" on your machine to check it out 23:43
kanarip these are all "variables" you can use in your puppet manifests 23:43
kanarip given a small amount of RAM for example, you may want to apply a snippet similar to: package { "firefox": ensure => absent } 23:44
kanarip anyway, what i really wanted to say rather then to give a rant on firefox's memory consumption is this; 23:44
kanarip facts, types and providers, these things that make puppet do smart things... 23:44
kanarip facts for information about the client... 23:45
erinlea80 do we have a sample facter output? 23:45
kanarip i could fpaste you some 23:45
erinlea80 that would be great :) 23:45
zcat kanarip, is facter supposed to spit out "virtual => vmware_server" if detected? 23:45
domg472_ creating new ones doesnt look that easy 23:45
kanarip http://fpaste.org/paste/15 23:46
domg472_ but theres good documentation on create types fact etc 23:46
kanarip types to define resources to be managed on the puppet... 23:46
erinlea80 thanks 23:47
kanarip and providers to make puppet speak the local language... 23:47
kanarip the great thing is... you can write your own for all of these 23:47
kanarip it does require ruby knowledge, but then again... there's sample recipes on reductivelabs.com for...for example zcat, a vmware custom fact ;-) 23:47
kanarip see, i was getting there ;-) 23:47
kanarip actually i think the custom fact is called "this is a vmware machine" and "whether it has vm-tools installed" 23:48
kanarip one more thing i really, really need to stress out to you 23:48
kanarip all communication between the puppet and it's puppetmaster is *secure* 23:49
*nirik has one of his questions answered. ;) 23:49
kanarip that being said, the security is based on the puppetmaster running the Certificate Authority, the client generating a certificate and putting in a request with the puppetmaster to get a signed copy of that certificate 23:50
erinlea80 can communication be tunneled over ssh if necessary? (firewall restrictions, etc.) 23:50
domg472_ but the puppets have root access obviously? 23:50
domg472_ and the master 23:50
kanarip erinlea80, you can make the puppetmaster run on any port you want 23:50
kanarip erinlea80, may i point out "autossh" with which you can create tunnels to communicate over if you wish 23:50
erinlea80 ty :) 23:50
kanarip domg472_, the puppet client daemon runs with root privileges, yes 23:51
domg472_ has anyone tested this with selinux? 23:51
kanarip domg472_, the master runs with under the puppet user 23:51
domg472_ ok thanks 23:51
kanarip domg472_, i have, and i can tell you it requires a custom selinux policy in which you basically describe the puppet daemon can do this and that and more 23:52
kanarip in my case, the puppet daemon can do anything it likes 23:52
domg472_ youd need custom modules i bet 23:52
domg472_ interesting 23:52
sdodson There are also a few minor bugs which I think have been fixed recently where puppet creates files without the proper contexts. 23:53
kanarip selinux is being integrated better into puppet as we speak 23:53
domg472_ great 23:53
kanarip it's a big issue, i concur 23:53
nuonguy Q: if I enable, for example httpd in a manifest, and 2 hours later comment it out, does the puppet uninstall/disable httpd or ignore it from then on? 23:53
kanarip nuonguy, puppet only applies changes 23:54
kanarip nuonguy, so it only enforces what you describe needs to happen 23:54
kanarip if you say package httpd should be installed at one point 23:54
nuonguy so I'd have to explicity turn it off, if that's what I meant? 23:54
kanarip and then comment that out... no other machine is going to care whether the package should be installed, but it's not going to be removed on puppet's behalf 23:55
kanarip nuonguy, yes 23:55
nuonguy I dig, thanks 23:55
kanarip nuonguy, same goes for the service type; ensure => running, enable => true would need to become ensure => stopped, enable => false 23:56
nuonguy precisely 23:56
nuonguy I can just see myself not remembering that... 23:56
kanarip so, another thing on the topic; what do you think happens if the puppet daemon cannot contact the puppetmaster? 23:56
nuonguy and commenting it out instead 23:56
nirik does it do them in order in the manifest? ie, make sure to stop before ensure 23:56
kanarip nuonguy, there's some discussion going on about supporting an "exclude" statement like we do "include webserver" now 23:57
nuonguy nice 23:57
kanarip nuonguy, and then flipping all the false's into true's and so forth 23:57
kanarip nirik, good point! 23:57
sdodson Could create a baseline that ensures none of that is installed/running then include webserver for only your webservers which would override those baselines? 23:57
kanarip puppet allows ordering the resources; 23:57
kanarip let me look you up an example 23:57
domg472_ why was ruby chosen as the language for writing types etc? 23:58
domg472_ why not bash? 23:59
kanarip here's a yp manifest: http://fpaste.org/paste/16 23:59
kanarip domg472_, i'm not sure i'm not one of the core developers, but i can try and answer it if you promise not to quote me on it ;-) 00:00
domg472_ hah ok 00:00
domg472_ i think most sysadmins know bash 00:00
kanarip nirik, you can see how "require => (...)" in that yp manifest causes one resource to be dependent on another 00:00
domg472_ and they will need to write custom types probably 00:00
kanarip domg472_, i think bash is what you use to do a quick thing, clean and simple. I think ruby allows a framework to be built, reusing snippets of code you've already written in a different place. I think ruby is more modular then is bash 00:01
domg472_ ok thanks 00:02
kanarip you could write a website in bash but you won't, right? 00:02
domg472_ i guess ill be learning ruby then 00:02
domg472_ true 00:02
domg472_ but these are simplate admin tasks 00:02
domg472_ simple 00:02
kanarip not saying you should choose php to do it BTW ;-) 00:02
*nirik notes we are over time, but this is also the last class today. 00:02
kanarip in puppet terms; distribute the bash scripts amongst the clients that need it using the file type, and exec that script 00:03
nirik I had one last question: how do you decide what should be in a module? whats the logical boundry there? 00:03
kanarip anything you; 00:03
domg472_ ah right, thanks kanarip 00:03
kanarip 1) pull from an upstream source 00:03
kanarip 2) need to share (with the general public) 00:04
kanarip 3) want to stage 00:04
nirik so it doesn't need to be a specific service or anything? just whatever you want to put in one? 00:04
kanarip 4) that is a concise set of files, manifests, etc. 00:04
sdodson They're advising people to get away from writing classes and move towards modules. 00:04
kanarip nirik, you're almost right, a module called everything-else doesn't make sense ;-) 00:05
kanarip sdodson, yes, very much so 00:05
kanarip nirik, a module webserver makes sense; keeping it close and concise within a module is way easier then dispersing it all over the place 00:05
nirik ok, makes sense. 00:06
tmz domg472_: regarding why ruby was used to write puppet, here's a short interview with Luke Kanies (primary puppet author), where he touches on that choice: 00:06
tmz http://on-ruby.blogspot.com/2008/02/puppet-interview-with-luke-kanies.html 00:06
domg472_ thanks 00:06
kanarip what i tend to recommend to customers is also, to keep the systems they manage as consistent as possible 00:06
kanarip being able to determine the exceptions to the rule you've layed down saves you a lot of time in determining what the cause might be for a specific issue 00:07
nirik shall we wrap up and let kanarip get some sleep? 00:08
kanarip ;-) 00:08
daMaestro no, no sleep for kanarip ! 00:08
kanarip thank you all for your interest, and thank you for attending 00:08
*daMaestro /dcc kanarip latte 00:08
jds2001 he must stay up all night! 00:08
nirik thanks so much for the session kanarip ! 00:08
erinlea80 thanks kanarip! 00:08
domg472_ thanks again 00:08
erinlea80 :) 00:08
iondrip thanks 00:08
kanarip i hope you find a lot of use in the pdf/html/odp i've given you ;-) 00:08
neverho0d kanarip: thanks 00:08
nirik thanks everyone for coming... 00:09
Bugz_ kanarip: Thanks 00:09
erinlea80 :) 00:09
domg472_ thanks for hosting 00:09
SSlater Thanks 00:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!