diff --git a/.nojekyll b/.nojekyll
index 53a239c8..e625decc 100644
--- a/.nojekyll
+++ b/.nojekyll
@@ -1 +1 @@
-9985d21a
\ No newline at end of file
+07824c48
\ No newline at end of file
diff --git a/chapters/append/auth.html b/chapters/append/auth.html
index f207d667..096e7954 100644
--- a/chapters/append/auth.html
+++ b/chapters/append/auth.html
@@ -7,7 +7,7 @@
 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
 
 
-<title>DevOps for Data Science - Appendix A — Auth Technologies</title>
+<title>DevOps for Data Science - Appendix A — Technical Detail: Auth Technologies</title>
 <style>
 code{white-space: pre-wrap;}
 span.smallcaps{font-variant: small-caps;}
@@ -84,7 +84,7 @@
       <button type="button" class="quarto-btn-toggle btn" data-bs-toggle="collapse" data-bs-target="#quarto-sidebar,#quarto-sidebar-glass" aria-controls="quarto-sidebar" aria-expanded="false" aria-label="Toggle sidebar navigation" onclick="if (window.quartoToggleHeadroom) { window.quartoToggleHeadroom(); }">
         <i class="bi bi-layout-text-sidebar-reverse"></i>
       </button>
-      <nav class="quarto-page-breadcrumbs" aria-label="breadcrumb"><ol class="breadcrumb"><li class="breadcrumb-item"><a href="../../chapters/append/auth.html">Appendices</a></li><li class="breadcrumb-item"><a href="../../chapters/append/auth.html"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></a></li></ol></nav>
+      <nav class="quarto-page-breadcrumbs" aria-label="breadcrumb"><ol class="breadcrumb"><li class="breadcrumb-item"><a href="../../chapters/append/auth.html">Appendices</a></li><li class="breadcrumb-item"><a href="../../chapters/append/auth.html"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></a></li></ol></nav>
       <a class="flex-grow-1" role="button" data-bs-toggle="collapse" data-bs-target="#quarto-sidebar,#quarto-sidebar-glass" aria-controls="quarto-sidebar" aria-expanded="false" aria-label="Toggle sidebar navigation" onclick="if (window.quartoToggleHeadroom) { window.quartoToggleHeadroom(); }">      
       </a>
       <button type="button" class="btn quarto-search-button" aria-label="Search" onclick="window.quartoOpenSearch();">
@@ -294,7 +294,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link active">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -345,7 +345,7 @@ <h2 id="toc-title">Table of contents</h2>
 
 <header id="title-block-header" class="quarto-title-block default">
 <div class="quarto-title">
-<h1 class="title"><span id="sec-append-auth" class="quarto-section-identifier">Appendix A — Auth Technologies</span></h1>
+<h1 class="title"><span id="sec-append-auth" class="quarto-section-identifier">Appendix A — Technical Detail: Auth Technologies</span></h1>
 </div>
 
 
@@ -360,9 +360,9 @@ <h1 class="title"><span id="sec-append-auth" class="quarto-section-identifier">A
 
 </header>
 
-<p><a href="../sec3/3-2-auth.html">Chapter&nbsp;<span>16</span></a> was all about a conceptual understanding of how auth works and what SSO is. In that chapter, we briefly mentioned a few technologies used to do auth, including LDAP/AD, SAML, and OIDC/OAuth2.0.</p>
-<p>In this appendix chapter we’ll get a little deeper into these technologies. Having a basic understanding of these technologies can be helpful when you’re talking to IT/Admins. That said, it’s definitely beyond the scope of most people’s need to understand, which is why this is an appendix.</p>
-<p>In terms of auth technologies, there are two big distinctions. The first is between “token-based” systems that can do SSO and others that that cannot. There is also a distinction between modern systems that are designed to work with cloud services and legacy systems that were designed during the on-prem era.</p>
+<p><a href="../sec3/3-2-auth.html">Chapter&nbsp;<span>16</span></a> provided a conceptual understanding of how auth works and what SSO is. I also briefly mentioned a few technologies used to do auth, including LDAP/AD, SAML, and OIDC/OAuth2.0. We’ll get a little deeper into them in this appendix chapter.</p>
+<p>Having a basic understanding of these technologies can be helpful when you’re talking to IT/Admins about a data science platform. That said, this topic is beyond the scope of what you <strong>need</strong> to understand, which is why this is an appendix.</p>
+<p>There are two big distinctions between auth technologies. One is between systems that pass tokens to services and, therefore, can do SSO and other systems that provide credentials to the service.<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> The other is between modern systems that are designed to work with cloud services and legacy systems that were designed for on-prem software.</p>
 <table class="table">
 <thead>
 <tr class="header">
@@ -379,7 +379,7 @@ <h1 class="title"><span id="sec-append-auth" class="quarto-section-identifier">A
 </tr>
 <tr class="even">
 <td>Linux Accounts</td>
-<td>❌<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a></td>
+<td>❌<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a></td>
 <td>❌</td>
 </tr>
 <tr class="odd">
@@ -404,28 +404,31 @@ <h1 class="title"><span id="sec-append-auth" class="quarto-section-identifier">A
 </tr>
 </tbody>
 </table>
-<p>These days, token-based systems are very much preferred for security reasons. Users only ever provide credentials to a centralized identity provider and the rest of the process is just trading one secure token for another.</p>
-<p>The other benefit of token auth is session expiration. In most systems, you don’t have to re-authenticate every single time you access it. In a credential-based system, that means that you usually trade your credentials for a <em>browser cookie</em> issued by the service, which the service then looks for and lets you skip logging in again. Generally, the cookie won’t be reissued until it expires and you have to log in again. So these cookies generally have pretty long lifetimes. That means that if someone unauthorized were to get a cookie, they could have access for a long time. And if someone gets removed from the system, that won’t actually take effect until the cookie expires.</p>
-<p>In contrast, tokens expiration is centrally-managed. Every time a token expires, the identity provider is consulted to see if the user should be allowed to get a new one. This can happen without the user needing to login again, allowing token lifetimes to be very short. That drastically limits the potential of someone unauthorized getting a token. While it’s bad for someone to ever get unauthorized access, having it for only an hour is way less bad than having it for days or weeks. Additionally, if you need to remove someone from the system, you know that they’ll be completely locked out as soon as their token expires.</p>
+<p>Token-based systems are rising in popularity because they are more convenient for admins and users and are more secure.</p>
+<p>One reason token-based systems are more secure is because of credential handling. In a non token system, the user provides their credentials directly to the services, which passes them along to authenticate. This means you have to trust the service with the credentials. Additionally, if you wanted to use advanced credentials like MFA, biometrics, or passkeys, the service itself would have to implement them. Most services do not, so username and password credentials are the only option.</p>
+<p>In contrast, credentials are only ever provided to the trusted identity provider in a token system. That means only the identity provider needs to implement advanced credentials and less trust in the service is required because it never sees user credentials.</p>
+<p>Token systems are also more secure because of how sessions expire. No system requires users to log in every single visit to a service. That’s too demanding. Instead, the system issues a cookie or token that will let the user back in without re-authenticating.</p>
+<p>In a credential system, the service itself issues a <em>browser cookie</em> that allows the user back in without re-authenticating until it expires and it’s time to authenticate again. That’s usually a relatively long time, sometimes multiple days.</p>
+<p>In a token system, the token to a service has a much shorter life than the time to re-authenticate. When the service encounters an expired token, it checks if the user should have access against the identity provider. This means that changes to authorization propagate as quickly as the short-lived service tokens expire. That drastically limits the risk of a stolen token or someone trying to log back in after they’ve been locked out.</p>
 <section id="service-based-auth" class="level2" data-number="A.1">
 <h2 data-number="A.1" class="anchored" data-anchor-id="service-based-auth"><span class="header-section-number">A.1</span> Service-based auth</h2>
-<p>Many pieces of software come with integrated authentication. When you use those systems, the service stores encrypted username and password pairs in a database it owns. These setups are often really easy from an admin perspective – you just set up individual users on the service.</p>
-<p>On the other hand, everything has to be managed service-by-service and you’re only as secure as what the service has implemented. Almost any organization with an IT/Admin group will prefer not to use service-based auth.</p>
+<p>Many pieces of software come with integrated authentication. When you use those systems, the service stores encrypted username and password pairs in its own database. If you’re administering a single service, this is really simple. You just set up individual users on the service.</p>
+<p>But once you have multiple services, everything has to be managed service-by-service. And the system is only as secure as what the service has implemented. Almost any organization with an IT/Admin group will prefer not to use service-based auth.</p>
 </section>
 <section id="system-linux-accounts" class="level2" data-number="A.2">
 <h2 data-number="A.2" class="anchored" data-anchor-id="system-linux-accounts"><span class="header-section-number">A.2</span> System (Linux) Accounts</h2>
-<p>Many pieces of software – especially data science workbenches – are able to look at the server they’re sitting on and use the user accounts and groups from the server themselves.</p>
-<p>On a Linux server, <em>Pluggable Authentication Modules (PAM)</em> is the system that allows a service to make use of the Linux host’s users and groups. As of this writing, PAM is the default authentication method for both RStudio Server and JupyterHub.</p>
-<p>As the name might suggest, PAM includes a number of different modules that allow it to authenticate against different systems. The most common is to authenticate against the underlying Linux server, but it can also use LDAP/AD or Kerberos tickets (uncommon).</p>
+<p>Many pieces of software – especially data science workbenches – can look at the server it’s sitting on and authenticate against the user accounts and groups on the server.</p>
+<p>On a Linux server, <em>Pluggable Authentication Modules (PAM)</em> allow a service to make use of the Linux host’s users and groups. As of this writing, PAM is the default authentication method for RStudio Server and JupyterHub.</p>
+<p>As the name suggests, PAM includes modules that allow it to authenticate against different systems. The most common is to authenticate against the underlying Linux server, but it can also use LDAP/AD (common) or Kerberos tickets (uncommon).</p>
 <p><img src="images/auth-pam.png" class="img-fluid" width="539"></p>
-<p>PAM can also be used to do things when users login – the most common being initializing Kerberos tickets to connect with databases.</p>
-<p>When PAM is used in concert with LDAP/AD, the Linux users are usually created automatically on the system using a system called <em>SSSD (System Security Services Daemon)</em>. This process is called <em>joining the domain</em>.</p>
-<p>Though conceptually simple, reading, writing, and managing PAM modules is quite painful. Additionally, as more services move to the cloud, there isn’t necessarily an underlying Linux host where identities live and PAM is generally considered a legacy technology.</p>
+<p>PAM can also be used to do things when users log in. The most common of these is initializing Kerberos tickets to connect with databases or connecting with shared drives.</p>
+<p>When PAM is used in concert with LDAP/AD, the Linux users are usually created automatically on the system using <em>SSSD (System Security Services Daemon)</em>. This process is called <em>joining the domain</em>.</p>
+<p>Though conceptually simple, the syntax of PAM modules is confusing, and reading, writing, and managing PAM modules is onerous. Additionally, as more services move to the cloud, there isn’t necessarily an underlying Linux host where identities live and PAM can’t be used at all.</p>
 </section>
 <section id="ldapad" class="level2" data-number="A.3">
 <h2 data-number="A.3" class="anchored" data-anchor-id="ldapad"><span class="header-section-number">A.3</span> LDAP/AD</h2>
-<p>For many years, Microsoft’s Lightweight Directory Access Protocol (LDAP) implementation called Active Directory (AD) was basically the standard in enterprise authentication. It is increasingly being retired in favor of token-based systems like SAML and OAuth2.0.</p>
-<p>Depending on the service, it may use LDAP/AD indirectly via PAM, or it may be directly configured to talk to LDAP/AD.</p>
+<p>For many years, Microsoft’s Lightweight Directory Access Protocol (LDAP) implementation called Active Directory (AD) was the standard in enterprise auth. It is increasingly being retired in favor of token-based systems like SAML and OAuth2.0.</p>
+<p>Some services can use LDAP/AD indirectly via PAM, while others may be directly configured to talk to LDAP/AD.</p>
 <div class="callout callout-style-default callout-note callout-titled">
 <div class="callout-header d-flex align-content-center">
 <div class="callout-icon-container">
@@ -439,8 +442,8 @@ <h2 data-number="A.3" class="anchored" data-anchor-id="ldapad"><span class="head
 <p>LDAP is an application-layer protocol, like HTTP. And like HTTP, there is an SSL-secured version called LDAPS. Because LDAP is almost always used only inside a private network, adoption of LDAPS is uneven. The default port for LDAP is <span class="math inline">\(389\)</span> and for LDAPS it’s <span class="math inline">\(636\)</span>.</p>
 </div>
 </div>
-<p>LDAP/AD actually isn’t a type of authentication. It’s a hierarchical tree database that is good for storing organizational entities. Doing authentication with LDAP/AD consists of sending a search for the provided username/password combination to the LDAP/AD database using the <code>ldapsearch</code> command.</p>
-<p>When you configure LDAP/AD in an application, you’ll configure a <em>search base</em>, which is the subtree to look for users inside. Additionally, you may configure LDAP/AD with <em>bind credentials</em> to validate that it’s allowed to be looking things up in the server.</p>
+<p>Strictly speaking, LDAP/AD isn’t an authentication tool. It’s a hierarchical tree database that is good for storing organizational entities. Doing authentication with LDAP/AD consists of sending a search for the provided username/password combination to the LDAP/AD database using the <code>ldapsearch</code> command.</p>
+<p>When you configure LDAP/AD in an application, you’ll configure a <em>search base</em>, which is the subtree to look for users inside. Additionally, you may configure LDAP/AD with <em>bind credentials</em> of a service account to authenticate to the LDAP/AD server itself.</p>
 <p><img src="images/auth-ldap.png" class="img-fluid" alt="A diagram of the LDAP flow. 1-User provides username and password to service. 2-service sends bind credentials w/ ldapsearch to LDAP server. 3-LDAP server checks credentials. 4-LDAP server returns results to service." width="600"></p>
 <div class="callout callout-style-default callout-note callout-titled">
 <div class="callout-header d-flex align-content-center">
