Merge branch 'main' into install-fix

Author: y82

content/nap-dos/deployment-guide/learn-about-deployment.md

@@ -413,22 +413,28 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
 
 6. Enable Yum repositories to pull NGINX App Protect DoS dependencies:
 
-    If you have a RHEL subscription:
+    For RHEL subscription:
 
     ```shell
     sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
     sudo subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms
     sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
     ```
 
-7. Add NGINX Plus and NGINX App Protect DoS repository:
+    For RockyLinux:
+   
+    ```shell
+    sudo dnf -y install epel-release
+    ```
+
+8. Add NGINX Plus and NGINX App Protect DoS repository:
 
     ```shell
     sudo wget -P /etc/yum.repos.d https://cs.nginx.com/static/files/nginx-plus-8.repo
     sudo wget -P /etc/yum.repos.d https://cs.nginx.com/static/files/app-protect-dos-8.repo
     ```
 
-8. In case of fresh installation, update the repository and install the most recent version of the NGINX Plus App Protect DoS package (which includes NGINX Plus):
+9. In case of fresh installation, update the repository and install the most recent version of the NGINX Plus App Protect DoS package (which includes NGINX Plus):
 
     ```shell
     sudo dnf install app-protect-dos
@@ -457,7 +463,7 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
     sudo dnf install app-protect-dos-27+2.4.0
     ```
 
-9. In case of upgrading from previously installed NGINX Plus App Protect DoS package (which includes NGINX Plus):
+10. In case of upgrading from previously installed NGINX Plus App Protect DoS package (which includes NGINX Plus):
 
     ```shell
     sudo dnf remove nginx-plus
@@ -621,14 +627,20 @@ When deploying App Protect DoS on NGINX Plus take the following precautions to s
 
 6. Enable the yum repositories to pull NGINX App Protect DoS dependencies:
 
-    If you have a RHEL subscription:
+    For RHEL subscription:
 
     ```shell
     sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-rpms
     sudo subscription-manager repos --enable=rhel-9-for-x86_64-appstream-rpms
     sudo dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
     ```
 
+    For RockyLinux:
+   
+    ```shell
+    sudo dnf -y install epel-release
+    ```
+
 7. Add the NGINX Plus and NGINX App Protect DoS repositories:
 
     ```shell

content/nginx/admin-guide/basic-functionality/managing-configuration-files.md

@@ -9,11 +9,33 @@ type:
 - how-to
 ---
 
-Similar to other services, NGINX and NGINX Plus use a text‑based configuration file with a precise format. By default the file is named **nginx.conf** and for NGINX Plus is placed in the `/etc/nginx` directory.
+NGINX and NGINX Plus use a text‑based configuration file, by default named **nginx.conf**.
 
-For NGINX Open Source, the location depends on the package system used to install NGINX and the operating system. It is typically one of `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.
+NGINX Plus: default location is `/etc/nginx` for Linux or `/usr/local/etc/nginx` for FreeBSD.
+
+NGINX Open Source: location depends on the package system used to install NGINX and the operating system. It is typically one of `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.
+
+You can verify the exact configuration file path with the `--conf-path=` parameter in the output of the `nginx -V` command:
+
+```shell
+ nginx -V 2>&1 | awk -F: '/configure arguments/ {print $2}' | xargs -n1
+```
+
+Sample output:
+
+```none
+--prefix=/etc/nginx
+--sbin-path=/usr/sbin/nginx
+--modules-path=/usr/lib64/nginx/modules
+--conf-path=/etc/nginx/nginx.conf          # The path to your config file
+--error-log-path=/var/log/nginx/error.log
+--http-log-path=/var/log/nginx/access.log
+--pid-path=/var/run/nginx.pid
+--...<more parameters>
+```
 
 ## Directives
+
 The configuration file consists of _directives_ and their parameters. Simple (single‑line) directives end with a semicolon ( `;` ). Other directives act as “containers” which group together related directives. Containers are enclosed in curly braces ( `{}` ) and are often referred to as _blocks_. Here are some examples of simple directives.
 
 ```nginx
@@ -22,9 +44,9 @@ error_log        logs/error.log notice;
 worker_processes 1;
 ```
 
