Home / Puppet / Puppet – Resource Declaration – Overview

Puppet – Resource Declaration – Overview

Resources are essential unit to perform the system configuration. Each resource will describe the particular thing in puppet. For an example,  specific user needs to be created or specific file needs to be updated across the puppet agent nodes. When you would like to manage the users, “user” resource type will come in to play. If you want to modify specific file, you need to use “file” resource type.  To create a user , you need to provide set of attributes to define home directory , user id , group id , type of shell and comments. To define these attributes, you need to create a block of puppet code and this is called resource declaration. You must write these codes in “Declarative Modelling Language” (DML).

 

Let’s have look at the sample resource declaration code.

user { 'oracle':
ensure => present,
uid => '1020',
shell => '/bin/bash',
home => '/home/oracle',
managehome => true,
comment => 'oracle DB user',
}

 

The above code consists following parts.

  • Resource Type – which in this case is “user“
  • Resource Title – which in this case is “oracle”
  • Attributes – these are the resource’s properties. (UID, GID, SHELL,HOME)
  • Values – this are the values that correspond to each properties.

 

Let’s apply the above resource declaration code on one of the puppet agent node.

 

 

Executing the Resource Declaration Code:

 

1.Login to the puppet agent node .

 

2. Apply the resource declaration code which we have created.

 

3.Navigate to directory “/etc/puppetlabs/code/environments/production/manifests” . (Not Mandatory)

 

4. Create a new file with name init.pp with following code.

user { 'oracle':
ensure => present,
uid => '1020',
shell => '/bin/bash',
home => '/home/oracle',
managehome => true,
comment => 'oracle DB user',
}

 

5. Let’s apply the code using puppet command.

[root@uapa1 manifests]# puppet apply init.pp
Notice: Compiled catalog for uapa1 in environment production in 0.04 seconds
Notice: /Stage[main]/Main/User[oracle]/ensure: created
Notice: Applied catalog in 0.31 seconds
[root@uapa1 manifests]#

 

6. Verify our work.

[root@uapa1 manifests]# id -a oracle
uid=1020(oracle) gid=1020(oracle) groups=1020(oracle)
[root@uapa1 manifests]# ls -ld /home/oracle
drwx------ 3 oracle oracle 74 Feb 9 18:58 /home/oracle
[root@uapa1 manifests]# puppet resource user oracle
user { 'oracle':
 ensure => 'present',
 comment => 'oracle DB user',
 gid => '1020',
 home => '/home/oracle',
 password => '!!',
 password_max_age => '99999',
 password_min_age => '0',
 shell => '/bin/bash',
 uid => '1020',
}
[root@uapa1 manifests]#


We can see that oracle user is created as defined in the puppet code.  At this point , we are not dealing with puppet Server/Master. We are just dealing with puppet agents on the client systems. Master/Server will come in to play when you would like to manage the things from centralized location (Which is the industry common practice).  The above demonstration is just to understand that how puppet agent works.

 

To remove the resource , you just need to specify the resource name with “ensure=absent” value.

[root@uapa1 manifests]# puppet resource user oracle ensure=absent
Notice: /User[oracle]/ensure: removed
user { 'oracle':
 ensure => 'absent',
}
[root@uapa1 manifests]#

 

Verify the user again,

[root@uapa1 manifests]# puppet resource user oracle
user { 'oracle':
 ensure => 'absent',
}
[root@uapa1 manifests]#
root@uapa1 manifests]# ls -ld /home/oracle
ls: cannot access /home/oracle: No such file or directory
[root@uapa1 manifests]# grep oracle /etc/passwd
[root@uapa1 manifests]# id -a oracle
id: oracle: no such user
[root@uapa1 manifests]#

 

This is just an small example that how to define the resource with require attributes, create and delete it. In the above example, we have seen about “user” resource type. Let’s see that what are the in-built resource types available in puppet.

 

RESOURCE TYPE:

1. You view the available resource type using puppet command.

