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 Tue Apr 01 04:04:51 +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)
• 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)
• 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)
• PracticalTypes Building a mental model (development, documentation, type, types)
• 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 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)
• 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)
• SubversionToGitOrDarcs Submitting Patches (darcs, documentation, dscm, git, scm, svn)
• 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.4 ------ Binary and Configuration ++++++++++++++++++++++++ The http keep-alive is now disabled by default. There is now a constant in Puppet::Network::Http Pool? that will disable or enable this feature but it you enable it you may be at risk of corruption, especially in file serving. The yamldir is automatically created by the server now that it's in the puppetmasterd section rather than a separate yaml section. Types and Providers +++++++++++++++++++ In the OpenBSD package provider, assume a source ending in a / indicates it is a directory, and pass it to pkg_add via PKG_PATH. Allows pkg_add to resolve dependencies, and make it possible to specify packages without version numbers. Provider suitability is now checked at resource evaluation time, rather than resource instantiation time. This means that you don't catch your "errors" as early, but it also means you should be able to realistically configure a whole host in one run. Documentation +++++++++++++ Puppet now has man pages available. These are recreated at each release. They are located in the man directory and are installed into mandir. 0.24.3 ------ Languages and Facts +++++++++++++++++++ Downloading plugins and facts now ignores noop. Note that this changes the behaviour of a resource's noop setting. The resources noop setting will now alway override the global setting (previously, whichever was true would win). Host names can now have dashes anywhere. Binaries and Configuration ++++++++++++++++++++++++++ The CA serial file will no longer ever be owned by root. External Nodes ++++++++++++++ External node commands can specify an environment and Puppet will now use it. LDAP Nodes ++++++++++ LDAP nodes now support environments, and the schema has been updated accordingly. 0.24.2 ------ Plugins +++++++ Autoloading now searches the plugins directory in each module, in addition to the libdir directory. The libdir directory is also deprecated, but supported for now to give people a chance to convert. Virtual Resources +++++++++++++++++ Virtual defined types are no longer evaluated. This introduces a behaviour change, in that you previously could realize a resource within a virtual defined resource, and now you must realize the entire defined resource, rather than just the contained resource. Tags ++++ The full name of qualified classes and the class parts are now added as tags. This is supported by the new Tagging module. Binaries and Configuration ++++++++++++++++++++++++++ The rundir directory permissions are again set to 1777. The yamldir setting has been moved to its own yaml section. This should keep the yamldir from being created on clients. Language and Facts ++++++++++++++++++ Classes can once again be included multiple times. Exec resources must now have unique names, although the commands can still be duplicated. This is easily accomplished by just specifying a unique name with whatever (unique or otherwise) command you need. There is a change in Puppet's parser - the order of statement evaluation is no longer changed. This means case statements can now set variables that can be used by other variables. Types and Providers +++++++++++++++++++ Added built-in support for Nagios types using Naginator to parse and generate the files. The package type (and Puppet overall) is now compatible with gems 1.0.1. You can now copy links using the file type. Removed the loglevels from the valid values for logoutput in the exec resource type -- the log levels are specified using the loglevel parameter, not logoutput. 0.24.1 ------ Binaries and Configuration ++++++++++++++++++++++++++ Removed the ability to disable http keep-alive. Removed warning about deprecated explicit plugins mounts. 0.24.0 (misspiggy) ------------------ External Nodes ++++++++++++++ External node support now requires that you set the node_terminus setting to exec:: node_terminus (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)