@@ -452,10 +455,10 @@ <h2 data-number="A.3" class="anchored" data-anchor-id="ldapad"><span class="head
 </div>
 </div>
 <div class="callout-body-container callout-body">
-<p>Depending on your application and LDAP/AD configuration, it may be possible to skip the bind credentials and use the user’s credentials to look them up in <em>single-bind</em> mode (as opposed to <em>double-bind</em> when there are bind credentials). Single-bind is generally inferior and shouldn’t be used unless you can’t get bind credentials.</p>
+<p>Depending on your application and LDAP/AD configuration, it may be possible to skip the bind credentials look up the user with their own credentials in <em>single-bind</em> mode, as opposed to <em>double-bind</em> when there are bind credentials. Single-bind is inferior and shouldn’t be used unless you can’t get bind credentials.</p>
 </div>
 </div>
-<p>When you run an <code>ldapsearch</code>, you get back the <em>distinguished name (DN)</em> of the entity that you are looking for (assuming it’s found).</p>
+<p>An <code>ldapsearch</code> returns the <em>distinguished name (DN)</em> of the entity that you are looking for – assuming it’s found.</p>
 <p>Here’s what my entry in a corporate LDAP directory might look like this:</p>
 <pre><code>cn: Alex Gold
 mail: alex.gold@example.com
@@ -463,50 +466,49 @@ <h2 data-number="A.3" class="anchored" data-anchor-id="ldapad"><span class="head
 department: solutions
 mobile: 555-555-5555
 objectClass: Person</code></pre>
-<p>This is helpful information, but you’ll note that there’s no direct information about authorization. Instead, you configure the service authorize certain users or groups. This is a pain, as each service needs to be configured separately.</p>
-<p>One of the big issues with LDAP/AD is that credentials are provided to the service, which passes them along to the LDAP/AD server. This is one reason why LDAP/AD is inferior to token-based technologies, where the credentials are only ever provided to the identity provider.</p>
+<p>This is helpful information, but you’ll note that there’s no direct information about authorization. Instead, you configure the service to authorize certain users or groups. This is time-consuming and error-prone, as each service needs to be configured separately.</p>
 </section>
 <section id="sec-kerberos" class="level2" data-number="A.4">
 <h2 data-number="A.4" class="anchored" data-anchor-id="sec-kerberos"><span class="header-section-number">A.4</span> Kerberos Tickets</h2>
-<p>Kerberos is a relatively old, but very secure, token-based auth technology for use inside a private network. In Kerberos, encrypted tokens called <em>Kerberos tickets</em> are passed between the servers in the system. A system that is designed to authenticate against a Kerberos ticket is called <em>kerberized</em>.<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a></p>
-<p>Though Kerberos is freely available, it was widely adopted along with Active Directory, and it’s used almost exclusively in places that are running a lot of Microsoft products. The most frequent use of Kerberos tickets these days is to establish connections to Microsoft databases.</p>
-<p>Kerberos is tightly linked to the underlying servers, one of the reasons why it is so secure. In a Kerberos-based system, users often store their credentials in a secure file called a <em>keytab</em>. They can manually initialize a ticket using the <code>kinit</code> command, though PAM sessions are often used to automatically fetch a ticket upon user login.</p>
-<p>When a Kerberos session is initialized, the service sends the users’ credentials off to the central <em>Kerberos Domain Controller (KDC)</em> and requests something called the <em>Ticket Granting Ticket (TGT)</em> from the KDC. Like most token authentication, TGTs have a set expiration period and must be reacquired when they expire.</p>
+<p>Kerberos is a relatively old, but very secure, token-based auth technology for use inside a private network. In Kerberos, encrypted tokens called <em>Kerberos tickets</em> are passed between the servers in the system. A system that is designed to authenticate against a Kerberos ticket is called <em>kerberized</em>.</p>
+<p>Kerberos was widely adopted along with Active Directory, and it’s used almost exclusively in places that are running a lot of Microsoft products. The most frequent use of Kerberos tickets is to establish connections to Microsoft databases.</p>
+<p>In a Kerberos-based system, users often store their credentials in a secure <em>keytab</em>, which is a file on disk. They can manually initialize a ticket using the <code>kinit</code> command or via a PAM session that automatically fetches a ticket upon user login.</p>
+<p>When a Kerberos session is initialized, the service sends the user’s credentials off to the central <em>Kerberos Domain Controller (KDC)</em> and requests the <em>Ticket Granting Ticket (TGT)</em> from the KDC. Like most token authentication, TGTs have a set expiration period and must be reacquired when they expire.</p>
 <p>When the user wants to access a service, they send the TGT back to the KDC again along with the service they’re trying to access and get a <em>session key</em> (sometimes referred to as a <em>service ticket</em>) that allows access to a particular service.</p>
 <p><img src="images/auth-kerberos.png" class="img-fluid" alt="The kerberos flow. 1 - User on server requests TGT from KDC. 2 - TGT granted. 3 - user requests service ticket with TGT from KDC. 4 - Service ticket granted. 5 - user uses service ticket to access service." width="553"></p>
-<p>Kerberos is basically only used inside a corporate network. This is one reason it’s still considered secure. On the other hand, because everything has to live inside the network, it doesn’t work well for providing access to services outside the network, like SaaS software. For that reason, Kerberos is considered a legacy tool.</p>
+<p>Kerberos is only used inside a corporate network and is tightly linked to the underlying servers. That makes it very secure. Even if someone stole a Kerberos ticket, it would be very hard for them to use it.</p>
+<p>On the other hand, because Kerberos is so tightly tied to servers, it is a difficult fit alongside cloud technologies and services.</p>
 </section>
 <section id="oauth-saml" class="level2" data-number="A.5">
 <h2 data-number="A.5" class="anchored" data-anchor-id="oauth-saml"><span class="header-section-number">A.5</span> Modern systems: OAuth + SAML</h2>
-<p>These days, most organizations are quickly moving towards implementing a modern token-based authentication system through SAML and/or OAuth2.0.</p>
-<p>When you go to login to a service that uses SAML or OAuth, you are redirected to the SAML/OAuth identity provider to seek a token that will let you in. Assuming all goes well, you’re granted a token and go back to the service to go do your work.</p>
+<p>Most organizations are now quickly moving toward implementing a modern token-based authentication system through SAML and/or OAuth2.0.</p>
+<p>When you go to log in to a service that uses SAML or OAuth, you are redirected to the SAML/OAuth identity provider to seek a token that will let you in. Assuming all goes well, you’re granted a token and go back to the service to do your work.</p>
 <p>Both OAuth and SAML rely on plain HTTP traffic, making them easier to configure than LDAP/AD or Kerberos from a networking standpoint.</p>
 <section id="saml" class="level3" data-number="A.5.1">
 <h3 data-number="A.5.1" class="anchored" data-anchor-id="saml"><span class="header-section-number">A.5.1</span> SAML</h3>
-<p>The current SAML 2.0 standard was finalized in 2005 – roughly coinciding with the beginning of the modern era of the web. Facebook was started just the prior year.</p>
-<p>SAML was invented to be a modern successor to enterprise auth methods like LDAP/AD and Kerberos. SAML uses encrypted and cryptographically-signed XML-based tokens that are generated through a browser redirect flow.</p>
-<p>In SAML, the service you’re accessing is called the <em>service provider</em> (SP) and the entity issuing the token is called the SAML <em>identity provider</em> (IdP). Most SAML tooling allows you start at either the IdP or the SP.</p>
-<p>If you start at the SP, you’ll get redirected to the IdP. The IdP will verify your credentials. If all is good, it will put a SAML token in your browser, which the SP will use to authenticate you.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a></p>
+<p>The current SAML 2.0 standard was finalized in 2005, roughly coinciding with the beginning of the web’s modern era, with Facebook launching just the prior year.</p>
+<p>SAML was invented to be a successor to enterprise auth methods like LDAP/AD and Kerberos. SAML uses encrypted and cryptographically signed XML tokens that are generated through a browser redirect flow.</p>
+<p>In SAML, the service you’re accessing is called the <em>service provider</em> (SP) and the entity issuing the token is the SAML <em>identity provider</em> (IdP). Most SAML tooling allows you start at either the IdP or the SP.</p>
+<p>If you start at the SP, you’ll get redirected to the IdP. The IdP will verify your credentials. If the credentials are valid, the IdP will put a SAML token in your browser, which the SP will use to authenticate you.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a></p>
 <p><img src="images/auth-saml.png" class="img-fluid" width="600"></p>
-<p>A SAML token contains a number of <em>claims</em>, which usually include a username and may include groups or other attributes. Whoever controls the IdP can configure what claims appear on the token at the IdP. The SAML standard itself doesn’t do authorization, but it’s very common for an application to have required or optional claims that it can interpret to do authorization.</p>
+<p>A SAML token contains several <em>claims</em>, which usually include a username and may include groups or other attributes. Whoever controls the IdP can configure what claims appear on the token at the IdP. The SAML standard itself is for authentication, not authorization, but it’s very common for an application to have required or optional claims that it can interpret to do authorization.</p>
 </section>
 <section id="oauth" class="level3" data-number="A.5.2">
 <h3 data-number="A.5.2" class="anchored" data-anchor-id="oauth"><span class="header-section-number">A.5.2</span> OAuth</h3>
 <p>OAuth was started in 2006 and the current 2.0 standard was finalized in 2013. OAuth 2.1 is under development as of 2023.</p>
-<p>From the very beginning, OAuth was designed to be used with different services across the web. Any time you’ve used a <em>Login with Google/Facebook/Twitter/GitHub</em> flow – that’s OAuth.</p>
-<p>OAuth relies on passing around cryptographically-signed JSON Web Tokens (JWT). This makes OAuth much easier to debug compared to SAML because the JWT is just plain-text JSON with a signature that proves it’s valid.</p>
-<p>Unlike a SAML token that always lives in a browser cache, JWTs can go basically anywhere. They can live in the browser, but they also can pass from one server to another to do authorization or can be saved in a user’s home directory. For example, if you’ve accessed Google Sheets or another Google service from R or Python, you may have manually handled the resulting OAuth token in your home directory.</p>
-<p>OAuth is actually an authorization scheme, so the contents of a JWT explicitly are about the permissions of the bearer of the token. There is a related standard called <em>OpenID Connect (OIDC)</em> that does authentication with OAuth tokens. Over the next few years, I fully expect basically all data access to move towards using OAuth tokens.</p>
-<p>In OAuth, the service you’re trying to visit is called the <em>resource server</em> and the token issuer is the <em>authorization server</em>. When you try to access a service, the service knows to look for a JWT that includes specific <em>claims</em> against a set of <em>scopes</em> defined ahead of time.</p>
-<p>For example, if you want to read my Google Calendar, you would need to have a JWT that includes a claim granting <em>read</em> access against the scope of <em>events on Alex’s calendar</em>.</p>
-<p>If you don’t have that token, you’ll need to go to the authorization server to get it. Unlike in SAML where action is all occurring via HTTP redirects, OAuth makes no assumptions about how this flow happens.</p>
+<p>OAuth was designed to be used with different services across the web from the beginning. Any time you’ve used a <em>Log in with Google/Facebook/Twitter/GitHub</em> flow – that’s OAuth.</p>
+<p>OAuth relies on passing around cryptographically signed JSON Web Tokens (JWTs). This makes OAuth more straightforward to debug than SAML because the JWT is plain-text JSON with a signature that proves it’s valid.</p>
+<p>Unlike a SAML token that always lives in a browser cache, JWTs can go anywhere. They can live in the browser cache, but they also can pass from one server to another to do authorization or can be saved in a user’s home directory. For example, if you’ve accessed Google Sheets or another Google service from R or Python, you may have manually handled the resulting OAuth token in your home directory.</p>
+<p>OAuth is an authorization scheme, so the contents of a JWT are about the permissions of the bearer of the token. A related standard called <em>OpenID Connect (OIDC)</em> can be used to do authentication with OAuth tokens. Over the next few years, I fully expect all data access to move toward using OAuth tokens.</p>
+<p>In OAuth, the service you’re trying to visit is called the <em>resource server</em> and the token issuer is the <em>authorization server</em>. When you try to access a service, the service knows to look for a JWT that includes specific <em>claims</em> against a set of <em>scopes</em>. If you don’t have a JWT, you must seek it from the authorization server.</p>
+<p>For example, if you want to read my Google Calendar, you need a JWT that includes a claim granting <em>read</em> access against the scope of <em>events on Alex’s calendar</em>.</p>
 <p><img src="images/auth-oauth.png" class="img-fluid" width="600"></p>
-<p>The authorization server knows how to accept requests for a token and the resource server knows how to accept them. The process of requesting and getting a token can happen in a number of different ways that might include browser redirects and caches, but also could be done entirely in R or Python.</p>
+<p>Unlike in SAML where action occurs via browser redirects, OAuth makes no assumptions about how this flow happens. The process of requesting and getting a token can happen in several different ways, including browser redirects and caches, but could be done entirely in R or Python.</p>
 </section>
 </section>
 <section id="user-provisioning" class="level2" data-number="A.6">
 <h2 data-number="A.6" class="anchored" data-anchor-id="user-provisioning"><span class="header-section-number">A.6</span> User Provisioning</h2>
-<p>When you’re using a service, users often need to be created (<em>provisioned</em>) in that system. In some cases, the users will be provisioned the first time they log in. In other cases, you may want the ability to provision them ahead of time.</p>
+<p>When you’re using a service, users often need to be created (<em>provisioned</em>) in that system. Sometimes, the users will be provisioned the first time they log in. In other cases, you may want the ability to provision them beforehand.</p>
 <p>LDAP/AD is very good for user provisioning. You can often configure your application to provision everyone who comes back from a particular <code>ldapsearch</code>. In contrast, token-based systems don’t know anything about you until you show up for the first time with a valid token.</p>
 <p>There is a SAML-based provisioning system called <em>SCIM (System for Cross-Domain Identity Management)</em> that is slowly being adopted by many IdPs and SPs.</p>
 
@@ -515,9 +517,9 @@ <h2 data-number="A.6" class="anchored" data-anchor-id="user-provisioning"><span
 <section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
 <hr>
 <ol>