[root@uapa1 manifests]# puppet describe --list
These are the types known to puppet:
augeas          - Apply a change or an array of changes to the  ...
computer        - Computer object management using DirectorySer ...
cron            - Installs and manages cron jobs
exec            - Executes external commands
file            - Manages files, including their content, owner ...
filebucket      - A repository for storing and retrieving file  ...
group           - Manage groups
host            - Installs and manages host entries
interface       - This represents a router or switch interface
k5login         - Manage the `.k5login` file for a user
macauthorization - Manage the Mac OS X authorization database
mailalias       - .. no documentation ..
maillist        - Manage email lists
mcx             - MCX object management using DirectoryService  ...
mount           - Manages mounted filesystems, including puttin ...
nagios_command  - The Nagios type command
nagios_contact  - The Nagios type contact
nagios_contactgroup - The Nagios type contactgroup
nagios_host     - The Nagios type host
nagios_hostdependency - The Nagios type hostdependency
nagios_hostescalation - The Nagios type hostescalation
nagios_hostextinfo - The Nagios type hostextinfo
nagios_hostgroup - The Nagios type hostgroup
nagios_service  - The Nagios type service
nagios_servicedependency - The Nagios type servicedependency
nagios_serviceescalation - The Nagios type serviceescalation
nagios_serviceextinfo - The Nagios type serviceextinfo
nagios_servicegroup - The Nagios type servicegroup
nagios_timeperiod - The Nagios type timeperiod
notify          - .. no documentation ..
package         - Manage packages
pe_anchor       - A simple resource type intended to be used as ...
pe_file_line    - Ensures that a given line is contained within ...
pe_hocon_setting - .. no documentation ..
pe_ini_setting  - .. no documentation ..
pe_ini_subsetting - .. no documentation ..
pe_java_ks      - Manages entries in a java keystore
pe_postgresql_conf - .. no documentation ..
pe_postgresql_psql - .. no documentation ..
pe_puppet_authorization_hocon_rule - .. no documentation ..
resources       - This is a metatype that can manage other reso ...
router          - .. no documentation ..
schedule        - Define schedules for Puppet
scheduled_task  - Installs and manages Windows Scheduled Tasks
selboolean      - Manages SELinux booleans on systems with SELi ...
selmodule       - Manages loading and unloading of SELinux poli ...
service         - Manage running services
ssh_authorized_key - Manages SSH authorized keys
sshkey          - Installs and manages ssh host keys
stage           - A resource type for creating new run stages
tidy            - Remove unwanted files based on specific crite ...
user            - Manage users
vlan            - .. no documentation ..
whit            - Whits are internal artifacts of Puppet's curr ...
yumrepo         - The client-side description of a yum reposito ...
zfs             - Manage zfs
zone            - Manages Solaris zones
zpool           - Manage zpools
[root@uapa1 manifests]#

 

2. To know more about the specific resource type, use the following command with specific resource type.

[root@uapa1 manifests]# puppet describe cron

cron
====
Installs and manages cron jobs.  Every cron resource created by Puppet
requires a command and at least one periodic attribute (hour, minute,
month, monthday, weekday, or special).  While the name of the cron job is
not part of the actual job, the name is stored in a comment beginning with
`# Puppet Name: `. These comments are used to match crontab entries created
by Puppet with cron resources.
If an existing crontab entry happens to match the scheduling and command of
a
cron resource that has never been synched, Puppet will defer to the existing
crontab entry and will not create a new entry tagged with the `# Puppet
Name: `
comment.
Example:
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => 2,
      minute  => 0
    }
Note that all periodic attributes can be specified as an array of values:
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => [2, 4]
    }
...or using ranges or the step syntax `*/2` (although there's no guarantee
that your `cron` daemon supports these):
    cron { logrotate:
      command => "/usr/sbin/logrotate",
      user    => root,
      hour    => ['2-4'],
      minute  => '*/10'
    }
An important note: _the Cron type will not reset parameters that are
removed from a manifest_. For example, removing a `minute => 10` parameter
will not reset the minute component of the associated cronjob to `*`.
These changes must be expressed by setting the parameter to
`minute => absent` because Puppet only manages parameters that are out of
sync with manifest entries.
**Autorequires:** If Puppet is managing the user account specified by the
`user` property of a cron resource, then the cron resource will autorequire
that user.


Parameters
----------

- **command**
    The command to execute in the cron job.  The environment
    provided to the command varies by local system rules, and it is
    best to always provide a fully qualified command.  The user's
    profile is not sourced when the command is run, so if the
    user's environment is desired it should be sourced manually.
    All cron parameters support `absent` as a value; this will
    remove any existing values for that field.

- **ensure**
    The basic property that the resource should be in.
    Valid values are `present`, `absent`.

 

 

Resource Abstraction Layer (RAL)

Each resource is belongs to specific resource type. Resources are described independently from the target operating system. It gives you enough information to the puppet server regardless of whether the puppet agent is a windows or Linux machine. Puppet agent allows you to view/manage all these resource via Puppet’s CLI interface Layer. (Ex: user creation , deletion )

The platform-specific-implementation exists in the form of “Providers” for each resource type. By default, in-built  resource type will cover all Linux, Unix and windows platforms for each resource-type’s attribute. You can use the “describe” subcommand along with it’s “–providers” option to view a list of providers for each attribute for a given resource type. For an example, to view all the providers for the “service” resource type, use the following command.

[root@uapa1 manifests]# puppet describe service --providers

 

Providers will be displayed in last section. Let me just bring  up the “providers” part.

