chore(config): rename to docs

_config.yml

@@ -59,10 +59,10 @@ defaults:
   -
     scope:
       path: "" # an empty string here means all files in the project
-      type: "config" # previously `post` in Jekyll 2.2.
+      type: "docs" # previously `post` in Jekyll 2.2.
     values:
-      layout: "config"
-      permalink: /config/:name
+      layout: "docs"
+      permalink: /docs/:name
   -
     scope:
       path: "" # an empty string here means all files in the project

_includes/header.html

@@ -20,7 +20,7 @@
 
           <div class="trigger">
               <a class="page-link" href="/get-started/">Get Started</a>
-              <a class="page-link" href="/config/">Config</a>
+              <a class="page-link" href="/docs/">Docs</a>
               <a class="page-link" href="/guides/">Guides</a>
               <a class="page-link" href="/demo/">Demo</a>
               <a class="page-link" href="/blog/">Blog</a>

config/_subsections/operator-architecture.md → docs/_subsections/operator-architecture.md

@@ -63,7 +63,7 @@ The label <code>cryostat.io/callback-port</code> can be used to control the HTTP
 
 ### [Flow of JFR Data](#flow-of-jfr-data)
 
-**Cryostat** traditonally connects to other **JVM** applications within its cluster using remote JMX, using cluster-internal URLs so that no traffic will leave the cluster. **Cryostat** supports connecting to target **JVMs** with JMX auth credentials enabled ("Basic" style authentication). When a connection attempt to a target fails due to a <code>SecurityException</code>, Cryostat responds to the requesting client with an HTTP 427 status code and the header <code>X-JMX-Authenticate: Basic</code>. The client is expected to create a [Stored Credential](/guides/#store-credentials) object via the **Cryostat API** before retrying the request, which results in the required target credentials being stored in an encrypted database table. When deployed in **OpenShift** the requests are already encrypted using **OpenShift** TLS re-encryption as mentioned above, so the credentials are never transmitted in cleartext. The table is encrypted with a passphrase either provided by the user at deployment time, or generated by the **Operator** if none is specified. It is also possible to configure **Cryostat** to trust SSL certificates used by target JVMs by adding the certificate to a <code>Secret</code> and linking that to the **Cryostat CR**, which will add the certificate to the SSL trust store used by **Cryostat**. The Operator also uses **cert-manager** to generate a self-signed CA and provides **Cryostat's** auth proxy with certificates as a mounted volume. For more information on setting this up, see [Configuring the Operator](/config/#configure-the-cryostat-operator)
+**Cryostat** traditonally connects to other **JVM** applications within its cluster using remote JMX, using cluster-internal URLs so that no traffic will leave the cluster. **Cryostat** supports connecting to target **JVMs** with JMX auth credentials enabled ("Basic" style authentication). When a connection attempt to a target fails due to a <code>SecurityException</code>, Cryostat responds to the requesting client with an HTTP 427 status code and the header <code>X-JMX-Authenticate: Basic</code>. The client is expected to create a [Stored Credential](/guides/#store-credentials) object via the **Cryostat API** before retrying the request, which results in the required target credentials being stored in an encrypted database table. When deployed in **OpenShift** the requests are already encrypted using **OpenShift** TLS re-encryption as mentioned above, so the credentials are never transmitted in cleartext. The table is encrypted with a passphrase either provided by the user at deployment time, or generated by the **Operator** if none is specified. It is also possible to configure **Cryostat** to trust SSL certificates used by target JVMs by adding the certificate to a <code>Secret</code> and linking that to the **Cryostat CR**, which will add the certificate to the SSL trust store used by **Cryostat**. The Operator also uses **cert-manager** to generate a self-signed CA and provides **Cryostat's** auth proxy with certificates as a mounted volume. For more information on setting this up, see [Configuring the Operator](/docs/#configure-the-cryostat-operator)
 
 In more recent releases, **JVM** applications may optionally be instrumented with the **Cryostat Agent**, which uses the local **JDK** Instrumentation API to hook into the target application. The **Cryostat Agent** then exposes a **JDK** HTTP(S) webserver, generates credentials to secure it, and looks up its supplied configuration to locate the **Cryostat** server instance it should register with. Once it is registered the **Cryostat Agent** creates a <code>Stored Credential</code> object on the server corresponding to itself, then clears its generated password from memory retaining only the hash. From this point on, the **Agent** and **Cryostat** server communicate with each other using Basic authentication bidirectionally, and with TLS enabled on each webserver if enabled/configured.
 

config/index.md → docs/index.md

@@ -1,6 +1,6 @@
 ---
-layout: config
-title: Cryostat Advanced Configuration
+layout: docs
+title: Cryostat Documentation
 ---
 
 * auto-gen TOC:

get-started/index.md

@@ -242,7 +242,7 @@ is built with **Maven**, packaged into an image with a `Dockerfile`, and running
 
 ##### [Using the Cryostat Agent](#using-the-cryostat-agent)
 
-[The **Cryostat Agent**](/config/#using-the-cryostat-agent)
+[The **Cryostat Agent**](/docs/#using-the-cryostat-agent)
 is compatible with **Cryostat** versions 2.3.0 and newer, and application **JDKs 11** and newer.
 If you are using an older version of **Cryostat** we recommend upgrading to ensure compatibility.
 Please see the [version compatibility chart](https://github.com/cryostatio/cryostat-agent?tab=readme-ov-file#run-requirements) to ensure
@@ -376,7 +376,7 @@ look for different names/numbers.
 ## [Next Steps](#next-steps)
 Now that you have installed and deployed **Cryostat** and know how to access its
 **web client**, continue on to [Guides](/guides/) for
-guides through various common actions and workflows. For more information on advanced installation configurations, continue to [Config](/config/).
+guides through various common actions and workflows. For more information on advanced installation configurations, continue to [Docs](/docs/).
 
 ## [Uninstalling Cryostat Operator](#uninstalling-cryostat-operator)
 Reference [**OLM**](https://olm.operatorframework.io/docs/tasks/uninstall-operator/#combine-steps-2-and-3)