From Fedora Project Wiki
mNo edit summary |
mNo edit summary |
||
(3 intermediate revisions by 2 users not shown) | |||
Line 3: | Line 3: | ||
==== IRC Log of the Class ==== | ==== IRC Log of the Class ==== | ||
{| | |||
|- 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 => 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 => 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 => 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 => running, enable => true would need to become ensure => stopped, enable => 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 => (...)" 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]! | |||
[[Category:Classroom|Puppet]] | |||
[[Category:Classroom]] |
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!