-<li id="fn1"><p>To be precise, possible if integrated with Kerberos, but unlikely.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn2"><p>Yuck, what a gross word.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
-<li id="fn3"><p>The diagram below assumes you don’t already have a token in your browser. Step 6 is actually the first thing that happens when the user visits the SP. If the user has a token already, steps 2-5 get skipped.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn1"><p>As in <a href="../sec3/3-2-auth.html">Chapter&nbsp;<span>16</span></a>, I’m using the term token as a summary, but Kerberos, SAML, and OAuth all have different names – more on that below.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn2"><p>To be precise, possible if integrated with Kerberos, but unlikely.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
+<li id="fn3"><p>The diagram assumes you don’t already have a token in your browser. If the user has a token already, steps 2-5 get skipped.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
 </ol>
 </section>
 
diff --git a/chapters/append/cheatsheets.html b/chapters/append/cheatsheets.html
index 66e50d5b..a388af1c 100644
--- a/chapters/append/cheatsheets.html
+++ b/chapters/append/cheatsheets.html
@@ -327,7 +327,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/append/lab-map.html b/chapters/append/lab-map.html
index ae56364f..93768180 100644
--- a/chapters/append/lab-map.html
+++ b/chapters/append/lab-map.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/append/lb.html b/chapters/append/lb.html
index fba5279e..7866b832 100644
--- a/chapters/append/lb.html
+++ b/chapters/append/lb.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -352,32 +352,32 @@ <h1 class="title"><span id="sec-append-lb" class="quarto-section-identifier">App
 
 </header>
 
-<p><a href="../sec3/3-3-ent-scale.html">Chapter&nbsp;<span>17</span></a> introduced you to the idea of a load balancer as a kind of proxy server to serve as the “front door” to a computational cluster. This appendix chapter will explain a few of the different configuration options for load balancers that your organization’s IT/Admins may consider.</p>
-<p>Depending on your organization, they may run their own load balancing servers using software like <em>F5</em>, <em>HA Proxy</em>, or <em>Hostwinds</em>. If your organization is in the cloud, it’s very likely they use a cloud load balancer like AWS <em>ELB</em> <em>(Elastic Load Balancer)</em>, Azure <em>App Proxy</em>, or GCP <em>Cloud Load Balancing</em>. If they’re running in Kubernetes, they are likely to use the open-source <em>Traefik</em>.</p>
+<p><a href="../sec3/3-3-ent-scale.html">Chapter&nbsp;<span>17</span></a> introduced the idea of a load balancer as the “front door” to a computational cluster. This appendix chapter will explain a few of the different configuration options for load balancers that your organization’s IT/Admins may consider.</p>
+<p>Depending on your organization, they may run load balancing servers using software like <em>F5</em>, <em>HA Proxy</em>, or <em>Hostwinds</em>. If your organization is in the cloud, it probably uses the cloud provider’s load balancer like AWS <em>ELB</em> <em>(Elastic Load Balancer)</em>, Azure <em>App Proxy</em>, or GCP <em>Cloud Load Balancing</em>. If they’re running in Kubernetes, they are likely to use the open-source <em>Traefik</em>.</p>
 <section id="load-balancer-settings" class="level2" data-number="B.1">
 <h2 data-number="B.1" class="anchored" data-anchor-id="load-balancer-settings"><span class="header-section-number">B.1</span> Load balancer settings</h2>
-<p>Regardless of which load balancer you’re using, a basic requirement is that it knows what nodes are accepting traffic. This is accomplished by configuring a <em>health check/heartbeat</em> for the application on the node. A health check is a feature of the application that responds to periodic pings from the load balancer. If no response comes back, the load balancer treats that node as unhealthy and doesn’t send traffic there.</p>
-<p>One other feature that may come up is <em>sticky sessions</em> or <em>sticky cookies</em>. For stateful applications, like Shiny apps, you want to get back to the same node in the cluster so you can resume a previous session. In most load balancers, this is just an option you can activate.</p>
+<p>Regardless of which load balancer you’re using, a basic requirement is that it knows what nodes are accepting traffic. This is accomplished by configuring a <em>health check/heartbeat</em> for the application on the node. A health check is an application feature that responds to periodic pings from the load balancer. If no response comes back, the load balancer treats that node as unhealthy and doesn’t send traffic there.</p>
+<p>For applications that maintain user state, like Shiny apps, you want to get back to the same node in the cluster so you can resume a previous session. This can be enabled with <em>sticky sessions</em> or <em>sticky cookies</em>. In most load balancers, this is simply an option you can activate.</p>
 </section>
 <section id="ways-to-configure-load-balancing" class="level2" data-number="B.2">
 <h2 data-number="B.2" class="anchored" data-anchor-id="ways-to-configure-load-balancing"><span class="header-section-number">B.2</span> Ways to configure load balancing</h2>
-<p>The simplest form of load balancing is to just rotate traffic to each node that is healthy in a <em>round-robin</em> configuration. Depending on the capabilities of the load balancer and what metrics are emitted by the application, it may also be possible or desirable to do more complicated load balancing that pays attention to how loaded different nodes are.</p>
-<p>Usually, load balancers are configured to send traffic to all the nodes in the cluster in an <em>active/active</em> configuration. It is also possible to configure the load balancer in an <em>active/passive</em> configuration to send traffic to only some of the nodes, with the rest remaining inert until they are switched on, usually in the event of a failure in the active ones. This is sometimes called a <em>blue/green</em> or <em>red/black</em> configuration when it’s used to diminish downtime in upgrades and migrations.</p>
+<p>The simplest form of load balancing is to rotate traffic to each healthy node in a <em>round-robin</em> configuration. Depending on the capabilities of the load balancer and what metrics are emitted by the application, it may also be possible or desirable to do more sophisticated load balancing that routes sessions according to how loaded each node is.</p>
+<p>Usually, load balancers are configured to send traffic to all the nodes in the cluster in an <em>active/active</em> configuration. It is also possible to configure the load balancer in an <em>active/passive</em> configuration to send traffic to only some of the nodes, with the rest remaining inert until they are switched on – usually in the event of a failure in the active ones. This is sometimes called a <em>blue/green</em> or <em>red/black</em> configuration when it’s used to diminish downtime in upgrades and migrations.</p>
 </section>
 <section id="shared-state" class="level2" data-number="B.3">
 <h2 data-number="B.3" class="anchored" data-anchor-id="shared-state"><span class="header-section-number">B.3</span> Shared state</h2>
-<p>Aside from the load balancer, the nodes need to be able to share state with each other so users can have the same experience on each node. The requirements for that shared state depend on the software.</p>
+<p>Aside from the load balancer, the nodes need to be able to share state so users can have the same experience on each node. The requirements for that shared state depend on the software.</p>
 <p>Often the shared state takes the form of a database (often Postgres) and/or <em>Network Attached Storage (NAS, pronounced naahz)</em> for things that get stored in a filesystem.</p>
-<p>If your NAS is exclusively for Linux, you it would use <em>NFS (Network File System)</em>. If Windows is involved, you’d use <em>SMB (Server Message Block)</em> or <em>Samba</em> to connect SMB to a Linux server. There’s also an outdated Windows NAS called <em>CIFS (Common Internet File System)</em> that you might see in older systems.</p>
+<p>If your NAS is exclusively for Linux, it would use <em>NFS (Network File System)</em>. If Windows is involved, you’d use <em>SMB (Server Message Block)</em> or <em>Samba</em> to connect SMB to a Linux server. There’s also an outdated Windows NAS called <em>CIFS (Common Internet File System)</em> that you might see in older systems.</p>
 <p>Each of the cloud providers has a NAS offering. AWS has <em>EFS (Elastic File System)</em> and <em>FSx</em>. Azure has <em>Azure File</em>, and GCP has <em>Filestore</em>.</p>
 </section>
 <section id="upgrades-in-ha" class="level2" data-number="B.4">
 <h2 data-number="B.4" class="anchored" data-anchor-id="upgrades-in-ha"><span class="header-section-number">B.4</span> Upgrades in HA</h2>
-<p>Sometimes IT/Admins want to run an HA cluster with software that supports <em>zero downtime upgrades</em>. In order to do a zero-downtime upgrade, you need to take some nodes offline, upgrade them, put them back online, and then upgrade the rest of the nodes.</p>
-<p>There are a two features the application you’re upgrading needs to support to accomplish this feat. If it doesn’t support both, you’ll need to endure some downtime to do an upgrade.</p>
+<p>Sometimes IT/Admins want to upgrade the software running in the cluster without taking the service offline. This is called a <em>zero-downtime upgrade</em>. In a zero-downtime upgrade, you take some nodes offline, upgrade them, put them back online, and then upgrade the remainder.</p>
+<p>To accomplish this feat, there are two features the application needs to support. If it doesn’t support both, you’ll need to endure some downtime to do an upgrade.</p>
 <p>The first is <em>node draining</em>. If you just naively removed a node, you might kill someone’s active session. Instead, you’d want to configure the node so that it doesn’t kill any existing sessions but also doesn’t accept any new ones. As the current sessions end, the node empties and you can safely take it offline when all the sessions are gone.</p>
-<p>The second is <em>rolling upgrade</em>. Some software supports being in a load balanced cluster with different versions of the software and other does not. If your software doesn’t support a cluster with mixed versions, a rolling upgrade won’t be possible. Supporting a rolling upgrade is relatively rare. It requires that the cluster understand how to maintain metadata across different versions simultaneously, which is a tricky bit of application programming.</p>
-<p>If your application doesn’t support zero downtime upgrades, some organizations like to get close by building a second copy of the environment, getting it almost live, and then taking downtime just to switch the networking over. That’s generally much faster than building the whole thing during downtime.</p>
+<p>The second is <em>rolling upgrade</em>, which is the ability to support mixed software versions in the same cluster. When you upgrade a piece of software, there are often changes to how the data in the shared state is stored. That means the creators would need to undertake painstaking work to avoid conflicts during the upgrade process. Because it’s tricky to support active sessions in a cluster with mixed versions, it’s relatively uncommon.</p>
+<p>If your application doesn’t support zero downtime upgrades, some organizations like to get close by building a second copy of the server and its applications, getting it almost live, and then taking downtime solely to switch the networking over. That’s generally much faster than building the whole thing during downtime.</p>
 
 
 </section>
@@ -619,7 +619,7 @@ <h2 data-number="B.4" class="anchored" data-anchor-id="upgrades-in-ha"><span cla
 <nav class="page-navigation">
   <div class="nav-page nav-page-previous">
       <a href="../../chapters/append/auth.html" class="pagination-link">
-        <i class="bi bi-arrow-left-short"></i> <span class="nav-page-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span>
+        <i class="bi bi-arrow-left-short"></i> <span class="nav-page-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span>
       </a>          
   </div>
   <div class="nav-page nav-page-next">
diff --git a/chapters/intro.html b/chapters/intro.html
index a4df45f3..b0abe6e1 100644
--- a/chapters/intro.html
+++ b/chapters/intro.html
@@ -294,7 +294,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -399,7 +399,7 @@ <h2 class="anchored" data-anchor-id="processes-and-people">Processes and People<
 <li><p>Some organizations have chosen to outsource their IT/Admin functions. While the individuals in those outsourced teams are often competent, building relationships can be difficult. Outsourced IT/Admin teams are often in India, so it can be hard to find meeting times with American and European teams. Additionally, turnover on projects and systems tends to be high, so institutional knowledge is thin, and relationships can’t be relied on long term.</p></li>
 <li><p>Some organizations, especially small or new ones, don’t have an IT/Admin function. At others, the IT/Admins are preoccupied with other tasks and lack the capacity to help the data science team. This isn’t a tragedy, but it probably means you’ll have to become the IT/Admin if you want to get anything done.</p></li>
 </ol>
-<p>Whether your organization has an IT/Admin setup that facilitates DevOps best practices or not, this book can help you take the first steps towards making your path to production smoother and simpler.</p>
+<p>Whether your organization has an IT/Admin setup that facilitates DevOps best practices or not, this book can help you take the first steps toward making your path to production smoother and simpler.</p>
 </section>
 <section id="a-data-science-platform" class="level2">
 <h2 class="anchored" data-anchor-id="a-data-science-platform">A data science platform</h2>
diff --git a/chapters/sec1/1-0-sec-intro.html b/chapters/sec1/1-0-sec-intro.html
index f1ad5a01..c973e3b9 100644
--- a/chapters/sec1/1-0-sec-intro.html
+++ b/chapters/sec1/1-0-sec-intro.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec1/1-1-env-as-code.html b/chapters/sec1/1-1-env-as-code.html
index 4bd99214..04e4dad2 100644
--- a/chapters/sec1/1-1-env-as-code.html
+++ b/chapters/sec1/1-1-env-as-code.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -404,7 +404,7 @@ <h1 class="title"><span id="sec-env-as-code" class="quarto-section-identifier"><
 <p>In some cases, you might have no choice. Some industries are highly regulated and analysts need to be able to guarantee that they can reproduce an analysis exactly – even a decade later – down to the layer of machine instructions. In this world, IT/Admins need to keep a physical piece of hardware running for many years.</p>
 <p>You don’t have to go there if you don’t work in such an industry. Crafting a completely reproducible environment is a fool’s errand. There’s always a tradeoff. Making things more reproducible generally takes more work – in a frustratingly asymptotic way.</p>
 <p><img src="images/repro-spectrum.png" class="img-fluid" alt="Spectrum of reproducibility from not at all to &quot;fully&quot; indicating that as reproducibility rises, so does that amount of work."></p>
-<p>But the first steps towards a more reproducible environment are simple enough to fit in a single book chapter (this one!) – to create and use <em>environments as code</em>.</p>
+<p>But the first steps toward a more reproducible environment are simple enough to fit in a single book chapter (this one!) – to create and use <em>environments as code</em>.</p>
 <p>The DevOps term for this is that environments are <em>stateless</em> or in the phrase that environments should be “cattle, not pets”. That means that you can use standardized tooling to create and destroy functionally identical copies of the environment without secret state being left behind.</p>
 <p>In this chapter, we’ll get into the why and how of capturing data science environments in code, saving them for later, and then easily moving them around from place to place.</p>
 <section id="environments-have-layers" class="level2" data-number="1.1">
