Учебники

Puppet — слой абстракции ресурсов

В Puppet Resource Abstraction Layer (RAL) можно рассматривать как основную концептуализированную модель, на которой работает вся инфраструктура и настройка Puppet. В RAL каждый алфавит имеет свое значимое значение, которое определяется следующим образом.

Ресурс [R]

Ресурс может рассматриваться как все ресурсы, которые используются для моделирования любой конфигурации в Puppet. Это в основном встроенные ресурсы, которые по умолчанию присутствуют в Puppet. Их можно рассматривать как набор ресурсов, принадлежащих к предопределенному типу ресурса. Они похожи на концепцию ООП в любом другом языке программирования, где объект является экземпляром класса. В Puppet его ресурс является экземпляром типа ресурса.

Абстракция [A]

Абстракция может рассматриваться как ключевая особенность, где ресурсы определяются независимо от целевой ОС. Другими словами, при написании любого файла манифеста пользователю не нужно беспокоиться о целевой машине или ОС, которая присутствует на этой конкретной машине. В абстракции ресурсы дают достаточно информации о том, что должно существовать в агенте Puppet.

Puppet позаботится обо всех функциях или магии, происходящих за сценой. Независимо от ресурсов и ОС, Puppet позаботится о реализации конфигурации на целевой машине, при этом пользователю не нужно беспокоиться о том, как Puppet делает это за кулисами.

В абстракции Puppet отделяет ресурсы от своей реализации. Эта специфичная для платформы конфигурация существует от поставщиков. Мы можем использовать несколько подкоманд вместе со своими провайдерами.

Слой [L]

Вполне возможно, что каждый задает настройку и конфигурацию всей машины с точки зрения сбора ресурсов, и он может просматриваться и управляться через интерфейс CLI Puppet.

Пример для типа ресурса пользователя

[root@puppetmaster ~]# puppet describe user --providers 
user 
==== 
Manage users.
This type is mostly built to manage systemusers, 
so it is lacking some features useful for managing normalusers. 
This resource type uses the prescribed native tools for 
creating groups and generally uses POSIX APIs for retrieving informationabout them.
It does not directly modify '/etc/passwd' or anything. 

- **comment** 
   A description of the user.  Generally the user's full name.  

- **ensure** 
   The basic state that the object should be in. 
   Valid values are 'present', 'absent', 'role'.  

- **expiry** 
   The expiry date for this user. 
   Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19. 
   If you want to make sure the user account does never expire, 
   you can pass the special value 'absent'. 
   Valid values are 'absent'. 
   Values can match '/^\d{4}-\d{2}-\d{2}$/'. 
   Requires features manages_expiry.  

- **forcelocal** 
   Forces the management of local accounts when accounts are also 
   being managed by some other NSS 
   Valid values are 'true', 'false', 'yes', 'no'. 
   Requires features libuser.  

- **gid** 
   The user's primary group.  Can be specified numerically or by name. 
   This attribute is not supported on Windows systems; use the groups 
   attribute instead. (On Windows, designating a primary group is only 
   meaningful for domain accounts, which Puppet does not currently manage.)  

- **groups** 
   The groups to which the user belongs. The primary group should 
   not be listed, and groups should be identified by name rather than by 
   GID. Multiple groups should be specified as an array.  

- **home** 
   The home directory of the user.  The directory must be created 
   separately and is not currently checked for existence.  

- **ia_load_module**
   The name of the I&A module to use to manage this user. 
   Requires features manages_aix_lam.  

