diff --git a/content/agent/configuration/configuration-overview.md b/content/agent/configuration/configuration-overview.md index b060f4728..51e724fa2 100644 --- a/content/agent/configuration/configuration-overview.md +++ b/content/agent/configuration/configuration-overview.md @@ -51,11 +51,11 @@ server: host: grpcPort: 443 backoff: # note: default values are prepopulated - initial_interval: 100ms # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour - randomization_factor: 0.10 # Add the appropriate float value here, e.g., 0.10 - multiplier: 1.5 # Add the appropriate float value here, e.g., 1.5 - max_interval: 1m # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour - max_elapsed_time: 0 # Add the appropriate duration value here, e.g., "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + initial_interval: 100ms # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + randomization_factor: 0.10 # Add the appropriate float value here, for example, 0.10 + multiplier: 1.5 # Add the appropriate float value here, for example, 1.5 + max_interval: 1m # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + max_elapsed_time: 0 # Add the appropriate duration value here, for example, "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour # tls options tls: # enable tls in the nginx-agent setup for grpcs @@ -89,11 +89,11 @@ metrics: collection_interval: 15s mode: aggregated backoff: # note: default values are prepopulated - initial_interval: 100ms # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour - randomization_factor: 0.10 # Add the appropriate float value here, e.g., 0.10 - multiplier: 1.5 # Add the appropriate float value here, e.g., 1.5 - max_interval: 1m # Add the appropriate duration value here, e.g., "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour - max_elapsed_time: 0 # Add the appropriate duration value here, e.g., "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + initial_interval: 100ms # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + randomization_factor: 0.10 # Add the appropriate float value here, for example, 0.10 + multiplier: 1.5 # Add the appropriate float value here, for example, 1.5 + max_interval: 1m # Add the appropriate duration value here, for example, "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour + max_elapsed_time: 0 # Add the appropriate duration value here, for example, "0" for indefinite "100ms" for 100 milliseconds, "5s" for 5 seconds, "1m" for 1 minute, "1h" for 1 hour # OSS NGINX default config path # path to aux file dirs can also be added @@ -193,7 +193,7 @@ If you are upgrading from an older version, update your configuration accordingl | `--features` | `NGINX_AGENT_FEATURES` | Specifies a comma-separated list of features enabled for the agent. Default: *[registration, nginx-config-async, nginx-ssl-config, nginx-counting, metrics, dataplane-status, process-watcher, file-watcher, activity-events, agent-api]* | | `--ignore-directives` | | Specifies a comma-separated list of directives to ignore for sensitive info.| | `--instance-group` | `NGINX_AGENT_INSTANCE_GROUP` | Sets the instance's group value. | -| `--log-level` | `NGINX_AGENT_LOG_LEVEL` | Sets the logging level (e.g., panic, fatal, error, info, debug, trace). Default: *info* | +| `--log-level` | `NGINX_AGENT_LOG_LEVEL` | Sets the logging level (for example, panic, fatal, error, info, debug, trace). Default: *info* | | `--log-path` | `NGINX_AGENT_LOG_PATH` | Specifies the path to output log messages. | | `--metrics-bulk-size` | `NGINX_AGENT_METRICS_BULK_SIZE` | Specifies the number of metrics reports collected before sending data. Default: *20* | | `--metrics-collection-interval` | `NGINX_AGENT_METRICS_COLLECTION_INTERVAL` | Sets the interval for metrics collection. Default: *15s* | diff --git a/content/amplify/faq/nginx-amplify-agent.md b/content/amplify/faq/nginx-amplify-agent.md index e075a0292..f6965a94b 100644 --- a/content/amplify/faq/nginx-amplify-agent.md +++ b/content/amplify/faq/nginx-amplify-agent.md @@ -82,7 +82,7 @@ If you don't see the new system or NGINX in the web interface, or (some) metrics 3. NGINX Amplify Agent is running under the same user as your NGINX worker processes. -4. The NGINX instance is started with an absolute path. Currently, NGINX Amplify Agent **can't** detect NGINX instances launched with a relative path (e.g., "./nginx"). +4. The NGINX instance is started with an absolute path. Currently, NGINX Amplify Agent **can't** detect NGINX instances launched with a relative path (for example, "./nginx"). 5. The [user ID that is used by NGINX Amplify Agent and NGINX ]({{< ref "/amplify/nginx-amplify-agent/install/configuring-amplify-agent#overriding-the-effective-user-id" >}}), can run *ps(1)* to see all system processes. If *ps(1)* is restricted for non-privileged users, NGINX Amplify Agent won't be able to find and properly detect the NGINX master process. diff --git a/content/amplify/nginx-amplify-agent/configuration-analysis.md b/content/amplify/nginx-amplify-agent/configuration-analysis.md index eff066d47..0110f4a9b 100644 --- a/content/amplify/nginx-amplify-agent/configuration-analysis.md +++ b/content/amplify/nginx-amplify-agent/configuration-analysis.md @@ -8,7 +8,7 @@ docs: DOCS-961 F5 NGINX Amplify Agent can automatically find all relevant NGINX configuration files, parse them, extract their logical structure, and send the associated JSON data to the Amplify backend for further analysis and reporting. For more information on configuration analysis, please see the [Analyzer]({{< ref "/amplify/user-interface/analyzer.md" >}})) documentation. -After NGINX Amplify Agent finds a particular NGINX configuration, it then automatically starts to keep track of its changes. When a change is detected with NGINX — e.g., a master process restarts, or the NGINX config is edited, an update is sent to the Amplify backend. +After NGINX Amplify Agent finds a particular NGINX configuration, it then automatically starts to keep track of its changes. When a change is detected with NGINX — for example, a master process restarts, or the NGINX config is edited, an update is sent to the Amplify backend. {{< note >}} NGINX Amplify Agent never sends the raw unprocessed config files to the backend system. In addition, the following directives in the NGINX configuration are never analyzed — and their parameters aren't exported to the SaaS backend: [ssl_certificate_key](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_certificate_key), [ssl_client_certificate](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_client_certificate), [ssl_password_file](http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html#ssl_password_file), [ssl_stapling_file](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_file), [ssl_trusted_certificate](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate), [auth_basic_user_file](http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file), [secure_link_secret](http://nginx.org/en/docs/http/ngx_http_secure_link_module.html#secure_link_secret).{{< /note >}} diff --git a/content/amplify/nginx-amplify-agent/configuring-metric-collection.md b/content/amplify/nginx-amplify-agent/configuring-metric-collection.md index b9ab5b37c..b3bf29981 100644 --- a/content/amplify/nginx-amplify-agent/configuring-metric-collection.md +++ b/content/amplify/nginx-amplify-agent/configuring-metric-collection.md @@ -93,7 +93,7 @@ NGINX Amplify Agent will also collect more NGINX metrics from the [access.log](h You don't have to specifically point NGINX Amplify Agent to either the NGINX configuration or the NGINX log files — it should detect their location automatically. -NGINX Amplify Agent will also try to detect the [log format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for a particular log to parse it properly and try to extract even more useful metrics, e.g., [$upstream_response_time](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_response_time). +NGINX Amplify Agent will also try to detect the [log format](http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) for a particular log to parse it properly and try to extract even more useful metrics, for example, [$upstream_response_time](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#var_upstream_response_time). {{< note >}}Several metrics outlined in [Metrics and Metadata]({{< ref "metrics-metadata" >}}) will only be available if the corresponding variables are included in a custom [access.log](http://nginx.org/en/docs/http/ngx_http_log_module.html) format used for logging requests. You can find a complete list of NGINX log variables [here](http://nginx.org/en/docs/varindex.html).{{< /note >}} diff --git a/content/amplify/nginx-amplify-agent/metadata-metrics-collection.md b/content/amplify/nginx-amplify-agent/metadata-metrics-collection.md index c95335a6c..0263c68f6 100644 --- a/content/amplify/nginx-amplify-agent/metadata-metrics-collection.md +++ b/content/amplify/nginx-amplify-agent/metadata-metrics-collection.md @@ -9,7 +9,7 @@ docs: DOCS-964 F5 NGINX Amplify Agent collects the following types of data: * **NGINX metrics.** NGINX Amplify Agent collects a lot of NGINX related metrics from [stub_status](http://nginx.org/en/docs/http/ngx_http_stub_status_module.html), the NGINX Plus status API, the NGINX log files, and from the NGINX process state. - * **System metrics.** These are various key metrics describing the system, e.g., CPU usage, memory usage, network traffic, etc. + * **System metrics.** These are various key metrics describing the system, for example, CPU usage, memory usage, network traffic, etc. * **PHP-FPM metrics.** NGINX Amplify Agent can obtain metrics from the PHP-FPM pool status if it detects a running PHP-FPM main process. * **MySQL metrics.** NGINX Amplify Agent can obtain metrics from the MySQL global status set of variables. * **NGINX metadata.** This is what describes your NGINX instances, and it includes package data, build information, the path to the binary, build configuration options, etc. NGINX metadata also includes the NGINX configuration elements. diff --git a/content/amplify/user-interface/account-settings.md b/content/amplify/user-interface/account-settings.md index 9c8bdb3b5..bef423f0b 100644 --- a/content/amplify/user-interface/account-settings.md +++ b/content/amplify/user-interface/account-settings.md @@ -26,7 +26,7 @@ Users can be assigned one of the three roles — Admin, User, or Read-Only. Admi In the **Notifications** section, you will find information about the emails currently registered with your account and whether they are verified or not. The alert notifications are only sent to verified emails. -In addition to the email alert notifications, you can optionally configure the integration with your Slack team and workspace. Under the registered emails section, select the "Add to Slack" button to allow Amplify to send you certain notifications on Slack. You will have to log in and provide the necessary details about your team and what channels you'd like to add to Amplify notifications. Both direct messages and channels can be used for notifications. If configured successfully, Amplify can send alert information to Slack. A few more additional notifications are available — e.g., F5 NGINX Amplify Agent not finding a running NGINX instance, but also proactive messages about the issues with the SSL certs. +In addition to the email alert notifications, you can optionally configure the integration with your Slack team and workspace. Under the registered emails section, select the "Add to Slack" button to allow Amplify to send you certain notifications on Slack. You will have to log in and provide the necessary details about your team and what channels you'd like to add to Amplify notifications. Both direct messages and channels can be used for notifications. If configured successfully, Amplify can send alert information to Slack. A few more additional notifications are available — for example, F5 NGINX Amplify Agent not finding a running NGINX instance, but also proactive messages about the issues with the SSL certs. {{< img src="amplify/amplify-notifications.png" alt="Notifications" >}} diff --git a/content/amplify/user-interface/analyzer.md b/content/amplify/user-interface/analyzer.md index 9b011311f..054790cdd 100644 --- a/content/amplify/user-interface/analyzer.md +++ b/content/amplify/user-interface/analyzer.md @@ -37,14 +37,14 @@ The following information is provided when a report is generated from an NGINX c * Typical configuration issues highlighted * Common advice about proxy configurations * Suggestions about simplifying rewrites for certain use cases - * Key security measures (e.g., *stub_status* is unprotected) + * Key security measures (for example, *stub_status* is unprotected) * Typical errors in configuring locations, especially with *regex* To parse SSL certificate metadata, NGINX Amplify Agent uses standard OpenSSL(1) functions. SSL certificates are parsed and analyzed only when the corresponding [settings]({{< ref "/amplify/user-interface/account-settings" >}}) are turned on. SSL certificate analysis is *off* by default. Static analysis will only include information about specific issues with the NGINX configuration if those are found in your NGINX setup. -In the future, the **Analyzer** page will also include *dynamic analysis*, effectively linking the observed NGINX behavior to its configuration — e.g., when it makes sense to increase or decrease certain parameters like [proxy_buffers](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers), etc. +In the future, the **Analyzer** page will also include *dynamic analysis*, effectively linking the observed NGINX behavior to its configuration — for example, when it makes sense to increase or decrease certain parameters like [proxy_buffers](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers), etc. {{< note >}} Config analysis is *on* by default. If you don't want your NGINX configuration to be checked, unset the corresponding setting in either Global, or Local (per-system) settings. See [**Settings**]({{< ref "/amplify/user-interface/account-settings" >}}). {{< /note >}} diff --git a/content/amplify/user-interface/dashboards.md b/content/amplify/user-interface/dashboards.md index 3b6167309..eef3fcd73 100644 --- a/content/amplify/user-interface/dashboards.md +++ b/content/amplify/user-interface/dashboards.md @@ -35,14 +35,14 @@ To define a graph, perform these steps: 2. Pick one or more metrics. You can combine multiple metrics on the same graph using the "Add another metric" button. 3. After the metric is selected, you can see the systems for which the metric has been observed. Select one or multiple systems here. You can also use tags to specify the systems. 4. When aggregating across multiple systems, select either "Sum" or "Avg" as the aggregation function. - 5. Last but not least, the “filter” functionality is also available for NGINX metrics collected from the log files. If you select "Add metric filter", you can add multiple criteria to define specific "metric dimensions". In the example above, we are matching the NGINX upstream response time against the **/api/feed/reports** URI. You can also build other filters, e.g., displaying metric **nginx.http.status.2xx** for the responses with the status code 201. + 5. Last but not least, the “filter” functionality is also available for NGINX metrics collected from the log files. If you select "Add metric filter", you can add multiple criteria to define specific "metric dimensions". In the example above, we are matching the NGINX upstream response time against the **/api/feed/reports** URI. You can also build other filters, for example, displaying metric **nginx.http.status.2xx** for the responses with the status code 201. 6. Select "Save" to add the graph to the dashboard. You can also edit the graph, move it around, resize it, stack the graphs on top of each other, etc. {{< note >}} When using filters, all the "metric dimensions" aren't stored in the F5 NGINX Amplify backend by default. A particular filter starts to slice the metric according to the specification only after the graph is created. Hence, it can be a while before the "filtered" metric is displayed on the graph — the end result depends on how quickly the log files are being populated with the new entries, but typically you should see the first data points in under 5 minutes. {{< /note >}} Because NGINX Amplify is **not** a SaaS log analyzer, the additional slicing for "metric dimensions" is implemented inside NGINX Amplify Agent. NGINX Amplify Agent can parse the NGINX access logs on-the-fly and extract all the necessary metrics **without** sending the raw log entries elsewhere. Moreover, NGINX Amplify Agent understands custom log formats automatically, and will start looking for various newly defined "metric dimensions" following a particular [log_format](https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format) specification. -Essentially, NGINX Amplify Agent performs a combination of real-time log analytics and standard metrics collection (e.g., metrics from the *stub_status* module). NGINX Amplify Agent does only the **real-time log processing**, and always on the same host where it is running. +Essentially, NGINX Amplify Agent performs a combination of real-time log analytics and standard metrics collection (for example, metrics from the *stub_status* module). NGINX Amplify Agent does only the **real-time log processing**, and always on the same host where it is running. Metric filters can be really powerful. By using the filters and creating additional "metric dimensions", it is possible to build highly granular and informative graphs. To enable NGINX Amplify Agent to slice the metrics you must add the corresponding log variables to the active NGINX log format. Please see the [Additional NGINX metrics]({{< ref "/amplify/metrics-metadata/nginx-metrics#additional-nginx-metrics" >}}) section below. diff --git a/content/amplify/user-interface/overview.md b/content/amplify/user-interface/overview.md index a797c8c77..5fbb45d7e 100644 --- a/content/amplify/user-interface/overview.md +++ b/content/amplify/user-interface/overview.md @@ -20,7 +20,7 @@ The cumulative [metrics]({{< ref "/amplify/metrics-metadata" >}}) displayed on t {{< note >}} By default the metrics above are calculated for all monitored hosts. You can configure specific tags in the **Overview** settings popup to display the metrics for a set of hosts (e.g. only the "production environment"). {{< /note >}} -You may see zero numbers if some metrics are not being gathered, e.g., if the request time (P95) is 0.000s, please check that you have correctly configured NGINX log for [additional metric]() collection. +You may see zero numbers if some metrics are not being gathered, for example, if the request time (P95) is 0.000s, please check that you have correctly configured NGINX log for [additional metric]() collection. {{< img src="amplify/amplify-overview.png" alt="Overview section of the User Interface" >}} diff --git a/content/controller/releases/release-notes.md b/content/controller/releases/release-notes.md index 13feddc5b..f5d74c780 100644 --- a/content/controller/releases/release-notes.md +++ b/content/controller/releases/release-notes.md @@ -1274,7 +1274,7 @@ Refer to the [NGINX Controller Tech Specs]({{< ref "/controller/admin-guides/ins - **After enabling WAF, security violations aren't reported right away (10558)** - When an App Component is initially enabled with WAF, there may be a few seconds where Security Events (that is, WAF violation events) are not mapped to the correct App Component and App. The following warning message is logged in `/var/log/nginx-controller/security-events-mgr.log`: *"Generating event without app-centric dimensions (i.e., app, component, environment, gateway, correlationId)."* + When an App Component is initially enabled with WAF, there may be a few seconds where Security Events (that is, WAF violation events) are not mapped to the correct App Component and App. The following warning message is logged in `/var/log/nginx-controller/security-events-mgr.log`: *"Generating event without app-centric dimensions (that is, app, component, environment, gateway, correlationId)."* - **Security events not mapped to App or App Component if combined length of resource IDs exceeds 445 characters (11112)** diff --git a/content/includes/nap-waf/config/common/grpc-content-profiles.md b/content/includes/nap-waf/config/common/grpc-content-profiles.md index 23f7d711a..2f5ec344c 100644 --- a/content/includes/nap-waf/config/common/grpc-content-profiles.md +++ b/content/includes/nap-waf/config/common/grpc-content-profiles.md @@ -92,7 +92,7 @@ The definitions of `OperationResult` and `Condition` messages are in the importe The profile in this example enables checking of attack signatures and disallowed metacharacters in the string-typed fields within the service messages. Two signatures are disabled. The profile also limits the size of the messages to 100KB and disallows fields that are not defined in the IDL files. -The main IDL file, `album.proto` is marked as `primary`. The file it imports, `messages.proto`, is marked as secondary, i.e., `isPrimary` is `false` and so should be any imported file. In order for App Protect to be able to match it to the import statement, the file location should be specified as done in the example above using the `importUrl` property. +The main IDL file, `album.proto` is marked as `primary`. The file it imports, `messages.proto`, is marked as secondary, that is, `isPrimary` is `false` and so should be any imported file. In order for App Protect to be able to match it to the import statement, the file location should be specified as done in the example above using the `importUrl` property. An alternative and probably more convenient way to specify all the IDL files, the primary and all its imports, direct and indirect, is to bundle them into a single tar file in the same directory structure as they are expected by the import statements. In this case, you will have to specify which of the files in the tarball is the primary one. The supported formats are `tar` and `tgz`. App Protect will identify the file type automatically (tar, gzipped tar, or JSON) and handle it accordingly. Following the above example: diff --git a/content/includes/nap-waf/config/common/json-web-token-overview.md b/content/includes/nap-waf/config/common/json-web-token-overview.md index 3dca981c3..9e5ee5741 100644 --- a/content/includes/nap-waf/config/common/json-web-token-overview.md +++ b/content/includes/nap-waf/config/common/json-web-token-overview.md @@ -39,7 +39,7 @@ In example above, the payload contains several claims: - nbf (Not Before) - Specifies the time before which the token should not be considered valid. -- exp (Expiration Time) - Specifies the expiration time of the token. It is represented as a numeric timestamp (e.g., 1654608348), and the token is considered invalid after this time. +- exp (Expiration Time) - Specifies the expiration time of the token. It is represented as a numeric timestamp (for example, 1654608348), and the token is considered invalid after this time. These claims provide information about the JWT and can be used by the recipient to verify the token's authenticity and determine its validity. Additionally, you can include custom claims in the payload to carry additional information specific to your application. diff --git a/content/includes/nap-waf/config/common/signature-sets.md b/content/includes/nap-waf/config/common/signature-sets.md index a7f9757b5..4afb8fe65 100644 --- a/content/includes/nap-waf/config/common/signature-sets.md +++ b/content/includes/nap-waf/config/common/signature-sets.md @@ -289,7 +289,7 @@ The table below lists all the available Server Technologies. Some of them are bu |Elasticsearch | Elasticsearch is a search engine based on Lucene. | | Yes | |Apache Struts | Apache Struts is an open source web application framework for developing Java EE web applications. | Java Servlets/JSP | Yes | |XML | Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. | | Yes | -|PostgreSQL | PostgreSQL, often simply Postgres, is an object-relational database (ORDBMS) - i.e., an RDBMS, with additional (optional use) \"object\" features - with an emphasis on extensibility and standards-compliance. | | Yes | +|PostgreSQL | PostgreSQL, often simply Postgres, is an object-relational database (ORDBMS) - that is, an RDBMS, with additional (optional use) \"object\" features - with an emphasis on extensibility and standards-compliance. | | Yes | |IBM DB2 | IBM DB2 contains database server products developed by IBM. | | Yes | |Sybase/ASE | SAP ASE (Adaptive Server Enterprise), originally known as Sybase SQL Server, and also commonly known as Sybase DB or ASE, is a relational model database server product for businesses developed by Sybase Corporation which became part of SAP AG. | | Yes | |CGI | Common Gateway Interface (CGI) offers a standard protocol for web servers to interface with executable programs running on a server that generate web pages dynamically. | | Yes | diff --git a/content/nap-dos/directives-and-policy/learn-about-directives-and-policy.md b/content/nap-dos/directives-and-policy/learn-about-directives-and-policy.md index 39704ee99..2d018750a 100644 --- a/content/nap-dos/directives-and-policy/learn-about-directives-and-policy.md +++ b/content/nap-dos/directives-and-policy/learn-about-directives-and-policy.md @@ -153,7 +153,7 @@ Monitor directive has four arguments - **uri**, **protocol**, **timeout** and ** - **URI** - The URI of the Protected Object as defined in the `nginx.conf`. This must point to a location block that proxies traffic to the backend (upstream) to ensure accurate monitoring.
Format: **scheme://server_name:port/location**. - {{< note >}}For gRPC, the URI must specify a valid gRPC method (e.g., /RouteGuide/GetFeature).
+ {{< note >}}For gRPC, the URI must specify a valid gRPC method (for example, /RouteGuide/GetFeature).
The health check is not a true gRPC client, so its requests do not conform to the gRPC wire protocol. As a result, the backend responds with grpc-status: 12 (UNIMPLEMENTED), which is expected and treated as a successful health check. Regular gRPC client traffic is unaffected by this behavior.{{< /note >}} - **Protocol** - determines the protocol type of the service. Options are `http1 / http2 / grpc / websocket`.
Default: `http1`.
@@ -212,7 +212,7 @@ server_name my_grpc; location /routeguide. { # Protected Object is defined here - # Note: The URI must include a valid gRPC method (e.g., /routeguide.RouteGuide/GetFeature). + # Note: The URI must include a valid gRPC method (for example, /routeguide.RouteGuide/GetFeature). # The health check will expect a grpc-status of 12 (UNIMPLEMENTED) because it is not a true gRPC client. app_protect_dos_monitor uri=http://my_grpc:50051/routeguide.RouteGuide/GetFeature protocol=grpc; } diff --git a/content/nap-waf/v4/logging-overview/security-log.md b/content/nap-waf/v4/logging-overview/security-log.md index 905ecff57..d0211d06a 100644 --- a/content/nap-waf/v4/logging-overview/security-log.md +++ b/content/nap-waf/v4/logging-overview/security-log.md @@ -100,7 +100,7 @@ The filter is mandatory, although it may be left blank. |Element | Meaning | Type/Values | Default | | ---| ---| ---| --- | -|request_type | Log according to what App Protect detected in the request. | Enumerated values: | all | +|request_type | Log according to what App Protect detected in the request. | Enumerated values: | all | {{}} @@ -255,7 +255,7 @@ NGINX will provide example configuration files under /opt/app_protect/share/defa ### Available Security Log Attributes -The table below lists attributes that are generated in the security logs. When using customized logs (i.e., format=user-defined), you can add or remove entries from the list below. Per each attribute we show whether it is included in each of the predefined formats: `default` and `grpc`. +The table below lists attributes that are generated in the security logs. When using customized logs (that is, format=user-defined), you can add or remove entries from the list below. Per each attribute we show whether it is included in each of the predefined formats: `default` and `grpc`. @@ -304,7 +304,7 @@ The table below lists attributes that are generated in the security logs. When u |uri | The URI or Uniform Resource Identifier of the request. | default, grpc | |violation_details | XML including details about each violation. | default, grpc | |violation_rating | Estimation of the likelihood that the request is indeed a threat on a scale of 0 to 5: 0 - not a threat (no violations), 5 - most likely a threat | default, grpc | -|violations | Comma-separated list of logical violation names (e.g., `VIOL_ATTACK_SIGNATURES`, `VIOL_HTTP_PROTOCOL`). | default, grpc | +|violations | Comma-separated list of logical violation names (for example, `VIOL_ATTACK_SIGNATURES`, `VIOL_HTTP_PROTOCOL`). | default, grpc | |vs_name | A unique identifier of the location in the nginx.conf file that this request is associated with. It contains the line number of the containing server block in nginx.conf, the server name, a numeric discriminator that distinguishes between multiple entries within the same server, and the location name. For example: ’34-mydomain.com:0-~/.*php(2). | default, grpc | |x_forwarded_for_header_value | `X-Forwarded-For` header information. This option is commonly used when proxies are involved to track the originator of the request. | default, grpc | diff --git a/content/nap-waf/v5/logging-overview/security-log.md b/content/nap-waf/v5/logging-overview/security-log.md index d0af14d78..e23f281c1 100644 --- a/content/nap-waf/v5/logging-overview/security-log.md +++ b/content/nap-waf/v5/logging-overview/security-log.md @@ -89,7 +89,7 @@ The filter is mandatory, although it may be left blank. {{}} |Element | Meaning | Type/Values | Default | | ---| ---| ---| --- | -|request_type | Log according to what App Protect detected in the request. | Enumerated values: | all | +|request_type | Log according to what App Protect detected in the request. | Enumerated values: | all | {{}} @@ -240,7 +240,7 @@ NGINX will provide example configuration files under /opt/app_protect/share/defa ### Available Security Log Attributes -The table below lists attributes that are generated in the security logs. When using customized logs (i.e., format=user-defined), you can add or remove entries from the list below. Per each attribute we show whether it is included in each of the predefined formats: `default` and `grpc`. +The table below lists attributes that are generated in the security logs. When using customized logs (that is, format=user-defined), you can add or remove entries from the list below. Per each attribute we show whether it is included in each of the predefined formats: `default` and `grpc`. {{}} |Attribute Name | Description | Included in formats | @@ -286,7 +286,7 @@ The table below lists attributes that are generated in the security logs. When u |uri | The URI or Uniform Resource Identifier of the request. | default, grpc | |violation_details | XML including details about each violation. | default, grpc | |violation_rating | Estimation of the likelihood that the request is indeed a threat on a scale of 0 to 5: 0 - not a threat (no violations), 5 - most likely a threat | default, grpc | -|violations | Comma-separated list of logical violation names (e.g., `VIOL_ATTACK_SIGNATURES`, `VIOL_HTTP_PROTOCOL`). | default, grpc | +|violations | Comma-separated list of logical violation names (for example, `VIOL_ATTACK_SIGNATURES`, `VIOL_HTTP_PROTOCOL`). | default, grpc | |vs_name | A unique identifier of the location in the nginx.conf file that this request is associated with. It contains the line number of the containing server block in nginx.conf, the server name, a numeric discriminator that distinguishes between multiple entries within the same server, and the location name. For example: ’34-mydomain.com:0-~/.*php(2). | default, grpc | |x_forwarded_for_header_value | `X-Forwarded-For` header information. This option is commonly used when proxies are involved to track the originator of the request. | default, grpc | {{}} diff --git a/content/ngf/how-to/data-plane-configuration.md b/content/ngf/how-to/data-plane-configuration.md index f69911b3b..1ffb7a17a 100644 --- a/content/ngf/how-to/data-plane-configuration.md +++ b/content/ngf/how-to/data-plane-configuration.md @@ -183,7 +183,7 @@ The choice of mode depends on how the load balancer fronting NGINX Gateway Fabri **TrustedAddresses** are used to specify the IP addresses of the trusted proxies that pass the request. These can be in the form of CIDRs, IPs, or hostnames. For example, if a load balancer is forwarding the request to NGINX Gateway Fabric, the IP address of the load balancer should be specified in the `trustedAddresses` list to inform NGINX that the forwarded request is from a known source. -**SetIPRecursively** is a boolean field used to enable recursive search when selecting the client's address from a multi-value header. It is applicable in cases where we have a multi-value header containing client IPs to select from, i.e., when using `XForwardedFor` mode. +**SetIPRecursively** is a boolean field used to enable recursive search when selecting the client's address from a multi-value header. It is applicable in cases where we have a multi-value header containing client IPs to select from, that is, when using `XForwardedFor` mode. The following command creates an `NginxProxy` resource with `RewriteClientIP` settings that set the mode to ProxyProtocol and sets a CIDR in the list of trusted addresses to find the original client IP address. diff --git a/content/nim/admin-guide/authentication/oidc/getting-started.md b/content/nim/admin-guide/authentication/oidc/getting-started.md index 1ca092e8e..fc3dc9901 100644 --- a/content/nim/admin-guide/authentication/oidc/getting-started.md +++ b/content/nim/admin-guide/authentication/oidc/getting-started.md @@ -89,8 +89,8 @@ The sections below provide detailed descriptions of the OIDC configuration value - **$oidc_logout_endpoint**: The URL of the IdP’s end_session endpoint. - **$oidc_token_endpoint**: The URL of the IdP’s OAuth 2.0 Token endpoint. - **$oidc_userinfo_endpoint**: The URL of the IdP’s UserInfo endpoint. -- **$oidc_host**: The URL of the IdP’s application (e.g., `https://{my-app}.okta.com`). -- **$oidc_scopes**: List of OAuth 2.0 scope values supported by the server (e.g., `openid+profile+email+offline_access`). +- **$oidc_host**: The URL of the IdP’s application (for example, `https://{my-app}.okta.com`). +- **$oidc_scopes**: List of OAuth 2.0 scope values supported by the server (for example, `openid+profile+email+offline_access`). #### Custom configuration for well-known endpoints diff --git a/content/nim/admin-guide/authentication/oidc/microsoft-entra-automation.md b/content/nim/admin-guide/authentication/oidc/microsoft-entra-automation.md index 27314f6ad..cb77e112b 100644 --- a/content/nim/admin-guide/authentication/oidc/microsoft-entra-automation.md +++ b/content/nim/admin-guide/authentication/oidc/microsoft-entra-automation.md @@ -14,7 +14,7 @@ This guide explains how to secure NGINX Instance Manager with OpenID Connect (OI ## Before you begin {{}} -Before proceeding, first secure NGINX Instance Manager with OpenID Connect (OIDC) using Microsoft Entra as the identity provider. Complete the steps in the [Set up OIDC authentication with Microsoft Entra]({{< ref "/nim/admin-guide/authentication/oidc/microsoft-entra-setup.md" >}}) guide. Afterward, you'll have a registered application (e.g., "NGINX Instance Manager") in Microsoft Entra, as well as a client ID and secret to configure automation. +Before proceeding, first secure NGINX Instance Manager with OpenID Connect (OIDC) using Microsoft Entra as the identity provider. Complete the steps in the [Set up OIDC authentication with Microsoft Entra]({{< ref "/nim/admin-guide/authentication/oidc/microsoft-entra-setup.md" >}}) guide. Afterward, you'll have a registered application (for example, "NGINX Instance Manager") in Microsoft Entra, as well as a client ID and secret to configure automation. {{}} ## Configure Azure @@ -26,7 +26,7 @@ Before proceeding, first secure NGINX Instance Manager with OpenID Connect (OIDC 3. In the left navigation menu, under **Manage**, select **App registrations**. 4. Select **New registration**. 5. Complete the following: - - In the **Name** field, enter the name of the application (e.g., "Automation"). + - In the **Name** field, enter the name of the application (for example, "Automation"). - Select **Accounts in this organizational directory only** for account types. - Leave **Redirect URI** blank. 6. Select **Register**. @@ -46,7 +46,7 @@ Before proceeding, first secure NGINX Instance Manager with OpenID Connect (OIDC 1. In the left navigation menu, under **Manage**, select **App roles**. 2. Select **Create app role**. 3. Fill in the role details. Use the information from an existing user group in NGINX Instance Manager, such as from the [Create user groups in Instance Manager]({{< ref "/nim/admin-guide/authentication/oidc/microsoft-entra-setup.md#create-user-groups-in-nginx-instance-manager" >}}) step: - - In the **Display name** field, enter a role name (e.g., "Admin"). + - In the **Display name** field, enter a role name (for example, "Admin"). - In **Allowed member types**, select **Applications**. - In the **Value** field, enter the value for the role. This must match the user group in NGINX Management Suite. - Provide a description for the role. @@ -54,12 +54,12 @@ Before proceeding, first secure NGINX Instance Manager with OpenID Connect (OIDC ### Assign the app role to the application -1. On the **App registrations** page, select the first application you created (e.g., "Instance Manager"). +1. On the **App registrations** page, select the first application you created (for example, "Instance Manager"). 2. In the left navigation menu, under **Manage**, select **API permissions**. 3. Select **Add a permission**. 4. In the **Request API permissions** section, select **My APIs**. -5. Select the app name you created for automation (e.g., "Automation"). -6. Under **Application permissions**, select the role you created earlier (e.g., "Admin"). +5. Select the app name you created for automation (for example, "Automation"). +6. Under **Application permissions**, select the role you created earlier (for example, "Admin"). 7. Select **Add permissions**. {{< note >}}If the permission is not granted, contact your Microsoft Entra administrator to approve it.{{< /note >}} @@ -115,7 +115,7 @@ Additionally, complete the following steps: 2. Include the following in your request body: - `client_id`: The client ID of the application you created. - `client_secret`: The client secret for the application. - - `scope`: The application scope (e.g., `api:///.default`). + - `scope`: The application scope (for example, `api:///.default`). - `grant_type`: Use `client_credentials`. 3. The response will contain an access token. Decoding the token should give you a result similar to: diff --git a/content/nim/system-configuration/configure-high-availability.md b/content/nim/system-configuration/configure-high-availability.md index e36f11d78..183288d10 100644 --- a/content/nim/system-configuration/configure-high-availability.md +++ b/content/nim/system-configuration/configure-high-availability.md @@ -129,7 +129,7 @@ vrrp_instance VI_28 { ``` Replace: -- `` with your actual network interface (e.g., `ens32`). +- `` with your actual network interface (for example, `ens32`). - `` with a secure authentication password. - `` with your reserved VIP. diff --git a/content/nim/system-configuration/configure-with-config.md b/content/nim/system-configuration/configure-with-config.md index b0ac6f2ee..87f54ba33 100644 --- a/content/nim/system-configuration/configure-with-config.md +++ b/content/nim/system-configuration/configure-with-config.md @@ -132,7 +132,7 @@ integrations: attack_signatures_ttl: 336h # Time to live for compiled bundles, this includes compiled security policies and compiled log profiles. If a compiled # bundle exceeds its TTL and is not deployed to an instance or instance group, it will be deleted from the database. Note - # that the compiled bundle is deleted, not the definition of it (i.e., the security policy or log profile definition). + # that the compiled bundle is deleted, not the definition of it (that is, the security policy or log profile definition). # Duration unit can be seconds (s), minutes (m), or hours (h). compiled_bundles_ttl: 336h # Time to live for threat campaigns. If the threat campaigns exceed their TTL and are not deployed to an instance or diff --git a/content/nms/nginx-agent/install-nginx-agent.md b/content/nms/nginx-agent/install-nginx-agent.md index 279f2dcd9..0660ed391 100644 --- a/content/nms/nginx-agent/install-nginx-agent.md +++ b/content/nms/nginx-agent/install-nginx-agent.md @@ -311,7 +311,7 @@ If you are upgrading from an older version, update your configuration accordingl | `--features` | `NGINX_AGENT_FEATURES` | Specifies a comma-separated list of features enabled for the agent. Default: *[registration, nginx-config-async, nginx-ssl-config, nginx-counting, metrics, dataplane-status, process-watcher, file-watcher, activity-events, agent-api]* | | `--ignore-directives` | | Specifies a comma-separated list of directives to ignore for sensitive info.| | `--instance-group` | `NGINX_AGENT_INSTANCE_GROUP` | Sets the instance's group value. | -| `--log-level` | `NGINX_AGENT_LOG_LEVEL` | Sets the logging level (e.g., panic, fatal, error, info, debug, trace). Default: *info* | +| `--log-level` | `NGINX_AGENT_LOG_LEVEL` | Sets the logging level (for example, panic, fatal, error, info, debug, trace). Default: *info* | | `--log-path` | `NGINX_AGENT_LOG_PATH` | Specifies the path to output log messages. | | `--metrics-bulk-size` | `NGINX_AGENT_METRICS_BULK_SIZE` | Specifies the number of metrics reports collected before sending data. Default: *20* | | `--metrics-collection-interval` | `NGINX_AGENT_METRICS_COLLECTION_INTERVAL` | Sets the interval for metrics collection. Default: *15s* |