diff --git a/chapters/sec1/1-2-proj-arch.html b/chapters/sec1/1-2-proj-arch.html
index 83b2b225..8713af07 100644
--- a/chapters/sec1/1-2-proj-arch.html
+++ b/chapters/sec1/1-2-proj-arch.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec1/1-3-data-access.html b/chapters/sec1/1-3-data-access.html
index 8e006e2f..824008b0 100644
--- a/chapters/sec1/1-3-data-access.html
+++ b/chapters/sec1/1-3-data-access.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec1/1-4-monitor-log.html b/chapters/sec1/1-4-monitor-log.html
index 50c08538..65e42066 100644
--- a/chapters/sec1/1-4-monitor-log.html
+++ b/chapters/sec1/1-4-monitor-log.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec1/1-5-deployments.html b/chapters/sec1/1-5-deployments.html
index aacc475c..6a60a268 100644
--- a/chapters/sec1/1-5-deployments.html
+++ b/chapters/sec1/1-5-deployments.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec1/1-6-docker.html b/chapters/sec1/1-6-docker.html
index 144574f7..fe16cc4e 100644
--- a/chapters/sec1/1-6-docker.html
+++ b/chapters/sec1/1-6-docker.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-0-sec-intro.html b/chapters/sec2/2-0-sec-intro.html
index 45999c3e..cefe76f7 100644
--- a/chapters/sec2/2-0-sec-intro.html
+++ b/chapters/sec2/2-0-sec-intro.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-1-cloud.html b/chapters/sec2/2-1-cloud.html
index b536743b..91388e7c 100644
--- a/chapters/sec2/2-1-cloud.html
+++ b/chapters/sec2/2-1-cloud.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-2-cmd-line.html b/chapters/sec2/2-2-cmd-line.html
index ee6340fe..33e15388 100644
--- a/chapters/sec2/2-2-cmd-line.html
+++ b/chapters/sec2/2-2-cmd-line.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -377,7 +377,7 @@ <h2 id="toc-title">Table of contents</h2>
   <li><a href="#step-3-use-ssh" id="toc-step-3-use-ssh" class="nav-link" data-scroll-target="#step-3-use-ssh"><span class="header-section-number">8.7.3</span> Step 3: Use SSH</a></li>
   </ul></li>
   <li><a href="#comprehension-questions" id="toc-comprehension-questions" class="nav-link" data-scroll-target="#comprehension-questions"><span class="header-section-number">8.8</span> Comprehension Questions</a></li>
-  <li><a href="#lab-login-to-the-server" id="toc-lab-login-to-the-server" class="nav-link" data-scroll-target="#lab-login-to-the-server"><span class="header-section-number">8.9</span> Lab: Login to the server</a>
+  <li><a href="#lab-log-in-to-the-server" id="toc-lab-log-in-to-the-server" class="nav-link" data-scroll-target="#lab-log-in-to-the-server"><span class="header-section-number">8.9</span> Lab: Log in to the server</a>
   <ul class="collapse">
   <li><a href="#step-1-grab-the-server-address" id="toc-step-1-grab-the-server-address" class="nav-link" data-scroll-target="#step-1-grab-the-server-address"><span class="header-section-number">8.9.1</span> Step 1: Grab the server address</a></li>
   <li><a href="#step-2-log-on-with-the-.pem-key" id="toc-step-2-log-on-with-the-.pem-key" class="nav-link" data-scroll-target="#step-2-log-on-with-the-.pem-key"><span class="header-section-number">8.9.2</span> Step 2: Log on with the <code>.pem</code> key</a></li>
@@ -610,8 +610,8 @@ <h2 data-number="8.8" class="anchored" data-anchor-id="comprehension-questions">
 <li>What is it about SSH public keys that makes them safe to share?</li>
 </ol>
 </section>
-<section id="lab-login-to-the-server" class="level2" data-number="8.9">
-<h2 data-number="8.9" class="anchored" data-anchor-id="lab-login-to-the-server"><span class="header-section-number">8.9</span> Lab: Login to the server</h2>
+<section id="lab-log-in-to-the-server" class="level2" data-number="8.9">
+<h2 data-number="8.9" class="anchored" data-anchor-id="lab-log-in-to-the-server"><span class="header-section-number">8.9</span> Lab: Log in to the server</h2>
 <p>In the previous chapter, we got your server up and running. In this lab, we’ll use the provided <code>.pem</code> key to log in for the first time.</p>
 <section id="step-1-grab-the-server-address" class="level3" data-number="8.9.1">
 <h3 data-number="8.9.1" class="anchored" data-anchor-id="step-1-grab-the-server-address"><span class="header-section-number">8.9.1</span> Step 1: Grab the server address</h3>
@@ -662,11 +662,11 @@ <h3 data-number="8.9.2" class="anchored" data-anchor-id="step-2-log-on-with-the-
 <span id="cb3-15"><a href="#cb3-15" aria-hidden="true" tabindex="-1"></a></span>
 <span id="cb3-16"><a href="#cb3-16" aria-hidden="true" tabindex="-1"></a><span class="ex">ubuntu@ec2-54-159-134-39.compute-1.amazonaws.com:</span> Permission denied <span class="er">(</span><span class="ex">publickey</span><span class="kw">)</span><span class="bu">.</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <p>Because the keypair is so powerful, AWS requires that you restrict the access. You’ll need to change the permissions before using it to access the server. We’ll get into permissions in <a href="2-3-linux.html">Chapter&nbsp;<span>9</span></a>. Until then, you can adjust the permissions by navigating to the correct directory with the <code>cd</code> command and running <code>chmod 600 do4ds-lab-key.pem</code>.</p>
-<p>Once you’ve done that, you can login to your machine as the root user. You can type <code>exit</code> to exit an SSH session and return to your machine.</p>
+<p>Once you’ve done that, you can log in to your machine as the root user. You can type <code>exit</code> to exit an SSH session and return to your machine.</p>
 </section>
 <section id="step-3-create-your-own-ssh-key" class="level3" data-number="8.9.3">
 <h3 data-number="8.9.3" class="anchored" data-anchor-id="step-3-create-your-own-ssh-key"><span class="header-section-number">8.9.3</span> Step 3: Create your own SSH key</h3>
-<p>You shouldn’t use the AWS-provided <code>.pem</code> key to login to your server after the first time. It’s too powerful. Create a normal SSH key using the instructions earlier in this chapter. In the next lab, we’ll get that SSH key configured for your user on the server.</p>
+<p>You shouldn’t use the AWS-provided <code>.pem</code> key to log in to your server after the first time. It’s too powerful. Create a normal SSH key using the instructions earlier in this chapter. In the next lab, we’ll get that SSH key configured for your user on the server.</p>
 
 
 </section>
diff --git a/chapters/sec2/2-3-linux.html b/chapters/sec2/2-3-linux.html
index 58bcc416..52330e4c 100644
--- a/chapters/sec2/2-3-linux.html
+++ b/chapters/sec2/2-3-linux.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -673,8 +673,8 @@ <h2 data-number="9.8" class="anchored" data-anchor-id="comprehension-questions">
 </section>
 <section id="lab-set-up-a-user" class="level2" data-number="9.9">
 <h2 data-number="9.9" class="anchored" data-anchor-id="lab-set-up-a-user"><span class="header-section-number">9.9</span> Lab: Set up a user</h2>
-<p>When you use your server’s <code>.pem</code> key, you login as the root user, but that’s too much power to acquire regularly. Additionally, since your server is probably for multiple people, you will want to create users for them.</p>
-<p>In this lab, you’ll create a regular user for yourself and add an SSH key for them so you can directly login from your personal computer.</p>
+<p>When you use your server’s <code>.pem</code> key, you log in as the root user, but that’s too much power to acquire regularly. Additionally, since your server is probably for multiple people, you will want to create users for them.</p>
+<p>In this lab, you’ll create a regular user for yourself and add an SSH key for them so you can directly log in from your personal computer.</p>
 <section id="step-1-create-a-non-root-user" class="level3" data-number="9.9.1">
 <h3 data-number="9.9.1" class="anchored" data-anchor-id="step-1-create-a-non-root-user"><span class="header-section-number">9.9.1</span> Step 1: Create a non-root user</h3>
 <p>Let’s create a user using the <code>adduser</code> command. This will walk us through prompts to create a new user with a home directory and a password. Feel free to add any information you want – or to leave it blank – when prompted.</p>
@@ -740,7 +740,7 @@ <h3 data-number="9.9.2" class="anchored" data-anchor-id="step-2-add-an-ssh-key-f
 </div>
 </div>
 <p>Once you’ve done all this, you should be able to log in from your personal computer with <code>ssh test-user@$SERVER_ADDRESS</code>.</p>
-<p>Now that we’re all set up, you should store the <code>.pem</code> key somewhere safe and never use it to login again.</p>
+<p>Now that we’re all set up, you should store the <code>.pem</code> key somewhere safe and never use it to log in again.</p>
 
 
 </section>
diff --git a/chapters/sec2/2-4-app-admin.html b/chapters/sec2/2-4-app-admin.html
index f28fd806..5a15de3f 100644
--- a/chapters/sec2/2-4-app-admin.html
+++ b/chapters/sec2/2-4-app-admin.html
@@ -326,7 +326,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-5-scale.html b/chapters/sec2/2-5-scale.html
index 3bec7148..3f48a4ed 100644
--- a/chapters/sec2/2-5-scale.html
+++ b/chapters/sec2/2-5-scale.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-6-networking.html b/chapters/sec2/2-6-networking.html
index 2bce3831..2c3d17f3 100644
--- a/chapters/sec2/2-6-networking.html
+++ b/chapters/sec2/2-6-networking.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-7-dns.html b/chapters/sec2/2-7-dns.html
index 5781c18b..a619e41d 100644
--- a/chapters/sec2/2-7-dns.html
+++ b/chapters/sec2/2-7-dns.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec2/2-8-ssl.html b/chapters/sec2/2-8-ssl.html
index 2c4f37cf..f7a75915 100644
--- a/chapters/sec2/2-8-ssl.html
+++ b/chapters/sec2/2-8-ssl.html
@@ -328,7 +328,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec3/3-0-sec-intro.html b/chapters/sec3/3-0-sec-intro.html
index e23232e8..1177cc27 100644
--- a/chapters/sec3/3-0-sec-intro.html
+++ b/chapters/sec3/3-0-sec-intro.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec3/3-1-ent-networks.html b/chapters/sec3/3-1-ent-networks.html
index 3cd1dbf9..2d33dcc8 100644
--- a/chapters/sec3/3-1-ent-networks.html
+++ b/chapters/sec3/3-1-ent-networks.html
@@ -294,7 +294,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/chapters/sec3/3-2-auth.html b/chapters/sec3/3-2-auth.html
index 44673d42..2d967953 100644
--- a/chapters/sec3/3-2-auth.html
+++ b/chapters/sec3/3-2-auth.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -421,7 +421,7 @@ <h2 data-number="16.3" class="anchored" data-anchor-id="the-rise-of-single-sign-
 </div>
 </div>
 <p>SSO is analogous to a process where users exchange their credentials for an access pass upon entering the building. Each room has a machine to send a request to the central security office, where the room can be remotely unlocked if the request is approved.</p>
-<p><img src="images/sso.png" class="img-fluid" alt="A user getting an SSO token, which they use to login to each service." width="600"></p>
+<p><img src="images/sso.png" class="img-fluid" alt="A user getting an SSO token, which they use to log in to each service." width="600"></p>
 <p>SSO isn’t a technology. It describes a user and admin experience almost always accomplished through a standalone identity provider like Okta, OneLogin, Ping, or Microsoft Entra ID.<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a> These providers most often use one of two technologies – <em>SAML (Security Assertion Markup Language)</em> or <em>OIDC/OAuth</em> <em>(Open Identity Connect/OAuth2.0)</em>.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> Your organization’s IT/Admins will likely use OAuth for external SaaS services and may prefer SAML for services inside your organization’s firewall. The experience of using either is very similar as a user.</p>
 <p>As I write this in 2023, there’s a transition underway from on-prem systems like LDAP/AD to cloud-friendly SSO systems and the enhanced security they enable. In particular, the use of non-password credentials like passkeys and the use of OAuth to do sophisticated authorization management inside enterprises are now cutting-edge, but will be standard practices within a few years.</p>
 </section>
@@ -444,7 +444,7 @@ <h2 data-number="16.5" class="anchored" data-anchor-id="managing-permissions"><s
 <p>For example, there might be a <code>manager</code> role that should have access to specific permissions in the HR software. This role would be applied to anyone in the <code>data-science-manager</code> group as well as the <code>data-engineering-manager</code> group.</p>
 <p>There are a few issues with RBAC. Most importantly, if there are many idiosyncratic permissions, creating tons of special roles is often simpler than figuring out how to harmonize them into a system.</p>
 <p>Many organizations haven’t reached the complexity of adopting RBAC. They often use simple <em>Access Control Lists (ACLs)</em> of who can access each service.<a href="#fn4" class="footnote-ref" id="fnref4" role="doc-noteref"><sup>4</sup></a> ACLs have the advantage of being conceptually simple, but maintaining individual lists for each service is a lot of work with many services and users.</p>
-<p>Some organizations are moving towards even more granular techniques than RBAC and are adopting <em>Attribute Based Access Control (ABAC)</em>. In ABAC, permissions are granted based on an interaction of user-level and object-level attributes and a rules engine.</p>
+<p>Some organizations are moving toward even more granular techniques than RBAC and are adopting <em>Attribute Based Access Control (ABAC)</em>. In ABAC, permissions are granted based on an interaction of user-level and object-level attributes and a rules engine.</p>
 <p>For example, you can imagine three distinct attributes a user could have: <code>data-science</code>, <code>data-engineer</code>, and <code>manager</code>. You could create a rules engine that provides access to different resources based on the combinations of these attributes.</p>
 <p>Relative to RBAC, ABAC is a more robust system that allows for more granular permissions, but it’s a much bigger lift to configure initially. You’ve already encountered an ABAC system in the AWS IAM system. You were probably completely befuddled if you tried to configure anything in IAM. You can thank the power and complexity of ABAC.</p>
 </section>
