lots of minor tweaks and updates

1-server-install.rst

@@ -106,7 +106,9 @@ workshop) and accept the defaults for configuring the reverse zone::
   Do you want to configure DNS forwarders? [yes]: no
   No DNS forwarders configured
   Do you want to search for missing reverse zones? [yes]:
-
+  Do you want to create reverse zone for IP 192.168.33.10 [yes]:
+  Please specify the reverse zone name [33.168.192.in-addr.arpa.]:
+  Using reverse zone(s) 33.168.192.in-addr.arpa.
 
 Next, you will be presented with a summary of the server
 configuration and asked for final confirmation.  Give confirmation to begin the
@@ -118,10 +120,15 @@ server installation::
   Domain name:    ipademo.local
   Realm name:     IPADEMO.LOCAL
 
+  The CA will be configured with:
+  Subject DN:   CN=Certificate Authority,O=IPADEMO.LOCAL
+  Subject base: O=IPADEMO.LOCAL
+  Chaining:     self-signed
+
   BIND DNS server will be configured to serve IPA domain with:
   Forwarders:       No forwarders
   Forward policy:   only
-  Reverse zone(s):  No reverse zone
+  Reverse zone(s):  33.168.192.in-addr.arpa.
 
   Continue to configure the system with these values? [no]: yes
 
@@ -129,7 +136,7 @@ The installation takes a few minutes; you will see output indicating
 the progress.
 
 When it completes, run ``kinit admin`` and enter your *admin*
-password to obtain a Kerberos ticket granting ticket (TGT) for the
+password to obtain a Kerberos *ticket granting ticket* (TGT) for the
 ``admin`` user::
 
   [server]$ kinit admin

10-ssh-key-management.rst

@@ -42,7 +42,7 @@ Generate a user keypair on the client system::
   Your identification has been saved in /home/alice/.ssh/id_rsa.
   Your public key has been saved in /home/alice/.ssh/id_rsa.pub.
   The key fingerprint is:
-  SHA256:TbuWICAdqkdXwG3uQoXxh03DuJdRC6Vh3ntOcacdfHM alice@ipademo.local
+  SHA256:KZ1MQCvaGAGZxKaMxmWBexzH98NPBsTsuo1uf/42SB0 alice@ipademo.local
   The key's randomart image is:
   +---[RSA 2048]----+
   |   .+=.o*oo      |
@@ -62,6 +62,7 @@ entry in FreeIPA::
 
   [alice@client]$ kinit alice
   Password for alice@IPADEMO.LOCAL:
+
   [alice@client]$ ipa user-mod alice \
       --sshpubkey="$(cat /home/alice/.ssh/id_rsa.pub)"
   ---------------------
@@ -78,14 +79,14 @@ entry in FreeIPA::
     SSH public key: ssh-rsa
                     AAAAB3NzaC1yc2EAAAADAQABAAABAQDH8pLi61DjkEPqNZnfOgGLLZfLdu9EqVL9UrZeXD3M/j3ig+xeDCCO80YjzuND0UZE4CHgA+uGrtoinQMYkt/FRkm/ie8wcinP/8BxSoOeYSHDNG+cG3iSNJrDiHoqPeQ/+nzBS5n6HWy18N5IMNoqC+f9f2VDuHWZCKqPHMLD29MAX6vOgawdHWFcAk416O+EgS43w3ub89+VPz3Egz4z9K+gjpoboFHk94n7n09B+qyzzImVMsz9vMFSr0rcaVRd9Tb0Q6HlUXkU7aH1Vjkl/DJdQalCpPYJXujkRYAZIs1ouU5IBuuq6k54fk1vBmwjv2tK2NkpvfWfhaxQVwdn
                     alice@ipademo.local
+    SSH public key fingerprint: C4:62:89:7A:65:F9:82:12:EF:08:96:D1:C9:7D:51:A5 alice@ipademo.local
+                                (ssh-rsa)
     Account disabled: False
     Password: True
     Member of groups: ipausers, sysadmin
     Indirect Member of Sudo rule: sysadmin_sudo
     Indirect Member of HBAC rule: sysadmin_all
     Kerberos keys available: True
