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 !!!
Leave a Reply