[root@uapa1 manifests]# puppet describe service --providers |grep -A 1000 "Providers"
Providers
---------

- **base**
    The simplest form of Unix service support.
    You have to specify enough about your service for this to work; the
    minimum you can specify is a binary for starting the process, and this
    same binary will be searched for in the process table to stop the
    service.  As with `init`-style services, it is preferable to specify
    start,
    stop, and status commands.
    * Required binaries: `kill`.
* Supported features: `refreshable`.

- **bsd**
    Generic BSD form of `init`-style service management with `rc.d`.
    Uses `rc.conf.d` for service enabling and disabling.
    * Supported features: `enableable`, `refreshable`.

- **daemontools**
    Daemontools service management.
    This provider manages daemons supervised by D.J. Bernstein daemontools.
    When detecting the service directory it will check, in order of
    preference:
    * `/service`
    * `/etc/service`
    * `/var/lib/svscan`
    The daemon directory should be in one of the following locations:
    * `/var/lib/service`
    * `/etc`
    ...or this can be overriden in the resource's attributes:
        service { "myservice":
          provider => "daemontools",
          path     => "/path/to/daemons",
        }
    This provider supports out of the box:
    * start/stop (mapped to enable/disable)
    * enable/disable
    * restart
    * status
    If a service has `ensure => "running"`, it will link /path/to/daemon to
    /path/to/service, which will automatically enable the service.
    If a service has `ensure => "stopped"`, it will only shut down the
    service, not
    remove the `/path/to/service` link.
    * Required binaries: `/usr/bin/svc`, `/usr/bin/svstat`.
    * Supported features: `enableable`, `refreshable`.

- **debian**
    Debian's form of `init`-style management.
    The only differences from `init` are support for enabling and disabling
    services via `update-rc.d` and the ability to determine enabled status
    via
    `invoke-rc.d`.
    * Required binaries: `/usr/sbin/invoke-rc.d`, `/usr/sbin/update-rc.d`.
    * Default for `operatingsystem` == `cumuluslinux`. Default for
    `operatingsystem` == `debian` and `operatingsystemmajrelease` == `5, 6,
    7`.
* Supported features: `enableable`, `refreshable`.

- **freebsd**
    Provider for FreeBSD and DragonFly BSD. Uses the `rcvar` argument of
    init scripts and parses/edits rc files.
    * Default for `operatingsystem` == `freebsd, dragonfly`.
    * Supported features: `enableable`, `refreshable`.

- **gentoo**
    Gentoo's form of `init`-style service management.
    Uses `rc-update` for service enabling and disabling.
    * Required binaries: `/sbin/rc-update`.
    * Supported features: `enableable`, `refreshable`.

- **init**
    Standard `init`-style service management.
    * Supported features: `refreshable`.

- **launchd**
    This provider manages jobs with `launchd`, which is the default service
    framework for Mac OS X (and may be available for use on other
    platforms).
    For `launchd` documentation, see:
    * <http://developer.apple.com/macosx/launchd.html>
    * <http://launchd.macosforge.org/>
    This provider reads plists out of the following directories:
    * `/System/Library/LaunchDaemons`
    * `/System/Library/LaunchAgents`
    * `/Library/LaunchDaemons`
    * `/Library/LaunchAgents`
    ...and builds up a list of services based upon each plist's "Label"
    entry.
    This provider supports:
    * ensure => running/stopped,
    * enable => true/false
    * status
    * restart
    Here is how the Puppet states correspond to `launchd` states:
    * stopped --- job unloaded
    * started --- job loaded
    * enabled --- 'Disable' removed from job plist file
    * disabled --- 'Disable' added to job plist file
    Note that this allows you to do something `launchctl` can't do, which is
    to
    be in a state of "stopped/enabled" or "running/disabled".
    Note that this provider does not support overriding 'restart' or
    'status'.
    * Required binaries: `/bin/launchctl`, `/usr/bin/plutil`.
    * Default for `operatingsystem` == `darwin`.
    * Supported features: `enableable`, `refreshable`.

- **openbsd**
    Provider for OpenBSD's rc.d daemon control scripts
    * Required binaries: `/usr/sbin/rcctl`.
    * Default for `operatingsystem` == `openbsd`.
    * Supported features: `enableable`, `flaggable`, `refreshable`.

- **openrc**
    Support for Gentoo's OpenRC initskripts
    Uses rc-update, rc-status and rc-service to manage services.
    * Required binaries: `/bin/rc-status`, `/sbin/rc-service`,
    `/sbin/rc-update`.
    * Default for `operatingsystem` == `gentoo`. Default for
    `operatingsystem` == `funtoo`.
    * Supported features: `enableable`, `refreshable`.