-    SSH public key fingerprint: C4:62:89:7A:65:F9:82:12:EF:08:96:D1:C9:7D:51:A5 alice@ipademo.local
-                                (ssh-rsa)
 
 During enrolment of the systems, SSSD has been configured to use
 FreeIPA as one of its identity domains and OpenSSH has been
@@ -99,16 +100,16 @@ Logging in to the server using SSH public key authentication should
 now work::
 
   [alice@client]$ ssh -o GSSAPIAuthentication=no server.ipademo.local
+  Enter passphrase for key '/home/alice/.ssh/id_rsa':
   Last login: Tue Feb  2 15:10:13 2016
   [alice@server]$
 
-To verify the SSH public key was used for authentication, you can
+To verify that the SSH public key was used for authentication, you
-check the ``sshd`` service journal on the server, which should have
+can check the ``sshd`` log on the server::
-an entry like::
 
-  server.ipademo.local sshd[19729]: \
+  [server]$ sudo journalctl -u sshd -S "5 minutes ago" --no-pager
-    Accepted publickey for alice from 192.168.33.20 port 37244 \
+  -- Logs begin at Mon 2018-06-04 19:01:11 UTC, end at Mon 2018-06-11 04:55:19 UTC. --
-    ssh2: RSA SHA256:rgVSyPM/yn/b5bsZQIsAXWF+16zkP59VS9GS+k+bbOg
+  Jun 11 04:51:52 server.ipademo.local sshd[8570]: Accepted publickey for alice from 192.168.33.20 port 57596 ssh2: RSA SHA256:KZ1MQCvaGAGZxKaMxmWBexzH98NPBsTsuo1uf/42SB0
 
 
 Using FreeIPA as a backend store for SSH host keys
@@ -120,8 +121,8 @@ key.  The first time the host authenticates, the user may have to
 examine the target host's public key and manually authenticate it.
 The client then stores the host's public key in a ``known_hosts``
 file.  On subsequent attempts to log in, the client checks its
-``known_hosts`` files and automatically grants access to recognised
+``known_hosts`` files.  If the presented host key does not match the
-hosts.
+stored host key, the OpenSSH client refuses to continue.
 
 Based on the last exercise, try to figure out how to upload SSH host
 keys to the FreeIPA server.

2-client-install.rst

@@ -40,16 +40,16 @@ proceed::
 
   Continue to configure the system with these values? [no]: yes
 
-You might see a warning about time synchronisation, which for this
+Next, the client's time will be synchronised with the server, then
-workshop can be ignored.  Next you will be be prompted to enter
+the installer will prompt you to enter the credentials of a user
-credentials of a user authorised to enrol hosts (``admin``)::
+authorised to enrol hosts (``admin``)::
 
   User authorized to enroll computers: admin
   Password for admin@IPADEMO.LOCAL:
 
 The enrolment now proceeds; no further input is required.  You will
-see output detailing the operations being completed.  Unlike
+see output detailing the operations being completed.  Client
-``ipa-server-install``, client enrolment only takes a few seconds.
+enrolment only takes a few seconds.
 
 Users in your FreeIPA domain can now log into FreeIPA-enrolled
 hosts, subject to *Host-based access control* (HBAC) rules.  Users

3-user-management.rst

@@ -49,14 +49,13 @@ commands starting with ``cert-``::
   cert-remove-hold  cert-revoke       cert-status
 
 
-You'll notice that commands are grouped by *plugin*.  You can read a
+You'll notice that commands are grouped by *topic*, or the kind of
-general overview of a plugin by running ``ipa help <plugin>``, and
+object they act upon.  You can read a general overview of a plugin
-specific information on a particular command by running ``ipa help
+by running ``ipa help <topic>``, and specific information on a
-<command>``.
+particular command by running ``ipa help <command>``.
 
