Skip to content

Commit 70e1028

Browse files
authored
Merge branch 'main' into patch-1
2 parents 77d823f + 1c0e789 commit 70e1028

File tree

9 files changed

+151
-79
lines changed

9 files changed

+151
-79
lines changed

content/ngf/overview/gateway-api-compatibility.md

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -174,7 +174,6 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
174174
- `Accepted/False/NotAllowedByListeners`
175175
- `Accepted/False/UnsupportedValue`: Custom reason for when the HTTPRoute includes an invalid or unsupported value.
176176
- `Accepted/False/InvalidListener`: Custom reason for when the HTTPRoute references an invalid listener.
177-
- `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. HTTPRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
178177
- `Accepted/False/GatewayIgnored`: Custom reason for when the Gateway is ignored by NGINX Gateway Fabric. NGINX Gateway Fabric only supports one Gateway.
179178
- `ResolvedRefs/True/ResolvedRefs`
180179
- `ResolvedRefs/False/InvalidKind`
@@ -220,7 +219,6 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
220219
- `Accepted/False/NotAllowedByListeners`
221220
- `Accepted/False/UnsupportedValue`: Custom reason for when the GRPCRoute includes an invalid or unsupported value.
222221
- `Accepted/False/InvalidListener`: Custom reason for when the GRPCRoute references an invalid listener.
223-
- `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. GRPCRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
224222
- `ResolvedRefs/True/ResolvedRefs`
225223
- `ResolvedRefs/False/InvalidKind`
226224
- `ResolvedRefs/False/RefNotPermitted`
@@ -275,7 +273,6 @@ Fields:
275273
- `Accepted/False/NotAllowedByListeners`
276274
- `Accepted/False/UnsupportedValue`: Custom reason for when the TLSRoute includes an invalid or unsupported value.
277275
- `Accepted/False/InvalidListener`: Custom reason for when the TLSRoute references an invalid listener.
278-
- `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. TLSRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
279276
- `Accepted/False/HostnameConflict`: Custom reason for when the TLSRoute has a hostname that conflicts with another TLSRoute on the same port.
280277
- `ResolvedRefs/True/ResolvedRefs`
281278
- `ResolvedRefs/False/InvalidKind`

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

Lines changed: 32 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -9,11 +9,33 @@ type:
99
- how-to
1010
---
1111

12-
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.
12+
NGINX and NGINX Plus use a text‑based configuration file, by default named **nginx.conf**.
1313

14-
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`.
14+
NGINX Plus: default location is `/etc/nginx` for Linux or `/usr/local/etc/nginx` for FreeBSD.
15+
16+
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`.
17+
18+
You can verify the exact configuration file path with the `--conf-path=` parameter in the output of the `nginx -V` command:
19+
20+
```shell
21+
nginx -V 2>&1 | awk -F: '/configure arguments/ {print $2}' | xargs -n1
22+
```
23+
24+
Sample output:
25+
26+
```none
27+
--prefix=/etc/nginx
28+
--sbin-path=/usr/sbin/nginx
29+
--modules-path=/usr/lib64/nginx/modules
30+
--conf-path=/etc/nginx/nginx.conf # The path to your config file
31+
--error-log-path=/var/log/nginx/error.log
32+
--http-log-path=/var/log/nginx/access.log
33+
--pid-path=/var/run/nginx.pid
34+
--...<more parameters>
35+
```
1536

1637
## Directives
38+
1739
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.
1840

1941
```nginx
@@ -22,9 +44,9 @@ error_log logs/error.log notice;
2244
worker_processes 1;
2345
```
2446

25-
## Feature-Specific Configuration Files
47+
## Feature-specific configuration files
2648

27-
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.
49+
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.
2850

2951
```nginx
3052
include conf.d/http;
@@ -43,14 +65,15 @@ A few top‑level directives, referred to as _contexts_, group together the dire
4365

4466
Directives placed outside of these contexts are said to be in the _main_ context.
4567

46-
### Virtual Servers
68+
### Virtual servers
69+
4770
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.
4871

4972
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.
5073

5174
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.
5275

53-
### Sample Configuration File with Multiple Contexts
76+
### Sample configuration file with multiple contexts
5477

5578
The following configuration illustrates the use of contexts.
5679

