Open source Puppet 6.10
- Welcome to Puppet 6.10
- Release notes
- Getting started with Puppet
- Installing and upgrading
- Configuring Puppet
- Puppet settings
- Key configuration settings
- Puppet's configuration files
- puppet.conf: The main config file
- environment.conf: Per-environment settings
- fileserver.conf: Custom fileserver mount points
- puppetdb.conf: PuppetDB server locations
- hiera.yaml: Data lookup configuration
- autosign.conf: Basic certificate autosigning
- csr_attributes.yaml: Certificate extensions
- custom_trusted_oid_mapping.yaml: Short names for cert extension OIDs
- device.conf: Network hardware access
- routes.yaml: Advanced plugin routing
- Configuring Puppet Server
- Puppet Server's config files
- puppetserver.conf: Main config file
- auth.conf: Access control
- webserver.conf: Jetty web server config
- web-routes.conf: Mount points for component services
- global.conf: Trapperkeeper settings
- ca.conf: CA service access control (deprecated)
- master.conf: Authorization by HTTP header (deprecated)
- product.conf: Configuring Product-level Interactions (optional)
- logback.xml: Logging level and location
- Advanced logging configuration
- Bootstrap upgrade notes
- Adding file server mount points
- Checking the values of settings
- Editing settings on the command line
- Configuration settings reference
- Settings that differ under Puppet Server
- Important directories and files
- Environments
- Modules
- Puppet services and tools
- Puppet Server
- Index
- About Puppet Server
- Release Notes
- Deprecated features
- Compatibility with Puppet agent
- Installing Puppet Server
- Configuring Puppet Server
- Differing behavior in puppet.conf
- Using and extending Puppet Server
- Known issues and workarounds
- Administrative API endpoints
- CA v1 API
- Server-specific Puppet API endpoints
- Status API endpoints
- Metrics API endpoints
- Developer information
- The Puppet language
- Language visual index
- The Puppet language style guide
- Files and paths on Windows
- Code comments
- Variables
- Resources
- Relationships and ordering
- Classes
- Defined resource types
- Bolt tasks
- Type aliases
- Expressions and operators
- Conditional statements and expressions
- Function calls
- Built-in functions
- Node definitions
- Facts and built-in variables
- Reserved words and acceptable names
- Custom resources
- Values and data types
- Templates
- Advanced constructs
- Details of complex behaviors
- Writing custom functions
- Hiera
- Facter
- Resource types
- Tracking Puppet activity with reports
- Writing external node classifiers
- References (settings, functions, etc.)
- Man pages
- HTTP API
- Certificate authority and SSL
- Puppet's internals
- Experimental features
Managing sudo on your agents allows you to control which system users have access to elevated privileges. This guide helps you get started managing sudo privileges across your nodes, using a module from the Puppet Forge in conjunction with a simple module you write.
Before starting this walk-through, complete the previous exercises.
Ensure you’ve already installed Puppet, and at least one *nix agent. Also, log in as root or Administrator on your nodes.
Using this guide, you learn how to:
-
Install the
saz-sudo
module as the foundation for managing sudo privileges. -
Write a module that contains a class called
privileges
to manage a resource that sets privileges for certain users. -
Add classes from the
privileges
andsudo
modules to your agents.
sudo
and privileges
classes to as many agents as needed. For simplicity, this guide describes only one.- Start by installing the
saz-sudo
module. It's available on the Forge, and is one of many modules written by a member of the Puppet user community. You can learn more about the module at forge.puppet.com/saz/sudo. To install thesaz-sudo
module, run the following command on the master:puppet module install saz-sudo
The resulting output is similar to this:
That’s it! You’ve installed thePreparing to install into /etc/puppetlabs/code/environments/production/modules … Notice: Downloading from http://forgeapi.puppetlabs.com ... Notice: Installing -- do not interrupt ... /etc/puppetlabs/puppet/modules └── saz-sudo (v2.3.6) └── puppetlabs-stdlib (3.2.2) [/opt/puppet/share/puppet/modules]
saz-sudo
module. - Next, you'll create a module that contains the
privileges
class.Like in the DNS exercise, this is a small module with just one class. You'll create the
privileges
module directory, itsmanifests
subdirectory, and aninit.pp
manifest file that contains theprivileges
class.- From the command line on the master, navigate to the modules directory:
cd /etc/puppetlabs/code/environments/production/modules
- Create the module directory and its manifests directory:
mkdir -p privileges/manifests
- In the manifests directory, use your text editor to create the
init.pp
file, and edit it so it contains the following Puppet code:class privileges { sudo::conf { 'admins': ensure => present, content => '%admin ALL=(ALL) ALL', } }
The
sudo::conf 'admins'
line creates a sudoers rule that ensures that members of theadmins
group have the ability to run any command using sudo. This resource creates a configuration fragment file to define this rule in/etc/sudoers.d/
. It's called something like10_admins
. - Save and exit the file.
That’s it! You’ve created a module that contains a class that, after it's applied, ensures that your agents have the correct sudo privileges set for the root user and the
admins
and wheel groups.
- From the command line on the master, navigate to the modules directory:
- Next, add the
privileges
andsudo
classes to default nodes.- From the command line on the master, navigate to the main manifest:
cd /etc/puppetlabs/code/environments/production/manifests
- Open
site.pp
with your text editor and add the following Puppet code to the default node:class { 'sudo': } sudo::conf { 'web': content => "web ALL=(ALL) NOPASSWD: ALL", } class { 'privileges': } sudo::conf { 'jargyle': priority => 60, content => "jargyle ALL=(ALL) NOPASSWD: ALL", }
The
sdo::conf ‘web’
line creates a sudoers rule to ensure that members of theweb
group can run any command using sudo. This resource creates a configuration fragment file to define this rule in/etc/sudoers.d/
.The
sudo::conf ‘jargyle’
line creates a sudoers rule to ensure that the userjargyle
can run any command using sudo. This resource creates a configuration fragment to define this rule in/etc/sudoers.d/
. It's called something like60_jargyle
. - Save and exit the file.
- On your master, ensure that there are no errors:
puppet parser validate site.pp
The parser returns nothing if there are no errors.
- From the command line on your agent, run Puppet:
puppet agent -t
That’s it! You have successfully applied
sudo
andprivileges
classes to nodes. - To confirm it worked, run the following command on an agent:
sudo -l -U jargyle
The results resemble the following:Matching Defaults entries for jargyle on this host: !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/usr/local/bin\:/sbin\:/bin\:/usr/sbin\:/usr/bin User jargyle may run the following commands on this host: (ALL) NOPASSWD: ALL
- From the command line on the master, navigate to the main manifest:
For more information about working with Puppet and sudo users, see our Module of The Week: saz/sudo - Manage sudo configuration blog post.
Puppet offers many opportunities for learning and training, from formal certification courses to guided online lessons. See the Learning Puppet page for more information.