diff --git a/chapters/sec3/3-3-ent-scale.html b/chapters/sec3/3-3-ent-scale.html
index ec2c03ea..f088dd56 100644
--- a/chapters/sec3/3-3-ent-scale.html
+++ b/chapters/sec3/3-3-ent-scale.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -442,7 +442,7 @@ <h2 data-number="17.3" class="anchored" data-anchor-id="computing-in-clusters"><
 </section>
 <section id="docker-in-enterprise-kubernetes" class="level2" data-number="17.4">
 <h2 data-number="17.4" class="anchored" data-anchor-id="docker-in-enterprise-kubernetes"><span class="header-section-number">17.4</span> Docker in enterprise = Kubernetes</h2>
-<p>Initially created at Google and released in 2014, the open-source <em>Kubernetes (K8S, pronounced koo-ber-net-ees or kates for the abbreviation)</em> is the way to run production services out of Docker containers.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> Many organizations are moving towards running most or all of their production work in Kubernetes.</p>
+<p>Initially created at Google and released in 2014, the open-source <em>Kubernetes (K8S, pronounced koo-ber-net-ees or kates for the abbreviation)</em> is the way to run production services out of Docker containers.<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> Many organizations are moving toward running most or all of their production work in Kubernetes.</p>
 <div class="callout callout-style-default callout-note callout-titled">
 <div class="callout-header d-flex align-content-center">
 <div class="callout-icon-container">
diff --git a/chapters/sec3/3-4-ent-pm.html b/chapters/sec3/3-4-ent-pm.html
index 2e52acf8..b0cd6bcb 100644
--- a/chapters/sec3/3-4-ent-pm.html
+++ b/chapters/sec3/3-4-ent-pm.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="../../chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
@@ -685,7 +685,7 @@ <h2 data-number="18.4" class="anchored" data-anchor-id="comprehension-questions"
   </div>
   <div class="nav-page nav-page-next">
       <a href="../../chapters/append/auth.html" class="pagination-link">
-        <span class="nav-page-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span> <i class="bi bi-arrow-right-short"></i>
+        <span class="nav-page-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span> <i class="bi bi-arrow-right-short"></i>
       </a>
   </div>
 </nav>
diff --git a/index.html b/index.html
index e1154855..c5b2cc15 100644
--- a/index.html
+++ b/index.html
@@ -292,7 +292,7 @@
           <li class="sidebar-item">
   <div class="sidebar-item-container"> 
   <a href="./chapters/append/auth.html" class="sidebar-item-text sidebar-link">
- <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Auth Technologies</span></span></a>
+ <span class="menu-text"><span class="chapter-number">A</span>&nbsp; <span class="chapter-title">Technical Detail: Auth Technologies</span></span></a>
   </div>
 </li>
           <li class="sidebar-item">
diff --git a/search.json b/search.json
index a974723f..06c35691 100644
--- a/search.json
+++ b/search.json
@@ -46,7 +46,7 @@
     "href": "chapters/intro.html#processes-and-people",
     "title": "Introduction",
     "section": "Processes and People",
