On Wednesday, November 6, 2013 11:32:09 PM UTC-6, Salient Digital wrote: > > Thanks in advance for your advice. > > I'm a beginner running puppet on 1 server running Debian Wheezy following > along with the Learning docs. > > Is this configuration what is referred to "masterless"? If so, it seems > "agent less" would make more sense to me, I'm just curious if I understand > the terminology correctly. In this setup, do I need to use agent? >
Master and agent work together. If you are not using a master then you cannot use the agent -- instead of "puppet agent" you use "puppet apply". The latter approach is referred to as "masterless". Masterless mode is thus also agent-less, but the former term emphasizes that that mode does not rely on any external machine, which is its the most important characteristic. > > I've managed to install some modules from Puppet forge, eg., > puppetlabs-mysql … and see they have gone to /etc/puppet/ - are these meant > to be overridden by copies I put in to my local configuration? > Specifically, the blank init.pp? Or, should I just make changes to the one > in the module folder? > > Well, the idea and hope of third-party modules is that users should not need to modify them. A blank init.pp file in a module obtained from the forge is meant to be that way (or else is a bug); do not interpret its blankness as the mark of an extension point. You use modules by declaring their classes classes and resource types to be in the target node's configuration, and you customize for your site (within the dimensions anticipated by the module) via the classes' and resources' parameters. I would recommend recording site-specific data in an hiera data store to keep data separate from your manifests, but you do have the alternative of using parameterized-style class declaration syntax instead. Separating data from manifests may be less important if your manifests are machine-specific anyway, as can be the case in masterless mode. > I'm immediately wanting to put my changes into revision control. > > Would I be better off cloning or forking existing modules on Github, e.g. > https://github.com/puppetlabs/puppetlabs-mysql in this case? > > Well that's entirely a question of your intentions. Do you intend to modify the module for your own internal purposes only? Then you have many alternatives, but I suggest just making a local git clone of the module repository, perhaps even into the appropriate spot in your module path. There is a lower barrier to using git here, but you could also use any other version-control system. Are you planning to make changes that you hope will be accepted by the module maintainers? Then make a *local* git clone of the module repository, apply the changes, and then submit a pull request to the maintainer. It will be by far easiest to stick with git in this case. Do you really have some reason to create a public fork of the module? Then do whatever you think best. > When should I put something into site.pp vs a module's init.pp (that I > forked/modified), vs some custom file location? > > The only thing that should ever go into a module's init.pp is a class having the same name as the module. If the module contains such a class then it should go into init.pp; otherwise, init.pp should be blank or absent. > Ultimately I want to manage a LAMP environment in EC2. Where in the > puppetlabs/mysql module is the version number of the server defined? Same > question for puppetlabs/apache and PHP with the extensions I need, e.g. > mcrypt, memcache, etc. > > I've installed LAMP stack software so many times, I know how I would do it > manually, but I'm having trouble understanding where versions and > dependencies get defined for a puppet-managed install of these softwares. > > Those details are in the realm of *using* the appropriate modules. Any need to modify the modules to achieve those objectives constitutes an inadequacy in the module. There are docs on general module use at http://docs.puppetlabs.com/puppet/3/reference/modules_fundamentals.html#using-modules, but for module-specific usage details, you should refer to the module documentation. However, in order to understand the documentation, it would be well to get a firm grasp on Puppet fundamentals. The language reference is actually a relatively easy read (or so I've always thought); it starts here: http://docs.puppetlabs.com/puppet/3/reference/lang_summary.html. Generally speaking, you will find that modules rely on packaged software, preferably obtainable from a repository. For Debian, that means .deb packages and (probably) apt. In that paradigm, you control software versions via which package is installed. In the case of PuppetLabs's mysql module in particular, you would set a specific package version via the 'package_ensure' parameter to class mysql::server. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/686c8ef8-09a2-4a0b-860e-53046261f022%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
