Merge branch 'main' into ngf-release-2.0

Author: ADubhlaoich

config/_default/config.toml

@@ -47,7 +47,8 @@ enableGitInfo = true
     "taxonomyTerm"
   ]
   taxonomiesExcludedFromSitemap = ["tags", "categories", "doctypes"]
-
+  unitversion= "1.34.1"
+  unitversionv= "v1.34.1"
   #logo = ""
 
   # Version lists; used by the versions shortcode

content/includes/nginx-one/staged-config-overview.md

@@ -13,6 +13,6 @@ With Staged Configurations, you can use these features of NGINX One Console:
 - Automatic syntax checking
 - Contextual documentation
 - Dynamic analysis of your work in progress
-- Suggestions from our AI assistant
+- Suggestions from our F5 AI assistant
 
 Once you've finished your work and have pushed the changes to an Instance or a Config Sync Group, you can next delete that Staged Configuration.

content/includes/nginxaas-azure/ssl-tls-prerequisites.md

@@ -2,9 +2,11 @@
 docs: "DOCS-000"
 ---
 
+NGINXaaS natively integrates with [Azure Key Vault (AKV)](https://azure.microsoft.com/en-us/products/key-vault), so you can bring your own certificates and manage them in a centralized location. You will need:
+
 - AKV to store certificates that you want to add to the deployment.
 
-- A user or system assigned identity associated with your NGINXaaS deployment. Ensure that your managed identity (MI) has read access to secrets stored in AKV:
+- A user or system assigned identity associated with your NGINXaaS deployment. Ensure that your Managed Identity (MI) has read access to secrets stored in AKV:
 
   - If using Azure RBAC for AKV, ensure that your MI has [Key Vault Secrets User](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#key-vault-secrets-user) or higher permissions.
 

content/includes/unit/howto_change_ownership.md

@@ -0,0 +1,18 @@
+Run the following command (as root) so Unit can access the application
+directory (If the application uses several directories, run the command for
+each one):
+
+```console
+# chown -R unit:unit /path/to/app/  # User and group that Unit's router runs as by default
+```
+
+
+{{< note >}}
+The **unit:unit** user-group pair is available only with
+[official packages]({{< relref "/unit/installation.md#installation-precomp-pkgs" >}})
+, Docker [images]({{< relref "/unit/installation.md#installation-docker" >}}),
+and some [third-party repos]({{< relref "/unit/installation.md#installation-community-repos" >}}). Otherwise, account names may differ; run the `ps aux | grep unitd` command to be sure.
+{{< /note >}}
+
+For further details, including permissions, see the
+[security checklist]({{< relref "/unit/howto/security.md#secutiry-apps" >}}).

content/includes/unit/howto_install_app.md

@@ -0,0 +1,2 @@
+Install {{ app }}'s [app-link]. Here, we install it at **/path/to/app/**; use
+a real path in your configuration.

content/includes/unit/howto_install_prereq.md

@@ -0,0 +1 @@
+Install and configure {{ app }}'s [app-preq].

content/includes/unit/howto_install_unit.md

@@ -0,0 +1 @@
+Install [Unit]({{< relref "/unit/installation.md#installation-precomp-pkgs" >}}) with a {{ mod }} language module.

content/includes/unit/howto_upload_config.md

@@ -0,0 +1,14 @@
+Assuming the JSON above was added to
+`config.json`. Run the following command as root:
+
+```console
+# curl -X PUT --data-binary @config.json --unix-socket \
+   /path/to/control.unit.sock \  # Path to Unit's control socket in your installation
+   http://localhost/config/      # Path to the config section in Unit's control API
+```
+
+{{< note >}}
+The [control socket]({{< relref "/unit/installation.md#configuration-socket" >}}) path may vary; run
+`unitd -h` or see
+[Startup and shutdown]({{< relref "/unit/howto/source.md#source-startup" >}}) for details.
+{{< /note >}}

content/includes/unit/version.md

@@ -0,0 +1 @@
+1.34.1

content/nginx-one/changelog.md

@@ -94,9 +94,9 @@ Using the NGINX One Console you can now:
 - Review the differences between the current and other saved configurations
 - Revert to older configurations as needed
 
-### AI Assistant
+### F5 AI Assistant
 
-In the F5 NGINX One Console, you can now select lines from your configuration files, and then select **Explain with AI**. The NGINX One AI Assistant explains those lines based on the official NGINX documentation.
+In the F5 NGINX One Console, you can now select lines from your configuration files, and then select **Explain with AI**. The F5 AI Assistant explains those lines based on the official NGINX documentation.
 
 ## November 7, 2024
 

content/nginx-one/how-to/certificates/manage-certificates.md

@@ -178,7 +178,7 @@ If you register an instance to NGINX One Console, as described in [Add your NGIN
 - Are used in their NGINX configuration
 - Do _not_ match an existing managed SSL certificate/CA bundle
 
-These certificates appear in the list of unmanaged certificates.
+These certificates appear in the list of unmanaged certificates. NGINX One Console does not store unmanaged certs or keys, only metadata associated with certs for monitoring.
 
 We recommend that you convert your unmanaged certificates. Converting to a managed certificate allows you to centrally manage, update, and deploy a certificate to your data plane from the NGINX One Console.
 

content/nginx-one/how-to/config-sync-groups/manage-config-sync-groups.md

@@ -37,7 +37,7 @@ Config Sync Groups support configuration inheritance and persistance. If you've
 
 On the other hand, if you remove all instances from a Config Sync Group, the original configuration persists. In other words, the group retains the configuration from that first instance (or the original configuration). Any new instance that you add later still inherits that configuration.
 
-{{< tip >}}You can use _unmanaged_ certificates. Your actions can affect the [Config Sync Group status](#config-sync-group-status). For future instances on the data plane, if it:
+{{< tip >}}You can use _unmanaged_ certificates. NGINX One Console does not store unmanaged certs or keys, only metadata associated with the certs or keys for monitoring. Your actions can affect the [Config Sync Group status](#config-sync-group-status). For future instances on the data plane, if it:
 
 - Has unmanaged certificates in the same file paths as defined by the NGINX configuration as the Config Sync Group, that instance will be [**In Sync**](#config-sync-group-status).
 - Will be [**Out of Sync**](#config-sync-group-status) if the instance:

content/nginx-one/rbac/rbac-api.md

@@ -42,6 +42,6 @@ The following table lists the available API groups that you can use to construct
 | f5xc-nginx-one-custom-settings-manage               | Write           | View and update NGINX One Console Settings.                                                                               |
 | f5xc-nginx-one-custom-settings-read                 | Read            | View NGINX One Console Settings.                                                                                          |
 | f5xc-nginx-one-custom-event-read                   | Read            | View NGINX One Events.                                                                                                    |
-| f5xc-nginx-one-custom-ai-assistant                  | Write           | Interact with the NGINX One AI Assistant.                                                                                     |
+| f5xc-nginx-one-custom-ai-assistant                  | Write           | Interact with the F5 AI Assistant.                                                                                     |
 | f5xc-nginx-one-custom-staged-config-manage         | Write           | View, create, update, and delete Staged Configs.                                                                          |
 | f5xc-nginx-one-custom-staged-config-read           | Read            | View Staged Configs.                                                                                                      |

content/nginx/admin-guide/basic-functionality/runtime-control.md

@@ -32,7 +32,7 @@ where `<SIGNAL>` can be one of the following:
 - `quit` – Shut down gracefully (the `SIGQUIT` signal)
 - `reload` – Reload the configuration file (the `SIGHUP` signal)
 - `reopen` – Reopen log files (the `SIGUSR1` signal)
-- `stop` – Shut down immediately (or fast shutdown, the `SIGTERM` singal)
+- `stop` – Shut down immediately (or fast shutdown, the `SIGTERM` signal)
 
 The `kill` utility can also be used to send a signal directly to the master process. The process ID of the master process is written, by default, to the **nginx.pid** file, which is located in the **/usr/local/nginx/logs** or **/var/run** directory.