more rewording from puppet to OpenVox

Signed-off-by: Martin Alfke <ma@betadots.de>

Author: tuxmea

docs/background/index.markdown

@@ -6,14 +6,14 @@ toc: false
 
 
 This page collects information about foundational technologies and practices.
-These are not tied to any specific Puppet product, but we believe many of our users will either need to or want to be familiar with them.
+These are not tied to any specific OpenVox product, but we believe many of our users will either need to or want to be familiar with them.
 
 ## [SSL and Related Topics](./ssl/)
 
-Puppet relies on HTTPS to secure its communications and identify nodes.
-Using it effectively requires familiarity with concepts like certificates and public key cryptography, which can sometimes present a steep learning curve for new Puppet users.
+OpenVox relies on HTTPS to secure its communications and identify nodes.
+Using it effectively requires familiarity with concepts like certificates and public key cryptography, which can sometimes present a steep learning curve for new OpenVox users.
 
-This series of articles explains the foundations of Puppet's security model, which is also used by many other systems across the internet.
+This series of articles explains the foundations of OpenVox's security model, which is also used by many other systems across the internet.
 
 - [Index](./ssl/index.html)
 - [What is Public Key Cryptography?](./ssl/public_key.html)

docs/background/ssl/cert_anatomy.markdown

@@ -85,7 +85,7 @@ To inspect a certificate, you must first dump it to a text format.
 
 * On the CA OpenVox server node, this can be done with the `puppetserver ca print --certname <name>` command.
 * The `openssl x509 -text -noout -in <file>` command will also work and is not restricted to the CA puppet master, although it requires a full file path.
-Note that it also will not use friendly names for any Puppet-specific certificate extensions (explained further below).
+Note that it also will not use friendly names for any OpenVox-specific certificate extensions (explained further below).
 
 Here's the certificate from above in human-readable form:
 

docs/background/ssl/certificates_pki.markdown

@@ -94,7 +94,7 @@ The traditional way to manage revocation info is with a **certificate revocation
 
 Participants in the PKI should regularly retrieve a copy of each CA's CRL, and should double-check certificates against it when checking their validity.
 
-This is the method of revocation checking that Puppet uses.
+This is the method of revocation checking that OpenVox uses.
 
 ### Online Certificate Status Protocol (OCSP)
 
@@ -190,7 +190,7 @@ Sometimes this agreement is active; other times, it's tacit, like when you insta
 * Because the CA approves all certificate metadata, participants don't have to keep a list of all the public keys they'll need to know about; instead, they can just trust any valid certificate they are shown.
 * Because certificates include public keys, only their rightful owner can present them as ID. A stolen cert is inert without a stolen private key.
 * The CA can also revoke certificates, but that only works if everybody regularly checks for revoked certificates (via a traditional CRL or more modern means). This is even harder to ensure than it sounds.
-* Puppet has built-in tools to make managing a CA easier. These are covered in other documentation.
+* OpenVox has built-in tools to make managing a CA easier. These are covered in other documentation.
 
 ## Next in This Series
 

docs/background/ssl/https.markdown

@@ -72,16 +72,8 @@ When the proxy receives a reply, it will forward it to the client along the orig
 
 If the application needs any SSL or certificate data, the proxy can be configured to publish it by inserting the data into the HTTP headers of the request it sends to the backend application server.
 
-An example of this is a puppet master running with the Nginx + Unicorn stack:
-
-* Nginx terminates SSL, and inserts the SSL client authentication status and client certificate DN into the HTTP headers of a new request. It sends this request to the Unicorn workers.
-* A Unicorn worker receives the unencrypted request, and, according to the common gateway interface (CGI) standard, publishes all HTTP header information as CGI variables,
-including the SSL information inserted by Nginx. It uses the Rack interface to translate the HTTP request into a request to the puppet master application.
-* The puppet master application reads SSL information from pre-arranged environment variables, and uses its auth.conf configuration to decide whether to serve the request.
-If yes, it uses its own application logic to decide what the request should be. Any response passes back through the Unicorn worker and Nginx to make its way to the puppet agent client.
-
 ## End of Series
 
-At this point, you should understand enough about the fundamentals to understand any documentation on this site about managing Puppet's certificates, CA, and HTTPS authorization tools.
+At this point, you should understand enough about the fundamentals to understand any documentation on this site about managing OpenVox's certificates, CA, and HTTPS authorization tools.
 
 For a little more practical depth, you may also want to see the [appendix on certificate anatomy.][certificate_anatomy]

docs/background/ssl/tls_ssl.markdown

@@ -14,7 +14,7 @@ SSL ("secure socket layer") is an older version of that same protocol, which is
 
 > ## A Note on Names
 >
-> "TLS" and "SSL" both refer to essentially the same thing. Informally, many people (including us at Puppet Labs) often just say "SSL" to refer to any combination of TLS and SSL, mostly because old habits die hard.
+> "TLS" and "SSL" both refer to essentially the same thing. Informally, many people often just say "SSL" to refer to any combination of TLS and SSL, mostly because old habits die hard.
 >
 > Most tools can use multiple versions of the protocol, and the combination of versions they support will often cross the arbitrary TLS/SSL boundary. (Usually something like SSL 3.0, TLS 1.0, and TLS 1.1.)
 > Since clients and servers can negotiate versions on the fly, the exact protocol you'll be using at any given moment depends on the configuration of every tool that might interact with the system.
@@ -42,7 +42,7 @@ After a client starts the process, an SSL connection involves the following proc
   * The client software validates that certificate, based on its list of trustworthy CAs, the CRLs it has available, and the validity period of the certificate. If it won't validate, the client bails.
 * **Optionally,** the client can present a certificate of its own to the server.
 The client will also sign a piece of server-provided data to prove that it possesses the corresponding private key. The server will validate the client certificate before continuing.
-  * This only happens if the server explicitly requests **client authentication.** Most HTTPS sites on the web don't require client authentication. Puppet, however, does (for some services).
+  * This only happens if the server explicitly requests **client authentication.** Most HTTPS sites on the web don't require client authentication. OpenVox, however, does (for some services).
 * The client sends a temporary "session" key to the server, encrypted so that only the owner of the server certificate can read it.
 * Both client and server use that session key to encrypt all subsequent traffic in the connection, using a symmetric cypher.
 (Using a public key cypher wouldn't be appropriate, since the client doesn't always provide a public key.)