-Add a user named ``bob`` from the CLI.  See if you can work out how
+Add a user named ``bob`` from the CLI.  Use the CLI help to find the
-to do this using the CLI help commands.  (**hint**: the ``user``
+right command (**hint**: the ``user`` plugin provides the command).
-plugin provides the command).
 
 
 User authentication
@@ -115,7 +114,7 @@ is a true *single sign-on* protocol!
 
   [server]$ klist
   Ticket cache: KEYRING:persistent:1000:1000
-  Default principal: admin@IPADEMO.LOCAL
+  Default principal: bob@IPADEMO.LOCAL
 
   Valid starting       Expires              Service principal
   06/04/2018 21:45:50  06/05/2018 21:38:24  host/client.ipademo.local@IPADEMO.LOCAL

4-hbac.rst

@@ -12,7 +12,7 @@ they are trying to access (or its *Host Groups*), and (optionally)
 the service being accessed.
 
 In this unit, we will define an HBAC policy that restricts
-access to ``client.ipademo.local`` to members of the
+login access to ``client.ipademo.local`` to members of the
 ``sysadmin`` user group.
 
 
@@ -26,9 +26,9 @@ UI or the ``ipa`` CLI program (don't forget to ``kinit admin``; see
 if you can work out what plugin provides the host group
 functionality).
 
-**Hint:** if you use the CLI will need to run two commands - one to
+**Hint:** if you use the CLI will need to run two separate
-create the host group, and one to add ``client.ipademo.local`` as a
+commands—one to create the host group, then another to add
-member of the host group.
+``client.ipademo.local`` to the host group.
 
 
 Disabling the ``allow_all`` HBAC rule
@@ -118,7 +118,8 @@ command::
     Not matched rules: sysadmin_webservers
 
 Poor ``bob``.  He won't be allowed in because he is not a member of
-the ``sysadmin`` group.  What about ``alice``?
+the ``sysadmin`` group.  What is the result of ``ipa hbactest`` for
+``alice``?
 
 ``kinit`` as ``bob`` and try to log in to the client::
 
@@ -127,7 +128,9 @@ the ``sysadmin`` group.  What about ``alice``?
   [server]$ ssh bob@client.ipademo.local
   Connection closed by UNKNOWN port 65535
 
-Then try ``alice``::
+The server refused to let ``bob`` in and closed the connection.
+
+Now try ``alice``::
 
   [server]$ kinit alice
   Password for alice@IPADEMO.LOCAL:

5-web-app-authnz.rst

@@ -14,7 +14,8 @@ authentication to authenticate users, PAM to enforce HBAC rules, and
 user attributes.
 
 All activities in this unit take place on ``client`` unless
-otherwise specified.
+otherwise specified.  **Access the host via ``vagrant ssh client``**
+to ensure you have ``sudo`` access.
 
 The demo web application is trivial.  It just reads its request
 environment and responds in plain text with a list of variables
@@ -36,8 +37,8 @@ Create a service
 Create a *service* representing the web application on
 ``client.ipademo.local``.  A service principal name has the service
 type as its first part, separated from the host name by a slash,