- **iterations** 
   This is the number of iterations of a chained computation of the 
   password hash (http://en.wikipedia.org/wiki/PBKDF2).  
   This parameter is used in OS X. 
   This field is required for managing passwords on OS X >= 10.8.  

- **key_membership** 
   Whether specified key/value pairs should be considered the 
   **complete list** ('inclusive') or the **minimum list** ('minimum') of 
   the user's attributes. Defaults to 'minimum'. 
   Valid values are 'inclusive', 'minimum'.  

- **keys** 
   Specify user attributes in an array of key = value pairs. 
   Requires features manages_solaris_rbac.  

- **managehome** 
   Whether to manage the home directory when managing the user. 
   This will create the home directory when 'ensure => present', and 
   delete the home directory when ‘ensure => absent’. Defaults to ‘false’. 
   Valid values are ‘true’, ‘false’, ‘yes’, ‘no’.  

- **membership** 
   Whether specified groups should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of groups to which 
   the user belongs. Defaults to ‘minimum’. 
   Valid values are ‘inclusive’, ‘minimum’. 

- **name** 
   The user name. While naming limitations vary by operating system, 
   it is advisable to restrict names to the lowest common denominator.  

- **password** 
   The user's password, in whatever encrypted format the local system requires. 
   * Most modern Unix-like systems use salted SHA1 password hashes. You can use 
      Puppet's built-in ‘sha1’ function to generate a hash from a password. 
   * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes. 
   * Mac OS X 10.7 (Lion) uses salted SHA512 hashes. 
   The Puppet Labs [stdlib][] module contains a ‘str2saltedsha512’ 
   function which can generate password hashes for Lion. 
   * Mac OS X 10.8 and higher use salted SHA512 PBKDF2 hashes. 
   When managing passwords on these systems the salt and iterations properties 
   need to be specified as well as the password. 
   [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/ 
   Be sure to enclose any value that includes a dollar sign ($) in single 
   quotes (') to avoid accidental variable interpolation. 
   Requires features manages_passwords.  

- **password_max_age** 
   The maximum number of days a password may be used before it must be changed. 
Requires features manages_password_age.  

- **password_min_age** 
   The minimum number of days a password must be used before it may be changed. 
Requires features manages_password_age.  

- **profile_membership** 
   Whether specified roles should be treated as the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles 
   of which the user is a member. Defaults to minimum’. 
   Valid values are inclusive’, minimum’. 

- **profiles** 
   The profiles the user has.  Multiple profiles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **project** 
   The name of the project associated with a user. 
   Requires features manages_solaris_rbac.  

- **purge_ssh_keys** 
   Purge ssh keys authorized for the user 
   if they are not managed via ssh_authorized_keys. 
   When true, looks for keys in .ssh/authorized_keys in the user's home directory. 
   Possible values are true, false, or an array of 
   paths to file to search for authorized keys. 
   If a path starts with ~ or %h, this token is replaced with the user's home directory. 
   Valid values are true’, false’.  

- **role_membership** 
   Whether specified roles should be considered the **complete list** 
   (‘inclusive’) or the **minimum list** (‘minimum’) of roles the user has. 
   Defaults to minimum’. 
Valid values are inclusive’, minimum’.  

- **roles** 
   The roles the user has.  Multiple roles should be 
   specified as an array. 
Requires features manages_solaris_rbac.  

- **salt** 
   This is the 32 byte salt used to generate the PBKDF2 password used in 
   OS X. This field is required for managing passwords on OS X >= 10.8. 
   Requires features manages_password_salt. 

- **shell** 
   The user's login shell.  The shell must exist and be 
   executable. 
   This attribute cannot be managed on Windows systems. 
   Requires features manages_shell. 

- **system** 
   Whether the user is a system user, according to the OS's criteria; 
   on most platforms, a UID less than or equal to 500 indicates a system 
   user. Defaults to false’. 
   Valid values are true’, false’, yes’, no’.  

- **uid** 
   The user ID; must be specified numerically. If no user ID is 
   specified when creating a new user, then one will be chosen 
   automatically. This will likely result in the same user having 
   different UIDs on different systems, which is not recommended. 
   This is especially noteworthy when managing the same user on both Darwin and 
   other platforms, since Puppet does UID generation on Darwin, but 
   the underlying tools do so on other platforms. 
   On Windows, this property is read-only and will return the user's 
   security identifier (SID).  

Providers 
--------- 

- **aix** 
   User management for AIX. 
   * Required binaries: '/bin/chpasswd', '/usr/bin/chuser', 
   '/usr/bin/mkuser', '/usr/sbin/lsgroup', '/usr/sbin/lsuser', 
   '/usr/sbin/rmuser'. 
   * Default for ‘operatingsystem’ == ‘aix’. 
   * Supported features: ‘manages_aix_lam’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’. 

- **directoryservice** 
   User management on OS X. 
   * Required binaries: ‘/usr/bin/dscacheutil’, ‘/usr/bin/dscl’, 
   ‘/usr/bin/dsimport’, ‘/usr/bin/plutil’, ‘/usr/bin/uuidgen’. 
   * Default for ‘operatingsystem’ == ‘darwin’. 
   * Supported features: ‘manages_password_salt’, ‘manages_passwords’, 
   ‘manages_shell’.

- **hpuxuseradd** 
   User management for HP-UX. This provider uses the undocumented ‘-F’ 
   switch to HP-UX's special usermod binary to work around the fact that 
   its standard usermod cannot make changes while the user is logged in. 
   * Required binaries: ‘/usr/sam/lbin/useradd.sam’, 
   ‘/usr/sam/lbin/userdel.sam’, ‘/usr/sam/lbin/usermod.sam’. 
   * Default for operatingsystem == hp-ux’. 
   * Supported features: allows_duplicates’, manages_homedir’, 
   manages_passwords’.  

- **ldap** 
   User management via LDAP. 
   This provider requires that you have valid values for all of the 
   LDAP-related settings in puppet.conf’, including ldapbase’.
   You will almost definitely need settings for ldapuser and ldappassword in order 
   for your clients to write to LDAP. 
* Supported features: manages_passwords’, manages_shell’.  

- **pw** 
   User management via pw on FreeBSD and DragonFly BSD. 
   * Required binaries: pw’. 
   * Default for operatingsystem == freebsd, dragonfly’. 
   * Supported features: allows_duplicates’, manages_expiry’, 
   manages_homedir’, manages_passwords’, manages_shell’. 

- **user_role_add** 
   User and role management on Solaris, via useradd and roleadd’. 
   * Required binaries: passwd’, roleadd’, roledel’, rolemod’, 
   useradd’, userdel’, usermod’. 
   * Default for osfamily == solaris’. 
   * Supported features: allows_duplicates’, manages_homedir’, 
   manages_password_age’, manages_passwords’, manages_solaris_rbac’.  

- **useradd** 
   User management via useradd and its ilk.  Note that you will need to 
   install Ruby's shadow password library (often known as ‘ruby-libshadow’) 
   if you wish to manage user passwords. 
   * Required binaries: ‘chage’, ‘luseradd’, ‘useradd’, ‘userdel’, ‘usermod’. 
   * Supported features: ‘allows_duplicates’, ‘libuser’, ‘manages_expiry’, 
   ‘manages_homedir’, ‘manages_password_age’, ‘manages_passwords’, 
   ‘manages_shell’, ‘system_users’.  

- **windows_adsi** 
   Local user management for Windows. 
   * Default for 'operatingsystem' == 'windows'. 
   * Supported features: 'manages_homedir', 'manages_passwords'. 

Ресурс тестирования

В Puppet тестирование ресурса напрямую указывает на то, что сначала нужно применить ресурсы, которые он хочет использовать, чтобы сконфигурировать целевой узел, чтобы соответственно изменить состояние машины.

Для тестирования мы будем применять ресурс локально. Поскольку у нас есть ресурс, предопределенный выше с user = vipin . Одним из способов применения ресурса является CLI. Это можно сделать, переписав весь ресурс в одну команду, а затем передав его в подкоманду ресурса.

puppet resource user vipin ensure = present uid = '505' 
shell = '/bin/bash' home = '/home/vipin'

Протестируйте прикладной ресурс.

[root@puppetmaster ~]# cat /etc/passwd | grep "vipin" 
vipin:x:505:501::/home/vipin:/bin/bash 

Приведенный выше вывод показывает, что ресурс применяется к системе, и у нас создан новый пользователь с именем Vipin. Рекомендуется проверить это самостоятельно, так как все вышеперечисленные коды проверены и являются рабочими кодами.