Merge branch 'nginx:main' into Mv1205

Author: MV1205

content/includes/licensing-and-reporting/apply-jwt.md

@@ -1,11 +1,21 @@
 ---
 docs:
+file:
+  - content/solutions/about-subscription-licenses.md
+  - content/nap-waf/v5/admin-guide/install.md
 ---
 
 1. Copy the license file to `/etc/nginx/license.jwt` on Linux or `/usr/local/etc/nginx/license.jwt` on FreeBSD for each NGINX Plus instance.
+2. Reload NGINX:
 
-1. **SELinux**: If you're running a Linux distribution with SELinux enabled, set the file security context type with the following command:
-
-   ```bash
-   chcon -t httpd_config_t /etc/nginx/license.jwt
+   ```shell
+   systemctl reload nginx
    ```
+
+**If SELinux is enabled**: 
+
+Set the correct file context so NGINX can read the license:
+
+```shell
+chcon -t httpd_config_t /etc/nginx/license.jwt
+```

content/includes/licensing-and-reporting/configure-nginx-plus-report-to-nim.md

@@ -17,5 +17,5 @@ docs:
 3. Reload NGINX:
 
     ``` bash
-    nginx -s reload
+    systemctl reload nginx
     ```

content/nginx-one/changelog.md

@@ -30,6 +30,15 @@ h2 {
 
 Stay up-to-date with what's new and improved in the F5 NGINX One Console.
 
+## Apr 30, 2025
+
+### Manage RBAC access with namespaces
+
+We have added support for namespaces in N1C. You can now:
+
+- Manage resources in isolation in different namespaces.
+- Configure granular user permission controls base on namespace.
+
 ## April 3, 2025
 
 ### Create Custom Roles with more precise permissions

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

@@ -100,6 +100,12 @@ Now that you created a Config Sync Group, you can add instances to that group. A
 
 Any instance that joins the group afterwards inherits that configuration.
 
+{{< note >}} If you see the following [Config Sync Group Status](#config-sync-group-status) message: **Out of Sync**:
+
+ - Review the instance details in NGINX One Console to identify any publication problems.
+ - After you change the configuration of the Config Sync Group, [Publish it](#publish-the-config-sync-group-configuration].
+In that case, review and resolve discrepancies between the Instance and the rest of the Config Sync Group. {{< /note >}}
+
 ### Add an existing instance to a Config Sync Group {#add-an-existing-instance-to-a-config-sync-group}
 
 You can add existing NGINX instances that are already registered with NGINX One to a Config Sync Group.

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

@@ -91,7 +91,7 @@ stream {
 
 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.
 
-## Reloading Configuration
+## 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" >}}).
 

content/nginx/admin-guide/installing-nginx/installing-nginx-plus-amazon-web-services.md

@@ -16,7 +16,7 @@ The AMIs contain the following components:
 - Latest version of [NGINX Plus](https://www.f5.com/products/nginx/nginx-plus), optimized for use on Amazon EC2
 - Pre-packaged software for building highly available (HA) NGINX Plus configurations
 
-## Installing the F5 NGINX Plus AMI
+## Install the F5 NGINX Plus AMI
 
 To quickly set up an NGINX Plus environment on AWS:
 

content/nginx/admin-guide/installing-nginx/installing-nginx-plus-google-cloud-platform.md

@@ -12,7 +12,7 @@ type:
 [NGINX Plus](https://www.f5.com/products/nginx/nginx-plus), the high‑performance application delivery platform, load balancer, and web server, is available on the Google Cloud Platform as a virtual machine (VM) image. The VM image contains the latest version of NGINX Plus, optimized for use with the Google Cloud Platform Compute Engine.
 
 
-## Installing the NGINX Plus VM
+## Install the NGINX Plus VM
 
 To quickly set up an NGINX Plus environment on the Google Cloud Platform, perform the following steps.
 
@@ -52,7 +52,7 @@ If you encounter any problems with NGINX Plus configuration, documentation is a
 Customers who purchase an NGINX Plus VM image on the Google Cloud Platform are eligible for the Google Cloud Platform VM support provided by the NGINX, Inc. engineering team. To activate support, submit the [Google Cloud Platform Support Activation](https://www.nginx.com/gcp-support-activation/) form.
 
 
-### Accessing the Open Source Licenses for NGINX Plus
+### Access the Open Source Licenses for NGINX Plus
 
 NGINX Plus includes open source software written by NGINX, Inc. and other contributors. The text of the open source licenses is provided in Appendix B of the _NGINX Plus Reference Guide_. To access the guide included with the NGINX Plus VM instance, run this command:
 

content/nginx/admin-guide/installing-nginx/installing-nginx-plus-microsoft-azure.md

@@ -13,7 +13,7 @@ type:
 
 The VM image contains the latest version of NGINX Plus, optimized for use with Azure.
 
-## Installing the NGINX Plus VM
+## Install the NGINX Plus VM
 
 To quickly set up an NGINX Plus environment on Microsoft Azure:
 

content/nginx/admin-guide/mail-proxy/mail-proxy.md

@@ -2,7 +2,7 @@
 description: Simplify your email service and improve its performance with NGINX or
   F5 NGINX Plus as a proxy for the IMAP, POP3, and SMTP protocols
 docs: DOCS-423
-title: Configuring NGINX as a Mail Proxy Server
+title: Configure NGINX as a Mail Proxy Server
 toc: true
 weight: 100
 type:

content/nginx/admin-guide/monitoring/logging.md

@@ -9,32 +9,33 @@ type:
 - how-to
 ---
 
-This article describes how to configure logging of errors and processed requests in NGINX Open Source and NGINX Plus.
+This article describes how to log errors and requests in NGINX Open Source and NGINX Plus.
 
 <span id="error_log"></span>
-## Setting Up the Error Log
+## Set Up the Error Log
+
+NGINX writes an error log that records encountered issues of different severity levels. The [error_log](https://nginx.org/en/docs/ngx_core_module.html#error_log) directive sets up the log location and severity level. The log location can be a particular file, `stderr`, or `syslog`. By default, the error log is located at **logs/error.log**, but the absolute path depends on the operating system and installation. The error severity level follows the `syslog` classification system. The log includes messages from all severity levels above the specified level. 
 
-NGINX writes information about encountered issues of different severity levels to the error log. The [error_log](https://nginx.org/en/docs/ngx_core_module.html#error_log) directive sets up logging to a particular file, `stderr`, or `syslog` and specifies the minimal severity level of messages to log. By default, the error log is located at **logs/error.log** (the absolute path depends on the operating system and installation), and messages from all severity levels above the one specified are logged.
 
 The configuration below changes the minimal severity level of error messages to log from `error` to `warn`:
 
 ```nginx
 error_log logs/error.log warn;
 ```
 
-In this case, messages of `warn`, `error` `crit`, `alert`, and `emerg` levels are logged.
+In this case, messages above the `warn` level are logged. That includes `warn`, `error` `crit`, `alert`, and `emerg` levels.
 
-The default setting of the error log works globally. To override it, place the [error_log](https://nginx.org/en/docs/ngx_core_module.html#error_log) directive in the `main` (top-level) configuration context. Settings in the `main` context are always inherited by other configuration levels (`http`, `server`, `location`). The `error_log` directive can be also specified at the [http](https://nginx.org/en/docs/http/ngx_http_core_module.html#http), [stream](https://nginx.org/en/docs/stream/ngx_stream_core_module.html#stream), `server` and [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) levels and overrides the setting inherited from the higher levels. In case of an error, the message is written to only one error log, the one closest to the level where the error has occurred. However, if several `error_log` directives are specified on the same level, the message are written to all specified logs.
+The default setting of the error log works globally. To override it, place the [error_log](https://nginx.org/en/docs/ngx_core_module.html#error_log) directive in the `main` (top-level) configuration context. Settings in the `main` context are always inherited by other configuration levels (`http`, `server`, `location`). The `error_log` directive can be also specified at the [http](https://nginx.org/en/docs/http/ngx_http_core_module.html#http), [stream](https://nginx.org/en/docs/stream/ngx_stream_core_module.html#stream), `server` and [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) levels. Settings at lower levels override the settings inherited from the higher levels. Each error message is written only once to the error log closest to the level where the error has occurred. However, if several `error_log` directives are specified on the same level, the message is written to all specified logs.
 
 > **Note:** The ability to specify multiple `error_log` directives on the same configuration level was added in NGINX Open Source  version [1.5.2](https://nginx.org/en/CHANGES).
 
 
 <span id="access_log"></span>
-## Setting Up the Access Log
+## Set Up the Access Log
 
-NGINX writes information about client requests in the access log right after the request is processed. By default, the access log is located at **logs/access.log**, and the information is written to the log in the predefined **combined** format. To override the default setting, use the [log_format](https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) directive to change the format of logged messages, as well as the [access_log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive to specify the location of the log and its format. The log format is defined using variables.
+NGINX records client requests in the access log right after the request is processed. The [access_log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive specifies the location of the log and its format. By default, the access log is located at **logs/access.log**. The format of logged messages is the predefined **combined** format. To change the format of logged messages, use the [log_format](https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) directive. The log format is defined using variables.
 
-The following examples define the log format that extends the predefined **combined** format with the value indicating the ratio of gzip compression of the response. The format is then applied to a virtual server that enables compression.
+The following example extends the predefined **combined** format by specifying the `gzip ratio` keyword. This enables gzip compression of the response in a virtual server.
 
 ```nginx
 http {
@@ -50,7 +51,7 @@ http {
 }
 ```
 
-Another example of the log format enables tracking different time values between NGINX and an upstream server that may help to diagnose a problem if your website experience slowdowns. You can use the following variables to log the indicated time values:
+Another example of the log format enables tracking different time values between NGINX and an upstream server. This may help with diagnosing a slowdown of your website. You can use the following variables to log the indicated time values:
 
 - [`$upstream_connect_time`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_connect_time) – The time spent on establishing a connection with an upstream server
 - [`$upstream_header_time`](https://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_header_time) – The time between establishing a connection and receiving the first byte of the response header from the upstream server
@@ -80,11 +81,10 @@ When reading the resulting time values, keep the following in mind:
 - When a request is unable to reach an upstream server or a full header cannot be received, the variable contains `0` (zero)
 - In case of internal error while connecting to an upstream or when a reply is taken from the cache, the variable contains `-` (hyphen)
 
-Logging can be optimized by enabling the buffer for log messages and the cache of descriptors of frequently used log files whose names contain variables. To enable buffering use the `buffer` parameter of the [access_log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive to specify the size of the buffer. The buffered messages are then written to the log file when the next log message does not fit into the buffer as well as in some other [cases](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log).
-
+The log can be optimized by enabling the `buffer` and the `cache`. With the [buffer](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) parameter enabled, messages will be stored in the buffer first. When the buffer is full (or in some other [cases](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log)), the messages will be written to the log. 
 To enable caching of log file descriptors, use the [open_log_file_cache](https://nginx.org/en/docs/http/ngx_http_log_module.html#open_log_file_cache) directive.
 
-Similar to the `error_log` directive, the [access_log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive defined on a particular configuration level overrides the settings from the previous levels. When processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. If one level defines multiple access logs, the message is written to all of them.
+Similar to the `error_log` directive, the [access_log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) directive defined on a particular configuration level overrides the settings from the previous levels. When processing of a request is completed, the message is written to the log that is configured on the current level, or inherited from the previous levels. If one level has multiple access log definitions, the message is written to all of them.
 
 
 <span id="conditional"></span>