Objects matching the expression 'documentation'

• #480 Language Reference? is gone from wiki (documentation, language, languagereference, reference)
• #481 "Introduction to Puppet" link bad (documentation)
• #513 explicitly document "backup" possibilities in pfile.rb [PATCH] (documentation)
• #535 Provider development should be documented (documentation)
• #713 [DOC] add a word about multiple dependencies with the require parameter (documentation, require)
• #783 unclear formatting of method names (documentation, methods)
• #879 What triggers an Exec when it has "refreshonly" set to true? (documentation, exec, notify, refreshonly, subscribe)
• #979 documementation fixes - type and configuraton (code, documentation, pkgdmg)
• #980 Minor documentation fix for nagios_maker (documentation, nagios)
• #1004 Documentation fixes for restructured text - puppetrun and ralsh (documentation, puppetrun, ralsh, rst)
• #1068 Minor doco fix (documentation, exec)
• #1171 Updates to rrdgraph documentation (documentation, rrdgraph)
• BetterDebugging (development, documentation, planned)
• BranchTesting Testing against a Branch Revision (change, control, documentation, management, subversion, svn, version)
• CertificatesAndSecurity Certificates and Security (certificates, documentation, security)
• CodeNames Puppet code names (development, documentation, download, package, planned, puppet)
• CommunityRoles (community, documentation, people, roles)
• CompleteResourceExample This document walks through the definition of a very simple resource type and one provider. We'll build the resource up slowly, and the provider along with it. See CreatingCustomTypes Creating Custom Types:trac: and ProviderDevelopment Provider Development:trac: for more information on the individual classes. Resource Creation ----------------- Any reasonable resource needs to be able to be created and destroyed, and resources have to have names, so we'll start with those two features. Puppet's property support has a helper method called ensurable that handles modeling creation and destruction; it creates an ensure property and adds absent and present values for it, which in turn require three methods on the provider, create, destroy, and exists?. Here's the first start to the resource:: Puppet::Type.newtype(:file) do @doc (documentation, example, providers, types)
• ConfigurationReference **This page is autogenerated; any changes will get overwritten** *(last generated on Wed Aug 20 18:39:30 +0200 2008)* .. contents:: :depth: 1 Specifying Configuration Parameters ----------------------------------- On The Command-Line +++++++++++++++++++ Every Puppet executable (with the exception of puppetdoc) accepts all of the parameters below, but not all of the arguments make sense for every executable. Each parameter has a section listed with it in parentheses; often, that section will map to an executable (e.g., puppetd), in which case it probably only makes sense for that one executable. If main is listed as the section, it is most likely an option that is valid for everyone. I have tried to be as thorough as possible in the descriptions of the arguments, so it should be obvious whether an argument is appropriate or not. These parameters can be supplied to the executables either as command-line options or in the configuration file. For instance, the command-line invocation below would set the configuration directory to /private/puppet:: $ puppetd --confdir (documentation, reference)
• ConfigurationVersion (development, documentation, planned)
• ConvertFromXmlrpcToRest * Use REST for all communication, instead of XMLRPC, to eliminate the encoding/escaping overhead of XMLRPC and simplify the process of integrating with other services * Retain the ability for a given network service to be used locally or remotely * Simplify creating new services and new termini for those services. Secondary Goals --------------- * Allow direct file serving by the external web servers, rather than forcing Puppet's server to handle all files (e.g., when using Mongrel behind Apache, we should be able to allow Apache to serve the files, rather than sending those requests to Mongrel) Terminology (development, documentation, inprogress, rest, xmlrpc)
• CreatingCustomTypes (If this page is a bit... abstract, try PracticalTypes:trac: for a different view of the same information) Organizational Principles ------------------------- When creating a new Puppet type, you will be focusing on two types of classes: The resource type itself, which we normally just call a 'type', and the provider(s) for that type. The resource types provide the model for what you can do: They set the valid parameters, they handle input validation, and they determine what features a provider can or should provide. The providers implement support for that type by translating calls in the resource type to operations on the system. Once you have your code, you have to figure out how to deploy it where necessary. Both your clients and servers will need the code; the clients obviously need it in order to actually use them, but the server needs it in order to validate resource parameters. You can, in theory, put your types in a puppet/type subdirectory of any directory in Ruby's load path, however the best place is Puppet's libdir. The libdir is special because you can use the pluginsync system to copy all of your plugins from the fileserver to all of your clients (and your Puppetmaster, if it's a Puppet-managed machine too). To enable pluginsync, set pluginsync (development, documentation, types)
• DmgPackages (documentation, package, provider)
• DocumentationStandards (documentation, rest, restructured, tags, text, wiki)
• DocumentationStart Puppet Documentation (documentation, index, puppet, start.)
• DocumentationVision The goal of the documentation should be to answer the questions of those who use it, as quickly and sensibly as possible. Toward that end, the documentation should be approached from the perspective of those who will be using it, not those who write either it or Puppet. The best reading on this subject is Kathy Sierra's Creating Passionate Users_ blog (unfortunately, it's now defunct, but there are great archived posts there). One of Kathy's main points about documentation is that it should provide the reader with new avenues of accomplishment, rather than just information on how to do every little piece. So, as you write or organize documentation for Puppet, please ask yourself: Are you helping the reader find new ways to solve problems, or are you just describing the product for those who already know what they want to do? Choose Your Own Adventure (documentation, planning)
• DocumentationWranglers (documentation, people)
• DownloadingPuppet (documentation, download, install, puppet, source)
• ExternalNodeClassification (development, documentation, planned, specd)
• GettingHelp (documentation, help, support)
• InstallationGuide Installation Guide (documentation, installation)
• IrcChannel Pasting configuration files (IRC, documentation, puppet, support)
• LanguageTutorial The purpose of Puppet's language is to make it easy to specify the resources you need to manage on the machines you're managing. The language has been developed with a focus on making it easy to handle all kinds of heterogeneity, whether that means different resources for different hosts or different attributes for a similar list of resources. Resources --------- Resources are fundamentally built from a type, a title, and a list of attributes, with each resource type having a specific list of supported attributes. You can find all of the supported resource types, their valid attributes, and documentation for all of it in the TypeReference Type Reference:trac:. Here's a simple example of a resource:: file { "/etc/passwd": owner (documentation, language, tutorial)
• LateBindingDefinitionNames (development, documentation, planned)
• LdapNodes? (documentation, ldap, nodes)
• ModuleDocumentationStandards Proposed Module Documentation System (documentation, module, modules, standard, standards)
• MultipleCertificateAuthorities NOTE (SSL, certificates, documentation, puppet, security)
• NameSpaceAuth (configuration, documentation, example, executables)
• NetworkReference (development, documentation, reference)
• NetworkedClasses This is the certificate authority. The current code accepts a certificate request and returns a signed certificate, so following the REST model we'd need to serve those classes separately. The certificates also require, at least, a private key, which needs to be stored separately. You can look in lib/puppet/sslcertificates/support.rb for a good picture of what needs to be managed. This module contains code for loading, generating, and storing all of the certificate-related objects. Note that a ca cert is a normal cert but with a different path; we don't have a good way to handle this right now, so it might just be a one-off. filebucket (development, docs, documentation)
• NewToPuppet (beginner, documentation, index, intro, new)
• ProviderDevelopment .. contents:: The core of Puppet's cross-platform support is via Resource Providers, which are essentially back-ends that implement support for a specific implementation of a given resource type. For instance, there are more than 20 package providers, including providers for package formats like dpkg and rpm along with high-level package managers like apt and yum. A provider's main job is to wrap client-side tools, usually by just calling out to those tools with the right information. Not all resource types have or need providers, but any resource type concerned about portability will likely need them. We will use the apt and dpkg package providers as examples throughout this document, and the examples used are current as of 0.23.0. Declaration -------------------- Providers are always associated with a single resource type, so they are created by calling the provide class method on that resource type. When declarating a provider, you can specify a parent class -- for instance, all package providers have a common parent class:: Puppet::Type.type(:package).provide :dpkg, :parent (development, documentation, providers)
• ProviderSuitabilityReportTest **This page is autogenerated; any changes will get overwritten** .. contents:: :depth: 1 Puppet resource types are usually backed by multiple implementations called providers, which handle variance between platforms and tools. Different providers are suitable or unsuitable on different platforms based on things like the presence of a given tool. Here are all of the provider-backed types and their different providers. Any unmentioned types do not use providers yet. Details about this host: :Ruby version: 1.8.4 :Puppet version: 0.22.4 :Operating system: Darwin :Operating system release: 8.9.1 cron_ ----- .. _cron: http://reductivelabs.com/trac/puppet/wiki/TypeReference#cron :Default provider: crontab (darwin, documentation, report)
• Publications Luke Kanies Wants to Modernize System Administration_ ------------------------------------------------------- :By: chromatic :On: O'Reilly :Date: August 2008 "Luke Kanies spent some time as a system administrator. That job can have its own tedium -- keeping machines up to date, building new machines, and managing dozens to thousands of individual configurations. Clever administrators automate." .. _Luke Kanies Wants to Modernize System Administration: http://news.oreilly.com/2008/08/luke-kanies-wants-to-modernize.html Puppet can ease system administration tasks across the network_ ----------------------------------------------------------------- :By: Ben Martin :On: Linux.com :Date: August 2008 "The Puppet project allows you to issue system administration commands to one or more machines, and will smooth over the differences between distributions for you. For example, if you want to install MySQL, that action should be your primary aim, and you shouldn't have to worry about if the machine is running Maemo, Ubuntu, or Fedora." .. _Puppet can ease system administration tasks across the network: http://www.linux.com/feature/143893 Master of Puppets_ -------------------- :By: Larry Ludwig :On: Empowering Media's blog :Date: June 2008 "No this post isn’t about the Metallica album, it’s about the provisioning system we use named Puppet. It allows us to automate many of the system administration tasks, to a level that was previously very costly or hard to do." .. _Master of Puppets: http://www.empoweringmedia.com/blog/master-of-puppets Puppet at Google_ ------------------- :By: Michael Cote, Redmonk :On: People Over Process :Date: June 2008 "I recently talked with Reductive Lab’s Luke Kaines and Google’s Nigel Kersten on the topic of Puppet. First, we go through a quick overview of what Puppet does - establishing the desired configuration of machines by modeling services and then enforcing that model." .. _Puppet at Google: http://www.redmonk.com/cote/2008/06/11/puppet-at-google-redmonk-radio-episode-48/ The Craft: Automation and Scaling Infrastructure_ --------------------------------------------------- :By: Andrew Shafer :On: GigaOM :Date: June 2008 "Until the late 18th century, craftsmen were a primary source of production. With specialized skills, a craftsman’s economic contribution was a function of personal quantity and quality, and a skilled artisan often found it undesirable, if not impossible, to duplicate previous work with accuracy. Plus, there is a limit to how much a skilled craftsman can do in one day. Scaling up the quantity of crafted goods to meet increased demand was a question of working more or adding more bodies — both of which potentially sacrificed quality and consistency." .. _The Craft: Automation and Scaling Infrastructure: http://refresh.gigaom.com/2008/06/12/the-craft-automation-and-scaling-infrastructure/ Cloudy Saturday: Puppet, for Automating Virtual Machines_ ----------------------------------------------------------- :By: Aaron Huslage :On: OSTATIC :Date: June 2008 "This is the first of our weekly "Cloudy Saturday" columns that will delve into using cloud computing techniques to manage your own server farms, both large and small. This week we'll talk about the Puppet automation system from Reductive Labs. Puppet is built upon the legacy of the venerable Cfengine system, but takes things to a whole new level." .. _Cloudy Saturday: Puppet, for Automating Virtual Machines: http://ostatic.com/164363-blog/cloudy-saturday-puppet-for-automating-virtual-machines Expert Q&A: Simplifying configuration management with Puppet_ ------------------------------------------------------------------- :By: James Turnbull_ and Caroline Hunter :On: Tech Target? :Date: April 2008 "Systems administrators have to live with the fact that "configuration management is hard," says James Turnbull, author of the new book Pulling Strings with Puppet. When this task is done, it is often done ad hoc; administrators resort to using a "for" loop and SSH scripts. They may also go with a commercial offering, but this option brings its own challenges. Commercial products are often monolithic and hard to use, configure, learn and manage. In his book and in this interview, Turnbull describes how to use Puppet and the broader principles of configuration management, particularly when managing multiple systems." .. _Expert Q&A: Simplifying configuration management with Puppet: http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1311788,00.html Pulling Strings with Puppet: Configuration Management Made Easy_ ------------------------------------------------------------------- :By: James Turnbull_ :On: Apress_ :Date: February 2008 "Pulling Strings with Puppet" is the first book on Puppet. The book guides you through Puppet’s key features, showing you how to install and configure, create recipes, handle reporting and introduce you to extending Puppet and Facter. .. _Pulling Strings with Puppet: Configuration Management Made Easy: http://www.apress.com/book/view/1590599780/ .. _Apress: http://www.apress.com/ Interview with Luke Kanies by Michael Coté_ ----------------------------------------------- :By: Michael Coté_ :On: Redmonk_ :Date: October 2007 Coté interviews Luke at Inno Tech? Austin. .. _michael coté: http://www.redmonk.com/cote/ .. _Interview with Luke Kanies by Michael Coté: http://www.redmonk.com/cote/2007/10/29/puppet-video-interview-with-luke-kanies-open-source-server-configuration-automation/ .. _redmonk: http://www.redmonk.com/ Master of Puppet: System Management Made Easy_ --------------------------------------------------------------------------- :By: LukeKanies Luke Kanies:trac: :On: Linux Magazine_ :Date: October 2007 How to install and use Puppet on Red Hat distributions. .. _Master of Puppet: System Management Made Easy: http://www.linux-mag.com/id/4141/ .. _linux magazine: http://www.linux-mag.com/ Virtual host management: How to use Puppet on Red Hat Enterprise Linux 5_ --------------------------------------------------------------------------- :By: James Turnbull_ :On: Search Enterprise Linux_ :Date: June 2007 How to install and use Puppet on Red Hat distributions. .. _Virtual host management: How to use Puppet on Red Hat Enterprise Linux 5: http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1262344,00.html .. _james turnbull: http://ablog.apress.com/?author (articles, book, books, documentation)
• PuppetEnvironment (development, documentation, planned)
• PuppetInternals (development, documentation)
• PuppetIntroduction Introduction to Puppet (documentation, introduction, puppet)
• PuppetMacOSX Puppet on Mac OS X (documentation, osx, package, provider, puppet)
• PuppetRecipeManager (documentation, modules, prm)
• PuppetSource Puppet is currently implemented in Ruby and uses standard Ruby libraries. You should be able to run Puppet on any Unix-style host with Ruby. Windows support is planned but not currently available. Before you Begin ---------------- Make sure your host has Ruby version 1.8.2 or later:: $ ruby -v and, if you want to run the tests, rake:: $ rake -V While Puppet should work with 1.8.1, there have been many reports of problems with this version. Make sure you have Git_:: $ git --version Get the Source -------------- Puppet currently relies on another Reductive Labs tool, Facter_. Create a working directory and get them both:: $ SETUP_DIR (documentation, download, facter, git, source, testing)
• PuppetSuSE Puppet on SuSE/opensuse (documentation, installation, opensuse, suse)
• PuppetUsers (documentation, toc)
• PuppetWithRunit Puppet With Runit (debian, documentation, restart, runit, service, start, starting, stop)
• PurgingResources (development, documentation, planned)
• RegenerateSSL Regenerating Puppet SSL Certificates (certificates, documentation, ssl)
• ReportReference (documentation, reference)
• ReportsAndReporting Puppet clients can be configured to send reports at the end of every configuration run. Because the Transaction class is responsible for creating and sending the reports, these are called transaction reports. Currently, these reports include all of the log messages generated during the configuration run, along with some basic metrics of what happened on that run. Reports are sent as Puppet::Transaction::Report instances, serialized with YAML. Logs ---- The bulk of the report is every log message generated during the transaction. This is a simple way to send almost all client logs to the Puppet server; you can use the log report to send all of these client logs to syslog on the server. Metrics ------- The rest of the report is some basic metrics describing what happened in the transaction. There are three types of metrics in each report, and each type of metric has one or more values: - **Time**: Keeps track of how long things took. - *Total*: Total time for the configuration run - *File*: - *Exec*: - *User*: - *Group*: - *Config Retrieval*: How long the configuration took to retrieve - *Service*: - *Package*: - **Resources**: Keeps track of the following stats: - *Total*: The total number of resources being managed - *Skipped*: How many resources were skipped, because of either tagging or scheduling restrictions - *Scheduled*: How many resources met any scheduling restrictions - *Out of Sync*: How many resources were out of sync - *Applied*: How many resources were attempted to be fixed - *Failed*: How many resources were not successfully fixed - *Restarted*: How many resources were restarted because their dependencies changed - *Failed Restarts*: How many resources could not be restarted - **Changes**: The total number of changes in the transaction. Setting Up Reporting (client, documentation, reports, server)
• RubySSL-2007-006 2007-006-RubySSL Security Patch (bug, certificates, documentation, faq, puppet)
• TOC Puppet Documentation (documentation, toc)
• TagFolksonomy (community, documentation, standard)
• UPGRADE The UPGRADE documents is a feature roadmap to the various Puppet versions. It details changes to features, functions, language, configuration and types during the course of Puppet's development. It highlights incompatibilities and specifies when new features were introduced and the extent to which they are backwards-compatible. If upgrading you should review this document upward from the version you are upgrading from. Please remember that if upgrading through multiple versions some behaviour may change more than once. There is also a Roadmap <http://reductivelabs.com/trac/puppet/wiki/RoadMap>_ document available that details future development plans. .. contents:: 0.24.5 ------ Binary and Configuration ++++++++++++++++++++++++ Added the catalog_format configuration option which accepts the yaml or marshal options. This option allows you to switch the catalog formatting from YAML to Marshal. Marshal formatting should provide significant performance enhancement over YAML. The return code from waitpid now right shifted 8 bits. Added support for the --all option to puppetca --clean. If puppetca --clean --all is issued then all client certificates are removed. Environments ++++++++++++ The default environment is now production. Types and Providers +++++++++++++++++++ The interface type is buggy and has been disabled. A native type type for managing ssh authorized_keys files is available The gem package type can now specify source repositories. The service type now supports HP-UX. On Red Hat instead of deleting the init scripts (with chkconfig --del) we disable it with chkconfig service off, and do the same for enable (documentation, migrate, upgrade, upgrades, versions)
• UsingMultipleEnvironments As of 0.24.0, Puppet has support for multiple environments, along the same lines as Ruby on Rails_. The idea behind these environments is to provide an easy mechanism for managing machines at different levels of SLA -- some machines need to be up constantly and thus cannot tolerate disruptions and usually use older software, while other machines are more up to date and are used for testing upgrades to more important machines. Puppet allows you to define whatever environments you want, but it is recommended that you stick to production, testing, and development for community consistency. Valid environment names need to be defined, both server-side and client-side. This is done via the environments variable defined in ConfigurationReference:trac:. Puppet defaults to not using an environment, and if you do not set one on either the client or server, then it will behave as though environments do not exist at all, so you can safely ignore this feature if you do not need it. **Please note:** Not using Environments doesn't mean that client doesn't have an Environment set. The client's environment is per default set to development and will only be changed by changing the clients configuration or per command parameter. You can't set it to a default value on the server side . For a more detailed discussion have a look at: environment default setting_ - thread on the mailing list. Possible Goal of Environments ----------------------------- The main goal of a setup split by environments could be that puppet can run different sources (of modules, manifests etc. ) for different environments on the same master. See more here: ConfigurationReference:trac: This enables for example the possibility to have a stable and a testing branch of your manifests and modules and therefor it would be possible to do any development work in a safe testing environment and leave all Production-Servers untouched from the development and its possible damages. To test the new developed Manifest(s), Module(s), etc. one or some Server(s) could be run against the testing environment with the following command:: puppetd --test --environment (documentation, environment, nodes, sla)
• WikiStart (documentation, puppet)