-## Feature-Specific Configuration Files
+## Feature-specific configuration files
 
-To make the configuration easier to maintain, we recommend that you split it into a set of feature‑specific files stored in the <span style="white-space: nowrap;">**/etc/nginx/conf.d**</span> directory and use the [include](https://nginx.org/en/docs/ngx_core_module.html#include) directive in the main **nginx.conf** file to reference the contents of the feature‑specific files.
+To make the configuration easier to maintain, it is possible to split it into a set of feature‑specific files stored in the `/etc/nginx/conf.d` directory and use the [include](https://nginx.org/en/docs/ngx_core_module.html#include) directive in the main **nginx.conf** file to reference the contents of the feature‑specific files.
 
 ```nginx
 include conf.d/http;
@@ -43,14 +65,15 @@ A few top‑level directives, referred to as _contexts_, group together the dire
 
 Directives placed outside of these contexts are said to be in the _main_ context.
 
-### Virtual Servers
+### Virtual servers
+
 In each of the traffic‑handling contexts, you include one or more `server` blocks to define _virtual servers_ that control the processing of requests. The directives you can include within a `server` context vary depending on the traffic type.
 
 For HTTP traffic (the `http` context), each [server](https://nginx.org/en/docs/http/ngx_http_core_module.html#server) directive controls the processing of requests for resources at particular domains or IP addresses. One or more [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) contexts within a `server` context define how to process specific sets of URIs.
 
 For mail and TCP/UDP traffic (the [mail](https://nginx.org/en/docs/mail/ngx_mail_core_module.html) and [stream](https://nginx.org/en/docs/stream/ngx_stream_core_module.html) contexts) the `server` directives each control the processing of traffic arriving at a particular TCP port or UNIX socket.
 
-### Sample Configuration File with Multiple Contexts
+### Sample configuration file with multiple contexts
 
 The following configuration illustrates the use of contexts.
 
@@ -89,10 +112,10 @@ stream {
 
 ### Inheritance
 
-In general, a _child_ context – a context contained within another context (its _parent_) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the [proxy_set_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive.
+In general, a _child_ context – a context contained within another context (its _parent_) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the [proxy_set_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive.
 
-## Reload Configuration File
+## Reload configuration file
 
 For changes to the configuration file to take effect, it must be reloaded. You can either restart the `nginx` process or send the `reload` signal to upgrade the configuration without interrupting the processing of current requests. For details, see [Control NGINX Processes at Runtime]({{< ref "/nginx/admin-guide/basic-functionality/runtime-control.md" >}}).
 
-With NGINX Plus, you can dynamically reconfigure [load balancing]({{< ref "/nginx/admin-guide/load-balancer/dynamic-configuration-api.md" >}}) across the servers in an upstream group without reloading the configuration. You can also use the NGINX Plus API and key‑value store to dynamically control access, for example [based on client IP address]({{< ref "/nginx/admin-guide/security-controls/denylisting-ip-addresses.md" >}}).
+With NGINX Plus, you can dynamically reconfigure [load balancing]({{< ref "/nginx/admin-guide/load-balancer/dynamic-configuration-api.md" >}}) across the servers in an upstream group without reloading the configuration. You can also use the NGINX Plus API and key‑value store to dynamically control access, for example [based on client IP address]({{< ref "/nginx/admin-guide/security-controls/denylisting-ip-addresses.md" >}}).

content/nginx/fips-compliance-nginx-plus.md

@@ -24,36 +24,42 @@ Some industries such as finance, healthcare, energy, also adopt FIPS to enhance
 
 Currently, both FIPS 140-2 and FIPS 140-3 certifications are accepted. However, FIPS 140-2 is being phased out as part of the [FIPS 140-3 transition plan](https://csrc.nist.gov/projects/fips-140-3-transition-effort). After September 22, 2026, only FIPS 140-3 certifications will be recognized. Organizations are encouraged to migrate to FIPS 140-3 to meet updated cryptographic security requirements.
 
-{{<bootstrap-table "table table-striped table-bordered table-sm">}}
-| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status**                                                  |
-|---------------------------------|----------------------------------|---------------------------------------------------------------------|
-| CJIS                          | 140-2 or 140-3               | FIPS required for systems protecting criminal justice data.               |
-| CMMC                          | 140-2 or 140-3               | FIPS required for Levels 2 and 3 compliance.                              |
-| Common Criteria               | 140-2 or 140-3               | Evaluations reference both FIPS versions for cryptographic security.      |
-| Critical Infrastructure       | 140-2 or 140-3               | Utilities and systems accept both versions depending on deployments.      |
-| Department of Veterans Affairs| 140-2 or 140-3               | Both versions used for securing sensitive health and personal data.       |
-| DFARS                         | 140-2 or 140-3               | Cryptographic modules for CUI must be FIPS compliant.                     |
-| DoDIN APL                     | 140-2 or 140-3               | Approved IT products must include FIPS validation.                        |
-| FAA                           | 140-2 transitioning to 140-3 | 140-2 modules common in existing systems; new systems use 140-3.          |
-| FERPA                         | 140-2 or 140-3               | Federal-funded educational systems align with 140-2 or 140-3.             |
-| FedRAMP                       | 140-2 or 140-3               | FIPS required for encryption; both versions accepted.                     |
-| FISMA                         | 140-2 or 140-3               | Both versions accepted; agencies adopt existing 140-2 modules.            |
-| HIPAA                         | 140-2 or 140-3               | FIPS ensures encryption for ePHI; both versions are valid.                |
-| HITECH                        | 140-2 or 140-3               | FIPS use aligns with encryption best practices for ePHI.                  |
-| Intelligence Community        | 140-2 transitioning to 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3.              |
-| Military & Tactical Systems   | 140-2 transitioning to 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools.|
-| NSA CSfC                      | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3.           |
-| Nuclear Regulatory Commission | 140-2 or 140-3               | Cryptography for nuclear systems relies on both versions.                 |
-| PCI DSS                       | 140-2 or 140-3               | Both versions recommended but not mandatory.                              |
-| State and Local Gov Programs  | 140-2 or 140-3               | FIPS required for federal grant-funded security systems.                  |
-| TSA                           | 140-2 or 140-3               | Best practice for cryptographic protection; both versions accepted.       |
-{{< /bootstrap-table >}}
+{{< table >}}
+| **Sector / Program**           | **Version**    | **Status**    |
+|--------------------------------|----------------|---------------|
+| **Federal Programs**           |                |               |
+| CJIS                           | 140-2 or 140-3 | Mandatory     |
+| FedRAMP                        | 140-2 or 140-3 | Mandatory     |
+| FISMA                          | 140-2 or 140-3 | Mandatory     |
+| DFARS                          | 140-2 or 140-3 | Mandatory     |
+| DoDIN APL                      | 140-2 or 140-3 | Mandatory     |
+| FAA                            | 140-2 to 140-3 | Transitioning |
+| TSA                            | 140-2 or 140-3 | Recommended   |
+| **Defense & Intelligence**     |                |               |
+| CMMC                           | 140-2 or 140-3 | Mandatory     |
+| Intelligence Community         | 140-2 to 140-3 | Transitioning |
+| NSA CSfC                       | 140-2 to 140-3 | Transitioning |
+| Military & Tactical Systems    | 140-2 to 140-3 | Transitioning |
+| **Healthcare & Education**     |                |               |
+| HIPAA                          | 140-2 or 140-3 | Mandatory     |
+| HITECH                         | 140-2 or 140-3 | Mandatory     |
+| Department of Veterans Affairs | 140-2 or 140-3 | Mandatory     |
+| FERPA                          | 140-2 or 140-3 | Recommended   |
+| **Commercial/Private Sector**  |                |               |
+| PCI DSS                        | 140-2 or 140-3 | Recommended   |
+| Common Criteria                | 140-2 or 140-3 | Recommended   |
+| **Infrastructure & Critical Systems** |         |               |
+| Critical Infrastructure        | 140-2 or 140-3 | Recommended   |
+| Nuclear Regulatory Commission  | 140-2 or 140-3 | Recommended   |
+| **State & Local Government**   |                |               |
+| State and Local Gov Programs   | 140-2 or 140-3 | Mandatory     |
+{{< /table >}}
 
 ### FIPS compliance in other countries
 
 Although FIPS 140 is primarily a North American government cryptographic standard, it is widely recognized as a global benchmark for cryptographic security. Numerous countries outside North America align their cryptographic requirements with FIPS, especially in regulated sectors such as finance, defense, healthcare, and critical infrastructure.
 
-{{<bootstrap-table "table table-striped table-bordered table-sm">}}
+{{< table >}}
 | Country/Region | FIPS Use                                                                    |
 |----------------|-----------------------------------------------------------------------------|
 | Australia      | Referenced for government, defense, and cryptography systems.               |
@@ -74,7 +80,7 @@ Although FIPS 140 is primarily a North American government cryptographic standar
 | UAE            | Trusted in finance, energy, and interoperability with the U.S. cryptography.|
 | United Kingdom | Referenced for defense, health, and procurement standards.                  |
 | United States  | Mandatory for federal government systems and contractors.                   |
-{{< /bootstrap-table >}}
+{{< /table >}}
 
 ## FIPS compliant vs FIPS validated
 
@@ -129,7 +135,7 @@ The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example and c
 
 ### Step 1: Configure the operating system to use FIPS mode {#os-fips-setup}
 
-For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations#sec-Enabling-FIPS-Mode) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system.
+For the purposes of the following demonstration, we installed and configured a RHEL 9.6 server. The [Red Hat FIPS documentation](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/switching-rhel-to-fips-mode_security-hardening) explains how to switch the operating system between FIPS mode and non‑FIPS mode by editing the boot options and restarting the system.
 
 For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation, for example:
 

content/nginxaas-azure/changelog.md

@@ -14,6 +14,17 @@ To see a list of currently active issues, visit the [Known issues]({{< ref "/ngi
 To review older entries, visit the [Changelog archive]({{< ref "/nginxaas-azure/changelog-archive" >}}) section.
 
 
+## September 18, 2025
+
+- {{% icon-feature %}} **Notification on update to deployments using the Stable Upgrade Channel**
+
+   NGINXaaS for Azure deployments using the **Stable** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}) will be updated to [NGINX Plus Release 35 (R35)]({{< ref "/nginx/releases.md#nginxplusrelease-35-r35" >}}) during the week of Oct 06-10, 2025. This will also include updates to the following NGINX Plus modules:
+  - nginx-plus-module-njs
+
+   Please review the [NGINX Plus Release 35 (R35)]({{< ref "/nginx/releases.md#nginxplusrelease-35-r35" >}}) Release Notes carefully. If you have any concerns, it's recommended to validate your configuration against NGINX Plus R35 by setting up a test deployment using the **Preview** [Upgrade Channel]({{< ref "/nginxaas-azure/quickstart/upgrade-channels.md" >}}). See [these instructions]({{< ref "/nginxaas-azure/quickstart/recreate.md" >}}) on how to set up a deployment similar to your current one.
+
+   If you have any questions or concerns, please [contact us]({{< ref "/nginxaas-azure/get-help.md" >}}).
+
 ## August 18, 2025
 
 - {{% icon-feature %}} **Updates to NGINXaaS for Azure GitHub Action**

content/nginxaas-azure/getting-started/nginx-configuration/nginx-configuration-azure-cli.md

@@ -127,6 +127,15 @@ az nginx deployment configuration analyze --deployment-name $DEPLOYMENT_NAME \
       --package data="$TAR_DATA"
    ```
 
+   Upload a package with config files and protected files:
+
+   ```shell
+   az nginx deployment configuration create --deployment-name myDeployment \
+      --resource-group myResourceGroup --root-file nginx.conf --name default \
+      --package data="$TAR_DATA" \
+      protected-files="['nginx/servers/server1.conf','nginx/servers/server2.conf']"
+   ```
+
 - Multiple file configuration with protected files:
 
    ```shell