-e.g.  ``HTTP/www.example.com``.  The host part must correspond to an
+e.g.  ``HTTP/www.example.com``.  The host part must be a host
-existing host in the directory.
+enrolled in FreeIPA.
 
 You must be getting the hang of FreeIPA by now, so I'll leave the
 rest of this step up to you.  (It's OK to ask for help!)
@@ -50,8 +51,7 @@ The service needs access to its Kerberos key in order to
 authenticate users.  Retrieve the key from the FreeIPA server and
 store it in a *keytab* file (you will need a TGT for ``admin``)::
 
-  [client]$ ipa-getkeytab -s server.ipademo.local \
+  [client]$ ipa-getkeytab -p HTTP/client.ipademo.local -k app.keytab
-            -p HTTP/client.ipademo.local -k app.keytab
   Keytab successfully retrieved and stored in: app.keytab
 
 We also have to move the file, change its ownership and apply the
@@ -115,7 +115,7 @@ and make a request using ``curl``::
     REMOTE_PORT: 42499
 
 The ``REMOTE_USER`` variable in the request environment indicates
-that there is a logged-in user and identifies that user.
+that there is an authenticated user, and identifies that user.
 
 
 Populating request environment with user attributes
@@ -128,8 +128,7 @@ attributes.  In this section, we will use mod_lookup_identity_ to
 populate the HTTP request environment with variables providing
 information about the authenticated user.
 
-.. _mod_lookup_identity: http://www.adelton.com/apache/mod_lookup_identity/
+.. _mod_lookup_identity: https://www.adelton.com/apache/mod_lookup_identity/
-
 
 ``mod_lookup_identity`` retrieves user attributes from SSSD (via D-Bus).
 Edit ``/etc/sssd/sssd.conf``; enable the SSSD ``ifp`` *InfoPipe*
@@ -181,7 +180,7 @@ environment.  The ``LookupUserXXX`` directives define the mapping of
 user attributes to request environment variables.  Multi-valued
 attributes can be expanded into multiple variables, as in the
 ``LookupUserGroupsIter`` directive.  Do not forget the
-``LoadModule`` directive!
+``LoadModule`` directive at the top!
 
 ::
 
@@ -207,7 +206,7 @@ attributes can be expanded into multiple variables, as in the
   </VirtualHost>
 
 Default SELinux policy prevents Apache from communicating with SSSD
-over D-Bus.  Flip ``httpd_dbus_sssd`` to ``1``::
+over D-Bus.  Set ``httpd_dbus_sssd`` to ``1``::
 
   [client]$ sudo setsebool -P httpd_dbus_sssd 1
 

6-cert-management.rst

@@ -4,54 +4,59 @@ Unit 6: Service certificates
 You probably noticed that the web service was not hosted over HTTPS,
 so there is no TLS-based authentication or confidentiality.  In this
 unit, we will issue an X.509 certificate for the web service via
-the *certmonger* program.
+the *Certmonger* program.
 
 Certmonger supports multiple CAs including FreeIPA's CA, and can
 generate keys, issue certifiate requests, track certificates, and
 renew tracked certificates when the expiration time approaches.
 Will also use ``mod_ssl`` with Apache.
 
+Issue the service certificate
+-----------------------------
+
 Let's start by confirming that the HTTP service does not yet have a
 certificate::
 
   [client]$ ipa service-show HTTP/client.ipademo.local
-    Principal: HTTP/client.ipademo.local@IPADEMO.LOCAL
+    Principal name: HTTP/client.ipademo.local@IPADEMO.LOCAL
+    Principal alias: HTTP/client.ipademo.local@IPADEMO.LOCAL
     Keytab: True
     Managed by: client.ipademo.local
 
-Enable and start certmonger::
+Enable and start Certmonger::
 
   [client]$ sudo systemctl enable certmonger
-  Created symlink from /etc/systemd/system/multi-user.target.wants/certmonger.service to /usr/lib/systemd/system/certmonger.service.
+  Created symlink /etc/systemd/system/multi-user.target.wants/certmonger.service → /usr/lib/systemd/system/certmonger.service.
   [client]$ sudo systemctl start certmonger
 
 Now let's request a certificate.  We will generate keys and store
 certificates in the NSS database at ``/etc/httpd/alias``::
 
-  [client]$ sudo ipa-getcert request -f /etc/pki/tls/certs/app.crt -k /etc/pki/tls/private/app.key \
+  [client]$ sudo ipa-getcert request \
-            -K HTTP/client.ipademo.local \
+              -f /etc/pki/tls/certs/app.crt \
-            -D client.ipademo.local
+              -k /etc/pki/tls/private/app.key \
+              -K HTTP/client.ipademo.local \
+              -D client.ipademo.local
   New signing request "20180603185400" added.
 
 Let's break down some of those command arguments.
 
 ``-k <path>``
-  Path to private key
+  Path to private key (Certmonger will generate it)
 ``-f <path>``
-  Path to certificate
+  Path to certificate (where it will be saved after being issued)
 ``-K <principal>``
-  Kerberos service principal; because different kinds of services may
+  Kerberos service principal; because different kinds of services
-  be accessed at one hostname, this argument is needed to tell
+  may be accessed at one hostname, this argument tells Certmonger
-  certmonger which service principal is the subject
+  which service principal is the subject
 ``-D <dnsname>``
   Requests the given domain name to appear in the *Subject
-  Alternative Name (SAN)* extension.  The hostname will appear in
+  Alternative Name (SAN)* extension; today the *Common Name (CN)*
-  the *Common Name (CN)* field but this practice is deprecated, so
+  field is no longer used by browsers so the SAN value is essential
-  it is important to also include it in the SAN extension.
 
-Another important argument is ``-N <subject-name>`` but this
+Another important option is ``-N <subject-name>``.  It defaults to
-defaults to the system hostname, which in our case
+the system hostname, which in our case (``client.ipademo.local``) is
-(``client.ipademo.local``) is appropriate.
+appropriate.
 
 Let's check the status of our certificate request using the tracking
 identifier given in the ``ipa-getcert request`` output::
@@ -77,13 +82,16 @@ identifier given in the ``ipa-getcert request`` output::
     auto-renew: yes
 
 
-Confirm that the certificate was issued and that certmonger is now
+Confirm that the certificate was issued and that Certmonger is now
 ``MONITORING`` the certificate and will ``auto-renew`` it when it is
 close to expiration.  Now if you run ``ipa service-show``, you will
 see a number of attributes related to the certificate, including the
 certificate itself.  Can you work out how to save the PEM-encoded
 certificate to a file?
 
+Set up TLS for Apache
+---------------------
+
 Now we can reconfigure Apache to serve our app over TLS.  Update
 ``app.conf`` to listen on port 443 and add the SSL directives::
 

7-replica-install.rst

@@ -6,25 +6,29 @@ Unit 7: Replica installation
 - `Unit 1: Installing the FreeIPA server <1-server-install.rst>`_
 
 FreeIPA is designed to be run in a replicated multi-master
-environment.  In this unit, we will deploy a single FreeIPA
+environment.  In this unit, we will install a replica of the
-replica.  For recommended production topologies, see
+existing master.  For recommended production topologies, see
-http://www.freeipa.org/page/Deployment_Recommendations#Replicas.
+https://www.freeipa.org/page/Deployment_Recommendations#Servers.2FReplicas.
 
 If you have disabled the ``allow_all`` HBAC rule, add a new rule
 that will **allow ``admin`` to access the ``sshd`` service on any
 host**.
 
-[To be confirmed] As of FreeIPA 4.3, replica installation is accomplished by
+Client installation
-*promoting* an enrolled client machine to a server.
+-------------------
 
-SSH to the ``replica`` VM and enrol it per `Unit 2: Enrolling
+The first step of replica creation is to enrol the machine that will
-client machines`_.
+become the replica.  SSH to the ``replica`` VM and enrol it per
+`Unit 2: Enrolling client machines <2-client-install.rst>`_
+
+Replica promotion
+-----------------
 
 Now promote the client to server.  We will set up the replica
-*without* CA or DNS, but in a production deployment there should be
+*without* the CA or DNS role.  In a production deployment there
-at least one instance of these services in each datacentre.  These
+should be at least one instance of these services in each data
-components can be added later via ``ipa-ca-install(1)`` and
+centre.  These roles can be configured later via
-``ipa-dns-install(1)``.
+``ipa-ca-install(1)`` and ``ipa-dns-install(1)``.
 
 ::
 

8-sudorule.rst

@@ -36,9 +36,11 @@ Observe that the action is denied::
 
   [client]$ su -l alice
   Password:
+
   [alice@client]$ sudo id
   [sudo] password for alice:
   alice is not allowed to run sudo on client.  This incident will be reported.
+
   [alice@client]$ exit
   logout
 
@@ -75,6 +77,7 @@ Now attempt to ``sudo id`` as ``alice`` again::
 
   [client]$ su -l alice
   Password:
+
   [alice@client]$ sudo id
   [sudo] password for alice:
   uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
@@ -82,6 +85,9 @@ Now attempt to ``sudo id`` as ``alice`` again::
 This time the action was allowed, and we can see from the output
 that ``alice`` indeed executed the ``id`` command as ``root``.
 
+**Note:** if the command is prevented there may be some stale cache
+entries.  Move on with the workshop and try again in 5 minutes.
+
 
 Permitting ``bob`` to run web administration commands
 -----------------------------------------------------
@@ -93,6 +99,7 @@ observe that ``bob`` currently cannot restart Apache::
 
   [client]$ su -l bob
   Password:
+
   [bob@client]$ sudo systemctl restart httpd
   [sudo] password for bob:
   Sorry, user bob is not allowed to execute '/bin/systemctl restart httpd' as root on client.ipademo.local.
@@ -115,7 +122,7 @@ Now define the ``webadmin_sudo`` rule.  Note that we *do not* use
     Enabled: TRUE
     RunAs User category: all
     RunAs Group category: all
-  [client]$
+
 
 Add the ``webadmin`` User Group and ``webservers`` Host Group to the rule::
 
@@ -128,6 +135,7 @@ Add the ``webadmin`` User Group and ``webservers`` Host Group to the rule::
   -------------------------
   Number of members added 1
   -------------------------
+
   [client]$ ipa sudorule-add-host webadmin_sudo --hostgroup webservers
     Rule name: webadmin_sudo
     Enabled: TRUE
@@ -147,16 +155,19 @@ web server administration::
   Added Sudo Command "/usr/bin/systemctl start httpd"
   ---------------------------------------------------
     Sudo Command: /usr/bin/systemctl start httpd
+
   [client]$ ipa sudocmd-add "/usr/bin/systemctl restart httpd"
   -----------------------------------------------------
   Added Sudo Command "/usr/bin/systemctl restart httpd"
   -----------------------------------------------------
     Sudo Command: /usr/bin/systemctl restart httpd
+
   [client]$ ipa sudocmdgroup-add webadmin_cmds
   ----------------------------------------
   Added Sudo Command Group "webadmin_cmds"
   ----------------------------------------
     Sudo Command Group: webadmin_cmds
+
   [client]$ ipa sudocmdgroup-add-member webadmin_cmds \
       --sudocmds "/usr/bin/systemctl start httpd" \
       --sudocmds "/usr/bin/systemctl restart httpd"
@@ -186,8 +197,10 @@ restart (or start) Apache, but not run other commands via ``sudo``::
 
   [client]$ su -l bob
   Password:
+
   [bob@client]$ sudo systemctl restart httpd
   [sudo] password for bob:
+
   [bob@client]$ sudo id
   Sorry, user bob is not allowed to execute '/bin/id' as root on client.ipademo.local.
 

9-selinux-user-map.rst

@@ -10,19 +10,20 @@ Unit 9: SELinux User Maps
 SELinux is a *mandatory access controls* mechanism for Linux,
 providing more powerful and flexible access control than traditional
 Unix permissions.  Users have an SELinux *context* consisting of a
-*user*, *role* and *type*.  The goal of this unit is to cause users
+*user*, *role* and *type*.  In this unit, you will cause users
 to be *confined* by an SELinux *role-based access control (RBAC)*
 policy when the log into hosts that are members of the
-``webservers`` Host Group.
+``webservers`` Host Group.  You will also learn how to change a
-
+user's SELinux context when they execute commands via Sudo.
-..
-  - users can have different selinux policy on diff hosts
 
 **Note:** SELinux contexts are applied during PAM-based login, so
 when testing our changes in this unit ``su -l <user>`` will not
 suffice: it is necessary to log in via SSH.  You can do this from
 any of the VMs (even ``client`` itself).
 
+Confining users
+---------------
+
 Log in as ``alice`` and run ``id -Z`` to see her current SELinux
 context::
 
@@ -62,6 +63,7 @@ by the ``staff_u`` policy::
   [server]$ ssh alice@client.ipademo.local
   alice@client.ipademo.local's password:
   Last login: Fri Sep  2 05:47:03 2016
+
   [alice@client]$ id -Z
   staff_u:staff_r:staff_t:s0-s0:c0.c1023
 
@@ -83,15 +85,17 @@ inherit a user's context, as the following commands demonstrate::
 
   [alice@client]$ sudo -s
   [sudo] password for alice:
-  sh-4.3# id -Z
-  staff_u:staff_r:staff_t:s0-s0:c0.c1023
-  sh-4.3# systemctl restart httpd
-  Failed to restart httpd.service: Access denied
-  See system logs and 'systemctl status httpd.service' for details.
-  sh-4.3#
 
-Now let's make it so that ``alice`` can do her job.  We need to
+  sh-4.4# id
-update the Sudo rule to change the SELinux context::
+  uid=0(root) gid=0(root) groups=0(root) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
+
+  sh-4.4# echo "Hello, world!" > /etc/motd
+  sh: /etc/motd: Permission denied
+
+As you can see, ``alice`` became ``root``, but the SELinux
+confinement prevents her from writing ``/etc/motd`` (and many other
+things).  Let's make it so that ``alice`` can do her job.  We need
+to update the Sudo rule to change the SELinux context::
 
   [alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption type=unconfined_t
   -------------------------------------------------------------
@@ -104,6 +108,7 @@ update the Sudo rule to change the SELinux context::
     RunAs User category: all
     RunAs Group category: all
     Sudo Option: type=unconfined_t
+
   [alice@client]$ ipa sudorule-add-option sysadmin_sudo --sudooption role=unconfined_r
   -------------------------------------------------------------
   Added option "role=unconfined_r" to Sudo Rule "sysadmin_sudo"
@@ -120,11 +125,14 @@ Now when ``alice`` runs ``sudo`` it changes the SELinux context of
 the program being run::
 
   [alice@client]$ sudo -s
-  sh-4.3# id -Z
-  staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-  sh-4.3# systemctl restart httpd
-  sh-4.3#
 
+  sh-4.4# id -Z
+  staff_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
+
+  sh-4.4# echo "Hello, world!" > /etc/motd
+
+  sh-4.4# cat /etc/motd
+  Hello, world!
 
 This concludes the unit.  You can now proceed to
 `Unit 10: SSH user and host key management <10-ssh-key-management.rst>`_

workshop.rst

@@ -70,12 +70,10 @@ Preparation
 
 Some preparation is needed prior to the workshop.  The workshop is
 designed to be carried out in a Vagrant_ environment that configures
-three virtual machines with all software network configuration ready
+three networked virtual machines (VMs) with all software needed for
-for the workshop.
+the workshop.  **The goal of this preparation** is to ``vagrant up``
-
+the VMs.  After this preparation is completed you are ready to begin
-several VMs.  **The goal of the preparation** is to be able to
+the workshop.
-successfully ``vagrant up`` the VMs as the first step of the
-workshop.
 
 .. _Vagrant: https://www.vagrantup.com/
 
@@ -235,9 +233,9 @@ so it may not be feasible to download it during the workshop.
 Add hosts file entries
 ----------------------
 
-*This step is necessary if you want to access the FreeIPA Web UI in
+*This step is optional.  All units can be completed using the CLI
-the VM from a browser on your host, but otherwise this step is optional. All
+only.  But if you want to access the FreeIPA Web UI or other web
-workshop units can be completed using the CLI.*
+servers on the VMs from your browser, follow these instructions.*
 
 Add the following entries to your hosts file::