-    "text": "Processes and People\nThroughout this book, DevOps refers to the knowledge, practices, and tools that make it easier, safer, and faster to put work into production. So, if you’re a software developer (and as a data scientist, you are), you need to be thinking about DevOps.\nMost organizations also have a set of people and roles who have the permission and responsibility for managing their organization’s servers and software. Their titles vary. They might be named Information Technology (IT), SysAdmin, Site Reliability Engineering (SRE), or DevOps.1\nFor simplicity, I will use the term IT/Admin to refer to these people and teams throughout this book.\nAs a data scientist, you are the Dev, so a huge part of making DevOps work for you is finding IT/Admin counterparts with whom you can collaborate. In some cases, that will be easier than others. Here are three patterns that are almost always red flags – mainly because they make it hard to develop durable relationships to sustain the kind of collaboration DevOps requires.\n\nAt some large organizations, IT/Admin functions are split into small atomic units like security, databases, networking, storage, procurement, cloud, and more. This is useful for keeping the scope of work manageable for the people in that group and often yields deep technical expertise. But it also can be slow to get anything done because you’ll need to bring people together from disparate teams.\nSome organizations have chosen to outsource their IT/Admin functions. While the individuals in those outsourced teams are often competent, building relationships can be difficult. Outsourced IT/Admin teams are often in India, so it can be hard to find meeting times with American and European teams. Additionally, turnover on projects and systems tends to be high, so institutional knowledge is thin, and relationships can’t be relied on long term.\nSome organizations, especially small or new ones, don’t have an IT/Admin function. At others, the IT/Admins are preoccupied with other tasks and lack the capacity to help the data science team. This isn’t a tragedy, but it probably means you’ll have to become the IT/Admin if you want to get anything done.\n\nWhether your organization has an IT/Admin setup that facilitates DevOps best practices or not, this book can help you take the first steps towards making your path to production smoother and simpler."
+    "text": "Processes and People\nThroughout this book, DevOps refers to the knowledge, practices, and tools that make it easier, safer, and faster to put work into production. So, if you’re a software developer (and as a data scientist, you are), you need to be thinking about DevOps.\nMost organizations also have a set of people and roles who have the permission and responsibility for managing their organization’s servers and software. Their titles vary. They might be named Information Technology (IT), SysAdmin, Site Reliability Engineering (SRE), or DevOps.1\nFor simplicity, I will use the term IT/Admin to refer to these people and teams throughout this book.\nAs a data scientist, you are the Dev, so a huge part of making DevOps work for you is finding IT/Admin counterparts with whom you can collaborate. In some cases, that will be easier than others. Here are three patterns that are almost always red flags – mainly because they make it hard to develop durable relationships to sustain the kind of collaboration DevOps requires.\n\nAt some large organizations, IT/Admin functions are split into small atomic units like security, databases, networking, storage, procurement, cloud, and more. This is useful for keeping the scope of work manageable for the people in that group and often yields deep technical expertise. But it also can be slow to get anything done because you’ll need to bring people together from disparate teams.\nSome organizations have chosen to outsource their IT/Admin functions. While the individuals in those outsourced teams are often competent, building relationships can be difficult. Outsourced IT/Admin teams are often in India, so it can be hard to find meeting times with American and European teams. Additionally, turnover on projects and systems tends to be high, so institutional knowledge is thin, and relationships can’t be relied on long term.\nSome organizations, especially small or new ones, don’t have an IT/Admin function. At others, the IT/Admins are preoccupied with other tasks and lack the capacity to help the data science team. This isn’t a tragedy, but it probably means you’ll have to become the IT/Admin if you want to get anything done.\n\nWhether your organization has an IT/Admin setup that facilitates DevOps best practices or not, this book can help you take the first steps toward making your path to production smoother and simpler."
   },
   {
     "objectID": "chapters/intro.html#a-data-science-platform",
@@ -539,11 +539,11 @@
     "text": "8.8 Comprehension Questions\n\nDraw a mental map that includes the following: terminal, shell, theme manager, operating system, my laptop\nUnder what circumstances should you move or share your SSH private key?\nWhat is it about SSH public keys that makes them safe to share?"
   },
   {
-    "objectID": "chapters/sec2/2-2-cmd-line.html#lab-login-to-the-server",
-    "href": "chapters/sec2/2-2-cmd-line.html#lab-login-to-the-server",
+    "objectID": "chapters/sec2/2-2-cmd-line.html#lab-log-in-to-the-server",
+    "href": "chapters/sec2/2-2-cmd-line.html#lab-log-in-to-the-server",
     "title": "8  Using the command line",
-    "section": "8.9 Lab: Login to the server",
-    "text": "8.9 Lab: Login to the server\nIn the previous chapter, we got your server up and running. In this lab, we’ll use the provided .pem key to log in for the first time.\n\n8.9.1 Step 1: Grab the server address\nFrom the EC2 page, you can click on the instance ID in blue to see all the details about your server.\nCopy the Public IPv4 DNS address, which starts with \\(\\text{ec2-}\\) and ends with \\(\\text{amazonaws.com}\\). You’ll need this address throughout the labs. If you lose it, come back here to get it.\n\n\n\n\n\n\nSet a Server Address Variable\n\n\n\nIn the rest of the labs in this book, I will write the commands using the bash variable SERVER_ADDRESS. If you create that variable, you can copy the commands from the book.\nFor example, as I write this, my server has the address \\(\\text{ec2-54-159-134-39.compute-1.amazonaws.com}\\). So I would set my server address variable on my command line with SERVER_ADDRESS=ec2-54-159-134-39.compute-1.amazonaws.com.\nIf you’re used to R or Python, notice that spaces are not permitted around = when assigning variables in bash.\n\n\n\n\n8.9.2 Step 2: Log on with the .pem key\nThe .pem key you downloaded when you set up the server is the private key for a pre-registered keypair that will let you SSH into your server as the admin user (named ubuntu on a Ubuntu system).\nThe .pem key is just an SSH key, so that you can SSH to your server with\n\n\nTerminal\n\nssh -i do4ds-lab-key.pem \\\n  ubuntu@SERVER_ADDRESS\n\nWhen you first try this, you’re probably going to get an alert that looks something like this:\n\n\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\n\n\\@ WARNING: UNPROTECTED PRIVATE KEY FILE! \\@\n\n\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\n\nPermissions 0644 for 'do4ds-lab-key.pem' are too open.\n\nIt is required that your private key files are NOT accessible by others.\n\nThis private key will be ignored.\n\nLoad key \"do4ds-lab-key.pem\": bad permissions\n\nubuntu@ec2-54-159-134-39.compute-1.amazonaws.com: Permission denied (publickey).\nBecause the keypair is so powerful, AWS requires that you restrict the access. You’ll need to change the permissions before using it to access the server. We’ll get into permissions in Chapter 9. Until then, you can adjust the permissions by navigating to the correct directory with the cd command and running chmod 600 do4ds-lab-key.pem.\nOnce you’ve done that, you can login to your machine as the root user. You can type exit to exit an SSH session and return to your machine.\n\n\n8.9.3 Step 3: Create your own SSH key\nYou shouldn’t use the AWS-provided .pem key to login to your server after the first time. It’s too powerful. Create a normal SSH key using the instructions earlier in this chapter. In the next lab, we’ll get that SSH key configured for your user on the server."
+    "section": "8.9 Lab: Log in to the server",
+    "text": "8.9 Lab: Log in to the server\nIn the previous chapter, we got your server up and running. In this lab, we’ll use the provided .pem key to log in for the first time.\n\n8.9.1 Step 1: Grab the server address\nFrom the EC2 page, you can click on the instance ID in blue to see all the details about your server.\nCopy the Public IPv4 DNS address, which starts with \\(\\text{ec2-}\\) and ends with \\(\\text{amazonaws.com}\\). You’ll need this address throughout the labs. If you lose it, come back here to get it.\n\n\n\n\n\n\nSet a Server Address Variable\n\n\n\nIn the rest of the labs in this book, I will write the commands using the bash variable SERVER_ADDRESS. If you create that variable, you can copy the commands from the book.\nFor example, as I write this, my server has the address \\(\\text{ec2-54-159-134-39.compute-1.amazonaws.com}\\). So I would set my server address variable on my command line with SERVER_ADDRESS=ec2-54-159-134-39.compute-1.amazonaws.com.\nIf you’re used to R or Python, notice that spaces are not permitted around = when assigning variables in bash.\n\n\n\n\n8.9.2 Step 2: Log on with the .pem key\nThe .pem key you downloaded when you set up the server is the private key for a pre-registered keypair that will let you SSH into your server as the admin user (named ubuntu on a Ubuntu system).\nThe .pem key is just an SSH key, so that you can SSH to your server with\n\n\nTerminal\n\nssh -i do4ds-lab-key.pem \\\n  ubuntu@SERVER_ADDRESS\n\nWhen you first try this, you’re probably going to get an alert that looks something like this:\n\n\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\n\n\\@ WARNING: UNPROTECTED PRIVATE KEY FILE! \\@\n\n\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\\@\n\nPermissions 0644 for 'do4ds-lab-key.pem' are too open.\n\nIt is required that your private key files are NOT accessible by others.\n\nThis private key will be ignored.\n\nLoad key \"do4ds-lab-key.pem\": bad permissions\n\nubuntu@ec2-54-159-134-39.compute-1.amazonaws.com: Permission denied (publickey).\nBecause the keypair is so powerful, AWS requires that you restrict the access. You’ll need to change the permissions before using it to access the server. We’ll get into permissions in Chapter 9. Until then, you can adjust the permissions by navigating to the correct directory with the cd command and running chmod 600 do4ds-lab-key.pem.\nOnce you’ve done that, you can log in to your machine as the root user. You can type exit to exit an SSH session and return to your machine.\n\n\n8.9.3 Step 3: Create your own SSH key\nYou shouldn’t use the AWS-provided .pem key to log in to your server after the first time. It’s too powerful. Create a normal SSH key using the instructions earlier in this chapter. In the next lab, we’ll get that SSH key configured for your user on the server."
   },
   {
     "objectID": "chapters/sec2/2-2-cmd-line.html#footnotes",
@@ -613,7 +613,7 @@
     "href": "chapters/sec2/2-3-linux.html#lab-set-up-a-user",
     "title": "9  Intro to Linux Administration",
     "section": "9.9 Lab: Set up a user",
-    "text": "9.9 Lab: Set up a user\nWhen you use your server’s .pem key, you login as the root user, but that’s too much power to acquire regularly. Additionally, since your server is probably for multiple people, you will want to create users for them.\nIn this lab, you’ll create a regular user for yourself and add an SSH key for them so you can directly login from your personal computer.\n\n9.9.1 Step 1: Create a non-root user\nLet’s create a user using the adduser command. This will walk us through prompts to create a new user with a home directory and a password. Feel free to add any information you want – or to leave it blank – when prompted.\nI’m going to use the username test-user. If you want to be able to copy/paste commands, I’d advise doing the same. If you were creating users for actual humans, I’d recommend using their names.\n\n\nTerminal\n\n&gt; adduser test-user\n\nWe want this new user to be able to adopt root privileges so let’s add them to the sudo group with\n\n\nTerminal\n\n&gt; usermod -aG sudo test-user\n\n\n\n9.9.2 Step 2: Add an SSH key for your new user\nLet’s register an SSH key for the new user by adding the key from the last lab to the server user’s authorized_users file.\nFirst, you must get your public key to the server using scp.\nFor me, the command looks like this\n\n\nTerminal\n\n&gt; scp -i ~/Documents/do4ds-lab/do4ds-lab-key.pem \\ \n  ~/.ssh/id_ed25519.pub \\\n  ubuntu@$SERVER_ADDRESS:/home/ubuntu\n\n\n\n\n\n\n\nTip\n\n\n\nWe’re copying the public key, but SSH access (argument to -i) is still with the server’s .pem key because there isn’t another one registered yet.\n\n\nThe public key is on the server but in the ubuntu user’s home directory. You’ll need to do the following:\n\nCreate .ssh/authorized_keys in test-user’s home directory.\nCopy the contents of the public key you uploaded into the authorized_keys file (recall &gt;&gt;).\nEnsure the .ssh directory and authorized_keys files are owned by test-user with 700 permissions on .ssh and 600 on authorized_keys.\n\nYou could do this all as the admin user, but I’d recommend switching to being test-user at some point with the su command.\n\n\n\n\n\n\nTip\n\n\n\nIf you run into trouble assuming sudo with your new user, try exiting SSH and returning. Sometimes, these changes aren’t picked up until you restart the shell.\n\n\nOnce you’ve done all this, you should be able to log in from your personal computer with ssh test-user@$SERVER_ADDRESS.\nNow that we’re all set up, you should store the .pem key somewhere safe and never use it to login again."
+    "text": "9.9 Lab: Set up a user\nWhen you use your server’s .pem key, you log in as the root user, but that’s too much power to acquire regularly. Additionally, since your server is probably for multiple people, you will want to create users for them.\nIn this lab, you’ll create a regular user for yourself and add an SSH key for them so you can directly log in from your personal computer.\n\n9.9.1 Step 1: Create a non-root user\nLet’s create a user using the adduser command. This will walk us through prompts to create a new user with a home directory and a password. Feel free to add any information you want – or to leave it blank – when prompted.\nI’m going to use the username test-user. If you want to be able to copy/paste commands, I’d advise doing the same. If you were creating users for actual humans, I’d recommend using their names.\n\n\nTerminal\n\n&gt; adduser test-user\n\nWe want this new user to be able to adopt root privileges so let’s add them to the sudo group with\n\n\nTerminal\n\n&gt; usermod -aG sudo test-user\n\n\n\n9.9.2 Step 2: Add an SSH key for your new user\nLet’s register an SSH key for the new user by adding the key from the last lab to the server user’s authorized_users file.\nFirst, you must get your public key to the server using scp.\nFor me, the command looks like this\n\n\nTerminal\n\n&gt; scp -i ~/Documents/do4ds-lab/do4ds-lab-key.pem \\ \n  ~/.ssh/id_ed25519.pub \\\n  ubuntu@$SERVER_ADDRESS:/home/ubuntu\n\n\n\n\n\n\n\nTip\n\n\n\nWe’re copying the public key, but SSH access (argument to -i) is still with the server’s .pem key because there isn’t another one registered yet.\n\n\nThe public key is on the server but in the ubuntu user’s home directory. You’ll need to do the following:\n\nCreate .ssh/authorized_keys in test-user’s home directory.\nCopy the contents of the public key you uploaded into the authorized_keys file (recall &gt;&gt;).\nEnsure the .ssh directory and authorized_keys files are owned by test-user with 700 permissions on .ssh and 600 on authorized_keys.\n\nYou could do this all as the admin user, but I’d recommend switching to being test-user at some point with the su command.\n\n\n\n\n\n\nTip\n\n\n\nIf you run into trouble assuming sudo with your new user, try exiting SSH and returning. Sometimes, these changes aren’t picked up until you restart the shell.\n\n\nOnce you’ve done all this, you should be able to log in from your personal computer with ssh test-user@$SERVER_ADDRESS.\nNow that we’re all set up, you should store the .pem key somewhere safe and never use it to log in again."
   },
   {
     "objectID": "chapters/sec2/2-3-linux.html#footnotes",
@@ -1026,7 +1026,7 @@
     "href": "chapters/sec3/3-2-auth.html#managing-permissions",
     "title": "16  Auth in Enterprise",
     "section": "16.5 Managing permissions",
-    "text": "16.5 Managing permissions\nIrrespective of the technology used, your organization will have policies about managing permissions that you must incorporate or adopt.\nThere are meaningful differences in how LDAP, SAML, and OAuth communicate to services about permissions. That’s a level of detail beyond this chapter – more in Appendix A if you’re interested.\nIf your organization has a policy that you’re going to need to be able to enforce inside the data science environment, it’s most likely a Role Based Access Control (RBAC) policy. In RBAC, permissions are assigned to an abstraction called a role. Users and groups are then given roles depending on their needs.\nFor example, there might be a manager role that should have access to specific permissions in the HR software. This role would be applied to anyone in the data-science-manager group as well as the data-engineering-manager group.\nThere are a few issues with RBAC. Most importantly, if there are many idiosyncratic permissions, creating tons of special roles is often simpler than figuring out how to harmonize them into a system.\nMany organizations haven’t reached the complexity of adopting RBAC. They often use simple Access Control Lists (ACLs) of who can access each service.4 ACLs have the advantage of being conceptually simple, but maintaining individual lists for each service is a lot of work with many services and users.\nSome organizations are moving towards even more granular techniques than RBAC and are adopting Attribute Based Access Control (ABAC). In ABAC, permissions are granted based on an interaction of user-level and object-level attributes and a rules engine.\nFor example, you can imagine three distinct attributes a user could have: data-science, data-engineer, and manager. You could create a rules engine that provides access to different resources based on the combinations of these attributes.\nRelative to RBAC, ABAC is a more robust system that allows for more granular permissions, but it’s a much bigger lift to configure initially. You’ve already encountered an ABAC system in the AWS IAM system. You were probably completely befuddled if you tried to configure anything in IAM. You can thank the power and complexity of ABAC."
+    "text": "16.5 Managing permissions\nIrrespective of the technology used, your organization will have policies about managing permissions that you must incorporate or adopt.\nThere are meaningful differences in how LDAP, SAML, and OAuth communicate to services about permissions. That’s a level of detail beyond this chapter – more in Appendix A if you’re interested.\nIf your organization has a policy that you’re going to need to be able to enforce inside the data science environment, it’s most likely a Role Based Access Control (RBAC) policy. In RBAC, permissions are assigned to an abstraction called a role. Users and groups are then given roles depending on their needs.\nFor example, there might be a manager role that should have access to specific permissions in the HR software. This role would be applied to anyone in the data-science-manager group as well as the data-engineering-manager group.\nThere are a few issues with RBAC. Most importantly, if there are many idiosyncratic permissions, creating tons of special roles is often simpler than figuring out how to harmonize them into a system.\nMany organizations haven’t reached the complexity of adopting RBAC. They often use simple Access Control Lists (ACLs) of who can access each service.4 ACLs have the advantage of being conceptually simple, but maintaining individual lists for each service is a lot of work with many services and users.\nSome organizations are moving toward even more granular techniques than RBAC and are adopting Attribute Based Access Control (ABAC). In ABAC, permissions are granted based on an interaction of user-level and object-level attributes and a rules engine.\nFor example, you can imagine three distinct attributes a user could have: data-science, data-engineer, and manager. You could create a rules engine that provides access to different resources based on the combinations of these attributes.\nRelative to RBAC, ABAC is a more robust system that allows for more granular permissions, but it’s a much bigger lift to configure initially. You’ve already encountered an ABAC system in the AWS IAM system. You were probably completely befuddled if you tried to configure anything in IAM. You can thank the power and complexity of ABAC."
   },
   {
     "objectID": "chapters/sec3/3-2-auth.html#comprehension-questions",
@@ -1068,7 +1068,7 @@
     "href": "chapters/sec3/3-3-ent-scale.html#docker-in-enterprise-kubernetes",
     "title": "17  Compute at enterprise scale",
     "section": "17.4 Docker in enterprise = Kubernetes",
-    "text": "17.4 Docker in enterprise = Kubernetes\nInitially created at Google and released in 2014, the open-source Kubernetes (K8S, pronounced koo-ber-net-ees or kates for the abbreviation) is the way to run production services out of Docker containers.3 Many organizations are moving towards running most or all of their production work in Kubernetes.\n\n\n\n\n\n\nNote\n\n\n\nApparently, Kubernetes is an ancient Greek word for “helmsman”.\n\n\nIn a load-balanced cluster of servers, the IT/Admin must provision each node and then configure applications on it. In Kubernetes, the IT/Admin creates and registers a cluster of worker nodes. The only requirement for the worker nodes is that they run Kubernetes. No application-level configuration occurs on the nodes.\nTo run applications in a Kubernetes cluster, an IT/Admin tells the cluster’s control plane to run a set of Docker containers with a certain amount of computational power allocated to each one. These Docker Containers running in Kubernetes are called pods.\nThe elegance of Kubernetes is that the IT/Admin doesn’t have to think about where each pod goes. The control plane schedules the pods on the nodes without a human having to consider networking or application requirements.\n\nFrom the IT/Admin’s perspective, this is wonderful because they ensure the cluster has sufficient horsepower and all the app requirements come in the container, which makes node configuration trivial. The app’s authors are often responsible for building the Docker Containers, removing one thing from the IT/Admin’s to-do list.\nFor production purposes, pod deployments are usually managed with Helm charts, the standard IaC way to declare what pods you want, how many you need, and their relationships.\nAlmost any IT/Admin running Kubernetes can add nodes with a few clicks because they’re using a cloud provider’s managed service: AWS’s EKS (Elastic Kubernetes Service, Azure’s AKS (Azure Kubernetes Service), or GCP’s GKE (Google Kubernetes Engine).4\nKubernetes is a powerful tool, and there are many reasons to like it. But like most powerful tools, it’s also complicated. Becoming a proficient Kubernetes admin is a skill unto itself. These days, many IT/Admins are trying to add Kubernetes to their list of skills. If you have a competent Kubernetes admin, you should be in good shape, but you should be careful that setting up your data science environment doesn’t become someone else’s chance to learn Kubernetes."
+    "text": "17.4 Docker in enterprise = Kubernetes\nInitially created at Google and released in 2014, the open-source Kubernetes (K8S, pronounced koo-ber-net-ees or kates for the abbreviation) is the way to run production services out of Docker containers.3 Many organizations are moving toward running most or all of their production work in Kubernetes.\n\n\n\n\n\n\nNote\n\n\n\nApparently, Kubernetes is an ancient Greek word for “helmsman”.\n\n\nIn a load-balanced cluster of servers, the IT/Admin must provision each node and then configure applications on it. In Kubernetes, the IT/Admin creates and registers a cluster of worker nodes. The only requirement for the worker nodes is that they run Kubernetes. No application-level configuration occurs on the nodes.\nTo run applications in a Kubernetes cluster, an IT/Admin tells the cluster’s control plane to run a set of Docker containers with a certain amount of computational power allocated to each one. These Docker Containers running in Kubernetes are called pods.\nThe elegance of Kubernetes is that the IT/Admin doesn’t have to think about where each pod goes. The control plane schedules the pods on the nodes without a human having to consider networking or application requirements.\n\nFrom the IT/Admin’s perspective, this is wonderful because they ensure the cluster has sufficient horsepower and all the app requirements come in the container, which makes node configuration trivial. The app’s authors are often responsible for building the Docker Containers, removing one thing from the IT/Admin’s to-do list.\nFor production purposes, pod deployments are usually managed with Helm charts, the standard IaC way to declare what pods you want, how many you need, and their relationships.\nAlmost any IT/Admin running Kubernetes can add nodes with a few clicks because they’re using a cloud provider’s managed service: AWS’s EKS (Elastic Kubernetes Service, Azure’s AKS (Azure Kubernetes Service), or GCP’s GKE (Google Kubernetes Engine).4\nKubernetes is a powerful tool, and there are many reasons to like it. But like most powerful tools, it’s also complicated. Becoming a proficient Kubernetes admin is a skill unto itself. These days, many IT/Admins are trying to add Kubernetes to their list of skills. If you have a competent Kubernetes admin, you should be in good shape, but you should be careful that setting up your data science environment doesn’t become someone else’s chance to learn Kubernetes."
   },
   {
     "objectID": "chapters/sec3/3-3-ent-scale.html#sizing-and-scaling-clusters",
@@ -1129,79 +1129,79 @@
   {
     "objectID": "chapters/append/auth.html#service-based-auth",
     "href": "chapters/append/auth.html#service-based-auth",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.1 Service-based auth",
-    "text": "A.1 Service-based auth\nMany pieces of software come with integrated authentication. When you use those systems, the service stores encrypted username and password pairs in a database it owns. These setups are often really easy from an admin perspective – you just set up individual users on the service.\nOn the other hand, everything has to be managed service-by-service and you’re only as secure as what the service has implemented. Almost any organization with an IT/Admin group will prefer not to use service-based auth."
+    "text": "A.1 Service-based auth\nMany pieces of software come with integrated authentication. When you use those systems, the service stores encrypted username and password pairs in its own database. If you’re administering a single service, this is really simple. You just set up individual users on the service.\nBut once you have multiple services, everything has to be managed service-by-service. And the system is only as secure as what the service has implemented. Almost any organization with an IT/Admin group will prefer not to use service-based auth."
   },
   {
     "objectID": "chapters/append/auth.html#system-linux-accounts",
     "href": "chapters/append/auth.html#system-linux-accounts",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.2 System (Linux) Accounts",
-    "text": "A.2 System (Linux) Accounts\nMany pieces of software – especially data science workbenches – are able to look at the server they’re sitting on and use the user accounts and groups from the server themselves.\nOn a Linux server, Pluggable Authentication Modules (PAM) is the system that allows a service to make use of the Linux host’s users and groups. As of this writing, PAM is the default authentication method for both RStudio Server and JupyterHub.\nAs the name might suggest, PAM includes a number of different modules that allow it to authenticate against different systems. The most common is to authenticate against the underlying Linux server, but it can also use LDAP/AD or Kerberos tickets (uncommon).\n\nPAM can also be used to do things when users login – the most common being initializing Kerberos tickets to connect with databases.\nWhen PAM is used in concert with LDAP/AD, the Linux users are usually created automatically on the system using a system called SSSD (System Security Services Daemon). This process is called joining the domain.\nThough conceptually simple, reading, writing, and managing PAM modules is quite painful. Additionally, as more services move to the cloud, there isn’t necessarily an underlying Linux host where identities live and PAM is generally considered a legacy technology."
+    "text": "A.2 System (Linux) Accounts\nMany pieces of software – especially data science workbenches – can look at the server it’s sitting on and authenticate against the user accounts and groups on the server.\nOn a Linux server, Pluggable Authentication Modules (PAM) allow a service to make use of the Linux host’s users and groups. As of this writing, PAM is the default authentication method for RStudio Server and JupyterHub.\nAs the name suggests, PAM includes modules that allow it to authenticate against different systems. The most common is to authenticate against the underlying Linux server, but it can also use LDAP/AD (common) or Kerberos tickets (uncommon).\n\nPAM can also be used to do things when users log in. The most common of these is initializing Kerberos tickets to connect with databases or connecting with shared drives.\nWhen PAM is used in concert with LDAP/AD, the Linux users are usually created automatically on the system using SSSD (System Security Services Daemon). This process is called joining the domain.\nThough conceptually simple, the syntax of PAM modules is confusing, and reading, writing, and managing PAM modules is onerous. Additionally, as more services move to the cloud, there isn’t necessarily an underlying Linux host where identities live and PAM can’t be used at all."
   },
   {
     "objectID": "chapters/append/auth.html#ldapad",
     "href": "chapters/append/auth.html#ldapad",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.3 LDAP/AD",
-    "text": "A.3 LDAP/AD\nFor many years, Microsoft’s Lightweight Directory Access Protocol (LDAP) implementation called Active Directory (AD) was basically the standard in enterprise authentication. It is increasingly being retired in favor of token-based systems like SAML and OAuth2.0.\nDepending on the service, it may use LDAP/AD indirectly via PAM, or it may be directly configured to talk to LDAP/AD.\n\n\n\n\n\n\nNote\n\n\n\nLDAP is an application-layer protocol, like HTTP. And like HTTP, there is an SSL-secured version called LDAPS. Because LDAP is almost always used only inside a private network, adoption of LDAPS is uneven. The default port for LDAP is \\(389\\) and for LDAPS it’s \\(636\\).\n\n\nLDAP/AD actually isn’t a type of authentication. It’s a hierarchical tree database that is good for storing organizational entities. Doing authentication with LDAP/AD consists of sending a search for the provided username/password combination to the LDAP/AD database using the ldapsearch command.\nWhen you configure LDAP/AD in an application, you’ll configure a search base, which is the subtree to look for users inside. Additionally, you may configure LDAP/AD with bind credentials to validate that it’s allowed to be looking things up in the server.\n\n\n\n\n\n\n\nNote\n\n\n\nDepending on your application and LDAP/AD configuration, it may be possible to skip the bind credentials and use the user’s credentials to look them up in single-bind mode (as opposed to double-bind when there are bind credentials). Single-bind is generally inferior and shouldn’t be used unless you can’t get bind credentials.\n\n\nWhen you run an ldapsearch, you get back the distinguished name (DN) of the entity that you are looking for (assuming it’s found).\nHere’s what my entry in a corporate LDAP directory might look like this:\ncn: Alex Gold\nmail: alex.gold@example.com\nmail: alex.gold@example.org\ndepartment: solutions\nmobile: 555-555-5555\nobjectClass: Person\nThis is helpful information, but you’ll note that there’s no direct information about authorization. Instead, you configure the service authorize certain users or groups. This is a pain, as each service needs to be configured separately.\nOne of the big issues with LDAP/AD is that credentials are provided to the service, which passes them along to the LDAP/AD server. This is one reason why LDAP/AD is inferior to token-based technologies, where the credentials are only ever provided to the identity provider."
+    "text": "A.3 LDAP/AD\nFor many years, Microsoft’s Lightweight Directory Access Protocol (LDAP) implementation called Active Directory (AD) was the standard in enterprise auth. It is increasingly being retired in favor of token-based systems like SAML and OAuth2.0.\nSome services can use LDAP/AD indirectly via PAM, while others may be directly configured to talk to LDAP/AD.\n\n\n\n\n\n\nNote\n\n\n\nLDAP is an application-layer protocol, like HTTP. And like HTTP, there is an SSL-secured version called LDAPS. Because LDAP is almost always used only inside a private network, adoption of LDAPS is uneven. The default port for LDAP is \\(389\\) and for LDAPS it’s \\(636\\).\n\n\nStrictly speaking, LDAP/AD isn’t an authentication tool. It’s a hierarchical tree database that is good for storing organizational entities. Doing authentication with LDAP/AD consists of sending a search for the provided username/password combination to the LDAP/AD database using the ldapsearch command.\nWhen you configure LDAP/AD in an application, you’ll configure a search base, which is the subtree to look for users inside. Additionally, you may configure LDAP/AD with bind credentials of a service account to authenticate to the LDAP/AD server itself.\n\n\n\n\n\n\n\nNote\n\n\n\nDepending on your application and LDAP/AD configuration, it may be possible to skip the bind credentials look up the user with their own credentials in single-bind mode, as opposed to double-bind when there are bind credentials. Single-bind is inferior and shouldn’t be used unless you can’t get bind credentials.\n\n\nAn ldapsearch returns the distinguished name (DN) of the entity that you are looking for – assuming it’s found.\nHere’s what my entry in a corporate LDAP directory might look like this:\ncn: Alex Gold\nmail: alex.gold@example.com\nmail: alex.gold@example.org\ndepartment: solutions\nmobile: 555-555-5555\nobjectClass: Person\nThis is helpful information, but you’ll note that there’s no direct information about authorization. Instead, you configure the service to authorize certain users or groups. This is time-consuming and error-prone, as each service needs to be configured separately."
   },
   {
     "objectID": "chapters/append/auth.html#sec-kerberos",
     "href": "chapters/append/auth.html#sec-kerberos",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.4 Kerberos Tickets",
-    "text": "A.4 Kerberos Tickets\nKerberos is a relatively old, but very secure, token-based auth technology for use inside a private network. In Kerberos, encrypted tokens called Kerberos tickets are passed between the servers in the system. A system that is designed to authenticate against a Kerberos ticket is called kerberized.2\nThough Kerberos is freely available, it was widely adopted along with Active Directory, and it’s used almost exclusively in places that are running a lot of Microsoft products. The most frequent use of Kerberos tickets these days is to establish connections to Microsoft databases.\nKerberos is tightly linked to the underlying servers, one of the reasons why it is so secure. In a Kerberos-based system, users often store their credentials in a secure file called a keytab. They can manually initialize a ticket using the kinit command, though PAM sessions are often used to automatically fetch a ticket upon user login.\nWhen a Kerberos session is initialized, the service sends the users’ credentials off to the central Kerberos Domain Controller (KDC) and requests something called the Ticket Granting Ticket (TGT) from the KDC. Like most token authentication, TGTs have a set expiration period and must be reacquired when they expire.\nWhen the user wants to access a service, they send the TGT back to the KDC again along with the service they’re trying to access and get a session key (sometimes referred to as a service ticket) that allows access to a particular service.\n\nKerberos is basically only used inside a corporate network. This is one reason it’s still considered secure. On the other hand, because everything has to live inside the network, it doesn’t work well for providing access to services outside the network, like SaaS software. For that reason, Kerberos is considered a legacy tool."
+    "text": "A.4 Kerberos Tickets\nKerberos is a relatively old, but very secure, token-based auth technology for use inside a private network. In Kerberos, encrypted tokens called Kerberos tickets are passed between the servers in the system. A system that is designed to authenticate against a Kerberos ticket is called kerberized.\nKerberos was widely adopted along with Active Directory, and it’s used almost exclusively in places that are running a lot of Microsoft products. The most frequent use of Kerberos tickets is to establish connections to Microsoft databases.\nIn a Kerberos-based system, users often store their credentials in a secure keytab, which is a file on disk. They can manually initialize a ticket using the kinit command or via a PAM session that automatically fetches a ticket upon user login.\nWhen a Kerberos session is initialized, the service sends the user’s credentials off to the central Kerberos Domain Controller (KDC) and requests the Ticket Granting Ticket (TGT) from the KDC. Like most token authentication, TGTs have a set expiration period and must be reacquired when they expire.\nWhen the user wants to access a service, they send the TGT back to the KDC again along with the service they’re trying to access and get a session key (sometimes referred to as a service ticket) that allows access to a particular service.\n\nKerberos is only used inside a corporate network and is tightly linked to the underlying servers. That makes it very secure. Even if someone stole a Kerberos ticket, it would be very hard for them to use it.\nOn the other hand, because Kerberos is so tightly tied to servers, it is a difficult fit alongside cloud technologies and services."
   },
   {
     "objectID": "chapters/append/auth.html#oauth-saml",
     "href": "chapters/append/auth.html#oauth-saml",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.5 Modern systems: OAuth + SAML",
-    "text": "A.5 Modern systems: OAuth + SAML\nThese days, most organizations are quickly moving towards implementing a modern token-based authentication system through SAML and/or OAuth2.0.\nWhen you go to login to a service that uses SAML or OAuth, you are redirected to the SAML/OAuth identity provider to seek a token that will let you in. Assuming all goes well, you’re granted a token and go back to the service to go do your work.\nBoth OAuth and SAML rely on plain HTTP traffic, making them easier to configure than LDAP/AD or Kerberos from a networking standpoint.\n\nA.5.1 SAML\nThe current SAML 2.0 standard was finalized in 2005 – roughly coinciding with the beginning of the modern era of the web. Facebook was started just the prior year.\nSAML was invented to be a modern successor to enterprise auth methods like LDAP/AD and Kerberos. SAML uses encrypted and cryptographically-signed XML-based tokens that are generated through a browser redirect flow.\nIn SAML, the service you’re accessing is called the service provider (SP) and the entity issuing the token is called the SAML identity provider (IdP). Most SAML tooling allows you start at either the IdP or the SP.\nIf you start at the SP, you’ll get redirected to the IdP. The IdP will verify your credentials. If all is good, it will put a SAML token in your browser, which the SP will use to authenticate you.3\n\nA SAML token contains a number of claims, which usually include a username and may include groups or other attributes. Whoever controls the IdP can configure what claims appear on the token at the IdP. The SAML standard itself doesn’t do authorization, but it’s very common for an application to have required or optional claims that it can interpret to do authorization.\n\n\nA.5.2 OAuth\nOAuth was started in 2006 and the current 2.0 standard was finalized in 2013. OAuth 2.1 is under development as of 2023.\nFrom the very beginning, OAuth was designed to be used with different services across the web. Any time you’ve used a Login with Google/Facebook/Twitter/GitHub flow – that’s OAuth.\nOAuth relies on passing around cryptographically-signed JSON Web Tokens (JWT). This makes OAuth much easier to debug compared to SAML because the JWT is just plain-text JSON with a signature that proves it’s valid.\nUnlike a SAML token that always lives in a browser cache, JWTs can go basically anywhere. They can live in the browser, but they also can pass from one server to another to do authorization or can be saved in a user’s home directory. For example, if you’ve accessed Google Sheets or another Google service from R or Python, you may have manually handled the resulting OAuth token in your home directory.\nOAuth is actually an authorization scheme, so the contents of a JWT explicitly are about the permissions of the bearer of the token. There is a related standard called OpenID Connect (OIDC) that does authentication with OAuth tokens. Over the next few years, I fully expect basically all data access to move towards using OAuth tokens.\nIn OAuth, the service you’re trying to visit is called the resource server and the token issuer is the authorization server. When you try to access a service, the service knows to look for a JWT that includes specific claims against a set of scopes defined ahead of time.\nFor example, if you want to read my Google Calendar, you would need to have a JWT that includes a claim granting read access against the scope of events on Alex’s calendar.\nIf you don’t have that token, you’ll need to go to the authorization server to get it. Unlike in SAML where action is all occurring via HTTP redirects, OAuth makes no assumptions about how this flow happens.\n\nThe authorization server knows how to accept requests for a token and the resource server knows how to accept them. The process of requesting and getting a token can happen in a number of different ways that might include browser redirects and caches, but also could be done entirely in R or Python."
+    "text": "A.5 Modern systems: OAuth + SAML\nMost organizations are now quickly moving toward implementing a modern token-based authentication system through SAML and/or OAuth2.0.\nWhen you go to log in to a service that uses SAML or OAuth, you are redirected to the SAML/OAuth identity provider to seek a token that will let you in. Assuming all goes well, you’re granted a token and go back to the service to do your work.\nBoth OAuth and SAML rely on plain HTTP traffic, making them easier to configure than LDAP/AD or Kerberos from a networking standpoint.\n\nA.5.1 SAML\nThe current SAML 2.0 standard was finalized in 2005, roughly coinciding with the beginning of the web’s modern era, with Facebook launching just the prior year.\nSAML was invented to be a successor to enterprise auth methods like LDAP/AD and Kerberos. SAML uses encrypted and cryptographically signed XML tokens that are generated through a browser redirect flow.\nIn SAML, the service you’re accessing is called the service provider (SP) and the entity issuing the token is the SAML identity provider (IdP). Most SAML tooling allows you start at either the IdP or the SP.\nIf you start at the SP, you’ll get redirected to the IdP. The IdP will verify your credentials. If the credentials are valid, the IdP will put a SAML token in your browser, which the SP will use to authenticate you.3\n\nA SAML token contains several claims, which usually include a username and may include groups or other attributes. Whoever controls the IdP can configure what claims appear on the token at the IdP. The SAML standard itself is for authentication, not authorization, but it’s very common for an application to have required or optional claims that it can interpret to do authorization.\n\n\nA.5.2 OAuth\nOAuth was started in 2006 and the current 2.0 standard was finalized in 2013. OAuth 2.1 is under development as of 2023.\nOAuth was designed to be used with different services across the web from the beginning. Any time you’ve used a Log in with Google/Facebook/Twitter/GitHub flow – that’s OAuth.\nOAuth relies on passing around cryptographically signed JSON Web Tokens (JWTs). This makes OAuth more straightforward to debug than SAML because the JWT is plain-text JSON with a signature that proves it’s valid.\nUnlike a SAML token that always lives in a browser cache, JWTs can go anywhere. They can live in the browser cache, but they also can pass from one server to another to do authorization or can be saved in a user’s home directory. For example, if you’ve accessed Google Sheets or another Google service from R or Python, you may have manually handled the resulting OAuth token in your home directory.\nOAuth is an authorization scheme, so the contents of a JWT are about the permissions of the bearer of the token. A related standard called OpenID Connect (OIDC) can be used to do authentication with OAuth tokens. Over the next few years, I fully expect all data access to move toward using OAuth tokens.\nIn OAuth, the service you’re trying to visit is called the resource server and the token issuer is the authorization server. When you try to access a service, the service knows to look for a JWT that includes specific claims against a set of scopes. If you don’t have a JWT, you must seek it from the authorization server.\nFor example, if you want to read my Google Calendar, you need a JWT that includes a claim granting read access against the scope of events on Alex’s calendar.\n\nUnlike in SAML where action occurs via browser redirects, OAuth makes no assumptions about how this flow happens. The process of requesting and getting a token can happen in several different ways, including browser redirects and caches, but could be done entirely in R or Python."
   },
   {
     "objectID": "chapters/append/auth.html#user-provisioning",
     "href": "chapters/append/auth.html#user-provisioning",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "A.6 User Provisioning",
-    "text": "A.6 User Provisioning\nWhen you’re using a service, users often need to be created (provisioned) in that system. In some cases, the users will be provisioned the first time they log in. In other cases, you may want the ability to provision them ahead of time.\nLDAP/AD is very good for user provisioning. You can often configure your application to provision everyone who comes back from a particular ldapsearch. In contrast, token-based systems don’t know anything about you until you show up for the first time with a valid token.\nThere is a SAML-based provisioning system called SCIM (System for Cross-Domain Identity Management) that is slowly being adopted by many IdPs and SPs."
+    "text": "A.6 User Provisioning\nWhen you’re using a service, users often need to be created (provisioned) in that system. Sometimes, the users will be provisioned the first time they log in. In other cases, you may want the ability to provision them beforehand.\nLDAP/AD is very good for user provisioning. You can often configure your application to provision everyone who comes back from a particular ldapsearch. In contrast, token-based systems don’t know anything about you until you show up for the first time with a valid token.\nThere is a SAML-based provisioning system called SCIM (System for Cross-Domain Identity Management) that is slowly being adopted by many IdPs and SPs."
   },
   {
     "objectID": "chapters/append/auth.html#footnotes",
     "href": "chapters/append/auth.html#footnotes",
-    "title": "Appendix A — Auth Technologies",
+    "title": "Appendix A — Technical Detail: Auth Technologies",
     "section": "",
-    "text": "To be precise, possible if integrated with Kerberos, but unlikely.↩︎\nYuck, what a gross word.↩︎\nThe diagram below assumes you don’t already have a token in your browser. Step 6 is actually the first thing that happens when the user visits the SP. If the user has a token already, steps 2-5 get skipped.↩︎"
+    "text": "As in Chapter 16, I’m using the term token as a summary, but Kerberos, SAML, and OAuth all have different names – more on that below.↩︎\nTo be precise, possible if integrated with Kerberos, but unlikely.↩︎\nThe diagram assumes you don’t already have a token in your browser. If the user has a token already, steps 2-5 get skipped.↩︎"
   },
   {
     "objectID": "chapters/append/lb.html#load-balancer-settings",
     "href": "chapters/append/lb.html#load-balancer-settings",
     "title": "Appendix B — Technical Detail: Load balancers",
     "section": "B.1 Load balancer settings",
-    "text": "B.1 Load balancer settings\nRegardless of which load balancer you’re using, a basic requirement is that it knows what nodes are accepting traffic. This is accomplished by configuring a health check/heartbeat for the application on the node. A health check is a feature of the application that responds to periodic pings from the load balancer. If no response comes back, the load balancer treats that node as unhealthy and doesn’t send traffic there.\nOne other feature that may come up is sticky sessions or sticky cookies. For stateful applications, like Shiny apps, you want to get back to the same node in the cluster so you can resume a previous session. In most load balancers, this is just an option you can activate."
+    "text": "B.1 Load balancer settings\nRegardless of which load balancer you’re using, a basic requirement is that it knows what nodes are accepting traffic. This is accomplished by configuring a health check/heartbeat for the application on the node. A health check is an application feature that responds to periodic pings from the load balancer. If no response comes back, the load balancer treats that node as unhealthy and doesn’t send traffic there.\nFor applications that maintain user state, like Shiny apps, you want to get back to the same node in the cluster so you can resume a previous session. This can be enabled with sticky sessions or sticky cookies. In most load balancers, this is simply an option you can activate."
   },
   {
     "objectID": "chapters/append/lb.html#ways-to-configure-load-balancing",
     "href": "chapters/append/lb.html#ways-to-configure-load-balancing",
     "title": "Appendix B — Technical Detail: Load balancers",
     "section": "B.2 Ways to configure load balancing",
-    "text": "B.2 Ways to configure load balancing\nThe simplest form of load balancing is to just rotate traffic to each node that is healthy in a round-robin configuration. Depending on the capabilities of the load balancer and what metrics are emitted by the application, it may also be possible or desirable to do more complicated load balancing that pays attention to how loaded different nodes are.\nUsually, load balancers are configured to send traffic to all the nodes in the cluster in an active/active configuration. It is also possible to configure the load balancer in an active/passive configuration to send traffic to only some of the nodes, with the rest remaining inert until they are switched on, usually in the event of a failure in the active ones. This is sometimes called a blue/green or red/black configuration when it’s used to diminish downtime in upgrades and migrations."
+    "text": "B.2 Ways to configure load balancing\nThe simplest form of load balancing is to rotate traffic to each healthy node in a round-robin configuration. Depending on the capabilities of the load balancer and what metrics are emitted by the application, it may also be possible or desirable to do more sophisticated load balancing that routes sessions according to how loaded each node is.\nUsually, load balancers are configured to send traffic to all the nodes in the cluster in an active/active configuration. It is also possible to configure the load balancer in an active/passive configuration to send traffic to only some of the nodes, with the rest remaining inert until they are switched on – usually in the event of a failure in the active ones. This is sometimes called a blue/green or red/black configuration when it’s used to diminish downtime in upgrades and migrations."
   },
   {
     "objectID": "chapters/append/lb.html#shared-state",
     "href": "chapters/append/lb.html#shared-state",
     "title": "Appendix B — Technical Detail: Load balancers",
     "section": "B.3 Shared state",
-    "text": "B.3 Shared state\nAside from the load balancer, the nodes need to be able to share state with each other so users can have the same experience on each node. The requirements for that shared state depend on the software.\nOften the shared state takes the form of a database (often Postgres) and/or Network Attached Storage (NAS, pronounced naahz) for things that get stored in a filesystem.\nIf your NAS is exclusively for Linux, you it would use NFS (Network File System). If Windows is involved, you’d use SMB (Server Message Block) or Samba to connect SMB to a Linux server. There’s also an outdated Windows NAS called CIFS (Common Internet File System) that you might see in older systems.\nEach of the cloud providers has a NAS offering. AWS has EFS (Elastic File System) and FSx. Azure has Azure File, and GCP has Filestore."
+    "text": "B.3 Shared state\nAside from the load balancer, the nodes need to be able to share state so users can have the same experience on each node. The requirements for that shared state depend on the software.\nOften the shared state takes the form of a database (often Postgres) and/or Network Attached Storage (NAS, pronounced naahz) for things that get stored in a filesystem.\nIf your NAS is exclusively for Linux, it would use NFS (Network File System). If Windows is involved, you’d use SMB (Server Message Block) or Samba to connect SMB to a Linux server. There’s also an outdated Windows NAS called CIFS (Common Internet File System) that you might see in older systems.\nEach of the cloud providers has a NAS offering. AWS has EFS (Elastic File System) and FSx. Azure has Azure File, and GCP has Filestore."
   },
   {
     "objectID": "chapters/append/lb.html#upgrades-in-ha",
     "href": "chapters/append/lb.html#upgrades-in-ha",
     "title": "Appendix B — Technical Detail: Load balancers",
     "section": "B.4 Upgrades in HA",
-    "text": "B.4 Upgrades in HA\nSometimes IT/Admins want to run an HA cluster with software that supports zero downtime upgrades. In order to do a zero-downtime upgrade, you need to take some nodes offline, upgrade them, put them back online, and then upgrade the rest of the nodes.\nThere are a two features the application you’re upgrading needs to support to accomplish this feat. If it doesn’t support both, you’ll need to endure some downtime to do an upgrade.\nThe first is node draining. If you just naively removed a node, you might kill someone’s active session. Instead, you’d want to configure the node so that it doesn’t kill any existing sessions but also doesn’t accept any new ones. As the current sessions end, the node empties and you can safely take it offline when all the sessions are gone.\nThe second is rolling upgrade. Some software supports being in a load balanced cluster with different versions of the software and other does not. If your software doesn’t support a cluster with mixed versions, a rolling upgrade won’t be possible. Supporting a rolling upgrade is relatively rare. It requires that the cluster understand how to maintain metadata across different versions simultaneously, which is a tricky bit of application programming.\nIf your application doesn’t support zero downtime upgrades, some organizations like to get close by building a second copy of the environment, getting it almost live, and then taking downtime just to switch the networking over. That’s generally much faster than building the whole thing during downtime."
+    "text": "B.4 Upgrades in HA\nSometimes IT/Admins want to upgrade the software running in the cluster without taking the service offline. This is called a zero-downtime upgrade. In a zero-downtime upgrade, you take some nodes offline, upgrade them, put them back online, and then upgrade the remainder.\nTo accomplish this feat, there are two features the application needs to support. If it doesn’t support both, you’ll need to endure some downtime to do an upgrade.\nThe first is node draining. If you just naively removed a node, you might kill someone’s active session. Instead, you’d want to configure the node so that it doesn’t kill any existing sessions but also doesn’t accept any new ones. As the current sessions end, the node empties and you can safely take it offline when all the sessions are gone.\nThe second is rolling upgrade, which is the ability to support mixed software versions in the same cluster. When you upgrade a piece of software, there are often changes to how the data in the shared state is stored. That means the creators would need to undertake painstaking work to avoid conflicts during the upgrade process. Because it’s tricky to support active sessions in a cluster with mixed versions, it’s relatively uncommon.\nIf your application doesn’t support zero downtime upgrades, some organizations like to get close by building a second copy of the server and its applications, getting it almost live, and then taking downtime solely to switch the networking over. That’s generally much faster than building the whole thing during downtime."
   },
   {
     "objectID": "chapters/append/lab-map.html",
diff --git a/sitemap.xml b/sitemap.xml
index 4827a412..6e2fec05 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,110 +2,110 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
   <url>
     <loc>https://do4ds.com/index.html</loc>
-    <lastmod>2023-10-23T22:24:07.349Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.282Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/intro.html</loc>
-    <lastmod>2023-10-23T22:24:07.361Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.294Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-0-sec-intro.html</loc>
-    <lastmod>2023-10-23T22:24:07.373Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.302Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-1-env-as-code.html</loc>
-    <lastmod>2023-10-23T22:24:07.397Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.322Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-2-proj-arch.html</loc>
-    <lastmod>2023-10-23T22:24:07.413Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.338Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-3-data-access.html</loc>
-    <lastmod>2023-10-23T22:24:07.461Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.382Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-4-monitor-log.html</loc>
-    <lastmod>2023-10-23T22:24:07.501Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.410Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-5-deployments.html</loc>
-    <lastmod>2023-10-23T22:24:07.521Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.430Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec1/1-6-docker.html</loc>
-    <lastmod>2023-10-23T22:24:07.549Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.446Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-0-sec-intro.html</loc>
-    <lastmod>2023-10-23T22:24:07.561Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.458Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-1-cloud.html</loc>
-    <lastmod>2023-10-23T22:24:07.589Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.482Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-2-cmd-line.html</loc>
-    <lastmod>2023-10-23T22:24:07.617Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.506Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-3-linux.html</loc>
-    <lastmod>2023-10-23T22:24:07.645Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.530Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-4-app-admin.html</loc>
-    <lastmod>2023-10-23T22:24:07.685Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.562Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-5-scale.html</loc>
-    <lastmod>2023-10-23T22:24:07.725Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.598Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-6-networking.html</loc>
-    <lastmod>2023-10-23T22:24:07.789Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.650Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-7-dns.html</loc>
-    <lastmod>2023-10-23T22:24:07.805Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.662Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec2/2-8-ssl.html</loc>
-    <lastmod>2023-10-23T22:24:07.817Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.674Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec3/3-0-sec-intro.html</loc>
-    <lastmod>2023-10-23T22:24:07.829Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.682Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec3/3-1-ent-networks.html</loc>
-    <lastmod>2023-10-23T22:24:07.845Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.694Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec3/3-2-auth.html</loc>
-    <lastmod>2023-10-23T22:24:07.857Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.706Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec3/3-3-ent-scale.html</loc>
-    <lastmod>2023-10-23T22:24:07.873Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.718Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/sec3/3-4-ent-pm.html</loc>
-    <lastmod>2023-10-23T22:24:07.885Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.730Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/append/auth.html</loc>
-    <lastmod>2023-10-23T22:24:07.913Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.750Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/append/lb.html</loc>
-    <lastmod>2023-10-23T22:24:07.925Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.758Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/append/lab-map.html</loc>
-    <lastmod>2023-10-23T22:24:07.937Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.766Z</lastmod>
   </url>
   <url>
     <loc>https://do4ds.com/chapters/append/cheatsheets.html</loc>
-    <lastmod>2023-10-23T22:24:07.981Z</lastmod>
+    <lastmod>2023-10-25T14:37:21.806Z</lastmod>
   </url>
 </urlset>