- **openwrt**
    Support for OpenWrt flavored init scripts.
    Uses /etc/init.d/service_name enable, disable, and enabled.
    * Default for `operatingsystem` == `openwrt`.
    * Supported features: `enableable`, `refreshable`.

- **rcng**
    RCng service management with rc.d
    * Default for `operatingsystem` == `netbsd, cargos`.
    * Supported features: `enableable`, `refreshable`.

- **redhat**
    Red Hat's (and probably many others') form of `init`-style service
    management. Uses `chkconfig` for service enabling and disabling.
    * Required binaries: `/sbin/chkconfig`, `/sbin/service`.
    * Default for `osfamily` == `redhat`. Default for
    `operatingsystemmajrelease` == `10, 11` and `osfamily` == `suse`.
    * Supported features: `enableable`, `refreshable`.

- **runit**
    Runit service management.
    This provider manages daemons running supervised by Runit.
    When detecting the service directory it will check, in order of
    preference:
    * `/service`
    * `/etc/service`
    * `/var/service`
    The daemon directory should be in one of the following locations:
    * `/etc/sv`
    * `/var/lib/service`
    or this can be overriden in the service resource parameters::
        service { "myservice":
          provider => "runit",
          path => "/path/to/daemons",
        }
    This provider supports out of the box:
    * start/stop
    * enable/disable
    * restart
    * status
    * Required binaries: `/usr/bin/sv`.
    * Supported features: `enableable`, `refreshable`.

- **service**
    The simplest form of service support.
    * Supported features: `refreshable`.

- **smf**
    Support for Sun's new Service Management Framework.
    Starting a service is effectively equivalent to enabling it, so there is
    only support for starting and stopping services, which also enables and
    disables them, respectively.
    By specifying `manifest => "/path/to/service.xml"`, the SMF manifest
    will
    be imported if it does not exist.
    * Required binaries: `/usr/bin/svcs`, `/usr/sbin/svcadm`,
    `/usr/sbin/svccfg`.
    * Default for `osfamily` == `solaris`.
    * Supported features: `enableable`, `refreshable`.

- **src**
    Support for AIX's System Resource controller.
    Services are started/stopped based on the `stopsrc` and `startsrc`
    commands, and some services can be refreshed with `refresh` command.
    Enabling and disabling services is not supported, as it requires
    modifications to `/etc/inittab`. Starting and stopping groups of
    subsystems
    is not yet supported.
    * Required binaries: `/usr/bin/lssrc`, `/usr/bin/refresh`,
    `/usr/bin/startsrc`, `/usr/bin/stopsrc`, `/usr/sbin/chitab`,
    `/usr/sbin/lsitab`, `/usr/sbin/mkitab`, `/usr/sbin/rmitab`.
    * Default for `operatingsystem` == `aix`.
    * Supported features: `enableable`, `refreshable`.

- **systemd**
    Manages `systemd` services using `systemctl`.
    * Required binaries: `systemctl`.
    * Default for `osfamily` == `archlinux`. Default for
    `operatingsystemmajrelease` == `7` and `osfamily` == `redhat`. Default
    for `operatingsystem` == `fedora` and `osfamily` == `redhat`. Default
    for `osfamily` == `suse`. Default for `operatingsystem` == `debian` and
    `operatingsystemmajrelease` == `8`. Default for `operatingsystem` ==
    `ubuntu` and `operatingsystemmajrelease` == `15.04`.
    * Supported features: `enableable`, `maskable`, `refreshable`.

- **upstart**
    Ubuntu service management with `upstart`.
    This provider manages `upstart` jobs on Ubuntu. For `upstart`
    documentation,
    see <http://upstart.ubuntu.com/>.
    * Required binaries: `/sbin/initctl`, `/sbin/restart`, `/sbin/start`,
    `/sbin/status`, `/sbin/stop`.
    * Default for `operatingsystem` == `ubuntu` and
    `operatingsystemmajrelease` == `10.04, 12.04, 14.04, 14.10`.
    * Supported features: `enableable`, `refreshable`.

- **windows**
    Support for Windows Service Control Manager (SCM). This provider can
    start, stop, enable, and disable services, and the SCM provides working
    status methods for all services.
    Control of service groups (dependencies) is not yet supported, nor is
    running
    services as a specific user.
    * Required binaries: `net.exe`.
    * Default for `operatingsystem` == `windows`.
    * Supported features: `enableable`, `refreshable`.
[root@uapa1 manifests]#

Here you can see that “service” resource type has different attributes for each OS family. Puppet agent handles these things in back-end.

 

Hope this article is informative to you. Share it ! Comment it ! Be Sociable !!!

VMTURBO-CLOUD-CAPACITY

Leave a Reply

Your email address will not be published. Required fields are marked *