Objects matching the expression 'nodes'

• #620 Nodes and classes can't have the same names (errormessage, nodes)
• ExternalNodes To use an external node classifier, in addition to or rather than having to define a node entry for each of your hosts, you need to create a script that can take a hostname as an argument and return information about that host for puppet to use. NOTE: You can use node entries in your manifests together with External nodes. You cannot however use external nodes and LDAP nodes together. You must use one of the two types. Configuring puppetmasterd ------------------------- First, configure your puppetmasterd to use an external nodes script:: [main] external_nodes (external, external_nodes, nodes)
• LDAPNodes By default, puppetmasterd looks for nodes in its normal manifests, but you can additionally or instead have it look in LDAP. This works especially well if you are already storing your host information in LDAP. I've only used OpenLDAP_ to do this, but it should work just as well with Fedora Directory Server_ or Sun's Directory Server_, although you'll have to translate the schema to work with them. This guide will go through what it takes to modify an existing OpenLDAP setup; please check OpenLDAP's documentation_ to get to that point. NOTE: You can use node entries in your manifests together with LDAP nodes. External or LDAP nodes will be used before node entries. You cannot however use LDAP nodes and external nodes together. You must use one of these two types. Why You'd Do This ----------------- There are multiple benefits to storing nodes in LDAP instead of using Puppet's built-in node support: - Other applications can easily get access to the same data - All attributes on the LDAP nodes are assigned as variables in the Puppet configuration, just like Facts, so you can easily configure attributes for individual classes - It is straightforward to allow other applications to modify this data to configure nodes (e.g., as part of a deployment process), which is easier to support than generating Puppet configurations Prerequisites --------------- * ruby-ldap_ Pre-Puppet Ruby/LDAP Validation --------------------------------- You can run the following tests to make sure that the Ruby-LDAP Library and your LDAP software are configured properly:: ruby -rldap -e 'puts :installed' If this returns installed then you can try:: ruby -rpuppet -e 'p Puppet.features.ldap?' These are basically doing the same thing, so they should either both succeed or both fail, and if they both succeed, then LDAP nodes should work. Node Attributes --------------- As mentioned, every attribute returned by LDAP nodes or parent nodes will be assigned as a variable in Puppet configurations during compilation. Attributes with multiple values will be created as arrays. As an example, take the following simple LDAP nodes:: dn: cn (LDAP, OpenLDAP, node, nodes)
• LdapNodes? (documentation, ldap, nodes)
• Recipes/ShowNodeObjects This script accepts a host name and produces a list of objects in manifest syntax associated with that host. It is meant to be run on the puppetmaster host. By default only the 'hostname' fact is supplied but other facts can be specified by using the '--fact` option (multiple times if needed). If the argument to '--fact' does not contain a ' (node, nodes, puppet, recipe)
• 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)