@@ -89,10 +112,10 @@ stream {
89112

90113
### Inheritance
91114

92-
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.
115+
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.
93116

94-
## Reload Configuration File
117+
## Reload configuration file
95118

96119
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" >}}).
97120

98-
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" >}}).
121+
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/admin-guide/installing-nginx/installing-nginx-plus.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -294,7 +294,7 @@ NGINX Plus can be installed on the following versions of Debian or Ubuntu:
294294
295295
1. {{< include "nginx-plus/install/check-nginx-binary-version.md" >}}
296296
297-
1. {{< include "nginx-plus/install/configure-usage-reporting.md" >}}
297+
1. Make sure license reporting to F5 licensing endpoint is configured. By default, no configuration is required. However, it becomes necessary when NGINX Plus is installed in a disconnected environment, uses NGINX Instance Manager for usage reporting, or uses a custom path for the license file. Configuration can be done in the [`mgmt {}`](https://nginx.org/en/docs/ngx_mgmt_module.html) block of the NGINX Plus configuration file (`/usr/local/etc/nginx/nginx.conf`). For more information, see [About Subscription Licenses](https://docs.nginx.com/solutions/about-subscription-licenses/).
298298
299299
1. {{< include "nginx-plus/install/install-nginx-agent-for-nim.md" >}}
300300
@@ -398,7 +398,7 @@ NGINX Plus can be installed on the following versions of Debian or Ubuntu:
398398
399399
1. {{< include "nginx-plus/install/install-nginx-agent-for-nim.md" >}}
400400
401-
## Install Dynamically Loadable Modules {#install_modules}
401+
## Install dynamically loadable modules {#install_modules}
402402
403403
NGINX Plus functionality can be extended with dynamically loadable modules. They can be added or updated independently of the core binary, enabling powerful capabilities such as advanced security, traffic shaping, telemetry, embedded scripting, geolocation, and many more.
404404
@@ -515,7 +515,7 @@ After installing the module, you will need to:
515515
- enable it with the [`load_module`](https://nginx.org/en/docs/ngx_core_module.html#load_module) directive
516516
- configure it according to the module's documentation
517517
518-
### Enabling Dynamic Modules {#enable_dynamic}
518+
### Enabling dynamic modules {#enable_dynamic}
519519
520520
To enable a dynamic module:
521521
@@ -694,7 +694,7 @@ For a community dynamic module to work with NGINX Plus, it must be compiled alo
694694
695695
After installing the module, you need to enable it in the NGINX Plus configuration file. For more information, see [Enabling Dynamic Modules](#enable_dynamic).
696696
697-
## NGINX Plus Unprivileged Installation {#unpriv_install}
697+
## NGINX Plus unprivileged installation {#unpriv_install}
698698
699699
In some environments, access to the root account is restricted for security reasons. On Linux systems, this limitation prevents the use of package managers to install NGINX Plus without root privileges.
700700
@@ -787,7 +787,7 @@ With this script, you can also upgrade an existing unprivileged installation of
787787
./ngxunprivinst.sh upgrade [-y] -p <path> <file1.rpm> <file2.rpm>
788788
```
789789
790-
## NGINX Plus Offline Installation {#offline_install}
790+
## NGINX Plus offline installation {#offline_install}
791791
792792
This section explains how to install NGINX Plus and its [dynamic modules]({{< ref "/nginx/admin-guide/dynamic-modules/dynamic-modules.md" >}}) on a server with limited or no Internet access.
793793
@@ -982,7 +982,7 @@ To upgrade your NGINX Plus installation to the newest version:
982982
nginx version: nginx/1.29.0 (nginx-plus-r35)
983983
```
984984
985-
## Upgrade NGINX Plus Modules {#upgrade_modules}
985+
## Upgrade NGINX Plus modules {#upgrade_modules}
986986
987987
The upgrade procedure depends on how the module was supplied and installed.
988988
@@ -992,7 +992,7 @@ The upgrade procedure depends on how the module was supplied and installed.
992992
993993
- [Community](#community-dynamic-modules) dynamic modules must be recompiled against the corresponding NGINX Open Source version. See [Installing NGINX Community Modules](#install_modules_oss).
994994
995-
## Explore Related Topics
995+
## Explore related topics
996996
997997
### Install NGINX App Protect
998998

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

Lines changed: 33 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -24,36 +24,42 @@ Some industries such as finance, healthcare, energy, also adopt FIPS to enhance
2424

2525
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.
2626

27-
{{<bootstrap-table "table table-striped table-bordered table-sm">}}
28-
| **Program/Regulation/Industry** | **FIPS 140-2/140-3 Requirement** | **Current Status** |
29-
|---------------------------------|----------------------------------|---------------------------------------------------------------------|
30-
| CJIS | 140-2 or 140-3 | FIPS required for systems protecting criminal justice data. |
31-
| CMMC | 140-2 or 140-3 | FIPS required for Levels 2 and 3 compliance. |
32-
| Common Criteria | 140-2 or 140-3 | Evaluations reference both FIPS versions for cryptographic security. |
33-
| Critical Infrastructure | 140-2 or 140-3 | Utilities and systems accept both versions depending on deployments. |
34-
| Department of Veterans Affairs| 140-2 or 140-3 | Both versions used for securing sensitive health and personal data. |
35-
| DFARS | 140-2 or 140-3 | Cryptographic modules for CUI must be FIPS compliant. |
36-
| DoDIN APL | 140-2 or 140-3 | Approved IT products must include FIPS validation. |
37-
| FAA | 140-2 transitioning to 140-3 | 140-2 modules common in existing systems; new systems use 140-3. |
38-
| FERPA | 140-2 or 140-3 | Federal-funded educational systems align with 140-2 or 140-3. |
39-
| FedRAMP | 140-2 or 140-3 | FIPS required for encryption; both versions accepted. |
40-
| FISMA | 140-2 or 140-3 | Both versions accepted; agencies adopt existing 140-2 modules. |
41-
| HIPAA | 140-2 or 140-3 | FIPS ensures encryption for ePHI; both versions are valid. |
42-
| HITECH | 140-2 or 140-3 | FIPS use aligns with encryption best practices for ePHI. |
43-
| Intelligence Community | 140-2 transitioning to 140-3 | Current systems mostly use 140-2; newer systems adopt 140-3. |
44-
| Military & Tactical Systems | 140-2 transitioning to 140-3 | 140-2 used widely; transitioning to 140-3 certifications for future tools.|
45-
| NSA CSfC | 140-2 transitioning to 140-3 | NSA accepts 140-2 but prefers newer certifications under 140-3. |
46-
| Nuclear Regulatory Commission | 140-2 or 140-3 | Cryptography for nuclear systems relies on both versions. |
47-
| PCI DSS | 140-2 or 140-3 | Both versions recommended but not mandatory. |
48-
| State and Local Gov Programs | 140-2 or 140-3 | FIPS required for federal grant-funded security systems. |
49-
| TSA | 140-2 or 140-3 | Best practice for cryptographic protection; both versions accepted. |
50-
{{< /bootstrap-table >}}
27+
{{< table >}}
28+
| **Sector / Program** | **Version** | **Status** |
29+
|--------------------------------|----------------|---------------|
30+
| **Federal Programs** | | |
31+
| CJIS | 140-2 or 140-3 | Mandatory |
32+
| FedRAMP | 140-2 or 140-3 | Mandatory |
33+
| FISMA | 140-2 or 140-3 | Mandatory |
34+
| DFARS | 140-2 or 140-3 | Mandatory |
35+
| DoDIN APL | 140-2 or 140-3 | Mandatory |
36+
| FAA | 140-2 to 140-3 | Transitioning |
37+
| TSA | 140-2 or 140-3 | Recommended |
38+
| **Defense & Intelligence** | | |
39+
| CMMC | 140-2 or 140-3 | Mandatory |
40+
| Intelligence Community | 140-2 to 140-3 | Transitioning |
41+
| NSA CSfC | 140-2 to 140-3 | Transitioning |
42+
| Military & Tactical Systems | 140-2 to 140-3 | Transitioning |
43+
| **Healthcare & Education** | | |
44+
| HIPAA | 140-2 or 140-3 | Mandatory |
45+
| HITECH | 140-2 or 140-3 | Mandatory |
46+
| Department of Veterans Affairs | 140-2 or 140-3 | Mandatory |
47+
| FERPA | 140-2 or 140-3 | Recommended |
48+
| **Commercial/Private Sector** | | |
49+
| PCI DSS | 140-2 or 140-3 | Recommended |
50+
| Common Criteria | 140-2 or 140-3 | Recommended |
51+
| **Infrastructure & Critical Systems** | | |
52+
| Critical Infrastructure | 140-2 or 140-3 | Recommended |
53+
| Nuclear Regulatory Commission | 140-2 or 140-3 | Recommended |
54+
| **State & Local Government** | | |
55+
| State and Local Gov Programs | 140-2 or 140-3 | Mandatory |
56+
{{< /table >}}
5157

5258
### FIPS compliance in other countries
5359

5460
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.
5561

56-
{{<bootstrap-table "table table-striped table-bordered table-sm">}}
62+
{{< table >}}
5763
| Country/Region | FIPS Use |
5864
|----------------|-----------------------------------------------------------------------------|
5965
| Australia | Referenced for government, defense, and cryptography systems. |
@@ -74,7 +80,7 @@ Although FIPS 140 is primarily a North American government cryptographic standar
7480
| UAE | Trusted in finance, energy, and interoperability with the U.S. cryptography.|
7581
| United Kingdom | Referenced for defense, health, and procurement standards. |
7682
| United States | Mandatory for federal government systems and contractors. |
77-
{{< /bootstrap-table >}}
83+
{{< /table >}}
7884

7985
## FIPS compliant vs FIPS validated
8086

@@ -129,7 +135,7 @@ The process uses Red Hat Enterprise Linux (RHEL) release 9.6 as an example and c
129135

130136
### Step 1: Configure the operating system to use FIPS mode {#os-fips-setup}
131137

132-
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.
138+
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.
133139

134140
For instructions for enabling FIPS mode on other FIPS‑compliant Linux operating systems, see the operating system documentation, for example:
135141

0 commit comments

Comments
 (0)